idnits 2.17.1 draft-ietf-opsawg-model-automation-framework-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 8, 2020) is 1324 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-bess-l3vpn-yang-04 == Outdated reference: A later version (-05) exists of draft-ietf-bess-mvpn-yang-04 == Outdated reference: A later version (-18) exists of draft-ietf-i2rs-yang-l2-network-topology-17 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-09 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-capacity-metric-method-03 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-stamp-yang-05 == Outdated reference: A later version (-17) exists of draft-ietf-mpls-base-yang-15 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-00 == Outdated reference: A later version (-18) exists of draft-ietf-opsawg-l3sm-l3nm-03 == Outdated reference: A later version (-20) exists of draft-ietf-pim-igmp-mld-snooping-yang-18 == Outdated reference: A later version (-31) exists of draft-ietf-rtgwg-policy-model-21 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-qos-model-02 == Outdated reference: A later version (-30) exists of draft-ietf-spring-sr-yang-22 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-03 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-09 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-10 == Outdated reference: A later version (-09) exists of draft-ietf-teas-yang-rsvp-te-08 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-25 == Outdated reference: A later version (-10) exists of draft-wwx-netmod-event-yang-09 Summary: 0 errors (**), 0 flaws (~~), 20 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG Q. Wu, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational M. Boucadair, Ed. 5 Expires: March 12, 2021 Orange 6 D. Lopez 7 Telefonica I+D 8 C. Xie 9 China Telecom 10 L. Geng 11 China Mobile 12 September 8, 2020 14 A Framework for Automating Service and Network Management with YANG 15 draft-ietf-opsawg-model-automation-framework-05 17 Abstract 19 Data models provide a programmatic approach to represent services and 20 networks. Concretely, they can be used to derive configuration 21 information for network and service components, and state information 22 that will be monitored and tracked. Data models can be used during 23 the service and network management life cycle, such as service 24 instantiation, provisioning, optimization, monitoring, diagnostic, 25 and assurance. Data models are also instrumental in the automation 26 of network management, and they can provide closed-loop control for 27 adaptive and deterministic service creation, delivery, and 28 maintenance. 30 This document describes an architecture for service and network 31 management automation that takes advantage of YANG modeling 32 technologies. This architecture is drawn from a Network Operator 33 perspective irrespective of the origin of a data module; it can thus 34 accommodate modules that are developed outside the IETF. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 12, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 5 72 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3. Architectural Concepts and Goals . . . . . . . . . . . . . . 6 75 3.1. Data Models: Layering and Representation . . . . . . . . 6 76 3.2. Automation of Service Delivery Procedures . . . . . . . . 10 77 3.3. Service Fullfillment Automation . . . . . . . . . . . . . 10 78 3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 11 79 4. Functional Blocks and Interactions . . . . . . . . . . . . . 11 80 4.1. Service Lifecycle Management Procedure . . . . . . . . . 12 81 4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 13 82 4.1.2. Service Creation/Modification . . . . . . . . . . . . 13 83 4.1.3. Service Optimization . . . . . . . . . . . . . . . . 13 84 4.1.4. Service Diagnosis . . . . . . . . . . . . . . . . . . 14 85 4.1.5. Service Decommission . . . . . . . . . . . . . . . . 14 86 4.2. Service Fullfillment Management Procedure . . . . . . . . 14 87 4.2.1. Intended Configuration Provision . . . . . . . . . . 15 88 4.2.2. Configuration Validation . . . . . . . . . . . . . . 15 89 4.2.3. Performance Monitoring/Model-driven Telemetry . . . . 16 90 4.2.4. Fault Diagnostic . . . . . . . . . . . . . . . . . . 16 91 4.3. Multi-Layer/Multi-Domain Service Mapping . . . . . . . . 16 92 4.4. Service Decomposing . . . . . . . . . . . . . . . . . . . 17 93 5. YANG Data Model Integration Examples . . . . . . . . . . . . 17 94 5.1. L2VPN/L3VPN Service Delivery . . . . . . . . . . . . . . 17 95 5.2. VN Lifecycle Management . . . . . . . . . . . . . . . . . 19 96 5.3. Event-based Telemetry in the Device Self Management . . . 20 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 100 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 10.2. Informative References . . . . . . . . . . . . . . . . . 24 104 Appendix A. Layered YANG Modules Examples Overview . . . . . . . 32 105 A.1. Service Models: Definition and Samples . . . . . . . . . 32 106 A.2. Network Models: Samples . . . . . . . . . . . . . . . . . 33 107 A.3. Device Models: Samples . . . . . . . . . . . . . . . . . 35 108 A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 37 109 A.3.2. Device Models: Samples . . . . . . . . . . . . . . . 37 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 112 1. Introduction 114 Service management systems usually comprise service activation/ 115 provision and service operation. Current service delivery 116 procedures, from the processing of customer's requirements and orders 117 to service delivery and operation, typically assume the manipulation 118 of data sequentially into multiple OSS/BSS applications that may be 119 managed by different departments within the service provider's 120 organization (e.g., billing factory, design factory, network 121 operation center). In addition, many of these applications have been 122 developed in-house over the years and operate in a silo mode: 124 o The lack of standard data input/output (i.e., data model) raises 125 many challenges in system integration and often results in manual 126 configuration tasks. 128 o Service fulfillment systems might have a limited visibility on the 129 network state and therefore have slow response to network changes. 131 Software Defined Networking (SDN) becomes crucial to address these 132 challenges. SDN techniques are meant to automate the overall service 133 delivery procedures and typically rely upon standard data models. 134 These models are used to not only reflect service providers' savoir- 135 faire, but also to dynamically instantiate and enforce a set of 136 service-inferred policies that best accommodate what has been defined 137 and possibly negotiated with the customer. [RFC7149] provides a 138 first tentative attempt to rationalize that service provider's view 139 on the SDN space by identifying concrete technical domains that need 140 to be considered and for which solutions can be provided: 142 o Techniques for the dynamic discovery of topology, devices, and 143 capabilities, along with relevant information and data models that 144 are meant to precisely document such topology, devices, and their 145 capabilities. 147 o Techniques for exposing network services [RFC8309] and their 148 characteristics. 150 o Techniques used by service-derived dynamic resource allocation and 151 policy enforcement schemes, so that networks can be programmed 152 accordingly. 154 o Dynamic feedback mechanisms that are meant to assess how 155 efficiently a given policy (or a set thereof) is enforced from a 156 service fulfillment and assurance perspectives. 158 Models are key for each of the aforementioned four technical items. 159 Service and network management automation is an important step to 160 improve the agility of network operations. Models are also important 161 to ease integrating multi-vendor solutions. 163 YANG [RFC7950] module developers have taken both top-down and bottom- 164 up approaches to develop modules [RFC8199] and to establish a mapping 165 between a network technology and customer requirements at the top or 166 abstracting common constructs from various network technologies at 167 the bottom. At the time of writing this document (2020), there are 168 many YANG data models including configuration and service models that 169 have been specified or are being specified by the IETF. They cover 170 many of the networking protocols and techniques. However, how these 171 models work together to configure a device, manage a set of devices 172 involved in a service, or provide a service is something that is not 173 currently documented either within the IETF or other Standards 174 Development Organizations (SDOs). 176 This document describes an architectural framework for service and 177 network management automation (Section 3) that takes advantage of 178 YANG modeling technologies and investigates how different layer YANG 179 data models interact with each other (e.g., service mapping, model 180 composing) in the context of service delivery and fulfillment 181 (Section 4). 183 This framework is drawn from a Network Operator perspective 184 irrespective of the origin of a data module; it can accommodate 185 modules that are developed outside the IETF. 187 The document identifies a list of use cases to exemplify the proposed 188 approach (Section 5), but it does not claim nor aim to be exhaustive. 190 2. Terminology and Acronyms 192 2.1. Terminology 194 The following terms are defined in [RFC8309][RFC8199] and are not 195 redefined here: 197 o Network Operator 199 o Customer 201 o Service 203 o Data Model 205 o Service Model 207 o Network Element Module 209 In addition, the document makes use of the following terms: 211 Network Model: Describes a network level abstraction (or a subset of 212 aspects of a network infrastructure), including devices and their 213 subsystems, and relevant protocols operating at the link and 214 network layers across multiple devices. This model corresponds to 215 the Network Configuration Model discussed in [RFC8309]. 217 It can be used by a Network Operator to allocate resources (e.g., 218 tunnel resource, topology resource) for the service or schedule 219 resources to meet the service requirements defined in a Service 220 Model. 222 Device Model: Refers to the Network Element YANG data model 223 described in [RFC8199] or the Device Configuration Model discussed 224 in [RFC8309]. 226 Device Models are also used to refer to model a function embedded 227 in a device (e.g., Network Address Translation (NAT) [RFC8512], 228 Access Control Lists (ACLs) [RFC8519]). 230 Pipe: Refers to a communication scope where only one-to-one (1:1) 231 communications are allowed. The scope can be identified between 232 ingress and egress nodes, two service sites, etc. 234 Hose: Refers to a communication scope where one-to-many (1:N) 235 communications are allowed (e.g., one site to multiple sites). 237 Funnel: Refers to a communication scope where many-to-one (N:1) 238 communications are allowed. 240 2.2. Acronyms 242 The following acronyms are used in the document: 244 ACL Access Control List 245 CE Customer Edge 246 ECA Event Condition Action 247 L2VPN Layer 2 Virtual Private Network 248 L3VPN Layer 3 Virtual Private Network 249 NAT Network Address Translation 250 OAM Operations, Administration, and Maintenance 251 OWD One-Way Delay 252 PE Provider Edge 253 QoS Quality of Service 254 RD Route Distinguisher 255 RT Route Target 256 SDN Software Defined Networking 257 TE Traffic Engineering 258 VN Virtual Network 259 VPN Virtual Private Network 260 VRF Virtual Routing and Forwarding 262 3. Architectural Concepts and Goals 264 3.1. Data Models: Layering and Representation 266 As described in Section 2 of [RFC8199], layering of modules allows 267 for better reusability of lower-layer modules by higher-level modules 268 while limiting duplication of features across layers. 270 Data models can be classified into Service, Network, and Device 271 Models. Different Service Models may rely on the same set of Network 272 and/or Device Models. 274 Service Models traditionally follow top-down approach and are mostly 275 customer-facing YANG modules providing a common model construct for 276 higher level network services (e.g., Layer 3 Virtual Private Network 277 (L3VPN)). Such modules can be mapped to network technology-specific 278 modules at lower layers (e.g., tunnel, routing, Quality of Service 279 (QoS), security). For example, the service level can be used to 280 characterise the network service(s) to be ensured between service 281 nodes (ingress/egress) such as: 283 o the communication scope (pipe, hose, funnel, ...), 284 o the directionality (inbound/outbound), 285 o the traffic performance guarantees (One-Way Delay (OWD) [RFC7679], 286 One-Way Loss [RFC7680], ...), 287 o link capacity [RFC5136][I-D.ietf-ippm-capacity-metric-method], 288 o etc. 290 Figure 1 depicts the example of a VoIP service that relies upon 291 connectivity services offered by a Network Operator. In this 292 example, the VoIP service is offered to the Network Operator's 293 customers by Service Provider (SP1). In order to provide global VoIP 294 reachability, SP1 service site interconnects with other Service 295 Providers service sites typically by interconnecting Session Border 296 Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406]. 297 For other VoIP destinations, sessions are forwarded over the 298 Internet. These connectivity services can be captured in a YANG 299 Service Module that reflects the service attributes that are shown in 300 Figure 2. This example follows the IP Connectivity Provisioning 301 Profile template defined in [RFC7297]. 303 ,--,--,--. ,--,--,--. 304 ,-' SP1 `-. ,-' SP2 `-. 305 ( Service Site ) ( Service Site ) 306 `-. ,-' `-. ,-' 307 `--'--'--' `--'--'--' 308 x | o * * | 309 (2)x | o * * | 310 ,x-,--o-*-. (1) ,--,*-,--. 311 ,-' x o * * * * * * * * * `-. 312 ( x o +----( Internet ) 313 User---(x x x o o o o o o o o o o o o o o o o o o 314 `-. ,-' `-. ,-' (3) 315 `--'--'--' `--'--'--' 316 Network Operator 318 **** (1) Inter-SP connectivity 319 xxxx (2) Customer to SP connectivity 320 oooo (3) SP to any destination connectivity 322 Figure 1: An Example of Service Connectivty Components 324 Connectivity: Scope and Guarantees 325 (1) Inter-SP connectivity 326 - Pipe scope from the local to the remote SBE/DBE 327 - Full guarantees class 328 (2) Customer to SP connectivity 329 - Hose/Funnel scope connecting the local SBE/DBE 330 to the customer access points 331 - Full guarantees class 332 (3) SP to any destination connectivity 333 - Hose/Funnel scope from the local SBE/DBE to the 334 Internet gateway 335 - Delay guarantees class 336 Flow Identification 337 * Destination IP address (SBE, DBE) 338 * DSCP marking 339 Traffic Isolation 340 * VPN 341 Routing & Forwarding 342 * Routing rule to exclude some ASes from the inter-domain 343 paths 344 Notifications (including feedback) 345 * Statistics on aggregate traffic to adjust capacity 346 * Failures 347 * Planned maintenance operations 348 * Triggered by thresholds 350 Figure 2: Sample Attributes Captured in a Service Model 352 Network Models are mainly network resource-facing modules; they 353 describe various aspects of a network infrastructure, including 354 devices and their subsystems, and relevant protocols operating at the 355 link and network layers across multiple devices (e.g., network 356 topology and traffic-engineering tunnel modules). 358 Device (and function) Models usually follow a bottom-up approach and 359 are mostly technology-specific modules used to realize a service 360 (e.g., BGP, NAT). 362 Each level maintains a view of the supported YANG modules provided by 363 low-levels (see for example, Appendix A). 365 Figure 3 illustrates the overall layering model. The reader may 366 refer to Section 4 of [RFC8309] for an overview of "Orchestrator" and 367 "Controller" elements. 369 +-----------------------------------------------------------------+ 370 | +-----------------------+ | 371 | | Orchestrator | Hierarchy Abstraction | 372 | |+---------------------+| | 373 | || Service Modeling || Service Model | 374 | |+---------------------+| (Customer Oriented) | 375 | | | Scope: "1:1" Pipe model | 376 | | | Bidirectional | 377 | |+---------------------+| +-+ Capacity,OWD +-+ | 378 | ||Service Orchestration|| | +----------------+ | | 379 | |+---------------------+| +-+ +-+ | 380 | +-----------------------+ 1. Ingress 2. Egress | 381 | | 382 | | 383 | | 384 | +-----------------------+ Network Model | 385 | | Controller | (Operator Oriented) | 386 | |+---------------------+| +-+ +--+ +---+ +-+ | 387 | || Network Modeling || | | | | | | | | | 388 | |+---------------------+| | o----o--o----o---o---o | | 389 | |+---------------------+| +-+ +--+ +---+ +-+ | 390 | ||Network Orchestration|| src dst | 391 | |+---------------------+| L3VPN over TE | 392 | | | Instance Name/Access Interface | 393 | +-----------------------+ Protocol Type/Capacity/RD/RT/... | 394 | mapping for hop | 395 | | 396 | | 397 | +-----------------------+ | 398 | | Device | Device Model | 399 | |+--------------------+ | | 400 | || Device Modeling | | Interface add, BGP Peer, | 401 | |+--------------------+ | Tunnel ID, QoS/TE, ... | 402 | +-----------------------+ | 403 +-----------------------------------------------------------------+ 405 Figure 3: Layering and Representation 407 The layering model depicted in Figure 3 does not make any assumption 408 about the location of the various entities (e.g., controller, 409 orchestrator) within the network. As such, the architecture does not 410 preclude deployments where, for example, the controller is embedded 411 on a device that hosts other functions that are controlled via YANG 412 modules. 414 In order to ease the mapping between layers and data reuse, this 415 document focuses on service models that are modelled using YANG. 416 Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3 417 does not preclude service models to be modelled using other data 418 modelling languages than YANG. 420 3.2. Automation of Service Delivery Procedures 422 Service Models can be used by a Network Operator to expose its 423 services to its customers. Exposing such models allows to automate 424 the activation of service orders and thus the service delivery. One 425 or more monolithic Service Models can be used in the context of a 426 composite service activation request (e.g., delivery of a caching 427 infrastructure over a VPN). Such models are used to feed a decision- 428 making intelligence to adequately accommodate customer's needs. 430 Also, such models may be used jointly with services that require 431 dynamic invocation. An example is provided by the service modules 432 defined by the DOTS WG to dynamically trigger requests to handle 433 Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service 434 filtering request modelled using [RFC8783] will be translated into 435 device-specific filtering (e.g., ACLs defined in [RFC8519]) that to 436 fulfil the service request. 438 Network Models can be derived from Service Models and used to 439 provision, monitor, instantiate the service, and provide lifecycle 440 management of network resources. Doing so is meant to: 442 o expose network resources to customers (including other Network 443 Operators) to provide service fulfillment and assurance. 445 o allow customers (or Network Operators) to dynamically adjust the 446 network resources based on service requirements as described in 447 Service Models (e.g., Figure 2) and the current network 448 performance information described in the telemetry modules. 450 3.3. Service Fullfillment Automation 452 To operate a service, the settings of the parameters in the Device 453 Models are derived from Service Models and/or Network Models and are 454 used to: 456 o Provision each involved network function/device with the proper 457 configuration information. 459 o Operate the network based on service requirements as described in 460 the Service Model(s) and local operational guidelines. 462 In addition, the operational state including configuration that is in 463 effect together with statistics should be exposed to upper layers to 464 provide better network visibility and assess to what extent the 465 derived low level modules are consistent with the upper level inputs. 467 Filters are enforced on the notifications that are communicated to 468 Service layers. The type and frequency of notifications may be 469 agreed in the Service Model. 471 Note that it is important to correlate telemetry data with 472 configuration data to be used for closed loops at the different 473 stages of service delivery, from resource allocation to service 474 operation, in particular. 476 3.4. YANG Modules Integration 478 To support top-down service delivery, YANG modules at different 479 levels or at the same level need to be integrated together for proper 480 service delivery (including, proper network setup). For example, the 481 service parameters captured in Service Models need to be decomposed 482 into a set of configuration/notification parameters that may be 483 specific to one or more technologies; these technology-specific 484 parameters are grouped together to define technology-specific device 485 level models or network level models. 487 In addition, these technology-specific Device or Network Models can 488 be further integrated with each other using the schema mount 489 mechanism [RFC8528] to provision each involved network function/ 490 device or each involved administrative domain to support newly added 491 module or features. A collection of Device Models integrated 492 together can be loaded and validated during the implementation time. 494 High-level policies can be defined at Service or Network Models 495 (e.g., "Autonomous System Number (ASN) Exclude" in the example 496 depicted in Figure 2). Device Models will be tweaked accordingly to 497 provide policy-based management. Policies can also be used for 498 telemetry automation, e.g., policies that contain conditions can 499 trigger the generation and pushing of new telemetry data. 501 Performance measurement telemetry can be used to provide service 502 assurance at Service and/or Network levels. Performance measurement 503 telemetry model can tie with Service or Network Models to monitor 504 network performance or Service Level Agreement. 506 4. Functional Blocks and Interactions 508 The architectural considerations described in Section 3 lead to the 509 architecture described in this section and illustrated in Figure 4. 511 +------------------+ 512 ................. | | 513 Service level | | 514 V | 515 E2E E2E E2E E2E 516 Service --> Service ---------> Service -----> Service -----+ 517 Exposure Creation ^ Optimization ^ Diagnosis | 518 /Modification | | | 519 | |Diff | V 520 Multi-layer | | E2E | E2E 521 Multi-domain | | Service | Service 522 Service Mapping| +------ Assurance --+ Decommission 523 | ^ 524 ................. |<-----------------+ | 525 Network level | | +-------+ 526 V | | 527 Specific Specific | 528 Service --------> Service <--+ | 529 Creation ^ Optimization | | 530 /Modification | | | 531 | |Diff | | 532 | | Specific --+ | 533 Service | | Service | 534 Decomposing | +----- Assurance ----+ 535 | ^ 536 ................. | | Aggregation 537 Device level | +------------+ 538 V | 539 Service Intent | 540 Fulfillment Config ----> Config ----> Performance ----> Fault 541 Provision Validate Monitoring Diagnostic 543 Figure 4: Service and Network Lifecycle Management 545 4.1. Service Lifecycle Management Procedure 547 Service lifecycle management includes end-to-end service lifecycle 548 management at the service level and technology specific network 549 lifecycle management at the network level. 551 The end-to-end service lifecycle management is technology-independent 552 service management and spans across multiple administrative domain or 553 multiple layers while technology specific service lifecycle 554 management is technology domain specific or layer specific service 555 lifecycle management. 557 4.1.1. Service Exposure 559 A service in the context of this document (sometimes called, Network 560 Service) is some form of connectivity between customer sites and the 561 Internet or between customer sites across the operator's network and 562 across the Internet. 564 Service exposure is used to capture services offered to customers 565 (ordering and order handling). One typical example is that a 566 customer can use a L3VPN Service Model (L3SM) to request L3VPN 567 service by providing the abstract technical characterization of the 568 intended service between customer sites. 570 Service Model catalogs can be created along to expose the various 571 services and the information needed to invoke/order a given service. 573 4.1.2. Service Creation/Modification 575 A customer is usually unaware of the technology that the Network 576 Operator has available to deliver the service, so the customer does 577 not make requests specific to the underlying technology but is 578 limited to making requests specific to the service that is to be 579 delivered. This service request can be issued using a Service Model. 581 Upon receiving a service request, and assuming that appropriate 582 authentication and authorization checks have been made, the service 583 orchestrator/management system should verify whether the service 584 requirements in the service request can be met (i.e., whether there 585 is sufficient resources that can be allocated with the requested 586 guarantees). 588 If the request is accepted, the service orchestrator/management 589 system maps such service request to its view. This view can be 590 described as a technology specific network model or a set of 591 technology specific Device Models and this mapping may include a 592 choice of which networks and technologies to use depending on which 593 service features have been requested. 595 In addition, a customer may require to change the underlying network 596 infrastructure to adapt to new customer's needs and service 597 requirements. This service modification can be issued following the 598 same Service Model used by the service request. 600 4.1.3. Service Optimization 602 Service optimization is a technique that gets the configuration of 603 the network updated due to network changes, incidents mitigation, or 604 new service requirements. One typical example is once a tunnel or a 605 VPN is setup, Performance monitoring information or telemetry 606 information per tunnel (or per VPN) can be collected and fed into the 607 management system. If the network performance doesn't meet the 608 service requirements, the management system can create new VPN 609 policies capturing network service requirements and populate them 610 into the network. 612 Both network performance information and policies can be modelled 613 using YANG. With Policy-based management, self-configuration and 614 self-optimization behavior can be specified and implemented. 616 4.1.4. Service Diagnosis 618 Operations, Administration, and Maintenance (OAM) are important 619 networking functions for service diagnosis that allow Network 620 Operators to: 622 o monitor network communications (i.e., reachability verification 623 and Continuity Check) 625 o troubleshoot failures (i.e., fault verification and localization) 627 o monitor service-level agreements and performance (i.e., 628 performance management) 630 When the network is down, service diagnosis should be in place to 631 pinpoint the problem and provide recommendations (or instructions) 632 for the network recovery. 634 The service diagnosis information can be modelled as technology- 635 independent Remote Procedure Call (RPC) operations for OAM protocols 636 and technology-independent abstraction of key OAM constructs for OAM 637 protocols [RFC8531][RFC8533]. These models can be used to provide 638 consistent configuration, reporting, and presentation for the OAM 639 mechanisms used to manage the network. 641 4.1.5. Service Decommission 643 Service decommission allows a customer to stop the service by 644 removing the service from active status and thus releasing the 645 network resources that were allocated to the service. Customers can 646 also use the Service Model to withdraw the registration to a service. 648 4.2. Service Fullfillment Management Procedure 649 4.2.1. Intended Configuration Provision 651 Intended configuration at the device level is derived from Network 652 Models at the network level or Service Model at the service level and 653 represents the configuration that the system attempts to apply. Take 654 L3SM as a Service Model example to deliver a L3VPN service, we need 655 to map the L3VPN service view defined in the Service Model into 656 detailed intended configuration view defined by specific 657 configuration models for network elements, configuration information 658 includes: 660 o Virtual Routing and Forwarding (VRF) definition, including VPN 661 policy expression 663 o Physical Interface(s) 665 o IP layer (IPv4, IPv6) 667 o QoS features such as classification, profiles, etc. 669 o Routing protocols: support of configuration of all protocols 670 listed in a service request, as well as routing policies 671 associated with those protocols. 673 o Multicast support 675 o Address sharing (e.g., NAT) 677 o Security 679 These specific configuration models can be used to configure Provider 680 Edge (PE) and Customer Edge (CE) devices within a site, e.g., a BGP 681 policy model can be used to establish VPN membership between sites 682 and VPN Service Topology. 684 4.2.2. Configuration Validation 686 Configuration validation is used to validate intended configuration 687 and ensure the configuration take effect. 689 For example, a customer creates an interface "eth-0/0/0" but the 690 interface does not physically exist at this point, then configuration 691 data appears in the status but does not appear in 692 datastore. 694 4.2.3. Performance Monitoring/Model-driven Telemetry 696 When configuration is in effect in the device, 697 datastore holds the complete operational state of the device 698 including learned, system, default configuration, and system state. 699 However, the configurations and state of a particular device does not 700 have the visibility to the whole network or information of the flow 701 packets are going to take through the entire network. Therefore it 702 becomes more difficult to operate the network without understanding 703 the current status of the network. 705 The management system should subscribe to updates of a YANG datastore 706 in all the network devices for performance monitoring purpose and 707 build a full topological visibility of the network by aggregating 708 (and filtering) these operational state from different sources. 710 4.2.4. Fault Diagnostic 712 When configuration is in effect in the device, some devices may be 713 mis-configured (e.g.,device links are not consistent in both sides of 714 the network connection), network resources be mis-allocated and 715 services may be negatively affected without knowing what is going on 716 in the network. 718 Technology-dependent nodes and RPC commands are defined in 719 technology-specific YANG data models which can use and extend the 720 base model described in Section 4.1.4 to deal with these issues. 722 These RPC commands received in the technology-dependent node can be 723 used to trigger technology-specific OAM message exchanges for fault 724 verification and fault isolation For example, TRILL Multicast Tree 725 Verification (MTV) RPC command [I-D.ietf-trill-yang-oam] can be used 726 to trigger Multi-Destination Tree Verification Message defined in 727 [RFC7455] to verify TRILL distribution tree integrity. 729 4.3. Multi-Layer/Multi-Domain Service Mapping 731 Multi-layer/Multi-domain Service Mapping allows to map an end-to-end 732 abstract view of the service segmented at different layers or 733 different administrative domains into domain-specific view. 735 One example is to map service parameters in L3VPN service model into 736 configuration parameters such as Route Distinguisher (RD), Route 737 Target (RT), and VRF in L3VPN network model. 739 Another example is to map service parameters in L3VPN service model 740 into Traffic Engineered (TE) tunnel parameter (e.g., Tunnel ID) in TE 741 model and Virtual Network (VN) parameters (e.g., Access Point (AP) 742 list, VN members) in the YANG data model for VN operation 743 [I-D.ietf-teas-actn-vn-yang]. 745 4.4. Service Decomposing 747 Service Decomposing allows to decompose service model at the service 748 level or network model at the network level into a set of device/ 749 function models at the device level. These Device Models may be tied 750 to specific device types or classified into a collection of related 751 YANG modules based on service types and features offered, and load at 752 the implementation time before configuration is loaded and validated. 754 5. YANG Data Model Integration Examples 756 The following subsections provides some YANG data models integration 757 examples. 759 5.1. L2VPN/L3VPN Service Delivery 761 In reference to Figure 5, the following steps are performed to 762 deliver the L3VPN service within the network management automation 763 architecture defined in this document: 765 1. The Customer requests to create two sites (as per service 766 creation operation in Section 4.2.1) relying upon a L3SM Service 767 model with each having one network access connectivity, for 768 example: 770 * Site A: Network-Access A, Link Capacity = 20 Mbps, for class 771 "foo", guaranteed-capacity-percent = 10, average-One-Way-Delay 772 = 70 ms. 774 * Site B: Network-Access B, Link Capacity = 30 Mbps, for class 775 "foo1", guaranteed-capacity-percent = 15, average-One-Way- 776 Delay = 60 ms. 778 2. The Orchestrator extracts the service parameters from the L3SM 779 model. Then, it uses them as input to translate ("service 780 mapping operation" in Section 4.4) them into an orchestrated 781 configuration of network elements (e.g., RD, RT, VRF) that are 782 part of the L3VPN Network YANG Model specified in 783 [I-D.ietf-opsawg-l3sm-l3nm]. 785 3. The Controller takes orchestrated configuration parameters in the 786 L3NM network model and translates them into orchestrated 787 ("service decomposing operation" in ) configuration of network 788 elements that are part of, e.g., BGP, QoS, Network Instance 789 model, IP management, and interface models. 791 [I-D.ogondio-opsawg-uni-topology] can be used for representing, 792 managing, and controlling the User Network Interface (UNI) topology. 794 L3SM | 795 Service | 796 Model | 797 +----------------------+--------------------------+ 798 | +--------V--------+ | 799 | | Service Mapping | | 800 | +--------+--------+ | 801 | Orchestrator | | 802 +----------------------+--------------------------+ 803 L3NM | ^ UNI Topology Model 804 Network| | 805 Model | | 806 +----------------------+--------------------------+ 807 | +----------V-----------+ | 808 | | Service Decomposing | | 809 | +---++--------------++-+ | 810 | || || | 811 | Controller || || | 812 +---------------++--------------++----------------+ 813 || || 814 || BGP, || 815 || QoS, || 816 || Interface, || 817 +------------+| NI, |+--------------+ 818 | | IP | | 819 +--+--+ +--+--+ +--+--+ +--+--+ 820 | CE1 +-------+ PE1 | | PE2 +---------+ CE2 | 821 +-----+ +-----+ +-----+ +-----+ 823 Figure 5: L3VPN Service Delivery Example (Current) 825 L3NM inherits some of data elements from the L3SM. Nevertheless, the 826 L3NM does not expose some information to the above layer such as the 827 capabilities of an underlying network (which can be used to drive 828 service order handling) or notifications (to notify subscribers about 829 specific events or degradations as per agreed SLAs). Some of this 830 information can be provided using, e.g., 831 [I-D.www-bess-yang-vpn-service-pm]. A target overall model is 832 depicted in Figure 6. 834 L3SM | ^ 835 Service | | Notifications 836 Model | | 837 +----------------------+--------------------------+ 838 | +--------V--------+ | 839 | | Service Mapping | | 840 | +--------+--------+ | 841 | Orchestrator | | 842 +----------------------+--------------------------+ 843 L3NM | ^ UNI Topology Model 844 Network| | L3NM Notifications 845 Model | | L3NM Capabilities 846 +----------------------+--------------------------+ 847 | +----------V-----------+ | 848 | | Service Decomposing | | 849 | +---++--------------++-+ | 850 | || || | 851 | Controller || || | 852 +---------------++--------------++----------------+ 853 || || 854 || BGP, || 855 || QoS, || 856 || Interface, || 857 +------------+| NI, |+--------------+ 858 | | IP | | 859 +--+--+ +--+--+ +--+--+ +--+--+ 860 | CE1 +-------+ PE1 | | PE2 +---------+ CE2 | 861 +-----+ +-----+ +-----+ +-----+ 863 Figure 6: L3VPN Service Delivery Example (Target) 865 Note that a similar analysis can be performed for Layer 2 VPNs 866 (L2VPNs). A L2VPN Service Model (L2SM) is defined in [RFC8466], 867 while the L2VPN Network YANG Model (L2NM) is specified in 868 [I-D.ietf-opsawg-l2nm]. 870 5.2. VN Lifecycle Management 872 In reference to Figure 7, the following steps are performed to 873 deliver the VN service within the network management automation 874 architecture defined in this document: 876 1. Customer requests (service exposure operation in Section 4.1.1) 877 to create 'VN' based on Access point, association between VN and 878 Access point, VN member defined in the VN YANG module. 880 2. The orchestrator creates the single abstract node topology based 881 on the information captured in an VN YANG module. 883 3. The Customer exchanges connectivity-matrix on abstract node and 884 explicit path using TE topology model with the orchestrator. 885 This information can be used to instantiate VN and setup tunnels 886 between source and destination endpoints (service creation 887 operation in Section 4.1.2). 889 4. The telemetry model which augments the VN model and corresponding 890 TE tunnel model can be used to subscribe to performance 891 measurement data and notify all the parameter changes and network 892 performance change related to VN topology or Tunnel 893 [I-D.ietf-teas-actn-pm-telemetry-autonomics] and provide service 894 assurance (service optimization operation in Section 4.1.3). 896 | 897 VN | 898 Service | 899 Model | 900 +----------------------|--------------------------+ 901 | Orchestrator | | 902 | +--------V--------+ | 903 | | Service Mapping | | 904 | +-----------------+ | 905 +----------------------+--------------------^-----+ 906 TE | Telemetry 907 Tunnel | Model 908 Model | | 909 +----------------------V--------------------+-----+ 910 | Controller | 911 | | 912 +-------------------------------------------------+ 914 +-----+ +-----+ +-----+ +-----+ 915 | CE1 +------+ PE1 | | PE2 +------+ CE2 | 916 +-----+ +-----+ +-----+ +-----+ 918 Figure 7: A VN Service Delivery Example 920 5.3. Event-based Telemetry in the Device Self Management 922 In reference to Figure 8, the following steps are performed to 923 monitor state changes of managed objects or resources in a network 924 device and provide device self-management within the network 925 management automation architecture defined in this document: 927 1. To control which state a network device should be in or is 928 allowed to be in at any given time, a set of conditions and 929 actions are defined and correlated with network events (e.g., 930 allow the NETCONF server to send updates only when the value 931 exceeds a certain threshold for the first time, but not again 932 until the threshold is cleared), which constitute ECA policy or 933 an event-driven policy control logic that can be executed on the 934 device (e.g., [I-D.wwx-netmod-event-yang]). 936 2. To provide rapid autonomic response that can exhibit self- 937 management properties, the controller pushes the ECA policy to 938 the network device and delegates network control logic to the 939 network device. 941 3. The network device uses the ECA model to subscribe to the event 942 source, e.g., an event stream or datastore state data conveyed to 943 the server via YANG Push subscription, monitors state parameters, 944 and takes simple and instant actions when associated event 945 condition on state parameters is met. ECA notifications can be 946 generated as the result of actions based on event stream 947 subscription or datastore subscription (model-driven telemetry 948 operation discussed in Section 4.2.3). 950 +----------------+ 951 | <----+ 952 | Controller | | 953 +-------+--------+ | 954 | | 955 | | 956 ECA | | ECA 957 Model | | Notification 958 | | 959 | | 960 +------------V-------------+-----+ 961 |Device | | 962 | +-------+ +---------+ +--+---+ | 963 | | Event +-> Event +->Event | | 964 | | Source| |Condition| |Action| | 965 | +-------+ +---------+ +------+ | 966 +--------------------------------+ 968 Figure 8: Event-based Telemetry 970 6. Security Considerations 972 The YANG modules cited in this document define schema for data that 973 are designed to be accessed via network management protocols such as 974 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 975 the secure transport layer, and the mandatory-to-implement secure 976 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 977 is HTTPS, and the mandatory-to-implement secure transport is TLS 978 [RFC8446]. 980 The NETCONF access control model [RFC8341] provides the means to 981 restrict access for particular NETCONF or RESTCONF users to a 982 preconfigured subset of all available NETCONF or RESTCONF protocol 983 operations and content. 985 Security considerations specific to each of the technologies and 986 protocols listed in the document are discussed in the specification 987 documents of each of these protocols. 989 Security considerations specific to this document are listed below: 991 o Create forwarding loops by mis-configuring the underlying network. 993 o Leak sensitive information: special care should be considered when 994 translating between the various layers in Section 4 or when 995 aggregating data retrieved from various sources. The Network 996 Operator must enforce means to protect privacy-related information 997 included in cutsomer-facing models. 999 o Some Service Models may include a traffic isolation clause, 1000 appropriate technology-specific actions must be enforced to avoid 1001 that traffic is accessible to non-authorized parties. 1003 7. IANA Considerations 1005 There are no IANA requests or assignments included in this document. 1007 8. Acknowledgements 1009 Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter, 1010 and Adrian Farrel for the review. 1012 Many thanks to Robert Wilton for the detailed AD review. 1014 9. Contributors 1015 Christian Jacquenet 1016 Orange 1017 Rennes, 35000 1018 France 1019 Email: Christian.jacquenet@orange.com 1021 Luis Miguel Contreras Murillo 1022 Telifonica 1024 Email: luismiguel.contrerasmurillo@telefonica.com 1026 Oscar Gonzalez de Dios 1027 Telefonica 1028 Madrid 1029 ES 1031 Email: oscar.gonzalezdedios@telefonica.com 1033 Weiqiang Cheng 1034 China Mobile 1036 Email: chengweiqiang@chinamobile.com 1038 Young Lee 1039 Sung Kyun Kwan University 1041 Email: younglee.tx@gmail.com 1043 10. References 1045 10.1. Normative References 1047 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1048 and A. Bierman, Ed., "Network Configuration Protocol 1049 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1050 . 1052 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1053 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1054 . 1056 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1057 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1058 . 1060 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1061 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1062 . 1064 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1065 Access Control Model", STD 91, RFC 8341, 1066 DOI 10.17487/RFC8341, March 2018, 1067 . 1069 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1070 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1071 . 1073 10.2. Informative References 1075 [I-D.clacla-netmod-model-catalog] 1076 Clarke, J. and B. Claise, "YANG module for 1077 yangcatalog.org", draft-clacla-netmod-model-catalog-03 1078 (work in progress), April 2018. 1080 [I-D.ietf-bess-evpn-yang] 1081 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 1082 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 1083 bess-evpn-yang-07 (work in progress), March 2019. 1085 [I-D.ietf-bess-l2vpn-yang] 1086 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1087 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1088 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 1089 July 2019. 1091 [I-D.ietf-bess-l3vpn-yang] 1092 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 1093 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 1094 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 1095 in progress), October 2018. 1097 [I-D.ietf-bess-mvpn-yang] 1098 Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and 1099 M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP 1100 IP VPNs", draft-ietf-bess-mvpn-yang-04 (work in progress), 1101 June 2020. 1103 [I-D.ietf-bfd-yang] 1104 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 1105 and G. Mirsky, "YANG Data Model for Bidirectional 1106 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 1107 in progress), August 2018. 1109 [I-D.ietf-i2rs-yang-l2-network-topology] 1110 Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A 1111 YANG Data Model for Layer 2 Network Topologies", draft- 1112 ietf-i2rs-yang-l2-network-topology-17 (work in progress), 1113 August 2020. 1115 [I-D.ietf-idr-bgp-model] 1116 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1117 YANG Model for Service Provider Networks", draft-ietf-idr- 1118 bgp-model-09 (work in progress), June 2020. 1120 [I-D.ietf-ippm-capacity-metric-method] 1121 Morton, A., Geib, R., and L. Ciavattone, "Metrics and 1122 Methods for IP Capacity", draft-ietf-ippm-capacity-metric- 1123 method-03 (work in progress), August 2020. 1125 [I-D.ietf-ippm-stamp-yang] 1126 Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active 1127 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 1128 stamp-yang-05 (work in progress), October 2019. 1130 [I-D.ietf-ippm-twamp-yang] 1131 Civil, R., Morton, A., Rahman, R., Jethanandani, M., and 1132 K. Pentikousis, "Two-Way Active Measurement Protocol 1133 (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work 1134 in progress), July 2018. 1136 [I-D.ietf-mpls-base-yang] 1137 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 1138 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 1139 yang-15 (work in progress), August 2020. 1141 [I-D.ietf-netmod-module-tags] 1142 Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module 1143 Tags", draft-ietf-netmod-module-tags-10 (work in 1144 progress), February 2020. 1146 [I-D.ietf-opsawg-l2nm] 1147 barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil, 1148 L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- 1149 ietf-opsawg-l2nm-00 (work in progress), July 2020. 1151 [I-D.ietf-opsawg-l3sm-l3nm] 1152 barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. 1153 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 1154 opsawg-l3sm-l3nm-03 (work in progress), April 2020. 1156 [I-D.ietf-pim-igmp-mld-snooping-yang] 1157 Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, 1158 "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- 1159 pim-igmp-mld-snooping-yang-18 (work in progress), August 1160 2020. 1162 [I-D.ietf-pim-yang] 1163 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1164 Y., and f. hu, "A YANG Data Model for Protocol Independent 1165 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1166 progress), May 2018. 1168 [I-D.ietf-rtgwg-policy-model] 1169 Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data 1170 Model for Routing Policy Management", draft-ietf-rtgwg- 1171 policy-model-21 (work in progress), September 2020. 1173 [I-D.ietf-rtgwg-qos-model] 1174 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 1175 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 1176 model-02 (work in progress), July 2020. 1178 [I-D.ietf-spring-sr-yang] 1179 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 1180 Tantsura, "YANG Data Model for Segment Routing", draft- 1181 ietf-spring-sr-yang-22 (work in progress), August 2020. 1183 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 1184 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 1185 and D. Ceccarelli, "YANG models for VN/TE Performance 1186 Monitoring Telemetry and Scaling Intent Autonomics", 1187 draft-ietf-teas-actn-pm-telemetry-autonomics-03 (work in 1188 progress), July 2020. 1190 [I-D.ietf-teas-actn-vn-yang] 1191 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1192 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1193 teas-actn-vn-yang-09 (work in progress), July 2020. 1195 [I-D.ietf-teas-yang-path-computation] 1196 Busi, I., Belotti, S., Lopezalvarez, V., Sharma, A., and 1197 Y. Shi, "Yang model for requesting Path Computation", 1198 draft-ietf-teas-yang-path-computation-10 (work in 1199 progress), July 2020. 1201 [I-D.ietf-teas-yang-rsvp-te] 1202 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 1203 and H. Shah, "A YANG Data Model for RSVP-TE Protocol", 1204 draft-ietf-teas-yang-rsvp-te-08 (work in progress), March 1205 2020. 1207 [I-D.ietf-teas-yang-te] 1208 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1209 "A YANG Data Model for Traffic Engineering Tunnels, Label 1210 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 1211 (work in progress), July 2020. 1213 [I-D.ietf-trill-yang-oam] 1214 Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., 1215 and H. Weiguo, "YANG Data Model for TRILL Operations, 1216 Administration, and Maintenance (OAM)", draft-ietf-trill- 1217 yang-oam-05 (work in progress), March 2017. 1219 [I-D.ogondio-opsawg-uni-topology] 1220 Dios, O., barguil, s., WU, Q., and M. Boucadair, "A YANG 1221 Model for User-Network Interface (UNI) Topologies", draft- 1222 ogondio-opsawg-uni-topology-01 (work in progress), April 1223 2020. 1225 [I-D.www-bess-yang-vpn-service-pm] 1226 WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., and H. 1227 Xu, "A YANG Model for Network and VPN Service Performance 1228 Monitoring", draft-www-bess-yang-vpn-service-pm-06 (work 1229 in progress), April 2020. 1231 [I-D.wwx-netmod-event-yang] 1232 Bierman, A., WU, Q., Bryskin, I., Birkholz, H., Liu, X., 1233 and B. Claise, "A YANG Data model for ECA Policy 1234 Management", draft-wwx-netmod-event-yang-09 (work in 1235 progress), July 2020. 1237 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1238 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1239 2006, . 1241 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1242 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1243 DOI 10.17487/RFC4664, September 2006, 1244 . 1246 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1247 LAN Service (VPLS) Using BGP for Auto-Discovery and 1248 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1249 . 1251 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1252 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1253 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1254 . 1256 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 1257 RFC 5136, DOI 10.17487/RFC5136, February 2008, 1258 . 1260 [RFC5486] Malas, D., Ed. and D. Meyer, Ed., "Session Peering for 1261 Multimedia Interconnect (SPEERMINT) Terminology", 1262 RFC 5486, DOI 10.17487/RFC5486, March 2009, 1263 . 1265 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1266 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1267 . 1269 [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for 1270 Multimedia INTerconnect (SPEERMINT) Architecture", 1271 RFC 6406, DOI 10.17487/RFC6406, November 2011, 1272 . 1274 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1275 Networking: A Perspective from within a Service Provider 1276 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1277 . 1279 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1280 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1281 . 1283 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1284 Weingarten, "An Overview of Operations, Administration, 1285 and Maintenance (OAM) Tools", RFC 7276, 1286 DOI 10.17487/RFC7276, June 2014, 1287 . 1289 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1290 Connectivity Provisioning Profile (CPP)", RFC 7297, 1291 DOI 10.17487/RFC7297, July 2014, 1292 . 1294 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 1295 3rd, D., Aldrin, S., and Y. Li, "Transparent 1296 Interconnection of Lots of Links (TRILL): Fault 1297 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 1298 . 1300 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1301 Ed., "A One-Way Delay Metric for IP Performance Metrics 1302 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1303 2016, . 1305 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1306 Ed., "A One-Way Loss Metric for IP Performance Metrics 1307 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1308 2016, . 1310 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 1311 Maintenance Using the Label Distribution Protocol (LDP)", 1312 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 1313 . 1315 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1316 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1317 August 2017, . 1319 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1320 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1321 2017, . 1323 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1324 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1325 DOI 10.17487/RFC8299, January 2018, 1326 . 1328 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1329 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1330 . 1332 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1333 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1334 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1335 2018, . 1337 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1338 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1339 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1340 March 2018, . 1342 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1343 Routing Management (NMDA Version)", RFC 8349, 1344 DOI 10.17487/RFC8349, March 2018, 1345 . 1347 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1348 Data Model for Layer 2 Virtual Private Network (L2VPN) 1349 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1350 2018, . 1352 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1353 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1354 Address Translation (NAT) and Network Prefix Translation 1355 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1356 . 1358 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1359 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1360 DOI 10.17487/RFC8513, January 2019, 1361 . 1363 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1364 "YANG Data Model for Network Access Control Lists (ACLs)", 1365 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1366 . 1368 [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", 1369 RFC 8528, DOI 10.17487/RFC8528, March 2019, 1370 . 1372 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1373 Liu, "YANG Data Model for Network Instances", RFC 8529, 1374 DOI 10.17487/RFC8529, March 2019, 1375 . 1377 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1378 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1379 DOI 10.17487/RFC8530, March 2019, 1380 . 1382 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1383 for Connection-Oriented Operations, Administration, and 1384 Maintenance (OAM) Protocols", RFC 8531, 1385 DOI 10.17487/RFC8531, April 2019, 1386 . 1388 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1389 Raghavan, "Generic YANG Data Model for the Management of 1390 Operations, Administration, and Maintenance (OAM) 1391 Protocols That Use Connectionless Communications", 1392 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1393 . 1395 [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. 1396 Raghavan, "A YANG Data Model for Retrieval Methods for the 1397 Management of Operations, Administration, and Maintenance 1398 (OAM) Protocols That Use Connectionless Communications", 1399 RFC 8533, DOI 10.17487/RFC8533, April 2019, 1400 . 1402 [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm 1403 Management", RFC 8632, DOI 10.17487/RFC8632, September 1404 2019, . 1406 [RFC8652] Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 1407 Peter, "A YANG Data Model for the Internet Group 1408 Management Protocol (IGMP) and Multicast Listener 1409 Discovery (MLD)", RFC 8652, DOI 10.17487/RFC8652, November 1410 2019, . 1412 [RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data 1413 Model for Tunnel Interface Types", RFC 8675, 1414 DOI 10.17487/RFC8675, November 2019, 1415 . 1417 [RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for 1418 IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, 1419 DOI 10.17487/RFC8676, November 2019, 1420 . 1422 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 1423 Denial-of-Service Open Threat Signaling (DOTS) Data 1424 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 1425 May 2020, . 1427 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1428 O. Gonzalez de Dios, "YANG Data Model for Traffic 1429 Engineering (TE) Topologies", RFC 8795, 1430 DOI 10.17487/RFC8795, August 2020, 1431 . 1433 Appendix A. Layered YANG Modules Examples Overview 1435 This appendix lists a set of YANG data models that can be used for 1436 the delivery of connectivity services. These models can be 1437 classified as Service, Network, or Device Models. 1439 It is not the intent of this appendix to provide an inventory of 1440 tools and mechanisms used in specific network and service management 1441 domains; such inventory can be found in documents such as [RFC7276]. 1443 The reader may refer to the YANG Catalog 1444 () or the public Github YANG repository 1445 () to query existing YANG models. 1446 The YANG Catalog includes some metadata to indicate the module type 1447 ('module-classification') [I-D.clacla-netmod-model-catalog]. Note 1448 that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to 1449 associate tags with YANG modules in order to help classifying the 1450 modules. 1452 A.1. Service Models: Definition and Samples 1454 As described in [RFC8309], the service is "some form of connectivity 1455 between customer sites and the Internet and/or between customer sites 1456 across the Network Operator's network and across the Internet". More 1457 concretely, an IP connectivity service can be defined as the IP 1458 transfer capability characterized by a (Source Nets, Destination 1459 Nets, Guarantees, Scope) tuple where "Source Nets" is a group of 1460 unicast IP addresses, "Destination Nets" is a group of IP unicast 1461 and/or multicast addresses, and "Guarantees" reflects the guarantees 1462 (expressed in terms of QoS, performance, and availability, for 1463 example) to properly forward traffic to the said "Destination" 1464 [RFC7297]. 1466 For example: 1468 o The L3SM model [RFC8299] defines the L3VPN service ordered by a 1469 customer from a Network Operator. 1471 o The L2SM model [RFC8466] defines the L2VPN service ordered by a 1472 customer from a Network Operator. 1474 o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang] 1475 provides a YANG data model applicable to any mode of VN operation. 1477 L2SM and L3SM are customer service models as per [RFC8309]. 1479 A.2. Network Models: Samples 1481 L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are 1482 examples of YANG Network Models. 1484 Figure 9 depicts a set of additional Network Models such as topology 1485 and tunnel models: 1487 +-------------------------------+-------------------------------+ 1488 | Topology YANG modules | Tunnel YANG modules | 1489 +-------------------------------+-------------------------------+ 1490 | +------------+ | | 1491 | |Network Topo| | +------+ +-----------+ | 1492 | | Model | | |Other | | TE Tunnel | | 1493 | +----+-------+ | |Tunnel| +----+------+ | 1494 | | +--------+ | +------+ | | 1495 | +---+Svc Topo| | +----------+---------+ | 1496 | | +--------+ | | | | | 1497 | | +--------+ |+----+---+ +----+---+ +---+---+| 1498 | +---+L2 Topo | ||MPLS-TE | |RSVP-TE | | SR-TE || 1499 | | +--------+ || Tunnel | | Tunnel | |Tunnel || 1500 | | +--------+ |+--------+ +--------+ +-------+| 1501 | +---+TE Topo | | | 1502 | | +--------+ | | 1503 | | +--------+ | | 1504 | +---+L3 Topo | | | 1505 | +--------+ | | 1506 +-------------------------------+-------------------------------+ 1508 Legend: 1509 Topo: Topology 1510 Svc: Service 1512 Figure 9: Sample Resource Facing Network Models 1514 Examples of topology YANG modules are listed below: 1516 o Network Topology Models: [RFC8345] defines a base model for 1517 network topology and inventories. Network topology data include 1518 link resource, node resource, and terminate-point resources. 1520 o TE Topology Models: [RFC8795] defines a YANG data model for 1521 representing and manipulating TE topologies. 1523 This module is extended from network topology model defined in 1524 [RFC8345] with TE topologies specifics. This model contains 1525 technology-agnostic TE Topology building blocks that can be 1526 augmented and used by other technology-specific TE topology 1527 models. 1529 o Layer 3 Topology Models: 1531 [RFC8346] defines a YANG data model for representing and 1532 manipulating Layer 3 topologies. This model is extended from the 1533 network topology model defined in [RFC8345] with Layer 3 1534 topologies specifics. 1536 o Layer 2 Topology Models: 1538 [I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model 1539 for representing and manipulating Layer 2 topologies. This model 1540 is extended from the network topology model defined in [RFC8345] 1541 with Layer 2 topologies specifics. 1543 Examples of tunnel YANG modules are provided below: 1545 o Tunnel identities: [RFC8675] defines a collection of YANG 1546 identities used as interface types for tunnel interfaces. 1548 o TE Tunnel Model: 1550 [I-D.ietf-teas-yang-te] defines a YANG module for the 1551 configuration and management of TE interfaces, tunnels, and LSPs. 1553 o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model: 1555 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1556 model(s) and defines a YANG module for SR-TE specific data. 1558 o MPLS-TE Model: 1560 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1561 model(s) and defines a YANG module for MPLS-TE configurations, 1562 state, RPC and notifications. 1564 o RSVP-TE MPLS Model: 1566 [I-D.ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 1567 with parameters to configure and manage signaling of MPLS RSVP-TE 1568 LSPs. 1570 Other sample Network Models are listed hereafter: 1572 o Path Computation API Model: 1574 [I-D.ietf-teas-yang-path-computation] YANG module for a stateless 1575 RPC which complements the stateful solution defined in 1576 [I-D.ietf-teas-yang-te]. 1578 o OAM Models (including Fault Management (FM) and Performance 1579 Monitoring): 1581 [RFC8532] defines a base YANG module for the management of OAM 1582 protocols that use Connectionless Communications. [RFC8533] 1583 defines a retrieval method YANG module for connectionless OAM 1584 protocols. [RFC8531] defines a base YANG module for connection 1585 oriented OAM protocols. These three models are intended to 1586 provide consistent reporting, configuration, and representation 1587 for connection-less OAM and Connection oriented OAM separately. 1589 Alarm monitoring is a fundamental part of monitoring the network. 1590 Raw alarms from devices do not always tell the status of the 1591 network services or necessarily point to the root cause. 1592 [RFC8632] defines a YANG module for alarm management. 1594 A.3. Device Models: Samples 1596 Network Element models (Figure 10) are used to describe how a service 1597 can be implemented by activating and tweaking a set of functions 1598 (enabled in one or multiple devices, or hosted in cloud 1599 infrastructures) that are involved in the service delivery. 1600 Figure 10 uses IETF-defined data models as an example. 1602 +------------------------+ 1603 +-+ Device Model | 1604 | +------------------------+ 1605 | +------------------------+ 1606 +---------------+ | | Logical Network | 1607 | | +-+ Element Model | 1608 | Architecture | | +------------------------+ 1609 | | | +------------------------+ 1610 +-------+-------+ +-+ Network Instance Model | 1611 | | +------------------------+ 1612 | | +------------------------+ 1613 | +-+ Routing Type Model | 1614 | +------------------------+ 1615 +-------+----------+----+------+------------+-----------+------+ 1616 | | | | | | | 1617 +-+-+ +---+---+ +----+----+ +--+--+ +----+----+ +--+--+ | 1618 |ACL| |Routing| |Transport| | OAM | |Multicast| | PM | Others 1619 +---+ +-+-----+ +----+----+ +--+--+ +-----+---+ +--+--+ 1620 | +-------+ | +------+ | +--------+ | +-----+ | +-----+ 1621 +-+Core | +-+ MPLS | +-+ BFD | +-+IGMP | +-+TWAMP| 1622 | |Routing| | | Base | | +--------+ | |/MLD | | +-----+ 1623 | +-------+ | +------+ | +--------+ | +-----+ | +-----+ 1624 | +-------+ | +------+ +-+LSP Ping| | +-----+ +-+OWAMP| 1625 +-+ BGP | +-+ MPLS | | +--------+ +-+ PIM | | +-----+ 1626 | +-------+ | | LDP | | +--------+ | +-----+ | +-----+ 1627 | +-------+ | +------+ +-+MPLS-TP | | +-----+ +-+LMAP | 1628 +-+ ISIS | | +------+ +--------+ +-+ MVPN| +-----+ 1629 | +-------+ +-+ MPLS | +-----+ 1630 | +-------+ |Static| 1631 +-+ OSPF | +------+ 1632 | +-------+ 1633 | +-------+ 1634 +-+ RIP | 1635 | +-------+ 1636 | +-------+ 1637 +-+ VRRP | 1638 | +-------+ 1639 | +-------+ 1640 +-+SR/SRv6| 1641 | +-------+ 1642 | +-------+ 1643 +-+ISIS-SR| 1644 | +-------+ 1645 | +-------+ 1646 +-+OSPF-SR| 1647 +-------+ 1649 Figure 10: Network Element Modules Overview 1651 A.3.1. Model Composition 1653 o Logical Network Element Model 1655 [RFC8530] defines a logical network element module which can be 1656 used to manage the logical resource partitioning that may be 1657 present on a network device. Examples of common industry terms 1658 for logical resource partitioning are Logical Systems or Logical 1659 Routers. 1661 o Network Instance Model 1663 [RFC8529] defines a network instance module. This module can be 1664 used to manage the virtual resource partitioning that may be 1665 present on a network device. Examples of common industry terms 1666 for virtual resource partitioning are VRF instances and Virtual 1667 Switch Instances (VSIs). 1669 A.3.1.1. Schema Mount 1671 Modularity and extensibility were among the leading design principles 1672 of the YANG data modeling language. As a result, the same YANG 1673 module can be combined with various sets of other modules and thus 1674 form a data model that is tailored to meet the requirements of a 1675 specific use case. [RFC8528] defines a mechanism, denoted schema 1676 mount, that allows for mounting one data model consisting of any 1677 number of YANG modules at a specified location of another (parent) 1678 schema. 1680 A.3.2. Device Models: Samples 1682 The following provides an overview of some Device Models that can be 1683 used within a network. This list is not comprehensive. 1685 Interface: [RFC7224] defines a YANG module for interface type 1686 definitions. 1688 BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for 1689 configuring and managing BGP, including protocol, policy, 1690 and operational aspects based on data center, carrier, and 1691 content provider operational requirements. 1693 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 1694 which serves as a base framework for configuring and 1695 managing an MPLS switching subsystem. It is expected that 1696 other MPLS technology YANG modules (e.g., MPLS LSP Static, 1697 LDP, or RSVP-TE models) will augment the MPLS base YANG 1698 module. 1700 QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of 1701 Differentiated Services for configuration and operations. 1703 ACL: Access Control List (ACL) is one of the basic elements 1704 used to configure device forwarding behavior. It is used 1705 in many networking technologies such as Policy Based 1706 Routing, Firewalls, etc. [RFC8519] describes a YANG data 1707 model of ACL basic building blocks. 1709 NAT: For the sake of network automation and the need for 1710 programming Network Address Translation (NAT) function in 1711 particular, a YANG data model for configuring and managing 1712 the NAT is essential. 1714 [RFC8512] defines a YANG module for the NAT function 1715 covering a variety of NAT flavors such as Network Address 1716 Translation from IPv4 to IPv4 (NAT44), Network Address and 1717 Protocol Translation from IPv6 Clients to IPv4 Servers 1718 (NAT64), customer-side translator (CLAT), Stateless IP/ 1719 ICMP Translation (SIIT), Explicit Address Mappings (EAM) 1720 for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), 1721 and Destination NAT. 1723 [RFC8513] specifies a DS-Lite YANG module. 1725 Stateless Address Sharing: [RFC8676] specifies a YANG module for A+P 1726 address sharing, including Lightweight 4over6, Mapping of 1727 Address and Port with Encapsulation (MAP-E), and Mapping 1728 of Address and Port using Translation (MAP-T) softwire 1729 mechanisms. 1731 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 1732 to configure and manage Protocol Independent Multicast 1733 (PIM) devices. 1735 [RFC8652] defines a YANG module that can be used to 1736 configure and manage Internet Group Management Protocol 1737 (IGMP) and Multicast Listener Discovery (MLD) devices. 1739 [I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG 1740 module that can be used to configure and manage Internet 1741 Group Management Protocol (IGMP) and Multicast Listener 1742 Discovery (MLD) Snooping devices. 1744 [I-D.ietf-bess-mvpn-yang] defines a YANG data model to 1745 configure and manage Multicast in MPLS/BGP IP VPNs 1746 (MVPNs). 1748 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for 1749 Ethernet VPN services. The model is agnostic of the 1750 underlay. It applies to MPLS as well as to VxLAN 1751 encapsulation. The module is also agnostic to the 1752 services, including E-LAN, E-LINE, and E-TREE services. 1754 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can 1755 be used to configure and manage BGP L3VPNs [RFC4364]. It 1756 contains VRF specific parameters as well as BGP specific 1757 parameters applicable for L3VPNs. 1759 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS 1760 based Layer 2 VPN services (L2VPN) [RFC4664] and includes 1761 switching between the local attachment circuits. The 1762 L2VPN model covers point-to-point VPWS and Multipoint VPLS 1763 services. These services use signaling of Pseudowires 1764 across MPLS networks using LDP [RFC8077][RFC4762] or BGP 1765 [RFC4761]. 1767 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module 1768 for configuring and managing routing policies based on 1769 operational practice. The module provides a generic 1770 policy framework which can be augmented with protocol- 1771 specific policy configuration. 1773 BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a 1774 network protocol which is used for liveness detection of 1775 arbitrary paths between systems. [I-D.ietf-bfd-yang] 1776 defines a YANG module that can be used to configure and 1777 manage BFD. 1779 SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment 1780 routing configuration and operation. 1782 Core Routing: [RFC8349] defines the core routing YANG data model, 1783 which is intended as a basis for future data model 1784 development covering more-sophisticated routing systems. 1785 It is expected that other Routing technology YANG modules 1786 (e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core 1787 Routing base YANG module. 1789 PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for 1790 client and server implementations of the Two-Way Active 1791 Measurement Protocol (TWAMP). 1793 [I-D.ietf-ippm-stamp-yang] defines the data model for 1794 implementations of Session-Sender and Session-Reflector 1795 for Simple Two-way Active Measurement Protocol (STAMP) 1796 mode using YANG. 1798 [RFC8194] defines a YANG data model for Large-Scale 1799 Measurement Platforms (LMAPs). 1801 Authors' Addresses 1803 Qin Wu (editor) 1804 Huawei 1805 101 Software Avenue, Yuhua District 1806 Nanjing, Jiangsu 210012 1807 China 1809 Email: bill.wu@huawei.com 1811 Mohamed Boucadair (editor) 1812 Orange 1813 Rennes 35000 1814 France 1816 Email: mohamed.boucadair@orange.com 1818 Diego R. Lopez 1819 Telefonica I+D 1820 Spain 1822 Email: diego.r.lopez@telefonica.com 1824 Chongfeng Xie 1825 China Telecom 1826 Beijing 1827 China 1829 Email: xiechf@chinatelecom.cn 1831 Liang Geng 1832 China Mobile 1834 Email: gengliang@chinamobile.com