idnits 2.17.1 draft-ietf-opsawg-model-automation-framework-01.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 (February 26, 2020) is 1520 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-idr-bgp-yang-model' is mentioned on line 1541, but not defined == Unused Reference: 'I-D.arkko-arch-virtualization' is defined on line 905, but no explicit reference was found in the text == Unused Reference: 'I-D.clacla-netmod-model-catalog' is defined on line 916, but no explicit reference was found in the text == Unused Reference: 'I-D.homma-slice-provision-models' is defined on line 921, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-yang' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-alarm-module' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-media-channel-yang' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-yang' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-l1csm-yang' is defined on line 967, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-mw-yang' is defined on line 973, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-otn-topo-yang' is defined on line 979, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-otn-tunnel-model' is defined on line 985, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-wson-tunnel-model' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-model' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-stamp-yang' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-twamp-yang' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pim-igmp-mld-snooping-yang' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-device-model' is defined on line 1049, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-data-model' is defined on line 1074, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-sf-aware-topo-model' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-te-service-mapping-yang' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-l3-te-topo' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-path-computation' is defined on line 1110, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-rsvp-te' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-sr-te-topo' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 1134, but no explicit reference was found in the text == 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-05 == 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 (-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-12 == 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-08 == 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-01 == 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-04 == 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-08 == 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-06 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-22 == Outdated reference: A later version (-01) exists of draft-ogondio-opsawg-uni-topology-00 Summary: 0 errors (**), 0 flaws (~~), 51 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: August 29, 2020 Orange 6 D. Lopez 7 Telefonica I+D 8 C. Xie 9 China Telecom 10 L. Geng 11 China Mobile 12 February 26, 2020 14 A Framework for Automating Service and Network Management with YANG 15 draft-ietf-opsawg-model-automation-framework-01 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 August 29, 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 . . . . . . . . . . . . 15 99 5.1. L3VPN Service Delivery . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . 19 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 108 10.2. Informative References . . . . . . . . . . . . . . . . . 21 109 Appendix A. Layered YANG Modules Example Overview . . . . . . . 29 110 A.1. Service Models: Definition and Samples . . . . . . . . . 29 111 A.2. Network Models: Definitions and Samples . . . . . . . . . 30 112 A.3. Device Models: Definitions and Samples . . . . . . . . . 32 113 A.3.1. Model Composition . . . . . . . . . . . . . . . . . . 33 114 A.3.2. Device Models: Definitions and Samples . . . . . . . 34 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 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-requirement-derived dynamic resource 159 allocation and policy enforcement schemes, so that networks can be 160 programmed 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 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 modules 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 and the delivery of service orders. One or more 364 monolithic Service Models can be used in the context of a composite 365 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 lead 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 NAT or address sharing 600 o Security function 602 This specific configuration models can be used to configure PE and CE 603 devices within the site, e.g., a BGP policy model can be used to 604 establish VPN membership between sites and VPN Service Topology. 606 4.2.2. Configuration Validation 608 Configuration validation is used to validate intended configuration 609 and ensure the configuration take effect. For example, a customer 610 creates an interface "et-0/0/0" but the interface does not physically 611 exist at this point, then configuration data appears in the 612 status but does not appear in datastore. 614 4.2.3. Performance Monitoring/Model-driven Telemetry 616 When configuration is in effect in the device, 617 datastore holds the complete operational state of the device 618 including learned, system, default configuration and system state. 619 However the configurations and state of a particular device does not 620 have the visibility to the whole network or information of the flow 621 packets are going to take through the entire network. Therefore it 622 becomes more difficult to operate the network without understanding 623 the current status of the network. 625 The management system should subscribe to updates of a YANG datastore 626 in all the network devices for performance monitoring purpose and 627 build full topological visibility to the network by aggregating and 628 filtering these operational state from different sources. 630 4.2.4. Fault Diagnostic 632 When configuration is in effect in the device, some device may be 633 misconfigured(e.g.,device links are not consistent on both sides of 634 the network connection), network resources be misallocated and 635 services may be negatively affected without knowing what is going on 636 in the network. 638 Technology-dependent nodes and RPC commands are defined in 639 technology-specific YANG data models which can use and extend the 640 base model described in Section 4.1.4can be used to deal with these 641 challenges. 643 These RPC commands received in the technology dependent node can be 644 used to trigger technology specific OAM message exchange for fault 645 verification and fault isolation,e.g., TRILL Multicast Tree 646 Verification (MTV) RPC command [I-D.ietf-trill-yang-oam] can be used 647 to trigger Multi-Destination Tree Verification Message defined in 648 [RFC7455] to verify TRILL distribution tree integrity. 650 4.3. Multi-layer/Multi-domain Service Mapping 652 Multi-layer/Multi-domain Service Mapping allow you map end to end 653 abstract view of the service segmented at different layer or 654 different administrative domain into domain specific view. One 655 example is to map service parameters in L3VPN service model into 656 configuration parameters such as RD, RT, and VRF in L3VPN network 657 model. Another example is to map service parameters in L3VPN service 658 model into TE tunnel parameter (e.g.,Tunnel ID) in TE model and VN 659 parameters (e.g., AP list, VN member) in TEAS VN model 660 [I-D.ietf-teas-actn-vn-yang]. 662 4.4. Service Decomposing 664 Service Decomposing allows to decompose service model at the service 665 level or network model at the network level into a set of device/ 666 function models at the device level. These device models may be tied 667 to specific device type or classified into a collection of related 668 YANG modules based on service type and feature offered and load at 669 the implementation time before configuration is loaded and validated. 671 5. YANG Data Model Integration Examples 673 5.1. L3VPN Service Delivery 674 L3SM | ^ 675 Service | | Notifications 676 Model | | 677 +--------------------+----------------------------+ 678 | +-----V- -------+ | 679 | Orchestrator |Service Mapping| | 680 | +-----+---------+ | 681 | | | 682 +--------------------+----------------------------+ 683 L3NM | ^ 684 Network| | L3NM Notifications 685 Model | | L3NM Capabilities 686 +--------------------+----------------------------+ 687 | Controller+--------V-----------+ | 688 | | Service Decomposing| | 689 | +-++------------++---+ | 690 | || || | 691 | || || | 692 +-------------++---------- ++--------------------+ 693 || || 694 || || 695 ||BGP,QoS || 696 || || 697 +----------+|NI,Intf,IP |+-----------------+ 698 +--+--+ +++---+ --+---+ +--+--+ 699 | CE1 |------| PE1 | | PE2 | ---------+ CE2 | 700 +-----+ +-----+ +-----+ +-----+ 702 Figure 5: L3VPN Service Delivery Example 704 In reference to Figure 5, the following steps are performed to 705 deliver the L3VPN service within the network management automation 706 architecture defined in this document: 708 1. The Customer requests to create two sites (as per service 709 creation operation in Section 4.2.1) relying upon a L3SM Service 710 model with each having one network access connectivity: 712 Site A: Network-Access A, Bandwidth=20M, for class "foo", 713 guaranteed-bw-percent = 10, One-Way-Delay=70 msec 715 Site B: Network-Access B, Bandwidth=30M, for class "foo1", 716 guaranteed-bw-percent = 15, One-Way-Delay=60 msec 718 2. The Orchestrator extracts the service parameters from the L3SM 719 model. Then, it uses them as input to translate ("service 720 mapping operation" in Section 4.4) them into an orchestrated 721 configuration of network elements (e.g., RD, RT, VRF) that are 722 part of the L3NM network model. 724 3. The Controller takes orchestrated configuration parameters in the 725 L3NM network model and translates them into orchestrated 726 ("service decomposing operation" in ) configuration of network 727 elements that are part of, e.g, BGP, QoS, Network Instance model, 728 IP management, and interface models. 730 [I-D.ogondio-opsawg-uni-topology] is used for representing, managing 731 and controlling the User Network Interface (UNI) topology. 733 L3NM inherits some of data elements from the L3SM. Likewise, the 734 L3NM expose some information to the above layer such as the 735 capabilities of an underlying network (which can be used to drive 736 service order handling) or notifications (to notify subscribers about 737 specific events or degradations as per agreed SLAs). 739 5.2. VN Lifecycle Management 741 | 742 VN | 743 Service | 744 Model | 745 +----------------------|--------------------------+ 746 | Orchestrator | | 747 | +--------V--------+ | 748 | | Service Mapping | | 749 | +-----------------+ | 750 +----------------------+--------------------^-----+ 751 TE | Telemetry 752 Tunnel | Model 753 Model | | 754 +----------------------V--------------------+----+ 755 | Controller | 756 | | 757 +-------------------------------------------------+ 759 +-----+ +-----+ +-----+ +-----+ 760 | CE1 |------| PE1 | | PE2 |---------+ CE2 | 761 +-----+ +-----+ +-----+ +-----+ 763 Figure 6 765 In reference to Figure 6, the following steps are performed to 766 deliver the VN service within the network management automation 767 architecture defined in this document: 769 1. Customer requests (service exposure operation in Section 4.1.1) 770 to create 'VN' based on Access point, association between VN and 771 Access point, VN member defined in the VN YANG module. 773 2. The orchestrator creates the single abstract node topology based 774 on the information captured in an VN YANG module. 776 3. The Customer exchanges connectivity-matrix on abstract node and 777 explicit path using TE topology model with the orchestrator. 778 This information can be used to instantiate VN and setup tunnels 779 between source and destination endpoints (service creation 780 operation in Section 4.1.2). 782 4. The telemetry model which augments the TEAS VN model and 783 corresponding TE Tunnel model can be used to subscribe to 784 performance measurement data and notify all the parameter changes 785 and network performance change related to VN topology or Tunnel 786 [I-D.ietf-teas-actn-pm-telemetry-autonomics] and provide service 787 assurance (service optimization operation in Section 4.1.3). 789 5.3. Event-based Telemetry in the Device Self management 791 +----------------+ 792 | | 793 | Controller | 794 +----------------+ 795 | 796 | 797 ECA | 798 Model| ^ 799 | |Notif 800 | | 801 +------------V-------------+-------+ 802 |Device | Reconfig 803 | +-------+ +---------+ +--+---+ | 804 | | Event --> Event -->Event --> | 805 | | Source| |Condition| |Action| | 806 | +-------+ +---------+ +------+ | 807 +--------Update------trigger-------+ 809 Figure 7: Event-based Telemetry 811 In reference to Figure 7, the following steps are performed to 812 monitor state changes of managed objects or resource in the device 813 and provide device self management within the network management 814 automation architecture defined in this document: 816 1. To control which state a network device should be in or is 817 allowed to be in at any given time, a set of conditions and 818 actions are defined and correlated with network events (e.g., 819 allow the NETCONF server send updates only when the value exceeds 820 a certain threshold for the first time but not again until the 821 threshold is cleared.), which constitute an event-driven policy 822 or network control logic in the controller. 824 2. The controller pushes ECA policy to the network device and 825 delegate network control logic to the network device. 827 3. The network device generates ECA script from ECA model and 828 execute ECA script or network control logic based on Event. 829 Event based notification or telemetry can be triggered if a 830 certain condition is satisfied (model driven telemetry operation 831 in Section 4.2.3). 833 6. Security Considerations 835 Security considerations specific to each of the technologies and 836 protocols listed in the document are discussed in the specification 837 documents of each of these techniques. 839 (Potential) security considerations specific to this document are 840 listed below: 842 o Create forwarding loops by mis-configuring the underlying network. 844 o Leak sensitive information: special care should be considered when 845 translating between the various layers introduced in the document. 847 o Some Service Models may include a traffic isolation clause, 848 appropriate technology-specific actions must be enforced to avoid 849 that traffic is accessible to non-authorized parties. 851 7. IANA Considerations 853 There are no IANA requests or assignments included in this document. 855 8. Acknowledgements 857 Thanks to Joe Clark, Greg Mirsky, and Shunsuke Homma for the review. 859 9. Contributors 860 Christian Jacquenet 861 Orange 862 Rennes, 35000 863 France 864 Email: Christian.jacquenet@orange.com 866 Luis Miguel Contreras Murillo 867 Telifonica 869 Email: luismiguel.contrerasmurillo@telefonica.com 871 Oscar Gonzalez de Dios 872 Telefonica 873 Madrid 874 ES 876 Email: oscar.gonzalezdedios@telefonica.com 878 Chongfeng Xie 879 China Telecom 880 Beijing 881 China 883 Email: xiechf.bri@chinatelecom.cn 885 Weiqiang Cheng 886 China Mobile 888 Email: chengweiqiang@chinamobile.com 890 Young Lee 891 Sung Kyun Kwan University 893 Email: younglee.tx@gmail.com 895 10. References 897 10.1. Normative References 899 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 900 RFC 7950, DOI 10.17487/RFC7950, August 2016, 901 . 903 10.2. Informative References 905 [I-D.arkko-arch-virtualization] 906 Arkko, J., Tantsura, J., Halpern, J., and B. Varga, 907 "Considerations on Network Virtualization and Slicing", 908 draft-arkko-arch-virtualization-01 (work in progress), 909 March 2018. 911 [I-D.asechoud-netmod-diffserv-model] 912 Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N. 913 Strahle, "YANG Model for Diffserv", draft-asechoud-netmod- 914 diffserv-model-03 (work in progress), June 2015. 916 [I-D.clacla-netmod-model-catalog] 917 Clarke, J. and B. Claise, "YANG module for 918 yangcatalog.org", draft-clacla-netmod-model-catalog-03 919 (work in progress), April 2018. 921 [I-D.homma-slice-provision-models] 922 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 923 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 924 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 925 Foy, "Network Slice Provision Models", draft-homma-slice- 926 provision-models-02 (work in progress), November 2019. 928 [I-D.ietf-bess-evpn-yang] 929 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 930 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 931 bess-evpn-yang-07 (work in progress), March 2019. 933 [I-D.ietf-bess-l2vpn-yang] 934 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 935 and K. Tiruveedhula, "YANG Data Model for MPLS-based 936 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 937 July 2019. 939 [I-D.ietf-bess-l3vpn-yang] 940 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 941 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 942 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 943 in progress), October 2018. 945 [I-D.ietf-bfd-yang] 946 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 947 and G. Mirsky, "YANG Data Model for Bidirectional 948 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 949 in progress), August 2018. 951 [I-D.ietf-ccamp-alarm-module] 952 Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft- 953 ietf-ccamp-alarm-module-09 (work in progress), April 2019. 955 [I-D.ietf-ccamp-flexigrid-media-channel-yang] 956 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 957 King, D., Lee, Y., and G. Galimberti, "YANG data model for 958 Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid- 959 media-channel-yang-02 (work in progress), March 2019. 961 [I-D.ietf-ccamp-flexigrid-yang] 962 Madrid, U., Perdices, D., Lopezalvarez, V., King, D., Lee, 963 Y., and H. Zheng, "YANG data model for Flexi-Grid Optical 964 Networks", draft-ietf-ccamp-flexigrid-yang-05 (work in 965 progress), January 2020. 967 [I-D.ietf-ccamp-l1csm-yang] 968 Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. 969 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 970 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in 971 progress), September 2019. 973 [I-D.ietf-ccamp-mw-yang] 974 Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M. 975 Vaupotic, "A YANG Data Model for Microwave Radio Link", 976 draft-ietf-ccamp-mw-yang-13 (work in progress), November 977 2018. 979 [I-D.ietf-ccamp-otn-topo-yang] 980 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Dios, "A 981 YANG Data Model for Optical Transport Network Topology", 982 draft-ietf-ccamp-otn-topo-yang-09 (work in progress), 983 November 2019. 985 [I-D.ietf-ccamp-otn-tunnel-model] 986 Zheng, H., Busi, I., Belotti, S., Lopezalvarez, V., and Y. 987 Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 988 model-09 (work in progress), November 2019. 990 [I-D.ietf-ccamp-wson-tunnel-model] 991 Lee, Y., Zheng, H., Guo, A., Lopezalvarez, V., King, D., 992 Yoon, B., and R. Vilata, "A Yang Data Model for WSON 993 Tunnel", draft-ietf-ccamp-wson-tunnel-model-04 (work in 994 progress), September 2019. 996 [I-D.ietf-dots-data-channel] 997 Boucadair, M. and T. Reddy.K, "Distributed Denial-of- 998 Service Open Threat Signaling (DOTS) Data Channel 999 Specification", draft-ietf-dots-data-channel-31 (work in 1000 progress), July 2019. 1002 [I-D.ietf-dots-signal-channel] 1003 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 1004 N. Teague, "Distributed Denial-of-Service Open Threat 1005 Signaling (DOTS) Signal Channel Specification", draft- 1006 ietf-dots-signal-channel-41 (work in progress), January 1007 2020. 1009 [I-D.ietf-idr-bgp-model] 1010 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 1011 YANG Model for Service Provider Networks", draft-ietf-idr- 1012 bgp-model-07 (work in progress), October 2019. 1014 [I-D.ietf-ippm-stamp-yang] 1015 Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active 1016 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 1017 stamp-yang-05 (work in progress), October 2019. 1019 [I-D.ietf-ippm-twamp-yang] 1020 Civil, R., Morton, A., Rahman, R., Jethanandani, M., and 1021 K. Pentikousis, "Two-Way Active Measurement Protocol 1022 (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work 1023 in progress), July 2018. 1025 [I-D.ietf-mpls-base-yang] 1026 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 1027 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 1028 yang-12 (work in progress), February 2020. 1030 [I-D.ietf-pim-igmp-mld-snooping-yang] 1031 Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, 1032 "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- 1033 pim-igmp-mld-snooping-yang-09 (work in progress), January 1034 2020. 1036 [I-D.ietf-pim-igmp-mld-yang] 1037 Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 1038 Peter, "A YANG Data Model for Internet Group Management 1039 Protocol (IGMP) and Multicast Listener Discovery (MLD)", 1040 draft-ietf-pim-igmp-mld-yang-15 (work in progress), June 1041 2019. 1043 [I-D.ietf-pim-yang] 1044 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1045 Y., and f. hu, "A YANG Data Model for Protocol Independent 1046 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1047 progress), May 2018. 1049 [I-D.ietf-rtgwg-device-model] 1050 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 1051 "Network Device YANG Logical Organization", draft-ietf- 1052 rtgwg-device-model-02 (work in progress), March 2017. 1054 [I-D.ietf-rtgwg-policy-model] 1055 Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data 1056 Model for Routing Policy Management", draft-ietf-rtgwg- 1057 policy-model-08 (work in progress), January 2020. 1059 [I-D.ietf-softwire-iftunnel] 1060 Boucadair, M., Farrer, I., and R. Asati, "Tunnel Interface 1061 Types YANG Module", draft-ietf-softwire-iftunnel-07 (work 1062 in progress), June 2019. 1064 [I-D.ietf-softwire-yang] 1065 Farrer, I. and M. Boucadair, "YANG Modules for IPv4-in- 1066 IPv6 Address plus Port (A+P) Softwires", draft-ietf- 1067 softwire-yang-16 (work in progress), January 2019. 1069 [I-D.ietf-spring-sr-yang] 1070 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 1071 Tantsura, "YANG Data Model for Segment Routing", draft- 1072 ietf-spring-sr-yang-15 (work in progress), January 2020. 1074 [I-D.ietf-supa-generic-policy-data-model] 1075 Halpern, J. and J. Strassner, "Generic Policy Data Model 1076 for Simplified Use of Policy Abstractions (SUPA)", draft- 1077 ietf-supa-generic-policy-data-model-04 (work in progress), 1078 June 2017. 1080 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 1081 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 1082 and D. Ceccarelli, "YANG models for VN/TE Performance 1083 Monitoring Telemetry and Scaling Intent Autonomics", 1084 draft-ietf-teas-actn-pm-telemetry-autonomics-01 (work in 1085 progress), October 2019. 1087 [I-D.ietf-teas-actn-vn-yang] 1088 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1089 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1090 teas-actn-vn-yang-07 (work in progress), October 2019. 1092 [I-D.ietf-teas-sf-aware-topo-model] 1093 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, 1094 L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology 1095 YANG Model", draft-ietf-teas-sf-aware-topo-model-04 (work 1096 in progress), November 2019. 1098 [I-D.ietf-teas-te-service-mapping-yang] 1099 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 1100 and J. Tantsura, "Traffic Engineering (TE) and Service 1101 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 1102 yang-02 (work in progress), September 2019. 1104 [I-D.ietf-teas-yang-l3-te-topo] 1105 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1106 O. Dios, "YANG Data Model for Layer 3 TE Topologies", 1107 draft-ietf-teas-yang-l3-te-topo-05 (work in progress), 1108 July 2019. 1110 [I-D.ietf-teas-yang-path-computation] 1111 Busi, I., Belotti, S., Lopezalvarez, V., Sharma, A., and 1112 Y. Shi, "Yang model for requesting Path Computation", 1113 draft-ietf-teas-yang-path-computation-08 (work in 1114 progress), December 2019. 1116 [I-D.ietf-teas-yang-rsvp-te] 1117 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 1118 and H. Shah, "A YANG Data Model for RSVP-TE Protocol", 1119 draft-ietf-teas-yang-rsvp-te-07 (work in progress), July 1120 2019. 1122 [I-D.ietf-teas-yang-sr-te-topo] 1123 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1124 S. Litkowski, "YANG Data Model for SR and SR TE 1125 Topologies", draft-ietf-teas-yang-sr-te-topo-06 (work in 1126 progress), November 2019. 1128 [I-D.ietf-teas-yang-te] 1129 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1130 "A YANG Data Model for Traffic Engineering Tunnels and 1131 Interfaces", draft-ietf-teas-yang-te-22 (work in 1132 progress), November 2019. 1134 [I-D.ietf-teas-yang-te-topo] 1135 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1136 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1137 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 1138 progress), June 2019. 1140 [I-D.ietf-trill-yang-oam] 1141 Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., 1142 and H. Weiguo, "YANG Data Model for TRILL Operations, 1143 Administration, and Maintenance (OAM)", draft-ietf-trill- 1144 yang-oam-05 (work in progress), March 2017. 1146 [I-D.ogondio-opsawg-uni-topology] 1147 Dios, O., Barguil, S., WU, Q., and M. Boucadair, "A YANG 1148 Model for User-Network Interface (UNI) Topologies", draft- 1149 ogondio-opsawg-uni-topology-00 (work in progress), 1150 November 2019. 1152 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1153 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1154 2006, . 1156 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1157 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1158 DOI 10.17487/RFC4664, September 2006, 1159 . 1161 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1162 LAN Service (VPLS) Using BGP for Auto-Discovery and 1163 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1164 . 1166 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1167 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1168 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1169 . 1171 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1172 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1173 . 1175 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1176 Networking: A Perspective from within a Service Provider 1177 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1178 . 1180 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1181 Weingarten, "An Overview of Operations, Administration, 1182 and Maintenance (OAM) Tools", RFC 7276, 1183 DOI 10.17487/RFC7276, June 2014, 1184 . 1186 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1187 Connectivity Provisioning Profile (CPP)", RFC 7297, 1188 DOI 10.17487/RFC7297, July 2014, 1189 . 1191 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 1192 3rd, D., Aldrin, S., and Y. Li, "Transparent 1193 Interconnection of Lots of Links (TRILL): Fault 1194 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 1195 . 1197 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 1198 Maintenance Using the Label Distribution Protocol (LDP)", 1199 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 1200 . 1202 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1203 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1204 August 2017, . 1206 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1207 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1208 2017, . 1210 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1211 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1212 DOI 10.17487/RFC8299, January 2018, 1213 . 1215 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1216 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1217 . 1219 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 1220 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 1221 Management Framework for the Simplified Use of Policy 1222 Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328, 1223 March 2018, . 1225 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1226 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1227 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1228 2018, . 1230 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1231 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1232 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1233 March 2018, . 1235 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1236 Routing Management (NMDA Version)", RFC 8349, 1237 DOI 10.17487/RFC8349, March 2018, 1238 . 1240 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1241 Data Model for Layer 2 Virtual Private Network (L2VPN) 1242 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1243 2018, . 1245 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1246 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1247 Address Translation (NAT) and Network Prefix Translation 1248 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1249 . 1251 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1252 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1253 DOI 10.17487/RFC8513, January 2019, 1254 . 1256 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1257 "YANG Data Model for Network Access Control Lists (ACLs)", 1258 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1259 . 1261 [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", 1262 RFC 8528, DOI 10.17487/RFC8528, March 2019, 1263 . 1265 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1266 Liu, "YANG Data Model for Network Instances", RFC 8529, 1267 DOI 10.17487/RFC8529, March 2019, 1268 . 1270 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1271 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1272 DOI 10.17487/RFC8530, March 2019, 1273 . 1275 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1276 for Connection-Oriented Operations, Administration, and 1277 Maintenance (OAM) Protocols", RFC 8531, 1278 DOI 10.17487/RFC8531, April 2019, 1279 . 1281 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1282 Raghavan, "Generic YANG Data Model for the Management of 1283 Operations, Administration, and Maintenance (OAM) 1284 Protocols That Use Connectionless Communications", 1285 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1286 . 1288 [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. 1289 Raghavan, "A YANG Data Model for Retrieval Methods for the 1290 Management of Operations, Administration, and Maintenance 1291 (OAM) Protocols That Use Connectionless Communications", 1292 RFC 8533, DOI 10.17487/RFC8533, April 2019, 1293 . 1295 Appendix A. Layered YANG Modules Example Overview 1297 It is not the intent of this document to provide an inventory of 1298 tools and mechanisms used in specific network and service management 1299 domains; such inventory can be found in documents such as [RFC7276]. 1301 A.1. Service Models: Definition and Samples 1303 As described in [RFC8309], the service is "some form of connectivity 1304 between customer sites and the Internet and/or between customer sites 1305 across the network operator's network and across the Internet". More 1306 concretely, an IP connectivity service can be defined as the IP 1307 transfer capability characterized by a (Source Nets, Destination 1308 Nets, Guarantees, Scope) tuple where "Source Nets" is a group of 1309 unicast IP addresses, "Destination Nets" is a group of IP unicast 1310 and/or multicast addresses, and "Guarantees" reflects the guarantees 1311 (expressed in terms of Quality Of Service (QoS), performance, and 1312 availability, for example) to properly forward traffic to the said 1313 "Destination" [RFC7297]. 1315 For example: 1317 o L3SM model [RFC8299] defines the L3VPN service ordered by a 1318 customer from a network operator. 1320 o L2SM model [RFC8466] defines the L2VPN service ordered by a 1321 customer from a network operator. 1323 o VN model [I-D.ietf-teas-actn-vn-yang]provides a YANG data model 1324 generally applicable to any mode of Virtual Network (VN) 1325 operation. 1327 A.2. Network Models: Definitions and Samples 1329 Figure 8 depicts a set of Network models such as topology models or 1330 tunnel models: 1332 | | 1333 Topo YANG modules | Tunnel YANG modules | 1334 ------------------------------------------------| 1335 +------------+ | | 1336 |Network Top | | +------+ +-----------+ | 1337 | Model | | |Other | | TE Tunnel | | 1338 +----+-------+ | |Tunnel| +------+----+ | 1339 | +--------+ | +------+ | | 1340 |---+Svc Topo| | +--------+-+--------+ 1341 | +--------+ | +----+---+ +---+----+ +-+-----+ 1342 | +--------+ | |MPLS-TE | |RSVP-TE | |SR TE | 1343 |---+L2 Topo | | | Tunnel | | Tunnel | |Tunnel | 1344 | +--------+ | +--------+ +--------+ +-------+ 1345 | +--------+ | 1346 |---+TE Topo | | 1347 | +--------+ | 1348 | +--------+ | 1349 +---+L3 Topo | | 1350 +--------+ | 1352 Figure 8: Sample Resource Facing Network Models 1354 Topology YANG module Examples: 1356 o Network Topology Models: [RFC8345] defines a base model for 1357 network topology and inventories. Network topology data include 1358 link resource, node resource, and terminate-point resources. 1360 o TE Topology Models: [I.D-ietf-teas-yang-te-topo] defines a data 1361 model for representing and manipulating TE topologies. 1363 This module is extended from network topology model defined in 1364 [RFC8345] with TE topologies specifics. This model contains 1365 technology-agnostic TE Topology building blocks that can be 1366 augmented and used by other technology-specific TE Topology 1367 models. 1369 o L3 Topology Models 1371 [RFC8346] defines a data model for representing and manipulating 1372 L3 Topologies. This model is extended from the network topology 1373 model defined in [RFC8345] with L3 topologies specifics. 1375 o L2 Topology Models 1377 [I.D-ietf-i2rs-yang-l2-topology] defines a data model for 1378 representing and manipulating L2 Topologies. This model is 1379 extended from the network topology model defined in [RFC8345] with 1380 L2 topologies specifics. 1382 Tunnel YANG module Examples: 1384 o Tunnel identities [I-D.ietf-softwire-iftunnel] to ease 1385 manipulating extensions to specific tunnels. 1387 o TE Tunnel Model 1389 [I.D-ietf-teas-yang-te] defines a YANG module for the 1390 configuration and management of TE interfaces, tunnels and LSPs. 1392 o SR TE Tunnel Model 1394 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 1395 model(s) and defines a YANG module for Segment Routing (SR) TE 1396 specific data. 1398 o MPLS TE Model 1400 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 1401 model(s) and defines a YANG module for MPLS TE configurations, 1402 state, RPC and notifications. 1404 o RSVP-TE MPLS Model 1406 [I.D-ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 1407 with parameters to configure and manage signaling of MPLS RSVP-TE 1408 LSPs. 1410 Other Network Models: 1412 o Path Computation API Model 1414 [I.D-ietf-teas-path-computation] YANG module for a stateless RPC 1415 which complements the stateful solution defined in [I.D-ietf-teas- 1416 yang-te]. 1418 o OAM Models (including Fault Management (FM) and Performance 1419 Monitoring) 1421 [RFC8532] defines a base YANG module for the management of OAM 1422 protocols that use Connectionless Communications. [RFC8533] 1423 defines a retrieval method YANG module for connectionless OAM 1424 protocols. [RFC8531] defines a base YANG module for connection 1425 oriented OAM protocols. These three models are intended to 1426 provide consistent reporting, configuration and representation for 1427 connection-less OAM and Connection oriented OAM separately. 1429 Alarm monitoring is a fundamental part of monitoring the network. 1430 Raw alarms from devices do not always tell the status of the 1431 network services or necessarily point to the root cause. [I.D- 1432 ietf-ccamp-alarm-module] defines a YANG module for alarm 1433 management. 1435 o Generic Policy Model 1437 The Simplified Use of Policy Abstractions (SUPA) policy-based 1438 management framework [RFC8328] defines base YANG modules 1439 [I-D.ietf-supa-generic-policy-data-model]to encode policy. These 1440 models point to device-, technology-, and service-specific YANG 1441 modules developed elsewhere. Policy rules within an operator's 1442 environment can be used to express high-level, possibly network- 1443 wide, policies to a network management function (within a 1444 controller, an orchestrator, or a network element). The network 1445 management function can then control the configuration and/or 1446 monitoring of network elements and services. This document 1447 describes the SUPA basic framework, its elements, and interfaces. 1449 A.3. Device Models: Definitions and Samples 1451 Network Element models (Figure 9) are used to describe how a service 1452 can be implemented by activating and tweaking a set of functions 1453 (enabled in one or multiple devices, or hosted in cloud 1454 infrastructures) that are involved in the service delivery. The 1455 following figure uses IETF defined models as an example. 1457 +----------------+ 1458 --|Device Model | 1459 | +----------------+ 1460 | +------------------+ 1461 +---------------+ | |Logical Network | 1462 | | --| Element Mode | 1463 | Architecture | | +------------------+ 1464 | | | +----------------------+ 1465 +-------+-------+ --|Network Instance Mode | 1466 | | +----------------------+ 1467 | | +-------------------+ 1468 | --|Routing Type Model | 1469 | +-------------------+ 1470 +-------+----------+----+------+------------+-----------+-------+ 1471 | | | | | | | 1472 +-+-+ +---+---+ +--+------+ +-+-+ +-----+---+ +---+-+ | 1473 |ACL| |Routing| |Transport| |OAM| |Multicast| | PM | Others 1474 +---+ |-------+ +---------+ +---+ +---------+ +-----+ 1475 | +-------+ +----------+ +-------+ +-----+ +-----+ 1476 --|Core | |MPLS Basic| |BFD | |IGMP | |TWAMP| 1477 | |Routing| +----------+ +-------+ |/MLD | +-----+ 1478 | +-------+ |MPLS LDP | |LSP Ping +-----+ |OWAMP| 1479 --|BGP | +----------+ +-------+ |PIM | +-----+ 1480 | +-------+ |MPLS Static |MPLS-TP| +-----+ |LMAP | 1481 --|ISIS | +----------+ +-------+ |MVPN | +-----+ 1482 | +-------+ +-----+ 1483 --|OSPF | 1484 | +-------+ 1485 --|RIP | 1486 | +-------+ 1487 --|VRRP | 1488 | +-------+ 1489 --|SR/SRv6| 1490 | +-------+ 1491 --|ISIS-SR| 1492 | +-------+ 1493 --|OSPF-SR| 1494 +-------+ 1496 Figure 9: Network Element Modules Overview 1498 A.3.1. Model Composition 1500 o Device Model 1502 [I.D-ietf-rtgwg-device-model] presents an approach for organizing 1503 YANG modules in a comprehensive logical structure that may be used 1504 to configure and operate network devices. The structure is itself 1505 represented as an example YANG module, with all of the related 1506 component models logically organized in a way that is 1507 operationally intuitive, but this model is not expected to be 1508 implemented. 1510 o Logical Network Element Model 1512 [RFC8530] defines a logical network element module which can be 1513 used to manage the logical resource partitioning that may be 1514 present on a network device. Examples of common industry terms 1515 for logical resource partitioning are Logical Systems or Logical 1516 Routers. 1518 o Network Instance Model 1520 [RFC8529] defines a network instance module. This module can be 1521 used to manage the virtual resource partitioning that may be 1522 present on a network device. Examples of common industry terms 1523 for virtual resource partitioning are Virtual Routing and 1524 Forwarding (VRF) instances and Virtual Switch Instances (VSIs). 1526 A.3.1.1. Schema Mount 1528 Modularity and extensibility were among the leading design principles 1529 of the YANG data modeling language. As a result, the same YANG 1530 module can be combined with various sets of other modules and thus 1531 form a data model that is tailored to meet the requirements of a 1532 specific use case. [RFC8528] defines a mechanism, denoted schema 1533 mount, that allows for mounting one data model consisting of any 1534 number of YANG modules at a specified location of another (parent) 1535 schema. 1537 That capability does not cover design time. 1539 A.3.2. Device Models: Definitions and Samples 1541 BGP: [I-D.ietf-idr-bgp-yang-model] defines a YANG module for 1542 configuring and managing BGP, including protocol, policy, 1543 and operational aspects based on data center, carrier and 1544 content provider operational requirements. 1546 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 1547 which serves as a base framework for configuring and 1548 managing an MPLS switching subsystem. It is expected that 1549 other MPLS technology YANG modules (e.g. MPLS LSP Static, 1550 LDP or RSVP-TE models) will augment the MPLS base YANG 1551 module. 1553 QoS: [I-D.asechoud-netmod-diffserv-model] describes a YANG 1554 module of Differentiated Services for configuration and 1555 operations. 1557 ACL: Access Control List (ACL) is one of the basic elements 1558 used to configure device forwarding behavior. It is used 1559 in many networking technologies such as Policy Based 1560 Routing, Firewalls, etc. [RFC8519] describes a data model 1561 of Access Control List (ACL) basic building blocks. 1563 NAT: For the sake of network automation and the need for 1564 programming Network Address Translation (NAT) function in 1565 particular, a data model for configuring and managing the 1566 NAT is essential. [RFC8512] defines a YANG module for the 1567 NAT function covering a variety of NAT flavors such as 1568 Network Address Translation from IPv4 to IPv4 (NAT44), 1569 Network Address and Protocol Translation from IPv6 Clients 1570 to IPv4 Servers (NAT64), customer-side translator (CLAT), 1571 Stateless IP/ICMP Translation (SIIT), Explicit Address 1572 Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix 1573 Translation (NPTv6), and Destination NAT. [RFC8513] 1574 specifies a YANG module for the DS-Lite AFTR. 1576 Stateless Address Sharing: [I-D.ietf-softwire-yang] specifies a YANG 1577 module for A+P address sharing, including Lightweight 1578 4over6, Mapping of Address and Port with Encapsulation 1579 (MAP-E), and Mapping of Address and Port using Translation 1580 (MAP-T) softwire mechanisms. 1582 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 1583 to configure and manage Protocol Independent Multicast 1584 (PIM) devices. [I-D.ietf-pim-igmp-mld-yang] defines a 1585 YANG module that can be used to configure and manage 1586 Internet Group Management Protocol (IGMP) and Multicast 1587 Listener Discovery (MLD) devices. [I-D.ietf-pim-igmp-mld- 1588 snooping-yang] defines a YANG module that can be used to 1589 configure and manage Internet Group Management Protocol 1590 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1591 devices. 1593 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for 1594 Ethernet VPN services. The model is agnostic of the 1595 underlay. It apply to MPLS as well as to VxLAN 1596 encapsulation. The model is also agnostic of the services 1597 including E-LAN, E-LINE and E-TREE services. This 1598 document mainly focuses on EVPN and Ethernet-Segment 1599 instance framework. 1601 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can 1602 be used to configure and manage BGP L3VPNs [RFC4364]. It 1603 contains VRF specific parameters as well as BGP specific 1604 parameters applicable for L3VPNs. 1606 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS 1607 based Layer 2 VPN services (L2VPN) [RFC4664] and includes 1608 switching between the local attachment circuits. The 1609 L2VPN model covers point-to-point VPWS and Multipoint VPLS 1610 services. These services use signaling of Pseudowires 1611 across MPLS networks using LDP [RFC8077][RFC4762] or BGP 1612 [RFC4761]. 1614 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module 1615 for configuring and managing routing policies in a vendor- 1616 neutral way and based on actual operational practice. The 1617 model provides a generic policy framework which can be 1618 augmented with protocol-specific policy configuration. 1620 BFD: [I-D.ietf-bfd-yang]defines a YANG module that can be used 1621 to configure and manage Bidirectional Forwarding Detection 1622 (BFD) [RFC5880]. BFD is a network protocol which is used 1623 for liveness detection of arbitrary paths between systems. 1625 SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment 1626 routing configuration and operation. [I-D.raza-spring- 1627 srv6-yang] defines a YANG module for Segment Routing IPv6 1628 (SRv6) base. The model serves as a base framework for 1629 configuring and managing an SRv6 subsystem and expected to 1630 be augmented by other SRv6 technology models accordingly. 1632 Core Routing: [RFC8349] defines the core routing data model, which 1633 is intended as a basis for future data model development 1634 covering more-sophisticated routing systems. It is 1635 expected that other Routing technology YANG modules (e.g., 1636 VRRP, RIP, ISIS, OSPF models) will augment the Core 1637 Routing base YANG module. 1639 PM: 1641 [I.D-ietf-ippm-twamp-yang] defines a data model for client 1642 and server implementations of the Two-Way Active 1643 Measurement Protocol (TWAMP). 1645 [I.D-ietf-ippm-stamp-yang] defines the data model for 1646 implementations of Session-Sender and Session-Reflector 1647 for Simple Two-way Active Measurement Protocol (STAMP) 1648 mode using YANG. 1650 [RFC8194] defines a data model for Large-Scale Measurement 1651 Platforms (LMAPs). 1653 Authors' Addresses 1655 Qin Wu (editor) 1656 Huawei 1657 101 Software Avenue, Yuhua District 1658 Nanjing, Jiangsu 210012 1659 China 1661 Email: bill.wu@huawei.com 1663 Mohamed Boucadair (editor) 1664 Orange 1665 Rennes 35000 1666 France 1668 Email: mohamed.boucadair@orange.com 1670 Diego R. Lopez 1671 Telefonica I+D 1672 Spain 1674 Email: diego.r.lopez@telefonica.com 1676 Chongfeng Xie 1677 China Telecom 1678 Beijing 1679 China 1681 Email: xiechf.bri@chinatelecom.cn 1683 Liang Geng 1684 China Mobile 1686 Email: gengliang@chinamobile.com