idnits 2.17.1 draft-ietf-teas-te-service-mapping-yang-10.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 18 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 718 has weird spacing: '...ic-type ide...' == Line 722 has weird spacing: '...w usage ide...' == Line 728 has weird spacing: '...rw name str...' == Line 735 has weird spacing: '...w usage ide...' == Line 789 has weird spacing: '...int-ref lea...' == (4 more instances...) -- The document date (7 March 2022) is 781 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 274, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-16 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-12 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-policy-yang-01 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-14 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-29 == Outdated reference: A later version (-04) exists of draft-dhody-teas-te-traffic-yang-00 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-08 Summary: 1 error (**), 0 flaws (~~), 15 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: 8 September 2022 G. Fioccola 6 Q. Wu, Ed. 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 J. Tantsura 11 Microsoft 12 7 March 2022 14 Traffic Engineering (TE) and Service Mapping YANG Model 15 draft-ietf-teas-te-service-mapping-yang-10 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 These models are referred to as TE Service Mapping Model and are 23 applicable generically to the operator's need for seamless control 24 and management of their VPN services with underlying TE support. 26 The models are principally used for monitoring and diagnostics of the 27 management systems to show how the service requests are mapped onto 28 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 8 September 2022. 47 Copyright Notice 49 Copyright (c) 2022 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 (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Purpose of TE Service Mapping for Service Model . . . . . 4 65 1.2. Purpose of TE Service Mapping for Network Model . . . . . 5 66 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 67 1.4. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 6 68 1.5. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 69 2. TE and Service Related Parameters . . . . . . . . . . . . . . 8 70 2.1. VN/Tunnel Selection Requirements . . . . . . . . . . . . 8 71 2.2. TE Policy . . . . . . . . . . . . . . . . . . . . . . . . 9 72 2.2.1. Availability Requirement . . . . . . . . . . . . . . 9 73 3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 9 74 3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 11 75 3.2. TE and Network Models . . . . . . . . . . . . . . . . . . 11 76 4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 12 77 4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 16 78 4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 16 79 5. Applicability of TE-Service Mapping in Generic context . . . 17 80 6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.1. Service Mapping Types . . . . . . . . . . . . . . . . . . 17 82 6.2. Service Models . . . . . . . . . . . . . . . . . . . . . 18 83 6.2.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 18 84 6.2.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 19 85 6.2.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 21 86 6.3. Network Models . . . . . . . . . . . . . . . . . . . . . 21 87 6.3.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 22 88 6.3.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 22 89 7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 23 90 7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 23 91 7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 32 92 7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 32 93 7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 35 94 7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 37 96 7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 39 97 7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 39 98 7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 41 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 101 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 46 104 11.2. Informative References . . . . . . . . . . . . . . . . . 49 105 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 50 106 Appendix B. Out of Scope . . . . . . . . . . . . . . . . . . . . 52 107 Appendix C. Contributor Addresses . . . . . . . . . . . . . . . 52 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 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 modeling 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 * 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 * 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 the service models. Section 3 discusses YANG modeling 178 approach. 180 1.1. Purpose of TE Service Mapping for Service Model 182 The TE service mapping for the LxSM supports: 184 * A mapping of the LxSM with the underlying TE resources. The TE 185 resources could be in a form of VN, set of TE tunnels, TE abstract 186 topology etc. This mapping can be populated by the network at the 187 time of realization of the service. It is also possible to 188 configure the mapping provided one is aware of VN/tunnels. This 189 mapping model is used only when the there is an awareness of VN or 190 TE by the consumer of the model. Otherwise this mapping 191 information is internal and used for monitoring and diagnostics 192 purpose such as telemetry, auto-scaling, closed-loop automation. 194 * Possibility to request creation of a new VN/Tunnel to be binded to 195 LxSM . 197 * Indication to share the VN/Tunnel sharing (with or without 198 modification) for the LxSM. 200 * Support for configuration of underlying TE properties (as apposed 201 to existing VN or tunnels). 203 * Provide some additional service characteristics for the LxSM 204 models 206 1.2. Purpose of TE Service Mapping for Network Model 208 Apart from the service model, the TE mapping is equally applicable to 209 the Network Models (L3 VPN Service Network Model (L3NM) 210 [I-D.ietf-opsawg-l3sm-l3nm], L2 VPN Service Network Model (L2NM) 211 [I-D.ietf-opsawg-l2nm] etc.). See Section 3.2 for details. 213 The TE service mapping for the LxNM supports: 215 * A mapping of the LxNM with the underlying TE resources. The TE 216 resources could be in a form of VN, set of TE tunnels, TE abstract 217 topology etc. This mapping can be populated by the network or 218 configured. This mapping is useful to understand the TE 219 realization of the LxVPN as well for monitoring/diagnostic 220 purpose. 222 * Possibility to request creation of a new VN/Tunnel to be binded to 223 LxNM . 225 * Indication to share the VN/Tunnel sharing (with or without 226 modification) for the LxNM. 228 * Support for configuration of underlying TE properties (as apposed 229 to existing VN or tunnels). 231 * Provide some additional service characteristics for the LxNM 232 models 234 1.3. Terminology 236 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 237 in this document. 239 The terminology for describing YANG data models is found in 240 [RFC7950]. 242 1.4. Tree diagram 244 A simplified graphical representation of the data model is used in 245 Section 5 of this this document. The meaning of the symbols in these 246 diagrams is defined in [RFC8340]. 248 1.5. Prefixes in Data Node Names 250 In this document, names of data nodes and other data model objects 251 are prefixed using the standard prefix associated with the 252 corresponding YANG imported modules, as shown in Table 1. 254 +========+==================+==================================+ 255 | Prefix | YANG module | Reference | 256 +========+==================+==================================+ 257 | tsmt | ietf-te-service- | [RFCXXXX] | 258 | | mapping-types | | 259 +--------+------------------+----------------------------------+ 260 | l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang] | 261 +--------+------------------+----------------------------------+ 262 | l2vpn- | ietf-l2vpn-svc | [RFC8466] | 263 | svc | | | 264 +--------+------------------+----------------------------------+ 265 | l3vpn- | ietf-l3vpn-svc | [RFC8299] | 266 | svc | | | 267 +--------+------------------+----------------------------------+ 268 | l1-tsm | ietf-l1csm-te- | [RFCXXXX] | 269 | | service-mapping | | 270 +--------+------------------+----------------------------------+ 271 | l2-tsm | ietf-l2sm-te- | [RFCXXXX] | 272 | | service-mapping | | 273 +--------+------------------+----------------------------------+ 274 | l3-tsm | ietf-l3sm-te- | [RFCXXXX] | 275 | | service-mapping | | 276 +--------+------------------+----------------------------------+ 277 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang] | 278 +--------+------------------+----------------------------------+ 279 | nw | ietf-network | [RFC8345] | 280 +--------+------------------+----------------------------------+ 281 | te- | ietf-te-types | [RFC8776] | 282 | types | | | 283 +--------+------------------+----------------------------------+ 284 | te | ietf-te | [I-D.ietf-teas-yang-te] | 285 +--------+------------------+----------------------------------+ 286 | l2vpn- | ietf-l2vpn-ntw | [I-D.ietf-opsawg-l2nm] | 287 | ntw | | | 288 +--------+------------------+----------------------------------+ 289 | l3vpn- | ietf-l3vpn-ntw | [I-D.ietf-opsawg-l3sm-l3nm] | 290 | ntw | | | 291 +--------+------------------+----------------------------------+ 292 | rt | ietf-routing | [RFC8349] | 293 +--------+------------------+----------------------------------+ 294 | sr- | ietf-sr-policy | [I-D.ietf-spring-sr-policy-yang] | 295 | policy | | | 296 +--------+------------------+----------------------------------+ 298 Table 1: Prefixes and corresponding YANG modules 300 Note: The RFC Editor should replace XXXX with the number assigned to 301 the RFC once this draft becomes an RFC. 303 2. TE and Service Related Parameters 305 While L1/L2/L3 service models (L1CSM, L2SM, L3SM) are intended to 306 provide service-specific parameters for VPN service instances, there 307 are a number of TE Service related parameters that are not included 308 in these service models. 310 Additional 'service parameters and policies' that are not included in 311 the aforementioned service models are addressed in the YANG models 312 defined in this document. 314 2.1. VN/Tunnel Selection Requirements 316 In some cases, the service requirements may need addition VN/TE 317 tunnels to be established. This may occur when there are no suitable 318 existing VN/TE tunnels that can support the service requirements, or 319 when the operator would like to dynamically create and bind tunnels 320 to the VPN such that they are not shared by other VPNs, for example, 321 for network slicing. The establishment of TE tunnels is subject to 322 the network operator's policies. 324 To summarize, there are three modes of VN/Tunnel selection operations 325 to be supported as follows. Additional modes may be defined in the 326 future. 328 * New VN/Tunnel Binding - A customer could request a VPN service 329 based on VN/Tunnels that are not shared with other existing or 330 future services. This might be to meet VPN isolation 331 requirements. Further, the YANG model described in Section 4 of 332 this document can be used to describe the mapping between the VPN 333 service and the ACTN VN. The VN (and TE tunnels) could be bound 334 to the VPN and not used for any other VPN. Under this mode, the 335 following sub-categories can be supported: 337 1. Hard Isolation with deterministic characteristics: A customer 338 could request a VPN service using a set of TE Tunnels with 339 deterministic characteristics requirements (e.g., no latency 340 variation) and where that set of TE Tunnels must not be shared 341 with other VPN services and must not compete for bandwidth or 342 other network resources with other TE Tunnels. 344 2. Hard Isolation: This is similar to the above case but without 345 the deterministic characteristics requirements. 347 3. Soft Isolation: The customer requests a VPN service using a 348 set of new TE tunnels which can be shared with other VPN 349 services if need be. 351 * VN/Tunnel Sharing - A customer could request a VPN service where 352 new tunnels (or a VN) do not need to be created for each VPN and 353 can be shared across multiple VPNs. Further, the mapping YANG 354 model described in Section 5 of this document can be used to 355 describe the mapping between the VPN service and the tunnels in 356 use. No modification of the properties of a tunnel (or VN) is 357 allowed in this mode: an existing tunnel can only be selected. 359 * VN/Tunnel Modify - This mode allows the modification of the 360 properties of the existing VN/tunnel (e.g., bandwidth). 362 * TE Mapping Template - This mode allows a VPN service to use a 363 mapping template containing constraints and optimization criteria. 364 This allows mapping with the underlay TE characteristics without 365 first creating a VN or tunnels to map. The VPN service could be 366 mapped to a template first. Once the VN/Tunnels are actually 367 created/selected for the VPN service, the mapping based on the 368 actual TE resources is created. 370 2.2. TE Policy 372 The service models could be associated with various policies related 373 to mapping the underlying TE resources. A color could be used to map 374 to the underlying colored TE resources. The desired protection and 375 availability requirements could be specified. 377 2.2.1. Availability Requirement 379 Availability is another service requirement or intent that may 380 influence the selection or provisioning of TE tunnels or a VN to 381 support the requested service. Availability is a probabilistic 382 measure of the length of time that a VPN/VN instance functions 383 without a network failure. 385 The availability level will need to be translated into network 386 specific policies such as the protection/reroute policy associated 387 with a VN or Tunnel. The means by which this is achieved is not in 388 the scope of this document. 390 3. YANG Modeling Approach 392 This section provides how the TE and Service mapping parameters are 393 supported using augmentation of the existing service models (i.e., 394 [I-D.ietf-ccamp-l1csm-yang], [RFC8466], and [RFC8299]). Figure 1 395 shows the scope of the Augmented LxSM Model. 397 +--------------+ +----------------------+ +----------+ 398 | LxSM |o-------| | . . . . | ACTN VN | 399 +--------------+ augment| | +----------+ 400 | | +----------+ 401 +--------------+ | Augmented LxSM Model | . . . . | TE-topo | 402 | TE & Service |------->| | +----------+ 403 | Mapping Types| import | | +----------+ 404 +--------------+ | | . . . . | TE-tunnel| 405 +----------------------+ +----------+ 406 reference 408 Figure 1: Augmented LxSM Model 410 The Augmented LxSM model (where x=1,2,3) augments the basic LxSM 411 model while importing the common TE and Service related parameters 412 (defined in Section 2) grouping information from TE and Service 413 Mapping Types. The TE and Service Mapping Types (ietf-te-service- 414 mapping-types) module is the repository of all common groupings 415 imported by each augmented LxSM model. Any future service models 416 would import this mapping-type common model. 418 The mapping could be made to any underlying TE resources such as VN, 419 TE topology abstract node (and its connectivity matrix), set of TE 420 tunnels etc. This flexibility from the modeling point of view allows 421 for various use cases at both service and network model. 423 The role of the augmented LxSM is to expose the mapping relationship 424 between service models and TE models so that VN/VPN service 425 instantiations provided by the underlying TE networks can be viewed 426 outside of the MDSC, for example by an operator who is diagnosing the 427 behavior of the network. Note that this should be done only if the 428 operator understands the VN/Tunnel resources and the the MDSC is 429 willing to share that information. It also allows for the customers 430 to access operational state information about how their services are 431 instantiated with the underlying VN, TE topology or TE tunnels. This 432 mapping will facilitate a seamless service management operation with 433 underlay-TE network visibility. 435 As seen in Figure 1, the augmented LxSM service model records a 436 mapping between the customer service models and the ACTN VN YANG 437 model. Thus, when the MDSC receives a service request it creates a 438 VN that meets the customer's service objectives with various 439 constraints via TE-topology model [RFC8795], and this relationship is 440 recorded by the Augmented LxSM Model. The model also supports a 441 mapping between a service model and TE-topology or a TE-tunnel. 443 The YANG models defined in this document conforms to the Network 444 Management Datastore Architecture (NMDA) [RFC8342]. 446 3.1. Forward Compatibility 448 The YANG module defined in this document supports three existing 449 service models via augmenting while sharing the common TE and Service 450 Mapping Types. 452 It is possible that new service models will be defined at some future 453 time and that it will be desirable to map them to underlying TE 454 constructs in the same way as the three existing models are 455 augmented. 457 Appendix B higlights some some features that are deemed out of scope 458 of this document. 460 3.2. TE and Network Models 462 The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN 463 Service in the Service Provider Network. It contains information of 464 the Service Provider network and might include allocated resources. 465 It can be used by network controllers to manage and control the VPN 466 Service configuration in the Service Provider network. 468 Similar to service model, the existing network models (i.e., 469 [I-D.ietf-opsawg-l3sm-l3nm], and [I-D.ietf-opsawg-l2nm]) are 470 augmented to include the TE and Service mapping parameters. Figure 2 471 shows the scope of the Augmented LxNM Model. 473 +--------------+ +----------------------+ +----------+ 474 | LxNM |o-------| | . . . . | ACTN VN | 475 +--------------+ augment| | +----------+ 476 | | +----------+ 477 +--------------+ | Augmented LxNM Model | . . . . | TE-topo | 478 | TE & Service |------->| | +----------+ 479 | Mapping Types| import | | +----------+ 480 +--------------+ | | . . . . | TE-tunnel| 481 +----------------------+ +----------+ 482 reference 484 Figure 2: Augmented LxNM Model 486 The Augmented LxNM model (where x=2,3) augments the basic LxNM model 487 while importing the common TE mapping related parameters (defined in 488 Section 2) grouping information from TE and Service Mapping Types. 489 The role of the augmented LxNM network model is to expose the mapping 490 relationship between network models and TE models. 492 4. L3VPN Architecture in the ACTN Context 494 Figure 3 shows the architectural context of this document referencing 495 the ACTN components and interfaces. 497 +----------------------------+ 498 | Customer Service Manager | 499 | +-----------------------+ | 500 | | CNC + | 501 | +-+-------------------+-+ | 502 +----|-------------------|---+ 503 | | 504 |CMI(Augmented L3SM)|CMI(VN) 505 | | 506 +----------------|-------------------|----+ 507 | +--------------|-----------------+ | | 508 | | MDSC | | | | 509 | | | | | | 510 | | +-----------+--------------+ | | | 511 TE-Svc-Map<------+ Service Mapping Function | | | | 512 | | +-----------+--------------+ | | | 513 | | | | | | 514 | +-------+------|-----------------+ | | 515 | | | | | 516 | | |CMI(VN) | | 517 | | | | | 518 | | +--|-------------------|--+ | 519 | | | | MDSC | | | 520 | | | ++-------------------++ | | 521 | | | + Service Mapping +---->TE-Svc-Map 522 | | | ++----------+---------+ | | 523 | | +--|----------|-----------+ | 524 +---------|------|----------|-------------+ 525 | | | 526 | +----+--------+ | 527 | | | | 528 MPI(VPN / TE models)| | | |MPI(TE / L1 models) 529 | | | | 530 +-----|-|---+ +-----|-|----+ 531 IP/MPLS | +--+-+-+ | | +--+-+-+ | Optical Domain 532 Domain | | PNC1 | | | | PNC2 | | Controller 533 Controller | +--+---+ | | +--+---+ | 534 +-----|-----+ +-----|------+ 535 | | 536 V | SBI 537 +---------------------+ | 538 / IP/MPLS Network \ | 539 +-------------------------+ | 540 V 541 +---------------------+ 542 / Optical Network \ 543 +-------------------------+ 545 Figure 3: L3VPN Architecture from the IP+Optical Network Perspective 547 There are three main entities in the ACTN architecture and shown in 548 Figure 3. 550 * CNC: The Customer Network Controller is responsible for generating 551 service requests. In the context of an L3VPN, the CNC uses the 552 Augmented L3SM to express the service request and communicate it 553 to the network operator. 555 * MDSC: This entity is responsible for coordinating a L3VPN service 556 request (expressed via the Augmented L3SM) with the IP/MPLS PNC 557 and the Transport PNC. For TE services, one of the key 558 responsibilities of the MDSC is to coordinate with both the IP PNC 559 and the Transport PNC for the mapping of the Augmented L3VPN 560 Service Model to the ACTN VN model. In the VN/TE-tunnel binding 561 case, the MDSC will need to coordinate with the Transport PNC to 562 dynamically create the TE-tunnels in the transport network as 563 needed. These tunnels are added as links in the IP/MPLS Layer 564 topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 565 tunnels in the IP/MPLS layer, as part of the ACTN VN creation. 567 * PNC: The Provisioning Network Controller is responsible for 568 configuring and operating the network devices. Figure 3 shows two 569 distinct PNCs. 571 - IP/MPLS PNC (PNC1): This entity is responsible for device 572 configuration to create PE-PE L3VPN tunnels for the VPN 573 customer and for the configuration of the L3VPN VRF on the PE 574 nodes. Each network element would select a tunnel based on the 575 configuration. 577 - Transport PNC (PNC2): This entity is responsible for device 578 configuration for TE tunnels in the transport networks. 580 The three main interfaces are shown in Figure 3 and listed below. 582 * CMI: The CNC-MDSC Interface is used to communicate service 583 requests from the customer to the operator. The requests may be 584 expressed as Augmented VPN service requests (L2SM, L3SM), as 585 connectivity requests (L1CSM), or as virtual network requests 586 (ACTN VN). 588 * MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate 589 networks under the control of PNCs. The requests on this 590 interface may use TE tunnel models, TE topology models, VPN 591 network configuration models or layer one connectivity models. 593 * SBI: The Southbound Interface is used by the PNC to control 594 network devices and is out of scope for this document. 596 The TE Service Mapping Model as described in this document can be 597 used to see the mapping between service models and VN models and TE 598 Tunnel/Topology models. That mapping may occur in the CNC if a 599 service request is mapped to a VN request. Or it may occur in the 600 MDSC where a service request is mapped to a TE tunnel, TE topology, 601 or VPN network configuration model. The TE Service Mapping Model may 602 be read from the CNC or MDSC to understand how the mapping has been 603 made and to see the purpose for which network resources are used. 605 As shown in Figure 3, the MDSC may be used recursively. For example, 606 the CNC might map a L3SM request to a VN request that it sends to a 607 recursive MDSC. 609 The high-level control flows for one example are as follows: 611 1. A customer asks for an L3VPN between CE1 and CE2 using the 612 Augmented L3SM model. 614 2. The MDSC considers the service request and local policy to 615 determine if it needs to create a new VN or any TE Topology, and 616 if that is the case, ACTN VN YANG [I-D.ietf-teas-actn-vn-yang] is 617 used to configure a new VN based on this VPN and map the VPN 618 service to the ACTN VN. In case an existing tunnel is to be 619 used, each device will select which tunnel to use and populate 620 this mapping information. 622 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 623 PNC to create a PE-PE tunnel in the IP network mapped to a TE 624 tunnel in the transport network by providing the inter-layer 625 access points and tunnel requirements. The specific service 626 information is passed to the IP/MPLS PNC for the actual VPN 627 configuration and activation. 629 a. The Transport PNC creates the corresponding TE tunnel 630 matching with the access point and egress point. 632 b. The IP/MPLS PNC maps the VPN ID with the corresponding TE 633 tunnel ID to bind these two IDs. 635 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 636 customer. This is not in the scope of this document. 638 4.1. Service Mapping 640 Augmented L3SM and L2SM can be used to request VPN service creation 641 including the creation of sites and corresponding site network access 642 connection between CE and PE. A VPN-ID is used to identify each VPN 643 service ordered by the customer. The ACTN VN can be used further to 644 establish PE-to-PE connectivity between VPN sites belonging to the 645 same VPN service. A VN-ID is used to identify each virtual network 646 established between VPN sites. 648 Once the ACTN VN has been established over the TE network (maybe a 649 new VN, maybe modification of an existing VN, or maybe the use of an 650 unmodified existing VN), the mapping between the VPN service and the 651 ACTN VN service can be created. 653 4.2. Site Mapping 655 The elements in Augmented L3SM and L2SM define site location 656 parameters and constraints such as distance and access diversity that 657 can influence the placement of network attachment points (i.e, 658 virtual network access points (VNAP)). To achieve this, a central 659 directory can be set up to establish the mapping between location 660 parameters and constraints and network attachment point location. 661 Suppose multiple attachment points are matched, the management system 662 can use constraints or other local policy to select the best 663 candidate network attachment points. 665 After a network attachment point is selected, the mapping between VPN 666 site and VNAP can be established as shown in Table 1. 668 +=======+=========+==================+========================+=====+ 669 | Site | Site | Location | Access Diversity | PE | 670 | | Network | (Address, | (Constraint-Type, | | 671 | | Access | Postal Code, | Group-id,Target Group- | | 672 | | | State, | id) | | 673 | | | City,Country | | | 674 | | | Code) | | | 675 +=======+=========+==================+========================+=====+ 676 | SITE1 | ACCESS1 | (,,US,NewYork,) | (10,PE-Diverse,10) | PE1 | 677 +-------+---------+------------------+------------------------+-----+ 678 | SITE2 | ACCESS2 | (,,CN,Beijing,) | (10,PE-Diverse,10) | PE2 | 679 +-------+---------+------------------+------------------------+-----+ 680 | SITE3 | ACCESS3 | (,,UK,London, ) | (12,same-PE,12) | PE4 | 681 +-------+---------+------------------+------------------------+-----+ 682 | SITE4 | ACCESS4 | (,,FR,Paris,) | (20,Bearer-Diverse,20) | PE7 | 683 +-------+---------+------------------+------------------------+-----+ 685 Table 2: : Mapping Between VPN Site and VNAP 687 5. Applicability of TE-Service Mapping in Generic context 689 As discussed in the Introduction Section, the models presented in 690 this document are also applicable generically outside of the ACTN 691 architecture. [RFC8309] defines Customer Service Model between 692 Customer and Service Orchestrator and Service Delivery Model between 693 Service Orchestrator and Network Orchestrator(s). TE-Service mapping 694 models defined in this document can be regarded primarily as Customer 695 Service Model and secondarily as Service Deliver Model. 697 6. YANG Data Trees 699 6.1. Service Mapping Types 701 module: ietf-te-service-mapping-types 702 +--rw te-mapping-templates 703 +--rw te-mapping-template* [id] 704 +--rw id te-mapping-template-id 705 +--rw description? string 706 +--rw map-type? identityref 707 +--rw path-constraints 708 | +--rw te-bandwidth 709 | | +--rw (technology)? 710 | | +--:(generic) 711 | | +--rw generic? te-bandwidth 712 | +--rw link-protection? identityref 713 | +--rw setup-priority? uint8 714 | +--rw hold-priority? uint8 715 | +--rw signaling-type? identityref 716 | +--rw path-metric-bounds 717 | | +--rw path-metric-bound* [metric-type] 718 | | +--rw metric-type identityref 719 | | +--rw upper-bound? uint64 720 | +--rw path-affinities-values 721 | | +--rw path-affinities-value* [usage] 722 | | +--rw usage identityref 723 | | +--rw value? admin-groups 724 | +--rw path-affinity-names 725 | | +--rw path-affinity-name* [usage] 726 | | +--rw usage identityref 727 | | +--rw affinity-name* [name] 728 | | +--rw name string 729 | +--rw path-srlgs-lists 730 | | +--rw path-srlgs-list* [usage] 731 | | +--rw usage identityref 732 | | +--rw values* srlg 733 | +--rw path-srlgs-names 734 | | +--rw path-srlgs-name* [usage] 735 | | +--rw usage identityref 736 | | +--rw names* string 737 | +--rw disjointness? te-path-disjointness 738 +--rw optimizations 739 +--rw (algorithm)? 740 +--:(metric) {path-optimization-metric}? 741 | +--rw optimization-metric* [metric-type] 742 | | +--rw metric-type 743 | | | identityref 744 | | +--rw weight? uint8 745 | | +--rw explicit-route-exclude-objects 746 | | | ... 747 | | +--rw explicit-route-include-objects 748 | | ... 749 | +--rw tiebreakers 750 | +--rw tiebreaker* [tiebreaker-type] 751 | ... 752 +--:(objective-function) 753 {path-optimization-objective-function}? 754 +--rw objective-function 755 +--rw objective-function-type? identityref 757 6.2. Service Models 759 6.2.1. L3SM 761 module: ietf-l3sm-te-service-mapping 763 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services 764 /l3vpn-svc:vpn-service: 765 +--rw te-service-mapping! 766 +--rw te-mapping 767 +--rw map-type? identityref 768 +--rw te-policy 769 | +--rw color? uint32 770 | +--rw protection-type? identityref 771 | +--rw availability-type? identityref 772 +--rw (te)? 773 | +--:(vn) 774 | | +--rw vn* 775 | | -> /vn:virtual-network/vn/vn-id 776 | +--:(te-topo) 777 | | +--rw te-topology-identifier 778 | | | +--rw provider-id? te-global-id 779 | | | +--rw client-id? te-global-id 780 | | | +--rw topology-id? te-topology-id 781 | | +--rw abstract-node? 782 | | -> /nw:networks/network/node/node-id 783 | +--:(te-tunnel) 784 | +--rw te-tunnel* te:tunnel-ref 785 | +--rw sr-policy* 786 | [policy-color-ref policy-endpoint-ref] 787 | {sr-policy}? 788 | +--rw policy-color-ref leafref 789 | +--rw policy-endpoint-ref leafref 790 +--rw te-mapping-template-ref? 791 -> /tsmt:te-mapping-templates/te-mapping-template/id 792 {template}? 793 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 794 /l3vpn-svc:site-network-accesses 795 /l3vpn-svc:site-network-access: 796 +--rw (te)? 797 +--:(vn) 798 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 799 +--:(te) 800 +--rw ltp? te-types:te-tp-id 801 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 802 /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile 803 /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes 804 /l3vpn-svc:class: 805 +--rw (te)? 806 +--:(vn) 807 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 808 +--:(te) 809 +--rw ltp? te-types:te-tp-id 810 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 811 /l3vpn-svc:site-network-accesses 812 /l3vpn-svc:site-network-access/l3vpn-svc:service 813 /l3vpn-svc:qos/l3vpn-svc:qos-profile 814 /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes 815 /l3vpn-svc:class: 816 +--rw (te)? 817 +--:(vn) 818 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 819 +--:(te) 820 +--rw ltp? te-types:te-tp-id 822 6.2.2. L2SM 824 module: ietf-l2sm-te-service-mapping 826 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services 827 /l2vpn-svc:vpn-service: 828 +--rw te-service-mapping! 829 +--rw te-mapping 830 +--rw map-type? identityref 831 +--rw te-policy 832 | +--rw color? uint32 833 | +--rw protection-type? identityref 834 | +--rw availability-type? identityref 835 +--rw (te)? 836 | +--:(vn) 837 | | +--rw vn* 838 | | -> /vn:virtual-network/vn/vn-id 839 | +--:(te-topo) 840 | | +--rw te-topology-identifier 841 | | | +--rw provider-id? te-global-id 842 | | | +--rw client-id? te-global-id 843 | | | +--rw topology-id? te-topology-id 844 | | +--rw abstract-node? 845 | | -> /nw:networks/network/node/node-id 846 | +--:(te-tunnel) 847 | +--rw te-tunnel* te:tunnel-ref 848 | +--rw sr-policy* 849 | [policy-color-ref policy-endpoint-ref] 850 | {sr-policy}? 851 | +--rw policy-color-ref leafref 852 | +--rw policy-endpoint-ref leafref 853 +--rw te-mapping-template-ref? 854 -> /tsmt:te-mapping-templates/te-mapping-template/id 855 {template}? 856 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 857 /l2vpn-svc:site-network-accesses 858 /l2vpn-svc:site-network-access: 859 +--rw (te)? 860 +--:(vn) 861 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 862 +--:(te) 863 +--rw ltp? te-types:te-tp-id 864 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 865 /l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile 866 /l2vpn-svc:qos-profile/l2vpn-svc:custom/l2vpn-svc:classes 867 /l2vpn-svc:class: 868 +--rw (te)? 869 +--:(vn) 870 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 871 +--:(te) 872 +--rw ltp? te-types:te-tp-id 873 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 874 /l2vpn-svc:site-network-accesses 875 /l2vpn-svc:site-network-access/l2vpn-svc:service 876 /l2vpn-svc:qos/l2vpn-svc:qos-profile 877 /l2vpn-svc:qos-profile/l2vpn-svc:custom/l2vpn-svc:classes 878 /l2vpn-svc:class: 880 +--rw (te)? 881 +--:(vn) 882 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 883 +--:(te) 884 +--rw ltp? te-types:te-tp-id 886 6.2.3. L1CSM 888 module: ietf-l1csm-te-service-mapping 890 augment /l1csm:l1-connectivity/l1csm:services/l1csm:service: 891 +--rw te-service-mapping! 892 +--rw te-mapping 893 +--rw map-type? identityref 894 +--rw te-policy 895 | +--rw color? uint32 896 | +--rw protection-type? identityref 897 | +--rw availability-type? identityref 898 +--rw (te)? 899 | +--:(vn) 900 | | +--rw vn* 901 | | -> /vn:virtual-network/vn/vn-id 902 | +--:(te-topo) 903 | | +--rw te-topology-identifier 904 | | | +--rw provider-id? te-global-id 905 | | | +--rw client-id? te-global-id 906 | | | +--rw topology-id? te-topology-id 907 | | +--rw abstract-node? 908 | | -> /nw:networks/network/node/node-id 909 | +--:(te-tunnel) 910 | +--rw te-tunnel* te:tunnel-ref 911 | +--rw sr-policy* 912 | [policy-color-ref policy-endpoint-ref] 913 | {sr-policy}? 914 | +--rw policy-color-ref leafref 915 | +--rw policy-endpoint-ref leafref 916 +--rw te-mapping-template-ref? 917 -> /tsmt:te-mapping-templates/te-mapping-template/id 918 {template}? 919 augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni: 920 +--rw (te)? 921 +--:(vn) 922 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 923 +--:(te) 924 +--rw ltp? te-types:te-tp-id 926 6.3. Network Models 927 6.3.1. L3NM 929 module: ietf-l3nm-te-service-mapping 931 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 932 /l3vpn-ntw:vpn-service: 933 +--rw te-service-mapping! 934 +--rw te-mapping 935 +--rw map-type? identityref 936 +--rw te-policy 937 | +--rw color? uint32 938 | +--rw protection-type? identityref 939 | +--rw availability-type? identityref 940 +--rw (te)? 941 | +--:(vn) 942 | | +--rw vn* 943 | | -> /vn:virtual-network/vn/vn-id 944 | +--:(te-topo) 945 | | +--rw te-topology-identifier 946 | | | +--rw provider-id? te-global-id 947 | | | +--rw client-id? te-global-id 948 | | | +--rw topology-id? te-topology-id 949 | | +--rw abstract-node? 950 | | -> /nw:networks/network/node/node-id 951 | +--:(te-tunnel) 952 | +--rw te-tunnel* te:tunnel-ref 953 | +--rw sr-policy* 954 | [policy-color-ref policy-endpoint-ref] 955 | {sr-policy}? 956 | +--rw policy-color-ref leafref 957 | +--rw policy-endpoint-ref leafref 958 +--rw te-mapping-template-ref? 959 -> /tsmt:te-mapping-templates/te-mapping-template/id 960 {template}? 961 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 962 /l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes 963 /l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses 964 /l3vpn-ntw:vpn-network-access: 965 +--rw (te)? 966 +--:(vn) 967 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 968 +--:(te) 969 +--rw ltp? te-types:te-tp-id 971 6.3.2. L2NM 972 module: ietf-l2nm-te-service-mapping 974 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 975 /l2vpn-ntw:vpn-service: 976 +--rw te-service-mapping! 977 +--rw te-mapping 978 +--rw map-type? identityref 979 +--rw te-policy 980 | +--rw color? uint32 981 | +--rw protection-type? identityref 982 | +--rw availability-type? identityref 983 +--rw (te)? 984 | +--:(vn) 985 | | +--rw vn* 986 | | -> /vn:virtual-network/vn/vn-id 987 | +--:(te-topo) 988 | | +--rw te-topology-identifier 989 | | | +--rw provider-id? te-global-id 990 | | | +--rw client-id? te-global-id 991 | | | +--rw topology-id? te-topology-id 992 | | +--rw abstract-node? 993 | | -> /nw:networks/network/node/node-id 994 | +--:(te-tunnel) 995 | +--rw te-tunnel* te:tunnel-ref 996 | +--rw sr-policy* 997 | [policy-color-ref policy-endpoint-ref] 998 | {sr-policy}? 999 | +--rw policy-color-ref leafref 1000 | +--rw policy-endpoint-ref leafref 1001 +--rw te-mapping-template-ref? 1002 -> /tsmt:te-mapping-templates/te-mapping-template/id 1003 {template}? 1004 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 1005 /l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes 1006 /l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses 1007 /l2vpn-ntw:vpn-network-access: 1008 +--rw (te)? 1009 +--:(vn) 1010 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 1011 +--:(te) 1012 +--rw ltp? te-types:te-tp-id 1014 7. YANG Data Models 1016 The YANG codes are as follows: 1018 7.1. ietf-te-service-mapping-types 1019 file "ietf-te-service-mapping-types@2022-03-07.yang" 1020 module ietf-te-service-mapping-types { 1021 yang-version 1.1; 1022 namespace 1023 "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; 1024 prefix tsmt; 1026 /* Import te-types */ 1028 import ietf-te-types { 1029 prefix te-types; 1030 reference 1031 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 1032 } 1034 /* Import network model */ 1036 import ietf-network { 1037 prefix nw; 1038 reference 1039 "RFC 8345: A YANG Data Model for Network Topologies"; 1040 } 1042 /* Import TE model */ 1044 import ietf-te { 1045 prefix te; 1046 reference 1047 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1048 Engineering Tunnels and Interfaces"; 1049 } 1051 /* Import VN model */ 1053 import ietf-vn { 1054 prefix vn; 1055 reference 1056 "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation"; 1057 } 1059 /* Import Routing */ 1061 import ietf-routing { 1062 prefix rt; 1063 reference 1064 "RFC 8349: A YANG Data Model for Routing Management"; 1065 } 1066 /* Import SR Policy */ 1068 import ietf-sr-policy { 1069 prefix sr-policy; 1070 reference 1071 "I-D.ietf-spring-sr-policy-yang: YANG Data Model for Segment 1072 Routing Policy"; 1073 } 1075 organization 1076 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1077 Working Group"; 1078 contact 1079 "WG Web: 1080 WG List: 1082 Editor: Young Lee 1083 1084 Editor: Dhruv Dhody 1085 1086 Editor: Qin Wu 1087 "; 1088 description 1089 "This module contains a YANG module for TE & Service mapping 1090 parameters and policies as a common grouping applicable to 1091 variuous service models (e.g., L1CSM, L2SM, L3SM, etc.) 1093 Copyright (c) 2022 IETF Trust and the persons identified as 1094 authors of the code. All rights reserved. 1096 Redistribution and use in source and binary forms, with or 1097 without modification, is permitted pursuant to, and subject to 1098 the license terms contained in, the Revised BSD License set 1099 forth in Section 4.c of the IETF Trust's Legal Provisions 1100 Relating to IETF Documents 1101 (https://trustee.ietf.org/license-info). 1103 This version of this YANG module is part of RFC XXXX; see the 1104 RFC itself for full legal notices."; 1106 revision 2022-03-07 { 1107 description 1108 "Initial revision."; 1109 reference 1110 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1111 } 1113 /* 1114 * Features 1115 */ 1117 feature template { 1118 description 1119 "Support TE mapping templates."; 1120 } 1122 feature sr-policy { 1123 description 1124 "Support SR Policy."; 1125 } 1127 /* 1128 * Identity for map-type 1129 */ 1131 identity map-type { 1132 description 1133 "Base identity from which specific map types are derived."; 1134 } 1136 identity new { 1137 base map-type; 1138 description 1139 "The new VN/tunnels are binded to the service."; 1140 } 1142 identity hard-isolation { 1143 base new; 1144 description 1145 "Hard isolation."; 1146 } 1148 identity detnet-hard-isolation { 1149 base hard-isolation; 1150 description 1151 "Hard isolation with deterministic characteristics."; 1152 } 1154 identity soft-isolation { 1155 base new; 1156 description 1157 "Soft-isolation."; 1158 } 1160 identity select { 1161 base map-type; 1162 description 1163 "The VPN service selects an existing tunnel with no 1164 modification."; 1165 } 1167 identity modify { 1168 base map-type; 1169 description 1170 "The VPN service selects an existing tunnel and allows to modify 1171 the properties of the tunnel (e.g., b/w)"; 1172 } 1174 identity none { 1175 base map-type; 1176 description 1177 "The VPN service is not mapped to any underlying TE"; 1178 } 1180 /* 1181 * Identity for availability-type 1182 */ 1184 identity availability-type { 1185 description 1186 "Base identity from which specific map types are derived."; 1187 } 1189 identity level-1 { 1190 base availability-type; 1191 description 1192 "level 1: 99.9999%"; 1193 } 1195 identity level-2 { 1196 base availability-type; 1197 description 1198 "level 2: 99.999%"; 1199 } 1201 identity level-3 { 1202 base availability-type; 1203 description 1204 "level 3: 99.99%"; 1205 } 1207 identity level-4 { 1208 base availability-type; 1209 description 1210 "level 4: 99.9%"; 1211 } 1213 identity level-5 { 1214 base availability-type; 1215 description 1216 "level 5: 99%"; 1217 } 1219 /* 1220 * Typedef 1221 */ 1223 typedef te-mapping-template-id { 1224 type string; 1225 description 1226 "Identifier for a TE mapping template."; 1227 } 1229 /* 1230 * Groupings 1231 */ 1233 grouping te-ref { 1234 description 1235 "The reference to TE."; 1236 choice te { 1237 description 1238 "How the VPN is mapped to a VN, Topology, Tunnel, SR Policy 1239 etc."; 1240 case vn { 1241 leaf-list vn { 1242 type leafref { 1243 path "/vn:virtual-network/vn:vn/vn:vn-id"; 1244 } 1245 description 1246 "The reference to VN"; 1247 reference 1248 "RFC 8453: Framework for Abstraction and Control of TE 1249 Networks (ACTN)"; 1250 } 1251 } 1252 case te-topo { 1253 /*An identifier to the TE Topology Model where the abstract 1254 nodes and links of the Topology can be found for Type 2 1255 VNs as defined in RFC 8453*/ 1256 uses te-types:te-topology-identifier; 1257 leaf abstract-node { 1258 type leafref { 1259 path "/nw:networks/nw:network/nw:node/nw:node-id"; 1260 } 1261 description 1262 "A reference to the abstract node in TE Topology"; 1263 reference 1264 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1265 Topologies"; 1266 } 1267 } 1268 case te-tunnel { 1269 leaf-list te-tunnel { 1270 type te:tunnel-ref; 1271 description 1272 "Reference to TE Tunnels"; 1273 reference 1274 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1275 Engineering Tunnels and Interfaces"; 1276 } 1277 list sr-policy { 1278 if-feature "sr-policy"; 1279 /*Headend should also be there!*/ 1280 key "policy-color-ref policy-endpoint-ref"; 1281 description 1282 "SR Policy"; 1283 leaf policy-color-ref { 1284 type leafref { 1285 path 1286 "/rt:routing/sr-policy:segment-routing" 1287 + "/sr-policy:traffic-engineering/sr-policy:policies" 1288 + "/sr-policy:policy/sr-policy:color"; 1289 } 1290 description 1291 "Reference to sr-policy color"; 1292 } 1293 leaf policy-endpoint-ref { 1294 type leafref { 1295 path 1296 "/rt:routing/sr-policy:segment-routing" 1297 + "/sr-policy:traffic-engineering/sr-policy:policies" 1298 + "/sr-policy:policy/sr-policy:endpoint"; 1299 } 1300 description 1301 "Reference to sr-policy endpoint"; 1302 } 1303 } 1304 } 1305 } 1306 leaf te-mapping-template-ref { 1307 if-feature "template"; 1308 type leafref { 1309 path "/tsmt:te-mapping-templates/" 1310 + "tsmt:te-mapping-template/tsmt:id"; 1311 } 1312 description 1313 "An identifier to the TE Mapping Template where the TE 1314 constraints and optimization criteria are specified."; 1315 } 1316 } 1318 //grouping 1320 grouping te-endpoint-ref { 1321 description 1322 "The reference to TE endpoints."; 1323 choice te { 1324 description 1325 "How the TE endpoint is defined by VN's AP or TE's LTP"; 1326 case vn { 1327 leaf-list vn-ap { 1328 type leafref { 1329 path "/vn:access-point/vn:ap/vn:vn-ap/vn:vn-ap-id"; 1330 } 1331 description 1332 "The reference to VNAP"; 1333 reference 1334 "RFC 8453: Framework for Abstraction and Control of TE 1335 Networks (ACTN)"; 1336 } 1337 } 1338 case te { 1339 leaf ltp { 1340 type te-types:te-tp-id; 1341 description 1342 "Reference LTP in the TE-topology"; 1343 reference 1344 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1345 Topologies"; 1346 } 1347 } 1348 } 1349 } 1351 //grouping 1353 grouping te-policy { 1354 description 1355 "Various underlying TE policy requirements"; 1356 leaf color { 1357 type uint32; 1358 description 1359 "Maps to the underlying colored TE resources"; 1360 } 1361 leaf protection-type { 1362 type identityref { 1363 base te-types:lsp-protection-type; 1364 } 1365 description 1366 "Desired protection level for the underlying 1367 TE resources"; 1368 } 1369 leaf availability-type { 1370 type identityref { 1371 base availability-type; 1372 } 1373 description 1374 "Availability Requirement for the Service"; 1375 } 1376 } 1378 //grouping 1380 grouping te-mapping { 1381 description 1382 "Mapping between Services and TE"; 1383 container te-mapping { 1384 description 1385 "Mapping between Services and TE"; 1386 leaf map-type { 1387 type identityref { 1388 base map-type; 1389 } 1390 description 1391 "Isolation Requirements, Tunnel Bind or 1392 Tunnel Selection"; 1393 } 1394 container te-policy { 1395 uses te-policy; 1396 description 1397 "Desired Underlying TE Policy"; 1398 } 1399 uses te-ref; 1400 } 1401 } 1402 //grouping 1404 container te-mapping-templates { 1405 description 1406 "The TE constraints and optimization criteria"; 1407 list te-mapping-template { 1408 key "id"; 1409 leaf id { 1410 type te-mapping-template-id; 1411 description 1412 "Identification of the Template to be used."; 1413 } 1414 leaf description { 1415 type string; 1416 description 1417 "Description of the template."; 1418 } 1419 leaf map-type { 1420 type identityref { 1421 base map-type; 1422 } 1423 must "0 = derived-from-or-self(.,'none')" { 1424 error-message "The map-type must be other than " 1425 + "none"; 1426 } 1427 description 1428 "Map type for the VN/Tunnel creation/ 1429 selection."; 1430 } 1431 uses te-types:generic-path-constraints; 1432 uses te-types:generic-path-optimization; 1433 description 1434 "List for templates."; 1435 } 1436 } 1437 } 1438 1440 7.2. Service Models 1442 7.2.1. ietf-l3sm-te-service-mapping 1444 file "ietf-l3sm-te-service-mapping@2022-03-07.yang" 1445 module ietf-l3sm-te-service-mapping { 1446 yang-version 1.1; 1447 namespace 1448 "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; 1449 prefix l3-tsm; 1450 import ietf-te-service-mapping-types { 1451 prefix tsmt; 1452 reference 1453 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1454 } 1455 import ietf-l3vpn-svc { 1456 prefix l3vpn-svc; 1457 reference 1458 "RFC 8299: YANG Data Model for L3VPN Service Delivery"; 1459 } 1461 organization 1462 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1463 Working Group"; 1464 contact 1465 "WG Web: 1466 WG List: 1468 Editor: Young Lee 1469 1470 Editor: Dhruv Dhody 1471 1472 Editor: Qin Wu 1473 "; 1474 description 1475 "This module contains a YANG module for the mapping of Layer 3 1476 Service Model (L3SM) to the TE and VN. 1478 Copyright (c) 2022 IETF Trust and the persons identified as 1479 authors of the code. All rights reserved. 1481 Redistribution and use in source and binary forms, with or 1482 without modification, is permitted pursuant to, and subject to 1483 the license terms contained in, the Revised BSD License set 1484 forth in Section 4.c of the IETF Trust's Legal Provisions 1485 Relating to IETF Documents 1486 (https://trustee.ietf.org/license-info). 1488 This version of this YANG module is part of RFC XXXX; see the 1489 RFC itself for full legal notices."; 1491 revision 2022-03-07 { 1492 description 1493 "Initial revision."; 1494 reference 1495 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1496 } 1497 /* 1498 * Augmentation to L3SM 1499 */ 1501 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services" 1502 + "/l3vpn-svc:vpn-service" { 1503 description 1504 "L3SM augmented to include TE parameters and mapping"; 1505 container te-service-mapping { 1506 presence "Indicates L3 service to TE mapping"; 1507 description 1508 "Container to augment l3sm to TE parameters and mapping"; 1509 uses tsmt:te-mapping; 1510 } 1511 } 1513 //augment 1515 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1516 + "/l3vpn-svc:site-network-accesses" 1517 + "/l3vpn-svc:site-network-access" { 1518 description 1519 "This augment is only valid for TE mapping of L3SM network-access 1520 to TE endpoints"; 1521 uses tsmt:te-endpoint-ref; 1522 } 1524 //augment 1526 augment 1527 "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1528 + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile" 1529 + "/l3vpn-svc:qos-profile/l3vpn-svc:custom" 1530 + "/l3vpn-svc:classes/l3vpn-svc:class" { 1531 description 1532 "This augment is for per-class in site for custom QoS profile"; 1533 uses tsmt:te-endpoint-ref; 1534 } 1536 augment 1537 "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1538 + "/l3vpn-svc:site-network-accesses" 1539 + "/l3vpn-svc:site-network-access" 1540 + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile" 1541 + "/l3vpn-svc:qos-profile/l3vpn-svc:custom" 1542 + "/l3vpn-svc:classes/l3vpn-svc:class" { 1543 description 1544 "This augment is for per-class in site-network-access for custom 1545 QoS profile"; 1546 uses tsmt:te-endpoint-ref; 1547 } 1548 } 1549 1551 7.2.2. ietf-l2sm-te-service-mapping 1553 file "ietf-l2sm-te-service-mapping@2022-03-07.yang" 1554 module ietf-l2sm-te-service-mapping { 1555 yang-version 1.1; 1556 namespace 1557 "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; 1558 prefix l2-tsm; 1560 import ietf-te-service-mapping-types { 1561 prefix tsmt; 1562 reference 1563 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1564 } 1565 import ietf-l2vpn-svc { 1566 prefix l2vpn-svc; 1567 reference 1568 "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network 1569 (L2VPN) Service Delivery"; 1570 } 1572 organization 1573 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1574 Working Group"; 1575 contact 1576 "WG Web: 1577 WG List: 1579 Editor: Young Lee 1580 1581 Editor: Dhruv Dhody 1582 1583 Editor: Qin Wu 1584 "; 1585 description 1586 "This module contains a YANG module for the mapping of Layer 2 1587 Service Model (L2SM) to the TE and VN. 1589 Copyright (c) 2022 IETF Trust and the persons identified as 1590 authors of the code. All rights reserved. 1592 Redistribution and use in source and binary forms, with or 1593 without modification, is permitted pursuant to, and subject to 1594 the license terms contained in, the Revised BSD License set 1595 forth in Section 4.c of the IETF Trust's Legal Provisions 1596 Relating to IETF Documents 1597 (https://trustee.ietf.org/license-info). 1599 This version of this YANG module is part of RFC XXXX; see the 1600 RFC itself for full legal notices."; 1602 revision 2022-03-07 { 1603 description 1604 "Initial revision."; 1605 reference 1606 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1607 } 1609 /* 1610 * Augmentation to L2SM 1611 */ 1613 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/" 1614 + "l2vpn-svc:vpn-service" { 1615 description 1616 "L2SM augmented to include TE parameters and mapping"; 1617 container te-service-mapping { 1618 presence "indicates L2 service to te mapping"; 1619 description 1620 "Container to augment L2SM to TE parameters and mapping"; 1621 uses tsmt:te-mapping; 1622 } 1623 } 1625 //augment 1627 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1628 + "/l2vpn-svc:site-network-accesses" 1629 + "/l2vpn-svc:site-network-access" { 1630 description 1631 "This augment the L2SM network-access with a reference 1632 to TE endpoints when underlying TE is used"; 1633 uses tsmt:te-endpoint-ref; 1634 } 1636 //augment 1638 augment 1639 "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1640 + "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile" 1641 + "/l2vpn-svc:qos-profile/l2vpn-svc:custom" 1642 + "/l2vpn-svc:classes/l2vpn-svc:class" { 1643 when './l2vpn-svc:bandwidth/l2vpn-svc:end-to-end' { 1644 description 1645 "applicable only with end-to-end"; 1646 } 1647 description 1648 "This augment is for per-class in site for custom QoS profile"; 1649 uses tsmt:te-endpoint-ref; 1650 } 1652 augment 1653 "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1654 + "/l2vpn-svc:site-network-accesses" 1655 + "/l2vpn-svc:site-network-access" 1656 + "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile" 1657 + "/l2vpn-svc:qos-profile/l2vpn-svc:custom" 1658 + "/l2vpn-svc:classes/l2vpn-svc:class" { 1659 description 1660 "This augment is for per-class in site-network-access for custom 1661 QoS profile"; 1662 uses tsmt:te-endpoint-ref; 1663 } 1664 } 1665 1667 7.2.3. ietf-l1csm-te-service-mapping 1669 file "ietf-l1csm-te-service-mapping@2022-03-07.yang" 1670 module ietf-l1csm-te-service-mapping { 1671 yang-version 1.1; 1672 namespace 1673 "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; 1674 prefix l1-tsm; 1676 import ietf-te-service-mapping-types { 1677 prefix tsmt; 1678 reference 1679 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1680 } 1681 import ietf-l1csm { 1682 prefix l1csm; 1683 reference 1684 "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity 1685 Service Model (L1CSM)"; 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 1703 Layer 1 Connectivity Service Module (L1CSM) to the TE and VN 1705 Copyright (c) 2022 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 Revised 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 revision 2022-03-07 { 1719 description 1720 "Initial revision."; 1721 reference 1722 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1723 } 1725 /* 1726 * Augmentation to L1CSM 1727 */ 1729 augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" { 1730 description 1731 "L1CSM augmented to include TE parameters and mapping"; 1732 container te-service-mapping { 1733 presence "Indicates L1 service to TE mapping"; 1734 description 1735 "Container to augment L1CSM to TE parameters and mapping"; 1736 uses tsmt:te-mapping; 1738 } 1739 } 1741 //augment 1743 augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/" 1744 + "l1csm:uni" { 1745 description 1746 "This augment the L1CSM UNI with a reference 1747 to TE endpoints"; 1748 uses tsmt:te-endpoint-ref; 1749 } 1751 //augment 1752 } 1753 1755 7.3. Network Models 1757 7.3.1. ietf-l3nm-te-service-mapping 1759 file "ietf-l3nm-te-service-mapping@2022-03-07.yang" 1760 module ietf-l3nm-te-service-mapping { 1761 yang-version 1.1; 1762 namespace 1763 "urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping"; 1764 prefix l3nm-tsm; 1766 import ietf-te-service-mapping-types { 1767 prefix tsmt; 1768 reference 1769 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1770 } 1771 import ietf-l3vpn-ntw { 1772 prefix l3vpn-ntw; 1773 reference 1774 "I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model"; 1775 } 1777 organization 1778 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1779 Working Group"; 1780 contact 1781 "WG Web: 1782 WG List: 1784 Editor: Young Lee 1785 1787 Editor: Dhruv Dhody 1788 1789 Editor: Qin Wu 1790 "; 1791 description 1792 "This module contains a YANG module for the mapping of Layer 3 1793 Network Model (L3NM) to the TE and VN. 1795 Copyright (c) 2022 IETF Trust and the persons identified as 1796 authors of the code. All rights reserved. 1798 Redistribution and use in source and binary forms, with or 1799 without modification, is permitted pursuant to, and subject to 1800 the license terms contained in, the Revised BSD License set 1801 forth in Section 4.c of the IETF Trust's Legal Provisions 1802 Relating to IETF Documents 1803 (https://trustee.ietf.org/license-info). 1805 This version of this YANG module is part of RFC XXXX; see the 1806 RFC itself for full legal notices."; 1808 revision 2022-03-07 { 1809 description 1810 "Initial revision."; 1811 reference 1812 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1813 } 1815 /* 1816 * Augmentation to L3NM 1817 */ 1819 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1820 + "/l3vpn-ntw:vpn-service" { 1821 description 1822 "L3SM augmented to include TE parameters and mapping"; 1823 container te-service-mapping { 1824 presence "Indicates L3 network to TE mapping"; 1825 description 1826 "Container to augment l3nm to TE parameters and mapping"; 1827 uses tsmt:te-mapping; 1828 } 1829 } 1831 //augment 1833 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1834 + "/l3vpn-ntw:vpn-service" 1835 + "/l3vpn-ntw:vpn-nodes/l3vpn-ntw:vpn-node" 1836 + "/l3vpn-ntw:vpn-network-accesses" 1837 + "/l3vpn-ntw:vpn-network-access" { 1838 description 1839 "This augment the L3NM network-access with a reference 1840 to TE endpoints when underlying TE is used"; 1841 uses tsmt:te-endpoint-ref; 1842 } 1844 //augment 1845 } 1846 1848 7.3.2. ietf-l2nm-te-service-mapping 1850 file "ietf-l2nm-te-service-mapping@2022-03-07.yang" 1851 module ietf-l2nm-te-service-mapping { 1852 yang-version 1.1; 1853 namespace 1854 "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping"; 1855 prefix l2nm-tsm; 1857 import ietf-te-service-mapping-types { 1858 prefix tsmt; 1859 reference 1860 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1861 } 1862 import ietf-l2vpn-ntw { 1863 prefix l2vpn-ntw; 1864 reference 1865 "I-D.ietf-opsawg-l2nm: A Layer 2 VPN Network YANG Model"; 1866 } 1868 organization 1869 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1870 Working Group"; 1871 contact 1872 "WG Web: 1873 WG List: 1875 Editor: Young Lee 1876 1877 Editor: Dhruv Dhody 1878 1879 Editor: Qin Wu 1880 "; 1881 description 1882 "This module contains a YANG module for the mapping of Layer 2 1883 Network Model (L2NM) to the TE and VN. 1885 Copyright (c) 2022 IETF Trust and the persons identified as 1886 authors of the code. All rights reserved. 1888 Redistribution and use in source and binary forms, with or 1889 without modification, is permitted pursuant to, and subject to 1890 the license terms contained in, the Revised BSD License set 1891 forth in Section 4.c of the IETF Trust's Legal Provisions 1892 Relating to IETF Documents 1893 (https://trustee.ietf.org/license-info). 1895 This version of this YANG module is part of RFC XXXX; see the 1896 RFC itself for full legal notices."; 1898 revision 2022-03-07 { 1899 description 1900 "Initial revision."; 1901 reference 1902 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1903 } 1905 /* 1906 * Augmentation to L2NM 1907 */ 1909 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1910 + "/l2vpn-ntw:vpn-service" { 1911 description 1912 "L2SM augmented to include TE parameters and mapping"; 1913 container te-service-mapping { 1914 presence "Indicates L2 network to TE mapping"; 1915 description 1916 "Container to augment l2nm to TE parameters and mapping"; 1917 uses tsmt:te-mapping; 1918 } 1919 } 1921 //augment 1923 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1924 + "/l2vpn-ntw:vpn-service" 1925 + "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node" 1926 + "/l2vpn-ntw:vpn-network-accesses" 1927 + "/l2vpn-ntw:vpn-network-access" { 1928 description 1929 "This augment the L2NM network-access with a reference 1930 to TE endpoints when underlying TE is used"; 1932 uses tsmt:te-endpoint-ref; 1933 } 1935 //augment 1936 } 1937 1939 8. Security Considerations 1941 The YANG modules defined in this document is designed to be accessed 1942 via network management protocol such as NETCONF [RFC6241] or RESTCONF 1943 [RFC8040]. The lowest NETCONF layer is the secure transport layer 1944 and the mandatory-to-implement secure transport is SSH [RFC6242]. 1945 The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement 1946 secure transport is TLS [RFC8446] 1948 The NETCONF access control model [RFC8341] provides the means to 1949 restrict access for particular NETCONF or RESTCONF users to a pre- 1950 configured subset of all available NETCONF or RESTCONF protocol 1951 operations and content. 1953 There are a number of data nodes defined in the YANG moduleS which 1954 are writable/creatable/deletable (i.e., config true, which is the 1955 default). These data nodes may be considered sensitive or vulnerable 1956 in some network environments. Write operations (e.g., ) 1957 to these data nodes without proper protection can have a negative 1958 effect on network operations. These are the subtrees and data nodes 1959 and their sensitivity/vulnerability: 1961 * /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1962 - can configure TE Service mapping. 1964 * /l3vpn-svc/sites/site/site-network-accesses/site-network-access/ 1965 te/ - can configure TE Endpoint mapping. 1967 * /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1968 - can configure TE Service mapping. 1970 * /l2vpn-svc/sites/site/site-network-accesses/site-network-access/ 1971 te/ - can configure TE Endpoint mapping. 1973 * /l1-connectivity/services/service/te-service-mapping/te-mapping/ - 1974 can configure TE Service mapping. 1976 * /l1-connectivity/access/unis/uni/te/ - can configure TE Endpoint 1977 mapping. 1979 * /l3vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1980 - can configure TE Network mapping. 1982 * /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1983 network-accesses/vpn-network-access/te/ - can configure TE 1984 Endpoint mapping. 1986 * /l2vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1987 - can configure TE Network mapping. 1989 * /l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1990 network-accesses/vpn-network-access/te/ - can configure TE 1991 Endpoint mapping. 1993 Unauthorized access to above list can adversely affect the VPN 1994 service. 1996 Some of the readable data nodes in the YANG module may be considered 1997 sensitive or vulnerable in some network environments. It is thus 1998 important to control read access (e.g., via get, get-config, or 1999 notification) to these data nodes. The TE related parameters 2000 attached to the VPN service can leak sensitive information about the 2001 network. This is applicable to all elements in the yang models 2002 defined in this document. 2004 This document has no RPC defined. 2006 9. IANA Considerations 2008 This document request the IANA to register six URIs in the "IETF XML 2009 Registry" [RFC3688]. Following the format in RFC 3688, the following 2010 registrations are requested - 2011 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 2012 Registrant Contact: The IESG. 2013 XML: N/A, the requested URI is an XML namespace. 2015 URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 2016 Registrant Contact: The IESG. 2017 XML: N/A, the requested URI is an XML namespace. 2019 URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 2020 Registrant Contact: The IESG. 2021 XML: N/A, the requested URI is an XML namespace. 2023 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 2024 Registrant Contact: The IESG. 2025 XML: N/A, the requested URI is an XML namespace. 2027 URI: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 2028 Registrant Contact: The IESG. 2029 XML: N/A, the requested URI is an XML namespace. 2031 URI: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 2032 Registrant Contact: The IESG. 2033 XML: N/A, the requested URI is an XML namespace. 2035 This document request the IANA to register six YANG modules in the 2036 "YANG Module Names" registry [RFC6020], as follows - 2037 Name: ietf-te-service-mapping-types 2038 Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 2039 Prefix: tsmt 2040 Reference: [This.I-D] 2042 Name: ietf-l3sm-te-service-mapping 2043 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 2044 Prefix: l3-tsm 2045 Reference: [This.I-D] 2047 Name: ietf-l2sm-te-service-mapping 2048 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 2049 Prefix: l2-tsm 2050 Reference: [This.I-D] 2052 Name: ietf-l1csm-te-service-mapping 2053 Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 2054 Prefix: l1-tsm 2055 Reference: [This.I-D] 2057 Name: ietf-l3nm-te-service-mapping 2058 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 2059 Prefix: l3nm-tsm 2060 Reference: [This.I-D] 2062 Name: ietf-l2nm-te-service-mapping 2063 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 2064 Prefix: l2nm-tsm 2065 Reference: [This.I-D] 2067 10. Acknowledgements 2069 We thank Diego Caviglia, and Igor Bryskin for useful discussions and 2070 motivation for this work. 2072 11. References 2074 11.1. Normative References 2076 [I-D.ietf-ccamp-l1csm-yang] 2077 Lee, Y., Lee, K., Zheng, H., Dios, O. G. D., and D. 2078 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2079 Model (L1CSM)", Work in Progress, Internet-Draft, draft- 2080 ietf-ccamp-l1csm-yang-16, 13 December 2021, 2081 . 2084 [I-D.ietf-opsawg-l2nm] 2085 Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. 2086 Munoz, "A Layer 2 VPN Network YANG Model", Work in 2087 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22 2088 November 2021, . 2091 [I-D.ietf-opsawg-l3sm-l3nm] 2092 Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., 2093 and A. Aguado, "A YANG Network Data Model for Layer 3 2094 VPNs", Work in Progress, Internet-Draft, draft-ietf- 2095 opsawg-l3sm-l3nm-18, 8 October 2021, 2096 . 2099 [I-D.ietf-spring-sr-policy-yang] 2100 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 2101 Matsushima, S., and V. P. Beeram, "YANG Data Model for 2102 Segment Routing Policy", Work in Progress, Internet-Draft, 2103 draft-ietf-spring-sr-policy-yang-01, 7 April 2021, 2104 . 2107 [I-D.ietf-teas-actn-vn-yang] 2108 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 2109 Yoon, "A YANG Data Model for VN Operation", Work in 2110 Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-14, 2111 7 March 2022, . 2114 [I-D.ietf-teas-yang-te] 2115 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 2116 and O. G. D. Dios, "A YANG Data Model for Traffic 2117 Engineering Tunnels, Label Switched Paths and Interfaces", 2118 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 2119 29, 7 February 2022, 2120 . 2123 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2124 DOI 10.17487/RFC3688, January 2004, 2125 . 2127 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2128 the Network Configuration Protocol (NETCONF)", RFC 6020, 2129 DOI 10.17487/RFC6020, October 2010, 2130 . 2132 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2133 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2134 . 2136 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 2137 Ceccarelli, D., and X. Zhang, "Problem Statement and 2138 Architecture for Information Exchange between 2139 Interconnected Traffic-Engineered Networks", BCP 206, 2140 RFC 7926, DOI 10.17487/RFC7926, July 2016, 2141 . 2143 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2144 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2145 . 2147 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2148 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2149 . 2151 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2152 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2153 DOI 10.17487/RFC8299, January 2018, 2154 . 2156 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2157 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2158 . 2160 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2161 Access Control Model", STD 91, RFC 8341, 2162 DOI 10.17487/RFC8341, March 2018, 2163 . 2165 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2166 and R. Wilton, "Network Management Datastore Architecture 2167 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2168 . 2170 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2171 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2172 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2173 2018, . 2175 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 2176 Routing Management (NMDA Version)", RFC 8349, 2177 DOI 10.17487/RFC8349, March 2018, 2178 . 2180 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2181 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2182 . 2184 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2185 Data Model for Layer 2 Virtual Private Network (L2VPN) 2186 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2187 2018, . 2189 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2190 "Common YANG Data Types for Traffic Engineering", 2191 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2192 . 2194 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2195 O. Gonzalez de Dios, "YANG Data Model for Traffic 2196 Engineering (TE) Topologies", RFC 8795, 2197 DOI 10.17487/RFC8795, August 2020, 2198 . 2200 11.2. Informative References 2202 [I-D.dhody-teas-te-traffic-yang] 2203 Dhody, D., "Traffic Mapping YANG model for Traffic 2204 Engineering (TE)", Work in Progress, Internet-Draft, 2205 draft-dhody-teas-te-traffic-yang-00, 24 October 2021, 2206 . 2209 [I-D.ietf-teas-actn-yang] 2210 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. 2211 Belotti, "Applicability of YANG models for Abstraction and 2212 Control of Traffic Engineered Networks", Work in Progress, 2213 Internet-Draft, draft-ietf-teas-actn-yang-08, 8 September 2214 2021, . 2217 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2218 and A. Bierman, Ed., "Network Configuration Protocol 2219 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2220 . 2222 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 2223 Classification", RFC 8199, DOI 10.17487/RFC8199, July 2224 2017, . 2226 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2227 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2228 . 2230 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2231 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2232 DOI 10.17487/RFC8453, August 2018, 2233 . 2235 Appendix A. Examples 2237 This section details a few examples on how the TE-service mapping is 2238 used in various scenarios. 2240 Example 1: An L3VPN service with an optimization criteria for the 2241 underlying TE as delay can be set in the mapping template and then 2242 augmented to the L3SM service. 2244 { 2245 "te-mapping-template":[ 2246 { 2247 "id": "delay", 2248 "map-type": "select", 2249 "optimizations": 2250 { 2251 "algorithm":{ 2252 "optimization-metric": [ 2253 { 2254 "metric-type":"path-metric-delay-average" 2255 } 2256 ] 2257 } 2258 } 2259 } 2260 ] 2261 } 2263 The L3SM service can map it to the existing least delay TE resources 2264 in form of a VN or TE-tunnels. 2266 Example 2: An L2VPN service with a bandwidth constraint and a hop- 2267 limit criteria for the underlying TE can be set in the mapping 2268 template and then augmented to the L2SM service. 2270 { 2271 "te-mapping-template":[ 2272 { 2273 "id": "bw-hop", 2274 "map-type": "new", 2275 "path-constraints":{ 2276 "te-bandwidth":{ 2277 "generic":10000 2278 }, 2279 "path-metric-bounds":{ 2280 "path-metric-bound":[ 2281 { 2282 "metric-type":"path-metric-hop", 2283 "upper-bound":10 2284 } 2285 ] 2286 } 2287 } 2288 ] 2289 } 2291 The L2SM service can map it to a new TE resources in form of a VN or 2292 TE-tunnels. 2294 Example 3: A VN (VN1) could be created before hand and then 2295 explicitly mapped to the L2VPN service as shown below. 2297 2298 2299 2300 2301 VPN1 2302 2303 2304 select 2305 2306 VN1 2307 2308 2309 2310 2311 2312 2314 Example 4: A VPN service may want different optimization criteria for 2315 some of its sites. The template does not allow for such a case but 2316 it can be achieved by creating the TE resources separately and then 2317 mapping them to the service. 2319 Appendix B. Out of Scope 2321 Scheduling is currently out of scope, although an operator could use 2322 their own scheduling mechanism on top of this YANG model. In future 2323 augmentations to this model might also be designed to integrate 2324 scheduling and calendering. 2326 Note that the mechanism to map traffic (for example the enterprise 2327 customer can tell, the traffic from source X on port Y should go on a 2328 path with delay less than Z) can be via local configuration or 2329 through a YANG model developed in the future (See one such attempt at 2330 [I-D.dhody-teas-te-traffic-yang]). 2332 Appendix C. Contributor Addresses 2333 Adrian Farrel 2334 Old Dog Consulting 2336 EMail: adrian@olddog.co.uk 2338 Italo Busi 2339 Huawei Technologies 2341 EMail: Italo.Busi@huawei.com 2343 Haomian Zheng 2344 Huawei Technologies 2346 EMail: zhenghaomian@huawei.com 2348 Anton Snitser 2349 Sedonasys 2351 EMail: antons@sedonasys.com 2353 SAMIER BARGUIL GIRALDO 2354 Telefonica 2356 EMail: samier.barguilgiraldo.ext@telefonica.com 2358 Oscar Gonzalez de Dios 2359 Telefonica 2361 EMail: oscar.gonzalezdedios@telefonica.com 2363 Carlo Perocchio 2364 Ericsson 2366 EMail: carlo.perocchio@ericsson.com 2368 Kenichi Ogaki 2369 KDDI 2370 Email: ke-oogaki@kddi.com 2372 Authors' Addresses 2374 Young Lee (editor) 2375 Samsung Electronics 2376 Email: younglee.tx@gmail.com 2377 Dhruv Dhody (editor) 2378 Huawei Technologies 2379 Divyashree Techno Park, Whitefield 2380 Bangalore 560066 2381 Karnataka 2382 India 2383 Email: dhruv.ietf@gmail.com 2385 Giuseppe Fioccola 2386 Huawei Technologies 2387 Email: giuseppe.fioccola@huawei.com 2389 Qin Wu (editor) 2390 Huawei Technologies 2391 Email: bill.wu@huawei.com 2393 Daniele Ceccarelli 2394 Ericsson 2395 Torshamnsgatan,48 2396 Stockholm, Sweden 2397 Email: daniele.ceccarelli@ericsson.com 2399 Jeff Tantsura 2400 Microsoft 2401 Email: jefftant.ietf@gmail.com