idnits 2.17.1 draft-ietf-opsawg-model-automation-framework-02.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 (March 17, 2020) is 1498 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 (-18) exists of draft-ietf-i2rs-yang-l2-network-topology-13 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-08 == 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-14 == Outdated reference: A later version (-20) exists of draft-ietf-pim-igmp-mld-snooping-yang-09 == Outdated reference: A later version (-31) exists of draft-ietf-rtgwg-policy-model-09 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-qos-model-00 == Outdated reference: A later version (-30) exists of draft-ietf-spring-sr-yang-15 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-02 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-08 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-08 == 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-23 == Outdated reference: A later version (-01) exists of draft-ogondio-opsawg-uni-topology-00 Summary: 0 errors (**), 0 flaws (~~), 16 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: September 18, 2020 Orange 6 D. Lopez 7 Telefonica I+D 8 C. Xie 9 China Telecom 10 L. Geng 11 China Mobile 12 March 17, 2020 14 A Framework for Automating Service and Network Management with YANG 15 draft-ietf-opsawg-model-automation-framework-02 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, 27 diagnostic, and assurance. Also, data models are instrumental in the 28 automation of network management. They also provide closed-loop 29 control for the sake of adaptive and deterministic service creation, 30 delivery, and maintenance. 32 This document describes an architecture for service and network 33 management automation that takes advantage of YANG modeling 34 technologies. This architecture is drawn from a network provider 35 perspective irrespective of the origin of a data module; it can thus 36 accommodate even modules that are developed outside the IETF. 38 The document aims in particular to exemplify an approach that 39 specifies the journey from technology-agnostic services to 40 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 September 18, 2020. 59 Copyright Notice 61 Copyright (c) 2020 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 . . . . . . . . 8 81 3.3. Service Fullfillment Automation . . . . . . . . . . . . . 9 82 3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 9 83 4. Functional Bocks and Interactions . . . . . . . . . . . . . . 10 84 4.1. Service Lifecycle Management Procedure . . . . . . . . . 11 85 4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 11 86 4.1.2. Service Creation/Modification . . . . . . . . . . . . 12 87 4.1.3. Service Optimization . . . . . . . . . . . . . . . . 12 88 4.1.4. Service Diagnosis . . . . . . . . . . . . . . . . . . 13 89 4.1.5. Service Decommission . . . . . . . . . . . . . . . . 13 90 4.2. Service Fullfillment Management Procedure . . . . . . . . 13 91 4.2.1. Intended Configuration Provision . . . . . . . . . . 13 92 4.2.2. Configuration Validation . . . . . . . . . . . . . . 14 93 4.2.3. Performance Monitoring/Model-driven Telemetry . . . . 14 94 4.2.4. Fault Diagnostic . . . . . . . . . . . . . . . . . . 15 95 4.3. Multi-layer/Multi-domain Service Mapping . . . . . . . . 15 96 4.4. Service Decomposing . . . . . . . . . . . . . . . . . . . 15 98 5. YANG Data Model Integration Examples . . . . . . . . . . . . 16 99 5.1. L3VPN Service Delivery . . . . . . . . . . . . . . . . . 16 100 5.2. VN Lifecycle Management . . . . . . . . . . . . . . . . . 17 101 5.3. Event-based Telemetry in the Device Self Management . . . 18 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 104 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 105 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 108 10.2. Informative References . . . . . . . . . . . . . . . . . 21 109 Appendix A. Layered YANG Modules Examples Overview . . . . . . . 27 110 A.1. Service Models: Definition and Samples . . . . . . . . . 27 111 A.2. Network Models: Samples . . . . . . . . . . . . . . . . . 28 112 A.3. Device Models: Samples . . . . . . . . . . . . . . . . . 30 113 A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 31 114 A.3.2. Device Models: Samples . . . . . . . . . . . . . . . 32 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 117 1. Introduction 119 The service management system usually comprises service activation/ 120 provision and service operation. Current service delivery 121 procedures, from the processing of customer's requirements and order 122 to service delivery and operation, typically assume the manipulation 123 of data sequentially into multiple OSS/BSS applications that may be 124 managed by different departments within the service provider's 125 organization (e.g., billing factory, design factory, network 126 operation center, etc.). In addition, many of these applications 127 have been developed in-house over the years and operating in a silo 128 mode: 130 o The lack of standard data input/output (i.e., data model) also 131 raises many challenges in system integration and often results in 132 manual configuration tasks. 134 o Secondly, many current service fulfillment system might have a 135 limited visibility on the network state and therefore have slow 136 response to the network changes. 138 Software Defined Networking (SDN) becomes crucial to address these 139 challenges. SDN techniques [RFC7149] are meant to automate the 140 overall service delivery procedures and typically rely upon 141 (standard) data models that are used to not only reflect service 142 providers'savoir-faire but also to dynamically instantiate and 143 enforce a set of (service-inferred) policies that best accommodate 144 what has been (contractually) defined (and possibly negotiated) with 145 the customer. [RFC7149] provides a first tentative to rationalize 146 that service provider's view on the SDN space by identifying concrete 147 technical domains that need to be considered and for which solutions 148 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 perspective. 166 Models are key for each of these technical items. Service and 167 network management automation is an important step to improve the 168 agility of network operations. Models are also important to ease 169 integrating multi-vendor solutions. 171 YANG ([RFC7950]) module developers have taken both top-down and 172 bottom-up approaches to develop modules [RFC8199] and to establish a 173 mapping between a network technology and customer requirements on the 174 top or abstracting common construct from various network technologies 175 on the bottom. At the time of writing this document (2020), there 176 are many 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 device, manage a set of devices 180 involved in a service, or even provide a service is something that is 181 not currently documented either within the IETF or other SDOs (e.g., 182 MEF). 184 This document describes an architectural framework for service and 185 network management automation (Section 3) that takes advantage of 186 YANG modeling technologies and investigates how different layer YANG 187 data models interact with each other (e.g., service mapping, model 188 composing) in the context of service delivery and fulfillment 189 (Section 4). 191 This framework is drawn from a network provider perspective 192 irrespective of the origin of a data module; it can accommodate even 193 modules that are developed outside the IETF. 195 The document identifies a list of use cases to exemplify the proposed 196 approach (Section 5), but it does not claim nor aim to be exhaustive. 198 2. Terminology 200 The following terms are defined in [RFC8309][RFC8199] and are not 201 redefined here: 203 o Network Operator 205 o Customer 207 o Service 209 o Data Model 211 o Service Model 213 o Network Element Module 215 The document makes use of the following terms: 217 Network Model: Describes a network level abstraction (or a subset of 218 aspects of a network infrastructure), including devices and their 219 subsystems, and relevant protocols operating at the link and 220 network layers across multiple devices. It can be used by a 221 network operator to allocate the resource (e.g., tunnel resource, 222 topology resource) for the service or schedule the resource to 223 meet the service requirements defined in a Service Model. 225 Device Model: Refers to the Network Element YANG data module 226 described in [RFC8199]. Device Model is also used to refer to 227 model a function embedded in a device (e.g., NAT [RFC8512], ACL 228 [RFC8519]). 230 3. Architectural Concepts & Goals 232 3.1. Data Models: Layering and Representation 234 As described in [RFC8199], layering of modules allows for better 235 reusability of lower-layer modules by higher-level modules while 236 limiting duplication of features across layers. 238 The data models can be classified into Service, Network, and Device 239 Models. Different Service Models may rely on the same set of Network 240 and/or Device Models. 242 Service Models traditionally follow top down approach and are mostly 243 customer-facing YANG modules providing a common model construct for 244 higher level network services (e.g., L3VPN), which can be mapped to 245 network technology-specific modules at lower layers (e.g., tunnel, 246 routing, QoS, security). For example, the service level can be used 247 to characterise the network service(s) to be ensured between service 248 nodes (ingress/egress) such as the communication scope (pipe, hose, 249 funnel, ...), the directionality, the traffic performance guarantees 250 (one-way delay (OWD), one-way loss, ...), etc. 252 Figure 1 depicts the example of a VoIP service provider that relies 253 in the connectivity services offered by a network provider. These 254 connectivity services can be captured in a YANG Service Module that 255 reflects the service attributes that are shown in Figure 2. This 256 example follows the IP Connectivity Provisioning Profile template 257 defined in [RFC7297]. 259 ,--,--,--. ,--,--,--. 260 ,-' SP1 `-. ,-' SP2 `-. 261 ( Service Site ) ( Service Site ) 262 `-. ,-' `-. ,-' 263 `--'--'--' `--'--'--' 264 x | o * * | 265 (2)x | o * * | 266 ,x-,--o-*-. (1) ,--,*-,--. 267 ,-' x o * * * * * * * * * `-. 268 ( x o +----( Internet ) 269 User---(x x x o o o o o o o o o o o o o o o o o o 270 `-. Provider ,-' `-. ,-' (3) 271 `--'--'--' `--'--'--' 273 **** (1) Inter-SP connectivity 274 xxxx (2) Customer to SP connectivity 275 oooo (3) SP to any destination connectivity 277 Figure 1: An Example of Service Connectivty Components 279 Connectivity: Scope and Guarantees 280 * inter-SP connectivity (1) 281 - Pipe scope from the local to the remote VoIP gateway 282 - Full guarantees class 283 * Customer to SP connectivity (2) 284 - Hose/Funnel scope connecting the local VoIP gateway 285 to the customer access points 286 - Full guarantees class 287 * SP to any destination connectivity (3) 288 - Hose/Funnel scope from the local VoIP gateway to the 289 Internet gateway 290 - Delay guarantees class 291 Flow Identification 292 * Destination IP address (SBC, SBE, DBE) 293 * DSCP marking 294 Traffic Isolation 295 * VPN 296 Routing & Forwarding 297 * Routing rule to exclude ASes from the inter-domain paths 298 Notifications (including feedback) 299 * Statistics on aggregate traffic to adjust capacity 300 * Failures 301 * Planned maintenance operations 302 * Triggered by thresholds 304 Figure 2: Sample Attributes Captured in a Service Model 306 Network Models are mainly network resource-facing modules and 307 describe various aspects of a network infrastructure, including 308 devices and their subsystems, and relevant protocols operating at the 309 link and network layers across multiple devices (e.g., network 310 topology and traffic-engineering tunnel modules). 312 Device (and function) Models usually follow a bottom-up approach and 313 are mostly technology-specific modules used to realize a service 314 (e.g., BGP, NAT). 316 Each level maintains a view of the supported YANG modules provided by 317 low-levels (see for example, Appendix A). 319 Figure 3 illustrates the overall layering model. 321 +-----------------------------------------------------------------+ 322 | +-----------------------+ | 323 | | Orchestrator | Hierarchy Abstraction | 324 | |+---------------------+| | 325 | || Service Modeling || Service Model | 326 | |+---------------------+| (Customer Oriented) | 327 | | | Scope: "1:1" Pipe model | 328 | | | Bidirectional | 329 | |+---------------------+| +-+ BW:100M,OWD +-+ | 330 | ||Service Orchestration|| | +---------------+ | | 331 | |+---------------------+| +-+ +-+ | 332 | +-----------------------+ 1. Ingress 2. Egress | 333 | | 334 | | 335 | | 336 | +-----------------------+ Network Model | 337 | | Controller | (Operator Oriented) | 338 | |+---------------------+| +-+ +--+ +---+ +-+ | 339 | || Network Modeling || | | | | | | | | | 340 | |+---------------------+| | o----o--o----o---o---o | | 341 | |+---------------------+| +-+ +--+ +---+ +-+ | 342 | ||network Orchestration| src dst | 343 | |+---------------------+| L3VPN over TE | 344 | | | Instance Name/Access Interface| 345 | +-----------------------+ Proto Type/BW/RD,RT,..mapping | 346 | for hop | 347 | | 348 | | 349 | +-----------------------+ | 350 | | Device | Device Model | 351 | |+--------------------+ | | 352 | || Device Modeling | | Interface add, BGP Peer, | 353 | |+--------------------+ | Tunnel id, QoS/TE | 354 | +-----------------------+ | 355 +-----------------------------------------------------------------+ 357 Figure 3: Layering and Representation 359 3.2. Automation of Service Delivery Procedures 361 Service Models can be used by an operator to expose its services to 362 its customers. Exposing such models allows to automate the 363 activation of service orders and thus the service delivery. One or 364 more monolithic Service Models can be used in the context of a 365 composite service activation request (e.g., delivery of a caching 366 infrastructure over a VPN). Such modules are used to feed a 367 decision-making intelligence to adequately accommodate customer's 368 needs. 370 Such modules may also be used jointly with services that require 371 dynamic invocation. An example is provided by the service modules 372 defined by the DOTS WG to dynamically trigger requests to handle DDoS 373 attacks [I-D.ietf-dots-signal-channel][I-D.ietf-dots-data-channel]. 375 Network Models can be derived from Service Models and used to 376 provision, monitor, instantiate the service, and provide lifecycle 377 management of network resources (e.g., expose network resources to 378 customers or operators to provide service fulfillment and assurance 379 and allow customers or operators to dynamically adjust the network 380 resources based on service requirements as described in Service 381 Models (e.g., Figure 2) and the current network performance 382 information described in the telemetry modules). 384 3.3. Service Fullfillment Automation 386 To operate a service, Device Models derived from Service Models or 387 Network Models can be used to provision each involved network 388 function/device with the proper configuration information, and 389 operate the network based on service requirements as described in the 390 Service Model(s) and local operational guidelines. 392 In addition, the operational state including configuration that is in 393 effect together with statistics should be exposed to upper layers to 394 provide better network visibility (and assess to what extent the 395 derived low level modules are consistent with the upper level 396 inputs). Filters are enforced on the notifications that are 397 communicated to Service layers. The type of notifications may be 398 agreed in the Service Model. 400 Note that it is important to correlate telemetry data with 401 configuration data to be used for closed loops at the different 402 stages of service delivery, from resource allocation to service 403 operation, in particular. 405 3.4. YANG Modules Integration 407 To support top-down service delivery, YANG modules at different 408 levels or at the same level need to be integrated together for proper 409 service delivery (including, proper network setup). For example, the 410 service parameters captured in Service Models need to be decomposed 411 into a set of (configuration/notification) parameters that may be 412 specific to one or more technologies; these technology-specific 413 parameters are grouped together to define technology-specific device 414 level models or network level models. 416 In addition, these technology-specific Device or Network Models can 417 be further integrated with each other using the schema mount 418 mechanism [RFC8528] to provision each involved network function/ 419 device or each involved administrative domain to support newly added 420 module or features. A collection of Device Models integrated 421 together can be loaded and validated during the implementation time. 423 High-level policies can be defined at Service or Network Models 424 (e.g., AS Exclude in the example depicted in Figure 2). Device 425 Models will be tweaked accordingly to provide policy-based 426 management. Policies can also be used for telemetry automation, 427 e.g., policies that contain conditions can trigger the generation and 428 pushing of new telemetry data. 430 Performance measurement telemetry can be used to provide service 431 assurance at Service and/or Network levels. Performance measurement 432 telemetry model can tie with Service or Network Models to monitor 433 network performance or Service Level Agreement. 435 4. Functional Bocks and Interactions 437 The architectural considerations described in Section 3 led to the 438 architecture described in this section and illustrated in Figure 4. 440 +------------------+ 441 Service level | | 442 ----------- V | 443 E2E E2E E2E E2E 444 Service -- Service --------> Service --->Service ---+ 445 Exposure Creation ^ Optimization | Diagnosis | 446 /Modification | | | 447 | |Diff | V 448 Multi-layer | | E2E | E2E 449 Multi-domain | | Service | Service 450 Service Mapping| +------ Assurance ---+ Decommission 451 | ^ 452 |<-----------------+ | 453 Network level | | +----+ 454 ------------ V | | 455 Specific Specific | 456 Service ----+---> Service ---+--+ 457 Creation ^ Optimization | | 458 /Modification | | | 459 | |Diff | | 460 | | Specific----+ | 461 Service | | Service | 462 Decomposing | +------Assurance ----+ 463 | ^ 464 | | Aggregation 465 Device level | +------------+ 466 ------------ V | 467 Service Intent 468 Fullfillment Config ------> Config ----> Performance -->Fault 469 Provision Validate Monitoring Diagnostic 471 Figure 4: Service and Network Lifecycle Management 473 4.1. Service Lifecycle Management Procedure 475 Service lifecycle management includes end to end service lifecycle 476 management at the service level and technology specific network 477 lifecycle management at the network level. The end-to-end service 478 lifecycle management is technology independent service management and 479 span across multiple administrative domain or multiple layers while 480 technology specific service lifecycle management is technology domain 481 specific or layer specific service lifecycle management. 483 4.1.1. Service Exposure 485 A service in the context of this document (sometimes called a Network 486 Service) is some form of connectivity between customer sites and the 487 Internet or between customer sites across the operator's network and 488 across the Internet. 490 Service exposure is used to capture services offered to customers 491 (ordering and order handling). One typical example is that a 492 customer can use a L3SM service model to request L3VPN service by 493 providing the abstract technical characterization of the intended 494 service between customer sites. 496 Service model catalogs can be created along to expose the various 497 services and the information needed to invoke/order a given service. 499 4.1.2. Service Creation/Modification 501 A customer is (usually) unaware of the technology that the network 502 operator has available to deliver the service, so the customer does 503 not make requests specific to the underlying technology but is 504 limited to making requests specific to the service that is to be 505 delivered. This service request can be issued using the service 506 model. 508 Upon receiving the service request, the service orchestrator/ 509 management system should first verify whether the service 510 requirements in the service request can be met (i.e., whether there 511 is sufficient resource that can be allocated). 513 In successful case, the service orchestrator/management system maps 514 such service request to its view. This view can be described as a 515 technology specific network model or a set of technology specific 516 device models and this mapping may include a choice of which networks 517 and technologies to use depending on which service features have been 518 requested. 520 In addition, a customer may require to change underlying network 521 infrastructure to adapt to new customer's needs and service 522 requirements. This service modification can be issued in the same 523 service model used by the service request. 525 4.1.3. Service Optimization 527 Service optimization is a technique that gets the configuration of 528 the network updated due to network change, incident mitigation, or 529 new service requirements. One typical example is once the tunnel or 530 the VPN is setup, Performance monitoring information or telemetry 531 information per tunnel or per VPN can be collected and fed into the 532 management system, if the network performance doesn't meet the 533 service requirements, the management system can create new VPN 534 policies capturing network service requirements and populate them 535 into the network. 537 Both network performance information and policies can be modelled 538 using YANG. With Policy-based management, self-configuration and 539 self-optimization behavior can be specified and implemented. 541 4.1.4. Service Diagnosis 543 Operations, Administration, and Maintenance (OAM) are important 544 networking functions for service diagnosis that allow operators to: 546 o monitor network communications (i.e., reachability verification 547 and Continuity Check) 549 o troubleshoot failures (i.e., fault verification and localization) 551 o monitor service-level agreements and performance (i.e., 552 performance management) 554 When the network is down, service diagnosis should be in place to 555 pinpoint the problem and provide recommendation (or instructions) for 556 the network recovery. 558 The service diagnosis information can be modelled as technology- 559 independent Remote Procedure Call (RPC) operations for OAM protocols 560 and technology-independent abstraction of key OAM constructs for OAM 561 protocols [RFC8531][RFC8533]. These models can provide consistent 562 configuration, reporting, and presentation for the OAM mechanisms 563 used to manage the network. 565 4.1.5. Service Decommission 567 Service decommission allow the customer to stop the service and 568 remove the service from active status and release the network 569 resource that is allocated to the service. Customer can also use the 570 service model to withdraw the registration to a service. 572 4.2. Service Fullfillment Management Procedure 574 4.2.1. Intended Configuration Provision 576 Intended configuration at the device level is derived from network 577 model at the network level or service model at the service level and 578 represents the configuration that the system attempts to apply. Take 579 L3SM service model as an example, to deliver a L3VPN service, we need 580 to map L3VPN service view defined in Service model into detailed 581 intended configuration view defined by specific configuration models 582 for network elements, configuration information includes: 584 o VRF definition, including VPN Policy expression 586 o Physical Interface 588 o IP layer (IPv4, IPv6) 590 o QoS features such as classification, profiles, etc. 592 o Routing protocols: support of configuration of all protocols 593 listed in the document, as well as routing policies associated 594 with those protocols. 596 o Multicast Support 598 o Address sharing 600 o Security function 602 This specific configuration models can be used to configure Provider 603 Edge (PE) and Customer Edge (CE) devices within the site, e.g., a BGP 604 policy model can be used to establish VPN membership between sites 605 and VPN Service Topology. 607 4.2.2. Configuration Validation 609 Configuration validation is used to validate intended configuration 610 and ensure the configuration take effect. For example, a customer 611 creates an interface "et-0/0/0" but the interface does not physically 612 exist at this point, then configuration data appears in the 613 status but does not appear in datastore. 615 4.2.3. Performance Monitoring/Model-driven Telemetry 617 When configuration is in effect in the device, 618 datastore holds the complete operational state of the device 619 including learned, system, default configuration and system state. 620 However the configurations and state of a particular device does not 621 have the visibility to the whole network or information of the flow 622 packets are going to take through the entire network. Therefore it 623 becomes more difficult to operate the network without understanding 624 the current status of the network. 626 The management system should subscribe to updates of a YANG datastore 627 in all the network devices for performance monitoring purpose and 628 build full topological visibility to the network by aggregating and 629 filtering these operational state from different sources. 631 4.2.4. Fault Diagnostic 633 When configuration is in effect in the device, some device may be 634 mis-configured(e.g.,device links are not consistent on both sides of 635 the network connection), network resources be mis-allocated and 636 services may be negatively affected without knowing what is going on 637 in the network. 639 Technology-dependent nodes and RPC commands are defined in 640 technology-specific YANG data models which can use and extend the 641 base model described in Section 4.1.4 can be used to deal with these 642 challenges. 644 These RPC commands received in the technology dependent node can be 645 used to trigger technology specific OAM message exchange for fault 646 verification and fault isolation,e.g., TRILL Multicast Tree 647 Verification (MTV) RPC command [I-D.ietf-trill-yang-oam] can be used 648 to trigger Multi-Destination Tree Verification Message defined in 649 [RFC7455] to verify TRILL distribution tree integrity. 651 4.3. Multi-layer/Multi-domain Service Mapping 653 Multi-layer/Multi-domain Service Mapping allow you map end to end 654 abstract view of the service segmented at different layer or 655 different administrative domain into domain specific view. One 656 example is to map service parameters in L3VPN service model into 657 configuration parameters such as RD, RT, and VRF in L3VPN network 658 model. Another example is to map service parameters in L3VPN service 659 model into TE tunnel parameter (e.g.,Tunnel ID) in TE model and VN 660 parameters (e.g., AP list, VN member) in TEAS VN model 661 [I-D.ietf-teas-actn-vn-yang]. 663 4.4. Service Decomposing 665 Service Decomposing allows to decompose service model at the service 666 level or network model at the network level into a set of device/ 667 function models at the device level. These device models may be tied 668 to specific device type or classified into a collection of related 669 YANG modules based on service type and feature offered and load at 670 the implementation time before configuration is loaded and validated. 672 5. YANG Data Model Integration Examples 674 5.1. L3VPN Service Delivery 676 L3SM | ^ 677 Service | | Notifications 678 Model | | 679 +--------------------+----------------------------+ 680 | +-----V- -------+ | 681 | Orchestrator |Service Mapping| | 682 | +-----+---------+ | 683 | | | 684 +--------------------+----------------------------+ 685 L3NM | ^ 686 Network| | L3NM Notifications 687 Model | | L3NM Capabilities 688 +--------------------+----------------------------+ 689 | Controller+--------V-----------+ | 690 | | Service Decomposing| | 691 | +-++------------++---+ | 692 | || || | 693 | || || | 694 +-------------++---------- ++--------------------+ 695 || || 696 || || 697 ||BGP,QoS || 698 || || 699 +----------+|NI,Intf,IP |+-----------------+ 700 +--+--+ +++---+ --+---+ +--+--+ 701 | CE1 |------| PE1 | | PE2 | ---------+ CE2 | 702 +-----+ +-----+ +-----+ +-----+ 704 Figure 5: L3VPN Service Delivery Example 706 In reference to Figure 5, the following steps are performed to 707 deliver the L3VPN service within the network management automation 708 architecture defined in this document: 710 1. The Customer requests to create two sites (as per service 711 creation operation in Section 4.2.1) relying upon a L3SM Service 712 model with each having one network access connectivity: 714 Site A: Network-Access A, Bandwidth=20M, for class "foo", 715 guaranteed-bw-percent = 10, One-Way-Delay=70 msec 717 Site B: Network-Access B, Bandwidth=30M, for class "foo1", 718 guaranteed-bw-percent = 15, One-Way-Delay=60 msec 720 2. The Orchestrator extracts the service parameters from the L3SM 721 model. Then, it uses them as input to translate ("service 722 mapping operation" in Section 4.4) them into an orchestrated 723 configuration of network elements (e.g., RD, RT, VRF) that are 724 part of the L3NM network model. 726 3. The Controller takes orchestrated configuration parameters in the 727 L3NM network model and translates them into orchestrated 728 ("service decomposing operation" in ) configuration of network 729 elements that are part of, e.g, BGP, QoS, Network Instance model, 730 IP management, and interface models. 732 [I-D.ogondio-opsawg-uni-topology] is used for representing, managing 733 and controlling the User Network Interface (UNI) topology. 735 L3NM inherits some of data elements from the L3SM. Likewise, the 736 L3NM expose some information to the above layer such as the 737 capabilities of an underlying network (which can be used to drive 738 service order handling) or notifications (to notify subscribers about 739 specific events or degradations as per agreed SLAs). 741 5.2. VN Lifecycle Management 743 | 744 VN | 745 Service | 746 Model | 747 +----------------------|--------------------------+ 748 | Orchestrator | | 749 | +--------V--------+ | 750 | | Service Mapping | | 751 | +-----------------+ | 752 +----------------------+--------------------^-----+ 753 TE | Telemetry 754 Tunnel | Model 755 Model | | 756 +----------------------V--------------------+----+ 757 | Controller | 758 | | 759 +-------------------------------------------------+ 761 +-----+ +-----+ +-----+ +-----+ 762 | CE1 |------| PE1 | | PE2 |---------+ CE2 | 763 +-----+ +-----+ +-----+ +-----+ 765 Figure 6 767 In reference to Figure 6, the following steps are performed to 768 deliver the VN service within the network management automation 769 architecture defined in this document: 771 1. Customer requests (service exposure operation in Section 4.1.1) 772 to create 'VN' based on Access point, association between VN and 773 Access point, VN member defined in the VN YANG module. 775 2. The orchestrator creates the single abstract node topology based 776 on the information captured in an VN YANG module. 778 3. The Customer exchanges connectivity-matrix on abstract node and 779 explicit path using TE topology model with the orchestrator. 780 This information can be used to instantiate VN and setup tunnels 781 between source and destination endpoints (service creation 782 operation in Section 4.1.2). 784 4. The telemetry model which augments the TEAS VN model and 785 corresponding TE Tunnel model can be used to subscribe to 786 performance measurement data and notify all the parameter changes 787 and network performance change related to VN topology or Tunnel 788 [I-D.ietf-teas-actn-pm-telemetry-autonomics] and provide service 789 assurance (service optimization operation in Section 4.1.3). 791 5.3. Event-based Telemetry in the Device Self Management 793 +----------------+ 794 | | 795 | Controller | 796 +----------------+ 797 | 798 | 799 ECA | 800 Model| ^ 801 | |Notif 802 | | 803 +------------V-------------+-------+ 804 |Device | Reconfig 805 | +-------+ +---------+ +--+---+ | 806 | | Event --> Event -->Event --> | 807 | | Source| |Condition| |Action| | 808 | +-------+ +---------+ +------+ | 809 +--------Update------trigger-------+ 811 Figure 7: Event-based Telemetry 813 In reference to Figure 7, the following steps are performed to 814 monitor state changes of managed objects or resource in the device 815 and provide device self management within the network management 816 automation architecture defined in this document: 818 1. To control which state a network device should be in or is 819 allowed to be in at any given time, a set of conditions and 820 actions are defined and correlated with network events (e.g., 821 allow the NETCONF server send updates only when the value exceeds 822 a certain threshold for the first time but not again until the 823 threshold is cleared), which constitute an event-driven policy or 824 network control logic in the controller. 826 2. The controller pushes ECA policy to the network device and 827 delegate network control logic to the network device. 829 3. The network device generates ECA script from ECA model and 830 execute ECA script or network control logic based on Event. 831 Event based notification or telemetry can be triggered if a 832 certain condition is satisfied (model driven telemetry operation 833 in Section 4.2.3). 835 6. Security Considerations 837 Security considerations specific to each of the technologies and 838 protocols listed in the document are discussed in the specification 839 documents of each of these techniques. 841 (Potential) security considerations specific to this document are 842 listed below: 844 o Create forwarding loops by mis-configuring the underlying network. 846 o Leak sensitive information: special care should be considered when 847 translating between the various layers introduced in the document. 849 o Some Service Models may include a traffic isolation clause, 850 appropriate technology-specific actions must be enforced to avoid 851 that traffic is accessible to non-authorized parties. 853 7. IANA Considerations 855 There are no IANA requests or assignments included in this document. 857 8. Acknowledgements 859 Thanks to Joe Clark, Greg Mirsky, and Shunsuke Homma for the review. 861 9. Contributors 863 Christian Jacquenet 864 Orange 865 Rennes, 35000 866 France 867 Email: Christian.jacquenet@orange.com 869 Luis Miguel Contreras Murillo 870 Telifonica 872 Email: luismiguel.contrerasmurillo@telefonica.com 874 Oscar Gonzalez de Dios 875 Telefonica 876 Madrid 877 ES 879 Email: oscar.gonzalezdedios@telefonica.com 881 Chongfeng Xie 882 China Telecom 883 Beijing 884 China 886 Email: xiechf.bri@chinatelecom.cn 888 Weiqiang Cheng 889 China Mobile 891 Email: chengweiqiang@chinamobile.com 893 Young Lee 894 Sung Kyun Kwan University 896 Email: younglee.tx@gmail.com 898 10. References 900 10.1. Normative References 902 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 903 RFC 7950, DOI 10.17487/RFC7950, August 2016, 904 . 906 10.2. Informative References 908 [I-D.ietf-bess-evpn-yang] 909 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 910 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 911 bess-evpn-yang-07 (work in progress), March 2019. 913 [I-D.ietf-bess-l2vpn-yang] 914 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 915 and K. Tiruveedhula, "YANG Data Model for MPLS-based 916 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 917 July 2019. 919 [I-D.ietf-bess-l3vpn-yang] 920 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 921 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 922 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 923 in progress), October 2018. 925 [I-D.ietf-bfd-yang] 926 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 927 and G. Mirsky, "YANG Data Model for Bidirectional 928 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 929 in progress), August 2018. 931 [I-D.ietf-dots-data-channel] 932 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 933 Service Open Threat Signaling (DOTS) Data Channel 934 Specification", draft-ietf-dots-data-channel-31 (work in 935 progress), July 2019. 937 [I-D.ietf-dots-signal-channel] 938 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 939 N. Teague, "Distributed Denial-of-Service Open Threat 940 Signaling (DOTS) Signal Channel Specification", draft- 941 ietf-dots-signal-channel-41 (work in progress), January 942 2020. 944 [I-D.ietf-i2rs-yang-l2-network-topology] 945 Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A 946 YANG Data Model for Layer-2 Network Topologies", draft- 947 ietf-i2rs-yang-l2-network-topology-13 (work in progress), 948 March 2020. 950 [I-D.ietf-idr-bgp-model] 951 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 952 YANG Model for Service Provider Networks", draft-ietf-idr- 953 bgp-model-08 (work in progress), February 2020. 955 [I-D.ietf-ippm-stamp-yang] 956 Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active 957 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 958 stamp-yang-05 (work in progress), October 2019. 960 [I-D.ietf-ippm-twamp-yang] 961 Civil, R., Morton, A., Rahman, R., Jethanandani, M., and 962 K. Pentikousis, "Two-Way Active Measurement Protocol 963 (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work 964 in progress), July 2018. 966 [I-D.ietf-mpls-base-yang] 967 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 968 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 969 yang-14 (work in progress), March 2020. 971 [I-D.ietf-pim-igmp-mld-snooping-yang] 972 Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, 973 "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- 974 pim-igmp-mld-snooping-yang-09 (work in progress), January 975 2020. 977 [I-D.ietf-pim-yang] 978 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 979 Y., and f. hu, "A YANG Data Model for Protocol Independent 980 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 981 progress), May 2018. 983 [I-D.ietf-rtgwg-device-model] 984 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 985 "Network Device YANG Logical Organization", draft-ietf- 986 rtgwg-device-model-02 (work in progress), March 2017. 988 [I-D.ietf-rtgwg-policy-model] 989 Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data 990 Model for Routing Policy Management", draft-ietf-rtgwg- 991 policy-model-09 (work in progress), March 2020. 993 [I-D.ietf-rtgwg-qos-model] 994 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 995 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 996 model-00 (work in progress), October 2019. 998 [I-D.ietf-spring-sr-yang] 999 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 1000 Tantsura, "YANG Data Model for Segment Routing", draft- 1001 ietf-spring-sr-yang-15 (work in progress), January 2020. 1003 [I-D.ietf-supa-generic-policy-data-model] 1004 Halpern, J. and J. Strassner, "Generic Policy Data Model 1005 for Simplified Use of Policy Abstractions (SUPA)", draft- 1006 ietf-supa-generic-policy-data-model-04 (work in progress), 1007 June 2017. 1009 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 1010 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 1011 and D. Ceccarelli, "YANG models for VN/TE Performance 1012 Monitoring Telemetry and Scaling Intent Autonomics", 1013 draft-ietf-teas-actn-pm-telemetry-autonomics-02 (work in 1014 progress), March 2020. 1016 [I-D.ietf-teas-actn-vn-yang] 1017 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1018 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1019 teas-actn-vn-yang-08 (work in progress), March 2020. 1021 [I-D.ietf-teas-yang-path-computation] 1022 Busi, I., Belotti, S., Lopezalvarez, V., Sharma, A., and 1023 Y. Shi, "Yang model for requesting Path Computation", 1024 draft-ietf-teas-yang-path-computation-08 (work in 1025 progress), December 2019. 1027 [I-D.ietf-teas-yang-rsvp-te] 1028 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 1029 and H. Shah, "A YANG Data Model for RSVP-TE Protocol", 1030 draft-ietf-teas-yang-rsvp-te-08 (work in progress), March 1031 2020. 1033 [I-D.ietf-teas-yang-te] 1034 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1035 "A YANG Data Model for Traffic Engineering Tunnels and 1036 Interfaces", draft-ietf-teas-yang-te-23 (work in 1037 progress), March 2020. 1039 [I-D.ietf-teas-yang-te-topo] 1040 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1041 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1042 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 1043 progress), June 2019. 1045 [I-D.ietf-trill-yang-oam] 1046 Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., 1047 and H. Weiguo, "YANG Data Model for TRILL Operations, 1048 Administration, and Maintenance (OAM)", draft-ietf-trill- 1049 yang-oam-05 (work in progress), March 2017. 1051 [I-D.ogondio-opsawg-uni-topology] 1052 Dios, O., Barguil, S., WU, Q., and M. Boucadair, "A YANG 1053 Model for User-Network Interface (UNI) Topologies", draft- 1054 ogondio-opsawg-uni-topology-00 (work in progress), 1055 November 2019. 1057 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1058 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1059 2006, . 1061 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1062 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1063 DOI 10.17487/RFC4664, September 2006, 1064 . 1066 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1067 LAN Service (VPLS) Using BGP for Auto-Discovery and 1068 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1069 . 1071 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1072 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1073 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1074 . 1076 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1077 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1078 . 1080 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1081 Networking: A Perspective from within a Service Provider 1082 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1083 . 1085 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1086 Weingarten, "An Overview of Operations, Administration, 1087 and Maintenance (OAM) Tools", RFC 7276, 1088 DOI 10.17487/RFC7276, June 2014, 1089 . 1091 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1092 Connectivity Provisioning Profile (CPP)", RFC 7297, 1093 DOI 10.17487/RFC7297, July 2014, 1094 . 1096 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 1097 3rd, D., Aldrin, S., and Y. Li, "Transparent 1098 Interconnection of Lots of Links (TRILL): Fault 1099 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 1100 . 1102 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 1103 Maintenance Using the Label Distribution Protocol (LDP)", 1104 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 1105 . 1107 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1108 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1109 August 2017, . 1111 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1112 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1113 2017, . 1115 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1116 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1117 DOI 10.17487/RFC8299, January 2018, 1118 . 1120 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1121 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1122 . 1124 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 1125 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 1126 Management Framework for the Simplified Use of Policy 1127 Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328, 1128 March 2018, . 1130 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1131 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1132 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1133 2018, . 1135 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1136 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1137 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1138 March 2018, . 1140 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1141 Routing Management (NMDA Version)", RFC 8349, 1142 DOI 10.17487/RFC8349, March 2018, 1143 . 1145 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1146 Data Model for Layer 2 Virtual Private Network (L2VPN) 1147 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1148 2018, . 1150 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1151 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1152 Address Translation (NAT) and Network Prefix Translation 1153 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1154 . 1156 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1157 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1158 DOI 10.17487/RFC8513, January 2019, 1159 . 1161 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1162 "YANG Data Model for Network Access Control Lists (ACLs)", 1163 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1164 . 1166 [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", 1167 RFC 8528, DOI 10.17487/RFC8528, March 2019, 1168 . 1170 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1171 Liu, "YANG Data Model for Network Instances", RFC 8529, 1172 DOI 10.17487/RFC8529, March 2019, 1173 . 1175 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1176 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1177 DOI 10.17487/RFC8530, March 2019, 1178 . 1180 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1181 for Connection-Oriented Operations, Administration, and 1182 Maintenance (OAM) Protocols", RFC 8531, 1183 DOI 10.17487/RFC8531, April 2019, 1184 . 1186 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1187 Raghavan, "Generic YANG Data Model for the Management of 1188 Operations, Administration, and Maintenance (OAM) 1189 Protocols That Use Connectionless Communications", 1190 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1191 . 1193 [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. 1194 Raghavan, "A YANG Data Model for Retrieval Methods for the 1195 Management of Operations, Administration, and Maintenance 1196 (OAM) Protocols That Use Connectionless Communications", 1197 RFC 8533, DOI 10.17487/RFC8533, April 2019, 1198 . 1200 [RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data 1201 Model for Tunnel Interface Types", RFC 8675, 1202 DOI 10.17487/RFC8675, November 2019, 1203 . 1205 [RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for 1206 IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, 1207 DOI 10.17487/RFC8676, November 2019, 1208 . 1210 Appendix A. Layered YANG Modules Examples Overview 1212 It is not the intent of this appendix to provide an inventory of 1213 tools and mechanisms used in specific network and service management 1214 domains; such inventory can be found in documents such as [RFC7276]. 1216 A.1. Service Models: Definition and Samples 1218 As described in [RFC8309], the service is "some form of connectivity 1219 between customer sites and the Internet and/or between customer sites 1220 across the network operator's network and across the Internet". More 1221 concretely, an IP connectivity service can be defined as the IP 1222 transfer capability characterized by a (Source Nets, Destination 1223 Nets, Guarantees, Scope) tuple where "Source Nets" is a group of 1224 unicast IP addresses, "Destination Nets" is a group of IP unicast 1225 and/or multicast addresses, and "Guarantees" reflects the guarantees 1226 (expressed in terms of Quality Of Service (QoS), performance, and 1227 availability, for example) to properly forward traffic to the said 1228 "Destination" [RFC7297]. 1230 For example: 1232 o The L3SM model [RFC8299] defines the L3VPN service ordered by a 1233 customer from a network operator. 1235 o The L2SM model [RFC8466] defines the L2VPN service ordered by a 1236 customer from a network operator. 1238 o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang] 1239 provides a YANG data model applicable to any mode of VN operation. 1241 A.2. Network Models: Samples 1243 Figure 8 depicts a set of Network models such as topology models or 1244 tunnel models: 1246 | | 1247 Topo YANG modules | Tunnel YANG modules | 1248 ------------------------------------------------| 1249 +------------+ | | 1250 |Network Top | | +------+ +-----------+ | 1251 | Model | | |Other | | TE Tunnel | | 1252 +----+-------+ | |Tunnel| +------+----+ | 1253 | +--------+ | +------+ | | 1254 |---+Svc Topo| | +--------+-+--------+ 1255 | +--------+ | +----+---+ +---+----+ +-+-----+ 1256 | +--------+ | |MPLS-TE | |RSVP-TE | |SR TE | 1257 |---+L2 Topo | | | Tunnel | | Tunnel | |Tunnel | 1258 | +--------+ | +--------+ +--------+ +-------+ 1259 | +--------+ | 1260 |---+TE Topo | | 1261 | +--------+ | 1262 | +--------+ | 1263 +---+L3 Topo | | 1264 +--------+ | 1266 Figure 8: Sample Resource Facing Network Models 1268 Topology YANG module Examples: 1270 o Network Topology Models: [RFC8345] defines a base model for 1271 network topology and inventories. Network topology data include 1272 link resource, node resource, and terminate-point resources. 1274 o TE Topology Models: [I-D.ietf-teas-yang-te-topo] defines a data 1275 model for representing and manipulating TE topologies. 1277 This module is extended from network topology model defined in 1278 [RFC8345] with TE topologies specifics. This model contains 1279 technology-agnostic TE Topology building blocks that can be 1280 augmented and used by other technology-specific TE Topology 1281 models. 1283 o L3 Topology Models 1285 [RFC8346] defines a data model for representing and manipulating 1286 Layer 3 topologies. This model is extended from the network 1287 topology model defined in [RFC8345] with L3 topologies specifics. 1289 o L2 Topology Models 1291 [I-D.ietf-i2rs-yang-l2-network-topology] defines a data model for 1292 representing and manipulating L2 topologies. This model is 1293 extended from the network topology model defined in [RFC8345] with 1294 Layer 2 topologies specifics. 1296 Tunnel YANG module Examples: 1298 o Tunnel identities to ease manipulating extensions to specific 1299 tunnels [RFC8675]. 1301 o TE Tunnel Model: 1303 [I-D.ietf-teas-yang-te] defines a YANG module for the 1304 configuration and management of TE interfaces, tunnels, and LSPs. 1306 o SR TE Tunnel Model: 1308 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1309 model(s) and defines a YANG module for Segment Routing (SR) TE 1310 specific data. 1312 o MPLS TE Model: 1314 [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE 1315 model(s) and defines a YANG module for MPLS TE configurations, 1316 state, RPC and notifications. 1318 o RSVP-TE MPLS Model: 1320 [I-D.ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 1321 with parameters to configure and manage signaling of MPLS RSVP-TE 1322 LSPs. 1324 Other Network Models: 1326 o Path Computation API Model: 1328 [I-D.ietf-teas-yang-path-computation] YANG module for a stateless 1329 RPC which complements the stateful solution defined in 1330 [I-D.ietf-teas-yang-te]. 1332 o OAM Models (including Fault Management (FM) and Performance 1333 Monitoring): 1335 [RFC8532] defines a base YANG module for the management of OAM 1336 protocols that use Connectionless Communications. [RFC8533] 1337 defines a retrieval method YANG module for connectionless OAM 1338 protocols. [RFC8531] defines a base YANG module for connection 1339 oriented OAM protocols. These three models are intended to 1340 provide consistent reporting, configuration, and representation 1341 for connection-less OAM and Connection oriented OAM separately. 1343 Alarm monitoring is a fundamental part of monitoring the network. 1344 Raw alarms from devices do not always tell the status of the 1345 network services or necessarily point to the root cause. RFC8632 1346 defines a YANG module for alarm management. 1348 o Generic Policy Model: 1350 The Simplified Use of Policy Abstractions (SUPA) policy-based 1351 management framework [RFC8328] defines base YANG modules 1352 [I-D.ietf-supa-generic-policy-data-model] to encode policy. These 1353 models point to other device-, technology-, and service-specific 1354 YANG modules. Policy rules within an operator's environment can 1355 be used to express high-level, possibly network-wide, policies to 1356 a network management function (within a controller, an 1357 orchestrator, or a network element). The network management 1358 function can then control the configuration and/or monitoring of 1359 network elements and services. This document describes the SUPA 1360 basic framework, its elements, and interfaces. 1362 A.3. Device Models: Samples 1364 Network Element models (Figure 9) are used to describe how a service 1365 can be implemented by activating and tweaking a set of functions 1366 (enabled in one or multiple devices, or hosted in cloud 1367 infrastructures) that are involved in the service delivery. Figure 9 1368 uses IETF-defined models as an example. 1370 +----------------+ 1371 --|Device Model | 1372 | +----------------+ 1373 | +------------------+ 1374 +---------------+ | |Logical Network | 1375 | | --| Element Mode | 1376 | Architecture | | +------------------+ 1377 | | | +----------------------+ 1378 +-------+-------+ --|Network Instance Mode | 1379 | | +----------------------+ 1380 | | +-------------------+ 1381 | --|Routing Type Model | 1382 | +-------------------+ 1383 +-------+----------+----+------+------------+-----------+-------+ 1384 | | | | | | | 1385 +-+-+ +---+---+ +--+------+ +-+-+ +-----+---+ +---+-+ | 1386 |ACL| |Routing| |Transport| |OAM| |Multicast| | PM | Others 1387 +---+ |-------+ +---------+ +---+ +---------+ +-----+ 1388 | +-------+ +----------+ +-------+ +-----+ +-----+ 1389 --|Core | |MPLS Basic| |BFD | |IGMP | |TWAMP| 1390 | |Routing| +----------+ +-------+ |/MLD | +-----+ 1391 | +-------+ |MPLS LDP | |LSP Ping +-----+ |OWAMP| 1392 --|BGP | +----------+ +-------+ |PIM | +-----+ 1393 | +-------+ |MPLS Static |MPLS-TP| +-----+ |LMAP | 1394 --|ISIS | +----------+ +-------+ |MVPN | +-----+ 1395 | +-------+ +-----+ 1396 --|OSPF | 1397 | +-------+ 1398 --|RIP | 1399 | +-------+ 1400 --|VRRP | 1401 | +-------+ 1402 --|SR/SRv6| 1403 | +-------+ 1404 --|ISIS-SR| 1405 | +-------+ 1406 --|OSPF-SR| 1407 +-------+ 1409 Figure 9: Network Element Modules Overview 1411 A.3.1. Model Composition 1413 o Device Model 1415 [I-D.ietf-rtgwg-device-model] presents an approach for organizing 1416 YANG modules in a comprehensive logical structure that may be used 1417 to configure and operate network devices. The structure is itself 1418 represented as an example YANG module, with all of the related 1419 component models logically organized in a way that is 1420 operationally intuitive, but this model is not expected to be 1421 implemented. 1423 o Logical Network Element Model 1425 [RFC8530] defines a logical network element module which can be 1426 used to manage the logical resource partitioning that may be 1427 present on a network device. Examples of common industry terms 1428 for logical resource partitioning are Logical Systems or Logical 1429 Routers. 1431 o Network Instance Model 1433 [RFC8529] defines a network instance module. This module can be 1434 used to manage the virtual resource partitioning that may be 1435 present on a network device. Examples of common industry terms 1436 for virtual resource partitioning are Virtual Routing and 1437 Forwarding (VRF) instances and Virtual Switch Instances (VSIs). 1439 A.3.1.1. Schema Mount 1441 Modularity and extensibility were among the leading design principles 1442 of the YANG data modeling language. As a result, the same YANG 1443 module can be combined with various sets of other modules and thus 1444 form a data model that is tailored to meet the requirements of a 1445 specific use case. [RFC8528] defines a mechanism, denoted schema 1446 mount, that allows for mounting one data model consisting of any 1447 number of YANG modules at a specified location of another (parent) 1448 schema. 1450 That capability does not cover design time. 1452 A.3.2. Device Models: Samples 1454 The following provides an overview of some device models that can be 1455 used within a network. This list is not comprehensive. 1457 BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for 1458 configuring and managing BGP, including protocol, policy, 1459 and operational aspects based on data center, carrier, and 1460 content provider operational requirements. 1462 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 1463 which serves as a base framework for configuring and 1464 managing an MPLS switching subsystem. It is expected that 1465 other MPLS technology YANG modules (e.g., MPLS LSP Static, 1466 LDP or RSVP-TE models) will augment the MPLS base YANG 1467 module. 1469 QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of 1470 Differentiated Services for configuration and operations. 1472 ACL: Access Control List (ACL) is one of the basic elements 1473 used to configure device forwarding behavior. It is used 1474 in many networking technologies such as Policy Based 1475 Routing, Firewalls, etc. [RFC8519] describes a data model 1476 of ACL basic building blocks. 1478 NAT: For the sake of network automation and the need for 1479 programming Network Address Translation (NAT) function in 1480 particular, a data model for configuring and managing the 1481 NAT is essential. [RFC8512] defines a YANG module for the 1482 NAT function covering a variety of NAT flavors such as 1483 Network Address Translation from IPv4 to IPv4 (NAT44), 1484 Network Address and Protocol Translation from IPv6 Clients 1485 to IPv4 Servers (NAT64), customer-side translator (CLAT), 1486 Stateless IP/ICMP Translation (SIIT), Explicit Address 1487 Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix 1488 Translation (NPTv6), and Destination NAT. [RFC8513] 1489 specifies a DS-Lite YANG module. 1491 Stateless Address Sharing: [RFC8676] specifies a YANG module for A+P 1492 address sharing, including Lightweight 4over6, Mapping of 1493 Address and Port with Encapsulation (MAP-E), and Mapping 1494 of Address and Port using Translation (MAP-T) softwire 1495 mechanisms. 1497 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 1498 to configure and manage Protocol Independent Multicast 1499 (PIM) devices. 1501 RFC8652 defines a YANG module that can be used to 1502 configure and manage Internet Group Management Protocol 1503 (IGMP) and Multicast Listener Discovery (MLD) devices. 1505 [I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG 1506 module that can be used to configure and manage Internet 1507 Group Management Protocol (IGMP) and Multicast Listener 1508 Discovery (MLD) Snooping devices. 1510 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for 1511 Ethernet VPN services. The model is agnostic of the 1512 underlay. It applies to MPLS as well as to VxLAN 1513 encapsulation. The module is also agnostic to the 1514 services, including E-LAN, E-LINE, and E-TREE services. 1516 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can 1517 be used to configure and manage BGP L3VPNs [RFC4364]. It 1518 contains VRF specific parameters as well as BGP specific 1519 parameters applicable for L3VPNs. 1521 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS 1522 based Layer 2 VPN services (L2VPN) [RFC4664] and includes 1523 switching between the local attachment circuits. The 1524 L2VPN model covers point-to-point VPWS and Multipoint VPLS 1525 services. These services use signaling of Pseudowires 1526 across MPLS networks using LDP [RFC8077][RFC4762] or BGP 1527 [RFC4761]. 1529 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module 1530 for configuring and managing routing policies based on 1531 operational practice. The module provides a generic 1532 policy framework which can be augmented with protocol- 1533 specific policy configuration. 1535 BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a 1536 network protocol which is used for liveness detection of 1537 arbitrary paths between systems. [I-D.ietf-bfd-yang] 1538 defines a YANG module that can be used to configure and 1539 manage BFD. 1541 SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment 1542 routing configuration and operation. 1544 Core Routing: [RFC8349] defines the core routing data model, which 1545 is intended as a basis for future data model development 1546 covering more-sophisticated routing systems. It is 1547 expected that other Routing technology YANG modules (e.g., 1548 VRRP, RIP, ISIS, OSPF models) will augment the Core 1549 Routing base YANG module. 1551 PM: 1553 [I-D.ietf-ippm-twamp-yang] defines a data model for client 1554 and server implementations of the Two-Way Active 1555 Measurement Protocol (TWAMP). 1557 [I-D.ietf-ippm-stamp-yang] defines the data model for 1558 implementations of Session-Sender and Session-Reflector 1559 for Simple Two-way Active Measurement Protocol (STAMP) 1560 mode using YANG. 1562 [RFC8194] defines a data model for Large-Scale Measurement 1563 Platforms (LMAPs). 1565 Authors' Addresses 1567 Qin Wu (editor) 1568 Huawei 1569 101 Software Avenue, Yuhua District 1570 Nanjing, Jiangsu 210012 1571 China 1573 Email: bill.wu@huawei.com 1575 Mohamed Boucadair (editor) 1576 Orange 1577 Rennes 35000 1578 France 1580 Email: mohamed.boucadair@orange.com 1582 Diego R. Lopez 1583 Telefonica I+D 1584 Spain 1586 Email: diego.r.lopez@telefonica.com 1588 Chongfeng Xie 1589 China Telecom 1590 Beijing 1591 China 1593 Email: xiechf.bri@chinatelecom.cn 1595 Liang Geng 1596 China Mobile 1598 Email: gengliang@chinamobile.com