idnits 2.17.1 draft-ietf-teas-te-service-mapping-yang-05.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 642 has weird spacing: '...ic-type ide...' == Line 646 has weird spacing: '...w usage ide...' == Line 652 has weird spacing: '...rw name str...' == Line 659 has weird spacing: '...w usage ide...' == Line 707 has weird spacing: '...int-ref lea...' == (4 more instances...) -- The document date (November 2, 2020) is 1269 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 224, but not defined == Unused Reference: 'I-D.ietf-spring-sr-policy-yang' is defined on line 1930, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-12 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-00 == 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-09 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-25 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-06 Summary: 0 errors (**), 0 flaws (~~), 16 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: May 6, 2021 G. Fioccola 6 Q. Wu, Ed. 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 J. Tantsura 11 Apstra 12 November 2, 2020 14 Traffic Engineering (TE) and Service Mapping Yang Model 15 draft-ietf-teas-te-service-mapping-yang-05 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 May 6, 2021. 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.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. Availability Requirement . . . . . . . . . . . . . . . . 8 72 3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 8 73 3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 9 74 3.2. TE and Network Models . . . . . . . . . . . . . . . . . . 9 75 4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 10 76 4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 13 77 4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 13 78 5. Applicability of TE-Service Mapping in Generic context . . . 14 79 6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.1. Service Mapping Types . . . . . . . . . . . . . . . . . . 14 81 6.2. Service Models . . . . . . . . . . . . . . . . . . . . . 16 82 6.2.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 16 83 6.2.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 17 84 6.2.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.3. Network Models . . . . . . . . . . . . . . . . . . . . . 18 86 6.3.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 18 87 6.3.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 19 88 7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 20 89 7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 20 90 7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 29 91 7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 29 92 7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 31 93 7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 33 94 7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 35 95 7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 35 96 7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 37 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 99 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 42 102 11.2. Informative References . . . . . . . . . . . . . . . . . 45 103 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 46 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 106 1. Introduction 108 Data models are a representation of objects that can be configured or 109 monitored within a system. Within the IETF, YANG [RFC7950] is the 110 language of choice for documenting data models, and YANG models have 111 been produced to allow configuration or modelling of a variety of 112 network devices, protocol instances, and network services. YANG data 113 models have been classified in [RFC8199] and [RFC8309]. 115 Framework for Abstraction and Control of Traffic Engineered Networks 116 (ACTN) [RFC8453] introduces an architecture to support virtual 117 network services and connectivity services. 118 [I-D.ietf-teas-actn-vn-yang] defines a YANG model and describes how 119 customers or end-to-end orchestrator can request and/or instantiate a 120 generic virtual network service. [I-D.ietf-teas-actn-yang] describes 121 the way IETF YANG models of different classifications can be applied 122 to the ACTN interfaces. In particular, it describes how customer 123 service models can be mapped into the CNC-MDSC Interface (CMI) of the 124 ACTN architecture. 126 The models presented in this document are also applicable in generic 127 context [RFC8309] as part of Customer Service Model used between 128 Service Orchestrator and Customer. 130 [RFC8299] provides a L3VPN service delivery YANG model for PE-based 131 VPNs. The scope of that draft is limited to a set of domains under 132 control of the same network operator to deliver services requiring TE 133 tunnels. 135 [RFC8466] provides a L2VPN service delivery YANG model for PE-based 136 VPNs. The scope of that draft is limited to a set of domains under 137 control of the same network operator to deliver services requiring TE 138 tunnels. 140 [I-D.ietf-ccamp-l1csm-yang] provides a L1 connectivity service 141 delivery YANG model for PE-based VPNs. The scope of that draft is 142 limited to a set of domains under control of the same network 143 operator to deliver services requiring TE tunnels. 145 While the IP/MPLS Provisioning Network Controller (PNC) is 146 responsible for provisioning the VPN service on the Provider Edge 147 (PE) nodes, the Multi-Domain Service Coordinator (MDSC) can 148 coordinate how to map the VPN services onto Traffic Engineering (TE) 149 tunnels. This is consistent with the two of the core functions of 150 the MDSC specified in [RFC8453]: 152 o Customer mapping/translation function: This function is to map 153 customer requests/commands into network provisioning requests that 154 can be sent to the PNC according to the business policies that 155 have been provisioned statically or dynamically. Specifically, it 156 provides mapping and translation of a customer's service request 157 into a set of parameters that are specific to a network type and 158 technology such that the network configuration process is made 159 possible. 161 o Virtual service coordination function: This function translates 162 customer service-related information into virtual network service 163 operations in order to seamlessly operate virtual networks while 164 meeting a customer's service requirements. In the context of 165 ACTN, service/virtual service coordination includes a number of 166 service orchestration functions such as multi-destination load 167 balancing, guarantees of service quality, bandwidth and 168 throughput. It also includes notifications for service fault and 169 performance degradation and so forth. 171 Section 2 describes a set of TE and service related parameters that 172 this document addresses as "new and advanced parameters" that are not 173 included in generic service models. Section 3 discusses YANG 174 modelling approach. 176 Apart from the service model, the TE mapping is equally applicable to 177 the Network Models (L3 VPN Service Network Model (L3NM) 178 [I-D.ietf-opsawg-l3sm-l3nm], L2 VPN Service Network Model (L2NM) 179 [I-D.ietf-opsawg-l2nm] etc.). See Section 3.2 for details. 181 1.1. Terminology 183 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 184 in this document. 186 The terminology for describing YANG data models is found in 187 [RFC7950]. 189 1.1.1. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in BCP 194 14 [RFC2119] [RFC8174] when, and only when, they appear in all 195 capitals, as shown here. 197 1.2. Tree diagram 199 A simplified graphical representation of the data model is used in 200 Section 5 of this this document. The meaning of the symbols in these 201 diagrams is defined in [RFC8340]. 203 1.3. Prefixes in Data Node Names 205 In this document, names of data nodes and other data model objects 206 are prefixed using the standard prefix associated with the 207 corresponding YANG imported modules, as shown in Table 1. 209 +---------+---------------------------+-----------------------------+ 210 | Prefix | YANG module | Reference | 211 +---------+---------------------------+-----------------------------+ 212 | inet | ietf-inet-types | [RFC6991] | 213 | tsm- | ietf-te-service-mapping- | [RFCXXXX] | 214 | types | types | | 215 | l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang] | 216 | l2vpn- | ietf-l2vpn-svc | [RFC8466] | 217 | svc | | | 218 | l3vpn- | ietf-l3vpn-svc | [RFC8299] | 219 | svc | | | 220 | l1-tsm | ietf-l1csm-te-service- | [RFCXXXX] | 221 | | mapping | | 222 | l2-tsm | ietf-l2sm-te-service- | [RFCXXXX] | 223 | | mapping | | 224 | l3-tsm | ietf-l3sm-te-service- | [RFCXXXX] | 225 | | mapping | | 226 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang | 227 | | | ] | 228 | nw | ietf-network | [RFC8345] | 229 | te- | ietf-te-types | [RFC8776] | 230 | types | | | 231 | te | ietf-te | [I-D.ietf-teas-yang-te] | 232 | l2vpn- | ietf-l2vpn-ntw | [I-D.ietf-opsawg-l2nm] | 233 | ntw | | | 234 | l3vpn- | ietf-l3vpn-ntw | [I-D.ietf-opsawg-l3sm-l3nm] | 235 | ntw | | | 236 | rt | ietf-routing | [RFC8349] | 237 | sr- | ietf-sr-policy | [I-D.ietf-spring-sr-policy- | 238 | policy | | yang] | 239 +---------+---------------------------+-----------------------------+ 241 Table 1: Prefixes and corresponding YANG modules 243 Note: The RFC Editor should replace XXXX with the number assigned to 244 the RFC once this draft becomes an RFC. 246 2. TE and Service Related Parameters 248 While L1/L2/L3 service models (L1CSM, L2SM, L3SM) are intended to 249 provide service-specific parameters for VPN service instances, there 250 are a number of TE Service related parameters that are not included 251 in these service models. 253 Additional 'service parameters and policies' that are not included in 254 the aforementioned service models are addressed in the YANG models 255 defined in this document. 257 2.1. VN/Tunnel Selection Requirements 259 In some cases, the service requirements may need addition TE tunnels 260 to be established. This may occur when there are no suitable 261 existing TE tunnels that can support the service requirements, or 262 when the operator would like to dynamically create and bind tunnels 263 to the VPN such that they are not shared by other VPNs, for example, 264 for network slicing. The establishment of TE tunnels is subject to 265 the network operator's policies. 267 To summarize, there are three modes of VN/Tunnel selection operations 268 to be supported as follows. Additional modes may be defined in the 269 future. 271 o New VN/Tunnel Binding - A customer could request a VPN service 272 based on VN/Tunnels that are not shared with other existing or 273 future services. This might be to meet VPN isolation 274 requirements. Further, the YANG model described in Section 5 of 275 this document can be used to describe the mapping between the VPN 276 service and the ACTN VN. The VN (and TE tunnels) could be bound 277 to the VPN and not used for any other VPN. Under this mode, the 278 following sub-categories can be supported: 280 1. Hard Isolation with deterministic characteristics: A customer 281 could request a VPN service using a set of TE Tunnels with 282 deterministic characteristics requirements (e.g., no latency 283 variation) and where that set of TE Tunnels must not be shared 284 with other VPN services and must not compete for bandwidth or 285 other network resources with other TE Tunnels. 287 2. Hard Isolation: This is similar to the above case but without 288 the deterministic characteristics requirements. 290 3. Soft Isolation: The customer requests a VPN service using a 291 set of TE tunnels which can be shared with other VPN services. 293 o VN/Tunnel Sharing - A customer could request a VPN service where 294 new tunnels (or a VN) do not need to be created for each VPN and 295 can be shared across multiple VPNs. Further, the mapping YANG 296 model described in Section 5 of this document can be used to 297 describe the mapping between the VPN service and the tunnels in 298 use. No modification of the properties of a tunnel (or VN) is 299 allowed in this mode: an existing tunnel can only be selected. 301 o VN/Tunnel Modify - This mode allows the modification of the 302 properties of the existing VN/tunnel (e.g., bandwidth). 304 o TE Mapping Template - This mode allows a VPN service to be bound 305 to a mapping template containing constraints and optimization 306 criteria. This allows mapping with the underlay TE 307 characteristics without first creating a VN or tunnels to map. 308 The VPN service could be mapped to a template first. Once the VN/ 309 Tunnels are actually created/selected for the VPN service, this 310 mode is no longer used and replaced with the above modes. 312 2.2. Availability Requirement 314 Availability is another service requirement or intent that may 315 influence the selection or provisioning of TE tunnels or a VN to 316 support the requested service. Availability is a probabilistic 317 measure of the length of time that a VPN/VN instance functions 318 without a network failure. 320 The availability level will need to be translated into network 321 specific policies such as the protection/reroute policy associated 322 with a VN or Tunnel. The means by which this is achieved is not in 323 the scope of this document. 325 3. YANG Modeling Approach 327 This section provides how the TE and Service mapping parameters are 328 supported using augmentation of the existing service models (i.e., 329 [I-D.ietf-ccamp-l1csm-yang], [RFC8466], and [RFC8299]). Figure 1 330 shows the scope of the Augmented LxSM Model. 332 +--------------+ +----------------------+ +----------+ 333 | LxSM |o-------| | . . . . | ACTN VN | 334 +--------------+ augment| | +----------+ 335 | | +----------+ 336 +--------------+ | Augmented LxSM Model | . . . . | TE-topo | 337 | TE & Service |------->| | +----------+ 338 | Mapping Types| import | | +----------+ 339 +--------------+ | | . . . . | TE-tunnel| 340 +----------------------+ +----------+ 341 reference 343 Figure 1: Augmented LxSM Model 345 The Augmented LxSM model (where x=1,2,3) augments the basic LxSM 346 model while importing the common TE and Service related parameters 347 (defined in Section 2) grouping information from TE and Service 348 Mapping Types. The TE and Service Mapping Types (ietf-te-service- 349 mapping-types) module is the repository of all common groupings 350 imported by each augmented LxSM model. Any future service models 351 would import this mapping-type common model. 353 The role of the augmented LxSm service model is to expose the mapping 354 relationship between service models and TE models so that VN/VPN 355 service instantiations provided by the underlying TE networks can be 356 viewed outside of the MDSC, for example by an operator who is 357 diagnosing the behaviour of the network. It also allows for the 358 customers to access operational state information about how their 359 services are instantiated with the underlying VN, TE topology or TE 360 tunnels provided that the MDSC operator is willing to share that 361 information. This mapping will facilitate a seamless service 362 management operation with underlay-TE network visibility. 364 As seen in Figure 1, the augmented LxSM service model records a 365 mapping between the customer service models and the ACTN VN YANG 366 model. Thus, when the MDSC receives a service request it creates a 367 VN that meets the customer's service objectives with various 368 constraints via TE-topology model [RFC8795], and this relationship is 369 recorded by the Augmented LxSM Model. The model also supports a 370 mapping between a service model and TE-topology or a TE-tunnel. 372 The YANG models defined in this document conforms to the Network 373 Management Datastore Architecture (NMDA) [RFC8342]. 375 3.1. Forward Compatibility 377 The YANG module defined in this document supports three existing 378 service models via augmenting while sharing the common TE and Service 379 Mapping Types. 381 It is possible that new service models will be defined at some future 382 time and that it will be desirable to map them to underlying TE 383 constructs in the same way as the three existing models are 384 augmented. 386 3.2. TE and Network Models 388 The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN 389 Service in the Service Provider Network. It containts information of 390 the Service Provider network and might include allocated resources. 391 It can be used by network controllers to manage and control the VPN 392 Service configuration in the Service Provider network. 394 Similar to service model, the existing network models (i.e., 395 [I-D.ietf-opsawg-l3sm-l3nm], and [I-D.ietf-opsawg-l2nm]) are 396 augmented to include the TE and Service mapping parameters. Figure 2 397 shows the scope of the Augmented LxNM Model. 399 +--------------+ +----------------------+ +----------+ 400 | LxNM |o-------| | . . . . | ACTN VN | 401 +--------------+ augment| | +----------+ 402 | | +----------+ 403 +--------------+ | Augmented LxNM Model | . . . . | TE-topo | 404 | TE & Service |------->| | +----------+ 405 | Mapping Types| import | | +----------+ 406 +--------------+ | | . . . . | TE-tunnel| 407 +----------------------+ +----------+ 408 reference 410 Figure 2: Augmented LxNM Model 412 The Augmented LxNM model (where x=2,3) augments the basic LxNM model 413 while importing the common TE mapping related parameters (defined in 414 Section 2) grouping information from TE and Service Mapping Types. 415 The role of the augmented LxNM network model is to expose the mapping 416 relationship between network models and TE models. 418 4. L3VPN Architecture in the ACTN Context 420 Figure 3 shows the architectural context of this document referencing 421 the ACTN components and interfaces. 423 +----------------------------+ 424 | Customer Service Manager | 425 | +-----------------------+ | 426 | | CNC + | 427 | +-+-------------------+-+ | 428 +----|-------------------|---+ 429 | | 430 |CMI(Augmented L3SM)|CMI(VN) 431 | | 432 +----------------|-------------------|----+ 433 | +--------------|-----------------+ | | 434 | | MDSC | | | | 435 | | | | | | 436 | | +-----------+--------------+ | | | 437 TE-Svc-Map<------+ Service Mapping Function | | | | 438 | | +-----------+--------------+ | | | 439 | | | | | | 440 | +-------+------|-----------------+ | | 441 | | | | | 442 | | |CMI(VN) | | 443 | | | | | 444 | | +--|-------------------|--+ | 445 | | | | MDSC | | | 446 | | | ++-------------------++ | | 447 | | | + Service Mapping +---->TE-Svc-Map 448 | | | ++----------+---------+ | | 449 | | +--|----------|-----------+ | 450 +---------|------|----------|-------------+ 451 | | | 452 | +----+--------+ | 453 | | | | 454 MPI(VPN / TE models)| | | |MPI(TE / L1 models) 455 | | | | 456 +-----|-|---+ +-----|-|----+ 457 IP/MPLS | +--+-+-+ | | +--+-+-+ | Optical Domain 458 Domain | | PNC1 | | | | PNC2 | | Controller 459 Controller | +--+---+ | | +--+---+ | 460 +-----|-----+ +-----|------+ 461 | | 462 V | SBI 463 +---------------------+ | 464 / IP/MPLS Network \ | 465 +-------------------------+ | 466 V 467 +---------------------+ 468 / Optical Network \ 469 +-------------------------+ 471 Figure 3: L3VPN Architecture from the IP+Optical Network Perspective 473 There are three main entities in the ACTN architecture and shown in 474 Figure 3. 476 o CNC: The Customer Network Controller is responsible for generating 477 service requests. In the context of an L3VPN, the CNC uses the 478 Augmented L3SM to express the service request and communicate it 479 to the network operator. 481 o MDSC: This entity is responsible for coordinating a L3VPN service 482 request (expressed via the Augmented L3SM) with the IP/MPLS PNC 483 and the Transport PNC. For TE services, one of the key 484 responsibilities of the MDSC is to coordinate with both the IP PNC 485 and the Transport PNC for the mapping of the Augmented L3VPN 486 Service Model to the ACTN VN model. In the VN/TE-tunnel binding 487 case, the MDSC will need to coordinate with the Transport PNC to 488 dynamically create the TE-tunnels in the transport network as 489 needed. These tunnels are added as links in the IP/MPLS Layer 490 topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 491 tunnels in the IP/MPLS layer, as part of the ACTN VN creation. 493 o PNC: The Provisioning Network Controller is responsible for 494 configuring and operating the network devices. Figure 2 shows two 495 distinct PNCs. 497 * IP/MPLS PNC (PNC1): This entity is responsible for device 498 configuration to create PE-PE L3VPN tunnels for the VPN 499 customer and for the configuration of the L3VPN VRF on the PE 500 nodes. Each network element would select a tunnel based on the 501 configuration. 503 * Transport PNC (PNC2): This entity is responsible for device 504 configuration for TE tunnels in the transport networks. 506 There are four main interfaces shown in Figure 2. 508 o CMI: The CNC-MDSC Interface is used to communicate service 509 requests from the customer to the operator. The requests may be 510 expressed as Augmented VPN service requests (L2SM, L3SM), as 511 connectivity requests (L1CSM), or as virtual network requests 512 (ACTN VN). 514 o MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate 515 networks under the control of PNCs. The requests on this 516 interface may use TE tunnel models, TE topology models, VPN 517 network configuration models or layer one connectivity models. 519 o SBI: The Southbound Interface is used by the PNC to control 520 network devices and is out of scope for this document. 522 The TE Service Mapping Model as described in this document can be 523 used to see the mapping between service models and VN models and TE 524 Tunnel/Topology models. That mapping may occur in the CNC if a 525 service request is mapped to a VN request. Or it may occur in the 526 MDSC where a service request is mapped to a TE tunnel, TE topology, 527 or VPN network configuration model. The TE Service Mapping Model may 528 be read from the CNC or MDSC to understand how the mapping has been 529 made and to see the purpose for which network resources are used. 531 As shown in Figure 2, the MDSC may be used recursively. For example, 532 the CNC might map a L3SM request to a VN request that it sends to a 533 recursive MDSC. 535 The high-level control flows for one example are as follows: 537 1. A customer asks for an L3VPN between CE1 and CE2 using the 538 Augmented L3SM model. 540 2. The MDSC considers the service request and local policy to 541 determine if it needs to create a new VN or any TE Topology, and 542 if that is the case, ACTN VN YANG [I-D.ietf-teas-actn-vn-yang] is 543 used to configure a new VN based on this VPN and map the VPN 544 service to the ACTN VN. In case an existing tunnel is to be 545 used, each device will select which tunnel to use and populate 546 this mapping information. 548 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 549 PNC to create a PE-PE tunnel in the IP network mapped to a TE 550 tunnel in the transport network by providing the inter-layer 551 access points and tunnel requirements. The specific service 552 information is passed to the IP/MPLS PNC for the actual VPN 553 configuration and activation. 555 A. The Transport PNC creates the corresponding TE tunnel 556 matching with the access point and egress point. 557 B. The IP/MPLS PNC maps the VPN ID with the corresponding TE 558 tunnel ID to bind these two IDs. 560 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 561 customer. This is not in the scope of this document. 563 4.1. Service Mapping 565 Augmented L3SM and L2SM can be used to request VPN service creation 566 including the creation of sites and corresponding site network access 567 connection between CE and PE. A VPN-ID is used to identify each VPN 568 service ordered by the customer. The ACTN VN can be used further to 569 establish PE-to-PE connectivity between VPN sites belonging to the 570 same VPN service. A VN-ID is used to identify each virtual network 571 established between VPN sites. 573 Once the ACTN VN has been established over the TE network (maybe a 574 new VN, maybe modification of an existing VN, or maybe the use of an 575 unmodified existing VN), the mapping between the VPN service and the 576 ACTN VN service can be created. 578 4.2. Site Mapping 580 The elements in Augmented L3SM and L2SM define site location 581 parameters and constraints such as distance and access diversity that 582 can influence the placement of network attachment points (i.e, 583 virtual network access points (VNAP)). To achieve this, a central 584 directory can be set up to establish the mapping between location 585 parameters and constraints and network attachment point location. 586 Suppose multiple attachment points are matched, the management system 587 can use constraints or other local policy to select the best 588 candidate network attachment points. 590 After a network attachment point is selected, the mapping between VPN 591 site and VNAP can be established as shown in Table 1. 593 +-------+---------+------------------+------------------------+-----+ 594 | Site | Site | Location | Access Diversity | PE | 595 | | Network | (Address, Postal | (Constraint-Type, | | 596 | | Access | Code, State, | Group-id,Target Group- | | 597 | | | City,Country | id) | | 598 | | | Code) | | | 599 +-------+---------+------------------+------------------------+-----+ 600 | SITE1 | ACCESS1 | (,,US,NewYork,) | (10,PE-Diverse,10) | PE1 | 601 +-------+---------+------------------+------------------------+-----+ 602 | SITE2 | ACCESS2 | (,,CN,Beijing,) | (10,PE-Diverse,10) | PE2 | 603 +-------+---------+------------------+------------------------+-----+ 604 | SITE3 | ACCESS3 | (,,UK,London, ) | (12,same-PE,12) | PE4 | 605 +-------+---------+------------------+------------------------+-----+ 606 | SITE4 | ACCESS4 | (,,FR,Paris,) | (20,Bearer-Diverse,20) | PE7 | 607 +-------+---------+------------------+------------------------+-----+ 609 Table 2: : Mapping Between VPN Site and VNAP 611 5. Applicability of TE-Service Mapping in Generic context 613 As discussed in the Introduction Section, the models presented in 614 this document are also applicable generically outside of the ACTN 615 architecture. [RFC8309] defines Customer Service Model between 616 Customer and Service Orchestrator and Service Delivery Model between 617 Service Orchestrator and Network Orchestrator(s). TE-Service mapping 618 models defined in this document can be regarded primarily as Customer 619 Service Model and secondarily as Service Deliver Model. 621 6. YANG Data Trees 623 6.1. Service Mapping Types 625 module: ietf-te-service-mapping-types 626 +--rw te-mapping-templates 627 +--rw te-mapping-template* [id] 628 +--rw id te-mapping-template-id 629 +--rw description? string 630 +--rw map-type? identityref 631 +--rw path-constraints 632 | +--rw te-bandwidth 633 | | +--rw (technology)? 634 | | +--:(generic) 635 | | +--rw generic? te-bandwidth 636 | +--rw link-protection? identityref 637 | +--rw setup-priority? uint8 638 | +--rw hold-priority? uint8 639 | +--rw signaling-type? identityref 640 | +--rw path-metric-bounds 641 | | +--rw path-metric-bound* [metric-type] 642 | | +--rw metric-type identityref 643 | | +--rw upper-bound? uint64 644 | +--rw path-affinities-values 645 | | +--rw path-affinities-value* [usage] 646 | | +--rw usage identityref 647 | | +--rw value? admin-groups 648 | +--rw path-affinity-names 649 | | +--rw path-affinity-name* [usage] 650 | | +--rw usage identityref 651 | | +--rw affinity-name* [name] 652 | | +--rw name string 653 | +--rw path-srlgs-lists 654 | | +--rw path-srlgs-list* [usage] 655 | | +--rw usage identityref 656 | | +--rw values* srlg 657 | +--rw path-srlgs-names 658 | | +--rw path-srlgs-name* [usage] 659 | | +--rw usage identityref 660 | | +--rw names* string 661 | +--rw disjointness? te-path-disjointness 662 +--rw optimizations 663 +--rw (algorithm)? 664 +--:(metric) {path-optimization-metric}? 665 | +--rw optimization-metric* [metric-type] 666 | | +--rw metric-type 667 | | | identityref 668 | | +--rw weight? uint8 669 | | +--rw explicit-route-exclude-objects 670 | | | ... 671 | | +--rw explicit-route-include-objects 672 | | ... 673 | +--rw tiebreakers 674 | +--rw tiebreaker* [tiebreaker-type] 675 | ... 676 +--:(objective-function) 677 {path-optimization-objective-function}? 678 +--rw objective-function 679 +--rw objective-function-type? identityref 681 6.2. Service Models 683 6.2.1. L3SM 685 module: ietf-l3sm-te-service-mapping 686 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services 687 /l3vpn-svc:vpn-service: 688 +--rw te-service-mapping! 689 +--rw te-mapping 690 +--rw map-type? identityref 691 +--rw availability-type? identityref 692 +--rw (te)? 693 +--:(vn) 694 | +--rw vn-list* 695 | -> /vn:vn/vn-list/vn-id 696 +--:(te-topo) 697 | +--rw vn-topology-id? 698 | | te-types:te-topology-id 699 | +--rw abstract-node? 700 | -> /nw:networks/network/node/node-id 701 +--:(te-tunnel) 702 | +--rw te-tunnel-list* te:tunnel-ref 703 | +--rw sr-policy* 704 | [policy-color-ref policy-endpoint-ref] 705 | {sr-policy}? 706 | +--rw policy-color-ref leafref 707 | +--rw policy-endpoint-ref leafref 708 +--:(te-mapping-template) {template}? 709 +--rw te-mapping-template-ref? leafref 710 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 711 /l3vpn-svc:site-network-accesses 712 /l3vpn-svc:site-network-access: 713 +--rw (te)? 714 +--:(vn) 715 | +--rw ap-list* 716 | -> /vn:ap/access-point-list/access-point-id 717 +--:(te) 718 +--rw ltp? te-types:te-tp-id 720 6.2.2. L2SM 722 module: ietf-l2sm-te-service-mapping 723 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services 724 /l2vpn-svc:vpn-service: 725 +--rw te-service-mapping! 726 +--rw te-mapping 727 +--rw map-type? identityref 728 +--rw availability-type? identityref 729 +--rw (te)? 730 +--:(vn) 731 | +--rw vn-list* 732 | -> /vn:vn/vn-list/vn-id 733 +--:(te-topo) 734 | +--rw vn-topology-id? 735 | | te-types:te-topology-id 736 | +--rw abstract-node? 737 | -> /nw:networks/network/node/node-id 738 +--:(te-tunnel) 739 | +--rw te-tunnel-list* te:tunnel-ref 740 | +--rw sr-policy* 741 | [policy-color-ref policy-endpoint-ref] 742 | {sr-policy}? 743 | +--rw policy-color-ref leafref 744 | +--rw policy-endpoint-ref leafref 745 +--:(te-mapping-template) {template}? 746 +--rw te-mapping-template-ref? leafref 747 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 748 /l2vpn-svc:site-network-accesses 749 /l2vpn-svc:site-network-access: 750 +--rw (te)? 751 +--:(vn) 752 | +--rw ap-list* 753 | -> /vn:ap/access-point-list/access-point-id 754 +--:(te) 755 +--rw ltp? te-types:te-tp-id 757 6.2.3. L1CSM 758 module: ietf-l1csm-te-service-mapping 759 augment /l1csm:l1-connectivity/l1csm:services/l1csm:service: 760 +--rw te-service-mapping! 761 +--rw te-mapping 762 +--rw map-type? identityref 763 +--rw availability-type? identityref 764 +--rw (te)? 765 +--:(vn) 766 | +--rw vn-list* 767 | -> /vn:vn/vn-list/vn-id 768 +--:(te-topo) 769 | +--rw vn-topology-id? 770 | | te-types:te-topology-id 771 | +--rw abstract-node? 772 | -> /nw:networks/network/node/node-id 773 +--:(te-tunnel) 774 | +--rw te-tunnel-list* te:tunnel-ref 775 | +--rw sr-policy* 776 | [policy-color-ref policy-endpoint-ref] 777 | {sr-policy}? 778 | +--rw policy-color-ref leafref 779 | +--rw policy-endpoint-ref leafref 780 +--:(te-mapping-template) {template}? 781 +--rw te-mapping-template-ref? leafref 782 augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni: 783 +--rw (te)? 784 +--:(vn) 785 | +--rw ap-list* 786 | -> /vn:ap/access-point-list/access-point-id 787 +--:(te) 788 +--rw ltp? te-types:te-tp-id 790 6.3. Network Models 792 6.3.1. L3NM 793 module: ietf-l3nm-te-service-mapping 794 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 795 /l3vpn-ntw:vpn-service: 796 +--rw te-service-mapping! 797 +--rw te-mapping 798 +--rw map-type? identityref 799 +--rw availability-type? identityref 800 +--rw (te)? 801 +--:(vn) 802 | +--rw vn-list* 803 | -> /vn:vn/vn-list/vn-id 804 +--:(te-topo) 805 | +--rw vn-topology-id? 806 | | te-types:te-topology-id 807 | +--rw abstract-node? 808 | -> /nw:networks/network/node/node-id 809 +--:(te-tunnel) 810 | +--rw te-tunnel-list* te:tunnel-ref 811 | +--rw sr-policy* 812 | [policy-color-ref policy-endpoint-ref] 813 | {sr-policy}? 814 | +--rw policy-color-ref leafref 815 | +--rw policy-endpoint-ref leafref 816 +--:(te-mapping-template) {template}? 817 +--rw te-mapping-template-ref? leafref 818 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 819 /l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes 820 /l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses 821 /l3vpn-ntw:vpn-network-access: 822 +--rw (te)? 823 +--:(vn) 824 | +--rw ap-list* 825 | -> /vn:ap/access-point-list/access-point-id 826 +--:(te) 827 +--rw ltp? te-types:te-tp-id 829 6.3.2. L2NM 830 module: ietf-l2nm-te-service-mapping 831 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 832 /l2vpn-ntw:vpn-service: 833 +--rw te-service-mapping! 834 +--rw te-mapping 835 +--rw map-type? identityref 836 +--rw availability-type? identityref 837 +--rw (te)? 838 +--:(vn) 839 | +--rw vn-list* 840 | -> /vn:vn/vn-list/vn-id 841 +--:(te-topo) 842 | +--rw vn-topology-id? 843 | | te-types:te-topology-id 844 | +--rw abstract-node? 845 | -> /nw:networks/network/node/node-id 846 +--:(te-tunnel) 847 | +--rw te-tunnel-list* te:tunnel-ref 848 | +--rw sr-policy* 849 | [policy-color-ref policy-endpoint-ref] 850 | {sr-policy}? 851 | +--rw policy-color-ref leafref 852 | +--rw policy-endpoint-ref leafref 853 +--:(te-mapping-template) {template}? 854 +--rw te-mapping-template-ref? leafref 855 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 856 /l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes 857 /l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses 858 /l2vpn-ntw:vpn-network-access: 859 +--rw (te)? 860 +--:(vn) 861 | +--rw ap-list* 862 | -> /vn:ap/access-point-list/access-point-id 863 +--:(te) 864 +--rw ltp? te-types:te-tp-id 866 7. YANG Data Models 868 The YANG codes are as follows: 870 7.1. ietf-te-service-mapping-types 872 file "ietf-te-service-mapping-types@2020-11-02.yang" 873 module ietf-te-service-mapping-types { 874 yang-version 1.1; 875 namespace 876 "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; 877 prefix tsm-types; 879 /* Import inet-types */ 881 import ietf-inet-types { 882 prefix inet; 883 reference 884 "RFC 6991: Common YANG Data Types"; 885 } 887 /* Import inet-types */ 889 import ietf-te-types { 890 prefix te-types; 891 reference 892 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 893 } 895 /* Import network model */ 897 import ietf-network { 898 prefix nw; 899 reference 900 "RFC 8345: A YANG Data Model for Network Topologies"; 901 } 903 /* Import TE model */ 905 import ietf-te { 906 prefix te; 907 reference 908 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 909 Engineering Tunnels and Interfaces"; 910 } 912 /* Import VN model */ 914 import ietf-vn { 915 prefix vn; 916 reference 917 "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation"; 918 } 920 /* Import Routing */ 922 import ietf-routing { 923 prefix rt; 924 reference 925 "RFC 8349: A YANG Data Model for Routing Management"; 926 } 928 /* Import SR Policy */ 930 import ietf-sr-policy { 931 prefix sr-policy; 932 reference 933 "I-D.ietf-spring-sr-policy-yang: YANG Data Model for Segment 934 Routing Policy"; 935 } 937 organization 938 "IETF Traffic Engineering Architecture and Signaling (TEAS) 939 Working Group"; 940 contact 941 "WG Web: 942 WG List: 944 Editor: Young Lee 945 946 Editor: Dhruv Dhody 947 948 Editor: Qin Wu 949 "; 950 description 951 "This module contains a YANG module for TE & Service mapping 952 parameters and policies as a common grouping applicable to 953 variuous service models (e.g., L1CSM, L2SM, L3SM, etc.) 955 Copyright (c) 2020 IETF Trust and the persons identified as 956 authors of the code. All rights reserved. 958 Redistribution and use in source and binary forms, with or 959 without modification, is permitted pursuant to, and subject to 960 the license terms contained in, the Simplified BSD License set 961 forth in Section 4.c of the IETF Trust's Legal Provisions 962 Relating to IETF Documents 963 (https://trustee.ietf.org/license-info). 965 This version of this YANG module is part of RFC XXXX; see the 966 RFC itself for full legal notices. 968 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 969 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 970 'MAY', and 'OPTIONAL' in this document are to be interpreted as 971 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 972 they appear in all capitals, as shown here."; 974 revision 2020-11-02 { 975 description 976 "Initial revision."; 977 reference 978 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 979 } 981 /* 982 * Features 983 */ 985 feature template { 986 description 987 "Support TE mapping templates."; 988 } 990 feature sr-policy { 991 description 992 "Support SR Policy."; 993 } 995 /* 996 * Identity for map-type 997 */ 999 identity map-type { 1000 description 1001 "Base identity from which specific map types are derived."; 1002 } 1004 identity new { 1005 base map-type; 1006 description 1007 "The new VN/tunnels are binded to the service."; 1008 } 1010 identity hard-isolation { 1011 base new; 1012 description 1013 "Hard isolation."; 1014 } 1016 identity detnet-hard-isolation { 1017 base hard-isolation; 1018 description 1019 "Hard isolation with deterministic characteristics."; 1021 } 1023 identity soft-isolation { 1024 base new; 1025 description 1026 "Soft-isolation."; 1027 } 1029 identity select { 1030 base map-type; 1031 description 1032 "The VPN service selects an existing tunnel with no 1033 modification."; 1034 } 1036 identity modify { 1037 base map-type; 1038 description 1039 "The VPN service selects an existing tunnel and allows to modify 1040 the properties of the tunnel (e.g., b/w)"; 1041 } 1043 identity template { 1044 base map-type; 1045 description 1046 "The VPN service selects an TE mapping template with path 1047 constraints and optimization criteria"; 1048 } 1050 /* 1051 * Identity for availability-type 1052 */ 1054 identity availability-type { 1055 description 1056 "Base identity from which specific map types are derived."; 1057 } 1059 identity level-1 { 1060 base availability-type; 1061 description 1062 "level 1: 99.9999%"; 1063 } 1065 identity level-2 { 1066 base availability-type; 1067 description 1068 "level 2: 99.999%"; 1070 } 1072 identity level-3 { 1073 base availability-type; 1074 description 1075 "level 3: 99.99%"; 1076 } 1078 identity level-4 { 1079 base availability-type; 1080 description 1081 "level 4: 99.9%"; 1082 } 1084 identity level-5 { 1085 base availability-type; 1086 description 1087 "level 5: 99%"; 1088 } 1090 /* 1091 * Typedef 1092 */ 1094 typedef te-mapping-template-id { 1095 type inet:uri; 1096 description 1097 "Identifier for a TE mapping template. The precise 1098 structure of the te-mapping-template-id will be up 1099 to the implementation. The identifier SHOULD be 1100 chosen such that the same template will always be 1101 identified through the same identifier, even if the 1102 data model is instantiated in separate datastores."; 1103 } 1105 /* 1106 * Groupings 1107 */ 1109 grouping te-ref { 1110 description 1111 "The reference to TE."; 1112 choice te { 1113 description 1114 "The TE"; 1115 case vn { 1116 leaf-list vn-list { 1117 type leafref { 1118 path "/vn:vn/vn:vn-list/vn:vn-id"; 1119 } 1120 description 1121 "The reference to VN"; 1122 reference 1123 "RFC 8453: Framework for Abstraction and Control of TE 1124 Networks (ACTN)"; 1125 } 1126 } 1127 case te-topo { 1128 leaf vn-topology-id { 1129 type te-types:te-topology-id; 1130 description 1131 "An identifier to the TE Topology Model where the abstract 1132 nodes and links of the Topology can be found for Type 2 1133 VNS"; 1134 reference 1135 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1136 Topologies"; 1137 } 1138 leaf abstract-node { 1139 type leafref { 1140 path "/nw:networks/nw:network/nw:node/nw:node-id"; 1141 } 1142 description 1143 "A reference to the abstract node in TE Topology"; 1144 reference 1145 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1146 Topologies"; 1147 } 1148 } 1149 case te-tunnel { 1150 leaf-list te-tunnel-list { 1151 type te:tunnel-ref; 1152 description 1153 "Reference to TE Tunnels"; 1154 reference 1155 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1156 Engineering Tunnels and Interfaces"; 1157 } 1158 list sr-policy { 1159 if-feature "sr-policy"; 1160 key "policy-color-ref policy-endpoint-ref"; 1161 description 1162 "SR Policy"; 1163 leaf policy-color-ref { 1164 type leafref { 1165 path 1166 "/rt:routing/sr-policy:segment-routing" 1167 + "/sr-policy:traffic-engineering/sr-policy:policies" 1168 + "/sr-policy:policy/sr-policy:color"; 1169 } 1170 description 1171 "Reference to sr-policy color"; 1172 } 1173 leaf policy-endpoint-ref { 1174 type leafref { 1175 path 1176 "/rt:routing/sr-policy:segment-routing" 1177 + "/sr-policy:traffic-engineering/sr-policy:policies" 1178 + "/sr-policy:policy/sr-policy:endpoint"; 1179 } 1180 description 1181 "Reference to sr-policy endpoint"; 1182 } 1183 } 1184 } 1185 case te-mapping-template { 1186 if-feature "template"; 1187 leaf te-mapping-template-ref { 1188 type leafref { 1189 path "/tsm-types:te-mapping-templates/" 1190 + "tsm-types:te-mapping-template/tsm-types:id"; 1191 } 1192 description 1193 "An identifier to the TE Mapping Template where the TE 1194 constraints and optimization criteria are specified."; 1195 } 1196 } 1197 } 1198 } 1200 //grouping 1202 grouping te-endpoint-ref { 1203 description 1204 "The reference to TE endpoints."; 1205 choice te { 1206 description 1207 "The TE"; 1208 case vn { 1209 leaf-list ap-list { 1210 type leafref { 1211 path "/vn:ap/vn:access-point-list/vn:access-point-id"; 1212 } 1213 description 1214 "The reference to VN AP"; 1215 reference 1216 "RFC 8453: Framework for Abstraction and Control of TE 1217 Networks (ACTN)"; 1218 } 1219 } 1220 case te { 1221 leaf ltp { 1222 type te-types:te-tp-id; 1223 description 1224 "Reference LTP in the TE-topology"; 1225 reference 1226 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1227 Topologies"; 1228 } 1229 } 1230 } 1231 } 1233 //grouping 1235 grouping te-mapping { 1236 description 1237 "Mapping between Services and TE"; 1238 container te-mapping { 1239 description 1240 "Mapping between Services and TE"; 1241 leaf map-type { 1242 type identityref { 1243 base map-type; 1244 } 1245 description 1246 "Isolation Requirements, Tunnel Bind or 1247 Tunnel Selection"; 1248 } 1249 leaf availability-type { 1250 type identityref { 1251 base availability-type; 1252 } 1253 description 1254 "Availability Requirement for the Service"; 1255 } 1256 uses te-ref; 1257 } 1258 } 1260 //grouping 1261 container te-mapping-templates { 1262 description 1263 "The TE constraints and optimization criteria"; 1264 list te-mapping-template { 1265 key "id"; 1266 leaf id { 1267 type te-mapping-template-id; 1268 description 1269 "Identification of the Template to be used."; 1270 } 1271 leaf description { 1272 type string; 1273 description 1274 "Description of the template."; 1275 } 1276 leaf map-type { 1277 type identityref { 1278 base map-type; 1279 } 1280 must "0 = derived-from-or-self(.,'template')" { 1281 error-message "The map-type must be other than " 1282 + "TE mapping template"; 1283 } 1284 description 1285 "Map type for the VN/Tunnel creation/ 1286 selection."; 1287 } 1288 uses te-types:generic-path-constraints; 1289 uses te-types:generic-path-optimization; 1290 description 1291 "List for templates."; 1292 } 1293 } 1294 } 1296 1298 7.2. Service Models 1300 7.2.1. ietf-l3sm-te-service-mapping 1302 file "ietf-l3sm-te-service-mapping@2020-11-02.yang" 1303 module ietf-l3sm-te-service-mapping { 1304 yang-version 1.1; 1305 namespace 1306 "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; 1307 prefix l3-tsm; 1308 import ietf-te-service-mapping-types { 1309 prefix tsm-types; 1310 reference 1311 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1312 } 1313 import ietf-l3vpn-svc { 1314 prefix l3vpn-svc; 1315 reference 1316 "RFC 8299: YANG Data Model for L3VPN Service Delivery"; 1317 } 1319 organization 1320 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1321 Working Group"; 1322 contact 1323 "WG Web: 1324 WG List: 1326 Editor: Young Lee 1327 1328 Editor: Dhruv Dhody 1329 1330 Editor: Qin Wu 1331 "; 1332 description 1333 "This module contains a YANG module for the mapping of Layer 3 1334 Service Model (L3SM) to the TE and VN. 1336 Copyright (c) 2020 IETF Trust and the persons identified as 1337 authors of the code. All rights reserved. 1339 Redistribution and use in source and binary forms, with or 1340 without modification, is permitted pursuant to, and subject to 1341 the license terms contained in, the Simplified BSD License set 1342 forth in Section 4.c of the IETF Trust's Legal Provisions 1343 Relating to IETF Documents 1344 (https://trustee.ietf.org/license-info). 1346 This version of this YANG module is part of RFC XXXX; see the 1347 RFC itself for full legal notices. 1349 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1350 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1351 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1352 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1353 they appear in all capitals, as shown here."; 1355 revision 2020-11-02 { 1356 description 1357 "Initial revision."; 1358 reference 1359 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1360 } 1362 /* 1363 * Augmentation to L3SM 1364 */ 1366 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services" 1367 + "/l3vpn-svc:vpn-service" { 1368 description 1369 "L3SM augmented to include TE parameters and mapping"; 1370 container te-service-mapping { 1371 presence "Indicates L3 service to TE mapping"; 1372 description 1373 "Container to augment l3sm to TE parameters and mapping"; 1374 uses tsm-types:te-mapping; 1375 } 1376 } 1378 //augment 1380 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1381 + "/l3vpn-svc:site-network-accesses" 1382 + "/l3vpn-svc:site-network-access" { 1383 description 1384 "This augment is only valid for TE mapping of L3SM network-access 1385 to TE endpoints"; 1386 uses tsm-types:te-endpoint-ref; 1387 } 1389 //augment 1390 } 1392 1394 7.2.2. ietf-l2sm-te-service-mapping 1396 file "ietf-l2sm-te-service-mapping@2020-11-02.yang" 1397 module ietf-l2sm-te-service-mapping { 1398 yang-version 1.1; 1399 namespace 1400 "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; 1401 prefix l2-tsm; 1403 import ietf-te-service-mapping-types { 1404 prefix tsm-types; 1405 reference 1406 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1407 } 1408 import ietf-l2vpn-svc { 1409 prefix l2vpn-svc; 1410 reference 1411 "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network 1412 (L2VPN) Service Delivery"; 1413 } 1415 organization 1416 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1417 Working Group"; 1418 contact 1419 "WG Web: 1420 WG List: 1422 Editor: Young Lee 1423 1424 Editor: Dhruv Dhody 1425 1426 Editor: Qin Wu 1427 "; 1428 description 1429 "This module contains a YANG module for the mapping of Layer 2 1430 Service Model (L2SM) to the TE and VN. 1432 Copyright (c) 2020 IETF Trust and the persons identified as 1433 authors of the code. All rights reserved. 1435 Redistribution and use in source and binary forms, with or 1436 without modification, is permitted pursuant to, and subject to 1437 the license terms contained in, the Simplified BSD License set 1438 forth in Section 4.c of the IETF Trust's Legal Provisions 1439 Relating to IETF Documents 1440 (https://trustee.ietf.org/license-info). 1442 This version of this YANG module is part of RFC XXXX; see the 1443 RFC itself for full legal notices. 1445 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1446 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1447 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1448 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1449 they appear in all capitals, as shown here."; 1451 revision 2020-11-02 { 1452 description 1453 "Initial revision."; 1454 reference 1455 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1456 } 1458 /* 1459 * Augmentation to L2SM 1460 */ 1462 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/" 1463 + "l2vpn-svc:vpn-service" { 1464 description 1465 "L2SM augmented to include TE parameters and mapping"; 1466 container te-service-mapping { 1467 presence "indicates L2 service to te mapping"; 1468 description 1469 "Container to augment L2SM to TE parameters and mapping"; 1470 uses tsm-types:te-mapping; 1471 } 1472 } 1474 //augment 1476 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1477 + "/l2vpn-svc:site-network-accesses" 1478 + "/l2vpn-svc:site-network-access" { 1479 description 1480 "This augment is only valid for TE mapping of L2SM network-access 1481 to TE endpoints"; 1482 uses tsm-types:te-endpoint-ref; 1483 } 1485 //augment 1486 } 1488 1490 7.2.3. ietf-l1csm-te-service-mapping 1492 file "ietf-l1csm-te-service-mapping@2020-11-02.yang" 1493 module ietf-l1csm-te-service-mapping { 1494 yang-version 1.1; 1495 namespace 1496 "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; 1497 prefix l1-tsm; 1498 import ietf-te-service-mapping-types { 1499 prefix tsm-types; 1500 reference 1501 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1502 } 1503 import ietf-l1csm { 1504 prefix l1csm; 1505 reference 1506 "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity 1507 Service Model (L1CSM)"; 1508 } 1510 organization 1511 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1512 Working Group"; 1513 contact 1514 "WG Web: 1515 WG List: 1517 Editor: Young Lee 1518 1519 Editor: Dhruv Dhody 1520 1521 Editor: Qin Wu 1522 "; 1523 description 1524 "This module contains a YANG module for the mapping of 1525 Layer 1 Connectivity Service Module (L1CSM) to the TE and VN 1527 Copyright (c) 2020 IETF Trust and the persons identified as 1528 authors of the code. All rights reserved. 1530 Redistribution and use in source and binary forms, with or 1531 without modification, is permitted pursuant to, and subject to 1532 the license terms contained in, the Simplified BSD License set 1533 forth in Section 4.c of the IETF Trust's Legal Provisions 1534 Relating to IETF Documents 1535 (https://trustee.ietf.org/license-info). 1537 This version of this YANG module is part of RFC XXXX; see the 1538 RFC itself for full legal notices. 1540 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1541 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1542 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1543 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1544 they appear in all capitals, as shown here."; 1546 revision 2020-11-02 { 1547 description 1548 "Initial revision."; 1549 reference 1550 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1551 } 1553 /* 1554 * Augmentation to L1CSM 1555 */ 1557 augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" { 1558 description 1559 "L1CSM augmented to include TE parameters and mapping"; 1560 container te-service-mapping { 1561 presence "Indicates L1 service to TE mapping"; 1562 description 1563 "Container to augment L1CSM to TE parameters and mapping"; 1564 uses tsm-types:te-mapping; 1565 } 1566 } 1568 //augment 1570 augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/" 1571 + "l1csm:uni" { 1572 description 1573 "This augment is only valid for TE mapping of L1CSM UNI to TE 1574 endpoints"; 1575 uses tsm-types:te-endpoint-ref; 1576 } 1578 //augment 1579 } 1581 1583 7.3. Network Models 1585 7.3.1. ietf-l3nm-te-service-mapping 1587 file "ietf-l3nm-te-service-mapping@2020-11-02.yang" 1588 module ietf-l3nm-te-service-mapping { 1589 yang-version 1.1; 1590 namespace 1591 "urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping"; 1592 prefix l3nm-tsm; 1593 import ietf-te-service-mapping-types { 1594 prefix tsm-types; 1595 reference 1596 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1597 } 1598 import ietf-l3vpn-ntw { 1599 prefix l3vpn-ntw; 1600 reference 1601 "I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model"; 1602 } 1604 organization 1605 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1606 Working Group"; 1607 contact 1608 "WG Web: 1609 WG List: 1611 Editor: Young Lee 1612 1613 Editor: Dhruv Dhody 1614 1615 Editor: Qin Wu 1616 "; 1617 description 1618 "This module contains a YANG module for the mapping of Layer 3 1619 Network Model (L3NM) to the TE and VN. 1621 Copyright (c) 2020 IETF Trust and the persons identified as 1622 authors of the code. All rights reserved. 1624 Redistribution and use in source and binary forms, with or 1625 without modification, is permitted pursuant to, and subject to 1626 the license terms contained in, the Simplified BSD License set 1627 forth in Section 4.c of the IETF Trust's Legal Provisions 1628 Relating to IETF Documents 1629 (https://trustee.ietf.org/license-info). 1631 This version of this YANG module is part of RFC XXXX; see the 1632 RFC itself for full legal notices. 1634 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1635 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1636 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1637 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1638 they appear in all capitals, as shown here."; 1640 revision 2020-11-02 { 1641 description 1642 "Initial revision."; 1643 reference 1644 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1645 } 1647 /* 1648 * Augmentation to L3NM 1649 */ 1651 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1652 + "/l3vpn-ntw:vpn-service" { 1653 description 1654 "L3SM augmented to include TE parameters and mapping"; 1655 container te-service-mapping { 1656 presence "Indicates L3 network to TE mapping"; 1657 description 1658 "Container to augment l3nm to TE parameters and mapping"; 1659 uses tsm-types:te-mapping; 1660 } 1661 } 1663 //augment 1665 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1666 + "/l3vpn-ntw:vpn-service" 1667 + "/l3vpn-ntw:vpn-nodes/l3vpn-ntw:vpn-node" 1668 + "/l3vpn-ntw:vpn-network-accesses" 1669 + "/l3vpn-ntw:vpn-network-access" { 1670 description 1671 "This augment is only valid for TE mapping of L3NM network-access 1672 to TE endpoints"; 1673 uses tsm-types:te-endpoint-ref; 1674 } 1676 //augment 1677 } 1679 1681 7.3.2. ietf-l2nm-te-service-mapping 1683 file "ietf-l2nm-te-service-mapping@2020-11-02.yang" 1684 module ietf-l2nm-te-service-mapping { 1685 yang-version 1.1; 1686 namespace 1687 "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping"; 1688 prefix l2nm-tsm; 1689 import ietf-te-service-mapping-types { 1690 prefix tsm-types; 1691 reference 1692 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1693 } 1694 import ietf-l2vpn-ntw { 1695 prefix l2vpn-ntw; 1696 reference 1697 "I-D.ietf-l2nm: A Layer 2 VPN Network YANG Model"; 1698 } 1700 organization 1701 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1702 Working Group"; 1703 contact 1704 "WG Web: 1705 WG List: 1707 Editor: Young Lee 1708 1709 Editor: Dhruv Dhody 1710 1711 Editor: Qin Wu 1712 "; 1713 description 1714 "This module contains a YANG module for the mapping of Layer 2 1715 Network Model (L2NM) to the TE and VN. 1717 Copyright (c) 2020 IETF Trust and the persons identified as 1718 authors of the code. All rights reserved. 1720 Redistribution and use in source and binary forms, with or 1721 without modification, is permitted pursuant to, and subject to 1722 the license terms contained in, the Simplified BSD License set 1723 forth in Section 4.c of the IETF Trust's Legal Provisions 1724 Relating to IETF Documents 1725 (https://trustee.ietf.org/license-info). 1727 This version of this YANG module is part of RFC XXXX; see the 1728 RFC itself for full legal notices. 1730 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1731 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1732 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1733 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1734 they appear in all capitals, as shown here."; 1736 revision 2020-11-02 { 1737 description 1738 "Initial revision."; 1739 reference 1740 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1741 } 1743 /* 1744 * Augmentation to L2NM 1745 */ 1747 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1748 + "/l2vpn-ntw:vpn-service" { 1749 description 1750 "L2SM augmented to include TE parameters and mapping"; 1751 container te-service-mapping { 1752 presence "Indicates L2 network to TE mapping"; 1753 description 1754 "Container to augment l2nm to TE parameters and mapping"; 1755 uses tsm-types:te-mapping; 1756 } 1757 } 1759 //augment 1761 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1762 + "/l2vpn-ntw:vpn-service" 1763 + "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node" 1764 + "/l2vpn-ntw:vpn-network-accesses" 1765 + "/l2vpn-ntw:vpn-network-access" { 1766 description 1767 "This augment is only valid for TE mapping of L2NM network-access 1768 to TE endpoints"; 1769 uses tsm-types:te-endpoint-ref; 1770 } 1772 //augment 1773 } 1775 1777 8. Security Considerations 1779 The YANG modules defined in this document is designed to be accessed 1780 via network management protocol such as NETCONF [RFC6241] or RESTCONF 1781 [RFC8040]. The lowest NETCONF layer is the secure transport layer 1782 and the mandatory-to-implement secure transport is SSH [RFC6242]. 1783 The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement 1784 secure transport is TLS [RFC8446] 1785 The NETCONF access control model [RFC8341] provides the means to 1786 restrict access for particular NETCONF or RESTCONF users to a pre- 1787 configured subset of all available NETCONF or RESTCONF protocol 1788 operations and content. 1790 There are a number of data nodes defined in the YANG moduleS which 1791 are writable/creatable/deletable (i.e., config true, which is the 1792 default). These data nodes may be considered sensitive or vulnerable 1793 in some network environments. Write operations (e.g., ) 1794 to these data nodes without proper protection can have a negative 1795 effect on network operations. These are the subtrees and data nodes 1796 and their sensitivity/vulnerability: 1798 o /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1799 - configure TE Service mapping. 1801 o /l3vpn-svc/sites/site/site-network-accesses/site-network-access/ 1802 te/ - configure TE Endpoint mapping. 1804 o /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1805 - configure TE Service mapping. 1807 o /l2vpn-svc/sites/site/site-network-accesses/site-network-access/ 1808 te/ - configure TE Endpoint mapping. 1810 o /l1-connectivity/services/service/te-service-mapping/te-mapping/ - 1811 configure TE Service mapping. 1813 o /l1-connectivity/access/unis/uni/te/ - configure TE Endpoint 1814 mapping. 1816 o /l3vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1817 - configure TE Network mapping. 1819 o /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1820 network-accesses/vpn-network-access/te/ - configure TE Endpoint 1821 mapping. 1823 o /l2vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1824 - configure TE Network mapping. 1826 o /l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1827 network-accesses/vpn-network-access/te/ - configure TE Endpoint 1828 mapping. 1830 Unauthorized access to above list can adversely affect the VPN 1831 service. 1833 Some of the readable data nodes in the YANG module may be considered 1834 sensitive or vulnerable in some network environments. It is thus 1835 important to control read access (e.g., via get, get-config, or 1836 notification) to these data nodes. The TE related parameters 1837 attached to the VPN service can leak sensitive information about the 1838 network. This is apploicable to all elements in the yang models 1839 defined in this document. 1841 This document has no RPC defined. 1843 9. IANA Considerations 1845 This document request the IANA to register four URIs in the "IETF XML 1846 Registry" [RFC3688]. Following the format in RFC 3688, the following 1847 registrations are requested - 1849 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1850 Registrant Contact: The IESG. 1851 XML: N/A, the requested URI is an XML namespace. 1853 URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 1854 Registrant Contact: The IESG. 1855 XML: N/A, the requested URI is an XML namespace. 1857 URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 1858 Registrant Contact: The IESG. 1859 XML: N/A, the requested URI is an XML namespace. 1861 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 1862 Registrant Contact: The IESG. 1863 XML: N/A, the requested URI is an XML namespace. 1865 URI: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 1866 Registrant Contact: The IESG. 1867 XML: N/A, the requested URI is an XML namespace. 1869 URI: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 1870 Registrant Contact: The IESG. 1871 XML: N/A, the requested URI is an XML namespace. 1873 This document request the IANA to register four YANG modules in the 1874 "YANG Module Names" registry [RFC6020], as follows - 1875 Name: ietf-te-service-mapping-types 1876 Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1877 Prefix: tsm-types 1878 Reference: [This.I-D] 1880 Name: ietf-l3sm-te-service-mapping 1881 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 1882 Prefix: l3-tsm 1883 Reference: [This.I-D] 1885 Name: ietf-l2sm-te-service-mapping 1886 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 1887 Prefix: l2-tsm 1888 Reference: [This.I-D] 1890 Name: ietf-l1csm-te-service-mapping 1891 Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 1892 Prefix: l1-tsm 1893 Reference: [This.I-D] 1895 Name: ietf-l3nm-te-service-mapping 1896 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 1897 Prefix: l3nm-tsm 1898 Reference: [This.I-D] 1900 Name: ietf-l2nm-te-service-mapping 1901 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 1902 Prefix: l2nm-tsm 1903 Reference: [This.I-D] 1905 10. Acknowledgements 1907 We thank Diego Caviglia, and Igor Bryskin for useful discussions and 1908 motivation for this work. 1910 11. References 1912 11.1. Normative References 1914 [I-D.ietf-ccamp-l1csm-yang] 1915 Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli, 1916 "A YANG Data Model for L1 Connectivity Service Model 1917 (L1CSM)", draft-ietf-ccamp-l1csm-yang-12 (work in 1918 progress), September 2020. 1920 [I-D.ietf-opsawg-l2nm] 1921 barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil, 1922 L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- 1923 ietf-opsawg-l2nm-00 (work in progress), July 2020. 1925 [I-D.ietf-opsawg-l3sm-l3nm] 1926 barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. 1927 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 1928 opsawg-l3sm-l3nm-05 (work in progress), October 2020. 1930 [I-D.ietf-spring-sr-policy-yang] 1931 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 1932 Matsushima, S., and V. Beeram, "YANG Data Model for 1933 Segment Routing Policy", draft-ietf-spring-sr-policy- 1934 yang-00 (work in progress), September 2020. 1936 [I-D.ietf-teas-actn-vn-yang] 1937 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1938 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1939 teas-actn-vn-yang-09 (work in progress), July 2020. 1941 [I-D.ietf-teas-yang-te] 1942 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1943 "A YANG Data Model for Traffic Engineering Tunnels, Label 1944 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 1945 (work in progress), July 2020. 1947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1948 Requirement Levels", BCP 14, RFC 2119, 1949 DOI 10.17487/RFC2119, March 1997, 1950 . 1952 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1953 DOI 10.17487/RFC3688, January 2004, 1954 . 1956 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1957 the Network Configuration Protocol (NETCONF)", RFC 6020, 1958 DOI 10.17487/RFC6020, October 2010, 1959 . 1961 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1962 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1963 . 1965 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1966 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1967 . 1969 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1970 Ceccarelli, D., and X. Zhang, "Problem Statement and 1971 Architecture for Information Exchange between 1972 Interconnected Traffic-Engineered Networks", BCP 206, 1973 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1974 . 1976 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1977 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1978 . 1980 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1981 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1982 . 1984 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1985 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1986 May 2017, . 1988 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1989 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1990 DOI 10.17487/RFC8299, January 2018, 1991 . 1993 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1994 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1995 . 1997 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1998 Access Control Model", STD 91, RFC 8341, 1999 DOI 10.17487/RFC8341, March 2018, 2000 . 2002 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2003 and R. Wilton, "Network Management Datastore Architecture 2004 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2005 . 2007 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2008 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2009 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2010 2018, . 2012 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 2013 Routing Management (NMDA Version)", RFC 8349, 2014 DOI 10.17487/RFC8349, March 2018, 2015 . 2017 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2018 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2019 . 2021 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2022 Data Model for Layer 2 Virtual Private Network (L2VPN) 2023 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2024 2018, . 2026 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2027 "Common YANG Data Types for Traffic Engineering", 2028 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2029 . 2031 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2032 O. Gonzalez de Dios, "YANG Data Model for Traffic 2033 Engineering (TE) Topologies", RFC 8795, 2034 DOI 10.17487/RFC8795, August 2020, 2035 . 2037 11.2. Informative References 2039 [I-D.ietf-teas-actn-yang] 2040 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 2041 Shin, J., and S. Belotti, "Applicability of YANG models 2042 for Abstraction and Control of Traffic Engineered 2043 Networks", draft-ietf-teas-actn-yang-06 (work in 2044 progress), August 2020. 2046 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2047 and A. Bierman, Ed., "Network Configuration Protocol 2048 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2049 . 2051 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 2052 Classification", RFC 8199, DOI 10.17487/RFC8199, July 2053 2017, . 2055 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2056 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2057 . 2059 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2060 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2061 DOI 10.17487/RFC8453, August 2018, 2062 . 2064 Appendix A. Contributor Addresses 2066 Adrian Farrel 2067 Old Dog Consulting 2069 EMail: adrian@olddog.co.uk 2071 Italo Busi 2072 Huawei Technologies 2074 EMail: Italo.Busi@huawei.com 2076 Haomian Zheng 2077 Huawei Technologies 2079 EMail: zhenghaomian@huawei.com 2081 Anton Snitser 2082 Sedonasys 2084 EMail: antons@sedonasys.com 2086 SAMIER BARGUIL GIRALDO 2087 Telefonica 2089 EMail: samier.barguilgiraldo.ext@telefonica.com 2091 Oscar Gonzalez de Dios 2092 Telefonica 2094 EMail: oscar.gonzalezdedios@telefonica.com 2096 Carlo Perocchio 2097 Ericsson 2099 EMail: carlo.perocchio@ericsson.com 2101 Kenichi Ogaki 2102 KDDI 2103 Email: ke-oogaki@kddi.com 2105 Authors' Addresses 2107 Young Lee (editor) 2108 Samsung Electronics 2110 Email: younglee.tx@gmail.com 2111 Dhruv Dhody (editor) 2112 Huawei Technologies 2113 Divyashree Techno Park, Whitefield 2114 Bangalore, Karnataka 560066 2115 India 2117 Email: dhruv.ietf@gmail.com 2119 Giuseppe Fioccola 2120 Huawei Technologies 2122 Email: giuseppe.fioccola@huawei.com 2124 Qin Wu (editor) 2125 Huawei Technologies 2127 Email: bill.wu@huawei.com 2129 Daniele Ceccarelli 2130 Ericsson 2131 Torshamnsgatan,48 2132 Stockholm, Sweden 2134 Email: daniele.ceccarelli@ericsson.com 2136 Jeff Tantsura 2137 Apstra 2139 Email: jefftant.ietf@gmail.com