< draft-ietf-rtgwg-ni-model-00.txt   draft-ietf-rtgwg-ni-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
Network Instance Model YANG Network Instances
draft-ietf-rtgwg-ni-model-00 draft-ietf-rtgwg-ni-model-01
Abstract Abstract
This document defines a network instance module. This module along This document defines a network instance module. This module along
with the logical network element module can be used to manage the with the logical network element 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 common industry terms for virtual resource Examples 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 24 skipping to change at page 2, line 24
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. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Network Instance Policy . . . . . . . . . . . . . . . . . 6 3.1. Network Instance Policy . . . . . . . . . . . . . . . . . 6
3.2. Network Instance Management . . . . . . . . . . . . . . . 7 3.2. Network Instance Management . . . . . . . . . . . . . . . 7
3.3. Network Instance Instantiation . . . . . . . . . . . . . 8 3.3. Network Instance Instantiation . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 8 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 make use of emerging management and networking perspectives. Both make use of the YANG
YANG functionality supported by YANG Schema Mount functionality enabled by YANG Schema Mount
[I-D.ietf-netmod-schema-mount]. This document is expected to use [I-D.ietf-netmod-schema-mount].
whatever Schema Mount solution is agreed upon by the Netmod Working
Group.
Two forms of resource partitioning are supported: Two forms of resource partitioning are supported:
The first form, which is defined in [LNE-MODEL], provides a logical The first form, which is defined in [I-D.ietf-rtgwg-lne-model],
partitioning of a network device where each partition is separately provides a logical partitioning of a network device where each
managed as essentially an independent network element which is partition is separately managed as essentially an independent network
'hosted' by the base network device. These hosted network elements element which is 'hosted' by the base network device. These hosted
are referred to as logical network elements, or LNEs, and are network elements are referred to as logical network elements, or
supported by the logical-network-element module defined in LNEs, and are supported by the logical-network-element module defined
[LNE-MODEL]. The module is used to identify LNEs and associate in [I-D.ietf-rtgwg-lne-model]. The module is used to identify LNEs
resources from the network-device with each LNE. LNEs themselves are and associate resources from the network-device with each LNE. LNEs
represented in YANG as independent network devices; each accessed themselves are represented in YANG as independent network devices;
independently. Optionally, and when supported by the implementation, each accessed independently. Optionally, and when supported by the
they may also be accessed from the host system. Examples of vendor implementation, they may also be accessed from the host system.
terminology for an LNE include logical system or logical router, and Examples of vendor terminology for an LNE include logical system or
virtual switch, chassis, or fabric. logical router, and virtual switch, chassis, or fabric.
The second form, which is defined in this document, provides support The second form, which is defined in this document, provides support
what is commonly referred to as Virtual Routing and Forwarding (VRF) what is commonly referred to as Virtual Routing and Forwarding (VRF)
instances as well as Virtual Switch Instances (VSI), see [RFC4026]. instances as well as Virtual Switch Instances (VSI), see [RFC4026].
In this form of resource partitioning multiple control plane and In this form of resource partitioning multiple control plane and
forwarding/bridging instances are provided by and managed via a forwarding/bridging instances are provided by and managed via a
single (physical or logical) network device. This form of resource single (physical or logical) network device. This form of resource
partitioning is referred to as Network Instances and are supported by partitioning is referred to as Network Instances and are supported by
the network-instance module defined below. Configuration and the network-instance module defined below. Configuration and
operation of each network-instance is always via the network device operation of each network-instance is always via the network device
and the network-instance module. and the network-instance module.
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.
2. Overview 2. Overview
skipping to change at page 4, line 23 skipping to change at page 4, line 23
| :+-----+-----+-----+: :+-----+-----+-----+: | | :+-----+-----+-----+: :+-----+-----+-----+: |
| : | | | | | | : : | | | | | | : | | : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | | | | | | | | | | | | | |
Interfaces Interfaces Interfaces Interfaces
Figure 1: Module Element Relationships Figure 1: Module Element Relationships
A model for LNEs is described in [LNE-MODEL] and the model for A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the
network instances is covered in Section 3. For more information on model for network instances is covered in Section 3. For more
how these models may be used within an overall device model information on how these models may be used within an overall device
structure, see [RTG-DEVICE-MODEL]. model structure, see [I-D.ietf-rtgwg-device-model].
The interface management model [RFC7223] is an existing model that is The interface management model [RFC7223] is an existing model that is
impacted by the definition of LNEs and network instances. This impacted by the definition of LNEs and network instances. This
document and [LNE-MODEL] define augmentations to the interface module document and [I-D.ietf-rtgwg-lne-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 25 skipping to change at page 6, line 25
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 type? identityref +--rw type? identityref
+--rw enabled? boolean +--rw enabled? boolean
+--rw description? string +--rw description? string
+--rw network-instance-policy +--rw network-instance-policy
| ... | ...
+--rw root? schema-mount +--rw root? yang-schema-mount
| ... | ...
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw bind-network-instance-name? string +--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv4: augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-network-instance-name? string +--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv6: augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-network-instance-name? string +--rw bind-network-instance-name? string
A network instance is identified by a `name` string. This string is A network instance is identified by a `name` string. This string is
used both as an index within the network-instance module and to used both as an index within the network-instance module and to
skipping to change at page 7, line 16 skipping to change at page 7, line 16
+--rw network-instances +--rw network-instances
+--rw network-instance* [name] +--rw network-instance* [name]
+--rw network-instance-policy +--rw network-instance-policy
(TBD) (TBD)
3.2. Network Instance Management 3.2. Network Instance Management
Modules that may be used to represent network instance specific Modules that may be used to represent network instance specific
information will be available under `root`. As with LNEs, actual information will be available under `root`. As with LNEs, actual
module availability is expected to be implementation dependent. The module availability is expected to be implementation dependent. The
yang library module [I-D.ietf-netconf-yang-library] is expected to be yang library module [RFC7895] is expected to be the primary method
the primary method used to identify supported modules. Resource used to identify supported modules. Resource related control and
related control and assignment is expected to be managed at the assignment is expected to be managed at the network-device level, not
network-device level, not the network instance level, based on the the network instance level, based on the `bind-network-instance-name`
`bind-network-instance-name` augmentation mentioned above. augmentation mentioned above.
As an example, consider the case where a network instance with a As an example, consider the case where a network instance with a
`name` of "green" is defined on a network device. In this case the `name` of "green" is defined on a network device. In this case the
following structure might be made available: following structure might be made available:
+--rw yanglib:modules-state [I-D.ietf-netconf-yang-library] +--rw yanglib:modules-state [RFC7895]
+--rw if:interfaces [RFC7223] +--rw if:interfaces [RFC7223]
| +--rw bind-network-instance-name="green" string | +--rw bind-network-instance-name="green" string
+--rw network-instances +--rw network-instances
+--rw network-instance* [name] +--rw network-instance* [name]
+--rw name="green" string +--rw name="green" string
+--rw type? identityref +--rw type? identityref
+--rw enabled=true boolean +--rw enabled=true boolean
+--rw description="The Green VRF" string +--rw description="The Green VRF" string
+--rw network-instance-policy +--rw network-instance-policy
| ... (RT=1000:1, RD=1.2.3.4) | ... (RT=1000:1, RD=1.2.3.4)
+--rw root? schema-mount +--rw root? yang-schema-mount
+--rw yanglib:modules-state [I-D.ietf-netconf-yang-library] +--rw yanglib:modules-state [RFC7895]
+--rw if:intefaces [RFC7223] +--rw if:intefaces [RFC7223]
+--rw mm:network-services +--rw mm:network-services
+--rw nn:oam-protocols +--rw nn:oam-protocols
+--rw oo:routing +--rw oo:routing
+--rw pp:mpls +--rw pp:mpls
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`, and be accessible via paths modified may be present at the `root`, and be accessible via paths modified
per [I-D.ietf-netmod-schema-mount]. The list of available modules is per [I-D.ietf-netmod-schema-mount]. The list of available modules is
expected to be implementation dependent. As is the method used by an expected to be implementation dependent. As is the method used by an
implementation to support NIs. implementation to support NIs.
3.3. Network Instance Instantiation 3.3. Network Instance Instantiation
TBD -- need to resolve if instantiation is based on new list entry Network instances may be controlled by clients using existing list
creation per the pending Schema Mount solution definition. operations. When list entries are created, a new instance is
instantiated. The models mounted under a NI root is expected to be
dependent on the server implementation. When a list entry is
deleted, an existing network instance 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-network-instance
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-network-instance
namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance
prefix: ni
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@2016-06-23.yang" <CODE BEGINS> file "ietf-network-instance@2016-10-27.yang"
module ietf-network-instance { module ietf-network-instance {
yang-version "1"; yang-version 1.1;
// namespace // namespace
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;
} }
import ietf-ip { import ietf-ip {
prefix ip; prefix ip;
} }
// meta import ietf-yang-schema-mount {
prefix yangmnt;
}
// 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 network instances "This module is used to support multiple network instances
within a single physical or virtual device. Network within a single physical or virtual device. Network
instances are commonly know as VRFs (virtual routing instances are commonly know as VRFs (virtual routing
and forwarding) and VSIs (virtual switching instances)."; and forwarding) and VSIs (virtual switching instances).";
revision "2016-06-23" { revision "2016-10-27" {
description description
"Initial revision."; "Initial revision.";
reference "RFC TBD"; reference "RFC TBD";
} }
// extension statements // extension statements
feature bind-network-instance-name { feature bind-network-instance-name {
description description
"Network Instance to which an interface instance is bound"; "Network Instance to which an interface instance is bound";
skipping to change at page 11, line 4 skipping to change at page 11, line 23
on an interface"; on an interface";
leaf type { leaf type {
type identityref { type identityref {
base ipv6-interface-protocol-type; base ipv6-interface-protocol-type;
} }
mandatory true; mandatory true;
description description
"ND, ICMPv6, VRRP, DHCPv6 Client, etc."; "ND, ICMPv6, VRRP, DHCPv6 Client, etc.";
} }
} }
} }
} }
grouping network-instance-policy { grouping network-instance-policy {
description description
"Network instance policies such as route "Network instance policies such as route
distinguisher, route targets, VPLS ID and neighbor, distinguisher, route targets, VPLS ID and neighbor,
Ethernet ID, etc. "; Ethernet ID, etc. ";
reference reference
"RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs) "RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs)
RFC 6074 - Provisioning, Auto-Discovery, and Signaling RFC 6074 - Provisioning, Auto-Discovery, and Signaling
in Layer 2 Virtual Private Networks (L2VPNs) in Layer 2 Virtual Private Networks (L2VPNs)
RFC 7432 - BGP MPLS-Based Ethernet VPN"; RFC 7432 - BGP MPLS-Based Ethernet VPN";
container network-instance-policy { container network-instance-policy {
description "Network Instance Policy -- details TBD"; description
"Network Instance Policy -- details TBD,
perhaps based on BESS model";
} }
} }
// top level device definition statements // top level device definition statements
container network-instances { container network-instances {
description "Network instances each of which have description "Network instances each of which have
an independent IP/IPv6 addressing space an independent IP/IPv6 addressing space
and protocol instantiations. For layer 3, and protocol instantiations. For layer 3,
this consistent with the routing-instance this consistent with the routing-instance
definition in ietf-routing"; definition in ietf-routing";
skipping to change at page 12, line 13 skipping to change at page 12, line 34
description description
"Flag indicating whether or not the network "Flag indicating whether or not the network
instance is enabled."; instance is enabled.";
} }
leaf description { leaf description {
type string; type string;
description description
"Description of the network instance "Description of the network instance
and its intended purpose"; and its intended purpose";
} }
uses network-instance-policy; uses network-instance-policy;
leaf root {
type schema-mount; anydata root {
description "Root for models supported per yangmnt:mount-point root;
network instance"; description "Root for models supported per
network instance";
} }
} }
} }
// 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
instance (which is within the interface's identified logical instance (which is within the interface's identified logical
skipping to change at page 13, line 32 skipping to change at page 14, line 11
} }
<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.
[LNE-MODEL] [I-D.ietf-rtgwg-lne-model]
Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
"Logical Network Element Model", draft-ietf-rtgwg-lne- "Logical Network Element Model", draft-ietf-rtgwg-lne-
model-00.txt (work in progress), June 2016. model-00 (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>.
[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] [I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-21 (work in Management", draft-ietf-netmod-routing-cfg-24 (work in
progress), March 2016. 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.
[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>. <http://www.rfc-editor.org/info/rfc4026>.
[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
 End of changes. 32 change blocks. 
99 lines changed or deleted 119 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/