idnits 2.17.1 draft-wu-model-driven-management-virtualization-05.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 31 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 3, 2019) is 1730 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 209, but not defined == Missing Reference: 'RFC8174' is mentioned on line 209, but not defined == Missing Reference: 'I-D.ietf-idr-bgp-yang-model' is mentioned on line 522, but not defined == Missing Reference: 'APL' is mentioned on line 1002, but not defined == Missing Reference: 'Y5' is mentioned on line 1072, but not defined == Missing Reference: 'Z5' is mentioned on line 1072, but not defined == Missing Reference: 'Z3' is mentioned on line 1072, but not defined == Missing Reference: 'Y4' is mentioned on line 1076, but not defined == Missing Reference: 'Y1' is mentioned on line 1076, but not defined == Missing Reference: 'Z2' is mentioned on line 1076, but not defined == Missing Reference: 'X5' is mentioned on line 1150, but not defined == Unused Reference: 'I-D.arkko-arch-virtualization' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'I-D.clacla-netmod-model-catalog' is defined on line 1241, but no explicit reference was found in the text == Unused Reference: 'I-D.homma-slice-provision-models' is defined on line 1246, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bfd-yang' is defined on line 1270, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-alarm-module' is defined on line 1276, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-media-channel-yang' is defined on line 1280, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-yang' is defined on line 1286, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-l1csm-yang' is defined on line 1292, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-mw-yang' is defined on line 1298, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-otn-topo-yang' is defined on line 1304, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-otn-tunnel-model' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-wson-tunnel-model' is defined on line 1316, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-bgp-model' is defined on line 1334, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-stamp-yang' is defined on line 1339, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-twamp-yang' is defined on line 1344, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pim-igmp-mld-snooping-yang' is defined on line 1355, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-device-model' is defined on line 1374, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-data-model' is defined on line 1399, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-sf-aware-topo-model' is defined on line 1410, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-te-service-mapping-yang' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-l3-te-topo' is defined on line 1422, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-path-computation' is defined on line 1428, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-rsvp-te' is defined on line 1435, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-sr-te-topo' is defined on line 1441, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 1447, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 1453, but no explicit reference was found in the text -- No information found for draft-arkko-arch-virtualization - is the name correct? -- No information found for draft-asechoud-netmod-diffserv-model - is the name correct? -- No information found for draft-homma-slice-provision-models - is the name correct? == Outdated reference: A later version (-05) exists of draft-ietf-bess-l3vpn-yang-04 -- No information found for draft-ietf-bfd-yang - is the name correct? -- No information found for draft-ietf-ccamp-flexigrid-media-channel-yang - is the name correct? -- No information found for draft-ietf-ccamp-flexigrid-yang - is the name correct? -- No information found for draft-ietf-ccamp-l1csm-yang - is the name correct? -- No information found for draft-ietf-ccamp-mw-yang - is the name correct? == Outdated reference: A later version (-17) exists of draft-ietf-ccamp-otn-topo-yang-06 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-06 -- No information found for draft-ietf-ccamp-wson-tunnel-model - is the name correct? == 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 -- No information found for draft-ietf-ippm-twamp-yang - is the name correct? == Outdated reference: A later version (-17) exists of draft-ietf-mpls-base-yang-10 -- No information found for draft-ietf-pim-igmp-mld-snooping-yang - is the name correct? -- No information found for draft-ietf-pim-igmp-mld-yang - is the name correct? -- No information found for draft-ietf-pim-yang - is the name correct? -- No information found for draft-ietf-rtgwg-device-model - is the name correct? == Outdated reference: A later version (-31) exists of draft-ietf-rtgwg-policy-model-06 -- No information found for draft-ietf-softwire-iftunnel - is the name correct? -- No information found for draft-ietf-softwire-yang - is the name correct? -- No information found for draft-ietf-spring-sr-yang - is the name correct? -- No information found for draft-ietf-supa-generic-policy-data-model - is the name correct? == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-05 -- No information found for draft-ietf-teas-sf-aware-topo-model - is the name correct? == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-01 -- No information found for draft-ietf-teas-yang-l3-te-topo - is the name correct? == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-05 -- No information found for draft-ietf-teas-yang-rsvp-te - is the name correct? -- No information found for draft-ietf-teas-yang-sr-te-topo - is the name correct? == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-21 Summary: 1 error (**), 0 flaws (~~), 53 warnings (==), 23 comments (--). 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: January 4, 2020 C. Jacquenet 6 Orange 7 L. Miguel Contreras Murillo 8 Telifonica 9 D. Lopez 10 Telefonica I+D 11 C. Xie 12 China Telecom 13 W. Cheng 14 China Mobile 15 Y. Lee 16 Futurewei 17 July 3, 2019 19 A Framework for Automating Service and Network Management with YANG 20 draft-wu-model-driven-management-virtualization-05 22 Abstract 24 Data models for service and network management provides a 25 programmatic approach for representing (virtual) services or networks 26 and deriving configuration information that will be forwarded to 27 network and service components that are used to build and deliver the 28 service. Data Models can be used during various phases of the 29 service and network management life cycle, such as service 30 instantiation, service provisioning, optimization, monitoring, and 31 diagnostic. Also, data models are are instrumental in the automation 32 of network management. They also provide closed-loop control for the 33 sake of adaptive and deterministic service creation, delivery, and 34 maintenance. 36 This document provides a framework that describes and discusses an 37 architecture for service and network management automation that takes 38 advantage of YANG modeling technologies. This framework is drawn 39 from a network provider perspective irrespective of the origin of a 40 data module andcan accommodate even modules that are developed 41 outside the IETF. 43 The document aims to exemplify an approach that specifies the journey 44 from technology-agnostic services to technology-specific actions. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on January 4, 2020. 63 Copyright Notice 65 Copyright (c) 2019 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 82 2. Layered YANG Modules: An Overview . . . . . . . . . . . . . . 6 83 2.1. Network Service and Resource Models . . . . . . . . . . . 6 84 2.1.1. Network Service Models: Definition and Samples . . . 7 85 2.1.2. Network Resource Models: Definitions and Samples . . 7 86 2.2. Network Element Models: Definitions and Samples . . . . . 10 87 2.2.1. Model Composition . . . . . . . . . . . . . . . . . . 11 88 2.2.2. Protocol/Function Configuration Models: Definitions 89 and Samples . . . . . . . . . . . . . . . . . . . . . 12 90 3. Architectural Concepts . . . . . . . . . . . . . . . . . . . 15 91 3.1. Data Models: Layering and Representation . . . . . . . . 15 92 3.2. Automation of service delivery procedures . . . . . . . . 15 93 3.3. Service Fullfillment Automation . . . . . . . . . . . . . 16 94 3.4. Module Decomposition and Composition . . . . . . . . . . 16 95 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 17 96 4.1. End-to-End Service Delivery and Service Assurance 97 Procedure . . . . . . . . . . . . . . . . . . . . . . . . 18 98 4.1.1. Resource Collection and Abstraction (a) . . . . . . . 18 99 4.1.2. Service Exposure & Abstraction (b) . . . . . . . . . 18 100 4.1.3. IP Service Mapping (c) . . . . . . . . . . . . . . . 19 101 4.1.4. IP Service Composition (d) . . . . . . . . . . . . . 19 102 4.1.5. IP Service Provision (e) . . . . . . . . . . . . . . 20 103 4.1.6. Performance Measurement and Alarm Telemetry (g) . . . 20 104 4.1.7. IP Service to TE Mapping (f) . . . . . . . . . . . . 20 105 4.1.8. Path Management (h) . . . . . . . . . . . . . . . . . 21 106 4.1.9. TE Resource Exposure (i) . . . . . . . . . . . . . . 21 107 5. Sample Service Coordination via YANG Moodules . . . . . . . . 22 108 5.1. L3VPN Service Delivery via Coordinated YANG Modules . . . 22 109 5.2. 5G Transport Service Delivery via Coordinated YANG 110 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 22 111 6. Modules Usage in Automated Virtualized Network Environment: 112 Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 24 113 6.1. Network-initiated Resource Creation . . . . . . . . . . . 24 114 6.2. Customer-initiated Dynamic Resource Creation . . . . . . 25 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 116 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 117 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 119 11. Informative References . . . . . . . . . . . . . . . . . . . 28 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 122 1. Introduction 124 The service management system usually comprises service activation/ 125 provision and service operation. Current service delivery 126 procedures, from the processing of customer's requirements and order 127 to service delivery and operation, typically assume the manipulation 128 of data sequentially into multiple OSS/BSS applications that may be 129 managed by different departments within the service provider's 130 organization (e.g., billing factory, design factory, network 131 operation center, etc.). In addition, many of these applications 132 have been developed in-house over the years and operating in a silo 133 mode. The lack of standard data input/output (i.e., data model) also 134 raises many challenges in system integration and often results in 135 manual configuration tasks. Secondly, many current service 136 fulfillment might not support real time streaming telemetry 137 capability in high frequency and in high throughput on the current 138 state of networking and therefore have slow response to the network 139 changes. Software Defined Networking (SDN) becomes crucial to 140 address these challenges. 142 Software-Defined Networking techniques [RFC7149] are meant to 143 automate the overall service delivery procedures and typically rely 144 upon (standard) data models that are used to not only reflect service 145 providers'savoir-faire but also to dynamically instantiate and 146 enforce a set of (service-inferred) policies that best accommodate 147 what has been (contractually) defined (and possibly negotiated) with 148 the customer. [RFC7149] provides a first tentative to rationalize 149 that service provider's view on the SDN space by identifying concrete 150 technical domains that need to be considered and for which solutions 151 can be provided: 153 o Techniques for the dynamic discovery of topology, devices, and 154 capabilities, along with relevant information and data models that 155 are meant to precisely document such topology, devices, and their 156 capabilities. 158 o Techniques for exposing network services [RFC8309] and their 159 characteristics. 161 o Techniques used by service-requirement-derived dynamic resource 162 allocation and policy enforcement schemes, so that networks can be 163 programmed accordingly. 165 o Dynamic feedback mechanisms that are meant to assess how 166 efficiently a given policy (or a set thereof) is enforced from a 167 service fulfillment and assurance perspective. 169 Models are key for each of these technical items. Service and 170 network management automation is an important step to improve the 171 agility of network operations and infrastructures. 173 YANG module developers have taken both top-down and bottom-up 174 approaches to develop modules [RFC8199] and to establish a mapping 175 between network technology and customer requirements on the top or 176 abstracting common construct from various network technologies on the 177 bottom. At the time of writing this document (2019), there are many 178 data models including configuration and service models that have been 179 specified or are being specified by the IETF. They cover many of the 180 networking protocols and techniques. However, how these models work 181 together to configure a device, manage a set of devices involved in a 182 service, or even provide a service is something that is not currently 183 documented either within the IETF or other SDOs (e.g., MEF). 185 This document provides a framework that describes and discusses an 186 architecture for service and network management automation that takes 187 advantage of YANG modeling technologies and investigates how 188 different layer YANG data models interact with each other (e.g., 189 service mapping, model composing) in the context of service delivery 190 and fulfillment. This framework is drawn from a network provider 191 perspective irrespective of the origin of a data module andcan 192 accommodate even modules that are developed outside the IETF. 194 The document also identifies a list of modules and use cases to 195 exemplify the proposed approach, but it does not claim to be 196 exhaustive. 198 It is not the intent of this document to provide an inventory of 199 tools and mechanisms used in specific network and service management 200 domains; such inventory can be found in documents such as [RFC7276]. 202 1.1. Terminology 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 206 "OPTIONAL" in this document are to be interpreted as described in BCP 207 14 [RFC2119] [RFC8174] when, and only when, they appear in all 208 capitals, as shown here. 210 The following terms are defined in [RFC8309][RFC8199] and are not 211 redefined here: 213 o Network Operator 215 o Customer 217 o Service 219 o Data Model 221 o Service Model 223 o Customer Service Model 225 o Service Delivery Model 227 o Network Service Module 229 o Network Element Module 231 The following terms are defined in this document as follows: 233 Network Resource Module: The Network Resource Module is used by a 234 network operator to allocate the resource(e.g., tunnel resource, 235 topology resource) for the service or schedule the resource to 236 meet the service requirements define in the Service Model. 238 2. Layered YANG Modules: An Overview 240 Figure 1 provides an overview of various macro-functional blocks at 241 different levels that articulate the various YANG data modules. In 242 this figure, we use IETF defined YANG data model as an example 243 Models. 245 <> 246 +-------------------------------------------------------------------------+ 247 | << Network Service Models>> | 248 | +----------------+ +----------------+ | 249 | | L3SM | | L2SM | | 250 | | Service Model | | Service Model | ............. | 251 | +----------------+ +----------------+ | 252 +------------------------------------------------------------------------ + 253 <> 254 +------------------------------------------------------------------------ + 255 | << Network Resource Models >> | 256 | +------------+ +-------+ +----------------+ +------------+ | 257 | |Network Topo| | Tunnel| |Path Computation| |FM/PM/Alarm | | 258 | | Models | | Models| | API Models | | OAM Models|... | 259 | +------------+ +-------+ +----------------+ +------------+ | 260 +-------------------------------------------------------------------------+ 261 -------------------------------------------------------------------------- 262 > 263 +-------------------------------------------------------------------------+ 264 | <> | 265 | +-------------+ +---------------+ +----------------+ | 266 | |Device Model | |Logical Network| |Network Instance| | 267 | | | |Element Model | | Model | ... | 268 | +-------------+ +---------------+ +----------------+ | 269 |-------------------------------------------------------------------------| 270 | << Function Models>> | 271 |+---------++---------++---------++----------++---------++---------+ | 272 || || || ||Common || || OAM: | | 273 || Routing ||Transport|| Policy ||(interface||Multicast|| | | 274 ||(e.g.,BGP||(e.g., ||(e.g, ACL||multicast || (IGMP ||FM,PM, | | 275 || OSPF) || MPLS) || QoS) || IP, ... )|| MLD,...)||Alarm | ... | 276 |+---------++---------++---------++----------++---------++---------+ | 277 +-------------------------------------------------------------------------+ 279 Figure 1: An overview of Layered YANG Modules 281 2.1. Network Service and Resource Models 282 2.1.1. Network Service Models: Definition and Samples 284 As described in [RFC8309], the service is "some form of connectivity 285 between customer sites and the Internet and/or between customer sites 286 across the network operator's network and across the Internet". More 287 concretely, an IP connectivity service can be defined as the IP 288 transfer capability characterized by a (Source Nets, Destination 289 Nets, Guarantees, Scope) tuple where "Source Nets" is a group of 290 unicast IP addresses, "Destination Nets" is a group of IP unicast 291 and/or multicast addresses, and "Guarantees" reflects the guarantees 292 (expressed in terms of Quality Of Service (QoS), performance, and 293 availability, for example) to properly forward traffic to the said 294 "Destination" [RFC7297]. 296 For example: 298 o L3SM model [RFC8299] defines the L3VPN service ordered by a 299 customer from a network operator. 301 o L2SM model [RFC8466] defines the L2VPN service ordered by a 302 customer from a network operator. 304 o VN model [I-D.ietf-teas-actn-vn-yang]provides a YANG data model 305 generally applicable to any mode of Virtual Network (VN) 306 operation. 308 2.1.2. Network Resource Models: Definitions and Samples 310 Figure 2 depicts a set of Network resource YANG modules such as 311 topology models or tunnel models: 313 | | 314 Topo YANG modules | Tunnel YANG modules |Resource NM Tool 315 ------------------------------------------------|-- ------------ 316 +------------+ | | 317 |Network Top | | +------+ +-----------+ | +-------+ 318 | Model | | |Other | | TE Tunnel | | | LIME | 319 +----+-------+ | |Tunnel| +------+----+ | | Model | 320 | +--------+ | +------+ | | |/PM/FM | 321 |---+Svc Topo| | +--------+-+--------+ |Model | 322 | +--------+ | +----+---+ +---+----+ +-+-----+ +-------+ 323 | +--------+ | |MPLS-TE | |RSVP-TE | |SR TE | +--------+ 324 |---+L2 Topo | | | Tunnel | | Tunnel | |Tunnel | | Alarm | 325 | +--------+ | +--------+ +--------+ +-------+ | Model | 326 | +--------+ | +--------+ 327 |---+TE Topo | | +-----------+ 328 | +--------+ | |Path | 329 | +--------+ | |Computation| 330 +---+L3 Topo | | |API Model | 331 +--------+ | +-----------+ 333 Figure 2: Sample Resource Facing Network Models 335 Topology YANG module Examples: 337 o Network Topology Models: [RFC8345] defines a base model for 338 network topology and inventories. Network topology data include 339 link resource, node resource, and terminate-point resources. 341 o TE Topology Models: [I.D-ietf-teas-yang-te-topo] defines a data 342 model for representing and manipulating TE topologies. 344 This module is extended from network topology model defined in 345 [RFC8345] with TE topologies specifics. This model contains 346 technology-agnostic TE Topology building blocks that can be 347 augmented and used by other technology-specific TE Topology 348 models. 350 o L3 Topology Models 352 [RFC8346] defines a data model for representing and manipulating 353 L3 Topologies. This model is extended from the network topology 354 model defined in [RFC8345] with L3 topologies specifics. 356 o L2 Topology Models 358 [I.D-ietf-i2rs-yang-l2-topology] defines a data model for 359 representing and manipulating L2 Topologies. This model is 360 extended from the network topology model defined in [RFC8345] with 361 L2 topologies specifics. 363 Tunnel YANG module Examples: 365 o Tunnel identities [I-D.ietf-softwire-iftunnel] to ease 366 manipulating extensions to specific tunnels. 368 o TE Tunnel Model 370 [I.D-ietf-teas-yang-te] defines a YANG module for the 371 configuration and management of TE interfaces, tunnels and LSPs. 373 o SR TE Tunnel Model 375 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 376 model(s) and defines a YANG module for Segment Routing (SR) TE 377 specific data. 379 o MPLS TE Model 381 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 382 model(s) and defines a YANG module for MPLS TE configurations, 383 state, RPC and notifications. 385 o RSVP-TE MPLS Model 387 [I.D-ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 388 with parameters to configure and manage signaling of MPLS RSVP-TE 389 LSPs. 391 Resource NM Tool Models: 393 o Path Computation API Model 395 [I.D-ietf-teas-path-computation] YANG module for a stateless RPC 396 which complements the stateful solution defined in [I.D-ietf-teas- 397 yang-te]. 399 o OAM Models (including Fault Management (FM) and Performance 400 Monitoring) 402 [RFC8532] defines a base YANG module for the management of OAM 403 protocols that use Connectionless Communications. [RFC8533] 404 defines a retrieval method YANG module for connectionless OAM 405 protocols. [RFC8531] defines a base YANG module for connection 406 oriented OAM protocols. These three models are intended to 407 provide consistent reporting, configuration and representation for 408 connection-less OAM and Connection oriented OAM separately. 410 Alarm monitoring is a fundamental part of monitoring the network. 411 Raw alarms from devices do not always tell the status of the 412 network services or necessarily point to the root cause. [I.D- 413 ietf-ccamp-alarm-module]defines a YANG module for alarm 414 management. 416 o Generic Policy Model 418 The Simplified Use of Policy Abstractions (SUPA) policy-based 419 management framework [RFC8328] defines base YANG modules 420 [I-D.ietf-supa-generic-policy-data-model]to encode policy. These 421 models point to device-, technology-, and service-specific YANG 422 modules developed elsewhere. Policy rules within an operator's 423 environment can be used to express high-level, possibly network- 424 wide, policies to a network management function (within a 425 controller, an orchestrator, or a network element). The network 426 management function can then control the configuration and/or 427 monitoring of network elements and services. This document 428 describes the SUPA basic framework, its elements, and interfaces. 430 2.2. Network Element Models: Definitions and Samples 432 Network Element models (Figure 3) are used to describe how a service 433 can be implemented by activating and tweaking a set of functions 434 (enabled in one or multiple devices, or hosted in cloud 435 infrastructures) that are involved in the service delivery. The 436 following figure uses IETF defined models as an example. 438 +----------------+ 439 --|Device Model | 440 | +----------------+ 441 | +------------------+ 442 +---------------+ | |Logical Network | 443 | | --| Element Mode | 444 | Architecture | | +------------------+ 445 | | | +----------------------+ 446 +-------+-------+ --|Network Instance Mode | 447 | | +----------------------+ 448 | | +-------------------+ 449 | --|Routing Type Model | 450 | +-------------------+ 451 +-------+----------+----+------+------------+-----------+-------+ 452 | | | | | | | 453 +-+-+ +---+---+ +--+------+ +-+-+ +-----+---+ +---+-+ | 454 |ACL| |Routing| |Transport| |OAM| |Multicast| | PM | Others 455 +---+ |-------+ +---------+ +---+ +---------+ +-----+ 456 | +-------+ +----------+ +-------+ +-----+ +-----+ 457 --|Core | |MPLS Basic| |BFD | |IGMP | |TWAMP| 458 | |Routing| +----------+ +-------+ |/MLD | +-----+ 459 | +-------+ |MPLS LDP | |LSP Ping +-----+ |OWAMP| 460 --|BGP | +----------+ +-------+ |PIM | +-----+ 461 | +-------+ |MPLS Static |MPLS-TP| +-----+ |LMAP | 462 --|ISIS | +----------+ +-------+ |MVPN | +-----+ 463 | +-------+ +-----+ 464 --|OSPF | 465 | +-------+ 466 --|RIP | 467 | +-------+ 468 --|VRRP | 469 | +-------+ 470 --|SR/SRv6| 471 | +-------+ 472 --|ISIS-SR| 473 | +-------+ 474 --|OSPF-SR| 475 +-------+ 477 Figure 3: Network Element Modules Overview 479 2.2.1. Model Composition 481 o Device Model 483 [I.D-ietf-rtgwg-device-model] presents an approach for organizing 484 YANG modules in a comprehensive logical structure that may be used 485 to configure and operate network devices. The structure is itself 486 represented as an example YANG module, with all of the related 487 component models logically organized in a way that is 488 operationally intuitive, but this model is not expected to be 489 implemented. 491 o Logical Network Element Model 493 [RFC8530] defines a logical network element module which can be 494 used to manage the logical resource partitioning that may be 495 present on a network device. Examples of common industry terms 496 for logical resource partitioning are Logical Systems or Logical 497 Routers. 499 o Network Instance Model 501 [RFC8529] defines a network instance module. This module can be 502 used to manage the virtual resource partitioning that may be 503 present on a network device. Examples of common industry terms 504 for virtual resource partitioning are Virtual Routing and 505 Forwarding (VRF) instances and Virtual Switch Instances (VSIs). 507 2.2.1.1. Schema Mount 509 Modularity and extensibility were among the leading design principles 510 of the YANG data modeling language. As a result, the same YANG 511 module can be combined with various sets of other modules and thus 512 form a data model that is tailored to meet the requirements of a 513 specific use case. [RFC8528] defines a mechanism, denoted schema 514 mount, that allows for mounting one data model consisting of any 515 number of YANG modules at a specified location of another (parent) 516 schema. 518 That capability does not cover design time. 520 2.2.2. Protocol/Function Configuration Models: Definitions and Samples 522 BGP: [I-D.ietf-idr-bgp-yang-model] defines a YANG module for 523 configuring and managing BGP, including protocol, policy, 524 and operational aspects based on data center, carrier and 525 content provider operational requirements. 527 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 528 which serves as a base framework for configuring and 529 managing an MPLS switching subsystem. It is expected that 530 other MPLS technology YANG modules (e.g. MPLS LSP Static, 531 LDP or RSVP-TE models) will augment the MPLS base YANG 532 module. 534 QoS: [I-D.asechoud-netmod-diffserv-model] describes a YANG 535 module of Differentiated Services for configuration and 536 operations. 538 ACL: Access Control List (ACL) is one of the basic elements 539 used to configure device forwarding behavior. It is used 540 in many networking technologies such as Policy Based 541 Routing, Firewalls, etc. [RFC8519] describes a data model 542 of Access Control List (ACL) basic building blocks. 544 NAT: For the sake of network automation and the need for 545 programming Network Address Translation (NAT) function in 546 particular, a data model for configuring and managing the 547 NAT is essential. [RFC8512] defines a YANG module for the 548 NAT function covering a variety of NAT flavors such as 549 Network Address Translation from IPv4 to IPv4 (NAT44), 550 Network Address and Protocol Translation from IPv6 Clients 551 to IPv4 Servers (NAT64), customer-side translator (CLAT), 552 Stateless IP/ICMP Translation (SIIT), Explicit Address 553 Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix 554 Translation (NPTv6), and Destination NAT. [RFC8513] 555 specifies a YANG module for the DS-Lite AFTR. 557 Stateless Address Sharing: [I-D.ietf-softwire-yang] specifies a YANG 558 module for A+P address sharing, including Lightweight 559 4over6, Mapping of Address and Port with Encapsulation 560 (MAP-E), and Mapping of Address and Port using Translation 561 (MAP-T) softwire mechanisms. 563 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 564 to configure and manage Protocol Independent Multicast 565 (PIM) devices. [I-D.ietf-pim-igmp-mld-yang] defines a 566 YANG module that can be used to configure and manage 567 Internet Group Management Protocol (IGMP) and Multicast 568 Listener Discovery (MLD) devices. [I-D.ietf-pim-igmp-mld- 569 snooping-yang] defines a YANG module that can be used to 570 configure and manage Internet Group Management Protocol 571 (IGMP) and Multicast Listener Discovery (MLD) Snooping 572 devices. 574 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for 575 Ethernet VPN services. The model is agnostic of the 576 underlay. It apply to MPLS as well as to VxLAN 577 encapsulation. The model is also agnostic of the services 578 including E-LAN, E-LINE and E-TREE services. This 579 document mainly focuses on EVPN and Ethernet-Segment 580 instance framework. 582 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can 583 be used to configure and manage BGP L3VPNs [RFC4364]. It 584 contains VRF specific parameters as well as BGP specific 585 parameters applicable for L3VPNs. 587 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS 588 based Layer 2 VPN services (L2VPN) [RFC4664] and includes 589 switching between the local attachment circuits. The 590 L2VPN model covers point-to-point VPWS and Multipoint VPLS 591 services. These services use signaling of Pseudowires 592 across MPLS networks using LDP [RFC8077][RFC4762] or BGP 593 [RFC4761]. 595 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module 596 for configuring and managing routing policies in a vendor- 597 neutral way and based on actual operational practice. The 598 model provides a generic policy framework which can be 599 augmented with protocol-specific policy configuration. 601 BFD: [I-D.ietf-bfd-yang]defines a YANG module that can be used 602 to configure and manage Bidirectional Forwarding Detection 603 (BFD) [RFC5880]. BFD is a network protocol which is used 604 for liveness detection of arbitrary paths between systems. 606 SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment 607 routing configuration and operation. [I-D.raza-spring- 608 srv6-yang] defines a YANG module for Segment Routing IPv6 609 (SRv6) base. The model serves as a base framework for 610 configuring and managing an SRv6 subsystem and expected to 611 be augmented by other SRv6 technology models accordingly. 613 Core Routing: [RFC8349] defines the core routing data model, which 614 is intended as a basis for future data model development 615 covering more-sophisticated routing systems. It is 616 expected that other Routing technology YANG modules (e.g., 617 VRRP, RIP, ISIS, OSPF models) will augment the Core 618 Routing base YANG module. 620 PM: 622 [I.D-ietf-ippm-twamp-yang] defines a data model for client 623 and server implementations of the Two-Way Active 624 Measurement Protocol (TWAMP). 626 [I.D-ietf-ippm-stamp-yang] defines the data model for 627 implementations of Session-Sender and Session-Reflector 628 for Simple Two-way Active Measurement Protocol (STAMP) 629 mode using YANG. 631 [RFC8194] defines a data model for Large-Scale Measurement 632 Platforms (LMAPs). 634 3. Architectural Concepts 636 3.1. Data Models: Layering and Representation 638 As described in [RFC8199], layering of modules allows for better 639 reusability of lower-layer modules by higher-level modules while 640 limiting duplication of features across layers. 642 The data modules developed by IETF can be classified into service 643 level, network level and device level modules. Different service 644 level modules may rely on the same set of network level or device 645 level modules. Service level modules usually follow top down 646 approach and are mostly customer-facing modules providing a common 647 model construct for higher level network services, which can be 648 further mapped to network technology-specific modules at lower layer. 650 Network level modules mostly follow a bottom-up approach and are 651 mainly network resource-facing modules and describe various aspects 652 of a network infrastructure, including devices and their subsystems, 653 and relevant protocols operating at the link and network layers 654 across multiple devices (e.g., Network topology and TE Tunnel 655 modules). 657 Device level modules usually follow a bottom-up approach and are 658 mostly technology-specific modules used to realize a service. 660 3.2. Automation of service delivery procedures 662 To dynamically provide service offerings, Service level modules can 663 be used by an operator. One or more monolithic Service modules can 664 be used in the context of a composite service activation request 665 (e.g., delivery of a caching infrastructure over a VPN). Such 666 modules are used to feed a decision-making intelligence to adequately 667 accommodate customer's needs. 669 Also, such modules may be used jointly with services that require 670 dynamic invocation. An example is provided by the service modules 671 defined by the DOTS WG to dynamically trigger requests to handle DDoS 672 attacks [I-D.ietf-dots-signal-channel][I-D.ietf-dots-data-channel]. 674 Network level modules can be derived from service level modules and 675 used to provision, monitor, instantiate the service and provide 676 lifecycle management of network resources, e.g., expose network 677 resources to customers or operators to provide service fulfillment 678 and assurance and allow customers or operators to dynamically adjust 679 the network resources based on service requirements as described in 680 service level modules and the current network performance information 681 described in the Northbound telemetry modules. 683 3.3. Service Fullfillment Automation 685 To operate the service, Device level modules derived from Service 686 level modules or Network level modules can be used to provision each 687 involved network function/device with the proper configuration 688 information, and operate the network based on service requirements as 689 described in the Service level module(s). 691 In addition, the operational state including configuration that is in 692 effect together with statistics should be exposed to upper layers to 693 provide better network visibility (and assess to what extent the 694 derived low level modules are consistent with the upper level 695 inputs). Note that it is important to relate telemetry data with 696 configuration data to used closed loops at the different stages of 697 service delivery, from resource allocation to service operation, in 698 particular. 700 3.4. Module Decomposition and Composition 702 To support top-down service delivery, the service parameters captured 703 in service level module(s) need to be decomposed into a set of 704 configuration parameters that may be specific to one or more 705 technologies; these technology-specific parameters will be grouped 706 together per technique to define technology-specific device level 707 modules or network level modules. 709 In addition, these technology-specific device level models can be 710 further assembled together to provision each involved network 711 function/device or each involved administrative domain to improve 712 provision efficiency. 714 For example, IETF rtgwg and netmod working groups have already been 715 tasked to define a model composition mechanism (i.e., Schema Mount 716 mechanism) and relevant grouping base models such as network instance 717 model, logical network element model . The model composition 718 mechanism can be used to assembler different model together while 719 grouping based models can be used to setup and administrate both 720 virtualized system and physical systems . 722 IETF also developed a YANG catalog tool to manage metadata around 723 IETF- defined modules; it allows both YANG developers and operators 724 to discover appropriate YANG modules that may be used to automate 725 services operations. This YANG tool catalog tools can be used to 726 select appropriate models for grouping purposes or even to identify 727 gaps. 729 4. Architecture Overview 731 The architectural considerations described in the previous section 732 lead to the architecture described in this section and illustrated in 733 Figure 4. 735 The interfaces and interactions shown in the figure and labeled (a) 736 through (j) are further described in Section 4.1. 738 +-----------------+ ---------------- 739 |Service Requester| Service Level| 740 +-----------------+ | 741 +-------------|--------------------------------------------------+ | 742 | | +----------------------+ | | 743 | | | | | | 744 | +--------V---------+ | +------------+ +---+--+| | 745 | | Service Exposure |-------------V--- IP Service | |Alarm/|| | 746 | +-------(b)--------+ | Mapping | | PM || | 747 | | +--(c)-|-----+ +-(g) -+| | 748 | | | | | 749 | +---------->|<----------------+ +------------+ | 750 | | | | | -------------+-- 751 | | | | | Network Level| 752 | | +--------V---------+ | | | | 753 | | | IP Service to TE | +------->|<-----------+ | | 754 | | | Mapping | | | | | | | 755 | | +-------(f)--------+ | | +------|-----+ | | | 756 | | | +-----|-----+| | IP Service | +---+--+| | 757 | | +--------V---------+ |TE Resource|| | Composition| |Alarm/|| | 758 | | | TE Path | | Exposure || +--(d)-|-----+ | PM || | 759 | | | Management +----(h)----+| | +-(g) -+| | 760 | | +-------(e)--------+ | | +------|------+ | | 761 | | | | | | IP Service | | | | 762 | | +-----------------+ | | Provision +-----| | | 763 | | | +-(e)--|------+ | | 764 | | +-----------++ | | 765 | | | Resource | | | 766 | | | Collection | | | 767 | |------------------------+&Abstraction| | | 768 | +----(a)-----+ ---------------- 769 +----------------------------------------------------------------+ 771 Figure 4: Service and Network Management Automation with YANG 773 4.1. End-to-End Service Delivery and Service Assurance Procedure 775 4.1.1. Resource Collection and Abstraction (a) 777 Network Resources such as links, nodes, or terminate-point resources 778 can be collected from the network and aggregated or abstracted to the 779 management system. Periodic fetching of data is not an adequate 780 solution for applications requiring frequent or prompt updates of 781 network resources. Applying polling-based solutions to retrieve 782 network resource information impacts networks, devices, and 783 applications' loads. These limitations can be addressed by including 784 generic object subscription mechanisms within network elements. 786 These resources can be modelled using network topology models, L3 787 topology model, L2 topology model, TE topology model, L3 TE topology 788 model, SR TE topology models at different layers. 790 In some cases, there may be multiple overlay topologies built on top 791 of the same underlay topology, and the underlay topology can also be 792 built from one or more lower layer underlay topologies. The network 793 resources and management objects in these multi-layer topologies are 794 not recommended to be exposed to customers, but rather exposed to the 795 management system for IP service mapping and Path Management. 797 4.1.2. Service Exposure & Abstraction (b) 799 Service exposure & abstraction is used to capture services offered to 800 customers. 802 Service abstraction can be used by a customer to request a service 803 (ordering and order handling). One typical example is that a 804 customer can use a L3SM service model to request L3VPN service by 805 providing the abstract technical characterization of the intended 806 service. 808 Service catalogs can be created to expose the various services and 809 the information needed to invoke/order a given service. 811 YANG modules can be grouped into various service bundles; each 812 service bundle corresponds to a set of YANG modules that have been 813 released or published. Then, a mapping can be established between 814 service abstraction at higher layer and service bundle or a set of 815 YANG modules at lower layer. 817 4.1.3. IP Service Mapping (c) 819 Service abstraction starts with high-level abstractions exposing the 820 business capabilities or capturing customer requirements. Then, it 821 needs to map them to resource abstraction and specific network 822 technologies. 824 Therefore, the interaction between service abstraction in the overlay 825 and network resource abstraction in the underlay is required. For 826 example, in the L3SM service model, a VPN service topology is 827 described as e.g., hub and spoke and any-to-any, single-homed, dual- 828 homed, multi-homed relation between PEs and CEs, but we don't know 829 how this service topology can be mapped into the underlying network 830 topology Section 4.1.8 832 In addition, there is a need to decide on a mapping between service 833 abstraction and the underlying specific network technologies. Take 834 L3SM service model as an example, to deliver a L3VPN service, we need 835 to map L3SM service view defined in Service model into detailed 836 configuration view defined by specific configuration models for 837 network elements, configuartion information includes: 839 o VRF definition, including VPN Policy expression 841 o Physical Interface 843 o IP layer (IPv4, IPv6). 845 o QoS features such as classification, profiles, etc. 847 o Routing protocols: support of configuration of all protocols 848 listed in the document, as well as routing policies associated 849 with those protocols. 851 o Multicast Support 853 o NAT or address sharing 855 o Security functions 857 4.1.4. IP Service Composition (d) 859 These configuration models are further grouped together into service 860 bundles, as described in Figure 3using, e.g., device models, logical 861 network element models or network instance models defined in [I.D- 862 ietf-rtgwg-device-model] [RFC8530] [RFC8529] and provide the 863 association between an interface and its associated LNE and NI and 864 populate them into appropriate devices(e.g., PE and CE). 866 4.1.5. IP Service Provision (e) 868 IP Service Provision is used to provide IP network devices with a set 869 of configuration information, e.g., network element models such as 870 BGP, ACL, QoS, Interface model, Network instance models to configure 871 PE and CE devices within the site, etc. A BGP policy model is used 872 to establish VPN membership between sites and VPN Service Topology. 873 Experience shows that "pushing" configuration information to each 874 device one after the other is not efficient. 876 To automate the configuration of service elements, we first assemble 877 all the related network elements models into logical network element 878 model as defined in [RFC8530] and then establish an association with 879 an interface and a set of network element configurations. 881 In addition, not all the parameters of the service level model or 882 network level model(e.g., mapped from service level model) needs to 883 be specified, in many cases, some default values, or even some values 884 depending of some contextual information (e.g., the particular 885 service / network element / location / etc) should be taken to 886 automate the configuration process. 888 Seconldy, IP Service Provision can be used to setup tunnels between 889 sites and setup tunnels between PEs and CEs based upon tunnel-related 890 configuration information that can be derived from service 891 abstraction. However, when tunnel-related configuration parameters 892 cannot be generated from service abstraction, other service Mapping 893 procedure is required,e.g.,IP Service to TE mapping procdure 894 described in Section 4.1.7. 896 4.1.6. Performance Measurement and Alarm Telemetry (g) 898 Once the tunnel or VPN is setup, PM and Alarm information per tunnel 899 or per link based on network topology can be collected and report to 900 the management system. This information can be further aggregated 901 and abstracted from layered network topology to monitor and manage 902 network Performance on the topology at different layer or the overlay 903 topology between VPN sites. These network performance information or 904 VPN performance information (e.g., latency or bandwidth utilization 905 between two VPN sites) can be put into NBI telemetry model or NBI 906 performance monitoring model at either service level or network level 907 to further optimize the network or provide troubleshooting support. 909 4.1.7. IP Service to TE Mapping (f) 911 Take L3VPN service model as an example, the management system will 912 use L3SM service model to determine where to connect each site- 913 network-access of a particular site to the provider network (e.g., 914 PE, aggregation switch). The L3SM Service model includes parameters 915 that can help design the VPN, according to customer's requirements, 916 for example. 918 Nodes used to connect a site may be captured in relevant clauses of a 919 service exposure model (e.g., Customer Nodes Map [RFC7297]). 921 When Site location is determined, PE and CE device location will be 922 selected. Then we can replace parameters and constraints that can 923 influence the meshing of the site-network-access with specified PE 924 and CE device information associated with site-network-access and 925 generate resource facing VN Overlay Resource model. One example of 926 resource facing VN Overlay Resource model is TEAS VN Service Model 927 [I-D.ietf-teas-actn-vn-yang]. 929 This VN model can be used to calculate node and link resource to meet 930 service requirements based on Network Topology models collected at 931 step (a). 933 4.1.8. Path Management (h) 935 Path Management includes Path computation and Path setup. For 936 example, we can derive an instantiated L3SM service model into a 937 resource facing VN Model, with selected PE and CE in each site, we 938 can calculate point- to-point or multipoint end-to-end paths between 939 sites based on the VPN Overlay Resource Model. 941 After identifying node and link resources required to meet service 942 requirements, the mapping between overlay topology and underlay 943 topology can be established, e.g., establish an association between 944 VPN service topology defined in customer-facing model and underlying 945 network topology defined in the TE topology model (e.g., one overlay 946 node is supported by multiple underlay nodes, one overlay link is 947 supported by multiple underlay nodes) and generate end-to-end VPN 948 topology. 950 4.1.9. TE Resource Exposure (i) 952 When tunnel-related configuration parameters cannot be derived from 953 service abstraction, IP Service-to-TE Mapping procedure can be used 954 to generate TE Resource Exposure view, this TE resource Exposure view 955 can be modeled as a resource-facing VPN model which is translated and 956 instantiated from a L3SM model and manage TE resources based on path 957 management information and PM and alarm telemetry information. 959 Operators may use this dedicated TE resource Exposure view to 960 dynamically capture the overall network status and topology to: 962 o Perform all the requested recovery operations upon detecting 963 network failures affecting the network service. 965 o Adjust resource distribution and update to end to end Service 966 topology models 968 o Provide resource scheduling to better guarantee services for 969 customers and to improve the efficiency of network resource usage. 971 5. Sample Service Coordination via YANG Moodules 973 5.1. L3VPN Service Delivery via Coordinated YANG Modules 975 Take L3VPN service as an example, IETF has already developed L3VPN 976 service model [RFC8299] which can be used to describe L3VPN service. 977 To enforce L3VPN service and program the network, a set of network 978 element models are needed, e.g., BGP model, Network Instance model, 979 ACL model, Multicast Model, QoS model, or NAT model. 981 These network element models can be grouped into different release 982 bundles or feature bundles using Schema Mount technology to meet 983 different tailored requirements and deliver the L3VPN service. 985 To support the creation of logical network elements on a network 986 device and deliver a virtualized network, Logical Network Element 987 (LNE) models can be used to manage its own set of modules such as 988 ACL, QoS, or Network Instance modules. 990 5.2. 5G Transport Service Delivery via Coordinated YANG Modules 992 The overview of network slice structure as defined in the 3GPP 5GS is 993 shown in Figure 5. The terms are described in specific 3GPP 994 documents (e.g., [TS.23.501-3GPP] and [TS.28.530-3GPP]). 996 <================== E2E-NSI =======================> 997 : : : : : 998 : : : : : 999 <====== RAN-NSSI ======><=TRN-NSSI=><====== CN-NSSI ======>VL[APL] 1000 : : : : : : : : : 1001 : : : : : : : : : 1002 RW[NFs ]<=TRN-NSSI=>[NFs ]<=TRN-NSSI=>[NFs ]<=TRN-NSSI=>[NFs ]VL[APL] 1004 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 1005 .,----. ,----. ,----.. ,----. .,----. ,----. ,----.. 1006 UE--|RAN |---| TN |---|RAN |---| TN |---|CN |---| TN |---|CN |--[APL] 1007 .|NFs | `----' |NFs |. `----' .|NFs | `----' |NFs |. 1008 .`----' `----'. .`----' `----'. 1009 . . . . . . . . . . . . .. . . . . . . . . . . . . .. 1011 RW RAN MBH CN DN 1013 *Legends 1014 UE: User Equipment 1015 RAN: Radio Access Network 1016 CN: Core Network 1017 DN: Data Network 1018 TN: Transport Network 1019 MBH: Mobile Backhaul 1020 RW: Radio Wave 1021 NF: Network Function 1022 APL: Application Server 1023 NSI: Network Slice Instance 1024 NSSI: Network Slice Subnet Instance 1026 Figure 5: Overview of Structure of NS in 3GPP 5GS 1028 To support 5G service (e.g., 5G MBB service), L3VPN service model 1029 [RFC8299] and TEAS VN model [I-D. ietf-teas-actn-vn-yang] can be both 1030 provided to describe 5G MBB Transport Service or connectivity 1031 service. L3VPN service model is used to describe end-to-end 1032 connectivity service while TEAS VN model is used to describe TE 1033 connectivity service between VPN sites or between RAN NFs and Core 1034 network NFs. 1036 VN in TEAS VN model and support point-to-point or multipoint-to- 1037 multipoint connectivity service and can be seen as one example of 1038 network slice. 1040 TE Service mapping model can be used to map L3VPN service requests 1041 onto underlying network resource and TE models to get TE network 1042 setup. 1044 For IP VPN service provision, L3VPN service model is used to derive a 1045 set of configuration parameterswhich will be bound to different 1046 network element models and group them together to form feature or 1047 service bundles to deliver the VPN service. 1049 6. Modules Usage in Automated Virtualized Network Environment: Sample 1050 Examples 1052 6.1. Network-initiated Resource Creation 1054 |(2) 1055 | 1056 V 1057 +-------------------+ 1058 | Management System | (3)(4)(5) 1059 +-------------------+ 1061 +--------------------------------------------------------+ 1062 / _[CE2] _[CE3] / 1063 / _/ : \_ _/ : \_ / 1064 / _/ : \_ _/ : \_ / 1065 / _/ : \_ _/ : \_ / 1066 / / : \ / : \ / 1067 /[CE1]_________________[PE1] [PE2]_________________[CE4] / 1068 +---------:--------------:------------:--------------:---+ 1069 "Service" 1070 -------------------------------------------------------------------- 1071 +---------------------+ +---------------------+"Resource" 1072 / [Y5]... / / [Z5]______[Z3] / 1073 / / \ : / / : \_ / : / 1074 / / \ : / / : \_ / : / 1075 / / \ : / / : \ / : / 1076 / [Y4]____[Y1] : / / : [Z2] : / 1077 +------:-------:---:--+ +---:---------:-----:-+ ^ 1078 vNet1 : : : : : : vNet2 | 1079 : : : : : : |(1) 1080 : +-------:---:-----:------------:-----:-----+ | 1081 : / [X1]__:___:___________[X2] : / | 1082 :/ / \_ : : _____/ / : / | 1083 : / \_ : _____/ / : / 1084 /: / \: / / : / 1085 / : / [X5] / : / 1086 / : / __/ \__ / : / 1087 / : / ___/ \__ / : / 1088 / : / ___/ \ / : / 1089 / [X4]__________________[X3]..: / 1090 +------------------------------------------+ 1091 L3 Topology 1093 The following steps are performed to deliver the service within the 1094 network management automation architecture proposed in this document: 1096 1. Pre-provision multiple virtualized networks on top of the same 1097 basic network infrastructure based on pre-configured service 1098 requirements and establish resource pool for each virtualized 1099 network and expose to the customer with several service templates 1100 through web portal. 1102 2. Selects and uses one which best accommodates its requirement 1103 among the service templates. 1105 3. Calculate the node resource, link resource corresponding to 1106 connectivity between sites and create resource facing VN Network 1107 based on selected service template, and 1109 4. Setup tunnels between sites and map them into the selected 1110 virtualized network topology and establish resource facing VN 1111 topology based on TEAS VN model [I-D.ietf-teas-actn-vn-yang] and 1112 TE tunnel based on TE Tunnel model. 1114 The resource-facing VN model and corresponding TE Tunnel model 1115 can be further used to notify all the parameter changes and event 1116 related to VN topology or Tunnel. This information can be 1117 further used to adjust network resource distributed in the 1118 network. 1120 The network initiated resource creation is similar to ready-made 1121 Network Slice creation pattern discussed in Section 5.1 of [I- 1122 D.homma-slice-provision-models]. 1124 6.2. Customer-initiated Dynamic Resource Creation 1125 |(2) 1126 | 1127 V 1128 +-------------------+ 1129 | Management System | (3)(4)(5) 1130 +-------------------+ 1132 +--------------------------------------------------------+ 1133 / _[CE2] _[CE3] / 1134 / _/ : \_ _/ : \_ / 1135 / _/ : \_ _/ : \_ / 1136 / _/ : \_ _/ : \_ / 1137 / / : \ / : \ / 1138 /[CE1]_________________[PE1] [PE2]_________________[CE4] / 1139 +---------:--------------:------------:--------------:---+ 1140 "Service" 1141 -------------------------------------------------------------------- 1142 "Resource" ^ 1143 : | 1144 : : : |(1) 1145 : +-------:---:-----:------------:-----:-----+ | 1146 : / [X1]__:___ __________[X2] / | 1147 :/ / \_ : _____/ / / | 1148 : / \_ : _____/ / / 1149 /: / \: / / / 1150 / : / [X5] / / 1151 / : / __/ \__ / / 1152 / : / ___/ \__ / / 1153 / : / ___/ \ / / 1154 / [X4]__________________[X3]. / 1155 +------------------------------------------+ 1156 L3 Topology 1158 The following steps are performed to deliver the service within the 1159 network management automation architecture proposed in this document: 1161 1. Establish resource pool for the basic common network 1162 infrastructure. 1164 2. Request to create two sites based on L3SM Service model with each 1165 having one network access connectivity: 1167 Site A: Network-Access A, Bandwidth=20M, for class "foo", 1168 guaranteed-bw-percent = 10, One-Way-Delay=70 msec 1170 Site B: Network-Access B, Bandwidth=30M, for class "foo1", 1171 guaranteed-bw-percent = 15, One-Way-Delay=60 msec 1173 3. Create a new service topology based on Service Type and service 1174 requirements (e.g., Service Type, Site location, Number of 1175 Slices, QoS requirements corresponding to network connectivity 1176 within a L3VPN) defined in L3SM service model. 1178 4. Translate L3SM service model into resource facing TEAS VN Model 1179 [I-D.ietf-teas-actn-vn-yang] and a set of Network element models 1180 to enable the protocols on the network device and get the network 1181 setup, and the generated resource facing TEAS VN model can be 1182 further used to calculate the node resource, link resource 1183 corresponding to connectivity between sites. 1185 5. Setup tunnels between sites and map them with the network 1186 infrastructure and establish resource facing VN topology based on 1187 TEAS VN model and TE tunnel based on TE Tunnel model. The 1188 resource facing TEAS VN model and corresponding TE Tunnel model 1189 can be used to notify all the parameter changes and event related 1190 to VN topology or Tunnel. These information can be further used 1191 to adjust network resource distributed within the network. 1193 The customer-initiated resource creation is similar to customer made 1194 Network Slice creation pattern discussed in Section 5.2 of [I- 1195 D.homma-slice-provision-models]. 1197 7. Security Considerations 1199 Security considerations specific to each of the technologies and 1200 protocols listed in the document are discussed in the specification 1201 documents of each of these techniques. 1203 (Potential) security considerations specific to this document are 1204 listed below: 1206 o Create forwarding loops by mis-configuring the underlying network. 1208 o Leak sensitive information: special care should be considered when 1209 translating between the various layers introduced in the document. 1211 o ...tbc 1213 8. IANA Considerations 1215 There are no IANA requests or assignments included in this document. 1217 9. Contributors 1219 Shunsuke Homma 1220 Japan 1222 Email: s.homma0718+ietf@gmail.com 1224 10. Acknowledgements 1226 Thanks to Joe Clark and Greg Mirsky for the review. 1228 11. Informative References 1230 [I-D.arkko-arch-virtualization] 1231 Arkko, J., Tantsura, J., Halpern, J., and B. Varga, 1232 "Considerations on Network Virtualization and Slicing", 1233 draft-arkko-arch-virtualization-01 (work in progress), 1234 March 2018. 1236 [I-D.asechoud-netmod-diffserv-model] 1237 Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N. 1238 Strahle, "YANG Model for Diffserv", draft-asechoud-netmod- 1239 diffserv-model-03 (work in progress), June 2015. 1241 [I-D.clacla-netmod-model-catalog] 1242 Clarke, J. and B. Claise, "YANG module for 1243 yangcatalog.org", draft-clacla-netmod-model-catalog-03 1244 (work in progress), April 2018. 1246 [I-D.homma-slice-provision-models] 1247 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 1248 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 1249 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 1250 Foy, "Network Slice Provision Models", draft-homma-slice- 1251 provision-models-00 (work in progress), February 2019. 1253 [I-D.ietf-bess-evpn-yang] 1254 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 1255 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 1256 bess-evpn-yang-07 (work in progress), March 2019. 1258 [I-D.ietf-bess-l2vpn-yang] 1259 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1260 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1261 L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), 1262 July 2019. 1264 [I-D.ietf-bess-l3vpn-yang] 1265 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 1266 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 1267 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 1268 in progress), October 2018. 1270 [I-D.ietf-bfd-yang] 1271 Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and 1272 G. Mirsky, "YANG Data Model for Bidirectional Forwarding 1273 Detection (BFD)", draft-ietf-bfd-yang-17 (work in 1274 progress), August 2018. 1276 [I-D.ietf-ccamp-alarm-module] 1277 Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft- 1278 ietf-ccamp-alarm-module-09 (work in progress), April 2019. 1280 [I-D.ietf-ccamp-flexigrid-media-channel-yang] 1281 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1282 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1283 Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid- 1284 media-channel-yang-02 (work in progress), March 2019. 1286 [I-D.ietf-ccamp-flexigrid-yang] 1287 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1288 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1289 Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid- 1290 yang-03 (work in progress), March 2019. 1292 [I-D.ietf-ccamp-l1csm-yang] 1293 Fioccola, G., Lee, K., Lee, Y., Dhody, D., and D. 1294 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 1295 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-09 (work in 1296 progress), March 2019. 1298 [I-D.ietf-ccamp-mw-yang] 1299 Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M. 1300 Vaupotic, "A YANG Data Model for Microwave Radio Link", 1301 draft-ietf-ccamp-mw-yang-13 (work in progress), November 1302 2018. 1304 [I-D.ietf-ccamp-otn-topo-yang] 1305 Zheng, H., Guo, A., Busi, I., Sharma, A., Liu, X., 1306 Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data 1307 Model for Optical Transport Network Topology", draft-ietf- 1308 ccamp-otn-topo-yang-06 (work in progress), February 2019. 1310 [I-D.ietf-ccamp-otn-tunnel-model] 1311 Zheng, H., Guo, A., Busi, I., Sharma, A., Rao, R., 1312 Belotti, S., Lopezalvarez, V., Li, Y., and Y. Xu, "OTN 1313 Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-model-06 1314 (work in progress), February 2019. 1316 [I-D.ietf-ccamp-wson-tunnel-model] 1317 Lee, Y., Dhody, D., Guo, A., Lopezalvarez, V., King, D., 1318 Yoon, B., and R. Vilata, "A Yang Data Model for WSON 1319 Tunnel", draft-ietf-ccamp-wson-tunnel-model-03 (work in 1320 progress), March 2019. 1322 [I-D.ietf-dots-data-channel] 1323 Boucadair, M. and R. K, "Distributed Denial-of-Service 1324 Open Threat Signaling (DOTS) Data Channel Specification", 1325 draft-ietf-dots-data-channel-29 (work in progress), May 1326 2019. 1328 [I-D.ietf-dots-signal-channel] 1329 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 1330 Teague, "Distributed Denial-of-Service Open Threat 1331 Signaling (DOTS) Signal Channel Specification", draft- 1332 ietf-dots-signal-channel-34 (work in progress), May 2019. 1334 [I-D.ietf-idr-bgp-model] 1335 Jethanandani, M., Patel, K., and S. Hares, "BGP YANG Model 1336 for Service Provider Networks", draft-ietf-idr-bgp- 1337 model-06 (work in progress), June 2019. 1339 [I-D.ietf-ippm-stamp-yang] 1340 Mirsky, G., Xiao, M., and W. Luo, "Simple Two-way Active 1341 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 1342 stamp-yang-03 (work in progress), March 2019. 1344 [I-D.ietf-ippm-twamp-yang] 1345 Civil, R., Morton, A., Rahman, R., Jethanandani, M., and 1346 K. Pentikousis, "Two-Way Active Measurement Protocol 1347 (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work 1348 in progress), July 2018. 1350 [I-D.ietf-mpls-base-yang] 1351 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 1352 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 1353 yang-10 (work in progress), February 2019. 1355 [I-D.ietf-pim-igmp-mld-snooping-yang] 1356 Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, 1357 "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- 1358 pim-igmp-mld-snooping-yang-08 (work in progress), June 1359 2019. 1361 [I-D.ietf-pim-igmp-mld-yang] 1362 Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 1363 Peter, "A YANG Data Model for Internet Group Management 1364 Protocol (IGMP) and Multicast Listener Discovery (MLD)", 1365 draft-ietf-pim-igmp-mld-yang-15 (work in progress), June 1366 2019. 1368 [I-D.ietf-pim-yang] 1369 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1370 Y., and f. hu, "A YANG Data Model for Protocol Independent 1371 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1372 progress), May 2018. 1374 [I-D.ietf-rtgwg-device-model] 1375 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 1376 "Network Device YANG Logical Organization", draft-ietf- 1377 rtgwg-device-model-02 (work in progress), March 2017. 1379 [I-D.ietf-rtgwg-policy-model] 1380 Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data 1381 Model for Routing Policy Management", draft-ietf-rtgwg- 1382 policy-model-06 (work in progress), March 2019. 1384 [I-D.ietf-softwire-iftunnel] 1385 Boucadair, M., Farrer, I., and R. Asati, "Tunnel Interface 1386 Types YANG Module", draft-ietf-softwire-iftunnel-07 (work 1387 in progress), June 2019. 1389 [I-D.ietf-softwire-yang] 1390 Farrer, I. and M. Boucadair, "YANG Modules for IPv4-in- 1391 IPv6 Address plus Port (A+P) Softwires", draft-ietf- 1392 softwire-yang-16 (work in progress), January 2019. 1394 [I-D.ietf-spring-sr-yang] 1395 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 1396 Tantsura, "YANG Data Model for Segment Routing", draft- 1397 ietf-spring-sr-yang-12 (work in progress), February 2019. 1399 [I-D.ietf-supa-generic-policy-data-model] 1400 Halpern, J. and J. Strassner, "Generic Policy Data Model 1401 for Simplified Use of Policy Abstractions (SUPA)", draft- 1402 ietf-supa-generic-policy-data-model-04 (work in progress), 1403 June 2017. 1405 [I-D.ietf-teas-actn-vn-yang] 1406 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1407 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1408 teas-actn-vn-yang-05 (work in progress), June 2019. 1410 [I-D.ietf-teas-sf-aware-topo-model] 1411 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, 1412 L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology 1413 YANG Model", draft-ietf-teas-sf-aware-topo-model-03 (work 1414 in progress), March 2019. 1416 [I-D.ietf-teas-te-service-mapping-yang] 1417 Lee, Y., Dhody, D., Ceccarelli, D., Tantsura, J., 1418 Fioccola, G., and Q. Wu, "Traffic Engineering and Service 1419 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 1420 yang-01 (work in progress), March 2019. 1422 [I-D.ietf-teas-yang-l3-te-topo] 1423 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1424 O. Dios, "YANG Data Model for Layer 3 TE Topologies", 1425 draft-ietf-teas-yang-l3-te-topo-04 (work in progress), 1426 March 2019. 1428 [I-D.ietf-teas-yang-path-computation] 1429 Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma, 1430 A., Shi, Y., Vilata, R., Sethuraman, K., Scharf, M., and 1431 D. Ceccarelli, "Yang model for requesting Path 1432 Computation", draft-ietf-teas-yang-path-computation-05 1433 (work in progress), March 2019. 1435 [I-D.ietf-teas-yang-rsvp-te] 1436 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 1437 and H. Shah, "A YANG Data Model for RSVP-TE Protocol", 1438 draft-ietf-teas-yang-rsvp-te-06 (work in progress), April 1439 2019. 1441 [I-D.ietf-teas-yang-sr-te-topo] 1442 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1443 S. Litkowski, "YANG Data Model for SR and SR TE 1444 Topologies", draft-ietf-teas-yang-sr-te-topo-04 (work in 1445 progress), March 2019. 1447 [I-D.ietf-teas-yang-te] 1448 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1449 "A YANG Data Model for Traffic Engineering Tunnels and 1450 Interfaces", draft-ietf-teas-yang-te-21 (work in 1451 progress), April 2019. 1453 [I-D.ietf-teas-yang-te-topo] 1454 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1455 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1456 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 1457 progress), June 2019. 1459 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1460 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1461 2006, . 1463 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1464 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1465 DOI 10.17487/RFC4664, September 2006, 1466 . 1468 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1469 LAN Service (VPLS) Using BGP for Auto-Discovery and 1470 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1471 . 1473 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1474 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1475 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1476 . 1478 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1479 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1480 . 1482 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1483 Networking: A Perspective from within a Service Provider 1484 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1485 . 1487 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1488 Weingarten, "An Overview of Operations, Administration, 1489 and Maintenance (OAM) Tools", RFC 7276, 1490 DOI 10.17487/RFC7276, June 2014, 1491 . 1493 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1494 Connectivity Provisioning Profile (CPP)", RFC 7297, 1495 DOI 10.17487/RFC7297, July 2014, 1496 . 1498 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 1499 Maintenance Using the Label Distribution Protocol (LDP)", 1500 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 1501 . 1503 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1504 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1505 August 2017, . 1507 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1508 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1509 2017, . 1511 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1512 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1513 DOI 10.17487/RFC8299, January 2018, 1514 . 1516 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1517 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1518 . 1520 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 1521 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 1522 Management Framework for the Simplified Use of Policy 1523 Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328, 1524 March 2018, . 1526 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1527 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1528 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1529 2018, . 1531 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1532 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1533 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1534 March 2018, . 1536 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1537 Routing Management (NMDA Version)", RFC 8349, 1538 DOI 10.17487/RFC8349, March 2018, 1539 . 1541 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1542 Data Model for Layer 2 Virtual Private Network (L2VPN) 1543 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1544 2018, . 1546 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1547 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1548 Address Translation (NAT) and Network Prefix Translation 1549 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1550 . 1552 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1553 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1554 DOI 10.17487/RFC8513, January 2019, 1555 . 1557 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1558 "YANG Data Model for Network Access Control Lists (ACLs)", 1559 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1560 . 1562 [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", 1563 RFC 8528, DOI 10.17487/RFC8528, March 2019, 1564 . 1566 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1567 Liu, "YANG Data Model for Network Instances", RFC 8529, 1568 DOI 10.17487/RFC8529, March 2019, 1569 . 1571 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1572 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1573 DOI 10.17487/RFC8530, March 2019, 1574 . 1576 [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1577 for Connection-Oriented Operations, Administration, and 1578 Maintenance (OAM) Protocols", RFC 8531, 1579 DOI 10.17487/RFC8531, April 2019, 1580 . 1582 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1583 Raghavan, "Generic YANG Data Model for the Management of 1584 Operations, Administration, and Maintenance (OAM) 1585 Protocols That Use Connectionless Communications", 1586 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1587 . 1589 [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. 1590 Raghavan, "A YANG Data Model for Retrieval Methods for the 1591 Management of Operations, Administration, and Maintenance 1592 (OAM) Protocols That Use Connectionless Communications", 1593 RFC 8533, DOI 10.17487/RFC8533, April 2019, 1594 . 1596 Authors' Addresses 1598 Qin Wu 1599 Huawei 1600 101 Software Avenue, Yuhua District 1601 Nanjing, Jiangsu 210012 1602 China 1604 Email: bill.wu@huawei.com 1606 Mohamed Boucadair 1607 Orange 1608 Rennes 35000 1609 France 1611 Email: mohamed.boucadair@orange.com 1613 Christian 1614 Orange 1615 Rennes 35000 1616 France 1618 Email: christian.jacquenet@orange.com 1620 Luis Miguel Contreras Murillo 1621 Telifonica 1623 Email: luismiguel.contrerasmurillo@telefonica.com 1625 Diego R. Lopez 1626 Telefonica I+D 1627 Spain 1629 Email: diego.r.lopez@telefonica.com 1630 Chongfeng Xie 1631 China Telecom 1632 Beijing 1633 China 1635 Email: xiechf.bri@chinatelecom.cn 1637 Weiqiang Cheng 1638 China Mobile 1640 Email: chengweiqiang@chinamobile.com 1642 Young Lee 1643 Futurewei 1645 Email: younglee.tx@gmail.com