draft-ietf-rtgwg-ni-model-06.txt   draft-ietf-rtgwg-ni-model-07.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: July 20, 2018 Deutsche Telekom Expires: August 7, 2018 Deutsche Telekom
A. Lindem A. Lindem
Cisco Systems Cisco Systems
D. Bogdanovic D. Bogdanovic
X. Liu X. Liu
Jabil Jabil
January 16, 2018 February 3, 2018
YANG Network Instances YANG Network Instances
draft-ietf-rtgwg-ni-model-06 draft-ietf-rtgwg-ni-model-07
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://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 July 20, 2018. This Internet-Draft will expire on August 7, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (http://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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . 10
3.4. Network Instance Instantiation . . . . . . . . . . . . . 13 3.4. Network Instance Instantiation . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 15 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23
Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23 Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23
B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23 B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23
B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 26 B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | | | | | | | | | | | | | |
Interfaces Interfaces Interfaces Interfaces
Figure 1: Module Element Relationships Figure 1: Module Element Relationships
A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the
model for NIs is covered in this document in Section 3. model for NIs is covered in this document in Section 3.
The current interface management model [RFC7223] is impacted by the The current interface management model [I-D.ietf-netmod-rfc7223bis]
definition of LNEs and NIs. This document and is impacted by the definition of LNEs and NIs. This document and
[I-D.ietf-rtgwg-lne-model] define augmentations to the interface [I-D.ietf-rtgwg-lne-model] define augmentations to the interface
module to support LNEs and NIs. module to support LNEs and NIs.
The network instance model supports the configuration of VRFs and The network instance model supports the configuration of VRFs and
VSIs. Each instance is supported by information that relates to the VSIs. Each instance is supported by information that relates to the
device, for example the route target used when advertising VRF routes device, for example the route target used when advertising VRF routes
via the mechanisms defined in [RFC4364], and information that relates via the mechanisms defined in [RFC4364], and information that relates
to the internal operation of the NI, for example for routing to the internal operation of the NI, for example for routing
protocols [RFC8022] and OSPF [I-D.ietf-ospf-yang]. This document protocols [I-D.ietf-netmod-rfc8022bis] and OSPF [I-D.ietf-ospf-yang].
defines the network-instance module that provides a basis for the This document defines the network-instance module that provides a
management of both types of information. basis for the management of both types of information.
NI information that relates to the device, including the assignment NI information that relates to the device, including the assignment
of interfaces to NIs, is defined as part of this document. The of interfaces to NIs, is defined as part of this document. The
defined module also provides a placeholder for the definition of NI- defined module also provides a placeholder for the definition of NI-
technology specific information both at the device level and for NI technology specific information both at the device level and for NI
internal operation. Information related to NI internal operation is internal operation. Information related to NI internal operation is
supported via schema mount [I-D.ietf-netmod-schema-mount] and supported via schema mount [I-D.ietf-netmod-schema-mount] and
mounting appropriate modules under the mount point. Well known mount mounting appropriate modules under the mount point. Well known mount
points are defined for L3VPN, L2VPN, and L2+L3VPN NI types. points are defined for L3VPN, L2VPN, and L2+L3VPN NI types.
skipping to change at page 9, line 20 skipping to change at page 8, line 38
+--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 router-id? yang:dotted-quad
| +--ro control-plane-protocols
| +--ro control-plane-protocol* [type name]
| +--ro ospf:ospf/
| +--ro instance* [af]
+--rw rt:routing/ +--rw rt:routing/
| +--rw router-id? yang:dotted-quad | +--rw router-id? yang:dotted-quad
| +--rw control-plane-protocols | +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name] | +--rw control-plane-protocol* [type name]
| +--rw ospf:ospf/ | +--rw ospf:ospf/
| +--rw instance* [af] | +--rw instance* [af]
| +--rw areas | +--rw areas
| +--rw area* [area-id] | +--rw area* [area-id]
| +--rw interfaces | +--rw interfaces
| +--rw interface* [name] | +--rw interface* [name]
| +--rw name if:interface-ref | +--rw name if:interface-ref
| +--rw cost? uint16 | +--rw cost? uint16
+--ro if:interfaces@ +--ro if:interfaces@
| ... | ...
+--ro if:interfaces-state@
| ...
This shows YANG Routing Management [RFC8022] and YANG OSPF This shows YANG Routing Management [I-D.ietf-netmod-rfc8022bis] and
[I-D.ietf-ospf-yang] as mounted modules. The mounted modules can YANG OSPF [I-D.ietf-ospf-yang] as mounted modules. The mounted
reference interface information via a parent-reference to the modules can reference interface information via a parent-reference to
containers defined in [RFC7223]. the containers defined in [I-D.ietf-netmod-rfc7223bis].
3.2. NIs and Interfaces 3.2. NIs and Interfaces
Interfaces are a crucial part of any network device's configuration Interfaces are a crucial part of any network device's configuration
and operational state. They generally include a combination of raw and operational state. They generally include a combination of raw
physical interfaces, link-layer interfaces, addressing configuration, physical interfaces, link-layer interfaces, addressing configuration,
and logical interfaces that may not be tied to any physical and logical interfaces that may not be tied to any physical
interface. Several system services, and layer 2 and layer 3 interface. Several system services, and layer 2 and layer 3
protocols may also associate configuration or operational state data protocols may also associate configuration or operational state data
with different types of interfaces (these relationships are not shown with different types of interfaces (these relationships are not shown
for simplicity). The interface management model is defined by for simplicity). The interface management model is defined by
[RFC7223]. [I-D.ietf-netmod-rfc7223bis].
As shown below, the network-instance module augments the existing As shown below, the network-instance module augments the existing
interface management model by adding a name which is used on interface management model by adding a name which is used on
interface or sub-interface types to identify an associated network interface or sub-interface types to identify an associated network
instance. Similarly, this name is also added for IPv4 and IPv6 instance. Similarly, this name is also added for IPv4 and IPv6
types, as defined in [RFC7277]. types, as defined in [I-D.ietf-netmod-rfc7277bis].
The following is an example of envisioned usage. The interfaces The following is an example of envisioned usage. The interfaces
container includes a number of commonly used components as examples: container includes a number of commonly used components as examples:
module: ietf-interfaces module: ietf-interfaces
+--rw interfaces +--rw interfaces
| +--rw interface* [name] | +--rw interface* [name]
| +--rw name string | +--rw name string
| +--rw ip:ipv4! | +--rw ip:ipv4!
| | +--rw ip:enabled? boolean | | +--rw ip:enabled? boolean
skipping to change at page 10, line 41 skipping to change at page 10, line 5
| | | +--:(ip:prefix-length) | | | +--:(ip:prefix-length)
| | | | +--rw ip:prefix-length? uint8 | | | | +--rw ip:prefix-length? uint8
| | | +--:(ip:netmask) | | | +--:(ip:netmask)
| | | +--rw ip:netmask? yang:dotted-quad | | | +--rw ip:netmask? yang:dotted-quad
| | +--rw ip:neighbor* [ip] | | +--rw ip:neighbor* [ip]
| | | +--rw ip:ip inet:ipv4-address-no-zone | | | +--rw ip:ip inet:ipv4-address-no-zone
| | | +--rw ip:link-layer-address yang:phys-address | | | +--rw ip:link-layer-address yang:phys-address
| | +--rw ni:bind-network-instance-name? string | | +--rw ni:bind-network-instance-name? string
| +--rw ni:bind-network-instance-name? string | +--rw ni:bind-network-instance-name? string
The [RFC7223] defined interface model is structured to include all The [I-D.ietf-netmod-rfc7223bis] defined interface model is
interfaces in a flat list, without regard to virtual instances (e.g., structured to include all interfaces in a flat list, without regard
VRFs) supported on the device. The bind-network-instance-name leaf to virtual instances (e.g., VRFs) supported on the device. The bind-
provides the association between an interface and its associated NI network-instance-name leaf provides the association between an
(e.g., VRF or VSI). Note that as currently defined, to assign an interface and its associated NI (e.g., VRF or VSI). Note that as
interface to both an LNE and NI, the interface would first be currently defined, to assign an interface to both an LNE and NI, the
assigned to the LNE using the mechanisms defined in interface would first be assigned to the LNE using the mechanisms
[I-D.ietf-rtgwg-lne-model] and then within that LNE's interface defined in [I-D.ietf-rtgwg-lne-model] and then within that LNE's
module, the LNE's representation of that interface would be assigned interface module, the LNE's representation of that interface would be
to an NI. assigned to an NI.
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
skipping to change at page 12, line 26 skipping to change at page 11, line 26
} }
] ]
} }
], ],
"schema": [ "schema": [
{ {
"name": "ni-schema", "name": "ni-schema",
"module": [ "module": [
{ {
"name": "ietf-routing", "name": "ietf-routing",
"revision": "2016-11-04", "revision": "2018-01-25",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing", "urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-ospf", "name": "ietf-ospf",
"revision": "2017-03-12", "revision": "2017-10-30",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf", "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement" "conformance-type": "implement"
} }
] ]
} }
] ]
} }
Module data identified under "schema" will be instantiated under the Module data identified under "schema" will be instantiated under the
skipping to change at page 14, line 13 skipping to change at page 13, line 13
associations for interfaces. When a bind-ni-name is set to a valid associations for interfaces. When a bind-ni-name is set to a valid
NI name, an implementation MUST take whatever steps are internally NI name, an implementation MUST take whatever steps are internally
necessary to assign the interface to the NI or provide an error necessary to assign the interface to the NI or provide an error
message (defined below) with an indication of why the assignment message (defined below) with an indication of why the assignment
failed. It is possible for the assignment to fail while processing failed. It is possible for the assignment to fail while processing
the set operation, or after asynchronous processing. Error the set operation, or after asynchronous processing. Error
notification in the latter case is supported via a notification. notification in the latter case is supported via a notification.
4. Security Considerations 4. Security Considerations
The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246].
The NETCONF access control model [RFC6536] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are two different sets of security considerations to consider There are two different sets of security considerations to consider
in the context of this document. One set is security related to in the context of this document. One set is security related to
information contained within mounted modules. The security information contained within mounted modules. The security
considerations for mounted modules are not substantively changed considerations for mounted modules are not substantively changed
based on the information being accessible within the context of an based on the information being accessible within the context of an
NI. For example, when considering the modules defined in [RFC8022], NI. For example, when considering the modules defined in
the security considerations identified in that document are equally [I-D.ietf-netmod-rfc8022bis], the security considerations identified
applicable, whether those modules are accessed at a server's root or in that document are equally applicable, whether those modules are
under an NI instance's root node. accessed at a server's root or under an NI instance's root node.
The second area for consideration is information contained in the NI The second area for consideration is information contained in the NI
module itself. NI information represents network configuration and module itself. NI information represents network configuration and
route distribution policy information. As such, the security of this route distribution policy information. As such, the security of this
information is important, but it is fundamentally no different than information is important, but it is fundamentally no different than
any other interface or routing configuration information that has any other interface or routing configuration information that has
already been covered in [RFC7223] and [RFC8022]. already been covered in [I-D.ietf-netmod-rfc7223bis] and
[I-D.ietf-netmod-rfc8022bis].
The vulnerable "config true" parameters and subtrees are the The vulnerable "config true" parameters and subtrees are the
following: following:
/network-instances/network-instance: This list specifies the network /network-instances/network-instance: This list specifies the network
instances and the related control plane protocols configured on a instances and the related control plane protocols configured on a
device. device.
/if:interfaces/if:interface/*/bind-network-instance-name: This leaf /if:interfaces/if:interface/*/bind-network-instance-name: This leaf
indicates the NI instance to which an interface is assigned. indicates the NI instance to which an interface is assigned.
skipping to change at page 15, line 24 skipping to change at page 14, line 38
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-12-04.yang" <CODE BEGINS> file "ietf-network-instance@2018-02-03.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 "draft-ietf-netmod-rfc7223bis: A YANG Data Model
Management"; for Interface Management";
} }
import ietf-ip { import ietf-ip {
prefix ip; prefix ip;
reference "RFC 7277: A YANG Data Model for IP Management"; reference "draft-ietf-netmod-rfc7277bis: A YANG Data Model
for IP Management";
} }
import ietf-yang-schema-mount { import ietf-yang-schema-mount {
prefix yangmnt; prefix yangmnt;
reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; reference "draft-ietf-netmod-schema-mount: YANG Schema Mount";
// RFC Ed.: Please replace this draft name with the // RFC Ed.: Please replace this draft name with the
// corresponding RFC number // corresponding RFC number
} }
organization organization
"IETF Routing Area (rtgwg) Working Group"; "IETF Routing Area (rtgwg) Working Group";
skipping to change at page 16, line 35 skipping to change at page 15, line 51
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-12-04 { revision 2018-02-03 {
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 "draft-ietf-rtgwg-rfc8022bis - A YANG Data Model
Management"; for Routing 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; mandatory true;
description description
"device scoped identifier for the network "device scoped identifier for the network
instance."; instance.";
skipping to change at page 21, line 20 skipping to change at page 20, line 38
failure."; failure.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-netmod-rfc7223bis]
Bjorklund, M., "A YANG Data Model for Interface
Management", draft-ietf-netmod-rfc7223bis-03 (work in
progress), January 2018.
[I-D.ietf-netmod-rfc7277bis]
Bjorklund, M., "A YANG Data Model for IP Management",
draft-ietf-netmod-rfc7277bis-03 (work in progress),
January 2018.
[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-08 (work in progress), October ietf-netmod-schema-mount-08 (work in progress), October
2017. 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-04 (work in progress), ietf-netmod-yang-tree-diagrams-05 (work in progress),
December 2017. January 2018.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. 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, <https://www.rfc- DOI 10.17487/RFC3688, January 2004, <https://www.rfc-
editor.org/info/rfc3688>. editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>.
[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, <https://www.rfc- DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
editor.org/info/rfc6020>. editor.org/info/rfc6020>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, and A. Bierman, Ed., "Network Configuration Protocol
<https://www.rfc-editor.org/info/rfc7223>. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
RFC 7277, DOI 10.17487/RFC7277, June 2014, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc7277>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
editor.org/info/rfc6536>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
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-07 (work in progress), L2VPN", draft-ietf-bess-l2vpn-yang-07 (work in progress),
October 2017. October 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-02 (work for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-02 (work
in progress), October 2017. in progress), October 2017.
[I-D.ietf-netmod-rfc8022bis]
Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", draft-ietf-netmod-
rfc8022bis-11 (work in progress), January 2018.
[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-09 (work in progress), October 2017. yang-09 (work in progress), October 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.
skipping to change at page 23, line 5 skipping to change at page 23, line 9
[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, <https://www.rfc- DOI 10.17487/RFC4664, September 2006, <https://www.rfc-
editor.org/info/rfc4664>. 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,
<https://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
Management", RFC 8022, DOI 10.17487/RFC8022, November
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].
Thanks for AD and IETF last call comments from Alia Atlas and Liang
Xia.
The RFC text was produced using Marshall Rose's xml2rfc tool. The RFC text was produced using Marshall Rose's xml2rfc tool.
Appendix B. Example NI usage Appendix B. Example NI usage
The following subsections provide example uses of NIs. The following subsections provide example uses of NIs.
B.1. Configuration Data B.1. Configuration Data
The following shows an example where two customer specific network The following shows an example where two customer specific network
instances are configured: instances are configured:
 End of changes. 32 change blocks. 
66 lines changed or deleted 102 lines changed or added

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