draft-ietf-rtgwg-device-model-00.txt   draft-ietf-rtgwg-device-model-01.txt 
Network Working Group A. Lindem, Ed. Network Working Group A. Lindem, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational L. Berger, Ed. Intended status: Informational L. Berger, Ed.
Expires: February 3, 2017 LabN Consulting, L.L.C. Expires: May 1, 2017 LabN Consulting, L.L.C.
D. Bogdanovic D. Bogdanovic
C. Hopps C. Hopps
Deutsche Telekom Deutsche Telekom
August 2, 2016 October 28, 2016
Network Device YANG Organizational Models Network Device YANG Organizational Models
draft-ietf-rtgwg-device-model-00 draft-ietf-rtgwg-device-model-01
Abstract Abstract
This document presents an approach for organizing YANG models in a This document presents an approach for organizing YANG models in a
comprehensive structure that may be used to configure and operate comprehensive structure that may be used to configure and operate
network devices. The structure is itself represented as a YANG network devices. The structure is itself represented as a YANG
model, with all of the related component models logically organized model, with all of the related component models logically organized
in a way that is operationally intuitive, but this model is not in a way that is operationally intuitive, but this model is not
expected to be implemented. The identified component modules are expected to be implemented. The identified component modules are
expected to be defined and implemented on common network devices. expected to be defined and implemented on common network devices.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 February 3, 2017. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 28 skipping to change at page 3, line 28
implemented. These models are defined to support the configuration implemented. These models are defined to support the configuration
and operation of network-devices that allow for the partitioning of and operation of network-devices that allow for the partitioning of
resources from both, or either, management and networking resources from both, or either, management and networking
perspectives. Two forms of resource partitioning are referenced: perspectives. Two forms of resource partitioning are referenced:
The first form provides a logical partitioning of a network device The first form provides a logical partitioning of a network device
where each partition is separately managed as essentially an where each partition is separately managed as essentially an
independent network element which is 'hosted' by the base network independent network element which is 'hosted' by the base network
device. These hosted network elements are referred to as logical device. These hosted network elements are referred to as logical
network elements, or LNEs, and are supported by the logical-network- network elements, or LNEs, and are supported by the logical-network-
element module defined in [LNE-MODEL]. The module is used to element module defined in [I-D.ietf-rtgwg-lne-model]. The module is
identify LNEs and associate resources from the network-device with used to identify LNEs and associate resources from the network-device
each LNE. LNEs themselves are represented in YANG as independent with each LNE. LNEs themselves are represented in YANG as
network devices; each accessed independently. Optionally, and when independent network devices; each accessed independently.
supported by the implementation, they may also be accessed from the Optionally, and when supported by the implementation, they may also
host system. Examples of vendor terminology for an LNE include be accessed from the host system. Examples of vendor terminology for
logical system or logical router, and virtual switch, chassis, or an LNE include logical system or logical router, and virtual switch,
fabric. chassis, or fabric.
The second form provides support what is commonly referred to as The second form provides support what is commonly referred to as
Virtual Routing and Forwarding (VRF) instances as well as Virtual Virtual Routing and Forwarding (VRF) instances as well as Virtual
Switch Instances (VSI), see [RFC4026]. In this form of resource Switch Instances (VSI), see [RFC4026]. In this form of resource
partitioning multiple control plane and forwarding/bridging instances partitioning multiple control plane and forwarding/bridging instances
are provided by and managed via a single (physical or logical) are provided by and managed via a single (physical or logical)
network device. This form of resource partitioning is referred to as network device. This form of resource partitioning is referred to as
Network Instances and are supported by the network-instance module Network Instances and are supported by the network-instance module
defined in [NI-MODEL]. Configuration and operation of each network- defined in [I-D.ietf-rtgwg-ni-model]. Configuration and operation of
instance is always via the network device and the network-instance each network-instance is always via the network device and the
module. network-instance module.
This document was motivated by, and derived from, This document was motivated by, and derived from,
[I-D.openconfig-netmod-model-structure]. The requirements from that [I-D.openconfig-netmod-model-structure]. The requirements from that
document have been combined with the requirements from "Consistent document have been combined with the requirements from "Consistent
Modeling of Operational State Data in YANG", Modeling of Operational State Data in YANG",
[I-D.openconfig-netmod-opstate], into "NETMOD Operational State [I-D.openconfig-netmod-opstate], into "NETMOD Operational State
Requirements", [I-D.ietf-netmod-opstate-reqs]. This document is Requirements", [I-D.ietf-netmod-opstate-reqs]. This document is
aimed at the requirement related to a common model-structure, aimed at the requirement related to a common model-structure,
currently Requirement 7, and also aims to provide a modeling base for currently Requirement 7, and also aims to provide a modeling base for
skipping to change at page 5, line 44 skipping to change at page 5, line 44
| :+-----+-----+-----+: :+-----+-----+-----+: | | :+-----+-----+-----+: :+-----+-----+-----+: |
| : | | | | | | : : | | | | | | : | | : | | | | | | : : | | | | | | : |
| :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
`'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|'''''
| | | | | | | | | | | | | | | | | | | | | | | |
Interfaces Interfaces Interfaces Interfaces
Figure 1: Module Element Relationships Figure 1: Module Element Relationships
A model for LNEs is described in [LNE-MODEL] and the model for A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the
network instances is covered in [NI-MODEL]. model for network instances is covered in [I-D.ietf-rtgwg-ni-model].
The presented notional network device module can itself be thought of The presented notional network device module can itself be thought of
as a "meta-model" as it describes the relationships between as a "meta-model" as it describes the relationships between
individual models. We choose to represent it also as a simple YANG individual models. We choose to represent it also as a simple YANG
module consisting of other models, which are in fact independent top module consisting of other models, which are in fact independent top
level individual models. Although it is never expected to be level individual models. Although it is never expected to be
implemented. implemented.
The presented modules do not follow the hierarchy of any Particular The presented modules do not follow the hierarchy of any Particular
implementation, and hence is vendor-neutral. Nevertheless, the implementation, and hence is vendor-neutral. Nevertheless, the
structure should be familiar to network operators and also readily structure should be familiar to network operators and also readily
mapped to vendor implementations. mapped to vendor implementations.
The overall structure is: The overall structure is:
module: ietf-network-device module: ietf-network-device
+--rw modules-state [I-D.ietf-netconf-yang-library] +--rw modules-state [RFC7895]
| |
+--rw interfaces [RFC7223] +--rw interfaces [RFC7223]
+--rw hardware +--rw hardware
+--rw qos +--rw qos
| |
+--rw system-management [RFC7317 or derived] +--rw system-management [RFC7317 or derived]
+--rw network-services +--rw network-services
+--rw oam-protocols +--rw oam-protocols
| |
+--rw routing [I-D.ietf-netmod-routing-cfg] +--rw routing [I-D.ietf-netmod-routing-cfg]
+--rw mpls +--rw mpls
+--rw ieee-dot1Q +--rw ieee-dot1Q
| |
+--rw acls [I-D.ietf-netmod-acl-model] +--rw acls [I-D.ietf-netmod-acl-model]
+--rw key-chains [I-D.ietf-rtgwg-yang-key-chain] +--rw key-chains [I-D.ietf-rtgwg-yang-key-chain]
| |
+--rw logical-network-elements [I-D.rtgyangdt-rtgwg-lne-model] +--rw logical-network-elements [I-D.ietf-rtgwg-lne-model]
+--rw network-instances [I-D.rtgyangdt-rtgwg-ni-model] +--rw network-instances [I-D.ietf-rtgwg-ni-model]
The network device is composed of top level modules that can be used The network device is composed of top level modules that can be used
to configure and operate a network device. (This is a significant to configure and operate a network device. (This is a significant
difference from earlier versions of this document where there was a difference from earlier versions of this document where there was a
strict model hierarchy.) Importantly the network device structure is strict model hierarchy.) Importantly the network device structure is
the same for a physical network device or a logical network device, the same for a physical network device or a logical network device,
such as those instantiated via the logical-network-element model. such as those instantiated via the logical-network-element model.
Extra spacing is included to denote different types of modules Extra spacing is included to denote different types of modules
included. included.
YANG library [I-D.ietf-netconf-yang-library] is included as it used YANG library [RFC7895] is included as it used to identify details of
to identify details of the top level modules supported by the the top level modules supported by the (physical or logical) network
(physical or logical) network device. Th ability to identify device. Th ability to identify supported modules is particularly
supported modules is particularly important for LNEs which may have a important for LNEs which may have a set of supported modules which
set of supported modules which differs from the set supported by the differs from the set supported by the host network device.
host network device.
The interface management model [RFC7223] is included at the top The interface management model [RFC7223] is included at the top
level. The hardware module is a placeholder for a future device- level. The hardware module is a placeholder for a future device-
specific configuration and operational state data model. For specific configuration and operational state data model. For
example, a common structure for the hardware model might include example, a common structure for the hardware model might include
chassis, line cards, and ports, but we leave this unspecified. The chassis, line cards, and ports, but we leave this unspecified. The
quality of service (QoS) section is also a placeholder module for quality of service (QoS) section is also a placeholder module for
device configuration and operational state data which relates to the device configuration and operational state data which relates to the
treatment of traffic across the device. This document references treatment of traffic across the device. This document references
augmentations to the interface module to support LNEs and NIs. augmentations to the interface module to support LNEs and NIs.
skipping to change at page 8, line 6 skipping to change at page 7, line 50
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 defined in The logical-network-element and network-instance modules defined in
[LNE-MODEL] and [NI-MODEL] augment the existing interface management [I-D.ietf-rtgwg-lne-model] and [I-D.ietf-rtgwg-ni-model] augment the
model in two ways: The first, by the logical-network-element module, existing interface management model in two ways: The first, by the
adds an identifier which is used on physical interface types to logical-network-element module, adds an identifier which is used on
identify an associated LNE. The second, by the network-instance physical interface types to identify an associated LNE. The second,
module, adds a name which is used on interface or sub-interface types by the network-instance module, adds a name which is used on
to identify an associated network instance. Similarly, this name is interface or sub-interface types to identify an associated network
also added for IPv4 and IPv6 types, as defined in [RFC7277]. instance. Similarly, this name is also added for IPv4 and IPv6
types, as defined in [RFC7277].
The interface related augmentations are as follows: The interface related augmentations are as follows:
module: ietf-logical-network-element module: ietf-logical-network-element
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw bind-lne-name? string +--rw bind-lne-name? string
module: ietf-network-instance module: ietf-network-instance
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw bind-network-instance-name? string +--rw bind-network-instance-name? string
skipping to change at page 19, line 42 skipping to change at page 19, line 42
// notification statements // notification statements
} }
<CODE ENDS> <CODE ENDS>
6. References 6. References
6.1. Normative References 6.1. Normative References
[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-rtgyangdt-rtgwg- "Logical Network Element Model", draft-ietf-rtgwg-lne-
lne-model-00.txt (work in progress), May 2016. model-00 (work in progress), June 2016.
[NI-MODEL] [I-D.ietf-rtgwg-ni-model]
Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
"Network Instance Model", draft-rtgyangdt-rtgwg-ni-model- "Network Instance Model", draft-ietf-rtgwg-ni-model-00
00.txt (work in progress), May 2016. (work in progress), June 2016.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[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>.
skipping to change at page 20, line 33 skipping to change at page 20, line 33
[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>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <http://www.rfc-editor.org/info/rfc7317>. 2014, <http://www.rfc-editor.org/info/rfc7317>.
6.2. Informative References 6.2. Informative References
[I-D.ietf-netconf-yang-library] [I-D.ietf-netmod-acl-model]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
Library", draft-ietf-netconf-yang-library-05 (work in "Network Access Control List (ACL) YANG Data Model",
progress), April 2016. draft-ietf-netmod-acl-model-09 (work in progress), October
2016.
[I-D.ietf-netmod-opstate-reqs] [I-D.ietf-netmod-opstate-reqs]
Watsen, K. and T. Nadeau, "Terminology and Requirements Watsen, K. and T. Nadeau, "Terminology and Requirements
for Enhanced Handling of Operational State", draft-ietf- for Enhanced Handling of Operational State", draft-ietf-
netmod-opstate-reqs-03 (work in progress), January 2016. netmod-opstate-reqs-04 (work in progress), January 2016.
[I-D.ietf-netmod-routing-cfg] [I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-20 (work in Management", draft-ietf-netmod-routing-cfg-24 (work in
progress), October 2015. progress), October 2016.
[I-D.ietf-rtgwg-yang-key-chain]
Lindem, A., Qu, Y., Yeung, D., Chen, I., Zhang, Z., and Y.
Yang, "Routing Key Chain YANG Data Model", draft-ietf-
rtgwg-yang-key-chain-10 (work in progress), October 2016.
[I-D.openconfig-mpls-consolidated-model] [I-D.openconfig-mpls-consolidated-model]
George, J., Fang, L., eric.osborne@level3.com, e., and R. George, J., Fang, L., eric.osborne@level3.com, e., and R.
Shakir, "MPLS / TE Model for Service Provider Networks", Shakir, "MPLS / TE Model for Service Provider Networks",
draft-openconfig-mpls-consolidated-model-02 (work in draft-openconfig-mpls-consolidated-model-02 (work in
progress), October 2015. progress), October 2015.
[I-D.openconfig-netmod-model-structure] [I-D.openconfig-netmod-model-structure]
Shaikh, A., Shakir, R., D'Souza, K., and L. Fang, Shaikh, A., Shakir, R., D'Souza, K., and L. Fang,
"Operational Structure and Organization of YANG Models", "Operational Structure and Organization of YANG Models",
skipping to change at page 21, line 21 skipping to change at page 21, line 27
[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.
[IEEE-8021Q] [IEEE-8021Q]
Holness, M., "IEEE 802.1Q YANG Module Specifications", Holness, M., "IEEE 802.1Q YANG Module Specifications",
IEEE-Draft http://www.ieee802.org/1/files/public/docs2015/ IEEE-Draft http://www.ieee802.org/1/files/public/docs2015/
new-mholness-yang-8021Q-0515-v04.pdf, May 2015. new-mholness-yang-8021Q-0515-v04.pdf, May 2015.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<http://www.rfc-editor.org/info/rfc7895>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
This document is derived from draft-openconfig-netmod-model- This document is derived from draft-openconfig-netmod-model-
structure-00. We thank the Authors of that document and acknowledge structure-00. We thank the Authors of that document and acknowledge
their indirect contribution to this work. The authors include: Anees their indirect contribution to this work. The authors include: Anees
Shaikh, Rob Shakir, Kevin D'Souza, Luyuan Fang, Qin Wu, Stephane Shaikh, Rob Shakir, Kevin D'Souza, Luyuan Fang, Qin Wu, Stephane
Litkowski and Gang Yan. Litkowski and Gang Yan.
This work was discussed in and produced by the Routing Area Yang This work was discussed in and produced by the Routing Area Yang
Architecture design team. Members at the time of writing included Architecture design team. Members at the time of writing included
 End of changes. 19 change blocks. 
46 lines changed or deleted 56 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/