idnits 2.17.1 draft-ietf-teas-te-service-mapping-yang-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 652 has weird spacing: '...ic-type ide...' == Line 656 has weird spacing: '...w usage ide...' == Line 662 has weird spacing: '...rw name str...' == Line 669 has weird spacing: '...w usage ide...' == Line 718 has weird spacing: '...int-ref lea...' == (4 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 20, 2021) is 1154 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: 'RFCXXXX' is mentioned on line 227, but not defined == Unused Reference: 'I-D.ietf-spring-sr-policy-yang' is defined on line 2012, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-13 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-01 == Outdated reference: A later version (-18) exists of draft-ietf-opsawg-l3sm-l3nm-05 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-policy-yang-00 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-10 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-25 ** Downref: Normative reference to an Informational RFC: RFC 8453 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-06 Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Y. Lee, Ed. 3 Internet-Draft Samsung Electronics 4 Intended status: Standards Track D. Dhody, Ed. 5 Expires: August 24, 2021 G. Fioccola 6 Q. Wu, Ed. 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 J. Tantsura 11 Apstra 12 February 20, 2021 14 Traffic Engineering (TE) and Service Mapping Yang Model 15 draft-ietf-teas-te-service-mapping-yang-06 17 Abstract 19 This document provides a YANG data model to map customer service 20 models (e.g., the L3VPN Service Model (L3SM)) to Traffic Engineering 21 (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). 22 This model is referred to as TE Service Mapping Model and is 23 applicable generically to the operator's need for seamless control 24 and management of their VPN services with TE tunnel support. 26 The model is principally used to allow monitoring and diagnostics of 27 the management systems to show how the service requests are mapped 28 onto underlying network resource and TE models. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 24, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 5 67 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5 68 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 69 2. TE and Service Related Parameters . . . . . . . . . . . . . . 6 70 2.1. VN/Tunnel Selection Requirements . . . . . . . . . . . . 7 71 2.2. TE Policy . . . . . . . . . . . . . . . . . . . . . . . . 8 72 2.2.1. Availability Requirement . . . . . . . . . . . . . . 8 73 3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 8 74 3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 9 75 3.2. TE and Network Models . . . . . . . . . . . . . . . . . . 9 76 4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 10 77 4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 13 78 4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 13 79 5. Applicability of TE-Service Mapping in Generic context . . . 14 80 6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 14 81 6.1. Service Mapping Types . . . . . . . . . . . . . . . . . . 14 82 6.2. Service Models . . . . . . . . . . . . . . . . . . . . . 16 83 6.2.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 16 84 6.2.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.2.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.3. Network Models . . . . . . . . . . . . . . . . . . . . . 18 87 6.3.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 18 88 6.3.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 19 89 7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 20 90 7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 20 91 7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 30 92 7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 30 93 7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 32 94 7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 34 96 7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 36 97 7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 36 98 7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 38 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 101 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 43 104 11.2. Informative References . . . . . . . . . . . . . . . . . 46 105 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 47 106 Appendix B. Discussion . . . . . . . . . . . . . . . . . . . . . 49 107 Appendix C. Contributor Addresses . . . . . . . . . . . . . . . 49 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 110 1. Introduction 112 Data models are a representation of objects that can be configured or 113 monitored within a system. Within the IETF, YANG [RFC7950] is the 114 language of choice for documenting data models, and YANG models have 115 been produced to allow configuration or modelling of a variety of 116 network devices, protocol instances, and network services. YANG data 117 models have been classified in [RFC8199] and [RFC8309]. 119 Framework for Abstraction and Control of Traffic Engineered Networks 120 (ACTN) [RFC8453] introduces an architecture to support virtual 121 network services and connectivity services. 122 [I-D.ietf-teas-actn-vn-yang] defines a YANG model and describes how 123 customers or end-to-end orchestrator can request and/or instantiate a 124 generic virtual network service. [I-D.ietf-teas-actn-yang] describes 125 the way IETF YANG models of different classifications can be applied 126 to the ACTN interfaces. In particular, it describes how customer 127 service models can be mapped into the CNC-MDSC Interface (CMI) of the 128 ACTN architecture. 130 The models presented in this document are also applicable in generic 131 context [RFC8309] as part of Customer Service Model used between 132 Service Orchestrator and Customer. 134 [RFC8299] provides a L3VPN service delivery YANG model for PE-based 135 VPNs. The scope of that draft is limited to a set of domains under 136 control of the same network operator to deliver services requiring TE 137 tunnels. 139 [RFC8466] provides a L2VPN service delivery YANG model for PE-based 140 VPNs. The scope of that draft is limited to a set of domains under 141 control of the same network operator to deliver services requiring TE 142 tunnels. 144 [I-D.ietf-ccamp-l1csm-yang] provides a L1 connectivity service 145 delivery YANG model for PE-based VPNs. The scope of that draft is 146 limited to a set of domains under control of the same network 147 operator to deliver services requiring TE tunnels. 149 While the IP/MPLS Provisioning Network Controller (PNC) is 150 responsible for provisioning the VPN service on the Provider Edge 151 (PE) nodes, the Multi-Domain Service Coordinator (MDSC) can 152 coordinate how to map the VPN services onto Traffic Engineering (TE) 153 tunnels. This is consistent with the two of the core functions of 154 the MDSC specified in [RFC8453]: 156 o Customer mapping/translation function: This function is to map 157 customer requests/commands into network provisioning requests that 158 can be sent to the PNC according to the business policies that 159 have been provisioned statically or dynamically. Specifically, it 160 provides mapping and translation of a customer's service request 161 into a set of parameters that are specific to a network type and 162 technology such that the network configuration process is made 163 possible. 165 o Virtual service coordination function: This function translates 166 customer service-related information into virtual network service 167 operations in order to seamlessly operate virtual networks while 168 meeting a customer's service requirements. In the context of 169 ACTN, service/virtual service coordination includes a number of 170 service orchestration functions such as multi-destination load 171 balancing, guarantees of service quality, bandwidth and 172 throughput. It also includes notifications for service fault and 173 performance degradation and so forth. 175 Section 2 describes a set of TE and service related parameters that 176 this document addresses as "new and advanced parameters" that are not 177 included in generic service models. Section 3 discusses YANG 178 modelling approach. 180 Apart from the service model, the TE mapping is equally applicable to 181 the Network Models (L3 VPN Service Network Model (L3NM) 182 [I-D.ietf-opsawg-l3sm-l3nm], L2 VPN Service Network Model (L2NM) 183 [I-D.ietf-opsawg-l2nm] etc.). See Section 3.2 for details. 185 1.1. Terminology 187 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 188 in this document. 190 The terminology for describing YANG data models is found in 191 [RFC7950]. 193 1.1.1. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL" in this document are to be interpreted as described in BCP 198 14 [RFC2119] [RFC8174] when, and only when, they appear in all 199 capitals, as shown here. 201 1.2. Tree diagram 203 A simplified graphical representation of the data model is used in 204 Section 5 of this this document. The meaning of the symbols in these 205 diagrams is defined in [RFC8340]. 207 1.3. Prefixes in Data Node Names 209 In this document, names of data nodes and other data model objects 210 are prefixed using the standard prefix associated with the 211 corresponding YANG imported modules, as shown in Table 1. 213 +---------+---------------------------+-----------------------------+ 214 | Prefix | YANG module | Reference | 215 +---------+---------------------------+-----------------------------+ 216 | tsmt | ietf-te-service-mapping- | [RFCXXXX] | 217 | | types | | 218 | l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang] | 219 | l2vpn- | ietf-l2vpn-svc | [RFC8466] | 220 | svc | | | 221 | l3vpn- | ietf-l3vpn-svc | [RFC8299] | 222 | svc | | | 223 | l1-tsm | ietf-l1csm-te-service- | [RFCXXXX] | 224 | | mapping | | 225 | l2-tsm | ietf-l2sm-te-service- | [RFCXXXX] | 226 | | mapping | | 227 | l3-tsm | ietf-l3sm-te-service- | [RFCXXXX] | 228 | | mapping | | 229 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang | 230 | | | ] | 231 | nw | ietf-network | [RFC8345] | 232 | te- | ietf-te-types | [RFC8776] | 233 | types | | | 234 | te | ietf-te | [I-D.ietf-teas-yang-te] | 235 | l2vpn- | ietf-l2vpn-ntw | [I-D.ietf-opsawg-l2nm] | 236 | ntw | | | 237 | l3vpn- | ietf-l3vpn-ntw | [I-D.ietf-opsawg-l3sm-l3nm] | 238 | ntw | | | 239 | rt | ietf-routing | [RFC8349] | 240 | sr- | ietf-sr-policy | [I-D.ietf-spring-sr-policy- | 241 | policy | | yang] | 242 +---------+---------------------------+-----------------------------+ 244 Table 1: Prefixes and corresponding YANG modules 246 Note: The RFC Editor should replace XXXX with the number assigned to 247 the RFC once this draft becomes an RFC. 249 2. TE and Service Related Parameters 251 While L1/L2/L3 service models (L1CSM, L2SM, L3SM) are intended to 252 provide service-specific parameters for VPN service instances, there 253 are a number of TE Service related parameters that are not included 254 in these service models. 256 Additional 'service parameters and policies' that are not included in 257 the aforementioned service models are addressed in the YANG models 258 defined in this document. 260 2.1. VN/Tunnel Selection Requirements 262 In some cases, the service requirements may need addition TE tunnels 263 to be established. This may occur when there are no suitable 264 existing TE tunnels that can support the service requirements, or 265 when the operator would like to dynamically create and bind tunnels 266 to the VPN such that they are not shared by other VPNs, for example, 267 for network slicing. The establishment of TE tunnels is subject to 268 the network operator's policies. 270 To summarize, there are three modes of VN/Tunnel selection operations 271 to be supported as follows. Additional modes may be defined in the 272 future. 274 o New VN/Tunnel Binding - A customer could request a VPN service 275 based on VN/Tunnels that are not shared with other existing or 276 future services. This might be to meet VPN isolation 277 requirements. Further, the YANG model described in Section 5 of 278 this document can be used to describe the mapping between the VPN 279 service and the ACTN VN. The VN (and TE tunnels) could be bound 280 to the VPN and not used for any other VPN. Under this mode, the 281 following sub-categories can be supported: 283 1. Hard Isolation with deterministic characteristics: A customer 284 could request a VPN service using a set of TE Tunnels with 285 deterministic characteristics requirements (e.g., no latency 286 variation) and where that set of TE Tunnels must not be shared 287 with other VPN services and must not compete for bandwidth or 288 other network resources with other TE Tunnels. 290 2. Hard Isolation: This is similar to the above case but without 291 the deterministic characteristics requirements. 293 3. Soft Isolation: The customer requests a VPN service using a 294 set of TE tunnels which can be shared with other VPN services. 296 o VN/Tunnel Sharing - A customer could request a VPN service where 297 new tunnels (or a VN) do not need to be created for each VPN and 298 can be shared across multiple VPNs. Further, the mapping YANG 299 model described in Section 5 of this document can be used to 300 describe the mapping between the VPN service and the tunnels in 301 use. No modification of the properties of a tunnel (or VN) is 302 allowed in this mode: an existing tunnel can only be selected. 304 o VN/Tunnel Modify - This mode allows the modification of the 305 properties of the existing VN/tunnel (e.g., bandwidth). 307 o TE Mapping Template - This mode allows a VPN service to use a 308 mapping template containing constraints and optimization criteria. 309 This allows mapping with the underlay TE characteristics without 310 first creating a VN or tunnels to map. The VPN service could be 311 mapped to a template first. Once the VN/Tunnels are actually 312 created/selected for the VPN service, the mapping based on the 313 actual TE resources is created. 315 2.2. TE Policy 317 The service models could be associated with various policies related 318 to mapping the underlying TE resources. A color could be used to map 319 to the underlying colored TE resources. The desired protection and 320 availability requirements could be specified. 322 2.2.1. Availability Requirement 324 Availability is another service requirement or intent that may 325 influence the selection or provisioning of TE tunnels or a VN to 326 support the requested service. Availability is a probabilistic 327 measure of the length of time that a VPN/VN instance functions 328 without a network failure. 330 The availability level will need to be translated into network 331 specific policies such as the protection/reroute policy associated 332 with a VN or Tunnel. The means by which this is achieved is not in 333 the scope of this document. 335 3. YANG Modeling Approach 337 This section provides how the TE and Service mapping parameters are 338 supported using augmentation of the existing service models (i.e., 339 [I-D.ietf-ccamp-l1csm-yang], [RFC8466], and [RFC8299]). Figure 1 340 shows the scope of the Augmented LxSM Model. 342 +--------------+ +----------------------+ +----------+ 343 | LxSM |o-------| | . . . . | ACTN VN | 344 +--------------+ augment| | +----------+ 345 | | +----------+ 346 +--------------+ | Augmented LxSM Model | . . . . | TE-topo | 347 | TE & Service |------->| | +----------+ 348 | Mapping Types| import | | +----------+ 349 +--------------+ | | . . . . | TE-tunnel| 350 +----------------------+ +----------+ 351 reference 353 Figure 1: Augmented LxSM Model 355 The Augmented LxSM model (where x=1,2,3) augments the basic LxSM 356 model while importing the common TE and Service related parameters 357 (defined in Section 2) grouping information from TE and Service 358 Mapping Types. The TE and Service Mapping Types (ietf-te-service- 359 mapping-types) module is the repository of all common groupings 360 imported by each augmented LxSM model. Any future service models 361 would import this mapping-type common model. 363 The role of the augmented LxSm service model is to expose the mapping 364 relationship between service models and TE models so that VN/VPN 365 service instantiations provided by the underlying TE networks can be 366 viewed outside of the MDSC, for example by an operator who is 367 diagnosing the behavior of the network. It also allows for the 368 customers to access operational state information about how their 369 services are instantiated with the underlying VN, TE topology or TE 370 tunnels provided that the MDSC operator is willing to share that 371 information. This mapping will facilitate a seamless service 372 management operation with underlay-TE network visibility. 374 As seen in Figure 1, the augmented LxSM service model records a 375 mapping between the customer service models and the ACTN VN YANG 376 model. Thus, when the MDSC receives a service request it creates a 377 VN that meets the customer's service objectives with various 378 constraints via TE-topology model [RFC8795], and this relationship is 379 recorded by the Augmented LxSM Model. The model also supports a 380 mapping between a service model and TE-topology or a TE-tunnel. 382 The YANG models defined in this document conforms to the Network 383 Management Datastore Architecture (NMDA) [RFC8342]. 385 3.1. Forward Compatibility 387 The YANG module defined in this document supports three existing 388 service models via augmenting while sharing the common TE and Service 389 Mapping Types. 391 It is possible that new service models will be defined at some future 392 time and that it will be desirable to map them to underlying TE 393 constructs in the same way as the three existing models are 394 augmented. 396 3.2. TE and Network Models 398 The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN 399 Service in the Service Provider Network. It contains information of 400 the Service Provider network and might include allocated resources. 401 It can be used by network controllers to manage and control the VPN 402 Service configuration in the Service Provider network. 404 Similar to service model, the existing network models (i.e., 405 [I-D.ietf-opsawg-l3sm-l3nm], and [I-D.ietf-opsawg-l2nm]) are 406 augmented to include the TE and Service mapping parameters. Figure 2 407 shows the scope of the Augmented LxNM Model. 409 +--------------+ +----------------------+ +----------+ 410 | LxNM |o-------| | . . . . | ACTN VN | 411 +--------------+ augment| | +----------+ 412 | | +----------+ 413 +--------------+ | Augmented LxNM Model | . . . . | TE-topo | 414 | TE & Service |------->| | +----------+ 415 | Mapping Types| import | | +----------+ 416 +--------------+ | | . . . . | TE-tunnel| 417 +----------------------+ +----------+ 418 reference 420 Figure 2: Augmented LxNM Model 422 The Augmented LxNM model (where x=2,3) augments the basic LxNM model 423 while importing the common TE mapping related parameters (defined in 424 Section 2) grouping information from TE and Service Mapping Types. 425 The role of the augmented LxNM network model is to expose the mapping 426 relationship between network models and TE models. 428 4. L3VPN Architecture in the ACTN Context 430 Figure 3 shows the architectural context of this document referencing 431 the ACTN components and interfaces. 433 +----------------------------+ 434 | Customer Service Manager | 435 | +-----------------------+ | 436 | | CNC + | 437 | +-+-------------------+-+ | 438 +----|-------------------|---+ 439 | | 440 |CMI(Augmented L3SM)|CMI(VN) 441 | | 442 +----------------|-------------------|----+ 443 | +--------------|-----------------+ | | 444 | | MDSC | | | | 445 | | | | | | 446 | | +-----------+--------------+ | | | 447 TE-Svc-Map<------+ Service Mapping Function | | | | 448 | | +-----------+--------------+ | | | 449 | | | | | | 450 | +-------+------|-----------------+ | | 451 | | | | | 452 | | |CMI(VN) | | 453 | | | | | 454 | | +--|-------------------|--+ | 455 | | | | MDSC | | | 456 | | | ++-------------------++ | | 457 | | | + Service Mapping +---->TE-Svc-Map 458 | | | ++----------+---------+ | | 459 | | +--|----------|-----------+ | 460 +---------|------|----------|-------------+ 461 | | | 462 | +----+--------+ | 463 | | | | 464 MPI(VPN / TE models)| | | |MPI(TE / L1 models) 465 | | | | 466 +-----|-|---+ +-----|-|----+ 467 IP/MPLS | +--+-+-+ | | +--+-+-+ | Optical Domain 468 Domain | | PNC1 | | | | PNC2 | | Controller 469 Controller | +--+---+ | | +--+---+ | 470 +-----|-----+ +-----|------+ 471 | | 472 V | SBI 473 +---------------------+ | 474 / IP/MPLS Network \ | 475 +-------------------------+ | 476 V 477 +---------------------+ 478 / Optical Network \ 479 +-------------------------+ 481 Figure 3: L3VPN Architecture from the IP+Optical Network Perspective 483 There are three main entities in the ACTN architecture and shown in 484 Figure 3. 486 o CNC: The Customer Network Controller is responsible for generating 487 service requests. In the context of an L3VPN, the CNC uses the 488 Augmented L3SM to express the service request and communicate it 489 to the network operator. 491 o MDSC: This entity is responsible for coordinating a L3VPN service 492 request (expressed via the Augmented L3SM) with the IP/MPLS PNC 493 and the Transport PNC. For TE services, one of the key 494 responsibilities of the MDSC is to coordinate with both the IP PNC 495 and the Transport PNC for the mapping of the Augmented L3VPN 496 Service Model to the ACTN VN model. In the VN/TE-tunnel binding 497 case, the MDSC will need to coordinate with the Transport PNC to 498 dynamically create the TE-tunnels in the transport network as 499 needed. These tunnels are added as links in the IP/MPLS Layer 500 topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 501 tunnels in the IP/MPLS layer, as part of the ACTN VN creation. 503 o PNC: The Provisioning Network Controller is responsible for 504 configuring and operating the network devices. Figure 3 shows two 505 distinct PNCs. 507 * IP/MPLS PNC (PNC1): This entity is responsible for device 508 configuration to create PE-PE L3VPN tunnels for the VPN 509 customer and for the configuration of the L3VPN VRF on the PE 510 nodes. Each network element would select a tunnel based on the 511 configuration. 513 * Transport PNC (PNC2): This entity is responsible for device 514 configuration for TE tunnels in the transport networks. 516 The three main interfaces are shown in Figure 3 and listed below. 518 o CMI: The CNC-MDSC Interface is used to communicate service 519 requests from the customer to the operator. The requests may be 520 expressed as Augmented VPN service requests (L2SM, L3SM), as 521 connectivity requests (L1CSM), or as virtual network requests 522 (ACTN VN). 524 o MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate 525 networks under the control of PNCs. The requests on this 526 interface may use TE tunnel models, TE topology models, VPN 527 network configuration models or layer one connectivity models. 529 o SBI: The Southbound Interface is used by the PNC to control 530 network devices and is out of scope for this document. 532 The TE Service Mapping Model as described in this document can be 533 used to see the mapping between service models and VN models and TE 534 Tunnel/Topology models. That mapping may occur in the CNC if a 535 service request is mapped to a VN request. Or it may occur in the 536 MDSC where a service request is mapped to a TE tunnel, TE topology, 537 or VPN network configuration model. The TE Service Mapping Model may 538 be read from the CNC or MDSC to understand how the mapping has been 539 made and to see the purpose for which network resources are used. 541 As shown in Figure 3, the MDSC may be used recursively. For example, 542 the CNC might map a L3SM request to a VN request that it sends to a 543 recursive MDSC. 545 The high-level control flows for one example are as follows: 547 1. A customer asks for an L3VPN between CE1 and CE2 using the 548 Augmented L3SM model. 550 2. The MDSC considers the service request and local policy to 551 determine if it needs to create a new VN or any TE Topology, and 552 if that is the case, ACTN VN YANG [I-D.ietf-teas-actn-vn-yang] is 553 used to configure a new VN based on this VPN and map the VPN 554 service to the ACTN VN. In case an existing tunnel is to be 555 used, each device will select which tunnel to use and populate 556 this mapping information. 558 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 559 PNC to create a PE-PE tunnel in the IP network mapped to a TE 560 tunnel in the transport network by providing the inter-layer 561 access points and tunnel requirements. The specific service 562 information is passed to the IP/MPLS PNC for the actual VPN 563 configuration and activation. 565 A. The Transport PNC creates the corresponding TE tunnel 566 matching with the access point and egress point. 567 B. The IP/MPLS PNC maps the VPN ID with the corresponding TE 568 tunnel ID to bind these two IDs. 570 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 571 customer. This is not in the scope of this document. 573 4.1. Service Mapping 575 Augmented L3SM and L2SM can be used to request VPN service creation 576 including the creation of sites and corresponding site network access 577 connection between CE and PE. A VPN-ID is used to identify each VPN 578 service ordered by the customer. The ACTN VN can be used further to 579 establish PE-to-PE connectivity between VPN sites belonging to the 580 same VPN service. A VN-ID is used to identify each virtual network 581 established between VPN sites. 583 Once the ACTN VN has been established over the TE network (maybe a 584 new VN, maybe modification of an existing VN, or maybe the use of an 585 unmodified existing VN), the mapping between the VPN service and the 586 ACTN VN service can be created. 588 4.2. Site Mapping 590 The elements in Augmented L3SM and L2SM define site location 591 parameters and constraints such as distance and access diversity that 592 can influence the placement of network attachment points (i.e, 593 virtual network access points (VNAP)). To achieve this, a central 594 directory can be set up to establish the mapping between location 595 parameters and constraints and network attachment point location. 596 Suppose multiple attachment points are matched, the management system 597 can use constraints or other local policy to select the best 598 candidate network attachment points. 600 After a network attachment point is selected, the mapping between VPN 601 site and VNAP can be established as shown in Table 1. 603 +-------+---------+------------------+------------------------+-----+ 604 | Site | Site | Location | Access Diversity | PE | 605 | | Network | (Address, Postal | (Constraint-Type, | | 606 | | Access | Code, State, | Group-id,Target Group- | | 607 | | | City,Country | id) | | 608 | | | Code) | | | 609 +-------+---------+------------------+------------------------+-----+ 610 | SITE1 | ACCESS1 | (,,US,NewYork,) | (10,PE-Diverse,10) | PE1 | 611 +-------+---------+------------------+------------------------+-----+ 612 | SITE2 | ACCESS2 | (,,CN,Beijing,) | (10,PE-Diverse,10) | PE2 | 613 +-------+---------+------------------+------------------------+-----+ 614 | SITE3 | ACCESS3 | (,,UK,London, ) | (12,same-PE,12) | PE4 | 615 +-------+---------+------------------+------------------------+-----+ 616 | SITE4 | ACCESS4 | (,,FR,Paris,) | (20,Bearer-Diverse,20) | PE7 | 617 +-------+---------+------------------+------------------------+-----+ 619 Table 2: : Mapping Between VPN Site and VNAP 621 5. Applicability of TE-Service Mapping in Generic context 623 As discussed in the Introduction Section, the models presented in 624 this document are also applicable generically outside of the ACTN 625 architecture. [RFC8309] defines Customer Service Model between 626 Customer and Service Orchestrator and Service Delivery Model between 627 Service Orchestrator and Network Orchestrator(s). TE-Service mapping 628 models defined in this document can be regarded primarily as Customer 629 Service Model and secondarily as Service Deliver Model. 631 6. YANG Data Trees 633 6.1. Service Mapping Types 635 module: ietf-te-service-mapping-types 636 +--rw te-mapping-templates 637 +--rw te-mapping-template* [id] 638 +--rw id te-mapping-template-id 639 +--rw description? string 640 +--rw map-type? identityref 641 +--rw path-constraints 642 | +--rw te-bandwidth 643 | | +--rw (technology)? 644 | | +--:(generic) 645 | | +--rw generic? te-bandwidth 646 | +--rw link-protection? identityref 647 | +--rw setup-priority? uint8 648 | +--rw hold-priority? uint8 649 | +--rw signaling-type? identityref 650 | +--rw path-metric-bounds 651 | | +--rw path-metric-bound* [metric-type] 652 | | +--rw metric-type identityref 653 | | +--rw upper-bound? uint64 654 | +--rw path-affinities-values 655 | | +--rw path-affinities-value* [usage] 656 | | +--rw usage identityref 657 | | +--rw value? admin-groups 658 | +--rw path-affinity-names 659 | | +--rw path-affinity-name* [usage] 660 | | +--rw usage identityref 661 | | +--rw affinity-name* [name] 662 | | +--rw name string 663 | +--rw path-srlgs-lists 664 | | +--rw path-srlgs-list* [usage] 665 | | +--rw usage identityref 666 | | +--rw values* srlg 667 | +--rw path-srlgs-names 668 | | +--rw path-srlgs-name* [usage] 669 | | +--rw usage identityref 670 | | +--rw names* string 671 | +--rw disjointness? te-path-disjointness 672 +--rw optimizations 673 +--rw (algorithm)? 674 +--:(metric) {path-optimization-metric}? 675 | +--rw optimization-metric* [metric-type] 676 | | +--rw metric-type 677 | | | identityref 678 | | +--rw weight? uint8 679 | | +--rw explicit-route-exclude-objects 680 | | | ... 681 | | +--rw explicit-route-include-objects 682 | | ... 683 | +--rw tiebreakers 684 | +--rw tiebreaker* [tiebreaker-type] 685 | ... 686 +--:(objective-function) 687 {path-optimization-objective-function}? 688 +--rw objective-function 689 +--rw objective-function-type? identityref 691 6.2. Service Models 693 6.2.1. L3SM 695 module: ietf-l3sm-te-service-mapping 696 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services 697 /l3vpn-svc:vpn-service: 698 +--rw te-service-mapping! 699 +--rw te-mapping 700 +--rw map-type? identityref 701 +--rw te-policy 702 | +--rw color? uint32 703 | +--rw protection-type? identityref 704 | +--rw availability-type? identityref 705 +--rw (te)? 706 | +--:(vn) 707 | | +--rw vn* -> /vn:vn/vn/vn-id 708 | +--:(te-topo) 709 | | +--rw vn-topology-id? te-types:te-topology-id 710 | | +--rw abstract-node? 711 | | -> /nw:networks/network/node/node-id 712 | +--:(te-tunnel) 713 | +--rw te-tunnel* te:tunnel-ref 714 | +--rw sr-policy* 715 | [policy-color-ref policy-endpoint-ref] 716 | {sr-policy}? 717 | +--rw policy-color-ref leafref 718 | +--rw policy-endpoint-ref leafref 719 +--rw te-mapping-template-ref? 720 -> /te-mapping-templates/te-mapping-template/id 721 {template}? 722 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 723 /l3vpn-svc:site-network-accesses 724 /l3vpn-svc:site-network-access: 725 +--rw (te)? 726 +--:(vn) 727 | +--rw ap* -> /vn:ap/ap/ap-id 728 +--:(te) 729 +--rw ltp? te-types:te-tp-id 730 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 731 /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile 732 /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes 733 /l3vpn-svc:class: 734 +--rw vnap? -> /vn:ap/ap/vn-ap/vn-ap-id 736 6.2.2. L2SM 738 module: ietf-l2sm-te-service-mapping 739 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services 740 /l2vpn-svc:vpn-service: 741 +--rw te-service-mapping! 742 +--rw te-mapping 743 +--rw map-type? identityref 744 +--rw te-policy 745 | +--rw color? uint32 746 | +--rw protection-type? identityref 747 | +--rw availability-type? identityref 748 +--rw (te)? 749 | +--:(vn) 750 | | +--rw vn* -> /vn:vn/vn/vn-id 751 | +--:(te-topo) 752 | | +--rw vn-topology-id? te-types:te-topology-id 753 | | +--rw abstract-node? 754 | | -> /nw:networks/network/node/node-id 755 | +--:(te-tunnel) 756 | +--rw te-tunnel* te:tunnel-ref 757 | +--rw sr-policy* 758 | [policy-color-ref policy-endpoint-ref] 759 | {sr-policy}? 760 | +--rw policy-color-ref leafref 761 | +--rw policy-endpoint-ref leafref 762 +--rw te-mapping-template-ref? 763 -> /te-mapping-templates/te-mapping-template/id 764 {template}? 765 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 766 /l2vpn-svc:site-network-accesses 767 /l2vpn-svc:site-network-access: 768 +--rw (te)? 769 +--:(vn) 770 | +--rw ap* -> /vn:ap/ap/ap-id 771 +--:(te) 772 +--rw ltp? te-types:te-tp-id 773 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 774 /l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile 775 /l2vpn-svc:qos-profile/l2vpn-svc:custom/l2vpn-svc:classes 776 /l2vpn-svc:class: 777 +--rw vnap? -> /vn:ap/ap/vn-ap/vn-ap-id 779 6.2.3. L1CSM 780 module: ietf-l1csm-te-service-mapping 781 augment /l1csm:l1-connectivity/l1csm:services/l1csm:service: 782 +--rw te-service-mapping! 783 +--rw te-mapping 784 +--rw map-type? identityref 785 +--rw te-policy 786 | +--rw color? uint32 787 | +--rw protection-type? identityref 788 | +--rw availability-type? identityref 789 +--rw (te)? 790 | +--:(vn) 791 | | +--rw vn* -> /vn:vn/vn/vn-id 792 | +--:(te-topo) 793 | | +--rw vn-topology-id? te-types:te-topology-id 794 | | +--rw abstract-node? 795 | | -> /nw:networks/network/node/node-id 796 | +--:(te-tunnel) 797 | +--rw te-tunnel* te:tunnel-ref 798 | +--rw sr-policy* 799 | [policy-color-ref policy-endpoint-ref] 800 | {sr-policy}? 801 | +--rw policy-color-ref leafref 802 | +--rw policy-endpoint-ref leafref 803 +--rw te-mapping-template-ref? 804 -> /te-mapping-templates/te-mapping-template/id 805 {template}? 806 augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni: 807 +--rw (te)? 808 +--:(vn) 809 | +--rw ap* -> /vn:ap/ap/ap-id 810 +--:(te) 811 +--rw ltp? te-types:te-tp-id 813 6.3. Network Models 815 6.3.1. L3NM 816 module: ietf-l3nm-te-service-mapping 817 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 818 /l3vpn-ntw:vpn-service: 819 +--rw te-service-mapping! 820 +--rw te-mapping 821 +--rw map-type? identityref 822 +--rw te-policy 823 | +--rw color? uint32 824 | +--rw protection-type? identityref 825 | +--rw availability-type? identityref 826 +--rw (te)? 827 | +--:(vn) 828 | | +--rw vn* -> /vn:vn/vn/vn-id 829 | +--:(te-topo) 830 | | +--rw vn-topology-id? te-types:te-topology-id 831 | | +--rw abstract-node? 832 | | -> /nw:networks/network/node/node-id 833 | +--:(te-tunnel) 834 | +--rw te-tunnel* te:tunnel-ref 835 | +--rw sr-policy* 836 | [policy-color-ref policy-endpoint-ref] 837 | {sr-policy}? 838 | +--rw policy-color-ref leafref 839 | +--rw policy-endpoint-ref leafref 840 +--rw te-mapping-template-ref? 841 -> /te-mapping-templates/te-mapping-template/id 842 {template}? 843 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 844 /l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes 845 /l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses 846 /l3vpn-ntw:vpn-network-access: 847 +--rw (te)? 848 +--:(vn) 849 | +--rw ap* -> /vn:ap/ap/ap-id 850 +--:(te) 851 +--rw ltp? te-types:te-tp-id 853 6.3.2. L2NM 854 module: ietf-l2nm-te-service-mapping 855 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 856 /l2vpn-ntw:vpn-service: 857 +--rw te-service-mapping! 858 +--rw te-mapping 859 +--rw map-type? identityref 860 +--rw te-policy 861 | +--rw color? uint32 862 | +--rw protection-type? identityref 863 | +--rw availability-type? identityref 864 +--rw (te)? 865 | +--:(vn) 866 | | +--rw vn* -> /vn:vn/vn/vn-id 867 | +--:(te-topo) 868 | | +--rw vn-topology-id? te-types:te-topology-id 869 | | +--rw abstract-node? 870 | | -> /nw:networks/network/node/node-id 871 | +--:(te-tunnel) 872 | +--rw te-tunnel* te:tunnel-ref 873 | +--rw sr-policy* 874 | [policy-color-ref policy-endpoint-ref] 875 | {sr-policy}? 876 | +--rw policy-color-ref leafref 877 | +--rw policy-endpoint-ref leafref 878 +--rw te-mapping-template-ref? 879 -> /te-mapping-templates/te-mapping-template/id 880 {template}? 881 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 882 /l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes 883 /l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses 884 /l2vpn-ntw:vpn-network-access: 885 +--rw (te)? 886 +--:(vn) 887 | +--rw ap* -> /vn:ap/ap/ap-id 888 +--:(te) 889 +--rw ltp? te-types:te-tp-id 891 7. YANG Data Models 893 The YANG codes are as follows: 895 7.1. ietf-te-service-mapping-types 897 file "ietf-te-service-mapping-types@2021-02-20.yang" 898 module ietf-te-service-mapping-types { 899 yang-version 1.1; 900 namespace 901 "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; 903 prefix tsmt; 905 /* Import te-types */ 907 import ietf-te-types { 908 prefix te-types; 909 reference 910 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 911 } 913 /* Import network model */ 915 import ietf-network { 916 prefix nw; 917 reference 918 "RFC 8345: A YANG Data Model for Network Topologies"; 919 } 921 /* Import TE model */ 923 import ietf-te { 924 prefix te; 925 reference 926 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 927 Engineering Tunnels and Interfaces"; 928 } 930 /* Import VN model */ 932 import ietf-vn { 933 prefix vn; 934 reference 935 "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation"; 936 } 938 /* Import Routing */ 940 import ietf-routing { 941 prefix rt; 942 reference 943 "RFC 8349: A YANG Data Model for Routing Management"; 944 } 946 /* Import SR Policy */ 948 import ietf-sr-policy { 949 prefix sr-policy; 950 reference 951 "I-D.ietf-spring-sr-policy-yang: YANG Data Model for Segment 952 Routing Policy"; 953 } 955 organization 956 "IETF Traffic Engineering Architecture and Signaling (TEAS) 957 Working Group"; 958 contact 959 "WG Web: 960 WG List: 962 Editor: Young Lee 963 964 Editor: Dhruv Dhody 965 966 Editor: Qin Wu 967 "; 968 description 969 "This module contains a YANG module for TE & Service mapping 970 parameters and policies as a common grouping applicable to 971 variuous service models (e.g., L1CSM, L2SM, L3SM, etc.) 973 Copyright (c) 2021 IETF Trust and the persons identified as 974 authors of the code. All rights reserved. 976 Redistribution and use in source and binary forms, with or 977 without modification, is permitted pursuant to, and subject to 978 the license terms contained in, the Simplified BSD License set 979 forth in Section 4.c of the IETF Trust's Legal Provisions 980 Relating to IETF Documents 981 (https://trustee.ietf.org/license-info). 983 This version of this YANG module is part of RFC XXXX; see the 984 RFC itself for full legal notices. 986 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 987 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 988 'MAY', and 'OPTIONAL' in this document are to be interpreted as 989 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 990 they appear in all capitals, as shown here."; 992 revision 2021-02-20 { 993 description 994 "Initial revision."; 995 reference 996 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 997 } 998 /* 999 * Features 1000 */ 1002 feature template { 1003 description 1004 "Support TE mapping templates."; 1005 } 1007 feature sr-policy { 1008 description 1009 "Support SR Policy."; 1010 } 1012 /* 1013 * Identity for map-type 1014 */ 1016 identity map-type { 1017 description 1018 "Base identity from which specific map types are derived."; 1019 } 1021 identity new { 1022 base map-type; 1023 description 1024 "The new VN/tunnels are binded to the service."; 1025 } 1027 identity hard-isolation { 1028 base new; 1029 description 1030 "Hard isolation."; 1031 } 1033 identity detnet-hard-isolation { 1034 base hard-isolation; 1035 description 1036 "Hard isolation with deterministic characteristics."; 1037 } 1039 identity soft-isolation { 1040 base new; 1041 description 1042 "Soft-isolation."; 1043 } 1045 identity select { 1046 base map-type; 1047 description 1048 "The VPN service selects an existing tunnel with no 1049 modification."; 1050 } 1052 identity modify { 1053 base map-type; 1054 description 1055 "The VPN service selects an existing tunnel and allows to modify 1056 the properties of the tunnel (e.g., b/w)"; 1057 } 1059 identity none { 1060 base map-type; 1061 description 1062 "The VPN service is not mapped to any underlying TE"; 1063 } 1065 /* 1066 * Identity for availability-type 1067 */ 1069 identity availability-type { 1070 description 1071 "Base identity from which specific map types are derived."; 1072 } 1074 identity level-1 { 1075 base availability-type; 1076 description 1077 "level 1: 99.9999%"; 1078 } 1080 identity level-2 { 1081 base availability-type; 1082 description 1083 "level 2: 99.999%"; 1084 } 1086 identity level-3 { 1087 base availability-type; 1088 description 1089 "level 3: 99.99%"; 1090 } 1092 identity level-4 { 1093 base availability-type; 1094 description 1095 "level 4: 99.9%"; 1096 } 1098 identity level-5 { 1099 base availability-type; 1100 description 1101 "level 5: 99%"; 1102 } 1104 /* 1105 * Typedef 1106 */ 1108 typedef te-mapping-template-id { 1109 type string; 1110 description 1111 "Identifier for a TE mapping template."; 1112 } 1114 /* 1115 * Groupings 1116 */ 1118 grouping te-ref { 1119 description 1120 "The reference to TE."; 1121 choice te { 1122 description 1123 "How the VPN is mapped to a VN, Topology, Tunnel, SR Policy 1124 etc."; 1125 case vn { 1126 leaf-list vn { 1127 type leafref { 1128 path "/vn:vn/vn:vn/vn:vn-id"; 1129 } 1130 description 1131 "The reference to VN"; 1132 reference 1133 "RFC 8453: Framework for Abstraction and Control of TE 1134 Networks (ACTN)"; 1135 } 1136 } 1137 case te-topo { 1138 leaf vn-topology-id { 1139 type te-types:te-topology-id; 1140 description 1141 "An identifier to the TE Topology Model where the abstract 1142 nodes and links of the Topology can be found for Type 2 1143 VNs as defined in RFC 8453"; 1144 reference 1145 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1146 Topologies 1147 RFC 8453: Framework for Abstraction and Control of TE 1148 Networks (ACTN)"; 1149 } 1150 leaf abstract-node { 1151 type leafref { 1152 path "/nw:networks/nw:network/nw:node/nw:node-id"; 1153 } 1154 description 1155 "A reference to the abstract node in TE Topology"; 1156 reference 1157 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1158 Topologies"; 1159 } 1160 } 1161 case te-tunnel { 1162 leaf-list te-tunnel { 1163 type te:tunnel-ref; 1164 description 1165 "Reference to TE Tunnels"; 1166 reference 1167 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1168 Engineering Tunnels and Interfaces"; 1169 } 1170 list sr-policy { 1171 if-feature "sr-policy"; 1172 key "policy-color-ref policy-endpoint-ref"; 1173 description 1174 "SR Policy"; 1175 leaf policy-color-ref { 1176 type leafref { 1177 path 1178 "/rt:routing/sr-policy:segment-routing" 1179 + "/sr-policy:traffic-engineering/sr-policy:policies" 1180 + "/sr-policy:policy/sr-policy:color"; 1181 } 1182 description 1183 "Reference to sr-policy color"; 1184 } 1185 leaf policy-endpoint-ref { 1186 type leafref { 1187 path 1188 "/rt:routing/sr-policy:segment-routing" 1189 + "/sr-policy:traffic-engineering/sr-policy:policies" 1190 + "/sr-policy:policy/sr-policy:endpoint"; 1191 } 1192 description 1193 "Reference to sr-policy endpoint"; 1194 } 1195 } 1196 } 1197 } 1198 leaf te-mapping-template-ref { 1199 if-feature "template"; 1200 type leafref { 1201 path "/tsmt:te-mapping-templates/" 1202 + "tsmt:te-mapping-template/tsmt:id"; 1203 } 1204 description 1205 "An identifier to the TE Mapping Template where the TE 1206 constraints and optimization criteria are specified."; 1207 } 1208 } 1210 //grouping 1212 grouping te-endpoint-ref { 1213 description 1214 "The reference to TE endpoints."; 1215 choice te { 1216 description 1217 "How the TE endpoint is defined by VN's AP or TE's LTP"; 1218 case vn { 1219 leaf-list ap { 1220 type leafref { 1221 path "/vn:ap/vn:ap/vn:ap-id"; 1222 } 1223 description 1224 "The reference to VN's AP"; 1225 reference 1226 "RFC 8453: Framework for Abstraction and Control of TE 1227 Networks (ACTN)"; 1228 } 1229 } 1230 case te { 1231 leaf ltp { 1232 type te-types:te-tp-id; 1233 description 1234 "Reference LTP in the TE-topology"; 1235 reference 1236 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1237 Topologies"; 1239 } 1240 } 1241 } 1242 } 1244 //grouping 1246 grouping vnap-ref { 1247 description 1248 "The reference to VNAP."; 1249 leaf vnap { 1250 type leafref { 1251 path "/vn:ap/vn:ap/vn:vn-ap/vn:vn-ap-id"; 1252 } 1253 description 1254 "The reference to VNAP"; 1255 reference 1256 "RFC 8453: Framework for Abstraction and Control of TE 1257 Networks (ACTN)"; 1258 } 1259 } 1261 //grouping 1263 grouping te-policy { 1264 description 1265 "Various underlying TE policy requirements"; 1266 leaf color { 1267 type uint32; 1268 description 1269 "Maps to the underlying colored TE resources"; 1270 } 1271 leaf protection-type { 1272 type identityref { 1273 base te-types:lsp-protection-type; 1274 } 1275 description 1276 "Desired protection level for the underlying 1277 TE resources"; 1278 } 1279 leaf availability-type { 1280 type identityref { 1281 base availability-type; 1282 } 1283 description 1284 "Availability Requirement for the Service"; 1285 } 1286 } 1287 //grouping 1289 grouping te-mapping { 1290 description 1291 "Mapping between Services and TE"; 1292 container te-mapping { 1293 description 1294 "Mapping between Services and TE"; 1295 leaf map-type { 1296 type identityref { 1297 base map-type; 1298 } 1299 description 1300 "Isolation Requirements, Tunnel Bind or 1301 Tunnel Selection"; 1302 } 1303 container te-policy { 1304 uses te-policy; 1305 description 1306 "Desired Underlying TE Policy"; 1307 } 1308 uses te-ref; 1309 } 1310 } 1312 //grouping 1314 container te-mapping-templates { 1315 description 1316 "The TE constraints and optimization criteria"; 1317 list te-mapping-template { 1318 key "id"; 1319 leaf id { 1320 type te-mapping-template-id; 1321 description 1322 "Identification of the Template to be used."; 1323 } 1324 leaf description { 1325 type string; 1326 description 1327 "Description of the template."; 1328 } 1329 leaf map-type { 1330 type identityref { 1331 base map-type; 1332 } 1333 must "0 = derived-from-or-self(.,'none')" { 1334 error-message "The map-type must be other than " 1335 + "none"; 1336 } 1337 description 1338 "Map type for the VN/Tunnel creation/ 1339 selection."; 1340 } 1341 uses te-types:generic-path-constraints; 1342 uses te-types:generic-path-optimization; 1343 description 1344 "List for templates."; 1345 } 1346 } 1347 } 1348 1350 7.2. Service Models 1352 7.2.1. ietf-l3sm-te-service-mapping 1354 file "ietf-l3sm-te-service-mapping@2021-02-20.yang" 1355 module ietf-l3sm-te-service-mapping { 1356 yang-version 1.1; 1357 namespace 1358 "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; 1359 prefix l3-tsm; 1361 import ietf-te-service-mapping-types { 1362 prefix tsmt; 1363 reference 1364 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1365 } 1366 import ietf-l3vpn-svc { 1367 prefix l3vpn-svc; 1368 reference 1369 "RFC 8299: YANG Data Model for L3VPN Service Delivery"; 1370 } 1372 organization 1373 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1374 Working Group"; 1375 contact 1376 "WG Web: 1377 WG List: 1379 Editor: Young Lee 1380 1381 Editor: Dhruv Dhody 1382 1384 Editor: Qin Wu 1385 "; 1386 description 1387 "This module contains a YANG module for the mapping of Layer 3 1388 Service Model (L3SM) to the TE and VN. 1390 Copyright (c) 2020 IETF Trust and the persons identified as 1391 authors of the code. All rights reserved. 1393 Redistribution and use in source and binary forms, with or 1394 without modification, is permitted pursuant to, and subject to 1395 the license terms contained in, the Simplified BSD License set 1396 forth in Section 4.c of the IETF Trust's Legal Provisions 1397 Relating to IETF Documents 1398 (https://trustee.ietf.org/license-info). 1400 This version of this YANG module is part of RFC XXXX; see the 1401 RFC itself for full legal notices. 1403 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1404 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1405 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1406 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1407 they appear in all capitals, as shown here."; 1409 revision 2021-02-20 { 1410 description 1411 "Initial revision."; 1412 reference 1413 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1414 } 1416 /* 1417 * Augmentation to L3SM 1418 */ 1420 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services" 1421 + "/l3vpn-svc:vpn-service" { 1422 description 1423 "L3SM augmented to include TE parameters and mapping"; 1424 container te-service-mapping { 1425 presence "Indicates L3 service to TE mapping"; 1426 description 1427 "Container to augment l3sm to TE parameters and mapping"; 1428 uses tsmt:te-mapping; 1429 } 1430 } 1431 //augment 1433 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1434 + "/l3vpn-svc:site-network-accesses" 1435 + "/l3vpn-svc:site-network-access" { 1436 description 1437 "This augment is only valid for TE mapping of L3SM network-access 1438 to TE endpoints"; 1439 uses tsmt:te-endpoint-ref; 1440 } 1442 //augment 1444 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1445 + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile" 1446 + "/l3vpn-svc:qos-profile/l3vpn-svc:custom" 1447 + "/l3vpn-svc:classes/l3vpn-svc:class" { 1448 when './l3vpn-svc:bandwidth/l3vpn-svc:end-to-end' { 1449 description 1450 "applicable only with end-to-end"; 1451 } 1452 description 1453 "This augment is only valid for the custom qos-profile with 1454 end-to-end set"; 1455 uses tsmt:vnap-ref; 1456 } 1457 } 1458 1460 7.2.2. ietf-l2sm-te-service-mapping 1462 file "ietf-l2sm-te-service-mapping@2021-02-20.yang" 1463 module ietf-l2sm-te-service-mapping { 1464 yang-version 1.1; 1465 namespace 1466 "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; 1467 prefix l2-tsm; 1469 import ietf-te-service-mapping-types { 1470 prefix tsmt; 1471 reference 1472 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1473 } 1474 import ietf-l2vpn-svc { 1475 prefix l2vpn-svc; 1476 reference 1477 "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network 1478 (L2VPN) Service Delivery"; 1480 } 1482 organization 1483 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1484 Working Group"; 1485 contact 1486 "WG Web: 1487 WG List: 1489 Editor: Young Lee 1490 1491 Editor: Dhruv Dhody 1492 1493 Editor: Qin Wu 1494 "; 1495 description 1496 "This module contains a YANG module for the mapping of Layer 2 1497 Service Model (L2SM) to the TE and VN. 1499 Copyright (c) 2021 IETF Trust and the persons identified as 1500 authors of the code. All rights reserved. 1502 Redistribution and use in source and binary forms, with or 1503 without modification, is permitted pursuant to, and subject to 1504 the license terms contained in, the Simplified BSD License set 1505 forth in Section 4.c of the IETF Trust's Legal Provisions 1506 Relating to IETF Documents 1507 (https://trustee.ietf.org/license-info). 1509 This version of this YANG module is part of RFC XXXX; see the 1510 RFC itself for full legal notices. 1512 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1513 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1514 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1515 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1516 they appear in all capitals, as shown here."; 1518 revision 2021-02-20 { 1519 description 1520 "Initial revision."; 1521 reference 1522 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1523 } 1525 /* 1526 * Augmentation to L2SM 1527 */ 1529 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/" 1530 + "l2vpn-svc:vpn-service" { 1531 description 1532 "L2SM augmented to include TE parameters and mapping"; 1533 container te-service-mapping { 1534 presence "indicates L2 service to te mapping"; 1535 description 1536 "Container to augment L2SM to TE parameters and mapping"; 1537 uses tsmt:te-mapping; 1538 } 1539 } 1541 //augment 1543 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1544 + "/l2vpn-svc:site-network-accesses" 1545 + "/l2vpn-svc:site-network-access" { 1546 description 1547 "This augment the L2SM network-access with a reference 1548 to TE endpoints when underlying TE is used"; 1549 uses tsmt:te-endpoint-ref; 1550 } 1552 //augment 1554 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1555 + "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile" 1556 + "/l2vpn-svc:qos-profile/l2vpn-svc:custom" 1557 + "/l2vpn-svc:classes/l2vpn-svc:class" { 1558 when './l2vpn-svc:bandwidth/l2vpn-svc:end-to-end' { 1559 description 1560 "applicable only with end-to-end"; 1561 } 1562 description 1563 "This augment is only valid for the custom qos-profile with 1564 end-to-end set"; 1565 uses tsmt:vnap-ref; 1566 } 1567 } 1568 1570 7.2.3. ietf-l1csm-te-service-mapping 1572 file "ietf-l1csm-te-service-mapping@2021-02-20.yang" 1573 module ietf-l1csm-te-service-mapping { 1574 yang-version 1.1; 1575 namespace 1576 "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; 1578 prefix l1-tsm; 1580 import ietf-te-service-mapping-types { 1581 prefix tsmt; 1582 reference 1583 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1584 } 1585 import ietf-l1csm { 1586 prefix l1csm; 1587 reference 1588 "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity 1589 Service Model (L1CSM)"; 1590 } 1592 organization 1593 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1594 Working Group"; 1595 contact 1596 "WG Web: 1597 WG List: 1599 Editor: Young Lee 1600 1601 Editor: Dhruv Dhody 1602 1603 Editor: Qin Wu 1604 "; 1605 description 1606 "This module contains a YANG module for the mapping of 1607 Layer 1 Connectivity Service Module (L1CSM) to the TE and VN 1609 Copyright (c) 2021 IETF Trust and the persons identified as 1610 authors of the code. All rights reserved. 1612 Redistribution and use in source and binary forms, with or 1613 without modification, is permitted pursuant to, and subject to 1614 the license terms contained in, the Simplified BSD License set 1615 forth in Section 4.c of the IETF Trust's Legal Provisions 1616 Relating to IETF Documents 1617 (https://trustee.ietf.org/license-info). 1619 This version of this YANG module is part of RFC XXXX; see the 1620 RFC itself for full legal notices. 1622 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1623 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1624 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1625 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1626 they appear in all capitals, as shown here."; 1628 revision 2021-02-20 { 1629 description 1630 "Initial revision."; 1631 reference 1632 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1633 } 1635 /* 1636 * Augmentation to L1CSM 1637 */ 1639 augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" { 1640 description 1641 "L1CSM augmented to include TE parameters and mapping"; 1642 container te-service-mapping { 1643 presence "Indicates L1 service to TE mapping"; 1644 description 1645 "Container to augment L1CSM to TE parameters and mapping"; 1646 uses tsmt:te-mapping; 1647 } 1648 } 1650 //augment 1652 augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/" 1653 + "l1csm:uni" { 1654 description 1655 "This augment the L1CSM UNI with a reference 1656 to TE endpoints"; 1657 uses tsmt:te-endpoint-ref; 1658 } 1660 //augment 1661 } 1663 1665 7.3. Network Models 1667 7.3.1. ietf-l3nm-te-service-mapping 1669 file "ietf-l3nm-te-service-mapping@202-02-20.yang" 1670 module ietf-l3nm-te-service-mapping { 1671 yang-version 1.1; 1672 namespace 1673 "urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping"; 1675 prefix l3nm-tsm; 1677 import ietf-te-service-mapping-types { 1678 prefix tsmt; 1679 reference 1680 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1681 } 1682 import ietf-l3vpn-ntw { 1683 prefix l3vpn-ntw; 1684 reference 1685 "I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model"; 1686 } 1688 organization 1689 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1690 Working Group"; 1691 contact 1692 "WG Web: 1693 WG List: 1695 Editor: Young Lee 1696 1697 Editor: Dhruv Dhody 1698 1699 Editor: Qin Wu 1700 "; 1701 description 1702 "This module contains a YANG module for the mapping of Layer 3 1703 Network Model (L3NM) to the TE and VN. 1705 Copyright (c) 2021 IETF Trust and the persons identified as 1706 authors of the code. All rights reserved. 1708 Redistribution and use in source and binary forms, with or 1709 without modification, is permitted pursuant to, and subject to 1710 the license terms contained in, the Simplified BSD License set 1711 forth in Section 4.c of the IETF Trust's Legal Provisions 1712 Relating to IETF Documents 1713 (https://trustee.ietf.org/license-info). 1715 This version of this YANG module is part of RFC XXXX; see the 1716 RFC itself for full legal notices. 1718 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1719 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1720 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1721 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1722 they appear in all capitals, as shown here."; 1724 revision 2021-02-20 { 1725 description 1726 "Initial revision."; 1727 reference 1728 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1729 } 1731 /* 1732 * Augmentation to L3NM 1733 */ 1735 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1736 + "/l3vpn-ntw:vpn-service" { 1737 description 1738 "L3SM augmented to include TE parameters and mapping"; 1739 container te-service-mapping { 1740 presence "Indicates L3 network to TE mapping"; 1741 description 1742 "Container to augment l3nm to TE parameters and mapping"; 1743 uses tsmt:te-mapping; 1744 } 1745 } 1747 //augment 1749 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1750 + "/l3vpn-ntw:vpn-service" 1751 + "/l3vpn-ntw:vpn-nodes/l3vpn-ntw:vpn-node" 1752 + "/l3vpn-ntw:vpn-network-accesses" 1753 + "/l3vpn-ntw:vpn-network-access" { 1754 description 1755 "This augment the L3NM network-access with a reference 1756 to TE endpoints when underlying TE is used"; 1757 uses tsmt:te-endpoint-ref; 1758 } 1760 //augment 1761 } 1762 1764 7.3.2. ietf-l2nm-te-service-mapping 1766 file "ietf-l2nm-te-service-mapping@2021-02-20.yang" 1767 module ietf-l2nm-te-service-mapping { 1768 yang-version 1.1; 1769 namespace 1770 "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping"; 1771 prefix l2nm-tsm; 1772 import ietf-te-service-mapping-types { 1773 prefix tsmt; 1774 reference 1775 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1776 } 1777 import ietf-l2vpn-ntw { 1778 prefix l2vpn-ntw; 1779 reference 1780 "I-D.ietf-opsawg-l2nm: A Layer 2 VPN Network YANG Model"; 1781 } 1783 organization 1784 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1785 Working Group"; 1786 contact 1787 "WG Web: 1788 WG List: 1790 Editor: Young Lee 1791 1792 Editor: Dhruv Dhody 1793 1794 Editor: Qin Wu 1795 "; 1796 description 1797 "This module contains a YANG module for the mapping of Layer 2 1798 Network Model (L2NM) to the TE and VN. 1800 Copyright (c) 2021 IETF Trust and the persons identified as 1801 authors of the code. All rights reserved. 1803 Redistribution and use in source and binary forms, with or 1804 without modification, is permitted pursuant to, and subject to 1805 the license terms contained in, the Simplified BSD License set 1806 forth in Section 4.c of the IETF Trust's Legal Provisions 1807 Relating to IETF Documents 1808 (https://trustee.ietf.org/license-info). 1810 This version of this YANG module is part of RFC XXXX; see the 1811 RFC itself for full legal notices. 1813 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1814 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1815 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1816 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1817 they appear in all capitals, as shown here."; 1819 revision 2021-02-20 { 1820 description 1821 "Initial revision."; 1822 reference 1823 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1824 } 1826 /* 1827 * Augmentation to L2NM 1828 */ 1830 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1831 + "/l2vpn-ntw:vpn-service" { 1832 description 1833 "L2SM augmented to include TE parameters and mapping"; 1834 container te-service-mapping { 1835 presence "Indicates L2 network to TE mapping"; 1836 description 1837 "Container to augment l2nm to TE parameters and mapping"; 1838 uses tsmt:te-mapping; 1839 } 1840 } 1842 //augment 1844 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1845 + "/l2vpn-ntw:vpn-service" 1846 + "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node" 1847 + "/l2vpn-ntw:vpn-network-accesses" 1848 + "/l2vpn-ntw:vpn-network-access" { 1849 description 1850 "This augment the L2NM network-access with a reference 1851 to TE endpoints when underlying TE is used"; 1852 uses tsmt:te-endpoint-ref; 1853 } 1855 //augment 1856 } 1857 1859 8. Security Considerations 1861 The YANG modules defined in this document is designed to be accessed 1862 via network management protocol such as NETCONF [RFC6241] or RESTCONF 1863 [RFC8040]. The lowest NETCONF layer is the secure transport layer 1864 and the mandatory-to-implement secure transport is SSH [RFC6242]. 1865 The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement 1866 secure transport is TLS [RFC8446] 1867 The NETCONF access control model [RFC8341] provides the means to 1868 restrict access for particular NETCONF or RESTCONF users to a pre- 1869 configured subset of all available NETCONF or RESTCONF protocol 1870 operations and content. 1872 There are a number of data nodes defined in the YANG moduleS which 1873 are writable/creatable/deletable (i.e., config true, which is the 1874 default). These data nodes may be considered sensitive or vulnerable 1875 in some network environments. Write operations (e.g., ) 1876 to these data nodes without proper protection can have a negative 1877 effect on network operations. These are the subtrees and data nodes 1878 and their sensitivity/vulnerability: 1880 o /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1881 - configure TE Service mapping. 1883 o /l3vpn-svc/sites/site/site-network-accesses/site-network-access/ 1884 te/ - configure TE Endpoint mapping. 1886 o /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1887 - configure TE Service mapping. 1889 o /l2vpn-svc/sites/site/site-network-accesses/site-network-access/ 1890 te/ - configure TE Endpoint mapping. 1892 o /l1-connectivity/services/service/te-service-mapping/te-mapping/ - 1893 configure TE Service mapping. 1895 o /l1-connectivity/access/unis/uni/te/ - configure TE Endpoint 1896 mapping. 1898 o /l3vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1899 - configure TE Network mapping. 1901 o /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1902 network-accesses/vpn-network-access/te/ - configure TE Endpoint 1903 mapping. 1905 o /l2vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1906 - configure TE Network mapping. 1908 o /l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1909 network-accesses/vpn-network-access/te/ - configure TE Endpoint 1910 mapping. 1912 Unauthorized access to above list can adversely affect the VPN 1913 service. 1915 Some of the readable data nodes in the YANG module may be considered 1916 sensitive or vulnerable in some network environments. It is thus 1917 important to control read access (e.g., via get, get-config, or 1918 notification) to these data nodes. The TE related parameters 1919 attached to the VPN service can leak sensitive information about the 1920 network. This is applicable to all elements in the yang models 1921 defined in this document. 1923 This document has no RPC defined. 1925 9. IANA Considerations 1927 This document request the IANA to register six URIs in the "IETF XML 1928 Registry" [RFC3688]. Following the format in RFC 3688, the following 1929 registrations are requested - 1931 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1932 Registrant Contact: The IESG. 1933 XML: N/A, the requested URI is an XML namespace. 1935 URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 1936 Registrant Contact: The IESG. 1937 XML: N/A, the requested URI is an XML namespace. 1939 URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 1940 Registrant Contact: The IESG. 1941 XML: N/A, the requested URI is an XML namespace. 1943 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 1944 Registrant Contact: The IESG. 1945 XML: N/A, the requested URI is an XML namespace. 1947 URI: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 1948 Registrant Contact: The IESG. 1949 XML: N/A, the requested URI is an XML namespace. 1951 URI: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 1952 Registrant Contact: The IESG. 1953 XML: N/A, the requested URI is an XML namespace. 1955 This document request the IANA to register six YANG modules in the 1956 "YANG Module Names" registry [RFC6020], as follows - 1957 Name: ietf-te-service-mapping-types 1958 Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1959 Prefix: tsmt 1960 Reference: [This.I-D] 1962 Name: ietf-l3sm-te-service-mapping 1963 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 1964 Prefix: l3-tsm 1965 Reference: [This.I-D] 1967 Name: ietf-l2sm-te-service-mapping 1968 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 1969 Prefix: l2-tsm 1970 Reference: [This.I-D] 1972 Name: ietf-l1csm-te-service-mapping 1973 Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 1974 Prefix: l1-tsm 1975 Reference: [This.I-D] 1977 Name: ietf-l3nm-te-service-mapping 1978 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 1979 Prefix: l3nm-tsm 1980 Reference: [This.I-D] 1982 Name: ietf-l2nm-te-service-mapping 1983 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 1984 Prefix: l2nm-tsm 1985 Reference: [This.I-D] 1987 10. Acknowledgements 1989 We thank Diego Caviglia, and Igor Bryskin for useful discussions and 1990 motivation for this work. 1992 11. References 1994 11.1. Normative References 1996 [I-D.ietf-ccamp-l1csm-yang] 1997 Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli, 1998 "A YANG Data Model for L1 Connectivity Service Model 1999 (L1CSM)", draft-ietf-ccamp-l1csm-yang-13 (work in 2000 progress), November 2020. 2002 [I-D.ietf-opsawg-l2nm] 2003 barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil, 2004 L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- 2005 ietf-opsawg-l2nm-01 (work in progress), November 2020. 2007 [I-D.ietf-opsawg-l3sm-l3nm] 2008 barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. 2009 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 2010 opsawg-l3sm-l3nm-05 (work in progress), October 2020. 2012 [I-D.ietf-spring-sr-policy-yang] 2013 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 2014 Matsushima, S., and V. Beeram, "YANG Data Model for 2015 Segment Routing Policy", draft-ietf-spring-sr-policy- 2016 yang-00 (work in progress), September 2020. 2018 [I-D.ietf-teas-actn-vn-yang] 2019 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 2020 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 2021 teas-actn-vn-yang-10 (work in progress), November 2020. 2023 [I-D.ietf-teas-yang-te] 2024 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2025 "A YANG Data Model for Traffic Engineering Tunnels, Label 2026 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 2027 (work in progress), July 2020. 2029 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2030 Requirement Levels", BCP 14, RFC 2119, 2031 DOI 10.17487/RFC2119, March 1997, 2032 . 2034 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2035 DOI 10.17487/RFC3688, January 2004, 2036 . 2038 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2039 the Network Configuration Protocol (NETCONF)", RFC 6020, 2040 DOI 10.17487/RFC6020, October 2010, 2041 . 2043 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2044 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2045 . 2047 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 2048 Ceccarelli, D., and X. Zhang, "Problem Statement and 2049 Architecture for Information Exchange between 2050 Interconnected Traffic-Engineered Networks", BCP 206, 2051 RFC 7926, DOI 10.17487/RFC7926, July 2016, 2052 . 2054 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2055 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2056 . 2058 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2059 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2060 . 2062 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2063 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2064 May 2017, . 2066 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2067 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2068 DOI 10.17487/RFC8299, January 2018, 2069 . 2071 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2072 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2073 . 2075 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2076 Access Control Model", STD 91, RFC 8341, 2077 DOI 10.17487/RFC8341, March 2018, 2078 . 2080 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2081 and R. Wilton, "Network Management Datastore Architecture 2082 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2083 . 2085 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2086 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2087 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2088 2018, . 2090 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 2091 Routing Management (NMDA Version)", RFC 8349, 2092 DOI 10.17487/RFC8349, March 2018, 2093 . 2095 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2096 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2097 . 2099 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2100 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2101 DOI 10.17487/RFC8453, August 2018, 2102 . 2104 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2105 Data Model for Layer 2 Virtual Private Network (L2VPN) 2106 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2107 2018, . 2109 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2110 "Common YANG Data Types for Traffic Engineering", 2111 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2112 . 2114 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2115 O. Gonzalez de Dios, "YANG Data Model for Traffic 2116 Engineering (TE) Topologies", RFC 8795, 2117 DOI 10.17487/RFC8795, August 2020, 2118 . 2120 11.2. Informative References 2122 [I-D.ietf-teas-actn-yang] 2123 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 2124 Shin, J., and S. Belotti, "Applicability of YANG models 2125 for Abstraction and Control of Traffic Engineered 2126 Networks", draft-ietf-teas-actn-yang-06 (work in 2127 progress), August 2020. 2129 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2130 and A. Bierman, Ed., "Network Configuration Protocol 2131 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2132 . 2134 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 2135 Classification", RFC 8199, DOI 10.17487/RFC8199, July 2136 2017, . 2138 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2139 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2140 . 2142 Appendix A. Examples 2144 This section details a few examples on how the TE-service mapping is 2145 used in various scenarios. 2147 Example 1: An L3VPN service with an optimization criteria for the 2148 underlying TE as delay can be set in the mapping template and then 2149 augmented to the L3SM service. 2151 { 2152 "te-mapping-template":[ 2153 { 2154 "id": "delay", 2155 "map-type": "select", 2156 "optimizations": 2157 { 2158 "algorithm":{ 2159 "optimization-metric": [ 2160 { 2161 "metric-type":"path-metric-delay-average" 2162 } 2163 ] 2164 } 2165 } 2166 } 2167 ] 2168 } 2170 The L3SM service can map it to the existing least delay TE resources 2171 in form of a VN or TE-tunnels. 2173 Example 2: An L2VPN service with a bandwidth constraint and a hop- 2174 limit criteria for the underlying TE can be set in the mapping 2175 template and then augmented to the L2SM service. 2177 { 2178 "te-mapping-template":[ 2179 { 2180 "id": "bw-hop", 2181 "map-type": "new", 2182 "path-constraints":{ 2183 "te-bandwidth":{ 2184 "generic":10000 2185 }, 2186 "path-metric-bounds":{ 2187 "path-metric-bound":[ 2188 { 2189 "metric-type":"path-metric-hop", 2190 "upper-bound":10 2191 } 2192 ] 2193 } 2194 } 2195 ] 2196 } 2198 The L2SM service can map it to a new TE resources in form of a VN or 2199 TE-tunnels. 2201 Example 3: A VN (VN1) could be created before hand and then 2202 explicitly mapped to the L2VPN service as shown below. 2204 2205 2206 2207 2208 VPN1 2209 2210 2211 select 2212 2213 VN1 2214 2215 2216 2217 2218 2219 2221 Example 4: A VPN service may want different optimization criteria for 2222 some of its sites. The template does not allow for such a case but 2223 it can be achieved by creating the TE resources separately and then 2224 mapping them to the service. 2226 Appendix B. Discussion 2228 o While the support to bind a tunnel to the VPN is supported. We do 2229 not have a mechanism to map traffic to a path. The input can come 2230 from the user. E.g. the enterprise customer can tell, the traffic 2231 from source X on port Y should go with delay less than Z. Further 2232 discussion is required on how and where to model these. 2234 o Support for Calendaring and scheduling TE resources. 2236 Appendix C. Contributor Addresses 2237 Adrian Farrel 2238 Old Dog Consulting 2240 EMail: adrian@olddog.co.uk 2242 Italo Busi 2243 Huawei Technologies 2245 EMail: Italo.Busi@huawei.com 2247 Haomian Zheng 2248 Huawei Technologies 2250 EMail: zhenghaomian@huawei.com 2252 Anton Snitser 2253 Sedonasys 2255 EMail: antons@sedonasys.com 2257 SAMIER BARGUIL GIRALDO 2258 Telefonica 2260 EMail: samier.barguilgiraldo.ext@telefonica.com 2262 Oscar Gonzalez de Dios 2263 Telefonica 2265 EMail: oscar.gonzalezdedios@telefonica.com 2267 Carlo Perocchio 2268 Ericsson 2270 EMail: carlo.perocchio@ericsson.com 2272 Kenichi Ogaki 2273 KDDI 2274 Email: ke-oogaki@kddi.com 2276 Authors' Addresses 2278 Young Lee (editor) 2279 Samsung Electronics 2281 Email: younglee.tx@gmail.com 2282 Dhruv Dhody (editor) 2283 Huawei Technologies 2284 Divyashree Techno Park, Whitefield 2285 Bangalore, Karnataka 560066 2286 India 2288 Email: dhruv.ietf@gmail.com 2290 Giuseppe Fioccola 2291 Huawei Technologies 2293 Email: giuseppe.fioccola@huawei.com 2295 Qin Wu (editor) 2296 Huawei Technologies 2298 Email: bill.wu@huawei.com 2300 Daniele Ceccarelli 2301 Ericsson 2302 Torshamnsgatan,48 2303 Stockholm, Sweden 2305 Email: daniele.ceccarelli@ericsson.com 2307 Jeff Tantsura 2308 Apstra 2310 Email: jefftant.ietf@gmail.com