draft-ietf-rtgwg-ni-model-02.txt   draft-ietf-rtgwg-ni-model-03.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: September 14, 2017 Deutsche Telekom Expires: January 4, 2018 Deutsche Telekom
A. Lindem A. Lindem
Cisco Systems Cisco Systems
D. Bogdanovic D. Bogdanovic
March 13, 2017
X. Liu
Jabil
July 3, 2017
YANG Network Instances YANG Network Instances
draft-ietf-rtgwg-ni-model-02 draft-ietf-rtgwg-ni-model-03
Abstract Abstract
This document defines a network instance module. This module along This document defines a network instance module. This module can be
with the logical network element module can be used to manage the used to manage the virtual resource partitioning that may be present
logical and virtual resource representations that may be present on a on a network device. Examples of common industry terms for virtual
network device. Examples of common industry terms for logical resource partitioning are Virtual Routing and Forwarding (VRF)
resource representations are Logical Systems or Logical Routers. instances and Virtual Switch Instances (VSIs).
Examples of common industry terms for virtual resource
representations are Virtual Routing and Forwarding (VRF) instances
and Virtual Switch Instances (VSIs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at 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 September 14, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Status of Work and Open Issues . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Status of Work and Open Issues . . . . . . . . . . . . . 3
3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Network Instance Policy . . . . . . . . . . . . . . . . . 6 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Network Instance Management . . . . . . . . . . . . . . . 7 3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6
3.3. Network Instance Instantiation . . . . . . . . . . . . . 8 3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 9 3.3. Network Instance Management . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Network Instance Instantiation . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22
Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 22
B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 22
B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 the YANG management and networking perspectives. Both leverage the YANG
functionality enabled by YANG Schema Mount functionality enabled by YANG Schema Mount
[I-D.ietf-netmod-schema-mount]. [I-D.ietf-netmod-schema-mount].
Two forms of resource partitioning are supported: The first form of resource partitioning provides a logical
partitioning of a network device where each partition is separately
managed as essentially an independent network element which is
'hosted' by the base network device. These hosted network elements
are referred to as logical network elements, or LNEs, and are
supported by the logical-network-element module defined in
The first form, which is defined in [I-D.ietf-rtgwg-lne-model], [I-D.ietf-rtgwg-lne-model]. That module is used to identify LNEs and
provides a logical partitioning of a network device where each associate resources from the network-device with each LNE. LNEs
partition is separately managed as essentially an independent network
element which is 'hosted' by the base network device. These hosted
network elements are referred to as logical network elements, or
LNEs, and are supported by the logical-network-element module defined
in [I-D.ietf-rtgwg-lne-model]. The module is used to identify LNEs
and associate resources from the network-device with each LNE. LNEs
themselves are represented in YANG as independent network devices; themselves are represented in YANG as independent network devices;
each accessed independently. Optionally, and when supported by the each accessed independently. Examples of vendor terminology for an
implementation, they may also be accessed from the host system. LNE include logical system or logical router, and virtual switch,
Examples of vendor terminology for an LNE include logical system or 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) for what is commonly referred to as Virtual Routing and Forwarding
instances as well as Virtual Switch Instances (VSI), see [RFC4026]. (VRF) instances as well as Virtual Switch Instances (VSI), see
In this form of resource partitioning multiple control plane and [RFC4026] and [RFC4664]. In this form of resource partitioning,
forwarding/bridging instances are provided by and managed via a multiple control plane and forwarding/bridging instances are provided
single (physical or logical) network device. This form of resource by and managed via a single (physical or logical) network device.
partitioning is referred to as Network Instances and are supported by This form of resource partitioning is referred to as a Network
the network-instance module defined below. Configuration and Instance and is supported by the network-instance module defined
operation of each network-instance is always via the network device below. Configuration and operation of each network-instance is
and the network-instance module. always via the network device and the network-instance module.
This document was motivated by, and derived from, One notable difference between the LNE model and the NI model is that
[I-D.ietf-rtgwg-device-model]. the NI model provides a framework for VRF and VSI management. This
document envisions the separate definition of VRF and VSI, i.e., L3
and L2 VPN, technology specific models. An example of such can be
found in the emerging L3VPN model defined in
[I-D.ietf-bess-l3vpn-yang] and the examples discussed below.
1.1. Status of Work and Open Issues 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Readers are expected to be familiar with terms and concepts of YANG
[RFC7950] and YANG Schema Mount [I-D.ietf-netmod-schema-mount].
This document uses the graphical representation of data models
defined in [I-D.ietf-netmod-yang-tree-diagrams].
1.2. 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. Schema mount currently doesn't allow parent-reference filtering
standardization of [I-D.openconfig-netmod-opstate] or on the instance of the mount point, but rather just the schema.
[I-D.ietf-netmod-opstate-reqs] by the Netmod WG. This means it is not possible to filter based on actual data,
e.g., bind-network-instance-name="green". In the schema mount
definition, the text and examples should be updated to cover this
case.
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
device. Examples of vendor terminology for an LNE include logical device. Examples of vendor terminology for an LNE include logical
system or logical router, and virtual switch, chassis, or fabric. system or logical router, and virtual switch, chassis, or fabric.
Each LNE may also support virtual routing and forwarding (VRF) and Each LNE may also support virtual routing and forwarding (VRF) and
virtual switching instance (VSI) functions, which are referred to virtual switching instance (VSI) functions, which are referred to
below as a network instances (NIs). This breakdown is represented in below as a network instances (NIs). This breakdown is represented in
Figure 1. Figure 1.
skipping to change at page 4, line 24 skipping to change at page 4, line 40
| : | | | | | | : : | | | | | | : | | : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | | | | | | | | | | | | | |
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 network instances is covered in Section 3. For more model for NIs is covered in this document in Section 3.
information on how these models may be used within an overall device
model structure, see [I-D.ietf-rtgwg-device-model].
The interface management model [RFC7223] is an existing model that is The current interface management model [RFC7223] is impacted by the
impacted by the definition of LNEs and network instances. This definition of LNEs and NIs. This document and
document and [I-D.ietf-rtgwg-lne-model] define augmentations to the [I-D.ietf-rtgwg-lne-model] define augmentations to the interface
interface module to support LNEs and NIs. Similar elements, although module to support LNEs and NIs.
perhaps only for LNEs, may also need to be included as part of the
definition of the future hardware and QoS modules. The network instance model supports the configuration of VRFs and
VSIs. Each instance is supported by information that relates to the
device, for example the route target used when advertising VRF routes
via the mechanisms defined in [RFC4364], and information that relates
to the internal operation of the NI, for example for routing
protocols [RFC8022] and OSPF [I-D.ietf-ospf-yang]. This document
defines the network-instance module that provides a basis for the
management of both types of information.
NI information that relates to the device, including the assignment
of interfaces to NIs, is defined as part of this document. The
defined module also provides a placeholder for the definition of NI-
technology specific information both at the device level and for NI
internal operation. Information related to NI internal operation is
supported via schema mount [I-D.ietf-netmod-schema-mount] and
mounting appropriate modules under the mount point. Well known mount
points are defined for L3VPN, L2VPN, and L2+L3VPN NI types.
3. Network Instances
The network instance container is used to represent virtual routing
and forwarding instances (VRFs) and virtual switching instances
(VSIs). VRFs and VSIs are commonly used to isolate routing and
switching domains, for example to create virtual private networks,
each with their own active protocols and routing/switching policies.
The model supports both core/provider and virtual instances. Core/
provider instance information is accessible at the top level of the
server, while virtual instance information is accessible under the
root schema mount points.
The NI model can be represented using the tree format defined in
[I-D.ietf-netmod-yang-tree-diagrams] as:
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
+--rw (root-type)?
+--:(vrf-root)
| +--mp vrf-root?
+--:(vsi-root)
| +--mp vsi-root?
+--:(vv-root)
+--mp vv-root?
augment /if:interfaces/if:interface:
+--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-ni-name? -> /network-instances/network-instance/name
augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-ni-name? -> /network-instances/network-instance/name
notifications:
+---n bind-ni-name-failed
+--ro name -> /if:interfaces/interface/name
+--ro interface
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ni:bind-ni-name
+--ro ipv4
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv4/ni:bind-ni-name
+--ro ipv6
| +--ro bind-ni-name?
| -> /if:interfaces/interface/ip:ipv6/ni:bind-ni-name
+--ro error-info? string
A network instance is identified by a 'name' string. This string is
used both as an index within the network-instance module and to
associate resources with a network instance as shown above in the
interface augmentation. The ni-type and root-type choice statements
are used to support different types of L2 and L3 VPN technologies.
The bind-ni-name-failed notification is used in certain failure
cases.
3.1. NI Types and Mount Points
The network-instance module is structured to facilitate the
definition of information models for specific types of VRFs and VSIs
using augmentations. For example, the information needed to support
VPLS, VxLAN and EVPN based L2VPNs are likely to be quite different.
Example models under development that could be restructured to take
advantage on NIs include, for L3VPNs [I-D.ietf-bess-l3vpn-yang] and
for L2VPNs [I-D.ietf-bess-l2vpn-yang].
Documents defining new YANG models for the support of specific types
of network instances should augment the network instance module. The
basic structure that should be used for such augmentations include a
case statement, with containers for configuration and state data and
finally, when needed, a type specific mount point. Generally ni
types, are expected to not need to define type specific mount points,
but rather reuse one of the well known mount point, as defined in the
next section. The following is an example type specific
augmentation:
augment "/ni:network-instances/ni:network-instance/ni:ni-type" {
case l3vpn {
container l3vpn {
...
}
container l3vpn-state {
...
}
}
}
3.1.1. Well Known Mount Points
YANG Schema Mount, [I-D.ietf-netmod-schema-mount], identifies mount
points by name within a module. This definition allows for the
definition of mount points whose schema can be shared across ni-
types. As discussed above, ni-types largely differ in the
configuration information needed in the core/top level instance to
support the NI, rather than in the information represented within an
NI. This allows the use of shared mount points across certain NI
types.
The expectation is that there are actually very few different schema
that need to be defined to support NIs on an implementation. In
particular, it is expected that the following three forms of NI
schema are needed, and each can be defined with a well known mount
point that can be reused by future modules defining ni-types.
The three well known mount points are:
vrf-root
vrf-root is intended for use with L3VPN type ni-types.
vsi-root
vsi-root is intended for use with L2VPN type ni-types.
vv-root
vv-root is intended for use with ni-types that simultaneously
support L2VPN bridging and L3VPN routing capabilities.
Future model definitions should use the above mount points whenever
possible. When a well known mount point isn't appropriate, a model
may define a type specific mount point via augmentation.
3.1.2. NI Type Example
The following is an example of an L3VPN VRF using a hypothetical
augmentation to the networking instance schema defined in
[I-D.ietf-bess-l3vpn-yang]. More detailed examples can be found in
Appendix B.
module: ietf-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw enabled? boolean
+--rw description? string
+--rw (ni-type)?
| +--:(l3vpn)
| +--rw l3vpn:l3vpn
| | ... // config data
| +--ro l3vpn:l3vpn-state
| | ... // state data
+--rw (root-type)?
+--:(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 router-id? yang:dotted-quad
| +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name]
| +--rw ospf:ospf/
| +--rw instance* [af]
| +--rw areas
| +--rw area* [area-id]
| +--rw interfaces
| +--rw interface* [name]
| +--rw name if:interface-ref
| +--rw cost? uint16
+--ro if:interfaces@
| ...
+--ro if:interfaces-state@
| ...
This shows YANG Routing Management [RFC8022] and YANG OSPF
[I-D.ietf-ospf-yang] as mounted modules. The mounted modules can
reference interface information via a parent-reference to the
containers defined in [RFC7223].
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]. [RFC7223].
The logical-network-element and network-instance modules augment the As shown below, the network-instance module augments the existing
existing interface management model in two ways: The first, by the interface management model by adding a name which is used on
logical-network-element module, adds an identifier which is used on
physical interface types to identify an associated LNE. The second,
by the network-instance module, adds 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 [RFC7277].
The interface related augmentations are as follows: The following is an example of envisioned usage. The interfaces
container includes a number of commonly used components as examples:
module: ietf-logical-network-element
augment /if:interfaces/if:interface:
+--rw bind-lne-name? string
module: ietf-network-instance
augment /if:interfaces/if:interface:
+--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-network-instance-name? string
The following is an example of envisioned combined usage. The
interfaces container includes a number of commonly used components as
examples:
+--rw if:interfaces module: ietf-interfaces
| +--rw interface* [name] +--rw interfaces
| +--rw name string | +--rw interface* [name]
| +--rw bind-lne-name? string | +--rw name string
| +--rw ethernet | +--rw ip:ipv4!
| | +--rw ni:bind-network-instance-name? string | | +--rw ip:enabled? boolean
| | +--rw aggregates | | +--rw ip:forwarding? boolean
| | +--rw rstp | | +--rw ip:mtu? uint16
| | +--rw lldp | | +--rw ip:address* [ip]
| | +--rw ptp | | | +--rw ip:ip inet:ipv4-address-no-zone
| +--rw vlans | | | +--rw (ip:subnet)
| +--rw tunnels | | | +--:(ip:prefix-length)
| +--rw ipv4 | | | | +--rw ip:prefix-length? uint8
| | +--rw ni:bind-network-instance-name? string | | | +--:(ip:netmask)
| | +--rw arp | | | +--rw ip:netmask? yang:dotted-quad
| | +--rw icmp | | +--rw ip:neighbor* [ip]
| | +--rw vrrp | | | +--rw ip:ip inet:ipv4-address-no-zone
| | +--rw dhcp-client | | | +--rw ip:link-layer-address yang:phys-address
| +--rw ipv6 | | +--rw ni:bind-network-instance-name? string
| +--rw ni:bind-network-instance-name? string | +--rw ni:bind-network-instance-name? string
| +--rw vrrp
| +--rw icmpv6
| +--rw nd
| +--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 virtual instances (e.g.,
instances (e.g., VRFs) supported on the device. The bind-lne-name VRFs) supported on the device. The bind-network-instance-name leaf
and bind-network-instance-name leaves provide the association between provides the association between an interface and its associated NI
an interface and its associated LNE and NI (e.g., VRF or VSI). (e.g., VRF or VSI). Note that as currently defined, to assign an
interface to both an LNE and NI, the interface would first be
3. Network Instances assigned to the LNE using the mechanisms defined in
[I-D.ietf-rtgwg-lne-model] and then within that LNE's interface
The network instance container is used to represent virtual routing module, the LNE's representation of that interface would be assigned
and forwarding instances (VRFs) and virtual switching instances to an NI.
(VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate
routing and switching domains, for example to create virtual private
networks, each with their own active protocols and routing/switching
policies. The model represents both core/provider and virtual
instances. Network instances reuse and build on [RFC8022] and are
shown below:
module: ietf-network-instance 3.3. Network Instance Management
+--rw network-instances
+--rw network-instance* [name]
+--rw name string
+--rw type? identityref
+--rw enabled? boolean
+--rw description? string
+--rw network-instance-policy
| ...
+--rw root? yang-schema-mount
| ...
augment /if:interfaces/if:interface:
+--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv4:
+--rw bind-network-instance-name? string
augment /if:interfaces/if:interface/ip:ipv6:
+--rw bind-network-instance-name? string
A network instance is identified by a `name` string. This string is Modules that may be used to represent network instance information
used both as an index within the network-instance module and to will be available under the ni-type specific 'root' mount point. The
associate resources with a network instance as shown above in the use-schema mechanism defined as part of the Schema Mount module
interface augmentation. Type is used to indicate the type NI, such [I-D.ietf-netmod-schema-mount] MUST be used with the module defined
as L3-VRF, VPLS, L2-VSI, etc. Network instance policy and root are in this document to identify accessible modules. A future version of
discussed in greater detail below. this document could relax this requirement. Mounted modules in the
non-inline case SHOULD be defined with access, via the appropriate
schema mount parent-references [I-D.ietf-netmod-schema-mount], to
device resources such as interfaces.
3.1. Network Instance Policy All modules that represent control-plane and data-plane information
may be present at the 'root' mount point, and be accessible via paths
modified per [I-D.ietf-netmod-schema-mount]. The list of available
modules is expected to be implementation dependent, as is the method
used by an implementation to support NIs.
Network instance policies are used to control how NI information is For example, the following could be used to define the data
represented at the device level, VRF routing policies, and VRF/VSI organization of the example NI shown in Section 3.1.2:
identifiers. Examples include BGP route targets (RTs) and route
distinguishers (RDs), virtual network identifiers (VN-IDs), VPLS
neighbors, etc. The structure is expected to be:
module: ietf-network-instance "ietf-yang-schema-mount:schema-mounts": {
+--rw network-instances "mount-point": [
+--rw network-instance* [name] {
+--rw network-instance-policy "module": "ietf-network-instance",
(TBD) "name": "vrf-root",
"use-schema": [
{
"name": "ni-schema",
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
]
}
],
"schema": [
{
"name": "ni-schema",
"module": [
{
"name": "ietf-routing",
"revision": "2016-11-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2017-03-12",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
}
]
}
]
}
3.2. Network Instance Management Module data identified under "schema" will be instantiated under the
mount point identified under "mount-point". These modules will be
able to reference information for nodes belonging to top-level
modules that are identified under "parent-reference". Parent
referenced information is available to clients via their top level
paths only, and not under the associated mount point.
Modules that may be used to represent network instance specific 3.4. Network Instance Instantiation
information will be available under `root`. As with LNEs, actual
module availability is expected to be implementation dependent. The
use-schema mechanism defined as part of the Schema Mount module
[I-D.ietf-netmod-schema-mount] is expected to be the primary method
used to identify supported modules. Resource related control and
assignment is expected to be managed at the network-device level, not
the network instance level, based on the `bind-network-instance-name`
augmentation mentioned above. Mounted modules will access such
information, as well as any other information contained within a
module at the device root, by using the parent-reference mechanism
defined in [I-D.ietf-netmod-schema-mount].
As an example, consider the case where a network instance with a Network instances may be controlled by clients using existing list
`name` of "green" is defined on a network device. In this case the operations. When a list entry is created, a new instance is
following logical structure might be made available: instantiated. The models mounted under an NI root are 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.
+--rw yanglib:modules-state [RFC7895] Once instantiated, host network device resources can be associated
+--rw if:interfaces [RFC7223] with the new NI. As previously mentioned, this document augments
| +--rw bind-network-instance-name="green" string ietf-interfaces with the bind-ni-name leaf to support such
+--rw network-instances associations for interfaces. When a bind-ni-name is set to a valid
+--rw network-instance* [name] NI name, an implementation MUST take whatever steps are internally
+--rw name="green" string necessary to assign the interface to the NI or provide an error
+--rw type? identityref message (defined below) with an indication of why the assignment
+--rw enabled=true boolean failed. It is possible for the assignment to fail while processing
+--rw description="The Green VRF" string the set operation, or after asynchronous processing. Error
+--rw network-instance-policy notification in the latter case is supported via a notification.
| ... (RT=1000:1, RD=1.2.3.4)
+--rw root? yang-schema-mount
with a corresponding logical structure in the schema-mount module: 4. Security Considerations
module: ietf-yang-schema-mount There are two different sets of security considerations to consider
+--ro schema-mounts in the context of this document. One set is security related to
: information contained within mounted modules. The security
+--ro mount-point* [module name] considerations for mounted modules are not substantively changed
| +--ro module="ietf-network-instance" based on the information being accessible within the context of an
| +--ro name="root" NI. For example, when considering the modules defined in [RFC8022],
| +--ro config=true the security considerations identified in that document are equally
| +--ro (schema-ref)? applicable, whether those modules are accessed at a server's root or
| +--:(use-schema) under an NI instance's root node.
| +--ro use-schema* [name]
| +--ro name="ni-vrf"
: :
:
+--ro schema* [name]
+--ro name="ni-vrf" string
+--ro module* [name revision]
| +--ro name="mm:network-services"
: :
| +--ro name="nn:oam-protocols"
: :
| +--ro name="oo:routing"
: :
| +--ro name="pp:mpls"
: :
+--ro mount-point* [network-instance]
:
All modules that represent control-plane and data-plane information The second area for consideration is information contained in the NI
may be present at the `root`, and be accessible via paths modified module itself. NI information represents network configuration and
per [I-D.ietf-netmod-schema-mount]. The list of available modules is route distribution policy information. As such, the security of this
expected to be implementation dependent. As is the method used by an information is important, but it is fundamentally no different than
implementation to support NIs. any other interface or routing configuration information that has
already been covered in [RFC7223] and [RFC8022].
3.3. Network Instance Instantiation The vulnerable "config true" parameters and subtrees are the
following:
Network instances may be controlled by clients using existing list /network-instances/network-instance: This list specifies the network
operations. When list entries are created, a new instance is instances and the related control plane protocols configured on a
instantiated. The models mounted under a NI root is expected to be device.
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 /if:interfaces/if:interface/*/bind-network-instance-name: This leaf
indicates the NI instance to which an interface is assigned.
TBD Unauthorized access to any of these lists can adversely affect the
routing subsystem of both the local device and the network. This may
lead to network malfunctions, delivery of packets to inappropriate
destinations and other problems.
5. IANA Considerations 5. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers a URI in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following registration is Following the format in RFC 3688, the following registration is
requested to be made. requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-network-instance URI: urn:ietf:params:xml:ns:yang:ietf-network-instance
Registrant Contact: The IESG. Registrant Contact: The IESG.
skipping to change at page 9, line 30 skipping to change at page 14, line 35
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-03-13.yang" <CODE BEGINS> file "ietf-network-instance@2017-07-03.yang"
module ietf-network-instance { module ietf-network-instance {
yang-version 1.1; yang-version 1.1;
// 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;
reference "RFC 7223: A YANG Data Model for Interface
Management";
} }
import ietf-ip { import ietf-ip {
prefix ip; prefix ip;
reference "RFC 7277: 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";
// RFC Ed.: Please replace this draft name with the
// corresponding RFC number
} }
// meta organization
organization "IETF Routing Area Working Group (rtgwg)"; "IETF Routing Area (rtgwg) Working Group";
contact contact
"Routing Area Working Group - <rtgwg@ietf.org>"; "WG Web: <http://tools.ietf.org/wg/rtgwg/>
WG List: <mailto:rtgwg@ietf.org>
Author: Lou Berger
<mailto:lberger@labn.net>
Author: Christan Hopps
<mailto:chopps@chopps.org>
Author: Acee Lindem
<mailto:acee@cisco.com>
Author: Dean Bogdanovic
<mailto:ivandean@gmail.com>";
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 known as VRFs (virtual routing
and forwarding) and VSIs (virtual switching instances)."; and forwarding) and VSIs (virtual switching instances).
revision "2017-03-13" {
description
"Initial revision.";
reference "RFC TBD";
}
// extension statements
feature bind-network-instance-name {
description
"Network Instance to which an interface instance is bound";
}
// identity statements
identity network-instance-type { Copyright (c) 2017 IETF Trust and the persons
description identified as authors of the code. All rights reserved.
"Base identity from which identities describing
network instance types are derived.";
}
identity ipv4-interface-protocol-type { Redistribution and use in source and binary forms, with or
description without modification, is permitted pursuant to, and subject
"Base identity for derivation of IPv4 interface to the license terms contained in, the Simplified BSD License
protocols"; set forth in Section 4.c of the IETF Trust's Legal Provisions
} Relating to IETF Documents
(http://trustee.ietf.org/license-info).
identity ipv6-interface-protocol-type { This version of this YANG module is part of RFC XXXX; see
description the RFC itself for full legal notices.";
"Base identity for derivation of IPv6 interface
protocols";
}
// typedef statements // RFC Ed.: replace XXXX with actual RFC number and remove
// this note
// RFC Ed.: please update TBD
// grouping statements revision 2017-07-02 {
grouping interface-ip-common {
description description
"interface-specific configuration for IP interfaces, IPv4 and "Initial revision.";
IPv6"; reference "RFC TBD";
}
grouping ipv4-interface-protocols {
container ipv4-interface-protocols {
list ipv4-interface-protocol {
key "type";
leaf type {
type identityref {
base ipv4-interface-protocol-type;
}
mandatory true;
description
"ARP, ICMP, VRRP, DHCP Client, etc.";
}
description
"List of IPv4 protocols configured
on an interface";
}
description
"Container for list of IPv4 protocols configured
on an interface";
}
description
"Grouping for IPv4 protocols configured on an interface";
} }
// top level device definition statements
grouping ipv6-interface-protocols { container network-instances {
description
"Network instances each of which consists of a
VRFs (virtual routing and forwarding) and/or
VSIs (virtual switching instances).";
reference "RFC 8022 - A YANG Data Model for Routing
Management";
list network-instance {
key "name";
description description
"Grouping for IPv6 protocols configured on "List of network-instances.";
an interface."; leaf name {
container ipv6-interface-protocols { type string;
description description
"Container for list of IPv6 protocols configured "device scoped identifier for the network
on an interface."; instance.";
list ipv6-interface-protocol {
key "type";
description
"List of IPv6 protocols configured
on an interface";
leaf type {
type identityref {
base ipv6-interface-protocol-type;
}
mandatory true;
description
"ND, ICMPv6, VRRP, DHCPv6 Client, etc.";
}
}
} }
} leaf enabled {
type boolean;
grouping network-instance-policy { default "true";
description
"Network instance policies such as route
distinguisher, route targets, VPLS ID and neighbor,
Ethernet ID, etc. ";
reference
"RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs)
RFC 6074 - Provisioning, Auto-Discovery, and Signaling
in Layer 2 Virtual Private Networks (L2VPNs)
RFC 7432 - BGP MPLS-Based Ethernet VPN";
container network-instance-policy {
description description
"Network Instance Policy -- details TBD, "Flag indicating whether or not the network
perhaps based on BESS model"; instance is enabled.";
}
}
// top level device definition statements
container network-instances {
description "Network instances each of which have
an independent IP/IPv6 addressing space
and protocol instantiations. For layer 3,
this consistent with the routing-instance
definition in ietf-routing";
reference
"RFC 8022 - A YANG Data Model for Routing Management";
list network-instance {
key name;
description "List of network-instances";
leaf name {
type string;
description "device scoped
identifier for the network
instance";
}
leaf type {
type identityref {
base network-instance-type;
}
description
"The network instance type -- details TBD
Likely types include core, L3-VRF, VPLS,
L2-cross-connect, L2-VSI, etc.";
}
leaf enabled {
type boolean;
default "true";
description
"Flag indicating whether or not the network
instance is enabled.";
}
leaf description {
type string;
description
"Description of the network instance
and its intended purpose";
}
uses network-instance-policy;
yangmnt:mount-point root {
description
"Root for models supported per
network instance. This will
typically not be an inline type
mount point.";
}
} }
leaf description {
type string;
description
"Description of the network instance
and its intended purpose.";
}
choice ni-type {
description
"This node serves as an anchor point for different types
of network instances. Each 'case' is expected to
differ in terms of the information needed in the
parent/core to support the NI, and may differ in their
mounted schema definition. When the mounted schema is
not expected to be the same for a specific type of NI
a mount point should be defined.";
}
choice root-type {
description
"Well known mount points.";
yangmnt:mount-point "vrf-root" {
description
"Root for L3VPN type models. This will typically
not be an inline type mount point.";
}
yangmnt:mount-point "vsi-root" {
description
"Root for L2VPN type models. This will typically
not be an inline type mount point.";
}
yangmnt:mount-point "vv-root" {
description
"Root models that support both L2VPN type bridging
and L3VPN type routing. This will typically
not be an inline type mount point.";
}
}
}
} }
// augment statements // augment statements
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
description description
"Add a node for the identification of the logical network "Add a node for the identification of the network
instance (which is within the interface's identified logical instance associated with the information configured
network element) associated with the IP information on a interface.
configured on an interface";
leaf bind-network-instance-name { Note that a standard error will be returned if the
type string; identified leafref isn't present. If an interfaces cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description description
"Network Instance to which an interface is bound"; "Network Instance to which an interface is bound.";
} }
} }
augment "/if:interfaces/if:interface/ip:ipv4" { augment "/if:interfaces/if:interface/ip:ipv4" {
description description
"Add a node for the identification of the logical "Add a node for the identification of the network
network instance (which is within the interface's instance associated with the information configured
identified physical or virtual device) associated with on an IPv4 interface.
the IP information configured on an interface";
leaf bind-network-instance-name { Note that a standard error will be returned if the
type string; identified leafref isn't present. If an interfaces cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description description
"Network Instance to which IPv4 interface is bound"; "Network Instance to which IPv4 interface is bound.";
} }
} }
augment "/if:interfaces/if:interface/ip:ipv6" { augment "/if:interfaces/if:interface/ip:ipv6" {
description description
"Add a node for the identification of the logical "Add a node for the identification of the network
network instance (which is within the interface's instance associated with the information configured
identified physical or virtual device) associated with on an IPv6 interface.
the IP information configured on an interface";
leaf bind-network-instance-name { Note that a standard error will be returned if the
type string; identified leafref isn't present. If an interfaces cannot
be assigned for any other reason, the operation SHALL fail
with an error-tag of 'operation-failed' and an
error-app-tag of 'ni-assignment-failed'. A meaningful
error-info that indicates the source of the assignment
failure SHOULD also be provided.";
leaf bind-ni-name {
type leafref {
path "/network-instances/network-instance/name";
}
description description
"Network Instance to which IPv6 interface is bound"; "Network Instance to which IPv6 interface is bound.";
} }
} }
// rpc statements
// notification statements // notification statements
notification bind-ni-name-failed {
description
"Indicates an error in the association of an interface to an
NI. Only generated after success is initially returned when
bind-ni-name is set.
Note: some errors may need to be reported for multiple
associations, e.g., a single error may need to be reported
for an IPv4 and an IPv6 bind-ni-name.
At least one container with a bind-ni-name leaf MUST be
included in this notification.";
leaf name {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
mandatory true;
description
"Contains the interface name associated with the
failure.";
}
container interface {
description
"Generic interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
container ipv4 {
description
"IPv4 interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface"
+ "/ip:ipv4/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
container ipv6 {
description
"IPv6 interface type.";
leaf bind-ni-name {
type leafref {
path "/if:interfaces/if:interface"
+ "/ip:ipv6/ni:bind-ni-name";
}
description
"Contains the bind-ni-name associated with the
failure.";
}
}
leaf error-info {
type string;
description
"Optionally, indicates the source of the assignment
failure.";
}
}
} }
<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-04 (work in progress), March ietf-netmod-schema-mount-05 (work in progress), May 2017.
[I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-01 (work in progress), June
2017. 2017.
[I-D.ietf-rtgwg-lne-model] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, Requirement Levels", BCP 14, RFC 2119,
"YANG Logical Network Elements", draft-ietf-rtgwg-lne- DOI 10.17487/RFC2119, March 1997,
model-01 (work in progress), October 2016. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <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-netmod-opstate-reqs] [I-D.ietf-bess-l2vpn-yang]
Watsen, K. and T. Nadeau, "Terminology and Requirements Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
for Enhanced Handling of Operational State", draft-ietf- and K. Tiruveedhula, "YANG Data Model for MPLS-based
netmod-opstate-reqs-04 (work in progress), January 2016. L2VPN", draft-ietf-bess-l2vpn-yang-05 (work in progress),
March 2017.
[I-D.ietf-bess-l3vpn-yang]
Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,
Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model
for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-01 (work
in progress), April 2017.
[I-D.ietf-ospf-yang]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"Yang Data Model for OSPF Protocol", draft-ietf-ospf-
yang-08 (work in progress), July 2017.
[I-D.ietf-rtgwg-device-model] [I-D.ietf-rtgwg-device-model]
Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
"Network Device YANG Organizational Models", draft-ietf- "Network Device YANG Logical Organization", draft-ietf-
rtgwg-device-model-01 (work in progress), October 2016. rtgwg-device-model-02 (work in progress), March 2017.
[I-D.openconfig-netmod-opstate] [I-D.ietf-rtgwg-lne-model]
Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
of Operational State Data in YANG", draft-openconfig- "YANG Logical Network Elements", draft-ietf-rtgwg-lne-
netmod-opstate-01 (work in progress), July 2015. model-02 (work in progress), March 2017.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005, DOI 10.17487/RFC4026, March 2005,
<http://www.rfc-editor.org/info/rfc4026>. <http://www.rfc-editor.org/info/rfc4026>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
<http://www.rfc-editor.org/info/rfc7895>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006,
<http://www.rfc-editor.org/info/rfc4664>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", RFC 8022, DOI 10.17487/RFC8022, November Management", RFC 8022, DOI 10.17487/RFC8022, November
2016, <http://www.rfc-editor.org/info/rfc8022>. 2016, <http://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. Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review
comments were also received by Martin Bjorklund and John Scudder.
This document was motivated by, and derived from,
[I-D.ietf-rtgwg-device-model].
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. Example NI usage
Contributors' Addresses The following subsections provide example uses of NIs.
TBD B.1. Configuration Data
The following shows an example where two customer specific network
instances are configured:
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-routing:routing": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"instance": [
{
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
]
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-routing:routing": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"instance": [
{
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
]
}
}
]
}
}
}
}
]
},
"ietf-interfaces:interfaces": {
"interfaces": {
"interface": [
{
"name": "eth0",
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24,
}
]
}
},
{
"name": "eth1",
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
},
"ni:bind-network-instance-name": "vrf-red"
},
{
"name": "eth2",
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
},
"ni:bind-network-instance-name": "vrf-blue"
}
]
}
},
"ietf-system:system": {
"authentication": {
"user": [
{
"name": "john",
"password": "$0$password"
}
]
}
}
}
B.2. State Data
The following shows state data for the example above.
{
"ietf-network-instance:network-instances": {
"network-instance": [
{
"name": "vrf-red",
"vrf-root": {
"ietf-routing:routing-state": {
"router-id": "192.0.2.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"instance": [
{
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth1",
"cost": 10
}
]
}
}
]
}
}
]
}
}
]
}
}
}
},
{
"name": "vrf-blue",
"vrf-root": {
"ietf-routing:routing-state": {
"router-id": "192.0.2.2",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-routing:ospf",
"name": "1",
"ietf-ospf:ospf": {
"instance": [
{
"af": "ipv4",
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
]
}
}
]
}
}
}
}
]
},
"ietf-interfaces:interfaces-state": {
"interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C0",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.10",
"prefix-length": 24,
}
]
}
},
{
"name": "eth1",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
}
},
{
"name": "eth2",
"type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2",
"statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00"
},
"ip:ipv4": {
"address": [
{
"ip": "192.0.2.11",
"prefix-length": 24,
}
]
}
}
]
}
},
"ietf-yang-library:modules-state": {
"module-set-id": "123e4567-e89b-12d3-a456-426655440000",
"module": [
{
"name": "iana-if-type",
"revision": "2014-05-08",
"namespace":
"urn:ietf:params:xml:ns:yang:iana-if-type",
"conformance-type": "import"
},
{
"name": "ietf-inet-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-inet-types",
"conformance-type": "import"
},
{
"name": "ietf-interfaces",
"revision": "2014-05-08",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2014-06-16",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-network-instance",
"revision": "2017-03-13",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2017-03-12",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2016-11-04",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-system",
"revision": "2014-08-06",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-system",
"conformance-type": "implement"
},
{
"name": "ietf-yang-library",
"revision": "2016-06-21",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-library",
"conformance-type": "implement"
},
{
"name": "ietf-yang-schema-mount",
"revision": "2017-05-16",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
"conformance-type": "implement"
},
{
"name": "ietf-yang-types",
"revision": "2013-07-15",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-yang-types",
"conformance-type": "import"
}
]
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
}
}
Authors' Addresses Authors' Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Christan Hopps Christan Hopps
Deutsche Telekom Deutsche Telekom
skipping to change at line 744 skipping to change at page 31, line 4
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA USA
Email: acee@cisco.com Email: acee@cisco.com
Dean Bogdanovic Dean Bogdanovic
Email: ivandean@gmail.com Email: ivandean@gmail.com
Xufeng Liu
Jabil
Email: Xufeng_Liu@jabil.com
 End of changes. 87 change blocks. 
441 lines changed or deleted 1051 lines changed or added

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