idnits 2.17.1 draft-ietf-opsawg-model-automation-framework-06.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 22, 2020) is 1309 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 26, 2021 Orange 6 D. Lopez 7 Telefonica I+D 8 C. Xie 9 China Telecom 10 L. Geng 11 China Mobile 12 September 22, 2020 14 A Framework for Automating Service and Network Management with YANG 15 draft-ietf-opsawg-model-automation-framework-06 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 26, 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. Schema Mount . . . . . . . . . . . . . . . . . . . . . . 33 107 A.3. Network Models: Samples . . . . . . . . . . . . . . . . . 33 108 A.4. Device Models: Samples . . . . . . . . . . . . . . . . . 36 109 A.4.1. Model Composition . . . . . . . . . . . . . . . . . . 38 110 A.4.2. Device Management . . . . . . . . . . . . . . . . . . 38 111 A.4.3. Interface Management . . . . . . . . . . . . . . . . 38 112 A.4.4. Some Device Model Examples . . . . . . . . . . . . . 38 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 115 1. Introduction 117 Service management systems usually comprise service activation/ 118 provision and service operation. Current service delivery 119 procedures, from the processing of customer's requirements and orders 120 to service delivery and operation, typically assume the manipulation 121 of data sequentially into multiple OSS/BSS applications that may be 122 managed by different departments within the service provider's 123 organization (e.g., billing factory, design factory, network 124 operation center). In addition, many of these applications have been 125 developed in-house over the years and operate in a silo mode: 127 o The lack of standard data input/output (i.e., data model) raises 128 many challenges in system integration and often results in manual 129 configuration tasks. 131 o Service fulfillment systems might have a limited visibility on the 132 network state and therefore have slow response to network changes. 134 Software Defined Networking (SDN) becomes crucial to address these 135 challenges. SDN techniques are meant to automate the overall service 136 delivery procedures and typically rely upon standard data models. 137 These models are used to not only reflect service providers' savoir- 138 faire, but also to dynamically instantiate and enforce a set of 139 service-inferred policies that best accommodate what has been defined 140 and possibly negotiated with the customer. [RFC7149] provides a 141 first tentative attempt to rationalize that service provider's view 142 on the SDN space by identifying concrete technical domains that need 143 to be considered and for which solutions can be provided: 145 o Techniques for the dynamic discovery of topology, devices, and 146 capabilities, along with relevant information and data models that 147 are meant to precisely document such topology, devices, and their 148 capabilities. 150 o Techniques for exposing network services [RFC8309] and their 151 characteristics. 153 o Techniques used by service-derived dynamic resource allocation and 154 policy enforcement schemes, so that networks can be programmed 155 accordingly. 157 o Dynamic feedback mechanisms that are meant to assess how 158 efficiently a given policy (or a set thereof) is enforced from a 159 service fulfillment and assurance perspectives. 161 Models are key for each of the aforementioned four technical items. 162 Service and network management automation is an important step to 163 improve the agility of network operations. Models are also important 164 to ease integrating multi-vendor solutions. 166 YANG [RFC7950] module developers have taken both top-down and bottom- 167 up approaches to develop modules [RFC8199] and to establish a mapping 168 between a network technology and customer requirements at the top or 169 abstracting common constructs from various network technologies at 170 the bottom. At the time of writing this document (2020), there are 171 many YANG data models including configuration and service models that 172 have been specified or are being specified by the IETF. They cover 173 many of the networking protocols and techniques. However, how these 174 models work together to configure a device, manage a set of devices 175 involved in a service, or provide a service is something that is not 176 currently documented either within the IETF or other Standards 177 Development Organizations (SDOs). 179 This document describes an architectural framework for service and 180 network management automation (Section 3) that takes advantage of 181 YANG modeling technologies and investigates how different layer YANG 182 data models interact with each other (e.g., service mapping, model 183 composing) in the context of service delivery and fulfillment 184 (Section 4). 186 This framework is drawn from a network operator perspective 187 irrespective of the origin of a data module; it can also accommodate 188 modules that are developed outside the IETF. 190 The document identifies a list of use cases to exemplify the proposed 191 approach (Section 5), but it does not claim nor aim to be exhaustive. 193 2. Terminology and Acronyms 195 2.1. Terminology 197 The following terms are defined in [RFC8309][RFC8199] and are not 198 redefined here: 200 o Network Operator 202 o Customer 204 o Service 206 o Data Model 208 o Service Model 210 o Network Element Module 212 In addition, the document makes use of the following terms: 214 Network Model: Describes a network level abstraction (or a subset of 215 aspects of a network infrastructure), including devices and their 216 subsystems, and relevant protocols operating at the link and 217 network layers across multiple devices. This model corresponds to 218 the Network Configuration Model discussed in [RFC8309]. 220 It can be used by a network operator to allocate resources (e.g., 221 tunnel resource, topology resource) for the service or schedule 222 resources to meet the service requirements defined in a Service 223 Model. 225 Device Model: Refers to the Network Element YANG data model 226 described in [RFC8199] or the Device Configuration Model discussed 227 in [RFC8309]. 229 Device Models are also used to refer to model a function embedded 230 in a device (e.g., Network Address Translation (NAT) [RFC8512], 231 Access Control Lists (ACLs) [RFC8519]). 233 Pipe: Refers to a communication scope where only one-to-one (1:1) 234 communications are allowed. The scope can be identified between 235 ingress and egress nodes, two service sites, etc. 237 Hose: Refers to a communication scope where one-to-many (1:N) 238 communications are allowed (e.g., one site to multiple sites). 240 Funnel: Refers to a communication scope where many-to-one (N:1) 241 communications are allowed. 243 2.2. Acronyms 245 The following acronyms are used in the document: 247 ACL Access Control List 248 CE Customer Edge 249 ECA Event Condition Action 250 L2VPN Layer 2 Virtual Private Network 251 L3VPN Layer 3 Virtual Private Network 252 NAT Network Address Translation 253 OAM Operations, Administration, and Maintenance 254 OWD One-Way Delay 255 PE Provider Edge 256 QoS Quality of Service 257 RD Route Distinguisher 258 RT Route Target 259 SDN Software Defined Networking 260 TE Traffic Engineering 261 VN Virtual Network 262 VPN Virtual Private Network 263 VRF Virtual Routing and Forwarding 265 3. Architectural Concepts and Goals 267 3.1. Data Models: Layering and Representation 269 As described in Section 2 of [RFC8199], layering of modules allows 270 for better reusability of lower-layer modules by higher-level modules 271 while limiting duplication of features across layers. 273 Data models can be classified into Service, Network, and Device 274 Models. Different Service Models may rely on the same set of Network 275 and/or Device Models. 277 Service Models traditionally follow a top-down approach and are 278 mostly customer-facing YANG modules providing a common model 279 construct for higher level network services (e.g., Layer 3 Virtual 280 Private Network (L3VPN)). Such modules can be mapped to network 281 technology-specific modules at lower layers (e.g., tunnel, routing, 282 Quality of Service (QoS), security). For example, the service level 283 can be used to characterise the network service(s) to be ensured 284 between service nodes (ingress/egress) such as: 286 o the communication scope (pipe, hose, funnel, ...), 287 o the directionality (inbound/outbound), 288 o the traffic performance guarantees (One-Way Delay (OWD) [RFC7679], 289 One-Way Loss [RFC7680], ...), 290 o link capacity [RFC5136][I-D.ietf-ippm-capacity-metric-method], 291 o etc. 293 Figure 1 depicts the example of a VoIP service that relies upon 294 connectivity services offered by a network operator. In this 295 example, the VoIP service is offered to the network operator's 296 customers by Service Provider (SP1). In order to provide global VoIP 297 reachability, SP1 service site interconnects with other Service 298 Providers service sites typically by interconnecting Session Border 299 Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406]. 300 For other VoIP destinations, sessions are forwarded over the 301 Internet. These connectivity services can be captured in a YANG 302 Service Module that reflects the service attributes that are shown in 303 Figure 2. This example follows the IP Connectivity Provisioning 304 Profile template defined in [RFC7297]. 306 ,--,--,--. ,--,--,--. 307 ,-' SP1 `-. ,-' SP2 `-. 308 ( Service Site ) ( Service Site ) 309 `-. ,-' `-. ,-' 310 `--'--'--' `--'--'--' 311 x | o * * | 312 (2)x | o * * | 313 ,x-,--o-*-. (1) ,--,*-,--. 314 ,-' x o * * * * * * * * * `-. 315 ( x o +----( Internet ) 316 User---(x x x o o o o o o o o o o o o o o o o o o 317 `-. ,-' `-. ,-' (3) 318 `--'--'--' `--'--'--' 319 Network Operator 321 **** (1) Inter-SP connectivity 322 xxxx (2) Customer to SP connectivity 323 oooo (3) SP to any destination connectivity 325 Figure 1: An Example of Service Connectivty Components 327 Connectivity: Scope and Guarantees 328 (1) Inter-SP connectivity 329 - Pipe scope from the local to the remote SBE/DBE 330 - Full guarantees class 331 (2) Customer to SP connectivity 332 - Hose/Funnel scope connecting the local SBE/DBE 333 to the customer access points 334 - Full guarantees class 335 (3) SP to any destination connectivity 336 - Hose/Funnel scope from the local SBE/DBE to the 337 Internet gateway 338 - Delay guarantees class 339 Flow Identification 340 * Destination IP address (SBE, DBE) 341 * DSCP marking 342 Traffic Isolation 343 * VPN 344 Routing & Forwarding 345 * Routing rule to exclude some ASes from the inter-domain 346 paths 347 Notifications (including feedback) 348 * Statistics on aggregate traffic to adjust capacity 349 * Failures 350 * Planned maintenance operations 351 * Triggered by thresholds 353 Figure 2: Sample Attributes Captured in a Service Model 355 Network Models are mainly network resource-facing modules; they 356 describe various aspects of a network infrastructure, including 357 devices and their subsystems, and relevant protocols operating at the 358 link and network layers across multiple devices (e.g., network 359 topology and traffic-engineering tunnel modules). 361 Device (and function) Models usually follow a bottom-up approach and 362 are mostly technology-specific modules used to realize a service 363 (e.g., BGP, NAT). 365 Each level maintains a view of the supported YANG modules provided by 366 low-levels (see for example, Appendix A). 368 Figure 3 illustrates the overall layering model. The reader may 369 refer to Section 4 of [RFC8309] for an overview of "Orchestrator" and 370 "Controller" elements. 372 +-----------------------------------------------------------------+ 373 | +-----------------------+ | 374 | | Orchestrator | Hierarchy Abstraction | 375 | |+---------------------+| | 376 | || Service Modeling || Service Model | 377 | |+---------------------+| (Customer Oriented) | 378 | | | Scope: "1:1" Pipe model | 379 | | | Bidirectional | 380 | |+---------------------+| +-+ Capacity,OWD +-+ | 381 | ||Service Orchestration|| | +----------------+ | | 382 | |+---------------------+| +-+ +-+ | 383 | +-----------------------+ 1. Ingress 2. Egress | 384 | | 385 | | 386 | | 387 | +-----------------------+ Network Model | 388 | | Controller | (Operator Oriented) | 389 | |+---------------------+| +-+ +--+ +---+ +-+ | 390 | || Network Modeling || | | | | | | | | | 391 | |+---------------------+| | o----o--o----o---o---o | | 392 | |+---------------------+| +-+ +--+ +---+ +-+ | 393 | ||Network Orchestration|| src dst | 394 | |+---------------------+| L3VPN over TE | 395 | | | Instance Name/Access Interface | 396 | +-----------------------+ Protocol Type/Capacity/RD/RT/... | 397 | mapping for hop | 398 | | 399 | | 400 | +-----------------------+ | 401 | | Device | Device Model | 402 | |+--------------------+ | | 403 | || Device Modeling | | Interface add, BGP Peer, | 404 | |+--------------------+ | Tunnel ID, QoS/TE, ... | 405 | +-----------------------+ | 406 +-----------------------------------------------------------------+ 408 Figure 3: Layering and Representation 410 The layering model depicted in Figure 3 does not make any assumption 411 about the location of the various entities (e.g., controller, 412 orchestrator) within the network. As such, the architecture does not 413 preclude deployments where, for example, the controller is embedded 414 on a device that hosts other functions that are controlled via YANG 415 modules. 417 In order to ease the mapping between layers and data reuse, this 418 document focuses on service models that are modelled using YANG. 419 Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3 420 does not preclude service models to be modelled using other data 421 modelling languages than YANG. 423 3.2. Automation of Service Delivery Procedures 425 Service Models can be used by a network operator to expose its 426 services to its customers. Exposing such models allows to automate 427 the activation of service orders and thus the service delivery. One 428 or more monolithic Service Models can be used in the context of a 429 composite service activation request (e.g., delivery of a caching 430 infrastructure over a VPN). Such models are used to feed a decision- 431 making intelligence to adequately accommodate customer's needs. 433 Also, such models may be used jointly with services that require 434 dynamic invocation. An example is provided by the service modules 435 defined by the DOTS WG to dynamically trigger requests to handle 436 Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service 437 filtering request modelled using [RFC8783] will be translated into 438 device-specific filtering (e.g., ACLs defined in [RFC8519]) that to 439 fulfil the service request. 441 Network Models can be derived from Service Models and used to 442 provision, monitor, instantiate the service, and provide lifecycle 443 management of network resources. Doing so is meant to: 445 o expose network resources to customers (including other network 446 operators) to provide service fulfillment and assurance. 448 o allow customers (or network operators) to dynamically adjust the 449 network resources based on service requirements as described in 450 Service Models (e.g., Figure 2) and the current network 451 performance information described in the telemetry modules. 453 3.3. Service Fullfillment Automation 455 To operate a service, the settings of the parameters in the Device 456 Models are derived from Service Models and/or Network Models and are 457 used to: 459 o Provision each involved network function/device with the proper 460 configuration information. 462 o Operate the network based on service requirements as described in 463 the Service Model(s) and local operational guidelines. 465 In addition, the operational state including configuration that is in 466 effect together with statistics should be exposed to upper layers to 467 provide better network visibility and assess to what extent the 468 derived low level modules are consistent with the upper level inputs. 470 Filters are enforced on the notifications that are communicated to 471 Service layers. The type and frequency of notifications may be 472 agreed in the Service Model. 474 Note that it is important to correlate telemetry data with 475 configuration data to be used for closed loops at the different 476 stages of service delivery, from resource allocation to service 477 operation, in particular. 479 3.4. YANG Modules Integration 481 To support top-down service delivery, YANG modules at different 482 levels or at the same level need to be integrated together for proper 483 service delivery (including, proper network setup). For example, the 484 service parameters captured in Service Models need to be decomposed 485 into a set of configuration/notification parameters that may be 486 specific to one or more technologies; these technology-specific 487 parameters are grouped together to define technology-specific device 488 level models or network level models. 490 In addition, these technology-specific Device or Network Models can 491 be further integrated with each other using the schema mount 492 mechanism [RFC8528] to provision each involved network function/ 493 device or each involved administrative domain to support newly added 494 module or features. A collection of Device Models integrated 495 together can be loaded and validated during implementation. 497 High-level policies can be defined at Service or Network Models 498 (e.g., "Autonomous System Number (ASN) Exclude" in the example 499 depicted in Figure 2). Device Models will be tweaked accordingly to 500 provide policy-based management. Policies can also be used for 501 telemetry automation, e.g., policies that contain conditions can 502 trigger the generation and pushing of new telemetry data. 504 Performance measurement telemetry can be used to provide service 505 assurance at Service and/or Network levels. Performance measurement 506 telemetry model can tie with Service or Network Models to monitor 507 network performance or Service Level Agreement. 509 4. Functional Blocks and Interactions 511 The architectural considerations described in Section 3 lead to the 512 architecture described in this section and illustrated in Figure 4. 514 +------------------+ 515 ................. | | 516 Service level | | 517 V | 518 E2E E2E E2E E2E 519 Service --> Service ---------> Service -----> Service -----+ 520 Exposure Creation ^ Optimization ^ Diagnosis | 521 /Modification | | | 522 | |Diff | V 523 Multi-layer | | E2E | E2E 524 Multi-domain | | Service | Service 525 Service Mapping| +------ Assurance --+ Decommission 526 | ^ 527 ................. |<-----------------+ | 528 Network level | | +-------+ 529 V | | 530 Specific Specific | 531 Service --------> Service <--+ | 532 Creation ^ Optimization | | 533 /Modification | | | 534 | |Diff | | 535 | | Specific --+ | 536 Service | | Service | 537 Decomposing | +----- Assurance ----+ 538 | ^ 539 ................. | | Aggregation 540 Device level | +------------+ 541 V | 542 Service Intent | 543 Fulfillment Config ----> Config ----> Performance ----> Fault 544 Provision Validation Monitoring Diagnostic 546 Figure 4: Service and Network Lifecycle Management 548 4.1. Service Lifecycle Management Procedure 550 Service lifecycle management includes end-to-end service lifecycle 551 management at the service level and technology specific network 552 lifecycle management at the network level. 554 The end-to-end service lifecycle management is technology-independent 555 service management and spans across multiple administrative domain or 556 multiple layers while technology specific service lifecycle 557 management is technology domain specific or layer specific service 558 lifecycle management. 560 4.1.1. Service Exposure 562 A service in the context of this document (sometimes called, Network 563 Service) is some form of connectivity between customer sites and the 564 Internet or between customer sites across the operator's network and 565 across the Internet. 567 Service exposure is used to capture services offered to customers 568 (ordering and order handling). One typical example is that a 569 customer can use a L3VPN Service Model (L3SM) to request L3VPN 570 service by providing the abstract technical characterization of the 571 intended service between customer sites. 573 Service Model catalogs can be created along to expose the various 574 services and the information needed to invoke/order a given service. 576 4.1.2. Service Creation/Modification 578 A customer is usually unaware of the technology that the network 579 operator has available to deliver the service, so the customer does 580 not make requests specific to the underlying technology but is 581 limited to making requests specific to the service that is to be 582 delivered. This service request can be issued using a Service Model. 584 Upon receiving a service request, and assuming that appropriate 585 authentication and authorization checks have been made, the service 586 orchestrator/management system should verify whether the service 587 requirements in the service request can be met (i.e., whether there 588 is sufficient resources that can be allocated with the requested 589 guarantees). 591 If the request is accepted, the service orchestrator/management 592 system maps such service request to its view. This view can be 593 described as a technology specific network model or a set of 594 technology specific Device Models and this mapping may include a 595 choice of which networks and technologies to use depending on which 596 service features have been requested. 598 In addition, a customer may require to change the underlying network 599 infrastructure to adapt to new customer's needs and service 600 requirements. This service modification can be issued following the 601 same Service Model used by the service request. 603 4.1.3. Service Optimization 605 Service optimization is a technique that gets the configuration of 606 the network updated due to network changes, incidents mitigation, or 607 new service requirements. One typical example is once a tunnel or a 608 VPN is setup, Performance monitoring information or telemetry 609 information per tunnel (or per VPN) can be collected and fed into the 610 management system. If the network performance doesn't meet the 611 service requirements, the management system can create new VPN 612 policies capturing network service requirements and populate them 613 into the network. 615 Both network performance information and policies can be modelled 616 using YANG. With Policy-based management, self-configuration and 617 self-optimization behavior can be specified and implemented. 619 4.1.4. Service Diagnosis 621 Operations, Administration, and Maintenance (OAM) are important 622 networking functions for service diagnosis that allow network 623 operators to: 625 o monitor network communications (i.e., reachability verification 626 and Continuity Check) 628 o troubleshoot failures (i.e., fault verification and localization) 630 o monitor service-level agreements and performance (i.e., 631 performance management) 633 When the network is down, service diagnosis should be in place to 634 pinpoint the problem and provide recommendations (or instructions) 635 for the network recovery. 637 The service diagnosis information can be modelled as technology- 638 independent Remote Procedure Call (RPC) operations for OAM protocols 639 and technology-independent abstraction of key OAM constructs for OAM 640 protocols [RFC8531][RFC8533]. These models can be used to provide 641 consistent configuration, reporting, and presentation for the OAM 642 mechanisms used to manage the network. 644 4.1.5. Service Decommission 646 Service decommission allows a customer to stop the service by 647 removing the service from active status and thus releasing the 648 network resources that were allocated to the service. Customers can 649 also use the Service Model to withdraw the registration to a service. 651 4.2. Service Fullfillment Management Procedure 652 4.2.1. Intended Configuration Provision 654 Intended configuration at the device level is derived from Network 655 Models at the network level or Service Model at the service level and 656 represents the configuration that the system attempts to apply. Take 657 L3SM as a Service Model example to deliver a L3VPN service, we need 658 to map the L3VPN service view defined in the Service Model into 659 detailed intended configuration view defined by specific 660 configuration models for network elements, configuration information 661 includes: 663 o Virtual Routing and Forwarding (VRF) definition, including VPN 664 policy expression 666 o Physical Interface(s) 668 o IP layer (IPv4, IPv6) 670 o QoS features such as classification, profiles, etc. 672 o Routing protocols: support of configuration of all protocols 673 listed in a service request, as well as routing policies 674 associated with those protocols. 676 o Multicast support 678 o Address sharing (e.g., NAT) 680 o Security 682 These specific configuration models can be used to configure Provider 683 Edge (PE) and Customer Edge (CE) devices within a site, e.g., a BGP 684 policy model can be used to establish VPN membership between sites 685 and VPN Service Topology. 687 4.2.2. Configuration Validation 689 Configuration validation is used to validate intended configuration 690 and ensure the configuration take effect. 692 For example, a customer creates an interface "eth-0/0/0" but the 693 interface does not physically exist at this point, then configuration 694 data appears in the status but does not appear in 695 datastore. 697 4.2.3. Performance Monitoring/Model-driven Telemetry 699 When configuration is in effect in the device, 700 datastore holds the complete operational state of the device 701 including learned, system, default configuration, and system state. 702 However, the configurations and state of a particular device does not 703 have the visibility to the whole network or information of the flow 704 packets are going to take through the entire network. Therefore it 705 becomes more difficult to operate the network without understanding 706 the current status of the network. 708 The management system should subscribe to updates of a YANG datastore 709 in all the network devices for performance monitoring purpose and 710 build a full topological visibility of the network by aggregating 711 (and filtering) these operational state from different sources. 713 4.2.4. Fault Diagnostic 715 When configuration is in effect in the device, some devices may be 716 mis-configured (e.g.,device links are not consistent in both sides of 717 the network connection), network resources be mis-allocated and 718 services may be negatively affected without knowing what is going on 719 in the network. 721 Technology-dependent nodes and RPC commands are defined in 722 technology-specific YANG data models which can use and extend the 723 base model described in Section 4.1.4 to deal with these issues. 725 These RPC commands received in the technology-dependent node can be 726 used to trigger technology-specific OAM message exchanges for fault 727 verification and fault isolation For example, TRILL Multicast Tree 728 Verification (MTV) RPC command [I-D.ietf-trill-yang-oam] can be used 729 to trigger Multi-Destination Tree Verification Message defined in 730 [RFC7455] to verify TRILL distribution tree integrity. 732 4.3. Multi-Layer/Multi-Domain Service Mapping 734 Multi-layer/Multi-domain Service Mapping allows to map an end-to-end 735 abstract view of the service segmented at different layers or 736 different administrative domains into domain-specific view. 738 One example is to map service parameters in L3VPN service model into 739 configuration parameters such as Route Distinguisher (RD), Route 740 Target (RT), and VRF in L3VPN network model. 742 Another example is to map service parameters in L3VPN service model 743 into Traffic Engineered (TE) tunnel parameter (e.g., Tunnel ID) in TE 744 model and Virtual Network (VN) parameters (e.g., Access Point (AP) 745 list, VN members) in the YANG data model for VN operation 746 [I-D.ietf-teas-actn-vn-yang]. 748 4.4. Service Decomposing 750 Service Decomposing allows to decompose service model at the service 751 level or network model at the network level into a set of device/ 752 function models at the device level. These Device Models may be tied 753 to specific device types or classified into a collection of related 754 YANG modules based on service types and features offered, and load at 755 the implementation time before configuration is loaded and validated. 757 5. YANG Data Model Integration Examples 759 The following subsections provides some YANG data models integration 760 examples. 762 5.1. L2VPN/L3VPN Service Delivery 764 In reference to Figure 5, the following steps are performed to 765 deliver the L3VPN service within the network management automation 766 architecture defined in this document: 768 1. The Customer requests to create two sites (as per service 769 creation operation in Section 4.2.1) relying upon a L3SM Service 770 model with each having one network access connectivity, for 771 example: 773 * Site A: Network-Access A, Link Capacity = 20 Mbps, for class 774 "foo", guaranteed-capacity-percent = 10, average-One-Way-Delay 775 = 70 ms. 777 * Site B: Network-Access B, Link Capacity = 30 Mbps, for class 778 "foo1", guaranteed-capacity-percent = 15, average-One-Way- 779 Delay = 60 ms. 781 2. The Orchestrator extracts the service parameters from the L3SM 782 model. Then, it uses them as input to translate ("service 783 mapping operation" in Section 4.4) them into an orchestrated 784 configuration of network elements (e.g., RD, RT, VRF) that are 785 part of the L3VPN Network YANG Model specified in 786 [I-D.ietf-opsawg-l3sm-l3nm]. 788 3. The Controller takes orchestrated configuration parameters in the 789 L3NM network model and translates them into orchestrated 790 ("service decomposing operation" in ) configuration of network 791 elements that are part of, e.g., BGP, QoS, Network Instance 792 model, IP management, and interface models. 794 [I-D.ogondio-opsawg-uni-topology] can be used for representing, 795 managing, and controlling the User Network Interface (UNI) topology. 797 L3SM | 798 Service | 799 Model | 800 +----------------------+--------------------------+ 801 | +--------V--------+ | 802 | | Service Mapping | | 803 | +--------+--------+ | 804 | Orchestrator | | 805 +----------------------+--------------------------+ 806 L3NM | ^ UNI Topology Model 807 Network| | 808 Model | | 809 +----------------------+--------------------------+ 810 | +----------V-----------+ | 811 | | Service Decomposing | | 812 | +---++--------------++-+ | 813 | || || | 814 | Controller || || | 815 +---------------++--------------++----------------+ 816 || || 817 || BGP, || 818 || QoS, || 819 || Interface, || 820 +------------+| NI, |+--------------+ 821 | | IP | | 822 +--+--+ +--+--+ +--+--+ +--+--+ 823 | CE1 +-------+ PE1 | | PE2 +---------+ CE2 | 824 +-----+ +-----+ +-----+ +-----+ 826 Figure 5: L3VPN Service Delivery Example (Current) 828 L3NM inherits some of data elements from the L3SM. Nevertheless, the 829 L3NM does not expose some information to the above layer such as the 830 capabilities of an underlying network (which can be used to drive 831 service order handling) or notifications (to notify subscribers about 832 specific events or degradations as per agreed SLAs). Some of this 833 information can be provided using, e.g., 834 [I-D.www-bess-yang-vpn-service-pm]. A target overall model is 835 depicted in Figure 6. 837 L3SM | ^ 838 Service | | Notifications 839 Model | | 840 +----------------------+--------------------------+ 841 | +--------V--------+ | 842 | | Service Mapping | | 843 | +--------+--------+ | 844 | Orchestrator | | 845 +----------------------+--------------------------+ 846 L3NM | ^ UNI Topology Model 847 Network| | L3NM Notifications 848 Model | | L3NM Capabilities 849 +----------------------+--------------------------+ 850 | +----------V-----------+ | 851 | | Service Decomposing | | 852 | +---++--------------++-+ | 853 | || || | 854 | Controller || || | 855 +---------------++--------------++----------------+ 856 || || 857 || BGP, || 858 || QoS, || 859 || Interface, || 860 +------------+| NI, |+--------------+ 861 | | IP | | 862 +--+--+ +--+--+ +--+--+ +--+--+ 863 | CE1 +-------+ PE1 | | PE2 +---------+ CE2 | 864 +-----+ +-----+ +-----+ +-----+ 866 Figure 6: L3VPN Service Delivery Example (Target) 868 Note that a similar analysis can be performed for Layer 2 VPNs 869 (L2VPNs). A L2VPN Service Model (L2SM) is defined in [RFC8466], 870 while the L2VPN Network YANG Model (L2NM) is specified in 871 [I-D.ietf-opsawg-l2nm]. 873 5.2. VN Lifecycle Management 875 In reference to Figure 7, the following steps are performed to 876 deliver the VN service within the network management automation 877 architecture defined in this document: 879 1. Customer requests (service exposure operation in Section 4.1.1) 880 to create 'VN' based on Access point, association between VN and 881 Access point, VN member defined in the VN YANG module. 883 2. The orchestrator creates the single abstract node topology based 884 on the information captured in an VN YANG module. 886 3. The Customer exchanges connectivity-matrix on abstract node and 887 explicit path using TE topology model with the orchestrator. 888 This information can be used to instantiate VN and setup tunnels 889 between source and destination endpoints (service creation 890 operation in Section 4.1.2). 892 4. The telemetry model which augments the VN model and corresponding 893 TE tunnel model can be used to subscribe to performance 894 measurement data and notify all the parameter changes and network 895 performance change related to VN topology or Tunnel 896 [I-D.ietf-teas-actn-pm-telemetry-autonomics] and provide service 897 assurance (service optimization operation in Section 4.1.3). 899 | 900 VN | 901 Service | 902 Model | 903 +----------------------|--------------------------+ 904 | Orchestrator | | 905 | +--------V--------+ | 906 | | Service Mapping | | 907 | +-----------------+ | 908 +----------------------+--------------------^-----+ 909 TE | Telemetry 910 Tunnel | Model 911 Model | | 912 +----------------------V--------------------+-----+ 913 | Controller | 914 | | 915 +-------------------------------------------------+ 917 +-----+ +-----+ +-----+ +-----+ 918 | CE1 +------+ PE1 | | PE2 +------+ CE2 | 919 +-----+ +-----+ +-----+ +-----+ 921 Figure 7: A VN Service Delivery Example 923 5.3. Event-based Telemetry in the Device Self Management 925 In reference to Figure 8, the following steps are performed to 926 monitor state changes of managed objects or resources in a network 927 device and provide device self-management within the network 928 management automation architecture defined in this document: 930 1. To control which state a network device should be in or is 931 allowed to be in at any given time, a set of conditions and 932 actions are defined and correlated with network events (e.g., 933 allow the NETCONF server to send updates only when the value 934 exceeds a certain threshold for the first time, but not again 935 until the threshold is cleared), which constitute ECA policy or 936 an event-driven policy control logic that can be executed on the 937 device (e.g., [I-D.wwx-netmod-event-yang]). 939 2. To provide rapid autonomic response that can exhibit self- 940 management properties, the controller pushes the ECA policy to 941 the network device and delegates network control logic to the 942 network device. 944 3. The network device uses the ECA model to subscribe to the event 945 source, e.g., an event stream or datastore state data conveyed to 946 the server via YANG Push subscription, monitors state parameters, 947 and takes simple and instant actions when associated event 948 condition on state parameters is met. ECA notifications can be 949 generated as the result of actions based on event stream 950 subscription or datastore subscription (model-driven telemetry 951 operation discussed in Section 4.2.3). 953 +----------------+ 954 | <----+ 955 | Controller | | 956 +-------+--------+ | 957 | | 958 | | 959 ECA | | ECA 960 Model | | Notification 961 | | 962 | | 963 +------------V-------------+-----+ 964 |Device | | 965 | +-------+ +---------+ +--+---+ | 966 | | Event +-> Event +->Event | | 967 | | Source| |Condition| |Action| | 968 | +-------+ +---------+ +------+ | 969 +--------------------------------+ 971 Figure 8: Event-based Telemetry 973 6. Security Considerations 975 The YANG modules cited in this document define schema for data that 976 are designed to be accessed via network management protocols such as 977 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 978 the secure transport layer, and the mandatory-to-implement secure 979 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 980 is HTTPS, and the mandatory-to-implement secure transport is TLS 981 [RFC8446]. 983 The NETCONF access control model [RFC8341] provides the means to 984 restrict access for particular NETCONF or RESTCONF users to a 985 preconfigured subset of all available NETCONF or RESTCONF protocol 986 operations and content. 988 Security considerations specific to each of the technologies and 989 protocols listed in the document are discussed in the specification 990 documents of each of these protocols. 992 Security considerations specific to this document are listed below: 994 o Create forwarding loops by mis-configuring the underlying network. 996 o Leak sensitive information: special care should be considered when 997 translating between the various layers in Section 4 or when 998 aggregating data retrieved from various sources. The network 999 operator must enforce means to protect privacy-related information 1000 included in cutsomer-facing models. 1002 o Some Service Models may include a traffic isolation clause, 1003 appropriate technology-specific actions must be enforced to avoid 1004 that traffic is accessible to non-authorized parties. 1006 7. IANA Considerations 1008 There are no IANA requests or assignments included in this document. 1010 8. Acknowledgements 1012 Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter, 1013 and Adrian Farrel for the review. 1015 Many thanks to Robert Wilton for the detailed AD review. 1017 9. Contributors 1018 Christian Jacquenet 1019 Orange 1020 Rennes, 35000 1021 France 1022 Email: Christian.jacquenet@orange.com 1024 Luis Miguel Contreras Murillo 1025 Telifonica 1027 Email: luismiguel.contrerasmurillo@telefonica.com 1029 Oscar Gonzalez de Dios 1030 Telefonica 1031 Madrid 1032 ES 1034 Email: oscar.gonzalezdedios@telefonica.com 1036 Weiqiang Cheng 1037 China Mobile 1039 Email: chengweiqiang@chinamobile.com 1041 Young Lee 1042 Sung Kyun Kwan University 1044 Email: younglee.tx@gmail.com 1046 10. References 1048 10.1. Normative References 1050 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1051 and A. Bierman, Ed., "Network Configuration Protocol 1052 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1053 . 1055 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1056 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1057 . 1059 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1060 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1061 . 1063 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1064 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1065 . 1067 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1068 Access Control Model", STD 91, RFC 8341, 1069 DOI 10.17487/RFC8341, March 2018, 1070 . 1072 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1073 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1074 . 1076 10.2. Informative References 1078 [I-D.clacla-netmod-model-catalog] 1079 Clarke, J. and B. Claise, "YANG module for 1080 yangcatalog.org", draft-clacla-netmod-model-catalog-03 1081 (work in progress), April 2018. 1083 [I-D.ietf-bess-evpn-yang] 1084 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 1085 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 1086 bess-evpn-yang-07 (work in progress), March 2019. 1088 [I-D.ietf-bess-l2vpn-yang] 1089 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1090 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1091 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 1092 July 2019. 1094 [I-D.ietf-bess-l3vpn-yang] 1095 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 1096 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 1097 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 1098 in progress), October 2018. 1100 [I-D.ietf-bess-mvpn-yang] 1101 Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and 1102 M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP 1103 IP VPNs", draft-ietf-bess-mvpn-yang-04 (work in progress), 1104 June 2020. 1106 [I-D.ietf-bfd-yang] 1107 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 1108 and G. Mirsky, "YANG Data Model for Bidirectional 1109 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 1110 in progress), August 2018. 1112 [I-D.ietf-i2rs-yang-l2-network-topology] 1113 Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A 1114 YANG Data Model for Layer 2 Network Topologies", draft- 1115 ietf-i2rs-yang-l2-network-topology-17 (work in progress), 1116 August 2020. 1118 [I-D.ietf-idr-bgp-model] 1119 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1120 YANG Model for Service Provider Networks", draft-ietf-idr- 1121 bgp-model-09 (work in progress), June 2020. 1123 [I-D.ietf-ippm-capacity-metric-method] 1124 Morton, A., Geib, R., and L. Ciavattone, "Metrics and 1125 Methods for IP Capacity", draft-ietf-ippm-capacity-metric- 1126 method-03 (work in progress), August 2020. 1128 [I-D.ietf-ippm-stamp-yang] 1129 Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active 1130 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 1131 stamp-yang-05 (work in progress), October 2019. 1133 [I-D.ietf-ippm-twamp-yang] 1134 Civil, R., Morton, A., Rahman, R., Jethanandani, M., and 1135 K. Pentikousis, "Two-Way Active Measurement Protocol 1136 (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work 1137 in progress), July 2018. 1139 [I-D.ietf-mpls-base-yang] 1140 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 1141 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 1142 yang-15 (work in progress), August 2020. 1144 [I-D.ietf-netmod-module-tags] 1145 Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module 1146 Tags", draft-ietf-netmod-module-tags-10 (work in 1147 progress), February 2020. 1149 [I-D.ietf-opsawg-l2nm] 1150 barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil, 1151 L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- 1152 ietf-opsawg-l2nm-00 (work in progress), July 2020. 1154 [I-D.ietf-opsawg-l3sm-l3nm] 1155 barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. 1156 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 1157 opsawg-l3sm-l3nm-03 (work in progress), April 2020. 1159 [I-D.ietf-pim-igmp-mld-snooping-yang] 1160 Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, 1161 "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- 1162 pim-igmp-mld-snooping-yang-18 (work in progress), August 1163 2020. 1165 [I-D.ietf-pim-yang] 1166 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1167 Y., and f. hu, "A YANG Data Model for Protocol Independent 1168 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1169 progress), May 2018. 1171 [I-D.ietf-rtgwg-policy-model] 1172 Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data 1173 Model for Routing Policy Management", draft-ietf-rtgwg- 1174 policy-model-21 (work in progress), September 2020. 1176 [I-D.ietf-rtgwg-qos-model] 1177 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 1178 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 1179 model-02 (work in progress), July 2020. 1181 [I-D.ietf-spring-sr-yang] 1182 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 1183 Tantsura, "YANG Data Model for Segment Routing", draft- 1184 ietf-spring-sr-yang-22 (work in progress), August 2020. 1186 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 1187 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 1188 and D. Ceccarelli, "YANG models for VN/TE Performance 1189 Monitoring Telemetry and Scaling Intent Autonomics", 1190 draft-ietf-teas-actn-pm-telemetry-autonomics-03 (work in 1191 progress), July 2020. 1193 [I-D.ietf-teas-actn-vn-yang] 1194 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1195 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1196 teas-actn-vn-yang-09 (work in progress), July 2020. 1198 [I-D.ietf-teas-yang-path-computation] 1199 Busi, I., Belotti, S., Lopezalvarez, V., Sharma, A., and 1200 Y. Shi, "Yang model for requesting Path Computation", 1201 draft-ietf-teas-yang-path-computation-10 (work in 1202 progress), July 2020. 1204 [I-D.ietf-teas-yang-rsvp-te] 1205 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 1206 and H. Shah, "A YANG Data Model for RSVP-TE Protocol", 1207 draft-ietf-teas-yang-rsvp-te-08 (work in progress), March 1208 2020. 1210 [I-D.ietf-teas-yang-te] 1211 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1212 "A YANG Data Model for Traffic Engineering Tunnels, Label 1213 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 1214 (work in progress), July 2020. 1216 [I-D.ietf-trill-yang-oam] 1217 Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., 1218 and H. Weiguo, "YANG Data Model for TRILL Operations, 1219 Administration, and Maintenance (OAM)", draft-ietf-trill- 1220 yang-oam-05 (work in progress), March 2017. 1222 [I-D.ogondio-opsawg-uni-topology] 1223 Dios, O., barguil, s., WU, Q., and M. Boucadair, "A YANG 1224 Model for User-Network Interface (UNI) Topologies", draft- 1225 ogondio-opsawg-uni-topology-01 (work in progress), April 1226 2020. 1228 [I-D.www-bess-yang-vpn-service-pm] 1229 WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., and H. 1230 Xu, "A YANG Model for Network and VPN Service Performance 1231 Monitoring", draft-www-bess-yang-vpn-service-pm-06 (work 1232 in progress), April 2020. 1234 [I-D.wwx-netmod-event-yang] 1235 Bierman, A., WU, Q., Bryskin, I., Birkholz, H., Liu, X., 1236 and B. Claise, "A YANG Data model for ECA Policy 1237 Management", draft-wwx-netmod-event-yang-09 (work in 1238 progress), July 2020. 1240 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1241 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1242 2006, . 1244 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1245 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1246 DOI 10.17487/RFC4664, September 2006, 1247 . 1249 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1250 LAN Service (VPLS) Using BGP for Auto-Discovery and 1251 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1252 . 1254 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1255 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1256 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1257 . 1259 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 1260 RFC 5136, DOI 10.17487/RFC5136, February 2008, 1261 . 1263 [RFC5486] Malas, D., Ed. and D. Meyer, Ed., "Session Peering for 1264 Multimedia Interconnect (SPEERMINT) Terminology", 1265 RFC 5486, DOI 10.17487/RFC5486, March 2009, 1266 . 1268 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1269 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1270 . 1272 [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for 1273 Multimedia INTerconnect (SPEERMINT) Architecture", 1274 RFC 6406, DOI 10.17487/RFC6406, November 2011, 1275 . 1277 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1278 Networking: A Perspective from within a Service Provider 1279 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1280 . 1282 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1283 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1284 . 1286 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1287 Weingarten, "An Overview of Operations, Administration, 1288 and Maintenance (OAM) Tools", RFC 7276, 1289 DOI 10.17487/RFC7276, June 2014, 1290 . 1292 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1293 Connectivity Provisioning Profile (CPP)", RFC 7297, 1294 DOI 10.17487/RFC7297, July 2014, 1295 . 1297 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1298 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1299 2014, . 1301 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 1302 3rd, D., Aldrin, S., and Y. Li, "Transparent 1303 Interconnection of Lots of Links (TRILL): Fault 1304 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 1305 . 1307 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1308 Ed., "A One-Way Delay Metric for IP Performance Metrics 1309 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1310 2016, . 1312 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1313 Ed., "A One-Way Loss Metric for IP Performance Metrics 1314 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1315 2016, . 1317 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 1318 Maintenance Using the Label Distribution Protocol (LDP)", 1319 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 1320 . 1322 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1323 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1324 August 2017, . 1326 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1327 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1328 2017, . 1330 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1331 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1332 DOI 10.17487/RFC8299, January 2018, 1333 . 1335 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1336 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1337 . 1339 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1340 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1341 . 1343 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1344 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1345 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1346 2018, . 1348 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1349 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1350 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1351 March 2018, . 1353 [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 1354 YANG Data Model for Hardware Management", RFC 8348, 1355 DOI 10.17487/RFC8348, March 2018, 1356 . 1358 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1359 Routing Management (NMDA Version)", RFC 8349, 1360 DOI 10.17487/RFC8349, March 2018, 1361 . 1363 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1364 Data Model for Layer 2 Virtual Private Network (L2VPN) 1365 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1366 2018, . 1368 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1369 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1370 Address Translation (NAT) and Network Prefix Translation 1371 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1372 . 1374 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1375 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1376 DOI 10.17487/RFC8513, January 2019, 1377 . 1379 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1380 "YANG Data Model for Network Access Control Lists (ACLs)", 1381 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1382 . 1384 [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", 1385 RFC 8528, DOI 10.17487/RFC8528, March 2019, 1386 . 1388 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1389 Liu, "YANG Data Model for Network Instances", RFC 8529, 1390 DOI 10.17487/RFC8529, March 2019, 1391 . 1393 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1394 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1395 DOI 10.17487/RFC8530, March 2019, 1396 . 1398 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1399 for Connection-Oriented Operations, Administration, and 1400 Maintenance (OAM) Protocols", RFC 8531, 1401 DOI 10.17487/RFC8531, April 2019, 1402 . 1404 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1405 Raghavan, "Generic YANG Data Model for the Management of 1406 Operations, Administration, and Maintenance (OAM) 1407 Protocols That Use Connectionless Communications", 1408 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1409 . 1411 [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. 1412 Raghavan, "A YANG Data Model for Retrieval Methods for the 1413 Management of Operations, Administration, and Maintenance 1414 (OAM) Protocols That Use Connectionless Communications", 1415 RFC 8533, DOI 10.17487/RFC8533, April 2019, 1416 . 1418 [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm 1419 Management", RFC 8632, DOI 10.17487/RFC8632, September 1420 2019, . 1422 [RFC8652] Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 1423 Peter, "A YANG Data Model for the Internet Group 1424 Management Protocol (IGMP) and Multicast Listener 1425 Discovery (MLD)", RFC 8652, DOI 10.17487/RFC8652, November 1426 2019, . 1428 [RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data 1429 Model for Tunnel Interface Types", RFC 8675, 1430 DOI 10.17487/RFC8675, November 2019, 1431 . 1433 [RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for 1434 IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, 1435 DOI 10.17487/RFC8676, November 2019, 1436 . 1438 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 1439 Denial-of-Service Open Threat Signaling (DOTS) Data 1440 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 1441 May 2020, . 1443 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1444 O. Gonzalez de Dios, "YANG Data Model for Traffic 1445 Engineering (TE) Topologies", RFC 8795, 1446 DOI 10.17487/RFC8795, August 2020, 1447 . 1449 Appendix A. Layered YANG Modules Examples Overview 1451 This appendix lists a set of YANG data models that can be used for 1452 the delivery of connectivity services. These models can be 1453 classified as Service, Network, or Device Models. 1455 It is not the intent of this appendix to provide an inventory of 1456 tools and mechanisms used in specific network and service management 1457 domains; such inventory can be found in documents such as [RFC7276]. 1459 The reader may refer to the YANG Catalog 1460 () or the public Github YANG repository 1461 () to query existing YANG models. 1462 The YANG Catalog includes some metadata to indicate the module type 1463 ('module-classification') [I-D.clacla-netmod-model-catalog]. Note 1464 that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to 1465 associate tags with YANG modules in order to help classifying the 1466 modules. 1468 A.1. Service Models: Definition and Samples 1470 As described in [RFC8309], the service is "some form of connectivity 1471 between customer sites and the Internet and/or between customer sites 1472 across the network operator's network and across the Internet". More 1473 concretely, an IP connectivity service can be defined as the IP 1474 transfer capability characterized by a (Source Nets, Destination 1475 Nets, Guarantees, Scope) tuple where "Source Nets" is a group of 1476 unicast IP addresses, "Destination Nets" is a group of IP unicast 1477 and/or multicast addresses, and "Guarantees" reflects the guarantees 1478 (expressed in terms of QoS, performance, and availability, for 1479 example) to properly forward traffic to the said "Destination" 1480 [RFC7297]. 1482 For example: 1484 o The L3SM model [RFC8299] defines the L3VPN service ordered by a 1485 customer from a network operator. 1487 o The L2SM model [RFC8466] defines the L2VPN service ordered by a 1488 customer from a network operator. 1490 o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang] 1491 provides a YANG data model applicable to any mode of VN operation. 1493 L2SM and L3SM are customer service models as per [RFC8309]. 1495 A.2. Schema Mount 1497 Modularity and extensibility were among the leading design principles 1498 of the YANG data modeling language. As a result, the same YANG 1499 module can be combined with various sets of other modules and thus 1500 form a data model that is tailored to meet the requirements of a 1501 specific use case. [RFC8528] defines a mechanism, denoted schema 1502 mount, that allows for mounting one data model consisting of any 1503 number of YANG modules at a specified location of another (parent) 1504 schema. 1506 A.3. Network Models: Samples 1508 L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are 1509 examples of YANG Network Models. 1511 Figure 9 depicts a set of additional Network Models such as topology 1512 and tunnel models: 1514 +-------------------------------+-------------------------------+ 1515 | Topology YANG modules | Tunnel YANG modules | 1516 +-------------------------------+-------------------------------+ 1517 | +------------------+ | | 1518 | |Network Topologies| | +------+ +-----------+ | 1519 | | Model | | |Other | | TE Tunnel | | 1520 | +--------+---------+ | |Tunnel| +----+------+ | 1521 | | +---------+ | +------+ | | 1522 | +---+Service | | +----------+---------+ | 1523 | | |Topology | | | | | | 1524 | | +---------+ | | | | | 1525 | | +---------+ |+----+---+ +----+---+ +---+---+| 1526 | +---+Layer 3 | ||MPLS-TE | |RSVP-TE | | SR-TE || 1527 | | |Topology | || Tunnel | | Tunnel | |Tunnel || 1528 | | +---------+ |+--------+ +--------+ +-------+| 1529 | | +---------+ | | 1530 | +---+TE | | | 1531 | | |Topology | | | 1532 | | +---------+ | | 1533 | | +---------+ | | 1534 | +---+Layer 3 | | | 1535 | |Topology | | | 1536 | +---------+ | | 1537 +-------------------------------+-------------------------------+ 1539 Figure 9: Sample Resource Facing Network Models 1541 Examples of topology YANG modules are listed below: 1543 o Network Topologies Model: [RFC8345] defines a base model for 1544 network topology and inventories. Network topology data include 1545 link resource, node resource, and terminate-point resources. 1547 o TE Topology Model: [RFC8795] defines a YANG data model for 1548 representing and manipulating TE topologies. 1550 This module is extended from network topology model defined in 1551 [RFC8345] with TE topologies related content. This model contains 1552 technology-agnostic TE Topology building blocks that can be 1553 augmented and used by other technology-specific TE topology 1554 models. 1556 o Layer 3 Topology Model: 1558 [RFC8346] defines a YANG data model for representing and 1559 manipulating Layer 3 topologies. This model is extended from the 1560 network topology model defined in [RFC8345] with Layer 3 1561 topologies specifics. 1563 o Layer 2 Topology Model: 1565 [I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model 1566 for representing and manipulating Layer 2 topologies. This model 1567 is extended from the network topology model defined in [RFC8345] 1568 with Layer 2 topology specifics. 1570 Examples of tunnel YANG modules are provided below: 1572 o Tunnel identities: [RFC8675] defines a collection of YANG 1573 identities used as interface types for tunnel interfaces. 1575 o TE Tunnel Model: 1577 [I-D.ietf-teas-yang-te] defines a YANG module for the 1578 configuration and management of TE interfaces, tunnels, and LSPs. 1580 o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model: 1582 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1583 model(s) and defines a YANG module for SR-TE specific data. 1585 o MPLS-TE Model: 1587 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1588 model(s) and defines a YANG module for MPLS-TE configurations, 1589 state, RPC and notifications. 1591 o RSVP-TE MPLS Model: 1593 [I-D.ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 1594 with parameters to configure and manage signaling of MPLS RSVP-TE 1595 LSPs. 1597 Other sample Network Models are listed hereafter: 1599 o Path Computation API Model: 1601 [I-D.ietf-teas-yang-path-computation] YANG module for a stateless 1602 RPC which complements the stateful solution defined in 1603 [I-D.ietf-teas-yang-te]. 1605 o OAM Models (including Fault Management (FM) and Performance 1606 Monitoring): 1608 [RFC8532] defines a base YANG module for the management of OAM 1609 protocols that use Connectionless Communications. [RFC8533] 1610 defines a retrieval method YANG module for connectionless OAM 1611 protocols. [RFC8531] defines a base YANG module for connection 1612 oriented OAM protocols. These three models are intended to 1613 provide consistent reporting, configuration, and representation 1614 for connection-less OAM and Connection oriented OAM separately. 1616 Alarm monitoring is a fundamental part of monitoring the network. 1617 Raw alarms from devices do not always tell the status of the 1618 network services or necessarily point to the root cause. 1619 [RFC8632] defines a YANG module for alarm management. 1621 A.4. Device Models: Samples 1623 Network Element models (Figure 10) are used to describe how a service 1624 can be implemented by activating and tweaking a set of functions 1625 (enabled in one or multiple devices, or hosted in cloud 1626 infrastructures) that are involved in the service delivery. 1627 Figure 10 uses IETF-defined data models as an example. 1629 +------------------------+ 1630 +-+ Device Model | 1631 | +------------------------+ 1632 | +------------------------+ 1633 +---------------+ | | Logical Network | 1634 | | +-+ Element Model | 1635 | Architecture | | +------------------------+ 1636 | | | +------------------------+ 1637 +-------+-------+ +-+ Network Instance Model | 1638 | | +------------------------+ 1639 | | +------------------------+ 1640 | +-+ Routing Type Model | 1641 | +------------------------+ 1642 +-------+----------+----+------+------------+-----------+------+ 1643 | | | | | | | 1644 +-+-+ +---+---+ +----+----+ +--+--+ +----+----+ +--+--+ | 1645 |ACL| |Routing| |Transport| | OAM | |Multicast| | PM | Others 1646 +---+ +-+-----+ +----+----+ +--+--+ +-----+---+ +--+--+ 1647 | +-------+ | +------+ | +--------+ | +-----+ | +-----+ 1648 +-+Core | +-+ MPLS | +-+ BFD | +-+IGMP | +-+TWAMP| 1649 | |Routing| | | Base | | +--------+ | |/MLD | | +-----+ 1650 | +-------+ | +------+ | +--------+ | +-----+ | +-----+ 1651 | +-------+ | +------+ +-+LSP Ping| | +-----+ +-+OWAMP| 1652 +-+ BGP | +-+ MPLS | | +--------+ +-+ PIM | | +-----+ 1653 | +-------+ | | LDP | | +--------+ | +-----+ | +-----+ 1654 | +-------+ | +------+ +-+MPLS-TP | | +-----+ +-+LMAP | 1655 +-+ ISIS | | +------+ +--------+ +-+ MVPN| +-----+ 1656 | +-------+ +-+ MPLS | +-----+ 1657 | +-------+ |Static| 1658 +-+ OSPF | +------+ 1659 | +-------+ 1660 | +-------+ 1661 +-+ RIP | 1662 | +-------+ 1663 | +-------+ 1664 +-+ VRRP | 1665 | +-------+ 1666 | +-------+ 1667 +-+SR/SRv6| 1668 | +-------+ 1669 | +-------+ 1670 +-+ISIS-SR| 1671 | +-------+ 1672 | +-------+ 1673 +-+OSPF-SR| 1674 +-------+ 1676 Figure 10: Network Element Modules Overview 1678 A.4.1. Model Composition 1680 o Logical Network Element Model 1682 [RFC8530] defines a logical network element module which can be 1683 used to manage the logical resource partitioning that may be 1684 present on a network device. Examples of common industry terms 1685 for logical resource partitioning are Logical Systems or Logical 1686 Routers. 1688 o Network Instance Model 1690 [RFC8529] defines a network instance module. This module can be 1691 used to manage the virtual resource partitioning that may be 1692 present on a network device. Examples of common industry terms 1693 for virtual resource partitioning are VRF instances and Virtual 1694 Switch Instances (VSIs). 1696 A.4.2. Device Management 1698 The following list enumerates some YANG modules that can be used for 1699 device management: 1701 o [RFC8348]: defines a YANG module for the management of hardware. 1703 o [RFC7317]: defines the "ietf-system" YANG module that provides 1704 many features such as the configuration and the monitoring of 1705 system or system control operations (e.g., shutdown, restart, 1706 setting time) identification. 1708 o [RFC8341]: defines a network configuration access control YANG 1709 module. 1711 A.4.3. Interface Management 1713 The following provides some YANG modules that can be used for 1714 interface management: 1716 o [RFC7224]: defines a YANG module for interface type definitions. 1718 o [RFC8343]: defines a YANG module for the management of network 1719 interfaces. 1721 A.4.4. Some Device Model Examples 1723 The following provides an overview of some Device Models that can be 1724 used within a network. This list is not comprehensive. 1726 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS 1727 based Layer 2 VPN services (L2VPN) [RFC4664] and includes 1728 switching between the local attachment circuits. The 1729 L2VPN model covers point-to-point VPWS and Multipoint VPLS 1730 services. These services use signaling of Pseudowires 1731 across MPLS networks using LDP [RFC8077][RFC4762] or BGP 1732 [RFC4761]. 1734 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for 1735 Ethernet VPN services. The model is agnostic of the 1736 underlay. It applies to MPLS as well as to VxLAN 1737 encapsulation. The module is also agnostic to the 1738 services, including E-LAN, E-LINE, and E-TREE services. 1740 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can 1741 be used to configure and manage BGP L3VPNs [RFC4364]. It 1742 contains VRF specific parameters as well as BGP specific 1743 parameters applicable for L3VPNs. 1745 Core Routing: [RFC8349] defines the core routing YANG data model, 1746 which is intended as a basis for future data model 1747 development covering more-sophisticated routing systems. 1748 It is expected that other Routing technology YANG modules 1749 (e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core 1750 Routing base YANG module. 1752 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 1753 which serves as a base framework for configuring and 1754 managing an MPLS switching subsystem. It is expected that 1755 other MPLS technology YANG modules (e.g., MPLS LSP Static, 1756 LDP, or RSVP-TE models) will augment the MPLS base YANG 1757 module. 1759 BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for 1760 configuring and managing BGP, including protocol, policy, 1761 and operational aspects based on data center, carrier, and 1762 content provider operational requirements. 1764 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module 1765 for configuring and managing routing policies based on 1766 operational practice. The module provides a generic 1767 policy framework which can be augmented with protocol- 1768 specific policy configuration. 1770 SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment 1771 routing configuration and operation. 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 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 1780 to configure and manage Protocol Independent Multicast 1781 (PIM) devices. 1783 [RFC8652] defines a YANG module that can be used to 1784 configure and manage Internet Group Management Protocol 1785 (IGMP) and Multicast Listener Discovery (MLD) devices. 1787 [I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG 1788 module that can be used to configure and manage Internet 1789 Group Management Protocol (IGMP) and Multicast Listener 1790 Discovery (MLD) Snooping devices. 1792 [I-D.ietf-bess-mvpn-yang] defines a YANG data model to 1793 configure and manage Multicast in MPLS/BGP IP VPNs 1794 (MVPNs). 1796 PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for 1797 client and server implementations of the Two-Way Active 1798 Measurement Protocol (TWAMP). 1800 [I-D.ietf-ippm-stamp-yang] defines the data model for 1801 implementations of Session-Sender and Session-Reflector 1802 for Simple Two-way Active Measurement Protocol (STAMP) 1803 mode using YANG. 1805 [RFC8194] defines a YANG data model for Large-Scale 1806 Measurement Platforms (LMAPs). 1808 ACL: Access Control List (ACL) is one of the basic elements 1809 used to configure device forwarding behavior. It is used 1810 in many networking technologies such as Policy Based 1811 Routing, firewalls, etc. [RFC8519] describes a YANG data 1812 model of ACL basic building blocks. 1814 QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of 1815 Differentiated Services for configuration and operations. 1817 NAT: For the sake of network automation and the need for 1818 programming Network Address Translation (NAT) function in 1819 particular, a YANG data model for configuring and managing 1820 the NAT is essential. 1822 [RFC8512] defines a YANG module for the NAT function 1823 covering a variety of NAT flavors such as Network Address 1824 Translation from IPv4 to IPv4 (NAT44), Network Address and 1825 Protocol Translation from IPv6 Clients to IPv4 Servers 1826 (NAT64), customer-side translator (CLAT), Stateless IP/ 1827 ICMP Translation (SIIT), Explicit Address Mappings (EAM) 1828 for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), 1829 and Destination NAT. 1831 [RFC8513] specifies a DS-Lite YANG module. 1833 Stateless Address Sharing: [RFC8676] specifies a YANG module for A+P 1834 address sharing, including Lightweight 4over6, Mapping of 1835 Address and Port with Encapsulation (MAP-E), and Mapping 1836 of Address and Port using Translation (MAP-T) softwire 1837 mechanisms. 1839 Authors' Addresses 1841 Qin Wu (editor) 1842 Huawei 1843 101 Software Avenue, Yuhua District 1844 Nanjing, Jiangsu 210012 1845 China 1847 Email: bill.wu@huawei.com 1849 Mohamed Boucadair (editor) 1850 Orange 1851 Rennes 35000 1852 France 1854 Email: mohamed.boucadair@orange.com 1856 Diego R. Lopez 1857 Telefonica I+D 1858 Spain 1860 Email: diego.r.lopez@telefonica.com 1861 Chongfeng Xie 1862 China Telecom 1863 Beijing 1864 China 1866 Email: xiechf@chinatelecom.cn 1868 Liang Geng 1869 China Mobile 1871 Email: gengliang@chinamobile.com