idnits 2.17.1 draft-lee-teas-te-service-mapping-yang-12.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 (October 5, 2018) is 2002 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 167, but not defined == Missing Reference: 'RFC8340' is mentioned on line 174, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 191, but not defined == Missing Reference: 'ACTN-VN' is mentioned on line 192, but not defined == Missing Reference: 'RFC8345' is mentioned on line 193, but not defined == Missing Reference: 'L3SM' is mentioned on line 285, but not defined == Missing Reference: 'TE-topo' is mentioned on line 323, but not defined == Missing Reference: 'RFC6241' is mentioned on line 1053, but not defined == Missing Reference: 'RFC6536' is mentioned on line 1054, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 1065, but not defined == Missing Reference: 'RFC7950' is mentioned on line 1094, but not defined == Unused Reference: 'RFC4110' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'Netconf' is defined on line 1147, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 14 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: April 6, 2019 5 Daniele Ceccarelli 6 Ericsson 8 Jeff Tantsura 9 Nuage 11 Giuseppe Fioccola 12 Telecom Italia 14 Qin Wu 15 Huawei 17 October 5, 2018 19 Traffic Engineering and Service Mapping Yang Model 21 draft-lee-teas-te-service-mapping-yang-12 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 to the 30 operator's need for seamless control and management of their VPN 31 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 April 6, 2019. 60 Copyright Notice 62 Copyright (c) 2018 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..................................6 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.............................................11 89 5. YANG Data Trees...............................................12 90 6. YANG Data Models..............................................14 91 7. Security......................................................23 92 8. IANA Considerations...........................................24 93 9. Acknowledgements..............................................25 94 10. References...................................................25 95 10.1. Informative References..................................25 96 11. Contributors.................................................26 97 Authors' Addresses...............................................27 99 1. Introduction 101 Data models are a representation of objects that can be configured 102 or monitored within a system. Within the IETF, YANG [RFC6020] is the 103 language of choice for documenting data models, and YANG models have 104 been produced to allow configuration or modeling of a variety of 105 network devices, protocol instances, and network services. YANG data 106 models have been classified in [RFC8199] and [RFC8309]. 108 Framework for Abstraction and Control of Traffic Engineered Networks 109 (ACTN) [RFC8453] introduces an architecture to support virtual 110 network services and connectivity services. [ACTN-VN-YANG] defines a 111 YANG model and describes how customers or end-to-end orchestrators 112 can request and/or instantiate a generic virtual network service. 113 [ACTN-Applicability] describes the way IETF YANG models of different 114 classifications can be applied to the ACTN interfaces. In 115 particular, it describes how customer service models can be mapped 116 into the CNC-MDSC Interface (CMI) of the ACTN architecture. 118 [RFC8299] provides a L3VPN service delivery YANG model for PE-based 119 VPNs. The scope of that draft is limited to a set of domains under 120 control of the same network operator to deliver services requiring 121 TE tunnels. 123 [L2SM] provides a L2VPN 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 [L1CSM] provides a L1 connectivity service delivery YANG model for 129 PE-based VPNs. The scope of that draft is limited to a set of 130 domains under control of the same network operator to deliver 131 services requiring TE tunnels. 133 While the IP/MPLS Provisioning Network Controller (PNC) is 134 responsible for provisioning the VPN service on the Provider Edge 135 (PE) nodes, the Multi-Domain Service Coordinator (MDSC) can 136 coordinate how to map the VPN services onto Traffic Engineering (TE) 137 tunnels. This is consistent with the two of the core functions of 138 the MDSC specified in [RFC8453]: 140 . Customer mapping/translation function: This function is to map 141 customer requests/commands into network provisioning requests 142 that can be sent to the PNC according to the business policies 143 that have been provisioned statically or dynamically. 144 Specifically, it provides mapping and translation of a 145 customer's service request into a set of parameters that are 146 specific to a network type and technology such that the network 147 configuration process is made possible. 149 . Virtual service coordination function: This function translates 150 customer service-related information into virtual network 151 service operations in order to seamlessly operate virtual 152 networks while meeting a customer's service requirements. In 153 the context of ACTN, service/virtual service coordination 154 includes a number of service orchestration functions such as 155 multi-destination load balancing, guarantees of service 156 quality, bandwidth and throughput. It also includes 157 notifications for service fault and performance degradation and 158 so forth. 160 Section 2 describes a set of TE & service related parameters that 161 this document addresses as new and advanced parameters that are not 162 included in generic service models. Section 3 discusses YANG 163 modeling approach. 165 1.1. Terminology 167 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 168 in this document. 170 1.2. Tree diagram 172 A simplified graphical representation of the data model is used in 173 Section 5 of this this document. The meaning of the symbols in 174 these diagrams is defined in [RFC8340]. 176 1.3. Prefixes in Data Node Names 178 In this document, names of data nodes and other data model objects 179 are prefixed using the standard prefix associated with the 180 corresponding YANG imported modules, as shown in Table 1. 182 +---------+------------------------------+-----------------+ 183 | Prefix | YANG module | Reference | 184 +---------+------------------------------+-----------------+ 185 |tsm-types| ietf-te-service-mapping-types| [RFCXXXX} | 186 |l1 | ietf-l1csm | [L1CSM] | 187 |l2vpn-svc| ietf-l2vpn-svc | [L2SM] | 188 |l3vpn-svc| ietf-l3vpn-svc | [RFC8299] | 189 |l1-tsm | ietf-l1csm-te-service-mapping| [RFCXXXX] | 190 |l2-tsm | ietf-l2sm-te-service-mapping | [RFCXXXX] | 191 |l3-tsm | ietf-l3sm-te-service-mapping | [RFCXXXX] | 192 |vn | ietf-actn-vn | [ACTN-VN] | 193 |nw | ietf-network | [RFC8345] | 194 |te-types | ietf-te-types | [TE-Types] | 195 |te-topo | ietf-te-topology | [TE-Topo] | 196 |te | ietf-te | [TE-Tunnel] | 197 +---------+------------------------------+-----------------+ 199 Table 1: Prefixes and corresponding YANG modules 201 Note: The RFC Editor will replace XXXX with the number assigned to 202 the RFC once this draft becomes an RFC. 204 2. TE & Service Related Parameters 206 While L1/2/3 service models [L1CSM, L2SM, L3SM] are intended to 207 provide service-specific parameters for VPN service instances, there 208 are a number of TE & Service related parameters that are not 209 included in the generic service models. 211 Additional service parameters and policies that are not included in 212 the aforementioned service models are addressed in the YANG models 213 defined in this document. 215 2.1. VN/Tunnel Selection Requirements 217 In some cases, the service requirements may need addition TE tunnels 218 to be established. This may occur when there are no suitable 219 existing TE tunnels that can support the service requirements, or 220 when the operator would like to dynamically create and bind tunnels 221 to the VPN such that they are not shared by other VPNs, for example, 222 for network slicing. The establishment of TE tunnels is subject to 223 the network operator's policies. 225 To summarize, there are three modes of VN/Tunnel selection 226 operations to be supported as follows. Additional modes may be 227 defined in the future. 229 o New VN/Tunnel Binding - A customer could request a VPN 230 service based on VN/Tunnels that are not shared with other 231 existing or future services. This might be to meet VPN 232 isolation requirements. Further, the YANG model described in 233 Section 5 of this document can be used to describe the 234 mapping between the VPN service and the ACTN VN. The VN (and 235 TE tunnels) could be bound to the VPN and not used for any 236 other VPN. 238 Under this mode, the following sub-categories can be 239 supported: 241 1. Hard Isolation with deterministic characteristics: A 242 customer could request a VPN service using a set of TE 243 Tunnels with deterministic characteristics requirements 244 (e.g., no latency variation) and where that set of TE 245 Tunnels must not be shared with other VPN services and 246 must not compete for bandwidth or other network resources 247 with other TE Tunnels. 249 2. Hard Isolation: This is similar to the above case but 250 without the deterministic characteristics requirements. 252 3. Soft Isolation: The customer requests a VPN service using 253 a set of TE tunnels which can be shared with other VPN 254 services. 256 o VN/Tunnel Sharing - A customer could request a VPN service 257 where new tunnels (or a VN) do not need to be created for 258 each VPN and can be shared across multiple VPNs. Further, the 259 mapping YANG model described in Section 5 of this document 260 can be used to describe the mapping between the VPN service 261 and the tunnels in use. No modification of the properties of 262 a tunnel (or VN) is allowed in this mode: an existing tunnel 263 can only be selected. 265 o VN/Tunnel Modify - This mode allows the modification of the 266 properties of the existing VN/tunnel (e.g., bandwidth). 268 2.2. Availability Requirement 270 Availability is another service requirement or intent that may 271 influence the selection or provisioning of TE tunnels or a VN to 272 support the requested service. Availability is a probabilistic 273 measure of the length of time that a VPN/VN instance functions 274 without a network failure. 276 The availability level will need to be translated into network 277 specific policies such as the protection/reroute policy associated 278 with a VN or Tunnel. The means by which this is achieved is not in 279 the scope of this draft. 281 3. YANG Modeling Approach 283 This section provides how the TE & Service mapping parameters are 284 supported using augmentation of the existing service models (i.e., 285 [L1CSM], [L2SM], and [L3SM]). Figure 1 shows the scope of the 286 Augmented LxSM Model. 288 +--------------+ +----------------------------+ +----------+ 289 | LxSM |o-------| | . . . . . | ACTN VN | 290 +--------------+ augment| | +----------+ 291 | | +----------+ 292 +--------------+ | Augmented LxSM Model | . . . . . | TE-topo | 293 | TE & Service |------->| | +----------+ 294 | Mapping Types| import | | +----------+ 295 +--------------+ | | . . . . . | TE-tunnel| 296 +----------------------------+ reference +----------+ 298 Figure 1. Augmented LxSM Model 300 The Augmented LxSM model (where x=1,2,3) augments the basic LxSM 301 model while importing the common TE & Service related parameters 302 (defined in Section 2) grouping information from TE & Service 303 Mapping Types. The TE & Service Mapping Types (ietf-te-service- 304 mapping-types) module is the repository of all common groupings 305 imported by each augmented LxSM model. Any future service models 306 would import this grouping file. 308 The role of the augmented LxSm service model is to expose the 309 mapping relationship between service models and TE models so that 310 VN/VPN service instantiations provided by the underlying TE networks 311 can be viewed outside of the MDSC, for example by an operator who is 312 diagnosing the behavior of the network. It also allows for the 313 customers to access operational state information about how their 314 services are instantiated with the underlying VN, TE topology or TE 315 tunnels provided that the MDSC operator is willing to share that 316 information. This mapping will facilitate a seamless service 317 management operation with underlay-TE network visibility. 319 As seen in Figure 1, the augmented LxSM service model records a 320 mapping between the customer service models and the ACTN VN YANG 321 model. Thus, when the MDSC receives a service request it creates a 322 VN that meets the customer's service objectives with various 323 constraints via TE-topology model [TE-topo], and this relationship 324 is recorded by the Augmented LxSM Model. The model also supports a 325 mapping between a service model and TE-topology or a TE-tunnel. 327 3.1. Forward Compatibility 329 The YANG module defined in this document supports three existing 330 service models via augmenting while sharing the common TE & Service 331 Mapping Types. 333 It is possible that new service models will be defined at some 334 future time and that it will be desirable to map them to underlying 335 TE constructs in the same way as the three existing models are 336 augmented. 338 4. L3VPN Architecture in the ACTN Context 340 Figure 2 shows the architectural context of this document 341 referencing the ACTN components and interfaces. 343 +----------------------------+ 344 | Customer Service Manager | 345 | +-----------------------+ | 346 | | CNC + | 347 | +-+-------------------+-+ | 348 +----|-------------------|---+ 349 | | 350 |CMI(Augmented L3SM)|CMI(VN) 351 | | 352 +----------------|-------------------|----+ 353 | +--------------|-----------------+ | | 354 | | MDSC | | | | 355 | | | | | | 356 | | +-----------+--------------+ | | | 357 TE-Svc-Map<------+ Service Mapping Function | | | | 358 | | +-----------+--------------+ | | | 359 | | | | | | 360 | +-------+------|-----------------+ | | 361 | | | | | 362 | | |CMI(VN) | | 363 | | | | | 364 | | +--|-------------------|--+ | 365 | | | | MDSC | | | 366 | | | ++-------------------++ | | 367 | | | + Service Mapping +---->TE-Svc-Map 368 | | | ++----------+---------+ | | 369 | | +--|----------|-----------+ | 370 +---------|------|----------|-------------+ 371 | | | 372 | +----+--------+ | 373 | | | | 374 MPI(VPN / TE models)| | | |MPI(TE / L1 models) 375 | | | | 376 +-----|-|---+ +-----|-|----+ 377 IP/MPLS | +--+-+-+ | | +--+-+-+ | Optical Domain 378 Domain | | PNC1 | | | | PNC2 | | Controller 379 Controller | +--+---+ | | +--+---+ | 380 +-----|-----+ +-----|------+ 381 | | 382 V | SBI 383 +---------------------+ | 384 / IP/MPLS Network \ | 385 +-------------------------+ | 386 V 387 +---------------------+ 388 / Optical Network \ 389 +-------------------------+ 391 Figure 2: L3VPN Architecture from the IP+Optical Network Perspective 393 There are three main entities in the ACTN architecture and shown in 394 Figure 2. 396 . CNC: The Customer Network Controller is responsible for generating 397 service requests. In the context of an L3VPN, the CNC uses the 398 Augmented L3SM to express the service request and communicate it 399 to the network operator. 401 . MDSC: This entity is responsible for coordinating a L3VPN service 402 request (expressed via the Augmented L3SM) with the IP/MPLS PNC 403 and the Transport PNC. For TE services, one of the key 404 responsibilities of the MDSC is to coordinate with both the IP PNC 405 and the Transport PNC for the mapping of the Augmented L3VPN 406 Service Model to the ACTN VN model. In the VN/TE-tunnel binding 407 case, the MDSC will need to coordinate with the Transport PNC to 408 dynamically create the TE-tunnels in the transport network as 409 needed. These tunnels are added as links in the IP/MPLS Layer 410 topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 411 tunnels in the IP/MPLS layer, as part of the ACTN VN creation. 412 . PNC: The Provisioning Network Controller is responsible for 413 configuring and operating the network devices. Figure 2 shows two 414 distinct PNCs. 415 o IP/MPLS PNC (PNC1): This entity is responsible for device 416 configuration to create PE-PE L3VPN tunnels for the VPN 417 customer and for the configuration of the L3VPN VRF on the PE 418 nodes. Each network element would select a tunnel based on 419 the configuration. 420 o Transport PNC (PNC2): This entity is responsible for device 421 configuration for TE tunnels in the transport networks. 423 There are four main interfaces shown in Figure 2. 425 . CMI: The CNC-MDSC Interface is used to communicate service 426 requests from the customer to the operator. The requests may be 427 expressed as Augmented VPN service requests (L2SM, L3SM), as 428 connectivity requests (L1CSM), or as virtual network requests 429 (ACTN VN). 430 . MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate 431 networks under the control of PNCs. The requests on this interface 432 may use TE tunnel models, TE topology models, VPN network 433 configuration models or layer one connectivity models. 434 . SBI: The Southbound Interface is used by the PNC to control 435 network devices and is out of scope for this document. 436 . The TE Service Mapping Model as described in this document can be 437 used to see the mapping between service models and VN models and 438 TE Tunnel/Topology models. That mapping may occur in the CNC if a 439 service request is mapped to a VN request. Or it may occur in the 440 MDSC where a service request is mapped to a TE tunnel, TE 441 topology, or VPN network configuration model. The TE Service 442 Mapping Model may be read from the CNC or MDSC to understand how 443 the mapping has been made and to see the purpose for which network 444 resources are used. 446 As shown in Figure 2, the MDSC may be used recursively. For example, 447 the CNC might map a L3SM request to a VN request that it sends to a 448 recursive MDSC. 450 The high-level control flows for one example are as follows: 452 1. A customer asks for an L3VPN between CE1 and CE2 using the 453 Augmented L3SM model. 455 2. The MDSC considers the service request and local policy to 456 determine if it needs to create a new VN or any TE Topology, and 457 if that is the case, ACTN VN YANG [ACTN-VN-YANG] is used to 458 configure a new VN based on this VPN and map the VPN service to 459 the ACTN VN. In case an existing tunnel is to be used, each device 460 will select which tunnel to use and populate this mapping 461 information. 463 3. The MDSC interacts with both the IP/MPLS PNC and the Transport PNC 464 to create a PE-PE tunnel in the IP network mapped to a TE tunnel 465 in the transport network by providing the inter-layer access 466 points and tunnel requirements. The specific service information 467 is passed to the IP/MPLS PNC for the actual VPN configuration and 468 activation. 470 a. The Transport PNC creates the corresponding TE tunnel 471 matching with the access point and egress point. 472 b. The IP/MPLS PNC maps the VPN ID with the corresponding TE 473 tunnel ID to bind these two IDs. 475 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 476 customer. This is not in the scope of this document. 478 4.1. Service Mapping 480 Augmented L3SM and L2SM can be used to request VPN service creation 481 including the creation of sites and corresponding site network 482 access connection between CE and PE. A VPN-ID is used to identify 483 each VPN service ordered by the customer. The ACTN VN can be used 484 further to establish PE-to-PE connectivity between VPN sites 485 belonging to the same VPN service. A VN-ID is used to identify each 486 virtual network established between VPN sites. 488 Once the ACTN VN has been established over the TE network (maybe a 489 new VN, maybe modification of an existing VN, or maybe the use of an 490 unmodified existing VN), the mapping between the VPN service and the 491 ACTN VN service can be created. 493 4.2. Site Mapping 495 The elements in Augmented L3SM and L2SM define site location 496 parameters and constraints such as distance and access diversity 497 that can influence the placement of network attachment points (i.e, 498 virtual network access points (VNAP)). To achieve this, a central 499 directory can be set up to establish the mapping between location 500 parameters and constraints and network attachment point location. 501 Suppose multiple attachment points are matched, the management 502 system can use constraints or other local policy to select the best 503 candidate network attachment points. 505 After a network attachment point is selected, the mapping between 506 VPN site and VNAP can be established as shown in Table 1. 508 +------+---------+------------------+----------------------+-------+ 509 | | | Location | Access Diversity | PE | 510 | | Site | | | | 511 |Site | Network | (Address, Postal | (Constraint-Type, | | 512 | | Access | Code, State, | Group-id,Target | | 513 | | | City,Country | Group-id) | | 514 | | | Code) | | | 515 +------+---------+------------------+----------------------+-------+ 516 | | | | | | 517 |SITE1 | ACCESS1 | (,,US,NewYork,) |(10,PE-Diverse,10) | PE1 | 518 +------+---------+------------------+----------------------+-------+ 519 |SITE2 | ACCESS2 | (,,CN,Beijing,) |(10,PE-Diverse,10) | PE2 | 520 +------+---------+------------------+----------------------+-------+ 521 |SITE3 | ACCESS3 | (,,UK,London, ) |(12,same-PE,12) | PE4 | 522 +------+---------+------------------+----------------------+-------+ 523 |SITE4 | ACCESS4 | (,,FR,Paris,) |(20,Bearer-Diverse,20)| PE7 | 524 +------+---------+------------------+----------------------+-------+ 526 Table 1 : Mapping Between VPN Site and VNAP 528 5. YANG Data Trees 530 module: ietf-l1csm-te-service-mapping 531 augment /l1:l1-connectivity/l1:services/l1:service: 532 +-rw te-service-mapping! 533 augment /l1:l1-connectivity/l1:services/l1:service: 534 +-rw te-mapping 535 +-rw map-type? identityref 536 +-rw availability-type? identityref 537 +-rw (te)? 538 +-:(actn-vn) 539 | +-rw actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id 540 +-:(te-topo) 541 | +-rw vn-topology-id? te-types:te-topology-id 542 | +-rw abstract-node? -> /nw:networks/network/node/node-id 543 +-:(te-tunnel) 544 +-rw te-tunnel-list* te:tunnel-ref 545 augment /l1:l1-connectivity/l1:services/l1:service/l1:endpoint-1: 546 +-rw (te)? 547 +-:(actn-vn) 548 | +-rw actn-vn-ref? -> /vn:actn/ap/access-point-list/access-point-id 549 +-:(te) 550 +-rw ltp? te-types:te-tp-id 551 augment /l1:l1-connectivity/l1:services/l1:service/l1:endpoint-2: 552 +-rw (te)? 553 +-:(actn-vn) 554 | +-rw actn-vn-ref? -> /vn:actn/ap/access-point-list/access-point-id 555 +-:(te) 556 +-rw ltp? te-types:te-tp-id 558 module: ietf-l2sm-te-service-mapping 559 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service: 560 +-rw te-service-mapping! 561 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service: 562 +-rw te-mapping 563 +-rw map-type? identityref 564 +-rw availability-type? identityref 565 +-rw (te)? 566 +-:(actn-vn) 567 | +-rw actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id 568 +-:(te-topo) 569 | +-rw vn-topology-id? te-types:te-topology-id 570 | +-rw abstract-node? -> /nw:networks/network/node/node-id 571 +-:(te-tunnel) 572 +-rw te-tunnel-list* te:tunnel-ref 573 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site/l2vpn-svc:site-network- 574 accesses/l2vpn-svc:site-network-access: 575 +-rw (te)? 576 +-:(actn-vn) 577 | +-rw actn-vn-ref? -> /vn:actn/ap/access-point-list/access-point-id 578 +-:(te) 579 +-rw ltp? te-types:te-tp-id 581 module: ietf-l3sm-te-service-mapping 582 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service: 583 +-rw te-service-mapping! 584 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service: 585 +-rw te-mapping 586 +-rw map-type? identityref 587 +-rw availability-type? identityref 588 +-rw (te)? 589 +-:(actn-vn) 590 | +-rw actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id 591 +-:(te-topo) 592 | +-rw vn-topology-id? te-types:te-topology-id 593 | +-rw abstract-node? -> /nw:networks/network/node/node-id 594 +-:(te-tunnel) 595 +-rw te-tunnel-list* te:tunnel-ref 596 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site- 597 network-accesses/l3vpn-svc:site-network-access: 598 +-rw (te)? 599 +-:(actn-vn) 600 | +-rw actn-vn-ref? -> /vn:actn/ap/access-point-list/access-point-id 601 +-:(te) 602 +-rw ltp? te-types:te-tp-id 604 6. YANG Data Models 606 The YANG codes are as follows: 608 file "ietf-te-service-mapping-types@2018-10-05.yang" 610 module ietf-te-service-mapping-types { 612 namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; 614 prefix "tsm"; 616 import ietf-te-types { 617 prefix "te-types"; 618 } 620 import ietf-network { 621 prefix "nw"; 622 } 624 import ietf-te { 625 prefix "te"; 626 } 628 import ietf-actn-vn { 629 prefix "vn"; 630 } 632 organization 633 "IETF Traffic Engineering Architecture and Signaling (TEAS) 634 Working Group"; 636 contact 637 "Editor: Young Lee 638 Dhruv Dhody 639 Qin Wu "; 641 description 642 "This module contains a YANG module for TE & Service mapping 643 parameters and policies as a common grouping applicable to 644 variuous service models (e.g., L1CSM, L2SM, L3SM, etc.)"; 646 revision 2018-10-05 { 647 description 648 "initial version."; 649 reference 650 "TBD"; 651 } 653 /* 654 * Identity for map-type 655 */ 656 identity map-type { 657 description 658 "Base identity from which specific map types are 659 derived."; 660 } 662 identity new { 663 base map-type; 664 description 665 "The new VN/tunnels are binded to the service."; 666 } 668 identity detnet-hard-isolation { 669 base new; 670 description 671 "Hard isolation with deterministic characteristics."; 672 } 674 identity hard-isolation { 675 base new; 676 description 677 "Hard isolation."; 678 } 680 identity soft-isolation { 681 base new; 682 description 683 "Soft-isolation."; 684 } 686 identity select { 687 base map-type; 688 description 689 "The VPN service selects an existing tunnel with no 690 modification."; 691 } 693 identity modify { 694 base map-type; 695 description 696 "The VPN service selects an existing tunnel and allows 697 to modify the properties of the tunnel (e.g., b/w)"; 698 } 700 /* 701 * Identity for availability-type 702 */ 703 identity availability-type { 704 description 705 "Base identity from which specific map types are 706 derived."; 707 } 709 identity level-1 { 710 base availability-type; 711 description 712 "level 1: 99.9999%"; 713 } 715 identity level-2 { 716 base availability-type; 717 description 718 "level 2: 99.999%"; 719 } 721 identity level-3 { 722 base availability-type; 723 description 724 "level 3: 99.99%"; 725 } 727 identity level-4 { 728 base availability-type; 729 description 730 "level 4: 99.9%"; 731 } 733 identity level-5 { 734 base availability-type; 735 description 736 "level 5: 99%"; 737 } 738 /* 739 * Groupings 740 */ 742 grouping te-ref { 743 description 744 "The reference to TE."; 745 choice te { 746 description 747 "The TE"; 748 case actn-vn { 749 leaf actn-vn-ref { 750 type leafref { 751 path "/vn:actn/vn:vn/vn:vn-list/vn:vn-id"; 752 } 753 description 754 "The reference to ACTN VN"; 755 } 756 } 757 case te-topo { 758 leaf vn-topology-id{ 759 type te-types:te-topology-id; 760 description 761 "An identifier to the TE Topology Model 762 where the abstract nodes and links of 763 the Topology can be found for Type 2 764 VNS"; 765 } 766 leaf abstract-node { 767 type leafref { 768 path "/nw:networks/nw:network/nw:node/" 769 + "nw:node-id"; 770 } 771 description 772 "a reference to the abstract node in TE 773 Topology"; 774 } 775 } 776 case te-tunnel { 777 leaf-list te-tunnel-list { 778 type te:tunnel-ref; 779 description 780 "Reference to TE Tunnels"; 781 } 783 } 785 } 787 } 789 grouping te-endpoint-ref { 790 description 791 "The reference to TE endpoints."; 792 choice te { 793 description 794 "The TE"; 795 case actn-vn { 796 leaf actn-vn-ref { 797 type leafref { 798 path "/vn:actn/vn:ap/vn:access-point-list" 799 + "/vn:access-point-id"; 800 } 801 description 802 "The reference to ACTN VN"; 803 } 804 } 805 case te { 806 leaf ltp { 807 type te-types:te-tp-id; 808 description 809 "Reference LTP in the TE-topology"; 810 } 811 } 812 } 814 } 816 grouping te-mapping { 817 description 818 "Mapping between Services and TE"; 819 container te-mapping { 820 description 821 "Mapping between Services and TE"; 822 leaf map-type { 823 type identityref { 824 base map-type; 825 } 826 description 827 "Isolation Requirements, Tunnel Bind or 828 Tunnel Selection"; 829 } 830 leaf availability-type { 831 type identityref { 832 base availability-type; 833 } 834 description 835 "Availability Requirement for the Service"; 836 } 837 uses te-ref; 838 } 839 } 841 } 842 844 file "ietf-l1csm-te-service-mapping@2018-10-05.yang" 846 module ietf-l1csm-te-service-mapping { 848 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; 850 prefix "tm"; 852 import ietf-te-service-mapping-types { 853 prefix "tsm-types"; 854 } 856 import ietf-l1csm { 857 prefix "l1"; 858 } 860 organization 861 "IETF Traffic Engineering Architecture and Signaling (TEAS) 862 Working Group"; 864 contact 865 "Editor: Young Lee 866 Dhruv Dhody 867 Qin Wu "; 868 description 869 "This module contains a YANG module for the mapping of 870 Layer 1 Connectivity Service Module (L1CSM) to the TE and VN "; 872 revision 2018-10-05 { 873 description 874 "initial version."; 875 reference 876 "TBD"; 877 } 879 /* 880 * Configuration data nodes 881 */ 882 augment "/l1:l1-connectivity/l1:services/l1:service" { 883 description 884 "l1csm augmented to include TE parameters and mapping"; 885 container te-service-mapping { 886 presence "indicates l1 service to te mapping"; 887 description 888 "Container to augment l1csm to TE parameters and mapping"; 889 } 890 } 892 augment "/l1:l1-connectivity/l1:services/l1:service" { 893 description 894 "This augment is only valid for TE mapping -- 895 te mapping is added"; 896 uses tsm-types:te-mapping; 897 } 899 augment "/l1:l1-connectivity/l1:services/l1:service/l1:endpoint-1" { 900 description 901 "This augment is only valid for TE mapping -- 902 endpoint-1 te-reference is added"; 903 uses tsm-types:te-endpoint-ref; 904 } 906 augment "/l1:l1-connectivity/l1:services/l1:service/l1:endpoint-2" { 907 description 908 "This augment is only valid for TE mapping -- 909 endpoint-2 te-reference is added"; 910 uses tsm-types:te-endpoint-ref; 911 } 912 } 914 916 file "ietf-l2sm-te-service-mapping@2018-10-05.yang" 918 module ietf-l2sm-te-service-mapping { 920 namespace "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; 922 prefix "tm"; 924 import ietf-te-service-mapping-types { 925 prefix "tsm-types"; 926 } 928 import ietf-l2vpn-svc { 929 prefix "l2vpn-svc"; 930 } 932 organization 933 "IETF Traffic Engineering Architecture and Signaling (TEAS) 934 Working Group"; 936 contact 937 "Editor: Young Lee 938 Dhruv Dhody 939 Qin Wu "; 940 description 941 "This module contains a YANG module for the mapping of 942 Layer 2 Service Model (L1CSM) to the TE and VN "; 944 revision 2018-10-05 { 945 description 946 "initial version."; 947 reference 948 "TBD"; 949 } 951 /* 952 * Configuration data nodes 953 */ 954 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service" { 955 description 956 "l2sm augmented to include TE parameters and mapping"; 957 container te-service-mapping { 958 presence "indicates l2 service to te mapping"; 959 description 960 "Container to augment l2sm to TE parameters and mapping"; 961 } 962 } 964 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service" { 965 description 966 "This augment is only valid for TE mapping -- 967 te mapping is added"; 968 uses tsm-types:te-mapping; 969 } 971 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 972 +"/l2vpn-svc:site-network-accesses/l2vpn-svc:site-network-access" { 973 description 974 "This augment is only valid for TE mapping -- 975 network-access te-reference is added"; 976 uses tsm-types:te-endpoint-ref; 977 } 978 } 980 982 file "ietf-l3sm-te-service-mapping@2018-10-05.yang" 984 module ietf-l3sm-te-service-mapping { 986 namespace "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; 988 prefix "tm"; 990 import ietf-te-service-mapping-types { 991 prefix "tsm-types"; 992 } 994 import ietf-l3vpn-svc { 995 prefix "l3vpn-svc"; 996 } 998 organization 999 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1000 Working Group"; 1002 contact 1003 "Editor: Young Lee 1004 Dhruv Dhody 1005 Qin Wu "; 1006 description 1007 "This module contains a YANG module for the mapping of 1008 Layer 3 Service Model (L3SM) to the TE and VN "; 1010 revision 2018-10-05 { 1011 description 1012 "initial version."; 1014 reference 1015 "TBD"; 1016 } 1018 /* 1019 * Configuration data nodes 1020 */ 1021 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service" { 1022 description 1023 "l3sm augmented to include TE parameters and mapping"; 1024 container te-service-mapping { 1025 presence "indicates l3 service to te mapping"; 1026 description 1027 "Container to augment l3sm to TE parameters and mapping"; 1028 } 1029 } 1031 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service" { 1032 description 1033 "This augment is only valid for TE mapping -- 1034 te mapping is added"; 1035 uses tsm-types:te-mapping; 1036 } 1038 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1039 +"/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access" { 1040 description 1041 "This augment is only valid for TE mapping -- 1042 network-access te-reference is added"; 1043 uses tsm-types:te-endpoint-ref; 1044 } 1045 } 1047 1049 7. Security 1051 The configuration, state, and action data defined in this document 1052 are designed to be accessed via a management protocol with a secure 1053 transport layer, such as NETCONF [RFC6241]. The NETCONF access 1054 control model [RFC6536] provides the means to restrict access for 1055 particular NETCONF users to a preconfigured subset of all available 1056 NETCONF protocol operations and content. 1058 A number of configuration data nodes defined in this document are 1059 writable/deletable (i.e., "config true") These data nodes may be 1060 considered sensitive or vulnerable in some network environments. 1062 8. IANA Considerations 1064 This document registers the following namespace URIs in the IETF XML 1065 registry [RFC3688]: 1067 -------------------------------------------------------------------- 1068 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1069 Registrant Contact: The IESG. 1070 XML: N/A, the requested URI is an XML namespace. 1071 -------------------------------------------------------------------- 1073 -------------------------------------------------------------------- 1074 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 1075 Registrant Contact: The IESG. 1076 XML: N/A, the requested URI is an XML namespace. 1077 -------------------------------------------------------------------- 1079 -------------------------------------------------------------------- 1080 URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 1081 Registrant Contact: The IESG. 1082 XML: N/A, the requested URI is an XML namespace. 1083 -------------------------------------------------------------------- 1085 -------------------------------------------------------------------- 1086 URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 1087 Registrant Contact: The IESG. 1088 XML: N/A, the requested URI is an XML namespace. 1089 -------------------------------------------------------------------- 1091 This document registers the following YANG modules in the YANG 1092 Module. 1094 Names registry [RFC7950]: 1096 -------------------------------------------------------------------- 1097 name: ietf-te-service-mapping-types 1098 namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping- 1099 types 1100 reference: RFC XXXX (TDB) 1101 -------------------------------------------------------------------- 1103 -------------------------------------------------------------------- 1104 name: ietf-l1csm-te-service-mapping 1105 namespace: urn:ietf:params:xml:ns:yang:ietf-l1cms-te-service- 1106 mapping 1107 reference: RFC XXXX (TDB) 1108 -------------------------------------------------------------------- 1110 -------------------------------------------------------------------- 1111 name: ietf-l2sm-te-service-mapping 1112 namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service- 1113 mapping 1114 reference: RFC XXXX (TDB) 1115 -------------------------------------------------------------------- 1117 -------------------------------------------------------------------- 1118 name: ietf-l3sm-te-service-mapping 1119 namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service- 1120 mapping 1121 reference: RFC XXXX (TDB) 1122 -------------------------------------------------------------------- 1124 9. Acknowledgements 1126 We thank Diego Caviglia and Igor Bryskin for useful discussions and 1127 motivation for this work. 1129 10. References 1131 10.1. Informative References 1133 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 1134 Provider-Provisioned Virtual Private Networks (PPVPNs)", 1135 RFC 4110, July 2005. 1137 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for 1138 the Network Configuration Protocol (NETCONF)", RFC 6020, 1139 October 2010. 1141 [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", 1142 RFC 8309, January 2018. 1144 [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module 1145 Classification", RFC 8199, July 2017. 1147 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1148 and A. Bierman, Ed., "Network Configuration Protocol 1149 (NETCONF)", RFC 6241. 1151 [RFC8453] D. Cecarelli and Y. Lee, "Framework for Abstraction and 1152 Control of Traffic Engineered Networks", RFC 8453, August 1153 2018. 1155 [TE-Topo] X. Liu, et. al., "YANG Data Model for TE Topologies", 1156 draft-ietf-teas-yang-te-topo, work in progress. 1158 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 1159 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1160 te, work in progress. 1162 [TE-Types] T. Saad (Editor), "Traffic Engineering Common YANG 1163 Types", draft-ietf-teas-yang-te-types, work in progress. 1165 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 1166 Operation", draft-lee-teas-actn-vn-yang, work in progress. 1168 [ACTN-Applicability] Y. Lee, et al, "Applicability of YANG models 1169 for Abstraction and Control of Traffic Engineered 1170 Networks, draft-ietf-teas-actn-yang, work in progress. 1172 [RFC8299] Q. Wu, S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data 1173 Model for L3VPN service delivery", RFC 8299, January 2018. 1175 [L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service 1176 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 1177 progress. 1179 [L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity 1180 Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work 1181 in progress. 1183 11. Contributors 1185 Adrian Farrel 1186 Old Dog Consulting 1187 Email: adrian@olddog.co.uk 1189 Italo Busi 1190 Huawei Technologies 1192 Email: Italo.Busi@huawei.com 1194 Authors' Addresses 1196 Young Lee 1197 Huawei Technologies 1198 5340 Legacy Drive 1199 Plano, TX 75023, USA 1200 Phone: (469)277-5838 1202 Email: leeyoung@huawei.com 1204 Dhruv Dhody 1205 Huawei Technologies 1207 Email: dhruv.ietf@gmail.com 1209 Daniele Ceccarelli 1210 Ericsson 1211 Torshamnsgatan,48 1212 Stockholm, Sweden 1214 Email: daniele.ceccarelli@ericsson.com 1216 Jeff Tantsura 1217 Nuage 1219 EMail: jefftant@gmail.com 1221 Giuseppe Fioccola 1222 Telecom Italia 1223 Email: giuseppe.fioccola@telecomitalia.it 1225 Qin Wu 1226 Huawei 1227 Email: bill.wu@huawei.com