idnits 2.17.1 draft-ietf-teas-te-service-mapping-yang-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 39 instances of too long lines in the document, the longest one being 13 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 (March 5, 2019) is 1871 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: 'RFC7926' is mentioned on line 172, but not defined == Missing Reference: 'RFC8340' is mentioned on line 179, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 196, but not defined == Missing Reference: 'ACTN-VN' is mentioned on line 197, but not defined == Missing Reference: 'RFC8345' is mentioned on line 198, but not defined == Missing Reference: 'L3SM' is mentioned on line 290, but not defined == Missing Reference: 'TE-topo' is mentioned on line 328, but not defined == Missing Reference: 'RFC6536' is mentioned on line 1068, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 1079, but not defined == Missing Reference: 'RFC7950' is mentioned on line 1108, but not defined == Unused Reference: 'RFC4110' is defined on line 1147, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG Young Lee 2 Internet Draft Dhruv Dhody 3 Intended status: standard track Huawei 4 Expires: September 5, 2019 5 Daniele Ceccarelli 6 Ericsson 8 Jeff Tantsura 9 Apstra 11 Giuseppe Fioccola 12 Huawei 14 Qin Wu 15 Huawei 17 March 5, 2019 19 Traffic Engineering and Service Mapping Yang Model 21 draft-ietf-teas-te-service-mapping-yang-01 23 Abstract 25 This document provides a YANG data model to map customer service 26 models (e.g., the L3VPM Service Model) to Traffic Engineering (TE) 27 models (e.g., the TE Tunnel or the Abstraction and Control of 28 Traffic Engineered Networks Virtual Network model). This model is 29 referred to as TE Service Mapping Model and is applicable 30 generically to the operator's need for seamless control and 31 management of their VPN services with TE tunnel support. 33 The model is principally used to allow monitoring and diagnostics of 34 the management systems to show how the service requests are mapped 35 onto underlying network resource and TE models. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with 40 the provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other documents 49 at any time. It is inappropriate to use Internet-Drafts as 50 reference material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet-Draft will expire on September 5, 2019. 60 Copyright Notice 62 Copyright (c) 2019 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with 70 respect to this document. Code Components extracted from this 71 document must include Simplified BSD License text as described in 72 Section 4.e of the Trust Legal Provisions and are provided without 73 warranty as described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction...................................................3 78 1.1. Terminology...............................................4 79 1.2. Tree diagram..............................................4 80 1.3. Prefixes in Data Node Names...............................4 81 2. TE & Service Related Parameters................................5 82 2.1. VN/Tunnel Selection Requirements..........................5 83 2.2. Availability Requirement..................................7 84 3. YANG Modeling Approach.........................................7 85 3.1. Forward Compatibility.....................................8 86 4. L3VPN Architecture in the ACTN Context.........................8 87 4.1. Service Mapping..........................................11 88 4.2. Site Mapping.............................................12 89 5. Applicability of TE-Service Mapping in Generic context........12 90 6. YANG Data Trees...............................................13 91 7. YANG Data Models..............................................14 92 8. Security......................................................24 93 9. IANA Considerations...........................................24 94 10. Acknowledgements.............................................26 95 11. References...................................................26 96 11.1. Informative References..................................26 97 12. Contributors.................................................27 98 Authors' Addresses...............................................27 100 1. Introduction 102 Data models are a representation of objects that can be configured 103 or monitored within a system. Within the IETF, YANG [RFC6020] is the 104 language of choice for documenting data models, and YANG models have 105 been produced to allow configuration or modeling of a variety of 106 network devices, protocol instances, and network services. YANG data 107 models have been classified in [RFC8199] and [RFC8309]. 109 Framework for Abstraction and Control of Traffic Engineered Networks 110 (ACTN) [RFC8453] introduces an architecture to support virtual 111 network services and connectivity services. [ACTN-VN-YANG] defines a 112 YANG model and describes how customers or end-to-end orchestrators 113 can request and/or instantiate a generic virtual network service. 114 [ACTN-Applicability] describes the way IETF YANG models of different 115 classifications can be applied to the ACTN interfaces. In 116 particular, it describes how customer service models can be mapped 117 into the CNC-MDSC Interface (CMI) of the ACTN architecture. 119 The models presented in this document are also applicable in generic 120 context [RFC8309] as part of Customer Service Model used between 121 Service Orchestrator and Customer. 123 [RFC8299] provides a L3VPN service delivery YANG model for PE-based 124 VPNs. The scope of that draft is limited to a set of domains under 125 control of the same network operator to deliver services requiring 126 TE tunnels. 128 [L2SM] provides a L2VPN service delivery YANG model for PE-based 129 VPNs. The scope of that draft is limited to a set of domains under 130 control of the same network operator to deliver services requiring 131 TE tunnels. 133 [L1CSM] provides a L1 connectivity service delivery YANG model for 134 PE-based VPNs. The scope of that draft is limited to a set of 135 domains under control of the same network operator to deliver 136 services requiring TE tunnels. 138 While the IP/MPLS Provisioning Network Controller (PNC) is 139 responsible for provisioning the VPN service on the Provider Edge 140 (PE) nodes, the Multi-Domain Service Coordinator (MDSC) can 141 coordinate how to map the VPN services onto Traffic Engineering (TE) 142 tunnels. This is consistent with the two of the core functions of 143 the MDSC specified in [RFC8453]: 145 . Customer mapping/translation function: This function is to map 146 customer requests/commands into network provisioning requests 147 that can be sent to the PNC according to the business policies 148 that have been provisioned statically or dynamically. 149 Specifically, it provides mapping and translation of a 150 customer's service request into a set of parameters that are 151 specific to a network type and technology such that the network 152 configuration process is made possible. 154 . Virtual service coordination function: This function translates 155 customer service-related information into virtual network 156 service operations in order to seamlessly operate virtual 157 networks while meeting a customer's service requirements. In 158 the context of ACTN, service/virtual service coordination 159 includes a number of service orchestration functions such as 160 multi-destination load balancing, guarantees of service 161 quality, bandwidth and throughput. It also includes 162 notifications for service fault and performance degradation and 163 so forth. 165 Section 2 describes a set of TE & service related parameters that 166 this document addresses as new and advanced parameters that are not 167 included in generic service models. Section 3 discusses YANG 168 modeling approach. 170 1.1. Terminology 172 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 173 in this document. 175 1.2. Tree diagram 177 A simplified graphical representation of the data model is used in 178 Section 5 of this this document. The meaning of the symbols in 179 these diagrams is defined in [RFC8340]. 181 1.3. Prefixes in Data Node Names 183 In this document, names of data nodes and other data model objects 184 are prefixed using the standard prefix associated with the 185 corresponding YANG imported modules, as shown in Table 1. 187 +---------+------------------------------+-----------------+ 188 | Prefix | YANG module | Reference | 189 +---------+------------------------------+-----------------+ 190 |tsm-types| ietf-te-service-mapping-types| [RFCXXXX} | 191 |l1 | ietf-l1csm | [L1CSM] | 192 |l2vpn-svc| ietf-l2vpn-svc | [L2SM] | 193 |l3vpn-svc| ietf-l3vpn-svc | [RFC8299] | 194 |l1-tsm | ietf-l1csm-te-service-mapping| [RFCXXXX] | 195 |l2-tsm | ietf-l2sm-te-service-mapping | [RFCXXXX] | 196 |l3-tsm | ietf-l3sm-te-service-mapping | [RFCXXXX] | 197 |vn | ietf-vn | [ACTN-VN] | 198 |nw | ietf-network | [RFC8345] | 199 |te-types | ietf-te-types | [TE-Types] | 200 |te-topo | ietf-te-topology | [TE-Topo] | 201 |te | ietf-te | [TE-Tunnel] | 202 +---------+------------------------------+-----------------+ 204 Table 1: Prefixes and corresponding YANG modules 206 Note: The RFC Editor will replace XXXX with the number assigned to 207 the RFC once this draft becomes an RFC. 209 2. TE & Service Related Parameters 211 While L1/2/3 service models [L1CSM, L2SM, L3SM] are intended to 212 provide service-specific parameters for VPN service instances, there 213 are a number of TE & Service related parameters that are not 214 included in the generic service models. 216 Additional service parameters and policies that are not included in 217 the aforementioned service models are addressed in the YANG models 218 defined in this document. 220 2.1. VN/Tunnel Selection Requirements 222 In some cases, the service requirements may need addition TE tunnels 223 to be established. This may occur when there are no suitable 224 existing TE tunnels that can support the service requirements, or 225 when the operator would like to dynamically create and bind tunnels 226 to the VPN such that they are not shared by other VPNs, for example, 227 for network slicing. The establishment of TE tunnels is subject to 228 the network operator's policies. 230 To summarize, there are three modes of VN/Tunnel selection 231 operations to be supported as follows. Additional modes may be 232 defined in the future. 234 o New VN/Tunnel Binding - A customer could request a VPN 235 service based on VN/Tunnels that are not shared with other 236 existing or future services. This might be to meet VPN 237 isolation requirements. Further, the YANG model described in 238 Section 5 of this document can be used to describe the 239 mapping between the VPN service and the ACTN VN. The VN (and 240 TE tunnels) could be bound to the VPN and not used for any 241 other VPN. 243 Under this mode, the following sub-categories can be 244 supported: 246 1. Hard Isolation with deterministic characteristics: A 247 customer could request a VPN service using a set of TE 248 Tunnels with deterministic characteristics requirements 249 (e.g., no latency variation) and where that set of TE 250 Tunnels must not be shared with other VPN services and 251 must not compete for bandwidth or other network resources 252 with other TE Tunnels. 254 2. Hard Isolation: This is similar to the above case but 255 without the deterministic characteristics requirements. 257 3. Soft Isolation: The customer requests a VPN service using 258 a set of TE tunnels which can be shared with other VPN 259 services. 261 o VN/Tunnel Sharing - A customer could request a VPN service 262 where new tunnels (or a VN) do not need to be created for 263 each VPN and can be shared across multiple VPNs. Further, the 264 mapping YANG model described in Section 5 of this document 265 can be used to describe the mapping between the VPN service 266 and the tunnels in use. No modification of the properties of 267 a tunnel (or VN) is allowed in this mode: an existing tunnel 268 can only be selected. 270 o VN/Tunnel Modify - This mode allows the modification of the 271 properties of the existing VN/tunnel (e.g., bandwidth). 273 2.2. Availability Requirement 275 Availability is another service requirement or intent that may 276 influence the selection or provisioning of TE tunnels or a VN to 277 support the requested service. Availability is a probabilistic 278 measure of the length of time that a VPN/VN instance functions 279 without a network failure. 281 The availability level will need to be translated into network 282 specific policies such as the protection/reroute policy associated 283 with a VN or Tunnel. The means by which this is achieved is not in 284 the scope of this draft. 286 3. YANG Modeling Approach 288 This section provides how the TE & Service mapping parameters are 289 supported using augmentation of the existing service models (i.e., 290 [L1CSM], [L2SM], and [L3SM]). Figure 1 shows the scope of the 291 Augmented LxSM Model. 293 +--------------+ +----------------------------+ +----------+ 294 | LxSM |o-------| | . . . . . | ACTN VN | 295 +--------------+ augment| | +----------+ 296 | | +----------+ 297 +--------------+ | Augmented LxSM Model | . . . . . | TE-topo | 298 | TE & Service |------->| | +----------+ 299 | Mapping Types| import | | +----------+ 300 +--------------+ | | . . . . . | TE-tunnel| 301 +----------------------------+ reference +----------+ 303 Figure 1. Augmented LxSM Model 305 The Augmented LxSM model (where x=1,2,3) augments the basic LxSM 306 model while importing the common TE & Service related parameters 307 (defined in Section 2) grouping information from TE & Service 308 Mapping Types. The TE & Service Mapping Types (ietf-te-service- 309 mapping-types) module is the repository of all common groupings 310 imported by each augmented LxSM model. Any future service models 311 would import this grouping file. 313 The role of the augmented LxSm service model is to expose the 314 mapping relationship between service models and TE models so that 315 VN/VPN service instantiations provided by the underlying TE networks 316 can be viewed outside of the MDSC, for example by an operator who is 317 diagnosing the behavior of the network. It also allows for the 318 customers to access operational state information about how their 319 services are instantiated with the underlying VN, TE topology or TE 320 tunnels provided that the MDSC operator is willing to share that 321 information. This mapping will facilitate a seamless service 322 management operation with underlay-TE network visibility. 324 As seen in Figure 1, the augmented LxSM service model records a 325 mapping between the customer service models and the ACTN VN YANG 326 model. Thus, when the MDSC receives a service request it creates a 327 VN that meets the customer's service objectives with various 328 constraints via TE-topology model [TE-topo], and this relationship 329 is recorded by the Augmented LxSM Model. The model also supports a 330 mapping between a service model and TE-topology or a TE-tunnel. 332 3.1. Forward Compatibility 334 The YANG module defined in this document supports three existing 335 service models via augmenting while sharing the common TE & Service 336 Mapping Types. 338 It is possible that new service models will be defined at some 339 future time and that it will be desirable to map them to underlying 340 TE constructs in the same way as the three existing models are 341 augmented. 343 4. L3VPN Architecture in the ACTN Context 345 Figure 2 shows the architectural context of this document 346 referencing the ACTN components and interfaces. 348 +----------------------------+ 349 | Customer Service Manager | 350 | +-----------------------+ | 351 | | CNC + | 352 | +-+-------------------+-+ | 353 +----|-------------------|---+ 354 | | 355 |CMI(Augmented L3SM)|CMI(VN) 356 | | 357 +----------------|-------------------|----+ 358 | +--------------|-----------------+ | | 359 | | MDSC | | | | 360 | | | | | | 361 | | +-----------+--------------+ | | | 362 TE-Svc-Map<------+ Service Mapping Function | | | | 363 | | +-----------+--------------+ | | | 364 | | | | | | 365 | +-------+------|-----------------+ | | 366 | | | | | 367 | | |CMI(VN) | | 368 | | | | | 369 | | +--|-------------------|--+ | 370 | | | | MDSC | | | 371 | | | ++-------------------++ | | 372 | | | + Service Mapping +---->TE-Svc-Map 373 | | | ++----------+---------+ | | 374 | | +--|----------|-----------+ | 375 +---------|------|----------|-------------+ 376 | | | 377 | +----+--------+ | 378 | | | | 379 MPI(VPN / TE models)| | | |MPI(TE / L1 models) 380 | | | | 381 +-----|-|---+ +-----|-|----+ 382 IP/MPLS | +--+-+-+ | | +--+-+-+ | Optical Domain 383 Domain | | PNC1 | | | | PNC2 | | Controller 384 Controller | +--+---+ | | +--+---+ | 385 +-----|-----+ +-----|------+ 386 | | 387 V | SBI 388 +---------------------+ | 389 / IP/MPLS Network \ | 390 +-------------------------+ | 391 V 392 +---------------------+ 393 / Optical Network \ 394 +-------------------------+ 396 Figure 2: L3VPN Architecture from the IP+Optical Network Perspective 398 There are three main entities in the ACTN architecture and shown in 399 Figure 2. 401 . CNC: The Customer Network Controller is responsible for generating 402 service requests. In the context of an L3VPN, the CNC uses the 403 Augmented L3SM to express the service request and communicate it 404 to the network operator. 406 . MDSC: This entity is responsible for coordinating a L3VPN service 407 request (expressed via the Augmented L3SM) with the IP/MPLS PNC 408 and the Transport PNC. For TE services, one of the key 409 responsibilities of the MDSC is to coordinate with both the IP PNC 410 and the Transport PNC for the mapping of the Augmented L3VPN 411 Service Model to the ACTN VN model. In the VN/TE-tunnel binding 412 case, the MDSC will need to coordinate with the Transport PNC to 413 dynamically create the TE-tunnels in the transport network as 414 needed. These tunnels are added as links in the IP/MPLS Layer 415 topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 416 tunnels in the IP/MPLS layer, as part of the ACTN VN creation. 417 . PNC: The Provisioning Network Controller is responsible for 418 configuring and operating the network devices. Figure 2 shows two 419 distinct PNCs. 420 o IP/MPLS PNC (PNC1): This entity is responsible for device 421 configuration to create PE-PE L3VPN tunnels for the VPN 422 customer and for the configuration of the L3VPN VRF on the PE 423 nodes. Each network element would select a tunnel based on 424 the configuration. 425 o Transport PNC (PNC2): This entity is responsible for device 426 configuration for TE tunnels in the transport networks. 428 There are four main interfaces shown in Figure 2. 430 . CMI: The CNC-MDSC Interface is used to communicate service 431 requests from the customer to the operator. The requests may be 432 expressed as Augmented VPN service requests (L2SM, L3SM), as 433 connectivity requests (L1CSM), or as virtual network requests 434 (ACTN VN). 435 . MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate 436 networks under the control of PNCs. The requests on this interface 437 may use TE tunnel models, TE topology models, VPN network 438 configuration models or layer one connectivity models. 439 . SBI: The Southbound Interface is used by the PNC to control 440 network devices and is out of scope for this document. 441 . The TE Service Mapping Model as described in this document can be 442 used to see the mapping between service models and VN models and 443 TE Tunnel/Topology models. That mapping may occur in the CNC if a 444 service request is mapped to a VN request. Or it may occur in the 445 MDSC where a service request is mapped to a TE tunnel, TE 446 topology, or VPN network configuration model. The TE Service 447 Mapping Model may be read from the CNC or MDSC to understand how 448 the mapping has been made and to see the purpose for which network 449 resources are used. 451 As shown in Figure 2, the MDSC may be used recursively. For example, 452 the CNC might map a L3SM request to a VN request that it sends to a 453 recursive MDSC. 455 The high-level control flows for one example are as follows: 457 1. A customer asks for an L3VPN between CE1 and CE2 using the 458 Augmented L3SM model. 460 2. The MDSC considers the service request and local policy to 461 determine if it needs to create a new VN or any TE Topology, and 462 if that is the case, ACTN VN YANG [ACTN-VN-YANG] is used to 463 configure a new VN based on this VPN and map the VPN service to 464 the ACTN VN. In case an existing tunnel is to be used, each device 465 will select which tunnel to use and populate this mapping 466 information. 468 3. The MDSC interacts with both the IP/MPLS PNC and the Transport PNC 469 to create a PE-PE tunnel in the IP network mapped to a TE tunnel 470 in the transport network by providing the inter-layer access 471 points and tunnel requirements. The specific service information 472 is passed to the IP/MPLS PNC for the actual VPN configuration and 473 activation. 475 a. The Transport PNC creates the corresponding TE tunnel 476 matching with the access point and egress point. 477 b. The IP/MPLS PNC maps the VPN ID with the corresponding TE 478 tunnel ID to bind these two IDs. 480 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 481 customer. This is not in the scope of this document. 483 4.1. Service Mapping 485 Augmented L3SM and L2SM can be used to request VPN service creation 486 including the creation of sites and corresponding site network 487 access connection between CE and PE. A VPN-ID is used to identify 488 each VPN service ordered by the customer. The ACTN VN can be used 489 further to establish PE-to-PE connectivity between VPN sites 490 belonging to the same VPN service. A VN-ID is used to identify each 491 virtual network established between VPN sites. 493 Once the ACTN VN has been established over the TE network (maybe a 494 new VN, maybe modification of an existing VN, or maybe the use of an 495 unmodified existing VN), the mapping between the VPN service and the 496 ACTN VN service can be created. 498 4.2. Site Mapping 500 The elements in Augmented L3SM and L2SM define site location 501 parameters and constraints such as distance and access diversity 502 that can influence the placement of network attachment points (i.e, 503 virtual network access points (VNAP)). To achieve this, a central 504 directory can be set up to establish the mapping between location 505 parameters and constraints and network attachment point location. 506 Suppose multiple attachment points are matched, the management 507 system can use constraints or other local policy to select the best 508 candidate network attachment points. 510 After a network attachment point is selected, the mapping between 511 VPN site and VNAP can be established as shown in Table 1. 513 +------+---------+------------------+----------------------+-------+ 514 | | | Location | Access Diversity | PE | 515 | | Site | | | | 516 |Site | Network | (Address, Postal | (Constraint-Type, | | 517 | | Access | Code, State, | Group-id,Target | | 518 | | | City,Country | Group-id) | | 519 | | | Code) | | | 520 +------+---------+------------------+----------------------+-------+ 521 | | | | | | 522 |SITE1 | ACCESS1 | (,,US,NewYork,) |(10,PE-Diverse,10) | PE1 | 523 +------+---------+------------------+----------------------+-------+ 524 |SITE2 | ACCESS2 | (,,CN,Beijing,) |(10,PE-Diverse,10) | PE2 | 525 +------+---------+------------------+----------------------+-------+ 526 |SITE3 | ACCESS3 | (,,UK,London, ) |(12,same-PE,12) | PE4 | 527 +------+---------+------------------+----------------------+-------+ 528 |SITE4 | ACCESS4 | (,,FR,Paris,) |(20,Bearer-Diverse,20)| PE7 | 529 +------+---------+------------------+----------------------+-------+ 531 Table 1 : Mapping Between VPN Site and VNAP 533 5. Applicability of TE-Service Mapping in Generic context 535 As discussed in the Introduction Section, the models presented in 536 this document are also applicable generically outside of the ACTN 537 architecture. [RFC8309] defines Customer Service Model between 538 Customer and Service Orchestrator and Service Delivery Model between 539 Service Orchestrator and Network Orchestrator(s). TE-Service mapping 540 models defined in this document can be regarded primarily as 541 Customer Service Model and secondarily as Service Deliver Model. 543 6. YANG Data Trees 545 module: ietf-l1csm-te-service-mapping 546 augment /l1:l1-connectivity/l1:services/l1:service: 547 +-rw te-service-mapping! 548 augment /l1:l1-connectivity/l1:services/l1:service: 549 +-rw te-mapping 550 +-rw map-type? identityref 551 +-rw availability-type? identityref 552 +-rw (te)? 553 +-:(actn-vn) 554 | +-rw actn-vn-ref? -> /vn:vn/vn-list/vn-id 555 +-:(te-topo) 556 | +-rw vn-topology-id? te-types:te-topology-id 557 | +-rw abstract-node? -> /nw:networks/network/node/node-id 558 +-:(te-tunnel) 559 +-rw te-tunnel-list* te:tunnel-ref 560 augment /l1:l1-connectivity/l1:services/l1:service/l1:endpoint-1: 561 +-rw (te)? 562 +-:(actn-vn) 563 | +-rw actn-vn-ref? -> /vn:ap/access-point-list/access-point-id 564 +-:(te) 565 +-rw ltp? te-types:te-tp-id 566 augment /l1:l1-connectivity/l1:services/l1:service/l1:endpoint-2: 567 +-rw (te)? 568 +-:(actn-vn) 569 | +-rw actn-vn-ref? -> /vn:ap/access-point-list/access-point-id 570 +-:(te) 571 +-rw ltp? te-types:te-tp-id 573 module: ietf-l2sm-te-service-mapping 574 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service: 575 +-rw te-service-mapping! 576 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service: 577 +-rw te-mapping 578 +-rw map-type? identityref 579 +-rw availability-type? identityref 580 +-rw (te)? 581 +-:(actn-vn) 582 | +-rw actn-vn-ref? -> /vn:vn/vn-list/vn-id 583 +-:(te-topo) 584 | +-rw vn-topology-id? te-types:te-topology-id 585 | +-rw abstract-node? -> /nw:networks/network/node/node-id 586 +-:(te-tunnel) 587 +-rw te-tunnel-list* te:tunnel-ref 588 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site/l2vpn-svc:site-network- 589 accesses/l2vpn-svc:site-network-access: 591 +-rw (te)? 592 +-:(actn-vn) 593 | +-rw actn-vn-ref? -> /vn:ap/access-point-list/access-point-id 594 +-:(te) 595 +-rw ltp? te-types:te-tp-id 597 module: ietf-l3sm-te-service-mapping 598 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service: 599 +-rw te-service-mapping! 600 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service: 601 +-rw te-mapping 602 +-rw map-type? identityref 603 +-rw availability-type? identityref 604 +-rw (te)? 605 +-:(actn-vn) 606 | +-rw actn-vn-ref? -> /vn:vn/vn-list/vn-id 607 +-:(te-topo) 608 | +-rw vn-topology-id? te-types:te-topology-id 609 | +-rw abstract-node? -> /nw:networks/network/node/node-id 610 +-:(te-tunnel) 611 +-rw te-tunnel-list* te:tunnel-ref 612 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site- 613 network-accesses/l3vpn-svc:site-network-access: 614 +-rw (te)? 615 +-:(actn-vn) 616 | +-rw actn-vn-ref? -> /vn:ap/access-point-list/access-point-id 617 +-:(te) 618 +-rw ltp? te-types:te-tp-id 620 7. YANG Data Models 622 The YANG codes are as follows: 624 file "ietf-te-service-mapping-types@2019-03-05.yang" 626 module ietf-te-service-mapping-types { 628 namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; 630 prefix "tsm"; 632 import ietf-te-types { 633 prefix "te-types"; 634 } 636 import ietf-network { 637 prefix "nw"; 638 } 639 import ietf-te { 640 prefix "te"; 641 } 643 import ietf-vn { 644 prefix "vn"; 645 } 647 organization 648 "IETF Traffic Engineering Architecture and Signaling (TEAS) 649 Working Group"; 651 contact 652 "Editor: Young Lee 653 Dhruv Dhody 654 Qin Wu "; 655 description 656 "This module contains a YANG module for TE & Service mapping 657 parameters and policies as a common grouping applicable to 658 variuous service models (e.g., L1CSM, L2SM, L3SM, etc.)"; 660 revision 2019-03-05 { 661 description 662 "initial version."; 663 reference 664 "TBD"; 665 } 667 /* 668 * Identity for map-type 669 */ 670 identity map-type { 671 description 672 "Base identity from which specific map types are 673 derived."; 674 } 676 identity new { 677 base map-type; 678 description 679 "The new VN/tunnels are binded to the service."; 680 } 682 identity detnet-hard-isolation { 683 base new; 684 description 685 "Hard isolation with deterministic characteristics."; 687 } 689 identity hard-isolation { 690 base new; 691 description 692 "Hard isolation."; 693 } 695 identity soft-isolation { 696 base new; 697 description 698 "Soft-isolation."; 699 } 701 identity select { 702 base map-type; 703 description 704 "The VPN service selects an existing tunnel with no 705 modification."; 706 } 708 identity modify { 709 base map-type; 710 description 711 "The VPN service selects an existing tunnel and allows 712 to modify the properties of the tunnel (e.g., b/w)"; 713 } 715 /* 716 * Identity for availability-type 717 */ 718 identity availability-type { 719 description 720 "Base identity from which specific map types are 721 derived."; 722 } 724 identity level-1 { 725 base availability-type; 726 description 727 "level 1: 99.9999%"; 728 } 730 identity level-2 { 731 base availability-type; 732 description 733 "level 2: 99.999%"; 734 } 735 identity level-3 { 736 base availability-type; 737 description 738 "level 3: 99.99%"; 739 } 741 identity level-4 { 742 base availability-type; 743 description 744 "level 4: 99.9%"; 745 } 747 identity level-5 { 748 base availability-type; 749 description 750 "level 5: 99%"; 751 } 753 /* 754 * Groupings 755 */ 757 grouping te-ref { 758 description 759 "The reference to TE."; 760 choice te { 761 description 762 "The TE"; 763 case actn-vn { 764 leaf actn-vn-ref { 765 type leafref { 766 path "/vn:vn/vn:vn-list/vn:vn-id"; 767 } 768 description 769 "The reference to ACTN VN"; 770 } 771 } 772 case te-topo { 773 leaf vn-topology-id{ 774 type te-types:te-topology-id; 775 description 776 "An identifier to the TE Topology Model 777 where the abstract nodes and links of 778 the Topology can be found for Type 2 779 VNS"; 780 } 781 leaf abstract-node { 782 type leafref { 783 path "/nw:networks/nw:network/nw:node/" 784 + "nw:node-id"; 785 } 786 description 787 "a reference to the abstract node in TE 788 Topology"; 789 } 790 } 791 case te-tunnel { 792 leaf-list te-tunnel-list { 793 type te:tunnel-ref; 794 description 795 "Reference to TE Tunnels"; 796 } 798 } 800 } 802 } 804 grouping te-endpoint-ref { 805 description 806 "The reference to TE endpoints."; 807 choice te { 808 description 809 "The TE"; 810 case actn-vn { 811 leaf actn-vn-ref { 812 type leafref { 813 path "/vn:ap/vn:access-point-list" 814 + "/vn:access-point-id"; 815 } 816 description 817 "The reference to ACTN VN"; 818 } 819 } 820 case te { 821 leaf ltp { 822 type te-types:te-tp-id; 823 description 824 "Reference LTP in the TE-topology"; 825 } 826 } 827 } 829 } 831 grouping te-mapping { 832 description 833 "Mapping between Services and TE"; 834 container te-mapping { 835 description 836 "Mapping between Services and TE"; 837 leaf map-type { 838 type identityref { 839 base map-type; 840 } 841 description 842 "Isolation Requirements, Tunnel Bind or 843 Tunnel Selection"; 844 } 845 leaf availability-type { 846 type identityref { 847 base availability-type; 848 } 849 description 850 "Availability Requirement for the Service"; 851 } 852 uses te-ref; 853 } 854 } 856 } 857 859 file "ietf-l1csm-te-service-mapping@2019-03-05.yang" 861 module ietf-l1csm-te-service-mapping { 863 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; 865 prefix "tm"; 867 import ietf-te-service-mapping-types { 868 prefix "tsm-types"; 869 } 871 import ietf-l1csm { 872 prefix "l1"; 873 } 875 organization 876 "IETF Traffic Engineering Architecture and Signaling (TEAS) 877 Working Group"; 879 contact 880 "Editor: Young Lee 881 Dhruv Dhody 882 Qin Wu "; 883 description 884 "This module contains a YANG module for the mapping of 885 Layer 1 Connectivity Service Module (L1CSM) to the TE and VN "; 887 revision 2019-03-05 { 888 description 889 "initial version."; 890 reference 891 "TBD"; 892 } 894 /* 895 * Configuration data nodes 896 */ 897 augment "/l1:l1-connectivity/l1:services/l1:service" { 898 description 899 "l1csm augmented to include TE parameters and mapping"; 900 container te-service-mapping { 901 presence "indicates l1 service to te mapping"; 902 description 903 "Container to augment l1csm to TE parameters and mapping"; 904 } 905 } 907 augment "/l1:l1-connectivity/l1:services/l1:service" { 908 description 909 "This augment is only valid for TE mapping -- 910 te mapping is added"; 911 uses tsm-types:te-mapping; 912 } 914 augment "/l1:l1-connectivity/l1:services/l1:service/l1:endpoint-1" { 915 description 916 "This augment is only valid for TE mapping -- 917 endpoint-1 te-reference is added"; 918 uses tsm-types:te-endpoint-ref; 919 } 921 augment "/l1:l1-connectivity/l1:services/l1:service/l1:endpoint-2" { 922 description 923 "This augment is only valid for TE mapping -- 924 endpoint-2 te-reference is added"; 925 uses tsm-types:te-endpoint-ref; 926 } 927 } 929 931 file "ietf-l2sm-te-service-mapping@2019-03-05.yang" 933 module ietf-l2sm-te-service-mapping { 935 namespace "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; 937 prefix "tm"; 939 import ietf-te-service-mapping-types { 940 prefix "tsm-types"; 941 } 943 import ietf-l2vpn-svc { 944 prefix "l2vpn-svc"; 945 } 947 organization 948 "IETF Traffic Engineering Architecture and Signaling (TEAS) 949 Working Group"; 951 contact 952 "Editor: Young Lee 953 Dhruv Dhody 954 Qin Wu "; 955 description 956 "This module contains a YANG module for the mapping of 957 Layer 2 Service Model (L1CSM) to the TE and VN "; 959 revision 2019-03-05 { 960 description 961 "initial version."; 962 reference 963 "TBD"; 964 } 966 /* 967 * Configuration data nodes 968 */ 969 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service" { 970 description 971 "l2sm augmented to include TE parameters and mapping"; 972 container te-service-mapping { 973 presence "indicates l2 service to te mapping"; 974 description 975 "Container to augment l2sm to TE parameters and mapping"; 976 } 977 } 979 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service" { 980 description 981 "This augment is only valid for TE mapping -- 982 te mapping is added"; 983 uses tsm-types:te-mapping; 984 } 986 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 987 +"/l2vpn-svc:site-network-accesses/l2vpn-svc:site-network-access" { 988 description 989 "This augment is only valid for TE mapping -- 990 network-access te-reference is added"; 991 uses tsm-types:te-endpoint-ref; 992 } 993 } 995 997 file "ietf-l3sm-te-service-mapping@2019-03-05.yang" 999 module ietf-l3sm-te-service-mapping { 1001 namespace "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; 1003 prefix "tm"; 1005 import ietf-te-service-mapping-types { 1006 prefix "tsm-types"; 1007 } 1009 import ietf-l3vpn-svc { 1010 prefix "l3vpn-svc"; 1011 } 1012 organization 1013 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1014 Working Group"; 1016 contact 1017 "Editor: Young Lee 1018 Dhruv Dhody 1019 Qin Wu "; 1020 description 1021 "This module contains a YANG module for the mapping of 1022 Layer 3 Service Model (L3SM) to the TE and VN "; 1024 revision 2019-03-05 { 1025 description 1026 "initial version."; 1027 reference 1028 "TBD"; 1029 } 1031 /* 1032 * Configuration data nodes 1033 */ 1034 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service" { 1035 description 1036 "l3sm augmented to include TE parameters and mapping"; 1037 container te-service-mapping { 1038 presence "indicates l3 service to te mapping"; 1039 description 1040 "Container to augment l3sm to TE parameters and mapping"; 1041 } 1042 } 1044 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service" { 1045 description 1046 "This augment is only valid for TE mapping -- 1047 te mapping is added"; 1048 uses tsm-types:te-mapping; 1049 } 1051 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1052 +"/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access" { 1053 description 1054 "This augment is only valid for TE mapping -- 1055 network-access te-reference is added"; 1056 uses tsm-types:te-endpoint-ref; 1057 } 1059 } 1061 1063 8. Security 1065 The configuration, state, and action data defined in this document 1066 are designed to be accessed via a management protocol with a secure 1067 transport layer, such as NETCONF [RFC6241]. The NETCONF access 1068 control model [RFC6536] provides the means to restrict access for 1069 particular NETCONF users to a preconfigured subset of all available 1070 NETCONF protocol operations and content. 1072 A number of configuration data nodes defined in this document are 1073 writable/deletable (i.e., "config true") These data nodes may be 1074 considered sensitive or vulnerable in some network environments. 1076 9. IANA Considerations 1078 This document registers the following namespace URIs in the IETF XML 1079 registry [RFC3688]: 1081 -------------------------------------------------------------------- 1082 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1083 Registrant Contact: The IESG. 1084 XML: N/A, the requested URI is an XML namespace. 1085 -------------------------------------------------------------------- 1087 -------------------------------------------------------------------- 1088 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 1089 Registrant Contact: The IESG. 1090 XML: N/A, the requested URI is an XML namespace. 1091 -------------------------------------------------------------------- 1093 -------------------------------------------------------------------- 1094 URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 1095 Registrant Contact: The IESG. 1096 XML: N/A, the requested URI is an XML namespace. 1097 -------------------------------------------------------------------- 1099 -------------------------------------------------------------------- 1100 URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 1101 Registrant Contact: The IESG. 1102 XML: N/A, the requested URI is an XML namespace. 1103 -------------------------------------------------------------------- 1105 This document registers the following YANG modules in the YANG 1106 Module. 1108 Names registry [RFC7950]: 1110 -------------------------------------------------------------------- 1111 name: ietf-te-service-mapping-types 1112 namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping- 1113 types 1114 reference: RFC XXXX (TDB) 1115 -------------------------------------------------------------------- 1117 -------------------------------------------------------------------- 1118 name: ietf-l1csm-te-service-mapping 1119 namespace: urn:ietf:params:xml:ns:yang:ietf-l1cms-te-service- 1120 mapping 1121 reference: RFC XXXX (TDB) 1122 -------------------------------------------------------------------- 1124 -------------------------------------------------------------------- 1125 name: ietf-l2sm-te-service-mapping 1126 namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service- 1127 mapping 1128 reference: RFC XXXX (TDB) 1129 -------------------------------------------------------------------- 1131 -------------------------------------------------------------------- 1132 name: ietf-l3sm-te-service-mapping 1133 namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service- 1134 mapping 1135 reference: RFC XXXX (TDB) 1136 -------------------------------------------------------------------- 1138 10. Acknowledgements 1140 We thank Diego Caviglia and Igor Bryskin for useful discussions and 1141 motivation for this work. 1143 11. References 1145 11.1. Informative References 1147 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 1148 Provider-Provisioned Virtual Private Networks (PPVPNs)", 1149 RFC 4110, July 2005. 1151 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for 1152 the Network Configuration Protocol (NETCONF)", RFC 6020, 1153 October 2010. 1155 [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", 1156 RFC 8309, January 2018. 1158 [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module 1159 Classification", RFC 8199, July 2017. 1161 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1162 and A. Bierman, Ed., "Network Configuration Protocol 1163 (NETCONF)", RFC 6241. 1165 [RFC8453] D. Cecarelli and Y. Lee, "Framework for Abstraction and 1166 Control of Traffic Engineered Networks", RFC 8453, August 1167 2018. 1169 [TE-Topo] X. Liu, et. al., "YANG Data Model for TE Topologies", 1170 draft-ietf-teas-yang-te-topo, work in progress. 1172 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 1173 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1174 te, work in progress. 1176 [TE-Types] T. Saad (Editor), "Traffic Engineering Common YANG 1177 Types", draft-ietf-teas-yang-te-types, work in progress. 1179 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 1180 Operation", draft-lee-teas-actn-vn-yang, work in progress. 1182 [ACTN-Applicability] Y. Lee, et al, "Applicability of YANG models 1183 for Abstraction and Control of Traffic Engineered 1184 Networks, draft-ietf-teas-actn-yang, work in progress. 1186 [RFC8299] Q. Wu, S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data 1187 Model for L3VPN service delivery", RFC 8299, January 2018. 1189 [L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service 1190 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 1191 progress. 1193 [L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity 1194 Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work 1195 in progress. 1197 12. Contributors 1199 Adrian Farrel 1200 Old Dog Consulting 1202 Email: adrian@olddog.co.uk 1204 Italo Busi 1205 Huawei Technologies 1207 Email: Italo.Busi@huawei.com 1209 Authors' Addresses 1211 Young Lee 1212 Huawei Technologies 1213 5340 Legacy Drive 1214 Plano, TX 75023, USA 1215 Phone: (469)277-5838 1217 Email: leeyoung@huawei.com 1219 Dhruv Dhody 1220 Huawei Technologies 1222 Email: dhruv.ietf@gmail.com 1223 Daniele Ceccarelli 1224 Ericsson 1225 Torshamnsgatan,48 1226 Stockholm, Sweden 1228 Email: daniele.ceccarelli@ericsson.com 1230 Jeff Tantsura 1231 Apstra 1233 EMail: jefftant@gmail.com 1235 Giuseppe Fioccola 1236 Huawei 1237 Email: giuseppe.fioccola@huawei.com 1239 Qin Wu 1240 Huawei 1241 Email: bill.wu@huawei.com