idnits 2.17.1 draft-ietf-opsawg-model-automation-framework-00.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 (November 17, 2019) is 1622 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-teas-actn-pm-telemetry-autonomics' is mentioned on line 705, but not defined == Missing Reference: 'I-D.ietf-idr-bgp-yang-model' is mentioned on line 1393, but not defined == Unused Reference: 'I-D.arkko-arch-virtualization' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'I-D.clacla-netmod-model-catalog' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'I-D.homma-slice-provision-models' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-yang' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-alarm-module' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-media-channel-yang' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-yang' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-l1csm-yang' is defined on line 833, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-mw-yang' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-otn-topo-yang' is defined on line 845, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-otn-tunnel-model' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-wson-tunnel-model' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-model' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-stamp-yang' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-twamp-yang' is defined on line 885, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pim-igmp-mld-snooping-yang' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-device-model' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-data-model' is defined on line 940, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-actn-vn-yang' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-sf-aware-topo-model' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-te-service-mapping-yang' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-l3-te-topo' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-path-computation' is defined on line 969, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-rsvp-te' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-sr-te-topo' is defined on line 980, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 986, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 992, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-homma-slice-provision-models-01 == Outdated reference: A later version (-05) exists of draft-ietf-bess-l3vpn-yang-04 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-flexigrid-media-channel-yang-02 == Outdated reference: A later version (-16) exists of draft-ietf-ccamp-flexigrid-yang-04 == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-10 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-09 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-09 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-wson-tunnel-model-04 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-38 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-07 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-stamp-yang-05 == Outdated reference: A later version (-17) exists of draft-ietf-mpls-base-yang-11 == Outdated reference: A later version (-20) exists of draft-ietf-pim-igmp-mld-snooping-yang-08 == Outdated reference: A later version (-31) exists of draft-ietf-rtgwg-policy-model-07 == Outdated reference: A later version (-30) exists of draft-ietf-spring-sr-yang-13 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-07 == Outdated reference: A later version (-12) exists of draft-ietf-teas-sf-aware-topo-model-03 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-02 == Outdated reference: A later version (-16) exists of draft-ietf-teas-yang-l3-te-topo-05 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-06 == Outdated reference: A later version (-09) exists of draft-ietf-teas-yang-rsvp-te-07 == Outdated reference: A later version (-18) exists of draft-ietf-teas-yang-sr-te-topo-05 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-22 Summary: 0 errors (**), 0 flaws (~~), 53 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Q. Wu, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational M. Boucadair, Ed. 5 Expires: May 20, 2020 Orange 6 D. Lopez 7 Telefonica I+D 8 C. Xie 9 China Telecom 10 L. Geng 11 China Mobile 12 November 17, 2019 14 A Framework for Automating Service and Network Management with YANG 15 draft-ietf-opsawg-model-automation-framework-00 17 Abstract 19 Data models for service and network management provides a 20 programmatic approach for representing (virtual) services or networks 21 and deriving (1) configuration information that will be communicated 22 to network and service components that are used to build and deliver 23 the service and (2) state information that will be monitored and 24 tracked. Indeed, data models can be used during various phases of 25 the service and network management life cycle, such as service 26 instantiation, service provisioning, optimization, monitoring, and 27 diagnostic. Also, data models are instrumental in the automation of 28 network management. They also provide closed-loop control for the 29 sake of adaptive and deterministic service creation, delivery, and 30 maintenance. 32 This document provides a framework that describes and discusses an 33 architecture for service and network management automation that takes 34 advantage of YANG modeling technologies. This framework is drawn 35 from a network provider perspective irrespective of the origin of a 36 data module; it can accommodate even modules that are developed 37 outside the IETF. 39 The document aims to exemplify an approach that specifies the journey 40 from technology-agnostic services to technology-specific actions. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on May 20, 2020. 59 Copyright Notice 61 Copyright (c) 2019 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Architectural Concepts & Goals . . . . . . . . . . . . . . . 5 79 3.1. Data Models: Layering and Representation . . . . . . . . 5 80 3.2. Automation of Service Delivery Procedures . . . . . . . . 7 81 3.3. Service Fullfillment Automation . . . . . . . . . . . . . 8 82 3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 8 83 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 84 4.1. Service Lifecycle Management Procedure . . . . . . . . . 10 85 4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 11 86 4.1.2. Service Creation/Modification . . . . . . . . . . . . 11 87 4.1.3. Service Optimization . . . . . . . . . . . . . . . . 11 88 4.1.4. Service Diagnosis . . . . . . . . . . . . . . . . . . 12 89 4.1.5. Service Decommission . . . . . . . . . . . . . . . . 12 90 4.2. Service Fullfillment Management Procedure . . . . . . . . 12 91 4.2.1. Intended Configuration Provision . . . . . . . . . . 12 92 4.2.2. Configuration Validation . . . . . . . . . . . . . . 13 93 4.2.3. Performance Monitoring . . . . . . . . . . . . . . . 13 94 4.2.4. Fault Diagnostic . . . . . . . . . . . . . . . . . . 14 95 4.3. Multi-layer/Multi-domain Service Mapping . . . . . . . . 14 96 4.4. Service Decomposing . . . . . . . . . . . . . . . . . . . 14 98 5. YANG Data Model Integration Examples . . . . . . . . . . . . 14 99 5.1. L3VPN Service Delivery . . . . . . . . . . . . . . . . . 14 100 5.2. VN Lifecycle Management Example . . . . . . . . . . . . . 16 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 104 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 105 10. Informative References . . . . . . . . . . . . . . . . . . . 18 106 Appendix A. Layered YANG Modules Example Overview . . . . . . . 26 107 A.1. Service Models: Definition and Samples . . . . . . . . . 26 108 A.2. Network Models: Definitions and Samples . . . . . . . . . 27 109 A.3. Device Models: Definitions and Samples . . . . . . . . . 30 110 A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 31 111 A.3.2. Device Models: Definitions and Samples . . . . . . . 31 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 114 1. Introduction 116 The service management system usually comprises service activation/ 117 provision and service operation. Current service delivery 118 procedures, from the processing of customer's requirements and order 119 to service delivery and operation, typically assume the manipulation 120 of data sequentially into multiple OSS/BSS applications that may be 121 managed by different departments within the service provider's 122 organization (e.g., billing factory, design factory, network 123 operation center, etc.). In addition, many of these applications 124 have been developed in-house over the years and operating in a silo 125 mode: 127 o The lack of standard data input/output (i.e., data model) also 128 raises many challenges in system integration and often results in 129 manual configuration tasks. 131 o Secondly, many current service fulfillment system might have limit 132 visibility to the network and therefore have slow response to the 133 network changes. 135 Software Defined Networking (SDN) becomes crucial to address these 136 challenges. SDN techniques [RFC7149] are meant to automate the 137 overall service delivery procedures and typically rely upon 138 (standard) data models that are used to not only reflect service 139 providers'savoir-faire but also to dynamically instantiate and 140 enforce a set of (service-inferred) policies that best accommodate 141 what has been (contractually) defined (and possibly negotiated) with 142 the customer. [RFC7149] provides a first tentative to rationalize 143 that service provider's view on the SDN space by identifying concrete 144 technical domains that need to be considered and for which solutions 145 can be provided: 147 o Techniques for the dynamic discovery of topology, devices, and 148 capabilities, along with relevant information and data models that 149 are meant to precisely document such topology, devices, and their 150 capabilities. 152 o Techniques for exposing network services [RFC8309] and their 153 characteristics. 155 o Techniques used by service-requirement-derived dynamic resource 156 allocation and policy enforcement schemes, so that networks can be 157 programmed accordingly. 159 o Dynamic feedback mechanisms that are meant to assess how 160 efficiently a given policy (or a set thereof) is enforced from a 161 service fulfillment and assurance perspective. 163 Models are key for each of these technical items. Service and 164 network management automation is an important step to improve the 165 agility of network operations and infrastructures. Models are also 166 important to ease integrating multi-vendor solutions. 168 YANG module developers have taken both top-down and bottom-up 169 approaches to develop modules [RFC8199], and also to establish a 170 mapping between network technology and customer requirements on the 171 top or abstracting common construct from various network technologies 172 on the bottom. At the time of writing this document (2019), there 173 are many data models including configuration and service models that 174 have been specified or are being specified by the IETF. They cover 175 many of the networking protocols and techniques. However, how these 176 models work together to configure a device, manage a set of devices 177 involved in a service, or even provide a service is something that is 178 not currently documented either within the IETF or other SDOs (e.g., 179 MEF). 181 This document provides a framework that describes and discusses an 182 architecture for service and network management automation that takes 183 advantage of YANG modeling technologies and investigates how 184 different layer YANG data models interact with each other (e.g., 185 service mapping, model composing) in the context of service delivery 186 and fulfillment. 188 This framework is drawn from a network provider perspective 189 irrespective of the origin of a data module; it can accommodate even 190 modules that are developed outside the IETF. 192 The document also identifies a list of use cases to exemplify the 193 proposed approach, but it does not claim to be exhaustive. 195 2. Terminology 197 The following terms are defined in [RFC8309][RFC8199] and are not 198 redefined here: 200 o Network Operator 202 o Customer 204 o Service 206 o Data Model 208 o Service Model 210 o Network Element Module 212 The document makes use of the following terms: 214 Network Model: The Network Model describes network level abstraction 215 or various aspects of a network infrastructure, including devices 216 and their subsystems, and relevant protocols operating at the link 217 and network layers across multiple devices. It can be used by a 218 network operator to allocate the resource(e.g., tunnel resource, 219 topology resource) for the service or schedule the resource to 220 meet the service requirements define in the Service Model. 222 Device Model: Network Element YANG data module described in 223 [RFC8199]. 225 3. Architectural Concepts & Goals 227 3.1. Data Models: Layering and Representation 229 As described in [RFC8199], layering of modules allows for better 230 reusability of lower-layer modules by higher-level modules while 231 limiting duplication of features across layers. 233 The data modules developed by IETF can be classified into service 234 level, network level and device level modules. Different service 235 module at service level may rely on the same set of network level or 236 device level modules. 238 Service level modules usually follow top down approach and are mostly 239 customer-facing modules providing a common model construct for higher 240 level network services (e.g., L3VPN), which can be further mapped to 241 network technology-specific modules at lower layer (e.g., tunnel, 242 routing, QoS, security). For example, the service level can be used 243 to characterise the network service(s) to be ensured between service 244 nodes (ingress/egress) such as the communication scope (pipe, hose, 245 funnel, ...), the directionality, the traffic performance guarantees 246 (one-way delay (OWD), one-way loss, ...), etc. 248 Network level modules are mainly network resource-facing modules and 249 describe various aspects of a network infrastructure, including 250 devices and their subsystems, and relevant protocols operating at the 251 link and network layers across multiple devices (e.g., Network 252 topology and traffic- engineering Tunnel modules). 254 Device (and function) level modules usually follow a bottom-up 255 approach and are mostly technology-specific modules used to realize a 256 service (e.g., BGP, NAT). 258 Each level maintains a view of the supported YANG modules provided by 259 low-levels (see for example, Appendix A). 261 Figure 1 illustrates the overall layering model. 263 +-----------------------------------------------------------------+ 264 | +-----------------------+ | 265 | | Orchestrator | Hierarchy Abstraction | 266 | |+---------------------+| | 267 | || Service Modeling || Service Model | 268 | |+---------------------+| (Customer Oriented) | 269 | | | Scope: "1:1" Pipe model | 270 | | | Bidirectional | 271 | |+---------------------+| +-+ BW:100M,OWD +-+ | 272 | ||Service Orchestration|| | +---------------+ | | 273 | |+---------------------+| +-+ +-+ | 274 | +-----------------------+ 1. Ingress 2. Egress | 275 | | 276 | | 277 | | 278 | +-----------------------+ Network Model | 279 | | Controller | (Operator Oriented) | 280 | |+---------------------+| +-+ +--+ +---+ +-+ | 281 | || Network Modeling || | | | | | | | | | 282 | |+---------------------+| | o----o--o----o---o---o | | 283 | |+---------------------+| +-+ +--+ +---+ +-+ | 284 | ||network Orchestration| src dst | 285 | |+---------------------+| L3VPN over TE | 286 | | | Instance Name/Access Interface| 287 | +-----------------------+ Proto Type/BW/RD,RT,..mapping | 288 | for hop | 289 | | 290 | | 291 | +-----------------------+ | 292 | | Device | Device Model | 293 | |+--------------------+ | | 294 | || Device Modeling | | Interface add,BGP Peer, | 295 | |+--------------------+ | Tunnel id,QoS/TE config | 296 | +-----------------------+ | 297 +-----------------------------------------------------------------+ 299 Layering and representation 301 3.2. Automation of Service Delivery Procedures 303 To dynamically offer and deliver service offerings, Service level 304 modules can be used by an operator. One or more monolithic Service 305 modules can be used in the context of a composite service activation 306 request (e.g., delivery of a caching infrastructure over a VPN). 307 Such modules are used to feed a decision-making intelligence to 308 adequately accommodate customer's needs. 310 Also, such modules may be used jointly with services that require 311 dynamic invocation. An example is provided by the service modules 312 defined by the DOTS WG to dynamically trigger requests to handle DDoS 313 attacks [I-D.ietf-dots-signal-channel][I-D.ietf-dots-data-channel]. 315 Network level modules can be derived from service level modules and 316 used to provision, monitor, instantiate the service, and provide 317 lifecycle management of network resources (e.g., expose network 318 resources to customers or operators to provide service fulfillment 319 and assurance and allow customers or operators to dynamically adjust 320 the network resources based on service requirements as described in 321 service level modules and the current network performance information 322 described in the telemetry modules). 324 3.3. Service Fullfillment Automation 326 To operate the service, Device level modules derived from Service 327 level modules or Network level modules can be used to provision each 328 involved network function/device with the proper configuration 329 information, and operate the network based on service requirements as 330 described in the Service level module(s). 332 In addition, the operational state including configuration that is in 333 effect together with statistics should be exposed to upper layers to 334 provide better network visibility (and assess to what extent the 335 derived low level modules are consistent with the upper level 336 inputs). 338 Note that it is important to correlate telemetry data with 339 configuration data to be used for closed loops at the different 340 stages of service delivery, from resource allocation to service 341 operation, in particular. 343 3.4. YANG Modules Integration 345 To support top-down service delivery, YANG modules at different level 346 or at the same level need to be integrated together to enable 347 function, feature in the network device and get network setup. For 348 example, the service parameters captured in service level modules 349 need to be decomposed into a set of (configuration/notification) 350 parameters that may be specific to one or more technologies; these 351 technology-specific parameters are grouped together to define 352 technology-specific device level models or network level models. 354 In addition, these technology-specific device level models or network 355 level models can be further integrated with each other using schema 356 mount mechanism [RFC8528] to provision each involved network 357 function/device or each involved administrative domain to support 358 newly added module or features. A collection of device models 359 integrated together can be loaded and validated during implementation 360 time. 362 Policies provide a higher layer of abstraction. Policy models can be 363 defined at service level, network level, or device level to provide 364 policy-based management and telemetry automation,e.g., telemetry data 365 can trigger a new policy that captures new network service 366 requirements. 368 Performance measurement telemetry can be used to provide service 369 assurance at service level or at the network level. Performance 370 measurement telemetry model can tie with network level model or 371 service level model to monitor network performance or service level 372 agreement. 374 4. Architecture Overview 376 The architectural considerations described in Section 3 lead to the 377 architecture described in this section and illustrated in Figure 1. 379 +------------------+ 380 Service level | | 381 ----------- V | 382 E2E E2E E2E 383 Service -- Service --------> Service --->Service ---+ 384 Exposure Creation ^ Optimization | Diagnosis | 385 /Modification | | | 386 | |Diff | V 387 Multi-layer | | E2E | E2E 388 Multi-domain | | Service | Service 389 Service Mapping| +------ Assurance ---+ Decommission 390 | ^ 391 |<-----------------+ | 392 Network level | | +----+ 393 ------------ V | | 394 Specific Specific | Specific 395 Service ----+---> Service ---+--+-> Service --+ 396 Creation ^ Optimization | | Diagnosis | 397 /Modification | | | V 398 | |Diff | | Specific 399 | | Specific----+ | Service 400 Service | | Service | Decommission 401 Decomposing | +------Assurance -----+ 402 | ^ 403 | | Aggregation 404 Device level | +------------+ 405 ------------ V | 406 Service Intent 407 Fullfillment Config ------> Config ----> Performance -->Fault 408 Provision Validate Monitoring Diagnostic 410 Figure 1: Service and Network Lifecycle Management 412 4.1. Service Lifecycle Management Procedure 414 Service lifecycle management includes end to end service lifecycle 415 management at the service level and specific network lifecycle 416 management at the network level. The end-to-end service lifecycle 417 management is multi-domain or multi-layer service management while 418 specific service lifecycle management is domain specific or layer 419 specific service lifecycle management. 421 o Note: Clarify what is meant by "domain". 423 4.1.1. Service Exposure 425 A service in the context of this document (sometimes called a Network 426 Service) is some form of connectivity between customer sites and the 427 Internet or between customer sites across the network operator's 428 network and across the Internet. 430 Service exposure is used to capture services offered to customers 431 (ordering and order handling). One typical example is that a 432 customer can use a L3SM service model to request L3VPN service by 433 providing the abstract technical characterization of the intended 434 service between cutsomer sites. 436 Service model catalogs can be created along to expose the various 437 services and the information needed to invoke/order a given service. 439 4.1.2. Service Creation/Modification 441 A customer is (usually) unaware of the technology that the network 442 operator has available to deliver the service, so the customer does 443 not make requests specific to the underlying technology but is 444 limited to making requests specific to the service that is to be 445 delivered. This service request can be issued using the service 446 model. 448 The service orchestrator/management system maps such service request 449 to its view. This view can be described as a network model and this 450 mapping may include a choice of which networks and technologies to 451 use depending on which service features have been requested. 453 In addition, a customer may require to change underlying network 454 infrastructure to adapt to new customer's needs and service 455 requirements. This service modification can be issued in the same 456 service model used by the service request. 458 4.1.3. Service Optimization 460 Service optimization is a technique that gets the configuration of 461 the network updated due to network change, incident mitigation, or 462 new service requirements. One typical example is once the tunnel or 463 the VPN is setup, Performance monitoring information or telemetry 464 information per tunnel or per VPN can be collected and fed into the 465 management system, if the network performance doesn't meet the 466 service requirements, the management system can create new VPN 467 policies capturing network service requirements and populate them 468 into the network. 470 Both network performance information and policies can be modelled 471 using YANG. With Policy-based management, self-configuration and 472 self-optimization behavior can be specified and implemented. 474 4.1.4. Service Diagnosis 476 Operations, Administration, and Maintenance (OAM) are important 477 networking functions for service diagnosis that allow operators to: 479 o monitor network communications (i.e., reachability verification 480 and Continuity Check) 482 o troubleshoot failures (i.e., fault verification and localization) 484 o monitor service-level agreements and performance (i.e., 485 performance management) 487 When the network is down, service diagnosis should be in place to 488 pinpoint the problem and provide recommendation (or instructions) for 489 the network recovery. 491 The service diagnosis information can be modelled as technology- 492 independent RPC operations for OAM protocols and technology- 493 independent abstraction of key OAM constructs for OAM protocols 494 [RFC8531][RFC8533]. These models can provide consistent 495 configuration, reporting, and presentation for the OAM mechanisms 496 used to manage the network. 498 4.1.5. Service Decommission 500 Service decommission allow the customer to stop the service and 501 remove the service from active status and release the network 502 resource that is allocated to the service. Customer can also use the 503 service model to withdraw the subscription to a service. 505 4.2. Service Fullfillment Management Procedure 507 4.2.1. Intended Configuration Provision 509 Intended configuration at the device level is derived from network 510 model at the network level or service model at the service level and 511 represents the configuration that the system attempts to apply. Take 512 L3SM service model as an example, to deliver a L3VPN service, we need 513 to map L3VPN service view defined in Service model into detailed 514 intended configuration view defined by specific configuration models 515 for network elements, configuration information includes: 517 o VRF definition, including VPN Policy expression 518 o Physical Interface 520 o IP layer (IPv4, IPv6) 522 o QoS features such as classification, profiles, etc. 524 o Routing protocols: support of configuration of all protocols 525 listed in the document, as well as routing policies associated 526 with those protocols. 528 o Multicast Support 530 o NAT or address sharing 532 o Security function 534 This specific configuration models can be used to configure PE and CE 535 devices within the site, e.g., A BGP policy model can be used to 536 establish VPN membership between sites and VPN Service Topology. 538 4.2.2. Configuration Validation 540 Configuration validation is used to validate intended configuration 541 and ensure the configuration take effect. For example, a customer 542 creates an interface "et-0/0/0" but the interface does not physically 543 exist at this point, then configuration data appears in the 544 status but does not appear in datastore. 546 4.2.3. Performance Monitoring 548 When configuration is in effect in the device, 549 datastore holds the complete operational state of the device 550 including learned, system, default configuraton and system state. 551 However the configurations and state of a particular device does not 552 have the visibility to the whole network or information of the flow 553 packets are going to take through the entire network. Therefore it 554 becomes more difficult to operate the network without understanding 555 the current status of the network. 557 The management system should subscribe to updates of a YANG datastore 558 in all the network devices for performance monitoring purpose and 559 build full topological visibility to the network by aggregating and 560 filtering these operational state from different sources. 562 4.2.4. Fault Diagnostic 564 When configuration is in effect in the device, some device may be 565 misconfigured(e.g.,device links are not consistent on both sides of 566 the network connection), network resources be misallocated and 567 services may be negatively affected without knowing what is going on 568 in the network. 570 Technology-dependent nodes and remote procedure call (RPC) commands 571 are defined in technology-specific YANG data models which can use and 572 extend the base model described in Section 4.1.4can be used to deal 573 with these challenges. 575 These RPC command recieved in the technology dependent node can be 576 used to trigger technology specific OAM message exchange for fault 577 verification and fault isolation,e.g., TRILL Multicast Tree 578 Verification (MTV) RPC command [I-D.ietf-trill-yang-oam] can be used 579 to trigger Multi-Destination Tree Verification Message defined in 580 [RFC7455] to verify TRILL distribution tree integrity. 582 4.3. Multi-layer/Multi-domain Service Mapping 584 Multi-layer/Multi-domain Service Mapping allow you map end to end 585 abstract view of the service segmented at different layer or 586 different administrative domain into domain specific view. One 587 example is to map service parameters in L3VPN service model into 588 configuration parameters such as RD, RT, and VRF in L3VPN network 589 model. Another example is to map service parameters in L3VPN service 590 model into TE tunnel parameter (e.g.,Tunnel ID) in TE model and VN 591 parameters (e.g., AP list, VN member) in TEAS VN model [I-D.ietf- 592 teas-actn-vn-yang]. 594 4.4. Service Decomposing 596 Service Decomposing allows to decompose service model at the service 597 level or network model at the network level into a set of device/ 598 function models at the device level. These device models may be tied 599 to specific device type or classified into a collection of related 600 YANG modules based on service type and feature offered and load at 601 the implementation time before configuration is loaded and validated. 603 5. YANG Data Model Integration Examples 605 5.1. L3VPN Service Delivery 606 L3SM | 607 Service | 608 Model | 609 +--------------------+----------------------------+ 610 | +-----V- -------+ | 611 | Orchestrator |Service Mapping| | 612 | +-----+---------+ | 613 | | | 614 +--------------------+----------------------------+ 615 L3NM | 616 Network| 617 Model | 618 +--------------------+----------------------------+ 619 | Controller+--------V-----------+ | 620 | | Service Decomposing| | 621 | +-++------------++---+ | 622 | || || | 623 | || || | 624 +-------------++---------- ++--------------------+ 625 || || 626 || || 627 ||BGP,QoS || 628 || || 629 +----------+|NI,Intf,IP |+-----------------+ 630 +--+--+ +++---+ --+---+ +--+--+ 631 | CE1 |------| PE1 | | PE2 | ---------+ CE2 | 632 +-----+ +-----+ +-----+ +-----+ 634 Figure 2: L3VPN Service Delivery Example 636 In reference to Figure 2, the following steps are performed to 637 deliver the L3VPN service within the network management automation 638 architecture defined in this document: 640 1. Customer Requests to create two sites based on L3SM Service model 641 with each having one network access connectivity: 643 Site A: Network-Access A, Bandwidth=20M, for class "foo", 644 guaranteed-bw-percent = 10, One-Way-Delay=70 msec 646 Site B: Network-Access B, Bandwidth=30M, for class "foo1", 647 guaranteed-bw-percent = 15, One-Way-Delay=60 msec 649 2. The Orchestrator extracts the service parameters from the L3SM 650 model. Then, it uses them as input to translate them into an 651 orchestrated configuration of network elements (e.g., RD, RT, 652 VRF, etc.) that is part of the L3NM network model. 654 3. The Controller takes orchestrated configuration parameters in the 655 L3NM network model and translates them into orchestrated 656 configuration of network elements that is part of BGP model, QoS 657 model, Network Instance model, IP management model, interface 658 model, etc. 660 5.2. VN Lifecycle Management Example 662 | 663 VN | 664 Service | 665 Model | 666 +------------------- --|--------------------------+ 667 | Orchestrator | | 668 | +--------V--------+ +----------+ | 669 | | Service Mapping | +-+ECA Engine| | 670 | +-----------------+ | +--------^-+ | 671 +----------------------+----------+----------+----+ 672 TE | ECA | Telemetry 673 Tunnel | Policy| Model 674 Model | | | 675 +----------------------V----------V----------+----+ 676 | Controller | 677 | | 678 +-------------------------------------------------+ 680 +-----+ +-----+ +-----+ +-----+ 681 | CE1 |------| PE1 | | PE2 |---------+ CE2 | 682 +-----+ +-----+ +-----+ +-----+ 684 Figure 3 686 In reference to Figure 3, the following steps are performed to 687 deliver the VN service within the network management automation 688 architecture defined in this document: 690 1. Customer requests to create 'VN' based on Access point, 691 association between VN and Access point, VN member defined in the 692 VN YANG module. 694 2. The orchestrator creates the single abstract node topology based 695 on the information captured in an VN YANG module. 697 3. The Customer exchanges connectivity-matrix on abstract node and 698 explicit path using TE topology model with the orchestrator. 699 This information can be used to instantiate VN and setup tunnels 700 between source and destination endpoints. 702 4. The telemetry which augments the TEAS VN model and corresponding 703 TE Tunnel model can be used to notify all the parameter changes 704 and network performance change related to VN topology or Tunnel 705 [I-D.ietf-teas-actn-pm-telemetry-autonomics]. This information 706 can be further used as input to ECA engine in the orchestrator 707 and generate ECA policy model to optimize the network. 709 6. Security Considerations 711 Security considerations specific to each of the technologies and 712 protocols listed in the document are discussed in the specification 713 documents of each of these techniques. 715 (Potential) security considerations specific to this document are 716 listed below: 718 o Create forwarding loops by mis-configuring the underlying network. 720 o Leak sensitive information: special care should be considered when 721 translating between the various layers introduced in the document. 723 o ...tbc 725 7. IANA Considerations 727 There are no IANA requests or assignments included in this document. 729 8. Acknowledgements 731 Thanks to Joe Clark, Greg Mirsky, and Shunsuke Homma for the review. 733 9. Contributors 734 Christian Jacquenet 735 Orange 736 Rennes, 35000 737 France 738 Email: Christian.jacquenet@orange.com 740 Luis Miguel Contreras Murillo 741 Telifonica 743 Email: luismiguel.contrerasmurillo@telefonica.com 745 Oscar Gonzalez de Dios 746 Telefonica 747 Madrid 748 ES 750 Email: oscar.gonzalezdedios@telefonica.com 752 Chongfeng Xie 753 China Telecom 754 Beijing 755 China 757 Email: xiechf.bri@chinatelecom.cn 759 Weiqiang Cheng 760 China Mobile 762 Email: chengweiqiang@chinamobile.com 764 Young Lee 765 Sung Kyun Kwan University 767 Email: younglee.tx@gmail.com 769 10. Informative References 771 [I-D.arkko-arch-virtualization] 772 Arkko, J., Tantsura, J., Halpern, J., and B. Varga, 773 "Considerations on Network Virtualization and Slicing", 774 draft-arkko-arch-virtualization-01 (work in progress), 775 March 2018. 777 [I-D.asechoud-netmod-diffserv-model] 778 Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N. 779 Strahle, "YANG Model for Diffserv", draft-asechoud-netmod- 780 diffserv-model-03 (work in progress), June 2015. 782 [I-D.clacla-netmod-model-catalog] 783 Clarke, J. and B. Claise, "YANG module for 784 yangcatalog.org", draft-clacla-netmod-model-catalog-03 785 (work in progress), April 2018. 787 [I-D.homma-slice-provision-models] 788 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 789 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 790 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 791 Foy, "Network Slice Provision Models", draft-homma-slice- 792 provision-models-01 (work in progress), July 2019. 794 [I-D.ietf-bess-evpn-yang] 795 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 796 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 797 bess-evpn-yang-07 (work in progress), March 2019. 799 [I-D.ietf-bess-l2vpn-yang] 800 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 801 and K. Tiruveedhula, "YANG Data Model for MPLS-based 802 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 803 July 2019. 805 [I-D.ietf-bess-l3vpn-yang] 806 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 807 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 808 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 809 in progress), October 2018. 811 [I-D.ietf-bfd-yang] 812 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 813 and G. Mirsky, "YANG Data Model for Bidirectional 814 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 815 in progress), August 2018. 817 [I-D.ietf-ccamp-alarm-module] 818 Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft- 819 ietf-ccamp-alarm-module-09 (work in progress), April 2019. 821 [I-D.ietf-ccamp-flexigrid-media-channel-yang] 822 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 823 King, D., Lee, Y., and G. Galimberti, "YANG data model for 824 Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid- 825 media-channel-yang-02 (work in progress), March 2019. 827 [I-D.ietf-ccamp-flexigrid-yang] 828 Madrid, U., Perdices, D., Lopezalvarez, V., King, D., and 829 Y. Lee, "YANG data model for Flexi-Grid Optical Networks", 830 draft-ietf-ccamp-flexigrid-yang-04 (work in progress), 831 July 2019. 833 [I-D.ietf-ccamp-l1csm-yang] 834 Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. 835 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 836 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in 837 progress), September 2019. 839 [I-D.ietf-ccamp-mw-yang] 840 Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M. 841 Vaupotic, "A YANG Data Model for Microwave Radio Link", 842 draft-ietf-ccamp-mw-yang-13 (work in progress), November 843 2018. 845 [I-D.ietf-ccamp-otn-topo-yang] 846 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Dios, "A 847 YANG Data Model for Optical Transport Network Topology", 848 draft-ietf-ccamp-otn-topo-yang-09 (work in progress), 849 November 2019. 851 [I-D.ietf-ccamp-otn-tunnel-model] 852 Zheng, H., Busi, I., Belotti, S., Lopezalvarez, V., and Y. 853 Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 854 model-09 (work in progress), November 2019. 856 [I-D.ietf-ccamp-wson-tunnel-model] 857 Lee, Y., Zheng, H., Guo, A., Lopezalvarez, V., King, D., 858 Yoon, B., and R. Vilata, "A Yang Data Model for WSON 859 Tunnel", draft-ietf-ccamp-wson-tunnel-model-04 (work in 860 progress), September 2019. 862 [I-D.ietf-dots-data-channel] 863 Boucadair, M. and R. K, "Distributed Denial-of-Service 864 Open Threat Signaling (DOTS) Data Channel Specification", 865 draft-ietf-dots-data-channel-31 (work in progress), July 866 2019. 868 [I-D.ietf-dots-signal-channel] 869 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 870 Teague, "Distributed Denial-of-Service Open Threat 871 Signaling (DOTS) Signal Channel Specification", draft- 872 ietf-dots-signal-channel-38 (work in progress), October 873 2019. 875 [I-D.ietf-idr-bgp-model] 876 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 877 YANG Model for Service Provider Networks", draft-ietf-idr- 878 bgp-model-07 (work in progress), October 2019. 880 [I-D.ietf-ippm-stamp-yang] 881 Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active 882 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 883 stamp-yang-05 (work in progress), October 2019. 885 [I-D.ietf-ippm-twamp-yang] 886 Civil, R., Morton, A., Rahman, R., Jethanandani, M., and 887 K. Pentikousis, "Two-Way Active Measurement Protocol 888 (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work 889 in progress), July 2018. 891 [I-D.ietf-mpls-base-yang] 892 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 893 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 894 yang-11 (work in progress), September 2019. 896 [I-D.ietf-pim-igmp-mld-snooping-yang] 897 Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, 898 "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- 899 pim-igmp-mld-snooping-yang-08 (work in progress), June 900 2019. 902 [I-D.ietf-pim-igmp-mld-yang] 903 Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 904 Peter, "A YANG Data Model for Internet Group Management 905 Protocol (IGMP) and Multicast Listener Discovery (MLD)", 906 draft-ietf-pim-igmp-mld-yang-15 (work in progress), June 907 2019. 909 [I-D.ietf-pim-yang] 910 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 911 Y., and f. hu, "A YANG Data Model for Protocol Independent 912 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 913 progress), May 2018. 915 [I-D.ietf-rtgwg-device-model] 916 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 917 "Network Device YANG Logical Organization", draft-ietf- 918 rtgwg-device-model-02 (work in progress), March 2017. 920 [I-D.ietf-rtgwg-policy-model] 921 Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data 922 Model for Routing Policy Management", draft-ietf-rtgwg- 923 policy-model-07 (work in progress), September 2019. 925 [I-D.ietf-softwire-iftunnel] 926 Boucadair, M., Farrer, I., and R. Asati, "Tunnel Interface 927 Types YANG Module", draft-ietf-softwire-iftunnel-07 (work 928 in progress), June 2019. 930 [I-D.ietf-softwire-yang] 931 Farrer, I. and M. Boucadair, "YANG Modules for IPv4-in- 932 IPv6 Address plus Port (A+P) Softwires", draft-ietf- 933 softwire-yang-16 (work in progress), January 2019. 935 [I-D.ietf-spring-sr-yang] 936 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 937 Tantsura, "YANG Data Model for Segment Routing", draft- 938 ietf-spring-sr-yang-13 (work in progress), July 2019. 940 [I-D.ietf-supa-generic-policy-data-model] 941 Halpern, J. and J. Strassner, "Generic Policy Data Model 942 for Simplified Use of Policy Abstractions (SUPA)", draft- 943 ietf-supa-generic-policy-data-model-04 (work in progress), 944 June 2017. 946 [I-D.ietf-teas-actn-vn-yang] 947 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 948 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 949 teas-actn-vn-yang-07 (work in progress), October 2019. 951 [I-D.ietf-teas-sf-aware-topo-model] 952 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, 953 L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology 954 YANG Model", draft-ietf-teas-sf-aware-topo-model-03 (work 955 in progress), March 2019. 957 [I-D.ietf-teas-te-service-mapping-yang] 958 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 959 and J. Tantsura, "Traffic Engineering (TE) and Service 960 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 961 yang-02 (work in progress), September 2019. 963 [I-D.ietf-teas-yang-l3-te-topo] 964 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 965 O. Dios, "YANG Data Model for Layer 3 TE Topologies", 966 draft-ietf-teas-yang-l3-te-topo-05 (work in progress), 967 July 2019. 969 [I-D.ietf-teas-yang-path-computation] 970 Busi, I. and S. Belotti, "Yang model for requesting Path 971 Computation", draft-ietf-teas-yang-path-computation-06 972 (work in progress), July 2019. 974 [I-D.ietf-teas-yang-rsvp-te] 975 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 976 and H. Shah, "A YANG Data Model for RSVP-TE Protocol", 977 draft-ietf-teas-yang-rsvp-te-07 (work in progress), July 978 2019. 980 [I-D.ietf-teas-yang-sr-te-topo] 981 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 982 S. Litkowski, "YANG Data Model for SR and SR TE 983 Topologies", draft-ietf-teas-yang-sr-te-topo-05 (work in 984 progress), July 2019. 986 [I-D.ietf-teas-yang-te] 987 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 988 "A YANG Data Model for Traffic Engineering Tunnels and 989 Interfaces", draft-ietf-teas-yang-te-22 (work in 990 progress), November 2019. 992 [I-D.ietf-teas-yang-te-topo] 993 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 994 O. Dios, "YANG Data Model for Traffic Engineering (TE) 995 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 996 progress), June 2019. 998 [I-D.ietf-trill-yang-oam] 999 Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., 1000 and H. Weiguo, "YANG Data Model for TRILL Operations, 1001 Administration, and Maintenance (OAM)", draft-ietf-trill- 1002 yang-oam-05 (work in progress), March 2017. 1004 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1005 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1006 2006, . 1008 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1009 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1010 DOI 10.17487/RFC4664, September 2006, 1011 . 1013 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1014 LAN Service (VPLS) Using BGP for Auto-Discovery and 1015 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1016 . 1018 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1019 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1020 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1021 . 1023 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1024 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1025 . 1027 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1028 Networking: A Perspective from within a Service Provider 1029 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1030 . 1032 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1033 Weingarten, "An Overview of Operations, Administration, 1034 and Maintenance (OAM) Tools", RFC 7276, 1035 DOI 10.17487/RFC7276, June 2014, 1036 . 1038 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1039 Connectivity Provisioning Profile (CPP)", RFC 7297, 1040 DOI 10.17487/RFC7297, July 2014, 1041 . 1043 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 1044 3rd, D., Aldrin, S., and Y. Li, "Transparent 1045 Interconnection of Lots of Links (TRILL): Fault 1046 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 1047 . 1049 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 1050 Maintenance Using the Label Distribution Protocol (LDP)", 1051 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 1052 . 1054 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1055 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1056 August 2017, . 1058 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1059 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1060 2017, . 1062 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1063 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1064 DOI 10.17487/RFC8299, January 2018, 1065 . 1067 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1068 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1069 . 1071 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 1072 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 1073 Management Framework for the Simplified Use of Policy 1074 Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328, 1075 March 2018, . 1077 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1078 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1079 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1080 2018, . 1082 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1083 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1084 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1085 March 2018, . 1087 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1088 Routing Management (NMDA Version)", RFC 8349, 1089 DOI 10.17487/RFC8349, March 2018, 1090 . 1092 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1093 Data Model for Layer 2 Virtual Private Network (L2VPN) 1094 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1095 2018, . 1097 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1098 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1099 Address Translation (NAT) and Network Prefix Translation 1100 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1101 . 1103 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1104 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1105 DOI 10.17487/RFC8513, January 2019, 1106 . 1108 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1109 "YANG Data Model for Network Access Control Lists (ACLs)", 1110 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1111 . 1113 [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", 1114 RFC 8528, DOI 10.17487/RFC8528, March 2019, 1115 . 1117 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1118 Liu, "YANG Data Model for Network Instances", RFC 8529, 1119 DOI 10.17487/RFC8529, March 2019, 1120 . 1122 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1123 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1124 DOI 10.17487/RFC8530, March 2019, 1125 . 1127 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1128 for Connection-Oriented Operations, Administration, and 1129 Maintenance (OAM) Protocols", RFC 8531, 1130 DOI 10.17487/RFC8531, April 2019, 1131 . 1133 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1134 Raghavan, "Generic YANG Data Model for the Management of 1135 Operations, Administration, and Maintenance (OAM) 1136 Protocols That Use Connectionless Communications", 1137 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1138 . 1140 [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. 1141 Raghavan, "A YANG Data Model for Retrieval Methods for the 1142 Management of Operations, Administration, and Maintenance 1143 (OAM) Protocols That Use Connectionless Communications", 1144 RFC 8533, DOI 10.17487/RFC8533, April 2019, 1145 . 1147 Appendix A. Layered YANG Modules Example Overview 1149 It is not the intent of this document to provide an inventory of 1150 tools and mechanisms used in specific network and service management 1151 domains; such inventory can be found in documents such as [RFC7276]. 1153 A.1. Service Models: Definition and Samples 1155 As described in [RFC8309], the service is "some form of connectivity 1156 between customer sites and the Internet and/or between customer sites 1157 across the network operator's network and across the Internet". More 1158 concretely, an IP connectivity service can be defined as the IP 1159 transfer capability characterized by a (Source Nets, Destination 1160 Nets, Guarantees, Scope) tuple where "Source Nets" is a group of 1161 unicast IP addresses, "Destination Nets" is a group of IP unicast 1162 and/or multicast addresses, and "Guarantees" reflects the guarantees 1163 (expressed in terms of Quality Of Service (QoS), performance, and 1164 availability, for example) to properly forward traffic to the said 1165 "Destination" [RFC7297]. 1167 For example: 1169 o L3SM model [RFC8299] defines the L3VPN service ordered by a 1170 customer from a network operator. 1172 o L2SM model [RFC8466] defines the L2VPN service ordered by a 1173 customer from a network operator. 1175 o VN model [I-D.ietf-teas-actn-vn-yang]provides a YANG data model 1176 generally applicable to any mode of Virtual Network (VN) 1177 operation. 1179 A.2. Network Models: Definitions and Samples 1181 Figure 4 depicts a set of Network models such as topology models or 1182 tunnel models: 1184 | | 1185 Topo YANG modules | Tunnel YANG modules | 1186 ------------------------------------------------| 1187 +------------+ | | 1188 |Network Top | | +------+ +-----------+ | 1189 | Model | | |Other | | TE Tunnel | | 1190 +----+-------+ | |Tunnel| +------+----+ | 1191 | +--------+ | +------+ | | 1192 |---+Svc Topo| | +--------+-+--------+ 1193 | +--------+ | +----+---+ +---+----+ +-+-----+ 1194 | +--------+ | |MPLS-TE | |RSVP-TE | |SR TE | 1195 |---+L2 Topo | | | Tunnel | | Tunnel | |Tunnel | 1196 | +--------+ | +--------+ +--------+ +-------+ 1197 | +--------+ | 1198 |---+TE Topo | | 1199 | +--------+ | 1200 | +--------+ | 1201 +---+L3 Topo | | 1202 +--------+ | 1204 Figure 4: Sample Resource Facing Network Models 1206 Topology YANG module Examples: 1208 o Network Topology Models: [RFC8345] defines a base model for 1209 network topology and inventories. Network topology data include 1210 link resource, node resource, and terminate-point resources. 1212 o TE Topology Models: [I.D-ietf-teas-yang-te-topo] defines a data 1213 model for representing and manipulating TE topologies. 1215 This module is extended from network topology model defined in 1216 [RFC8345] with TE topologies specifics. This model contains 1217 technology-agnostic TE Topology building blocks that can be 1218 augmented and used by other technology-specific TE Topology 1219 models. 1221 o L3 Topology Models 1223 [RFC8346] defines a data model for representing and manipulating 1224 L3 Topologies. This model is extended from the network topology 1225 model defined in [RFC8345] with L3 topologies specifics. 1227 o L2 Topology Models 1229 [I.D-ietf-i2rs-yang-l2-topology] defines a data model for 1230 representing and manipulating L2 Topologies. This model is 1231 extended from the network topology model defined in [RFC8345] with 1232 L2 topologies specifics. 1234 Tunnel YANG module Examples: 1236 o Tunnel identities [I-D.ietf-softwire-iftunnel] to ease 1237 manipulating extensions to specific tunnels. 1239 o TE Tunnel Model 1241 [I.D-ietf-teas-yang-te] defines a YANG module for the 1242 configuration and management of TE interfaces, tunnels and LSPs. 1244 o SR TE Tunnel Model 1246 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 1247 model(s) and defines a YANG module for Segment Routing (SR) TE 1248 specific data. 1250 o MPLS TE Model 1252 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 1253 model(s) and defines a YANG module for MPLS TE configurations, 1254 state, RPC and notifications. 1256 o RSVP-TE MPLS Model 1258 [I.D-ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 1259 with parameters to configure and manage signaling of MPLS RSVP-TE 1260 LSPs. 1262 Other Network Models: 1264 o Path Computation API Model 1266 [I.D-ietf-teas-path-computation] YANG module for a stateless RPC 1267 which complements the stateful solution defined in [I.D-ietf-teas- 1268 yang-te]. 1270 o OAM Models (including Fault Management (FM) and Performance 1271 Monitoring) 1273 [RFC8532] defines a base YANG module for the management of OAM 1274 protocols that use Connectionless Communications. [RFC8533] 1275 defines a retrieval method YANG module for connectionless OAM 1276 protocols. [RFC8531] defines a base YANG module for connection 1277 oriented OAM protocols. These three models are intended to 1278 provide consistent reporting, configuration and representation for 1279 connection-less OAM and Connection oriented OAM separately. 1281 Alarm monitoring is a fundamental part of monitoring the network. 1282 Raw alarms from devices do not always tell the status of the 1283 network services or necessarily point to the root cause. [I.D- 1284 ietf-ccamp-alarm-module] defines a YANG module for alarm 1285 management. 1287 o Generic Policy Model 1289 The Simplified Use of Policy Abstractions (SUPA) policy-based 1290 management framework [RFC8328] defines base YANG modules 1291 [I-D.ietf-supa-generic-policy-data-model]to encode policy. These 1292 models point to device-, technology-, and service-specific YANG 1293 modules developed elsewhere. Policy rules within an operator's 1294 environment can be used to express high-level, possibly network- 1295 wide, policies to a network management function (within a 1296 controller, an orchestrator, or a network element). The network 1297 management function can then control the configuration and/or 1298 monitoring of network elements and services. This document 1299 describes the SUPA basic framework, its elements, and interfaces. 1301 A.3. Device Models: Definitions and Samples 1303 Network Element models (Figure 5) are used to describe how a service 1304 can be implemented by activating and tweaking a set of functions 1305 (enabled in one or multiple devices, or hosted in cloud 1306 infrastructures) that are involved in the service delivery. The 1307 following figure uses IETF defined models as an example. 1309 +----------------+ 1310 --|Device Model | 1311 | +----------------+ 1312 | +------------------+ 1313 +---------------+ | |Logical Network | 1314 | | --| Element Mode | 1315 | Architecture | | +------------------+ 1316 | | | +----------------------+ 1317 +-------+-------+ --|Network Instance Mode | 1318 | | +----------------------+ 1319 | | +-------------------+ 1320 | --|Routing Type Model | 1321 | +-------------------+ 1322 +-------+----------+----+------+------------+-----------+-------+ 1323 | | | | | | | 1324 +-+-+ +---+---+ +--+------+ +-+-+ +-----+---+ +---+-+ | 1325 |ACL| |Routing| |Transport| |OAM| |Multicast| | PM | Others 1326 +---+ |-------+ +---------+ +---+ +---------+ +-----+ 1327 | +-------+ +----------+ +-------+ +-----+ +-----+ 1328 --|Core | |MPLS Basic| |BFD | |IGMP | |TWAMP| 1329 | |Routing| +----------+ +-------+ |/MLD | +-----+ 1330 | +-------+ |MPLS LDP | |LSP Ping +-----+ |OWAMP| 1331 --|BGP | +----------+ +-------+ |PIM | +-----+ 1332 | +-------+ |MPLS Static |MPLS-TP| +-----+ |LMAP | 1333 --|ISIS | +----------+ +-------+ |MVPN | +-----+ 1334 | +-------+ +-----+ 1335 --|OSPF | 1336 | +-------+ 1337 --|RIP | 1338 | +-------+ 1339 --|VRRP | 1340 | +-------+ 1341 --|SR/SRv6| 1342 | +-------+ 1343 --|ISIS-SR| 1344 | +-------+ 1345 --|OSPF-SR| 1346 +-------+ 1348 Figure 5: Network Element Modules Overview 1350 A.3.1. Model Composition 1352 o Device Model 1354 [I.D-ietf-rtgwg-device-model] presents an approach for organizing 1355 YANG modules in a comprehensive logical structure that may be used 1356 to configure and operate network devices. The structure is itself 1357 represented as an example YANG module, with all of the related 1358 component models logically organized in a way that is 1359 operationally intuitive, but this model is not expected to be 1360 implemented. 1362 o Logical Network Element Model 1364 [RFC8530] defines a logical network element module which can be 1365 used to manage the logical resource partitioning that may be 1366 present on a network device. Examples of common industry terms 1367 for logical resource partitioning are Logical Systems or Logical 1368 Routers. 1370 o Network Instance Model 1372 [RFC8529] defines a network instance module. This module can be 1373 used to manage the virtual resource partitioning that may be 1374 present on a network device. Examples of common industry terms 1375 for virtual resource partitioning are Virtual Routing and 1376 Forwarding (VRF) instances and Virtual Switch Instances (VSIs). 1378 A.3.1.1. Schema Mount 1380 Modularity and extensibility were among the leading design principles 1381 of the YANG data modeling language. As a result, the same YANG 1382 module can be combined with various sets of other modules and thus 1383 form a data model that is tailored to meet the requirements of a 1384 specific use case. [RFC8528] defines a mechanism, denoted schema 1385 mount, that allows for mounting one data model consisting of any 1386 number of YANG modules at a specified location of another (parent) 1387 schema. 1389 That capability does not cover design time. 1391 A.3.2. Device Models: Definitions and Samples 1393 BGP: [I-D.ietf-idr-bgp-yang-model] defines a YANG module for 1394 configuring and managing BGP, including protocol, policy, 1395 and operational aspects based on data center, carrier and 1396 content provider operational requirements. 1398 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 1399 which serves as a base framework for configuring and 1400 managing an MPLS switching subsystem. It is expected that 1401 other MPLS technology YANG modules (e.g. MPLS LSP Static, 1402 LDP or RSVP-TE models) will augment the MPLS base YANG 1403 module. 1405 QoS: [I-D.asechoud-netmod-diffserv-model] describes a YANG 1406 module of Differentiated Services for configuration and 1407 operations. 1409 ACL: Access Control List (ACL) is one of the basic elements 1410 used to configure device forwarding behavior. It is used 1411 in many networking technologies such as Policy Based 1412 Routing, Firewalls, etc. [RFC8519] describes a data model 1413 of Access Control List (ACL) basic building blocks. 1415 NAT: For the sake of network automation and the need for 1416 programming Network Address Translation (NAT) function in 1417 particular, a data model for configuring and managing the 1418 NAT is essential. [RFC8512] defines a YANG module for the 1419 NAT function covering a variety of NAT flavors such as 1420 Network Address Translation from IPv4 to IPv4 (NAT44), 1421 Network Address and Protocol Translation from IPv6 Clients 1422 to IPv4 Servers (NAT64), customer-side translator (CLAT), 1423 Stateless IP/ICMP Translation (SIIT), Explicit Address 1424 Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix 1425 Translation (NPTv6), and Destination NAT. [RFC8513] 1426 specifies a YANG module for the DS-Lite AFTR. 1428 Stateless Address Sharing: [I-D.ietf-softwire-yang] specifies a YANG 1429 module for A+P address sharing, including Lightweight 1430 4over6, Mapping of Address and Port with Encapsulation 1431 (MAP-E), and Mapping of Address and Port using Translation 1432 (MAP-T) softwire mechanisms. 1434 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 1435 to configure and manage Protocol Independent Multicast 1436 (PIM) devices. [I-D.ietf-pim-igmp-mld-yang] defines a 1437 YANG module that can be used to configure and manage 1438 Internet Group Management Protocol (IGMP) and Multicast 1439 Listener Discovery (MLD) devices. [I-D.ietf-pim-igmp-mld- 1440 snooping-yang] defines a YANG module that can be used to 1441 configure and manage Internet Group Management Protocol 1442 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1443 devices. 1445 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for 1446 Ethernet VPN services. The model is agnostic of the 1447 underlay. It apply to MPLS as well as to VxLAN 1448 encapsulation. The model is also agnostic of the services 1449 including E-LAN, E-LINE and E-TREE services. This 1450 document mainly focuses on EVPN and Ethernet-Segment 1451 instance framework. 1453 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can 1454 be used to configure and manage BGP L3VPNs [RFC4364]. It 1455 contains VRF specific parameters as well as BGP specific 1456 parameters applicable for L3VPNs. 1458 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS 1459 based Layer 2 VPN services (L2VPN) [RFC4664] and includes 1460 switching between the local attachment circuits. The 1461 L2VPN model covers point-to-point VPWS and Multipoint VPLS 1462 services. These services use signaling of Pseudowires 1463 across MPLS networks using LDP [RFC8077][RFC4762] or BGP 1464 [RFC4761]. 1466 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module 1467 for configuring and managing routing policies in a vendor- 1468 neutral way and based on actual operational practice. The 1469 model provides a generic policy framework which can be 1470 augmented with protocol-specific policy configuration. 1472 BFD: [I-D.ietf-bfd-yang]defines a YANG module that can be used 1473 to configure and manage Bidirectional Forwarding Detection 1474 (BFD) [RFC5880]. BFD is a network protocol which is used 1475 for liveness detection of arbitrary paths between systems. 1477 SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment 1478 routing configuration and operation. [I-D.raza-spring- 1479 srv6-yang] defines a YANG module for Segment Routing IPv6 1480 (SRv6) base. The model serves as a base framework for 1481 configuring and managing an SRv6 subsystem and expected to 1482 be augmented by other SRv6 technology models accordingly. 1484 Core Routing: [RFC8349] defines the core routing data model, which 1485 is intended as a basis for future data model development 1486 covering more-sophisticated routing systems. It is 1487 expected that other Routing technology YANG modules (e.g., 1488 VRRP, RIP, ISIS, OSPF models) will augment the Core 1489 Routing base YANG module. 1491 PM: 1493 [I.D-ietf-ippm-twamp-yang] defines a data model for client 1494 and server implementations of the Two-Way Active 1495 Measurement Protocol (TWAMP). 1497 [I.D-ietf-ippm-stamp-yang] defines the data model for 1498 implementations of Session-Sender and Session-Reflector 1499 for Simple Two-way Active Measurement Protocol (STAMP) 1500 mode using YANG. 1502 [RFC8194] defines a data model for Large-Scale Measurement 1503 Platforms (LMAPs). 1505 Authors' Addresses 1507 Qin Wu (editor) 1508 Huawei 1509 101 Software Avenue, Yuhua District 1510 Nanjing, Jiangsu 210012 1511 China 1513 Email: bill.wu@huawei.com 1515 Mohamed Boucadair (editor) 1516 Orange 1517 Rennes 35000 1518 France 1520 Email: mohamed.boucadair@orange.com 1522 Diego R. Lopez 1523 Telefonica I+D 1524 Spain 1526 Email: diego.r.lopez@telefonica.com 1528 Chongfeng Xie 1529 China Telecom 1530 Beijing 1531 China 1533 Email: xiechf.bri@chinatelecom.cn 1534 Liang Geng 1535 China Mobile 1537 Email: gengliang@chinamobile.com