--- 1/draft-ietf-opsawg-model-automation-framework-05.txt 2020-09-22 02:13:12.018333302 -0700 +++ 2/draft-ietf-opsawg-model-automation-framework-06.txt 2020-09-22 02:13:12.106335533 -0700 @@ -1,61 +1,61 @@ OPSAWG Q. Wu, Ed. Internet-Draft Huawei Intended status: Informational M. Boucadair, Ed. -Expires: March 12, 2021 Orange +Expires: March 26, 2021 Orange D. Lopez Telefonica I+D C. Xie China Telecom L. Geng China Mobile - September 8, 2020 + September 22, 2020 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 Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle, such as service instantiation, provisioning, optimization, monitoring, diagnostic, and assurance. Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes an architecture for service and network 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 accommodate modules that are developed outside the IETF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -96,25 +96,28 @@ 5.3. Event-based Telemetry in the Device Self Management . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Layered YANG Modules Examples Overview . . . . . . . 32 A.1. Service Models: Definition and Samples . . . . . . . . . 32 - A.2. Network Models: Samples . . . . . . . . . . . . . . . . . 33 - A.3. Device Models: Samples . . . . . . . . . . . . . . . . . 35 - A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 37 - A.3.2. Device Models: Samples . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + A.2. Schema Mount . . . . . . . . . . . . . . . . . . . . . . 33 + A.3. Network Models: Samples . . . . . . . . . . . . . . . . . 33 + A.4. Device Models: Samples . . . . . . . . . . . . . . . . . 36 + A.4.1. Model Composition . . . . . . . . . . . . . . . . . . 38 + 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 Service management systems usually comprise service activation/ provision and service operation. Current service delivery procedures, from the processing of customer's requirements and orders to service delivery and operation, typically assume the manipulation of data sequentially into multiple OSS/BSS applications that may be managed by different departments within the service provider's organization (e.g., billing factory, design factory, network @@ -173,22 +176,22 @@ currently documented either within the IETF or other Standards Development Organizations (SDOs). This document describes an architectural framework for service and network management automation (Section 3) that takes advantage of YANG modeling technologies and investigates how different layer YANG data models interact with each other (e.g., service mapping, model composing) in the context of service delivery and fulfillment (Section 4). - This framework is drawn from a Network Operator perspective - irrespective of the origin of a data module; it can accommodate + This framework is drawn from a network operator perspective + irrespective of the origin of a data module; it can also accommodate modules that are developed outside the IETF. 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. 2. Terminology and Acronyms 2.1. Terminology The following terms are defined in [RFC8309][RFC8199] and are not @@ -207,21 +210,21 @@ o Network Element Module In addition, the document makes use of the following terms: Network Model: Describes a network level abstraction (or a subset of aspects of a network infrastructure), including devices and their subsystems, and relevant protocols operating at the link and network layers 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 resources to meet the service requirements defined in a Service Model. Device Model: Refers to the Network Element YANG data model described in [RFC8199] or the Device Configuration Model discussed in [RFC8309]. Device Models are also used to refer to model a function embedded in a device (e.g., Network Address Translation (NAT) [RFC8512], @@ -264,39 +267,39 @@ 3.1. Data Models: Layering and Representation As described in Section 2 of [RFC8199], layering of modules allows for better reusability of lower-layer modules by higher-level modules while limiting duplication of features across layers. Data models can be classified into Service, Network, and Device Models. Different Service Models may rely on the same set of Network and/or Device Models. - Service Models traditionally follow top-down approach and are mostly - customer-facing YANG modules providing a common model construct for - higher level network services (e.g., Layer 3 Virtual Private Network - (L3VPN)). Such modules can be mapped to network technology-specific - modules at lower layers (e.g., tunnel, routing, Quality of Service - (QoS), security). For example, the service level can be used to - characterise the network service(s) to be ensured between service - nodes (ingress/egress) such as: + Service Models traditionally follow a top-down approach and are + mostly customer-facing YANG modules providing a common model + construct for higher level network services (e.g., Layer 3 Virtual + Private Network (L3VPN)). Such modules can be mapped to network + technology-specific modules at lower layers (e.g., tunnel, routing, + Quality of Service (QoS), security). For example, the service level + can be used to characterise the network service(s) to be ensured + between service nodes (ingress/egress) such as: o the communication scope (pipe, hose, funnel, ...), o the directionality (inbound/outbound), o the traffic performance guarantees (One-Way Delay (OWD) [RFC7679], One-Way Loss [RFC7680], ...), o link capacity [RFC5136][I-D.ietf-ippm-capacity-metric-method], o etc. Figure 1 depicts the example of a VoIP service that relies upon - connectivity services offered by a Network Operator. In this - example, the VoIP service is offered to the Network Operator's + connectivity services offered by a network operator. In this + example, the VoIP service is offered to the network operator's customers by Service Provider (SP1). In order to provide global VoIP reachability, SP1 service site interconnects with other Service Providers service sites typically by interconnecting Session Border Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406]. For other VoIP destinations, sessions are forwarded over the Internet. These connectivity services can be captured in a YANG Service Module that reflects the service attributes that are shown in Figure 2. This example follows the IP Connectivity Provisioning Profile template defined in [RFC7297]. @@ -412,44 +415,44 @@ modules. In order to ease the mapping between layers and data reuse, this document focuses on service models that are modelled using YANG. Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3 does not preclude service models to be modelled using other data modelling languages than YANG. 3.2. Automation of Service Delivery Procedures - 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 the activation of service orders and thus the service delivery. One or more monolithic Service Models can be used in the context of a composite service activation request (e.g., delivery of a caching infrastructure over a VPN). Such models are used to feed a decision- making intelligence to adequately accommodate customer's needs. Also, such models may be used jointly with services that require dynamic invocation. An example is provided by the service modules defined by the DOTS WG to dynamically trigger requests to handle Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service filtering request modelled using [RFC8783] will be translated into device-specific filtering (e.g., ACLs defined in [RFC8519]) that to fulfil the service request. Network Models can be derived from Service Models and used to provision, monitor, instantiate the service, and provide lifecycle management of network resources. Doing so is meant to: - o expose network resources to customers (including other Network - Operators) to provide service fulfillment and assurance. + o expose network resources to customers (including other network + 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 Service Models (e.g., Figure 2) and the current network performance information described in the telemetry modules. 3.3. Service Fullfillment Automation To operate a service, the settings of the parameters in the Device Models are derived from Service Models and/or Network Models and are used to: @@ -482,21 +485,21 @@ into a set of configuration/notification parameters that may be specific to one or more technologies; these technology-specific parameters are grouped together to define technology-specific device level models or network level models. In addition, these technology-specific Device or Network Models can be further integrated with each other using the schema mount mechanism [RFC8528] to provision each involved network function/ device or each involved administrative domain to support newly added 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 (e.g., "Autonomous System Number (ASN) Exclude" in the example depicted in Figure 2). Device Models will be tweaked accordingly to provide policy-based management. Policies can also be used for telemetry automation, e.g., policies that contain conditions can trigger the generation and pushing of new telemetry data. Performance measurement telemetry can be used to provide service assurance at Service and/or Network levels. Performance measurement @@ -531,21 +534,21 @@ | |Diff | | | | Specific --+ | Service | | Service | Decomposing | +----- Assurance ----+ | ^ ................. | | Aggregation Device level | +------------+ V | Service Intent | Fulfillment Config ----> Config ----> Performance ----> Fault - Provision Validate Monitoring Diagnostic + Provision Validation Monitoring Diagnostic Figure 4: Service and Network Lifecycle Management 4.1. Service Lifecycle Management Procedure Service lifecycle management includes end-to-end service lifecycle management at the service level and technology specific network lifecycle management at the network level. The end-to-end service lifecycle management is technology-independent @@ -565,22 +568,22 @@ (ordering and order handling). One typical example is that a customer can use a L3VPN Service Model (L3SM) to request L3VPN service by providing the abstract technical characterization of the intended service between customer sites. Service Model catalogs can be created along to expose the various services and the information needed to invoke/order a given service. 4.1.2. Service Creation/Modification - A customer is usually unaware of the technology that the Network - Operator has available to deliver the service, so the customer does + A customer is usually unaware of the technology that the network + operator has available to deliver the service, so the customer does not make requests specific to the underlying technology but is limited to making requests specific to the service that is to be delivered. This service request can be issued using a Service Model. Upon receiving a service request, and assuming that appropriate authentication and authorization checks have been made, the service orchestrator/management system should verify whether the service requirements in the service request can be met (i.e., whether there is sufficient resources that can be allocated with the requested guarantees). @@ -609,22 +612,22 @@ policies capturing network service requirements and populate them into the network. Both network performance information and policies can be modelled using YANG. With Policy-based management, self-configuration and self-optimization behavior can be specified and implemented. 4.1.4. Service Diagnosis Operations, Administration, and Maintenance (OAM) are important - networking functions for service diagnosis that allow Network - Operators to: + networking functions for service diagnosis that allow network + operators to: o monitor network communications (i.e., reachability verification and Continuity Check) o troubleshoot failures (i.e., fault verification and localization) o monitor service-level agreements and performance (i.e., performance management) When the network is down, service diagnosis should be in place to @@ -985,22 +988,22 @@ Security considerations specific to each of the technologies and protocols listed in the document are discussed in the specification documents of each of these protocols. Security considerations specific to this document are listed below: o Create forwarding loops by mis-configuring the underlying network. o Leak sensitive information: special care should be considered when translating between the various layers in Section 4 or when - aggregating data retrieved from various sources. The Network - Operator must enforce means to protect privacy-related information + aggregating data retrieved from various sources. The network + operator must enforce means to protect privacy-related information included in cutsomer-facing models. o Some Service Models may include a traffic isolation clause, appropriate technology-specific actions must be enforced to avoid that traffic is accessible to non-authorized parties. 7. IANA Considerations There are no IANA requests or assignments included in this document. @@ -1284,20 +1287,24 @@ Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, . [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, . + [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for + System Management", RFC 7317, DOI 10.17487/RFC7317, August + 2014, . + [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, . [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, . @@ -1322,30 +1329,39 @@ [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . + [RFC8343] Bjorklund, M., "A YANG Data Model for Interface + Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, + . + [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, March 2018, . + [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, + . + [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, . @@ -1446,106 +1462,117 @@ The YANG Catalog includes some metadata to indicate the module type ('module-classification') [I-D.clacla-netmod-model-catalog]. Note that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to associate tags with YANG modules in order to help classifying the modules. A.1. Service Models: Definition and Samples As described in [RFC8309], the service is "some form of connectivity 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 transfer capability characterized by a (Source Nets, Destination Nets, Guarantees, Scope) tuple where "Source Nets" is a group of unicast IP addresses, "Destination Nets" is a group of IP unicast and/or multicast addresses, and "Guarantees" reflects the guarantees (expressed in terms of QoS, performance, and availability, for example) to properly forward traffic to the said "Destination" [RFC7297]. For example: 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 - customer from a Network Operator. + customer from a network operator. 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. 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 examples of YANG Network Models. Figure 9 depicts a set of additional Network Models such as topology and tunnel models: +-------------------------------+-------------------------------+ | Topology YANG modules | Tunnel YANG modules | +-------------------------------+-------------------------------+ - | +------------+ | | - | |Network Topo| | +------+ +-----------+ | + | +------------------+ | | + | |Network Topologies| | +------+ +-----------+ | | | Model | | |Other | | TE Tunnel | | - | +----+-------+ | |Tunnel| +----+------+ | - | | +--------+ | +------+ | | - | +---+Svc Topo| | +----------+---------+ | - | | +--------+ | | | | | - | | +--------+ |+----+---+ +----+---+ +---+---+| - | +---+L2 Topo | ||MPLS-TE | |RSVP-TE | | SR-TE || - | | +--------+ || Tunnel | | Tunnel | |Tunnel || - | | +--------+ |+--------+ +--------+ +-------+| - | +---+TE Topo | | | - | | +--------+ | | - | | +--------+ | | - | +---+L3 Topo | | | - | +--------+ | | + | +--------+---------+ | |Tunnel| +----+------+ | + | | +---------+ | +------+ | | + | +---+Service | | +----------+---------+ | + | | |Topology | | | | | | + | | +---------+ | | | | | + | | +---------+ |+----+---+ +----+---+ +---+---+| + | +---+Layer 3 | ||MPLS-TE | |RSVP-TE | | SR-TE || + | | |Topology | || Tunnel | | Tunnel | |Tunnel || + | | +---------+ |+--------+ +--------+ +-------+| + | | +---------+ | | + | +---+TE | | | + | | |Topology | | | + | | +---------+ | | + | | +---------+ | | + | +---+Layer 3 | | | + | |Topology | | | + | +---------+ | | +-------------------------------+-------------------------------+ - Legend: - Topo: Topology - Svc: Service - Figure 9: Sample Resource Facing Network Models 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 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. 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 augmented and used by other technology-specific TE topology models. - o Layer 3 Topology Models: + o Layer 3 Topology Model: [RFC8346] defines a YANG data model for representing and manipulating Layer 3 topologies. This model is extended from the network topology model defined in [RFC8345] with Layer 3 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 for representing and manipulating Layer 2 topologies. This model 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: o Tunnel identities: [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. @@ -1584,21 +1611,21 @@ protocols. [RFC8531] defines a base YANG module for connection oriented OAM protocols. These three models are intended to provide consistent reporting, configuration, and representation for connection-less OAM and Connection oriented OAM separately. Alarm monitoring is a fundamental part of monitoring the network. Raw alarms from devices do not always tell the status of the network services or necessarily point to the root cause. [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 can be implemented by activating and tweaking a set of functions (enabled in one or multiple devices, or hosted in cloud infrastructures) that are involved in the service delivery. Figure 10 uses IETF-defined data models as an example. +------------------------+ +-+ Device Model | | +------------------------+ @@ -1641,170 +1668,181 @@ | +-------+ | +-------+ +-+ISIS-SR| | +-------+ | +-------+ +-+OSPF-SR| +-------+ Figure 10: Network Element Modules Overview -A.3.1. Model Composition +A.4.1. Model Composition o Logical Network Element Model [RFC8530] defines a logical network element module which can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are Logical Systems or Logical Routers. o Network Instance Model [RFC8529] defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VRF instances and Virtual Switch Instances (VSIs). -A.3.1.1. 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.2. Device Models: Samples +A.4.2. Device Management - The following provides an overview of some Device Models that can be - used within a network. This list is not comprehensive. + The following list enumerates some YANG modules that can be used for + device management: - Interface: [RFC7224] defines a YANG module for interface type - definitions. + o [RFC8348]: defines a YANG module for the management of hardware. - 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. + o [RFC7317]: defines the "ietf-system" YANG module that provides + many features such as the configuration and the monitoring of + system or system control operations (e.g., shutdown, restart, + setting time) identification. - 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 + o [RFC8341]: defines a network configuration access control YANG module. - QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of - Differentiated Services for configuration and operations. - - 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. - - 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. +A.4.3. Interface Management - [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 - 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. + o [RFC7224]: defines a YANG module for interface type definitions. - Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used - to configure and manage Protocol Independent Multicast - (PIM) devices. + o [RFC8343]: defines a YANG module for the management of network + interfaces. - [RFC8652] defines a YANG module that can be used to - configure and manage Internet Group Management Protocol - (IGMP) and Multicast Listener Discovery (MLD) devices. +A.4.4. Some Device Model Examples - [I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG - module that can be used to configure and manage Internet - Group Management Protocol (IGMP) and Multicast Listener - Discovery (MLD) Snooping devices. + The following provides an overview of some Device Models that can be + used within a network. This list is not comprehensive. - [I-D.ietf-bess-mvpn-yang] defines a YANG data model to - configure and manage Multicast in MPLS/BGP IP VPNs - (MVPNs). + L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS + based Layer 2 VPN services (L2VPN) [RFC4664] and includes + 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 Ethernet VPN services. The model is agnostic of the underlay. It applies to MPLS as well as to VxLAN encapsulation. 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 be used to configure and manage BGP L3VPNs [RFC4364]. It contains VRF specific parameters as well as BGP specific parameters applicable for L3VPNs. - L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS - based Layer 2 VPN services (L2VPN) [RFC4664] and includes - 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]. + Core Routing: [RFC8349] defines the core routing YANG data model, + which is intended as a basis for future data model + development covering more-sophisticated routing systems. + It is expected that other Routing technology YANG modules + (e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core + Routing base YANG module. + + 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 for configuring and managing routing policies based on operational practice. The module provides a generic policy framework which can be augmented with protocol- 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 network protocol which is used for liveness detection of arbitrary paths between systems. [I-D.ietf-bfd-yang] defines a YANG module that can be used to configure and manage BFD. - SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment - routing configuration and operation. + Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used + to configure and manage Protocol Independent Multicast + (PIM) devices. - Core Routing: [RFC8349] defines the core routing YANG data model, - which is intended as a basis for future data model - development covering more-sophisticated routing systems. - It is expected that other Routing technology YANG modules - (e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core - Routing base YANG module. + [RFC8652] defines a YANG module that can be used to + 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 + 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 client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). [I-D.ietf-ippm-stamp-yang] defines the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. [RFC8194] defines a YANG data model for Large-Scale 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 Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com