idnits 2.17.1 draft-ietf-opsawg-model-automation-framework-09.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 (October 23, 2020) is 1274 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 (-08) exists of draft-ietf-dots-rfc8782-bis-01 == 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-04 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-stamp-yang-06 == 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-04 == Outdated reference: A later version (-12) exists of draft-ietf-opsawg-vpn-common-01 == 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-26 == 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 (-03) exists of draft-www-opsawg-yang-vpn-service-pm-01 == Outdated reference: A later version (-10) exists of draft-wwx-netmod-event-yang-09 Summary: 0 errors (**), 0 flaws (~~), 22 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: April 26, 2021 Orange 6 D. Lopez 7 Telefonica I+D 8 C. Xie 9 China Telecom 10 L. Geng 11 China Mobile 12 October 23, 2020 14 A Framework for Automating Service and Network Management with YANG 15 draft-ietf-opsawg-model-automation-framework-09 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 a framework for service and network 31 management automation that takes advantage of YANG modeling 32 technologies. This framework is drawn from a network operator 33 perspective irrespective of the origin of a data model; it can thus 34 accommodate YANG 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 April 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3. Architectural Concepts and Goals . . . . . . . . . . . . . . 7 75 3.1. Data Models: Layering and Representation . . . . . . . . 7 76 3.2. Automation of Service Delivery Procedures . . . . . . . . 12 77 3.3. Service Fulfillment Automation . . . . . . . . . . . . . 13 78 3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 13 79 4. Functional Blocks and Interactions . . . . . . . . . . . . . 14 80 4.1. Service Lifecycle Management Procedure . . . . . . . . . 15 81 4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 15 82 4.1.2. Service Creation/Modification . . . . . . . . . . . . 15 83 4.1.3. Service Assurance . . . . . . . . . . . . . . . . . . 16 84 4.1.4. Service Optimization . . . . . . . . . . . . . . . . 16 85 4.1.5. Service Diagnosis . . . . . . . . . . . . . . . . . . 16 86 4.1.6. Service Decommission . . . . . . . . . . . . . . . . 17 87 4.2. Service Fullfillment Management Procedure . . . . . . . . 17 88 4.2.1. Intended Configuration Provision . . . . . . . . . . 17 89 4.2.2. Configuration Validation . . . . . . . . . . . . . . 18 90 4.2.3. Performance Monitoring . . . . . . . . . . . . . . . 18 91 4.2.4. Fault Diagnostic . . . . . . . . . . . . . . . . . . 19 92 4.3. Multi-Layer/Multi-Domain Service Mapping . . . . . . . . 19 93 4.4. Service Decomposition . . . . . . . . . . . . . . . . . . 19 94 5. YANG Data Model Integration Examples . . . . . . . . . . . . 20 95 5.1. L2VPN/L3VPN Service Delivery . . . . . . . . . . . . . . 20 96 5.2. VN Lifecycle Management . . . . . . . . . . . . . . . . . 22 97 5.3. Event-based Telemetry in the Device Self Management . . . 23 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 99 6.1. Service Level . . . . . . . . . . . . . . . . . . . . . . 25 100 6.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 26 101 6.3. Device Level . . . . . . . . . . . . . . . . . . . . . . 26 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 104 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 107 10.2. Informative References . . . . . . . . . . . . . . . . . 28 108 Appendix A. Layered YANG Modules Examples Overview . . . . . . . 37 109 A.1. Service Models: Definition and Samples . . . . . . . . . 37 110 A.2. Schema Mount . . . . . . . . . . . . . . . . . . . . . . 38 111 A.3. Network Models: Samples . . . . . . . . . . . . . . . . . 38 112 A.4. Device Models: Samples . . . . . . . . . . . . . . . . . 41 113 A.4.1. Model Composition . . . . . . . . . . . . . . . . . . 43 114 A.4.2. Device Management . . . . . . . . . . . . . . . . . . 43 115 A.4.3. Interface Management . . . . . . . . . . . . . . . . 43 116 A.4.4. Some Device Model Examples . . . . . . . . . . . . . 43 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 119 1. Introduction 121 Service management systems usually comprise service activation/ 122 provision and service operation. Current service delivery 123 procedures, from the processing of customer requirements and orders 124 to service delivery and operation, typically assume the manipulation 125 of data sequentially into multiple Operations Support System (OSS) or 126 Business Support System (BSS) applications that may be managed by 127 different departments within the service provider's organization 128 (e.g., billing factory, design factory, network operation center). 129 Many of these applications have been developed in-house over the 130 years and operate in a silo mode: 132 o The lack of standard data input/output (i.e., data model) raises 133 many challenges in system integration and often results in manual 134 configuration tasks. 136 o Service fulfillment systems might have a limited visibility on the 137 network state and therefore have slow response to network changes. 139 Software Defined Networking (SDN) becomes crucial to address these 140 challenges. SDN techniques are meant to automate the overall service 141 delivery procedures and typically rely upon standard data models. 142 These models are used to not only reflect service providers' savoir- 143 faire, but also to dynamically instantiate and enforce a set of 144 service-inferred policies that best accommodate what has been defined 145 and possibly negotiated with the customer. [RFC7149] provides a 146 first tentative attempt to rationalize that service provider's view 147 on the SDN space by identifying concrete technical domains that need 148 to be considered and for which solutions can be provided: 150 o Techniques for the dynamic discovery of topology, devices, and 151 capabilities, along with relevant information and data models that 152 are meant to precisely document such topology, devices, and their 153 capabilities. 155 o Techniques for exposing network services [RFC8309] and their 156 characteristics. 158 o Techniques used by service-derived dynamic resource allocation and 159 policy enforcement schemes, so that networks can be programmed 160 accordingly. 162 o Dynamic feedback mechanisms that are meant to assess how 163 efficiently a given policy (or a set thereof) is enforced from a 164 service fulfillment and assurance perspectives. 166 Models are key for each of the aforementioned four technical items. 167 Service and network management automation is an important step to 168 improve the agility of network operations. Models are also important 169 to ease integrating multi-vendor solutions. 171 YANG [RFC7950] module developers have taken both top-down and bottom- 172 up approaches to develop modules [RFC8199] and to establish a mapping 173 between a network technology and customer requirements at the top or 174 abstracting common constructs from various network technologies at 175 the bottom. At the time of writing this document (2020), there are 176 many YANG data models including configuration and service models that 177 have been specified or are being specified by the IETF. They cover 178 many of the networking protocols and techniques. However, how these 179 models work together to configure a function, manage a set of devices 180 involved in a service, or provide a service is something that is not 181 currently documented either within the IETF or other Standards 182 Development Organizations (SDOs). 184 Many of the YANG modules listed in this document are used to exchange 185 data between NETCONF/RESTCONF clients and servers [RFC6241][RFC8040]. 186 Nevertheless, YANG is transport-independent data modeling language. 187 It can thus be used independently of NETCONF/RESTOCNF. For example, 188 YANG can be used to define abstract data structures [RFC8791] that 189 can be manipulated by other protocols (e.g., 190 [I-D.ietf-dots-rfc8782-bis]). 192 This document describes an architectural framework for service and 193 network management automation (Section 3) that takes advantage of 194 YANG modeling technologies and investigates how YANG data models at 195 different layers interact with each other (e.g., service mapping, 196 model composition) in the context of service delivery and fulfillment 197 (Section 4). Concretely, the following benefits can be provided: 199 o Allow for vendor-agnostic interfaces to manage a service and the 200 underlying network. 202 o Move from deployment schemes where vendor-specific network 203 managers are required to a scheme where the entities that are 204 responsible for orchestrating and controlling services and network 205 resources provided by multi-vendor devices are unified. 207 o Ease data inheritance and reusability among the various 208 architecture layers thus promoting a network-wise provisioning 209 instead of device-specific configuration. 211 o Dynamically feed a decision-making process (e.g., Controllers, 212 Orchestrators) with notifications that will trigger appropriate 213 actions, allowing that decision-making process to continuously 214 adjust a network (and thus, the involved resources) to deliver the 215 service that conforms to the intended parameters (service 216 objectives). 218 This framework is drawn from a network operator perspective 219 irrespective of the origin of a data model; it can also accommodate 220 YANG modules that are developed outside the IETF. The document 221 covers service models that are used by an operator to expose its 222 services and capture service requirements from the customers 223 (including other operators). Nevertheless, the document does not 224 elaborate on the communication protocol(s) that makes use of these 225 service models in order to request and deliver a service. Such 226 considerations are out of scope. 228 The document identifies a list of use cases to exemplify the proposed 229 approach (Section 5), but it does not claim nor aim to be exhaustive. 230 Appendix A lists some examples to illustrate the layered YANG modules 231 view. 233 2. Terminology and Acronyms 235 2.1. Terminology 237 The following terms are defined in [RFC8309][RFC8199] and are not 238 redefined here: 240 o Network Operator 242 o Customer 244 o Service 246 o Data Model 248 o Service Model 250 o Network Element Module 252 In addition, the document makes use of the following terms: 254 Network Model: Describes a network level abstraction (or a subset of 255 aspects of a network infrastructure), including devices and their 256 subsystems, and relevant protocols operating at the link and 257 network layers across multiple devices. This model corresponds to 258 the network configuration model discussed in [RFC8309]. 260 It can be used by a network operator to allocate resources (e.g., 261 tunnel resource, topology resource) for the service or schedule 262 resources to meet the service requirements defined in a service 263 model. 265 Network Domain: Refers to a network partitioning that is usually 266 followed by network operators to delimit parts of their network. 267 "access network" and "core network" are examples of network 268 domains. 270 Device Model: Refers to the Network Element YANG data model 271 described in [RFC8199] or the device configuration model discussed 272 in [RFC8309]. 274 Device models are also used to refer to model a function embedded 275 in a device (e.g., Network Address Translation (NAT) [RFC8512], 276 Access Control Lists (ACLs) [RFC8519]). 278 Pipe: Refers to a communication scope where only one-to-one (1:1) 279 communications are allowed. The scope can be identified between 280 ingress and egress nodes, two service sites, etc. 282 Hose: Refers to a communication scope where one-to-many (1:N) 283 communications are allowed (e.g., one site to multiple sites). 285 Funnel: Refers to a communication scope where many-to-one (N:1) 286 communications are allowed. 288 2.2. Acronyms 290 The following acronyms are used in the document: 292 ACL Access Control List 293 AS Autonomous System 294 AP Access Point 295 CE Customer Edge 296 DBE Data Border Element 297 E2E End-to-End 298 ECA Event Condition Action 299 L2VPN Layer 2 Virtual Private Network 300 L3VPN Layer 3 Virtual Private Network 301 L3SM L3VPN Service Model 302 L3NM L3VPN Network Model 303 NAT Network Address Translation 304 OAM Operations, Administration, and Maintenance 305 OWD One-Way Delay 306 PE Provider Edge 307 PM Performance Monitoring 308 QoS Quality of Service 309 RD Route Distinguisher 310 RT Route Target 311 SBE Session Border Element 312 SDN Software Defined Networking 313 SP Service Provider 314 TE Traffic Engineering 315 VN Virtual Network 316 VPN Virtual Private Network 317 VRF Virtual Routing and Forwarding 319 3. Architectural Concepts and Goals 321 3.1. Data Models: Layering and Representation 323 As described in Section 2 of [RFC8199], layering of modules allows 324 for better reusability of lower-layer modules by higher-level modules 325 while limiting duplication of features across layers. 327 Data models in the context of network management can be classified 328 into service, network, and device models. Different service models 329 may rely on the same set of network and/or device models. 331 Service models traditionally follow a top-down approach and are 332 mostly customer-facing YANG modules providing a common model 333 construct for higher level network services (e.g., Layer 3 Virtual 334 Private Network (L3VPN)). Such modules can be mapped to network 335 technology-specific modules at lower layers (e.g., tunnel, routing, 336 Quality of Service (QoS), security). For example, service models can 337 be used to characterise the network service(s) to be ensured between 338 service nodes (ingress/egress) such as: 340 o the communication scope (pipe, hose, funnel, ...), 341 o the directionality (inbound/outbound), 342 o the traffic performance guarantees expressed using metrics such as 343 One-Way Delay (OWD) [RFC7679] or One-Way Loss [RFC7680]; a summary 344 of performance metrics maintained by IANA can be found in [IPPM], 345 o link capacity [RFC5136] [I-D.ietf-ippm-capacity-metric-method], 346 o etc. 348 Figure 1 depicts the example of a VoIP service that relies upon 349 connectivity services offered by a network operator. In this 350 example, the VoIP service is offered to the network operator's 351 customers by Service Provider (SP1). In order to provide global VoIP 352 reachability, SP1 service site interconnects with other Service 353 Providers service sites typically by interconnecting Session Border 354 Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406]. 355 For other VoIP destinations, sessions are forwarded over the 356 Internet. These connectivity services can be captured in a YANG 357 service model that reflects the service attributes that are shown in 358 Figure 2. This example follows the IP Connectivity Provisioning 359 Profile template defined in [RFC7297]. 361 In reference to Figure 2, "Full traffic performance guarantees class" 362 refers to a service class where all traffic performance metrics 363 included in the service model (OWD, loss, delay variation) are 364 guaranteed, while "Delay traffic performance guarantees class" refers 365 to a service class where only OWD is guaranteed. 367 ,--,--,--. ,--,--,--. 368 ,-' SP1 `-. ,-' SP2 `-. 369 ( Service Site ) ( Service Site ) 370 `-. ,-' `-. ,-' 371 `--'--'--' `--'--'--' 372 x | o * * | 373 (2)x | o * * | 374 ,x-,--o-*-. (1) ,--,*-,--. 375 ,-' x o * * * * * * * * * `-. 376 ( x o +----( Internet ) 377 User---(x x x o o o o o o o o o o o o o o o o o o 378 `-. ,-' `-. ,-' (3) 379 `--'--'--' `--'--'--' 380 Network Operator 382 **** (1) Inter-SP connectivity 383 xxxx (2) Customer to SP connectivity 384 oooo (3) SP to any destination connectivity 386 Figure 1: An Example of Service Connectivity Components 388 Connectivity: Scope and Guarantees 389 (1) Inter-SP connectivity 390 - Pipe scope from the local to the remote SBE/DBE 391 - Full traffic performance guarantees class 392 (2) Customer to SP connectivity 393 - Hose/Funnel scope connecting the local SBE/DBE 394 to the customer access points 395 - Full traffic performance guarantees class 396 (3) SP to any destination connectivity 397 - Hose/Funnel scope from the local SBE/DBE to the 398 Internet gateway 399 - Delay traffic performance guarantees class 400 Flow Identification 401 * Destination IP address (SBE, DBE) 402 * DSCP marking 403 Traffic Isolation 404 * VPN 405 Routing & Forwarding 406 * Routing rule to exclude some ASes from the inter-domain 407 paths 408 Notifications (including feedback) 409 * Statistics on aggregate traffic to adjust capacity 410 * Failures 411 * Planned maintenance operations 412 * Triggered by thresholds 414 Figure 2: Sample Attributes Captured in a Service Model 416 Network models are mainly network resource-facing modules; they 417 describe various aspects of a network infrastructure, including 418 devices and their subsystems, and relevant protocols operating at the 419 link and network layers across multiple devices (e.g., network 420 topology and traffic-engineering tunnel modules). 422 Device (and function) models usually follow a bottom-up approach and 423 are mostly technology-specific modules used to realize a service 424 (e.g., BGP, ACL). 426 Each level maintains a view of the supported YANG modules provided by 427 lower levels (see for example, Appendix A). Mechanisms such as YANG 428 library [RFC8525] can be used to expose which YANG modules are 429 supported by nodes in lower levels. 431 Figure 3 illustrates the overall layering model. The reader may 432 refer to Section 4 of [RFC8309] for an overview of "Orchestrator" and 433 "Controller" elements. All these elements (i.e., Orchestrator(s), 434 Controller(s), device(s)) are under the responsibility of the same 435 operator. 437 +-----------------------------------------------------------------+ 438 | Hierarchy Abstraction | 439 | | 440 | +-----------------------+ Service Model | 441 | | Orchestrator | (Customer Oriented) | 442 | |+---------------------+| Scope: "1:1" Pipe model | 443 | || Service Modeling || | 444 | |+---------------------+| | 445 | | | Bidirectional | 446 | |+---------------------+| +-+ Capacity, OWD +-+ | 447 | ||Service Orchestration|| | +----------------+ | | 448 | |+---------------------+| +-+ +-+ | 449 | +-----------------------+ Ingress Egress | 450 | | 451 | | 452 | +-----------------------+ Network Model | 453 | | Controller | (Operator Oriented) | 454 | |+---------------------+| +-+ +--+ +---+ +-+ | 455 | || Network Modeling || | | | | | | | | | 456 | |+---------------------+| | o----o--o----o---o---o | | 457 | | | +-+ +--+ +---+ +-+ | 458 | |+---------------------+| src dst | 459 | ||Network Orchestration|| L3VPN over TE | 460 | |+---------------------+| Instance Name/Access Interface | 461 | +-----------------------+ Protocol Type/Capacity/RD/RT/... | 462 | | 463 | | 464 | +-----------------------+ Device Model | 465 | | Device | | 466 | |+--------------------+ | | 467 | || Device Modeling | | Interface add, BGP Peer, | 468 | |+--------------------+ | Tunnel ID, QoS/TE, ... | 469 | +-----------------------+ | 470 +-----------------------------------------------------------------+ 472 Figure 3: Layering and Representation Within a Network Operator 474 A composite service offered by a network operator may rely on 475 services from other operators. In such case, the network operator 476 acts as a customer to request services from other networks. The 477 operators providing these services will then follow the layering 478 depicted in Figure 3. The mapping between a composite service and a 479 third-party service is maintained at the orchestration level. From a 480 data plane perspective, appropriate traffic steering policies (e.g., 481 Service Function Chaining [RFC7665]) are managed by the network 482 controllers to guide how/when a third party service is invoked for 483 flows bound to a composite service. 485 The layering model depicted in Figure 3 does not make any assumption 486 about the location of the various entities (e.g., controller, 487 orchestrator) within the network. As such, the architecture does not 488 preclude deployments where, for example, the controller is embedded 489 on a device that hosts other functions that are controlled via YANG 490 modules. 492 In order to ease the mapping between layers and data reuse, this 493 document focuses on service models that are modelled using YANG. 494 Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3 495 does not preclude service models to be modelled using other data 496 modelling languages than YANG. 498 3.2. Automation of Service Delivery Procedures 500 Service models can be used by a network operator to expose its 501 services to its customers. Exposing such models allows to automate 502 the activation of service orders and thus the service delivery. One 503 or more monolithic service models can be used in the context of a 504 composite service activation request (e.g., delivery of a caching 505 infrastructure over a VPN). Such models are used to feed a decision- 506 making intelligence to adequately accommodate customer's needs. 508 Also, such models may be used jointly with services that require 509 dynamic invocation. An example is provided by the service modules 510 defined by the DOTS WG to dynamically trigger requests to handle 511 Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service 512 filtering request modelled using [RFC8783] will be translated into 513 device-specific filtering (e.g., ACLs defined in [RFC8519]) that 514 fulfils the service request. 516 Network models can be derived from service models and used to 517 provision, monitor, instantiate the service, and provide lifecycle 518 management of network resources. Doing so is meant to: 520 o expose network resources to customers (including other network 521 operators) to provide service fulfillment and assurance. 523 o allow customers (or network operators) to dynamically adjust the 524 network resources based on service requirements as described in 525 service models (e.g., Figure 2) and the current network 526 performance information described in the telemetry modules. 528 Note that it is out of the scope of this document to elaborate on the 529 communication protocols that are used to implement the interface 530 between the service ordering (customer) and service order handling 531 (provider). 533 3.3. Service Fulfillment Automation 535 To operate a service, the settings of the parameters in the device 536 models are derived from service models and/or network models and are 537 used to: 539 o Provision each involved network function/device with the proper 540 configuration information. 542 o Operate the network based on service requirements as described in 543 the service model(s) and local operational guidelines. 545 In addition, the operational state including configuration that is in 546 effect together with statistics should be exposed to upper layers to 547 provide better network visibility and assess to what extent the 548 derived low level modules are consistent with the upper level inputs. 550 Filters are enforced on the notifications that are communicated to 551 Service layers. The type and frequency of notifications may be 552 agreed in the service model. 554 Note that it is important to correlate telemetry data with 555 configuration data to be used for closed loops at the different 556 stages of service delivery, from resource allocation to service 557 operation, in particular. 559 3.4. YANG Modules Integration 561 To support top-down service delivery, YANG modules at different 562 levels or at the same level need to be integrated together for proper 563 service delivery (including, proper network setup). For example, the 564 service parameters captured in service models need to be decomposed 565 into a set of configuration/notification parameters that may be 566 specific to one or more technologies; these technology-specific 567 parameters are grouped together to define technology-specific device 568 level models or network level models. 570 In addition, these technology-specific device or network models can 571 be further integrated with each other using the schema mount 572 mechanism [RFC8528] to provision each involved network function/ 573 device or each involved network domain to support newly added modules 574 or features. A collection of device models integrated together can 575 be loaded and validated during implementation. 577 High-level policies can be defined at service or network models 578 (e.g., "Autonomous System Number (ASN) Exclude" in the example 579 depicted in Figure 2). Device models will be tweaked accordingly to 580 provide policy-based management. Policies can also be used for 581 telemetry automation, e.g., policies that contain conditions to 582 trigger the generation and pushing of new telemetry data. 584 4. Functional Blocks and Interactions 586 The architectural considerations described in Section 3 lead to the 587 lifecycle management architecture illustrated in Figure 4 and 588 described in the following subsections. 590 +------------------+ 591 ................. | | 592 Service level | | 593 V | 594 E2E E2E E2E E2E 595 Service --> Service ---------> Service ------------> Service 596 Exposure Creation ^ Optimization ^ Diagnosis 597 /Modification | | | 598 ^ | |Diff | | 599 E2E | | | E2E | | 600 Service ----+ | | Service | | 601 Decommission | +------ Assurance --+ | 602 | ^ | 603 Multi-layer | | | 604 Multi-domain | | | 605 Service Mapping| | | 606 ................. |<-----------------+ | | 607 Network level | | +-------+ v 608 V | | Specific 609 Specific Specific | Service 610 Service --------> Service <--+ | Diagnosis 611 Creation ^ Optimization | | | 612 /Modification | | | | 613 | |Diff | | | 614 | | Specific --+ | | 615 Service | | Service | | 616 Decomposition | +----- Assurance ----+ | 617 | ^ | 618 ................. | | Aggregation | 619 Device level | +------------+ | 620 V | | 621 Service Intent | v 622 Fulfillment Config ----> Config ----> Performance ----> Fault 623 Provision Validation Monitoring Diagnostic 625 Figure 4: Service and Network Lifecycle Management 627 4.1. Service Lifecycle Management Procedure 629 Service lifecycle management includes end-to-end service lifecycle 630 management at the service level and technology specific network 631 lifecycle management at the network level. 633 The end-to-end service lifecycle management is technology-independent 634 service management and spans across multiple network domains and/or 635 multiple layers while technology specific service lifecycle 636 management is technology domain specific or layer specific service 637 lifecycle management. 639 4.1.1. Service Exposure 641 A service in the context of this document (sometimes called, Network 642 Service) is some form of connectivity between customer sites and the 643 Internet or between customer sites across the operator's network and 644 across the Internet. 646 Service exposure is used to capture services offered to customers 647 (ordering and order handling). One example is that a customer can 648 use a L3VPN Service Model (L3SM) to request L3VPN service by 649 providing the abstract technical characterization of the intended 650 service between customer sites. 652 Service model catalogs can be created along to expose the various 653 services and the information needed to invoke/order a given service. 655 4.1.2. Service Creation/Modification 657 A customer is usually unaware of the technology that the network 658 operator has available to deliver the service, so the customer does 659 not make requests specific to the underlying technology but is 660 limited to making requests specific to the service that is to be 661 delivered. This service request can be filled using a service model. 663 Upon receiving a service request, and assuming that appropriate 664 authentication and authorization checks have been made with success, 665 the service orchestrator/management system should verify whether the 666 service requirements in the service request can be met (i.e., whether 667 there are sufficient resources that can be allocated with the 668 requested guarantees). 670 If the request is accepted, the service orchestrator/management 671 system maps such service request to its view. This view can be 672 described as a technology specific network model or a set of 673 technology specific device models and this mapping may include a 674 choice of which networks and technologies to use depending on which 675 service features have been requested. 677 In addition, a customer may require to change the underlying network 678 infrastructure to adapt to new customer's needs and service 679 requirements (e.g., service a new customer site, add a new access 680 link, provide disjoint paths). This service modification can be 681 issued following the same service model used by the service request. 683 Withdrawing a service is discussed in Section 4.1.6. 685 4.1.3. Service Assurance 687 The performance measurement telemetry (Section 4.2) can be used to 688 provide service assurance at Service and/or Network levels. 689 Performance measurement telemetry model can tie with service or 690 network models to monitor network performance or Service Level 691 Agreement. 693 4.1.4. Service Optimization 695 Service optimization is a technique that gets the configuration of 696 the network updated due to network changes, incident mitigation, or 697 new service requirements. One example is once a tunnel or a VPN is 698 setup, Performance monitoring information or telemetry information 699 per tunnel (or per VPN) can be collected and fed into the management 700 system. If the network performance doesn't meet the service 701 requirements, the management system can create new VPN policies 702 capturing network service requirements and populate them into the 703 network. 705 Both network performance information and policies can be modelled 706 using YANG. With Policy-based management, self-configuration and 707 self-optimization behavior can be specified and implemented. 709 The overall service optimization is managed at the service level, 710 while the network level is responsible for the optimization of the 711 specific network services it provides. 713 4.1.5. Service Diagnosis 715 Operations, Administration, and Maintenance (OAM) are important 716 networking functions for service diagnosis that allow network 717 operators to: 719 o monitor network communications (i.e., reachability verification 720 and Continuity Check) 722 o troubleshoot failures (i.e., fault verification and localization) 724 o monitor service-level agreements and performance (i.e., 725 performance management) 727 When the network is down, service diagnosis should be in place to 728 pinpoint the problem and provide recommendations (or instructions) 729 for the network recovery. 731 The service diagnosis information can be modelled as technology- 732 independent Remote Procedure Call (RPC) operations for OAM protocols 733 and technology-independent abstraction of key OAM constructs for OAM 734 protocols [RFC8531][RFC8533]. These models can be used to provide 735 consistent configuration, reporting, and presentation for the OAM 736 mechanisms used to manage the network. 738 Refer to Section 4.2.4 for the device-specific side. 740 4.1.6. Service Decommission 742 Service decommission allows a customer to stop the service by 743 removing the service from active status and thus releasing the 744 network resources that were allocated to the service. Customers can 745 also use the service model to withdraw the subscription to a service. 747 4.2. Service Fullfillment Management Procedure 749 4.2.1. Intended Configuration Provision 751 Intended configuration at the device level is derived from network 752 models at the network level or service model at the service level and 753 represents the configuration that the system attempts to apply. Take 754 L3SM as a service model example to deliver a L3VPN service, there is 755 a need to map the L3VPN service view defined in the service model 756 into a detailed intended configuration view defined by specific 757 configuration models for network elements; the configuration 758 information includes: 760 o Virtual Routing and Forwarding (VRF) definition, including VPN 761 policy expression 763 o Physical Interface(s) 765 o IP layer (IPv4, IPv6) 767 o QoS features such as classification, profiles, etc. 769 o Routing protocols: support of configuration of all protocols 770 listed in a service request, as well as routing policies 771 associated with those protocols. 773 o Multicast support 775 o Address sharing 777 o Security (e.g., access control, authentication, encryption) 779 These specific configuration models can be used to configure Provider 780 Edge (PE) and Customer Edge (CE) devices within a site, e.g., a BGP 781 policy model can be used to establish VPN membership between sites 782 and VPN Service Topology. 784 Note that in networks with legacy devices (that support proprietary 785 modules or do not support YANG at all), an adaptation layer is likely 786 to be required at the network level so that these devices can be 787 involved in the delivery of the network services. 789 This interface is also used to handle service withdrawal 790 (Section 4.1.6). 792 4.2.2. Configuration Validation 794 Configuration validation is used to validate intended configuration 795 and ensure the configuration take effect. 797 For example, if a customer creates an interface "eth-0/0/0" but the 798 interface does not physically exist at this point, then configuration 799 data appears in the status but does not appear in the 800 datastore. More details about and 801 datastores can be found in Section 5.1 of [RFC8342]. 803 4.2.3. Performance Monitoring 805 When a configuration is in effect in a device, 806 datastore holds the complete operational state of the device 807 including learned, system, default configuration, and system state. 808 However, the configurations and state of a particular device does not 809 have the visibility on the whole network or how packets are going to 810 be forwarded through the entire network. Therefore, it becomes more 811 difficult to operate the entire network without understanding the 812 current status of the network. 814 The management system should subscribe to updates of a YANG datastore 815 in all the network devices for performance monitoring purposes and 816 build a full topological visibility of the network by aggregating 817 (and filtering) these operational state from different sources. 819 4.2.4. Fault Diagnostic 821 When configuration is in effect in a device, some devices may be mis- 822 configured (e.g., device links are not consistent in both sides of 823 the network connection) or network resources might be mis-allocated. 824 Therefore, services may be negatively affected without knowing the 825 root cause in the network. 827 Technology-dependent nodes and RPC commands are defined in 828 technology-specific YANG data models which can use and extend the 829 base model described in Section 4.1.5 to deal with these issues. 831 These RPC commands received in the technology-dependent node can be 832 used to trigger technology-specific OAM message exchanges for fault 833 verification and fault isolation. For example, TRILL Multicast Tree 834 Verification (MTV) RPC command [I-D.ietf-trill-yang-oam] can be used 835 to trigger Multi-Destination Tree Verification Message defined in 836 [RFC7455] to verify TRILL distribution tree integrity. 838 4.3. Multi-Layer/Multi-Domain Service Mapping 840 Multi-layer/Multi-domain Service Mapping allows to map an end-to-end 841 abstract view of the service segmented at different layers and/or 842 different network domains into domain-specific views. 844 One example is to map service parameters in the L3SM into 845 configuration parameters such as Route Distinguisher (RD), Route 846 Target (RT), and VRF in the L3VPN Network Model (L3NM). 848 Another example is to map service parameters in the L3SM into Traffic 849 Engineered (TE) tunnel parameters (e.g., Tunnel ID) in TE model and 850 Virtual Network (VN) parameters (e.g., Access Point (AP) list, VN 851 members) in the YANG data model for VN operation 852 [I-D.ietf-teas-actn-vn-yang]. 854 4.4. Service Decomposition 856 Service Decomposition allows to decompose service models at the 857 service level or network models at the network level into a set of 858 device models at the device level. These device models may be tied 859 to specific device types or classified into a collection of related 860 YANG modules based on service types and features offered, and load at 861 the implementation time before configuration is loaded and validated. 863 5. YANG Data Model Integration Examples 865 The following subsections provide some YANG data models integration 866 examples. 868 5.1. L2VPN/L3VPN Service Delivery 870 In reference to Figure 5, the following steps are performed to 871 deliver the L3VPN service within the network management automation 872 architecture defined in Section 4: 874 1. The Customer requests to create two sites (as per Service 875 Creation in Section 4.2.1) relying upon L3SM with each site 876 having one network access connectivity, for example: 878 * Site A: network-access A, link-capacity = 20 Mbps, class 879 "foo", guaranteed-capacity-percent = 10, average-one-way-delay 880 = 70 ms. 882 * Site B: network-access B, link-capacity = 30 Mbps, class 883 "foo1", guaranteed-capacity-percent = 15, average-one-way- 884 delay = 60 ms. 886 2. The Orchestrator extracts the service parameters from the L3SM. 887 Then, it uses them as input to the Service Mapping in Section 4.3 888 to translate them into an orchestrated configuration parameters 889 (e.g., RD, RT, VRF) that are part of the L3NM specified in 890 [I-D.ietf-opsawg-l3sm-l3nm]. 892 3. The Controller takes the orchestrated configuration parameters in 893 the L3NM and translates them into orchestrated (Service 894 Decomposition in Section 4.4) configuration of network elements 895 that are part of, e.g., BGP, QoS, Network Instance, IP 896 management, and interface models. 898 [I-D.ogondio-opsawg-uni-topology] can be used for representing, 899 managing, and controlling the User Network Interface (UNI) topology. 901 L3SM | 902 Service | 903 Model | 904 +------------------------+------------------------+ 905 | +--------V--------+ | 906 | | Service Mapping | | 907 | +--------+--------+ | 908 | Orchestrator | | 909 +------------------------+------------------------+ 910 L3NM | ^ UNI Topology Model 911 Network | | 912 Model | | 913 +------------------------+------------------------+ 914 | +-----------V-----------+ | 915 | | Service Decomposition | | 916 | +--++---------------++--+ | 917 | || || | 918 | Controller || || | 919 +---------------++---------------++---------------+ 920 || || 921 || BGP, || 922 || QoS, || 923 || Interface, || 924 +------------+| NI, |+------------+ 925 | | IP | | 926 +--+--+ +--+--+ +--+--+ +--+--+ 927 | CE1 +-------+ PE1 | | PE2 +-------+ CE2 | 928 +-----+ +-----+ +-----+ +-----+ 930 Figure 5: L3VPN Service Delivery Example (Current) 932 L3NM inherits some of data elements from the L3SM. Nevertheless, the 933 L3NM as currently designed in [I-D.ietf-opsawg-l3sm-l3nm] does not 934 expose some information to the above layer such as the capabilities 935 of an underlying network (which can be used to drive service order 936 handling) or notifications (to notify subscribers about specific 937 events or degradations as per agreed SLAs). Some of this information 938 can be provided using, e.g., [I-D.www-opsawg-yang-vpn-service-pm]. A 939 target overall model is depicted in Figure 6. 941 L3SM | ^ 942 Service | | Notifications 943 Model | | 944 +------------------------+------------------------+ 945 | +--------V--------+ | 946 | | Service Mapping | | 947 | +--------+--------+ | 948 | Orchestrator | | 949 +------------------------+------------------------+ 950 L3NM | ^ UNI Topology Model 951 Network| | L3NM Notifications 952 Model | | L3NM Capabilities 953 +------------------------+------------------------+ 954 | +-----------V-----------+ | 955 | | Service Decomposition | | 956 | +--++---------------++--+ | 957 | || || | 958 | Controller || || | 959 +---------------++---------------++---------------+ 960 || || 961 || BGP, || 962 || QoS, || 963 || Interface, || 964 +------------+| NI, |+------------+ 965 | | IP | | 966 +--+--+ +--+--+ +--+--+ +--+--+ 967 | CE1 +-------+ PE1 | | PE2 +-------+ CE2 | 968 +-----+ +-----+ +-----+ +-----+ 970 Figure 6: L3VPN Service Delivery Example (Target) 972 Note that a similar analysis can be performed for Layer 2 VPNs 973 (L2VPNs). A L2VPN Service Model (L2SM) is defined in [RFC8466], 974 while the L2VPN Network YANG Model (L2NM) is specified in 975 [I-D.ietf-opsawg-l2nm]. 977 5.2. VN Lifecycle Management 979 In reference to Figure 7, the following steps are performed to 980 deliver the VN service within the network management automation 981 architecture defined in Section 4: 983 1. A customer makes a request (Service Exposure in Section 4.1.1) to 984 create a VN. The association between the VN, APs, and VN members 985 is defined in the VN YANG module [I-D.ietf-teas-actn-vn-yang]. 987 2. The Orchestrator creates the single abstract node topology based 988 on the information captured in the request. 990 3. The customer exchanges with the Orchestrator the connectivity 991 matrix on the abstract node topology and explicit paths using the 992 TE topology model [RFC8795]. This information can be used to 993 instantiate the VN and setup tunnels between source and 994 destination endpoints (Service Creation in Section 4.1.2). 996 4. In order to provide service assurance (Service Optimization in 997 Section 4.1.4), the telemetry model which augments the VN model 998 and corresponding TE tunnel model can be used by the Orchestrator 999 to subscribe to performance measurement data. The Controller 1000 will then notify the Orchestrator with all the parameter changes 1001 and network performance changes related to the VN topology and 1002 the tunnels [I-D.ietf-teas-actn-pm-telemetry-autonomics]. 1004 | 1005 VN | 1006 Service | 1007 Model | 1008 +----------------------|--------------------------+ 1009 | Orchestrator | | 1010 | +--------V--------+ | 1011 | | Service Mapping | | 1012 | +-----------------+ | 1013 +----------------------+--------------------^-----+ 1014 TE | Telemetry | 1015 Tunnel | Model | 1016 Model | | 1017 +----------------------V--------------------+-----+ 1018 | Controller | 1019 | | 1020 +-------------------------------------------------+ 1022 +-----+ +-----+ +-----+ +-----+ 1023 | CE1 +------+ PE1 | | PE2 +------+ CE2 | 1024 +-----+ +-----+ +-----+ +-----+ 1026 Figure 7: A VN Service Delivery Example 1028 5.3. Event-based Telemetry in the Device Self Management 1030 In reference to Figure 8, the following steps are performed to 1031 monitor state changes of managed resources in a network device and 1032 provide device self-management within the network management 1033 automation architecture defined in Section 4: 1035 1. To control which state a network device should be in or is 1036 allowed to be in at any given time, a set of conditions and 1037 actions are defined and correlated with network events (e.g., 1038 allow the NETCONF server to send updates only when the value 1039 exceeds a certain threshold for the first time, but not again 1040 until the threshold is cleared), which constitute an 1041 Event/Condition/Action (ECA) policy or an event-driven policy 1042 control logic that can be executed on the device (e.g., 1043 [I-D.wwx-netmod-event-yang]). 1045 2. To provide rapid autonomic response that can exhibit self- 1046 management properties, the Controller pushes the ECA policy to 1047 the network device and delegates the network control logic to the 1048 network device. 1050 3. The network device uses the ECA model to subscribe to the event 1051 source, e.g., an event stream or datastore state data conveyed to 1052 the server via YANG Push subscription [RFC8641], monitors state 1053 parameters, and takes simple and instant actions when an 1054 associated event condition on state parameters is met. ECA 1055 notifications can be generated as the result of actions based on 1056 event stream subscription or datastore subscription (model-driven 1057 telemetry operation discussed in Section 4.2.3). 1059 +----------------+ 1060 | <----+ 1061 | Controller | | 1062 +-------+--------+ | 1063 | | 1064 | | 1065 ECA | | ECA 1066 Model | | Notification 1067 | | 1068 | | 1069 +------------V-------------+-----+ 1070 |Device | | 1071 | +-------+ +---------+ +--+---+ | 1072 | | Event +-> Event +->Event | | 1073 | | Source| |Condition| |Action| | 1074 | +-------+ +---------+ +------+ | 1075 +--------------------------------+ 1077 Figure 8: Event-based Telemetry 1079 6. Security Considerations 1081 Many of the YANG modules cited in this document define schema for 1082 data that are designed to be accessed via network management 1083 protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The 1084 lowest NETCONF layer is the secure transport layer, and the 1085 mandatory-to-implement secure transport is Secure Shell (SSH) 1087 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 1088 implement secure transport is TLS [RFC8446]. 1090 The NETCONF access control model [RFC8341] provides the means to 1091 restrict access for particular NETCONF or RESTCONF users to a 1092 preconfigured subset of all available NETCONF or RESTCONF protocol 1093 operations and content. 1095 Security considerations specific to each of the technologies and 1096 protocols listed in the document are discussed in the specification 1097 documents of each of these protocols. 1099 In order to prevent leaking sensitive information and the "confused 1100 deputy" problem [Hardy] in general, special care should be considered 1101 when translating between the various layers in Section 4 or when 1102 aggregating data retrieved from various sources. Authorization and 1103 authentication checks should be performed to ensure that a data is 1104 available to an authorized entity. The network operator must enforce 1105 means to protect privacy-related information included in customer- 1106 facing models. 1108 To detect misalignment between layers that might be induced by 1109 misbehaving nodes, upper layers should continuously monitor the 1110 perceived service (Section 4.1.4) and should proceed with checks to 1111 assess that the provided service complies with the expected service 1112 and that the data reported by an underlying layer is matching the 1113 perceived service by the above layer. Such checks are the 1114 responsibility of the service diagnosis (Section 4.1.5). 1116 When a YANG module includes security-related parameters, it is 1117 recommended to include the relevant information as part of the 1118 service assurance to track the correct functioning of the security 1119 mechanisms. 1121 Additional considerations are discussed in the following subsections. 1123 6.1. Service Level 1125 A provider may rely on services offered by other providers to build 1126 composite services. Appropriate mechanisms should be enabled by the 1127 provider to monitor and detect a service disruption from these 1128 providers. The characterization of a service disruption (including, 1129 mean time between failures, mean time to repair), the escalation 1130 procedure, and penalties are usually documented in contractual 1131 agreements (e.g., as described in Section 2.1 of [RFC4176]). 1132 Misbehaving peer providers will thus be identified and appropriate 1133 countermeasures will be applied. 1135 The communication protocols that make use of a service model between 1136 a customer and an operator are out of scope. Relevant security 1137 considerations should be discussed in the specification documents of 1138 these protocols. 1140 6.2. Network Level 1142 Security considerations specific to the network level are listed 1143 below: 1145 o A controller may create forwarding loops by mis-configuring the 1146 underlying network nodes. It is recommended to proceed with tests 1147 to check the status of forwarding paths regularly or whenever 1148 changes are made to routing or forwarding processes. Such checks 1149 may be triggered from the service level owing to the means 1150 discussed in Section 4.1.5. 1152 o Some service models may include a traffic isolation clause that is 1153 passed down to the network level so that appropriate technology- 1154 specific actions must be enforced at the underlying network (and 1155 thus involved network devices) to avoid that such traffic is 1156 accessible to non-authorized parties. In particular, network 1157 models may indicate whether encryption is enabled and if so, 1158 expose a list of supported encryption schemes and parameters. 1159 Refer for example to the encryption feature defined in 1160 [I-D.ietf-opsawg-vpn-common] and its use in 1161 [I-D.ietf-opsawg-l3sm-l3nm]. 1163 6.3. Device Level 1165 Network operators should monitor and audit their networks to detect 1166 misbehaving nodes and abnormal behaviors. For example, OAM discussed 1167 in Section 4.1.5 can be used for that purpose. 1169 Access to some data requires specific access privilege levels. 1170 Devices must check that a required access privilege is provided 1171 before granting access to specific data or performing specific 1172 actions. 1174 7. IANA Considerations 1176 There are no IANA requests or assignments included in this document. 1178 8. Acknowledgements 1180 Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter, 1181 Adrian Farrel, Christian Huitema, Tommy Pauly, Ines Robles, and 1182 Olivier Augizeau for the review. 1184 Many thanks to Robert Wilton for the detailed AD review. 1186 Thanks to Eric Vyncke, Roman Danyliw, Erik Kline, and Benjamin Kaduk 1187 for the IESG review. 1189 9. Contributors 1191 Christian Jacquenet 1192 Orange 1193 Rennes, 35000 1194 France 1195 Email: Christian.jacquenet@orange.com 1197 Luis Miguel Contreras Murillo 1198 Telifonica 1200 Email: luismiguel.contrerasmurillo@telefonica.com 1202 Oscar Gonzalez de Dios 1203 Telefonica 1204 Madrid 1205 ES 1207 Email: oscar.gonzalezdedios@telefonica.com 1209 Weiqiang Cheng 1210 China Mobile 1212 Email: chengweiqiang@chinamobile.com 1214 Young Lee 1215 Sung Kyun Kwan University 1217 Email: younglee.tx@gmail.com 1219 10. References 1221 10.1. Normative References 1223 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1224 and A. Bierman, Ed., "Network Configuration Protocol 1225 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1226 . 1228 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1229 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1230 . 1232 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1233 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1234 . 1236 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1237 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1238 . 1240 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1241 Access Control Model", STD 91, RFC 8341, 1242 DOI 10.17487/RFC8341, March 2018, 1243 . 1245 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1246 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1247 . 1249 10.2. Informative References 1251 [Hardy] Hardy, N., "The Confused Deputy: (or why capabilities 1252 might have been invented)", October 1988, 1253 . 1255 [I-D.clacla-netmod-model-catalog] 1256 Clarke, J. and B. Claise, "YANG module for 1257 yangcatalog.org", draft-clacla-netmod-model-catalog-03 1258 (work in progress), April 2018. 1260 [I-D.ietf-bess-evpn-yang] 1261 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 1262 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 1263 bess-evpn-yang-07 (work in progress), March 2019. 1265 [I-D.ietf-bess-l2vpn-yang] 1266 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1267 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1268 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 1269 July 2019. 1271 [I-D.ietf-bess-l3vpn-yang] 1272 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 1273 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 1274 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 1275 in progress), October 2018. 1277 [I-D.ietf-bess-mvpn-yang] 1278 Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and 1279 M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP 1280 IP VPNs", draft-ietf-bess-mvpn-yang-04 (work in progress), 1281 June 2020. 1283 [I-D.ietf-bfd-yang] 1284 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 1285 and G. Mirsky, "YANG Data Model for Bidirectional 1286 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 1287 in progress), August 2018. 1289 [I-D.ietf-dots-rfc8782-bis] 1290 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 1291 Denial-of-Service Open Threat Signaling (DOTS) Signal 1292 Channel Specification", draft-ietf-dots-rfc8782-bis-01 1293 (work in progress), September 2020. 1295 [I-D.ietf-i2rs-yang-l2-network-topology] 1296 Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A 1297 YANG Data Model for Layer 2 Network Topologies", draft- 1298 ietf-i2rs-yang-l2-network-topology-18 (work in progress), 1299 September 2020. 1301 [I-D.ietf-idr-bgp-model] 1302 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1303 YANG Model for Service Provider Networks", draft-ietf-idr- 1304 bgp-model-09 (work in progress), June 2020. 1306 [I-D.ietf-ippm-capacity-metric-method] 1307 Morton, A., Geib, R., and L. Ciavattone, "Metrics and 1308 Methods for One-way IP Capacity", draft-ietf-ippm- 1309 capacity-metric-method-04 (work in progress), September 1310 2020. 1312 [I-D.ietf-ippm-stamp-yang] 1313 Mirsky, G., Min, X., and W. Luo, "Simple Two-way Active 1314 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 1315 stamp-yang-06 (work in progress), October 2020. 1317 [I-D.ietf-ippm-twamp-yang] 1318 Civil, R., Morton, A., Rahman, R., Jethanandani, M., and 1319 K. Pentikousis, "Two-Way Active Measurement Protocol 1320 (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work 1321 in progress), July 2018. 1323 [I-D.ietf-mpls-base-yang] 1324 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 1325 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 1326 yang-15 (work in progress), August 2020. 1328 [I-D.ietf-netmod-module-tags] 1329 Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module 1330 Tags", draft-ietf-netmod-module-tags-10 (work in 1331 progress), February 2020. 1333 [I-D.ietf-opsawg-l2nm] 1334 barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil, 1335 L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- 1336 ietf-opsawg-l2nm-00 (work in progress), July 2020. 1338 [I-D.ietf-opsawg-l3sm-l3nm] 1339 barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. 1340 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 1341 opsawg-l3sm-l3nm-04 (work in progress), October 2020. 1343 [I-D.ietf-opsawg-vpn-common] 1344 barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer 1345 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- 1346 common-01 (work in progress), September 2020. 1348 [I-D.ietf-pim-igmp-mld-snooping-yang] 1349 Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, 1350 "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- 1351 pim-igmp-mld-snooping-yang-18 (work in progress), August 1352 2020. 1354 [I-D.ietf-pim-yang] 1355 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1356 Y., and f. hu, "A YANG Data Model for Protocol Independent 1357 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1358 progress), May 2018. 1360 [I-D.ietf-rtgwg-policy-model] 1361 Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data 1362 Model for Routing Policy Management", draft-ietf-rtgwg- 1363 policy-model-26 (work in progress), October 2020. 1365 [I-D.ietf-rtgwg-qos-model] 1366 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 1367 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 1368 model-02 (work in progress), July 2020. 1370 [I-D.ietf-spring-sr-yang] 1371 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 1372 Tantsura, "YANG Data Model for Segment Routing", draft- 1373 ietf-spring-sr-yang-22 (work in progress), August 2020. 1375 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 1376 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 1377 and D. Ceccarelli, "YANG models for VN/TE Performance 1378 Monitoring Telemetry and Scaling Intent Autonomics", 1379 draft-ietf-teas-actn-pm-telemetry-autonomics-03 (work in 1380 progress), July 2020. 1382 [I-D.ietf-teas-actn-vn-yang] 1383 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1384 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1385 teas-actn-vn-yang-09 (work in progress), July 2020. 1387 [I-D.ietf-teas-yang-path-computation] 1388 Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, 1389 "Yang model for requesting Path Computation", draft-ietf- 1390 teas-yang-path-computation-10 (work in progress), July 1391 2020. 1393 [I-D.ietf-teas-yang-rsvp-te] 1394 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 1395 and H. Shah, "A YANG Data Model for RSVP-TE Protocol", 1396 draft-ietf-teas-yang-rsvp-te-08 (work in progress), March 1397 2020. 1399 [I-D.ietf-teas-yang-te] 1400 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1401 "A YANG Data Model for Traffic Engineering Tunnels, Label 1402 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 1403 (work in progress), July 2020. 1405 [I-D.ietf-trill-yang-oam] 1406 Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., 1407 and H. Weiguo, "YANG Data Model for TRILL Operations, 1408 Administration, and Maintenance (OAM)", draft-ietf-trill- 1409 yang-oam-05 (work in progress), March 2017. 1411 [I-D.ogondio-opsawg-uni-topology] 1412 Dios, O., barguil, s., WU, Q., and M. Boucadair, "A YANG 1413 Model for User-Network Interface (UNI) Topologies", draft- 1414 ogondio-opsawg-uni-topology-01 (work in progress), April 1415 2020. 1417 [I-D.www-opsawg-yang-vpn-service-pm] 1418 Bo, W., WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., 1419 and H. Xu, "A YANG Model for Network and VPN Service 1420 Performance Monitoring", draft-www-opsawg-yang-vpn- 1421 service-pm-01 (work in progress), July 2020. 1423 [I-D.wwx-netmod-event-yang] 1424 Bierman, A., WU, Q., Bryskin, I., Birkholz, H., Liu, X., 1425 and B. Claise, "A YANG Data model for ECA Policy 1426 Management", draft-wwx-netmod-event-yang-09 (work in 1427 progress), July 2020. 1429 [IPPM] IANA, "Performance Metrics", March 2020, 1430 . 1433 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 1434 and A. Gonguet, "Framework for Layer 3 Virtual Private 1435 Networks (L3VPN) Operations and Management", RFC 4176, 1436 DOI 10.17487/RFC4176, October 2005, 1437 . 1439 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1440 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1441 2006, . 1443 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1444 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1445 DOI 10.17487/RFC4664, September 2006, 1446 . 1448 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1449 LAN Service (VPLS) Using BGP for Auto-Discovery and 1450 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1451 . 1453 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1454 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1455 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1456 . 1458 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 1459 RFC 5136, DOI 10.17487/RFC5136, February 2008, 1460 . 1462 [RFC5486] Malas, D., Ed. and D. Meyer, Ed., "Session Peering for 1463 Multimedia Interconnect (SPEERMINT) Terminology", 1464 RFC 5486, DOI 10.17487/RFC5486, March 2009, 1465 . 1467 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1468 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1469 . 1471 [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for 1472 Multimedia INTerconnect (SPEERMINT) Architecture", 1473 RFC 6406, DOI 10.17487/RFC6406, November 2011, 1474 . 1476 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1477 Networking: A Perspective from within a Service Provider 1478 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1479 . 1481 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1482 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1483 . 1485 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1486 Weingarten, "An Overview of Operations, Administration, 1487 and Maintenance (OAM) Tools", RFC 7276, 1488 DOI 10.17487/RFC7276, June 2014, 1489 . 1491 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1492 Connectivity Provisioning Profile (CPP)", RFC 7297, 1493 DOI 10.17487/RFC7297, July 2014, 1494 . 1496 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1497 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1498 2014, . 1500 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 1501 3rd, D., Aldrin, S., and Y. Li, "Transparent 1502 Interconnection of Lots of Links (TRILL): Fault 1503 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 1504 . 1506 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1507 Chaining (SFC) Architecture", RFC 7665, 1508 DOI 10.17487/RFC7665, October 2015, 1509 . 1511 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1512 Ed., "A One-Way Delay Metric for IP Performance Metrics 1513 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1514 2016, . 1516 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1517 Ed., "A One-Way Loss Metric for IP Performance Metrics 1518 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1519 2016, . 1521 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 1522 Maintenance Using the Label Distribution Protocol (LDP)", 1523 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 1524 . 1526 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1527 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1528 August 2017, . 1530 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1531 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1532 2017, . 1534 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1535 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1536 DOI 10.17487/RFC8299, January 2018, 1537 . 1539 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1540 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1541 . 1543 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1544 and R. Wilton, "Network Management Datastore Architecture 1545 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1546 . 1548 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1549 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1550 . 1552 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1553 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1554 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1555 2018, . 1557 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1558 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1559 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1560 March 2018, . 1562 [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 1563 YANG Data Model for Hardware Management", RFC 8348, 1564 DOI 10.17487/RFC8348, March 2018, 1565 . 1567 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1568 Routing Management (NMDA Version)", RFC 8349, 1569 DOI 10.17487/RFC8349, March 2018, 1570 . 1572 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1573 Data Model for Layer 2 Virtual Private Network (L2VPN) 1574 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1575 2018, . 1577 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1578 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1579 Address Translation (NAT) and Network Prefix Translation 1580 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1581 . 1583 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1584 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1585 DOI 10.17487/RFC8513, January 2019, 1586 . 1588 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1589 "YANG Data Model for Network Access Control Lists (ACLs)", 1590 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1591 . 1593 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 1594 and R. Wilton, "YANG Library", RFC 8525, 1595 DOI 10.17487/RFC8525, March 2019, 1596 . 1598 [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", 1599 RFC 8528, DOI 10.17487/RFC8528, March 2019, 1600 . 1602 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1603 Liu, "YANG Data Model for Network Instances", RFC 8529, 1604 DOI 10.17487/RFC8529, March 2019, 1605 . 1607 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1608 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1609 DOI 10.17487/RFC8530, March 2019, 1610 . 1612 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1613 for Connection-Oriented Operations, Administration, and 1614 Maintenance (OAM) Protocols", RFC 8531, 1615 DOI 10.17487/RFC8531, April 2019, 1616 . 1618 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1619 Raghavan, "Generic YANG Data Model for the Management of 1620 Operations, Administration, and Maintenance (OAM) 1621 Protocols That Use Connectionless Communications", 1622 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1623 . 1625 [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. 1626 Raghavan, "A YANG Data Model for Retrieval Methods for the 1627 Management of Operations, Administration, and Maintenance 1628 (OAM) Protocols That Use Connectionless Communications", 1629 RFC 8533, DOI 10.17487/RFC8533, April 2019, 1630 . 1632 [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm 1633 Management", RFC 8632, DOI 10.17487/RFC8632, September 1634 2019, . 1636 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1637 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1638 September 2019, . 1640 [RFC8652] Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 1641 Peter, "A YANG Data Model for the Internet Group 1642 Management Protocol (IGMP) and Multicast Listener 1643 Discovery (MLD)", RFC 8652, DOI 10.17487/RFC8652, November 1644 2019, . 1646 [RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data 1647 Model for Tunnel Interface Types", RFC 8675, 1648 DOI 10.17487/RFC8675, November 2019, 1649 . 1651 [RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for 1652 IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, 1653 DOI 10.17487/RFC8676, November 2019, 1654 . 1656 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 1657 Denial-of-Service Open Threat Signaling (DOTS) Data 1658 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 1659 May 2020, . 1661 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 1662 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1663 June 2020, . 1665 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1666 O. Gonzalez de Dios, "YANG Data Model for Traffic 1667 Engineering (TE) Topologies", RFC 8795, 1668 DOI 10.17487/RFC8795, August 2020, 1669 . 1671 Appendix A. Layered YANG Modules Examples Overview 1673 This appendix lists a set of YANG data models that can be used for 1674 the delivery of connectivity services. These models can be 1675 classified as service, network, or device models. 1677 It is not the intent of this appendix to provide an inventory of 1678 tools and mechanisms used in specific network and service management 1679 domains; such inventory can be found in documents such as [RFC7276]. 1681 The reader may refer to the YANG Catalog 1682 () or the public Github YANG repository 1683 () to query existing YANG models. 1684 The YANG Catalog includes some metadata to indicate the module type 1685 ('module-classification') [I-D.clacla-netmod-model-catalog]. Note 1686 that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to 1687 associate tags with YANG modules in order to help classifying the 1688 modules. 1690 A.1. Service Models: Definition and Samples 1692 As described in [RFC8309], the service is "some form of connectivity 1693 between customer sites and the Internet and/or between customer sites 1694 across the network operator's network and across the Internet". More 1695 concretely, an IP connectivity service can be defined as the IP 1696 transfer capability characterized by a (Source Nets, Destination 1697 Nets, Guarantees, Scope) tuple where "Source Nets" is a group of 1698 unicast IP addresses, "Destination Nets" is a group of IP unicast 1699 and/or multicast addresses, and "Guarantees" reflects the guarantees 1700 (expressed in terms of QoS, performance, and availability, for 1701 example) to properly forward traffic to the said "Destination" 1702 [RFC7297]. 1704 For example: 1706 o The L3SM [RFC8299] defines the L3VPN service ordered by a customer 1707 from a network operator. 1709 o The L2SM [RFC8466] defines the L2VPN service ordered by a customer 1710 from a network operator. 1712 o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang] 1713 provides a YANG data model applicable to any mode of VN operation. 1715 L2SM and L3SM are customer service models as per [RFC8309]. 1717 A.2. Schema Mount 1719 Modularity and extensibility were among the leading design principles 1720 of the YANG data modeling language. As a result, the same YANG 1721 module can be combined with various sets of other modules and thus 1722 form a data model that is tailored to meet the requirements of a 1723 specific use case. [RFC8528] defines a mechanism, denoted schema 1724 mount, that allows for mounting one data model consisting of any 1725 number of YANG modules at a specified location of another (parent) 1726 schema. 1728 A.3. Network Models: Samples 1730 L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are 1731 examples of YANG network models. 1733 Figure 9 depicts a set of additional network models such as topology 1734 and tunnel models: 1736 +-------------------------------+-------------------------------+ 1737 | Topology YANG modules | Tunnel YANG modules | 1738 +-------------------------------+-------------------------------+ 1739 | +------------------+ | | 1740 | |Network Topologies| | +------+ +-----------+ | 1741 | | Model | | |Other | | TE Tunnel | | 1742 | +--------+---------+ | |Tunnel| +----+------+ | 1743 | | +---------+ | +------+ | | 1744 | +---+Service | | +----------+---------+ | 1745 | | |Topology | | | | | | 1746 | | +---------+ | | | | | 1747 | | +---------+ |+----+---+ +----+---+ +---+---+| 1748 | +---+Layer 3 | ||MPLS-TE | |RSVP-TE | | SR-TE || 1749 | | |Topology | || Tunnel | | Tunnel | |Tunnel || 1750 | | +---------+ |+--------+ +--------+ +-------+| 1751 | | +---------+ | | 1752 | +---+TE | | | 1753 | | |Topology | | | 1754 | | +---------+ | | 1755 | | +---------+ | | 1756 | +---+Layer 3 | | | 1757 | |Topology | | | 1758 | +---------+ | | 1759 +-------------------------------+-------------------------------+ 1761 Figure 9: Sample Resource Facing Network Models 1763 Examples of topology YANG modules are listed below: 1765 o Network Topologies Model: [RFC8345] defines a base model for 1766 network topology and inventories. Network topology data include 1767 link, node, and terminate-point resources. 1769 o TE Topology Model: [RFC8795] defines a YANG data model for 1770 representing and manipulating TE topologies. 1772 This module is extended from network topology model defined in 1773 [RFC8345] with TE topologies related content. This model contains 1774 technology-agnostic TE Topology building blocks that can be 1775 augmented and used by other technology-specific TE topology 1776 models. 1778 o Layer 3 Topology Model: 1780 [RFC8346] defines a YANG data model for representing and 1781 manipulating Layer 3 topologies. This model is extended from the 1782 network topology model defined in [RFC8345] with Layer 3 1783 topologies specifics. 1785 o Layer 2 Topology Model: 1787 [I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model 1788 for representing and manipulating Layer 2 topologies. This model 1789 is extended from the network topology model defined in [RFC8345] 1790 with Layer 2 topology specifics. 1792 Examples of tunnel YANG modules are provided below: 1794 o Tunnel identities: [RFC8675] defines a collection of YANG 1795 identities used as interface types for tunnel interfaces. 1797 o TE Tunnel Model: 1799 [I-D.ietf-teas-yang-te] defines a YANG module for the 1800 configuration and management of TE interfaces, tunnels, and LSPs. 1802 o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model: 1804 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1805 model(s) and defines a YANG module for SR-TE specific data. 1807 o MPLS-TE Model: 1809 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1810 model(s) and defines a YANG module for MPLS-TE configurations, 1811 state, RPC and notifications. 1813 o RSVP-TE MPLS Model: 1815 [I-D.ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 1816 with parameters to configure and manage signaling of MPLS RSVP-TE 1817 LSPs. 1819 Other sample network models are listed hereafter: 1821 o Path Computation API Model: 1823 [I-D.ietf-teas-yang-path-computation] YANG module for a stateless 1824 RPC which complements the stateful solution defined in 1825 [I-D.ietf-teas-yang-te]. 1827 o OAM Models (including Fault Management (FM) and Performance 1828 Monitoring): 1830 [RFC8532] defines a base YANG module for the management of OAM 1831 protocols that use Connectionless Communications. [RFC8533] 1832 defines a retrieval method YANG module for connectionless OAM 1833 protocols. [RFC8531] defines a base YANG module for connection 1834 oriented OAM protocols. These three models are intended to 1835 provide consistent reporting, configuration, and representation 1836 for connection-less OAM and Connection oriented OAM separately. 1838 Alarm monitoring is a fundamental part of monitoring the network. 1839 Raw alarms from devices do not always tell the status of the 1840 network services or necessarily point to the root cause. 1841 [RFC8632] defines a YANG module for alarm management. 1843 A.4. Device Models: Samples 1845 Network Element models (listed in Figure 10) are used to describe how 1846 a service can be implemented by activating and tweaking a set of 1847 functions (enabled in one or multiple devices, or hosted in cloud 1848 infrastructures) that are involved in the service delivery. For 1849 example, the L3VPN service will involve many PEs and require 1850 manipulating the following modules: 1852 o Routing management [RFC8349] 1854 o BGP [I-D.ietf-idr-bgp-model] 1856 o PIM [I-D.ietf-pim-yang] 1858 o NAT management [RFC8512] 1860 o QoS management [I-D.ietf-rtgwg-qos-model] 1862 o ACLs [RFC8519] 1864 Figure 10 uses IETF-defined data models as an example. 1866 +------------------------+ 1867 +-+ Device Model | 1868 | +------------------------+ 1869 | +------------------------+ 1870 +---------------+ | | Logical Network | 1871 | | +-+ Element Model | 1872 | Architecture | | +------------------------+ 1873 | | | +------------------------+ 1874 +-------+-------+ +-+ Network Instance Model | 1875 | | +------------------------+ 1876 | | +------------------------+ 1877 | +-+ Routing Type Model | 1878 | +------------------------+ 1879 +-------+----------+----+------+------------+-----------+------+ 1880 | | | | | | | 1881 +-+-+ +---+---+ +----+----+ +--+--+ +----+----+ +--+--+ | 1882 |ACL| |Routing| |Transport| | OAM | |Multicast| | PM | Others 1883 +---+ +-+-----+ +----+----+ +--+--+ +-----+---+ +--+--+ 1884 | +-------+ | +------+ | +--------+ | +-----+ | +-----+ 1885 +-+Core | +-+ MPLS | +-+ BFD | +-+IGMP | +-+TWAMP| 1886 | |Routing| | | Base | | +--------+ | |/MLD | | +-----+ 1887 | +-------+ | +------+ | +--------+ | +-----+ | +-----+ 1888 | +-------+ | +------+ +-+LSP Ping| | +-----+ +-+OWAMP| 1889 +-+ BGP | +-+ MPLS | | +--------+ +-+ PIM | | +-----+ 1890 | +-------+ | | LDP | | +--------+ | +-----+ | +-----+ 1891 | +-------+ | +------+ +-+MPLS-TP | | +-----+ +-+LMAP | 1892 +-+ ISIS | | +------+ +--------+ +-+ MVPN| +-----+ 1893 | +-------+ +-+ MPLS | +-----+ 1894 | +-------+ |Static| 1895 +-+ OSPF | +------+ 1896 | +-------+ 1897 | +-------+ 1898 +-+ RIP | 1899 | +-------+ 1900 | +-------+ 1901 +-+ VRRP | 1902 | +-------+ 1903 | +-------+ 1904 +-+SR/SRv6| 1905 | +-------+ 1906 | +-------+ 1907 +-+ISIS-SR| 1908 | +-------+ 1909 | +-------+ 1910 +-+OSPF-SR| 1911 +-------+ 1913 Figure 10: Network Element Modules Overview 1915 A.4.1. Model Composition 1917 o Logical Network Element Model 1919 [RFC8530] defines a logical network element module which can be 1920 used to manage the logical resource partitioning that may be 1921 present on a network device. Examples of common industry terms 1922 for logical resource partitioning are Logical Systems or Logical 1923 Routers. 1925 o Network Instance Model 1927 [RFC8529] defines a network instance module. This module can be 1928 used to manage the virtual resource partitioning that may be 1929 present on a network device. Examples of common industry terms 1930 for virtual resource partitioning are VRF instances and Virtual 1931 Switch Instances (VSIs). 1933 A.4.2. Device Management 1935 The following list enumerates some YANG modules that can be used for 1936 device management: 1938 o [RFC8348]: defines a YANG module for the management of hardware. 1940 o [RFC7317]: defines the "ietf-system" YANG module that provides 1941 many features such as the configuration and the monitoring of 1942 system or system control operations (e.g., shutdown, restart, 1943 setting time) identification. 1945 o [RFC8341]: defines a network configuration access control YANG 1946 module. 1948 A.4.3. Interface Management 1950 The following provides some YANG modules that can be used for 1951 interface management: 1953 o [RFC7224]: defines a YANG module for interface type definitions. 1955 o [RFC8343]: defines a YANG module for the management of network 1956 interfaces. 1958 A.4.4. Some Device Model Examples 1960 The following provides an overview of some device models that can be 1961 used within a network. This list is not comprehensive. 1963 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS 1964 based Layer 2 VPN services (L2VPN) [RFC4664] and includes 1965 switching between the local attachment circuits. The 1966 L2VPN model covers point-to-point VPWS and Multipoint VPLS 1967 services. These services use signaling of Pseudowires 1968 across MPLS networks using LDP [RFC8077][RFC4762] or BGP 1969 [RFC4761]. 1971 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for 1972 Ethernet VPN services. The model is agnostic of the 1973 underlay. It applies to MPLS as well as to VxLAN 1974 encapsulation. The module is also agnostic to the 1975 services, including E-LAN, E-LINE, and E-TREE services. 1977 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can 1978 be used to configure and manage BGP L3VPNs [RFC4364]. It 1979 contains VRF specific parameters as well as BGP specific 1980 parameters applicable for L3VPNs. 1982 Core Routing: [RFC8349] defines the core routing YANG data model, 1983 which is intended as a basis for future data model 1984 development covering more-sophisticated routing systems. 1985 It is expected that other Routing technology YANG modules 1986 (e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core 1987 Routing base YANG module. 1989 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 1990 which serves as a base framework for configuring and 1991 managing an MPLS switching subsystem. It is expected that 1992 other MPLS technology YANG modules (e.g., MPLS LSP Static, 1993 LDP, or RSVP-TE models) will augment the MPLS base YANG 1994 module. 1996 BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for 1997 configuring and managing BGP, including protocol, policy, 1998 and operational aspects based on data center, carrier, and 1999 content provider operational requirements. 2001 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module 2002 for configuring and managing routing policies based on 2003 operational practice. The module provides a generic 2004 policy framework which can be augmented with protocol- 2005 specific policy configuration. 2007 SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment 2008 routing configuration and operation. 2010 BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a 2011 network protocol which is used for liveness detection of 2012 arbitrary paths between systems. [I-D.ietf-bfd-yang] 2013 defines a YANG module that can be used to configure and 2014 manage BFD. 2016 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 2017 to configure and manage Protocol Independent Multicast 2018 (PIM) devices. 2020 [RFC8652] defines a YANG module that can be used to 2021 configure and manage Internet Group Management Protocol 2022 (IGMP) and Multicast Listener Discovery (MLD) devices. 2024 [I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG 2025 module that can be used to configure and manage Internet 2026 Group Management Protocol (IGMP) and Multicast Listener 2027 Discovery (MLD) Snooping devices. 2029 [I-D.ietf-bess-mvpn-yang] defines a YANG data model to 2030 configure and manage Multicast in MPLS/BGP IP VPNs 2031 (MVPNs). 2033 PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for 2034 client and server implementations of the Two-Way Active 2035 Measurement Protocol (TWAMP). 2037 [I-D.ietf-ippm-stamp-yang] defines the data model for 2038 implementations of Session-Sender and Session-Reflector 2039 for Simple Two-way Active Measurement Protocol (STAMP) 2040 mode using YANG. 2042 [RFC8194] defines a YANG data model for Large-Scale 2043 Measurement Platforms (LMAPs). 2045 ACL: Access Control List (ACL) is one of the basic elements 2046 used to configure device forwarding behavior. It is used 2047 in many networking technologies such as Policy Based 2048 Routing, firewalls, etc. [RFC8519] describes a YANG data 2049 model of ACL basic building blocks. 2051 QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of 2052 Differentiated Services for configuration and operations. 2054 NAT: For the sake of network automation and the need for 2055 programming Network Address Translation (NAT) function in 2056 particular, a YANG data model for configuring and managing 2057 the NAT is essential. 2059 [RFC8512] defines a YANG module for the NAT function 2060 covering a variety of NAT flavors such as Network Address 2061 Translation from IPv4 to IPv4 (NAT44), Network Address and 2062 Protocol Translation from IPv6 Clients to IPv4 Servers 2063 (NAT64), customer-side translator (CLAT), Stateless IP/ 2064 ICMP Translation (SIIT), Explicit Address Mappings (EAM) 2065 for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), 2066 and Destination NAT. 2068 [RFC8513] specifies a DS-Lite YANG module. 2070 Stateless Address Sharing: [RFC8676] specifies a YANG module for A+P 2071 address sharing, including Lightweight 4over6, Mapping of 2072 Address and Port with Encapsulation (MAP-E), and Mapping 2073 of Address and Port using Translation (MAP-T) softwire 2074 mechanisms. 2076 Authors' Addresses 2078 Qin Wu (editor) 2079 Huawei 2080 101 Software Avenue, Yuhua District 2081 Nanjing, Jiangsu 210012 2082 China 2084 Email: bill.wu@huawei.com 2086 Mohamed Boucadair (editor) 2087 Orange 2088 Rennes 35000 2089 France 2091 Email: mohamed.boucadair@orange.com 2093 Diego R. Lopez 2094 Telefonica I+D 2095 Spain 2097 Email: diego.r.lopez@telefonica.com 2098 Chongfeng Xie 2099 China Telecom 2100 Beijing 2101 China 2103 Email: xiechf@chinatelecom.cn 2105 Liang Geng 2106 China Mobile 2108 Email: gengliang@chinamobile.com