idnits 2.17.1 draft-ietf-teas-te-service-mapping-yang-09.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 19 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 725 has weird spacing: '...ic-type ide...' == Line 729 has weird spacing: '...w usage ide...' == Line 735 has weird spacing: '...rw name str...' == Line 742 has weird spacing: '...w usage ide...' == Line 792 has weird spacing: '...int-ref lea...' == (4 more instances...) -- The document date (24 October 2021) is 915 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 273, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-15 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-09 == 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-13 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-27 == 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: 27 April 2022 G. Fioccola 6 Q. Wu, Ed. 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 J. Tantsura 11 Microsoft 12 24 October 2021 14 Traffic Engineering (TE) and Service Mapping YANG Model 15 draft-ietf-teas-te-service-mapping-yang-09 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 27 April 2022. 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 (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 Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . . 20 86 6.3. Network Models . . . . . . . . . . . . . . . . . . . . . 21 87 6.3.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . 33 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. Contributor Addresses . . . . . . . . . . . . . . . 52 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 109 1. Introduction 111 Data models are a representation of objects that can be configured or 112 monitored within a system. Within the IETF, YANG [RFC7950] is the 113 language of choice for documenting data models, and YANG models have 114 been produced to allow configuration or modeling of a variety of 115 network devices, protocol instances, and network services. YANG data 116 models have been classified in [RFC8199] and [RFC8309]. 118 Framework for Abstraction and Control of Traffic Engineered Networks 119 (ACTN) [RFC8453] introduces an architecture to support virtual 120 network services and connectivity services. 121 [I-D.ietf-teas-actn-vn-yang] defines a YANG model and describes how 122 customers or end-to-end orchestrator can request and/or instantiate a 123 generic virtual network service. [I-D.ietf-teas-actn-yang] describes 124 the way IETF YANG models of different classifications can be applied 125 to the ACTN interfaces. In particular, it describes how customer 126 service models can be mapped into the CNC-MDSC Interface (CMI) of the 127 ACTN architecture. 129 The models presented in this document are also applicable in generic 130 context [RFC8309] as part of Customer Service Model used between 131 Service Orchestrator and Customer. 133 [RFC8299] provides a L3VPN service delivery YANG model for PE-based 134 VPNs. The scope of that draft is limited to a set of domains under 135 control of the same network operator to deliver services requiring TE 136 tunnels. 138 [RFC8466] provides a L2VPN service delivery YANG model for PE-based 139 VPNs. The scope of that draft is limited to a set of domains under 140 control of the same network operator to deliver services requiring TE 141 tunnels. 143 [I-D.ietf-ccamp-l1csm-yang] provides a L1 connectivity service 144 delivery YANG model for PE-based VPNs. The scope of that draft is 145 limited to a set of domains under control of the same network 146 operator to deliver services requiring TE tunnels. 148 While the IP/MPLS Provisioning Network Controller (PNC) is 149 responsible for provisioning the VPN service on the Provider Edge 150 (PE) nodes, the Multi-Domain Service Coordinator (MDSC) can 151 coordinate how to map the VPN services onto Traffic Engineering (TE) 152 tunnels. This is consistent with the two of the core functions of 153 the MDSC specified in [RFC8453]: 155 * Customer mapping/translation function: This function is to map 156 customer requests/commands into network provisioning requests that 157 can be sent to the PNC according to the business policies that 158 have been provisioned statically or dynamically. Specifically, it 159 provides mapping and translation of a customer's service request 160 into a set of parameters that are specific to a network type and 161 technology such that the network configuration process is made 162 possible. 164 * Virtual service coordination function: This function translates 165 customer service-related information into virtual network service 166 operations in order to seamlessly operate virtual networks while 167 meeting a customer's service requirements. In the context of 168 ACTN, service/virtual service coordination includes a number of 169 service orchestration functions such as multi-destination load 170 balancing, guarantees of service quality, bandwidth and 171 throughput. It also includes notifications for service fault and 172 performance degradation and so forth. 174 Section 2 describes a set of TE and service related parameters that 175 this document addresses as "new and advanced parameters" that are not 176 included in the service models. Section 3 discusses YANG modeling 177 approach. 179 1.1. Purpose of TE Service Mapping for Service Model 181 The TE service mapping for the LxSM supports: 183 * A mapping of the LxSM with the underlying TE resources. The TE 184 resources could be in a form of VN, set of TE tunnels, TE abstract 185 topology etc. This mapping can be populated by the network at the 186 time of realization of the service. It is also possible to 187 configure the mapping provided one is aware of VN/tunnels. This 188 mapping model is used only when the there is an awareness of VN or 189 TE by the consumer of the model. Otherwise this mapping 190 information is internal and used for monitoring and diagnostics 191 purpose such as telemetry, auto-scaling, closed-loop automation. 193 * Possibility to request creation of a new VN/Tunnel to be binded to 194 LxSM . 196 * Indication to share the VN/Tunnel sharing (with or without 197 modification) for the LxSM. 199 * Support for configuration of underlying TE properties (as apposed 200 to existing VN or tunnels). 202 * Provide some additional service characteristics for the LxSM 203 models 205 1.2. Purpose of TE Service Mapping for Network Model 207 Apart from the service model, the TE mapping is equally applicable to 208 the Network Models (L3 VPN Service Network Model (L3NM) 209 [I-D.ietf-opsawg-l3sm-l3nm], L2 VPN Service Network Model (L2NM) 210 [I-D.ietf-opsawg-l2nm] etc.). See Section 3.2 for details. 212 The TE service mapping for the LxNM supports: 214 * A mapping of the LxNM with the underlying TE resources. The TE 215 resources could be in a form of VN, set of TE tunnels, TE abstract 216 topology etc. This mapping can be populated by the network or 217 configured. This mapping is useful to understand the TE 218 realization of the LxVPN as well for monitoring/diagnostic 219 purpose. 221 * Possibility to request creation of a new VN/Tunnel to be binded to 222 LxNM . 224 * Indication to share the VN/Tunnel sharing (with or without 225 modification) for the LxNM. 227 * Support for configuration of underlying TE properties (as apposed 228 to existing VN or tunnels). 230 * Provide some additional service characteristics for the LxNM 231 models 233 1.3. Terminology 235 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 236 in this document. 238 The terminology for describing YANG data models is found in 239 [RFC7950]. 241 1.4. Tree diagram 243 A simplified graphical representation of the data model is used in 244 Section 5 of this this document. The meaning of the symbols in these 245 diagrams is defined in [RFC8340]. 247 1.5. Prefixes in Data Node Names 249 In this document, names of data nodes and other data model objects 250 are prefixed using the standard prefix associated with the 251 corresponding YANG imported modules, as shown in Table 1. 253 +========+==================+==================================+ 254 | Prefix | YANG module | Reference | 255 +========+==================+==================================+ 256 | tsmt | ietf-te-service- | [RFCXXXX] | 257 | | mapping-types | | 258 +--------+------------------+----------------------------------+ 259 | l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang] | 260 +--------+------------------+----------------------------------+ 261 | l2vpn- | ietf-l2vpn-svc | [RFC8466] | 262 | svc | | | 263 +--------+------------------+----------------------------------+ 264 | l3vpn- | ietf-l3vpn-svc | [RFC8299] | 265 | svc | | | 266 +--------+------------------+----------------------------------+ 267 | l1-tsm | ietf-l1csm-te- | [RFCXXXX] | 268 | | service-mapping | | 269 +--------+------------------+----------------------------------+ 270 | l2-tsm | ietf-l2sm-te- | [RFCXXXX] | 271 | | service-mapping | | 272 +--------+------------------+----------------------------------+ 273 | l3-tsm | ietf-l3sm-te- | [RFCXXXX] | 274 | | service-mapping | | 275 +--------+------------------+----------------------------------+ 276 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang] | 277 +--------+------------------+----------------------------------+ 278 | nw | ietf-network | [RFC8345] | 279 +--------+------------------+----------------------------------+ 280 | te- | ietf-te-types | [RFC8776] | 281 | types | | | 282 +--------+------------------+----------------------------------+ 283 | te | ietf-te | [I-D.ietf-teas-yang-te] | 284 +--------+------------------+----------------------------------+ 285 | l2vpn- | ietf-l2vpn-ntw | [I-D.ietf-opsawg-l2nm] | 286 | ntw | | | 287 +--------+------------------+----------------------------------+ 288 | l3vpn- | ietf-l3vpn-ntw | [I-D.ietf-opsawg-l3sm-l3nm] | 289 | ntw | | | 290 +--------+------------------+----------------------------------+ 291 | rt | ietf-routing | [RFC8349] | 292 +--------+------------------+----------------------------------+ 293 | sr- | ietf-sr-policy | [I-D.ietf-spring-sr-policy-yang] | 294 | policy | | | 295 +--------+------------------+----------------------------------+ 297 Table 1: Prefixes and corresponding YANG modules 299 Note: The RFC Editor should replace XXXX with the number assigned to 300 the RFC once this draft becomes an RFC. 302 2. TE and Service Related Parameters 304 While L1/L2/L3 service models (L1CSM, L2SM, L3SM) are intended to 305 provide service-specific parameters for VPN service instances, there 306 are a number of TE Service related parameters that are not included 307 in these service models. 309 Additional 'service parameters and policies' that are not included in 310 the aforementioned service models are addressed in the YANG models 311 defined in this document. 313 2.1. VN/Tunnel Selection Requirements 315 In some cases, the service requirements may need addition VN/TE 316 tunnels to be established. This may occur when there are no suitable 317 existing VN/TE tunnels that can support the service requirements, or 318 when the operator would like to dynamically create and bind tunnels 319 to the VPN such that they are not shared by other VPNs, for example, 320 for network slicing. The establishment of TE tunnels is subject to 321 the network operator's policies. 323 To summarize, there are three modes of VN/Tunnel selection operations 324 to be supported as follows. Additional modes may be defined in the 325 future. 327 * New VN/Tunnel Binding - A customer could request a VPN service 328 based on VN/Tunnels that are not shared with other existing or 329 future services. This might be to meet VPN isolation 330 requirements. Further, the YANG model described in Section 4 of 331 this document can be used to describe the mapping between the VPN 332 service and the ACTN VN. The VN (and TE tunnels) could be bound 333 to the VPN and not used for any other VPN. Under this mode, the 334 following sub-categories can be supported: 336 1. Hard Isolation with deterministic characteristics: A customer 337 could request a VPN service using a set of TE Tunnels with 338 deterministic characteristics requirements (e.g., no latency 339 variation) and where that set of TE Tunnels must not be shared 340 with other VPN services and must not compete for bandwidth or 341 other network resources with other TE Tunnels. 343 2. Hard Isolation: This is similar to the above case but without 344 the deterministic characteristics requirements. 346 3. Soft Isolation: The customer requests a VPN service using a 347 set of new TE tunnels which can be shared with other VPN 348 services if need be. 350 * VN/Tunnel Sharing - A customer could request a VPN service where 351 new tunnels (or a VN) do not need to be created for each VPN and 352 can be shared across multiple VPNs. Further, the mapping YANG 353 model described in Section 5 of this document can be used to 354 describe the mapping between the VPN service and the tunnels in 355 use. No modification of the properties of a tunnel (or VN) is 356 allowed in this mode: an existing tunnel can only be selected. 358 * VN/Tunnel Modify - This mode allows the modification of the 359 properties of the existing VN/tunnel (e.g., bandwidth). 361 * TE Mapping Template - This mode allows a VPN service to use a 362 mapping template containing constraints and optimization criteria. 363 This allows mapping with the underlay TE characteristics without 364 first creating a VN or tunnels to map. The VPN service could be 365 mapped to a template first. Once the VN/Tunnels are actually 366 created/selected for the VPN service, the mapping based on the 367 actual TE resources is created. 369 2.2. TE Policy 371 The service models could be associated with various policies related 372 to mapping the underlying TE resources. A color could be used to map 373 to the underlying colored TE resources. The desired protection and 374 availability requirements could be specified. 376 2.2.1. Availability Requirement 378 Availability is another service requirement or intent that may 379 influence the selection or provisioning of TE tunnels or a VN to 380 support the requested service. Availability is a probabilistic 381 measure of the length of time that a VPN/VN instance functions 382 without a network failure. 384 The availability level will need to be translated into network 385 specific policies such as the protection/reroute policy associated 386 with a VN or Tunnel. The means by which this is achieved is not in 387 the scope of this document. 389 3. YANG Modeling Approach 391 This section provides how the TE and Service mapping parameters are 392 supported using augmentation of the existing service models (i.e., 393 [I-D.ietf-ccamp-l1csm-yang], [RFC8466], and [RFC8299]). Figure 1 394 shows the scope of the Augmented LxSM Model. 396 +--------------+ +----------------------+ +----------+ 397 | LxSM |o-------| | . . . . | ACTN VN | 398 +--------------+ augment| | +----------+ 399 | | +----------+ 400 +--------------+ | Augmented LxSM Model | . . . . | TE-topo | 401 | TE & Service |------->| | +----------+ 402 | Mapping Types| import | | +----------+ 403 +--------------+ | | . . . . | TE-tunnel| 404 +----------------------+ +----------+ 405 reference 407 Figure 1: Augmented LxSM Model 409 The Augmented LxSM model (where x=1,2,3) augments the basic LxSM 410 model while importing the common TE and Service related parameters 411 (defined in Section 2) grouping information from TE and Service 412 Mapping Types. The TE and Service Mapping Types (ietf-te-service- 413 mapping-types) module is the repository of all common groupings 414 imported by each augmented LxSM model. Any future service models 415 would import this mapping-type common model. 417 The mapping could be made to any underlying TE resources such as VN, 418 TE topology abstract node (and its connectivity matrix), set of TE 419 tunnels etc. This flexibility from the modeling point of view allows 420 for various use cases at both service and network model. 422 The role of the augmented LxSM is to expose the mapping relationship 423 between service models and TE models so that VN/VPN service 424 instantiations provided by the underlying TE networks can be viewed 425 outside of the MDSC, for example by an operator who is diagnosing the 426 behavior of the network. Note that this should be done only if the 427 operator understands the VN/Tunnel resources and the the MDSC is 428 willing to share that information. It also allows for the customers 429 to access operational state information about how their services are 430 instantiated with the underlying VN, TE topology or TE tunnels. This 431 mapping will facilitate a seamless service management operation with 432 underlay-TE network visibility. 434 As seen in Figure 1, the augmented LxSM service model records a 435 mapping between the customer service models and the ACTN VN YANG 436 model. Thus, when the MDSC receives a service request it creates a 437 VN that meets the customer's service objectives with various 438 constraints via TE-topology model [RFC8795], and this relationship is 439 recorded by the Augmented LxSM Model. The model also supports a 440 mapping between a service model and TE-topology or a TE-tunnel. 442 The YANG models defined in this document conforms to the Network 443 Management Datastore Architecture (NMDA) [RFC8342]. 445 3.1. Forward Compatibility 447 The YANG module defined in this document supports three existing 448 service models via augmenting while sharing the common TE and Service 449 Mapping Types. 451 It is possible that new service models will be defined at some future 452 time and that it will be desirable to map them to underlying TE 453 constructs in the same way as the three existing models are 454 augmented. 456 Scheduling is currently out of scope, although an operator could use 457 their own scheduling mechanism on top of this YANG model. In future 458 augmentations to this model might also be designed to integrate 459 scheduling and calendering. 461 Note that the mechanism to map traffic (for example the enterprise 462 customer can tell, the traffic from source X on port Y should go on a 463 path with delay less than Z) can be via local configuration or 464 through a YANG model developed in the future (See one such attempt at 465 [I-D.dhody-teas-te-traffic-yang]). 467 3.2. TE and Network Models 469 The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN 470 Service in the Service Provider Network. It contains information of 471 the Service Provider network and might include allocated resources. 472 It can be used by network controllers to manage and control the VPN 473 Service configuration in the Service Provider network. 475 Similar to service model, the existing network models (i.e., 476 [I-D.ietf-opsawg-l3sm-l3nm], and [I-D.ietf-opsawg-l2nm]) are 477 augmented to include the TE and Service mapping parameters. Figure 2 478 shows the scope of the Augmented LxNM Model. 480 +--------------+ +----------------------+ +----------+ 481 | LxNM |o-------| | . . . . | ACTN VN | 482 +--------------+ augment| | +----------+ 483 | | +----------+ 484 +--------------+ | Augmented LxNM Model | . . . . | TE-topo | 485 | TE & Service |------->| | +----------+ 486 | Mapping Types| import | | +----------+ 487 +--------------+ | | . . . . | TE-tunnel| 488 +----------------------+ +----------+ 489 reference 491 Figure 2: Augmented LxNM Model 493 The Augmented LxNM model (where x=2,3) augments the basic LxNM model 494 while importing the common TE mapping related parameters (defined in 495 Section 2) grouping information from TE and Service Mapping Types. 496 The role of the augmented LxNM network model is to expose the mapping 497 relationship between network models and TE models. 499 4. L3VPN Architecture in the ACTN Context 501 Figure 3 shows the architectural context of this document referencing 502 the ACTN components and interfaces. 504 +----------------------------+ 505 | Customer Service Manager | 506 | +-----------------------+ | 507 | | CNC + | 508 | +-+-------------------+-+ | 509 +----|-------------------|---+ 510 | | 511 |CMI(Augmented L3SM)|CMI(VN) 512 | | 513 +----------------|-------------------|----+ 514 | +--------------|-----------------+ | | 515 | | MDSC | | | | 516 | | | | | | 517 | | +-----------+--------------+ | | | 518 TE-Svc-Map<------+ Service Mapping Function | | | | 519 | | +-----------+--------------+ | | | 520 | | | | | | 521 | +-------+------|-----------------+ | | 522 | | | | | 523 | | |CMI(VN) | | 524 | | | | | 525 | | +--|-------------------|--+ | 526 | | | | MDSC | | | 527 | | | ++-------------------++ | | 528 | | | + Service Mapping +---->TE-Svc-Map 529 | | | ++----------+---------+ | | 530 | | +--|----------|-----------+ | 531 +---------|------|----------|-------------+ 532 | | | 533 | +----+--------+ | 534 | | | | 535 MPI(VPN / TE models)| | | |MPI(TE / L1 models) 536 | | | | 537 +-----|-|---+ +-----|-|----+ 538 IP/MPLS | +--+-+-+ | | +--+-+-+ | Optical Domain 539 Domain | | PNC1 | | | | PNC2 | | Controller 540 Controller | +--+---+ | | +--+---+ | 541 +-----|-----+ +-----|------+ 542 | | 543 V | SBI 544 +---------------------+ | 545 / IP/MPLS Network \ | 546 +-------------------------+ | 547 V 548 +---------------------+ 549 / Optical Network \ 550 +-------------------------+ 552 Figure 3: L3VPN Architecture from the IP+Optical Network Perspective 554 There are three main entities in the ACTN architecture and shown in 555 Figure 3. 557 * CNC: The Customer Network Controller is responsible for generating 558 service requests. In the context of an L3VPN, the CNC uses the 559 Augmented L3SM to express the service request and communicate it 560 to the network operator. 562 * MDSC: This entity is responsible for coordinating a L3VPN service 563 request (expressed via the Augmented L3SM) with the IP/MPLS PNC 564 and the Transport PNC. For TE services, one of the key 565 responsibilities of the MDSC is to coordinate with both the IP PNC 566 and the Transport PNC for the mapping of the Augmented L3VPN 567 Service Model to the ACTN VN model. In the VN/TE-tunnel binding 568 case, the MDSC will need to coordinate with the Transport PNC to 569 dynamically create the TE-tunnels in the transport network as 570 needed. These tunnels are added as links in the IP/MPLS Layer 571 topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 572 tunnels in the IP/MPLS layer, as part of the ACTN VN creation. 574 * PNC: The Provisioning Network Controller is responsible for 575 configuring and operating the network devices. Figure 3 shows two 576 distinct PNCs. 578 - IP/MPLS PNC (PNC1): This entity is responsible for device 579 configuration to create PE-PE L3VPN tunnels for the VPN 580 customer and for the configuration of the L3VPN VRF on the PE 581 nodes. Each network element would select a tunnel based on the 582 configuration. 584 - Transport PNC (PNC2): This entity is responsible for device 585 configuration for TE tunnels in the transport networks. 587 The three main interfaces are shown in Figure 3 and listed below. 589 * CMI: The CNC-MDSC Interface is used to communicate service 590 requests from the customer to the operator. The requests may be 591 expressed as Augmented VPN service requests (L2SM, L3SM), as 592 connectivity requests (L1CSM), or as virtual network requests 593 (ACTN VN). 595 * MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate 596 networks under the control of PNCs. The requests on this 597 interface may use TE tunnel models, TE topology models, VPN 598 network configuration models or layer one connectivity models. 600 * SBI: The Southbound Interface is used by the PNC to control 601 network devices and is out of scope for this document. 603 The TE Service Mapping Model as described in this document can be 604 used to see the mapping between service models and VN models and TE 605 Tunnel/Topology models. That mapping may occur in the CNC if a 606 service request is mapped to a VN request. Or it may occur in the 607 MDSC where a service request is mapped to a TE tunnel, TE topology, 608 or VPN network configuration model. The TE Service Mapping Model may 609 be read from the CNC or MDSC to understand how the mapping has been 610 made and to see the purpose for which network resources are used. 612 As shown in Figure 3, the MDSC may be used recursively. For example, 613 the CNC might map a L3SM request to a VN request that it sends to a 614 recursive MDSC. 616 The high-level control flows for one example are as follows: 618 1. A customer asks for an L3VPN between CE1 and CE2 using the 619 Augmented L3SM model. 621 2. The MDSC considers the service request and local policy to 622 determine if it needs to create a new VN or any TE Topology, and 623 if that is the case, ACTN VN YANG [I-D.ietf-teas-actn-vn-yang] is 624 used to configure a new VN based on this VPN and map the VPN 625 service to the ACTN VN. In case an existing tunnel is to be 626 used, each device will select which tunnel to use and populate 627 this mapping information. 629 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 630 PNC to create a PE-PE tunnel in the IP network mapped to a TE 631 tunnel in the transport network by providing the inter-layer 632 access points and tunnel requirements. The specific service 633 information is passed to the IP/MPLS PNC for the actual VPN 634 configuration and activation. 636 a. The Transport PNC creates the corresponding TE tunnel 637 matching with the access point and egress point. 639 b. The IP/MPLS PNC maps the VPN ID with the corresponding TE 640 tunnel ID to bind these two IDs. 642 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 643 customer. This is not in the scope of this document. 645 4.1. Service Mapping 647 Augmented L3SM and L2SM can be used to request VPN service creation 648 including the creation of sites and corresponding site network access 649 connection between CE and PE. A VPN-ID is used to identify each VPN 650 service ordered by the customer. The ACTN VN can be used further to 651 establish PE-to-PE connectivity between VPN sites belonging to the 652 same VPN service. A VN-ID is used to identify each virtual network 653 established between VPN sites. 655 Once the ACTN VN has been established over the TE network (maybe a 656 new VN, maybe modification of an existing VN, or maybe the use of an 657 unmodified existing VN), the mapping between the VPN service and the 658 ACTN VN service can be created. 660 4.2. Site Mapping 662 The elements in Augmented L3SM and L2SM define site location 663 parameters and constraints such as distance and access diversity that 664 can influence the placement of network attachment points (i.e, 665 virtual network access points (VNAP)). To achieve this, a central 666 directory can be set up to establish the mapping between location 667 parameters and constraints and network attachment point location. 668 Suppose multiple attachment points are matched, the management system 669 can use constraints or other local policy to select the best 670 candidate network attachment points. 672 After a network attachment point is selected, the mapping between VPN 673 site and VNAP can be established as shown in Table 1. 675 +=======+=========+==================+========================+=====+ 676 | Site | Site | Location | Access Diversity | PE | 677 | | Network | (Address, | (Constraint-Type, | | 678 | | Access | Postal Code, | Group-id,Target Group- | | 679 | | | State, | id) | | 680 | | | City,Country | | | 681 | | | Code) | | | 682 +=======+=========+==================+========================+=====+ 683 | SITE1 | ACCESS1 | (,,US,NewYork,) | (10,PE-Diverse,10) | PE1 | 684 +-------+---------+------------------+------------------------+-----+ 685 | SITE2 | ACCESS2 | (,,CN,Beijing,) | (10,PE-Diverse,10) | PE2 | 686 +-------+---------+------------------+------------------------+-----+ 687 | SITE3 | ACCESS3 | (,,UK,London, ) | (12,same-PE,12) | PE4 | 688 +-------+---------+------------------+------------------------+-----+ 689 | SITE4 | ACCESS4 | (,,FR,Paris,) | (20,Bearer-Diverse,20) | PE7 | 690 +-------+---------+------------------+------------------------+-----+ 692 Table 2: : Mapping Between VPN Site and VNAP 694 5. Applicability of TE-Service Mapping in Generic context 696 As discussed in the Introduction Section, the models presented in 697 this document are also applicable generically outside of the ACTN 698 architecture. [RFC8309] defines Customer Service Model between 699 Customer and Service Orchestrator and Service Delivery Model between 700 Service Orchestrator and Network Orchestrator(s). TE-Service mapping 701 models defined in this document can be regarded primarily as Customer 702 Service Model and secondarily as Service Deliver Model. 704 6. YANG Data Trees 706 6.1. Service Mapping Types 708 module: ietf-te-service-mapping-types 709 +--rw te-mapping-templates 710 +--rw te-mapping-template* [id] 711 +--rw id te-mapping-template-id 712 +--rw description? string 713 +--rw map-type? identityref 714 +--rw path-constraints 715 | +--rw te-bandwidth 716 | | +--rw (technology)? 717 | | +--:(generic) 718 | | +--rw generic? te-bandwidth 719 | +--rw link-protection? identityref 720 | +--rw setup-priority? uint8 721 | +--rw hold-priority? uint8 722 | +--rw signaling-type? identityref 723 | +--rw path-metric-bounds 724 | | +--rw path-metric-bound* [metric-type] 725 | | +--rw metric-type identityref 726 | | +--rw upper-bound? uint64 727 | +--rw path-affinities-values 728 | | +--rw path-affinities-value* [usage] 729 | | +--rw usage identityref 730 | | +--rw value? admin-groups 731 | +--rw path-affinity-names 732 | | +--rw path-affinity-name* [usage] 733 | | +--rw usage identityref 734 | | +--rw affinity-name* [name] 735 | | +--rw name string 736 | +--rw path-srlgs-lists 737 | | +--rw path-srlgs-list* [usage] 738 | | +--rw usage identityref 739 | | +--rw values* srlg 740 | +--rw path-srlgs-names 741 | | +--rw path-srlgs-name* [usage] 742 | | +--rw usage identityref 743 | | +--rw names* string 744 | +--rw disjointness? te-path-disjointness 745 +--rw optimizations 746 +--rw (algorithm)? 747 +--:(metric) {path-optimization-metric}? 748 | +--rw optimization-metric* [metric-type] 749 | | +--rw metric-type 750 | | | identityref 751 | | +--rw weight? uint8 752 | | +--rw explicit-route-exclude-objects 753 | | | ... 754 | | +--rw explicit-route-include-objects 755 | | ... 756 | +--rw tiebreakers 757 | +--rw tiebreaker* [tiebreaker-type] 758 | ... 759 +--:(objective-function) 760 {path-optimization-objective-function}? 761 +--rw objective-function 762 +--rw objective-function-type? identityref 764 6.2. Service Models 766 6.2.1. L3SM 768 module: ietf-l3sm-te-service-mapping 769 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services 770 /l3vpn-svc:vpn-service: 771 +--rw te-service-mapping! 772 +--rw te-mapping 773 +--rw map-type? identityref 774 +--rw te-policy 775 | +--rw color? uint32 776 | +--rw protection-type? identityref 777 | +--rw availability-type? identityref 778 +--rw (te)? 779 | +--:(vn) 780 | | +--rw vn* 781 | | -> /vn:virtual-network/vn/vn-id 782 | +--:(te-topo) 783 | | +--rw vn-topology-id? te-types:te-topology-id 784 | | +--rw abstract-node? 785 | | -> /nw:networks/network/node/node-id 786 | +--:(te-tunnel) 787 | +--rw te-tunnel* te:tunnel-ref 788 | +--rw sr-policy* 789 | [policy-color-ref policy-endpoint-ref] 790 | {sr-policy}? 791 | +--rw policy-color-ref leafref 792 | +--rw policy-endpoint-ref leafref 793 +--rw te-mapping-template-ref? 794 -> /tsmt:te-mapping-templates/te-mapping-template/id 795 {template}? 796 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 797 /l3vpn-svc:site-network-accesses 798 /l3vpn-svc:site-network-access: 799 +--rw (te)? 800 +--:(vn) 801 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 802 +--:(te) 803 +--rw ltp? te-types:te-tp-id 804 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 805 /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile 806 /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes 807 /l3vpn-svc:class: 808 +--rw (te)? 809 +--:(vn) 810 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 811 +--:(te) 812 +--rw ltp? te-types:te-tp-id 813 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 814 /l3vpn-svc:site-network-accesses 815 /l3vpn-svc:site-network-access/l3vpn-svc:service 816 /l3vpn-svc:qos/l3vpn-svc:qos-profile 817 /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes 818 /l3vpn-svc:class: 819 +--rw (te)? 820 +--:(vn) 821 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 822 +--:(te) 823 +--rw ltp? te-types:te-tp-id 825 6.2.2. L2SM 827 module: ietf-l2sm-te-service-mapping 828 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services 829 /l2vpn-svc:vpn-service: 830 +--rw te-service-mapping! 831 +--rw te-mapping 832 +--rw map-type? identityref 833 +--rw te-policy 834 | +--rw color? uint32 835 | +--rw protection-type? identityref 836 | +--rw availability-type? identityref 837 +--rw (te)? 838 | +--:(vn) 839 | | +--rw vn* 840 | | -> /vn:virtual-network/vn/vn-id 841 | +--:(te-topo) 842 | | +--rw vn-topology-id? te-types:te-topology-id 843 | | +--rw abstract-node? 844 | | -> /nw:networks/network/node/node-id 845 | +--:(te-tunnel) 846 | +--rw te-tunnel* te:tunnel-ref 847 | +--rw sr-policy* 848 | [policy-color-ref policy-endpoint-ref] 849 | {sr-policy}? 850 | +--rw policy-color-ref leafref 851 | +--rw policy-endpoint-ref leafref 852 +--rw te-mapping-template-ref? 853 -> /tsmt:te-mapping-templates/te-mapping-template/id 854 {template}? 855 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 856 /l2vpn-svc:site-network-accesses 857 /l2vpn-svc:site-network-access: 858 +--rw (te)? 859 +--:(vn) 860 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 861 +--:(te) 862 +--rw ltp? te-types:te-tp-id 863 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 864 /l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile 865 /l2vpn-svc:qos-profile/l2vpn-svc:custom/l2vpn-svc:classes 866 /l2vpn-svc:class: 867 +--rw (te)? 868 +--:(vn) 869 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 870 +--:(te) 871 +--rw ltp? te-types:te-tp-id 872 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 873 /l2vpn-svc:site-network-accesses 874 /l2vpn-svc:site-network-access/l2vpn-svc:service 875 /l2vpn-svc:qos/l2vpn-svc:qos-profile 876 /l2vpn-svc:qos-profile/l2vpn-svc:custom/l2vpn-svc:classes 877 /l2vpn-svc:class: 878 +--rw (te)? 879 +--:(vn) 880 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 881 +--:(te) 882 +--rw ltp? te-types:te-tp-id 884 6.2.3. L1CSM 885 module: ietf-l1csm-te-service-mapping 886 augment /l1csm:l1-connectivity/l1csm:services/l1csm:service: 887 +--rw te-service-mapping! 888 +--rw te-mapping 889 +--rw map-type? identityref 890 +--rw te-policy 891 | +--rw color? uint32 892 | +--rw protection-type? identityref 893 | +--rw availability-type? identityref 894 +--rw (te)? 895 | +--:(vn) 896 | | +--rw vn* 897 | | -> /vn:virtual-network/vn/vn-id 898 | +--:(te-topo) 899 | | +--rw vn-topology-id? te-types:te-topology-id 900 | | +--rw abstract-node? 901 | | -> /nw:networks/network/node/node-id 902 | +--:(te-tunnel) 903 | +--rw te-tunnel* te:tunnel-ref 904 | +--rw sr-policy* 905 | [policy-color-ref policy-endpoint-ref] 906 | {sr-policy}? 907 | +--rw policy-color-ref leafref 908 | +--rw policy-endpoint-ref leafref 909 +--rw te-mapping-template-ref? 910 -> /tsmt:te-mapping-templates/te-mapping-template/id 911 {template}? 912 augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni: 913 +--rw (te)? 914 +--:(vn) 915 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 916 +--:(te) 917 +--rw ltp? te-types:te-tp-id 919 6.3. Network Models 921 6.3.1. L3NM 922 module: ietf-l3nm-te-service-mapping 923 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 924 /l3vpn-ntw:vpn-service: 925 +--rw te-service-mapping! 926 +--rw te-mapping 927 +--rw map-type? identityref 928 +--rw te-policy 929 | +--rw color? uint32 930 | +--rw protection-type? identityref 931 | +--rw availability-type? identityref 932 +--rw (te)? 933 | +--:(vn) 934 | | +--rw vn* 935 | | -> /vn:virtual-network/vn/vn-id 936 | +--:(te-topo) 937 | | +--rw vn-topology-id? te-types:te-topology-id 938 | | +--rw abstract-node? 939 | | -> /nw:networks/network/node/node-id 940 | +--:(te-tunnel) 941 | +--rw te-tunnel* te:tunnel-ref 942 | +--rw sr-policy* 943 | [policy-color-ref policy-endpoint-ref] 944 | {sr-policy}? 945 | +--rw policy-color-ref leafref 946 | +--rw policy-endpoint-ref leafref 947 +--rw te-mapping-template-ref? 948 -> /tsmt:te-mapping-templates/te-mapping-template/id 949 {template}? 950 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 951 /l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes 952 /l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses 953 /l3vpn-ntw:vpn-network-access: 954 +--rw (te)? 955 +--:(vn) 956 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 957 +--:(te) 958 +--rw ltp? te-types:te-tp-id 960 6.3.2. L2NM 961 module: ietf-l2nm-te-service-mapping 962 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 963 /l2vpn-ntw:vpn-service: 964 +--rw te-service-mapping! 965 +--rw te-mapping 966 +--rw map-type? identityref 967 +--rw te-policy 968 | +--rw color? uint32 969 | +--rw protection-type? identityref 970 | +--rw availability-type? identityref 971 +--rw (te)? 972 | +--:(vn) 973 | | +--rw vn* 974 | | -> /vn:virtual-network/vn/vn-id 975 | +--:(te-topo) 976 | | +--rw vn-topology-id? te-types:te-topology-id 977 | | +--rw abstract-node? 978 | | -> /nw:networks/network/node/node-id 979 | +--:(te-tunnel) 980 | +--rw te-tunnel* te:tunnel-ref 981 | +--rw sr-policy* 982 | [policy-color-ref policy-endpoint-ref] 983 | {sr-policy}? 984 | +--rw policy-color-ref leafref 985 | +--rw policy-endpoint-ref leafref 986 +--rw te-mapping-template-ref? 987 -> /tsmt:te-mapping-templates/te-mapping-template/id 988 {template}? 989 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 990 /l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes 991 /l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses 992 /l2vpn-ntw:vpn-network-access: 993 +--rw (te)? 994 +--:(vn) 995 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 996 +--:(te) 997 +--rw ltp? te-types:te-tp-id 999 7. YANG Data Models 1001 The YANG codes are as follows: 1003 7.1. ietf-te-service-mapping-types 1004 file "ietf-te-service-mapping-types@2021-10-24.yang" 1005 module ietf-te-service-mapping-types { 1006 yang-version 1.1; 1007 namespace 1008 "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; 1009 prefix tsmt; 1011 /* Import te-types */ 1013 import ietf-te-types { 1014 prefix te-types; 1015 reference 1016 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 1017 } 1019 /* Import network model */ 1021 import ietf-network { 1022 prefix nw; 1023 reference 1024 "RFC 8345: A YANG Data Model for Network Topologies"; 1025 } 1027 /* Import TE model */ 1029 import ietf-te { 1030 prefix te; 1031 reference 1032 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1033 Engineering Tunnels and Interfaces"; 1034 } 1036 /* Import VN model */ 1038 import ietf-vn { 1039 prefix vn; 1040 reference 1041 "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation"; 1042 } 1044 /* Import Routing */ 1046 import ietf-routing { 1047 prefix rt; 1048 reference 1049 "RFC 8349: A YANG Data Model for Routing Management"; 1050 } 1051 /* Import SR Policy */ 1053 import ietf-sr-policy { 1054 prefix sr-policy; 1055 reference 1056 "I-D.ietf-spring-sr-policy-yang: YANG Data Model for Segment 1057 Routing Policy"; 1058 } 1060 organization 1061 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1062 Working Group"; 1063 contact 1064 "WG Web: 1065 WG List: 1067 Editor: Young Lee 1068 1069 Editor: Dhruv Dhody 1070 1071 Editor: Qin Wu 1072 "; 1073 description 1074 "This module contains a YANG module for TE & Service mapping 1075 parameters and policies as a common grouping applicable to 1076 variuous service models (e.g., L1CSM, L2SM, L3SM, etc.) 1078 Copyright (c) 2021 IETF Trust and the persons identified as 1079 authors of the code. All rights reserved. 1081 Redistribution and use in source and binary forms, with or 1082 without modification, is permitted pursuant to, and subject to 1083 the license terms contained in, the Simplified BSD License set 1084 forth in Section 4.c of the IETF Trust's Legal Provisions 1085 Relating to IETF Documents 1086 (https://trustee.ietf.org/license-info). 1088 This version of this YANG module is part of RFC XXXX; see the 1089 RFC itself for full legal notices."; 1091 revision 2021-10-24 { 1092 description 1093 "Initial revision."; 1094 reference 1095 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1096 } 1098 /* 1099 * Features 1100 */ 1102 feature template { 1103 description 1104 "Support TE mapping templates."; 1105 } 1107 feature sr-policy { 1108 description 1109 "Support SR Policy."; 1110 } 1112 /* 1113 * Identity for map-type 1114 */ 1116 identity map-type { 1117 description 1118 "Base identity from which specific map types are derived."; 1119 } 1121 identity new { 1122 base map-type; 1123 description 1124 "The new VN/tunnels are binded to the service."; 1125 } 1127 identity hard-isolation { 1128 base new; 1129 description 1130 "Hard isolation."; 1131 } 1133 identity detnet-hard-isolation { 1134 base hard-isolation; 1135 description 1136 "Hard isolation with deterministic characteristics."; 1137 } 1139 identity soft-isolation { 1140 base new; 1141 description 1142 "Soft-isolation."; 1143 } 1145 identity select { 1146 base map-type; 1147 description 1148 "The VPN service selects an existing tunnel with no 1149 modification."; 1150 } 1152 identity modify { 1153 base map-type; 1154 description 1155 "The VPN service selects an existing tunnel and allows to modify 1156 the properties of the tunnel (e.g., b/w)"; 1157 } 1159 identity none { 1160 base map-type; 1161 description 1162 "The VPN service is not mapped to any underlying TE"; 1163 } 1165 /* 1166 * Identity for availability-type 1167 */ 1169 identity availability-type { 1170 description 1171 "Base identity from which specific map types are derived."; 1172 } 1174 identity level-1 { 1175 base availability-type; 1176 description 1177 "level 1: 99.9999%"; 1178 } 1180 identity level-2 { 1181 base availability-type; 1182 description 1183 "level 2: 99.999%"; 1184 } 1186 identity level-3 { 1187 base availability-type; 1188 description 1189 "level 3: 99.99%"; 1190 } 1192 identity level-4 { 1193 base availability-type; 1194 description 1195 "level 4: 99.9%"; 1196 } 1198 identity level-5 { 1199 base availability-type; 1200 description 1201 "level 5: 99%"; 1202 } 1204 /* 1205 * Typedef 1206 */ 1208 typedef te-mapping-template-id { 1209 type string; 1210 description 1211 "Identifier for a TE mapping template."; 1212 } 1214 /* 1215 * Groupings 1216 */ 1218 grouping te-ref { 1219 description 1220 "The reference to TE."; 1221 choice te { 1222 description 1223 "How the VPN is mapped to a VN, Topology, Tunnel, SR Policy 1224 etc."; 1225 case vn { 1226 leaf-list vn { 1227 type leafref { 1228 path "/vn:virtual-network/vn:vn/vn:vn-id"; 1229 } 1230 description 1231 "The reference to VN"; 1232 reference 1233 "RFC 8453: Framework for Abstraction and Control of TE 1234 Networks (ACTN)"; 1235 } 1236 } 1237 case te-topo { 1238 leaf vn-topology-id { 1239 type te-types:te-topology-id; 1240 description 1241 "An identifier to the TE Topology Model where the abstract 1242 nodes and links of the Topology can be found for Type 2 1243 VNs as defined in RFC 8453"; 1244 reference 1245 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1246 Topologies 1247 RFC 8453: Framework for Abstraction and Control of TE 1248 Networks (ACTN)"; 1249 } 1250 leaf abstract-node { 1251 type leafref { 1252 path "/nw:networks/nw:network/nw:node/nw:node-id"; 1253 } 1254 description 1255 "A reference to the abstract node in TE Topology"; 1256 reference 1257 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1258 Topologies"; 1259 } 1260 } 1261 case te-tunnel { 1262 leaf-list te-tunnel { 1263 type te:tunnel-ref; 1264 description 1265 "Reference to TE Tunnels"; 1266 reference 1267 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1268 Engineering Tunnels and Interfaces"; 1269 } 1270 list sr-policy { 1271 if-feature "sr-policy"; 1272 key "policy-color-ref policy-endpoint-ref"; 1273 description 1274 "SR Policy"; 1275 leaf policy-color-ref { 1276 type leafref { 1277 path 1278 "/rt:routing/sr-policy:segment-routing" 1279 + "/sr-policy:traffic-engineering/sr-policy:policies" 1280 + "/sr-policy:policy/sr-policy:color"; 1281 } 1282 description 1283 "Reference to sr-policy color"; 1284 } 1285 leaf policy-endpoint-ref { 1286 type leafref { 1287 path 1288 "/rt:routing/sr-policy:segment-routing" 1289 + "/sr-policy:traffic-engineering/sr-policy:policies" 1290 + "/sr-policy:policy/sr-policy:endpoint"; 1292 } 1293 description 1294 "Reference to sr-policy endpoint"; 1295 } 1296 } 1297 } 1298 } 1299 leaf te-mapping-template-ref { 1300 if-feature "template"; 1301 type leafref { 1302 path "/tsmt:te-mapping-templates/" 1303 + "tsmt:te-mapping-template/tsmt:id"; 1304 } 1305 description 1306 "An identifier to the TE Mapping Template where the TE 1307 constraints and optimization criteria are specified."; 1308 } 1309 } 1311 //grouping 1313 grouping te-endpoint-ref { 1314 description 1315 "The reference to TE endpoints."; 1316 choice te { 1317 description 1318 "How the TE endpoint is defined by VN's AP or TE's LTP"; 1319 case vn { 1320 leaf-list vn-ap { 1321 type leafref { 1322 path "/vn:access-point/vn:ap/vn:vn-ap/vn:vn-ap-id"; 1323 } 1324 description 1325 "The reference to VNAP"; 1326 reference 1327 "RFC 8453: Framework for Abstraction and Control of TE 1328 Networks (ACTN)"; 1329 } 1330 } 1331 case te { 1332 leaf ltp { 1333 type te-types:te-tp-id; 1334 description 1335 "Reference LTP in the TE-topology"; 1336 reference 1337 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1338 Topologies"; 1339 } 1341 } 1342 } 1343 } 1345 //grouping 1347 grouping te-policy { 1348 description 1349 "Various underlying TE policy requirements"; 1350 leaf color { 1351 type uint32; 1352 description 1353 "Maps to the underlying colored TE resources"; 1354 } 1355 leaf protection-type { 1356 type identityref { 1357 base te-types:lsp-protection-type; 1358 } 1359 description 1360 "Desired protection level for the underlying 1361 TE resources"; 1362 } 1363 leaf availability-type { 1364 type identityref { 1365 base availability-type; 1366 } 1367 description 1368 "Availability Requirement for the Service"; 1369 } 1370 } 1372 //grouping 1374 grouping te-mapping { 1375 description 1376 "Mapping between Services and TE"; 1377 container te-mapping { 1378 description 1379 "Mapping between Services and TE"; 1380 leaf map-type { 1381 type identityref { 1382 base map-type; 1383 } 1384 description 1385 "Isolation Requirements, Tunnel Bind or 1386 Tunnel Selection"; 1387 } 1388 container te-policy { 1389 uses te-policy; 1390 description 1391 "Desired Underlying TE Policy"; 1392 } 1393 uses te-ref; 1394 } 1395 } 1397 //grouping 1399 container te-mapping-templates { 1400 description 1401 "The TE constraints and optimization criteria"; 1402 list te-mapping-template { 1403 key "id"; 1404 leaf id { 1405 type te-mapping-template-id; 1406 description 1407 "Identification of the Template to be used."; 1408 } 1409 leaf description { 1410 type string; 1411 description 1412 "Description of the template."; 1413 } 1414 leaf map-type { 1415 type identityref { 1416 base map-type; 1417 } 1418 must "0 = derived-from-or-self(.,'none')" { 1419 error-message "The map-type must be other than " 1420 + "none"; 1421 } 1422 description 1423 "Map type for the VN/Tunnel creation/ 1424 selection."; 1425 } 1426 uses te-types:generic-path-constraints; 1427 uses te-types:generic-path-optimization; 1428 description 1429 "List for templates."; 1430 } 1431 } 1432 } 1433 1435 7.2. Service Models 1436 7.2.1. ietf-l3sm-te-service-mapping 1438 file "ietf-l3sm-te-service-mapping@2021-10-24.yang" 1439 module ietf-l3sm-te-service-mapping { 1440 yang-version 1.1; 1441 namespace 1442 "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; 1443 prefix l3-tsm; 1445 import ietf-te-service-mapping-types { 1446 prefix tsmt; 1447 reference 1448 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1449 } 1450 import ietf-l3vpn-svc { 1451 prefix l3vpn-svc; 1452 reference 1453 "RFC 8299: YANG Data Model for L3VPN Service Delivery"; 1454 } 1456 organization 1457 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1458 Working Group"; 1459 contact 1460 "WG Web: 1461 WG List: 1463 Editor: Young Lee 1464 1465 Editor: Dhruv Dhody 1466 1467 Editor: Qin Wu 1468 "; 1469 description 1470 "This module contains a YANG module for the mapping of Layer 3 1471 Service Model (L3SM) to the TE and VN. 1473 Copyright (c) 2021 IETF Trust and the persons identified as 1474 authors of the code. All rights reserved. 1476 Redistribution and use in source and binary forms, with or 1477 without modification, is permitted pursuant to, and subject to 1478 the license terms contained in, the Simplified BSD License set 1479 forth in Section 4.c of the IETF Trust's Legal Provisions 1480 Relating to IETF Documents 1481 (https://trustee.ietf.org/license-info). 1482 This version of this YANG module is part of RFC XXXX; see the 1483 RFC itself for full legal notices."; 1485 revision 2021-10-24 { 1486 description 1487 "Initial revision."; 1488 reference 1489 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1490 } 1492 /* 1493 * Augmentation to L3SM 1494 */ 1496 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services" 1497 + "/l3vpn-svc:vpn-service" { 1498 description 1499 "L3SM augmented to include TE parameters and mapping"; 1500 container te-service-mapping { 1501 presence "Indicates L3 service to TE mapping"; 1502 description 1503 "Container to augment l3sm to TE parameters and mapping"; 1504 uses tsmt:te-mapping; 1505 } 1506 } 1508 //augment 1510 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1511 + "/l3vpn-svc:site-network-accesses" 1512 + "/l3vpn-svc:site-network-access" { 1513 description 1514 "This augment is only valid for TE mapping of L3SM network-access 1515 to TE endpoints"; 1516 uses tsmt:te-endpoint-ref; 1517 } 1519 //augment 1521 augment 1522 "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1523 + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile" 1524 + "/l3vpn-svc:qos-profile/l3vpn-svc:custom" 1525 + "/l3vpn-svc:classes/l3vpn-svc:class" { 1526 description 1527 "This augment is for per-class in site for custom QoS profile"; 1528 uses tsmt:te-endpoint-ref; 1529 } 1531 augment 1532 "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1534 + "/l3vpn-svc:site-network-accesses" 1535 + "/l3vpn-svc:site-network-access" 1536 + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile" 1537 + "/l3vpn-svc:qos-profile/l3vpn-svc:custom" 1538 + "/l3vpn-svc:classes/l3vpn-svc:class" { 1539 description 1540 "This augment is for per-class in site-network-access for custom 1541 QoS profile"; 1542 uses tsmt:te-endpoint-ref; 1543 } 1544 } 1545 1547 7.2.2. ietf-l2sm-te-service-mapping 1549 file "ietf-l2sm-te-service-mapping@2021-10-24.yang" 1550 module ietf-l2sm-te-service-mapping { 1551 yang-version 1.1; 1552 namespace 1553 "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; 1554 prefix l2-tsm; 1556 import ietf-te-service-mapping-types { 1557 prefix tsmt; 1558 reference 1559 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1560 } 1561 import ietf-l2vpn-svc { 1562 prefix l2vpn-svc; 1563 reference 1564 "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network 1565 (L2VPN) Service Delivery"; 1566 } 1568 organization 1569 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1570 Working Group"; 1571 contact 1572 "WG Web: 1573 WG List: 1575 Editor: Young Lee 1576 1577 Editor: Dhruv Dhody 1578 1579 Editor: Qin Wu 1580 "; 1581 description 1582 "This module contains a YANG module for the mapping of Layer 2 1583 Service Model (L2SM) to the TE and VN. 1585 Copyright (c) 2021 IETF Trust and the persons identified as 1586 authors of the code. All rights reserved. 1588 Redistribution and use in source and binary forms, with or 1589 without modification, is permitted pursuant to, and subject to 1590 the license terms contained in, the Simplified BSD License set 1591 forth in Section 4.c of the IETF Trust's Legal Provisions 1592 Relating to IETF Documents 1593 (https://trustee.ietf.org/license-info). 1595 This version of this YANG module is part of RFC XXXX; see the 1596 RFC itself for full legal notices."; 1598 revision 2021-10-24 { 1599 description 1600 "Initial revision."; 1601 reference 1602 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1603 } 1605 /* 1606 * Augmentation to L2SM 1607 */ 1609 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/" 1610 + "l2vpn-svc:vpn-service" { 1611 description 1612 "L2SM augmented to include TE parameters and mapping"; 1613 container te-service-mapping { 1614 presence "indicates L2 service to te mapping"; 1615 description 1616 "Container to augment L2SM to TE parameters and mapping"; 1617 uses tsmt:te-mapping; 1618 } 1619 } 1621 //augment 1623 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1624 + "/l2vpn-svc:site-network-accesses" 1625 + "/l2vpn-svc:site-network-access" { 1626 description 1627 "This augment the L2SM network-access with a reference 1628 to TE endpoints when underlying TE is used"; 1629 uses tsmt:te-endpoint-ref; 1631 } 1633 //augment 1635 augment 1636 "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1637 + "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile" 1638 + "/l2vpn-svc:qos-profile/l2vpn-svc:custom" 1639 + "/l2vpn-svc:classes/l2vpn-svc:class" { 1640 when './l2vpn-svc:bandwidth/l2vpn-svc:end-to-end' { 1641 description 1642 "applicable only with end-to-end"; 1643 } 1644 description 1645 "This augment is for per-class in site for custom QoS profile"; 1646 uses tsmt:te-endpoint-ref; 1647 } 1649 augment 1650 "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1651 + "/l2vpn-svc:site-network-accesses" 1652 + "/l2vpn-svc:site-network-access" 1653 + "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile" 1654 + "/l2vpn-svc:qos-profile/l2vpn-svc:custom" 1655 + "/l2vpn-svc:classes/l2vpn-svc:class" { 1656 description 1657 "This augment is for per-class in site-network-access for custom 1658 QoS profile"; 1659 uses tsmt:te-endpoint-ref; 1660 } 1661 } 1662 1664 7.2.3. ietf-l1csm-te-service-mapping 1666 file "ietf-l1csm-te-service-mapping@2021-10-24.yang" 1667 module ietf-l1csm-te-service-mapping { 1668 yang-version 1.1; 1669 namespace 1670 "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; 1671 prefix l1-tsm; 1673 import ietf-te-service-mapping-types { 1674 prefix tsmt; 1675 reference 1676 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1677 } 1678 import ietf-l1csm { 1679 prefix l1csm; 1680 reference 1681 "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity 1682 Service Model (L1CSM)"; 1683 } 1685 organization 1686 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1687 Working Group"; 1688 contact 1689 "WG Web: 1690 WG List: 1692 Editor: Young Lee 1693 1694 Editor: Dhruv Dhody 1695 1696 Editor: Qin Wu 1697 "; 1698 description 1699 "This module contains a YANG module for the mapping of 1700 Layer 1 Connectivity Service Module (L1CSM) to the TE and VN 1702 Copyright (c) 2021 IETF Trust and the persons identified as 1703 authors of the code. All rights reserved. 1705 Redistribution and use in source and binary forms, with or 1706 without modification, is permitted pursuant to, and subject to 1707 the license terms contained in, the Simplified BSD License set 1708 forth in Section 4.c of the IETF Trust's Legal Provisions 1709 Relating to IETF Documents 1710 (https://trustee.ietf.org/license-info). 1712 This version of this YANG module is part of RFC XXXX; see the 1713 RFC itself for full legal notices."; 1715 revision 2021-10-24 { 1716 description 1717 "Initial revision."; 1718 reference 1719 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1720 } 1722 /* 1723 * Augmentation to L1CSM 1724 */ 1726 augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" { 1727 description 1728 "L1CSM augmented to include TE parameters and mapping"; 1729 container te-service-mapping { 1730 presence "Indicates L1 service to TE mapping"; 1731 description 1732 "Container to augment L1CSM to TE parameters and mapping"; 1733 uses tsmt:te-mapping; 1734 } 1735 } 1737 //augment 1739 augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/" 1740 + "l1csm:uni" { 1741 description 1742 "This augment the L1CSM UNI with a reference 1743 to TE endpoints"; 1744 uses tsmt:te-endpoint-ref; 1745 } 1747 //augment 1748 } 1749 1751 7.3. Network Models 1753 7.3.1. ietf-l3nm-te-service-mapping 1755 file "ietf-l3nm-te-service-mapping@2021-10-24.yang" 1756 module ietf-l3nm-te-service-mapping { 1757 yang-version 1.1; 1758 namespace 1759 "urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping"; 1760 prefix l3nm-tsm; 1762 import ietf-te-service-mapping-types { 1763 prefix tsmt; 1764 reference 1765 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1766 } 1767 import ietf-l3vpn-ntw { 1768 prefix l3vpn-ntw; 1769 reference 1770 "I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model"; 1771 } 1773 organization 1774 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1775 Working Group"; 1776 contact 1777 "WG Web: 1778 WG List: 1780 Editor: Young Lee 1781 1782 Editor: Dhruv Dhody 1783 1784 Editor: Qin Wu 1785 "; 1786 description 1787 "This module contains a YANG module for the mapping of Layer 3 1788 Network Model (L3NM) to the TE and VN. 1790 Copyright (c) 2021 IETF Trust and the persons identified as 1791 authors of the code. All rights reserved. 1793 Redistribution and use in source and binary forms, with or 1794 without modification, is permitted pursuant to, and subject to 1795 the license terms contained in, the Simplified BSD License set 1796 forth in Section 4.c of the IETF Trust's Legal Provisions 1797 Relating to IETF Documents 1798 (https://trustee.ietf.org/license-info). 1799 This version of this YANG module is part of RFC XXXX; see the 1800 RFC itself for full legal notices."; 1802 revision 2021-10-24 { 1803 description 1804 "Initial revision."; 1805 reference 1806 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1807 } 1809 /* 1810 * Augmentation to L3NM 1811 */ 1813 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1814 + "/l3vpn-ntw:vpn-service" { 1815 description 1816 "L3SM augmented to include TE parameters and mapping"; 1817 container te-service-mapping { 1818 presence "Indicates L3 network to TE mapping"; 1819 description 1820 "Container to augment l3nm to TE parameters and mapping"; 1821 uses tsmt:te-mapping; 1822 } 1824 } 1826 //augment 1828 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1829 + "/l3vpn-ntw:vpn-service" 1830 + "/l3vpn-ntw:vpn-nodes/l3vpn-ntw:vpn-node" 1831 + "/l3vpn-ntw:vpn-network-accesses" 1832 + "/l3vpn-ntw:vpn-network-access" { 1833 description 1834 "This augment the L3NM network-access with a reference 1835 to TE endpoints when underlying TE is used"; 1836 uses tsmt:te-endpoint-ref; 1837 } 1839 //augment 1840 } 1841 1843 7.3.2. ietf-l2nm-te-service-mapping 1845 file "ietf-l2nm-te-service-mapping@2021-10-24.yang" 1846 module ietf-l2nm-te-service-mapping { 1847 yang-version 1.1; 1848 namespace 1849 "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping"; 1850 prefix l2nm-tsm; 1852 import ietf-te-service-mapping-types { 1853 prefix tsmt; 1854 reference 1855 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1856 } 1857 import ietf-l2vpn-ntw { 1858 prefix l2vpn-ntw; 1859 reference 1860 "I-D.ietf-opsawg-l2nm: A Layer 2 VPN Network YANG Model"; 1861 } 1863 organization 1864 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1865 Working Group"; 1866 contact 1867 "WG Web: 1868 WG List: 1870 Editor: Young Lee 1871 1873 Editor: Dhruv Dhody 1874 1875 Editor: Qin Wu 1876 "; 1877 description 1878 "This module contains a YANG module for the mapping of Layer 2 1879 Network Model (L2NM) to the TE and VN. 1881 Copyright (c) 2021 IETF Trust and the persons identified as 1882 authors of the code. All rights reserved. 1884 Redistribution and use in source and binary forms, with or 1885 without modification, is permitted pursuant to, and subject to 1886 the license terms contained in, the Simplified BSD License set 1887 forth in Section 4.c of the IETF Trust's Legal Provisions 1888 Relating to IETF Documents 1889 (https://trustee.ietf.org/license-info). 1891 This version of this YANG module is part of RFC XXXX; see the 1892 RFC itself for full legal notices."; 1894 revision 2021-10-24 { 1895 description 1896 "Initial revision."; 1897 reference 1898 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1899 } 1901 /* 1902 * Augmentation to L2NM 1903 */ 1905 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1906 + "/l2vpn-ntw:vpn-service" { 1907 description 1908 "L2SM augmented to include TE parameters and mapping"; 1909 container te-service-mapping { 1910 presence "Indicates L2 network to TE mapping"; 1911 description 1912 "Container to augment l2nm to TE parameters and mapping"; 1913 uses tsmt:te-mapping; 1914 } 1915 } 1917 //augment 1919 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1920 + "/l2vpn-ntw:vpn-service" 1921 + "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node" 1922 + "/l2vpn-ntw:vpn-network-accesses" 1923 + "/l2vpn-ntw:vpn-network-access" { 1924 description 1925 "This augment the L2NM network-access with a reference 1926 to TE endpoints when underlying TE is used"; 1927 uses tsmt:te-endpoint-ref; 1928 } 1930 //augment 1931 } 1932 1934 8. Security Considerations 1936 The YANG modules defined in this document is designed to be accessed 1937 via network management protocol such as NETCONF [RFC6241] or RESTCONF 1938 [RFC8040]. The lowest NETCONF layer is the secure transport layer 1939 and the mandatory-to-implement secure transport is SSH [RFC6242]. 1940 The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement 1941 secure transport is TLS [RFC8446] 1943 The NETCONF access control model [RFC8341] provides the means to 1944 restrict access for particular NETCONF or RESTCONF users to a pre- 1945 configured subset of all available NETCONF or RESTCONF protocol 1946 operations and content. 1948 There are a number of data nodes defined in the YANG moduleS which 1949 are writable/creatable/deletable (i.e., config true, which is the 1950 default). These data nodes may be considered sensitive or vulnerable 1951 in some network environments. Write operations (e.g., ) 1952 to these data nodes without proper protection can have a negative 1953 effect on network operations. These are the subtrees and data nodes 1954 and their sensitivity/vulnerability: 1956 * /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1957 - can configure TE Service mapping. 1959 * /l3vpn-svc/sites/site/site-network-accesses/site-network-access/ 1960 te/ - can configure TE Endpoint mapping. 1962 * /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1963 - can configure TE Service mapping. 1965 * /l2vpn-svc/sites/site/site-network-accesses/site-network-access/ 1966 te/ - can configure TE Endpoint mapping. 1968 * /l1-connectivity/services/service/te-service-mapping/te-mapping/ - 1969 can configure TE Service mapping. 1971 * /l1-connectivity/access/unis/uni/te/ - can configure TE Endpoint 1972 mapping. 1974 * /l3vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1975 - can configure TE Network mapping. 1977 * /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1978 network-accesses/vpn-network-access/te/ - can configure TE 1979 Endpoint mapping. 1981 * /l2vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1982 - can configure TE Network mapping. 1984 * /l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1985 network-accesses/vpn-network-access/te/ - can configure TE 1986 Endpoint mapping. 1988 Unauthorized access to above list can adversely affect the VPN 1989 service. 1991 Some of the readable data nodes in the YANG module may be considered 1992 sensitive or vulnerable in some network environments. It is thus 1993 important to control read access (e.g., via get, get-config, or 1994 notification) to these data nodes. The TE related parameters 1995 attached to the VPN service can leak sensitive information about the 1996 network. This is applicable to all elements in the yang models 1997 defined in this document. 1999 This document has no RPC defined. 2001 9. IANA Considerations 2003 This document request the IANA to register six URIs in the "IETF XML 2004 Registry" [RFC3688]. Following the format in RFC 3688, the following 2005 registrations are requested - 2006 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 2007 Registrant Contact: The IESG. 2008 XML: N/A, the requested URI is an XML namespace. 2010 URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 2011 Registrant Contact: The IESG. 2012 XML: N/A, the requested URI is an XML namespace. 2014 URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 2015 Registrant Contact: The IESG. 2016 XML: N/A, the requested URI is an XML namespace. 2018 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 2019 Registrant Contact: The IESG. 2020 XML: N/A, the requested URI is an XML namespace. 2022 URI: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 2023 Registrant Contact: The IESG. 2024 XML: N/A, the requested URI is an XML namespace. 2026 URI: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 2027 Registrant Contact: The IESG. 2028 XML: N/A, the requested URI is an XML namespace. 2030 This document request the IANA to register six YANG modules in the 2031 "YANG Module Names" registry [RFC6020], as follows - 2032 Name: ietf-te-service-mapping-types 2033 Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 2034 Prefix: tsmt 2035 Reference: [This.I-D] 2037 Name: ietf-l3sm-te-service-mapping 2038 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 2039 Prefix: l3-tsm 2040 Reference: [This.I-D] 2042 Name: ietf-l2sm-te-service-mapping 2043 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 2044 Prefix: l2-tsm 2045 Reference: [This.I-D] 2047 Name: ietf-l1csm-te-service-mapping 2048 Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 2049 Prefix: l1-tsm 2050 Reference: [This.I-D] 2052 Name: ietf-l3nm-te-service-mapping 2053 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 2054 Prefix: l3nm-tsm 2055 Reference: [This.I-D] 2057 Name: ietf-l2nm-te-service-mapping 2058 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 2059 Prefix: l2nm-tsm 2060 Reference: [This.I-D] 2062 10. Acknowledgements 2064 We thank Diego Caviglia, and Igor Bryskin for useful discussions and 2065 motivation for this work. 2067 11. References 2069 11.1. Normative References 2071 [I-D.ietf-ccamp-l1csm-yang] 2072 Lee, Y., Lee, K., Zheng, H., Dios, O. G. D., and D. 2073 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2074 Model (L1CSM)", Work in Progress, Internet-Draft, draft- 2075 ietf-ccamp-l1csm-yang-15, 8 September 2021, 2076 . 2079 [I-D.ietf-opsawg-l2nm] 2080 Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. 2081 Munoz, "A Layer 2 VPN Network YANG Model", Work in 2082 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-09, 20 2083 October 2021, . 2086 [I-D.ietf-opsawg-l3sm-l3nm] 2087 Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., 2088 and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in 2089 Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-18, 2090 8 October 2021, . 2093 [I-D.ietf-spring-sr-policy-yang] 2094 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 2095 Matsushima, S., and V. P. Beeram, "YANG Data Model for 2096 Segment Routing Policy", Work in Progress, Internet-Draft, 2097 draft-ietf-spring-sr-policy-yang-01, 7 April 2021, 2098 . 2101 [I-D.ietf-teas-actn-vn-yang] 2102 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 2103 Yoon, "A YANG Data Model for VN Operation", Work in 2104 Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-13, 2105 23 October 2021, . 2108 [I-D.ietf-teas-yang-te] 2109 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 2110 and O. G. D. Dios, "A YANG Data Model for Traffic 2111 Engineering Tunnels, Label Switched Paths and Interfaces", 2112 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 2113 27, 8 July 2021, . 2116 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2117 DOI 10.17487/RFC3688, January 2004, 2118 . 2120 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2121 the Network Configuration Protocol (NETCONF)", RFC 6020, 2122 DOI 10.17487/RFC6020, October 2010, 2123 . 2125 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2126 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2127 . 2129 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 2130 Ceccarelli, D., and X. Zhang, "Problem Statement and 2131 Architecture for Information Exchange between 2132 Interconnected Traffic-Engineered Networks", BCP 206, 2133 RFC 7926, DOI 10.17487/RFC7926, July 2016, 2134 . 2136 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2137 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2138 . 2140 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2141 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2142 . 2144 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2145 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2146 DOI 10.17487/RFC8299, January 2018, 2147 . 2149 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2150 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2151 . 2153 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2154 Access Control Model", STD 91, RFC 8341, 2155 DOI 10.17487/RFC8341, March 2018, 2156 . 2158 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2159 and R. Wilton, "Network Management Datastore Architecture 2160 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2161 . 2163 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2164 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2165 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2166 2018, . 2168 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 2169 Routing Management (NMDA Version)", RFC 8349, 2170 DOI 10.17487/RFC8349, March 2018, 2171 . 2173 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2174 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2175 . 2177 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2178 Data Model for Layer 2 Virtual Private Network (L2VPN) 2179 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2180 2018, . 2182 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2183 "Common YANG Data Types for Traffic Engineering", 2184 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2185 . 2187 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2188 O. Gonzalez de Dios, "YANG Data Model for Traffic 2189 Engineering (TE) Topologies", RFC 8795, 2190 DOI 10.17487/RFC8795, August 2020, 2191 . 2193 11.2. Informative References 2195 [I-D.dhody-teas-te-traffic-yang] 2196 Dhody, D., "Traffic Mapping YANG model for Traffic 2197 Engineering (TE)", Work in Progress, Internet-Draft, 2198 draft-dhody-teas-te-traffic-yang-00, 24 October 2021, 2199 . 2202 [I-D.ietf-teas-actn-yang] 2203 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. 2204 Belotti, "Applicability of YANG models for Abstraction and 2205 Control of Traffic Engineered Networks", Work in Progress, 2206 Internet-Draft, draft-ietf-teas-actn-yang-08, 8 September 2207 2021, . 2210 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2211 and A. Bierman, Ed., "Network Configuration Protocol 2212 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2213 . 2215 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 2216 Classification", RFC 8199, DOI 10.17487/RFC8199, July 2217 2017, . 2219 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2220 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2221 . 2223 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2224 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2225 DOI 10.17487/RFC8453, August 2018, 2226 . 2228 Appendix A. Examples 2230 This section details a few examples on how the TE-service mapping is 2231 used in various scenarios. 2233 Example 1: An L3VPN service with an optimization criteria for the 2234 underlying TE as delay can be set in the mapping template and then 2235 augmented to the L3SM service. 2237 { 2238 "te-mapping-template":[ 2239 { 2240 "id": "delay", 2241 "map-type": "select", 2242 "optimizations": 2243 { 2244 "algorithm":{ 2245 "optimization-metric": [ 2246 { 2247 "metric-type":"path-metric-delay-average" 2248 } 2249 ] 2250 } 2251 } 2252 } 2253 ] 2254 } 2256 The L3SM service can map it to the existing least delay TE resources 2257 in form of a VN or TE-tunnels. 2259 Example 2: An L2VPN service with a bandwidth constraint and a hop- 2260 limit criteria for the underlying TE can be set in the mapping 2261 template and then augmented to the L2SM service. 2263 { 2264 "te-mapping-template":[ 2265 { 2266 "id": "bw-hop", 2267 "map-type": "new", 2268 "path-constraints":{ 2269 "te-bandwidth":{ 2270 "generic":10000 2271 }, 2272 "path-metric-bounds":{ 2273 "path-metric-bound":[ 2274 { 2275 "metric-type":"path-metric-hop", 2276 "upper-bound":10 2277 } 2278 ] 2279 } 2280 } 2281 ] 2282 } 2284 The L2SM service can map it to a new TE resources in form of a VN or 2285 TE-tunnels. 2287 Example 3: A VN (VN1) could be created before hand and then 2288 explicitly mapped to the L2VPN service as shown below. 2290 2291 2292 2293 2294 VPN1 2295 2296 2297 select 2298 2299 VN1 2300 2301 2302 2303 2304 2305 2307 Example 4: A VPN service may want different optimization criteria for 2308 some of its sites. The template does not allow for such a case but 2309 it can be achieved by creating the TE resources separately and then 2310 mapping them to the service. 2312 Appendix B. Contributor Addresses 2314 Adrian Farrel 2315 Old Dog Consulting 2317 EMail: adrian@olddog.co.uk 2319 Italo Busi 2320 Huawei Technologies 2322 EMail: Italo.Busi@huawei.com 2324 Haomian Zheng 2325 Huawei Technologies 2327 EMail: zhenghaomian@huawei.com 2329 Anton Snitser 2330 Sedonasys 2332 EMail: antons@sedonasys.com 2334 SAMIER BARGUIL GIRALDO 2335 Telefonica 2337 EMail: samier.barguilgiraldo.ext@telefonica.com 2339 Oscar Gonzalez de Dios 2340 Telefonica 2342 EMail: oscar.gonzalezdedios@telefonica.com 2344 Carlo Perocchio 2345 Ericsson 2347 EMail: carlo.perocchio@ericsson.com 2349 Kenichi Ogaki 2350 KDDI 2351 Email: ke-oogaki@kddi.com 2353 Authors' Addresses 2355 Young Lee (editor) 2356 Samsung Electronics 2358 Email: younglee.tx@gmail.com 2359 Dhruv Dhody (editor) 2360 Huawei Technologies 2361 Divyashree Techno Park, Whitefield 2362 Bangalore 560066 2363 Karnataka 2364 India 2366 Email: dhruv.ietf@gmail.com 2368 Giuseppe Fioccola 2369 Huawei Technologies 2371 Email: giuseppe.fioccola@huawei.com 2373 Qin Wu (editor) 2374 Huawei Technologies 2376 Email: bill.wu@huawei.com 2378 Daniele Ceccarelli 2379 Ericsson 2380 Torshamnsgatan,48 2381 Stockholm, Sweden 2383 Email: daniele.ceccarelli@ericsson.com 2385 Jeff Tantsura 2386 Microsoft 2388 Email: jefftant.ietf@gmail.com