< draft-ietf-rtgwg-lne-model-00.txt   draft-ietf-rtgwg-lne-model-01.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: December 25, 2016 Deutsche Telekom Expires: May 1, 2017 Deutsche Telekom
A. Lindem A. Lindem
Cisco Systems Cisco Systems
D. Bogdanovic D. Bogdanovic
June 23, 2016 October 28, 2016
Logical Network Element Model YANG Logical Network Elements
draft-ietf-rtgwg-lne-model-00 draft-ietf-rtgwg-lne-model-01
Abstract Abstract
This document defines a logical network element module. This module This document defines a logical network element module. This module
along with the network instance module can be used to manage the along with the network instance module can be used to manage the
logical and virtual resource representations that may be present on a logical and virtual resource representations that may be present on a
network device. Examples of common industry terms for logical network device. Examples of common industry terms for logical
resource representations are Logical Systems or Logical Routers. resource representations are Logical Systems or Logical Routers.
Examples of of common industry terms for virtual resource Examples of of common industry terms for virtual resource
representations are Virtual Routing and Forwarding (VRF) instances representations are Virtual Routing and Forwarding (VRF) instances
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 December 25, 2016. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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. Status of Work and Open Issues . . . . . . . . . . . . . 3 1.1. Status of Work and Open Issues . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Logical Network Elements . . . . . . . . . . . . . . . . . . 6 3. Logical Network Elements . . . . . . . . . . . . . . . . . . 6
3.1. LNE Management - Host Network Device View . . . . . . . . 6 3.1. LNE Management - Host Network Device View . . . . . . . . 6
3.2. LNE Management - LNE View . . . . . . . . . . . . . . . . 8 3.2. LNE Management - LNE View . . . . . . . . . . . . . . . . 8
3.3. LNE Instantiation . . . . . . . . . . . . . . . . . . . . 8 3.3. LNE Instantiation . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Logical Network Element Model . . . . . . . . . . . . . . . . 8 6. Logical Network Element Model . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document defines a YANG [RFC6020] module to support the creation This document defines a YANG [RFC6020] module to support the creation
of logical network elements on a network device. A logical network of logical network elements on a network device. A logical network
element (LNE) is an independently managed virtual device made up of element (LNE) is an independently managed virtual device made up of
resources allocated to it from the host, or parent, network device. resources allocated to it from the host, or parent, network device.
(An LNE running on a host network device conceptually parallels a (An LNE running on a host network device conceptually parallels a
virtual machine running on a host system.) This document also virtual machine running on a host system.) Using host-virtualization
defines the necessary augmentations for allocating host resources to terminology one could refer to an LNE as a "Guest", and the
a given LNE. As the interface management model [RFC7223] is the only containing network-device as the "Host". While LNEs may be
a module that currently defines host resources, this document implemented via host-virtualization technologies this is not a
currently defines only a single augmentation to cover the assignment requirement.
of interfaces to an LNE.
This document also defines the necessary augmentations for allocating
host resources to a given LNE. As the interface management model
[RFC7223] is the only a module that currently defines host resources,
this document currently defines only a single augmentation to cover
the assignment of interfaces to an LNE.
As each LNE is an independently managed device, each will have its As each LNE is an independently managed device, each will have its
own set of YANG modeled data that is independent of the host device own set of YANG modeled data that is independent of the host device
and other LNEs. For example, multiple LNEs may all have their own and other LNEs. For example, multiple LNEs may all have their own
"Tunnel0" interface defined which will not conflict with each other "Tunnel0" interface defined which will not conflict with each other
and will not exist in the host's interface model. An LNE will have and will not exist in the host's interface model. An LNE will have
it's own management interfaces possibly including independent it's own management interfaces possibly including independent
instances of netconf/restconf/etc servers to support configuration of instances of netconf/restconf/etc servers to support configuration of
their YANG models. As an example of this independence, an their YANG models. As an example of this independence, an
implementation may choose to completely rename assigned interfaces, implementation may choose to completely rename assigned interfaces,
so on the host the assigned interface might be called "Ethernet0/1" so on the host the assigned interface might be called "Ethernet0/1"
while within the LNE it might be called "eth1". while within the LNE it might be called "eth1".
In addition to standard management interfaces, a host device In addition to standard management interfaces, a host device
implementation may support accessing LNE configuration and implementation may support accessing LNE configuration and
operational YANG models directly from the host system. When operational YANG models directly from the host system. When
supported, such access is accomplished through a schema-mount mount supported, such access is accomplished through a yang-schema-mount
point [I-D.ietf-netmod-schema-mount] under which the root level LNE mount point [I-D.ietf-netmod-schema-mount] under which the root level
YANG models may be accessed. LNE YANG models may be accessed.
Examples of vendor terminology for an LNE include logical system or Examples of vendor terminology for an LNE include logical system or
logical router, and virtual switch, chassis, or fabric. logical router, and virtual switch, chassis, or fabric.
This document was motivated by, and derived from, [RTG-DEVICE-MODEL]. This document was motivated by, and derived from,
[I-D.ietf-rtgwg-device-model].
1.1. Status of Work and Open Issues 1.1. Status of Work and Open Issues
The top open issues are: The top open issues are:
1. This document will need to match the evolution and 1. This document will need to match the evolution and
standardization of [I-D.openconfig-netmod-opstate] or standardization of [I-D.openconfig-netmod-opstate] or
[I-D.ietf-netmod-opstate-reqs] by the Netmod WG. [I-D.ietf-netmod-opstate-reqs] by the Netmod WG.
It will also make use of emerging YANG functionality supported by It will also make use of emerging YANG functionality supported by
YANG Schema Mount This document is expected to use whatever Schema YANG Schema Mount.
Mount solution is agreed upon by the Netmod Working Group.
2. Overview 2. Overview
In this document, we consider network devices that support protocols In this document, we consider network devices that support protocols
and functions defined within the IETF Routing Area, e.g, routers, and functions defined within the IETF Routing Area, e.g, routers,
firewalls and hosts. Such devices may be physical or virtual, e.g., firewalls and hosts. Such devices may be physical or virtual, e.g.,
a classic router with custom hardware or one residing within a a classic router with custom hardware or one residing within a
server-based virtual machine implementing a virtual network function server-based virtual machine implementing a virtual network function
(VNF). Each device may sub-divide their resources into logical (VNF). Each device may sub-divide their resources into logical
network elements (LNEs) each of which provides a managed logical network elements (LNEs) each of which provides a managed logical
skipping to change at page 4, line 24 skipping to change at page 4, line 26
| : | | | | | | : : | | | | | | : | | : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | | | | | | | | | | | | | |
Interfaces Interfaces Interfaces Interfaces
Figure 1: Module Element Relationships Figure 1: Module Element Relationships
A model for LNEs is described in Section 3 and the model for network A model for LNEs is described in Section 3 and the model for network
instances is covered in [NI-MODEL]. For more information on how instances is covered in [I-D.ietf-rtgwg-ni-model]. For more
these models may be used within an overall device model structure, information on how these models may be used within an overall device
see [RTG-DEVICE-MODEL]. model structure, see [I-D.ietf-rtgwg-device-model].
The interface management model [RFC7223] is and existing model that The interface management model [RFC7223] is and existing model that
is impacted by the definition of LNEs and network instances. This is impacted by the definition of LNEs and network instances. This
document and [NI-MODEL] define augmentations to the interface module document and [I-D.ietf-rtgwg-ni-model] define augmentations to the
to support LNEs and NIs. Similar elements, although perhaps only for interface module to support LNEs and NIs. Similar elements, although
LNEs, may also need to be included as part of the definition of the perhaps only for LNEs, may also need to be included as part of the
future hardware and QoS modules. definition of the future hardware and QoS modules.
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]. [RFC7223].
skipping to change at page 6, line 7 skipping to change at page 6, line 13
| +--rw dhcpv6-client | +--rw dhcpv6-client
The [RFC7223] defined interface model is structured to include all The [RFC7223] defined interface model is structured to include all
interfaces in a flat list, without regard to logical or virtual interfaces in a flat list, without regard to logical or virtual
instances (e.g., VRFs) supported on the device. The bind-lne-name instances (e.g., VRFs) supported on the device. The bind-lne-name
and bind-network-instance-name leaves provide the association between and bind-network-instance-name leaves provide the association between
an interface and its associated LNE and NI (e.g., VRF or VSI). an interface and its associated LNE and NI (e.g., VRF or VSI).
3. Logical Network Elements 3. Logical Network Elements
A logical network element is a network-device which is contained
within another network-device. Using host-virtualization terminology
one could refer to an LNE as a "Guest", and the containing network-
device as the "Host". While LNEs may be implemented via host-
virtualization technologies this is not a requirement.
Logical network elements represent the capability of some devices to Logical network elements represent the capability of some devices to
partition resources into independent logical routers and/or switches. partition resources into independent logical routers and/or switches.
Device support for multiple logical network elements is Device support for multiple logical network elements is
implementation specific. Systems without such capabilities need not implementation specific. Systems without such capabilities need not
include support for the logical-network-element module. In physical include support for the logical-network-element module. In physical
devices, some hardware features are shared across partitions, but devices, some hardware features are shared across partitions, but
control plane (e.g., routing) protocol instances, tables, and control plane (e.g., routing) protocol instances, tables, and
configuration are managed separately. For example, in virtual configuration are managed separately. For example, in virtual
routers or VNFs, this may correspond to establishing multiple logical routers or VNFs, this may correspond to establishing multiple logical
instances using a single software installation. The model supports instances using a single software installation. The model supports
skipping to change at page 6, line 34 skipping to change at page 6, line 34
list of logical network elements, each with their own configuration list of logical network elements, each with their own configuration
and operational state related to routing and switching protocols, as and operational state related to routing and switching protocols, as
shown below: shown below:
module: ietf-logical-network-element module: ietf-logical-network-element
+--rw logical-network-inventory +--rw logical-network-inventory
+--rw logical-network-element* [name] +--rw logical-network-element* [name]
+--rw name? string +--rw name? string
+--rw description? string +--rw description? string
+--rw managed? boolean +--rw managed? boolean
+--rw root? schema-mount +--rw root? yang-schema-mount
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw bind-lne-name? string +--rw bind-lne-name? string
`name` identifies the logical network element. `managed` indicates `name` identifies the logical network element. `managed` indicates
if the host network device is able to manage the LNE via the `root` if the host network device is able to manage the LNE via the `root`
structure. structure.
3.1. LNE Management - Host Network Device View 3.1. LNE Management - Host Network Device View
There are multiple implementation approaches possible to enable a There are multiple implementation approaches possible to enable a
skipping to change at page 7, line 24 skipping to change at page 7, line 24
context is made available via the `root` element, with paths modified context is made available via the `root` element, with paths modified
as described in [I-D.ietf-netmod-schema-mount]. as described in [I-D.ietf-netmod-schema-mount].
As an example, consider the case where an LNE with a `name` of "one" As an example, consider the case where an LNE with a `name` of "one"
is defined on a network device. In this case the following structure is defined on a network device. In this case the following structure
might be made available: might be made available:
....................................................................... .......................................................................
(network-device state) (network-device state)
+--rw yanglib:modules-state [I-D.ietf-netconf-yang-library] +--rw yanglib:modules-state [RFC7895]
+--rw lne:logical-network-elements [I-D.ietf-rtgwg-lne-model] +--rw lne:logical-network-elements [This document]
+--rw logical-network-element* [name] +--rw logical-network-element* [name]
+--rw name="one" string +--rw name="one" string
+--rw manged=true boolean +--rw manged=true boolean
+--rw root schema-mount +--rw root yang-schema-mount
| |
....................................................................... .......................................................................
| (exposed LNE state if managed=true) | (exposed LNE state if managed=true)
| |
+--rw yanglib:modules-state [I-D.ietf-netconf-yang-library] +--rw yanglib:modules-state [RFC7895]
+--rw if:intefaces [RFC7223] +--rw if:intefaces [RFC7223]
+--rw hardware +--rw hardware
+--rw qos +--rw qos
+--rw system-management +--rw system-management
+--rw network-services +--rw network-services
+--rw oam-protocols +--rw oam-protocols
+--rw rt:routing [I-D.ietf-netmod-routing-cfg] +--rw rt:routing [I-D.ietf-netmod-routing-cfg]
+--rw mpls +--rw mpls
+--rw ieee-dot1Q +--rw ieee-dot1Q
+--rw ni:network-instances [I-D.ietf-rtgwg-ni-model] +--rw ni:network-instances [I-D.ietf-rtgwg-ni-model]
skipping to change at page 8, line 16 skipping to change at page 8, line 16
resource modules. e.g., an LNE's interfaces module will contain the resource modules. e.g., an LNE's interfaces module will contain the
interfaces assigned to that LNE from the containing network-device. interfaces assigned to that LNE from the containing network-device.
3.2. LNE Management - LNE View 3.2. LNE Management - LNE View
Management functions operating with the context of an LNE are Management functions operating with the context of an LNE are
accessed through standard LNE's management interfaces, e.g., NETCONF accessed through standard LNE's management interfaces, e.g., NETCONF
and SNMP. When accessing an LNE via an LNE's management interface, a and SNMP. When accessing an LNE via an LNE's management interface, a
network-device representation will be presented, but its scope will network-device representation will be presented, but its scope will
be limited to the specific LNE. Normal YANG/NETCONF mechanisms, be limited to the specific LNE. Normal YANG/NETCONF mechanisms,
together with yang library [I-D.ietf-netconf-yang-library], can be together with yang library [RFC7895], can be used to identify the
used to identify the available modules. Each supported module will available modules. Each supported module will be presented as a top
be presented as a top level module. Only LNE associated resources level module. Only LNE associated resources will be reflected in
will be reflected in resource related modules, e.g., interfaces, resource related modules, e.g., interfaces, hardware and perhaps QoS.
hardware and perhaps QoS. From the management perspective, there From the management perspective, there will be no difference between
will be no difference between the available LNE view (information) the available LNE view (information) and an a physical network
and an a physical network device. device.
Multiple implementation approaches are possible to provide LNE views, Multiple implementation approaches are possible to provide LNE views,
and these are outside the scope of this document. and these are outside the scope of this document.
3.3. LNE Instantiation 3.3. LNE Instantiation
TBD -- need to resolve if instantiation is based on new list entry Logical network elements may be controlled by clients using existing
creation per the pending Schema Mount solution definition. list operations. When list entries are created, a new LNE is
instantiated. The models mounted under an LNE root is expected to be
dependent on the server implementation. When a list entry is
deleted, an existing LNE is destroyed. For more information see
[RFC7950] Section 7.8.6.
4. Security Considerations 4. Security Considerations
LNE portion is TBD TBD
NI portion is TBD
5. IANA Considerations 5. IANA Considerations
This YANG model currently uses a temporary ad-hoc namespace. If it This document registers a URI in the IETF XML registry [RFC3688].
is placed or redirected for the standards track, an appropriate Following the format in RFC 3688, the following registration is
namespace URI will be registered in the "IETF XML Registry" requested to be made.
[RFC3688]. The YANG structure modules will be registered in the
"YANG Module Names" registry [RFC6020]. URI: urn:ietf:params:xml:ns:yang:ietf-logical-network-element
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names
registry [RFC6020].
name: ietf-logical-network-element
namespace: urn:ietf:params:xml:ns:yang:ietf-logical-network-element
prefix: lne
reference: RFC XXXX
6. Logical Network Element Model 6. Logical Network Element 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-logical-network-element@2016-06-23.yang" <CODE BEGINS> file "ietf-logical-network-element@2016-10-21.yang"
module ietf-logical-network-element { module ietf-logical-network-element {
yang-version "1";
yang-version 1.1;
// namespace // namespace
namespace "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"; namespace "urn:ietf:params:xml:ns:yang:ietf-logical-network-element";
prefix "lne"; prefix lne;
// import some basic types // import some basic types
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
import ietf-yang-schema-mount {
prefix yangmnt;
}
// meta // meta
organization "IETF Routing Area Working Group (rtgwg)"; organization "IETF Routing Area Working Group (rtgwg)";
contact contact
"Routing Area Working Group - <rtgwg@ietf.org>"; "Routing Area Working Group - <rtgwg@ietf.org>";
description description
"This module is used to support multiple logical network "This module is used to support multiple logical network
elements on a single physical or virtual system."; elements on a single physical or virtual system.";
revision "2016-06-23" { revision "2016-10-21" {
description description
"Initial revision."; "Initial revision.";
reference "RFC TBD"; reference "RFC TBD";
} }
// feature statements // feature statements
feature bind-lne-name { feature bind-lne-name {
description description
"Logical network element to which an interface is bound"; "Logical network element to which an interface is bound";
} }
// top level device definition statements // top level device definition statements
container logical-network-elements { container logical-network-elements {
description "Allows a network device to support multiple logical description "Allows a network device to support multiple logical
network element (device) instances"; network element (device) instances";
list logical-network-element { list logical-network-element {
key name; key name;
description "List of logical network elements"; description "List of logical network elements";
leaf name { leaf name {
type string; type string;
description "Device-wide unique identifier for the description
logical network element"; "Device-wide unique identifier for the
logical network element";
} }
leaf managed { leaf managed {
type boolean; type boolean;
description description
"True if the host can manage the LNE using the root mount "True if the host can manage the LNE using the root mount
point"; point";
} }
leaf description { leaf description {
type string; type string;
description description
"Description of the logical network element"; "Description of the logical network element";
} }
leaf root { anydata root {
type schema-mount; yangmnt:mount-point "root";
description "Root for models supported per logical description
network element"; "Root for models supported per logical
} network element";
}
} }
} }
// augment statements // augment statements
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
description description
"Add a node for the identification of the logical network "Add a node for the identification of the logical network
element associated with an interface. Applies to interfaces element associated with an interface. Applies to interfaces
that can be assigned on a per logical network element basis. that can be assigned on a per logical network element basis.
A <TBD> error is returned when the interface type cannot be A <TBD> error is returned when the interface type cannot be
skipping to change at page 10, line 50 skipping to change at page 11, line 25
} }
<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-01 (work in progress), April ietf-netmod-schema-mount-02 (work in progress), July 2016.
2016.
[NI-MODEL] [I-D.ietf-rtgwg-ni-model]
Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
"Network Instance Model", draft-ietf-rtgwg-ni-model-00.txt "Network Instance Model", draft-ietf-rtgwg-ni-model-00
(work in progress), June 2016. (work in progress), June 2016.
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc6020>.
skipping to change at page 11, line 29 skipping to change at page 12, line 7
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc7277>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-netconf-yang-library]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", draft-ietf-netconf-yang-library-06 (work in
progress), April 2016.
[I-D.ietf-netmod-opstate-reqs] [I-D.ietf-netmod-opstate-reqs]
Watsen, K. and T. Nadeau, "Terminology and Requirements Watsen, K. and T. Nadeau, "Terminology and Requirements
for Enhanced Handling of Operational State", draft-ietf- for Enhanced Handling of Operational State", draft-ietf-
netmod-opstate-reqs-04 (work in progress), January 2016. netmod-opstate-reqs-04 (work in progress), January 2016.
[I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-24 (work in
progress), October 2016.
[I-D.ietf-rtgwg-device-model]
Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
"Network Device YANG Organizational Models", draft-ietf-
rtgwg-device-model-00 (work in progress), August 2016.
[I-D.openconfig-netmod-opstate] [I-D.openconfig-netmod-opstate]
Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
of Operational State Data in YANG", draft-openconfig- of Operational State Data in YANG", draft-openconfig-
netmod-opstate-01 (work in progress), July 2015. netmod-opstate-01 (work in progress), July 2015.
[RTG-DEVICE-MODEL] [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Lindem, A., Ed., Berger, L., Ed., Bogdanovic, D., and C. Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
Hopps, "Network Device YANG Organizational Models", draft- <http://www.rfc-editor.org/info/rfc7895>.
rtgyangdt-rtgwg-device-model-04.txt (work in progress),
May 2016. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>.
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. Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang.
The RFC text was produced using Marshall Rose's xml2rfc tool. The RFC text was produced using Marshall Rose's xml2rfc tool.
Appendix B. Contributors Appendix B. Contributors
Contributors' Addresses Contributors' Addresses
 End of changes. 35 change blocks. 
83 lines changed or deleted 109 lines changed or added

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