< draft-ietf-rtgwg-ni-model-01.txt   draft-ietf-rtgwg-ni-model-02.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: May 1, 2017 Deutsche Telekom Expires: September 14, 2017 Deutsche Telekom
A. Lindem A. Lindem
Cisco Systems Cisco Systems
D. Bogdanovic D. Bogdanovic
October 28, 2016 March 13, 2017
YANG Network Instances YANG Network Instances
draft-ietf-rtgwg-ni-model-01 draft-ietf-rtgwg-ni-model-02
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 May 1, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . 9
6. Network Instance Model . . . . . . . . . . . . . . . . . . . 8 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 make use of 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].
skipping to change at page 6, line 13 skipping to change at page 6, line 13
an interface and its associated LNE and NI (e.g., VRF or VSI). an interface and its associated LNE and NI (e.g., VRF or VSI).
3. Network Instances 3. Network Instances
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), [RFC4026]. VRFs and VSIs are commonly used to isolate (VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate
routing and switching domains, for example to create virtual private routing and switching domains, for example to create virtual private
networks, each with their own active protocols and routing/switching networks, each with their own active protocols and routing/switching
policies. The model represents both core/provider and virtual policies. The model represents both core/provider and virtual
instances. Network instances reuse and build on instances. Network instances reuse and build on [RFC8022] and are
[I-D.ietf-netmod-routing-cfg] and are shown below: shown below:
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
| ... | ...
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 [RFC7895] is expected to be the primary method 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 used to identify supported modules. Resource related control and
assignment is expected to be managed at the network-device level, not assignment is expected to be managed at the network-device level, not
the network instance level, based on the `bind-network-instance-name` the network instance level, based on the `bind-network-instance-name`
augmentation mentioned above. 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 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 logical structure might be made available:
+--rw yanglib:modules-state [RFC7895] +--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? yang-schema-mount +--rw root? yang-schema-mount
+--rw yanglib:modules-state [RFC7895]
+--rw if:intefaces [RFC7223] with a corresponding logical structure in the schema-mount module:
+--rw mm:network-services
+--rw nn:oam-protocols module: ietf-yang-schema-mount
+--rw oo:routing +--ro schema-mounts
+--rw pp:mpls :
+--ro mount-point* [module name]
| +--ro module="ietf-network-instance"
| +--ro name="root"
| +--ro config=true
| +--ro (schema-ref)?
| +--:(use-schema)
| +--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 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
Network instances may be controlled by clients using existing list Network instances may be controlled by clients using existing list
skipping to change at page 8, line 43 skipping to change at page 9, line 30
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@2016-10-27.yang" <CODE BEGINS> file "ietf-network-instance@2017-03-13.yang"
module ietf-network-instance { module ietf-network-instance {
yang-version 1.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;
} }
import ietf-yang-schema-mount { import ietf-yang-schema-mount {
skipping to change at page 9, line 29 skipping to change at page 10, line 17
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-10-27" { revision "2017-03-13" {
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 50 skipping to change at page 12, line 36
} }
} }
// 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";
reference "draft-ietf-netmod-routing-cfg"; reference
"RFC 8022 - A YANG Data Model for Routing Management";
list network-instance { list network-instance {
key name; key name;
description "List of network-instances"; description "List of network-instances";
leaf name { leaf name {
type string; type string;
description "device scoped description "device scoped
identifier for the network identifier for the network
instance"; instance";
} }
leaf type { leaf type {
skipping to change at page 12, line 37 skipping to change at page 13, line 24
} }
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;
anydata root { yangmnt:mount-point root {
yangmnt:mount-point root; description
description "Root for models supported per "Root for models supported per
network instance"; network instance. 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 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 14, line 11 skipping to change at page 14, line 45
} }
<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-02 (work in progress), July 2016. ietf-netmod-schema-mount-04 (work in progress), March
2017.
[I-D.ietf-rtgwg-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- "YANG Logical Network Elements", draft-ietf-rtgwg-lne-
model-00 (work in progress), June 2016. model-01 (work in progress), October 2016.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
skipping to change at page 14, line 42 skipping to change at page 15, line 29
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-netmod-opstate-reqs]
Watsen, K. and T. Nadeau, "Terminology and Requirements Watsen, K. and T. Nadeau, "Terminology and Requirements
for Enhanced Handling of Operational State", draft-ietf- for Enhanced Handling of Operational State", draft-ietf-
netmod-opstate-reqs-04 (work in progress), January 2016. netmod-opstate-reqs-04 (work in progress), January 2016.
[I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-24 (work in
progress), October 2016.
[I-D.ietf-rtgwg-device-model] [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 Organizational Models", draft-ietf-
rtgwg-device-model-00 (work in progress), August 2016. rtgwg-device-model-01 (work in progress), October 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>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<http://www.rfc-editor.org/info/rfc7895>. <http://www.rfc-editor.org/info/rfc7895>.
[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
Management", RFC 8022, DOI 10.17487/RFC8022, November
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.
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. 22 change blocks. 
38 lines changed or deleted 69 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/