draft-ietf-rtgwg-ni-model-03.txt   draft-ietf-rtgwg-ni-model-04.txt 
Network Working Group L. Berger Network Working Group L. Berger
Internet-Draft LabN Consulting, L.L.C. Internet-Draft LabN Consulting, L.L.C.
Intended status: Standards Track C. Hopps Intended status: Standards Track C. Hopps
Expires: January 4, 2018 Deutsche Telekom Expires: March 30, 2018 Deutsche Telekom
A. Lindem A. Lindem
Cisco Systems Cisco Systems
D. Bogdanovic D. Bogdanovic
X. Liu X. Liu
Jabil Jabil
July 3, 2017 September 26, 2017
YANG Network Instances YANG Network Instances
draft-ietf-rtgwg-ni-model-03 draft-ietf-rtgwg-ni-model-04
Abstract Abstract
This document defines a network instance module. This module can be This document defines a network instance module. This module can be
used to manage the virtual resource partitioning that may be present used to manage the virtual resource partitioning that may be present
on a network device. Examples of common industry terms for virtual on a network device. Examples of common industry terms for virtual
resource partitioning are Virtual Routing and Forwarding (VRF) resource partitioning are Virtual Routing and Forwarding (VRF)
instances and Virtual Switch Instances (VSIs). instances and Virtual Switch Instances (VSIs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on March 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Status of Work and Open Issues . . . . . . . . . . . . . 3 1.2. Status of Work and Open Issues . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5
3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6 3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6
3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7 3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7
3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8 3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8
3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9 3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9
3.3. Network Instance Management . . . . . . . . . . . . . . . 11 3.3. Network Instance Management . . . . . . . . . . . . . . . 11
3.4. Network Instance Instantiation . . . . . . . . . . . . . 13 3.4. Network Instance Instantiation . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23
Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 22 Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23
B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 22 B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23
B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 25 B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document defines the second of two new modules that are defined This document defines the second of two new modules that are defined
to support the configuration and operation of network-devices that to support the configuration and operation of network-devices that
allow for the partitioning of resources from both, or either, allow for the partitioning of resources from both, or either,
management and networking perspectives. Both leverage the YANG management and networking perspectives. Both leverage the YANG
functionality enabled by YANG Schema Mount functionality enabled by YANG Schema Mount
[I-D.ietf-netmod-schema-mount]. [I-D.ietf-netmod-schema-mount].
skipping to change at page 6, line 12 skipping to change at page 6, line 12
The NI model can be represented using the tree format defined in The NI model can be represented using the tree format defined in
[I-D.ietf-netmod-yang-tree-diagrams] as: [I-D.ietf-netmod-yang-tree-diagrams] as:
module: ietf-network-instance module: ietf-network-instance
+--rw network-instances +--rw network-instances
+--rw network-instance* [name] +--rw network-instance* [name]
+--rw name string +--rw name string
+--rw enabled? boolean +--rw enabled? boolean
+--rw description? string +--rw description? string
+--rw (ni-type)? +--rw (ni-type)?
+--rw (root-type)? +--rw (root-type)
+--:(vrf-root) +--:(vrf-root)
| +--mp vrf-root? | +--mp vrf-root
+--:(vsi-root) +--:(vsi-root)
| +--mp vsi-root? | +--mp vsi-root
+--:(vv-root) +--:(vv-root)
+--mp vv-root? +--mp vv-root
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw bind-ni-name? -> /network-instances/network-instance/name +--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv4: augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-ni-name? -> /network-instances/network-instance/name +--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv6: augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-ni-name? -> /network-instances/network-instance/name +--rw bind-ni-name? -> /network-instances/network-instance/name
notifications: notifications:
+---n bind-ni-name-failed +---n bind-ni-name-failed
+--ro name -> /if:interfaces/interface/name +--ro name -> /if:interfaces/interface/name
skipping to change at page 9, line 17 skipping to change at page 9, line 17
+--rw network-instance* [name] +--rw network-instance* [name]
+--rw name string +--rw name string
+--rw enabled? boolean +--rw enabled? boolean
+--rw description? string +--rw description? string
+--rw (ni-type)? +--rw (ni-type)?
| +--:(l3vpn) | +--:(l3vpn)
| +--rw l3vpn:l3vpn | +--rw l3vpn:l3vpn
| | ... // config data | | ... // config data
| +--ro l3vpn:l3vpn-state | +--ro l3vpn:l3vpn-state
| | ... // state data | | ... // state data
+--rw (root-type)? +--rw (root-type)
+--:(vrf-root) +--:(vrf-root)
+--mp vrf-root +--mp vrf-root
+--ro rt:routing-state/ +--ro rt:routing-state/
| +--ro router-id? yang:dotted-quad | +--ro router-id? yang:dotted-quad
| +--ro control-plane-protocols | +--ro control-plane-protocols
| +--ro control-plane-protocol* [type name] | +--ro control-plane-protocol* [type name]
| +--ro ospf:ospf/ | +--ro ospf:ospf/
| +--ro instance* [af] | +--ro instance* [af]
+--rw rt:routing/ +--rw rt:routing/
| +--rw router-id? yang:dotted-quad | +--rw router-id? yang:dotted-quad
skipping to change at page 11, line 15 skipping to change at page 11, line 15
3.3. Network Instance Management 3.3. Network Instance Management
Modules that may be used to represent network instance information Modules that may be used to represent network instance information
will be available under the ni-type specific 'root' mount point. The will be available under the ni-type specific 'root' mount point. The
use-schema mechanism defined as part of the Schema Mount module use-schema mechanism defined as part of the Schema Mount module
[I-D.ietf-netmod-schema-mount] MUST be used with the module defined [I-D.ietf-netmod-schema-mount] MUST be used with the module defined
in this document to identify accessible modules. A future version of in this document to identify accessible modules. A future version of
this document could relax this requirement. Mounted modules in the this document could relax this requirement. Mounted modules in the
non-inline case SHOULD be defined with access, via the appropriate non-inline case SHOULD be defined with access, via the appropriate
schema mount parent-references [I-D.ietf-netmod-schema-mount], to schema mount parent-references [I-D.ietf-netmod-schema-mount], to
device resources such as interfaces. device resources such as interfaces. An implementation MAY choose to
restrict parent referenced information to information related to a
specific instance, e.g., only allowing references to interfaces that
have a "bind-network-instance-name" which is identical to the
instance's "name".
All modules that represent control-plane and data-plane information All modules that represent control-plane and data-plane information
may be present at the 'root' mount point, and be accessible via paths may be present at the 'root' mount point, and be accessible via paths
modified per [I-D.ietf-netmod-schema-mount]. The list of available modified per [I-D.ietf-netmod-schema-mount]. The list of available
modules is expected to be implementation dependent, as is the method modules is expected to be implementation dependent, as is the method
used by an implementation to support NIs. used by an implementation to support NIs.
For example, the following could be used to define the data For example, the following could be used to define the data
organization of the example NI shown in Section 3.1.2: organization of the example NI shown in Section 3.1.2:
skipping to change at page 13, line 5 skipping to change at page 12, line 50
] ]
} }
Module data identified under "schema" will be instantiated under the Module data identified under "schema" will be instantiated under the
mount point identified under "mount-point". These modules will be mount point identified under "mount-point". These modules will be
able to reference information for nodes belonging to top-level able to reference information for nodes belonging to top-level
modules that are identified under "parent-reference". Parent modules that are identified under "parent-reference". Parent
referenced information is available to clients via their top level referenced information is available to clients via their top level
paths only, and not under the associated mount point. paths only, and not under the associated mount point.
To allow a client to understand the previously mentioned instance
restrictions on parent referenced information, an implementation MAY
represent such restrictions in the "parent-reference" leaf-list. For
example:
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"parent-reference": [
"/if:interfaces/if:interface
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface
[if:name = /if:interfaces/if:interface
[ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv4
[if:name = /if:interfaces/if:interface/ip:ipv4
[ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv6
[if:name = /if:interfaces/if:interface/ip:ipv4
[ni:bind-ni-name = current()/../ni:name]/if:name]",
]
}
],
3.4. Network Instance Instantiation 3.4. Network Instance Instantiation
Network instances may be controlled by clients using existing list Network instances may be controlled by clients using existing list
operations. When a list entry is created, a new instance is operations. When a list entry is created, a new instance is
instantiated. The models mounted under an NI root are expected to be instantiated. The models mounted under an NI root are expected to be
dependent on the server implementation. When a list entry is dependent on the server implementation. When a list entry is
deleted, an existing network instance is destroyed. For more deleted, an existing network instance is destroyed. For more
information, see [RFC7950] Section 7.8.6. information, see [RFC7950] Section 7.8.6.
Once instantiated, host network device resources can be associated Once instantiated, host network device resources can be associated
skipping to change at page 14, line 35 skipping to change at page 15, line 24
name: ietf-network-instance name: ietf-network-instance
namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance
prefix: ni prefix: ni
reference: RFC XXXX reference: RFC XXXX
6. Network Instance Model 6. Network Instance Model
The structure of the model defined in this document is described by The structure of the model defined in this document is described by
the YANG module below. the YANG module below.
<CODE BEGINS> file "ietf-network-instance@2017-07-03.yang" <CODE BEGINS> file "ietf-network-instance@2017-09-27.yang"
module ietf-network-instance { module ietf-network-instance {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance";
prefix ni; prefix ni;
// import some basic types // import some basic types
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference "RFC 7223: A YANG Data Model for Interface reference "RFC 7223: A YANG Data Model for Interface
skipping to change at page 15, line 47 skipping to change at page 16, line 35
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove // RFC Ed.: replace XXXX with actual RFC number and remove
// this note // this note
// RFC Ed.: please update TBD // RFC Ed.: please update TBD
revision 2017-07-02 { revision 2017-09-27 {
description description
"Initial revision."; "Initial revision.";
reference "RFC TBD"; reference "RFC TBD";
} }
// top level device definition statements // top level device definition statements
container network-instances { container network-instances {
description description
"Network instances each of which consists of a "Network instances each of which consists of a
VRFs (virtual routing and forwarding) and/or VRFs (virtual routing and forwarding) and/or
VSIs (virtual switching instances)."; VSIs (virtual switching instances).";
reference "RFC 8022 - A YANG Data Model for Routing reference "RFC 8022 - A YANG Data Model for Routing
Management"; Management";
list network-instance { list network-instance {
skipping to change at page 16, line 19 skipping to change at page 17, line 8
VRFs (virtual routing and forwarding) and/or VRFs (virtual routing and forwarding) and/or
VSIs (virtual switching instances)."; VSIs (virtual switching instances).";
reference "RFC 8022 - A YANG Data Model for Routing reference "RFC 8022 - A YANG Data Model for Routing
Management"; Management";
list network-instance { list network-instance {
key "name"; key "name";
description description
"List of network-instances."; "List of network-instances.";
leaf name { leaf name {
type string; type string;
mandatory true;
description description
"device scoped identifier for the network "device scoped identifier for the network
instance."; instance.";
} }
leaf enabled { leaf enabled {
type boolean; type boolean;
default "true"; default "true";
description description
"Flag indicating whether or not the network "Flag indicating whether or not the network
instance is enabled."; instance is enabled.";
skipping to change at page 16, line 47 skipping to change at page 17, line 37
description description
"This node serves as an anchor point for different types "This node serves as an anchor point for different types
of network instances. Each 'case' is expected to of network instances. Each 'case' is expected to
differ in terms of the information needed in the differ in terms of the information needed in the
parent/core to support the NI, and may differ in their parent/core to support the NI, and may differ in their
mounted schema definition. When the mounted schema is mounted schema definition. When the mounted schema is
not expected to be the same for a specific type of NI not expected to be the same for a specific type of NI
a mount point should be defined."; a mount point should be defined.";
} }
choice root-type { choice root-type {
mandatory true;
description description
"Well known mount points."; "Well known mount points.";
yangmnt:mount-point "vrf-root" { container vrf-root {
description description
"Root for L3VPN type models. This will typically "Container for mount point.";
not be an inline type mount point."; yangmnt:mount-point "vrf-root" {
description
"Root for L3VPN type models. This will typically
not be an inline type mount point.";
}
} }
yangmnt:mount-point "vsi-root" { container vsi-root {
description description
"Root for L2VPN type models. This will typically "Container for mount point.";
not be an inline type mount point.";
yangmnt:mount-point "vsi-root" {
description
"Root for L2VPN type models. This will typically
not be an inline type mount point.";
}
} }
yangmnt:mount-point "vv-root" { container vv-root {
description description
"Root models that support both L2VPN type bridging "Container for mount point.";
and L3VPN type routing. This will typically yangmnt:mount-point "vv-root" {
not be an inline type mount point."; description
"Root models that support both L2VPN type bridging
and L3VPN type routing. This will typically
not be an inline type mount point.";
}
} }
} }
} }
} }
// augment statements // augment statements
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
description description
"Add a node for the identification of the network "Add a node for the identification of the network
skipping to change at page 20, line 20 skipping to change at page 21, line 22
} }
} }
<CODE ENDS> <CODE ENDS>
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-netmod-schema-mount] [I-D.ietf-netmod-schema-mount]
Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-
ietf-netmod-schema-mount-05 (work in progress), May 2017. ietf-netmod-schema-mount-06 (work in progress), July 2017.
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-01 (work in progress), June ietf-netmod-yang-tree-diagrams-01 (work in progress), June
2017. 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc7223>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014, RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>. <https://www.rfc-editor.org/info/rfc7277>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-bess-l2vpn-yang] [I-D.ietf-bess-l2vpn-yang]
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
and K. Tiruveedhula, "YANG Data Model for MPLS-based and K. Tiruveedhula, "YANG Data Model for MPLS-based
L2VPN", draft-ietf-bess-l2vpn-yang-05 (work in progress), L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress),
March 2017. June 2017.
[I-D.ietf-bess-l3vpn-yang] [I-D.ietf-bess-l3vpn-yang]
Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,
Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model
for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-01 (work for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-01 (work
in progress), April 2017. in progress), April 2017.
[I-D.ietf-ospf-yang] [I-D.ietf-ospf-yang]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"Yang Data Model for OSPF Protocol", draft-ietf-ospf- "Yang Data Model for OSPF Protocol", draft-ietf-ospf-
yang-08 (work in progress), July 2017. yang-08 (work in progress), July 2017.
[I-D.ietf-rtgwg-device-model] [I-D.ietf-rtgwg-device-model]
Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
"Network Device YANG Logical Organization", draft-ietf- "Network Device YANG Logical Organization", draft-ietf-
rtgwg-device-model-02 (work in progress), March 2017. rtgwg-device-model-02 (work in progress), March 2017.
[I-D.ietf-rtgwg-lne-model] [I-D.ietf-rtgwg-lne-model]
Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
"YANG Logical Network Elements", draft-ietf-rtgwg-lne- Liu, "YANG Logical Network Elements", draft-ietf-rtgwg-
model-02 (work in progress), March 2017. lne-model-03 (work in progress), July 2017.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005, DOI 10.17487/RFC4026, March 2005,
<http://www.rfc-editor.org/info/rfc4026>. <https://www.rfc-editor.org/info/rfc4026>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, 2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006, DOI 10.17487/RFC4664, September 2006,
<http://www.rfc-editor.org/info/rfc4664>. <https://www.rfc-editor.org/info/rfc4664>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", RFC 8022, DOI 10.17487/RFC8022, November Management", RFC 8022, DOI 10.17487/RFC8022, November
2016, <http://www.rfc-editor.org/info/rfc8022>. 2016, <https://www.rfc-editor.org/info/rfc8022>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The Routing Area Yang Architecture design team members included Acee The Routing Area Yang Architecture design team members included Acee
Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger,
Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review
comments were also received by Martin Bjorklund and John Scudder. comments were also received by Martin Bjorklund and John Scudder.
This document was motivated by, and derived from, This document was motivated by, and derived from,
[I-D.ietf-rtgwg-device-model]. [I-D.ietf-rtgwg-device-model].
 End of changes. 39 change blocks. 
50 lines changed or deleted 107 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/