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