idnits 2.17.1 draft-wu-model-driven-management-virtualization-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 33 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 24, 2018) is 2133 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-ccamp-wson-yang' is mentioned on line 405, but not defined == Missing Reference: 'I-D.ccamp-wson-tunnel-model' is mentioned on line 449, but not defined == Missing Reference: 'RFC4364' is mentioned on line 635, but not defined == Missing Reference: 'RFC4664' is mentioned on line 640, but not defined == Missing Reference: 'RFC8077' is mentioned on line 645, but not defined == Missing Reference: 'RFC4762' is mentioned on line 645, but not defined == Missing Reference: 'RFC4761' is mentioned on line 645, but not defined == Missing Reference: 'RFC5880' is mentioned on line 656, but not defined == Missing Reference: 'Y5' is mentioned on line 923, but not defined == Missing Reference: 'Z5' is mentioned on line 923, but not defined == Missing Reference: 'Z3' is mentioned on line 923, but not defined == Missing Reference: 'Y4' is mentioned on line 927, but not defined == Missing Reference: 'Y1' is mentioned on line 927, but not defined == Missing Reference: 'Z2' is mentioned on line 927, but not defined == Missing Reference: 'X5' is mentioned on line 1006, but not defined == Unused Reference: 'I-D.ietf-bfd-yang' is defined on line 1108, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-alarm-module' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-media-channel-yang' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-flexigrid-yang' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-l1csm-yang' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-mw-yang' is defined on line 1137, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-otn-topo-yang' is defined on line 1142, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-otn-tunnel-model' is defined on line 1149, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-wson-tunnel-model' is defined on line 1155, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-l3-topology' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-network-topo' is defined on line 1180, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lime-yang-connection-oriented-oam-model' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lime-yang-connectionless-oam' is defined on line 1198, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lime-yang-connectionless-oam-methods' is defined on line 1205, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-acl-model' is defined on line 1218, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-opsawg-nat-yang' is defined on line 1229, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-device-model' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-lne-model' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-ni-model' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-actn-vn-yang' is defined on line 1269, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-sf-aware-topo-model' is defined on line 1275, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-path-computation' is defined on line 1280, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-rsvp-te' is defined on line 1287, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 1292, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 1298, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-teas-yang-l3-te-topo' is defined on line 1316, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-bess-evpn-yang-05 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-08 == Outdated reference: A later version (-05) exists of draft-ietf-bess-l3vpn-yang-03 == Outdated reference: A later version (-17) exists of draft-ietf-bfd-yang-16 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-alarm-module-01 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-flexigrid-media-channel-yang-00 == Outdated reference: A later version (-16) exists of draft-ietf-ccamp-flexigrid-yang-00 == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-04 == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-mw-yang-06 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-03 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-02 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-wson-tunnel-model-00 == Outdated reference: A later version (-31) exists of draft-ietf-dots-data-channel-16 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-20 == Outdated reference: A later version (-17) exists of draft-ietf-mpls-base-yang-06 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-19 == Outdated reference: A later version (-12) exists of draft-ietf-netmod-schema-mount-10 == Outdated reference: A later version (-17) exists of draft-ietf-opsawg-nat-yang-14 == Outdated reference: A later version (-15) exists of draft-ietf-pim-igmp-mld-yang-06 == Outdated reference: A later version (-31) exists of draft-ietf-rtgwg-policy-model-02 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-01 == Outdated reference: A later version (-12) exists of draft-ietf-teas-sf-aware-topo-model-00 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-01 == Outdated reference: A later version (-09) exists of draft-ietf-teas-yang-rsvp-te-03 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-15 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-17 == Outdated reference: A later version (-13) exists of draft-lee-teas-te-service-mapping-yang-08 Summary: 1 error (**), 0 flaws (~~), 69 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: Standards Track M. Boucadair 5 Expires: December 26, 2018 Orange 6 Y. Lee 7 Huawei 8 June 24, 2018 10 An Architecture for Data Model Driven Network Management: the Network 11 Virtualization Case 12 draft-wu-model-driven-management-virtualization-01 14 Abstract 16 Data Model driven network management can be used at various phases of 17 service and network management life cycle such as service 18 instantiation, service provision, optimization, monitoring, and 19 diagnostic. Also, it can be designed to provide closed-loop control 20 for the sake of agile service creation, delivery and maintenance. 22 This document describes an architecture for data model driven network 23 management with a sample applicability case: network virtualization 24 environments. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 26, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 4 62 2.1. Data Models: Layering and Representation . . . . . . . . 4 63 2.2. Service and Network Resources Exposure: . . . . . . . . . 4 64 2.3. Service Element Configuration Model Composition . . . . . 4 65 2.4. A Catalog for YANG Modules . . . . . . . . . . . . . . . 5 66 3. IETF YANG Modules: An Overview . . . . . . . . . . . . . . . 5 67 3.1. Network Service and Resource Models . . . . . . . . . . . 6 68 3.1.1. Network Service Models: Definition and Samples . . . 7 69 3.1.2. Network Resource Models . . . . . . . . . . . . . . . 8 70 3.2. Network Element Models . . . . . . . . . . . . . . . . . 11 71 3.2.1. Model Composition . . . . . . . . . . . . . . . . . . 12 72 3.2.2. Protocol/Function Configuration Models . . . . . . . 13 73 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 15 74 4.1. End-to-End Service Delivery and Service Assurance 75 Procedure . . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.1.1. Resource Collection and Abstraction (a) . . . . . . . 16 77 4.1.2. Service Exposure & Abstraction (b) . . . . . . . . . 17 78 4.1.3. IP Service Mapping (c) . . . . . . . . . . . . . . . 18 79 4.1.4. IP Service Composition (d) . . . . . . . . . . . . . 18 80 4.1.5. IP Service Provision (e) . . . . . . . . . . . . . . 19 81 4.1.6. IP Service to TE Mapping (e) . . . . . . . . . . . . 19 82 4.1.7. Path Management (f) . . . . . . . . . . . . . . . . . 20 83 4.1.8. Performance Measurement and Alarm Telemetry (g) . . . 20 84 4.1.9. TE Resource Exposure (h) . . . . . . . . . . . . . . 20 85 5. Model usage in network virtualization environment: Sample 86 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 5.1. Network Topology Resource Pre-Provision . . . . . . . . . 21 88 5.2. On Demand Network Topology Resource Creation . . . . . . 22 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 91 8. Informative References . . . . . . . . . . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 94 1. Introduction 96 As observed in [I-D.arkko-arch-virtualization], many IETF discussions 97 earlier in the summer of 2017 started from a top-down view of new 98 virtualization technologies, but they were often unable to explain 99 the necessary delta to the wealth of existing IETF technologies in 100 this space. Therefore, [I-D.arkko-arch-virtualization] considered a 101 bottom-up approach to provide an overview of existing technologies 102 which is aiming at identifying areas for further development. 104 For years, the IETF has been driving the industry transition from an 105 overloaded Software Defined Networking (SDN) buzzword to focus on 106 specific areas such as data modeling-driven management. [RFC7149] 107 provides a first tentative to rationalize that space by identifying 108 concrete technical domains that need to be considered: 110 o Techniques for the dynamic discovery of network topology, devices, 111 and capabilities, along with relevant information and data models 112 that are meant to precisely document such topology, devices, and 113 their capabilities. 115 o Techniques for exposing network services [RFC8309] and their 116 characteristics. 118 o Techniques used by service-requirement-derived dynamic resource 119 allocation and policy enforcement schemes, so that networks can be 120 programmed accordingly. 122 o Dynamic feedback mechanisms that are meant to assess how 123 efficiently a given policy (or a set thereof) is enforced from a 124 service fulfillment and assurance perspective. 126 Models are key for each of these technical items. 128 In the later development, , as described in [RFC8199], YANG module 129 developers have taken both top-down and bottom-up approaches to 130 develop modules and establish mapping between network technology and 131 customer requirements on the top or abstracting common construct from 132 various network technologies. At the time of writing this document 133 (2018), we see the large number of data models including 134 configuration models and service models developed or under 135 development in IETF covering much of networking protocols and 136 techniques. In addition, how these models work together to fully 137 configure a device, or manage a set of devices involved in a service 138 aren't developed yet in IETF. 140 This document takes both bottom up approach and top down approach to 141 provide a framework that discusses the architecture for data model 142 driven network management, with a focus on network virtualization 143 environment. 145 This document also describes specific YANG modules needed to realize 146 connectivity services and investigates how top down built model 147 (e.g., customer-facing data models) interact with bottom up built 148 model (network resource-facing data models) in the context of service 149 delivery and assurance. 151 2. Architectural Concepts 153 2.1. Data Models: Layering and Representation 155 As described in [RFC8199], layering of modules allows for better 156 reusability of lower-layer modules by higher-level modules while 157 limiting duplication of features across layers. 159 The IETF has developed large number of network level and device level 160 modules and service level module. Different service level modules 161 may rely on the same set of network level or device level modules. 162 Service level modules follow top down approach and are mostly 163 customer-facing models providing a common model construct for higher 164 level network services, which can be further mapped to network 165 technology-specific models at lower layer. 167 Network level modules mostly follow bottom up approach and are mostly 168 network resource-facing model and describe various aspects of a 169 network infrastructure, including devices and their subsystems, and 170 relevant protocols operating at the link and network layers across 171 multiple devices (e.g., Network topology and TE Tunnel modules). 173 Device level modules follow bottom up approach and are mostly 174 technology-specific modules used to realize a service. 176 2.2. Service and Network Resources Exposure: 178 Service level model defines a service ordered by a customer from an 179 operator. The service can be built from a combination of network 180 elements and protocols configuration which also include various 181 aspects of the underlying network infrastructure, including 182 functions/devices and their subsystems, and relevant protocols 183 operating at the link and network layers across multiple device. 185 2.3. Service Element Configuration Model Composition 187 To provide service agility (including network management automation), 188 lower level technology-specific models need to be assembled together 189 to provision each involved network function/device and operate the 190 network based on service requirements described in the service level 191 model. 193 IETF RTGWG working group has already been tasked to define service 194 elements configuration model composition mechanism and develop 195 several composition model such as network instance model, logical 196 network element model and device model. 198 These models can be used to setup and administrate both virtualized 199 system and physical system. 201 2.4. A Catalog for YANG Modules 203 The idea of a catalog is similar to service catalogs in traditional 204 IT environments. Service catalogs serve as a software-based 205 registries of available services with information needed to discover 206 and invoke available services. 208 The IETF has already tasked to develop a YANG catalog which can be 209 used to manage not only IETF defined modules, but also non-IETF 210 defined ones [I-D.clacla-netmod-model-catalog]. 212 The YANG catalog allows to align IETF work with other SDOs work and 213 prevent duplicated building blocks being developed. It also 214 encourages reusability of common building blocks. 216 The YANG catalog allows both YANG developers and operators to 217 discover the more mature YANG modules that may be used to automate 218 services operations . 220 3. IETF YANG Modules: An Overview 221 <> 222 +-----------------------------------------------------------------------+ 223 | +-------------+ +-------------+| 224 | |DOTS Data | | I2NSF || 225 | |and Signaling| | Customer || 226 | << Network Service Models>> | Models | | Facing Model|| 227 | +-------------+ +-------------+| 228 | +----------------+ +----------------+ +-------------+ | 229 | | L3SM | | L2SM | | ACTN VN | | 230 | | Service Model | | Service Model | |Service Model| | 231 | +----------------+ +----------------+ +-------------+ | 232 |------------------------------------------------------------------- | 233 | << Network Resource Models >> | 234 | +------------+ +-------+ +----------------+ +------------+ | 235 | |Network Topo| | Tunnel| |Path Computation| |OAM,PM,Alarm| | 236 | | Models | | Models| | API Models | | Models | | 237 | +------------+ +-------+ +----------------+ +------------+ | 238 +-----------------------------------------------------------------------+ 239 -------------------------------------------------------------------- 240 > 241 +-----------------------------------------------------------------------+ 242 | <> | 243 | +-------------+ +---------------+ +----------------+ | 244 | |Device Model | |Logical Network| |Network Instance| | 245 | | | |Element Model | | Model | | 246 | +-------------+ +---------------+ +----------------+ | 247 |---------------------------------------------------------------------- | 248 | | 249 | << Component Models>> | 250 | +------------+ | 251 | +-----+ +------+ +---++----+ +----+ |OAM,PM,Alarm| | 252 | | BGP | | MPLS | |ACL||QoS | |NAT | | Models | ..... | 253 | +-----+ +------+ +---++----+ +----+ +------------+ | 254 | | 255 +-----------------------------------------------------------------------+ 257 3.1. Network Service and Resource Models 259 Service and Network Resource Exposure modules define what the 260 "service"/"resource" is. These modules can be classified into two 261 categories: 263 o Network Service Models 265 o Network Resource Models 267 3.1.1. Network Service Models: Definition and Samples 269 As described in [RFC8309], the service is some form of connectivity 270 between customer sites and the Internet or between customer sites 271 across the network operator's network and across the Internet. 273 For example, 275 o L3SM model [RFC8299] defines the L3VPN service ordered by a the 276 customer from a network operator. 278 o L2SM model [I-D.ietf-l2sm-l2vpn-service-model] defines the L2VPN 279 service ordered by a the customer from a network operator. 281 o L1CSM model [I-D.ietf-ccamp-l1csm-yang]defines a YANG data model 282 for Layer 1 Connectivity Service Model (L1CSM). 284 o ACTN model [I-D. ietf-teas-actn-vn-yang] defines YANG data model 285 for the Abstraction and Control of Traffic Engineered (TE) 286 networks (ACTN) Virtual Network Service (VNS) operation. Unlike 287 L3SM model, ACTN model can also be used as operator facing model, 288 e.g., establish interconnection between L3VPN sites across 289 multiple ASs. 291 o TE service mapping model [I-D.lee-teas-te-service-mapping-yang] a 292 YANG data model to map service model (e.g., L3SM) and Traffic 293 Engineering model (e.g., TE Tunnel or ACTN VN model). This model 294 is applicable to the operation's need for a seamless control and 295 management of their VPN services with TE tunnel support. 297 o Composite VPN model [I-D.chen-opsawg-composite-vpn-dm] the YANG 298 data model of the composite VPN for operators to provision, 299 optimize, monitor and diagnose the end to end PE-based VPN 300 services across multiple autonomous systems (ASes). The model 301 from this document are limited to multiple ASes within one service 302 provider. Ulike L3SM model, Composite VPN model is operator 303 facing model. 305 The IETF is currently defining three other customer-facing modules: 306 ietf-dots-signal-channel [I-D.ietf-dots-signal-channel] and ietf- 307 dots-data-channel [I-D.ietf-dots-data-channel] and I2NSF Consumer- 308 Facing Interface YANG module 309 [I-D.jeong-i2nsf-consumer-facing-interface-dm]. The first two 310 modules are meant to be used by clients to signal DDoS attacks or to 311 request installing filters for the sake of DDoS mitigation. Those 312 modules do not intervene directly in the configuration of underlying 313 network devices. The third module is required for enabling different 314 users of a given I2NSF system to define, manage, and monitor security 315 policies for specific flows within an administrative domain. 317 3.1.2. Network Resource Models 319 Figure 1 shows a set of resource-facing network YANG modules: 321 | | 322 Topo YANG Models | Tunnel YANG Models |Resource NM Tool 323 ------------------------------------------------|-- ------------ 324 +------------+ | | 325 |Network Top | | +-----------+ | +-------+ 326 | Model | | | TE Tunnel | | | LIME | 327 +----+-------+ | +------+----+ | | Model | 328 | +--------+ | | | |/PM/OAM| 329 |---+TE Topo | | +--------+-+--------+ | Model| 330 | +--------+ | +----+---+ +---+----+ +-+-----+ +-------+ 331 | +--------+ | |MPLS-TE | |RSVP-TE | |SR TE | +--------+ 332 +---+L3 Topo | | Tunnel | | Tunnel | |Tunnel | | Alarm | 333 +----|---+ +--------+ +--------+ +-------+ | Model | 334 +---------+---------+ +--------+ 335 | | | +-----------+ 336 +---|---+ +--|---+ +---|-+ |Path | 337 |SR Topo| |SR TE | |L3 TE| |Computation| 338 | Model | | Topo | |Topo | |API Model | 339 +-------+ +------+ +-----+ +-----------+ 341 Figure 1: Sample Resource Facing Network Models 343 Topology YANG Models: 345 o Network Topology Models: [I.D-ietf-i2rs-yang-network-topo] defines 346 base model for network topology and inventories. Network topology 347 data include link resource, node resource and terminate-point 348 resource. 350 o TE Topology Models: [I.D-ietf-teas-yang-te-topo] defines a data 351 model for representing and manipulating TE Topologies. 353 This module is extended from network topology model defined in 354 [I.D-ietf-i2rs-yang-network-topo] with TE topologies specifics. 355 This model contains technology agnostic TE Topology building 356 blocks that can be augmented and used by other technology-specific 357 TE Topology models. 359 o L3 Topology Models 361 [I.D-ietf-i2rs-yang-l3-topology] defines a data model for 362 representing and manipulating L3 Topologies. This model is 363 extended from the network topology model defined in [I.D-ietf- 364 i2rs-yang-network-topo] with L3 topologies specifics. 366 o L2 Topology Models 368 [I.D-ietf-i2rs-yang-l2-topology] defines a data model for 369 representing and manipulating L2 Topologies. This model is 370 extended from the network topology model defined in [I.D-ietf- 371 i2rs-yang-network-topo] with L2 topologies specifics. 373 o L3 TE Topology Models 375 When traffic engineering is enabled on a layer 3 network topology, 376 there will be a corresponding TE topology. [I.D-liu-teas-yang-l3- 377 te-topo] defines data models for layer 3 traffic engineering 378 topologies. Two data models are defined, one is layer 3 TE 379 topology model, the other is packet switching TE topology model. 380 Layer 3 TE topology model is extended from Layer 3 topology model. 381 Packet switching TE topology model is extended from TE topology 382 model. 384 o SR TE Topology Models 386 [I-D.liu-teas-yang-sr-te-topo] defines a YANG module for Segment 387 Routing (SR) topology and Segment Routing (SR) traffic engineering 388 (TE) topology. Two models are defined, one is SR topology model, 389 the other is SR TE topology model, SR topology model is extended 390 from L3 Topology model. SR TE topology model is extended from 391 both SR Topology model and L3 TE topology model. 393 o SF Aware TE Topology YANG Model 395 [I-D. ietf-teas-sf-aware-topo-model] defines a YANG data model 396 for TE network topologies that are network service and function 397 aware. 399 o Optical Transport Topology Models: 401 OTN Transport Topology Model: [I-D.ietf-ccamp-otn-topo- 402 yang]defines a YANG data model to describe the topologies of an 403 Optical Transport Network (OTN). 405 WSON Transport Topology Model: [I-D.ietf-ccamp-wson-yang] 406 defines a YANG data model for the routing and wavelength 407 assignment (RWA) Traffic Engineering (TE) topology in 408 wavelength switched optical networks (WSONs). 410 Flex-Grid Transport Topology Model: [I-D.ietf-ccamp-flexigrid- 411 yang]defines a YANG model for flexi-grid objects in the dynamic 412 optical network, including the nodes, transponders and links 413 between them, as well as how such links interconnect nodes and 414 transponders. 416 Tunnel YANG Models: 418 o TE Tunnel Model 420 [I.D-ietf-teas-yang-te] defines a YANG module for the 421 configuration and management of TE interfaces, tunnels and LSPs. 423 o SR TE Tunnel Model 425 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 426 model(s) and defines a YANG module for Segment Routing (SR) TE 427 specific data. 429 o MPLS TE Model 431 [I.D-ietf-teas-yang-te] augments the TE generic and MPLS-TE 432 model(s) and defines a YANG module for MPLS TE configurations, 433 state, RPC and notifications. 435 o RSVP-TE MPLS Model 437 [I.D-ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module 438 with parameters to configure and manage signaling of MPLS RSVP-TE 439 LSPs. 441 o Optical Transport Tunnel Models: 443 * Flexigrid Media Channel Tunnel Models: [I-D.ccamp-flexigrid- 444 media-channel-yang] defines a YANG model for the flexi-grid 445 media-channel. This YANG module defines the whole path from a 446 source transponder or node to the destination through a number 447 of intermediate nodes in the flexi-grid network. 449 * WSON Tunnel Model: [I-D.ccamp-wson-tunnel-model] defines a YANG 450 data model for WSON tunnel model. 452 * OTN Tunnel Model: [I-D. ietf-ccamp-otn-tunnel-model]defines a 453 YANG data model for OTN tunnel Model. 455 Resource NM Tool Models: 457 o Path Computation API Model 459 [I.D-ietf-teas-path-computation] yang model for a stateless RPC 460 which complements the stateful solution defined in [I.D-ietf-teas- 461 yang-te]. 463 o OAM Models 465 [I.D-ietf-lime-yang-connectionless-oam] defines a base YANG module 466 for the management of OAM protocols that use Connectionless 467 Communications. [I.D-ietf-lime-yang-connectionless-oam-methods] 468 defines a retrieval method YANG module for connectionless OAM 469 protocols. [I.D-ietf-lime-yang-connection-oriented-oam-model] 470 defines a base YANG module for connection oriented OAM protocols. 471 These three models can be used to provide consistent reporting, 472 configuration and representation. 474 o PM Models 476 o Alarm Models 478 Alarm monitoring is a fundamental part of monitoring the network. 479 Raw alarms from devices do not always tell the status of the 480 network services or necessarily point to the root cause. [I.D- 481 ietf-ccamp-alarm-module]defines a YANG module for alarm 482 management. 484 o Generic Policy Model 486 The Simplified Use of Policy Abstractions (SUPA) policy-based 487 management framework [RFC8328] defines base YANG data models to 488 encode policy. These models point to device-, technology-, and 489 service-specific YANG data models developed elsewhere. Policy 490 rules within an operator's environment can be used to express 491 high-level, possibly network-wide, policies to a network 492 management function (within a controller, an orchestrator, or a 493 network element). The network management function can then 494 control the configuration and/or monitoring of network elements 495 and services. This document describes the SUPA basic framework, 496 its elements, and interfaces. 498 3.2. Network Element Models 500 Network Element models are used to describe how a service can be 501 implemented by activating and tweaking a set of functions (enabled in 502 one or multiple devices) that are involved in the service delivery. 504 +----------------+ 505 --|Device Model | 506 | +----------------+ 507 | +------------------+ 508 +---------------+ | |Logical Network | 509 | | --| Element Mode | 510 | Architecture | | +------------------+ 511 | | | +----------------------+ 512 +-------+-------+ --|Network Instance Mode | 513 | | +----------------------+ 514 | | +-------------------+ 515 | --|Routing Type Model | 516 | +-------------------+ 517 +-------+----------+----+------+------------+-----------+-------+ 518 | | | | | | | 519 +-+-+ +---+---+ +--+-+ +-+-+ +-----+---+ +---+-+ | 520 |ACL| |Routing| |MPLS| |OAM| |Multicast| | PM | Others 521 +---+ |-------+ +----+ +---+ +---------+ +-----+ 522 | +-------+ +----------+ +-------+ +-----+ +-----+ 523 --|Core | |MPLS Basic| |BFD | |IGMP | |TWAMP| 524 | |Routing| +----------+ +-------+ |/MLD | +-----+ 525 | +-------+ |MPLS LDP | |LSP Ping +-----+ |OWAMP| 526 --|BGP | +----------+ +-------+ |PIM | +-----+ 527 | +-------+ |MPLS Static |MPLS-TP| +-----+ |LMAP | 528 --|ISIS | +----------+ +-------+ |MVPN | +-----+ 529 | +-------+ +-----+ 530 --|OSPF | 531 | +-------+ 532 --|RIP | 533 | +-------+ 534 --|VRRP | 535 | +-------+ 536 --|ISIS-SR| 537 | +-------+ 538 --|OSPF-SR| 539 | +-------+ 541 3.2.1. Model Composition 543 o Device Model 545 [I.D-ietf-rtgwg-device-model] presents an approach for organizing 546 YANG models in a comprehensive logical structure that may be used 547 to configure and operate network devices.The structure is itself 548 represented as an example YANG model, with all of the related 549 component models logically organized in a way that is 550 operationally intuitive, but this model is not expected to be 551 implemented. 553 o Logical Network Element Model 555 [I.D-ietf-rtgwg-lne-model] defines a logical network element 556 module which can be used to manage the logical resource 557 partitioning that may be present on a network device. Examples of 558 common industry terms for logical resource partitioning are 559 Logical Systems or Logical Routers. 561 o Network Instance Model 563 [I.D-ietf-rtgwg-ni-model] defines a network instance module. This 564 module can be used to manage the virtual resource partitioning 565 that may be present on a network device. Examples of common 566 industry terms for virtual resource partitioning are Virtual 567 Routing and Forwarding (VRF) instances and Virtual Switch 568 Instances (VSIs). 570 3.2.1.1. Schema Mount 572 Modularity and extensibility were among the leading design principles 573 of the YANG data modeling language. As a result, the same YANG 574 module can be combined with various sets of other modules and thus 575 form a data model that is tailored to meet the requirements of a 576 specific use case. [I-D.ietf-netmod-schema-mount] defines a 577 mechanism, denoted schema mount, that allows for mounting one data 578 model consisting of any number of YANG modules at a specified 579 location of another (parent) schema. 581 That capability does not cover design time. 583 3.2.2. Protocol/Function Configuration Models 585 BGP: [I-D.mks-idr-bgp-yang-model] defines a YANG module for 586 configuring and managing BGP, including protocol, policy, 587 and operational aspects based on data center, carrier and 588 content provider operational requirements. 590 MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS 591 which serves as a base framework for configuring and 592 managing an MPLS switching subsystem. It is expected that 593 other MPLS technology YANG models (e.g. MPLS LSP Static, 594 LDP or RSVP-TE models) will augment the MPLS base YANG 595 model. 597 QoS: [I-D.asechoud-netmod-diffserv-model] describes a YANG 598 model of Differentiated Services for configuration and 599 operations. 601 ACL: Access Control List (ACL) is one of the basic elements 602 used to configure device forwarding behavior. It is used 603 in many networking technologies such as Policy Based 604 Routing, Firewalls etc. [I.D-ietf-netmod-acl-model] 605 describes a data model of Access Control List (ACL) basic 606 building blocks. 608 NAT: For the sake of network automation and the need for 609 programming Network Address Translation (NAT) function in 610 particular, a data model for configuring and managing the 611 NAT is essential. [I.D-ietf-opsawg-nat-yang] defines a 612 YANG module for the NAT function. 614 Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used 615 to configure and manage Protocol Independent Multicast 616 (PIM) devices. [I-D.ietf-pim-igmp-mld-yang] defines a 617 YANG module that can be used to configure and manage 618 Internet Group Management Protocol (IGMP) and Multicast 619 Listener Discovery (MLD) devices. 621 Microwave: [I-D. ietf-ccamp-mw-yang] defines a YANG data model for 622 control and management of the radio link interfaces, and 623 their connectivity to packet(typically Ethernet) 624 interfaces in a microwave/millimeter wave node. 626 EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG data model for 627 Ethernet VPN services.The model is agnostic of the 628 underlay. It apply to MPLS as well as to VxLAN 629 encapsulation. The model is also agnostic of the services 630 including E-LAN, E-LINE and E-TREE services. This 631 document mainly focuses on EVPN and Ethernet-Segment 632 instance framework. 634 L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG model that can 635 be used to configure and manage BGP L3VPNs [RFC4364]. It 636 contains VRF sepcific parameters as well as BGP specific 637 parameters applicable for L3VPNs. 639 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG data model for 640 MPLS based Layer 2 VPN services (L2VPN) [RFC4664] and 641 includes switching between the local attachment circuits. 642 The L2VPN model covers point-to-point VPWS and Multipoint 643 VPLS services. These services use signaling of 644 Pseudowires across MPLS networks using LDP 645 [RFC8077][RFC4762] or BGP[RFC4761]. 647 Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG data 648 model for configuring and managing routing policies in a 649 vendor-neutral way and based on actual operational 650 practice. The model provides a generic policy framework 651 which can be augmented with protocol-specific policy 652 configuration. 654 BFD: [I-D.ietf-bfd-yang]defines a YANG data model that can be 655 used to configure and manage Bidirectional Forwarding 656 Detection (BFD) [RFC5880]. BFD is a network protocol 657 which is used for liveness detection of arbitrary paths 658 between systems. 660 4. Architecture Overview 662 The architectural considerations and conclusions described in the 663 previous section lead to the architecture described in this section 664 and illustrated in Figure 2. 666 The interfaces and interactions shown in the figure and labeled (a) 667 through (j) are further described in Section 5.1. 669 +-----------------+ 670 -->|Service Requester| 671 | +-----------------+ 672 +--|------- --|---------------------------------------------------+ 673 | | +--------V---------+ +------------+ | 674 | | | Service Exposure |------------------------ IP Service | | 675 | | +-------(b)--------+ +---->| Mapping | | 676 | | | | +--(c)-|-----+ | 677 | | +--------V---------+ | | | 678 | | | IP Service to TE | | | | 679 | | | Mapping | | | | 680 | | +-------(f)--------+ | +------|-----+ | 681 | | | | | IP Service | | 682 | | +--------V---------+ | | Composition| | 683 | | | TE Path | | +--(d)-|-----+ | 684 | | | Management <---------+ | | | 685 | | +-------(e)--------+ | | | | 686 | | | | | | | 687 | | +--------V---------+ | | +------|------+ | 688 | | | Alarm/PM | | | | IP Service | | 689 | | +-------(g)--------+ | | | Provision | | 690 | | | | | +-(e)---------+ | 691 | | | | | | 692 | | +--------V---------+ +-|-------|--+ | 693 | +-| TE Resource | | Resource | | 694 | | Exposure | | Collection | | 695 | | | |&Abstraction| | 696 | +-------(h)--_-----+ +----(a)-----+ | 697 | | 698 +-----------------------------------------------------------------+ 700 Figure 2: Data Model Driven Management 702 4.1. End-to-End Service Delivery and Service Assurance Procedure 704 4.1.1. Resource Collection and Abstraction (a) 706 Network Resource such as links, nodes, or terminate-point resources 707 can be collected from the network and aggregated or abstracted to the 708 management system. Periodic fetching of data is not an adequate 709 solution for applications requiring frequent or prompt updates of 710 network resource. Applying polling-based solutions to retrieve 711 network resource also imposes a load on networks, devices, and 712 applications.These limitations can be addressed by including generic 713 object subscription mechanisms within network elements. 715 These resources can be modelled using network topology model, L3 716 topology model, L2 topology model, TE topology model, L3 TE topology 717 model, SR TE topology models at different layers. 719 In some cases, there may have multiple overlay topologies built on 720 top of the same underlay topology, and the underlay topology can be 721 also built from one or more lower layer underlay topology. 723 In some cases, there may have multiple overlay topologies built on 724 top of the same underlay topology, and the underlay topology can be 725 also built from one or more lower layer underlay topology. The 726 network resources and management objects in these multi-layer 727 topologies are not recommended to be exposed to customers who (will) 728 order the service from the management system, instead it will be 729 exposed to the management system for IP service mapping and TE path 730 Management. 732 The abstract view is likely to be technology-agnostic. 734 4.1.2. Service Exposure & Abstraction (b) 736 Service exposure & abstraction is used to capture services offered to 737 customers. 739 Service abstraction can be used by a customer to request a service 740 (ordering and order handling). One typical example is that a 741 customer can use L3SM service model to request L3VPN service by 742 providing the abstract technical characterization of the intended 743 service. Such L3VPN service describes various aspects of network 744 infrastructure, including devices and their subsystems, and relevant 745 protocols operating at the link and network layers across multiple 746 device. The L3SM service model can be used to interact with the 747 network infrastructure, e.g., configure sites, decide QoS parameters 748 to be applied to each network access within a site, select PEs, CEs, 749 etc. 751 Service catalogs can be created to expose the various services and 752 the information needed to invoke/order a given service. 754 YANG modules can be grouped into various service bundles; each 755 service bundle is corresponding to a set of YANG modules that have 756 been released or published. Then, a mapping can be established 757 between service abstraction and service bundles at higher layer and 758 between service bundle and a set of YANG modules at lower layer. 760 4.1.3. IP Service Mapping (c) 762 Service abstraction starts with high-level abstractions exposing the 763 business capabilities or capturing customer requirements. Then, it 764 needs to maps them to resource abstraction and specific network 765 technologies. 767 Therefore, the interaction between service abstraction and resource 768 abstraction or between overlay and underlay is required. For 769 example, in the L3SM service model, we describe VPN service topology 770 including sites relationship, e.g., hub and spoke and any to any, 771 single homed, dual-homed, multi-homed relation between PEs and CEs, 772 but we don't know how this service topology can be mapped into 773 underlying network topology. For detailed interaction, please refer 774 to Section 4.1.7 776 In addition, there is a need to decide on a mapping between service 777 abstraction and underlying specific network technologies. Take L3SM 778 service model as an example, to realize L3VPN service, we need to map 779 L3SM service view defined in Service model into detailed 780 configuration view defined by specific configuration models for 781 network elements, these configuration models include: 783 o VRF definition, including VPN Policy expression 785 o Physical Interface 787 o IP layer (IPv4, IPv6). 789 o QoS features such as classification, profiles, etc. 791 o Routing protocols: support of configuration of all protocols 792 listed in the document, as well as routing policies associated 793 with those protocols. 795 o Multicast Support 797 o NAT 799 4.1.4. IP Service Composition (d) 801 These detailed configuration models are further assembled together 802 into service bundle using, e.g., device model, logical network 803 element model or network instance model defined in [I.D-ietf-rtgwg- 804 device-model] [I.D-ietf-rtgwg-lne-model] [I.D-ietf-rtgwg-ni-model] 805 provide the association between an interface and its associated LNE 806 and NI and populate into appropriate devices(e.g., PE and CE). 808 4.1.5. IP Service Provision (e) 810 IP Service Provision is used to provision service or network 811 infrastructure using various configuration models, e.g., use service 812 element models such as BGP, ACL, QoS, Interface model, Network 813 instance models to configure PE and CE device within the site. BGP 814 Policy model is used to establish VPN membership between sites and 815 VPN Service Topology. Traditionally, "push" service element 816 configuration model one by one to the network device and provide 817 association between an interface and each service element 818 configuration model is not efficient. 820 To automate configuration of the service elements, we first assemble 821 all related service elements models into logical network element 822 model defined in [I.D-ietf-rtgwg-lne-model] and then establish 823 association with an interface and a set of service elements. 825 In addition, IP Service Provision can be used to setup tunnels 826 between sites and setup tunnels between PE and CE within the site 827 when tunnels related configuration parameters can be generated from 828 service abstraction.However when tunnels related configuration 829 parameters can not be generated from service abstraction, IP Service 830 to TE Mapping procedure is required. 832 4.1.6. IP Service to TE Mapping (e) 834 In L3SM Service Model, the management system will have to determine 835 where to connect each site-network-access of a particular site to the 836 provider network (e.g., PE, aggregation switch). L3SM Service model 837 proposes parameters and constraints that can influence the meshing of 838 the site-network-access. 840 Nodes used to connect a site may be captured in relevant clauses of a 841 service exposure model (e.g., Customer Nodes Map [RFC7297]). 843 When Site location is determined, PE and CE device location will be 844 selected. Then we can replace parameters and constraints that can 845 influence the meshing of the site-network-access with specified PE 846 and CE device information associated with site- network-access and 847 generate resource facing VN Overlay Resource model.One example of 848 resource facing VN Overlay Resource model is ACTN VN Service Model. 850 This VN Overlay Resource model can be used to calculate node and link 851 resource to Meet service requirements based on Network Topology 852 models collected at step (a). 854 4.1.7. Path Management (f) 856 Path Management includes Path computation and Path setup. For 857 example, we can translate L3SM service model into resource facing VN 858 Overlay Resource Model, with selected PE and CE in each site, we can 859 calculate point to point or multipoint end to end path between sites 860 based on VPN Overlay Resource Model. 862 After identifying node and link resources required to meet service 863 requirements, the mapping between overlay topology and underlay 864 topology can be set, e.g., establish an association between VPN 865 service topology defined in customer facing model and underlying 866 network topology defined in I2RS network topology model (e.g., one 867 overlay node is supported by multiple underlay nodes, one overlay 868 link is supported by multiple underlay nodes)and generate end to end 869 VN topology model. 871 4.1.8. Performance Measurement and Alarm Telemetry (g) 873 Once the mapping between overlay and underlay has been setup, PM and 874 Warning information per link based on end to end VN topology can be 875 collected and report to the management system. 877 Performance metrics can be collected before instantiating a service, 878 too. 880 4.1.9. TE Resource Exposure (h) 882 When tunnels related configuration parameters can not be generated 883 from service abstraction, IP Service to TE Mapping procedure can be 884 used to generate TE Resource Exposure view, this TE reource Exposure 885 view can be modeled as resource facing VN model which is translated 886 and instantiated from L3SM model and manage TE resource based on path 887 management information and PM and alarm telemetry information. 889 Operators may use this dedicated TE resource Exposure view to 890 dynamically capture the overall network status and topology to: 892 o Perform all the requested recovery operations upon detecting 893 network failures affecting the network service. 895 o Adjust resource distribution and update to end to end Service 896 topology models 898 o Provide resource scheduling to better guarantee services for 899 customers and to improve the efficiency of network resource usage. 901 5. Model usage in network virtualization environment: Sample Examples 903 5.1. Network Topology Resource Pre-Provision 905 |(2) 906 | 907 V 908 +-------------------+ 909 | Management System | (3)(4)(5) 910 +-------------------+ 912 +--------------------------------------------------------+ 913 / _[CE2] _[CE3] / 914 / _/ : \_ _/ : \_ / 915 / _/ : \_ _/ : \_ / 916 / _/ : \_ _/ : \_ / 917 / / : \ / : \ / 918 /[CE1]_________________[PE1] [PE2]_________________[CE4] / 919 +---------:--------------:------------:--------------:---+ 920 "Service" 921 -------------------------------------------------------------------- 922 +---------------------+ +---------------------+"Resource" 923 / [Y5]... / / [Z5]______[Z3] / 924 / / \ : / / : \_ / : / 925 / / \ : / / : \_ / : / 926 / / \ : / / : \ / : / 927 / [Y4]____[Y1] : / / : [Z2] : / 928 +------:-------:---:--+ +---:---------:-----:-+ ^ 929 vNet1 : : : : : : vNet2 | 930 : : : : : : |(1) 931 : +-------:---:-----:------------:-----:-----+ | 932 : / [X1]__:___:___________[X2] : / | 933 :/ / \_ : : _____/ / : / | 934 : / \_ : _____/ / : / 935 /: / \: / / : / 936 / : / [X5] / : / 937 / : / __/ \__ / : / 938 / : / ___/ \__ / : / 939 / : / ___/ \ / : / 940 / [X4]__________________[X3]..: / 941 +------------------------------------------+ 942 L3 Topology 944 The following steps are performed to deliver the service within model 945 driven management architecture proposed in this document: 947 o Pre-provision multiple (virtualized) overlay networks on top of 948 the same basic network infrastructure and establish resource pool 949 for each overlay network. 951 o Request to create two sites based on L3SM Service model with each 952 having one network access connectivity: 954 Site A: Network-Access A, Bandwidth=20M, for class "foo", 955 guaranteed-bw-percent = 10, One-Way-Delay=70 msec 957 Site B: Network-Access B, Bandwidth=30M, for class "foo1", 958 guaranteed-bw-percent = 15, One-Way-Delay=60 msec 960 o Select appropriate virtualized overlay networks topology based on 961 Service Type and service requirements defined in L3SM service 962 model. 964 o Translate L3SM service model into resource facing VN Network 965 Model, based on selected virtualized overlay network topology and 966 PE and CE info in the generated resource facing VN network model, 967 calculate node resource, link resource corresponding to 968 connectivity between sites or connectivity between PE and CE 969 within a Site. 971 o Setup tunnels between sites and tunnels between PE and CE within a 972 Site and map them into the selected (virtualized) overlay topology 973 and establish resource facing VN topology model. 975 The source facing VN topology model and corresponding Tunnel model 976 can be used to notify all the parameter changes and event related 977 to VN topology or Tunnel. These information can be further used 978 to adjust network resource distributing in the network. 980 5.2. On Demand Network Topology Resource Creation 981 |(2) 982 | 983 V 984 +-------------------+ 985 | Management System | (3)(4)(5) 986 +-------------------+ 988 +--------------------------------------------------------+ 989 / _[CE2] _[CE3] / 990 / _/ : \_ _/ : \_ / 991 / _/ : \_ _/ : \_ / 992 / _/ : \_ _/ : \_ / 993 / / : \ / : \ / 994 /[CE1]_________________[PE1] [PE2]_________________[CE4] / 995 +---------:--------------:------------:--------------:---+ 996 "Service" 997 -------------------------------------------------------------------- 998 "Resource" ^ 999 : | 1000 : : : |(1) 1001 : +-------:---:-----:------------:-----:-----+ | 1002 : / [X1]__:___ __________[X2] / | 1003 :/ / \_ : _____/ / / | 1004 : / \_ : _____/ / / 1005 /: / \: / / / 1006 / : / [X5] / / 1007 / : / __/ \__ / / 1008 / : / ___/ \__ / / 1009 / : / ___/ \ / / 1010 / [X4]__________________[X3]. / 1011 +------------------------------------------+ 1012 L3 Topology 1014 The following steps are performed to deliver the service within model 1015 driven management architecture proposed in this document: 1017 o Establish resources pool for basic network infrastructure. 1019 o Request to create two sites based on L3SM Service model with each 1020 having one network access connectivity: 1022 Site A: Network-Access A, Bandwidth=20M, for class "foo", 1023 guaranteed-bw-percent = 10, One-Way-Delay=70 msec 1025 Site B: Network-Access B, Bandwidth=30M, for class "foo1", 1026 guaranteed-bw-percent = 15, One-Way-Delay=60 msec 1028 o Create a new service topology based on Service Type and service 1029 requirements (e.g., Slice Service Type, Slice location, Number of 1030 Slices, QoS requirements corresponding to network connectivity 1031 within a Slice) defined in L3SM service model. 1033 o Translate L3SM service model into resource facing VN Network 1034 Model, based on generated resource facing VN network model, 1035 calculate node resource, link resource corresponding to 1036 connectivity between sites or connectivity between PE and CE 1037 within Site in the service topology. 1039 o Setup tunnels between sites and tunnel between PE and CE within 1040 Site and map them into basic network infrastructure and establish 1041 resource facing VN topology model. The source facing VN topology 1042 model and corresponding Tunnel model can be used to notify all the 1043 parameter changes and event related to VN topology or Tunnel. 1044 These information can be further used to adjust network resource 1045 distribution within the network. 1047 6. Security Considerations 1049 Security considerations specific to each of the technologies and 1050 protocols listed in the document are discussed in the specification 1051 documents of each of these techniques. 1053 (Potential) security considerations specific to this document are 1054 listed below: 1056 o Create forwarding loops by mis-configuring the underlying network. 1058 o Leak sensitive information: special care should be considered when 1059 translating between the various layers introduced in the document. 1061 o ...tbc 1063 7. IANA Considerations 1065 There are no IANA requests or assignments included in this document. 1067 8. Informative References 1069 [I-D.arkko-arch-virtualization] 1070 Arkko, J., Tantsura, J., Halpern, J., and B. Varga, 1071 "Considerations on Network Virtualization and Slicing", 1072 draft-arkko-arch-virtualization-01 (work in progress), 1073 March 2018. 1075 [I-D.asechoud-netmod-diffserv-model] 1076 Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N. 1077 Strahle, "YANG Model for Diffserv", draft-asechoud-netmod- 1078 diffserv-model-03 (work in progress), June 2015. 1080 [I-D.chen-opsawg-composite-vpn-dm] 1081 Chen, R., Zhang, L., Hui, D., 67, 4., and C. Xie, "YANG 1082 Data Model for Composite VPN Service Delivery", draft- 1083 chen-opsawg-composite-vpn-dm-00 (work in progress), 1084 October 2016. 1086 [I-D.clacla-netmod-model-catalog] 1087 Clarke, J. and B. Claise, "YANG module for 1088 yangcatalog.org", draft-clacla-netmod-model-catalog-03 1089 (work in progress), April 2018. 1091 [I-D.ietf-bess-evpn-yang] 1092 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 1093 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 1094 bess-evpn-yang-05 (work in progress), February 2018. 1096 [I-D.ietf-bess-l2vpn-yang] 1097 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 1098 and K. Tiruveedhula, "YANG Data Model for MPLS-based 1099 L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress), 1100 February 2018. 1102 [I-D.ietf-bess-l3vpn-yang] 1103 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 1104 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 1105 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-03 (work 1106 in progress), April 2018. 1108 [I-D.ietf-bfd-yang] 1109 Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and 1110 G. Mirsky, "YANG Data Model for Bidirectional Forwarding 1111 Detection (BFD)", draft-ietf-bfd-yang-16 (work in 1112 progress), June 2018. 1114 [I-D.ietf-ccamp-alarm-module] 1115 Vallin, S. and M. Bjorklund, "YANG Alarm Module", draft- 1116 ietf-ccamp-alarm-module-01 (work in progress), February 1117 2018. 1119 [I-D.ietf-ccamp-flexigrid-media-channel-yang] 1120 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1121 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1122 Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid- 1123 media-channel-yang-00 (work in progress), May 2018. 1125 [I-D.ietf-ccamp-flexigrid-yang] 1126 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 1127 King, D., Lee, Y., and G. Galimberti, "YANG data model for 1128 Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid- 1129 yang-00 (work in progress), February 2018. 1131 [I-D.ietf-ccamp-l1csm-yang] 1132 Fioccola, G., Lee, K., Lee, Y., Dhody, D., and D. 1133 Ceccarelli, "A Yang Data Model for L1 Connectivity Service 1134 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-04 (work in 1135 progress), June 2018. 1137 [I-D.ietf-ccamp-mw-yang] 1138 Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M. 1139 Vaupotic, "A YANG Data Model for Microwave Radio Link", 1140 draft-ietf-ccamp-mw-yang-06 (work in progress), June 2018. 1142 [I-D.ietf-ccamp-otn-topo-yang] 1143 zhenghaomian@huawei.com, z., Guo, A., Busi, I., Sharma, 1144 A., Liu, X., Belotti, S., Xu, Y., Wang, L., and O. Dios, 1145 "A YANG Data Model for Optical Transport Network 1146 Topology", draft-ietf-ccamp-otn-topo-yang-03 (work in 1147 progress), June 2018. 1149 [I-D.ietf-ccamp-otn-tunnel-model] 1150 zhenghaomian@huawei.com, z., Guo, A., Busi, I., Sharma, 1151 A., Rao, R., Belotti, S., Lopezalvarez, V., Li, Y., and Y. 1152 Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 1153 model-02 (work in progress), June 2018. 1155 [I-D.ietf-ccamp-wson-tunnel-model] 1156 Lee, Y., Dhody, D., Lopezalvarez, V., King, D., Yoon, B., 1157 and R. Vilata, "A Yang Data Model for WSON Tunnel", draft- 1158 ietf-ccamp-wson-tunnel-model-00 (work in progress), 1159 February 2018. 1161 [I-D.ietf-dots-data-channel] 1162 Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, 1163 P., Mortensen, A., and N. Teague, "Distributed Denial-of- 1164 Service Open Threat Signaling (DOTS) Data Channel 1165 Specification", draft-ietf-dots-data-channel-16 (work in 1166 progress), May 2018. 1168 [I-D.ietf-dots-signal-channel] 1169 Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. 1170 Teague, "Distributed Denial-of-Service Open Threat 1171 Signaling (DOTS) Signal Channel Specification", draft- 1172 ietf-dots-signal-channel-20 (work in progress), May 2018. 1174 [I-D.ietf-i2rs-yang-l3-topology] 1175 Clemm, A., Medved, J., Varga, R., Liu, X., 1176 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1177 for Layer 3 Topologies", draft-ietf-i2rs-yang- 1178 l3-topology-16 (work in progress), December 2017. 1180 [I-D.ietf-i2rs-yang-network-topo] 1181 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1182 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1183 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 1184 progress), December 2017. 1186 [I-D.ietf-l2sm-l2vpn-service-model] 1187 Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data 1188 Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- 1189 service-model-10 (work in progress), April 2018. 1191 [I-D.ietf-lime-yang-connection-oriented-oam-model] 1192 Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model 1193 for Connection Oriented Operations, Administration, and 1194 Maintenance(OAM) protocols", draft-ietf-lime-yang- 1195 connection-oriented-oam-model-07 (work in progress), 1196 February 2018. 1198 [I-D.ietf-lime-yang-connectionless-oam] 1199 Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan, 1200 "Generic YANG Data Model for the Management of Operations, 1201 Administration, and Maintenance (OAM) Protocols that use 1202 Connectionless Communications", draft-ietf-lime-yang- 1203 connectionless-oam-18 (work in progress), November 2017. 1205 [I-D.ietf-lime-yang-connectionless-oam-methods] 1206 Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan, 1207 "Retrieval Methods YANG Data Model for the Management of 1208 Operations, Administration, and Maintenance (OAM) 1209 Protocols that use Connectionless Communications", draft- 1210 ietf-lime-yang-connectionless-oam-methods-13 (work in 1211 progress), November 2017. 1213 [I-D.ietf-mpls-base-yang] 1214 Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 1215 YANG Data Model for MPLS Base", draft-ietf-mpls-base- 1216 yang-06 (work in progress), February 2018. 1218 [I-D.ietf-netmod-acl-model] 1219 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 1220 "Network Access Control List (ACL) YANG Data Model", 1221 draft-ietf-netmod-acl-model-19 (work in progress), April 1222 2018. 1224 [I-D.ietf-netmod-schema-mount] 1225 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 1226 ietf-netmod-schema-mount-10 (work in progress), April 1227 2018. 1229 [I-D.ietf-opsawg-nat-yang] 1230 Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, 1231 S., and Q. Wu, "A YANG Module for Network Address 1232 Translation (NAT) and Network Prefix Translation (NPT)", 1233 draft-ietf-opsawg-nat-yang-14 (work in progress), March 1234 2018. 1236 [I-D.ietf-pim-igmp-mld-yang] 1237 Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 1238 Peter, "A YANG data model for Internet Group Management 1239 Protocol (IGMP) and Multicast Listener Discovery (MLD)", 1240 draft-ietf-pim-igmp-mld-yang-06 (work in progress), 1241 October 2017. 1243 [I-D.ietf-pim-yang] 1244 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1245 Y., and f. hu, "A YANG Data Model for Protocol Independent 1246 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1247 progress), May 2018. 1249 [I-D.ietf-rtgwg-device-model] 1250 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 1251 "Network Device YANG Logical Organization", draft-ietf- 1252 rtgwg-device-model-02 (work in progress), March 2017. 1254 [I-D.ietf-rtgwg-lne-model] 1255 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1256 Liu, "YANG Model for Logical Network Elements", draft- 1257 ietf-rtgwg-lne-model-10 (work in progress), March 2018. 1259 [I-D.ietf-rtgwg-ni-model] 1260 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1261 Liu, "YANG Model for Network Instances", draft-ietf-rtgwg- 1262 ni-model-12 (work in progress), March 2018. 1264 [I-D.ietf-rtgwg-policy-model] 1265 Qu, Y., Tantsura, J., Lindem, A., Liu, X., and A. Shaikh, 1266 "A YANG Data Model for Routing Policy Management", draft- 1267 ietf-rtgwg-policy-model-02 (work in progress), March 2018. 1269 [I-D.ietf-teas-actn-vn-yang] 1270 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., Yoon, B., 1271 Wu, Q., and P. Park, "A Yang Data Model for ACTN VN 1272 Operation", draft-ietf-teas-actn-vn-yang-01 (work in 1273 progress), June 2018. 1275 [I-D.ietf-teas-sf-aware-topo-model] 1276 Bryskin, I. and X. Liu, "SF Aware TE Topology YANG Model", 1277 draft-ietf-teas-sf-aware-topo-model-00 (work in progress), 1278 June 2018. 1280 [I-D.ietf-teas-yang-path-computation] 1281 Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma, 1282 A., Shi, Y., Vilata, R., Sethuraman, K., Scharf, M., and 1283 D. Ceccarelli, "Yang model for requesting Path 1284 Computation", draft-ietf-teas-yang-path-computation-01 1285 (work in progress), March 2018. 1287 [I-D.ietf-teas-yang-rsvp-te] 1288 Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., 1289 and H. Shah, "A YANG Data Model for RSVP-TE", draft-ietf- 1290 teas-yang-rsvp-te-03 (work in progress), February 2018. 1292 [I-D.ietf-teas-yang-te] 1293 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 1294 I. Bryskin, "A YANG Data Model for Traffic Engineering 1295 Tunnels and Interfaces", draft-ietf-teas-yang-te-15 (work 1296 in progress), June 2018. 1298 [I-D.ietf-teas-yang-te-topo] 1299 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1300 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1301 Topologies", draft-ietf-teas-yang-te-topo-17 (work in 1302 progress), June 2018. 1304 [I-D.jeong-i2nsf-consumer-facing-interface-dm] 1305 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, 1306 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 1307 jeong-i2nsf-consumer-facing-interface-dm-05 (work in 1308 progress), November 2017. 1310 [I-D.lee-teas-te-service-mapping-yang] 1311 Lee, Y., Dhody, D., Ceccarelli, D., Tantsura, J., 1312 Fioccola, G., and Q. Wu, "Traffic Engineering and Service 1313 Mapping Yang Model", draft-lee-teas-te-service-mapping- 1314 yang-08 (work in progress), June 2018. 1316 [I-D.liu-teas-yang-l3-te-topo] 1317 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1318 O. Dios, "YANG Data Model for Layer 3 TE Topologies", 1319 draft-liu-teas-yang-l3-te-topo-05 (work in progress), 1320 October 2017. 1322 [I-D.liu-teas-yang-sr-te-topo] 1323 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1324 S. Litkowski, "YANG Data Model for SR and SR TE 1325 Topologies", draft-liu-teas-yang-sr-te-topo-04 (work in 1326 progress), October 2017. 1328 [I-D.mks-idr-bgp-yang-model] 1329 Patel, K., Jethanandani, M., and S. Hares, "BGP YANG 1330 Model", draft-mks-idr-bgp-yang-model-01 (work in 1331 progress), November 2017. 1333 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1334 Networking: A Perspective from within a Service Provider 1335 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1336 . 1338 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1339 Connectivity Provisioning Profile (CPP)", RFC 7297, 1340 DOI 10.17487/RFC7297, July 2014, 1341 . 1343 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1344 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1345 2017, . 1347 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1348 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1349 DOI 10.17487/RFC8299, January 2018, 1350 . 1352 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1353 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1354 . 1356 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus, 1357 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based 1358 Management Framework for the Simplified Use of Policy 1359 Abstractions (SUPA)", RFC 8328, DOI 10.17487/RFC8328, 1360 March 2018, . 1362 Authors' Addresses 1364 Qin Wu 1365 Huawei 1366 101 Software Avenue, Yuhua District 1367 Nanjing, Jiangsu 210012 1368 China 1370 Email: bill.wu@huawei.com 1372 Mohamed Boucadair 1373 Orange 1374 Rennes 35000 1375 France 1377 Email: mohamed.boucadair@orange.com 1379 Young Lee 1380 Huawei 1382 Email: leeyoung@huawei.com