idnits 2.17.1 draft-ietf-opsawg-model-automation-framework-07.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 11, 2020) is 1293 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 (-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 (-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: April 14, 2021 Orange 6 D. Lopez 7 Telefonica I+D 8 C. Xie 9 China Telecom 10 L. Geng 11 China Mobile 12 October 11, 2020 14 A Framework for Automating Service and Network Management with YANG 15 draft-ietf-opsawg-model-automation-framework-07 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 model; 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 April 14, 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 . . . . . . . . 11 77 3.3. Service Fullfillment Automation . . . . . . . . . . . . . 12 78 3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 12 79 4. Functional Blocks and Interactions . . . . . . . . . . . . . 13 80 4.1. Service Lifecycle Management Procedure . . . . . . . . . 13 81 4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 14 82 4.1.2. Service Creation/Modification . . . . . . . . . . . . 14 83 4.1.3. Service Assurance . . . . . . . . . . . . . . . . . . 15 84 4.1.4. Service Optimization . . . . . . . . . . . . . . . . 15 85 4.1.5. Service Diagnosis . . . . . . . . . . . . . . . . . . 15 86 4.1.6. Service Decommission . . . . . . . . . . . . . . . . 16 87 4.2. Service Fullfillment Management Procedure . . . . . . . . 16 88 4.2.1. Intended Configuration Provision . . . . . . . . . . 16 89 4.2.2. Configuration Validation . . . . . . . . . . . . . . 17 90 4.2.3. Performance Monitoring/Model-driven Telemetry . . . . 17 91 4.2.4. Fault Diagnostic . . . . . . . . . . . . . . . . . . 17 92 4.3. Multi-Layer/Multi-Domain Service Mapping . . . . . . . . 18 93 4.4. Service Decomposing . . . . . . . . . . . . . . . . . . . 18 94 5. YANG Data Model Integration Examples . . . . . . . . . . . . 18 95 5.1. L2VPN/L3VPN Service Delivery . . . . . . . . . . . . . . 18 96 5.2. VN Lifecycle Management . . . . . . . . . . . . . . . . . 21 97 5.3. Event-based Telemetry in the Device Self Management . . . 22 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 99 6.1. Service Level . . . . . . . . . . . . . . . . . . . . . . 24 100 6.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 24 101 6.3. Device Level . . . . . . . . . . . . . . . . . . . . . . 25 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 104 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 107 10.2. Informative References . . . . . . . . . . . . . . . . . 27 108 Appendix A. Layered YANG Modules Examples Overview . . . . . . . 35 109 A.1. Service Models: Definition and Samples . . . . . . . . . 36 110 A.2. Schema Mount . . . . . . . . . . . . . . . . . . . . . . 36 111 A.3. Network Models: Samples . . . . . . . . . . . . . . . . . 37 112 A.4. Device Models: Samples . . . . . . . . . . . . . . . . . 39 113 A.4.1. Model Composition . . . . . . . . . . . . . . . . . . 41 114 A.4.2. Device Management . . . . . . . . . . . . . . . . . . 41 115 A.4.3. Interface Management . . . . . . . . . . . . . . . . 41 116 A.4.4. Some Device Model Examples . . . . . . . . . . . . . 41 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 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's 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 In addition, many of these applications have been developed in-house 130 over the 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 a NETCONF/RESTCONF clients and servers 186 [RFC6241][RFC8040]. Nevertheless, YANG is transport independent data 187 modeling language. It can thus be used independently of NETCONF/ 188 RESTOCNF. For example, YANG can be used to define abstract data 189 structures [RFC8791] that can be manipulated by other protocols 190 (e.g., [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 different layer YANG 195 data models interact with each other (e.g., service mapping, model 196 composing) 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 promoting thus a network-wise provisioning 209 instead of device-specific configuration. 211 o Dynamically fed a decision-making process (e.g., Controllers, 212 Orchestrators) with notifications that will trigger appropriate 213 actions allowing thus to continuously adjust a network (and thus 214 involved resources) to comply the intended service to deliver. 216 This framework is drawn from a network operator perspective 217 irrespective of the origin of a data model; it can also accommodate 218 modules that are developed outside the IETF. The document covers 219 Service Models that are used by an operator to expose its services 220 and capture service requirements from the customers (including other 221 operators). Nevertheless, the document does not elaborate on the 222 communication protocol(s) that makes use of these Service Models in 223 order to request and deliver a service. Such considerations are out 224 of the scope. 226 The document identifies a list of use cases to exemplify the proposed 227 approach (Section 5), but it does not claim nor aim to be exhaustive. 228 Appendix A lists some examples to illustrate the layered YANG modules 229 view. 231 2. Terminology and Acronyms 233 2.1. Terminology 235 The following terms are defined in [RFC8309][RFC8199] and are not 236 redefined here: 238 o Network Operator 239 o Customer 241 o Service 243 o Data Model 245 o Service Model 247 o Network Element Module 249 In addition, the document makes use of the following terms: 251 Network Model: Describes a network level abstraction (or a subset of 252 aspects of a network infrastructure), including devices and their 253 subsystems, and relevant protocols operating at the link and 254 network layers across multiple devices. This model corresponds to 255 the Network Configuration Model discussed in [RFC8309]. 257 It can be used by a network operator to allocate resources (e.g., 258 tunnel resource, topology resource) for the service or schedule 259 resources to meet the service requirements defined in a Service 260 Model. 262 Network Domain: Refers to a network partitioning that is usually 263 followed by network operators to delimit parts of their network. 264 "access network" and "core network" are examples of network 265 domains. 267 Device Model: Refers to the Network Element YANG data model 268 described in [RFC8199] or the Device Configuration Model discussed 269 in [RFC8309]. 271 Device Models are also used to refer to model a function embedded 272 in a device (e.g., Network Address Translation (NAT) [RFC8512], 273 Access Control Lists (ACLs) [RFC8519]). 275 Pipe: Refers to a communication scope where only one-to-one (1:1) 276 communications are allowed. The scope can be identified between 277 ingress and egress nodes, two service sites, etc. 279 Hose: Refers to a communication scope where one-to-many (1:N) 280 communications are allowed (e.g., one site to multiple sites). 282 Funnel: Refers to a communication scope where many-to-one (N:1) 283 communications are allowed. 285 2.2. Acronyms 287 The following acronyms are used in the document: 289 ACL Access Control List 290 AS Autonomous System 291 CE Customer Edge 292 DBE Data Border Element 293 E2E End-to-End 294 ECA Event Condition Action 295 L2VPN Layer 2 Virtual Private Network 296 L3VPN Layer 3 Virtual Private Network 297 L3SM L3VPN Service Model 298 L3NM L3VPN Network Model 299 NAT Network Address Translation 300 OAM Operations, Administration, and Maintenance 301 OWD One-Way Delay 302 PE Provider Edge 303 QoS Quality of Service 304 RD Route Distinguisher 305 RT Route Target 306 SBE Session Border Element 307 SDN Software Defined Networking 308 SP Service Provider 309 TE Traffic Engineering 310 VN Virtual Network 311 VPN Virtual Private Network 312 VRF Virtual Routing and Forwarding 314 3. Architectural Concepts and Goals 316 3.1. Data Models: Layering and Representation 318 As described in Section 2 of [RFC8199], layering of modules allows 319 for better reusability of lower-layer modules by higher-level modules 320 while limiting duplication of features across layers. 322 Data models in the context of network management can be classified 323 into Service, Network, and Device Models. Different Service Models 324 may rely on the same set of Network and/or Device Models. 326 Service Models traditionally follow a top-down approach and are 327 mostly customer-facing YANG modules providing a common model 328 construct for higher level network services (e.g., Layer 3 Virtual 329 Private Network (L3VPN)). Such modules can be mapped to network 330 technology-specific modules at lower layers (e.g., tunnel, routing, 331 Quality of Service (QoS), security). For example, Service Models can 332 be used to characterise the network service(s) to be ensured between 333 service nodes (ingress/egress) such as: 335 o the communication scope (pipe, hose, funnel, ...), 336 o the directionality (inbound/outbound), 337 o the traffic performance guarantees expressed using metrics such as 338 One-Way Delay (OWD) [RFC7679] or One-Way Loss [RFC7680]; a summary 339 of performance metrics maintained by IANA can be found in [IPPM], 340 o link capacity [RFC5136] [I-D.ietf-ippm-capacity-metric-method], 341 o etc. 343 Figure 1 depicts the example of a VoIP service that relies upon 344 connectivity services offered by a network operator. In this 345 example, the VoIP service is offered to the network operator's 346 customers by Service Provider (SP1). In order to provide global VoIP 347 reachability, SP1 service site interconnects with other Service 348 Providers service sites typically by interconnecting Session Border 349 Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406]. 350 For other VoIP destinations, sessions are forwarded over the 351 Internet. These connectivity services can be captured in a YANG 352 Service Model that reflects the service attributes that are shown in 353 Figure 2. This example follows the IP Connectivity Provisioning 354 Profile template defined in [RFC7297]. 356 ,--,--,--. ,--,--,--. 357 ,-' SP1 `-. ,-' SP2 `-. 358 ( Service Site ) ( Service Site ) 359 `-. ,-' `-. ,-' 360 `--'--'--' `--'--'--' 361 x | o * * | 362 (2)x | o * * | 363 ,x-,--o-*-. (1) ,--,*-,--. 364 ,-' x o * * * * * * * * * `-. 365 ( x o +----( Internet ) 366 User---(x x x o o o o o o o o o o o o o o o o o o 367 `-. ,-' `-. ,-' (3) 368 `--'--'--' `--'--'--' 369 Network Operator 371 **** (1) Inter-SP connectivity 372 xxxx (2) Customer to SP connectivity 373 oooo (3) SP to any destination connectivity 375 Figure 1: An Example of Service Connectivty Components 377 Connectivity: Scope and Guarantees 378 (1) Inter-SP connectivity 379 - Pipe scope from the local to the remote SBE/DBE 380 - Full guarantees class 381 (2) Customer to SP connectivity 382 - Hose/Funnel scope connecting the local SBE/DBE 383 to the customer access points 384 - Full guarantees class 385 (3) SP to any destination connectivity 386 - Hose/Funnel scope from the local SBE/DBE to the 387 Internet gateway 388 - Delay guarantees class 389 Flow Identification 390 * Destination IP address (SBE, DBE) 391 * DSCP marking 392 Traffic Isolation 393 * VPN 394 Routing & Forwarding 395 * Routing rule to exclude some ASes from the inter-domain 396 paths 397 Notifications (including feedback) 398 * Statistics on aggregate traffic to adjust capacity 399 * Failures 400 * Planned maintenance operations 401 * Triggered by thresholds 403 Figure 2: Sample Attributes Captured in a Service Model 405 Network Models are mainly network resource-facing modules; they 406 describe various aspects of a network infrastructure, including 407 devices and their subsystems, and relevant protocols operating at the 408 link and network layers across multiple devices (e.g., network 409 topology and traffic-engineering tunnel modules). 411 Device (and function) Models usually follow a bottom-up approach and 412 are mostly technology-specific modules used to realize a service 413 (e.g., BGP, NAT). 415 Each level maintains a view of the supported YANG modules provided by 416 low-levels (see for example, Appendix A). 418 Figure 3 illustrates the overall layering model. The reader may 419 refer to Section 4 of [RFC8309] for an overview of "Orchestrator" and 420 "Controller" elements. All these elements (i.e., Orchestrator(s), 421 Controller(s), device(s)) are under the responsibility of the same 422 operator. 424 +-----------------------------------------------------------------+ 425 | Hierarchy Abstraction | 426 | | 427 | +-----------------------+ Service Model | 428 | | Orchestrator | (Customer Oriented) | 429 | |+---------------------+| Scope: "1:1" Pipe model | 430 | || Service Modeling || | 431 | |+---------------------+| | 432 | | | Bidirectional | 433 | |+---------------------+| +-+ Capacity,OWD +-+ | 434 | ||Service Orchestration|| | +----------------+ | | 435 | |+---------------------+| +-+ +-+ | 436 | +-----------------------+ Ingress Egress | 437 | | 438 | | 439 | +-----------------------+ Network Model | 440 | | Controller | (Operator Oriented) | 441 | |+---------------------+| +-+ +--+ +---+ +-+ | 442 | || Network Modeling || | | | | | | | | | 443 | |+---------------------+| | o----o--o----o---o---o | | 444 | | | +-+ +--+ +---+ +-+ | 445 | |+---------------------+| src dst | 446 | ||Network Orchestration|| L3VPN over TE | 447 | |+---------------------+| Instance Name/Access Interface | 448 | +-----------------------+ Protocol Type/Capacity/RD/RT/... | 449 | | 450 | | 451 | +-----------------------+ Device Model | 452 | | Device | | 453 | |+--------------------+ | | 454 | || Device Modeling | | Interface add, BGP Peer, | 455 | |+--------------------+ | Tunnel ID, QoS/TE, ... | 456 | +-----------------------+ | 457 +-----------------------------------------------------------------+ 459 Figure 3: Layering and Representation Within a Network Operator 461 A composite service offered by a network operator may rely on 462 services from other operators. In such case, the network operator 463 acts as a customer to request services from other networks. The 464 operators providing these services will then follow the layering 465 depicted in Figure 3. The mapping between a composite service and a 466 third-party service is maintained at the orchestration level. From a 467 data plane perspective, appropriate traffic steering policies (e.g., 468 Service Function Chaining [RFC7665]) are managed by the network 469 controllers to guide how/when a third party service is invoked for 470 flows bound to a composite service. 472 The layering model depicted in Figure 3 does not make any assumption 473 about the location of the various entities (e.g., controller, 474 orchestrator) within the network. As such, the architecture does not 475 preclude deployments where, for example, the controller is embedded 476 on a device that hosts other functions that are controlled via YANG 477 modules. 479 In order to ease the mapping between layers and data reuse, this 480 document focuses on Service Models that are modelled using YANG. 481 Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3 482 does not preclude Service Models to be modelled using other data 483 modelling languages than YANG. 485 3.2. Automation of Service Delivery Procedures 487 Service Models can be used by a network operator to expose its 488 services to its customers. Exposing such models allows to automate 489 the activation of service orders and thus the service delivery. One 490 or more monolithic Service Models can be used in the context of a 491 composite service activation request (e.g., delivery of a caching 492 infrastructure over a VPN). Such models are used to feed a decision- 493 making intelligence to adequately accommodate customer's needs. 495 Also, such models may be used jointly with services that require 496 dynamic invocation. An example is provided by the service modules 497 defined by the DOTS WG to dynamically trigger requests to handle 498 Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service 499 filtering request modelled using [RFC8783] will be translated into 500 device-specific filtering (e.g., ACLs defined in [RFC8519]) that to 501 fulfil the service request. 503 Network Models can be derived from Service Models and used to 504 provision, monitor, instantiate the service, and provide lifecycle 505 management of network resources. Doing so is meant to: 507 o expose network resources to customers (including other network 508 operators) to provide service fulfillment and assurance. 510 o allow customers (or network operators) to dynamically adjust the 511 network resources based on service requirements as described in 512 Service Models (e.g., Figure 2) and the current network 513 performance information described in the telemetry modules. 515 Note that it is out of the scope of this document to elaborate on the 516 communication protocols that are used to implement the interface 517 between the service ordering (customer) and service order handling 518 (provider). 520 3.3. Service Fullfillment Automation 522 To operate a service, the settings of the parameters in the Device 523 Models are derived from Service Models and/or Network Models and are 524 used to: 526 o Provision each involved network function/device with the proper 527 configuration information. 529 o Operate the network based on service requirements as described in 530 the Service Model(s) and local operational guidelines. 532 In addition, the operational state including configuration that is in 533 effect together with statistics should be exposed to upper layers to 534 provide better network visibility and assess to what extent the 535 derived low level modules are consistent with the upper level inputs. 537 Filters are enforced on the notifications that are communicated to 538 Service layers. The type and frequency of notifications may be 539 agreed in the Service Model. 541 Note that it is important to correlate telemetry data with 542 configuration data to be used for closed loops at the different 543 stages of service delivery, from resource allocation to service 544 operation, in particular. 546 3.4. YANG Modules Integration 548 To support top-down service delivery, YANG modules at different 549 levels or at the same level need to be integrated together for proper 550 service delivery (including, proper network setup). For example, the 551 service parameters captured in Service Models need to be decomposed 552 into a set of configuration/notification parameters that may be 553 specific to one or more technologies; these technology-specific 554 parameters are grouped together to define technology-specific device 555 level models or network level models. 557 In addition, these technology-specific Device or Network Models can 558 be further integrated with each other using the schema mount 559 mechanism [RFC8528] to provision each involved network function/ 560 device or each involved network domain to support newly added module 561 or features. A collection of Device Models integrated together can 562 be loaded and validated during implementation. 564 High-level policies can be defined at Service or Network Models 565 (e.g., "Autonomous System Number (ASN) Exclude" in the example 566 depicted in Figure 2). Device Models will be tweaked accordingly to 567 provide policy-based management. Policies can also be used for 568 telemetry automation, e.g., policies that contain conditions to 569 trigger the generation and pushing of new telemetry data. 571 4. Functional Blocks and Interactions 573 The architectural considerations described in Section 3 lead to the 574 architecture described in this section and illustrated in Figure 4. 576 +------------------+ 577 ................. | | 578 Service level | | 579 V | 580 E2E E2E E2E E2E 581 Service --> Service ---------> Service -----> Service -----+ 582 Exposure Creation ^ Optimization ^ Diagnosis | 583 /Modification | | | 584 | |Diff | V 585 Multi-layer | | E2E | E2E 586 Multi-domain | | Service | Service 587 Service Mapping| +------ Assurance --+ Decommission 588 | ^ 589 ................. |<-----------------+ | 590 Network level | | +-------+ 591 V | | 592 Specific Specific | 593 Service --------> Service <--+ | 594 Creation ^ Optimization | | 595 /Modification | | | 596 | |Diff | | 597 | | Specific --+ | 598 Service | | Service | 599 Decomposing | +----- Assurance ----+ 600 | ^ 601 ................. | | Aggregation 602 Device level | +------------+ 603 V | 604 Service Intent | 605 Fulfillment Config ----> Config ----> Performance ----> Fault 606 Provision Validation Monitoring Diagnostic 608 Figure 4: Service and Network Lifecycle Management 610 4.1. Service Lifecycle Management Procedure 612 Service lifecycle management includes end-to-end service lifecycle 613 management at the service level and technology specific network 614 lifecycle management at the network level. 616 The end-to-end service lifecycle management is technology-independent 617 service management and spans across multiple network domains and/or 618 multiple layers while technology specific service lifecycle 619 management is technology domain specific or layer specific service 620 lifecycle management. 622 4.1.1. Service Exposure 624 A service in the context of this document (sometimes called, Network 625 Service) is some form of connectivity between customer sites and the 626 Internet or between customer sites across the operator's network and 627 across the Internet. 629 Service exposure is used to capture services offered to customers 630 (ordering and order handling). One typical example is that a 631 customer can use a L3VPN Service Model (L3SM) to request L3VPN 632 service by providing the abstract technical characterization of the 633 intended service between customer sites. 635 Service Model catalogs can be created along to expose the various 636 services and the information needed to invoke/order a given service. 638 4.1.2. Service Creation/Modification 640 A customer is usually unaware of the technology that the network 641 operator has available to deliver the service, so the customer does 642 not make requests specific to the underlying technology but is 643 limited to making requests specific to the service that is to be 644 delivered. This service request can be filled using a Service Model. 646 Upon receiving a service request, and assuming that appropriate 647 authentication and authorization checks have been made with success, 648 the service orchestrator/management system should verify whether the 649 service requirements in the service request can be met (i.e., whether 650 there is sufficient resources that can be allocated with the 651 requested guarantees). 653 If the request is accepted, the service orchestrator/management 654 system maps such service request to its view. This view can be 655 described as a technology specific Network Model or a set of 656 technology specific Device Models and this mapping may include a 657 choice of which networks and technologies to use depending on which 658 service features have been requested. 660 In addition, a customer may require to change the underlying network 661 infrastructure to adapt to new customer's needs and service 662 requirements. This service modification can be issued following the 663 same Service Model used by the service request. 665 4.1.3. Service Assurance 667 Performance measurement telemetry (Section 4.2) can be used to 668 provide service assurance at Service and/or Network levels. 669 Performance measurement telemetry model can tie with Service or 670 Network Models to monitor network performance or Service Level 671 Agreement. 673 4.1.4. Service Optimization 675 Service optimization is a technique that gets the configuration of 676 the network updated due to network changes, incidents mitigation, or 677 new service requirements. One typical example is once a tunnel or a 678 VPN is setup, Performance monitoring information or telemetry 679 information per tunnel (or per VPN) can be collected and fed into the 680 management system. If the network performance doesn't meet the 681 service requirements, the management system can create new VPN 682 policies capturing network service requirements and populate them 683 into the network. 685 Both network performance information and policies can be modelled 686 using YANG. With Policy-based management, self-configuration and 687 self-optimization behavior can be specified and implemented. 689 The overall service optimization is managed at the service level, 690 while the network level is responsible for the optimization of the 691 specific network services it provides. 693 4.1.5. Service Diagnosis 695 Operations, Administration, and Maintenance (OAM) are important 696 networking functions for service diagnosis that allow network 697 operators to: 699 o monitor network communications (i.e., reachability verification 700 and Continuity Check) 702 o troubleshoot failures (i.e., fault verification and localization) 704 o monitor service-level agreements and performance (i.e., 705 performance management) 707 When the network is down, service diagnosis should be in place to 708 pinpoint the problem and provide recommendations (or instructions) 709 for the network recovery. 711 The service diagnosis information can be modelled as technology- 712 independent Remote Procedure Call (RPC) operations for OAM protocols 713 and technology-independent abstraction of key OAM constructs for OAM 714 protocols [RFC8531][RFC8533]. These models can be used to provide 715 consistent configuration, reporting, and presentation for the OAM 716 mechanisms used to manage the network. 718 4.1.6. Service Decommission 720 Service decommission allows a customer to stop the service by 721 removing the service from active status and thus releasing the 722 network resources that were allocated to the service. Customers can 723 also use the Service Model to withdraw the registration to a service. 725 4.2. Service Fullfillment Management Procedure 727 4.2.1. Intended Configuration Provision 729 Intended configuration at the device level is derived from Network 730 Models at the network level or Service Model at the service level and 731 represents the configuration that the system attempts to apply. Take 732 L3SM as a Service Model example to deliver a L3VPN service, there is 733 a need to map the L3VPN service view defined in the Service Model 734 into a detailed intended configuration view defined by specific 735 configuration models for network elements; the configuration 736 information includes: 738 o Virtual Routing and Forwarding (VRF) definition, including VPN 739 policy expression 741 o Physical Interface(s) 743 o IP layer (IPv4, IPv6) 745 o QoS features such as classification, profiles, etc. 747 o Routing protocols: support of configuration of all protocols 748 listed in a service request, as well as routing policies 749 associated with those protocols. 751 o Multicast support 753 o Address sharing (e.g., NAT) 755 o Security 757 These specific configuration models can be used to configure Provider 758 Edge (PE) and Customer Edge (CE) devices within a site, e.g., a BGP 759 policy model can be used to establish VPN membership between sites 760 and VPN Service Topology. 762 Note that in networks with legacy devices (that support proprietary 763 modules or do not support YANG at all), an adaptation layer is likely 764 to be required at the network level so that these devices can be 765 involved in the delivery of the network services. 767 4.2.2. Configuration Validation 769 Configuration validation is used to validate intended configuration 770 and ensure the configuration take effect. 772 For example, a customer creates an interface "eth-0/0/0" but the 773 interface does not physically exist at this point, then configuration 774 data appears in the status but does not appear in 775 datastore. 777 4.2.3. Performance Monitoring/Model-driven Telemetry 779 When a configuration is in effect in a device, 780 datastore holds the complete operational state of the device 781 including learned, system, default configuration, and system state. 782 However, the configurations and state of a particular device does not 783 have the visibility on the whole network or how packets are going to 784 be forwarded through the entire network. Therefore, it becomes more 785 difficult to operate the entire network without understanding the 786 current status of the network. 788 The management system should subscribe to updates of a YANG datastore 789 in all the network devices for performance monitoring purposes and 790 build a full topological visibility of the network by aggregating 791 (and filtering) these operational state from different sources. 793 4.2.4. Fault Diagnostic 795 When configuration is in effect in a device, some devices may be mis- 796 configured (e.g., device links are not consistent in both sides of 797 the network connection) or network resources be mis-allocated. 798 Therefore, services may be negatively affected without knowing the 799 root cause in the network. 801 Technology-dependent nodes and RPC commands are defined in 802 technology-specific YANG data models which can use and extend the 803 base model described in Section 4.1.5 to deal with these issues. 805 These RPC commands received in the technology-dependent node can be 806 used to trigger technology-specific OAM message exchanges for fault 807 verification and fault isolation. For example, TRILL Multicast Tree 808 Verification (MTV) RPC command [I-D.ietf-trill-yang-oam] can be used 809 to trigger Multi-Destination Tree Verification Message defined in 810 [RFC7455] to verify TRILL distribution tree integrity. 812 4.3. Multi-Layer/Multi-Domain Service Mapping 814 Multi-layer/Multi-domain Service Mapping allows to map an end-to-end 815 abstract view of the service segmented at different layers and/or 816 different network domains into domain-specific views. 818 One example is to map service parameters in the L3SM into 819 configuration parameters such as Route Distinguisher (RD), Route 820 Target (RT), and VRF in the L3VPN Network Model (L3NM). 822 Another example is to map service parameters in the L3SM into Traffic 823 Engineered (TE) tunnel parameter (e.g., Tunnel ID) in TE model and 824 Virtual Network (VN) parameters (e.g., Access Point (AP) list, VN 825 members) in the YANG data model for VN operation 826 [I-D.ietf-teas-actn-vn-yang]. 828 4.4. Service Decomposing 830 Service Decomposing allows to decompose Service Models at the service 831 level or Network Models at the network level into a set of Device 832 Models at the device level. These Device Models may be tied to 833 specific device types or classified into a collection of related YANG 834 modules based on service types and features offered, and load at the 835 implementation time before configuration is loaded and validated. 837 5. YANG Data Model Integration Examples 839 The following subsections provide some YANG data models integration 840 examples. 842 5.1. L2VPN/L3VPN Service Delivery 844 In reference to Figure 5, the following steps are performed to 845 deliver the L3VPN service within the network management automation 846 architecture defined in Section 4: 848 1. The Customer requests to create two sites (as per Service 849 Creation in Section 4.2.1) relying upon L3SM with each site 850 having one network access connectivity, for example: 852 * Site A: network-access A, link-capacity = 20 Mbps, class 853 "foo", guaranteed-capacity-percent = 10, average-one-way-delay 854 = 70 ms. 856 * Site B: network-access B, link-capacity = 30 Mbps, class 857 "foo1", guaranteed-capacity-percent = 15, average-one-way- 858 delay = 60 ms. 860 2. The Orchestrator extracts the service parameters from the L3SM. 861 Then, it uses them as input to the Service Mapping in Section 4.3 862 to translate them into an orchestrated configuration parameters 863 (e.g., RD, RT, VRF) that are part of the L3NM specified in 864 [I-D.ietf-opsawg-l3sm-l3nm]. 866 3. The Controller takes the orchestrated configuration parameters in 867 the L3NM and translates them into orchestrated (Service 868 Decomposing in Section 4.4) configuration of network elements 869 that are part of, e.g., BGP, QoS, Network Instance, IP 870 management, and interface models. 872 [I-D.ogondio-opsawg-uni-topology] can be used for representing, 873 managing, and controlling the User Network Interface (UNI) topology. 875 L3SM | 876 Service | 877 Model | 878 +----------------------+--------------------------+ 879 | +--------V--------+ | 880 | | Service Mapping | | 881 | +--------+--------+ | 882 | Orchestrator | | 883 +----------------------+--------------------------+ 884 L3NM | ^ UNI Topology Model 885 Network| | 886 Model | | 887 +----------------------+--------------------------+ 888 | +----------V-----------+ | 889 | | Service Decomposing | | 890 | +---++--------------++-+ | 891 | || || | 892 | Controller || || | 893 +---------------++--------------++----------------+ 894 || || 895 || BGP, || 896 || QoS, || 897 || Interface, || 898 +------------+| NI, |+--------------+ 899 | | IP | | 900 +--+--+ +--+--+ +--+--+ +--+--+ 901 | CE1 +-------+ PE1 | | PE2 +---------+ CE2 | 902 +-----+ +-----+ +-----+ +-----+ 904 Figure 5: L3VPN Service Delivery Example (Current) 906 L3NM inherits some of data elements from the L3SM. Nevertheless, the 907 L3NM does not expose some information to the above layer such as the 908 capabilities of an underlying network (which can be used to drive 909 service order handling) or notifications (to notify subscribers about 910 specific events or degradations as per agreed SLAs). Some of this 911 information can be provided using, e.g., 912 [I-D.www-bess-yang-vpn-service-pm]. A target overall model is 913 depicted in Figure 6. 915 L3SM | ^ 916 Service | | Notifications 917 Model | | 918 +----------------------+--------------------------+ 919 | +--------V--------+ | 920 | | Service Mapping | | 921 | +--------+--------+ | 922 | Orchestrator | | 923 +----------------------+--------------------------+ 924 L3NM | ^ UNI Topology Model 925 Network| | L3NM Notifications 926 Model | | L3NM Capabilities 927 +----------------------+--------------------------+ 928 | +----------V-----------+ | 929 | | Service Decomposing | | 930 | +---++--------------++-+ | 931 | || || | 932 | Controller || || | 933 +---------------++--------------++----------------+ 934 || || 935 || BGP, || 936 || QoS, || 937 || Interface, || 938 +------------+| NI, |+--------------+ 939 | | IP | | 940 +--+--+ +--+--+ +--+--+ +--+--+ 941 | CE1 +-------+ PE1 | | PE2 +---------+ CE2 | 942 +-----+ +-----+ +-----+ +-----+ 944 Figure 6: L3VPN Service Delivery Example (Target) 946 Note that a similar analysis can be performed for Layer 2 VPNs 947 (L2VPNs). A L2VPN Service Model (L2SM) is defined in [RFC8466], 948 while the L2VPN Network YANG Model (L2NM) is specified in 949 [I-D.ietf-opsawg-l2nm]. 951 5.2. VN Lifecycle Management 953 In reference to Figure 7, the following steps are performed to 954 deliver the VN service within the network management automation 955 architecture defined in Section 4: 957 1. A customer makes a request (Service Exposure in Section 4.1.1) to 958 create a VN. The association between the VN, APs, and VN members 959 is defined in the VN YANG module [I-D.ietf-teas-actn-vn-yang]. 961 2. The Orchestrator creates the single abstract node topology based 962 on the information captured in the request. 964 3. The customer exchanges with the Orchestrator the connectivity 965 matrix on the abstract node and explicit paths using the TE 966 topology model [RFC8795]. This information can be used to 967 instantiate the VN and setup tunnels between source and 968 destination endpoints (Service Creation in Section 4.1.2). 970 4. The telemetry model which augments the VN model and corresponding 971 TE tunnel model can be used to subscribe to performance 972 measurement data and notify all the parameter changes and network 973 performance changes related to VN topology or Tunnel 974 [I-D.ietf-teas-actn-pm-telemetry-autonomics] and provide service 975 assurance (Service Optimization in Section 4.1.4). 977 | 978 VN | 979 Service | 980 Model | 981 +----------------------|--------------------------+ 982 | Orchestrator | | 983 | +--------V--------+ | 984 | | Service Mapping | | 985 | +-----------------+ | 986 +----------------------+--------------------^-----+ 987 TE | Telemetry | 988 Tunnel | Model | 989 Model | | 990 +----------------------V--------------------+-----+ 991 | Controller | 992 | | 993 +-------------------------------------------------+ 995 +-----+ +-----+ +-----+ +-----+ 996 | CE1 +------+ PE1 | | PE2 +------+ CE2 | 997 +-----+ +-----+ +-----+ +-----+ 999 Figure 7: A VN Service Delivery Example 1001 5.3. Event-based Telemetry in the Device Self Management 1003 In reference to Figure 8, the following steps are performed to 1004 monitor state changes of managed resources in a network device and 1005 provide device self-management within the network management 1006 automation architecture defined in Section 4: 1008 1. To control which state a network device should be in or is 1009 allowed to be in at any given time, a set of conditions and 1010 actions are defined and correlated with network events (e.g., 1011 allow the NETCONF server to send updates only when the value 1012 exceeds a certain threshold for the first time, but not again 1013 until the threshold is cleared), which constitute an 1014 Event/Condition/Action (ECA) policy or an event-driven policy 1015 control logic that can be executed on the device (e.g., 1016 [I-D.wwx-netmod-event-yang]). 1018 2. To provide rapid autonomic response that can exhibit self- 1019 management properties, the Controller pushes the ECA policy to 1020 the network device and delegates the network control logic to the 1021 network device. 1023 3. The network device uses the ECA model to subscribe to the event 1024 source, e.g., an event stream or datastore state data conveyed to 1025 the server via YANG Push subscription [RFC8641], monitors state 1026 parameters, and takes simple and instant actions when associated 1027 event condition on state parameters is met. ECA notifications 1028 can be generated as the result of actions based on event stream 1029 subscription or datastore subscription (model-driven telemetry 1030 operation discussed in Section 4.2.3). 1032 +----------------+ 1033 | <----+ 1034 | Controller | | 1035 +-------+--------+ | 1036 | | 1037 | | 1038 ECA | | ECA 1039 Model | | Notification 1040 | | 1041 | | 1042 +------------V-------------+-----+ 1043 |Device | | 1044 | +-------+ +---------+ +--+---+ | 1045 | | Event +-> Event +->Event | | 1046 | | Source| |Condition| |Action| | 1047 | +-------+ +---------+ +------+ | 1048 +--------------------------------+ 1050 Figure 8: Event-based Telemetry 1052 6. Security Considerations 1054 The YANG modules cited in this document define schema for data that 1055 are designed to be accessed via network management protocols such as 1056 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 1057 the secure transport layer, and the mandatory-to-implement secure 1058 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1059 is HTTPS, and the mandatory-to-implement secure transport is TLS 1060 [RFC8446]. 1062 The NETCONF access control model [RFC8341] provides the means to 1063 restrict access for particular NETCONF or RESTCONF users to a 1064 preconfigured subset of all available NETCONF or RESTCONF protocol 1065 operations and content. 1067 Security considerations specific to each of the technologies and 1068 protocols listed in the document are discussed in the specification 1069 documents of each of these protocols. 1071 In order to prevent leaking sensitive information, special care 1072 should be considered when translating between the various layers in 1073 Section 4 or when aggregating data retrieved from various sources. 1074 The network operator must enforce means to protect privacy-related 1075 information included in customer-facing models. 1077 To detect misalignment between layers that might be induced by 1078 misbehaving nodes, upper layers should continuously monitor the 1079 perceived service (Section 4.1.4) and should proceed with checks to 1080 assess that the provided service complies with the expected service 1081 and that the data reported by an underlying layer is matching the 1082 perceived service by the above layer. Typically, such checks are the 1083 responsibility of the service diagnosis (Section 4.1.5). 1085 Additional considerations are discussed in the following subsections. 1087 6.1. Service Level 1089 A provider may rely on services offered by other providers to build 1090 composite services. Appropriate mechanisms should be enabled by the 1091 provider to monitor and detect a service disruption from these 1092 providers. The characterization of a service disruption (including, 1093 mean time between failures, mean time to repair), the escalation 1094 procedure, and penalties are usually documented in contractual 1095 agreements (e.g., Section 2.1 of [RFC4176]). Misbehaving peer 1096 providers will thus be identified and appropriate countermeasures 1097 will be applied. 1099 6.2. Network Level 1101 Security considerations specific to the network level are listed 1102 below: 1104 o A controller may create forwarding loops by mis-configuring the 1105 underlying network nodes. It is recommended to proceed with tests 1106 to check the status of forwarding paths regularly or whenever 1107 changes are made to routing or forwarding processes. Such checks 1108 may be triggered from the service level owing to the means 1109 discussed in Section 4.1.5. 1111 o Some Service Models may include a traffic isolation clause, 1112 appropriate technology-specific actions must be enforced at the 1113 underlying network (and thus involved network devices) to avoid 1114 that such traffic is accessible to non-authorized parties. 1116 6.3. Device Level 1118 Network operators should monitor and audit their networks to detect 1119 misbehaving nodes and abnormal behaviors. For example, OAM discussed 1120 in Section 4.1.5 can be used for that purpose. 1122 7. IANA Considerations 1124 There are no IANA requests or assignments included in this document. 1126 8. Acknowledgements 1128 Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter, 1129 Adrian Farrel, Christian Huitema, Tommy Pauly, Ines Robles, and 1130 Olivier Augizeau for the review. 1132 Many thanks to Robert Wilton for the detailed AD review. 1134 9. Contributors 1135 Christian Jacquenet 1136 Orange 1137 Rennes, 35000 1138 France 1139 Email: Christian.jacquenet@orange.com 1141 Luis Miguel Contreras Murillo 1142 Telifonica 1144 Email: luismiguel.contrerasmurillo@telefonica.com 1146 Oscar Gonzalez de Dios 1147 Telefonica 1148 Madrid 1149 ES 1151 Email: oscar.gonzalezdedios@telefonica.com 1153 Weiqiang Cheng 1154 China Mobile 1156 Email: chengweiqiang@chinamobile.com 1158 Young Lee 1159 Sung Kyun Kwan University 1161 Email: younglee.tx@gmail.com 1163 10. References 1165 10.1. Normative References 1167 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1168 and A. Bierman, Ed., "Network Configuration Protocol 1169 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1170 . 1172 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1173 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1174 . 1176 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1177 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1178 . 1180 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1181 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1182 . 1184 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1185 Access Control Model", STD 91, RFC 8341, 1186 DOI 10.17487/RFC8341, March 2018, 1187 . 1189 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1190 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1191 . 1193 10.2. Informative References 1195 [I-D.clacla-netmod-model-catalog] 1196 Clarke, J. and B. Claise, "YANG module for 1197 yangcatalog.org", draft-clacla-netmod-model-catalog-03 1198 (work in progress), April 2018. 1200 [I-D.ietf-bess-evpn-yang] 1201 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 1202 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 1203 bess-evpn-yang-07 (work in progress), March 2019. 1205 [I-D.ietf-bess-l2vpn-yang] 1206 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1207 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1208 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 1209 July 2019. 1211 [I-D.ietf-bess-l3vpn-yang] 1212 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 1213 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 1214 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 1215 in progress), October 2018. 1217 [I-D.ietf-bess-mvpn-yang] 1218 Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and 1219 M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP 1220 IP VPNs", draft-ietf-bess-mvpn-yang-04 (work in progress), 1221 June 2020. 1223 [I-D.ietf-bfd-yang] 1224 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 1225 and G. Mirsky, "YANG Data Model for Bidirectional 1226 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 1227 in progress), August 2018. 1229 [I-D.ietf-dots-rfc8782-bis] 1230 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 1231 Denial-of-Service Open Threat Signaling (DOTS) Signal 1232 Channel Specification", draft-ietf-dots-rfc8782-bis-01 1233 (work in progress), September 2020. 1235 [I-D.ietf-i2rs-yang-l2-network-topology] 1236 Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A 1237 YANG Data Model for Layer 2 Network Topologies", draft- 1238 ietf-i2rs-yang-l2-network-topology-18 (work in progress), 1239 September 2020. 1241 [I-D.ietf-idr-bgp-model] 1242 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1243 YANG Model for Service Provider Networks", draft-ietf-idr- 1244 bgp-model-09 (work in progress), June 2020. 1246 [I-D.ietf-ippm-capacity-metric-method] 1247 Morton, A., Geib, R., and L. Ciavattone, "Metrics and 1248 Methods for One-way IP Capacity", draft-ietf-ippm- 1249 capacity-metric-method-04 (work in progress), September 1250 2020. 1252 [I-D.ietf-ippm-stamp-yang] 1253 Mirsky, G., Min, X., and W. Luo, "Simple Two-way Active 1254 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 1255 stamp-yang-06 (work in progress), October 2020. 1257 [I-D.ietf-ippm-twamp-yang] 1258 Civil, R., Morton, A., Rahman, R., Jethanandani, M., and 1259 K. Pentikousis, "Two-Way Active Measurement Protocol 1260 (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work 1261 in progress), July 2018. 1263 [I-D.ietf-mpls-base-yang] 1264 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 1265 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 1266 yang-15 (work in progress), August 2020. 1268 [I-D.ietf-netmod-module-tags] 1269 Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module 1270 Tags", draft-ietf-netmod-module-tags-10 (work in 1271 progress), February 2020. 1273 [I-D.ietf-opsawg-l2nm] 1274 barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil, 1275 L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- 1276 ietf-opsawg-l2nm-00 (work in progress), July 2020. 1278 [I-D.ietf-opsawg-l3sm-l3nm] 1279 barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. 1280 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 1281 opsawg-l3sm-l3nm-04 (work in progress), October 2020. 1283 [I-D.ietf-pim-igmp-mld-snooping-yang] 1284 Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, 1285 "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- 1286 pim-igmp-mld-snooping-yang-18 (work in progress), August 1287 2020. 1289 [I-D.ietf-pim-yang] 1290 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1291 Y., and f. hu, "A YANG Data Model for Protocol Independent 1292 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1293 progress), May 2018. 1295 [I-D.ietf-rtgwg-policy-model] 1296 Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data 1297 Model for Routing Policy Management", draft-ietf-rtgwg- 1298 policy-model-26 (work in progress), October 2020. 1300 [I-D.ietf-rtgwg-qos-model] 1301 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 1302 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 1303 model-02 (work in progress), July 2020. 1305 [I-D.ietf-spring-sr-yang] 1306 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 1307 Tantsura, "YANG Data Model for Segment Routing", draft- 1308 ietf-spring-sr-yang-22 (work in progress), August 2020. 1310 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 1311 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 1312 and D. Ceccarelli, "YANG models for VN/TE Performance 1313 Monitoring Telemetry and Scaling Intent Autonomics", 1314 draft-ietf-teas-actn-pm-telemetry-autonomics-03 (work in 1315 progress), July 2020. 1317 [I-D.ietf-teas-actn-vn-yang] 1318 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1319 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1320 teas-actn-vn-yang-09 (work in progress), July 2020. 1322 [I-D.ietf-teas-yang-path-computation] 1323 Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, 1324 "Yang model for requesting Path Computation", draft-ietf- 1325 teas-yang-path-computation-10 (work in progress), July 1326 2020. 1328 [I-D.ietf-teas-yang-rsvp-te] 1329 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 1330 and H. Shah, "A YANG Data Model for RSVP-TE Protocol", 1331 draft-ietf-teas-yang-rsvp-te-08 (work in progress), March 1332 2020. 1334 [I-D.ietf-teas-yang-te] 1335 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1336 "A YANG Data Model for Traffic Engineering Tunnels, Label 1337 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 1338 (work in progress), July 2020. 1340 [I-D.ietf-trill-yang-oam] 1341 Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., 1342 and H. Weiguo, "YANG Data Model for TRILL Operations, 1343 Administration, and Maintenance (OAM)", draft-ietf-trill- 1344 yang-oam-05 (work in progress), March 2017. 1346 [I-D.ogondio-opsawg-uni-topology] 1347 Dios, O., barguil, s., WU, Q., and M. Boucadair, "A YANG 1348 Model for User-Network Interface (UNI) Topologies", draft- 1349 ogondio-opsawg-uni-topology-01 (work in progress), April 1350 2020. 1352 [I-D.www-bess-yang-vpn-service-pm] 1353 WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., and H. 1354 Xu, "A YANG Model for Network and VPN Service Performance 1355 Monitoring", draft-www-bess-yang-vpn-service-pm-06 (work 1356 in progress), April 2020. 1358 [I-D.wwx-netmod-event-yang] 1359 Bierman, A., WU, Q., Bryskin, I., Birkholz, H., Liu, X., 1360 and B. Claise, "A YANG Data model for ECA Policy 1361 Management", draft-wwx-netmod-event-yang-09 (work in 1362 progress), July 2020. 1364 [IPPM] IANA, "Performance Metrics", March 2020, 1365 . 1368 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 1369 and A. Gonguet, "Framework for Layer 3 Virtual Private 1370 Networks (L3VPN) Operations and Management", RFC 4176, 1371 DOI 10.17487/RFC4176, October 2005, 1372 . 1374 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1375 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1376 2006, . 1378 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1379 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1380 DOI 10.17487/RFC4664, September 2006, 1381 . 1383 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1384 LAN Service (VPLS) Using BGP for Auto-Discovery and 1385 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1386 . 1388 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1389 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1390 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1391 . 1393 [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", 1394 RFC 5136, DOI 10.17487/RFC5136, February 2008, 1395 . 1397 [RFC5486] Malas, D., Ed. and D. Meyer, Ed., "Session Peering for 1398 Multimedia Interconnect (SPEERMINT) Terminology", 1399 RFC 5486, DOI 10.17487/RFC5486, March 2009, 1400 . 1402 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1403 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1404 . 1406 [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for 1407 Multimedia INTerconnect (SPEERMINT) Architecture", 1408 RFC 6406, DOI 10.17487/RFC6406, November 2011, 1409 . 1411 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1412 Networking: A Perspective from within a Service Provider 1413 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1414 . 1416 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1417 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1418 . 1420 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1421 Weingarten, "An Overview of Operations, Administration, 1422 and Maintenance (OAM) Tools", RFC 7276, 1423 DOI 10.17487/RFC7276, June 2014, 1424 . 1426 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1427 Connectivity Provisioning Profile (CPP)", RFC 7297, 1428 DOI 10.17487/RFC7297, July 2014, 1429 . 1431 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1432 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1433 2014, . 1435 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 1436 3rd, D., Aldrin, S., and Y. Li, "Transparent 1437 Interconnection of Lots of Links (TRILL): Fault 1438 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 1439 . 1441 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1442 Chaining (SFC) Architecture", RFC 7665, 1443 DOI 10.17487/RFC7665, October 2015, 1444 . 1446 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1447 Ed., "A One-Way Delay Metric for IP Performance Metrics 1448 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 1449 2016, . 1451 [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 1452 Ed., "A One-Way Loss Metric for IP Performance Metrics 1453 (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 1454 2016, . 1456 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 1457 Maintenance Using the Label Distribution Protocol (LDP)", 1458 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 1459 . 1461 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1462 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1463 August 2017, . 1465 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1466 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1467 2017, . 1469 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1470 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1471 DOI 10.17487/RFC8299, January 2018, 1472 . 1474 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1475 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1476 . 1478 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1479 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1480 . 1482 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1483 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1484 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1485 2018, . 1487 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1488 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1489 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1490 March 2018, . 1492 [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 1493 YANG Data Model for Hardware Management", RFC 8348, 1494 DOI 10.17487/RFC8348, March 2018, 1495 . 1497 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1498 Routing Management (NMDA Version)", RFC 8349, 1499 DOI 10.17487/RFC8349, March 2018, 1500 . 1502 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1503 Data Model for Layer 2 Virtual Private Network (L2VPN) 1504 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1505 2018, . 1507 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1508 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1509 Address Translation (NAT) and Network Prefix Translation 1510 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1511 . 1513 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1514 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1515 DOI 10.17487/RFC8513, January 2019, 1516 . 1518 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1519 "YANG Data Model for Network Access Control Lists (ACLs)", 1520 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1521 . 1523 [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", 1524 RFC 8528, DOI 10.17487/RFC8528, March 2019, 1525 . 1527 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1528 Liu, "YANG Data Model for Network Instances", RFC 8529, 1529 DOI 10.17487/RFC8529, March 2019, 1530 . 1532 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1533 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1534 DOI 10.17487/RFC8530, March 2019, 1535 . 1537 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1538 for Connection-Oriented Operations, Administration, and 1539 Maintenance (OAM) Protocols", RFC 8531, 1540 DOI 10.17487/RFC8531, April 2019, 1541 . 1543 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1544 Raghavan, "Generic YANG Data Model for the Management of 1545 Operations, Administration, and Maintenance (OAM) 1546 Protocols That Use Connectionless Communications", 1547 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1548 . 1550 [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. 1551 Raghavan, "A YANG Data Model for Retrieval Methods for the 1552 Management of Operations, Administration, and Maintenance 1553 (OAM) Protocols That Use Connectionless Communications", 1554 RFC 8533, DOI 10.17487/RFC8533, April 2019, 1555 . 1557 [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm 1558 Management", RFC 8632, DOI 10.17487/RFC8632, September 1559 2019, . 1561 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1562 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1563 September 2019, . 1565 [RFC8652] Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 1566 Peter, "A YANG Data Model for the Internet Group 1567 Management Protocol (IGMP) and Multicast Listener 1568 Discovery (MLD)", RFC 8652, DOI 10.17487/RFC8652, November 1569 2019, . 1571 [RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data 1572 Model for Tunnel Interface Types", RFC 8675, 1573 DOI 10.17487/RFC8675, November 2019, 1574 . 1576 [RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for 1577 IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, 1578 DOI 10.17487/RFC8676, November 2019, 1579 . 1581 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 1582 Denial-of-Service Open Threat Signaling (DOTS) Data 1583 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 1584 May 2020, . 1586 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 1587 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1588 June 2020, . 1590 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1591 O. Gonzalez de Dios, "YANG Data Model for Traffic 1592 Engineering (TE) Topologies", RFC 8795, 1593 DOI 10.17487/RFC8795, August 2020, 1594 . 1596 Appendix A. Layered YANG Modules Examples Overview 1598 This appendix lists a set of YANG data models that can be used for 1599 the delivery of connectivity services. These models can be 1600 classified as Service, Network, or Device Models. 1602 It is not the intent of this appendix to provide an inventory of 1603 tools and mechanisms used in specific network and service management 1604 domains; such inventory can be found in documents such as [RFC7276]. 1606 The reader may refer to the YANG Catalog 1607 () or the public Github YANG repository 1608 () to query existing YANG models. 1610 The YANG Catalog includes some metadata to indicate the module type 1611 ('module-classification') [I-D.clacla-netmod-model-catalog]. Note 1612 that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to 1613 associate tags with YANG modules in order to help classifying the 1614 modules. 1616 A.1. Service Models: Definition and Samples 1618 As described in [RFC8309], the service is "some form of connectivity 1619 between customer sites and the Internet and/or between customer sites 1620 across the network operator's network and across the Internet". More 1621 concretely, an IP connectivity service can be defined as the IP 1622 transfer capability characterized by a (Source Nets, Destination 1623 Nets, Guarantees, Scope) tuple where "Source Nets" is a group of 1624 unicast IP addresses, "Destination Nets" is a group of IP unicast 1625 and/or multicast addresses, and "Guarantees" reflects the guarantees 1626 (expressed in terms of QoS, performance, and availability, for 1627 example) to properly forward traffic to the said "Destination" 1628 [RFC7297]. 1630 For example: 1632 o The L3SM [RFC8299] defines the L3VPN service ordered by a customer 1633 from a network operator. 1635 o The L2SM [RFC8466] defines the L2VPN service ordered by a customer 1636 from a network operator. 1638 o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang] 1639 provides a YANG data model applicable to any mode of VN operation. 1641 L2SM and L3SM are customer Service Models as per [RFC8309]. 1643 A.2. Schema Mount 1645 Modularity and extensibility were among the leading design principles 1646 of the YANG data modeling language. As a result, the same YANG 1647 module can be combined with various sets of other modules and thus 1648 form a data model that is tailored to meet the requirements of a 1649 specific use case. [RFC8528] defines a mechanism, denoted schema 1650 mount, that allows for mounting one data model consisting of any 1651 number of YANG modules at a specified location of another (parent) 1652 schema. 1654 A.3. Network Models: Samples 1656 L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are 1657 examples of YANG Network Models. 1659 Figure 9 depicts a set of additional Network Models such as topology 1660 and tunnel models: 1662 +-------------------------------+-------------------------------+ 1663 | Topology YANG modules | Tunnel YANG modules | 1664 +-------------------------------+-------------------------------+ 1665 | +------------------+ | | 1666 | |Network Topologies| | +------+ +-----------+ | 1667 | | Model | | |Other | | TE Tunnel | | 1668 | +--------+---------+ | |Tunnel| +----+------+ | 1669 | | +---------+ | +------+ | | 1670 | +---+Service | | +----------+---------+ | 1671 | | |Topology | | | | | | 1672 | | +---------+ | | | | | 1673 | | +---------+ |+----+---+ +----+---+ +---+---+| 1674 | +---+Layer 3 | ||MPLS-TE | |RSVP-TE | | SR-TE || 1675 | | |Topology | || Tunnel | | Tunnel | |Tunnel || 1676 | | +---------+ |+--------+ +--------+ +-------+| 1677 | | +---------+ | | 1678 | +---+TE | | | 1679 | | |Topology | | | 1680 | | +---------+ | | 1681 | | +---------+ | | 1682 | +---+Layer 3 | | | 1683 | |Topology | | | 1684 | +---------+ | | 1685 +-------------------------------+-------------------------------+ 1687 Figure 9: Sample Resource Facing Network Models 1689 Examples of topology YANG modules are listed below: 1691 o Network Topologies Model: [RFC8345] defines a base model for 1692 network topology and inventories. Network topology data include 1693 link resource, node resource, and terminate-point resources. 1695 o TE Topology Model: [RFC8795] defines a YANG data model for 1696 representing and manipulating TE topologies. 1698 This module is extended from network topology model defined in 1699 [RFC8345] with TE topologies related content. This model contains 1700 technology-agnostic TE Topology building blocks that can be 1701 augmented and used by other technology-specific TE topology 1702 models. 1704 o Layer 3 Topology Model: 1706 [RFC8346] defines a YANG data model for representing and 1707 manipulating Layer 3 topologies. This model is extended from the 1708 network topology model defined in [RFC8345] with Layer 3 1709 topologies specifics. 1711 o Layer 2 Topology Model: 1713 [I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model 1714 for representing and manipulating Layer 2 topologies. This model 1715 is extended from the network topology model defined in [RFC8345] 1716 with Layer 2 topology specifics. 1718 Examples of tunnel YANG modules are provided below: 1720 o Tunnel identities: [RFC8675] defines a collection of YANG 1721 identities used as interface types for tunnel interfaces. 1723 o TE Tunnel Model: 1725 [I-D.ietf-teas-yang-te] defines a YANG module for the 1726 configuration and management of TE interfaces, tunnels, and LSPs. 1728 o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model: 1730 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1731 model(s) and defines a YANG module for SR-TE specific data. 1733 o MPLS-TE Model: 1735 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1736 model(s) and defines a YANG module for MPLS-TE configurations, 1737 state, RPC and notifications. 1739 o RSVP-TE MPLS Model: 1741 [I-D.ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 1742 with parameters to configure and manage signaling of MPLS RSVP-TE 1743 LSPs. 1745 Other sample Network Models are listed hereafter: 1747 o Path Computation API Model: 1749 [I-D.ietf-teas-yang-path-computation] YANG module for a stateless 1750 RPC which complements the stateful solution defined in 1751 [I-D.ietf-teas-yang-te]. 1753 o OAM Models (including Fault Management (FM) and Performance 1754 Monitoring): 1756 [RFC8532] defines a base YANG module for the management of OAM 1757 protocols that use Connectionless Communications. [RFC8533] 1758 defines a retrieval method YANG module for connectionless OAM 1759 protocols. [RFC8531] defines a base YANG module for connection 1760 oriented OAM protocols. These three models are intended to 1761 provide consistent reporting, configuration, and representation 1762 for connection-less OAM and Connection oriented OAM separately. 1764 Alarm monitoring is a fundamental part of monitoring the network. 1765 Raw alarms from devices do not always tell the status of the 1766 network services or necessarily point to the root cause. 1767 [RFC8632] defines a YANG module for alarm management. 1769 A.4. Device Models: Samples 1771 Network Element models (Figure 10) are used to describe how a service 1772 can be implemented by activating and tweaking a set of functions 1773 (enabled in one or multiple devices, or hosted in cloud 1774 infrastructures) that are involved in the service delivery. 1775 Figure 10 uses IETF-defined data models as an example. 1777 +------------------------+ 1778 +-+ Device Model | 1779 | +------------------------+ 1780 | +------------------------+ 1781 +---------------+ | | Logical Network | 1782 | | +-+ Element Model | 1783 | Architecture | | +------------------------+ 1784 | | | +------------------------+ 1785 +-------+-------+ +-+ Network Instance Model | 1786 | | +------------------------+ 1787 | | +------------------------+ 1788 | +-+ Routing Type Model | 1789 | +------------------------+ 1790 +-------+----------+----+------+------------+-----------+------+ 1791 | | | | | | | 1792 +-+-+ +---+---+ +----+----+ +--+--+ +----+----+ +--+--+ | 1793 |ACL| |Routing| |Transport| | OAM | |Multicast| | PM | Others 1794 +---+ +-+-----+ +----+----+ +--+--+ +-----+---+ +--+--+ 1795 | +-------+ | +------+ | +--------+ | +-----+ | +-----+ 1796 +-+Core | +-+ MPLS | +-+ BFD | +-+IGMP | +-+TWAMP| 1797 | |Routing| | | Base | | +--------+ | |/MLD | | +-----+ 1798 | +-------+ | +------+ | +--------+ | +-----+ | +-----+ 1799 | +-------+ | +------+ +-+LSP Ping| | +-----+ +-+OWAMP| 1800 +-+ BGP | +-+ MPLS | | +--------+ +-+ PIM | | +-----+ 1801 | +-------+ | | LDP | | +--------+ | +-----+ | +-----+ 1802 | +-------+ | +------+ +-+MPLS-TP | | +-----+ +-+LMAP | 1803 +-+ ISIS | | +------+ +--------+ +-+ MVPN| +-----+ 1804 | +-------+ +-+ MPLS | +-----+ 1805 | +-------+ |Static| 1806 +-+ OSPF | +------+ 1807 | +-------+ 1808 | +-------+ 1809 +-+ RIP | 1810 | +-------+ 1811 | +-------+ 1812 +-+ VRRP | 1813 | +-------+ 1814 | +-------+ 1815 +-+SR/SRv6| 1816 | +-------+ 1817 | +-------+ 1818 +-+ISIS-SR| 1819 | +-------+ 1820 | +-------+ 1821 +-+OSPF-SR| 1822 +-------+ 1824 Figure 10: Network Element Modules Overview 1826 A.4.1. Model Composition 1828 o Logical Network Element Model 1830 [RFC8530] defines a logical network element module which can be 1831 used to manage the logical resource partitioning that may be 1832 present on a network device. Examples of common industry terms 1833 for logical resource partitioning are Logical Systems or Logical 1834 Routers. 1836 o Network Instance Model 1838 [RFC8529] defines a network instance module. This module can be 1839 used to manage the virtual resource partitioning that may be 1840 present on a network device. Examples of common industry terms 1841 for virtual resource partitioning are VRF instances and Virtual 1842 Switch Instances (VSIs). 1844 A.4.2. Device Management 1846 The following list enumerates some YANG modules that can be used for 1847 device management: 1849 o [RFC8348]: defines a YANG module for the management of hardware. 1851 o [RFC7317]: defines the "ietf-system" YANG module that provides 1852 many features such as the configuration and the monitoring of 1853 system or system control operations (e.g., shutdown, restart, 1854 setting time) identification. 1856 o [RFC8341]: defines a network configuration access control YANG 1857 module. 1859 A.4.3. Interface Management 1861 The following provides some YANG modules that can be used for 1862 interface management: 1864 o [RFC7224]: defines a YANG module for interface type definitions. 1866 o [RFC8343]: defines a YANG module for the management of network 1867 interfaces. 1869 A.4.4. Some Device Model Examples 1871 The following provides an overview of some Device Models that can be 1872 used within a network. This list is not comprehensive. 1874 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS 1875 based Layer 2 VPN services (L2VPN) [RFC4664] and includes 1876 switching between the local attachment circuits. The 1877 L2VPN model covers point-to-point VPWS and Multipoint VPLS 1878 services. These services use signaling of Pseudowires 1879 across MPLS networks using LDP [RFC8077][RFC4762] or BGP 1880 [RFC4761]. 1882 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for 1883 Ethernet VPN services. The model is agnostic of the 1884 underlay. It applies to MPLS as well as to VxLAN 1885 encapsulation. The module is also agnostic to the 1886 services, including E-LAN, E-LINE, and E-TREE services. 1888 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can 1889 be used to configure and manage BGP L3VPNs [RFC4364]. It 1890 contains VRF specific parameters as well as BGP specific 1891 parameters applicable for L3VPNs. 1893 Core Routing: [RFC8349] defines the core routing YANG data model, 1894 which is intended as a basis for future data model 1895 development covering more-sophisticated routing systems. 1896 It is expected that other Routing technology YANG modules 1897 (e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core 1898 Routing base YANG module. 1900 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 1901 which serves as a base framework for configuring and 1902 managing an MPLS switching subsystem. It is expected that 1903 other MPLS technology YANG modules (e.g., MPLS LSP Static, 1904 LDP, or RSVP-TE models) will augment the MPLS base YANG 1905 module. 1907 BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for 1908 configuring and managing BGP, including protocol, policy, 1909 and operational aspects based on data center, carrier, and 1910 content provider operational requirements. 1912 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module 1913 for configuring and managing routing policies based on 1914 operational practice. The module provides a generic 1915 policy framework which can be augmented with protocol- 1916 specific policy configuration. 1918 SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment 1919 routing configuration and operation. 1921 BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a 1922 network protocol which is used for liveness detection of 1923 arbitrary paths between systems. [I-D.ietf-bfd-yang] 1924 defines a YANG module that can be used to configure and 1925 manage BFD. 1927 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 1928 to configure and manage Protocol Independent Multicast 1929 (PIM) devices. 1931 [RFC8652] defines a YANG module that can be used to 1932 configure and manage Internet Group Management Protocol 1933 (IGMP) and Multicast Listener Discovery (MLD) devices. 1935 [I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG 1936 module that can be used to configure and manage Internet 1937 Group Management Protocol (IGMP) and Multicast Listener 1938 Discovery (MLD) Snooping devices. 1940 [I-D.ietf-bess-mvpn-yang] defines a YANG data model to 1941 configure and manage Multicast in MPLS/BGP IP VPNs 1942 (MVPNs). 1944 PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for 1945 client and server implementations of the Two-Way Active 1946 Measurement Protocol (TWAMP). 1948 [I-D.ietf-ippm-stamp-yang] defines the data model for 1949 implementations of Session-Sender and Session-Reflector 1950 for Simple Two-way Active Measurement Protocol (STAMP) 1951 mode using YANG. 1953 [RFC8194] defines a YANG data model for Large-Scale 1954 Measurement Platforms (LMAPs). 1956 ACL: Access Control List (ACL) is one of the basic elements 1957 used to configure device forwarding behavior. It is used 1958 in many networking technologies such as Policy Based 1959 Routing, firewalls, etc. [RFC8519] describes a YANG data 1960 model of ACL basic building blocks. 1962 QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of 1963 Differentiated Services for configuration and operations. 1965 NAT: For the sake of network automation and the need for 1966 programming Network Address Translation (NAT) function in 1967 particular, a YANG data model for configuring and managing 1968 the NAT is essential. 1970 [RFC8512] defines a YANG module for the NAT function 1971 covering a variety of NAT flavors such as Network Address 1972 Translation from IPv4 to IPv4 (NAT44), Network Address and 1973 Protocol Translation from IPv6 Clients to IPv4 Servers 1974 (NAT64), customer-side translator (CLAT), Stateless IP/ 1975 ICMP Translation (SIIT), Explicit Address Mappings (EAM) 1976 for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), 1977 and Destination NAT. 1979 [RFC8513] specifies a DS-Lite YANG module. 1981 Stateless Address Sharing: [RFC8676] specifies a YANG module for A+P 1982 address sharing, including Lightweight 4over6, Mapping of 1983 Address and Port with Encapsulation (MAP-E), and Mapping 1984 of Address and Port using Translation (MAP-T) softwire 1985 mechanisms. 1987 Authors' Addresses 1989 Qin Wu (editor) 1990 Huawei 1991 101 Software Avenue, Yuhua District 1992 Nanjing, Jiangsu 210012 1993 China 1995 Email: bill.wu@huawei.com 1997 Mohamed Boucadair (editor) 1998 Orange 1999 Rennes 35000 2000 France 2002 Email: mohamed.boucadair@orange.com 2004 Diego R. Lopez 2005 Telefonica I+D 2006 Spain 2008 Email: diego.r.lopez@telefonica.com 2009 Chongfeng Xie 2010 China Telecom 2011 Beijing 2012 China 2014 Email: xiechf@chinatelecom.cn 2016 Liang Geng 2017 China Mobile 2019 Email: gengliang@chinamobile.com