idnits 2.17.1 draft-ietf-teas-te-service-mapping-yang-08.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 715 has weird spacing: '...ic-type ide...' == Line 719 has weird spacing: '...w usage ide...' == Line 725 has weird spacing: '...rw name str...' == Line 732 has weird spacing: '...w usage ide...' == Line 782 has weird spacing: '...int-ref lea...' == (4 more instances...) -- The document date (28 August 2021) is 969 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-14 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-04 == Outdated reference: A later version (-18) exists of draft-ietf-opsawg-l3sm-l3nm-10 == 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-12 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-27 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-07 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: 1 March 2022 G. Fioccola 6 Q. Wu, Ed. 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 J. Tantsura 11 Microsoft 12 28 August 2021 14 Traffic Engineering (TE) and Service Mapping Yang Model 15 draft-ietf-teas-te-service-mapping-yang-08 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 1 March 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 . . . . . . . . . . . 11 77 4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 15 78 4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 15 79 5. Applicability of TE-Service Mapping in Generic context . . . 16 80 6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 16 81 6.1. Service Mapping Types . . . . . . . . . . . . . . . . . . 16 82 6.2. Service Models . . . . . . . . . . . . . . . . . . . . . 17 83 6.2.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 17 84 6.2.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 18 85 6.2.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 19 86 6.3. Network Models . . . . . . . . . . . . . . . . . . . . . 20 87 6.3.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 20 88 6.3.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 21 89 7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 22 90 7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 22 91 7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 31 92 7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 32 93 7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 34 94 7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 36 96 7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 38 97 7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 38 98 7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 40 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 101 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 45 104 11.2. Informative References . . . . . . . . . . . . . . . . . 48 105 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 49 106 Appendix B. Discussion . . . . . . . . . . . . . . . . . . . . . 51 107 Appendix C. Contributor Addresses . . . . . . . . . . . . . . . 51 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 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 3.2. TE and Network Models 459 The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN 460 Service in the Service Provider Network. It contains information of 461 the Service Provider network and might include allocated resources. 462 It can be used by network controllers to manage and control the VPN 463 Service configuration in the Service Provider network. 465 Similar to service model, the existing network models (i.e., 466 [I-D.ietf-opsawg-l3sm-l3nm], and [I-D.ietf-opsawg-l2nm]) are 467 augmented to include the TE and Service mapping parameters. Figure 2 468 shows the scope of the Augmented LxNM Model. 470 +--------------+ +----------------------+ +----------+ 471 | LxNM |o-------| | . . . . | ACTN VN | 472 +--------------+ augment| | +----------+ 473 | | +----------+ 474 +--------------+ | Augmented LxNM Model | . . . . | TE-topo | 475 | TE & Service |------->| | +----------+ 476 | Mapping Types| import | | +----------+ 477 +--------------+ | | . . . . | TE-tunnel| 478 +----------------------+ +----------+ 479 reference 481 Figure 2: Augmented LxNM Model 483 The Augmented LxNM model (where x=2,3) augments the basic LxNM model 484 while importing the common TE mapping related parameters (defined in 485 Section 2) grouping information from TE and Service Mapping Types. 486 The role of the augmented LxNM network model is to expose the mapping 487 relationship between network models and TE models. 489 4. L3VPN Architecture in the ACTN Context 491 Figure 3 shows the architectural context of this document referencing 492 the ACTN components and interfaces. 494 +----------------------------+ 495 | Customer Service Manager | 496 | +-----------------------+ | 497 | | CNC + | 498 | +-+-------------------+-+ | 499 +----|-------------------|---+ 500 | | 501 |CMI(Augmented L3SM)|CMI(VN) 502 | | 503 +----------------|-------------------|----+ 504 | +--------------|-----------------+ | | 505 | | MDSC | | | | 506 | | | | | | 507 | | +-----------+--------------+ | | | 508 TE-Svc-Map<------+ Service Mapping Function | | | | 509 | | +-----------+--------------+ | | | 510 | | | | | | 511 | +-------+------|-----------------+ | | 512 | | | | | 513 | | |CMI(VN) | | 514 | | | | | 515 | | +--|-------------------|--+ | 516 | | | | MDSC | | | 517 | | | ++-------------------++ | | 518 | | | + Service Mapping +---->TE-Svc-Map 519 | | | ++----------+---------+ | | 520 | | +--|----------|-----------+ | 521 +---------|------|----------|-------------+ 522 | | | 523 | +----+--------+ | 524 | | | | 525 MPI(VPN / TE models)| | | |MPI(TE / L1 models) 526 | | | | 527 +-----|-|---+ +-----|-|----+ 528 IP/MPLS | +--+-+-+ | | +--+-+-+ | Optical Domain 529 Domain | | PNC1 | | | | PNC2 | | Controller 530 Controller | +--+---+ | | +--+---+ | 531 +-----|-----+ +-----|------+ 532 | | 533 V | SBI 534 +---------------------+ | 535 / IP/MPLS Network \ | 536 +-------------------------+ | 537 V 538 +---------------------+ 539 / Optical Network \ 540 +-------------------------+ 542 Figure 3: L3VPN Architecture from the IP+Optical Network Perspective 544 There are three main entities in the ACTN architecture and shown in 545 Figure 3. 547 * CNC: The Customer Network Controller is responsible for generating 548 service requests. In the context of an L3VPN, the CNC uses the 549 Augmented L3SM to express the service request and communicate it 550 to the network operator. 552 * MDSC: This entity is responsible for coordinating a L3VPN service 553 request (expressed via the Augmented L3SM) with the IP/MPLS PNC 554 and the Transport PNC. For TE services, one of the key 555 responsibilities of the MDSC is to coordinate with both the IP PNC 556 and the Transport PNC for the mapping of the Augmented L3VPN 557 Service Model to the ACTN VN model. In the VN/TE-tunnel binding 558 case, the MDSC will need to coordinate with the Transport PNC to 559 dynamically create the TE-tunnels in the transport network as 560 needed. These tunnels are added as links in the IP/MPLS Layer 561 topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 562 tunnels in the IP/MPLS layer, as part of the ACTN VN creation. 564 * PNC: The Provisioning Network Controller is responsible for 565 configuring and operating the network devices. Figure 3 shows two 566 distinct PNCs. 568 - IP/MPLS PNC (PNC1): This entity is responsible for device 569 configuration to create PE-PE L3VPN tunnels for the VPN 570 customer and for the configuration of the L3VPN VRF on the PE 571 nodes. Each network element would select a tunnel based on the 572 configuration. 574 - Transport PNC (PNC2): This entity is responsible for device 575 configuration for TE tunnels in the transport networks. 577 The three main interfaces are shown in Figure 3 and listed below. 579 * CMI: The CNC-MDSC Interface is used to communicate service 580 requests from the customer to the operator. The requests may be 581 expressed as Augmented VPN service requests (L2SM, L3SM), as 582 connectivity requests (L1CSM), or as virtual network requests 583 (ACTN VN). 585 * MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate 586 networks under the control of PNCs. The requests on this 587 interface may use TE tunnel models, TE topology models, VPN 588 network configuration models or layer one connectivity models. 590 * SBI: The Southbound Interface is used by the PNC to control 591 network devices and is out of scope for this document. 593 The TE Service Mapping Model as described in this document can be 594 used to see the mapping between service models and VN models and TE 595 Tunnel/Topology models. That mapping may occur in the CNC if a 596 service request is mapped to a VN request. Or it may occur in the 597 MDSC where a service request is mapped to a TE tunnel, TE topology, 598 or VPN network configuration model. The TE Service Mapping Model may 599 be read from the CNC or MDSC to understand how the mapping has been 600 made and to see the purpose for which network resources are used. 602 As shown in Figure 3, the MDSC may be used recursively. For example, 603 the CNC might map a L3SM request to a VN request that it sends to a 604 recursive MDSC. 606 The high-level control flows for one example are as follows: 608 1. A customer asks for an L3VPN between CE1 and CE2 using the 609 Augmented L3SM model. 611 2. The MDSC considers the service request and local policy to 612 determine if it needs to create a new VN or any TE Topology, and 613 if that is the case, ACTN VN YANG [I-D.ietf-teas-actn-vn-yang] is 614 used to configure a new VN based on this VPN and map the VPN 615 service to the ACTN VN. In case an existing tunnel is to be 616 used, each device will select which tunnel to use and populate 617 this mapping information. 619 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 620 PNC to create a PE-PE tunnel in the IP network mapped to a TE 621 tunnel in the transport network by providing the inter-layer 622 access points and tunnel requirements. The specific service 623 information is passed to the IP/MPLS PNC for the actual VPN 624 configuration and activation. 626 a. The Transport PNC creates the corresponding TE tunnel 627 matching with the access point and egress point. 629 b. The IP/MPLS PNC maps the VPN ID with the corresponding TE 630 tunnel ID to bind these two IDs. 632 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 633 customer. This is not in the scope of this document. 635 4.1. Service Mapping 637 Augmented L3SM and L2SM can be used to request VPN service creation 638 including the creation of sites and corresponding site network access 639 connection between CE and PE. A VPN-ID is used to identify each VPN 640 service ordered by the customer. The ACTN VN can be used further to 641 establish PE-to-PE connectivity between VPN sites belonging to the 642 same VPN service. A VN-ID is used to identify each virtual network 643 established between VPN sites. 645 Once the ACTN VN has been established over the TE network (maybe a 646 new VN, maybe modification of an existing VN, or maybe the use of an 647 unmodified existing VN), the mapping between the VPN service and the 648 ACTN VN service can be created. 650 4.2. Site Mapping 652 The elements in Augmented L3SM and L2SM define site location 653 parameters and constraints such as distance and access diversity that 654 can influence the placement of network attachment points (i.e, 655 virtual network access points (VNAP)). To achieve this, a central 656 directory can be set up to establish the mapping between location 657 parameters and constraints and network attachment point location. 658 Suppose multiple attachment points are matched, the management system 659 can use constraints or other local policy to select the best 660 candidate network attachment points. 662 After a network attachment point is selected, the mapping between VPN 663 site and VNAP can be established as shown in Table 1. 665 +=======+=========+==================+========================+=====+ 666 | Site | Site | Location | Access Diversity | PE | 667 | | Network | (Address, | (Constraint-Type, | | 668 | | Access | Postal Code, | Group-id,Target Group- | | 669 | | | State, | id) | | 670 | | | City,Country | | | 671 | | | Code) | | | 672 +=======+=========+==================+========================+=====+ 673 | SITE1 | ACCESS1 | (,,US,NewYork,) | (10,PE-Diverse,10) | PE1 | 674 +-------+---------+------------------+------------------------+-----+ 675 | SITE2 | ACCESS2 | (,,CN,Beijing,) | (10,PE-Diverse,10) | PE2 | 676 +-------+---------+------------------+------------------------+-----+ 677 | SITE3 | ACCESS3 | (,,UK,London, ) | (12,same-PE,12) | PE4 | 678 +-------+---------+------------------+------------------------+-----+ 679 | SITE4 | ACCESS4 | (,,FR,Paris,) | (20,Bearer-Diverse,20) | PE7 | 680 +-------+---------+------------------+------------------------+-----+ 682 Table 2: : Mapping Between VPN Site and VNAP 684 5. Applicability of TE-Service Mapping in Generic context 686 As discussed in the Introduction Section, the models presented in 687 this document are also applicable generically outside of the ACTN 688 architecture. [RFC8309] defines Customer Service Model between 689 Customer and Service Orchestrator and Service Delivery Model between 690 Service Orchestrator and Network Orchestrator(s). TE-Service mapping 691 models defined in this document can be regarded primarily as Customer 692 Service Model and secondarily as Service Deliver Model. 694 6. YANG Data Trees 696 6.1. Service Mapping Types 698 module: ietf-te-service-mapping-types 699 +--rw te-mapping-templates 700 +--rw te-mapping-template* [id] 701 +--rw id te-mapping-template-id 702 +--rw description? string 703 +--rw map-type? identityref 704 +--rw path-constraints 705 | +--rw te-bandwidth 706 | | +--rw (technology)? 707 | | +--:(generic) 708 | | +--rw generic? te-bandwidth 709 | +--rw link-protection? identityref 710 | +--rw setup-priority? uint8 711 | +--rw hold-priority? uint8 712 | +--rw signaling-type? identityref 713 | +--rw path-metric-bounds 714 | | +--rw path-metric-bound* [metric-type] 715 | | +--rw metric-type identityref 716 | | +--rw upper-bound? uint64 717 | +--rw path-affinities-values 718 | | +--rw path-affinities-value* [usage] 719 | | +--rw usage identityref 720 | | +--rw value? admin-groups 721 | +--rw path-affinity-names 722 | | +--rw path-affinity-name* [usage] 723 | | +--rw usage identityref 724 | | +--rw affinity-name* [name] 725 | | +--rw name string 726 | +--rw path-srlgs-lists 727 | | +--rw path-srlgs-list* [usage] 728 | | +--rw usage identityref 729 | | +--rw values* srlg 730 | +--rw path-srlgs-names 731 | | +--rw path-srlgs-name* [usage] 732 | | +--rw usage identityref 733 | | +--rw names* string 734 | +--rw disjointness? te-path-disjointness 735 +--rw optimizations 736 +--rw (algorithm)? 737 +--:(metric) {path-optimization-metric}? 738 | +--rw optimization-metric* [metric-type] 739 | | +--rw metric-type 740 | | | identityref 741 | | +--rw weight? uint8 742 | | +--rw explicit-route-exclude-objects 743 | | | ... 744 | | +--rw explicit-route-include-objects 745 | | ... 746 | +--rw tiebreakers 747 | +--rw tiebreaker* [tiebreaker-type] 748 | ... 749 +--:(objective-function) 750 {path-optimization-objective-function}? 751 +--rw objective-function 752 +--rw objective-function-type? identityref 754 6.2. Service Models 756 6.2.1. L3SM 758 module: ietf-l3sm-te-service-mapping 759 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services 760 /l3vpn-svc:vpn-service: 761 +--rw te-service-mapping! 762 +--rw te-mapping 763 +--rw map-type? identityref 764 +--rw te-policy 765 | +--rw color? uint32 766 | +--rw protection-type? identityref 767 | +--rw availability-type? identityref 768 +--rw (te)? 769 | +--:(vn) 770 | | +--rw vn* 771 | | -> /vn:virtual-network/vn/vn-id 772 | +--:(te-topo) 773 | | +--rw vn-topology-id? te-types:te-topology-id 774 | | +--rw abstract-node? 775 | | -> /nw:networks/network/node/node-id 776 | +--:(te-tunnel) 777 | +--rw te-tunnel* te:tunnel-ref 778 | +--rw sr-policy* 779 | [policy-color-ref policy-endpoint-ref] 780 | {sr-policy}? 781 | +--rw policy-color-ref leafref 782 | +--rw policy-endpoint-ref leafref 783 +--rw te-mapping-template-ref? 784 -> /tsmt:te-mapping-templates/te-mapping-template/id 785 {template}? 786 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 787 /l3vpn-svc:site-network-accesses 788 /l3vpn-svc:site-network-access: 789 +--rw (te)? 790 +--:(vn) 791 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 792 +--:(te) 793 +--rw ltp? te-types:te-tp-id 794 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 795 /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile 796 /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes 797 /l3vpn-svc:class: 798 +--rw (te)? 799 +--:(vn) 800 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 801 +--:(te) 802 +--rw ltp? te-types:te-tp-id 803 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 804 /l3vpn-svc:site-network-accesses 805 /l3vpn-svc:site-network-access/l3vpn-svc:service 806 /l3vpn-svc:qos/l3vpn-svc:qos-profile 807 /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes 808 /l3vpn-svc:class: 809 +--rw (te)? 810 +--:(vn) 811 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 812 +--:(te) 813 +--rw ltp? te-types:te-tp-id 815 6.2.2. L2SM 817 module: ietf-l2sm-te-service-mapping 818 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services 819 /l2vpn-svc:vpn-service: 820 +--rw te-service-mapping! 821 +--rw te-mapping 822 +--rw map-type? identityref 823 +--rw te-policy 824 | +--rw color? uint32 825 | +--rw protection-type? identityref 826 | +--rw availability-type? identityref 827 +--rw (te)? 828 | +--:(vn) 829 | | +--rw vn* 830 | | -> /vn:virtual-network/vn/vn-id 831 | +--:(te-topo) 832 | | +--rw vn-topology-id? te-types:te-topology-id 833 | | +--rw abstract-node? 834 | | -> /nw:networks/network/node/node-id 835 | +--:(te-tunnel) 836 | +--rw te-tunnel* te:tunnel-ref 837 | +--rw sr-policy* 838 | [policy-color-ref policy-endpoint-ref] 839 | {sr-policy}? 840 | +--rw policy-color-ref leafref 841 | +--rw policy-endpoint-ref leafref 842 +--rw te-mapping-template-ref? 843 -> /tsmt:te-mapping-templates/te-mapping-template/id 844 {template}? 845 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 846 /l2vpn-svc:site-network-accesses 847 /l2vpn-svc:site-network-access: 848 +--rw (te)? 849 +--:(vn) 850 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 851 +--:(te) 852 +--rw ltp? te-types:te-tp-id 853 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 854 /l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile 855 /l2vpn-svc:qos-profile/l2vpn-svc:custom/l2vpn-svc:classes 856 /l2vpn-svc:class: 857 +--rw (te)? 858 +--:(vn) 859 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 860 +--:(te) 861 +--rw ltp? te-types:te-tp-id 862 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 863 /l2vpn-svc:site-network-accesses 864 /l2vpn-svc:site-network-access/l2vpn-svc:service 865 /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 874 6.2.3. L1CSM 875 module: ietf-l1csm-te-service-mapping 876 augment /l1csm:l1-connectivity/l1csm:services/l1csm:service: 877 +--rw te-service-mapping! 878 +--rw te-mapping 879 +--rw map-type? identityref 880 +--rw te-policy 881 | +--rw color? uint32 882 | +--rw protection-type? identityref 883 | +--rw availability-type? identityref 884 +--rw (te)? 885 | +--:(vn) 886 | | +--rw vn* 887 | | -> /vn:virtual-network/vn/vn-id 888 | +--:(te-topo) 889 | | +--rw vn-topology-id? te-types:te-topology-id 890 | | +--rw abstract-node? 891 | | -> /nw:networks/network/node/node-id 892 | +--:(te-tunnel) 893 | +--rw te-tunnel* te:tunnel-ref 894 | +--rw sr-policy* 895 | [policy-color-ref policy-endpoint-ref] 896 | {sr-policy}? 897 | +--rw policy-color-ref leafref 898 | +--rw policy-endpoint-ref leafref 899 +--rw te-mapping-template-ref? 900 -> /tsmt:te-mapping-templates/te-mapping-template/id 901 {template}? 902 augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni: 903 +--rw (te)? 904 +--:(vn) 905 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 906 +--:(te) 907 +--rw ltp? te-types:te-tp-id 909 6.3. Network Models 911 6.3.1. L3NM 912 module: ietf-l3nm-te-service-mapping 913 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 914 /l3vpn-ntw:vpn-service: 915 +--rw te-service-mapping! 916 +--rw te-mapping 917 +--rw map-type? identityref 918 +--rw te-policy 919 | +--rw color? uint32 920 | +--rw protection-type? identityref 921 | +--rw availability-type? identityref 922 +--rw (te)? 923 | +--:(vn) 924 | | +--rw vn* 925 | | -> /vn:virtual-network/vn/vn-id 926 | +--:(te-topo) 927 | | +--rw vn-topology-id? te-types:te-topology-id 928 | | +--rw abstract-node? 929 | | -> /nw:networks/network/node/node-id 930 | +--:(te-tunnel) 931 | +--rw te-tunnel* te:tunnel-ref 932 | +--rw sr-policy* 933 | [policy-color-ref policy-endpoint-ref] 934 | {sr-policy}? 935 | +--rw policy-color-ref leafref 936 | +--rw policy-endpoint-ref leafref 937 +--rw te-mapping-template-ref? 938 -> /tsmt:te-mapping-templates/te-mapping-template/id 939 {template}? 940 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 941 /l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes 942 /l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses 943 /l3vpn-ntw:vpn-network-access: 944 +--rw (te)? 945 +--:(vn) 946 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 947 +--:(te) 948 +--rw ltp? te-types:te-tp-id 950 6.3.2. L2NM 951 module: ietf-l2nm-te-service-mapping 952 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 953 /l2vpn-ntw:vpn-service: 954 +--rw te-service-mapping! 955 +--rw te-mapping 956 +--rw map-type? identityref 957 +--rw te-policy 958 | +--rw color? uint32 959 | +--rw protection-type? identityref 960 | +--rw availability-type? identityref 961 +--rw (te)? 962 | +--:(vn) 963 | | +--rw vn* 964 | | -> /vn:virtual-network/vn/vn-id 965 | +--:(te-topo) 966 | | +--rw vn-topology-id? te-types:te-topology-id 967 | | +--rw abstract-node? 968 | | -> /nw:networks/network/node/node-id 969 | +--:(te-tunnel) 970 | +--rw te-tunnel* te:tunnel-ref 971 | +--rw sr-policy* 972 | [policy-color-ref policy-endpoint-ref] 973 | {sr-policy}? 974 | +--rw policy-color-ref leafref 975 | +--rw policy-endpoint-ref leafref 976 +--rw te-mapping-template-ref? 977 -> /tsmt:te-mapping-templates/te-mapping-template/id 978 {template}? 979 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 980 /l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes 981 /l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses 982 /l2vpn-ntw:vpn-network-access: 983 +--rw (te)? 984 +--:(vn) 985 | +--rw vn-ap* -> /vn:access-point/ap/vn-ap/vn-ap-id 986 +--:(te) 987 +--rw ltp? te-types:te-tp-id 989 7. YANG Data Models 991 The YANG codes are as follows: 993 7.1. ietf-te-service-mapping-types 994 file "ietf-te-service-mapping-types@2021-08-28.yang" 995 module ietf-te-service-mapping-types { 996 yang-version 1.1; 997 namespace 998 "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; 999 prefix tsmt; 1001 /* Import te-types */ 1003 import ietf-te-types { 1004 prefix te-types; 1005 reference 1006 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 1007 } 1009 /* Import network model */ 1011 import ietf-network { 1012 prefix nw; 1013 reference 1014 "RFC 8345: A YANG Data Model for Network Topologies"; 1015 } 1017 /* Import TE model */ 1019 import ietf-te { 1020 prefix te; 1021 reference 1022 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1023 Engineering Tunnels and Interfaces"; 1024 } 1026 /* Import VN model */ 1028 import ietf-vn { 1029 prefix vn; 1030 reference 1031 "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation"; 1032 } 1034 /* Import Routing */ 1036 import ietf-routing { 1037 prefix rt; 1038 reference 1039 "RFC 8349: A YANG Data Model for Routing Management"; 1040 } 1041 /* Import SR Policy */ 1043 import ietf-sr-policy { 1044 prefix sr-policy; 1045 reference 1046 "I-D.ietf-spring-sr-policy-yang: YANG Data Model for Segment 1047 Routing Policy"; 1048 } 1050 organization 1051 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1052 Working Group"; 1053 contact 1054 "WG Web: 1055 WG List: 1057 Editor: Young Lee 1058 1059 Editor: Dhruv Dhody 1060 1061 Editor: Qin Wu 1062 "; 1063 description 1064 "This module contains a YANG module for TE & Service mapping 1065 parameters and policies as a common grouping applicable to 1066 variuous service models (e.g., L1CSM, L2SM, L3SM, etc.) 1068 Copyright (c) 2021 IETF Trust and the persons identified as 1069 authors of the code. All rights reserved. 1071 Redistribution and use in source and binary forms, with or 1072 without modification, is permitted pursuant to, and subject to 1073 the license terms contained in, the Simplified BSD License set 1074 forth in Section 4.c of the IETF Trust's Legal Provisions 1075 Relating to IETF Documents 1076 (https://trustee.ietf.org/license-info). 1078 This version of this YANG module is part of RFC XXXX; see the 1079 RFC itself for full legal notices."; 1081 revision 2021-08-28 { 1082 description 1083 "Initial revision."; 1084 reference 1085 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1086 } 1088 /* 1089 * Features 1090 */ 1092 feature template { 1093 description 1094 "Support TE mapping templates."; 1095 } 1097 feature sr-policy { 1098 description 1099 "Support SR Policy."; 1100 } 1102 /* 1103 * Identity for map-type 1104 */ 1106 identity map-type { 1107 description 1108 "Base identity from which specific map types are derived."; 1109 } 1111 identity new { 1112 base map-type; 1113 description 1114 "The new VN/tunnels are binded to the service."; 1115 } 1117 identity hard-isolation { 1118 base new; 1119 description 1120 "Hard isolation."; 1121 } 1123 identity detnet-hard-isolation { 1124 base hard-isolation; 1125 description 1126 "Hard isolation with deterministic characteristics."; 1127 } 1129 identity soft-isolation { 1130 base new; 1131 description 1132 "Soft-isolation."; 1133 } 1135 identity select { 1136 base map-type; 1137 description 1138 "The VPN service selects an existing tunnel with no 1139 modification."; 1140 } 1142 identity modify { 1143 base map-type; 1144 description 1145 "The VPN service selects an existing tunnel and allows to modify 1146 the properties of the tunnel (e.g., b/w)"; 1147 } 1149 identity none { 1150 base map-type; 1151 description 1152 "The VPN service is not mapped to any underlying TE"; 1153 } 1155 /* 1156 * Identity for availability-type 1157 */ 1159 identity availability-type { 1160 description 1161 "Base identity from which specific map types are derived."; 1162 } 1164 identity level-1 { 1165 base availability-type; 1166 description 1167 "level 1: 99.9999%"; 1168 } 1170 identity level-2 { 1171 base availability-type; 1172 description 1173 "level 2: 99.999%"; 1174 } 1176 identity level-3 { 1177 base availability-type; 1178 description 1179 "level 3: 99.99%"; 1180 } 1182 identity level-4 { 1183 base availability-type; 1184 description 1185 "level 4: 99.9%"; 1186 } 1188 identity level-5 { 1189 base availability-type; 1190 description 1191 "level 5: 99%"; 1192 } 1194 /* 1195 * Typedef 1196 */ 1198 typedef te-mapping-template-id { 1199 type string; 1200 description 1201 "Identifier for a TE mapping template."; 1202 } 1204 /* 1205 * Groupings 1206 */ 1208 grouping te-ref { 1209 description 1210 "The reference to TE."; 1211 choice te { 1212 description 1213 "How the VPN is mapped to a VN, Topology, Tunnel, SR Policy 1214 etc."; 1215 case vn { 1216 leaf-list vn { 1217 type leafref { 1218 path "/vn:virtual-network/vn:vn/vn:vn-id"; 1219 } 1220 description 1221 "The reference to VN"; 1222 reference 1223 "RFC 8453: Framework for Abstraction and Control of TE 1224 Networks (ACTN)"; 1225 } 1226 } 1227 case te-topo { 1228 leaf vn-topology-id { 1229 type te-types:te-topology-id; 1230 description 1231 "An identifier to the TE Topology Model where the abstract 1232 nodes and links of the Topology can be found for Type 2 1233 VNs as defined in RFC 8453"; 1234 reference 1235 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1236 Topologies 1237 RFC 8453: Framework for Abstraction and Control of TE 1238 Networks (ACTN)"; 1239 } 1240 leaf abstract-node { 1241 type leafref { 1242 path "/nw:networks/nw:network/nw:node/nw:node-id"; 1243 } 1244 description 1245 "A reference to the abstract node in TE Topology"; 1246 reference 1247 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1248 Topologies"; 1249 } 1250 } 1251 case te-tunnel { 1252 leaf-list te-tunnel { 1253 type te:tunnel-ref; 1254 description 1255 "Reference to TE Tunnels"; 1256 reference 1257 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1258 Engineering Tunnels and Interfaces"; 1259 } 1260 list sr-policy { 1261 if-feature "sr-policy"; 1262 key "policy-color-ref policy-endpoint-ref"; 1263 description 1264 "SR Policy"; 1265 leaf policy-color-ref { 1266 type leafref { 1267 path 1268 "/rt:routing/sr-policy:segment-routing" 1269 + "/sr-policy:traffic-engineering/sr-policy:policies" 1270 + "/sr-policy:policy/sr-policy:color"; 1271 } 1272 description 1273 "Reference to sr-policy color"; 1274 } 1275 leaf policy-endpoint-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:endpoint"; 1282 } 1283 description 1284 "Reference to sr-policy endpoint"; 1285 } 1286 } 1287 } 1288 } 1289 leaf te-mapping-template-ref { 1290 if-feature "template"; 1291 type leafref { 1292 path "/tsmt:te-mapping-templates/" 1293 + "tsmt:te-mapping-template/tsmt:id"; 1294 } 1295 description 1296 "An identifier to the TE Mapping Template where the TE 1297 constraints and optimization criteria are specified."; 1298 } 1299 } 1301 //grouping 1303 grouping te-endpoint-ref { 1304 description 1305 "The reference to TE endpoints."; 1306 choice te { 1307 description 1308 "How the TE endpoint is defined by VN's AP or TE's LTP"; 1309 case vn { 1310 leaf-list vn-ap { 1311 type leafref { 1312 path "/vn:access-point/vn:ap/vn:vn-ap/vn:vn-ap-id"; 1313 } 1314 description 1315 "The reference to VNAP"; 1316 reference 1317 "RFC 8453: Framework for Abstraction and Control of TE 1318 Networks (ACTN)"; 1319 } 1320 } 1321 case te { 1322 leaf ltp { 1323 type te-types:te-tp-id; 1324 description 1325 "Reference LTP in the TE-topology"; 1326 reference 1327 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1328 Topologies"; 1329 } 1331 } 1332 } 1333 } 1335 //grouping 1337 grouping te-policy { 1338 description 1339 "Various underlying TE policy requirements"; 1340 leaf color { 1341 type uint32; 1342 description 1343 "Maps to the underlying colored TE resources"; 1344 } 1345 leaf protection-type { 1346 type identityref { 1347 base te-types:lsp-protection-type; 1348 } 1349 description 1350 "Desired protection level for the underlying 1351 TE resources"; 1352 } 1353 leaf availability-type { 1354 type identityref { 1355 base availability-type; 1356 } 1357 description 1358 "Availability Requirement for the Service"; 1359 } 1360 } 1362 //grouping 1364 grouping te-mapping { 1365 description 1366 "Mapping between Services and TE"; 1367 container te-mapping { 1368 description 1369 "Mapping between Services and TE"; 1370 leaf map-type { 1371 type identityref { 1372 base map-type; 1373 } 1374 description 1375 "Isolation Requirements, Tunnel Bind or 1376 Tunnel Selection"; 1377 } 1378 container te-policy { 1379 uses te-policy; 1380 description 1381 "Desired Underlying TE Policy"; 1382 } 1383 uses te-ref; 1384 } 1385 } 1387 //grouping 1389 container te-mapping-templates { 1390 description 1391 "The TE constraints and optimization criteria"; 1392 list te-mapping-template { 1393 key "id"; 1394 leaf id { 1395 type te-mapping-template-id; 1396 description 1397 "Identification of the Template to be used."; 1398 } 1399 leaf description { 1400 type string; 1401 description 1402 "Description of the template."; 1403 } 1404 leaf map-type { 1405 type identityref { 1406 base map-type; 1407 } 1408 must "0 = derived-from-or-self(.,'none')" { 1409 error-message "The map-type must be other than " 1410 + "none"; 1411 } 1412 description 1413 "Map type for the VN/Tunnel creation/ 1414 selection."; 1415 } 1416 uses te-types:generic-path-constraints; 1417 uses te-types:generic-path-optimization; 1418 description 1419 "List for templates."; 1420 } 1421 } 1422 } 1423 1425 7.2. Service Models 1426 7.2.1. ietf-l3sm-te-service-mapping 1428 file "ietf-l3sm-te-service-mapping@2021-08-28.yang" 1429 module ietf-l3sm-te-service-mapping { 1430 yang-version 1.1; 1431 namespace 1432 "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; 1433 prefix l3-tsm; 1435 import ietf-te-service-mapping-types { 1436 prefix tsmt; 1437 reference 1438 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1439 } 1440 import ietf-l3vpn-svc { 1441 prefix l3vpn-svc; 1442 reference 1443 "RFC 8299: YANG Data Model for L3VPN Service Delivery"; 1444 } 1446 organization 1447 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1448 Working Group"; 1449 contact 1450 "WG Web: 1451 WG List: 1453 Editor: Young Lee 1454 1455 Editor: Dhruv Dhody 1456 1457 Editor: Qin Wu 1458 "; 1459 description 1460 "This module contains a YANG module for the mapping of Layer 3 1461 Service Model (L3SM) to the TE and VN. 1463 Copyright (c) 2021 IETF Trust and the persons identified as 1464 authors of the code. All rights reserved. 1466 Redistribution and use in source and binary forms, with or 1467 without modification, is permitted pursuant to, and subject to 1468 the license terms contained in, the Simplified BSD License set 1469 forth in Section 4.c of the IETF Trust's Legal Provisions 1470 Relating to IETF Documents 1471 (https://trustee.ietf.org/license-info). 1472 This version of this YANG module is part of RFC XXXX; see the 1473 RFC itself for full legal notices."; 1475 revision 2021-08-28 { 1476 description 1477 "Initial revision."; 1478 reference 1479 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1480 } 1482 /* 1483 * Augmentation to L3SM 1484 */ 1486 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services" 1487 + "/l3vpn-svc:vpn-service" { 1488 description 1489 "L3SM augmented to include TE parameters and mapping"; 1490 container te-service-mapping { 1491 presence "Indicates L3 service to TE mapping"; 1492 description 1493 "Container to augment l3sm to TE parameters and mapping"; 1494 uses tsmt:te-mapping; 1495 } 1496 } 1498 //augment 1500 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1501 + "/l3vpn-svc:site-network-accesses" 1502 + "/l3vpn-svc:site-network-access" { 1503 description 1504 "This augment is only valid for TE mapping of L3SM network-access 1505 to TE endpoints"; 1506 uses tsmt:te-endpoint-ref; 1507 } 1509 //augment 1511 augment 1512 "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1513 + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile" 1514 + "/l3vpn-svc:qos-profile/l3vpn-svc:custom" 1515 + "/l3vpn-svc:classes/l3vpn-svc:class" { 1516 description 1517 "This augment is for per-class in site for custom QoS profile"; 1518 uses tsmt:te-endpoint-ref; 1519 } 1521 augment 1522 "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1524 + "/l3vpn-svc:site-network-accesses" 1525 + "/l3vpn-svc:site-network-access" 1526 + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile" 1527 + "/l3vpn-svc:qos-profile/l3vpn-svc:custom" 1528 + "/l3vpn-svc:classes/l3vpn-svc:class" { 1529 description 1530 "This augment is for per-class in site-network-access for custom 1531 QoS profile"; 1532 uses tsmt:te-endpoint-ref; 1533 } 1534 } 1535 1537 7.2.2. ietf-l2sm-te-service-mapping 1539 file "ietf-l2sm-te-service-mapping@2021-08-28.yang" 1540 module ietf-l2sm-te-service-mapping { 1541 yang-version 1.1; 1542 namespace 1543 "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; 1544 prefix l2-tsm; 1546 import ietf-te-service-mapping-types { 1547 prefix tsmt; 1548 reference 1549 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1550 } 1551 import ietf-l2vpn-svc { 1552 prefix l2vpn-svc; 1553 reference 1554 "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network 1555 (L2VPN) Service Delivery"; 1556 } 1558 organization 1559 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1560 Working Group"; 1561 contact 1562 "WG Web: 1563 WG List: 1565 Editor: Young Lee 1566 1567 Editor: Dhruv Dhody 1568 1569 Editor: Qin Wu 1570 "; 1571 description 1572 "This module contains a YANG module for the mapping of Layer 2 1573 Service Model (L2SM) to the TE and VN. 1575 Copyright (c) 2021 IETF Trust and the persons identified as 1576 authors of the code. All rights reserved. 1578 Redistribution and use in source and binary forms, with or 1579 without modification, is permitted pursuant to, and subject to 1580 the license terms contained in, the Simplified BSD License set 1581 forth in Section 4.c of the IETF Trust's Legal Provisions 1582 Relating to IETF Documents 1583 (https://trustee.ietf.org/license-info). 1585 This version of this YANG module is part of RFC XXXX; see the 1586 RFC itself for full legal notices."; 1588 revision 2021-08-28 { 1589 description 1590 "Initial revision."; 1591 reference 1592 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1593 } 1595 /* 1596 * Augmentation to L2SM 1597 */ 1599 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/" 1600 + "l2vpn-svc:vpn-service" { 1601 description 1602 "L2SM augmented to include TE parameters and mapping"; 1603 container te-service-mapping { 1604 presence "indicates L2 service to te mapping"; 1605 description 1606 "Container to augment L2SM to TE parameters and mapping"; 1607 uses tsmt:te-mapping; 1608 } 1609 } 1611 //augment 1613 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1614 + "/l2vpn-svc:site-network-accesses" 1615 + "/l2vpn-svc:site-network-access" { 1616 description 1617 "This augment the L2SM network-access with a reference 1618 to TE endpoints when underlying TE is used"; 1619 uses tsmt:te-endpoint-ref; 1621 } 1623 //augment 1625 augment 1626 "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1627 + "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile" 1628 + "/l2vpn-svc:qos-profile/l2vpn-svc:custom" 1629 + "/l2vpn-svc:classes/l2vpn-svc:class" { 1630 when './l2vpn-svc:bandwidth/l2vpn-svc:end-to-end' { 1631 description 1632 "applicable only with end-to-end"; 1633 } 1634 description 1635 "This augment is for per-class in site for custom QoS profile"; 1636 uses tsmt:te-endpoint-ref; 1637 } 1639 augment 1640 "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1641 + "/l2vpn-svc:site-network-accesses" 1642 + "/l2vpn-svc:site-network-access" 1643 + "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile" 1644 + "/l2vpn-svc:qos-profile/l2vpn-svc:custom" 1645 + "/l2vpn-svc:classes/l2vpn-svc:class" { 1646 description 1647 "This augment is for per-class in site-network-access for custom 1648 QoS profile"; 1649 uses tsmt:te-endpoint-ref; 1650 } 1651 } 1652 1654 7.2.3. ietf-l1csm-te-service-mapping 1656 file "ietf-l1csm-te-service-mapping@2021-08-28.yang" 1657 module ietf-l1csm-te-service-mapping { 1658 yang-version 1.1; 1659 namespace 1660 "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; 1661 prefix l1-tsm; 1663 import ietf-te-service-mapping-types { 1664 prefix tsmt; 1665 reference 1666 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1667 } 1668 import ietf-l1csm { 1669 prefix l1csm; 1670 reference 1671 "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity 1672 Service Model (L1CSM)"; 1673 } 1675 organization 1676 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1677 Working Group"; 1678 contact 1679 "WG Web: 1680 WG List: 1682 Editor: Young Lee 1683 1684 Editor: Dhruv Dhody 1685 1686 Editor: Qin Wu 1687 "; 1688 description 1689 "This module contains a YANG module for the mapping of 1690 Layer 1 Connectivity Service Module (L1CSM) to the TE and VN 1692 Copyright (c) 2021 IETF Trust and the persons identified as 1693 authors of the code. All rights reserved. 1695 Redistribution and use in source and binary forms, with or 1696 without modification, is permitted pursuant to, and subject to 1697 the license terms contained in, the Simplified BSD License set 1698 forth in Section 4.c of the IETF Trust's Legal Provisions 1699 Relating to IETF Documents 1700 (https://trustee.ietf.org/license-info). 1702 This version of this YANG module is part of RFC XXXX; see the 1703 RFC itself for full legal notices."; 1705 revision 2021-08-28 { 1706 description 1707 "Initial revision."; 1708 reference 1709 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1710 } 1712 /* 1713 * Augmentation to L1CSM 1714 */ 1716 augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" { 1717 description 1718 "L1CSM augmented to include TE parameters and mapping"; 1719 container te-service-mapping { 1720 presence "Indicates L1 service to TE mapping"; 1721 description 1722 "Container to augment L1CSM to TE parameters and mapping"; 1723 uses tsmt:te-mapping; 1724 } 1725 } 1727 //augment 1729 augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/" 1730 + "l1csm:uni" { 1731 description 1732 "This augment the L1CSM UNI with a reference 1733 to TE endpoints"; 1734 uses tsmt:te-endpoint-ref; 1735 } 1737 //augment 1738 } 1739 1741 7.3. Network Models 1743 7.3.1. ietf-l3nm-te-service-mapping 1745 file "ietf-l3nm-te-service-mapping@2021-08-28.yang" 1746 module ietf-l3nm-te-service-mapping { 1747 yang-version 1.1; 1748 namespace 1749 "urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping"; 1750 prefix l3nm-tsm; 1752 import ietf-te-service-mapping-types { 1753 prefix tsmt; 1754 reference 1755 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1756 } 1757 import ietf-l3vpn-ntw { 1758 prefix l3vpn-ntw; 1759 reference 1760 "I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model"; 1761 } 1763 organization 1764 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1765 Working Group"; 1766 contact 1767 "WG Web: 1768 WG List: 1770 Editor: Young Lee 1771 1772 Editor: Dhruv Dhody 1773 1774 Editor: Qin Wu 1775 "; 1776 description 1777 "This module contains a YANG module for the mapping of Layer 3 1778 Network Model (L3NM) to the TE and VN. 1780 Copyright (c) 2021 IETF Trust and the persons identified as 1781 authors of the code. All rights reserved. 1783 Redistribution and use in source and binary forms, with or 1784 without modification, is permitted pursuant to, and subject to 1785 the license terms contained in, the Simplified BSD License set 1786 forth in Section 4.c of the IETF Trust's Legal Provisions 1787 Relating to IETF Documents 1788 (https://trustee.ietf.org/license-info). 1789 This version of this YANG module is part of RFC XXXX; see the 1790 RFC itself for full legal notices."; 1792 revision 2021-08-28 { 1793 description 1794 "Initial revision."; 1795 reference 1796 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1797 } 1799 /* 1800 * Augmentation to L3NM 1801 */ 1803 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1804 + "/l3vpn-ntw:vpn-service" { 1805 description 1806 "L3SM augmented to include TE parameters and mapping"; 1807 container te-service-mapping { 1808 presence "Indicates L3 network to TE mapping"; 1809 description 1810 "Container to augment l3nm to TE parameters and mapping"; 1811 uses tsmt:te-mapping; 1812 } 1814 } 1816 //augment 1818 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1819 + "/l3vpn-ntw:vpn-service" 1820 + "/l3vpn-ntw:vpn-nodes/l3vpn-ntw:vpn-node" 1821 + "/l3vpn-ntw:vpn-network-accesses" 1822 + "/l3vpn-ntw:vpn-network-access" { 1823 description 1824 "This augment the L3NM network-access with a reference 1825 to TE endpoints when underlying TE is used"; 1826 uses tsmt:te-endpoint-ref; 1827 } 1829 //augment 1830 } 1831 1833 7.3.2. ietf-l2nm-te-service-mapping 1835 file "ietf-l2nm-te-service-mapping@2021-08-28.yang" 1836 module ietf-l2nm-te-service-mapping { 1837 yang-version 1.1; 1838 namespace 1839 "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping"; 1840 prefix l2nm-tsm; 1842 import ietf-te-service-mapping-types { 1843 prefix tsmt; 1844 reference 1845 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1846 } 1847 import ietf-l2vpn-ntw { 1848 prefix l2vpn-ntw; 1849 reference 1850 "I-D.ietf-opsawg-l2nm: A Layer 2 VPN Network YANG Model"; 1851 } 1853 organization 1854 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1855 Working Group"; 1856 contact 1857 "WG Web: 1858 WG List: 1860 Editor: Young Lee 1861 1863 Editor: Dhruv Dhody 1864 1865 Editor: Qin Wu 1866 "; 1867 description 1868 "This module contains a YANG module for the mapping of Layer 2 1869 Network Model (L2NM) to the TE and VN. 1871 Copyright (c) 2021 IETF Trust and the persons identified as 1872 authors of the code. All rights reserved. 1874 Redistribution and use in source and binary forms, with or 1875 without modification, is permitted pursuant to, and subject to 1876 the license terms contained in, the Simplified BSD License set 1877 forth in Section 4.c of the IETF Trust's Legal Provisions 1878 Relating to IETF Documents 1879 (https://trustee.ietf.org/license-info). 1881 This version of this YANG module is part of RFC XXXX; see the 1882 RFC itself for full legal notices."; 1884 revision 2021-08-28 { 1885 description 1886 "Initial revision."; 1887 reference 1888 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1889 } 1891 /* 1892 * Augmentation to L2NM 1893 */ 1895 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1896 + "/l2vpn-ntw:vpn-service" { 1897 description 1898 "L2SM augmented to include TE parameters and mapping"; 1899 container te-service-mapping { 1900 presence "Indicates L2 network to TE mapping"; 1901 description 1902 "Container to augment l2nm to TE parameters and mapping"; 1903 uses tsmt:te-mapping; 1904 } 1905 } 1907 //augment 1909 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1910 + "/l2vpn-ntw:vpn-service" 1911 + "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node" 1912 + "/l2vpn-ntw:vpn-network-accesses" 1913 + "/l2vpn-ntw:vpn-network-access" { 1914 description 1915 "This augment the L2NM network-access with a reference 1916 to TE endpoints when underlying TE is used"; 1917 uses tsmt:te-endpoint-ref; 1918 } 1920 //augment 1921 } 1922 1924 8. Security Considerations 1926 The YANG modules defined in this document is designed to be accessed 1927 via network management protocol such as NETCONF [RFC6241] or RESTCONF 1928 [RFC8040]. The lowest NETCONF layer is the secure transport layer 1929 and the mandatory-to-implement secure transport is SSH [RFC6242]. 1930 The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement 1931 secure transport is TLS [RFC8446] 1933 The NETCONF access control model [RFC8341] provides the means to 1934 restrict access for particular NETCONF or RESTCONF users to a pre- 1935 configured subset of all available NETCONF or RESTCONF protocol 1936 operations and content. 1938 There are a number of data nodes defined in the YANG moduleS which 1939 are writable/creatable/deletable (i.e., config true, which is the 1940 default). These data nodes may be considered sensitive or vulnerable 1941 in some network environments. Write operations (e.g., ) 1942 to these data nodes without proper protection can have a negative 1943 effect on network operations. These are the subtrees and data nodes 1944 and their sensitivity/vulnerability: 1946 * /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1947 - can configure TE Service mapping. 1949 * /l3vpn-svc/sites/site/site-network-accesses/site-network-access/ 1950 te/ - can configure TE Endpoint mapping. 1952 * /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1953 - can configure TE Service mapping. 1955 * /l2vpn-svc/sites/site/site-network-accesses/site-network-access/ 1956 te/ - can configure TE Endpoint mapping. 1958 * /l1-connectivity/services/service/te-service-mapping/te-mapping/ - 1959 can configure TE Service mapping. 1961 * /l1-connectivity/access/unis/uni/te/ - can configure TE Endpoint 1962 mapping. 1964 * /l3vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1965 - can configure TE Network mapping. 1967 * /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1968 network-accesses/vpn-network-access/te/ - can configure TE 1969 Endpoint mapping. 1971 * /l2vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1972 - can configure TE Network mapping. 1974 * /l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1975 network-accesses/vpn-network-access/te/ - can configure TE 1976 Endpoint mapping. 1978 Unauthorized access to above list can adversely affect the VPN 1979 service. 1981 Some of the readable data nodes in the YANG module may be considered 1982 sensitive or vulnerable in some network environments. It is thus 1983 important to control read access (e.g., via get, get-config, or 1984 notification) to these data nodes. The TE related parameters 1985 attached to the VPN service can leak sensitive information about the 1986 network. This is applicable to all elements in the yang models 1987 defined in this document. 1989 This document has no RPC defined. 1991 9. IANA Considerations 1993 This document request the IANA to register six URIs in the "IETF XML 1994 Registry" [RFC3688]. Following the format in RFC 3688, the following 1995 registrations are requested - 1996 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1997 Registrant Contact: The IESG. 1998 XML: N/A, the requested URI is an XML namespace. 2000 URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 2001 Registrant Contact: The IESG. 2002 XML: N/A, the requested URI is an XML namespace. 2004 URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 2005 Registrant Contact: The IESG. 2006 XML: N/A, the requested URI is an XML namespace. 2008 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 2009 Registrant Contact: The IESG. 2010 XML: N/A, the requested URI is an XML namespace. 2012 URI: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 2013 Registrant Contact: The IESG. 2014 XML: N/A, the requested URI is an XML namespace. 2016 URI: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 2017 Registrant Contact: The IESG. 2018 XML: N/A, the requested URI is an XML namespace. 2020 This document request the IANA to register six YANG modules in the 2021 "YANG Module Names" registry [RFC6020], as follows - 2022 Name: ietf-te-service-mapping-types 2023 Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 2024 Prefix: tsmt 2025 Reference: [This.I-D] 2027 Name: ietf-l3sm-te-service-mapping 2028 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 2029 Prefix: l3-tsm 2030 Reference: [This.I-D] 2032 Name: ietf-l2sm-te-service-mapping 2033 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 2034 Prefix: l2-tsm 2035 Reference: [This.I-D] 2037 Name: ietf-l1csm-te-service-mapping 2038 Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 2039 Prefix: l1-tsm 2040 Reference: [This.I-D] 2042 Name: ietf-l3nm-te-service-mapping 2043 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 2044 Prefix: l3nm-tsm 2045 Reference: [This.I-D] 2047 Name: ietf-l2nm-te-service-mapping 2048 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 2049 Prefix: l2nm-tsm 2050 Reference: [This.I-D] 2052 10. Acknowledgements 2054 We thank Diego Caviglia, and Igor Bryskin for useful discussions and 2055 motivation for this work. 2057 11. References 2059 11.1. Normative References 2061 [I-D.ietf-ccamp-l1csm-yang] 2062 Lee, Y., Lee, K., Zheng, H., Dios, O. G. D., and D. 2063 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2064 Model (L1CSM)", Work in Progress, Internet-Draft, draft- 2065 ietf-ccamp-l1csm-yang-14, 20 February 2021, 2066 . 2069 [I-D.ietf-opsawg-l2nm] 2070 Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. 2071 Munoz, "A Layer 2 VPN Network YANG Model", Work in 2072 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-04, 28 2073 July 2021, . 2076 [I-D.ietf-opsawg-l3sm-l3nm] 2077 Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., 2078 and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in 2079 Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-10, 2080 15 July 2021, . 2083 [I-D.ietf-spring-sr-policy-yang] 2084 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 2085 Matsushima, S., and V. P. Beeram, "YANG Data Model for 2086 Segment Routing Policy", Work in Progress, Internet-Draft, 2087 draft-ietf-spring-sr-policy-yang-01, 7 April 2021, 2088 . 2091 [I-D.ietf-teas-actn-vn-yang] 2092 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 2093 Yoon, "A YANG Data Model for VN Operation", Work in 2094 Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-12, 2095 25 August 2021, . 2098 [I-D.ietf-teas-yang-te] 2099 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 2100 and O. G. D. Dios, "A YANG Data Model for Traffic 2101 Engineering Tunnels, Label Switched Paths and Interfaces", 2102 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 2103 27, 8 July 2021, . 2106 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2107 DOI 10.17487/RFC3688, January 2004, 2108 . 2110 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2111 the Network Configuration Protocol (NETCONF)", RFC 6020, 2112 DOI 10.17487/RFC6020, October 2010, 2113 . 2115 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2116 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2117 . 2119 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 2120 Ceccarelli, D., and X. Zhang, "Problem Statement and 2121 Architecture for Information Exchange between 2122 Interconnected Traffic-Engineered Networks", BCP 206, 2123 RFC 7926, DOI 10.17487/RFC7926, July 2016, 2124 . 2126 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2127 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2128 . 2130 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2131 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2132 . 2134 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2135 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2136 DOI 10.17487/RFC8299, January 2018, 2137 . 2139 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2140 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2141 . 2143 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2144 Access Control Model", STD 91, RFC 8341, 2145 DOI 10.17487/RFC8341, March 2018, 2146 . 2148 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2149 and R. Wilton, "Network Management Datastore Architecture 2150 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2151 . 2153 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2154 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2155 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2156 2018, . 2158 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 2159 Routing Management (NMDA Version)", RFC 8349, 2160 DOI 10.17487/RFC8349, March 2018, 2161 . 2163 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2164 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2165 . 2167 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2168 Data Model for Layer 2 Virtual Private Network (L2VPN) 2169 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2170 2018, . 2172 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2173 "Common YANG Data Types for Traffic Engineering", 2174 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2175 . 2177 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2178 O. Gonzalez de Dios, "YANG Data Model for Traffic 2179 Engineering (TE) Topologies", RFC 8795, 2180 DOI 10.17487/RFC8795, August 2020, 2181 . 2183 11.2. Informative References 2185 [I-D.ietf-teas-actn-yang] 2186 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. 2187 Belotti, "Applicability of YANG models for Abstraction and 2188 Control of Traffic Engineered Networks", Work in Progress, 2189 Internet-Draft, draft-ietf-teas-actn-yang-07, 21 February 2190 2021, . 2193 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2194 and A. Bierman, Ed., "Network Configuration Protocol 2195 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2196 . 2198 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 2199 Classification", RFC 8199, DOI 10.17487/RFC8199, July 2200 2017, . 2202 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2203 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2204 . 2206 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2207 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2208 DOI 10.17487/RFC8453, August 2018, 2209 . 2211 Appendix A. Examples 2213 This section details a few examples on how the TE-service mapping is 2214 used in various scenarios. 2216 Example 1: An L3VPN service with an optimization criteria for the 2217 underlying TE as delay can be set in the mapping template and then 2218 augmented to the L3SM service. 2220 { 2221 "te-mapping-template":[ 2222 { 2223 "id": "delay", 2224 "map-type": "select", 2225 "optimizations": 2226 { 2227 "algorithm":{ 2228 "optimization-metric": [ 2229 { 2230 "metric-type":"path-metric-delay-average" 2231 } 2232 ] 2233 } 2234 } 2235 } 2236 ] 2237 } 2239 The L3SM service can map it to the existing least delay TE resources 2240 in form of a VN or TE-tunnels. 2242 Example 2: An L2VPN service with a bandwidth constraint and a hop- 2243 limit criteria for the underlying TE can be set in the mapping 2244 template and then augmented to the L2SM service. 2246 { 2247 "te-mapping-template":[ 2248 { 2249 "id": "bw-hop", 2250 "map-type": "new", 2251 "path-constraints":{ 2252 "te-bandwidth":{ 2253 "generic":10000 2254 }, 2255 "path-metric-bounds":{ 2256 "path-metric-bound":[ 2257 { 2258 "metric-type":"path-metric-hop", 2259 "upper-bound":10 2260 } 2261 ] 2262 } 2263 } 2264 ] 2265 } 2267 The L2SM service can map it to a new TE resources in form of a VN or 2268 TE-tunnels. 2270 Example 3: A VN (VN1) could be created before hand and then 2271 explicitly mapped to the L2VPN service as shown below. 2273 2274 2275 2276 2277 VPN1 2278 2279 2280 select 2281 2282 VN1 2283 2284 2285 2286 2287 2288 2290 Example 4: A VPN service may want different optimization criteria for 2291 some of its sites. The template does not allow for such a case but 2292 it can be achieved by creating the TE resources separately and then 2293 mapping them to the service. 2295 Appendix B. Discussion 2297 * While the support to bind a tunnel to the VPN is supported. We do 2298 not have a mechanism to map traffic to a path. The input can come 2299 from the user. E.g. the enterprise customer can tell, the traffic 2300 from source X on port Y should go with delay less than Z. Further 2301 discussion is required on how and where to model these. 2303 * Support for Calendaring and scheduling TE resources. 2305 Appendix C. Contributor Addresses 2306 Adrian Farrel 2307 Old Dog Consulting 2309 EMail: adrian@olddog.co.uk 2311 Italo Busi 2312 Huawei Technologies 2314 EMail: Italo.Busi@huawei.com 2316 Haomian Zheng 2317 Huawei Technologies 2319 EMail: zhenghaomian@huawei.com 2321 Anton Snitser 2322 Sedonasys 2324 EMail: antons@sedonasys.com 2326 SAMIER BARGUIL GIRALDO 2327 Telefonica 2329 EMail: samier.barguilgiraldo.ext@telefonica.com 2331 Oscar Gonzalez de Dios 2332 Telefonica 2334 EMail: oscar.gonzalezdedios@telefonica.com 2336 Carlo Perocchio 2337 Ericsson 2339 EMail: carlo.perocchio@ericsson.com 2341 Kenichi Ogaki 2342 KDDI 2343 Email: ke-oogaki@kddi.com 2345 Authors' Addresses 2347 Young Lee (editor) 2348 Samsung Electronics 2350 Email: younglee.tx@gmail.com 2351 Dhruv Dhody (editor) 2352 Huawei Technologies 2353 Divyashree Techno Park, Whitefield 2354 Bangalore 560066 2355 Karnataka 2356 India 2358 Email: dhruv.ietf@gmail.com 2360 Giuseppe Fioccola 2361 Huawei Technologies 2363 Email: giuseppe.fioccola@huawei.com 2365 Qin Wu (editor) 2366 Huawei Technologies 2368 Email: bill.wu@huawei.com 2370 Daniele Ceccarelli 2371 Ericsson 2372 Torshamnsgatan,48 2373 Stockholm, Sweden 2375 Email: daniele.ceccarelli@ericsson.com 2377 Jeff Tantsura 2378 Microsoft 2380 Email: jefftant.ietf@gmail.com