draft-ietf-rtgwg-device-model-01.txt   draft-ietf-rtgwg-device-model-02.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: May 1, 2017 LabN Consulting, L.L.C. Expires: September 14, 2017 LabN Consulting, L.L.C.
D. Bogdanovic D. Bogdanovic
C. Hopps C. Hopps
Deutsche Telekom Deutsche Telekom
October 28, 2016 March 13, 2017
Network Device YANG Organizational Models Network Device YANG Logical Organization
draft-ietf-rtgwg-device-model-01 draft-ietf-rtgwg-device-model-02
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 logical structure that may be used to configure and
network devices. The structure is itself represented as a YANG operate network devices. The structure is itself represented as an
model, with all of the related component models logically organized example YANG model, with all of the related component models
in a way that is operationally intuitive, but this model is not logically organized in a way that is operationally intuitive, but
expected to be implemented. The identified component modules are this model is not expected to be implemented. The identified
expected to be defined and implemented on common network devices. component modules are expected to be defined and implemented on
common network devices.
This document is derived from work submitted to the IETF by members This document is derived from work submitted to the IETF by members
of the informal OpenConfig working group of network operators and is of the informal OpenConfig working group of network operators and is
a product of the Routing Area YANG Architecture design team. a product of the Routing Area YANG Architecture design team.
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 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 46 skipping to change at page 2, line 46
6.2. Informative References . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
"Operational Structure and Organization of YANG Models" "Operational Structure and Organization of YANG Models"
[I-D.openconfig-netmod-model-structure], highlights the value of [I-D.openconfig-netmod-model-structure], highlights the value of
organizing individual, self-standing YANG [RFC6020] models into a organizing individual, self-standing YANG [RFC6020] models into a
more comprehensive structure. This document builds on that work and more comprehensive structure. This document builds on that work and
presents a derivative structure for use in representing the presents a derivative logical structure for use in representing the
networking infrastructure aspects of physical and virtual devices. networking infrastructure aspects of physical and virtual devices.
[I-D.openconfig-netmod-model-structure] and earlier versions of this [I-D.openconfig-netmod-model-structure] and earlier versions of this
document presented a single device-centric model root, this document document presented a single device-centric model root, this document
no longer contains this element. Such an element would have no longer contains this element. Such an element would have
translated to a single device management model that would be the root translated to a single device management model that would be the root
of all other models and was judged to be overly restrictive in terms of all other models and was judged to be overly restrictive in terms
of definition, implementation, and operation. of definition, implementation, and operation.
The document presents a notional network device YANG organizational The document presents a logical network device YANG organizational
structure that provides a conceptual framework for the models that structure that provides a conceptual framework for the models that
may be used to configure and operate network devices. The structure may be used to configure and operate network devices. The structure
is itself presented as a YANG module, with all of the related is itself presented as an example YANG module, with all of the
component modules logically organized in a way that is operationally related component modules logically organized in a way that is
intuitive. This network device model is not expected to be operationally intuitive. This network device model is not expected
implemented, but rather provide as context for the identified to be implemented, but rather provide as context for the identified
representative component modules with are expected to be defined, and representative component modules with are expected to be defined, and
supported on typical network devices. supported on typical network devices.
This document refers to two new modules that are expected to be This document refers to two new modules that are expected to be
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
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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: example-network-device
+--rw modules-state [RFC7895] +--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
| |
skipping to change at page 9, line 46 skipping to change at page 9, line 46
2.2. System Management 2.2. System Management
[Editor's note: need to discuss and resolve relationship between this [Editor's note: need to discuss and resolve relationship between this
structure and RFC7317 and determine if 7317 is close enough to simply structure and RFC7317 and determine if 7317 is close enough to simply
use as is.] use as is.]
System management is expected to reuse definitions contained in System management is expected to reuse definitions contained in
[RFC7317]. It is expected to be instantiated per device and LNE. [RFC7317]. It is expected to be instantiated per device and LNE.
Its structure is shown below: Its structure is shown below:
module: ietf-network-device module: example-network-device
+--rw system-management +--rw system-management
| +--rw system-management-global | +--rw system-management-global
| +--rw system-management-protocol* [type] | +--rw system-management-protocol* [type]
| +--rw type identityref | +--rw type identityref
System-management-global is used for configuration information and System-management-global is used for configuration information and
state that is independent of a particular management protocol. state that is independent of a particular management protocol.
System-management-protocol is a list of management protocol specific System-management-protocol is a list of management protocol specific
elements. The type-specific sub-modules are expected to be defined. elements. The type-specific sub-modules are expected to be defined.
The following is an example of envisioned usage: The following is an example of envisioned usage:
module: ietf-network-device module: example-network-device
+--rw system-management +--rw system-management
+--rw system-management-global +--rw system-management-global
| +--rw statistics-collection | +--rw statistics-collection
| ... | ...
+--rw system-management-protocol* [type] +--rw system-management-protocol* [type]
| +--rw type=syslog | +--rw type=syslog
| +--rw type=dns | +--rw type=dns
| +--rw type=ntp | +--rw type=ntp
| +--rw type=ssh | +--rw type=ssh
| +--rw type=tacacs | +--rw type=tacacs
skipping to change at page 10, line 35 skipping to change at page 10, line 35
2.3. Network Services 2.3. Network Services
A device may provide different network services to other devices, for A device may provide different network services to other devices, for
example a device my act as a DHCP server. The model may be example a device my act as a DHCP server. The model may be
instantiated per device, LNE, and NI. An identityref is used to instantiated per device, LNE, and NI. An identityref is used to
identify the type of specific service being provided and its identify the type of specific service being provided and its
associated configuration and state information. The defined associated configuration and state information. The defined
structure is as follows: structure is as follows:
module: ietf-network-device module: example-network-device
+--rw network-services +--rw network-services
| +--rw network-service* [type] | +--rw network-service* [type]
| +--rw type identityref | +--rw type identityref
The following is an example of envisioned usage: Examples shown below The following is an example of envisioned usage: Examples shown below
include a device-based Network Time Protocol (NTP) server, a Domain include a device-based Network Time Protocol (NTP) server, a Domain
Name System (DNS) server, and a Dynamic Host Configuration Protocol Name System (DNS) server, and a Dynamic Host Configuration Protocol
(DHCP) server: (DHCP) server:
module: ietf-network-device module: example-network-device
+--rw network-services +--rw network-services
+--rw network-service* [type] +--rw network-service* [type]
+--rw type=ntp-server +--rw type=ntp-server
+--rw type=dns-server +--rw type=dns-server
+--rw type=dhcp-server +--rw type=dhcp-server
2.4. OAM Protocols 2.4. OAM Protocols
OAM protocols that may run within the context of a device are grouped OAM protocols that may run within the context of a device are grouped
within the oam-protocols model. The model may be instantiated per within the oam-protocols model. The model may be instantiated per
device, LNE, and NI. An identifyref is used to identify the device, LNE, and NI. An identifyref is used to identify the
information and state that may relate to a specific OAM protocol. information and state that may relate to a specific OAM protocol.
The defined structure is as follows: The defined structure is as follows:
module: ietf-network-device module: example-network-device
+--rw oam-protocols +--rw oam-protocols
+--rw oam-protocol* [type] +--rw oam-protocol* [type]
+--rw type identityref +--rw type identityref
The following is an example of envisioned usage. Examples shown The following is an example of envisioned usage. Examples shown
below include Bi-directional Forwarding Detection (BFD), Ethernet below include Bi-directional Forwarding Detection (BFD), Ethernet
Connectivity Fault Management (CFM), and Two-Way Active Measurement Connectivity Fault Management (CFM), and Two-Way Active Measurement
Protocol (TWAMP): Protocol (TWAMP):
module: ietf-network-device module: example-network-device
+--rw oam-protocols +--rw oam-protocols
+--rw oam-protocol* [type] +--rw oam-protocol* [type]
+--rw type=bfd +--rw type=bfd
+--rw type=cfm +--rw type=cfm
+--rw type=twamp +--rw type=twamp
2.5. Routing 2.5. Routing
Routing protocol and IP forwarding configuration and operation Routing protocol and IP forwarding configuration and operation
information is modeled via a routing model, such as the one defined information is modeled via a routing model, such as the one defined
skipping to change at page 12, line 5 skipping to change at page 12, line 5
The routing module is expected to include all IETF defined control The routing module is expected to include all IETF defined control
plane protocols, such as BGP, OSPF, LDP and RSVP-TE. It is also plane protocols, such as BGP, OSPF, LDP and RSVP-TE. It is also
expected to support configuration and operation of or more routing expected to support configuration and operation of or more routing
information bases (RIB). A RIB is a list of routes complemented with information bases (RIB). A RIB is a list of routes complemented with
administrative data. Finally, policy is expected to be represented administrative data. Finally, policy is expected to be represented
within each control plane protocol and RIB. within each control plane protocol and RIB.
The anticipated structure is as follows: The anticipated structure is as follows:
module: ietf-network-device module: example-network-device
+--rw rt:routing [I-D.ietf-netmod-routing-cfg] +--rw rt:routing [I-D.ietf-netmod-routing-cfg]
+--rw control-plane-protocol* [type] +--rw control-plane-protocol* [type]
| +--rw type identityref | +--rw type identityref
| +--rw policy | +--rw policy
+--rw rib* [name] +--rw rib* [name]
+--rw name string +--rw name string
+--rw description? string +--rw description? string
+--rw policy +--rw policy
2.6. MPLS 2.6. MPLS
MPLS data plane related information is grouped together, as with the MPLS data plane related information is grouped together, as with the
previously discussed modules, is unaware of VRFs/NIs. The model may previously discussed modules, is unaware of VRFs/NIs. The model may
be instantiated per device, LNE, and NI. MPLS control plane be instantiated per device, LNE, and NI. MPLS control plane
protocols are expected to be included in Section 2.5. MPLS may reuse protocols are expected to be included in Section 2.5. MPLS may reuse
and build on [I-D.openconfig-mpls-consolidated-model] or other and build on [I-D.openconfig-mpls-consolidated-model] or other
emerging models and has an anticipated structure as follows: emerging models and has an anticipated structure as follows:
module: ietf-network-device module: example-network-device
+--rw mpls +--rw mpls
+--rw global +--rw global
+--rw lsps* [type] +--rw lsps* [type]
+--rw type identityref +--rw type identityref
Type refers to LSP type, such as static, traffic engineered or Type refers to LSP type, such as static, traffic engineered or
routing congruent. The following is an example of such usage: routing congruent. The following is an example of such usage:
module: ietf-network-device module: example-network-device
+--rw mpls +--rw mpls
+--rw global +--rw global
+--rw lsps* [type] +--rw lsps* [type]
+--rw type=static +--rw type=static
+--rw type=constrained-paths +--rw type=constrained-paths
+--rw type=igp-congruent +--rw type=igp-congruent
3. Security Considerations 3. Security Considerations
The network-device model structure described in this document does The network-device model structure described in this document does
skipping to change at page 13, line 19 skipping to change at page 13, line 19
4. IANA Considerations 4. IANA Considerations
This YANG model currently uses a temporary ad-hoc namespace. If it This YANG model currently uses a temporary ad-hoc namespace. If it
is placed or redirected for the standards track, an appropriate is placed or redirected for the standards track, an appropriate
namespace URI will be registered in the "IETF XML Registry" namespace URI will be registered in the "IETF XML Registry"
[RFC3688]. The YANG structure modules will be registered in the [RFC3688]. The YANG structure modules will be registered in the
"YANG Module Names" registry [RFC6020]. "YANG Module Names" registry [RFC6020].
5. Network Device Model Structure 5. Network Device Model Structure
<CODE BEGINS> file "ietf-network-device@2016-05-01.yang" <CODE BEGINS> file "example-network-device@2017-03-13.yang"
module ietf-network-device { module example-network-device {
yang-version "1"; yang-version "1";
// namespace // namespace
namespace "urn:ietf:params:xml:ns:yang:ietf-network-device"; namespace "urn:example:network-device";
prefix "nd"; prefix "nd";
// import some basic types // import some basic types
// meta // meta
organization "IETF RTG YANG Design Team Collaboration organization "IETF RTG YANG Design Team Collaboration
with OpenConfig"; with OpenConfig";
contact contact
"Routing Area YANG Architecture Design Team - "Routing Area YANG Architecture Design Team -
<rtg-dt-yang-arch@ietf.org>"; <rtg-dt-yang-arch@ietf.org>";
description description
"This module describes a model structure for YANG "This module describes a model structure for YANG
configuration and operational state data models. Its intent is configuration and operational state data models. Its intent is
to describe how individual device protocol and feature models to describe how individual device protocol and feature models
fit together and interact."; fit together and interact.";
revision "2016-05-01" { revision "2017-03-13" {
description description
"IETF Routing YANG Design Team Meta-Model"; "IETF Routing YANG Design Team Meta-Model";
reference "TBD"; reference "TBD";
} }
// extension statements // extension statements
// identity statements // identity statements
identity oam-protocol-type { identity oam-protocol-type {
description description
skipping to change at page 17, line 38 skipping to change at page 17, line 38
// Note that there is no routing or network instance // Note that there is no routing or network instance
list control-plane-protocol { list control-plane-protocol {
key "type"; key "type";
description description
"List of control plane protocols configured for "List of control plane protocols configured for
a network instance."; a network instance.";
leaf type { leaf type {
type identityref { type identityref {
base control-plane-protocol-type; base control-plane-protocol-type;
} }
mandatory true;
description description
"The control plane protocol type, e.g., BGP, "The control plane protocol type, e.g., BGP,
OSPF IS-IS, etc"; OSPF IS-IS, etc";
} }
container policy { container policy {
description description
"Protocol specific policy, "Protocol specific policy,
reusing [RTG-POLICY]"; reusing [RTG-POLICY]";
} }
} }
list rib { list rib {
key "name"; key "name";
min-elements "1";
description description
"Each entry represents a RIB identified by the "Each entry represents a RIB identified by the
'name' key. All routes in a RIB must belong to the 'name' key. All routes in a RIB must belong to the
same address family. same address family.
For each routing instance, an implementation should For each routing instance, an implementation should
provide one system-controlled default RIB for each provide one system-controlled default RIB for each
supported address family."; supported address family.";
leaf name { leaf name {
type string; type string;
mandatory true;
description description
"The name of the RIB."; "The name of the RIB.";
} }
reference "draft-ietf-netmod-routing-cfg"; reference "draft-ietf-netmod-routing-cfg";
leaf description { leaf description {
type string; type string;
description description
"Description of the RIB"; "Description of the RIB";
} }
// Note that there is no list of interfaces within // Note that there is no list of interfaces within
skipping to change at page 19, line 44 skipping to change at page 19, line 45
} }
<CODE ENDS> <CODE ENDS>
6. References 6. References
6.1. Normative References 6.1. Normative References
[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.
[I-D.ietf-rtgwg-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-ietf-rtgwg-ni-model-00 "YANG Network Instances", draft-ietf-rtgwg-ni-model-01
(work in progress), June 2016. (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>.
[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 46 skipping to change at page 20, line 46
draft-ietf-netmod-acl-model-09 (work in progress), October draft-ietf-netmod-acl-model-09 (work in progress), October
2016. 2016.
[I-D.ietf-netmod-opstate-reqs] [I-D.ietf-netmod-opstate-reqs]
Watsen, K. and T. Nadeau, "Terminology and Requirements Watsen, K. and T. Nadeau, "Terminology and Requirements
for Enhanced Handling of Operational State", draft-ietf- for Enhanced Handling of Operational State", draft-ietf-
netmod-opstate-reqs-04 (work in progress), January 2016. netmod-opstate-reqs-04 (work in progress), January 2016.
[I-D.ietf-netmod-routing-cfg] [I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-24 (work in Management", draft-ietf-netmod-routing-cfg-25 (work in
progress), October 2016. progress), November 2016.
[I-D.ietf-rtgwg-yang-key-chain] [I-D.ietf-rtgwg-yang-key-chain]
Lindem, A., Qu, Y., Yeung, D., Chen, I., Zhang, Z., and Y. Lindem, A., Qu, Y., Yeung, D., Chen, I., Zhang, Z., and Y.
Yang, "Routing Key Chain YANG Data Model", draft-ietf- Yang, "Routing Key Chain YANG Data Model", draft-ietf-
rtgwg-yang-key-chain-10 (work in progress), October 2016. rtgwg-yang-key-chain-15 (work in progress), February 2017.
[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",
 End of changes. 29 change blocks. 
40 lines changed or deleted 42 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/