draft-ietf-opsawg-model-automation-framework-05.txt   draft-ietf-opsawg-model-automation-framework-06.txt 
OPSAWG Q. Wu, Ed. OPSAWG Q. Wu, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational M. Boucadair, Ed. Intended status: Informational M. Boucadair, Ed.
Expires: March 12, 2021 Orange Expires: March 26, 2021 Orange
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
C. Xie C. Xie
China Telecom China Telecom
L. Geng L. Geng
China Mobile China Mobile
September 8, 2020 September 22, 2020
A Framework for Automating Service and Network Management with YANG A Framework for Automating Service and Network Management with YANG
draft-ietf-opsawg-model-automation-framework-05 draft-ietf-opsawg-model-automation-framework-06
Abstract Abstract
Data models provide a programmatic approach to represent services and Data models provide a programmatic approach to represent services and
networks. Concretely, they can be used to derive configuration networks. Concretely, they can be used to derive configuration
information for network and service components, and state information information for network and service components, and state information
that will be monitored and tracked. Data models can be used during that will be monitored and tracked. Data models can be used during
the service and network management life cycle, such as service the service and network management life cycle, such as service
instantiation, provisioning, optimization, monitoring, diagnostic, instantiation, provisioning, optimization, monitoring, diagnostic,
and assurance. Data models are also instrumental in the automation and assurance. Data models are also instrumental in the automation
of network management, and they can provide closed-loop control for of network management, and they can provide closed-loop control for
adaptive and deterministic service creation, delivery, and adaptive and deterministic service creation, delivery, and
maintenance. maintenance.
This document describes an architecture for service and network This document describes an architecture for service and network
management automation that takes advantage of YANG modeling management automation that takes advantage of YANG modeling
technologies. This architecture is drawn from a Network Operator technologies. This architecture is drawn from a network operator
perspective irrespective of the origin of a data module; it can thus perspective irrespective of the origin of a data module; it can thus
accommodate modules that are developed outside the IETF. accommodate 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2021. This Internet-Draft will expire on March 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
5.3. Event-based Telemetry in the Device Self Management . . . 20 5.3. Event-based Telemetry in the Device Self Management . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Layered YANG Modules Examples Overview . . . . . . . 32 Appendix A. Layered YANG Modules Examples Overview . . . . . . . 32
A.1. Service Models: Definition and Samples . . . . . . . . . 32 A.1. Service Models: Definition and Samples . . . . . . . . . 32
A.2. Network Models: Samples . . . . . . . . . . . . . . . . . 33 A.2. Schema Mount . . . . . . . . . . . . . . . . . . . . . . 33
A.3. Device Models: Samples . . . . . . . . . . . . . . . . . 35 A.3. Network Models: Samples . . . . . . . . . . . . . . . . . 33
A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 37 A.4. Device Models: Samples . . . . . . . . . . . . . . . . . 36
A.3.2. Device Models: Samples . . . . . . . . . . . . . . . 37 A.4.1. Model Composition . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 A.4.2. Device Management . . . . . . . . . . . . . . . . . . 38
A.4.3. Interface Management . . . . . . . . . . . . . . . . 38
A.4.4. Some Device Model Examples . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Service management systems usually comprise service activation/ Service management systems usually comprise service activation/
provision and service operation. Current service delivery provision and service operation. Current service delivery
procedures, from the processing of customer's requirements and orders procedures, from the processing of customer's requirements and orders
to service delivery and operation, typically assume the manipulation to service delivery and operation, typically assume the manipulation
of data sequentially into multiple OSS/BSS applications that may be of data sequentially into multiple OSS/BSS applications that may be
managed by different departments within the service provider's managed by different departments within the service provider's
organization (e.g., billing factory, design factory, network organization (e.g., billing factory, design factory, network
skipping to change at page 4, line 43 skipping to change at page 4, line 46
currently documented either within the IETF or other Standards currently documented either within the IETF or other Standards
Development Organizations (SDOs). Development Organizations (SDOs).
This document describes an architectural framework for service and This document describes an architectural framework for service and
network management automation (Section 3) that takes advantage of network management automation (Section 3) that takes advantage of
YANG modeling technologies and investigates how different layer YANG YANG modeling technologies and investigates how different layer YANG
data models interact with each other (e.g., service mapping, model data models interact with each other (e.g., service mapping, model
composing) in the context of service delivery and fulfillment composing) in the context of service delivery and fulfillment
(Section 4). (Section 4).
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 module; it can accommodate irrespective of the origin of a data module; it can also accommodate
modules that are developed outside the IETF. modules that are developed outside the IETF.
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.
2. Terminology and Acronyms 2. Terminology and Acronyms
2.1. Terminology 2.1. Terminology
The following terms are defined in [RFC8309][RFC8199] and are not The following terms are defined in [RFC8309][RFC8199] and are not
skipping to change at page 5, line 32 skipping to change at page 5, line 32
o Network Element Module o Network Element Module
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: Describes a network level abstraction (or a subset of
aspects of a network infrastructure), including devices and their aspects of a network infrastructure), including devices and their
subsystems, and relevant protocols operating at the link and subsystems, and relevant protocols operating at the link and
network layers across multiple devices. This model corresponds to network layers across multiple devices. This model corresponds to
the Network Configuration Model discussed in [RFC8309]. 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.
Device Model: Refers to the Network Element YANG data model Device Model: Refers to the Network Element YANG data model
described in [RFC8199] or the Device Configuration Model discussed described in [RFC8199] or the Device Configuration Model discussed
in [RFC8309]. in [RFC8309].
Device Models are also used to refer to model a function embedded Device Models are also used to refer to model a function embedded
in a device (e.g., Network Address Translation (NAT) [RFC8512], in a device (e.g., Network Address Translation (NAT) [RFC8512],
skipping to change at page 6, line 42 skipping to change at page 6, line 42
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 can be classified into Service, Network, and Device Data models can be classified into Service, Network, and Device
Models. Different Service Models may rely on the same set of Network Models. Different Service Models may rely on the same set of Network
and/or Device Models. and/or Device Models.
Service Models traditionally follow top-down approach and are mostly Service Models traditionally follow a top-down approach and are
customer-facing YANG modules providing a common model construct for mostly customer-facing YANG modules providing a common model
higher level network services (e.g., Layer 3 Virtual Private Network construct for higher level network services (e.g., Layer 3 Virtual
(L3VPN)). Such modules can be mapped to network technology-specific Private Network (L3VPN)). Such modules can be mapped to network
modules at lower layers (e.g., tunnel, routing, Quality of Service technology-specific modules at lower layers (e.g., tunnel, routing,
(QoS), security). For example, the service level can be used to Quality of Service (QoS), security). For example, the service level
characterise the network service(s) to be ensured between service can be used to characterise the network service(s) to be ensured
nodes (ingress/egress) such as: between service nodes (ingress/egress) such as:
o the communication scope (pipe, hose, funnel, ...), o the communication scope (pipe, hose, funnel, ...),
o the directionality (inbound/outbound), o the directionality (inbound/outbound),
o the traffic performance guarantees (One-Way Delay (OWD) [RFC7679], o the traffic performance guarantees (One-Way Delay (OWD) [RFC7679],
One-Way Loss [RFC7680], ...), One-Way Loss [RFC7680], ...),
o link capacity [RFC5136][I-D.ietf-ippm-capacity-metric-method], o link capacity [RFC5136][I-D.ietf-ippm-capacity-metric-method],
o etc. o etc.
Figure 1 depicts the example of a VoIP service that relies upon Figure 1 depicts the example of a VoIP service that relies upon
connectivity services offered by a Network Operator. In this connectivity services offered by a network operator. In this
example, the VoIP service is offered to the Network Operator's 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 (SP1). In order to provide global VoIP
reachability, SP1 service site interconnects with other Service 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 Module that reflects the service attributes that are shown in Service Module 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].
skipping to change at page 10, line 9 skipping to change at page 10, line 9
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 modelled 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 modelled using other data
modelling languages than YANG. modelling languages than YANG.
3.2. Automation of Service Delivery Procedures 3.2. Automation of Service Delivery Procedures
Service Models can be used by a Network Operator to expose its Service Models can be used by a network operator to expose its
services to its customers. Exposing such models allows to automate services to its customers. Exposing such models allows to automate
the activation of service orders and thus the service delivery. One the activation of service orders and thus the service delivery. One
or more monolithic Service Models can be used in the context of a or more monolithic Service Models can be used in the context of a
composite service activation request (e.g., delivery of a caching composite service activation request (e.g., delivery of a caching
infrastructure over a VPN). Such models are used to feed a decision- infrastructure over a VPN). Such models are used to feed a decision-
making intelligence to adequately accommodate customer's needs. making intelligence to adequately accommodate customer's needs.
Also, such models may be used jointly with services that require Also, such models may be used jointly with services that require
dynamic invocation. An example is provided by the service modules dynamic invocation. An example is provided by the service modules
defined by the DOTS WG to dynamically trigger requests to handle defined by the DOTS WG to dynamically trigger requests to handle
Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service
filtering request modelled using [RFC8783] will be translated into filtering request modelled using [RFC8783] will be translated into
device-specific filtering (e.g., ACLs defined in [RFC8519]) that to device-specific filtering (e.g., ACLs defined in [RFC8519]) that to
fulfil the service request. fulfil the service request.
Network Models can be derived from Service Models and used to Network Models can be derived from Service Models and used to
provision, monitor, instantiate the service, and provide lifecycle provision, monitor, instantiate the service, and provide lifecycle
management of network resources. Doing so is meant to: management of network resources. Doing so is meant to:
o expose network resources to customers (including other Network o expose network resources to customers (including other network
Operators) to provide service fulfillment and assurance. operators) to provide service fulfillment and assurance.
o allow customers (or Network Operators) to dynamically adjust the o allow customers (or network operators) to dynamically adjust the
network resources based on service requirements as described in network resources based on service requirements as described in
Service Models (e.g., Figure 2) and the current network Service Models (e.g., Figure 2) and the current network
performance information described in the telemetry modules. performance information described in the telemetry modules.
3.3. Service Fullfillment Automation 3.3. Service Fullfillment Automation
To operate a service, the settings of the parameters in the Device To operate a service, the settings of the parameters in the Device
Models are derived from Service Models and/or Network Models and are Models are derived from Service Models and/or Network Models and are
used to: used to:
skipping to change at page 11, line 32 skipping to change at page 11, line 32
into a set of configuration/notification parameters that may be into a set of configuration/notification parameters that may be
specific to one or more technologies; these technology-specific specific to one or more technologies; these technology-specific
parameters are grouped together to define technology-specific device parameters are grouped together to define technology-specific device
level models or network level models. level models or 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 administrative domain to support newly added device or each involved administrative domain to support newly added
module or features. A collection of Device Models integrated module or features. A collection of Device Models integrated
together can be loaded and validated during the implementation time. together can be loaded 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 can telemetry automation, e.g., policies that contain conditions can
trigger the generation and pushing of new telemetry data. trigger the generation and pushing of new telemetry data.
Performance measurement telemetry can be used to provide service Performance measurement telemetry can be used to provide service
assurance at Service and/or Network levels. Performance measurement assurance at Service and/or Network levels. Performance measurement
skipping to change at page 12, line 35 skipping to change at page 12, line 35
| |Diff | | | |Diff | |
| | Specific --+ | | | Specific --+ |
Service | | Service | Service | | Service |
Decomposing | +----- Assurance ----+ Decomposing | +----- Assurance ----+
| ^ | ^
................. | | Aggregation ................. | | Aggregation
Device level | +------------+ Device level | +------------+
V | V |
Service Intent | Service Intent |
Fulfillment Config ----> Config ----> Performance ----> Fault Fulfillment Config ----> Config ----> Performance ----> Fault
Provision Validate Monitoring Diagnostic Provision Validation Monitoring Diagnostic
Figure 4: Service and Network Lifecycle Management Figure 4: Service and Network Lifecycle Management
4.1. Service Lifecycle Management Procedure 4.1. Service Lifecycle Management Procedure
Service lifecycle management includes end-to-end service lifecycle Service lifecycle management includes end-to-end service lifecycle
management at the service level and technology specific network management at the service level and technology specific network
lifecycle management at the network level. lifecycle management at the network level.
The end-to-end service lifecycle management is technology-independent The end-to-end service lifecycle management is technology-independent
skipping to change at page 13, line 23 skipping to change at page 13, line 23
(ordering and order handling). One typical example is that a (ordering and order handling). One typical example is that a
customer can use a L3VPN Service Model (L3SM) to request L3VPN customer can use a L3VPN Service Model (L3SM) to request L3VPN
service by providing the abstract technical characterization of the service by providing the abstract technical characterization of the
intended service between customer sites. intended service between customer sites.
Service Model catalogs can be created along to expose the various Service Model catalogs can be created along to expose the various
services and the information needed to invoke/order a given service. services 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 issued using a Service Model. delivered. This service request can be issued 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, the service authentication and authorization checks have been made, the service
orchestrator/management system should verify whether the service orchestrator/management system should verify whether the service
requirements in the service request can be met (i.e., whether there requirements in the service request can be met (i.e., whether there
is sufficient resources that can be allocated with the requested is sufficient resources that can be allocated with the requested
guarantees). guarantees).
skipping to change at page 14, line 18 skipping to change at page 14, line 18
policies capturing network service requirements and populate them policies capturing network service requirements and populate them
into the network. into the network.
Both network performance information and policies can be modelled Both network performance information and policies can be modelled
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.
4.1.4. Service Diagnosis 4.1.4. 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 o monitor network communications (i.e., reachability verification
and Continuity Check) and Continuity Check)
o troubleshoot failures (i.e., fault verification and localization) o troubleshoot failures (i.e., fault verification and localization)
o monitor service-level agreements and performance (i.e., o 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
skipping to change at page 22, line 20 skipping to change at page 22, line 20
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.
Security considerations specific to this document are listed below: Security considerations specific to this document are listed below:
o Create forwarding loops by mis-configuring the underlying network. o Create forwarding loops by mis-configuring the underlying network.
o Leak sensitive information: special care should be considered when o Leak sensitive information: special care should be considered when
translating between the various layers in Section 4 or when translating between the various layers in Section 4 or when
aggregating data retrieved from various sources. The Network aggregating data retrieved from various sources. The network
Operator must enforce means to protect privacy-related information operator must enforce means to protect privacy-related information
included in cutsomer-facing models. included in cutsomer-facing models.
o Some Service Models may include a traffic isolation clause, o Some Service Models may include a traffic isolation clause,
appropriate technology-specific actions must be enforced to avoid appropriate technology-specific actions must be enforced to avoid
that traffic is accessible to non-authorized parties. that traffic is accessible to non-authorized parties.
7. IANA Considerations 7. IANA Considerations
There are no IANA requests or assignments included in this document. There are no IANA requests or assignments included in this document.
skipping to change at page 29, line 5 skipping to change at page 29, line 5
Weingarten, "An Overview of Operations, Administration, Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276, and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>. <https://www.rfc-editor.org/info/rfc7276>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297, Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014, DOI 10.17487/RFC7297, July 2014,
<https://www.rfc-editor.org/info/rfc7297>. <https://www.rfc-editor.org/info/rfc7297>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake
3rd, D., Aldrin, S., and Y. Li, "Transparent 3rd, D., Aldrin, S., and Y. Li, "Transparent
Interconnection of Lots of Links (TRILL): Fault Interconnection of Lots of Links (TRILL): Fault
Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, Management", RFC 7455, DOI 10.17487/RFC7455, March 2015,
<https://www.rfc-editor.org/info/rfc7455>. <https://www.rfc-editor.org/info/rfc7455>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>. 2016, <https://www.rfc-editor.org/info/rfc7679>.
skipping to change at page 29, line 43 skipping to change at page 29, line 47
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299, "YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018, DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>. <https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X.,
Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
March 2018, <https://www.rfc-editor.org/info/rfc8346>. March 2018, <https://www.rfc-editor.org/info/rfc8346>.
[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
YANG Data Model for Hardware Management", RFC 8348,
DOI 10.17487/RFC8348, March 2018,
<https://www.rfc-editor.org/info/rfc8348>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018, DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>. <https://www.rfc-editor.org/info/rfc8349>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN) Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>. 2018, <https://www.rfc-editor.org/info/rfc8466>.
skipping to change at page 32, line 28 skipping to change at page 32, line 44
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') [I-D.clacla-netmod-model-catalog]. Note
that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to
associate tags with YANG modules in order to help classifying the associate tags with YANG modules in 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 and/or between customer sites
across the Network Operator's network and across the Internet". More across the network operator's network and across the Internet". More
concretely, an IP connectivity service can be defined as the IP concretely, an IP connectivity service can be defined as the IP
transfer capability characterized by a (Source Nets, Destination transfer capability characterized by a (Source Nets, Destination
Nets, Guarantees, Scope) tuple where "Source Nets" is a group of Nets, Guarantees, Scope) tuple where "Source Nets" is a group of
unicast IP addresses, "Destination Nets" is a group of IP unicast unicast IP addresses, "Destination Nets" is a group of IP unicast
and/or multicast addresses, and "Guarantees" reflects the guarantees and/or multicast addresses, and "Guarantees" reflects the guarantees
(expressed in terms of QoS, performance, and availability, for (expressed in terms of QoS, performance, and availability, for
example) to properly forward traffic to the said "Destination" example) to properly forward traffic to the said "Destination"
[RFC7297]. [RFC7297].
For example: For example:
o The L3SM model [RFC8299] defines the L3VPN service ordered by a o The L3SM model [RFC8299] defines the L3VPN service ordered by a
customer from a Network Operator. customer from a network operator.
o The L2SM model [RFC8466] defines the L2VPN service ordered by a o The L2SM model [RFC8466] defines the L2VPN service ordered by a
customer from a Network Operator. customer from a network operator.
o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang] o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang]
provides a YANG data model applicable to any mode of VN operation. provides a YANG data model applicable to any mode of VN operation.
L2SM and L3SM are customer service models as per [RFC8309]. L2SM and L3SM are customer service models as per [RFC8309].
A.2. Network Models: Samples A.2. Schema Mount
Modularity and extensibility were among the leading design principles
of the YANG data modeling language. As a result, the same YANG
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
specific use case. [RFC8528] defines a mechanism, denoted schema
mount, that allows for mounting one data model consisting of any
number of YANG modules at a specified location of another (parent)
schema.
A.3. Network Models: Samples
L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are
examples of YANG Network Models. examples of YANG Network Models.
Figure 9 depicts a set of additional Network Models such as topology Figure 9 depicts a set of additional Network Models such as topology
and tunnel models: and tunnel models:
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Topology YANG modules | Tunnel YANG modules | | Topology YANG modules | Tunnel YANG modules |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| +------------+ | | | +------------------+ | |
| |Network Topo| | +------+ +-----------+ | | |Network Topologies| | +------+ +-----------+ |
| | Model | | |Other | | TE Tunnel | | | | Model | | |Other | | TE Tunnel | |
| +----+-------+ | |Tunnel| +----+------+ | | +--------+---------+ | |Tunnel| +----+------+ |
| | +--------+ | +------+ | | | | +---------+ | +------+ | |
| +---+Svc Topo| | +----------+---------+ | | +---+Service | | +----------+---------+ |
| | +--------+ | | | | | | | |Topology | | | | | |
| | +--------+ |+----+---+ +----+---+ +---+---+| | | +---------+ | | | | |
| +---+L2 Topo | ||MPLS-TE | |RSVP-TE | | SR-TE || | | +---------+ |+----+---+ +----+---+ +---+---+|
| | +--------+ || Tunnel | | Tunnel | |Tunnel || | +---+Layer 3 | ||MPLS-TE | |RSVP-TE | | SR-TE ||
| | +--------+ |+--------+ +--------+ +-------+| | | |Topology | || Tunnel | | Tunnel | |Tunnel ||
| +---+TE Topo | | | | | +---------+ |+--------+ +--------+ +-------+|
| | +--------+ | | | | +---------+ | |
| | +--------+ | | | +---+TE | | |
| +---+L3 Topo | | | | | |Topology | | |
| +--------+ | | | | +---------+ | |
| | +---------+ | |
| +---+Layer 3 | | |
| |Topology | | |
| +---------+ | |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
Legend:
Topo: Topology
Svc: Service
Figure 9: Sample Resource Facing Network Models Figure 9: Sample Resource Facing Network Models
Examples of topology YANG modules are listed below: Examples of topology YANG modules are listed below:
o Network Topology Models: [RFC8345] defines a base model for o Network Topologies Model: [RFC8345] defines a base model for
network topology and inventories. Network topology data include network topology and inventories. Network topology data include
link resource, node resource, and terminate-point resources. link resource, node resource, and terminate-point resources.
o TE Topology Models: [RFC8795] defines a YANG data model for o TE Topology Model: [RFC8795] defines a YANG data model for
representing and manipulating TE topologies. representing and manipulating TE topologies.
This module is extended from network topology model defined in This module is extended from network topology model defined in
[RFC8345] with TE topologies specifics. This model contains [RFC8345] with TE topologies related content. This model contains
technology-agnostic TE Topology building blocks that can be technology-agnostic TE Topology building blocks that can be
augmented and used by other technology-specific TE topology augmented and used by other technology-specific TE topology
models. models.
o Layer 3 Topology Models: o Layer 3 Topology 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] with Layer 3
topologies specifics. topologies specifics.
o Layer 2 Topology Models: o Layer 2 Topology Model:
[I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model [I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model
for representing and manipulating Layer 2 topologies. This model for representing and manipulating Layer 2 topologies. This model
is extended from the network topology model defined in [RFC8345] is extended from the network topology model defined in [RFC8345]
with Layer 2 topologies specifics. with 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 o Tunnel identities: [RFC8675] defines a collection of YANG
identities used as interface types for tunnel interfaces. identities used as interface types for tunnel interfaces.
o TE Tunnel Model: o TE Tunnel Model:
[I-D.ietf-teas-yang-te] defines a YANG module for the [I-D.ietf-teas-yang-te] defines a YANG module for the
configuration and management of TE interfaces, tunnels, and LSPs. configuration and management of TE interfaces, tunnels, and LSPs.
skipping to change at page 35, line 25 skipping to change at page 36, line 14
protocols. [RFC8531] defines a base YANG module for connection protocols. [RFC8531] defines a base YANG module for connection
oriented OAM protocols. These three models are intended to oriented OAM protocols. These three models are intended to
provide consistent reporting, configuration, and representation provide consistent reporting, configuration, and representation
for connection-less OAM and Connection oriented OAM separately. for connection-less OAM and Connection oriented OAM separately.
Alarm monitoring is a fundamental part of monitoring the network. Alarm monitoring is a fundamental part of monitoring the network.
Raw alarms from devices do not always tell the status of the Raw alarms from devices do not always tell the status of the
network services or necessarily point to the root cause. network services or necessarily point to the root cause.
[RFC8632] defines a YANG module for alarm management. [RFC8632] defines a YANG module for alarm management.
A.3. Device Models: Samples A.4. Device Models: Samples
Network Element models (Figure 10) are used to describe how a service Network Element models (Figure 10) are used to describe how a service
can be implemented by activating and tweaking a set of functions can be implemented by activating and tweaking a set of functions
(enabled in one or multiple devices, or hosted in cloud (enabled in one or multiple devices, or hosted in cloud
infrastructures) that are involved in the service delivery. infrastructures) that are involved in the service delivery.
Figure 10 uses IETF-defined data models as an example. Figure 10 uses IETF-defined data models as an example.
+------------------------+ +------------------------+
+-+ Device Model | +-+ Device Model |
| +------------------------+ | +------------------------+
skipping to change at page 37, line 5 skipping to change at page 38, line 5
| +-------+ | +-------+
| +-------+ | +-------+
+-+ISIS-SR| +-+ISIS-SR|
| +-------+ | +-------+
| +-------+ | +-------+
+-+OSPF-SR| +-+OSPF-SR|
+-------+ +-------+
Figure 10: Network Element Modules Overview Figure 10: Network Element Modules Overview
A.3.1. Model Composition A.4.1. Model Composition
o Logical Network Element Model o Logical Network Element Model
[RFC8530] defines a logical network element module which can be [RFC8530] defines a logical network element module which can be
used to manage the logical resource partitioning that may be used to manage the logical resource partitioning that may be
present on a network device. Examples of common industry terms present on a network device. Examples of common industry terms
for logical resource partitioning are Logical Systems or Logical for logical resource partitioning are Logical Systems or Logical
Routers. Routers.
o Network Instance Model o Network Instance Model
[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.3.1.1. Schema Mount A.4.2. Device Management
Modularity and extensibility were among the leading design principles
of the YANG data modeling language. As a result, the same YANG
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
specific use case. [RFC8528] defines a mechanism, denoted schema
mount, that allows for mounting one data model consisting of any
number of YANG modules at a specified location of another (parent)
schema.
A.3.2. Device Models: Samples
The following provides an overview of some Device Models that can be
used within a network. This list is not comprehensive.
Interface: [RFC7224] defines a YANG module for interface type
definitions.
BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for
configuring and managing BGP, including protocol, policy,
and operational aspects based on data center, carrier, and
content provider operational requirements.
MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS The following list enumerates some YANG modules that can be used for
which serves as a base framework for configuring and device management:
managing an MPLS switching subsystem. It is expected that
other MPLS technology YANG modules (e.g., MPLS LSP Static,
LDP, or RSVP-TE models) will augment the MPLS base YANG
module.
QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of o [RFC8348]: defines a YANG module for the management of hardware.
Differentiated Services for configuration and operations.
ACL: Access Control List (ACL) is one of the basic elements o [RFC7317]: defines the "ietf-system" YANG module that provides
used to configure device forwarding behavior. It is used many features such as the configuration and the monitoring of
in many networking technologies such as Policy Based system or system control operations (e.g., shutdown, restart,
Routing, Firewalls, etc. [RFC8519] describes a YANG data setting time) identification.
model of ACL basic building blocks.
NAT: For the sake of network automation and the need for o [RFC8341]: defines a network configuration access control YANG
programming Network Address Translation (NAT) function in module.
particular, a YANG data model for configuring and managing
the NAT is essential.
[RFC8512] defines a YANG module for the NAT function A.4.3. Interface Management
covering a variety of NAT flavors such as Network Address
Translation from IPv4 to IPv4 (NAT44), Network Address and
Protocol Translation from IPv6 Clients to IPv4 Servers
(NAT64), customer-side translator (CLAT), Stateless IP/
ICMP Translation (SIIT), Explicit Address Mappings (EAM)
for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6),
and Destination NAT.
[RFC8513] specifies a DS-Lite YANG module. The following provides some YANG modules that can be used for
interface management:
Stateless Address Sharing: [RFC8676] specifies a YANG module for A+P o [RFC7224]: defines a YANG module for interface type definitions.
address sharing, including Lightweight 4over6, Mapping of
Address and Port with Encapsulation (MAP-E), and Mapping
of Address and Port using Translation (MAP-T) softwire
mechanisms.
Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used o [RFC8343]: defines a YANG module for the management of network
to configure and manage Protocol Independent Multicast interfaces.
(PIM) devices.
[RFC8652] defines a YANG module that can be used to A.4.4. Some Device Model Examples
configure and manage Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) devices.
[I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG The following provides an overview of some Device Models that can be
module that can be used to configure and manage Internet used within a network. This list is not comprehensive.
Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) Snooping devices.
[I-D.ietf-bess-mvpn-yang] defines a YANG data model to L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS
configure and manage Multicast in MPLS/BGP IP VPNs based Layer 2 VPN services (L2VPN) [RFC4664] and includes
(MVPNs). switching between the local attachment circuits. The
L2VPN model covers point-to-point VPWS and Multipoint VPLS
services. These services use signaling of Pseudowires
across MPLS networks using LDP [RFC8077][RFC4762] or BGP
[RFC4761].
EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for
Ethernet VPN services. The model is agnostic of the Ethernet VPN services. The model is agnostic of the
underlay. It applies to MPLS as well as to VxLAN underlay. It applies to MPLS as well as to VxLAN
encapsulation. The module is also agnostic to the encapsulation. The module is also agnostic to the
services, including E-LAN, E-LINE, and E-TREE services. services, including E-LAN, E-LINE, and E-TREE services.
L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can
be used to configure and manage BGP L3VPNs [RFC4364]. It be used to configure and manage BGP L3VPNs [RFC4364]. It
contains VRF specific parameters as well as BGP specific contains VRF specific parameters as well as BGP specific
parameters applicable for L3VPNs. parameters applicable for L3VPNs.
L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS Core Routing: [RFC8349] defines the core routing YANG data model,
based Layer 2 VPN services (L2VPN) [RFC4664] and includes which is intended as a basis for future data model
switching between the local attachment circuits. The development covering more-sophisticated routing systems.
L2VPN model covers point-to-point VPWS and Multipoint VPLS It is expected that other Routing technology YANG modules
services. These services use signaling of Pseudowires (e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core
across MPLS networks using LDP [RFC8077][RFC4762] or BGP Routing base YANG module.
[RFC4761].
MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS
which serves as a base framework for configuring and
managing an MPLS switching subsystem. It is expected that
other MPLS technology YANG modules (e.g., MPLS LSP Static,
LDP, or RSVP-TE models) will augment the MPLS base YANG
module.
BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for
configuring and managing BGP, including protocol, policy,
and operational aspects based on data center, carrier, and
content provider operational requirements.
Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module
for configuring and managing routing policies based on for configuring and managing routing policies based on
operational practice. The module provides a generic operational practice. The module provides a generic
policy framework which can be augmented with protocol- policy framework which can be augmented with protocol-
specific policy configuration. specific policy configuration.
SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment
routing configuration and operation.
BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a
network protocol which is used for liveness detection of network protocol which is used for liveness detection of
arbitrary paths between systems. [I-D.ietf-bfd-yang] arbitrary paths between systems. [I-D.ietf-bfd-yang]
defines a YANG module that can be used to configure and defines a YANG module that can be used to configure and
manage BFD. manage BFD.
SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used
routing configuration and operation. to configure and manage Protocol Independent Multicast
(PIM) devices.
Core Routing: [RFC8349] defines the core routing YANG data model, [RFC8652] defines a YANG module that can be used to
which is intended as a basis for future data model configure and manage Internet Group Management Protocol
development covering more-sophisticated routing systems. (IGMP) and Multicast Listener Discovery (MLD) devices.
It is expected that other Routing technology YANG modules
(e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core [I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG
Routing base YANG module. module that can be used to configure and manage Internet
Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) Snooping devices.
[I-D.ietf-bess-mvpn-yang] defines a YANG data model to
configure and manage Multicast in MPLS/BGP IP VPNs
(MVPNs).
PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for
client and server implementations of the Two-Way Active client and server implementations of the Two-Way Active
Measurement Protocol (TWAMP). Measurement Protocol (TWAMP).
[I-D.ietf-ippm-stamp-yang] defines the data model for [I-D.ietf-ippm-stamp-yang] defines the data model for
implementations of Session-Sender and Session-Reflector implementations of Session-Sender and Session-Reflector
for Simple Two-way Active Measurement Protocol (STAMP) for Simple Two-way Active Measurement Protocol (STAMP)
mode using YANG. mode using YANG.
[RFC8194] defines a YANG data model for Large-Scale [RFC8194] defines a YANG data model for Large-Scale
Measurement Platforms (LMAPs). Measurement Platforms (LMAPs).
ACL: Access Control List (ACL) is one of the basic elements
used to configure device forwarding behavior. It is used
in many networking technologies such as Policy Based
Routing, firewalls, etc. [RFC8519] describes a YANG data
model of ACL basic building blocks.
QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of
Differentiated Services for configuration and operations.
NAT: For the sake of network automation and the need for
programming Network Address Translation (NAT) function in
particular, a YANG data model for configuring and managing
the NAT is essential.
[RFC8512] defines a YANG module for the NAT function
covering a variety of NAT flavors such as Network Address
Translation from IPv4 to IPv4 (NAT44), Network Address and
Protocol Translation from IPv6 Clients to IPv4 Servers
(NAT64), customer-side translator (CLAT), Stateless IP/
ICMP Translation (SIIT), Explicit Address Mappings (EAM)
for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6),
and Destination NAT.
[RFC8513] specifies a DS-Lite YANG module.
Stateless Address Sharing: [RFC8676] specifies a YANG module for A+P
address sharing, including Lightweight 4over6, Mapping of
Address and Port with Encapsulation (MAP-E), and Mapping
of Address and Port using Translation (MAP-T) softwire
mechanisms.
Authors' Addresses Authors' Addresses
Qin Wu (editor) Qin Wu (editor)
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
 End of changes. 52 change blocks. 
149 lines changed or deleted 187 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/