idnits 2.17.1 draft-ietf-teas-te-service-mapping-yang-03.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 -- The document date (March 8, 2020) is 1510 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 215, but not defined == Unused Reference: 'I-D.ietf-teas-yang-te-types' is defined on line 1724, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-10 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-07 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-22 == Outdated reference: A later version (-18) exists of draft-ietf-opsawg-l3sm-l3nm-01 == Outdated reference: A later version (-02) exists of draft-barguil-opsawg-l2sm-l2nm-00 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-05 Summary: 0 errors (**), 0 flaws (~~), 9 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: September 9, 2020 G. Fioccola 6 Q. Wu, Ed. 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 J. Tantsura 11 Apstra 12 March 8, 2020 14 Traffic Engineering (TE) and Service Mapping Yang Model 15 draft-ietf-teas-te-service-mapping-yang-03 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 September 9, 2020. 47 Copyright Notice 49 Copyright (c) 2020 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.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5 67 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 68 2. TE and Service Related Parameters . . . . . . . . . . . . . . 6 69 2.1. VN/Tunnel Selection Requirements . . . . . . . . . . . . 6 70 2.2. Availability Requirement . . . . . . . . . . . . . . . . 7 71 3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 7 72 3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 8 73 3.2. TE and Network Models . . . . . . . . . . . . . . . . . . 8 74 4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 9 75 4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 12 76 4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 12 77 5. Applicability of TE-Service Mapping in Generic context . . . 13 78 6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.1. Service Models . . . . . . . . . . . . . . . . . . . . . 13 80 6.1.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.1.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 14 82 6.1.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 15 83 6.2. Network Models . . . . . . . . . . . . . . . . . . . . . 16 84 6.2.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.2.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 17 86 7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 18 87 7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 18 88 7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 24 89 7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 24 90 7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 26 91 7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 28 92 7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 30 93 7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 30 94 7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 32 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 37 101 11.2. Informative References . . . . . . . . . . . . . . . . . 39 102 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 40 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 105 1. Introduction 107 Data models are a representation of objects that can be configured or 108 monitored within a system. Within the IETF, YANG [RFC7950] is the 109 language of choice for documenting data models, and YANG models have 110 been produced to allow configuration or modelling of a variety of 111 network devices, protocol instances, and network services. YANG data 112 models have been classified in [RFC8199] and [RFC8309]. 114 Framework for Abstraction and Control of Traffic Engineered Networks 115 (ACTN) [RFC8453] introduces an architecture to support virtual 116 network services and connectivity services. 117 [I-D.ietf-teas-actn-vn-yang] defines a YANG model and describes how 118 customers or end-to-end orchestrator can request and/or instantiate a 119 generic virtual network service. [I-D.ietf-teas-actn-yang] describes 120 the way IETF YANG models of different classifications can be applied 121 to the ACTN interfaces. In particular, it describes how customer 122 service models can be mapped into the CNC-MDSC Interface (CMI) of the 123 ACTN architecture. 125 The models presented in this document are also applicable in generic 126 context [RFC8309] as part of Customer Service Model used between 127 Service Orchestrator and Customer. 129 [RFC8299] provides a L3VPN service delivery YANG model for PE-based 130 VPNs. The scope of that draft is limited to a set of domains under 131 control of the same network operator to deliver services requiring TE 132 tunnels. 134 [RFC8466] provides a L2VPN 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 [I-D.ietf-ccamp-l1csm-yang] provides a L1 connectivity service 140 delivery YANG model for PE-based VPNs. The scope of that draft is 141 limited to a set of domains under control of the same network 142 operator to deliver services requiring TE tunnels. 144 While the IP/MPLS Provisioning Network Controller (PNC) is 145 responsible for provisioning the VPN service on the Provider Edge 146 (PE) nodes, the Multi-Domain Service Coordinator (MDSC) can 147 coordinate how to map the VPN services onto Traffic Engineering (TE) 148 tunnels. This is consistent with the two of the core functions of 149 the MDSC specified in [RFC8453]: 151 o Customer mapping/translation function: This function is to map 152 customer requests/commands into network provisioning requests that 153 can be sent to the PNC according to the business policies that 154 have been provisioned statically or dynamically. Specifically, it 155 provides mapping and translation of a customer's service request 156 into a set of parameters that are specific to a network type and 157 technology such that the network configuration process is made 158 possible. 160 o Virtual service coordination function: This function translates 161 customer service-related information into virtual network service 162 operations in order to seamlessly operate virtual networks while 163 meeting a customer's service requirements. In the context of 164 ACTN, service/virtual service coordination includes a number of 165 service orchestration functions such as multi-destination load 166 balancing, guarantees of service quality, bandwidth and 167 throughput. It also includes notifications for service fault and 168 performance degradation and so forth. 170 Section 2 describes a set of TE and service related parameters that 171 this document addresses as "new and advanced parameters" that are not 172 included in generic service models. Section 3 discusses YANG 173 modelling approach. 175 Apart from the service model, the TE mapping is equally applicable to 176 the Network Models (L3 VPN Service Network Model (L3NM) 177 [I-D.ietf-opsawg-l3sm-l3nm], L2 VPN Service Network Model (L2NM) 178 [I-D.barguil-opsawg-l2sm-l2nm] etc.). See Section 3.2 for details. 180 1.1. Terminology 182 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 183 in this document. 185 The terminology for describing YANG data models is found in 186 [RFC7950]. 188 1.2. Tree diagram 190 A simplified graphical representation of the data model is used in 191 Section 5 of this this document. The meaning of the symbols in these 192 diagrams is defined in [RFC8340]. 194 1.3. Prefixes in Data Node Names 196 In this document, names of data nodes and other data model objects 197 are prefixed using the standard prefix associated with the 198 corresponding YANG imported modules, as shown in Table 1. 200 +---------+----------------------------+----------------------------+ 201 | Prefix | YANG module | Reference | 202 +---------+----------------------------+----------------------------+ 203 | tsm- | ietf-te-service-mapping- | [RFCXXXX] | 204 | types | types | | 205 | l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang | 206 | | | ] | 207 | l2vpn- | ietf-l2vpn-svc | [RFC8466] | 208 | svc | | | 209 | l3vpn- | ietf-l3vpn-svc | [RFC8299] | 210 | svc | | | 211 | l1-tsm | ietf-l1csm-te-service- | [RFCXXXX] | 212 | | mapping | | 213 | l2-tsm | ietf-l2sm-te-service- | [RFCXXXX] | 214 | | mapping | | 215 | l3-tsm | ietf-l3sm-te-service- | [RFCXXXX] | 216 | | mapping | | 217 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yan | 218 | | | g] | 219 | nw | ietf-network | [RFC8345] | 220 | te- | ietf-te-types | [I-D.ietf-teas-yang-te-typ | 221 | types | | es] | 222 | te | ietf-te | [I-D.ietf-teas-yang-te] | 223 | l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang | 224 | | | ] | 225 | l2vpn- | ietf-l2vpn-ntw | [I-D.barguil-opsawg-l2sm-l | 226 | ntw | | 2nm] | 227 | l3vpn- | ietf-l3vpn-ntw | [I-D.ietf-opsawg-l3sm-l3nm | 228 | ntw | | ] | 229 +---------+----------------------------+----------------------------+ 231 Table 1: Prefixes and corresponding YANG modules 233 Note: The RFC Editor should replace XXXX with the number assigned to 234 the RFC once this draft becomes an RFC. 236 2. TE and Service Related Parameters 238 While L1/L2/L3 service models (L1CSM, L2SM, L3SM) are intended to 239 provide service-specific parameters for VPN service instances, there 240 are a number of TE Service related parameters that are not included 241 in these service models. 243 Additional 'service parameters and policies' that are not included in 244 the aforementioned service models are addressed in the YANG models 245 defined in this document. 247 2.1. VN/Tunnel Selection Requirements 249 In some cases, the service requirements may need addition TE tunnels 250 to be established. This may occur when there are no suitable 251 existing TE tunnels that can support the service requirements, or 252 when the operator would like to dynamically create and bind tunnels 253 to the VPN such that they are not shared by other VPNs, for example, 254 for network slicing. The establishment of TE tunnels is subject to 255 the network operator's policies. 257 To summarize, there are three modes of VN/Tunnel selection operations 258 to be supported as follows. Additional modes may be defined in the 259 future. 261 o New VN/Tunnel Binding - A customer could request a VPN service 262 based on VN/Tunnels that are not shared with other existing or 263 future services. This might be to meet VPN isolation 264 requirements. Further, the YANG model described in Section 5 of 265 this document can be used to describe the mapping between the VPN 266 service and the ACTN VN. The VN (and TE tunnels) could be bound 267 to the VPN and not used for any other VPN. Under this mode, the 268 following sub-categories can be supported: 270 1. Hard Isolation with deterministic characteristics: A customer 271 could request a VPN service using a set of TE Tunnels with 272 deterministic characteristics requirements (e.g., no latency 273 variation) and where that set of TE Tunnels must not be shared 274 with other VPN services and must not compete for bandwidth or 275 other network resources with other TE Tunnels. 277 2. Hard Isolation: This is similar to the above case but without 278 the deterministic characteristics requirements. 280 3. Soft Isolation: The customer requests a VPN service using a 281 set of TE tunnels which can be shared with other VPN services. 283 o VN/Tunnel Sharing - A customer could request a VPN service where 284 new tunnels (or a VN) do not need to be created for each VPN and 285 can be shared across multiple VPNs. Further, the mapping YANG 286 model described in Section 5 of this document can be used to 287 describe the mapping between the VPN service and the tunnels in 288 use. No modification of the properties of a tunnel (or VN) is 289 allowed in this mode: an existing tunnel can only be selected. 291 o VN/Tunnel Modify - This mode allows the modification of the 292 properties of the existing VN/tunnel (e.g., bandwidth). 294 2.2. Availability Requirement 296 Availability is another service requirement or intent that may 297 influence the selection or provisioning of TE tunnels or a VN to 298 support the requested service. Availability is a probabilistic 299 measure of the length of time that a VPN/VN instance functions 300 without a network failure. 302 The availability level will need to be translated into network 303 specific policies such as the protection/reroute policy associated 304 with a VN or Tunnel. The means by which this is achieved is not in 305 the scope of this document. 307 3. YANG Modeling Approach 309 This section provides how the TE and Service mapping parameters are 310 supported using augmentation of the existing service models (i.e., 311 [I-D.ietf-ccamp-l1csm-yang], [RFC8466], and [RFC8299]). Figure 1 312 shows the scope of the Augmented LxSM Model. 314 +--------------+ +----------------------+ +----------+ 315 | LxSM |o-------| | . . . . | ACTN VN | 316 +--------------+ augment| | +----------+ 317 | | +----------+ 318 +--------------+ | Augmented LxSM Model | . . . . | TE-topo | 319 | TE & Service |------->| | +----------+ 320 | Mapping Types| import | | +----------+ 321 +--------------+ | | . . . . | TE-tunnel| 322 +----------------------+ +----------+ 323 reference 325 Figure 1: Augmented LxSM Model 327 The Augmented LxSM model (where x=1,2,3) augments the basic LxSM 328 model while importing the common TE and Service related parameters 329 (defined in Section 2) grouping information from TE and Service 330 Mapping Types. The TE and Service Mapping Types (ietf-te-service- 331 mapping-types) module is the repository of all common groupings 332 imported by each augmented LxSM model. Any future service models 333 would import this mapping-type common model. 335 The role of the augmented LxSm service model is to expose the mapping 336 relationship between service models and TE models so that VN/VPN 337 service instantiations provided by the underlying TE networks can be 338 viewed outside of the MDSC, for example by an operator who is 339 diagnosing the behaviour of the network. It also allows for the 340 customers to access operational state information about how their 341 services are instantiated with the underlying VN, TE topology or TE 342 tunnels provided that the MDSC operator is willing to share that 343 information. This mapping will facilitate a seamless service 344 management operation with underlay-TE network visibility. 346 As seen in Figure 1, the augmented LxSM service model records a 347 mapping between the customer service models and the ACTN VN YANG 348 model. Thus, when the MDSC receives a service request it creates a 349 VN that meets the customer's service objectives with various 350 constraints via TE-topology model [I-D.ietf-teas-yang-te-topo], and 351 this relationship is recorded by the Augmented LxSM Model. The model 352 also supports a mapping between a service model and TE-topology or a 353 TE-tunnel. 355 The YANG models defined in this document conforms to the Network 356 Management Datastore Architecture (NMDA) [RFC8342]. 358 3.1. Forward Compatibility 360 The YANG module defined in this document supports three existing 361 service models via augmenting while sharing the common TE and Service 362 Mapping Types. 364 It is possible that new service models will be defined at some future 365 time and that it will be desirable to map them to underlying TE 366 constructs in the same way as the three existing models are 367 augmented. 369 3.2. TE and Network Models 371 The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN 372 Service in the Service Provider Network. It containts information of 373 the Service Provider network and might include allocated resources. 374 It can be used by network controllers to manage and control the VPN 375 Service configuration in the Service Provider network. 377 Similar to service model, the existing network models (i.e., 378 [I-D.ietf-opsawg-l3sm-l3nm], and [I-D.barguil-opsawg-l2sm-l2nm]) are 379 augmented to include the TE and Service mapping parameters. Figure 2 380 shows the scope of the Augmented LxNM Model. 382 +--------------+ +----------------------+ +----------+ 383 | LxNM |o-------| | . . . . | ACTN VN | 384 +--------------+ augment| | +----------+ 385 | | +----------+ 386 +--------------+ | Augmented LxNM Model | . . . . | TE-topo | 387 | TE & Service |------->| | +----------+ 388 | Mapping Types| import | | +----------+ 389 +--------------+ | | . . . . | TE-tunnel| 390 +----------------------+ +----------+ 391 reference 393 Figure 2: Augmented LxNM Model 395 The Augmented LxNM model (where x=2,3) augments the basic LxNM model 396 while importing the common TE mapping related parameters (defined in 397 Section 2) grouping information from TE and Service Mapping Types. 398 The role of the augmented LxNM network model is to expose the mapping 399 relationship between network models and TE models. 401 4. L3VPN Architecture in the ACTN Context 403 Figure 3 shows the architectural context of this document referencing 404 the ACTN components and interfaces. 406 +----------------------------+ 407 | Customer Service Manager | 408 | +-----------------------+ | 409 | | CNC + | 410 | +-+-------------------+-+ | 411 +----|-------------------|---+ 412 | | 413 |CMI(Augmented L3SM)|CMI(VN) 414 | | 415 +----------------|-------------------|----+ 416 | +--------------|-----------------+ | | 417 | | MDSC | | | | 418 | | | | | | 419 | | +-----------+--------------+ | | | 420 TE-Svc-Map<------+ Service Mapping Function | | | | 421 | | +-----------+--------------+ | | | 422 | | | | | | 423 | +-------+------|-----------------+ | | 424 | | | | | 425 | | |CMI(VN) | | 426 | | | | | 427 | | +--|-------------------|--+ | 428 | | | | MDSC | | | 429 | | | ++-------------------++ | | 430 | | | + Service Mapping +---->TE-Svc-Map 431 | | | ++----------+---------+ | | 432 | | +--|----------|-----------+ | 433 +---------|------|----------|-------------+ 434 | | | 435 | +----+--------+ | 436 | | | | 437 MPI(VPN / TE models)| | | |MPI(TE / L1 models) 438 | | | | 439 +-----|-|---+ +-----|-|----+ 440 IP/MPLS | +--+-+-+ | | +--+-+-+ | Optical Domain 441 Domain | | PNC1 | | | | PNC2 | | Controller 442 Controller | +--+---+ | | +--+---+ | 443 +-----|-----+ +-----|------+ 444 | | 445 V | SBI 446 +---------------------+ | 447 / IP/MPLS Network \ | 448 +-------------------------+ | 449 V 450 +---------------------+ 451 / Optical Network \ 452 +-------------------------+ 454 Figure 3: L3VPN Architecture from the IP+Optical Network Perspective 456 There are three main entities in the ACTN architecture and shown in 457 Figure 3. 459 o CNC: The Customer Network Controller is responsible for generating 460 service requests. In the context of an L3VPN, the CNC uses the 461 Augmented L3SM to express the service request and communicate it 462 to the network operator. 464 o MDSC: This entity is responsible for coordinating a L3VPN service 465 request (expressed via the Augmented L3SM) with the IP/MPLS PNC 466 and the Transport PNC. For TE services, one of the key 467 responsibilities of the MDSC is to coordinate with both the IP PNC 468 and the Transport PNC for the mapping of the Augmented L3VPN 469 Service Model to the ACTN VN model. In the VN/TE-tunnel binding 470 case, the MDSC will need to coordinate with the Transport PNC to 471 dynamically create the TE-tunnels in the transport network as 472 needed. These tunnels are added as links in the IP/MPLS Layer 473 topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 474 tunnels in the IP/MPLS layer, as part of the ACTN VN creation. 476 o PNC: The Provisioning Network Controller is responsible for 477 configuring and operating the network devices. Figure 2 shows two 478 distinct PNCs. 480 * IP/MPLS PNC (PNC1): This entity is responsible for device 481 configuration to create PE-PE L3VPN tunnels for the VPN 482 customer and for the configuration of the L3VPN VRF on the PE 483 nodes. Each network element would select a tunnel based on the 484 configuration. 486 * Transport PNC (PNC2): This entity is responsible for device 487 configuration for TE tunnels in the transport networks. 489 There are four main interfaces shown in Figure 2. 491 o CMI: The CNC-MDSC Interface is used to communicate service 492 requests from the customer to the operator. The requests may be 493 expressed as Augmented VPN service requests (L2SM, L3SM), as 494 connectivity requests (L1CSM), or as virtual network requests 495 (ACTN VN). 497 o MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate 498 networks under the control of PNCs. The requests on this 499 interface may use TE tunnel models, TE topology models, VPN 500 network configuration models or layer one connectivity models. 502 o SBI: The Southbound Interface is used by the PNC to control 503 network devices and is out of scope for this document. 505 The TE Service Mapping Model as described in this document can be 506 used to see the mapping between service models and VN models and TE 507 Tunnel/Topology models. That mapping may occur in the CNC if a 508 service request is mapped to a VN request. Or it may occur in the 509 MDSC where a service request is mapped to a TE tunnel, TE topology, 510 or VPN network configuration model. The TE Service Mapping Model may 511 be read from the CNC or MDSC to understand how the mapping has been 512 made and to see the purpose for which network resources are used. 514 As shown in Figure 2, the MDSC may be used recursively. For example, 515 the CNC might map a L3SM request to a VN request that it sends to a 516 recursive MDSC. 518 The high-level control flows for one example are as follows: 520 1. A customer asks for an L3VPN between CE1 and CE2 using the 521 Augmented L3SM model. 523 2. The MDSC considers the service request and local policy to 524 determine if it needs to create a new VN or any TE Topology, and 525 if that is the case, ACTN VN YANG [I-D.ietf-teas-actn-vn-yang] is 526 used to configure a new VN based on this VPN and map the VPN 527 service to the ACTN VN. In case an existing tunnel is to be 528 used, each device will select which tunnel to use and populate 529 this mapping information. 531 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 532 PNC to create a PE-PE tunnel in the IP network mapped to a TE 533 tunnel in the transport network by providing the inter-layer 534 access points and tunnel requirements. The specific service 535 information is passed to the IP/MPLS PNC for the actual VPN 536 configuration and activation. 538 A. The Transport PNC creates the corresponding TE tunnel 539 matching with the access point and egress point. 540 B. The IP/MPLS PNC maps the VPN ID with the corresponding TE 541 tunnel ID to bind these two IDs. 543 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 544 customer. This is not in the scope of this document. 546 4.1. Service Mapping 548 Augmented L3SM and L2SM can be used to request VPN service creation 549 including the creation of sites and corresponding site network access 550 connection between CE and PE. A VPN-ID is used to identify each VPN 551 service ordered by the customer. The ACTN VN can be used further to 552 establish PE-to-PE connectivity between VPN sites belonging to the 553 same VPN service. A VN-ID is used to identify each virtual network 554 established between VPN sites. 556 Once the ACTN VN has been established over the TE network (maybe a 557 new VN, maybe modification of an existing VN, or maybe the use of an 558 unmodified existing VN), the mapping between the VPN service and the 559 ACTN VN service can be created. 561 4.2. Site Mapping 563 The elements in Augmented L3SM and L2SM define site location 564 parameters and constraints such as distance and access diversity that 565 can influence the placement of network attachment points (i.e, 566 virtual network access points (VNAP)). To achieve this, a central 567 directory can be set up to establish the mapping between location 568 parameters and constraints and network attachment point location. 569 Suppose multiple attachment points are matched, the management system 570 can use constraints or other local policy to select the best 571 candidate network attachment points. 573 After a network attachment point is selected, the mapping between VPN 574 site and VNAP can be established as shown in Table 1. 576 +-------+---------+------------------+------------------------+-----+ 577 | Site | Site | Location | Access Diversity | PE | 578 | | Network | (Address, Postal | (Constraint-Type, | | 579 | | Access | Code, State, | Group-id,Target Group- | | 580 | | | City,Country | id) | | 581 | | | Code) | | | 582 +-------+---------+------------------+------------------------+-----+ 583 | SITE1 | ACCESS1 | (,,US,NewYork,) | (10,PE-Diverse,10) | PE1 | 584 +-------+---------+------------------+------------------------+-----+ 585 | SITE2 | ACCESS2 | (,,CN,Beijing,) | (10,PE-Diverse,10) | PE2 | 586 +-------+---------+------------------+------------------------+-----+ 587 | SITE3 | ACCESS3 | (,,UK,London, ) | (12,same-PE,12) | PE4 | 588 +-------+---------+------------------+------------------------+-----+ 589 | SITE4 | ACCESS4 | (,,FR,Paris,) | (20,Bearer-Diverse,20) | PE7 | 590 +-------+---------+------------------+------------------------+-----+ 592 Table 2: : Mapping Between VPN Site and VNAP 594 5. Applicability of TE-Service Mapping in Generic context 596 As discussed in the Introduction Section, the models presented in 597 this document are also applicable generically outside of the ACTN 598 architecture. [RFC8309] defines Customer Service Model between 599 Customer and Service Orchestrator and Service Delivery Model between 600 Service Orchestrator and Network Orchestrator(s). TE-Service mapping 601 models defined in this document can be regarded primarily as Customer 602 Service Model and secondarily as Service Deliver Model. 604 6. YANG Data Trees 606 6.1. Service Models 608 6.1.1. L3SM 609 module: ietf-l3sm-te-service-mapping 610 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services 611 /l3vpn-svc:vpn-service: 612 +--rw te-service-mapping! 613 +--rw te-mapping 614 +--rw map-type? identityref 615 +--rw availability-type? identityref 616 +--rw (te)? 617 +--:(vn) 618 | +--rw vn-ref? -> /vn:vn/vn-list/vn-id 619 +--:(te-topo) 620 | +--rw vn-topology-id? te-types:te-topology-id 621 | +--rw abstract-node? 622 | -> /nw:networks/network/node/node-id 623 +--:(te-tunnel) 624 +--rw te-tunnel-list* te:tunnel-ref 625 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 626 /l3vpn-svc:site-network-accesses 627 /l3vpn-svc:site-network-access: 628 +--rw (te)? 629 +--:(vn) 630 | +--rw vn-ref? 631 | -> /vn:ap/access-point-list/access-point-id 632 +--:(te) 633 +--rw ltp? te-types:te-tp-id 635 6.1.2. L2SM 636 module: ietf-l2sm-te-service-mapping 637 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services 638 /l2vpn-svc:vpn-service: 639 +--rw te-service-mapping! 640 +--rw te-mapping 641 +--rw map-type? identityref 642 +--rw availability-type? identityref 643 +--rw (te)? 644 +--:(vn) 645 | +--rw vn-ref? -> /vn:vn/vn-list/vn-id 646 +--:(te-topo) 647 | +--rw vn-topology-id? te-types:te-topology-id 648 | +--rw abstract-node? 649 | -> /nw:networks/network/node/node-id 650 +--:(te-tunnel) 651 +--rw te-tunnel-list* te:tunnel-ref 652 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 653 /l2vpn-svc:site-network-accesses 654 /l2vpn-svc:site-network-access: 655 +--rw (te)? 656 +--:(vn) 657 | +--rw vn-ref? 658 | -> /vn:ap/access-point-list/access-point-id 659 +--:(te) 660 +--rw ltp? te-types:te-tp-id 662 6.1.3. L1CSM 663 module: ietf-l1csm-te-service-mapping 664 augment /l1csm:l1-connectivity/l1csm:services/l1csm:service: 665 +--rw te-service-mapping! 666 +--rw te-mapping 667 +--rw map-type? identityref 668 +--rw availability-type? identityref 669 +--rw (te)? 670 +--:(vn) 671 | +--rw vn-ref? -> /vn:vn/vn-list/vn-id 672 +--:(te-topo) 673 | +--rw vn-topology-id? te-types:te-topology-id 674 | +--rw abstract-node? 675 | -> /nw:networks/network/node/node-id 676 +--:(te-tunnel) 677 +--rw te-tunnel-list* te:tunnel-ref 678 augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni: 679 +--rw (te)? 680 +--:(vn) 681 | +--rw vn-ref? 682 | -> /vn:ap/access-point-list/access-point-id 683 +--:(te) 684 +--rw ltp? te-types:te-tp-id 686 6.2. Network Models 688 6.2.1. L3NM 689 module: ietf-l3nm-te-service-mapping 690 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 691 /l3vpn-ntw:vpn-service: 692 +--rw te-service-mapping! 693 +--rw te-mapping 694 +--rw map-type? identityref 695 +--rw availability-type? identityref 696 +--rw (te)? 697 +--:(vn) 698 | +--rw vn-ref? -> /vn:vn/vn-list/vn-id 699 +--:(te-topo) 700 | +--rw vn-topology-id? te-types:te-topology-id 701 | +--rw abstract-node? 702 | -> /nw:networks/network/node/node-id 703 +--:(te-tunnel) 704 +--rw te-tunnel-list* te:tunnel-ref 705 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 706 /l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes 707 /l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses 708 /l3vpn-ntw:vpn-network-access: 709 +--rw (te)? 710 +--:(vn) 711 | +--rw vn-ref? 712 | -> /vn:ap/access-point-list/access-point-id 713 +--:(te) 714 +--rw ltp? te-types:te-tp-id 716 6.2.2. L2NM 717 module: ietf-l2nm-te-service-mapping 718 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 719 /l2vpn-ntw:vpn-svc: 720 +--rw te-service-mapping! 721 +--rw te-mapping 722 +--rw map-type? identityref 723 +--rw availability-type? identityref 724 +--rw (te)? 725 +--:(vn) 726 | +--rw vn-ref? -> /vn:vn/vn-list/vn-id 727 +--:(te-topo) 728 | +--rw vn-topology-id? te-types:te-topology-id 729 | +--rw abstract-node? 730 | -> /nw:networks/network/node/node-id 731 +--:(te-tunnel) 732 +--rw te-tunnel-list* te:tunnel-ref 733 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 734 /l2vpn-ntw:vpn-svc/l2vpn-ntw:vpn-nodes 735 /l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses 736 /l2vpn-ntw:vpn-network-access: 737 +--rw (te)? 738 +--:(vn) 739 | +--rw vn-ref? 740 | -> /vn:ap/access-point-list/access-point-id 741 +--:(te) 742 +--rw ltp? te-types:te-tp-id 744 7. YANG Data Models 746 The YANG codes are as follows: 748 7.1. ietf-te-service-mapping-types 750 file "ietf-te-service-mapping-types@2020-03-08.yang" 751 module ietf-te-service-mapping-types { 752 yang-version 1.1; 753 namespace 754 "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; 755 prefix tsm; 757 import ietf-te-types { 758 prefix te-types; 759 reference 760 "I-D.ietf-teas-yang-te-types: Traffic Engineering Common YANG 761 Types"; 762 } 763 import ietf-network { 764 prefix nw; 765 reference 766 "RFC 8345: A YANG Data Model for Network Topologies"; 767 } 768 import ietf-te { 769 prefix te; 770 reference 771 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 772 Engineering Tunnels and Interfaces"; 773 } 774 import ietf-vn { 775 prefix vn; 776 reference 777 "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation"; 778 } 780 organization 781 "IETF Traffic Engineering Architecture and Signaling (TEAS) 782 Working Group"; 783 contact 784 "WG Web: 785 WG List: 787 Editor: Young Lee 788 789 Editor: Dhruv Dhody 790 791 Editor: Qin Wu 792 "; 793 description 794 "This module contains a YANG module for TE & Service mapping 795 parameters and policies as a common grouping applicable to 796 variuous service models (e.g., L1CSM, L2SM, L3SM, etc.) 798 Copyright (c) 2020 IETF Trust and the persons identified as 799 authors of the code. All rights reserved. 801 Redistribution and use in source and binary forms, with or 802 without modification, is permitted pursuant to, and subject to 803 the license terms contained in, the Simplified BSD License set 804 forth in Section 4.c of the IETF Trust's Legal Provisions 805 Relating to IETF Documents 806 (https://trustee.ietf.org/license-info). 808 This version of this YANG module is part of RFC XXXX; see the 809 RFC itself for full legal notices. 811 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 812 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 813 'MAY', and 'OPTIONAL' in this document are to be interpreted as 814 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 815 they appear in all capitals, as shown here."; 817 revision 2020-03-08 { 818 description 819 "Initial revision."; 820 reference 821 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 822 } 824 /* 825 * Identity for map-type 826 */ 828 identity map-type { 829 description 830 "Base identity from which specific map types are derived."; 831 } 833 identity new { 834 base map-type; 835 description 836 "The new VN/tunnels are binded to the service."; 837 } 839 identity hard-isolation { 840 base new; 841 description 842 "Hard isolation."; 843 } 845 identity detnet-hard-isolation { 846 base hard-isolation; 847 description 848 "Hard isolation with deterministic characteristics."; 849 } 851 identity soft-isolation { 852 base new; 853 description 854 "Soft-isolation."; 855 } 857 identity select { 858 base map-type; 859 description 860 "The VPN service selects an existing tunnel with no 861 modification."; 862 } 864 identity modify { 865 base map-type; 866 description 867 "The VPN service selects an existing tunnel and allows to modify 868 the properties of the tunnel (e.g., b/w)"; 869 } 871 /* 872 * Identity for availability-type 873 */ 875 identity availability-type { 876 description 877 "Base identity from which specific map types are derived."; 878 } 880 identity level-1 { 881 base availability-type; 882 description 883 "level 1: 99.9999%"; 884 } 886 identity level-2 { 887 base availability-type; 888 description 889 "level 2: 99.999%"; 890 } 892 identity level-3 { 893 base availability-type; 894 description 895 "level 3: 99.99%"; 896 } 898 identity level-4 { 899 base availability-type; 900 description 901 "level 4: 99.9%"; 902 } 904 identity level-5 { 905 base availability-type; 906 description 907 "level 5: 99%"; 908 } 910 /* 911 * Groupings 912 */ 914 grouping te-ref { 915 description 916 "The reference to TE."; 917 choice te { 918 description 919 "The TE"; 920 case vn { 921 leaf vn-ref { 922 type leafref { 923 path "/vn:vn/vn:vn-list/vn:vn-id"; 924 } 925 description 926 "The reference to VN"; 927 reference 928 "RFC 8453: Framework for Abstraction and Control of TE 929 Networks (ACTN)"; 930 } 931 } 932 case te-topo { 933 leaf vn-topology-id { 934 type te-types:te-topology-id; 935 description 936 "An identifier to the TE Topology Model where the abstract 937 nodes and links of the Topology can be found for Type 2 938 VNS"; 939 reference 940 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 941 Engineering (TE) Topologies"; 942 } 943 leaf abstract-node { 944 type leafref { 945 path "/nw:networks/nw:network/nw:node/nw:node-id"; 946 } 947 description 948 "A reference to the abstract node in TE Topology"; 949 reference 950 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 951 Engineering (TE) Topologies"; 952 } 953 } 954 case te-tunnel { 955 leaf-list te-tunnel-list { 956 type te:tunnel-ref; 957 description 958 "Reference to TE Tunnels"; 959 reference 960 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 961 Engineering Tunnels and Interfaces"; 962 } 963 } 964 } 965 } 967 //grouping 969 grouping te-endpoint-ref { 970 description 971 "The reference to TE endpoints."; 972 choice te { 973 description 974 "The TE"; 975 case vn { 976 leaf vn-ref { 977 type leafref { 978 path "/vn:ap/vn:access-point-list/vn:access-point-id"; 979 } 980 description 981 "The reference to VN AP"; 982 reference 983 "RFC 8453: Framework for Abstraction and Control of TE 984 Networks (ACTN)"; 985 } 986 } 987 case te { 988 leaf ltp { 989 type te-types:te-tp-id; 990 description 991 "Reference LTP in the TE-topology"; 992 reference 993 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 994 Engineering (TE) Topologies"; 995 } 996 } 997 } 998 } 1000 //grouping 1002 grouping te-mapping { 1003 description 1004 "Mapping between Services and TE"; 1005 container te-mapping { 1006 description 1007 "Mapping between Services and TE"; 1008 leaf map-type { 1009 type identityref { 1010 base map-type; 1011 } 1012 description 1013 "Isolation Requirements, Tunnel Bind or 1014 Tunnel Selection"; 1015 } 1016 leaf availability-type { 1017 type identityref { 1018 base availability-type; 1019 } 1020 description 1021 "Availability Requirement for the Service"; 1022 } 1023 uses te-ref; 1024 } 1025 } 1027 //grouping 1028 } 1030 1032 7.2. Service Models 1034 7.2.1. ietf-l3sm-te-service-mapping 1036 file "ietf-l3sm-te-service-mapping@2020-03-08.yang" 1037 module ietf-l3sm-te-service-mapping { 1038 yang-version 1.1; 1039 namespace 1040 "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; 1041 prefix l3-tsm; 1043 import ietf-te-service-mapping-types { 1044 prefix tsm-types; 1045 reference 1046 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1047 } 1048 import ietf-l3vpn-svc { 1049 prefix l3vpn-svc; 1050 reference 1051 "RFC 8299: YANG Data Model for L3VPN Service Delivery"; 1052 } 1054 organization 1055 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1056 Working Group"; 1057 contact 1058 "WG Web: 1059 WG List: 1061 Editor: Young Lee 1062 1063 Editor: Dhruv Dhody 1064 1065 Editor: Qin Wu 1066 "; 1067 description 1068 "This module contains a YANG module for the mapping of Layer 3 1069 Service Model (L3SM) to the TE and VN. 1071 Copyright (c) 2020 IETF Trust and the persons identified as 1072 authors of the code. All rights reserved. 1074 Redistribution and use in source and binary forms, with or 1075 without modification, is permitted pursuant to, and subject to 1076 the license terms contained in, the Simplified BSD License set 1077 forth in Section 4.c of the IETF Trust's Legal Provisions 1078 Relating to IETF Documents 1079 (https://trustee.ietf.org/license-info). 1081 This version of this YANG module is part of RFC XXXX; see the 1082 RFC itself for full legal notices. 1084 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1085 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1086 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1087 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1088 they appear in all capitals, as shown here."; 1090 revision 2020-03-08 { 1091 description 1092 "Initial revision."; 1093 reference 1094 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1095 } 1097 /* 1098 * Augmentation to L3SM 1099 */ 1101 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services" 1102 + "/l3vpn-svc:vpn-service" { 1103 description 1104 "L3SM augmented to include TE parameters and mapping"; 1105 container te-service-mapping { 1106 presence "Indicates L3 service to TE mapping"; 1107 description 1108 "Container to augment l3sm to TE parameters and mapping"; 1109 uses tsm-types:te-mapping; 1110 } 1111 } 1113 //augment 1115 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1116 + "/l3vpn-svc:site-network-accesses" 1117 + "/l3vpn-svc:site-network-access" { 1118 description 1119 "This augment is only valid for TE mapping of L3SM network-access 1120 to TE endpoints"; 1121 uses tsm-types:te-endpoint-ref; 1122 } 1124 //augment 1125 } 1127 1129 7.2.2. ietf-l2sm-te-service-mapping 1131 file "ietf-l2sm-te-service-mapping@2020-03-08.yang" 1132 module ietf-l2sm-te-service-mapping { 1133 yang-version 1.1; 1134 namespace 1135 "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; 1136 prefix l2-tsm; 1138 import ietf-te-service-mapping-types { 1139 prefix tsm-types; 1140 reference 1141 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1142 } 1143 import ietf-l2vpn-svc { 1144 prefix l2vpn-svc; 1145 reference 1146 "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network 1147 (L2VPN) Service Delivery"; 1148 } 1150 organization 1151 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1152 Working Group"; 1153 contact 1154 "WG Web: 1155 WG List: 1157 Editor: Young Lee 1158 1159 Editor: Dhruv Dhody 1160 1161 Editor: Qin Wu 1162 "; 1163 description 1164 "This module contains a YANG module for the mapping of Layer 2 1165 Service Model (L2SM) to the TE and VN. 1167 Copyright (c) 2020 IETF Trust and the persons identified as 1168 authors of the code. All rights reserved. 1170 Redistribution and use in source and binary forms, with or 1171 without modification, is permitted pursuant to, and subject to 1172 the license terms contained in, the Simplified BSD License set 1173 forth in Section 4.c of the IETF Trust's Legal Provisions 1174 Relating to IETF Documents 1175 (https://trustee.ietf.org/license-info). 1177 This version of this YANG module is part of RFC XXXX; see the 1178 RFC itself for full legal notices. 1180 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1181 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1182 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1183 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1184 they appear in all capitals, as shown here."; 1186 revision 2020-03-08 { 1187 description 1188 "Initial revision."; 1189 reference 1190 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1191 } 1193 /* 1194 * Augmentation to L3SM 1195 */ 1197 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/" 1198 + "l2vpn-svc:vpn-service" { 1199 description 1200 "L2SM augmented to include TE parameters and mapping"; 1201 container te-service-mapping { 1202 presence "indicates L2 service to te mapping"; 1203 description 1204 "Container to augment L2SM to TE parameters and mapping"; 1205 uses tsm-types:te-mapping; 1206 } 1207 } 1209 //augment 1211 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1212 + "/l2vpn-svc:site-network-accesses" 1213 + "/l2vpn-svc:site-network-access" { 1214 description 1215 "This augment is only valid for TE mapping of L2SM network-access 1216 to TE endpoints"; 1217 uses tsm-types:te-endpoint-ref; 1218 } 1220 //augment 1221 } 1223 1225 7.2.3. ietf-l1csm-te-service-mapping 1227 file "ietf-l1csm-te-service-mapping@2020-03-08.yang" 1228 module ietf-l1csm-te-service-mapping { 1229 yang-version 1.1; 1230 namespace 1231 "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; 1232 prefix l1-tsm; 1234 import ietf-te-service-mapping-types { 1235 prefix tsm-types; 1236 reference 1237 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1238 } 1239 import ietf-l1csm { 1240 prefix l1csm; 1241 reference 1242 "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity 1243 Service Model (L1CSM)"; 1244 } 1246 organization 1247 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1248 Working Group"; 1249 contact 1250 "WG Web: 1251 WG List: 1253 Editor: Young Lee 1254 1255 Editor: Dhruv Dhody 1256 1257 Editor: Qin Wu 1258 "; 1259 description 1260 "This module contains a YANG module for the mapping of 1261 Layer 1 Connectivity Service Module (L1CSM) to the TE and VN 1263 Copyright (c) 2020 IETF Trust and the persons identified as 1264 authors of the code. All rights reserved. 1266 Redistribution and use in source and binary forms, with or 1267 without modification, is permitted pursuant to, and subject to 1268 the license terms contained in, the Simplified BSD License set 1269 forth in Section 4.c of the IETF Trust's Legal Provisions 1270 Relating to IETF Documents 1271 (https://trustee.ietf.org/license-info). 1273 This version of this YANG module is part of RFC XXXX; see the 1274 RFC itself for full legal notices. 1276 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1277 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1278 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1279 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1280 they appear in all capitals, as shown here."; 1282 revision 2020-03-08 { 1283 description 1284 "Initial revision."; 1285 reference 1286 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1287 } 1289 /* 1290 * Augmentation to L1CSM 1291 */ 1293 augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" { 1294 description 1295 "L1CSM augmented to include TE parameters and mapping"; 1296 container te-service-mapping { 1297 presence "Indicates L1 service to TE mapping"; 1298 description 1299 "Container to augment L1CSM to TE parameters and mapping"; 1300 uses tsm-types:te-mapping; 1301 } 1302 } 1304 //augment 1306 augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/" 1307 + "l1csm:uni" { 1308 description 1309 "This augment is only valid for TE mapping of L1CSM UNI to TE 1310 endpoints"; 1311 uses tsm-types:te-endpoint-ref; 1312 } 1314 //augment 1315 } 1317 1319 7.3. Network Models 1321 7.3.1. ietf-l3nm-te-service-mapping 1323 file "ietf-l3nm-te-service-mapping@2020-03-08.yang" 1324 module ietf-l3nm-te-service-mapping { 1325 yang-version 1.1; 1326 namespace 1327 "urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping"; 1328 prefix l3nm-tsm; 1330 import ietf-te-service-mapping-types { 1331 prefix tsm-types; 1332 reference 1333 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1334 } 1335 import ietf-l3vpn-ntw { 1336 prefix l3vpn-ntw; 1337 reference 1338 "I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model"; 1340 } 1342 organization 1343 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1344 Working Group"; 1345 contact 1346 "WG Web: 1347 WG List: 1349 Editor: Young Lee 1350 1351 Editor: Dhruv Dhody 1352 1353 Editor: Qin Wu 1354 "; 1355 description 1356 "This module contains a YANG module for the mapping of Layer 3 1357 Network Model (L3NM) to the TE and VN. 1359 Copyright (c) 2020 IETF Trust and the persons identified as 1360 authors of the code. All rights reserved. 1362 Redistribution and use in source and binary forms, with or 1363 without modification, is permitted pursuant to, and subject to 1364 the license terms contained in, the Simplified BSD License set 1365 forth in Section 4.c of the IETF Trust's Legal Provisions 1366 Relating to IETF Documents 1367 (https://trustee.ietf.org/license-info). 1369 This version of this YANG module is part of RFC XXXX; see the 1370 RFC itself for full legal notices. 1372 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1373 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1374 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1375 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1376 they appear in all capitals, as shown here."; 1378 revision 2020-03-08 { 1379 description 1380 "Initial revision."; 1381 reference 1382 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1383 } 1385 /* 1386 * Augmentation to L3NM 1387 */ 1389 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1390 + "/l3vpn-ntw:vpn-service" { 1391 description 1392 "L3SM augmented to include TE parameters and mapping"; 1393 container te-service-mapping { 1394 presence "Indicates L3 network to TE mapping"; 1395 description 1396 "Container to augment l3nm to TE parameters and mapping"; 1397 uses tsm-types:te-mapping; 1398 } 1399 } 1401 //augment 1403 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1404 + "/l3vpn-ntw:vpn-service" 1405 + "/l3vpn-ntw:vpn-nodes/l3vpn-ntw:vpn-node" 1406 + "/l3vpn-ntw:vpn-network-accesses" 1407 + "/l3vpn-ntw:vpn-network-access" { 1408 description 1409 "This augment is only valid for TE mapping of L3NM network-access 1410 to TE endpoints"; 1411 uses tsm-types:te-endpoint-ref; 1412 } 1414 //augment 1415 } 1417 1419 7.3.2. ietf-l2nm-te-service-mapping 1421 file "ietf-l2nm-te-service-mapping@2020-03-08.yang" 1422 module ietf-l2nm-te-service-mapping { 1423 yang-version 1.1; 1424 namespace 1425 "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping"; 1426 prefix l2nm-tsm; 1428 import ietf-te-service-mapping-types { 1429 prefix tsm-types; 1430 reference 1431 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1432 } 1433 import ietf-l2vpn-ntw { 1434 prefix l2vpn-ntw; 1435 reference 1436 "I-D.-barguil-opsawg-l2sm-l2nm: A Layer 2 VPN Network YANG Model"; 1438 } 1440 organization 1441 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1442 Working Group"; 1443 contact 1444 "WG Web: 1445 WG List: 1447 Editor: Young Lee 1448 1449 Editor: Dhruv Dhody 1450 1451 Editor: Qin Wu 1452 "; 1453 description 1454 "This module contains a YANG module for the mapping of Layer 2 1455 Network Model (L2NM) to the TE and VN. 1457 Copyright (c) 2020 IETF Trust and the persons identified as 1458 authors of the code. All rights reserved. 1460 Redistribution and use in source and binary forms, with or 1461 without modification, is permitted pursuant to, and subject to 1462 the license terms contained in, the Simplified BSD License set 1463 forth in Section 4.c of the IETF Trust's Legal Provisions 1464 Relating to IETF Documents 1465 (https://trustee.ietf.org/license-info). 1467 This version of this YANG module is part of RFC XXXX; see the 1468 RFC itself for full legal notices. 1470 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1471 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1472 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1473 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1474 they appear in all capitals, as shown here."; 1476 revision 2020-03-08 { 1477 description 1478 "Initial revision."; 1479 reference 1480 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1481 } 1483 /* 1484 * Augmentation to L2NM 1485 */ 1487 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1488 + "/l2vpn-ntw:vpn-svc" { 1489 description 1490 "L2SM augmented to include TE parameters and mapping"; 1491 container te-service-mapping { 1492 presence "Indicates L2 network to TE mapping"; 1493 description 1494 "Container to augment l2nm to TE parameters and mapping"; 1495 uses tsm-types:te-mapping; 1496 } 1497 } 1499 //augment 1501 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1502 + "/l2vpn-ntw:vpn-svc" 1503 + "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node" 1504 + "/l2vpn-ntw:vpn-network-accesses" 1505 + "/l2vpn-ntw:vpn-network-access" { 1506 description 1507 "This augment is only valid for TE mapping of L2NM network-access 1508 to TE endpoints"; 1509 uses tsm-types:te-endpoint-ref; 1510 } 1512 //augment 1513 } 1515 1517 8. Security Considerations 1519 The YANG modules defined in this document is designed to be accessed 1520 via network management protocol such as NETCONF [RFC6241] or RESTCONF 1521 [RFC8040]. The lowest NETCONF layer is the secure transport layer 1522 and the mandatory-to-implement secure transport is SSH [RFC6242]. 1523 The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement 1524 secure transport is TLS [RFC8446] 1526 The NETCONF access control model [RFC8341] provides the means to 1527 restrict access for particular NETCONF or RESTCONF users to a pre- 1528 configured subset of all available NETCONF or RESTCONF protocol 1529 operations and content. 1531 There are a number of data nodes defined in the YANG moduleS which 1532 are writable/creatable/deletable (i.e., config true, which is the 1533 default). These data nodes may be considered sensitive or vulnerable 1534 in some network environments. Write operations (e.g., ) 1535 to these data nodes without proper protection can have a negative 1536 effect on network operations. These are the subtrees and data nodes 1537 and their sensitivity/vulnerability: 1539 o /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1540 - configure TE Service mapping. 1542 o /l3vpn-svc/sites/site/site-network-accesses/site-network-access/ 1543 te/ - configure TE Endpoint mapping. 1545 o /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1546 - configure TE Service mapping. 1548 o /l2vpn-svc/sites/site/site-network-accesses/site-network-access/ 1549 te/ - configure TE Endpoint mapping. 1551 o /l1-connectivity/services/service/te-service-mapping/te-mapping/ - 1552 configure TE Service mapping. 1554 o /l1-connectivity/access/unis/uni/te/ - configure TE Endpoint 1555 mapping. 1557 o /l3vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1558 - configure TE Network mapping. 1560 o /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1561 network-accesses/vpn-network-access/te/ - configure TE Endpoint 1562 mapping. 1564 o /l2vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1565 - configure TE Network mapping. 1567 o /l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1568 network-accesses/vpn-network-access/te/ - configure TE Endpoint 1569 mapping. 1571 Unauthorized access to above list can adversely affect the VPN 1572 service. 1574 Some of the readable data nodes in the YANG module may be considered 1575 sensitive or vulnerable in some network environments. It is thus 1576 important to control read access (e.g., via get, get-config, or 1577 notification) to these data nodes. The TE related parameters 1578 attached to the VPN service can leak sensitive information about the 1579 network. This is apploicable to all elements in the yang models 1580 defined in this document. 1582 This document has no RPC defined. 1584 9. IANA Considerations 1586 This document request the IANA to register four URIs in the "IETF XML 1587 Registry" [RFC3688]. Following the format in RFC 3688, the following 1588 registrations are requested - 1590 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1591 Registrant Contact: The IESG. 1592 XML: N/A, the requested URI is an XML namespace. 1594 URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 1595 Registrant Contact: The IESG. 1596 XML: N/A, the requested URI is an XML namespace. 1598 URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 1599 Registrant Contact: The IESG. 1600 XML: N/A, the requested URI is an XML namespace. 1602 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 1603 Registrant Contact: The IESG. 1604 XML: N/A, the requested URI is an XML namespace. 1606 URI: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 1607 Registrant Contact: The IESG. 1608 XML: N/A, the requested URI is an XML namespace. 1610 URI: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 1611 Registrant Contact: The IESG. 1612 XML: N/A, the requested URI is an XML namespace. 1614 This document request the IANA to register four YANG modules in the 1615 "YANG Module Names" registry [RFC6020], as follows - 1616 Name: ietf-te-service-mapping-types 1617 Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1618 Prefix: tsm 1619 Reference: [This.I-D] 1621 Name: ietf-l3sm-te-service-mapping 1622 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 1623 Prefix: l3-tsm 1624 Reference: [This.I-D] 1626 Name: ietf-l2sm-te-service-mapping 1627 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 1628 Prefix: l2-tsm 1629 Reference: [This.I-D] 1631 Name: ietf-l1csm-te-service-mapping 1632 Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 1633 Prefix: l1-tsm 1634 Reference: [This.I-D] 1636 Name: ietf-l3nm-te-service-mapping 1637 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 1638 Prefix: l3nm-tsm 1639 Reference: [This.I-D] 1641 Name: ietf-l2nm-te-service-mapping 1642 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 1643 Prefix: l2nm-tsm 1644 Reference: [This.I-D] 1646 10. Acknowledgements 1648 We thank Diego Caviglia, Igor Bryskin, Oscar Gonzalez de Dios, and 1649 Samier Barguil Giraldo for useful discussions and motivation for this 1650 work. 1652 11. References 1654 11.1. Normative References 1656 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1657 DOI 10.17487/RFC3688, January 2004, 1658 . 1660 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1661 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1662 . 1664 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1665 Ceccarelli, D., and X. Zhang, "Problem Statement and 1666 Architecture for Information Exchange between 1667 Interconnected Traffic-Engineered Networks", BCP 206, 1668 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1669 . 1671 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1672 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1673 . 1675 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1676 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1677 . 1679 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1680 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1681 DOI 10.17487/RFC8299, January 2018, 1682 . 1684 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1685 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1686 . 1688 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1689 Access Control Model", STD 91, RFC 8341, 1690 DOI 10.17487/RFC8341, March 2018, 1691 . 1693 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1694 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1695 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1696 2018, . 1698 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1699 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1700 . 1702 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1703 Data Model for Layer 2 Virtual Private Network (L2VPN) 1704 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1705 2018, . 1707 [I-D.ietf-ccamp-l1csm-yang] 1708 Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. 1709 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 1710 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in 1711 progress), September 2019. 1713 [I-D.ietf-teas-actn-vn-yang] 1714 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1715 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1716 teas-actn-vn-yang-07 (work in progress), October 2019. 1718 [I-D.ietf-teas-yang-te] 1719 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1720 "A YANG Data Model for Traffic Engineering Tunnels and 1721 Interfaces", draft-ietf-teas-yang-te-22 (work in 1722 progress), November 2019. 1724 [I-D.ietf-teas-yang-te-types] 1725 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1726 "Traffic Engineering Common YANG Types", draft-ietf-teas- 1727 yang-te-types-13 (work in progress), November 2019. 1729 [I-D.ietf-opsawg-l3sm-l3nm] 1730 Aguado, A., Dios, O., Lopezalvarez, V., Voyer, D., and L. 1731 Munoz, "A Layer 3 VPN Network YANG Model", draft-ietf- 1732 opsawg-l3sm-l3nm-01 (work in progress), November 2019. 1734 [I-D.barguil-opsawg-l2sm-l2nm] 1735 Barguil, S., Dios, O., Lopezalvarez, V., Munoz, L., and L. 1736 Jalil, "A Layer 2 VPN Network Yang Model", draft-barguil- 1737 opsawg-l2sm-l2nm-00 (work in progress), December 2019. 1739 11.2. Informative References 1741 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1742 the Network Configuration Protocol (NETCONF)", RFC 6020, 1743 DOI 10.17487/RFC6020, October 2010, 1744 . 1746 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1747 and A. Bierman, Ed., "Network Configuration Protocol 1748 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1749 . 1751 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1752 Classification", RFC 8199, DOI 10.17487/RFC8199, July 1753 2017, . 1755 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1756 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1757 . 1759 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1760 and R. Wilton, "Network Management Datastore Architecture 1761 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1762 . 1764 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1765 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1766 DOI 10.17487/RFC8453, August 2018, 1767 . 1769 [I-D.ietf-teas-yang-te-topo] 1770 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1771 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1772 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 1773 progress), June 2019. 1775 [I-D.ietf-teas-actn-yang] 1776 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 1777 Shin, J., and S. Belotti, "Applicability of YANG models 1778 for Abstraction and Control of Traffic Engineered 1779 Networks", draft-ietf-teas-actn-yang-05 (work in 1780 progress), February 2020. 1782 Appendix A. Contributor Addresses 1784 Adrian Farrel 1785 Old Dog Consulting 1787 EMail: adrian@olddog.co.uk 1789 Italo Busi 1790 Huawei Technologies 1792 EMail: Italo.Busi@huawei.com 1794 Haomian Zheng 1795 Huawei Technologies 1797 EMail: zhenghaomian@huawei.com 1799 Authors' Addresses 1801 Young Lee (editor) 1802 Samsung Electronics 1804 Email: younglee.tx@gmail.com 1805 Dhruv Dhody (editor) 1806 Huawei Technologies 1808 Email: dhruv.ietf@gmail.com 1810 Giuseppe Fioccola 1811 Huawei Technologies 1813 Email: giuseppe.fioccola@huawei.com 1815 Qin Wu (editor) 1816 Huawei Technologies 1818 Email: bill.wu@huawei.com 1820 Daniele Ceccarelli 1821 Ericsson 1822 Torshamnsgatan,48 1823 Stockholm, Sweden 1825 Email: daniele.ceccarelli@ericsson.com 1827 Jeff Tantsura 1828 Apstra 1830 Email: jefftant@gmail.com