< draft-ietf-rtgwg-ni-model-09.txt   draft-ietf-rtgwg-ni-model-10.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: August 9, 2018 Deutsche Telekom Expires: August 17, 2018 Deutsche Telekom
A. Lindem A. Lindem
Cisco Systems Cisco Systems
D. Bogdanovic D. Bogdanovic
X. Liu X. Liu
Jabil Jabil
February 5, 2018 February 13, 2018
YANG Network Instances YANG Model for Network Instances
draft-ietf-rtgwg-ni-model-09 draft-ietf-rtgwg-ni-model-10
Abstract Abstract
This document defines a network instance module. This module can be This document defines a network instance module. This module can be
used to manage the virtual resource partitioning that may be present used to manage the virtual resource partitioning that may be present
on a network device. Examples of common industry terms for virtual on a network device. Examples of common industry terms for virtual
resource partitioning are Virtual Routing and Forwarding (VRF) resource partitioning are Virtual Routing and Forwarding (VRF)
instances and Virtual Switch Instances (VSIs). instances and Virtual Switch Instances (VSIs).
The YANG model in this document conforms to the Network Management
Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.
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 August 9, 2018. This Internet-Draft will expire on August 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 5
3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6 3.1. NI Types and Mount Points . . . . . . . . . . . . . . . . 6
3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7 3.1.1. Well Known Mount Points . . . . . . . . . . . . . . . 7
3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8 3.1.2. NI Type Example . . . . . . . . . . . . . . . . . . . 8
3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9 3.2. NIs and Interfaces . . . . . . . . . . . . . . . . . . . 9
3.3. Network Instance Management . . . . . . . . . . . . . . . 10 3.3. Network Instance Management . . . . . . . . . . . . . . . 10
3.4. Network Instance Instantiation . . . . . . . . . . . . . 12 3.4. Network Instance Instantiation . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 14 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 24
Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 23 Appendix B. Example NI usage . . . . . . . . . . . . . . . . . . 24
B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 23 B.1. Configuration Data . . . . . . . . . . . . . . . . . . . 24
B.2. State Data . . . . . . . . . . . . . . . . . . . . . . . 26 B.2. State Data - Non-NDMA Version . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 B.3. State Data - NDMA Version . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document defines the second of two new modules that are defined This document defines the second of two new modules that are defined
to support the configuration and operation of network-devices that to support the configuration and operation of network-devices that
allow for the partitioning of resources from both, or either, allow for the partitioning of resources from both, or either,
management and networking perspectives. Both leverage the YANG management and networking perspectives. Both leverage the YANG
functionality enabled by YANG Schema Mount functionality enabled by YANG Schema Mount
[I-D.ietf-netmod-schema-mount]. [I-D.ietf-netmod-schema-mount].
The YANG model in this document conforms to the Network Management
Datastore Architecture defined in the
[I-D.ietf-netmod-revised-datastores].
The first form of resource partitioning provides a logical The first form of resource partitioning provides a logical
partitioning of a network device where each partition is separately partitioning of a network device where each partition is separately
managed as essentially an independent network element which is managed as essentially an independent network element which is
'hosted' by the base network device. These hosted network elements 'hosted' by the base network device. These hosted network elements
are referred to as logical network elements, or LNEs, and are are referred to as logical network elements, or LNEs, and are
supported by the logical-network-element module defined in supported by the logical-network-element module defined in
[I-D.ietf-rtgwg-lne-model]. That module is used to identify LNEs and [I-D.ietf-rtgwg-lne-model]. That module is used to identify LNEs and
associate resources from the network-device with each LNE. LNEs 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. Examples of vendor terminology for an each accessed independently. Examples of vendor terminology for an
skipping to change at page 5, line 19 skipping to change at page 6, line 5
The network instance container is used to represent virtual routing The network instance container is used to represent virtual routing
and forwarding instances (VRFs) and virtual switching instances and forwarding instances (VRFs) and virtual switching instances
(VSIs). VRFs and VSIs are commonly used to isolate routing and (VSIs). VRFs and VSIs are commonly used to isolate routing and
switching domains, for example to create virtual private networks, switching domains, for example to create virtual private networks,
each with their own active protocols and routing/switching policies. each with their own active protocols and routing/switching policies.
The model supports both core/provider and virtual instances. Core/ The model supports both core/provider and virtual instances. Core/
provider instance information is accessible at the top level of the provider instance information is accessible at the top level of the
server, while virtual instance information is accessible under the server, while virtual instance information is accessible under the
root schema mount points. 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 module: ietf-network-instance
+--rw network-instances +--rw network-instances
+--rw network-instance* [name] +--rw network-instance* [name]
+--rw name string +--rw name string
+--rw enabled? boolean +--rw enabled? boolean
+--rw description? string +--rw description? string
+--rw (ni-type)? +--rw (ni-type)?
+--rw (root-type) +--rw (root-type)
+--:(vrf-root) +--:(vrf-root)
| +--mp vrf-root | +--mp vrf-root
skipping to change at page 12, line 22 skipping to change at page 12, line 22
{ {
"prefix": "ni", "prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance" "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
} }
], ],
"mount-point": [ "mount-point": [
{ {
"parent-reference": [ "parent-reference": [
"/if:interfaces/if:interface "/if:interfaces/if:interface
[ni:bind-network-instance-name = current()/../ni:name]", [ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]",
}
],
The same such "parent-reference" restrictions for non-NDMA
implementations can be represented based on the [RFC7223] and
[RFC7277] as:
"namespace": [
{
"prefix": "if",
"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
},
{
"prefix": "ni",
"uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
}
],
"mount-point": [
{
"parent-reference": [
"/if:interfaces/if:interface
[ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface "/if:interfaces-state/if:interface
[if:name = /if:interfaces/if:interface [if:name = /if:interfaces/if:interface
[ni:bind-ni-name = current()/../ni:name]/if:name]", [ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv4 "/if:interfaces/if:interface/ip:ipv4
[ni:bind-network-instance-name = current()/../ni:name]", [ni:bind-network-instance-name = current()/../ni:name]",
"/if:interfaces-state/if:interface/ip:ipv4 "/if:interfaces-state/if:interface/ip:ipv4
[if:name = /if:interfaces/if:interface/ip:ipv4 [if:name = /if:interfaces/if:interface/ip:ipv4
[ni:bind-ni-name = current()/../ni:name]/if:name]", [ni:bind-ni-name = current()/../ni:name]/if:name]",
"/if:interfaces/if:interface/ip:ipv6 "/if:interfaces/if:interface/ip:ipv6
[ni:bind-network-instance-name = current()/../ni:name]", [ni:bind-network-instance-name = current()/../ni:name]",
skipping to change at page 20, line 38 skipping to change at page 21, line 34
failure."; failure.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-10
(work in progress), January 2018.
[I-D.ietf-netmod-rfc7223bis] [I-D.ietf-netmod-rfc7223bis]
Bjorklund, M., "A YANG Data Model for Interface Bjorklund, M., "A YANG Data Model for Interface
Management", draft-ietf-netmod-rfc7223bis-03 (work in Management", draft-ietf-netmod-rfc7223bis-03 (work in
progress), January 2018. progress), January 2018.
[I-D.ietf-netmod-rfc7277bis] [I-D.ietf-netmod-rfc7277bis]
Bjorklund, M., "A YANG Data Model for IP Management", Bjorklund, M., "A YANG Data Model for IP Management",
draft-ietf-netmod-rfc7277bis-03 (work in progress), draft-ietf-netmod-rfc7277bis-03 (work in progress),
January 2018. January 2018.
skipping to change at page 23, line 5 skipping to change at page 24, line 10
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, 2 Virtual Private Networks (L2VPNs)", RFC 4664,
DOI 10.17487/RFC4664, September 2006, <https://www.rfc- DOI 10.17487/RFC4664, September 2006, <https://www.rfc-
editor.org/info/rfc4664>. editor.org/info/rfc4664>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<https://www.rfc-editor.org/info/rfc7277>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", RFC 8022, DOI 10.17487/RFC8022, November
2016, <https://www.rfc-editor.org/info/rfc8022>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The Routing Area Yang Architecture design team members included Acee The Routing Area Yang Architecture design team members included Acee
Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger,
Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. Useful review
comments were also received by Martin Bjorklund and John Scudder. comments were also received by Martin Bjorklund and John Scudder.
This document was motivated by, and derived from, This document was motivated by, and derived from,
[I-D.ietf-rtgwg-device-model]. [I-D.ietf-rtgwg-device-model].
Thanks for AD and IETF last call comments from Alia Atlas and Liang Thanks for AD and IETF last call comments from Alia Atlas, Liang Xia,
Xia. Benoit Claise, and Adam Roach.
The RFC text was produced using Marshall Rose's xml2rfc tool. The RFC text was produced using Marshall Rose's xml2rfc tool.
Appendix B. Example NI usage Appendix B. Example NI usage
The following subsections provide example uses of NIs. The following subsections provide example uses of NIs.
B.1. Configuration Data B.1. Configuration Data
The following shows an example where two customer specific network The following shows an example where two customer specific network
skipping to change at page 23, line 47 skipping to change at page 25, line 15
"name": "vrf-red", "name": "vrf-red",
"vrf-root": { "vrf-root": {
"ietf-routing:routing": { "ietf-routing:routing": {
"router-id": "192.0.2.1", "router-id": "192.0.2.1",
"control-plane-protocols": { "control-plane-protocols": {
"control-plane-protocol": [ "control-plane-protocol": [
{ {
"type": "ietf-routing:ospf", "type": "ietf-routing:ospf",
"name": "1", "name": "1",
"ietf-ospf:ospf": { "ietf-ospf:ospf": {
"instance": [ "af": "ipv4",
{ "areas": {
"af": "ipv4", "area": [
"areas": { {
"area": [ "area-id": "203.0.113.1",
{ "interfaces": {
"area-id": "203.0.113.1", "interface": [
"interfaces": { {
"interface": [ "name": "eth1",
{ "cost": 10
"name": "eth1",
"cost": 10
}
]
} }
} ]
] }
} }
} ]
] }
} }
} }
] ]
} }
} }
} }
}, },
{ {
"name": "vrf-blue", "name": "vrf-blue",
"vrf-root": { "vrf-root": {
"ietf-routing:routing": { "ietf-routing:routing": {
"router-id": "192.0.2.2", "router-id": "192.0.2.2",
"control-plane-protocols": { "control-plane-protocols": {
"control-plane-protocol": [ "control-plane-protocol": [
{ {
"type": "ietf-routing:ospf", "type": "ietf-routing:ospf",
"name": "1", "name": "1",
"ietf-ospf:ospf": { "ietf-ospf:ospf": {
"instance": [ "af": "ipv4",
{ "areas": {
"af": "ipv4", "area": [
"areas": { {
"area": [ "area-id": "203.0.113.1",
{ "interfaces": {
"area-id": "203.0.113.1", "interface": [
"interfaces": { {
"interface": [ "name": "eth2",
{ "cost": 10
"name": "eth2",
"cost": 10
}
]
} }
} ]
}
]
} }
} ]
] }
} }
} }
] ]
} }
} }
} }
} }
] ]
}, },
skipping to change at page 25, line 32 skipping to change at page 26, line 40
{ {
"name": "eth0", "name": "eth0",
"ip:ipv4": { "ip:ipv4": {
"address": [ "address": [
{ {
"ip": "192.0.2.10", "ip": "192.0.2.10",
"prefix-length": 24, "prefix-length": 24,
} }
] ]
} }
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64,
}
]
}
}, },
{ {
"name": "eth1", "name": "eth1",
"ip:ipv4": { "ip:ipv4": {
"address": [ "address": [
{ {
"ip": "192.0.2.11", "ip": "192.0.2.11",
"prefix-length": 24, "prefix-length": 24,
} }
] ]
}, },
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
},
"ni:bind-network-instance-name": "vrf-red" "ni:bind-network-instance-name": "vrf-red"
}, },
{ {
"name": "eth2", "name": "eth2",
"ip:ipv4": { "ip:ipv4": {
"address": [ "address": [
{ {
"ip": "192.0.2.11", "ip": "192.0.2.11",
"prefix-length": 24, "prefix-length": 24,
} }
]
},
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
] ]
}, },
"ni:bind-network-instance-name": "vrf-blue" "ni:bind-network-instance-name": "vrf-blue"
} }
] ]
} }
}, },
"ietf-system:system": { "ietf-system:system": {
"authentication": { "authentication": {
skipping to change at page 26, line 20 skipping to change at page 28, line 4
} }
}, },
"ietf-system:system": { "ietf-system:system": {
"authentication": { "authentication": {
"user": [ "user": [
{ {
"name": "john", "name": "john",
"password": "$0$password" "password": "$0$password"
} }
] ]
} }
} }
} }
B.2. State Data B.2. State Data - Non-NDMA Version
The following shows state data for the example above. The following shows state data for the configuration example above
based on [RFC7223], [RFC7277], and [RFC8022].
{ {
"ietf-network-instance:network-instances": { "ietf-network-instance:network-instances": {
"network-instance": [ "network-instance": [
{ {
"name": "vrf-red", "name": "vrf-red",
"vrf-root": { "vrf-root": {
"ietf-routing:routing-state": { "ietf-routing:routing-state": {
"router-id": "192.0.2.1", "router-id": "192.0.2.1",
"control-plane-protocols": { "control-plane-protocols": {
"control-plane-protocol": [ "control-plane-protocol": [
{ {
"type": "ietf-routing:ospf", "type": "ietf-routing:ospf",
"name": "1", "name": "1",
"ietf-ospf:ospf": { "ietf-ospf:ospf": {
"instance": [ "af": "ipv4",
{ "areas": {
"af": "ipv4", "area": [
"areas": { {
"area": [ "area-id": "203.0.113.1",
{ "interfaces": {
"area-id": "203.0.113.1", "interface": [
"interfaces": { {
"interface": [ "name": "eth1",
{ "cost": 10
"name": "eth1",
"cost": 10
}
]
} }
} ]
] }
} }
} ]
] }
} }
} }
] ]
} }
} }
} }
}, },
{ {
"name": "vrf-blue", "name": "vrf-blue",
"vrf-root": { "vrf-root": {
"ietf-routing:routing-state": { "ietf-routing:routing-state": {
"router-id": "192.0.2.2", "router-id": "192.0.2.2",
"control-plane-protocols": { "control-plane-protocols": {
"control-plane-protocol": [ "control-plane-protocol": [
{ {
"type": "ietf-routing:ospf", "type": "ietf-routing:ospf",
"name": "1", "name": "1",
"ietf-ospf:ospf": { "ietf-ospf:ospf": {
"instance": [ "af": "ipv4",
{ "areas": {
"af": "ipv4", "area": [
"areas": { {
"area": [ "area-id": "203.0.113.1",
{ "interfaces": {
"area-id": "203.0.113.1", "interface": [
"interfaces": { {
"interface": [ "name": "eth2",
{ "cost": 10
"name": "eth2",
"cost": 10
}
]
} }
} ]
] }
} }
} ]
] }
} }
} }
] ]
} }
} }
} }
} }
] ]
}, },
skipping to change at page 28, line 34 skipping to change at page 30, line 11
"discontinuity-time": "2017-06-26T12:34:56-05:00" "discontinuity-time": "2017-06-26T12:34:56-05:00"
}, },
"ip:ipv4": { "ip:ipv4": {
"address": [ "address": [
{ {
"ip": "192.0.2.10", "ip": "192.0.2.10",
"prefix-length": 24, "prefix-length": 24,
} }
] ]
} }
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64,
}
]
}
}, },
{ {
"name": "eth1", "name": "eth1",
"type": "iana-if-type:ethernetCsmacd", "type": "iana-if-type:ethernetCsmacd",
"oper-status": "up", "oper-status": "up",
"phys-address": "00:01:02:A1:B1:C1", "phys-address": "00:01:02:A1:B1:C1",
"statistics": { "statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00" "discontinuity-time": "2017-06-26T12:34:56-05:00"
}, },
"ip:ipv4": { "ip:ipv4": {
"address": [ "address": [
{ {
"ip": "192.0.2.11", "ip": "192.0.2.11",
"prefix-length": 24, "prefix-length": 24,
} }
] ]
} }
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
}
}, },
{ {
"name": "eth2", "name": "eth2",
"type": "iana-if-type:ethernetCsmacd", "type": "iana-if-type:ethernetCsmacd",
"oper-status": "up", "oper-status": "up",
"phys-address": "00:01:02:A1:B1:C2", "phys-address": "00:01:02:A1:B1:C2",
"statistics": { "statistics": {
"discontinuity-time": "2017-06-26T12:34:56-05:00" "discontinuity-time": "2017-06-26T12:34:56-05:00"
}, },
"ip:ipv4": { "ip:ipv4": {
"address": [ "address": [
{ {
"ip": "192.0.2.11", "ip": "192.0.2.11",
"prefix-length": 24, "prefix-length": 24,
} }
] ]
} }
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
}
} }
] ]
} }
}, },
"ietf-system:system-state": { "ietf-system:system-state": {
"platform": { "platform": {
"os-name": "NetworkOS" "os-name": "NetworkOS"
} }
} }
skipping to change at page 30, line 19 skipping to change at page 32, line 21
}, },
{ {
"name": "ietf-ip", "name": "ietf-ip",
"revision": "2014-06-16", "revision": "2014-06-16",
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-ip", "urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-network-instance", "name": "ietf-network-instance",
"revision": "2017-03-13", "revision": "2018-02-03",
"feature": [ "feature": [
"bind-network-instance-name" "bind-network-instance-name"
], ],
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance", "urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement" "conformance-type": "implement"
}, },
{ {
"name": "ietf-ospf", "name": "ietf-ospf",
"revision": "2017-03-12", "revision": "2017-03-12",
skipping to change at page 32, line 14 skipping to change at page 34, line 16
"namespace": "namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf", "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement" "conformance-type": "implement"
} }
] ]
} }
] ]
} }
} }
B.3. State Data - NDMA Version
The following shows state data for the configuration example above
based on [I-D.ietf-netmod-rfc7223bis], [I-D.ietf-netmod-rfc7277bis],
and [I-D.ietf-netmod-rfc8022bis].
{
"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": {
"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": {
"areas": {
"area": [
{
"area-id": "203.0.113.1",
"interfaces": {
"interface": [
{
"name": "eth2",
"cost": 10
}
]
}
}
]
}
}
}
]
}
}
}
}
]
},
"ietf-interfaces:interfaces": {
"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,
}
]
}
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::10",
"prefix-length": 64,
}
]
}
},
{
"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,
}
]
}
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
}
},
{
"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,
}
]
}
"ip:ipv6": {
"address": [
{
"ip": "2001:db8:0:2::11",
"prefix-length": 64,
}
]
}
}
]
}
},
"ietf-system:system-state": {
"platform": {
"os-name": "NetworkOS"
}
}
"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": "2018-01-09",
"feature": [
"arbitrary-names",
"pre-provisioning"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-interfaces",
"conformance-type": "implement"
},
{
"name": "ietf-ip",
"revision": "2018-01-09",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ip",
"conformance-type": "implement"
},
{
"name": "ietf-network-instance",
"revision": "2018-02-03",
"feature": [
"bind-network-instance-name"
],
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-network-instance",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2017-10-30",
"namespace": "urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
},
{
"name": "ietf-routing",
"revision": "2018-01-25",
"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-yang-schema-mount:schema-mounts": {
"mount-point": [
{
"module": "ietf-network-instance",
"label": "vrf-root",
"use-schema": [
{
"name": "ni-schema",
"parent-reference": [
"/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
]
}
]
}
],
"schema": [
{
"name": "ni-schema",
"module": [
{
"name": "ietf-routing",
"revision": "2018-01-25",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-routing",
"conformance-type": "implement"
},
{
"name": "ietf-ospf",
"revision": "2017-10-30",
"namespace":
"urn:ietf:params:xml:ns:yang:ietf-ospf",
"conformance-type": "implement"
}
]
}
]
}
}
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
 End of changes. 38 change blocks. 
101 lines changed or deleted 478 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/