draft-ietf-opsawg-model-automation-framework-10.txt | rfc8969.txt | |||
---|---|---|---|---|
OPSAWG Q. Wu, Ed. | Internet Engineering Task Force (IETF) Q. Wu, Ed. | |||
Internet-Draft Huawei | Request for Comments: 8969 Huawei | |||
Intended status: Informational M. Boucadair, Ed. | Category: Informational M. Boucadair, Ed. | |||
Expires: April 28, 2021 Orange | ISSN: 2070-1721 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 | |||
October 25, 2020 | January 2021 | |||
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-10 | ||||
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 (e.g., service | |||
instantiation, provisioning, optimization, monitoring, diagnostic, | instantiation, service provisioning, service optimization, service | |||
and assurance. Data models are also instrumental in the automation | monitoring, service diagnosing, and service assurance). Data models | |||
of network management, and they can provide closed-loop control for | are also instrumental in the automation of network management, and | |||
adaptive and deterministic service creation, delivery, and | they can provide closed-loop control for adaptive and deterministic | |||
maintenance. | service creation, delivery, and maintenance. | |||
This document describes a framework for service and network | This document describes a framework for service and network | |||
management automation that takes advantage of YANG modeling | management automation that takes advantage of YANG modeling | |||
technologies. This framework is drawn from a network operator | technologies. This framework is drawn from a network operator | |||
perspective irrespective of the origin of a data model; it can thus | perspective irrespective of the origin of a data model; thus, it can | |||
accommodate YANG modules that are developed outside the IETF. | accommodate YANG modules that are developed outside the IETF. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are candidates for any level of Internet | ||||
Standard; see Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on April 28, 2021. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc8969. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2021 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 5 | 2. Terminology and Abbreviations | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1. Terminology | |||
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2. Abbreviations | |||
3. Architectural Concepts and Goals . . . . . . . . . . . . . . 7 | 3. Architectural Concepts and Goals | |||
3.1. Data Models: Layering and Representation . . . . . . . . 7 | 3.1. Data Models: Layering and Representation | |||
3.2. Automation of Service Delivery Procedures . . . . . . . . 12 | 3.2. Automation of Service Delivery Procedures | |||
3.3. Service Fulfillment Automation . . . . . . . . . . . . . 13 | 3.3. Service Fulfillment Automation | |||
3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 13 | 3.4. YANG Module Integration | |||
4. Functional Blocks and Interactions . . . . . . . . . . . . . 14 | 4. Functional Blocks and Interactions | |||
4.1. Service Lifecycle Management Procedure . . . . . . . . . 15 | 4.1. Service Life-Cycle Management Procedure | |||
4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 15 | 4.1.1. Service Exposure | |||
4.1.2. Service Creation/Modification . . . . . . . . . . . . 15 | 4.1.2. Service Creation/Modification | |||
4.1.3. Service Assurance . . . . . . . . . . . . . . . . . . 16 | 4.1.3. Service Assurance | |||
4.1.4. Service Optimization . . . . . . . . . . . . . . . . 16 | 4.1.4. Service Optimization | |||
4.1.5. Service Diagnosis . . . . . . . . . . . . . . . . . . 16 | 4.1.5. Service Diagnosis | |||
4.1.6. Service Decommission . . . . . . . . . . . . . . . . 17 | 4.1.6. Service Decommission | |||
4.2. Service Fullfillment Management Procedure . . . . . . . . 17 | 4.2. Service Fulfillment Management Procedure | |||
4.2.1. Intended Configuration Provision . . . . . . . . . . 17 | 4.2.1. Intended Configuration Provision | |||
4.2.2. Configuration Validation . . . . . . . . . . . . . . 18 | 4.2.2. Configuration Validation | |||
4.2.3. Performance Monitoring . . . . . . . . . . . . . . . 18 | 4.2.3. Performance Monitoring | |||
4.2.4. Fault Diagnostic . . . . . . . . . . . . . . . . . . 19 | 4.2.4. Fault Diagnostic | |||
4.3. Multi-Layer/Multi-Domain Service Mapping . . . . . . . . 19 | 4.3. Multi-layer/Multi-domain Service Mapping | |||
4.4. Service Decomposition . . . . . . . . . . . . . . . . . . 19 | 4.4. Service Decomposition | |||
5. YANG Data Model Integration Examples . . . . . . . . . . . . 20 | 5. YANG Data Model Integration Examples | |||
5.1. L2VPN/L3VPN Service Delivery . . . . . . . . . . . . . . 20 | 5.1. L2VPN/L3VPN Service Delivery | |||
5.2. VN Lifecycle Management . . . . . . . . . . . . . . . . . 22 | 5.2. VN Life-Cycle Management | |||
5.3. Event-based Telemetry in the Device Self Management . . . 23 | 5.3. Event-Based Telemetry in the Device Self Management | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | 6. Security Considerations | |||
6.1. Service Level . . . . . . . . . . . . . . . . . . . . . . 25 | 6.1. Service Level | |||
6.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 26 | 6.2. Network Level | |||
6.3. Device Level . . . . . . . . . . . . . . . . . . . . . . 26 | 6.3. Device Level | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | 7. IANA Considerations | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 | 8. References | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 | 8.1. Normative References | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 8.2. Informative References | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 27 | Appendix A. Layered YANG Module Examples Overview | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 28 | A.1. Service Models: Definition and Samples | |||
Appendix A. Layered YANG Modules Examples Overview . . . . . . . 37 | A.2. Schema Mount | |||
A.1. Service Models: Definition and Samples . . . . . . . . . 37 | A.3. Network Models: Samples | |||
A.2. Schema Mount . . . . . . . . . . . . . . . . . . . . . . 38 | A.4. Device Models: Samples | |||
A.3. Network Models: Samples . . . . . . . . . . . . . . . . . 38 | A.4.1. Model Composition | |||
A.4. Device Models: Samples . . . . . . . . . . . . . . . . . 41 | A.4.2. Device Management | |||
A.4.1. Model Composition . . . . . . . . . . . . . . . . . . 43 | A.4.3. Interface Management | |||
A.4.2. Device Management . . . . . . . . . . . . . . . . . . 43 | A.4.4. Some Device Model Examples | |||
A.4.3. Interface Management . . . . . . . . . . . . . . . . 43 | Acknowledgements | |||
A.4.4. Some Device Model Examples . . . . . . . . . . . . . 43 | Contributors | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | Authors' Addresses | |||
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 requirements and orders | procedures, from the processing of customer requirements and orders | |||
to service delivery and operation, typically assume the manipulation | to service delivery and operation, typically assume the manipulation | |||
of data sequentially into multiple Operations Support System (OSS) or | of data sequentially into multiple Operations Support System (OSS) or | |||
Business Support System (BSS) applications that may be managed by | Business Support System (BSS) applications that may be managed by | |||
different departments within the service provider's organization | different departments within the service provider's organization | |||
(e.g., billing factory, design factory, network operation center). | (e.g., billing factory, design factory, network operation center). | |||
Many of these applications have been developed in-house over the | Many of these applications have been developed in house over the | |||
years and operate in a silo mode: | years and operate in a silo mode. As a result: | |||
o The lack of standard data input/output (i.e., data model) raises | * The lack of standard data input/output (i.e., data model) raises | |||
many challenges in system integration and often results in manual | many challenges in system integration and often results in manual | |||
configuration tasks. | configuration tasks. | |||
o Service fulfillment systems might have a limited visibility on the | * Service fulfillment systems might have a limited visibility on the | |||
network state and therefore have slow response to network changes. | network state and may therefore have a slow response to network | |||
changes. | ||||
Software Defined Networking (SDN) becomes crucial to address these | Software-Defined Networking (SDN) becomes crucial to address these | |||
challenges. SDN techniques are meant to automate the overall service | challenges. SDN techniques are meant to automate the overall service | |||
delivery procedures and typically rely upon standard data models. | delivery procedures and typically rely upon standard data models. | |||
These models are used to not only reflect service providers' savoir- | These models are used not only to reflect service providers' savoir | |||
faire, but also to dynamically instantiate and enforce a set of | faire, but also to dynamically instantiate and enforce a set of | |||
service-inferred policies that best accommodate what has been defined | service-inferred policies that best accommodate what has been defined | |||
and possibly negotiated with the customer. [RFC7149] provides a | and possibly negotiated with the customer. [RFC7149] provides a | |||
first tentative attempt to rationalize that service provider's view | first tentative attempt to rationalize that service provider's view | |||
on the SDN space by identifying concrete technical domains that need | on the SDN space by identifying concrete technical domains that need | |||
to be considered and for which solutions can be provided: | to be considered and for which solutions can be provided. These | |||
include: | ||||
o Techniques for the dynamic discovery of topology, devices, and | * Techniques for the dynamic discovery of topology, devices, and | |||
capabilities, along with relevant information and data models that | capabilities, along with relevant information and data models that | |||
are meant to precisely document such topology, devices, and their | are meant to precisely document such topology, devices, and their | |||
capabilities. | capabilities. | |||
o Techniques for exposing network services [RFC8309] and their | * Techniques for exposing network services [RFC8309] and their | |||
characteristics. | characteristics. | |||
o Techniques used by service-derived dynamic resource allocation and | * Techniques used by service-derived dynamic resource allocation and | |||
policy enforcement schemes, so that networks can be programmed | policy enforcement schemes, so that networks can be programmed | |||
accordingly. | accordingly. | |||
o Dynamic feedback mechanisms that are meant to assess how | * Dynamic feedback mechanisms that are meant to assess how | |||
efficiently a given policy (or a set thereof) is enforced from a | efficiently a given policy (or a set thereof) is enforced from a | |||
service fulfillment and assurance perspectives. | service fulfillment and assurance perspective. | |||
Models are key for each of the aforementioned four technical items. | Models are key for each of the four technical items above. Service | |||
Service and network management automation is an important step to | and network management automation is an important step to improve the | |||
improve the agility of network operations. Models are also important | agility of network operations. Models are also important to ease | |||
to ease integrating multi-vendor solutions. | integrating multi-vendor solutions. | |||
YANG [RFC7950] module developers have taken both top-down and bottom- | YANG module [RFC7950] 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 YANG data models including configuration and service models that | many YANG data models, including configuration and service models, | |||
have been specified or are being specified by the IETF. They cover | that have been specified or are being specified by the IETF. They | |||
many of the networking protocols and techniques. However, how these | cover many of the networking protocols and techniques. However, how | |||
models work together to configure a function, manage a set of devices | these models work together to configure a function, manage a set of | |||
involved in a service, or provide a service is something that is not | devices involved in a service, or provide a service is something that | |||
currently documented either within the IETF or other Standards | is not currently documented either within the IETF or other Standards | |||
Development Organizations (SDOs). | Development Organizations (SDOs). | |||
Many of the YANG modules listed in this document are used to exchange | Many of the YANG modules listed in this document are used to exchange | |||
data between NETCONF/RESTCONF clients and servers [RFC6241][RFC8040]. | data between NETCONF/RESTCONF clients and servers [RFC6241][RFC8040]. | |||
Nevertheless, YANG is a transport-independent data modeling language. | Nevertheless, YANG is a transport-independent data modeling language. | |||
It can thus be used independently of NETCONF/RESTONF. For example, | It can thus be used independently of NETCONF/RESTCONF. For example, | |||
YANG can be used to define abstract data structures [RFC8791] that | YANG can be used to define abstract data structures [RFC8791] that | |||
can be manipulated by other protocols (e.g., | can be manipulated by other protocols (e.g., [DOTS-DDOS]). | |||
[I-D.ietf-dots-rfc8782-bis]). | ||||
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 YANG data models at | YANG modeling technologies and investigates how YANG data models at | |||
different layers interact with each other (e.g., service mapping, | different layers interact with each other (e.g., Service Mapping, | |||
model composition) in the context of service delivery and fulfillment | model composition) in the context of service delivery and fulfillment | |||
(Section 4). Concretely, the following benefits can be provided: | (Section 4). Concretely, the following benefits can be provided: | |||
o Allow for vendor-agnostic interfaces to manage a service and the | * Vendor-agnostic interfaces managing a service and the underlying | |||
underlying network. | network are allowed. | |||
o Move from deployment schemes where vendor-specific network | * Movement from deployment schemes where vendor-specific network | |||
managers are required to a scheme where the entities that are | managers are required to a scheme where the entities that are | |||
responsible for orchestrating and controlling services and network | responsible for orchestrating and controlling services and network | |||
resources provided by multi-vendor devices are unified. | resources provided by multi-vendor devices are unified is allowed. | |||
o Ease data inheritance and reusability among the various | * Data inheritance and reusability among the various architecture | |||
architecture layers thus promoting a network-wise provisioning | layers thus promoting a network-wise provisioning instead of | |||
instead of device-specific configuration. | device-specific configuration is eased. | |||
o Dynamically feed a decision-making process (e.g., Controllers, | * Dynamically feeding a decision-making process (e.g., Controllers, | |||
Orchestrators) with notifications that will trigger appropriate | Orchestrators) with notifications that will trigger appropriate | |||
actions, allowing that decision-making process to continuously | actions, allowing that decision-making process to continuously | |||
adjust a network (and thus, the involved resources) to deliver the | adjust a network (and thus the involved resources) to deliver the | |||
service that conforms to the intended parameters (service | service that conforms to the intended parameters (service | |||
objectives). | objectives) is allowed. | |||
This framework is drawn from a network operator perspective | This framework is drawn from a network operator perspective | |||
irrespective of the origin of a data model; it can also accommodate | irrespective of the origin of a data model; it can also accommodate | |||
YANG modules that are developed outside the IETF. The document | YANG modules that are developed outside the IETF. The document | |||
covers service models that are used by an operator to expose its | covers service models that are used by an operator to expose its | |||
services and capture service requirements from the customers | services and capture service requirements from the customers | |||
(including other operators). Nevertheless, the document does not | (including other operators). Nevertheless, the document does not | |||
elaborate on the communication protocol(s) that makes use of these | elaborate on the communication protocol(s) that makes use of these | |||
service models in order to request and deliver a service. Such | service models in order to request and deliver a service. Such | |||
considerations are out of scope. | considerations are out of scope. | |||
The document identifies a list of use cases to exemplify the proposed | The document identifies a list of use cases to exemplify the proposed | |||
approach (Section 5), but it does not claim nor aim to be exhaustive. | approach (Section 5), but it does not claim nor aim to be exhaustive. | |||
Appendix A lists some examples to illustrate the layered YANG modules | Appendix A lists some examples to illustrate the layered YANG modules | |||
view. | view. | |||
2. Terminology and Acronyms | 2. Terminology and Abbreviations | |||
2.1. Terminology | 2.1. Terminology | |||
The following terms are defined in [RFC8309][RFC8199] and are not | The following terms are defined in [RFC8309] and [RFC8199] and are | |||
redefined here: | not redefined here: | |||
o Network Operator | * Network Operator | |||
o Customer | * Customer | |||
o Service | * Service | |||
o Data Model | * Data Model | |||
o Service Model | * Service Model | |||
o Network Element Module | * Network Element Model | |||
In addition, the document makes use of the following terms: | In addition, the document makes use of the following terms: | |||
Network Model: Describes a network level abstraction (or a subset of | Network Model: | |||
aspects of a network infrastructure), including devices and their | Describes a network-level abstraction (or a subset of aspects of a | |||
subsystems, and relevant protocols operating at the link and | network infrastructure), including devices and their subsystems, | |||
network layers across multiple devices. This model corresponds to | and relevant protocols operating at the link and network layers | |||
the network configuration model discussed in [RFC8309]. | across multiple devices. This model corresponds to the network | |||
configuration model discussed in [RFC8309]. | ||||
It can be used by a network operator to allocate resources (e.g., | It can be used by a network operator to allocate resources (e.g., | |||
tunnel resource, topology resource) for the service or schedule | tunnel resource, topology resource) for the service or schedule | |||
resources to meet the service requirements defined in a service | resources to meet the service requirements defined in a service | |||
model. | model. | |||
Network Domain: Refers to a network partitioning that is usually | Network Domain: | |||
followed by network operators to delimit parts of their network. | Refers to a network partitioning that is usually followed by | |||
"access network" and "core network" are examples of network | network operators to delimit parts of their network. "access | |||
domains. | network" and "core network" are examples of network domains. | |||
Device Model: Refers to the Network Element YANG data model | Device Model: | |||
described in [RFC8199] or the device configuration model discussed | Refers to the Network Element YANG data model described in | |||
in [RFC8309]. | [RFC8199] or the device configuration model discussed 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) | Pipe: | |||
Refers to a communication scope where only one-to-one (1:1) | ||||
communications are allowed. The scope can be identified between | communications are allowed. The scope can be identified between | |||
ingress and egress nodes, two service sites, etc. | ingress and egress nodes, two service sites, etc. | |||
Hose: Refers to a communication scope where one-to-many (1:N) | Hose: | |||
Refers to a communication scope where one-to-many (1:N) | ||||
communications are allowed (e.g., one site to multiple sites). | communications are allowed (e.g., one site to multiple sites). | |||
Funnel: Refers to a communication scope where many-to-one (N:1) | Funnel: | |||
Refers to a communication scope where many-to-one (N:1) | ||||
communications are allowed. | communications are allowed. | |||
2.2. Acronyms | 2.2. Abbreviations | |||
The following acronyms are used in the document: | The following abbreviations are used in the document: | |||
ACL Access Control List | ACL Access Control List | |||
AS Autonomous System | AS Autonomous System | |||
AP Access Point | AP Access Point | |||
CE Customer Edge | CE Customer Edge | |||
DBE Data Border Element | DBE Data Border Element | |||
E2E End-to-End | E2E End-to-End | |||
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 | |||
skipping to change at page 7, line 29 ¶ | skipping to change at line 316 ¶ | |||
L3NM L3VPN Network Model | L3NM L3VPN Network Model | |||
NAT Network Address Translation | NAT Network Address Translation | |||
OAM Operations, Administration, and Maintenance | OAM Operations, Administration, and Maintenance | |||
OWD One-Way Delay | OWD One-Way Delay | |||
PE Provider Edge | PE Provider Edge | |||
PM Performance Monitoring | PM Performance Monitoring | |||
QoS Quality of Service | QoS Quality of Service | |||
RD Route Distinguisher | RD Route Distinguisher | |||
RT Route Target | RT Route Target | |||
SBE Session Border Element | SBE Session Border Element | |||
SDN Software Defined Networking | SDN Software-Defined Networking | |||
SP Service Provider | SP Service Provider | |||
TE Traffic Engineering | TE Traffic Engineering | |||
VN Virtual Network | VN Virtual Network | |||
VPN Virtual Private Network | VPN Virtual Private Network | |||
VRF Virtual Routing and Forwarding | VRF Virtual Routing and Forwarding | |||
3. Architectural Concepts and Goals | 3. Architectural Concepts and Goals | |||
3.1. Data Models: Layering and Representation | 3.1. Data Models: Layering and Representation | |||
As described in Section 2 of [RFC8199], layering of modules allows | As described in Section 2 of [RFC8199], layering of modules allows | |||
for better reusability of lower-layer modules by higher-level modules | for better reusability of lower-layer modules by higher-level modules | |||
while limiting duplication of features across layers. | while limiting duplication of features across layers. | |||
Data models in the context of network management can be classified | Data models in the context of network management can be classified | |||
into service, network, and device models. Different service models | into service, network, and device models. Different service models | |||
may rely on the same set of network and/or device models. | may rely on the same set of network and/or device models. | |||
Service models traditionally follow a top-down approach and are | Service models traditionally follow a top-down approach and are | |||
mostly customer-facing YANG modules providing a common model | mostly customer-facing YANG modules providing a common model | |||
construct for higher level network services (e.g., Layer 3 Virtual | construct for higher-level network services (e.g., Layer 3 Virtual | |||
Private Network (L3VPN)). Such modules can be mapped to network | Private Network (L3VPN)). Such modules can be mapped to network | |||
technology-specific modules at lower layers (e.g., tunnel, routing, | technology-specific modules at lower layers (e.g., tunnel, routing, | |||
Quality of Service (QoS), security). For example, service models can | Quality of Service (QoS), security). For example, service models can | |||
be used to characterise the network service(s) to be ensured between | be used to characterize the network service(s) to be ensured between | |||
service nodes (ingress/egress) such as: | service nodes (ingress/egress) such as: | |||
o the communication scope (pipe, hose, funnel, ...), | * the communication scope (pipe, hose, funnel, etc.), | |||
o the directionality (inbound/outbound), | * the directionality (inbound/outbound), | |||
o the traffic performance guarantees expressed using metrics such as | * the traffic performance guarantees expressed using metrics such as | |||
One-Way Delay (OWD) [RFC7679] or One-Way Loss [RFC7680]; a summary | One-Way Delay (OWD) [RFC7679] or One-Way Loss [RFC7680]; a summary | |||
of performance metrics maintained by IANA can be found in [IPPM], | of performance metrics maintained by IANA can be found in [IPPM], | |||
o link capacity [RFC5136] [I-D.ietf-ippm-capacity-metric-method], | * link capacity [RFC5136] [METRIC-METHOD], | |||
o etc. | * etc. | |||
Figure 1 depicts the example of a VoIP service that relies upon | Figure 1 depicts the example of a Voice over IP (VoIP) service that | |||
connectivity services offered by a network operator. In this | relies upon connectivity services offered by a network operator. In | |||
example, the VoIP service is offered to the network operator's | this example, the VoIP service is offered to the network operator's | |||
customers by Service Provider (SP1). In order to provide global VoIP | customers by Service Provider 1 (SP1). In order to provide global | |||
reachability, SP1 service site interconnects with other Service | VoIP reachability, SP1 Service Site interconnects with other Service | |||
Providers service sites typically by interconnecting Session Border | Providers service sites typically by interconnecting Session Border | |||
Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406]. | Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406]. | |||
For other VoIP destinations, sessions are forwarded over the | For other VoIP destinations, sessions are forwarded over the | |||
Internet. These connectivity services can be captured in a YANG | Internet. These connectivity services can be captured in a YANG | |||
service model that reflects the service attributes that are shown in | service model that reflects the service attributes that are shown in | |||
Figure 2. This example follows the IP Connectivity Provisioning | Figure 2. This example follows the IP Connectivity Provisioning | |||
Profile template defined in [RFC7297]. | Profile template defined in [RFC7297]. | |||
In reference to Figure 2, "Full traffic performance guarantees class" | ||||
refers to a service class where all traffic performance metrics | ||||
included in the service model (OWD, loss, delay variation) are | ||||
guaranteed, while "Delay traffic performance guarantees class" refers | ||||
to a service class where only OWD is guaranteed. | ||||
,--,--,--. ,--,--,--. | ,--,--,--. ,--,--,--. | |||
,-' SP1 `-. ,-' SP2 `-. | ,-' SP1 `-. ,-' SP2 `-. | |||
( Service Site ) ( Service Site ) | ( Service Site ) ( Service Site ) | |||
`-. ,-' `-. ,-' | `-. ,-' `-. ,-' | |||
`--'--'--' `--'--'--' | `--'--'--' `--'--'--' | |||
x | o * * | | x | o * * | | |||
(2)x | o * * | | (2)x | o * * | | |||
,x-,--o-*-. (1) ,--,*-,--. | ,x-,--o-*-. (1) ,--,*-,--. | |||
,-' x o * * * * * * * * * `-. | ,-' x o * * * * * * * * * `-. | |||
( x o +----( Internet ) | ( x o +----( Internet ) | |||
User---(x x x o o o o o o o o o o o o o o o o o o | User---(x x x o o o o o o o o o o o o o o o o o o | |||
`-. ,-' `-. ,-' (3) | `-. ,-' `-. ,-' (3) | |||
`--'--'--' `--'--'--' | `--'--'--' `--'--'--' | |||
Network Operator | Network Operator | |||
**** (1) Inter-SP connectivity | **** (1) Inter-SP connectivity | |||
xxxx (2) Customer to SP connectivity | xxxx (2) Customer-to-SP connectivity | |||
oooo (3) SP to any destination connectivity | oooo (3) SP to any destination connectivity | |||
Figure 1: An Example of Service Connectivity Components | Figure 1: An Example of Service Connectivity Components | |||
In reference to Figure 2, "Full traffic performance guarantees class" | ||||
refers to a service class where all traffic performance metrics | ||||
included in the service model (OWD, loss, delay variation) are | ||||
guaranteed, while "Delay traffic performance guarantees class" refers | ||||
to a service class where only OWD is guaranteed. | ||||
Connectivity: Scope and Guarantees | Connectivity: Scope and Guarantees | |||
(1) Inter-SP connectivity | (1) Inter-SP connectivity | |||
- Pipe scope from the local to the remote SBE/DBE | - Pipe scope from the local to the remote SBE/DBE | |||
- Full traffic performance guarantees class | - Full traffic performance guarantees class | |||
(2) Customer to SP connectivity | (2) Customer-to-SP connectivity | |||
- Hose/Funnel scope connecting the local SBE/DBE | - Hose/Funnel scope connecting the local SBE/DBE | |||
to the customer access points | to the customer access points | |||
- Full traffic performance guarantees class | - Full traffic performance guarantees class | |||
(3) SP to any destination connectivity | (3) SP to any destination connectivity | |||
- Hose/Funnel scope from the local SBE/DBE to the | - Hose/Funnel scope from the local SBE/DBE to the | |||
Internet gateway | Internet gateway | |||
- Delay traffic performance guarantees class | - Delay traffic performance guarantees class | |||
Flow Identification | Flow Identification | |||
* Destination IP address (SBE, DBE) | * Destination IP address (SBE, DBE) | |||
* DSCP marking | * DSCP marking | |||
skipping to change at page 10, line 5 ¶ | skipping to change at line 420 ¶ | |||
* Routing rule to exclude some ASes from the inter-domain | * Routing rule to exclude some ASes from the inter-domain | |||
paths | paths | |||
Notifications (including feedback) | Notifications (including feedback) | |||
* Statistics on aggregate traffic to adjust capacity | * Statistics on aggregate traffic to adjust capacity | |||
* Failures | * Failures | |||
* Planned maintenance operations | * Planned maintenance operations | |||
* Triggered by thresholds | * Triggered by thresholds | |||
Figure 2: Sample Attributes Captured in a Service Model | Figure 2: Sample Attributes Captured in a Service Model | |||
Network models are mainly network resource-facing modules; they | Network models are mainly network-resource-facing modules; they | |||
describe various aspects of a network infrastructure, including | describe various aspects of a network infrastructure, including | |||
devices and their subsystems, and relevant protocols operating at the | devices and their subsystems, and relevant protocols operating at the | |||
link and network layers across multiple devices (e.g., network | link and network layers across multiple devices (e.g., network | |||
topology and traffic-engineering tunnel modules). | topology and traffic-engineering tunnel modules). | |||
Device (and function) models usually follow a bottom-up approach and | Device (and function) models usually follow a bottom-up approach and | |||
are mostly technology-specific modules used to realize a service | are mostly technology-specific modules used to realize a service | |||
(e.g., BGP, ACL). | (e.g., BGP, ACL). | |||
Each level maintains a view of the supported YANG modules provided by | Each level maintains a view of the supported YANG modules provided by | |||
lower levels (see for example, Appendix A). Mechanisms such as YANG | lower levels (see for example, Appendix A). Mechanisms such as the | |||
library [RFC8525] can be used to expose which YANG modules are | YANG library [RFC8525] can be used to expose which YANG modules are | |||
supported by nodes in lower levels. | supported by nodes in lower levels. | |||
Figure 3 illustrates the overall layering model. The reader may | Figure 3 illustrates the overall layering model. The reader may | |||
refer to Section 4 of [RFC8309] for an overview of "Orchestrator" and | refer to Section 4 of [RFC8309] for an overview of "Orchestrator" and | |||
"Controller" elements. All these elements (i.e., Orchestrator(s), | "Controller" elements. All these elements (i.e., Orchestrator(s), | |||
Controller(s), device(s)) are under the responsibility of the same | Controller(s), device(s)) are under the responsibility of the same | |||
operator. | operator. | |||
+-----------------------------------------------------------------+ | +-----------------------------------------------------------------+ | |||
| Hierarchy Abstraction | | | Hierarchy Abstraction | | |||
| | | | | | |||
| +-----------------------+ Service Model | | | +-----------------------+ Service Model | | |||
| | Orchestrator | (Customer Oriented) | | | | Orchestrator | (Customer Oriented) | | |||
| |+---------------------+| Scope: "1:1" Pipe model | | | |+---------------------+| Scope: "1:1" Pipe model | | |||
| || Service Modeling || | | | || Service Modeling || | | |||
| |+---------------------+| | | | |+---------------------+| | | |||
| | | Bidirectional | | | | | Bidirectional | | |||
| |+---------------------+| +-+ Capacity, OWD +-+ | | | |+---------------------+| +-+ Capacity, OWD +-+ | | |||
| ||Service Orchestration|| | +----------------+ | | | | ||Service Orchestration|| | +----------------+ | | | |||
| |+---------------------+| +-+ +-+ | | | |+---------------------+| +-+ +-+ | | |||
| +-----------------------+ Ingress Egress | | | +-----------------------+ Ingress Egress | | |||
| | | | | | |||
| | | | | | |||
| +-----------------------+ Network Model | | | +-----------------------+ Network Model | | |||
| | Controller | (Operator Oriented) | | | | Controller | (Operator Oriented) | | |||
| |+---------------------+| +-+ +--+ +---+ +-+ | | | |+---------------------+| +-+ +--+ +---+ +-+ | | |||
| || Network Modeling || | | | | | | | | | | | || Network Modeling || | | | | | | | | | | |||
| |+---------------------+| | o----o--o----o---o---o | | | | |+---------------------+| | o----o--o----o---o---o | | | |||
| | | +-+ +--+ +---+ +-+ | | | | | +-+ +--+ +---+ +-+ | | |||
| |+---------------------+| src dst | | | |+---------------------+| src dst | | |||
| ||Network Orchestration|| L3VPN over TE | | | ||Network Orchestration|| L3VPN over TE | | |||
| |+---------------------+| Instance Name/Access Interface | | | |+---------------------+| Instance Name/Access Interface | | |||
| +-----------------------+ Protocol Type/Capacity/RD/RT/... | | | +-----------------------+ Protocol Type/Capacity/RD/RT/... | | |||
| | | | | | |||
| | | | | | |||
| +-----------------------+ Device Model | | | +-----------------------+ Device Model | | |||
| | Device | | | | | Device | | | |||
| |+--------------------+ | | | | |+--------------------+ | | | |||
| || 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 Within a Network Operator | Figure 3: Layering and Representation within a Network Operator | |||
A composite service offered by a network operator may rely on | A composite service offered by a network operator may rely on | |||
services from other operators. In such case, the network operator | services from other operators. In such a case, the network operator | |||
acts as a customer to request services from other networks. The | acts as a customer to request services from other networks. The | |||
operators providing these services will then follow the layering | operators providing these services will then follow the layering | |||
depicted in Figure 3. The mapping between a composite service and a | depicted in Figure 3. The mapping between a composite service and a | |||
third-party service is maintained at the orchestration level. From a | third-party service is maintained at the orchestration level. From a | |||
data plane perspective, appropriate traffic steering policies (e.g., | data-plane perspective, appropriate traffic steering policies (e.g., | |||
Service Function Chaining [RFC7665]) are managed by the network | Service Function Chaining [RFC7665]) are managed by the network | |||
controllers to guide how/when a third party service is invoked for | controllers to guide how/when a third-party service is invoked for | |||
flows bound to a composite service. | flows bound to a composite service. | |||
The layering model depicted in Figure 3 does not make any assumption | The layering model depicted in Figure 3 does not make any assumption | |||
about the location of the various entities (e.g., controller, | about the location of the various entities (e.g., Controller, | |||
orchestrator) within the network. As such, the architecture does not | Orchestrator) within the network. As such, the architecture does not | |||
preclude deployments where, for example, the controller is embedded | preclude deployments where, for example, the Controller is embedded | |||
on a device that hosts other functions that are controlled via YANG | on a device that hosts other functions that are controlled via YANG | |||
modules. | modules. | |||
In order to ease the mapping between layers and data reuse, this | In order to ease the mapping between layers and data reuse, this | |||
document focuses on service models that are modelled using YANG. | document focuses on service models that are modeled using YANG. | |||
Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3 | Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3 | |||
does not preclude service models to be modelled using other data | does not preclude service models to be modeled using data modeling | |||
modelling languages than YANG. | languages other 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 automation of | |||
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 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]. The service | Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service | |||
filtering request modelled using [RFC8783] will be translated into | filtering request modeled using [RFC8783] will be translated into | |||
device-specific filtering (e.g., ACLs defined in [RFC8519]) that | device-specific filtering (e.g., ACLs defined in [RFC8519]) that | |||
fulfils the service request. | fulfills 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, and instantiate the service. Also, they are used | |||
management of network resources. Doing so is meant to: | to provide life-cycle management of network resources. Doing so is | |||
meant to: | ||||
o expose network resources to customers (including other network | * 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 | * 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. | |||
Note that it is out of the scope of this document to elaborate on the | Note that it is out of the scope of this document to elaborate on the | |||
communication protocols that are used to implement the interface | communication protocols that are used to implement the interface | |||
between the service ordering (customer) and service order handling | between the service ordering (customer) and service order handling | |||
(provider). | (provider). | |||
3.3. Service Fulfillment Automation | 3.3. Service Fulfillment 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 | |||
used to: | used to: | |||
o Provision each involved network function/device with the proper | * Provision each involved network function/device with the proper | |||
configuration information. | configuration information. | |||
o Operate the network based on service requirements as described in | * Operate the network based on service requirements as described in | |||
the service model(s) and local operational guidelines. | the service model(s) and local operational guidelines. | |||
In addition, the operational state including configuration that is in | In addition, the operational state including configuration that is in | |||
effect together with statistics should be exposed to upper layers to | effect together with statistics should be exposed to upper layers to | |||
provide better network visibility and assess to what extent the | provide better network visibility and assess to what extent the | |||
derived low level modules are consistent with the upper level inputs. | derived low-level modules are consistent with the upper-level inputs. | |||
Filters are enforced on the notifications that are communicated to | Filters are enforced on the notifications that are communicated to | |||
Service layers. The type and frequency of notifications may be | Service layers. The type and frequency of notifications may be | |||
agreed in the service model. | agreed upon in the service model. | |||
Note that it is important to correlate telemetry data with | Note that it is important to correlate telemetry data with | |||
configuration data to be used for closed loops at the different | configuration data to be used for closed loops at the different | |||
stages of service delivery, from resource allocation to service | stages of service delivery, from resource allocation to service | |||
operation, in particular. | operation, in particular. | |||
3.4. YANG Modules Integration | 3.4. YANG Module Integration | |||
To support top-down service delivery, YANG modules at different | To support top-down service delivery, YANG modules at different | |||
levels or at the same level need to be integrated together for proper | levels or at the same level need to be integrated for proper service | |||
service delivery (including, proper network setup). For example, the | delivery (including proper network setup). For example, the service | |||
service parameters captured in service models need to be decomposed | parameters captured in service models need to be decomposed into a | |||
into a set of configuration/notification parameters that may be | set of configuration/notification parameters that may be specific to | |||
specific to one or more technologies; these technology-specific | one or more technologies; these technology-specific parameters are | |||
parameters are grouped together to define technology-specific device | grouped together to define technology-specific device-level models or | |||
level models or network level models. | network-level models. | |||
In addition, these technology-specific device or network models can | In addition, these technology-specific device or network models can | |||
be further integrated with each other using the schema mount | be further integrated with each other using the schema mount | |||
mechanism [RFC8528] to provision each involved network function/ | mechanism [RFC8528] to provision each involved network function/ | |||
device or each involved network domain to support newly added modules | device or each involved network domain to support newly added modules | |||
or features. A collection of device models integrated together can | or features. A collection of integrated device models can be loaded | |||
be loaded and validated during implementation. | and validated during implementation. | |||
High-level policies can be defined at service or network models | High-level policies can be defined at service or network models | |||
(e.g., "Autonomous System Number (ASN) Exclude" in the example | (e.g., "Autonomous System Number (ASN) Exclude" in the example | |||
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 to | telemetry automation, e.g., policies that contain conditions to | |||
trigger the generation and pushing of new telemetry data. | trigger the generation and pushing of new telemetry data. | |||
4. Functional Blocks 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 | |||
lifecycle management architecture illustrated in Figure 4 and | life-cycle management architecture illustrated in Figure 4 and | |||
described in the following subsections. | described in the following subsections. | |||
+------------------+ | +------------------+ | |||
................. | | | ............... | | | |||
Service level | | | Service level | | | |||
V | | V | | |||
E2E E2E E2E E2E | E2E E2E E2E E2E | |||
Service --> Service ---------> Service ------------> Service | Service --> Service ---------> Service ------------> Service | |||
Exposure Creation ^ Optimization ^ Diagnosis | Exposure Creation ^ Optimization ^ Diagnosis | |||
/Modification | | | | /Modification | | | | |||
^ | |Diff | | | ^ | |Diff | | | |||
E2E | | | E2E | | | E2E | | | E2E | | | |||
Service ----+ | | Service | | | Service ----+ | | Service | | | |||
Decommission | +------ Assurance --+ | | Decommission | +------ Assurance --+ | | |||
| ^ | | | ^ | | |||
Multi-layer | | | | Multi-layer | | | | |||
Multi-domain | | | | Multi-domain | | | | |||
Service Mapping| | | | Service Mapping| | | | |||
................. |<-----------------+ | | | ............... |<-----------------+ | | | |||
Network level | | +-------+ v | Network level | | +-------+ v | |||
V | | Specific | V | | Specific | |||
Specific Specific | Service | Specific Specific | Service | |||
Service --------> Service <--+ | Diagnosis | Service --------> Service <--+ | Diagnosis | |||
Creation ^ Optimization | | | | Creation ^ Optimization | | | | |||
/Modification | | | | | /Modification | | | | | |||
| |Diff | | | | | |Diff | | | | |||
| | Specific --+ | | | | | Specific --+ | | | |||
Service | | Service | | | Service | | Service | | | |||
Decomposition | +----- Assurance ----+ | | Decomposition | +----- Assurance ----+ | | |||
| ^ | | | ^ | | |||
................. | | Aggregation | | ............... | | Aggregation | | |||
Device level | +------------+ | | Device level | +------------+ | | |||
V | | | V | | | |||
Service Intent | v | Service Intent | v | |||
Fulfillment Config ----> Config ----> Performance ----> Fault | Fulfillment Config ----> Config ----> Performance ----> Fault | |||
Provision Validation Monitoring Diagnostic | Provision Validation Monitoring Diagnostic | |||
Figure 4: Service and Network Lifecycle Management | Figure 4: Service and Network Life-Cycle Management | |||
4.1. Service Lifecycle Management Procedure | 4.1. Service Life-Cycle Management Procedure | |||
Service lifecycle management includes end-to-end service lifecycle | Service life-cycle management includes end-to-end service life-cycle | |||
management at the service level and technology specific network | management at the service level and technology-specific network life- | |||
lifecycle management at the network level. | cycle management at the network level. | |||
The end-to-end service lifecycle management is technology-independent | The end-to-end service life-cycle management is technology- | |||
service management and spans across multiple network domains and/or | independent service management and spans across multiple network | |||
multiple layers while technology specific service lifecycle | domains and/or multiple layers while technology-specific service | |||
management is technology domain specific or layer specific service | life-cycle management is technology domain-specific or layer-specific | |||
lifecycle management. | service life-cycle management. | |||
4.1.1. Service Exposure | 4.1.1. Service Exposure | |||
A service in the context of this document (sometimes called, Network | A service in the context of this document (sometimes called "Network | |||
Service) is some form of connectivity between customer sites and the | Service") is some form of connectivity between customer sites and the | |||
Internet or between customer sites across the operator's network and | Internet or between customer sites across the operator's network and | |||
across the Internet. | across the Internet. | |||
Service exposure is used to capture services offered to customers | Service exposure is used to capture services offered to customers | |||
(ordering and order handling). One example is that a customer can | (ordering and order handling). One example is that a customer can | |||
use a L3VPN Service Model (L3SM) to request L3VPN service by | use an L3VPN Service Model (L3SM) to request L3VPN service by | |||
providing the abstract technical characterization of the intended | providing the abstract technical characterization of the intended | |||
service between customer sites. | service between customer sites. | |||
Service model catalogs can be created along to expose the various | Service model catalogs can be created to expose the various services | |||
services and the information needed to invoke/order a given service. | and the information needed to invoke/order a given service. | |||
4.1.2. Service Creation/Modification | 4.1.2. Service Creation/Modification | |||
A customer is usually unaware of the technology that the network | A customer is usually unaware of the technology that the network | |||
operator has available to deliver the service, so the customer does | operator has available to deliver the service, so the customer does | |||
not make requests specific to the underlying technology but is | not make requests specific to the underlying technology but is | |||
limited to making requests specific to the service that is to be | limited to making requests specific to the service that is to be | |||
delivered. This service request can be filled using a service model. | delivered. This service request can be filled using a service model. | |||
Upon receiving a service request, and assuming that appropriate | Upon receiving a service request, and assuming that appropriate | |||
authentication and authorization checks have been made with success, | authentication and authorization checks have been made with success, | |||
the service orchestrator/management system should verify whether the | the service Orchestrator/management system should verify whether the | |||
service requirements in the service request can be met (i.e., whether | service requirements in the service request can be met (i.e., whether | |||
there are sufficient resources that can be allocated with the | there are sufficient resources that can be allocated with the | |||
requested guarantees). | requested guarantees). | |||
If the request is accepted, the service orchestrator/management | If the request is accepted, the service Orchestrator/management | |||
system maps such service request to its view. This view can be | system maps such a service request to its view. This view can be | |||
described as a technology specific network model or a set of | described as a technology-specific network model or a set of | |||
technology specific device models and this mapping may include a | technology-specific device models, and this mapping may include a | |||
choice of which networks and technologies to use depending on which | choice of which networks and technologies to use depending on which | |||
service features have been requested. | service features have been requested. | |||
In addition, a customer may require to change the underlying network | In addition, a customer may require a change in the underlying | |||
infrastructure to adapt to new customer's needs and service | network infrastructure to adapt to new customers' needs and service | |||
requirements (e.g., service a new customer site, add a new access | requirements (e.g., service a new customer site, add a new access | |||
link, provide disjoint paths). This service modification can be | link, or provide disjoint paths). This service modification can be | |||
issued following the same service model used by the service request. | issued following the same service model used by the service request. | |||
Withdrawing a service is discussed in Section 4.1.6. | Withdrawing a service is discussed in Section 4.1.6. | |||
4.1.3. Service Assurance | 4.1.3. Service Assurance | |||
The performance measurement telemetry (Section 4.2) can be used to | The performance measurement telemetry (Section 4.2.3) can be used to | |||
provide service assurance at Service and/or Network levels. | provide service assurance at service and/or network levels. The | |||
Performance measurement telemetry model can tie with service or | performance measurement telemetry model can tie with service or | |||
network models to monitor network performance or Service Level | network models to monitor network performance or Service Level | |||
Agreement. | Agreements. | |||
4.1.4. Service Optimization | 4.1.4. Service Optimization | |||
Service optimization is a technique that gets the configuration of | Service optimization is a technique that gets the configuration of | |||
the network updated due to network changes, incident mitigation, or | the network updated due to network changes, incident mitigation, or | |||
new service requirements. One example is once a tunnel or a VPN is | new service requirements. One example is once a tunnel or a VPN is | |||
setup, Performance monitoring information or telemetry information | set up, performance monitoring information or telemetry information | |||
per tunnel (or per VPN) can be collected and fed into the management | per tunnel (or per VPN) can be collected and fed into the management | |||
system. If the network performance doesn't meet the service | system. If the network performance doesn't meet the service | |||
requirements, the management system can create new VPN policies | requirements, the management system can create new VPN policies | |||
capturing network service requirements and populate them into the | capturing network service requirements and populate them into the | |||
network. | network. | |||
Both network performance information and policies can be modelled | Both network performance information and policies can be modeled | |||
using YANG. With Policy-based management, self-configuration and | using YANG. With Policy-based management, self-configuration and | |||
self-optimization behavior can be specified and implemented. | self-optimization behavior can be specified and implemented. | |||
The overall service optimization is managed at the service level, | The overall service optimization is managed at the service level, | |||
while the network level is responsible for the optimization of the | while the network level is responsible for the optimization of the | |||
specific network services it provides. | specific network services it provides. | |||
4.1.5. Service Diagnosis | 4.1.5. Service Diagnosis | |||
Operations, Administration, and Maintenance (OAM) are important | Operations, Administration, and Maintenance (OAM) are important | |||
networking functions for service diagnosis that allow network | networking functions for service diagnosis that allow network | |||
operators to: | operators to: | |||
o monitor network communications (i.e., reachability verification | * monitor network communications (i.e., reachability verification | |||
and Continuity Check) | and Continuity Check) | |||
o troubleshoot failures (i.e., fault verification and localization) | * troubleshoot failures (i.e., fault verification and localization) | |||
o monitor service-level agreements and performance (i.e., | * monitor service level agreements and performance (i.e., | |||
performance management) | performance management) | |||
When the network is down, service diagnosis should be in place to | When the network is down, service diagnosis should be in place to | |||
pinpoint the problem and provide recommendations (or instructions) | pinpoint the problem and provide recommendations (or instructions) | |||
for the network recovery. | for network recovery. | |||
The service diagnosis information can be modelled as technology- | The service diagnosis information can be modeled as technology- | |||
independent Remote Procedure Call (RPC) operations for OAM protocols | independent Remote Procedure Call (RPC) operations for OAM protocols | |||
and technology-independent abstraction of key OAM constructs for OAM | and technology-independent abstraction of key OAM constructs for OAM | |||
protocols [RFC8531][RFC8533]. These models can be used to provide | protocols [RFC8531][RFC8533]. These models can be used to provide | |||
consistent configuration, reporting, and presentation for the OAM | consistent configuration, reporting, and presentation for the OAM | |||
mechanisms used to manage the network. | mechanisms used to manage the network. | |||
Refer to Section 4.2.4 for the device-specific side. | Refer to Section 4.2.4 for the device-specific side. | |||
4.1.6. Service Decommission | 4.1.6. Service Decommission | |||
Service decommission allows a customer to stop the service by | Service decommission allows a customer to stop the service by | |||
removing the service from active status and thus releasing the | removing the service from active status, thus releasing the network | |||
network resources that were allocated to the service. Customers can | resources that were allocated to the service. Customers can also use | |||
also use the service model to withdraw the subscription to a service. | the service model to withdraw the subscription to a service. | |||
4.2. Service Fullfillment Management Procedure | 4.2. Service Fulfillment Management Procedure | |||
4.2.1. Intended Configuration Provision | 4.2.1. Intended Configuration Provision | |||
Intended configuration at the device level is derived from network | Intended configuration at the device level is derived from network | |||
models at the network level or service model at the service level and | models at the network level or service models at the service level | |||
represents the configuration that the system attempts to apply. Take | and represents the configuration that the system attempts to apply. | |||
L3SM as a service model example to deliver a L3VPN service, there is | Take L3SM as a service model example to deliver an L3VPN service; | |||
a need to map the L3VPN service view defined in the service model | there is a need to map the L3VPN service view defined in the service | |||
into a detailed intended configuration view defined by specific | model into a detailed intended configuration view defined by specific | |||
configuration models for network elements; the configuration | configuration models for network elements. The configuration | |||
information includes: | information includes: | |||
o Virtual Routing and Forwarding (VRF) definition, including VPN | * Virtual Routing and Forwarding (VRF) definition, including VPN | |||
policy expression | policy expression | |||
o Physical Interface(s) | * Physical Interface(s) | |||
o IP layer (IPv4, IPv6) | * IP layer (IPv4, IPv6) | |||
o QoS features such as classification, profiles, etc. | * QoS features such as classification, profiles, etc. | |||
o Routing protocols: support of configuration of all protocols | * Routing protocols: support of configuration of all protocols | |||
listed in a service request, as well as routing policies | listed in a service request, as well as routing policies | |||
associated with those protocols. | associated with those protocols | |||
o Multicast support | * Multicast support | |||
o Address sharing | * Address sharing | |||
o Security (e.g., access control, authentication, encryption) | * Security (e.g., access control, authentication, encryption) | |||
These specific configuration models can be used to configure Provider | These specific configuration models can be used to configure Provider | |||
Edge (PE) and Customer Edge (CE) devices within a site, e.g., a BGP | Edge (PE) and Customer Edge (CE) devices within a site, e.g., a BGP | |||
policy model can be used to establish VPN membership between sites | policy model can be used to establish VPN membership between sites | |||
and VPN Service Topology. | and VPN service topology. | |||
Note that in networks with legacy devices (that support proprietary | Note that in networks with legacy devices (that support proprietary | |||
modules or do not support YANG at all), an adaptation layer is likely | modules or do not support YANG at all), an adaptation layer is likely | |||
to be required at the network level so that these devices can be | to be required at the network level so that these devices can be | |||
involved in the delivery of the network services. | involved in the delivery of the network services. | |||
This interface is also used to handle service withdrawal | This interface is also used to handle service withdrawal | |||
(Section 4.1.6). | (Section 4.1.6). | |||
4.2.2. Configuration Validation | 4.2.2. Configuration Validation | |||
Configuration validation is used to validate intended configuration | Configuration validation is used to validate intended configuration | |||
and ensure the configuration take effect. | and ensure the configuration takes effect. | |||
For example, if a customer creates an interface "eth-0/0/0" but the | For example, if a customer creates an interface "eth-0/0/0" but the | |||
interface does not physically exist at this point, then configuration | interface does not physically exist at this point, then configuration | |||
data appears in the <intended> status but does not appear in the | data appears in the <intended> status but does not appear in the | |||
<operational> datastore. More details about <intended> and | <operational> datastore. More details about <intended> and | |||
<operational> datastores can be found in Section 5.1 of [RFC8342]. | <operational> datastores can be found in Section 5.1 of [RFC8342]. | |||
4.2.3. Performance Monitoring | 4.2.3. Performance Monitoring | |||
When a configuration is in effect in a device, <operational> | When a configuration is in effect in a device, the <operational> | |||
datastore holds the complete operational state of the device | datastore holds the complete operational state of the device, | |||
including learned, system, default configuration, and system state. | including learned, system, default configuration, and system state. | |||
However, the configurations and state of a particular device does not | However, the configurations and state of a particular device do not | |||
have the visibility on the whole network or how packets are going to | have visibility on the whole network, nor can they show how packets | |||
be forwarded through the entire network. Therefore, it becomes more | are going to be forwarded through the entire network. Therefore, it | |||
difficult to operate the entire network without understanding the | becomes more difficult to operate the entire network without | |||
current status of the network. | understanding the current status of the network. | |||
The management system should subscribe to updates of a YANG datastore | The management system should subscribe to updates of a YANG datastore | |||
in all the network devices for performance monitoring purposes and | in all the network devices for performance monitoring purposes and | |||
build a full topological visibility of the network by aggregating | build a full topological visibility of the network by aggregating | |||
(and filtering) these operational state from different sources. | (and filtering) these operational states from different sources. | |||
4.2.4. Fault Diagnostic | 4.2.4. Fault Diagnostic | |||
When configuration is in effect in a device, some devices may be mis- | When configuration is in effect in a device, some devices may be | |||
configured (e.g., device links are not consistent in both sides of | misconfigured (e.g., device links are not consistent in both sides of | |||
the network connection) or network resources might be mis-allocated. | the network connection) or network resources might be misallocated. | |||
Therefore, services may be negatively affected without knowing the | Therefore, services may be negatively affected without knowing the | |||
root cause in the network. | root cause in the network. | |||
Technology-dependent nodes and RPC commands are defined in | Technology-dependent nodes and RPC commands are defined in | |||
technology-specific YANG data models which can use and extend the | technology-specific YANG data models, which can use and extend the | |||
base model described in Section 4.1.5 to deal with these issues. | base model described in Section 4.1.5 to deal with these issues. | |||
These RPC commands received in the technology-dependent node can be | These RPC commands received in the technology-dependent node can be | |||
used to trigger technology-specific OAM message exchanges for fault | used to trigger technology-specific OAM message exchanges for fault | |||
verification and fault isolation. For example, TRILL Multicast Tree | verification and fault isolation. For example, Transparent | |||
Verification (MTV) RPC command [I-D.ietf-trill-yang-oam] can be used | Interconnection of Lots of Links (TRILL) Multi-destination Tree | |||
to trigger Multi-Destination Tree Verification Message defined in | Verification (MTV) RPC command [TRILL-YANG-OAM] can be used to | |||
[RFC7455] to verify TRILL distribution tree integrity. | trigger Multi-Destination Tree Verification Messages (MTVMs) defined | |||
in [RFC7455] to verify TRILL distribution tree integrity. | ||||
4.3. Multi-Layer/Multi-Domain Service Mapping | 4.3. Multi-layer/Multi-domain Service Mapping | |||
Multi-layer/Multi-domain Service Mapping allows to map an end-to-end | Multi-layer/Multi-domain Service Mapping allows the mapping of an | |||
abstract view of the service segmented at different layers and/or | end-to-end abstract view of the service segmented at different layers | |||
different network domains into domain-specific views. | and/or different network domains into domain-specific views. | |||
One example is to map service parameters in the L3SM into | One example is to map service parameters in the L3SM into | |||
configuration parameters such as Route Distinguisher (RD), Route | configuration parameters such as Route Distinguisher (RD), Route | |||
Target (RT), and VRF in the L3VPN Network Model (L3NM). | Target (RT), and VRF in the L3VPN Network Model (L3NM). | |||
Another example is to map service parameters in the L3SM into Traffic | Another example is to map service parameters in the L3SM into Traffic | |||
Engineered (TE) tunnel parameters (e.g., Tunnel ID) in TE model and | Engineered (TE) tunnel parameters (e.g., Tunnel ID) in TE model and | |||
Virtual Network (VN) parameters (e.g., Access Point (AP) list, VN | Virtual Network (VN) parameters (e.g., Access Point (AP) list and VN | |||
members) in the YANG data model for VN operation | members) in the YANG data model for VN operation [ACTN-VN-YANG]. | |||
[I-D.ietf-teas-actn-vn-yang]. | ||||
4.4. Service Decomposition | 4.4. Service Decomposition | |||
Service Decomposition allows to decompose service models at the | Service Decomposition allows to decompose service models at the | |||
service level or network models at the network level into a set of | service level or network models at the network level into a set of | |||
device models at the device level. These device models may be tied | device 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 they | |||
the implementation time before configuration is loaded and validated. | may load at the implementation time before configuration is loaded | |||
and validated. | ||||
5. YANG Data Model Integration Examples | 5. YANG Data Model Integration Examples | |||
The following subsections provide some YANG data models integration | The following subsections provide some YANG data model 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 Section 4: | architecture defined in Section 4: | |||
1. The Customer requests to create two sites (as per Service | 1. The Customer requests to create two sites (as per Service | |||
Creation in Section 4.2.1) relying upon L3SM with each site | Creation in Section 4.1.2) relying upon L3SM with each site | |||
having one network access connectivity, for example: | having one network access connectivity, for example: | |||
* Site A: network-access A, link-capacity = 20 Mbps, class | * Site A: network-access A, link-capacity = 20 Mbps, class | |||
"foo", guaranteed-capacity-percent = 10, average-one-way-delay | "foo", guaranteed-capacity-percent = 10, average-one-way-delay | |||
= 70 ms. | = 70 ms. | |||
* Site B: network-access B, link-capacity = 30 Mbps, class | * Site B: network-access B, link-capacity = 30 Mbps, class | |||
"foo1", guaranteed-capacity-percent = 15, average-one-way- | "foo1", guaranteed-capacity-percent = 15, average-one-way- | |||
delay = 60 ms. | delay = 60 ms. | |||
2. The Orchestrator extracts the service parameters from the L3SM. | 2. The Orchestrator extracts the service parameters from the L3SM. | |||
Then, it uses them as input to the Service Mapping in Section 4.3 | Then, it uses them as input to the Service Mapping in Section 4.3 | |||
to translate them into an orchestrated configuration parameters | to translate them into orchestrated configuration parameters | |||
(e.g., RD, RT, VRF) that are part of the L3NM specified in | (e.g., RD, RT, and VRF) that are part of the L3NM specified in | |||
[I-D.ietf-opsawg-l3sm-l3nm]. | [OPSAWG-L3SM-L3NM]. | |||
3. The Controller takes the orchestrated configuration parameters in | 3. The Controller takes the orchestrated configuration parameters in | |||
the L3NM and translates them into orchestrated (Service | the L3NM and translates them into an orchestrated (Service | |||
Decomposition in Section 4.4) configuration of network elements | Decomposition in Section 4.4) configuration of network elements | |||
that are part of, e.g., BGP, QoS, Network Instance, IP | that are part of, e.g., BGP, QoS, Network Instance, IP | |||
management, and interface models. | management, and interface models. | |||
[I-D.ogondio-opsawg-uni-topology] can be used for representing, | [UNI-TOPOLOGY] can be used for representing, managing, and | |||
managing, and controlling the User Network Interface (UNI) topology. | controlling the User Network Interface (UNI) topology. | |||
L3SM | | L3SM | | |||
Service | | Service | | |||
Model | | Model | | |||
+------------------------+------------------------+ | +------------------------+------------------------+ | |||
| +--------V--------+ | | | +--------V--------+ | | |||
| | Service Mapping | | | | | Service Mapping | | | |||
| +--------+--------+ | | | +--------+--------+ | | |||
| Orchestrator | | | | Orchestrator | | | |||
+------------------------+------------------------+ | +------------------------+------------------------+ | |||
skipping to change at page 21, line 34 ¶ | skipping to change at line 936 ¶ | |||
|| || | || || | |||
|| BGP, || | || BGP, || | |||
|| QoS, || | || QoS, || | |||
|| Interface, || | || Interface, || | |||
+------------+| NI, |+------------+ | +------------+| NI, |+------------+ | |||
| | IP | | | | | IP | | | |||
+--+--+ +--+--+ +--+--+ +--+--+ | +--+--+ +--+--+ +--+--+ +--+--+ | |||
| CE1 +-------+ PE1 | | PE2 +-------+ CE2 | | | CE1 +-------+ PE1 | | PE2 +-------+ CE2 | | |||
+-----+ +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ | |||
Figure 5: L3VPN Service Delivery Example (Current) | Figure 5: L3VPN Service Delivery Example (Current) | |||
L3NM inherits some of data elements from the L3SM. Nevertheless, the | L3NM inherits some of the data elements from the L3SM. Nevertheless, | |||
L3NM as currently designed in [I-D.ietf-opsawg-l3sm-l3nm] does not | the L3NM as designed in [OPSAWG-L3SM-L3NM] does not expose some | |||
expose some information to the above layer such as the capabilities | information to the above layer such as the capabilities of an | |||
of an underlying network (which can be used to drive service order | underlying network (which can be used to drive service order | |||
handling) or notifications (to notify subscribers about specific | handling) or notifications (to notify subscribers about specific | |||
events or degradations as per agreed SLAs). Some of this information | events or degradations as per agreed SLAs). Some of this information | |||
can be provided using, e.g., [I-D.www-opsawg-yang-vpn-service-pm]. A | can be provided using, e.g., [OPSAWG-YANG-VPN]. A target overall | |||
target overall model is depicted in Figure 6. | model is depicted in Figure 6. | |||
L3SM | ^ | L3SM | ^ | |||
Service | | Notifications | Service | | Notifications | |||
Model | | | Model | | | |||
+------------------------+------------------------+ | +------------------------+------------------------+ | |||
| +--------V--------+ | | | +--------V--------+ | | |||
| | Service Mapping | | | | | Service Mapping | | | |||
| +--------+--------+ | | | +--------+--------+ | | |||
| Orchestrator | | | | Orchestrator | | | |||
+------------------------+------------------------+ | +------------------------+------------------------+ | |||
skipping to change at page 22, line 37 ¶ | skipping to change at line 979 ¶ | |||
|| Interface, || | || Interface, || | |||
+------------+| NI, |+------------+ | +------------+| NI, |+------------+ | |||
| | 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). An L2VPN Service Model (L2SM) is defined in [RFC8466], | |||
while the L2VPN Network YANG Model (L2NM) is specified in | while the YANG L2VPN Network Model (L2NM) is specified in | |||
[I-D.ietf-opsawg-l2nm]. | [OPSAWG-L2NM]. | |||
5.2. VN Lifecycle Management | 5.2. VN Life-Cycle 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 Section 4: | architecture defined in Section 4: | |||
1. A customer makes a request (Service Exposure in Section 4.1.1) to | 1. A customer makes a request (Service Exposure in Section 4.1.1) to | |||
create a VN. The association between the VN, APs, and VN members | create a VN. The association between the VN, APs, and VN members | |||
is defined in the VN YANG module [I-D.ietf-teas-actn-vn-yang]. | is defined in the VN YANG model [ACTN-VN-YANG]. | |||
2. The Orchestrator creates the single abstract node topology based | 2. The Orchestrator creates the single abstract node topology based | |||
on the information captured in the request. | on the information captured in the request. | |||
3. The customer exchanges with the Orchestrator the connectivity | 3. The customer exchanges with the Orchestrator the connectivity | |||
matrix on the abstract node topology and explicit paths using the | matrix on the abstract node topology and explicit paths using the | |||
TE topology model [RFC8795]. This information can be used to | TE topology model [RFC8795]. This information can be used to | |||
instantiate the VN and setup tunnels between source and | instantiate the VN and set up tunnels between source and | |||
destination endpoints (Service Creation in Section 4.1.2). | destination endpoints (Service Creation in Section 4.1.2). | |||
4. In order to provide service assurance (Service Optimization in | 4. In order to provide service assurance (Service Optimization in | |||
Section 4.1.4), the telemetry model which augments the VN model | Section 4.1.4), the telemetry model that augments the VN model | |||
and corresponding TE tunnel model can be used by the Orchestrator | and corresponding TE tunnel model can be used by the Orchestrator | |||
to subscribe to performance measurement data. The Controller | to subscribe to performance measurement data. The Controller | |||
will then notify the Orchestrator with all the parameter changes | will then notify the Orchestrator with all the parameter changes | |||
and network performance changes related to the VN topology and | and network performance changes related to the VN topology and | |||
the tunnels [I-D.ietf-teas-actn-pm-telemetry-autonomics]. | the tunnels [TEAS-ACTN-PM]. | |||
| | | | |||
VN | | VN | | |||
Service | | Service | | |||
Model | | Model | | |||
+----------------------|--------------------------+ | +----------------------|--------------------------+ | |||
| Orchestrator | | | | Orchestrator | | | |||
| +--------V--------+ | | | +--------V--------+ | | |||
| | Service Mapping | | | | | Service Mapping | | | |||
| +-----------------+ | | | +-----------------+ | | |||
skipping to change at page 23, line 43 ¶ | skipping to change at line 1034 ¶ | |||
| Controller | | | Controller | | |||
| | | | | | |||
+-------------------------------------------------+ | +-------------------------------------------------+ | |||
+-----+ +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ | |||
| CE1 +------+ PE1 | | PE2 +------+ CE2 | | | CE1 +------+ PE1 | | PE2 +------+ CE2 | | |||
+-----+ +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ | |||
Figure 7: A VN Service Delivery Example | Figure 7: A VN Service Delivery Example | |||
5.3. Event-based Telemetry in the Device Self Management | 5.3. Event-Based Telemetry in the Device Self Management | |||
In reference to Figure 8, the following steps are performed to | In reference to Figure 8, the following steps are performed to | |||
monitor state changes of managed resources in a network device and | monitor state changes of managed resources in a network device and | |||
provide device self-management within the network management | provide device self management within the network management | |||
automation architecture defined in Section 4: | automation architecture defined in Section 4: | |||
1. To control which state a network device should be in or is | 1. To control which state a network device should be in or is | |||
allowed to be in at any given time, a set of conditions and | allowed to be in at any given time, a set of conditions and | |||
actions are defined and correlated with network events (e.g., | actions are defined and correlated with network events (e.g., | |||
allow the NETCONF server to send updates only when the value | allow the NETCONF server to send updates only when the value | |||
exceeds a certain threshold for the first time, but not again | exceeds a certain threshold for the first time, but not again | |||
until the threshold is cleared), which constitute an | until the threshold is cleared), which constitute an Event | |||
Event/Condition/Action (ECA) policy or an event-driven policy | Condition Action (ECA) policy or an event-driven policy control | |||
control logic that can be executed on the device (e.g., | logic that can be executed on the device (e.g., [EVENT-YANG]). | |||
[I-D.wwx-netmod-event-yang]). | ||||
2. To provide rapid autonomic response that can exhibit self- | 2. To provide a rapid autonomic response that can exhibit self- | |||
management properties, the Controller pushes the ECA policy to | management properties, the Controller pushes the ECA policy to | |||
the network device and delegates the network control logic to the | the network device and delegates the network control logic to the | |||
network device. | network device. | |||
3. The network device uses the ECA model to subscribe to the event | 3. The network device uses the ECA model to subscribe to the event | |||
source, e.g., an event stream or datastore state data conveyed to | source, e.g., an event stream or datastore state data conveyed to | |||
the server via YANG Push subscription [RFC8641], monitors state | the server via YANG-Push subscription [RFC8641], monitors state | |||
parameters, and takes simple and instant actions when an | parameters, and takes simple and instant actions when an | |||
associated event condition on state parameters is met. ECA | associated event condition on state parameters is met. ECA | |||
notifications can be generated as the result of actions based on | notifications can be generated as the result of actions based on | |||
event stream subscription or datastore subscription (model-driven | event stream subscription or datastore subscription (model-driven | |||
telemetry operation discussed in Section 4.2.3). | telemetry operation discussed in Section 4.2.3). | |||
+----------------+ | +----------------+ | |||
| <----+ | | <----+ | |||
| Controller | | | | Controller | | | |||
+-------+--------+ | | +-------+--------+ | | |||
skipping to change at page 24, line 43 ¶ | skipping to change at line 1082 ¶ | |||
| | | | | | |||
| | | | | | |||
+------------V-------------+-----+ | +------------V-------------+-----+ | |||
|Device | | | |Device | | | |||
| +-------+ +---------+ +--+---+ | | | +-------+ +---------+ +--+---+ | | |||
| | Event +-> Event +->Event | | | | | Event +-> Event +->Event | | | |||
| | Source| |Condition| |Action| | | | | Source| |Condition| |Action| | | |||
| +-------+ +---------+ +------+ | | | +-------+ +---------+ +------+ | | |||
+--------------------------------+ | +--------------------------------+ | |||
Figure 8: Event-based Telemetry | Figure 8: Event-Based Telemetry | |||
6. Security Considerations | 6. Security Considerations | |||
Many of the YANG modules cited in this document define schema for | Many of the YANG modules cited in this document define schema for | |||
data that are designed to be accessed via network management | data that is designed to be accessed via network management protocols | |||
protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The | such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF | |||
lowest NETCONF layer is the secure transport layer, and the | layer is the secure transport layer, and the mandatory-to-implement | |||
mandatory-to-implement secure transport is Secure Shell (SSH) | secure transport is Secure Shell (SSH) [RFC6242]. The lowest | |||
RESTCONF layer is HTTPS, and the mandatory-to-implement secure | ||||
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- | transport is TLS [RFC8446]. | |||
implement secure transport is TLS [RFC8446]. | ||||
The NETCONF access control model [RFC8341] provides the means to | The NETCONF access control model [RFC8341] provides the means to | |||
restrict access for particular NETCONF or RESTCONF users to a | restrict access for particular NETCONF or RESTCONF users to a | |||
preconfigured subset of all available NETCONF or RESTCONF protocol | preconfigured subset of all available NETCONF or RESTCONF protocol | |||
operations and content. | operations and content. | |||
Security considerations specific to each of the technologies and | Security considerations specific to each of the technologies and | |||
protocols listed in the document are discussed in the specification | protocols listed in the document are discussed in the specification | |||
documents of each of these protocols. | documents of each of these protocols. | |||
In order to prevent leaking sensitive information and the "confused | In order to prevent leaking sensitive information and the "confused | |||
deputy" problem [Hardy] in general, special care should be considered | deputy" problem [Hardy] in general, special care should be considered | |||
when translating between the various layers in Section 4 or when | when translating between the various layers in Section 4 or when | |||
aggregating data retrieved from various sources. Authorization and | aggregating data retrieved from various sources. Authorization and | |||
authentication checks should be performed to ensure that a data is | authentication checks should be performed to ensure that data is | |||
available to an authorized entity. The network operator must enforce | available to an authorized entity. The network operator must enforce | |||
means to protect privacy-related information included in customer- | means to protect privacy-related information included in customer- | |||
facing models. | facing models. | |||
To detect misalignment between layers that might be induced by | To detect misalignment between layers that might be induced by | |||
misbehaving nodes, upper layers should continuously monitor the | misbehaving nodes, upper layers should continuously monitor the | |||
perceived service (Section 4.1.4) and should proceed with checks to | perceived service (Section 4.1.4) and should proceed with checks to | |||
assess that the provided service complies with the expected service | assess that the provided service complies with the expected service | |||
and that the data reported by an underlying layer is matching the | and that the data reported by an underlying layer is matching the | |||
perceived service by the above layer. Such checks are the | perceived service by the above layer. Such checks are the | |||
skipping to change at page 25, line 46 ¶ | skipping to change at line 1132 ¶ | |||
service assurance to track the correct functioning of the security | service assurance to track the correct functioning of the security | |||
mechanisms. | mechanisms. | |||
Additional considerations are discussed in the following subsections. | Additional considerations are discussed in the following subsections. | |||
6.1. Service Level | 6.1. Service Level | |||
A provider may rely on services offered by other providers to build | A provider may rely on services offered by other providers to build | |||
composite services. Appropriate mechanisms should be enabled by the | composite services. Appropriate mechanisms should be enabled by the | |||
provider to monitor and detect a service disruption from these | provider to monitor and detect a service disruption from these | |||
providers. The characterization of a service disruption (including, | providers. The characterization of a service disruption (including | |||
mean time between failures, mean time to repair), the escalation | mean time between failures and mean time to repair), the escalation | |||
procedure, and penalties are usually documented in contractual | procedure, and penalties are usually documented in contractual | |||
agreements (e.g., as described in Section 2.1 of [RFC4176]). | agreements (e.g., as described in Section 2.1 of [RFC4176]). | |||
Misbehaving peer providers will thus be identified and appropriate | Misbehaving peer providers will thus be identified and appropriate | |||
countermeasures will be applied. | countermeasures will be applied. | |||
The communication protocols that make use of a service model between | The communication protocols that make use of a service model between | |||
a customer and an operator are out of scope. Relevant security | a customer and an operator are out of scope. Relevant security | |||
considerations should be discussed in the specification documents of | considerations should be discussed in the specification documents of | |||
these protocols. | these protocols. | |||
6.2. Network Level | 6.2. Network Level | |||
Security considerations specific to the network level are listed | Security considerations specific to the network level are listed | |||
below: | below: | |||
o A controller may create forwarding loops by mis-configuring the | * A controller may create forwarding loops by misconfiguring the | |||
underlying network nodes. It is recommended to proceed with tests | underlying network nodes. It is recommended to proceed with tests | |||
to check the status of forwarding paths regularly or whenever | to check the status of forwarding paths regularly or whenever | |||
changes are made to routing or forwarding processes. Such checks | changes are made to routing or forwarding processes. Such checks | |||
may be triggered from the service level owing to the means | may be triggered from the service level owing to the means | |||
discussed in Section 4.1.5. | discussed in Section 4.1.5. | |||
o Some service models may include a traffic isolation clause that is | * Some service models may include a traffic isolation clause that is | |||
passed down to the network level so that appropriate technology- | passed down to the network level so that appropriate technology- | |||
specific actions must be enforced at the underlying network (and | specific actions must be enforced at the underlying network (and | |||
thus involved network devices) to avoid that such traffic is | thus involved network devices) to avoid that such traffic is | |||
accessible to non-authorized parties. In particular, network | accessible to non-authorized parties. In particular, network | |||
models may indicate whether encryption is enabled and if so, | models may indicate whether encryption is enabled and, if so, | |||
expose a list of supported encryption schemes and parameters. | expose a list of supported encryption schemes and parameters. | |||
Refer for example to the encryption feature defined in | Refer, for example, to the encryption feature defined in | |||
[I-D.ietf-opsawg-vpn-common] and its use in | [OPSAWG-VPN-COMMON] and its use in [OPSAWG-L3SM-L3NM]. | |||
[I-D.ietf-opsawg-l3sm-l3nm]. | ||||
6.3. Device Level | 6.3. Device Level | |||
Network operators should monitor and audit their networks to detect | Network operators should monitor and audit their networks to detect | |||
misbehaving nodes and abnormal behaviors. For example, OAM discussed | misbehaving nodes and abnormal behaviors. For example, OAM, as | |||
in Section 4.1.5 can be used for that purpose. | discussed in Section 4.1.5, can be used for that purpose. | |||
Access to some data requires specific access privilege levels. | Access to some data requires specific access privilege levels. | |||
Devices must check that a required access privilege is provided | Devices must check that a required access privilege is provided | |||
before granting access to specific data or performing specific | before granting access to specific data or performing specific | |||
actions. | actions. | |||
7. IANA Considerations | 7. IANA Considerations | |||
There are no IANA requests or assignments included in this document. | This document has no IANA actions. | |||
8. Acknowledgements | ||||
Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter, | ||||
Adrian Farrel, Christian Huitema, Tommy Pauly, Ines Robles, and | ||||
Olivier Augizeau for the review. | ||||
Many thanks to Robert Wilton for the detailed AD review. | ||||
Thanks to Eric Vyncke, Roman Danyliw, Erik Kline, and Benjamin Kaduk | ||||
for the IESG review. | ||||
9. Contributors | ||||
Christian Jacquenet | ||||
Orange | ||||
Rennes, 35000 | ||||
France | ||||
Email: Christian.jacquenet@orange.com | ||||
Luis Miguel Contreras Murillo | ||||
Telifonica | ||||
Email: luismiguel.contrerasmurillo@telefonica.com | ||||
Oscar Gonzalez de Dios | ||||
Telefonica | ||||
Madrid | ||||
ES | ||||
Email: oscar.gonzalezdedios@telefonica.com | ||||
Weiqiang Cheng | ||||
China Mobile | ||||
Email: chengweiqiang@chinamobile.com | ||||
Young Lee | ||||
Sung Kyun Kwan University | ||||
Email: younglee.tx@gmail.com | ||||
10. References | 8. References | |||
10.1. Normative References | 8.1. Normative References | |||
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | |||
and A. Bierman, Ed., "Network Configuration Protocol | and A. Bierman, Ed., "Network Configuration Protocol | |||
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | |||
<https://www.rfc-editor.org/info/rfc6241>. | <https://www.rfc-editor.org/info/rfc6241>. | |||
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | |||
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | |||
<https://www.rfc-editor.org/info/rfc6242>. | <https://www.rfc-editor.org/info/rfc6242>. | |||
skipping to change at page 28, line 22 ¶ | skipping to change at line 1211 ¶ | |||
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration | |||
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 | 8.2. Informative References | |||
[Hardy] Hardy, N., "The Confused Deputy: (or why capabilities | ||||
might have been invented)", October 1988, | ||||
<https://dl.acm.org/doi/10.1145/54289.871709>. | ||||
[I-D.clacla-netmod-model-catalog] | ||||
Clarke, J. and B. Claise, "YANG module for | ||||
yangcatalog.org", draft-clacla-netmod-model-catalog-03 | ||||
(work in progress), April 2018. | ||||
[I-D.ietf-bess-evpn-yang] | ||||
Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., | ||||
and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- | ||||
bess-evpn-yang-07 (work in progress), March 2019. | ||||
[I-D.ietf-bess-l2vpn-yang] | ||||
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., | ||||
and K. Tiruveedhula, "YANG Data Model for MPLS-based | ||||
L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), | ||||
July 2019. | ||||
[I-D.ietf-bess-l3vpn-yang] | ||||
Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., | ||||
Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model | ||||
for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work | ||||
in progress), October 2018. | ||||
[I-D.ietf-bess-mvpn-yang] | [ACTN-VN-YANG] | |||
Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and | Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. | |||
M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP | Yoon, "A YANG Data Model for VN Operation", Work in | |||
IP VPNs", draft-ietf-bess-mvpn-yang-04 (work in progress), | Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-10, | |||
June 2020. | 2 November 2020, <https://tools.ietf.org/html/draft-ietf- | |||
teas-actn-vn-yang-10>. | ||||
[I-D.ietf-bfd-yang] | [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)", Work in Progress, Internet- | |||
in progress), August 2018. | Draft, draft-ietf-bfd-yang-17, 2 August 2018, | |||
<https://tools.ietf.org/html/draft-ietf-bfd-yang-17>. | ||||
[I-D.ietf-dots-rfc8782-bis] | [DOTS-DDOS] | |||
Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed | Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed | |||
Denial-of-Service Open Threat Signaling (DOTS) Signal | Denial-of-Service Open Threat Signaling (DOTS) Signal | |||
Channel Specification", draft-ietf-dots-rfc8782-bis-01 | Channel Specification", Work in Progress, Internet-Draft, | |||
(work in progress), September 2020. | draft-ietf-dots-rfc8782-bis-04, 3 December 2020, | |||
<https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis- | ||||
[I-D.ietf-i2rs-yang-l2-network-topology] | 04>. | |||
Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A | ||||
YANG Data Model for Layer 2 Network Topologies", draft- | ||||
ietf-i2rs-yang-l2-network-topology-18 (work in progress), | ||||
September 2020. | ||||
[I-D.ietf-idr-bgp-model] | ||||
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP | ||||
YANG Model for Service Provider Networks", draft-ietf-idr- | ||||
bgp-model-09 (work in progress), June 2020. | ||||
[I-D.ietf-ippm-capacity-metric-method] | ||||
Morton, A., Geib, R., and L. Ciavattone, "Metrics and | ||||
Methods for One-way IP Capacity", draft-ietf-ippm- | ||||
capacity-metric-method-04 (work in progress), September | ||||
2020. | ||||
[I-D.ietf-ippm-stamp-yang] | ||||
Mirsky, G., Min, X., and W. Luo, "Simple Two-way Active | ||||
Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- | ||||
stamp-yang-06 (work in progress), October 2020. | ||||
[I-D.ietf-ippm-twamp-yang] | ||||
Civil, R., Morton, A., Rahman, R., Jethanandani, M., and | ||||
K. Pentikousis, "Two-Way Active Measurement Protocol | ||||
(TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work | ||||
in progress), July 2018. | ||||
[I-D.ietf-mpls-base-yang] | ||||
Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A | ||||
YANG Data Model for MPLS Base", draft-ietf-mpls-base- | ||||
yang-16 (work in progress), October 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] | ||||
barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. | ||||
Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- | ||||
opsawg-l3sm-l3nm-05 (work in progress), October 2020. | ||||
[I-D.ietf-opsawg-vpn-common] | [EVENT-YANG] | |||
barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer | Wu, Q., Bryskin, I., Birkholz, H., Liu, X., and B. Claise, | |||
2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- | "A YANG Data model for ECA Policy Management", Work in | |||
common-01 (work in progress), September 2020. | Progress, Internet-Draft, draft-wwx-netmod-event-yang-10, | |||
1 November 2020, <https://tools.ietf.org/html/draft-wwx- | ||||
netmod-event-yang-10>. | ||||
[I-D.ietf-pim-igmp-mld-snooping-yang] | [EVPN-YANG] | |||
Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, | Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., | |||
"A Yang Data Model for IGMP and MLD Snooping", draft-ietf- | and J. Rabadan, "Yang Data Model for EVPN", Work in | |||
pim-igmp-mld-snooping-yang-18 (work in progress), August | Progress, Internet-Draft, draft-ietf-bess-evpn-yang-07, 11 | |||
2020. | March 2019, <https://tools.ietf.org/html/draft-ietf-bess- | |||
evpn-yang-07>. | ||||
[I-D.ietf-pim-yang] | [Hardy] Hardy, N., "The Confused Deputy: (or why capabilities | |||
Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, | might have been invented)", DOI 10.1145/54289.871709, | |||
Y., and f. hu, "A YANG Data Model for Protocol Independent | October 1988, | |||
Multicast (PIM)", draft-ietf-pim-yang-17 (work in | <https://dl.acm.org/doi/10.1145/54289.871709>. | |||
progress), May 2018. | ||||
[I-D.ietf-rtgwg-policy-model] | [IDR-BGP-MODEL] | |||
Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data | Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP | |||
Model for Routing Policy Management", draft-ietf-rtgwg- | YANG Model for Service Provider Networks", Work in | |||
policy-model-26 (work in progress), October 2020. | Progress, Internet-Draft, draft-ietf-idr-bgp-model-10, 15 | |||
November 2020, | ||||
<https://tools.ietf.org/html/draft-ietf-idr-bgp-model-10>. | ||||
[I-D.ietf-rtgwg-qos-model] | [IPPM] IANA, "Performance Metrics", March 2020, | |||
Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., | <https://www.iana.org/assignments/performance-metrics/ | |||
and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- | performance-metrics.xhtml>. | |||
model-02 (work in progress), July 2020. | ||||
[I-D.ietf-spring-sr-yang] | [L2VPN-YANG] | |||
Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. | Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., | |||
Tantsura, "YANG Data Model for Segment Routing", draft- | and K. Tiruveedhula, "YANG Data Model for MPLS-based | |||
ietf-spring-sr-yang-22 (work in progress), August 2020. | L2VPN", Work in Progress, Internet-Draft, draft-ietf-bess- | |||
l2vpn-yang-10, 2 July 2019, <https://tools.ietf.org/html/ | ||||
draft-ietf-bess-l2vpn-yang-10>. | ||||
[I-D.ietf-teas-actn-pm-telemetry-autonomics] | [L3VPN-YANG] | |||
Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., | Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., | |||
and D. Ceccarelli, "YANG models for VN/TE Performance | Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model | |||
Monitoring Telemetry and Scaling Intent Autonomics", | for BGP/MPLS L3 VPNs", Work in Progress, Internet-Draft, | |||
draft-ietf-teas-actn-pm-telemetry-autonomics-03 (work in | draft-ietf-bess-l3vpn-yang-04, 19 October 2018, | |||
progress), July 2020. | <https://tools.ietf.org/html/draft-ietf-bess-l3vpn-yang- | |||
04>. | ||||
[I-D.ietf-teas-actn-vn-yang] | [METRIC-METHOD] | |||
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. | Morton, A., Geib, R., and L. Ciavattone, "Metrics and | |||
Yoon, "A YANG Data Model for VN Operation", draft-ietf- | Methods for One-way IP Capacity", Work in Progress, | |||
teas-actn-vn-yang-09 (work in progress), July 2020. | Internet-Draft, draft-ietf-ippm-capacity-metric-method-04, | |||
10 September 2020, <https://tools.ietf.org/html/draft- | ||||
ietf-ippm-capacity-metric-method-04>. | ||||
[I-D.ietf-teas-yang-path-computation] | [MVPN-YANG] | |||
Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, | Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and | |||
"Yang model for requesting Path Computation", draft-ietf- | M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP | |||
teas-yang-path-computation-10 (work in progress), July | IP VPNs", Work in Progress, Internet-Draft, draft-ietf- | |||
2020. | bess-mvpn-yang-04, 30 June 2020, | |||
<https://tools.ietf.org/html/draft-ietf-bess-mvpn-yang- | ||||
04>. | ||||
[I-D.ietf-teas-yang-rsvp-te] | [NETMOD-MODEL] | |||
Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., | Clarke, J. and B. Claise, "YANG module for | |||
and H. Shah, "A YANG Data Model for RSVP-TE Protocol", | yangcatalog.org", Work in Progress, Internet-Draft, draft- | |||
draft-ietf-teas-yang-rsvp-te-08 (work in progress), March | clacla-netmod-model-catalog-03, 3 April 2018, | |||
2020. | <https://tools.ietf.org/html/draft-clacla-netmod-model- | |||
catalog-03>. | ||||
[I-D.ietf-teas-yang-te] | [OPSAWG-L2NM] | |||
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, | Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., | |||
"A YANG Data Model for Traffic Engineering Tunnels, Label | Jalil, L., and J. Ma, "A Layer 2 VPN Network YANG Model", | |||
Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 | Work in Progress, Internet-Draft, draft-ietf-opsawg-l2nm- | |||
(work in progress), July 2020. | 01, 2 November 2020, | |||
<https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-01>. | ||||
[I-D.ietf-trill-yang-oam] | [OPSAWG-L3SM-L3NM] | |||
Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., | Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., | |||
and H. Weiguo, "YANG Data Model for TRILL Operations, | and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in | |||
Administration, and Maintenance (OAM)", draft-ietf-trill- | Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-05, | |||
yang-oam-05 (work in progress), March 2017. | 16 October 2020, <https://tools.ietf.org/html/draft-ietf- | |||
opsawg-l3sm-l3nm-05>. | ||||
[I-D.ogondio-opsawg-uni-topology] | [OPSAWG-VPN-COMMON] | |||
Dios, O., barguil, s., WU, Q., and M. Boucadair, "A YANG | Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A | |||
Model for User-Network Interface (UNI) Topologies", draft- | Layer 2/3 VPN Common YANG Model", Work in Progress, | |||
ogondio-opsawg-uni-topology-01 (work in progress), April | Internet-Draft, draft-ietf-opsawg-vpn-common-03, 14 | |||
2020. | January 2021, <https://tools.ietf.org/html/draft-ietf- | |||
opsawg-vpn-common-03>. | ||||
[I-D.www-opsawg-yang-vpn-service-pm] | [OPSAWG-YANG-VPN] | |||
Bo, W., WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., | Wu, B., Wu, Q., Boucadair, M., Dios, O. G. D., Wen, B., | |||
and H. Xu, "A YANG Model for Network and VPN Service | Liu, C., and H. Xu, "A YANG Model for Network and VPN | |||
Performance Monitoring", draft-www-opsawg-yang-vpn- | Service Performance Monitoring", Work in Progress, | |||
service-pm-01 (work in progress), July 2020. | Internet-Draft, draft-www-opsawg-yang-vpn-service-pm-03, | |||
21 January 2021, <https://tools.ietf.org/html/draft-www- | ||||
opsawg-yang-vpn-service-pm-03>. | ||||
[I-D.wwx-netmod-event-yang] | [PIM-YANG] Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, | |||
Bierman, A., WU, Q., Bryskin, I., Birkholz, H., Liu, X., | Y., and F. Hu, "A YANG Data Model for Protocol Independent | |||
and B. Claise, "A YANG Data model for ECA Policy | Multicast (PIM)", Work in Progress, Internet-Draft, draft- | |||
Management", draft-wwx-netmod-event-yang-09 (work in | ietf-pim-yang-17, 19 May 2018, | |||
progress), July 2020. | <https://tools.ietf.org/html/draft-ietf-pim-yang-17>. | |||
[IPPM] IANA, "Performance Metrics", March 2020, | [QOS-MODEL] | |||
<https://www.iana.org/assignments/performance-metrics/ | Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., | |||
performance-metrics.xhtml>. | and I. Chen, "YANG Model for QoS", Work in Progress, | |||
Internet-Draft, draft-ietf-rtgwg-qos-model-02, 9 July | ||||
2020, <https://tools.ietf.org/html/draft-ietf-rtgwg-qos- | ||||
model-02>. | ||||
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., | [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., | |||
and A. Gonguet, "Framework for Layer 3 Virtual Private | and A. Gonguet, "Framework for Layer 3 Virtual Private | |||
Networks (L3VPN) Operations and Management", RFC 4176, | Networks (L3VPN) Operations and Management", RFC 4176, | |||
DOI 10.17487/RFC4176, October 2005, | DOI 10.17487/RFC4176, October 2005, | |||
<https://www.rfc-editor.org/info/rfc4176>. | <https://www.rfc-editor.org/info/rfc4176>. | |||
[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>. | |||
skipping to change at page 37, line 15 ¶ | skipping to change at line 1571 ¶ | |||
[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>. | |||
[RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data | [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data | |||
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, | Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, | |||
June 2020, <https://www.rfc-editor.org/info/rfc8791>. | June 2020, <https://www.rfc-editor.org/info/rfc8791>. | |||
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and | [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and | |||
O. Gonzalez de Dios, "YANG Data Model for Traffic | O. Gonzalez de Dios, "YANG Data Model for Traffic | |||
Engineering (TE) Topologies", RFC 8795, | Engineering (TE) Topologies", RFC 8795, | |||
DOI 10.17487/RFC8795, August 2020, | DOI 10.17487/RFC8795, August 2020, | |||
<https://www.rfc-editor.org/info/rfc8795>. | <https://www.rfc-editor.org/info/rfc8795>. | |||
Appendix A. Layered YANG Modules Examples Overview | [RFC8819] Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module | |||
Tags", RFC 8819, DOI 10.17487/RFC8819, January 2021, | ||||
<https://www.rfc-editor.org/info/rfc8819>. | ||||
[RFC8944] Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A | ||||
YANG Data Model for Layer 2 Network Topologies", RFC 8944, | ||||
DOI 10.17487/RFC8944, November 2020, | ||||
<https://www.rfc-editor.org/info/rfc8944>. | ||||
[RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A | ||||
YANG Data Model for MPLS Base", RFC 8960, | ||||
DOI 10.17487/RFC8960, December 2020, | ||||
<https://www.rfc-editor.org/info/rfc8960>. | ||||
[RTGWG-POLICY] | ||||
Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data | ||||
Model for Routing Policy", Work in Progress, Internet- | ||||
Draft, draft-ietf-rtgwg-policy-model-27, 10 January 2021, | ||||
<https://tools.ietf.org/html/draft-ietf-rtgwg-policy- | ||||
model-27>. | ||||
[SNOOPING-YANG] | ||||
Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, | ||||
"A Yang Data Model for IGMP and MLD Snooping", Work in | ||||
Progress, Internet-Draft, draft-ietf-pim-igmp-mld- | ||||
snooping-yang-18, 14 August 2020, | ||||
<https://tools.ietf.org/html/draft-ietf-pim-igmp-mld- | ||||
snooping-yang-18>. | ||||
[SPRING-SR-YANG] | ||||
Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. | ||||
Tantsura, "YANG Data Model for Segment Routing", Work in | ||||
Progress, Internet-Draft, draft-ietf-spring-sr-yang-29, 8 | ||||
December 2020, <https://tools.ietf.org/html/draft-ietf- | ||||
spring-sr-yang-29>. | ||||
[STAMP-YANG] | ||||
Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active | ||||
Measurement Protocol (STAMP) Data Model", Work in | ||||
Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-06, 7 | ||||
October 2020, <https://tools.ietf.org/html/draft-ietf- | ||||
ippm-stamp-yang-06>. | ||||
[TEAS-ACTN-PM] | ||||
Lee, Y., Dhody, D., Karunanithi, S., Vilalta, R., King, | ||||
D., and D. Ceccarelli, "YANG models for VN/TE Performance | ||||
Monitoring Telemetry and Scaling Intent Autonomics", Work | ||||
in Progress, Internet-Draft, draft-ietf-teas-actn-pm- | ||||
telemetry-autonomics-04, 2 November 2020, | ||||
<https://tools.ietf.org/html/draft-ietf-teas-actn-pm- | ||||
telemetry-autonomics-04>. | ||||
[TEAS-YANG-PATH-COMP] | ||||
Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, | ||||
"Yang model for requesting Path Computation", Work in | ||||
Progress, Internet-Draft, draft-ietf-teas-yang-path- | ||||
computation-11, 16 November 2020, | ||||
<https://tools.ietf.org/html/draft-ietf-teas-yang-path- | ||||
computation-11>. | ||||
[TEAS-YANG-RSVP] | ||||
Beeram, V. P., Saad, T., Gandhi, R., Liu, X., Bryskin, I., | ||||
and H. Shah, "A YANG Data Model for RSVP-TE Protocol", | ||||
Work in Progress, Internet-Draft, draft-ietf-teas-yang- | ||||
rsvp-te-08, 9 March 2020, <https://tools.ietf.org/html/ | ||||
draft-ietf-teas-yang-rsvp-te-08>. | ||||
[TEAS-YANG-TE] | ||||
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I. | ||||
Bryskin, "A YANG Data Model for Traffic Engineering | ||||
Tunnels, Label Switched Paths and Interfaces", Work in | ||||
Progress, Internet-Draft, draft-ietf-teas-yang-te-25, 27 | ||||
July 2020, | ||||
<https://tools.ietf.org/html/draft-ietf-teas-yang-te-25>. | ||||
[TRILL-YANG-OAM] | ||||
Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., | ||||
and W. Hao, "YANG Data Model for TRILL Operations, | ||||
Administration, and Maintenance (OAM)", Work in Progress, | ||||
Internet-Draft, draft-ietf-trill-yang-oam-05, 31 March | ||||
2017, <https://tools.ietf.org/html/draft-ietf-trill-yang- | ||||
oam-05>. | ||||
[TWAMP-DATA-MODEL] | ||||
Civil, R., Morton, A., Rahman, R., Jethanandani, M., and | ||||
K. Pentikousis, "Two-Way Active Measurement Protocol | ||||
(TWAMP) Data Model", Work in Progress, Internet-Draft, | ||||
draft-ietf-ippm-twamp-yang-13, 2 July 2018, | ||||
<https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang- | ||||
13>. | ||||
[UNI-TOPOLOGY] | ||||
Dios, O. G. D., Barguil, S., Wu, Q., and M. Boucadair, "A | ||||
YANG Model for User-Network Interface (UNI) Topologies", | ||||
Work in Progress, Internet-Draft, draft-ogondio-opsawg- | ||||
uni-topology-01, 2 April 2020, | ||||
<https://tools.ietf.org/html/draft-ogondio-opsawg-uni- | ||||
topology-01>. | ||||
Appendix A. Layered YANG Module Examples Overview | ||||
This appendix lists a set of YANG data models that can be used for | This appendix lists a set of YANG data models that can be used for | |||
the delivery of connectivity services. These models can be | the delivery of connectivity services. These models can be | |||
classified as 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 | The reader may refer to the YANG Catalog | |||
(<https://www.yangcatalog.org>) or the public Github YANG repository | (<https://www.yangcatalog.org>) or the public Github YANG repository | |||
(<https://github.com/YangModels/yang>) to query existing YANG models. | (<https://github.com/YangModels/yang>) to query existing YANG models. | |||
The YANG Catalog includes some metadata to indicate the module type | The YANG Catalog includes some metadata to indicate the module type | |||
('module-classification') [I-D.clacla-netmod-model-catalog]. Note | ('module-classification') [NETMOD-MODEL]. Note that the mechanism | |||
that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to | defined in [RFC8819] allows to associate tags with YANG modules in | |||
associate tags with YANG modules in order to help classifying the | order to help classifying the modules. | |||
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 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 | |||
(expressed in terms of QoS, performance, and availability, for | (expressed, for example, in terms of QoS, performance, and | |||
example) to properly forward traffic to the said "Destination" | availability) to properly forward traffic to the said "Destination" | |||
[RFC7297]. | [RFC7297]. The "Scope" denotes the network perimeter (e.g., between | |||
Provider Edge (PE) routers or Customer Nodes) where the said | ||||
guarantees need to be provided. | ||||
For example: | For example: | |||
o The L3SM [RFC8299] defines the L3VPN service ordered by a customer | * The L3SM [RFC8299] defines the L3VPN service ordered by a customer | |||
from a network operator. | from a network operator. | |||
o The L2SM [RFC8466] defines the L2VPN service ordered by a customer | * The L2SM [RFC8466] defines the L2VPN service ordered by a customer | |||
from a network operator. | from a network operator. | |||
o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang] | * The Virtual Network (VN) model [ACTN-VN-YANG] provides a YANG data | |||
provides a YANG data model applicable to any mode of VN operation. | 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. Schema Mount | A.2. Schema Mount | |||
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. | |||
A.3. Network Models: Samples | A.3. Network Models: Samples | |||
L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are | L2NM [OPSAWG-L2NM] and L3NM [OPSAWG-L3SM-L3NM] are examples of YANG | |||
examples of YANG network models. | 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 Topologies| | +------+ +-----------+ | | | |Network Topologies| | +------+ +-----------+ | | |||
| | Model | | |Other | | TE Tunnel | | | | | Model | | |Other | | TE Tunnel | | | |||
skipping to change at page 39, line 30 ¶ | skipping to change at line 1771 ¶ | |||
| | +---------+ | | | | | +---------+ | | | |||
| +---+TE | | | | | +---+TE | | | | |||
| | |Topology | | | | | | |Topology | | | | |||
| | +---------+ | | | | | +---------+ | | | |||
| | +---------+ | | | | | +---------+ | | | |||
| +---+Layer 3 | | | | | +---+Layer 3 | | | | |||
| |Topology | | | | | |Topology | | | | |||
| +---------+ | | | | +---------+ | | | |||
+-------------------------------+-------------------------------+ | +-------------------------------+-------------------------------+ | |||
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 Topologies Model: [RFC8345] defines a base model for | Network Topologies Model: | |||
network topology and inventories. Network topology data include | [RFC8345] defines a base model for network topology and | |||
link, node, and terminate-point resources. | inventories. Network topology data includes link, node, and | |||
terminate-point resources. | ||||
o TE Topology Model: [RFC8795] defines a YANG data model for | ||||
representing and manipulating TE topologies. | ||||
This module is extended from network topology model defined in | TE Topology Model: | |||
[RFC8345] with TE topologies related content. This model contains | [RFC8795] defines a YANG data model for representing and | |||
technology-agnostic TE Topology building blocks that can be | manipulating TE topologies. | |||
augmented and used by other technology-specific TE topology | ||||
models. | ||||
o Layer 3 Topology Model: | This module is extended from the network topology model defined in | |||
[RFC8345] and includes content related to TE topologies. This | ||||
model contains technology-agnostic TE topology building blocks | ||||
that can be augmented and used by other technology-specific TE | ||||
topology models. | ||||
Layer 3 Topology Model: | ||||
[RFC8346] defines a YANG data model for representing and | [RFC8346] defines a YANG data model for representing and | |||
manipulating Layer 3 topologies. This model is extended from the | manipulating Layer 3 topologies. This model is extended from the | |||
network topology model defined in [RFC8345] with Layer 3 | network topology model defined in [RFC8345] and includes content | |||
topologies specifics. | related to Layer 3 topology specifics. | |||
o Layer 2 Topology Model: | ||||
[I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model | Layer 2 Topology Model: | |||
for representing and manipulating Layer 2 topologies. This model | [RFC8944] defines a YANG data model for representing and | |||
is extended from the network topology model defined in [RFC8345] | manipulating Layer 2 topologies. This model is extended from the | |||
with Layer 2 topology specifics. | network topology model defined in [RFC8345] and includes content | |||
related to Layer 2 topology specifics. | ||||
Examples of tunnel YANG modules are provided below: | Examples of tunnel YANG modules are provided below: | |||
o Tunnel identities: [RFC8675] defines a collection of YANG | Tunnel Identities: | |||
identities used as interface types for tunnel interfaces. | [RFC8675] defines a collection of YANG identities used as | |||
interface types for tunnel interfaces. | ||||
o TE Tunnel Model: | ||||
[I-D.ietf-teas-yang-te] defines a YANG module for the | ||||
configuration and management of TE interfaces, tunnels, and LSPs. | ||||
o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model: | ||||
[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. | ||||
o MPLS-TE Model: | TE Tunnel Model: | |||
[TEAS-YANG-TE] defines a YANG module for the configuration and | ||||
management of TE interfaces, tunnels, and LSPs. | ||||
[I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE | Segment Routing (SR) Traffic Engineering (TE) Tunnel Model: | |||
model(s) and defines a YANG module for MPLS-TE configurations, | [TEAS-YANG-TE] augments the TE generic and MPLS-TE model(s) and | |||
state, RPC and notifications. | defines a YANG module for SR-TE-specific data. | |||
o RSVP-TE MPLS Model: | MPLS-TE Model: | |||
[TEAS-YANG-TE] augments the TE generic and MPLS-TE model(s) and | ||||
defines a YANG module for MPLS-TE configurations, state, RPC, and | ||||
notifications. | ||||
[I-D.ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module | RSVP-TE MPLS Model: | |||
with parameters to configure and manage signaling of MPLS RSVP-TE | [TEAS-YANG-RSVP] augments the RSVP-TE generic module with | |||
LSPs. | parameters to configure and manage signaling of MPLS RSVP-TE LSPs. | |||
Other sample network models are listed hereafter: | Other sample network models are listed hereafter: | |||
o Path Computation API Model: | Path Computation API Model: | |||
[TEAS-YANG-PATH-COMP] defines a YANG module for a stateless RPC | ||||
[I-D.ietf-teas-yang-path-computation] YANG module for a stateless | that complements the stateful solution defined in [TEAS-YANG-TE]. | |||
RPC which complements the stateful solution defined in | ||||
[I-D.ietf-teas-yang-te]. | ||||
o OAM Models (including Fault Management (FM) and Performance | ||||
Monitoring): | ||||
OAM Models (including Fault Management (FM) and Performance | ||||
Monitoring): | ||||
[RFC8532] defines a base YANG module for the management of OAM | [RFC8532] defines a base YANG module for the management of OAM | |||
protocols that use Connectionless Communications. [RFC8533] | protocols that use Connectionless Communications. [RFC8533] | |||
defines a retrieval method YANG module for connectionless OAM | defines a retrieval method YANG module for connectionless OAM | |||
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 connectionless 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. | |||
A.4. Device Models: Samples | A.4. Device Models: Samples | |||
Network Element models (listed in Figure 10) are used to describe how | Network Element models (listed in Figure 10) are used to describe how | |||
a service can be implemented by activating and tweaking a set of | a service can be implemented by activating and tweaking a set of | |||
functions (enabled in one or multiple devices, or hosted in cloud | functions (enabled in one or multiple devices, or hosted in cloud | |||
infrastructures) that are involved in the service delivery. For | infrastructures) that are involved in the service delivery. For | |||
example, the L3VPN service will involve many PEs and require | example, the L3VPN service will involve many PEs and require | |||
manipulating the following modules: | manipulating the following modules: | |||
o Routing management [RFC8349] | * Routing management [RFC8349] | |||
o BGP [I-D.ietf-idr-bgp-model] | * BGP [IDR-BGP-MODEL] | |||
o PIM [I-D.ietf-pim-yang] | * PIM [PIM-YANG] | |||
o NAT management [RFC8512] | * NAT management [RFC8512] | |||
o QoS management [I-D.ietf-rtgwg-qos-model] | * QoS management [QOS-MODEL] | |||
o ACLs [RFC8519] | * ACLs [RFC8519] | |||
Figure 10 uses IETF-defined data 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 | | +------------------------+ | |||
skipping to change at page 42, line 52 ¶ | skipping to change at line 1916 ¶ | |||
| +-------+ | | +-------+ | |||
+-+SR/SRv6| | +-+SR/SRv6| | |||
| +-------+ | | +-------+ | |||
| +-------+ | | +-------+ | |||
+-+ISIS-SR| | +-+ISIS-SR| | |||
| +-------+ | | +-------+ | |||
| +-------+ | | +-------+ | |||
+-+OSPF-SR| | +-+OSPF-SR| | |||
+-------+ | +-------+ | |||
Figure 10: Network Element Modules Overview | Figure 10: Network Element Models Overview | |||
A.4.1. Model Composition | A.4.1. Model Composition | |||
o Logical Network Element Model | Logical Network Element Model: | |||
[RFC8530] defines a logical network element model that can be used | ||||
[RFC8530] defines a logical network element module which can be | to manage the logical resource partitioning that may be present on | |||
used to manage the logical resource partitioning that may be | a network device. Examples of common industry terms for logical | |||
present on a network device. Examples of common industry terms | resource partitioning are Logical Systems or Logical Routers. | |||
for logical resource partitioning are Logical Systems or Logical | ||||
Routers. | ||||
o Network Instance Model | ||||
Network Instance Model: | ||||
[RFC8529] defines a network instance module. This module can be | [RFC8529] defines a network instance module. This module can be | |||
used to manage the virtual resource partitioning that may be | used to manage the virtual 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 virtual resource partitioning are VRF instances and Virtual | for virtual resource partitioning are VRF instances and Virtual | |||
Switch Instances (VSIs). | Switch Instances (VSIs). | |||
A.4.2. Device Management | A.4.2. Device Management | |||
The following list enumerates some YANG modules that can be used for | The following list enumerates some YANG modules that can be used for | |||
device management: | device management: | |||
o [RFC8348]: defines a YANG module for the management of hardware. | * [RFC8348] defines a YANG module for the management of hardware. | |||
o [RFC7317]: defines the "ietf-system" YANG module that provides | * [RFC7317] defines the "ietf-system" YANG module that provides many | |||
many features such as the configuration and the monitoring of | features such as the configuration and the monitoring of system or | |||
system or system control operations (e.g., shutdown, restart, | system control operations (e.g., shutdown, restart, and setting | |||
setting time) identification. | time) identification. | |||
o [RFC8341]: defines a network configuration access control YANG | * [RFC8341] defines a network configuration access control YANG | |||
module. | module. | |||
A.4.3. Interface Management | A.4.3. Interface Management | |||
The following provides some YANG modules that can be used for | The following provides some YANG modules that can be used for | |||
interface management: | interface management: | |||
o [RFC7224]: defines a YANG module for interface type definitions. | * [RFC7224] defines a YANG module for interface type definitions. | |||
o [RFC8343]: defines a YANG module for the management of network | * [RFC8343] defines a YANG module for the management of network | |||
interfaces. | interfaces. | |||
A.4.4. Some Device Model Examples | A.4.4. Some Device Model Examples | |||
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. | |||
L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS | L2VPN: | |||
based Layer 2 VPN services (L2VPN) [RFC4664] and includes | [L2VPN-YANG] defines a YANG module for MPLS-based Layer 2 VPN | |||
switching between the local attachment circuits. The | services (L2VPN) [RFC4664] and includes switching between the | |||
L2VPN model covers point-to-point VPWS and Multipoint VPLS | local attachment circuits. The L2VPN model covers point-to-point | |||
services. These services use signaling of Pseudowires | Virtual Private Wire Service (VPWS) and Multipoint Virtual Private | |||
across MPLS networks using LDP [RFC8077][RFC4762] or BGP | LAN Service (VPLS). These services use signaling of Pseudowires | |||
[RFC4761]. | across MPLS networks using LDP [RFC8077][RFC4762] or BGP | |||
[RFC4761]. | ||||
EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for | EVPN: | |||
Ethernet VPN services. The model is agnostic of the | [EVPN-YANG] defines a YANG module for Ethernet VPN services. The | |||
underlay. It applies to MPLS as well as to VxLAN | model is agnostic of the underlay. It applies to MPLS as well as | |||
encapsulation. The module is also agnostic to the | to Virtual eXtensible Local Area Network (VxLAN) encapsulation. | |||
services, including E-LAN, E-LINE, and E-TREE services. | The module is also agnostic to the services, including E-LAN, | |||
E-LINE, and E-TREE services. | ||||
L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can | L3VPN: | |||
be used to configure and manage BGP L3VPNs [RFC4364]. It | [L3VPN-YANG] defines a YANG module that can be used to configure | |||
contains VRF specific parameters as well as BGP specific | and manage BGP L3VPNs [RFC4364]. It contains VRF-specific | |||
parameters applicable for L3VPNs. | parameters as well as BGP-specific parameters applicable for | |||
L3VPNs. | ||||
Core Routing: [RFC8349] defines the core routing YANG data model, | Core Routing: | |||
which is intended as a basis for future data model | [RFC8349] defines the core routing YANG data model, which is | |||
development covering more-sophisticated routing systems. | intended as a basis for future data model development covering | |||
It is expected that other Routing technology YANG modules | more-sophisticated routing systems. It is expected that other | |||
(e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core | Routing technology YANG modules (e.g., VRRP, RIP, ISIS, or OSPF | |||
Routing base YANG module. | models) will augment the Core Routing base YANG module. | |||
MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS | MPLS: | |||
which serves as a base framework for configuring and | [RFC8960] defines a base model for MPLS that serves as a base | |||
managing an MPLS switching subsystem. It is expected that | framework for configuring and managing an MPLS switching | |||
other MPLS technology YANG modules (e.g., MPLS LSP Static, | subsystem. It is expected that other MPLS technology YANG modules | |||
LDP, or RSVP-TE models) will augment the MPLS base YANG | (e.g., MPLS LSP Static, LDP, or RSVP-TE models) will augment the | |||
module. | MPLS base YANG module. | |||
BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for | BGP: | |||
configuring and managing BGP, including protocol, policy, | [IDR-BGP-MODEL] defines a YANG module for configuring and managing | |||
and operational aspects based on data center, carrier, and | BGP, including protocol, policy, and operational aspects based on | |||
content provider operational requirements. | data center, carrier, and content provider operational | |||
requirements. | ||||
Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module | Routing Policy: | |||
for configuring and managing routing policies based on | [RTGWG-POLICY] defines a YANG module for configuring and managing | |||
operational practice. The module provides a generic | routing policies based on operational practice. The module | |||
policy framework which can be augmented with protocol- | provides a generic policy framework that can be augmented with | |||
specific policy configuration. | protocol-specific policy configuration. | |||
SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment | SR/SRv6: | |||
routing configuration and operation. | [SPRING-SR-YANG] defines a YANG module for segment routing | |||
configuration and operation. | ||||
BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a | BFD: | |||
network protocol which is used for liveness detection of | Bidirectional Forwarding Detection (BFD) [RFC5880] is a network | |||
arbitrary paths between systems. [I-D.ietf-bfd-yang] | protocol that is used for liveness detection of arbitrary paths | |||
defines a YANG module that can be used to configure and | between systems. [BFD-YANG] defines a YANG module that can be | |||
manage BFD. | used to configure and manage BFD. | |||
Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used | Multicast: | |||
to configure and manage Protocol Independent Multicast | [PIM-YANG] defines a YANG module that can be used to configure and | |||
(PIM) devices. | manage Protocol Independent Multicast (PIM) devices. | |||
[RFC8652] defines a YANG module that can be used to | [RFC8652] defines a YANG module that can be used to configure and | |||
configure and manage Internet Group Management Protocol | manage Internet Group Management Protocol (IGMP) and Multicast | |||
(IGMP) and Multicast Listener Discovery (MLD) devices. | Listener Discovery (MLD) devices. | |||
[I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG | [SNOOPING-YANG] defines a YANG module that can be used to | |||
module that can be used to configure and manage Internet | configure and manage Internet Group Management Protocol (IGMP) and | |||
Group Management Protocol (IGMP) and Multicast Listener | Multicast Listener Discovery (MLD) snooping devices. | |||
Discovery (MLD) Snooping devices. | ||||
[I-D.ietf-bess-mvpn-yang] defines a YANG data model to | [MVPN-YANG] defines a YANG data model to configure and manage | |||
configure and manage Multicast in MPLS/BGP IP VPNs | Multicast in MPLS/BGP IP VPNs (MVPNs). | |||
(MVPNs). | ||||
PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for | PM: | |||
client and server implementations of the Two-Way Active | [TWAMP-DATA-MODEL] defines a YANG data model for client and server | |||
Measurement Protocol (TWAMP). | implementations of the Two-Way Active Measurement Protocol | |||
(TWAMP). | ||||
[I-D.ietf-ippm-stamp-yang] defines the data model for | [STAMP-YANG] defines the data model for implementations of | |||
implementations of Session-Sender and Session-Reflector | Session-Sender and Session-Reflector for Simple Two-way Active | |||
for Simple Two-way Active Measurement Protocol (STAMP) | Measurement Protocol (STAMP) mode using YANG. | |||
mode using YANG. | ||||
[RFC8194] defines a YANG data model for Large-Scale | [RFC8194] defines a YANG data model for Large-Scale Measurement | |||
Measurement Platforms (LMAPs). | Platforms (LMAPs). | |||
ACL: Access Control List (ACL) is one of the basic elements | ACL: | |||
used to configure device forwarding behavior. It is used | An Access Control List (ACL) is one of the basic elements used to | |||
in many networking technologies such as Policy Based | configure device-forwarding behavior. It is used in many | |||
Routing, firewalls, etc. [RFC8519] describes a YANG data | networking technologies such as Policy-Based Routing, firewalls, | |||
model of ACL basic building blocks. | etc. [RFC8519] describes a YANG data model of ACL basic building | |||
blocks. | ||||
QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of | QoS: | |||
Differentiated Services for configuration and operations. | [QOS-MODEL] describes a YANG module of Differentiated Services for | |||
configuration and operations. | ||||
NAT: For the sake of network automation and the need for | NAT: | |||
programming Network Address Translation (NAT) function in | For the sake of network automation and the need for programming | |||
particular, a YANG data model for configuring and managing | the Network Address Translation (NAT) function in particular, a | |||
the NAT is essential. | YANG data model for configuring and managing the NAT is essential. | |||
[RFC8512] defines a YANG module for the NAT function | [RFC8512] defines a YANG module for the NAT function covering a | |||
covering a variety of NAT flavors such as Network Address | variety of NAT flavors such as Network Address Translation from | |||
Translation from IPv4 to IPv4 (NAT44), Network Address and | IPv4 to IPv4 (NAT44), Network Address and Protocol Translation | |||
Protocol Translation from IPv6 Clients to IPv4 Servers | from IPv6 Clients to IPv4 Servers (NAT64), customer-side | |||
(NAT64), customer-side translator (CLAT), Stateless IP/ | translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit | |||
ICMP Translation (SIIT), Explicit Address Mappings (EAM) | Address Mappings (EAMs) for SIIT, IPv6-to-IPv6 Network Prefix | |||
for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), | Translation (NPTv6), and Destination NAT. | |||
and Destination NAT. | ||||
[RFC8513] specifies a DS-Lite YANG module. | [RFC8513] specifies a Dual-Stack Lite (DS-Lite) YANG module. | |||
Stateless Address Sharing: [RFC8676] specifies a YANG module for A+P | Stateless Address Sharing: | |||
address sharing, including Lightweight 4over6, Mapping of | [RFC8676] specifies a YANG module for Address plus Port (A+P) | |||
Address and Port with Encapsulation (MAP-E), and Mapping | address sharing, including Lightweight 4over6, Mapping of Address | |||
of Address and Port using Translation (MAP-T) softwire | and Port with Encapsulation (MAP-E), and Mapping of Address and | |||
mechanisms. | Port using Translation (MAP-T) softwire mechanisms. | |||
Acknowledgements | ||||
Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter, | ||||
Adrian Farrel, Christian Huitema, Tommy Pauly, Ines Robles, and | ||||
Olivier Augizeau for the review. | ||||
Many thanks to Robert Wilton for the detailed AD review. | ||||
Thanks to Éric Vyncke, Roman Danyliw, Erik Kline, and Benjamin Kaduk | ||||
for the IESG review. | ||||
Contributors | ||||
Christian Jacquenet | ||||
Orange | ||||
Rennes, 35000 | ||||
France | ||||
Email: Christian.jacquenet@orange.com | ||||
Luis Miguel Contreras Murillo | ||||
Telefonica | ||||
Email: luismiguel.contrerasmurillo@telefonica.com | ||||
Oscar Gonzalez de Dios | ||||
Telefonica | ||||
Madrid | ||||
Spain | ||||
Email: oscar.gonzalezdedios@telefonica.com | ||||
Weiqiang Cheng | ||||
China Mobile | ||||
Email: chengweiqiang@chinamobile.com | ||||
Young Lee | ||||
Sung Kyun Kwan University | ||||
Email: younglee.tx@gmail.com | ||||
Authors' Addresses | Authors' Addresses | |||
Qin Wu (editor) | Qin Wu (editor) | |||
Huawei | Huawei | |||
101 Software Avenue, Yuhua District | 101 Software Avenue | |||
Nanjing, Jiangsu 210012 | Yuhua District | |||
Nanjing | ||||
Jiangsu, 210012 | ||||
China | China | |||
Email: bill.wu@huawei.com | Email: bill.wu@huawei.com | |||
Mohamed Boucadair (editor) | Mohamed Boucadair (editor) | |||
Orange | Orange | |||
Rennes 35000 | Rennes 35000 | |||
France | France | |||
Email: mohamed.boucadair@orange.com | Email: mohamed.boucadair@orange.com | |||
End of changes. 249 change blocks. | ||||
755 lines changed or deleted | 803 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/ |