draft-ietf-opsawg-model-automation-framework-04.txt   draft-ietf-opsawg-model-automation-framework-05.txt 
OPSAWG Q. Wu, Ed. OPSAWG Q. Wu, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational M. Boucadair, Ed. Intended status: Informational M. Boucadair, Ed.
Expires: December 16, 2020 Orange Expires: March 12, 2021 Orange
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
C. Xie C. Xie
China Telecom China Telecom
L. Geng L. Geng
China Mobile China Mobile
June 14, 2020 September 8, 2020
A Framework for Automating Service and Network Management with YANG A Framework for Automating Service and Network Management with YANG
draft-ietf-opsawg-model-automation-framework-04 draft-ietf-opsawg-model-automation-framework-05
Abstract Abstract
Data models provide a programmatic approach to represent services and Data models provide a programmatic approach to represent services and
networks. Concretely, they can be used to derive configuration networks. Concretely, they can be used to derive configuration
information for network and service components, and state information information for network and service components, and state information
that will be monitored and tracked. Data models can be used during that will be monitored and tracked. Data models can be used during
the service and network management life cycle, such as service the service and network management life cycle, such as service
instantiation, provisioning, optimization, monitoring, diagnostic, instantiation, provisioning, optimization, monitoring, diagnostic,
and assurance. Data models are also instrumental in the automation and assurance. Data models are also instrumental in the automation
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 16, 2020. This Internet-Draft will expire on March 12, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 5 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Concepts and Goals . . . . . . . . . . . . . . 6 3. Architectural Concepts and Goals . . . . . . . . . . . . . . 6
3.1. Data Models: Layering and Representation . . . . . . . . 6 3.1. Data Models: Layering and Representation . . . . . . . . 6
3.2. Automation of Service Delivery Procedures . . . . . . . . 9 3.2. Automation of Service Delivery Procedures . . . . . . . . 10
3.3. Service Fullfillment Automation . . . . . . . . . . . . . 10 3.3. Service Fullfillment Automation . . . . . . . . . . . . . 10
3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 10 3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 11
4. Functional Bocks and Interactions . . . . . . . . . . . . . . 11 4. Functional Blocks and Interactions . . . . . . . . . . . . . 11
4.1. Service Lifecycle Management Procedure . . . . . . . . . 12 4.1. Service Lifecycle Management Procedure . . . . . . . . . 12
4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 13 4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 13
4.1.2. Service Creation/Modification . . . . . . . . . . . . 13 4.1.2. Service Creation/Modification . . . . . . . . . . . . 13
4.1.3. Service Optimization . . . . . . . . . . . . . . . . 13 4.1.3. Service Optimization . . . . . . . . . . . . . . . . 13
4.1.4. Service Diagnosis . . . . . . . . . . . . . . . . . . 14 4.1.4. Service Diagnosis . . . . . . . . . . . . . . . . . . 14
4.1.5. Service Decommission . . . . . . . . . . . . . . . . 14 4.1.5. Service Decommission . . . . . . . . . . . . . . . . 14
4.2. Service Fullfillment Management Procedure . . . . . . . . 14 4.2. Service Fullfillment Management Procedure . . . . . . . . 14
4.2.1. Intended Configuration Provision . . . . . . . . . . 15 4.2.1. Intended Configuration Provision . . . . . . . . . . 15
4.2.2. Configuration Validation . . . . . . . . . . . . . . 15 4.2.2. Configuration Validation . . . . . . . . . . . . . . 15
4.2.3. Performance Monitoring/Model-driven Telemetry . . . . 16 4.2.3. Performance Monitoring/Model-driven Telemetry . . . . 16
skipping to change at page 3, line 14 skipping to change at page 3, line 14
5.3. Event-based Telemetry in the Device Self Management . . . 20 5.3. Event-based Telemetry in the Device Self Management . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Layered YANG Modules Examples Overview . . . . . . . 32 Appendix A. Layered YANG Modules Examples Overview . . . . . . . 32
A.1. Service Models: Definition and Samples . . . . . . . . . 32 A.1. Service Models: Definition and Samples . . . . . . . . . 32
A.2. Network Models: Samples . . . . . . . . . . . . . . . . . 32 A.2. Network Models: Samples . . . . . . . . . . . . . . . . . 33
A.3. Device Models: Samples . . . . . . . . . . . . . . . . . 35 A.3. Device Models: Samples . . . . . . . . . . . . . . . . . 35
A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 37 A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 37
A.3.2. Device Models: Samples . . . . . . . . . . . . . . . 37 A.3.2. Device Models: Samples . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Service management systems usually comprise service activation/ Service management systems usually comprise service activation/
provision and service operation. Current service delivery provision and service operation. Current service delivery
procedures, from the processing of customer's requirements and orders procedures, from the processing of customer's requirements and orders
skipping to change at page 4, line 28 skipping to change at page 4, line 28
Models are key for each of the aforementioned four technical items. Models are key for each of the aforementioned four technical items.
Service and network management automation is an important step to Service and network management automation is an important step to
improve the agility of network operations. Models are also important improve the agility of network operations. Models are also important
to ease integrating multi-vendor solutions. to ease integrating multi-vendor solutions.
YANG [RFC7950] module developers have taken both top-down and bottom- YANG [RFC7950] module developers have taken both top-down and bottom-
up approaches to develop modules [RFC8199] and to establish a mapping up approaches to develop modules [RFC8199] and to establish a mapping
between a network technology and customer requirements at the top or between a network technology and customer requirements at the top or
abstracting common constructs from various network technologies at abstracting common constructs from various network technologies at
the bottom. At the time of writing this document (2020), there are the bottom. At the time of writing this document (2020), there are
many data models including configuration and service models that have many YANG data models including configuration and service models that
been specified or are being specified by the IETF. They cover many have been specified or are being specified by the IETF. They cover
of the networking protocols and techniques. However, how these many of the networking protocols and techniques. However, how these
models work together to configure a device, manage a set of devices models work together to configure a device, manage a set of devices
involved in a service, or provide a service is something that is not involved in a service, or provide a service is something that is not
currently documented either within the IETF or other Standards currently documented either within the IETF or other Standards
Development Organizations (SDOs). Development Organizations (SDOs).
This document describes an architectural framework for service and This document describes an architectural framework for service and
network management automation (Section 3) that takes advantage of network management automation (Section 3) that takes advantage of
YANG modeling technologies and investigates how different layer YANG YANG modeling technologies and investigates how different layer YANG
data models interact with each other (e.g., service mapping, model data models interact with each other (e.g., service mapping, model
composing) in the context of service delivery and fulfillment composing) in the context of service delivery and fulfillment
skipping to change at page 5, line 45 skipping to change at page 5, line 45
Model. Model.
Device Model: Refers to the Network Element YANG data model Device Model: Refers to the Network Element YANG data model
described in [RFC8199] or the Device Configuration Model discussed described in [RFC8199] or the Device Configuration Model discussed
in [RFC8309]. in [RFC8309].
Device Models are also used to refer to model a function embedded Device Models are also used to refer to model a function embedded
in a device (e.g., Network Address Translation (NAT) [RFC8512], in a device (e.g., Network Address Translation (NAT) [RFC8512],
Access Control Lists (ACLs) [RFC8519]). Access Control Lists (ACLs) [RFC8519]).
Pipe: Refers to a communication scope where only one-to-one (1:1)
communications are allowed. The scope can be identified between
ingress and egress nodes, two service sites, etc.
Hose: Refers to a communication scope where one-to-many (1:N)
communications are allowed (e.g., one site to multiple sites).
Funnel: Refers to a communication scope where many-to-one (N:1)
communications are allowed.
2.2. Acronyms 2.2. Acronyms
The following acronyms are used in the document: The following acronyms are used in the document:
ACL Access Control List ACL Access Control List
CE Customer Edge CE Customer Edge
ECA Event Condition Action ECA Event Condition Action
L2VPN Layer 2 Virtual Private Network L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network L3VPN Layer 3 Virtual Private Network
NAT Network Address Translation NAT Network Address Translation
skipping to change at page 9, line 43 skipping to change at page 9, line 43
| +-----------------------+ | | +-----------------------+ |
| | Device | Device Model | | | Device | Device Model |
| |+--------------------+ | | | |+--------------------+ | |
| || Device Modeling | | Interface add, BGP Peer, | | || Device Modeling | | Interface add, BGP Peer, |
| |+--------------------+ | Tunnel ID, QoS/TE, ... | | |+--------------------+ | Tunnel ID, QoS/TE, ... |
| +-----------------------+ | | +-----------------------+ |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
Figure 3: Layering and Representation Figure 3: Layering and Representation
The layering model depicted in Figure 3 does not make any assumption
about the location of the various entities (e.g., controller,
orchestrator) within the network. As such, the architecture does not
preclude deployments where, for example, the controller is embedded
on a device that hosts other functions that are controlled via YANG
modules.
In order to ease the mapping between layers and data reuse, this
document focuses on service models that are modelled using YANG.
Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3
does not preclude service models to be modelled using other data
modelling languages than YANG.
3.2. Automation of Service Delivery Procedures 3.2. Automation of Service Delivery Procedures
Service Models can be used by a Network Operator to expose its Service Models can be used by a Network Operator to expose its
services to its customers. Exposing such models allows to automate services to its customers. Exposing such models allows to automate
the activation of service orders and thus the service delivery. One the activation of service orders and thus the service delivery. One
or more monolithic Service Models can be used in the context of a or more monolithic Service Models can be used in the context of a
composite service activation request (e.g., delivery of a caching composite service activation request (e.g., delivery of a caching
infrastructure over a VPN). Such models are used to feed a decision- infrastructure over a VPN). Such models are used to feed a decision-
making intelligence to adequately accommodate customer's needs. making intelligence to adequately accommodate customer's needs.
Also, such models may be used jointly with services that require Also, such models may be used jointly with services that require
dynamic invocation. An example is provided by the service modules dynamic invocation. An example is provided by the service modules
defined by the DOTS WG to dynamically trigger requests to handle defined by the DOTS WG to dynamically trigger requests to handle
Distributed Denial-of-Service (DDoS) attacks [RFC8783]. Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service
filtering request modelled using [RFC8783] will be translated into
device-specific filtering (e.g., ACLs defined in [RFC8519]) that to
fulfil the service request.
Network Models can be derived from Service Models and used to Network Models can be derived from Service Models and used to
provision, monitor, instantiate the service, and provide lifecycle provision, monitor, instantiate the service, and provide lifecycle
management of network resources. Doing so is meant to: management of network resources. Doing so is meant to:
o expose network resources to customers (including other Network o expose network resources to customers (including other Network
Operators) to provide service fulfillment and assurance Operators) to provide service fulfillment and assurance.
o allow customers (or Network Operators) to dynamically adjust the o allow customers (or Network Operators) to dynamically adjust the
network resources based on service requirements as described in network resources based on service requirements as described in
Service Models (e.g., Figure 2) and the current network Service Models (e.g., Figure 2) and the current network
performance information described in the telemetry modules. performance information described in the telemetry modules.
3.3. Service Fullfillment Automation 3.3. Service Fullfillment Automation
To operate a service, the settings of the parameters in the Device To operate a service, the settings of the parameters in the Device
Models are derived from Service Models and/or Network Models and are Models are derived from Service Models and/or Network Models and are
skipping to change at page 11, line 29 skipping to change at page 11, line 46
depicted in Figure 2). Device Models will be tweaked accordingly to depicted in Figure 2). Device Models will be tweaked accordingly to
provide policy-based management. Policies can also be used for provide policy-based management. Policies can also be used for
telemetry automation, e.g., policies that contain conditions can telemetry automation, e.g., policies that contain conditions can
trigger the generation and pushing of new telemetry data. trigger the generation and pushing of new telemetry data.
Performance measurement telemetry can be used to provide service Performance measurement telemetry can be used to provide service
assurance at Service and/or Network levels. Performance measurement assurance at Service and/or Network levels. Performance measurement
telemetry model can tie with Service or Network Models to monitor telemetry model can tie with Service or Network Models to monitor
network performance or Service Level Agreement. network performance or Service Level Agreement.
4. Functional Bocks and Interactions 4. Functional Blocks and Interactions
The architectural considerations described in Section 3 lead to the The architectural considerations described in Section 3 lead to the
architecture described in this section and illustrated in Figure 4. architecture described in this section and illustrated in Figure 4.
+------------------+ +------------------+
................. | | ................. | |
Service level | | Service level | |
V | V |
E2E E2E E2E E2E E2E E2E E2E E2E
Service --> Service ---------> Service -----> Service -----+ Service --> Service ---------> Service -----> Service -----+
skipping to change at page 17, line 18 skipping to change at page 17, line 18
Service Decomposing allows to decompose service model at the service Service Decomposing allows to decompose service model at the service
level or network model at the network level into a set of device/ level or network model at the network level into a set of device/
function models at the device level. These Device Models may be tied function models at the device level. These Device Models may be tied
to specific device types or classified into a collection of related to specific device types or classified into a collection of related
YANG modules based on service types and features offered, and load at YANG modules based on service types and features offered, and load at
the implementation time before configuration is loaded and validated. the implementation time before configuration is loaded and validated.
5. YANG Data Model Integration Examples 5. YANG Data Model Integration Examples
The following subsections provides some data models integration The following subsections provides some YANG data models integration
examples. examples.
5.1. L2VPN/L3VPN Service Delivery 5.1. L2VPN/L3VPN Service Delivery
In reference to Figure 5, the following steps are performed to In reference to Figure 5, the following steps are performed to
deliver the L3VPN service within the network management automation deliver the L3VPN service within the network management automation
architecture defined in this document: architecture defined in this document:
1. The Customer requests to create two sites (as per service 1. The Customer requests to create two sites (as per service
creation operation in Section 4.2.1) relying upon a L3SM Service creation operation in Section 4.2.1) relying upon a L3SM Service
skipping to change at page 19, line 39 skipping to change at page 19, line 39
| | IP | | | | IP | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| CE1 +-------+ PE1 | | PE2 +---------+ CE2 | | CE1 +-------+ PE1 | | PE2 +---------+ CE2 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 6: L3VPN Service Delivery Example (Target) Figure 6: L3VPN Service Delivery Example (Target)
Note that a similar analysis can be performed for Layer 2 VPNs Note that a similar analysis can be performed for Layer 2 VPNs
(L2VPNs). A L2VPN Service Model (L2SM) is defined in [RFC8466], (L2VPNs). A L2VPN Service Model (L2SM) is defined in [RFC8466],
while the L2VPN Network YANG Model (L2NM) is specified in while the L2VPN Network YANG Model (L2NM) is specified in
[I-D.barguil-opsawg-l2sm-l2nm]. [I-D.ietf-opsawg-l2nm].
5.2. VN Lifecycle Management 5.2. VN Lifecycle Management
In reference to Figure 7, the following steps are performed to In reference to Figure 7, the following steps are performed to
deliver the VN service within the network management automation deliver the VN service within the network management automation
architecture defined in this document: architecture defined in this document:
1. Customer requests (service exposure operation in Section 4.1.1) 1. Customer requests (service exposure operation in Section 4.1.1)
to create 'VN' based on Access point, association between VN and to create 'VN' based on Access point, association between VN and
Access point, VN member defined in the VN YANG module. Access point, VN member defined in the VN YANG module.
skipping to change at page 22, line 37 skipping to change at page 22, line 37
7. IANA Considerations 7. IANA Considerations
There are no IANA requests or assignments included in this document. There are no IANA requests or assignments included in this document.
8. Acknowledgements 8. Acknowledgements
Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter, Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter,
and Adrian Farrel for the review. and Adrian Farrel for the review.
Many thanks to Robert Wilton for the detailed AD review.
9. Contributors 9. Contributors
Christian Jacquenet Christian Jacquenet
Orange Orange
Rennes, 35000 Rennes, 35000
France France
Email: Christian.jacquenet@orange.com Email: Christian.jacquenet@orange.com
Luis Miguel Contreras Murillo Luis Miguel Contreras Murillo
Telifonica Telifonica
skipping to change at page 24, line 16 skipping to change at page 24, line 16
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
10.2. Informative References 10.2. Informative References
[I-D.barguil-opsawg-l2sm-l2nm] [I-D.clacla-netmod-model-catalog]
Barguil, S., Dios, O., Boucadair, M., Munoz, L., Jalil, Clarke, J. and B. Claise, "YANG module for
L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- yangcatalog.org", draft-clacla-netmod-model-catalog-03
barguil-opsawg-l2sm-l2nm-02 (work in progress), May 2020. (work in progress), April 2018.
[I-D.ietf-bess-evpn-yang] [I-D.ietf-bess-evpn-yang]
Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K.,
and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- and J. Rabadan, "Yang Data Model for EVPN", draft-ietf-
bess-evpn-yang-07 (work in progress), March 2019. bess-evpn-yang-07 (work in progress), March 2019.
[I-D.ietf-bess-l2vpn-yang] [I-D.ietf-bess-l2vpn-yang]
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
and K. Tiruveedhula, "YANG Data Model for MPLS-based and K. Tiruveedhula, "YANG Data Model for MPLS-based
L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress),
skipping to change at page 24, line 41 skipping to change at page 24, line 41
[I-D.ietf-bess-l3vpn-yang] [I-D.ietf-bess-l3vpn-yang]
Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S.,
Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model
for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work
in progress), October 2018. in progress), October 2018.
[I-D.ietf-bess-mvpn-yang] [I-D.ietf-bess-mvpn-yang]
Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and
M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP
IP VPNs", draft-ietf-bess-mvpn-yang-02 (work in progress), IP VPNs", draft-ietf-bess-mvpn-yang-04 (work in progress),
December 2019. June 2020.
[I-D.ietf-bfd-yang] [I-D.ietf-bfd-yang]
Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S.,
and G. Mirsky, "YANG Data Model for Bidirectional and G. Mirsky, "YANG Data Model for Bidirectional
Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work
in progress), August 2018. in progress), August 2018.
[I-D.ietf-i2rs-yang-l2-network-topology] [I-D.ietf-i2rs-yang-l2-network-topology]
Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A
YANG Data Model for Layer-2 Network Topologies", draft- YANG Data Model for Layer 2 Network Topologies", draft-
ietf-i2rs-yang-l2-network-topology-13 (work in progress), ietf-i2rs-yang-l2-network-topology-17 (work in progress),
March 2020. August 2020.
[I-D.ietf-idr-bgp-model] [I-D.ietf-idr-bgp-model]
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
YANG Model for Service Provider Networks", draft-ietf-idr- YANG Model for Service Provider Networks", draft-ietf-idr-
bgp-model-08 (work in progress), February 2020. bgp-model-09 (work in progress), June 2020.
[I-D.ietf-ippm-capacity-metric-method] [I-D.ietf-ippm-capacity-metric-method]
Morton, A., Geib, R., and L. Ciavattone, "Metrics and Morton, A., Geib, R., and L. Ciavattone, "Metrics and
Methods for IP Capacity", draft-ietf-ippm-capacity-metric- Methods for IP Capacity", draft-ietf-ippm-capacity-metric-
method-01 (work in progress), March 2020. method-03 (work in progress), August 2020.
[I-D.ietf-ippm-stamp-yang] [I-D.ietf-ippm-stamp-yang]
Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active
Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- Measurement Protocol (STAMP) Data Model", draft-ietf-ippm-
stamp-yang-05 (work in progress), October 2019. stamp-yang-05 (work in progress), October 2019.
[I-D.ietf-ippm-twamp-yang] [I-D.ietf-ippm-twamp-yang]
Civil, R., Morton, A., Rahman, R., Jethanandani, M., and Civil, R., Morton, A., Rahman, R., Jethanandani, M., and
K. Pentikousis, "Two-Way Active Measurement Protocol K. Pentikousis, "Two-Way Active Measurement Protocol
(TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work
in progress), July 2018. in progress), July 2018.
[I-D.ietf-mpls-base-yang] [I-D.ietf-mpls-base-yang]
Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A
YANG Data Model for MPLS Base", draft-ietf-mpls-base- YANG Data Model for MPLS Base", draft-ietf-mpls-base-
yang-14 (work in progress), March 2020. yang-15 (work in progress), August 2020.
[I-D.ietf-netmod-module-tags]
Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module
Tags", draft-ietf-netmod-module-tags-10 (work in
progress), February 2020.
[I-D.ietf-opsawg-l2nm]
barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil,
L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft-
ietf-opsawg-l2nm-00 (work in progress), July 2020.
[I-D.ietf-opsawg-l3sm-l3nm] [I-D.ietf-opsawg-l3sm-l3nm]
Barguil, S., Dios, O., Boucadair, M., Munoz, L., and A. barguil, s., Dios, O., Boucadair, M., Munoz, L., and A.
Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf-
opsawg-l3sm-l3nm-03 (work in progress), April 2020. opsawg-l3sm-l3nm-03 (work in progress), April 2020.
[I-D.ietf-pim-igmp-mld-snooping-yang] [I-D.ietf-pim-igmp-mld-snooping-yang]
Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter,
"A Yang Data Model for IGMP and MLD Snooping", draft-ietf- "A Yang Data Model for IGMP and MLD Snooping", draft-ietf-
pim-igmp-mld-snooping-yang-12 (work in progress), May pim-igmp-mld-snooping-yang-18 (work in progress), August
2020. 2020.
[I-D.ietf-pim-yang] [I-D.ietf-pim-yang]
Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
Y., and f. hu, "A YANG Data Model for Protocol Independent Y., and f. hu, "A YANG Data Model for Protocol Independent
Multicast (PIM)", draft-ietf-pim-yang-17 (work in Multicast (PIM)", draft-ietf-pim-yang-17 (work in
progress), May 2018. progress), May 2018.
[I-D.ietf-rtgwg-device-model]
Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
"Network Device YANG Logical Organization", draft-ietf-
rtgwg-device-model-02 (work in progress), March 2017.
[I-D.ietf-rtgwg-policy-model] [I-D.ietf-rtgwg-policy-model]
Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data
Model for Routing Policy Management", draft-ietf-rtgwg- Model for Routing Policy Management", draft-ietf-rtgwg-
policy-model-15 (work in progress), June 2020. policy-model-21 (work in progress), September 2020.
[I-D.ietf-rtgwg-qos-model] [I-D.ietf-rtgwg-qos-model]
Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., Choudhary, A., Jethanandani, M., Strahle, N., Aries, E.,
and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos-
model-01 (work in progress), April 2020. model-02 (work in progress), July 2020.
[I-D.ietf-spring-sr-yang] [I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.
Tantsura, "YANG Data Model for Segment Routing", draft- Tantsura, "YANG Data Model for Segment Routing", draft-
ietf-spring-sr-yang-15 (work in progress), January 2020. ietf-spring-sr-yang-22 (work in progress), August 2020.
[I-D.ietf-supa-generic-policy-data-model]
Halpern, J. and J. Strassner, "Generic Policy Data Model
for Simplified Use of Policy Abstractions (SUPA)", draft-
ietf-supa-generic-policy-data-model-04 (work in progress),
June 2017.
[I-D.ietf-teas-actn-pm-telemetry-autonomics] [I-D.ietf-teas-actn-pm-telemetry-autonomics]
Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D.,
and D. Ceccarelli, "YANG models for VN/TE Performance and D. Ceccarelli, "YANG models for VN/TE Performance
Monitoring Telemetry and Scaling Intent Autonomics", Monitoring Telemetry and Scaling Intent Autonomics",
draft-ietf-teas-actn-pm-telemetry-autonomics-02 (work in draft-ietf-teas-actn-pm-telemetry-autonomics-03 (work in
progress), March 2020. progress), July 2020.
[I-D.ietf-teas-actn-vn-yang] [I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
Yoon, "A Yang Data Model for VN Operation", draft-ietf- Yoon, "A YANG Data Model for VN Operation", draft-ietf-
teas-actn-vn-yang-08 (work in progress), March 2020. teas-actn-vn-yang-09 (work in progress), July 2020.
[I-D.ietf-teas-yang-path-computation] [I-D.ietf-teas-yang-path-computation]
Busi, I., Belotti, S., Lopezalvarez, V., Sharma, A., and Busi, I., Belotti, S., Lopezalvarez, V., Sharma, A., and
Y. Shi, "Yang model for requesting Path Computation", Y. Shi, "Yang model for requesting Path Computation",
draft-ietf-teas-yang-path-computation-09 (work in draft-ietf-teas-yang-path-computation-10 (work in
progress), June 2020. progress), July 2020.
[I-D.ietf-teas-yang-rsvp-te] [I-D.ietf-teas-yang-rsvp-te]
Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I.,
and H. Shah, "A YANG Data Model for RSVP-TE Protocol", and H. Shah, "A YANG Data Model for RSVP-TE Protocol",
draft-ietf-teas-yang-rsvp-te-08 (work in progress), March draft-ietf-teas-yang-rsvp-te-08 (work in progress), March
2020. 2020.
[I-D.ietf-teas-yang-te] [I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"A YANG Data Model for Traffic Engineering Tunnels and "A YANG Data Model for Traffic Engineering Tunnels, Label
Interfaces", draft-ietf-teas-yang-te-23 (work in Switched Paths and Interfaces", draft-ietf-teas-yang-te-25
progress), March 2020. (work in progress), July 2020.
[I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), June 2019.
[I-D.ietf-trill-yang-oam] [I-D.ietf-trill-yang-oam]
Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L.,
and H. Weiguo, "YANG Data Model for TRILL Operations, and H. Weiguo, "YANG Data Model for TRILL Operations,
Administration, and Maintenance (OAM)", draft-ietf-trill- Administration, and Maintenance (OAM)", draft-ietf-trill-
yang-oam-05 (work in progress), March 2017. yang-oam-05 (work in progress), March 2017.
[I-D.ogondio-opsawg-uni-topology] [I-D.ogondio-opsawg-uni-topology]
Dios, O., Barguil, S., WU, Q., and M. Boucadair, "A YANG Dios, O., barguil, s., WU, Q., and M. Boucadair, "A YANG
Model for User-Network Interface (UNI) Topologies", draft- Model for User-Network Interface (UNI) Topologies", draft-
ogondio-opsawg-uni-topology-01 (work in progress), April ogondio-opsawg-uni-topology-01 (work in progress), April
2020. 2020.
[I-D.www-bess-yang-vpn-service-pm] [I-D.www-bess-yang-vpn-service-pm]
WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., and H. WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., and H.
Xu, "A YANG Model for Network and VPN Service Performance Xu, "A YANG Model for Network and VPN Service Performance
Monitoring", draft-www-bess-yang-vpn-service-pm-06 (work Monitoring", draft-www-bess-yang-vpn-service-pm-06 (work
in progress), April 2020. in progress), April 2020.
[I-D.wwx-netmod-event-yang] [I-D.wwx-netmod-event-yang]
Birkholz, H., WU, Q., Bryskin, I., Liu, X., and B. Claise, Bierman, A., WU, Q., Bryskin, I., Birkholz, H., Liu, X.,
"A YANG Data model for ECA Policy Management", draft-wwx- and B. Claise, "A YANG Data model for ECA Policy
netmod-event-yang-07 (work in progress), May 2020. Management", draft-wwx-netmod-event-yang-09 (work in
progress), July 2020.
[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, DOI 10.17487/RFC4664, September 2006,
<https://www.rfc-editor.org/info/rfc4664>. <https://www.rfc-editor.org/info/rfc4664>.
skipping to change at page 28, line 43 skipping to change at page 28, line 38
[RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for
Multimedia INTerconnect (SPEERMINT) Architecture", Multimedia INTerconnect (SPEERMINT) Architecture",
RFC 6406, DOI 10.17487/RFC6406, November 2011, RFC 6406, DOI 10.17487/RFC6406, November 2011,
<https://www.rfc-editor.org/info/rfc6406>. <https://www.rfc-editor.org/info/rfc6406>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>. <https://www.rfc-editor.org/info/rfc7149>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014,
<https://www.rfc-editor.org/info/rfc7224>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration, Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276, and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>. <https://www.rfc-editor.org/info/rfc7276>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297, Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014, DOI 10.17487/RFC7297, July 2014,
<https://www.rfc-editor.org/info/rfc7297>. <https://www.rfc-editor.org/info/rfc7297>.
skipping to change at page 29, line 43 skipping to change at page 29, line 43
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299, "YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018, DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>. <https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus,
M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based
Management Framework for the Simplified Use of Policy
Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328,
March 2018, <https://www.rfc-editor.org/info/rfc8328>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X.,
Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
March 2018, <https://www.rfc-editor.org/info/rfc8346>. March 2018, <https://www.rfc-editor.org/info/rfc8346>.
skipping to change at page 32, line 5 skipping to change at page 31, line 44
[RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for [RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for
IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676,
DOI 10.17487/RFC8676, November 2019, DOI 10.17487/RFC8676, November 2019,
<https://www.rfc-editor.org/info/rfc8676>. <https://www.rfc-editor.org/info/rfc8676>.
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Data Denial-of-Service Open Threat Signaling (DOTS) Data
Channel Specification", RFC 8783, DOI 10.17487/RFC8783, Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
May 2020, <https://www.rfc-editor.org/info/rfc8783>. May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
Appendix A. Layered YANG Modules Examples Overview Appendix A. Layered YANG Modules Examples Overview
This appendix lists a set of data models that can be used for the This appendix lists a set of YANG data models that can be used for
delivery of connectivity services. These models can be classified as the delivery of connectivity services. These models can be
Service, Network, or Device Models. classified as Service, Network, or Device Models.
It is not the intent of this appendix to provide an inventory of It is not the intent of this appendix to provide an inventory of
tools and mechanisms used in specific network and service management tools and mechanisms used in specific network and service management
domains; such inventory can be found in documents such as [RFC7276]. domains; such inventory can be found in documents such as [RFC7276].
The reader may refer to the YANG Catalog
(<https://www.yangcatalog.org>) or the public Github YANG repository
(<https://github.com/YangModels/yang>) to query existing YANG models.
The YANG Catalog includes some metadata to indicate the module type
('module-classification') [I-D.clacla-netmod-model-catalog]. Note
that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to
associate tags with YANG modules in order to help classifying the
modules.
A.1. Service Models: Definition and Samples A.1. Service Models: Definition and Samples
As described in [RFC8309], the service is "some form of connectivity As described in [RFC8309], the service is "some form of connectivity
between customer sites and the Internet and/or between customer sites between customer sites and the Internet and/or between customer sites
across the Network Operator's network and across the Internet". More across the Network Operator's network and across the Internet". More
concretely, an IP connectivity service can be defined as the IP concretely, an IP connectivity service can be defined as the IP
transfer capability characterized by a (Source Nets, Destination transfer capability characterized by a (Source Nets, Destination
Nets, Guarantees, Scope) tuple where "Source Nets" is a group of Nets, Guarantees, Scope) tuple where "Source Nets" is a group of
unicast IP addresses, "Destination Nets" is a group of IP unicast unicast IP addresses, "Destination Nets" is a group of IP unicast
and/or multicast addresses, and "Guarantees" reflects the guarantees and/or multicast addresses, and "Guarantees" reflects the guarantees
skipping to change at page 32, line 44 skipping to change at page 33, line 7
o The L2SM model [RFC8466] defines the L2VPN service ordered by a o The L2SM model [RFC8466] defines the L2VPN service ordered by a
customer from a Network Operator. customer from a Network Operator.
o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang] o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang]
provides a YANG data model applicable to any mode of VN operation. provides a YANG data model applicable to any mode of VN operation.
L2SM and L3SM are customer service models as per [RFC8309]. L2SM and L3SM are customer service models as per [RFC8309].
A.2. Network Models: Samples A.2. Network Models: Samples
L2NM [I-D.barguil-opsawg-l2sm-l2nm] and L3NM L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are
[I-D.ietf-opsawg-l3sm-l3nm] are examples of YANG Network Models. examples of YANG Network Models.
Figure 9 depicts a set of additional Network Models such as topology Figure 9 depicts a set of additional Network Models such as topology
and tunnel models: and tunnel models:
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Topology YANG modules | Tunnel YANG modules | | Topology YANG modules | Tunnel YANG modules |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| +------------+ | | | +------------+ | |
| |Network Topo| | +------+ +-----------+ | | |Network Topo| | +------+ +-----------+ |
| | Model | | |Other | | TE Tunnel | | | | Model | | |Other | | TE Tunnel | |
skipping to change at page 33, line 38 skipping to change at page 33, line 46
Svc: Service Svc: Service
Figure 9: Sample Resource Facing Network Models Figure 9: Sample Resource Facing Network Models
Examples of topology YANG modules are listed below: Examples of topology YANG modules are listed below:
o Network Topology Models: [RFC8345] defines a base model for o Network Topology Models: [RFC8345] defines a base model for
network topology and inventories. Network topology data include network topology and inventories. Network topology data include
link resource, node resource, and terminate-point resources. link resource, node resource, and terminate-point resources.
o TE Topology Models: [I-D.ietf-teas-yang-te-topo] defines a data o TE Topology Models: [RFC8795] defines a YANG data model for
model for representing and manipulating TE topologies. representing and manipulating TE topologies.
This module is extended from network topology model defined in This module is extended from network topology model defined in
[RFC8345] with TE topologies specifics. This model contains [RFC8345] with TE topologies specifics. This model contains
technology-agnostic TE Topology building blocks that can be technology-agnostic TE Topology building blocks that can be
augmented and used by other technology-specific TE topology augmented and used by other technology-specific TE topology
models. models.
o Layer 3 Topology Models: o Layer 3 Topology Models:
[RFC8346] defines a data model for representing and manipulating [RFC8346] defines a YANG data model for representing and
Layer 3 topologies. This model is extended from the network manipulating Layer 3 topologies. This model is extended from the
topology model defined in [RFC8345] with Layer 3 topologies network topology model defined in [RFC8345] with Layer 3
specifics. topologies specifics.
o Layer 2 Topology Models: o Layer 2 Topology Models:
[I-D.ietf-i2rs-yang-l2-network-topology] defines a data model for [I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model
representing and manipulating Layer 2 topologies. This model is for representing and manipulating Layer 2 topologies. This model
extended from the network topology model defined in [RFC8345] with is extended from the network topology model defined in [RFC8345]
Layer 2 topologies specifics. with Layer 2 topologies specifics.
Examples of tunnel YANG modules are provided below: Examples of tunnel YANG modules are provided below:
o Tunnel identities to ease manipulating extensions to specific o Tunnel identities: [RFC8675] defines a collection of YANG
tunnels [RFC8675]. identities used as interface types for tunnel interfaces.
o TE Tunnel Model: o TE Tunnel Model:
[I-D.ietf-teas-yang-te] defines a YANG module for the [I-D.ietf-teas-yang-te] defines a YANG module for the
configuration and management of TE interfaces, tunnels, and LSPs. configuration and management of TE interfaces, tunnels, and LSPs.
o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model: o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model:
[I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE
model(s) and defines a YANG module for SR-TE specific data. model(s) and defines a YANG module for SR-TE specific data.
skipping to change at page 35, line 14 skipping to change at page 35, line 25
protocols. [RFC8531] defines a base YANG module for connection protocols. [RFC8531] defines a base YANG module for connection
oriented OAM protocols. These three models are intended to oriented OAM protocols. These three models are intended to
provide consistent reporting, configuration, and representation provide consistent reporting, configuration, and representation
for connection-less OAM and Connection oriented OAM separately. for connection-less OAM and Connection oriented OAM separately.
Alarm monitoring is a fundamental part of monitoring the network. Alarm monitoring is a fundamental part of monitoring the network.
Raw alarms from devices do not always tell the status of the Raw alarms from devices do not always tell the status of the
network services or necessarily point to the root cause. network services or necessarily point to the root cause.
[RFC8632] defines a YANG module for alarm management. [RFC8632] defines a YANG module for alarm management.
o Generic Policy Model:
The Simplified Use of Policy Abstractions (SUPA) policy-based
management framework [RFC8328] defines base YANG modules
[I-D.ietf-supa-generic-policy-data-model] to encode policy. These
models point to other device-, technology-, and service-specific
YANG modules. Policy rules within an operator's environment can
be used to express high-level, possibly network-wide, policies to
a network management function (within a controller, an
orchestrator, or a network element). The network management
function can then control the configuration and/or monitoring of
network elements and services. This document describes the SUPA
basic framework, its elements, and interfaces.
A.3. Device Models: Samples A.3. Device Models: Samples
Network Element models (Figure 10) are used to describe how a service Network Element models (Figure 10) are used to describe how a service
can be implemented by activating and tweaking a set of functions can be implemented by activating and tweaking a set of functions
(enabled in one or multiple devices, or hosted in cloud (enabled in one or multiple devices, or hosted in cloud
infrastructures) that are involved in the service delivery. infrastructures) that are involved in the service delivery.
Figure 10 uses IETF-defined models as an example. Figure 10 uses IETF-defined data models as an example.
+------------------------+ +------------------------+
+-+ Device Model | +-+ Device Model |
| +------------------------+ | +------------------------+
| +------------------------+ | +------------------------+
+---------------+ | | Logical Network | +---------------+ | | Logical Network |
| | +-+ Element Model | | | +-+ Element Model |
| Architecture | | +------------------------+ | Architecture | | +------------------------+
| | | +------------------------+ | | | +------------------------+
+-------+-------+ +-+ Network Instance Model | +-------+-------+ +-+ Network Instance Model |
skipping to change at page 37, line 7 skipping to change at page 37, line 7
+-+ISIS-SR| +-+ISIS-SR|
| +-------+ | +-------+
| +-------+ | +-------+
+-+OSPF-SR| +-+OSPF-SR|
+-------+ +-------+
Figure 10: Network Element Modules Overview Figure 10: Network Element Modules Overview
A.3.1. Model Composition A.3.1. Model Composition
o Device Model
[I-D.ietf-rtgwg-device-model] presents an approach for organizing
YANG modules in a comprehensive logical structure that may be used
to configure and operate network devices. The structure is itself
represented as an example YANG module, with all of the related
component models logically organized in a way that is
operationally intuitive, but this model is not expected to be
implemented.
o Logical Network Element Model o Logical Network Element Model
[RFC8530] defines a logical network element module which can be [RFC8530] defines a logical network element module which can be
used to manage the logical resource partitioning that may be used to manage the logical resource partitioning that may be
present on a network device. Examples of common industry terms present on a network device. Examples of common industry terms
for logical resource partitioning are Logical Systems or Logical for logical resource partitioning are Logical Systems or Logical
Routers. Routers.
o Network Instance Model o Network Instance Model
skipping to change at page 37, line 44 skipping to change at page 37, line 34
Modularity and extensibility were among the leading design principles Modularity and extensibility were among the leading design principles
of the YANG data modeling language. As a result, the same YANG of the YANG data modeling language. As a result, the same YANG
module can be combined with various sets of other modules and thus module can be combined with various sets of other modules and thus
form a data model that is tailored to meet the requirements of a form a data model that is tailored to meet the requirements of a
specific use case. [RFC8528] defines a mechanism, denoted schema specific use case. [RFC8528] defines a mechanism, denoted schema
mount, that allows for mounting one data model consisting of any mount, that allows for mounting one data model consisting of any
number of YANG modules at a specified location of another (parent) number of YANG modules at a specified location of another (parent)
schema. schema.
That capability does not cover design time.
A.3.2. Device Models: Samples A.3.2. Device Models: Samples
The following provides an overview of some Device Models that can be The following provides an overview of some Device Models that can be
used within a network. This list is not comprehensive. used within a network. This list is not comprehensive.
Interface: [RFC7224] defines a YANG module for interface type
definitions.
BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for
configuring and managing BGP, including protocol, policy, configuring and managing BGP, including protocol, policy,
and operational aspects based on data center, carrier, and and operational aspects based on data center, carrier, and
content provider operational requirements. content provider operational requirements.
MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS
which serves as a base framework for configuring and which serves as a base framework for configuring and
managing an MPLS switching subsystem. It is expected that managing an MPLS switching subsystem. It is expected that
other MPLS technology YANG modules (e.g., MPLS LSP Static, other MPLS technology YANG modules (e.g., MPLS LSP Static,
LDP, or RSVP-TE models) will augment the MPLS base YANG LDP, or RSVP-TE models) will augment the MPLS base YANG
module. module.
QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of
Differentiated Services for configuration and operations. Differentiated Services for configuration and operations.
ACL: Access Control List (ACL) is one of the basic elements ACL: Access Control List (ACL) is one of the basic elements
used to configure device forwarding behavior. It is used used to configure device forwarding behavior. It is used
in many networking technologies such as Policy Based in many networking technologies such as Policy Based
Routing, Firewalls, etc. [RFC8519] describes a data model Routing, Firewalls, etc. [RFC8519] describes a YANG data
of ACL basic building blocks. model of ACL basic building blocks.
NAT: For the sake of network automation and the need for NAT: For the sake of network automation and the need for
programming Network Address Translation (NAT) function in programming Network Address Translation (NAT) function in
particular, a data model for configuring and managing the particular, a YANG data model for configuring and managing
NAT is essential. the NAT is essential.
[RFC8512] defines a YANG module for the NAT function [RFC8512] defines a YANG module for the NAT function
covering a variety of NAT flavors such as Network Address covering a variety of NAT flavors such as Network Address
Translation from IPv4 to IPv4 (NAT44), Network Address and Translation from IPv4 to IPv4 (NAT44), Network Address and
Protocol Translation from IPv6 Clients to IPv4 Servers Protocol Translation from IPv6 Clients to IPv4 Servers
(NAT64), customer-side translator (CLAT), Stateless IP/ (NAT64), customer-side translator (CLAT), Stateless IP/
ICMP Translation (SIIT), Explicit Address Mappings (EAM) ICMP Translation (SIIT), Explicit Address Mappings (EAM)
for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6),
and Destination NAT. and Destination NAT.
skipping to change at page 39, line 48 skipping to change at page 39, line 39
BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a
network protocol which is used for liveness detection of network protocol which is used for liveness detection of
arbitrary paths between systems. [I-D.ietf-bfd-yang] arbitrary paths between systems. [I-D.ietf-bfd-yang]
defines a YANG module that can be used to configure and defines a YANG module that can be used to configure and
manage BFD. manage BFD.
SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment
routing configuration and operation. routing configuration and operation.
Core Routing: [RFC8349] defines the core routing data model, which Core Routing: [RFC8349] defines the core routing YANG data model,
is intended as a basis for future data model development which is intended as a basis for future data model
covering more-sophisticated routing systems. It is development covering more-sophisticated routing systems.
expected that other Routing technology YANG modules (e.g., It is expected that other Routing technology YANG modules
VRRP, RIP, ISIS, OSPF models) will augment the Core (e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core
Routing base YANG module. Routing base YANG module.
PM: [I-D.ietf-ippm-twamp-yang] defines a data model for client PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for
and server implementations of the Two-Way Active client and server implementations of the Two-Way Active
Measurement Protocol (TWAMP). Measurement Protocol (TWAMP).
[I-D.ietf-ippm-stamp-yang] defines the data model for [I-D.ietf-ippm-stamp-yang] defines the data model for
implementations of Session-Sender and Session-Reflector implementations of Session-Sender and Session-Reflector
for Simple Two-way Active Measurement Protocol (STAMP) for Simple Two-way Active Measurement Protocol (STAMP)
mode using YANG. mode using YANG.
[RFC8194] defines a data model for Large-Scale Measurement [RFC8194] defines a YANG data model for Large-Scale
Platforms (LMAPs). Measurement Platforms (LMAPs).
Authors' Addresses Authors' Addresses
Qin Wu (editor) Qin Wu (editor)
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
 End of changes. 55 change blocks. 
127 lines changed or deleted 139 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/