idnits 2.17.1 draft-wu-model-driven-management-virtualization-04.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 : ---------------------------------------------------------------------------- ** There are 29 instances of too long lines in the document, the longest one being 24 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2019) is 1773 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-ccamp-wson-yang' is mentioned on line 371, but not defined == Missing Reference: 'I-D.ccamp-wson-tunnel-model' is mentioned on line 418, but not defined == Missing Reference: 'I-D.ietf-idr-bgp-yang-model' is mentioned on line 553, but not defined == Missing Reference: 'APL' is mentioned on line 1027, but not defined == Missing Reference: 'Y5' is mentioned on line 1097, but not defined == Missing Reference: 'Z5' is mentioned on line 1097, but not defined == Missing Reference: 'Z3' is mentioned on line 1097, but not defined == Missing Reference: 'Y4' is mentioned on line 1101, but not defined == Missing Reference: 'Y1' is mentioned on line 1101, but not defined == Missing Reference: 'Z2' is mentioned on line 1101, but not defined == Missing Reference: 'X5' is mentioned on line 1175, but not defined == Unused Reference: 'I-D.arkko-arch-virtualization' is defined on line 1255, but no explicit reference was found in the text == Unused Reference: 'I-D.clacla-netmod-model-catalog' is defined on line 1266, but no explicit reference was found in the text == Unused Reference: 'I-D.homma-slice-provision-models' is defined on line 1276, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-yang' is defined on line 1300, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-alarm-module' is defined on line 1306, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-media-channel-yang' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-yang' is defined on line 1316, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-mw-yang' is defined on line 1328, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-otn-tunnel-model' is defined on line 1340, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-wson-tunnel-model' is defined on line 1346, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-model' is defined on line 1364, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-stamp-yang' is defined on line 1369, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-twamp-yang' is defined on line 1374, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pim-igmp-mld-snooping-yang' is defined on line 1385, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-device-model' is defined on line 1404, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-sf-aware-topo-model' is defined on line 1434, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-l3-te-topo' is defined on line 1446, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-path-computation' is defined on line 1452, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-rsvp-te' is defined on line 1459, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 1471, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 1477, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-homma-slice-provision-models-00 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-09 == 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-03 == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-09 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-06 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-06 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-wson-tunnel-model-03 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-29 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-34 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-06 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-stamp-yang-03 == Outdated reference: A later version (-17) exists of draft-ietf-mpls-base-yang-10 == Outdated reference: A later version (-20) exists of draft-ietf-pim-igmp-mld-snooping-yang-08 == Outdated reference: A later version (-31) exists of draft-ietf-rtgwg-policy-model-06 == Outdated reference: A later version (-30) exists of draft-ietf-spring-sr-yang-12 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-05 == Outdated reference: A later version (-12) exists of draft-ietf-teas-sf-aware-topo-model-03 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-01 == Outdated reference: A later version (-16) exists of draft-ietf-teas-yang-l3-te-topo-04 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-05 == Outdated reference: A later version (-09) exists of draft-ietf-teas-yang-rsvp-te-06 == Outdated reference: A later version (-18) exists of draft-ietf-teas-yang-sr-te-topo-04 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-21 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-21 Summary: 1 error (**), 0 flaws (~~), 59 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Q. Wu 3 Internet-Draft Huawei 4 Intended status: Informational M. Boucadair 5 Expires: December 21, 2019 Orange 6 Y. Lee 7 Futurewei 8 June 19, 2019 10 A Framework for Automating Service and Network Management with YANG 11 draft-wu-model-driven-management-virtualization-04 13 Abstract 15 Model-driven service and network management provides a programmatic 16 and standard-based approach for representing (virtual) services or 17 networks and configuration to the network device that are used to 18 build and deliver the service. Models can be used at various phases 19 of service and network management life cycle such as service 20 instantiation, service provisionning, optimization, monitoring, and 21 diagnostic. Also, models can be designed to automate network 22 management and provide closed-loop control for the sake of adaptive 23 and deterministic service creation, delivery, and maintenance. 25 This document provides a framework that describes and discusses an 26 architecture for service and network management automation with YANG 27 modeling technologies. An applicability of YANG data models to 28 automation of virtualized network service is also investigated. 30 The document aims to exemplify an approach to illustrate the journey 31 from technology-agnostic services to technology-specific actions. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 21, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. IETF YANG Modules: An Overview . . . . . . . . . . . . . . . 4 69 2.1. Network Service and Resource Models . . . . . . . . . . . 5 70 2.1.1. Network Service Models: Definition and Samples . . . 6 71 2.1.2. Network Resource Models . . . . . . . . . . . . . . . 7 72 2.2. Network Element Models . . . . . . . . . . . . . . . . . 10 73 2.2.1. Model Composition . . . . . . . . . . . . . . . . . . 11 74 2.2.2. Protocol/Function Configuration Models . . . . . . . 12 75 3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 15 76 3.1. Data Models: Layering and Representation . . . . . . . . 15 77 3.2. Service Activation, Provision, and Invocation Automation 15 78 3.3. Service Enforcement Automation . . . . . . . . . . . . . 16 79 3.4. Modules Decomposition and Composition . . . . . . . . . . 16 80 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 17 81 4.1. End-to-End Service Delivery and Service Assurance 82 Procedure . . . . . . . . . . . . . . . . . . . . . . . . 17 83 4.1.1. Resource Collection and Abstraction (a) . . . . . . . 17 84 4.1.2. Service Exposure & Abstraction (b) . . . . . . . . . 18 85 4.1.3. IP Service Mapping (c) . . . . . . . . . . . . . . . 19 86 4.1.4. IP Service Composition (d) . . . . . . . . . . . . . 20 87 4.1.5. IP Service Provision (e) . . . . . . . . . . . . . . 20 88 4.1.6. Performance Measurement and Alarm Telemetry (f) . . . 20 89 4.1.7. IP Service to TE Mapping (g) . . . . . . . . . . . . 20 90 4.1.8. Path Management (h) . . . . . . . . . . . . . . . . . 21 91 4.1.9. TE Resource Exposure (i) . . . . . . . . . . . . . . 21 92 5. Sample Service Coordination via YANG Moodules . . . . . . . . 22 93 5.1. L3VPN Service Delivery via Coordinated YANG Modules . . . 22 94 5.2. 5G Transport Service Delivery via Coordinated YANG 95 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 6. Modules Usage in Automated Virtualized Network Environment: 97 Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 24 99 6.1. Network-initiated Resource Creation . . . . . . . . . . . 24 100 6.2. Customer-initiated Dynamic Resource Creation . . . . . . 26 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 103 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 104 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 105 11. Informative References . . . . . . . . . . . . . . . . . . . 29 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 108 1. Introduction 110 The service management system usually comprises service activation/ 111 provision and service enforcement. Traditional service delivery work 112 flow process, from customer order to the actual service provision, 113 typically involves input data sequentially into multiple OSS/BSS 114 applications managed by different departments. Many of these 115 applications are custom built over the years and operating in a silo 116 mode. The lack of standard data input/output also causes many 117 challenges in system integration and results in manual data entry. 118 Secondly, traditional service fulfillment lack a programmatic and 119 standards-based way of writing configurations to any network device 120 and has slow response to the network changes and doesn't provide real 121 time monitoring capability in high frequency and in high throughput 122 on the current state of networking. Therefore, model-driven network 123 management becomes crucial to address these challenges. 125 For years, the IETF has been driving the industry transition from an 126 overloaded Software Defined Networking (SDN) buzzword to focus on 127 specific areas such as modeling-driven network management. [RFC7149] 128 provides a first tentative to rationalize that space by identifying 129 concrete technical domains that need to be considered and for which 130 solutions can be provided: 132 o Techniques for the dynamic discovery of topology, devices, and 133 capabilities, along with relevant information and data models that 134 are meant to precisely document such topology, devices, and their 135 capabilities. 137 o Techniques for exposing network services [RFC8309] and their 138 characteristics. 140 o Techniques used by service-requirement-derived dynamic resource 141 allocation and policy enforcement schemes, so that networks can be 142 programmed accordingly. 144 o Dynamic feedback mechanisms that are meant to assess how 145 efficiently a given policy (or a set thereof) is enforced from a 146 service fulfillment and assurance perspective. 148 Models are key for each of these technical items. Automation is an 149 important step to improve the agility of network operations and 150 infrastructure. 152 In the later development, as described in [RFC8199], YANG module 153 developers have taken both top-down and bottom-up approaches to 154 develop modules and establish mapping between network technology and 155 customer requirements on the top or abstracting common construct from 156 various network technologies. At the time of writing this document 157 (2019), we see the large number of data models including 158 configuration models and service models developed or under 159 development in IETF covering much of networking protocols and 160 techniques. In addition, how these models work together to fully 161 configure a device, manage a set of devices involved in a service, or 162 even provide a service aren't developed yet in IETF. 164 This document takes both bottom up approach and top down approach to 165 provide an architectural framework for network management automation, 166 with a focus on network virtualization environment. 168 This document also describes specific YANG modules needed to realize 169 connectivity services and investigates how top down built model 170 (e.g., customer-facing data models) interact with bottom up built 171 model (network resource-facing data models) in the context of service 172 delivery and assurance. 174 The document identifies a comprehensive list of modules to exemplify 175 the proposed approach, but the document does not claim to be 176 exhaustive. 178 It is not the intent of this document to provide an inventory of 179 tools and mechanisms used in specific network and service management 180 domains; such inventory can be found in documents such as [RFC7276]. 182 2. IETF YANG Modules: An Overview 184 Figure 1 provides an overview of various macro-functional blocks to 185 which belong the various IETF-defined modules. 187 <> 188 +-----------------------------------------------------------------------+ 189 | << Network Service Models>> | 190 | +----------------+ +----------------+ +-------------+ +-------------+ | 191 | | L3SM | | L2SM | | TEAS VN | | L1CSM | | 192 | | Service Model | | Service Model | |Service Model| |Service Model| | 193 | +----------------+ +----------------+ +-------------+ +-------------+ | 194 |------------------------------------------------------------------- | 195 | << Network Resource Models >> | 196 | +------------+ +-------+ +----------------+ +------------+ | 197 | |Network Topo| | Tunnel| |Path Computation| |FM/PM/Alarm | | 198 | | Models | | Models| | API Models | | OAM Models| | 199 | +------------+ +-------+ +----------------+ +------------+ | 200 +-----------------------------------------------------------------------+ 201 -------------------------------------------------------------------- 202 > 203 +-----------------------------------------------------------------------+ 204 | <> | 205 | +-------------+ +---------------+ +----------------+ | 206 | |Device Model | |Logical Network| |Network Instance| | 207 | | | |Element Model | | Model | | 208 | +-------------+ +---------------+ +----------------+ | 209 |---------------------------------------------------------------------- | 210 | << Component Models>> | 211 |+---------++---------++---------++----------++---------++---------+ | 212 || || || ||Common || || OAM: | | 213 || Routing ||Transport|| Policy ||(interface||Multicast|| | | 214 ||(e.g.,BGP||(e.g., ||(e.g, ACL||multicast || (IGMP ||FM,PM, | | 215 || OSPF) || MPLS) || QoS) || IP, ... )|| MLD,...)||Alarm | ...| 216 |+---------++---------++---------++----------++---------++---------+ | 217 +-----------------------------------------------------------------------+ 219 Figure 1: An overview of IETF YANG Modules 221 2.1. Network Service and Resource Models 223 Service and Network Resource modules define what the 224 "service"/"resource" is. These modules can be classified into two 225 categories: 227 1. Network Service Models (Section 2.1.1) 229 2. Network Resource Models (Section 2.1.2) 231 2.1.1. Network Service Models: Definition and Samples 233 As described in [RFC8309], the service is some form of connectivity 234 between customer sites and the Internet and/or between customer sites 235 across the network operator's network and across the Internet. More 236 concretely, an IP connectivity service can be defined as the IP 237 transfer capability characterized by a (Source Nets, Destination 238 Nets, Guarantees, Scope) tuple where "Source Nets" is a group of 239 unicast IP addresses, "Destination Nets" is a group of IP unicast 240 and/or multicast addresses, and "Guarantees" reflects the guarantees 241 (expressed in terms of Quality Of Service (QoS), performance, and 242 availability, for example) to properly forward traffic to the said 243 "Destination" [RFC7297]. 245 For example, 247 o L3SM model [RFC8299] defines the L3VPN service ordered by a 248 customer from a network operator. 250 o L2SM model [RFC8466] defines the L2VPN service ordered by a 251 customer from a network operator. 253 o L1CSM model [I-D.ietf-ccamp-l1csm-yang] defines a YANG module for 254 Layer 1 Connectivity Service Model (L1CSM). 256 o TEAS VN model [I-D.ietf-teas-actn-vn-yang] defines a YANG module 257 for the Abstraction and Control of Traffic Engineered (TE) 258 networks (ACTN) Virtual Network Service (VNS) operation. Unlike 259 L3SM model, ACTN model can also be used as operator-facing model, 260 e.g., establish interconnections between L3VPN sites across 261 multiple ASes. 263 o [I-D.ietf-teas-te-service-mapping-yang] defines a YANG module to 264 map service model (e.g., L3SM) and Traffic Engineering model 265 (e.g., TE Tunnel or the ACTN model). This model is applicable to 266 the operation's need for a control and management of VPN services 267 with TE tunnel support and principally used to allow monitoring 268 and diagnostic of the management systems to assess how the service 269 requests are mapped onto underlying network resources and TE 270 models. 272 o Composed VPN model [I-D.evenwu-opsawg-yang-composed-vpn] defines a 273 YANG module that can be used by a network operator to configure a 274 VPN service in multiple administrative domain environment 275 consisting of L2VPN or L3VPN or a mixture of the two. This model 276 provides an abstracted view of VPN service configuration 277 components at different layer. 279 2.1.2. Network Resource Models 281 Figure 2 depicts a set of Network resource YANG modules such as 282 topology models or tunnel models: 284 | | 285 Topo YANG modules | Tunnel YANG modules |Resource NM Tool 286 ------------------------------------------------|-- ------------ 287 +------------+ | | 288 |Network Top | | +------+ +-----------+ | +-------+ 289 | Model | | |Other | | TE Tunnel | | | LIME | 290 +----+-------+ | |Tunnel| +------+----+ | | Model | 291 | +--------+ | +------+ | | |/PM/FM | 292 |---+Svc Topo| | +--------+-+--------+ |Model | 293 | +--------+ | +----+---+ +---+----+ +-+-----+ +-------+ 294 | +--------+ | |MPLS-TE | |RSVP-TE | |SR TE | +--------+ 295 |---+L2 Topo | | | Tunnel | | Tunnel | |Tunnel | | Alarm | 296 | +--------+ | +--------+ +--------+ +-------+ | Model | 297 | +--------+ | +--------+ 298 |---+TE Topo | | +-----------+ 299 | +--------+ | |Path | 300 | +--------+ | |Computation| 301 +---+L3 Topo | |API Model | 302 +----|---+ +-----------+ 303 +---------+---------+ 304 | | | 305 +---|---+ +--|---+ +---|-+ 306 |SR Topo| |SR TE | |L3 TE| 307 | Model | | Topo | |Topo | 308 +-------+ +------+ +-----+ 310 Figure 2: Sample Resource Facing Network Models 312 Topology YANG modules: 314 o Network Topology Models: [RFC8345] defines a base model for 315 network topology and inventories. Network topology data include 316 link resource, node resource, and terminate-point resources. 318 o TE Topology Models: [I.D-ietf-teas-yang-te-topo] defines a data 319 model for representing and manipulating TE topologies. 321 This module is extended from network topology model defined in 322 [RFC8345] with TE topologies specifics. This model contains 323 technology agnostic TE Topology building blocks that can be 324 augmented and used by other technology-specific TE Topology 325 models. 327 o L3 Topology Models 329 [RFC8346] defines a data model for representing and manipulating 330 L3 Topologies. This model is extended from the network topology 331 model defined in [RFC8345] with L3 topologies specifics. 333 o L2 Topology Models 335 [I.D-ietf-i2rs-yang-l2-topology] defines a data model for 336 representing and manipulating L2 Topologies. This model is 337 extended from the network topology model defined in [RFC8345] with 338 L2 topologies specifics. 340 o L3 TE Topology Models 342 When traffic engineering is enabled on a layer 3 network topology, 343 there will be a corresponding TE topology. [I.D-ietf-teas-yang- 344 l3-te-topo] defines data models for layer 3 traffic engineering 345 topologies. Two data models are defined, one is layer 3 TE 346 topology model, the other is packet switching TE topology model. 347 Layer 3 TE topology model is extended from Layer 3 topology model. 348 Packet switching TE topology model is extended from TE topology 349 model. 351 o SR TE Topology Models 353 [I-D.ietf-teas-yang-sr-te-topo] defines a YANG module for Segment 354 Routing (SR) topology and Segment Routing (SR) traffic engineering 355 (TE) topology. Two models are defined, one is SR topology model, 356 the other is SR TE topology model, SR topology model is extended 357 from L3 Topology model. SR TE topology model is extended from 358 both SR Topology model and L3 TE topology model. 360 o SF Aware TE Topology YANG module 362 [I-D. ietf-teas-sf-aware-topo-model] defines a YANG module for TE 363 network topologies that are network service and function aware. 365 o Optical Transport Topology Models: 367 * OTN Transport Topology Model: [I-D.ietf-ccamp-otn-topo-yang] 368 defines a YANG module to describe the topologies of an Optical 369 Transport Network (OTN). 371 * WSON Transport Topology Model: [I-D.ietf-ccamp-wson-yang] 372 defines a YANG module for the routing and wavelength assignment 373 (RWA) Traffic Engineering (TE) topology in wavelength switched 374 optical networks (WSONs). 376 * Flex-Grid Transport Topology Model: [I-D.ietf-ccamp-flexigrid- 377 yang] defines a YANG module for flexi-grid objects in the 378 dynamic optical network, including the nodes, transponders and 379 links between them, as well as how such links interconnect 380 nodes and transponders. 382 Tunnel YANG modules: 384 o Tunnel identities [I-D.ietf-softwire-iftunnel] to ease 385 manipulating extensions to specific tunnels. 387 o TE Tunnel Model 389 [I.D-ietf-teas-yang-te] defines a YANG module for the 390 configuration and management of TE interfaces, tunnels and LSPs. 392 o SR TE Tunnel Model 394 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 395 model(s) and defines a YANG module for Segment Routing (SR) TE 396 specific data. 398 o MPLS TE Model 400 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 401 model(s) and defines a YANG module for MPLS TE configurations, 402 state, RPC and notifications. 404 o RSVP-TE MPLS Model 406 [I.D-ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 407 with parameters to configure and manage signaling of MPLS RSVP-TE 408 LSPs. 410 o Optical Transport Tunnel Models: 412 * Flexigrid Media Channel Tunnel Models: [I-D.ccamp-flexigrid- 413 media-channel-yang] defines a YANG module for the flexi-grid 414 media-channel. This YANG module defines the whole path from a 415 source transponder or node to the destination through a number 416 of intermediate nodes in the flexi-grid network. 418 * WSON Tunnel Model: [I-D.ccamp-wson-tunnel-model] defines a YANG 419 module for WSON tunnel model. 421 * OTN Tunnel Model: [I-D. ietf-ccamp-otn-tunnel-model]defines a 422 YANG module for OTN tunnel Model. 424 Resource NM Tool Models: 426 o Path Computation API Model 428 [I.D-ietf-teas-path-computation] YANG module for a stateless RPC 429 which complements the stateful solution defined in [I.D-ietf-teas- 430 yang-te]. 432 o OAM Models (including Fault Management (FM) and Performance 433 Monitoring) 435 [RFC8532] defines a base YANG module for the management of OAM 436 protocols that use Connectionless Communications. [RFC8533] 437 defines a retrieval method YANG module for connectionless OAM 438 protocols. [RFC8531] defines a base YANG module for connection 439 oriented OAM protocols. These three models are intended to 440 provide consistent reporting, configuration and representation for 441 connection-less OAM and Connection oriented OAM separately. 443 Alarm monitoring is a fundamental part of monitoring the network. 444 Raw alarms from devices do not always tell the status of the 445 network services or necessarily point to the root cause. [I.D- 446 ietf-ccamp-alarm-module]defines a YANG module for alarm 447 management. 449 o Generic Policy Model 451 The Simplified Use of Policy Abstractions (SUPA) policy-based 452 management framework [RFC8328] defines base YANG modules to encode 453 policy. These models point to device-, technology-, and service- 454 specific YANG modules developed elsewhere. Policy rules within an 455 operator's environment can be used to express high-level, possibly 456 network-wide, policies to a network management function (within a 457 controller, an orchestrator, or a network element). The network 458 management function can then control the configuration and/or 459 monitoring of network elements and services. This document 460 describes the SUPA basic framework, its elements, and interfaces. 462 2.2. Network Element Models 464 Network Element models (Figure 3) are used to describe how a service 465 can be implemented by activating and tweaking a set of functions 466 (enabled in one or multiple devices) that are involved in the service 467 delivery. 469 +----------------+ 470 --|Device Model | 471 | +----------------+ 472 | +------------------+ 473 +---------------+ | |Logical Network | 474 | | --| Element Mode | 475 | Architecture | | +------------------+ 476 | | | +----------------------+ 477 +-------+-------+ --|Network Instance Mode | 478 | | +----------------------+ 479 | | +-------------------+ 480 | --|Routing Type Model | 481 | +-------------------+ 482 +-------+----------+----+------+------------+-----------+-------+ 483 | | | | | | | 484 +-+-+ +---+---+ +--+------+ +-+-+ +-----+---+ +---+-+ | 485 |ACL| |Routing| |Transport| |OAM| |Multicast| | PM | Others 486 +---+ |-------+ +---------+ +---+ +---------+ +-----+ 487 | +-------+ +----------+ +-------+ +-----+ +-----+ 488 --|Core | |MPLS Basic| |BFD | |IGMP | |TWAMP| 489 | |Routing| +----------+ +-------+ |/MLD | +-----+ 490 | +-------+ |MPLS LDP | |LSP Ping +-----+ |OWAMP| 491 --|BGP | +----------+ +-------+ |PIM | +-----+ 492 | +-------+ |MPLS Static |MPLS-TP| +-----+ |LMAP | 493 --|ISIS | +----------+ +-------+ |MVPN | +-----+ 494 | +-------+ +-----+ 495 --|OSPF | 496 | +-------+ 497 --|RIP | 498 | +-------+ 499 --|VRRP | 500 | +-------+ 501 --|SR/SRv6| 502 | +-------+ 503 --|ISIS-SR| 504 | +-------+ 505 --|OSPF-SR| 506 +-------+ 508 Figure 3: Network Element Modules 510 2.2.1. Model Composition 512 o Device Model 514 [I.D-ietf-rtgwg-device-model] presents an approach for organizing 515 YANG modules in a comprehensive logical structure that may be used 516 to configure and operate network devices. The structure is itself 517 represented as an example YANG module, with all of the related 518 component models logically organized in a way that is 519 operationally intuitive, but this model is not expected to be 520 implemented. 522 o Logical Network Element Model 524 [RFC8530] defines a logical network element module which can be 525 used to manage the logical resource partitioning that may be 526 present on a network device. Examples of common industry terms 527 for logical resource partitioning are Logical Systems or Logical 528 Routers. 530 o Network Instance Model 532 [RFC8529] defines a network instance module. This module can be 533 used to manage the virtual resource partitioning that may be 534 present on a network device. Examples of common industry terms 535 for virtual resource partitioning are Virtual Routing and 536 Forwarding (VRF) instances and Virtual Switch Instances (VSIs). 538 2.2.1.1. Schema Mount 540 Modularity and extensibility were among the leading design principles 541 of the YANG data modeling language. As a result, the same YANG 542 module can be combined with various sets of other modules and thus 543 form a data model that is tailored to meet the requirements of a 544 specific use case. [RFC8528] defines a mechanism, denoted schema 545 mount, that allows for mounting one data model consisting of any 546 number of YANG modules at a specified location of another (parent) 547 schema. 549 That capability does not cover design time. 551 2.2.2. Protocol/Function Configuration Models 553 BGP: [I-D.ietf-idr-bgp-yang-model] defines a YANG module for 554 configuring and managing BGP, including protocol, policy, 555 and operational aspects based on data center, carrier and 556 content provider operational requirements. 558 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 559 which serves as a base framework for configuring and 560 managing an MPLS switching subsystem. It is expected that 561 other MPLS technology YANG modules (e.g. MPLS LSP Static, 562 LDP or RSVP-TE models) will augment the MPLS base YANG 563 module. 565 QoS: [I-D.asechoud-netmod-diffserv-model] describes a YANG 566 module of Differentiated Services for configuration and 567 operations. 569 ACL: Access Control List (ACL) is one of the basic elements 570 used to configure device forwarding behavior. It is used 571 in many networking technologies such as Policy Based 572 Routing, Firewalls, etc. [RFC8519] describes a data model 573 of Access Control List (ACL) basic building blocks. 575 NAT: For the sake of network automation and the need for 576 programming Network Address Translation (NAT) function in 577 particular, a data model for configuring and managing the 578 NAT is essential. [RFC8512] defines a YANG module for the 579 NAT function covering a variety of NAT flavors such as 580 Network Address Translation from IPv4 to IPv4 (NAT44), 581 Network Address and Protocol Translation from IPv6 Clients 582 to IPv4 Servers (NAT64), customer-side translator (CLAT), 583 Stateless IP/ICMP Translation (SIIT), Explicit Address 584 Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix 585 Translation (NPTv6), and Destination NAT. [RFC8513] 586 specifies a YANG module for the DS-Lite AFTR. 588 Stateless Address Sharing: [I-D.ietf-softwire-yang] specifies a YANG 589 module for A+P address sharing, including Lightweight 590 4over6, Mapping of Address and Port with Encapsulation 591 (MAP-E), and Mapping of Address and Port using Translation 592 (MAP-T) softwire mechanisms. 594 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 595 to configure and manage Protocol Independent Multicast 596 (PIM) devices. [I-D.ietf-pim-igmp-mld-yang] defines a 597 YANG module that can be used to configure and manage 598 Internet Group Management Protocol (IGMP) and Multicast 599 Listener Discovery (MLD) devices. [I-D.ietf-pim-igmp-mld- 600 snooping-yang] defines a YANG module that can be used to 601 configure and manage Internet Group Management Protocol 602 (IGMP) and Multicast Listener Discovery (MLD) Snooping 603 devices. 605 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for 606 Ethernet VPN services. The model is agnostic of the 607 underlay. It apply to MPLS as well as to VxLAN 608 encapsulation. The model is also agnostic of the services 609 including E-LAN, E-LINE and E-TREE services. This 610 document mainly focuses on EVPN and Ethernet-Segment 611 instance framework. 613 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can 614 be used to configure and manage BGP L3VPNs [RFC4364]. It 615 contains VRF specific parameters as well as BGP specific 616 parameters applicable for L3VPNs. 618 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS 619 based Layer 2 VPN services (L2VPN) [RFC4664] and includes 620 switching between the local attachment circuits. The 621 L2VPN model covers point-to-point VPWS and Multipoint VPLS 622 services. These services use signaling of Pseudowires 623 across MPLS networks using LDP [RFC8077][RFC4762] or BGP 624 [RFC4761]. 626 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module 627 for configuring and managing routing policies in a vendor- 628 neutral way and based on actual operational practice. The 629 model provides a generic policy framework which can be 630 augmented with protocol-specific policy configuration. 632 BFD: [I-D.ietf-bfd-yang]defines a YANG module that can be used 633 to configure and manage Bidirectional Forwarding Detection 634 (BFD) [RFC5880]. BFD is a network protocol which is used 635 for liveness detection of arbitrary paths between systems. 637 SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment 638 routing configuration and operation. [I-D.raza-spring- 639 srv6-yang] defines a YANG module for Segment Routing IPv6 640 (SRv6) base. The model serves as a base framework for 641 configuring and managing an SRv6 subsystem and expected to 642 be augmented by other SRv6 technology models accordingly. 644 Core Routing: [RFC8349] defines the core routing data model, which 645 is intended as a basis for future data model development 646 covering more-sophisticated routing systems. It is 647 expected that other Routing technology YANG modules (e.g., 648 VRRP, RIP, ISIS, OSPF models) will augment the Core 649 Routing base YANG module. 651 PM: 653 [I.D-ietf-ippm-twamp-yang] defines a data model for client 654 and server implementations of the Two-Way Active 655 Measurement Protocol (TWAMP). 657 [I.D-ietf-ippm-stamp-yang] defines the data model for 658 implementations of Session-Sender and Session-Reflector 659 for Simple Two-way Active Measurement Protocol (STAMP) 660 mode using YANG. 662 [RFC8194] defines a data model for Large-Scale Measurement 663 Platforms (LMAPs). 665 3. Architectural Concepts 667 3.1. Data Models: Layering and Representation 669 As described in [RFC8199], layering of modules allows for better 670 reusability of lower-layer modules by higher-level modules while 671 limiting duplication of features across layers. 673 The IETF has developed a number of service level, network level and 674 device level modules. Different service level modules may rely on 675 the same set of network level or device level modules. Service level 676 modules usually follow top down approach and are mostly customer- 677 facing models providing a common model construct for higher level 678 network services, which can be further mapped to network technology- 679 specific models at lower layer. 681 Network level modules mostly follow bottom up approach and are mainly 682 network resource-facing model and describe various aspects of a 683 network infrastructure, including devices and their subsystems, and 684 relevant protocols operating at the link and network layers across 685 multiple devices (e.g., Network topology and TE Tunnel modules). 687 Device level modules usually follow bottom up approach and are mostly 688 technology-specific modules used to realize a service. 690 3.2. Service Activation, Provision, and Invocation Automation 692 To provide more adaptive (a.k.a., agile) service offerings, Service 693 level modules can be used by an operator to structure how it 694 communicates with the customer. One or more monolithic Service 695 modules can be used in teh context of a composite service activation 696 requets (e.g., deliver of a caching infrastructure over a VPN). Such 697 modules are used to feed a decision-making intelligence to rapidly 698 accommodate customer' needs. 700 Also, such modules may be used jointly with services that require 701 dynamic service invocation. A typical example is the service modules 702 defined by the DOTS WG to dynamically trigger requests to handle DDoS 703 attacks [I-D.ietf-dots-signal-channel][I-D.ietf-dots-data-channel]. 705 Network level module can be translated from service level module and 706 used to provision, monitor, instantiate the service and provide life 707 cycle management of network resource,e.g., expose network resource to 708 the customer or operators to provide service assurance on network 709 service and allow customer or operator to re-optimize the network 710 based on service requirements described in the service level model. 712 3.3. Service Enforcement Automation 714 To provide network management automation, Device level modules 715 translated from Service level modules or Network level modules can be 716 used to provision each involved network function/device and operate 717 the network based on service requirements described in the Service 718 level module(s). 720 In addition, the operational state including configuration that is in 721 effect and status together with statistics should be exposed to upper 722 layers to provide better network visibility (and assess to what 723 extent the translated low level modules are honoring the upper level 724 inputs). Note that it is important is to stitch telemetry data with 725 configuration data to provide closed loop life cycle management on 726 the network as a system (including device-centric views). 728 3.4. Modules Decomposition and Composition 730 To support top-down service delivery, the service parameters captured 731 in service level module(s) need to be decomposed into a set of 732 configuration parameters specific to one or more technologies; these 733 technology-specific parameters will be grouped together per 734 technology to define technology-specific device level model or 735 network level model. 737 In addition, these technology-specific device level models can be 738 further assembled together to provision each involved network 739 function/device or each involved administrative domain to improve 740 provision efficiency. 742 For example, IETF rtgwg and netmod working groups have already been 743 tasked to define model composition mechanism (i.e., Schema Mount 744 mechanism) and relevant grouping base models such as network instance 745 model, logical network element model. The model composition 746 mechanism can be used to assembler different model together while 747 grouping based models can be used to setup and administrate both 748 virtualized system and physical system. 750 IETF also developed YANG catalog tool to manage metadata around IETF- 751 defined modules; it allows both YANG developers and operators to 752 discover appropriate YANG modules that may be used to automate 753 services operations. This YANG catalog tools can be used to select 754 appropriate models for grouping purposes or even to identify gaps. 756 4. Architecture Overview 758 The architectural considerations and conclusions described in the 759 previous section lead to the architecture described in this section 760 and illustrated in Figure 4. 762 The interfaces and interactions shown in the figure and labeled (a) 763 through (j) are further described in Section 4.1. 765 +-----------------+ ---------------- 766 |Service Requester| Service Level| 767 +-----------------+ | 768 +-------------|--------------------------------------------------+ | 769 | +--------V---------+ +------------+ | | 770 | | Service Exposure |----------------- IP Service | | | 771 | +-------(b)--------+ | Mapping | | | 772 | | +--(c)-|-----+ | | 773 | | | ---------------- 774 | |---------->|<----------------+ | Network Level| 775 | | +--------V---------+ | | | | 776 | | | IP Service to TE | +------->|<-----------+ | | 777 | | | Mapping | | | | | | | 778 | | +-------(f)--------+ | | +------|-----+ | | | 779 | | | +-----|-----+| | IP Service | +---+--+| | 780 | | +--------V---------+ |TE Resource|| | Composition| |Alarm/|| | 781 | | | TE Path | | Exposure || +--(d)-|-----+ | PM || | 782 | | | Management +----(h)----+| | +-(g) -+| | 783 | | +-------(e)--------+ | | +------|------+ | | 784 | | | | | | IP Service | | | | 785 | | +-----------------+ | | Provision +-----| | | 786 | | | +-(e)--|------+ | | 787 | | +-----------++ | | 788 | | | Resource | | | 789 | | | Collection | | | 790 | |------------------------+&Abstraction| | | 791 | +----(a)-----+ ---------------- 792 +----------------------------------------------------------------+ 794 Figure 4: Service and Network Management Automation with YANG 796 4.1. End-to-End Service Delivery and Service Assurance Procedure 798 4.1.1. Resource Collection and Abstraction (a) 800 Network Resource such as links, nodes, or terminate-point resources 801 can be collected from the network and aggregated or abstracted to the 802 management system. Periodic fetching of data is not an adequate 803 solution for applications requiring frequent or prompt updates of 804 network resource. Applying polling-based solutions to retrieve 805 network resource also imposes a load on networks, devices, and 806 applications. These limitations can be addressed by including 807 generic object subscription mechanisms within network elements. 809 These resources can be modelled using network topology model, L3 810 topology model, L2 topology model, TE topology model, L3 TE topology 811 model, SR TE topology models at different layers. 813 In some cases, there may have multiple overlay topologies built on 814 top of the same underlay topology, and the underlay topology can be 815 also built from one or more lower layer underlay topology. 817 In some cases, there may have multiple overlay topologies built on 818 top of the same underlay topology, and the underlay topology can be 819 also built from one or more lower layer underlay topology. The 820 network resources and management objects in these multi-layer 821 topologies are not recommended to be exposed to customers who (will) 822 order the service from the management system, instead it will be 823 exposed to the management system for IP service mapping and TE path 824 Management. 826 The abstract view is likely to be technology-agnostic. 828 4.1.2. Service Exposure & Abstraction (b) 830 Service exposure & abstraction is used to capture services offered to 831 customers. 833 Service abstraction can be used by a customer to request a service 834 (ordering and order handling). One typical example is that a 835 customer can use L3SM service model to request L3VPN service by 836 providing the abstract technical characterization of the intended 837 service. Such L3VPN service describes various aspects of network 838 infrastructure, including devices and their subsystems, and relevant 839 protocols operating at the link and network layers across multiple 840 device. The L3SM service model can be used to interact with the 841 network infrastructure, e.g., configure sites, decide QoS parameters 842 to be applied to end to end connectivity between VPN sites, select 843 PEs, CEs, etc. 845 Service catalogs can be created to expose the various services and 846 the information needed to invoke/order a given service. 848 YANG modules can be grouped into various service bundles; each 849 service bundle is corresponding to a set of YANG modules that have 850 been released or published. Then, a mapping can be established 851 between service abstraction at higher layer and service bundle or a 852 set of YANG modules at lower layer. 854 4.1.3. IP Service Mapping (c) 856 Service abstraction starts with high-level abstractions exposing the 857 business capabilities or capturing customer requirements. Then, it 858 needs to maps them to resource abstraction and specific network 859 technologies. 861 Therefore, the interaction between service abstraction in the overlay 862 and network resource abstraction in the underlay is required. For 863 example, in the L3SM service model, we describe VPN service topology 864 including sites relationship, e.g., hub and spoke and any to any, 865 single homed, dual-homed, multi-homed relation between PEs and CEs, 866 but we don't know how this service topology can be mapped into 867 underlying network topology. For detailed interaction, please refer 868 to Section 4.1.8 870 In addition, there is a need to decide on a mapping between service 871 abstraction and underlying specific network technologies. Take L3SM 872 service model as an example, to realize L3VPN service, we need to map 873 L3SM service view defined in Service model into detailed 874 configuration view defined by specific configuration models for 875 network elements, these configuration models include: 877 o VRF definition, including VPN Policy expression 879 o Physical Interface 881 o IP layer (IPv4, IPv6). 883 o QoS features such as classification, profiles, etc. 885 o Routing protocols: support of configuration of all protocols 886 listed in the document, as well as routing policies associated 887 with those protocols. 889 o Multicast Support 891 o NAT or address sharing 893 o Security functions 895 4.1.4. IP Service Composition (d) 897 These detailed configuration models are further assembled together 898 into service bundle described inFigure 3 using, e.g., device model, 899 logical network element model or network instance model defined in 900 [I.D-ietf-rtgwg-device-model] [RFC8530] [RFC8529] and provide the 901 association between an interface and its associated LNE and NI and 902 populate them into appropriate devices(e.g., PE and CE). 904 4.1.5. IP Service Provision (e) 906 IP Service Provision is used to provision network infrastructure 907 using various configuration models, e.g., use network element models 908 such as BGP, ACL, QoS, Interface model, Network instance models to 909 configure PE and CE device within the site. BGP Policy model is used 910 to establish VPN membership between sites and VPN Service Topology. 911 Traditionally, "push" service element configuration model one by one 912 to the network device and provide association between an interface 913 and each service element configuration model is not efficient. 915 To automate configuration of the service elements, we first assemble 916 all related network elements models into logical network element 917 model defined in [RFC8530] and then establish association with an 918 interface and a set of network element configurations. 920 In addition, IP Service Provision can be used to setup tunnels 921 between sites and setup tunnels between PE and CE within the site 922 when tunnels related configuration parameters can be generated from 923 service abstraction. However when tunnels related configuration 924 parameters can not be generated from service abstraction, IP Service 925 to TE Mapping procedure is required. 927 4.1.6. Performance Measurement and Alarm Telemetry (f) 929 Once the tunnel is setup, PM and Warning information per tunnel or 930 per link based on network topology can be collected and report to the 931 management system. This information can be used to optimize the 932 network or provide troubleshooting support. 934 4.1.7. IP Service to TE Mapping (g) 936 Take L3VPN service model as an example, the management system will 937 use L3SM service model to determine where to connect each site- 938 network-access of a particular site to the provider network (e.g., 939 PE, aggregation switch). L3SM Service model proposes parameters and 940 constraints that can influence the meshing of the site-network- 941 access. 943 Nodes used to connect a site may be captured in relevant clauses of a 944 service exposure model (e.g., Customer Nodes Map [RFC7297]). 946 When Site location is determined, PE and CE device location will be 947 selected. Then we can replace parameters and constraints that can 948 influence the meshing of the site-network-access with specified PE 949 and CE device information associated with site-network-access and 950 generate resource facing VN Overlay Resource model. One example of 951 resource facing VN Overlay Resource model is TEAS VN Service Model 952 [I-D.ietf-teas-actn-vn-yang]. 954 This VN Overlay Resource model can be used to calculate node and link 955 resource to Meet service requirements based on Network Topology 956 models collected at step (a). 958 4.1.8. Path Management (h) 960 Path Management includes Path computation and Path setup. For 961 example, we can translate L3SM service model into resource facing VN 962 Model, with selected PE and CE in each site, we can calculate point 963 to point or multipoint end to end path between sites based on VN 964 Overlay Resource Model. 966 After identifying node and link resources required to meet service 967 requirements, the mapping between overlay topology and underlay 968 topology can be established, e.g., establish an association between 969 VPN service topology defined in customer facing model and underlying 970 network topology defined in the TE topology model (e.g., one overlay 971 node is supported by multiple underlay nodes, one overlay link is 972 supported by multiple underlay nodes) and generate end to end VN 973 topology. 975 4.1.9. TE Resource Exposure (i) 977 When tunnels related configuration parameters can not be generated 978 from service abstraction, IP Service to TE Mapping procedure can be 979 used to generate TE Resource Exposure view, this TE resource Exposure 980 view can be modeled as resource facing VN model which is translated 981 and instantiated from L3SM model and manage TE resource based on path 982 management information and PM and alarm telemetry information. 984 Operators may use this dedicated TE resource Exposure view to 985 dynamically capture the overall network status and topology to: 987 o Perform all the requested recovery operations upon detecting 988 network failures affecting the network service. 990 o Adjust resource distribution and update to end to end Service 991 topology models 993 o Provide resource scheduling to better guarantee services for 994 customers and to improve the efficiency of network resource usage. 996 5. Sample Service Coordination via YANG Moodules 998 5.1. L3VPN Service Delivery via Coordinated YANG Modules 1000 Take L3VPN service as an example, IETF has already developed L3VPN 1001 service model [RFC8299] which can be used to describe L3VPN service. 1002 To enforce L3VPN service and program the network, a set of network 1003 element models are needed, e.g., BGP model, Network Instance model, 1004 ACL model, Multicast Model, QoS model, or NAT model. 1006 These network element models can be grouped into different release 1007 bundles or feature bundle using Schema Mount technology to meet 1008 different tailored requirements and realize L3VPN service. 1010 To support the creation of logical network elements on a network 1011 device and enable automation of virtualized network, Logical Network 1012 Element (LNE) model can be used to manage its own set of modules such 1013 as ACL, QoS, or Network Instance modules. 1015 5.2. 5G Transport Service Delivery via Coordinated YANG Modules 1017 The overview of network slice structure as defined in the 3GPP 5GS is 1018 shown in Figure 5. The terms are described in specific 3GPP 1019 documents (e.g., [TS.23.501-3GPP] and [TS.28.530-3GPP]). 1021 <================== E2E-NSI =======================> 1022 : : : : : 1023 : : : : : 1024 <====== RAN-NSSI ======><=TRN-NSSI=><====== CN-NSSI ======>VL[APL] 1025 : : : : : : : : : 1026 : : : : : : : : : 1027 RW[NFs ]<=TRN-NSSI=>[NFs ]<=TRN-NSSI=>[NFs ]<=TRN-NSSI=>[NFs ]VL[APL] 1029 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 1030 .,----. ,----. ,----.. ,----. .,----. ,----. ,----.. 1031 UE--|RAN |---| TN |---|RAN |---| TN |---|CN |---| TN |---|CN |--[APL] 1032 .|NFs | `----' |NFs |. `----' .|NFs | `----' |NFs |. 1033 .`----' `----'. .`----' `----'. 1034 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 1036 RW RAN MBH CN DN 1038 *Legends 1039 UE: User Equipment 1040 RAN: Radio Access Network 1041 CN: Core Network 1042 DN: Data Network 1043 TN: Transport Network 1044 MBH: Mobile Backhaul 1045 RW: Radio Wave 1046 NF: Network Function 1047 APL: Application Server 1048 NSI: Network Slice Instance 1049 NSSI: Network Slice Subnet Instance 1051 Figure 5: Overview of Structure of NS in 3GPP 5GS 1053 To support 5G service (e.g., 5G MBB service), L3VPN service model 1054 [RFC8299] and TEAS VN model [I-D. ietf-teas-actn-vn-yang] can be both 1055 provided to describe 5G MBB Transport Service or connectivity 1056 service. L3VPN service model is used to describe end-to-end 1057 connectivity service while TEAS VN model is used to describe TE 1058 connectivity service between VPN sites or between RAN NFs and Core 1059 network NFs. 1061 VN in TEAS VN model and support point-to-point or multipoint-to- 1062 multipoint connectivity service and can be seen as one example of 1063 network slice. 1065 TE Service mapping model can be used to map L3VPN service requests 1066 onto underlying network resource and TE models to get TE network 1067 setup. 1069 For IP VPN service provision, L3VPN service model is translated into 1070 a set of network element configuration parameters, these 1071 configuration parameters will be bound to different network element 1072 models and group them together to form feature bundle or service 1073 bundle to get L3VPN network setup. 1075 6. Modules Usage in Automated Virtualized Network Environment: Sample 1076 Examples 1078 6.1. Network-initiated Resource Creation 1079 |(2) 1080 | 1081 V 1082 +-------------------+ 1083 | Management System | (3)(4)(5) 1084 +-------------------+ 1086 +--------------------------------------------------------+ 1087 / _[CE2] _[CE3] / 1088 / _/ : \_ _/ : \_ / 1089 / _/ : \_ _/ : \_ / 1090 / _/ : \_ _/ : \_ / 1091 / / : \ / : \ / 1092 /[CE1]_________________[PE1] [PE2]_________________[CE4] / 1093 +---------:--------------:------------:--------------:---+ 1094 "Service" 1095 -------------------------------------------------------------------- 1096 +---------------------+ +---------------------+"Resource" 1097 / [Y5]... / / [Z5]______[Z3] / 1098 / / \ : / / : \_ / : / 1099 / / \ : / / : \_ / : / 1100 / / \ : / / : \ / : / 1101 / [Y4]____[Y1] : / / : [Z2] : / 1102 +------:-------:---:--+ +---:---------:-----:-+ ^ 1103 vNet1 : : : : : : vNet2 | 1104 : : : : : : |(1) 1105 : +-------:---:-----:------------:-----:-----+ | 1106 : / [X1]__:___:___________[X2] : / | 1107 :/ / \_ : : _____/ / : / | 1108 : / \_ : _____/ / : / 1109 /: / \: / / : / 1110 / : / [X5] / : / 1111 / : / __/ \__ / : / 1112 / : / ___/ \__ / : / 1113 / : / ___/ \ / : / 1114 / [X4]__________________[X3]..: / 1115 +------------------------------------------+ 1116 L3 Topology 1118 The following steps are performed to deliver the service within the 1119 network management automation architecture proposed in this document: 1121 o Pre-provision multiple virtualized networks on top of the same 1122 basic network infrastructure based on pre-configured service 1123 requirements and establish resource pool for each virtualized 1124 network and expose to the customer with several service templates 1125 through web portal. 1127 o Selects and uses one which fulfills most its requirement among the 1128 service templates. 1130 o Create resource facing VN Network based on selected service 1131 template, and calculate the node resource, link resource 1132 corresponding to connectivity between sites. 1134 o Setup tunnels between sites and map them into the selected 1135 virtualized network topology and establish resource facing VN 1136 topology based on TEAS VN model [I-D.ietf-teas-actn-vn-yang] and 1137 TE tunnel based on TE Tunnel model. 1139 The resource facing VN model and corresponding TE Tunnel model can 1140 be further used to notify all the parameter changes and event 1141 related to VN topology or Tunnel. These information can be 1142 further used to adjust network resource distributed in the 1143 network. 1145 The network initiated resource creation is similar to ready made 1146 Network Slice creation pattern discussed in Section 5.1 of [I- 1147 D.homma-slice-provision-models]. 1149 6.2. Customer-initiated Dynamic Resource Creation 1150 |(2) 1151 | 1152 V 1153 +-------------------+ 1154 | Management System | (3)(4)(5) 1155 +-------------------+ 1157 +--------------------------------------------------------+ 1158 / _[CE2] _[CE3] / 1159 / _/ : \_ _/ : \_ / 1160 / _/ : \_ _/ : \_ / 1161 / _/ : \_ _/ : \_ / 1162 / / : \ / : \ / 1163 /[CE1]_________________[PE1] [PE2]_________________[CE4] / 1164 +---------:--------------:------------:--------------:---+ 1165 "Service" 1166 -------------------------------------------------------------------- 1167 "Resource" ^ 1168 : | 1169 : : : |(1) 1170 : +-------:---:-----:------------:-----:-----+ | 1171 : / [X1]__:___ __________[X2] / | 1172 :/ / \_ : _____/ / / | 1173 : / \_ : _____/ / / 1174 /: / \: / / / 1175 / : / [X5] / / 1176 / : / __/ \__ / / 1177 / : / ___/ \__ / / 1178 / : / ___/ \ / / 1179 / [X4]__________________[X3]. / 1180 +------------------------------------------+ 1181 L3 Topology 1183 The following steps are performed to deliver the service within the 1184 network management automation architecture proposed in this document: 1186 o Establish resources pool for the basic common network 1187 infrastructure. 1189 o Request to create two sites based on L3SM Service model with each 1190 having one network access connectivity: 1192 Site A: Network-Access A, Bandwidth=20M, for class "foo", 1193 guaranteed-bw-percent = 10, One-Way-Delay=70 msec 1195 Site B: Network-Access B, Bandwidth=30M, for class "foo1", 1196 guaranteed-bw-percent = 15, One-Way-Delay=60 msec 1198 o Create a new service topology based on Service Type and service 1199 requirements (e.g., Slice Service Type, Slice location, Number of 1200 Slices, QoS requirements corresponding to network connectivity 1201 within a Slice) defined in L3SM service model. 1203 o Translate L3SM service model into resource facing TEAS VN Model 1204 [I-D.ietf-teas-actn-vn-yang], and calculate the node resource, 1205 link resource corresponding to connectivity between sites or 1206 connectivity between PE and CE within Site in the service topology 1207 based on generated resource facing TEAS VN model. 1209 o Setup tunnels between sites and tunnel between PE and CE within 1210 Site and map them into basic network infrastructure and establish 1211 resource facing VN topology based on TEAS VN model and TE tunnel 1212 based on TE Tunnel model. The resource facing TEAS VN model and 1213 corresponding TE Tunnel model can be used to notify all the 1214 parameter changes and event related to VN topology or Tunnel. 1215 These information can be further used to adjust network resource 1216 distributed within the network. 1218 The customer initiated resource creation is similar to customer made 1219 Network Slice creation pattern discussed in Section 5.2 of [I- 1220 D.homma-slice-provision-models]. 1222 7. Security Considerations 1224 Security considerations specific to each of the technologies and 1225 protocols listed in the document are discussed in the specification 1226 documents of each of these techniques. 1228 (Potential) security considerations specific to this document are 1229 listed below: 1231 o Create forwarding loops by mis-configuring the underlying network. 1233 o Leak sensitive information: special care should be considered when 1234 translating between the various layers introduced in the document. 1236 o ...tbc 1238 8. IANA Considerations 1240 There are no IANA requests or assignments included in this document. 1242 9. Contributors 1244 Shunsuke Homma 1245 Japan 1247 Email: s.homma0718+ietf@gmail.com 1249 10. Acknowledgements 1251 Thanks to Joe Clarck and Greg Mirsky for the review. 1253 11. Informative References 1255 [I-D.arkko-arch-virtualization] 1256 Arkko, J., Tantsura, J., Halpern, J., and B. Varga, 1257 "Considerations on Network Virtualization and Slicing", 1258 draft-arkko-arch-virtualization-01 (work in progress), 1259 March 2018. 1261 [I-D.asechoud-netmod-diffserv-model] 1262 Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N. 1263 Strahle, "YANG Model for Diffserv", draft-asechoud-netmod- 1264 diffserv-model-03 (work in progress), June 2015. 1266 [I-D.clacla-netmod-model-catalog] 1267 Clarke, J. and B. Claise, "YANG module for 1268 yangcatalog.org", draft-clacla-netmod-model-catalog-03 1269 (work in progress), April 2018. 1271 [I-D.evenwu-opsawg-yang-composed-vpn] 1272 Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model 1273 for Composed VPN Service Delivery", draft-evenwu-opsawg- 1274 yang-composed-vpn-03 (work in progress), March 2019. 1276 [I-D.homma-slice-provision-models] 1277 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 1278 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 1279 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 1280 Foy, "Network Slice Provision Models", draft-homma-slice- 1281 provision-models-00 (work in progress), February 2019. 1283 [I-D.ietf-bess-evpn-yang] 1284 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 1285 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 1286 bess-evpn-yang-07 (work in progress), March 2019. 1288 [I-D.ietf-bess-l2vpn-yang] 1289 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1290 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1291 L2VPN", draft-ietf-bess-l2vpn-yang-09 (work in progress), 1292 October 2018. 1294 [I-D.ietf-bess-l3vpn-yang] 1295 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 1296 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 1297 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 1298 in progress), October 2018. 1300 [I-D.ietf-bfd-yang] 1301 Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and 1302 G. Mirsky, "YANG Data Model for Bidirectional Forwarding 1303 Detection (BFD)", draft-ietf-bfd-yang-17 (work in 1304 progress), August 2018. 1306 [I-D.ietf-ccamp-alarm-module] 1307 Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft- 1308 ietf-ccamp-alarm-module-09 (work in progress), April 2019. 1310 [I-D.ietf-ccamp-flexigrid-media-channel-yang] 1311 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1312 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1313 Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid- 1314 media-channel-yang-02 (work in progress), March 2019. 1316 [I-D.ietf-ccamp-flexigrid-yang] 1317 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1318 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1319 Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid- 1320 yang-03 (work in progress), March 2019. 1322 [I-D.ietf-ccamp-l1csm-yang] 1323 Fioccola, G., Lee, K., Lee, Y., Dhody, D., and D. 1324 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 1325 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-09 (work in 1326 progress), March 2019. 1328 [I-D.ietf-ccamp-mw-yang] 1329 Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M. 1330 Vaupotic, "A YANG Data Model for Microwave Radio Link", 1331 draft-ietf-ccamp-mw-yang-13 (work in progress), November 1332 2018. 1334 [I-D.ietf-ccamp-otn-topo-yang] 1335 Zheng, H., Guo, A., Busi, I., Sharma, A., Liu, X., 1336 Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data 1337 Model for Optical Transport Network Topology", draft-ietf- 1338 ccamp-otn-topo-yang-06 (work in progress), February 2019. 1340 [I-D.ietf-ccamp-otn-tunnel-model] 1341 Zheng, H., Guo, A., Busi, I., Sharma, A., Rao, R., 1342 Belotti, S., Lopezalvarez, V., Li, Y., and Y. Xu, "OTN 1343 Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-model-06 1344 (work in progress), February 2019. 1346 [I-D.ietf-ccamp-wson-tunnel-model] 1347 Lee, Y., Dhody, D., Guo, A., Lopezalvarez, V., King, D., 1348 Yoon, B., and R. Vilata, "A Yang Data Model for WSON 1349 Tunnel", draft-ietf-ccamp-wson-tunnel-model-03 (work in 1350 progress), March 2019. 1352 [I-D.ietf-dots-data-channel] 1353 Boucadair, M. and R. K, "Distributed Denial-of-Service 1354 Open Threat Signaling (DOTS) Data Channel Specification", 1355 draft-ietf-dots-data-channel-29 (work in progress), May 1356 2019. 1358 [I-D.ietf-dots-signal-channel] 1359 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 1360 Teague, "Distributed Denial-of-Service Open Threat 1361 Signaling (DOTS) Signal Channel Specification", draft- 1362 ietf-dots-signal-channel-34 (work in progress), May 2019. 1364 [I-D.ietf-idr-bgp-model] 1365 Jethanandani, M., Patel, K., and S. Hares, "BGP YANG Model 1366 for Service Provider Networks", draft-ietf-idr-bgp- 1367 model-06 (work in progress), June 2019. 1369 [I-D.ietf-ippm-stamp-yang] 1370 Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active 1371 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 1372 stamp-yang-03 (work in progress), March 2019. 1374 [I-D.ietf-ippm-twamp-yang] 1375 Civil, R., Morton, A., Rahman, R., Jethanandani, M., and 1376 K. Pentikousis, "Two-Way Active Measurement Protocol 1377 (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work 1378 in progress), July 2018. 1380 [I-D.ietf-mpls-base-yang] 1381 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 1382 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 1383 yang-10 (work in progress), February 2019. 1385 [I-D.ietf-pim-igmp-mld-snooping-yang] 1386 Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, 1387 "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- 1388 pim-igmp-mld-snooping-yang-08 (work in progress), June 1389 2019. 1391 [I-D.ietf-pim-igmp-mld-yang] 1392 Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 1393 Peter, "A YANG Data Model for Internet Group Management 1394 Protocol (IGMP) and Multicast Listener Discovery (MLD)", 1395 draft-ietf-pim-igmp-mld-yang-15 (work in progress), June 1396 2019. 1398 [I-D.ietf-pim-yang] 1399 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1400 Y., and f. hu, "A YANG Data Model for Protocol Independent 1401 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1402 progress), May 2018. 1404 [I-D.ietf-rtgwg-device-model] 1405 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 1406 "Network Device YANG Logical Organization", draft-ietf- 1407 rtgwg-device-model-02 (work in progress), March 2017. 1409 [I-D.ietf-rtgwg-policy-model] 1410 Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data 1411 Model for Routing Policy Management", draft-ietf-rtgwg- 1412 policy-model-06 (work in progress), March 2019. 1414 [I-D.ietf-softwire-iftunnel] 1415 Boucadair, M., Farrer, I., and R. Asati, "Tunnel Interface 1416 Types YANG Module", draft-ietf-softwire-iftunnel-07 (work 1417 in progress), June 2019. 1419 [I-D.ietf-softwire-yang] 1420 Farrer, I. and M. Boucadair, "YANG Modules for IPv4-in- 1421 IPv6 Address plus Port (A+P) Softwires", draft-ietf- 1422 softwire-yang-16 (work in progress), January 2019. 1424 [I-D.ietf-spring-sr-yang] 1425 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 1426 Tantsura, "YANG Data Model for Segment Routing", draft- 1427 ietf-spring-sr-yang-12 (work in progress), February 2019. 1429 [I-D.ietf-teas-actn-vn-yang] 1430 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1431 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1432 teas-actn-vn-yang-05 (work in progress), June 2019. 1434 [I-D.ietf-teas-sf-aware-topo-model] 1435 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, 1436 L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology 1437 YANG Model", draft-ietf-teas-sf-aware-topo-model-03 (work 1438 in progress), March 2019. 1440 [I-D.ietf-teas-te-service-mapping-yang] 1441 Lee, Y., Dhody, D., Ceccarelli, D., Tantsura, J., 1442 Fioccola, G., and Q. Wu, "Traffic Engineering and Service 1443 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 1444 yang-01 (work in progress), March 2019. 1446 [I-D.ietf-teas-yang-l3-te-topo] 1447 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1448 O. Dios, "YANG Data Model for Layer 3 TE Topologies", 1449 draft-ietf-teas-yang-l3-te-topo-04 (work in progress), 1450 March 2019. 1452 [I-D.ietf-teas-yang-path-computation] 1453 Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma, 1454 A., Shi, Y., Vilata, R., Sethuraman, K., Scharf, M., and 1455 D. Ceccarelli, "Yang model for requesting Path 1456 Computation", draft-ietf-teas-yang-path-computation-05 1457 (work in progress), March 2019. 1459 [I-D.ietf-teas-yang-rsvp-te] 1460 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 1461 and H. Shah, "A YANG Data Model for RSVP-TE Protocol", 1462 draft-ietf-teas-yang-rsvp-te-06 (work in progress), April 1463 2019. 1465 [I-D.ietf-teas-yang-sr-te-topo] 1466 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1467 S. Litkowski, "YANG Data Model for SR and SR TE 1468 Topologies", draft-ietf-teas-yang-sr-te-topo-04 (work in 1469 progress), March 2019. 1471 [I-D.ietf-teas-yang-te] 1472 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1473 "A YANG Data Model for Traffic Engineering Tunnels and 1474 Interfaces", draft-ietf-teas-yang-te-21 (work in 1475 progress), April 2019. 1477 [I-D.ietf-teas-yang-te-topo] 1478 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1479 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1480 Topologies", draft-ietf-teas-yang-te-topo-21 (work in 1481 progress), May 2019. 1483 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1484 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1485 2006, . 1487 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1488 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1489 DOI 10.17487/RFC4664, September 2006, 1490 . 1492 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1493 LAN Service (VPLS) Using BGP for Auto-Discovery and 1494 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1495 . 1497 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1498 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1499 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1500 . 1502 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1503 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1504 . 1506 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1507 Networking: A Perspective from within a Service Provider 1508 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1509 . 1511 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1512 Weingarten, "An Overview of Operations, Administration, 1513 and Maintenance (OAM) Tools", RFC 7276, 1514 DOI 10.17487/RFC7276, June 2014, 1515 . 1517 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1518 Connectivity Provisioning Profile (CPP)", RFC 7297, 1519 DOI 10.17487/RFC7297, July 2014, 1520 . 1522 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 1523 Maintenance Using the Label Distribution Protocol (LDP)", 1524 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 1525 . 1527 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1528 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1529 August 2017, . 1531 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1532 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1533 2017, . 1535 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1536 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1537 DOI 10.17487/RFC8299, January 2018, 1538 . 1540 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1541 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1542 . 1544 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 1545 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 1546 Management Framework for the Simplified Use of Policy 1547 Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328, 1548 March 2018, . 1550 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1551 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1552 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1553 2018, . 1555 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1556 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1557 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1558 March 2018, . 1560 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1561 Routing Management (NMDA Version)", RFC 8349, 1562 DOI 10.17487/RFC8349, March 2018, 1563 . 1565 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1566 Data Model for Layer 2 Virtual Private Network (L2VPN) 1567 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1568 2018, . 1570 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1571 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1572 Address Translation (NAT) and Network Prefix Translation 1573 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1574 . 1576 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1577 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1578 DOI 10.17487/RFC8513, January 2019, 1579 . 1581 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1582 "YANG Data Model for Network Access Control Lists (ACLs)", 1583 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1584 . 1586 [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", 1587 RFC 8528, DOI 10.17487/RFC8528, March 2019, 1588 . 1590 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1591 Liu, "YANG Data Model for Network Instances", RFC 8529, 1592 DOI 10.17487/RFC8529, March 2019, 1593 . 1595 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1596 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1597 DOI 10.17487/RFC8530, March 2019, 1598 . 1600 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1601 for Connection-Oriented Operations, Administration, and 1602 Maintenance (OAM) Protocols", RFC 8531, 1603 DOI 10.17487/RFC8531, April 2019, 1604 . 1606 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1607 Raghavan, "Generic YANG Data Model for the Management of 1608 Operations, Administration, and Maintenance (OAM) 1609 Protocols That Use Connectionless Communications", 1610 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1611 . 1613 [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. 1614 Raghavan, "A YANG Data Model for Retrieval Methods for the 1615 Management of Operations, Administration, and Maintenance 1616 (OAM) Protocols That Use Connectionless Communications", 1617 RFC 8533, DOI 10.17487/RFC8533, April 2019, 1618 . 1620 Authors' Addresses 1622 Qin Wu 1623 Huawei 1624 101 Software Avenue, Yuhua District 1625 Nanjing, Jiangsu 210012 1626 China 1628 Email: bill.wu@huawei.com 1630 Mohamed Boucadair 1631 Orange 1632 Rennes 35000 1633 France 1635 Email: mohamed.boucadair@orange.com 1637 Young Lee 1638 Futurewei 1640 Email: younglee.tx@gmail.com