idnits 2.17.1 draft-ietf-teas-te-service-mapping-yang-04.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 643 has weird spacing: '...ic-type ide...' == Line 647 has weird spacing: '...w usage ide...' == Line 653 has weird spacing: '...rw name str...' == Line 660 has weird spacing: '...w usage ide...' == Line 678 has weird spacing: '...er-type ide...' == (5 more instances...) -- The document date (July 13, 2020) is 1381 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.raza-spring-sr-policy-yang' is defined on line 1955, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-11 == 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-03 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-08 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-23 == Outdated reference: A later version (-03) exists of draft-raza-spring-sr-policy-yang-02 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-05 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: January 14, 2021 G. Fioccola 6 Q. Wu, Ed. 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 J. Tantsura 11 Apstra 12 July 13, 2020 14 Traffic Engineering (TE) and Service Mapping Yang Model 15 draft-ietf-teas-te-service-mapping-yang-04 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 January 14, 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 . . . . . . . . . . . . . . . . . . . . . . . . 16 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.raza-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 [I-D.ietf-teas-yang-te-topo], and 369 this relationship is recorded by the Augmented LxSM Model. The model 370 also supports a mapping between a service model and TE-topology or a 371 TE-tunnel. 373 The YANG models defined in this document conforms to the Network 374 Management Datastore Architecture (NMDA) [RFC8342]. 376 3.1. Forward Compatibility 378 The YANG module defined in this document supports three existing 379 service models via augmenting while sharing the common TE and Service 380 Mapping Types. 382 It is possible that new service models will be defined at some future 383 time and that it will be desirable to map them to underlying TE 384 constructs in the same way as the three existing models are 385 augmented. 387 3.2. TE and Network Models 389 The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN 390 Service in the Service Provider Network. It containts information of 391 the Service Provider network and might include allocated resources. 392 It can be used by network controllers to manage and control the VPN 393 Service configuration in the Service Provider network. 395 Similar to service model, the existing network models (i.e., 396 [I-D.ietf-opsawg-l3sm-l3nm], and [I-D.ietf-opsawg-l2nm]) are 397 augmented to include the TE and Service mapping parameters. Figure 2 398 shows the scope of the Augmented LxNM Model. 400 +--------------+ +----------------------+ +----------+ 401 | LxNM |o-------| | . . . . | ACTN VN | 402 +--------------+ augment| | +----------+ 403 | | +----------+ 404 +--------------+ | Augmented LxNM Model | . . . . | TE-topo | 405 | TE & Service |------->| | +----------+ 406 | Mapping Types| import | | +----------+ 407 +--------------+ | | . . . . | TE-tunnel| 408 +----------------------+ +----------+ 409 reference 411 Figure 2: Augmented LxNM Model 413 The Augmented LxNM model (where x=2,3) augments the basic LxNM model 414 while importing the common TE mapping related parameters (defined in 415 Section 2) grouping information from TE and Service Mapping Types. 416 The role of the augmented LxNM network model is to expose the mapping 417 relationship between network models and TE models. 419 4. L3VPN Architecture in the ACTN Context 421 Figure 3 shows the architectural context of this document referencing 422 the ACTN components and interfaces. 424 +----------------------------+ 425 | Customer Service Manager | 426 | +-----------------------+ | 427 | | CNC + | 428 | +-+-------------------+-+ | 429 +----|-------------------|---+ 430 | | 431 |CMI(Augmented L3SM)|CMI(VN) 432 | | 433 +----------------|-------------------|----+ 434 | +--------------|-----------------+ | | 435 | | MDSC | | | | 436 | | | | | | 437 | | +-----------+--------------+ | | | 438 TE-Svc-Map<------+ Service Mapping Function | | | | 439 | | +-----------+--------------+ | | | 440 | | | | | | 441 | +-------+------|-----------------+ | | 442 | | | | | 443 | | |CMI(VN) | | 444 | | | | | 445 | | +--|-------------------|--+ | 446 | | | | MDSC | | | 447 | | | ++-------------------++ | | 448 | | | + Service Mapping +---->TE-Svc-Map 449 | | | ++----------+---------+ | | 450 | | +--|----------|-----------+ | 451 +---------|------|----------|-------------+ 452 | | | 453 | +----+--------+ | 454 | | | | 455 MPI(VPN / TE models)| | | |MPI(TE / L1 models) 456 | | | | 457 +-----|-|---+ +-----|-|----+ 458 IP/MPLS | +--+-+-+ | | +--+-+-+ | Optical Domain 459 Domain | | PNC1 | | | | PNC2 | | Controller 460 Controller | +--+---+ | | +--+---+ | 461 +-----|-----+ +-----|------+ 462 | | 463 V | SBI 464 +---------------------+ | 465 / IP/MPLS Network \ | 466 +-------------------------+ | 467 V 468 +---------------------+ 469 / Optical Network \ 470 +-------------------------+ 472 Figure 3: L3VPN Architecture from the IP+Optical Network Perspective 474 There are three main entities in the ACTN architecture and shown in 475 Figure 3. 477 o CNC: The Customer Network Controller is responsible for generating 478 service requests. In the context of an L3VPN, the CNC uses the 479 Augmented L3SM to express the service request and communicate it 480 to the network operator. 482 o MDSC: This entity is responsible for coordinating a L3VPN service 483 request (expressed via the Augmented L3SM) with the IP/MPLS PNC 484 and the Transport PNC. For TE services, one of the key 485 responsibilities of the MDSC is to coordinate with both the IP PNC 486 and the Transport PNC for the mapping of the Augmented L3VPN 487 Service Model to the ACTN VN model. In the VN/TE-tunnel binding 488 case, the MDSC will need to coordinate with the Transport PNC to 489 dynamically create the TE-tunnels in the transport network as 490 needed. These tunnels are added as links in the IP/MPLS Layer 491 topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 492 tunnels in the IP/MPLS layer, as part of the ACTN VN creation. 494 o PNC: The Provisioning Network Controller is responsible for 495 configuring and operating the network devices. Figure 2 shows two 496 distinct PNCs. 498 * IP/MPLS PNC (PNC1): This entity is responsible for device 499 configuration to create PE-PE L3VPN tunnels for the VPN 500 customer and for the configuration of the L3VPN VRF on the PE 501 nodes. Each network element would select a tunnel based on the 502 configuration. 504 * Transport PNC (PNC2): This entity is responsible for device 505 configuration for TE tunnels in the transport networks. 507 There are four main interfaces shown in Figure 2. 509 o CMI: The CNC-MDSC Interface is used to communicate service 510 requests from the customer to the operator. The requests may be 511 expressed as Augmented VPN service requests (L2SM, L3SM), as 512 connectivity requests (L1CSM), or as virtual network requests 513 (ACTN VN). 515 o MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate 516 networks under the control of PNCs. The requests on this 517 interface may use TE tunnel models, TE topology models, VPN 518 network configuration models or layer one connectivity models. 520 o SBI: The Southbound Interface is used by the PNC to control 521 network devices and is out of scope for this document. 523 The TE Service Mapping Model as described in this document can be 524 used to see the mapping between service models and VN models and TE 525 Tunnel/Topology models. That mapping may occur in the CNC if a 526 service request is mapped to a VN request. Or it may occur in the 527 MDSC where a service request is mapped to a TE tunnel, TE topology, 528 or VPN network configuration model. The TE Service Mapping Model may 529 be read from the CNC or MDSC to understand how the mapping has been 530 made and to see the purpose for which network resources are used. 532 As shown in Figure 2, the MDSC may be used recursively. For example, 533 the CNC might map a L3SM request to a VN request that it sends to a 534 recursive MDSC. 536 The high-level control flows for one example are as follows: 538 1. A customer asks for an L3VPN between CE1 and CE2 using the 539 Augmented L3SM model. 541 2. The MDSC considers the service request and local policy to 542 determine if it needs to create a new VN or any TE Topology, and 543 if that is the case, ACTN VN YANG [I-D.ietf-teas-actn-vn-yang] is 544 used to configure a new VN based on this VPN and map the VPN 545 service to the ACTN VN. In case an existing tunnel is to be 546 used, each device will select which tunnel to use and populate 547 this mapping information. 549 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 550 PNC to create a PE-PE tunnel in the IP network mapped to a TE 551 tunnel in the transport network by providing the inter-layer 552 access points and tunnel requirements. The specific service 553 information is passed to the IP/MPLS PNC for the actual VPN 554 configuration and activation. 556 A. The Transport PNC creates the corresponding TE tunnel 557 matching with the access point and egress point. 558 B. The IP/MPLS PNC maps the VPN ID with the corresponding TE 559 tunnel ID to bind these two IDs. 561 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 562 customer. This is not in the scope of this document. 564 4.1. Service Mapping 566 Augmented L3SM and L2SM can be used to request VPN service creation 567 including the creation of sites and corresponding site network access 568 connection between CE and PE. A VPN-ID is used to identify each VPN 569 service ordered by the customer. The ACTN VN can be used further to 570 establish PE-to-PE connectivity between VPN sites belonging to the 571 same VPN service. A VN-ID is used to identify each virtual network 572 established between VPN sites. 574 Once the ACTN VN has been established over the TE network (maybe a 575 new VN, maybe modification of an existing VN, or maybe the use of an 576 unmodified existing VN), the mapping between the VPN service and the 577 ACTN VN service can be created. 579 4.2. Site Mapping 581 The elements in Augmented L3SM and L2SM define site location 582 parameters and constraints such as distance and access diversity that 583 can influence the placement of network attachment points (i.e, 584 virtual network access points (VNAP)). To achieve this, a central 585 directory can be set up to establish the mapping between location 586 parameters and constraints and network attachment point location. 587 Suppose multiple attachment points are matched, the management system 588 can use constraints or other local policy to select the best 589 candidate network attachment points. 591 After a network attachment point is selected, the mapping between VPN 592 site and VNAP can be established as shown in Table 1. 594 +-------+---------+------------------+------------------------+-----+ 595 | Site | Site | Location | Access Diversity | PE | 596 | | Network | (Address, Postal | (Constraint-Type, | | 597 | | Access | Code, State, | Group-id,Target Group- | | 598 | | | City,Country | id) | | 599 | | | Code) | | | 600 +-------+---------+------------------+------------------------+-----+ 601 | SITE1 | ACCESS1 | (,,US,NewYork,) | (10,PE-Diverse,10) | PE1 | 602 +-------+---------+------------------+------------------------+-----+ 603 | SITE2 | ACCESS2 | (,,CN,Beijing,) | (10,PE-Diverse,10) | PE2 | 604 +-------+---------+------------------+------------------------+-----+ 605 | SITE3 | ACCESS3 | (,,UK,London, ) | (12,same-PE,12) | PE4 | 606 +-------+---------+------------------+------------------------+-----+ 607 | SITE4 | ACCESS4 | (,,FR,Paris,) | (20,Bearer-Diverse,20) | PE7 | 608 +-------+---------+------------------+------------------------+-----+ 610 Table 2: : Mapping Between VPN Site and VNAP 612 5. Applicability of TE-Service Mapping in Generic context 614 As discussed in the Introduction Section, the models presented in 615 this document are also applicable generically outside of the ACTN 616 architecture. [RFC8309] defines Customer Service Model between 617 Customer and Service Orchestrator and Service Delivery Model between 618 Service Orchestrator and Network Orchestrator(s). TE-Service mapping 619 models defined in this document can be regarded primarily as Customer 620 Service Model and secondarily as Service Deliver Model. 622 6. YANG Data Trees 624 6.1. Service Mapping Types 626 module: ietf-te-service-mapping-types 627 +--rw te-mapping-templates 628 +--rw te-mapping-template* [id] 629 +--rw id te-mapping-template-id 630 +--rw description? string 631 +--rw map-type? identityref 632 +--rw path-constraints 633 | +--rw te-bandwidth 634 | | +--rw (technology)? 635 | | +--:(generic) 636 | | +--rw generic? te-bandwidth 637 | +--rw link-protection? identityref 638 | +--rw setup-priority? uint8 639 | +--rw hold-priority? uint8 640 | +--rw signaling-type? identityref 641 | +--rw path-metric-bounds 642 | | +--rw path-metric-bound* [metric-type] 643 | | +--rw metric-type identityref 644 | | +--rw upper-bound? uint64 645 | +--rw path-affinities-values 646 | | +--rw path-affinities-value* [usage] 647 | | +--rw usage identityref 648 | | +--rw value? admin-groups 649 | +--rw path-affinity-names 650 | | +--rw path-affinity-name* [usage] 651 | | +--rw usage identityref 652 | | +--rw affinity-name* [name] 653 | | +--rw name string 654 | +--rw path-srlgs-lists 655 | | +--rw path-srlgs-list* [usage] 656 | | +--rw usage identityref 657 | | +--rw values* srlg 658 | +--rw path-srlgs-names 659 | | +--rw path-srlgs-name* [usage] 660 | | +--rw usage identityref 661 | | +--rw names* string 662 | +--rw disjointness? te-path-disjointness 663 +--rw optimizations 664 +--rw (algorithm)? 665 +--:(metric) {path-optimization-metric}? 666 | +--rw optimization-metric* [metric-type] 667 | | +--rw metric-type 668 | | | identityref 669 | | +--rw weight? uint8 670 | | +--rw explicit-route-exclude-objects 671 | | | +--rw route-object-exclude-object* [index] 672 | | | ... 673 | | +--rw explicit-route-include-objects 674 | | +--rw route-object-include-object* [index] 675 | | ... 676 | +--rw tiebreakers 677 | +--rw tiebreaker* [tiebreaker-type] 678 | +--rw tiebreaker-type identityref 679 +--:(objective-function) 680 {path-optimization-objective-function}? 681 +--rw objective-function 682 +--rw objective-function-type? identityref 684 6.2. Service Models 686 6.2.1. L3SM 688 module: ietf-l3sm-te-service-mapping 689 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services 690 /l3vpn-svc:vpn-service: 691 +--rw te-service-mapping! 692 +--rw te-mapping 693 +--rw map-type? identityref 694 +--rw availability-type? identityref 695 +--rw (te)? 696 +--:(vn) 697 | +--rw vn-ref? 698 | -> /vn:vn/vn-list/vn-id 699 +--:(te-topo) 700 | +--rw vn-topology-id? 701 | | te-types:te-topology-id 702 | +--rw abstract-node? 703 | -> /nw:networks/network/node/node-id 704 +--:(te-tunnel) 705 | +--rw te-tunnel-list* te:tunnel-ref 706 | +--rw sr-policy* 707 | [policy-color-ref policy-endpoint-ref] 708 | {sr-policy}? 709 | +--rw policy-color-ref leafref 710 | +--rw policy-endpoint-ref leafref 711 +--:(te-mapping-template) {template}? 712 +--rw te-mapping-template-ref? leafref 713 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site 714 /l3vpn-svc:site-network-accesses 715 /l3vpn-svc:site-network-access: 716 +--rw (te)? 717 +--:(vn) 718 | +--rw vn-ref? 719 | -> /vn:ap/access-point-list/access-point-id 720 +--:(te) 721 +--rw ltp? te-types:te-tp-id 723 6.2.2. L2SM 724 module: ietf-l2sm-te-service-mapping 725 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services 726 /l2vpn-svc:vpn-service: 727 +--rw te-service-mapping! 728 +--rw te-mapping 729 +--rw map-type? identityref 730 +--rw availability-type? identityref 731 +--rw (te)? 732 +--:(vn) 733 | +--rw vn-ref? 734 | -> /vn:vn/vn-list/vn-id 735 +--:(te-topo) 736 | +--rw vn-topology-id? 737 | | te-types:te-topology-id 738 | +--rw abstract-node? 739 | -> /nw:networks/network/node/node-id 740 +--:(te-tunnel) 741 | +--rw te-tunnel-list* te:tunnel-ref 742 | +--rw sr-policy* 743 | [policy-color-ref policy-endpoint-ref] 744 | {sr-policy}? 745 | +--rw policy-color-ref leafref 746 | +--rw policy-endpoint-ref leafref 747 +--:(te-mapping-template) {template}? 748 +--rw te-mapping-template-ref? leafref 749 augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site 750 /l2vpn-svc:site-network-accesses 751 /l2vpn-svc:site-network-access: 752 +--rw (te)? 753 +--:(vn) 754 | +--rw vn-ref? 755 | -> /vn:ap/access-point-list/access-point-id 756 +--:(te) 757 +--rw ltp? te-types:te-tp-id 759 6.2.3. L1CSM 760 module: ietf-l1csm-te-service-mapping 761 augment /l1csm:l1-connectivity/l1csm:services/l1csm:service: 762 +--rw te-service-mapping! 763 +--rw te-mapping 764 +--rw map-type? identityref 765 +--rw availability-type? identityref 766 +--rw (te)? 767 +--:(vn) 768 | +--rw vn-ref? 769 | -> /vn:vn/vn-list/vn-id 770 +--:(te-topo) 771 | +--rw vn-topology-id? 772 | | te-types:te-topology-id 773 | +--rw abstract-node? 774 | -> /nw:networks/network/node/node-id 775 +--:(te-tunnel) 776 | +--rw te-tunnel-list* te:tunnel-ref 777 | +--rw sr-policy* 778 | [policy-color-ref policy-endpoint-ref] 779 | {sr-policy}? 780 | +--rw policy-color-ref leafref 781 | +--rw policy-endpoint-ref leafref 782 +--:(te-mapping-template) {template}? 783 +--rw te-mapping-template-ref? leafref 784 augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni: 785 +--rw (te)? 786 +--:(vn) 787 | +--rw vn-ref? 788 | -> /vn:ap/access-point-list/access-point-id 789 +--:(te) 790 +--rw ltp? te-types:te-tp-id 792 6.3. Network Models 794 6.3.1. L3NM 795 module: ietf-l3nm-te-service-mapping 796 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 797 /l3vpn-ntw:vpn-service: 798 +--rw te-service-mapping! 799 +--rw te-mapping 800 +--rw map-type? identityref 801 +--rw availability-type? identityref 802 +--rw (te)? 803 +--:(vn) 804 | +--rw vn-ref? 805 | -> /vn:vn/vn-list/vn-id 806 +--:(te-topo) 807 | +--rw vn-topology-id? 808 | | te-types:te-topology-id 809 | +--rw abstract-node? 810 | -> /nw:networks/network/node/node-id 811 +--:(te-tunnel) 812 | +--rw te-tunnel-list* te:tunnel-ref 813 | +--rw sr-policy* 814 | [policy-color-ref policy-endpoint-ref] 815 | {sr-policy}? 816 | +--rw policy-color-ref leafref 817 | +--rw policy-endpoint-ref leafref 818 +--:(te-mapping-template) {template}? 819 +--rw te-mapping-template-ref? leafref 820 augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services 821 /l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes 822 /l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses 823 /l3vpn-ntw:vpn-network-access: 824 +--rw (te)? 825 +--:(vn) 826 | +--rw vn-ref? 827 | -> /vn:ap/access-point-list/access-point-id 828 +--:(te) 829 +--rw ltp? te-types:te-tp-id 831 6.3.2. L2NM 832 module: ietf-l2nm-te-service-mapping 833 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 834 /l2vpn-ntw:vpn-service: 835 +--rw te-service-mapping! 836 +--rw te-mapping 837 +--rw map-type? identityref 838 +--rw availability-type? identityref 839 +--rw (te)? 840 +--:(vn) 841 | +--rw vn-ref? 842 | -> /vn:vn/vn-list/vn-id 843 +--:(te-topo) 844 | +--rw vn-topology-id? 845 | | te-types:te-topology-id 846 | +--rw abstract-node? 847 | -> /nw:networks/network/node/node-id 848 +--:(te-tunnel) 849 | +--rw te-tunnel-list* te:tunnel-ref 850 | +--rw sr-policy* 851 | [policy-color-ref policy-endpoint-ref] 852 | {sr-policy}? 853 | +--rw policy-color-ref leafref 854 | +--rw policy-endpoint-ref leafref 855 +--:(te-mapping-template) {template}? 856 +--rw te-mapping-template-ref? leafref 857 augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services 858 /l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes 859 /l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses 860 /l2vpn-ntw:vpn-network-access: 861 +--rw (te)? 862 +--:(vn) 863 | +--rw vn-ref? 864 | -> /vn:ap/access-point-list/access-point-id 865 +--:(te) 866 +--rw ltp? te-types:te-tp-id 868 7. YANG Data Models 870 The YANG codes are as follows: 872 7.1. ietf-te-service-mapping-types 874 file "ietf-te-service-mapping-types@2020-07-13.yang" 875 module ietf-te-service-mapping-types { 876 yang-version 1.1; 877 namespace 878 "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; 880 prefix tsm-types; 882 /* Import inet-types */ 884 import ietf-inet-types { 885 prefix inet; 886 reference 887 "RFC 6991: Common YANG Data Types"; 888 } 890 /* Import inet-types */ 892 import ietf-te-types { 893 prefix te-types; 894 reference 895 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 896 } 898 /* Import network model */ 900 import ietf-network { 901 prefix nw; 902 reference 903 "RFC 8345: A YANG Data Model for Network Topologies"; 904 } 906 /* Import TE model */ 908 import ietf-te { 909 prefix te; 910 reference 911 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 912 Engineering Tunnels and Interfaces"; 913 } 915 /* Import VN model */ 917 import ietf-vn { 918 prefix vn; 919 reference 920 "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation"; 921 } 923 /* Import Routing */ 925 import ietf-routing { 926 prefix rt; 927 reference 928 "RFC 8349: A YANG Data Model for Routing Management"; 929 } 931 /* Import SR Policy */ 933 import ietf-sr-policy { 934 prefix sr-policy; 935 reference 936 "I-D.raza-spring-sr-policy-yang: YANG Data Model for Segment 937 Routing Policy"; 938 } 940 organization 941 "IETF Traffic Engineering Architecture and Signaling (TEAS) 942 Working Group"; 943 contact 944 "WG Web: 945 WG List: 947 Editor: Young Lee 948 949 Editor: Dhruv Dhody 950 951 Editor: Qin Wu 952 "; 953 description 954 "This module contains a YANG module for TE & Service mapping 955 parameters and policies as a common grouping applicable to 956 variuous service models (e.g., L1CSM, L2SM, L3SM, etc.) 958 Copyright (c) 2020 IETF Trust and the persons identified as 959 authors of the code. All rights reserved. 961 Redistribution and use in source and binary forms, with or 962 without modification, is permitted pursuant to, and subject to 963 the license terms contained in, the Simplified BSD License set 964 forth in Section 4.c of the IETF Trust's Legal Provisions 965 Relating to IETF Documents 966 (https://trustee.ietf.org/license-info). 968 This version of this YANG module is part of RFC XXXX; see the 969 RFC itself for full legal notices. 971 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 972 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 973 'MAY', and 'OPTIONAL' in this document are to be interpreted as 974 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 975 they appear in all capitals, as shown here."; 977 revision 2020-07-13 { 978 description 979 "Initial revision."; 980 reference 981 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 982 } 984 /* 985 * Features 986 */ 988 feature template { 989 description 990 "Support TE mapping templates."; 991 } 993 feature sr-policy { 994 description 995 "Support SR Policy."; 996 } 998 /* 999 * Identity for map-type 1000 */ 1002 identity map-type { 1003 description 1004 "Base identity from which specific map types are derived."; 1005 } 1007 identity new { 1008 base map-type; 1009 description 1010 "The new VN/tunnels are binded to the service."; 1011 } 1013 identity hard-isolation { 1014 base new; 1015 description 1016 "Hard isolation."; 1017 } 1019 identity detnet-hard-isolation { 1020 base hard-isolation; 1021 description 1022 "Hard isolation with deterministic characteristics."; 1023 } 1024 identity soft-isolation { 1025 base new; 1026 description 1027 "Soft-isolation."; 1028 } 1030 identity select { 1031 base map-type; 1032 description 1033 "The VPN service selects an existing tunnel with no 1034 modification."; 1035 } 1037 identity modify { 1038 base map-type; 1039 description 1040 "The VPN service selects an existing tunnel and allows to modify 1041 the properties of the tunnel (e.g., b/w)"; 1042 } 1044 identity template { 1045 base map-type; 1046 description 1047 "The VPN service selects an TE mapping template with path 1048 constraints and optimization criteria"; 1049 } 1051 /* 1052 * Identity for availability-type 1053 */ 1055 identity availability-type { 1056 description 1057 "Base identity from which specific map types are derived."; 1058 } 1060 identity level-1 { 1061 base availability-type; 1062 description 1063 "level 1: 99.9999%"; 1064 } 1066 identity level-2 { 1067 base availability-type; 1068 description 1069 "level 2: 99.999%"; 1070 } 1071 identity level-3 { 1072 base availability-type; 1073 description 1074 "level 3: 99.99%"; 1075 } 1077 identity level-4 { 1078 base availability-type; 1079 description 1080 "level 4: 99.9%"; 1081 } 1083 identity level-5 { 1084 base availability-type; 1085 description 1086 "level 5: 99%"; 1087 } 1089 /* 1090 * Typedef 1091 */ 1093 typedef te-mapping-template-id { 1094 type inet:uri; 1095 description 1096 "Identifier for a TE mapping template. The precise 1097 structure of the te-mapping-template-id will be up 1098 to the implementation. The identifier SHOULD be 1099 chosen such that the same template will always be 1100 identified through the same identifier, even if the 1101 data model is instantiated in separate datastores."; 1102 } 1104 /* 1105 * Groupings 1106 */ 1108 grouping te-ref { 1109 description 1110 "The reference to TE."; 1111 choice te { 1112 description 1113 "The TE"; 1114 case vn { 1115 leaf vn-ref { 1116 type leafref { 1117 path "/vn:vn/vn:vn-list/vn:vn-id"; 1118 } 1119 description 1120 "The reference to VN"; 1121 reference 1122 "RFC 8453: Framework for Abstraction and Control of TE 1123 Networks (ACTN)"; 1124 } 1125 } 1126 case te-topo { 1127 leaf vn-topology-id { 1128 type te-types:te-topology-id; 1129 description 1130 "An identifier to the TE Topology Model where the abstract 1131 nodes and links of the Topology can be found for Type 2 1132 VNS"; 1133 reference 1134 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 1135 Engineering (TE) Topologies"; 1136 } 1137 leaf abstract-node { 1138 type leafref { 1139 path "/nw:networks/nw:network/nw:node/nw:node-id"; 1140 } 1141 description 1142 "A reference to the abstract node in TE Topology"; 1143 reference 1144 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 1145 Engineering (TE) Topologies"; 1146 } 1147 } 1148 case te-tunnel { 1149 leaf-list te-tunnel-list { 1150 type te:tunnel-ref; 1151 description 1152 "Reference to TE Tunnels"; 1153 reference 1154 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1155 Engineering Tunnels and Interfaces"; 1156 } 1157 list sr-policy { 1158 if-feature "sr-policy"; 1159 key "policy-color-ref policy-endpoint-ref"; 1160 description 1161 "SR Policy"; 1162 leaf policy-color-ref { 1163 type leafref { 1164 path 1165 "/rt:routing/sr-policy:segment-routing" 1166 + "/sr-policy:traffic-engineering/sr-policy:policies" 1167 + "/sr-policy:policy/sr-policy:color"; 1168 } 1169 description 1170 "Reference to sr-policy color"; 1171 } 1172 leaf policy-endpoint-ref { 1173 type leafref { 1174 path 1175 "/rt:routing/sr-policy:segment-routing" 1176 + "/sr-policy:traffic-engineering/sr-policy:policies" 1177 + "/sr-policy:policy/sr-policy:endpoint"; 1178 } 1179 description 1180 "Reference to sr-policy endpoint"; 1181 } 1182 } 1183 } 1184 case te-mapping-template { 1185 if-feature "template"; 1186 leaf te-mapping-template-ref { 1187 type leafref { 1188 path "/te-mapping-templates/te-mapping-template/id"; 1189 } 1190 description 1191 "An identifier to the TE Mapping Template where the TE 1192 constraints and optimization criteria are specified."; 1193 } 1194 } 1195 } 1196 } 1198 //grouping 1200 grouping te-endpoint-ref { 1201 description 1202 "The reference to TE endpoints."; 1203 choice te { 1204 description 1205 "The TE"; 1206 case vn { 1207 leaf vn-ref { 1208 type leafref { 1209 path "/vn:ap/vn:access-point-list/vn:access-point-id"; 1210 } 1211 description 1212 "The reference to VN AP"; 1213 reference 1214 "RFC 8453: Framework for Abstraction and Control of TE 1215 Networks (ACTN)"; 1216 } 1217 } 1218 case te { 1219 leaf ltp { 1220 type te-types:te-tp-id; 1221 description 1222 "Reference LTP in the TE-topology"; 1223 reference 1224 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 1225 Engineering (TE) Topologies"; 1226 } 1227 } 1228 } 1229 } 1231 //grouping 1233 grouping te-mapping { 1234 description 1235 "Mapping between Services and TE"; 1236 container te-mapping { 1237 description 1238 "Mapping between Services and TE"; 1239 leaf map-type { 1240 type identityref { 1241 base map-type; 1242 } 1243 description 1244 "Isolation Requirements, Tunnel Bind or 1245 Tunnel Selection"; 1246 } 1247 leaf availability-type { 1248 type identityref { 1249 base availability-type; 1250 } 1251 description 1252 "Availability Requirement for the Service"; 1253 } 1254 uses te-ref; 1255 } 1256 } 1258 //grouping 1260 container te-mapping-templates { 1261 description 1262 "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 '(. != "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-07-13.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; 1309 import ietf-te-service-mapping-types { 1310 prefix tsm-types; 1311 reference 1312 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1313 } 1314 import ietf-l3vpn-svc { 1315 prefix l3vpn-svc; 1316 reference 1317 "RFC 8299: YANG Data Model for L3VPN Service Delivery"; 1318 } 1320 organization 1321 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1322 Working Group"; 1323 contact 1324 "WG Web: 1325 WG List: 1327 Editor: Young Lee 1328 1329 Editor: Dhruv Dhody 1330 1331 Editor: Qin Wu 1332 "; 1333 description 1334 "This module contains a YANG module for the mapping of Layer 3 1335 Service Model (L3SM) to the TE and VN. 1337 Copyright (c) 2020 IETF Trust and the persons identified as 1338 authors of the code. All rights reserved. 1340 Redistribution and use in source and binary forms, with or 1341 without modification, is permitted pursuant to, and subject to 1342 the license terms contained in, the Simplified BSD License set 1343 forth in Section 4.c of the IETF Trust's Legal Provisions 1344 Relating to IETF Documents 1345 (https://trustee.ietf.org/license-info). 1347 This version of this YANG module is part of RFC XXXX; see the 1348 RFC itself for full legal notices. 1350 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1351 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1352 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1353 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1354 they appear in all capitals, as shown here."; 1356 revision 2020-03-08 { 1357 description 1358 "Initial revision."; 1360 reference 1361 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1362 } 1364 /* 1365 * Augmentation to L3SM 1366 */ 1368 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services" 1369 + "/l3vpn-svc:vpn-service" { 1370 description 1371 "L3SM augmented to include TE parameters and mapping"; 1372 container te-service-mapping { 1373 presence "Indicates L3 service to TE mapping"; 1374 description 1375 "Container to augment l3sm to TE parameters and mapping"; 1376 uses tsm-types:te-mapping; 1377 } 1378 } 1380 //augment 1382 augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" 1383 + "/l3vpn-svc:site-network-accesses" 1384 + "/l3vpn-svc:site-network-access" { 1385 description 1386 "This augment is only valid for TE mapping of L3SM network-access 1387 to TE endpoints"; 1388 uses tsm-types:te-endpoint-ref; 1389 } 1391 //augment 1392 } 1394 1396 7.2.2. ietf-l2sm-te-service-mapping 1398 file "ietf-l2sm-te-service-mapping@2020-07-13.yang" 1399 module ietf-l2sm-te-service-mapping { 1400 yang-version 1.1; 1401 namespace 1402 "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; 1403 prefix l2-tsm; 1405 import ietf-te-service-mapping-types { 1406 prefix tsm-types; 1407 reference 1408 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1409 } 1410 import ietf-l2vpn-svc { 1411 prefix l2vpn-svc; 1412 reference 1413 "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network 1414 (L2VPN) Service Delivery"; 1415 } 1417 organization 1418 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1419 Working Group"; 1420 contact 1421 "WG Web: 1422 WG List: 1424 Editor: Young Lee 1425 1426 Editor: Dhruv Dhody 1427 1428 Editor: Qin Wu 1429 "; 1430 description 1431 "This module contains a YANG module for the mapping of Layer 2 1432 Service Model (L2SM) to the TE and VN. 1434 Copyright (c) 2020 IETF Trust and the persons identified as 1435 authors of the code. All rights reserved. 1437 Redistribution and use in source and binary forms, with or 1438 without modification, is permitted pursuant to, and subject to 1439 the license terms contained in, the Simplified BSD License set 1440 forth in Section 4.c of the IETF Trust's Legal Provisions 1441 Relating to IETF Documents 1442 (https://trustee.ietf.org/license-info). 1444 This version of this YANG module is part of RFC XXXX; see the 1445 RFC itself for full legal notices. 1447 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1448 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1449 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1450 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1451 they appear in all capitals, as shown here."; 1453 revision 2020-07-13 { 1454 description 1455 "Initial revision."; 1457 reference 1458 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1459 } 1461 /* 1462 * Augmentation to L2SM 1463 */ 1465 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/" 1466 + "l2vpn-svc:vpn-service" { 1467 description 1468 "L2SM augmented to include TE parameters and mapping"; 1469 container te-service-mapping { 1470 presence "indicates L2 service to te mapping"; 1471 description 1472 "Container to augment L2SM to TE parameters and mapping"; 1473 uses tsm-types:te-mapping; 1474 } 1475 } 1477 //augment 1479 augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" 1480 + "/l2vpn-svc:site-network-accesses" 1481 + "/l2vpn-svc:site-network-access" { 1482 description 1483 "This augment is only valid for TE mapping of L2SM network-access 1484 to TE endpoints"; 1485 uses tsm-types:te-endpoint-ref; 1486 } 1488 //augment 1489 } 1491 1493 7.2.3. ietf-l1csm-te-service-mapping 1495 file "ietf-l1csm-te-service-mapping@2020-07-13.yang" 1496 module ietf-l1csm-te-service-mapping { 1497 yang-version 1.1; 1498 namespace 1499 "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; 1500 prefix l1-tsm; 1502 import ietf-te-service-mapping-types { 1503 prefix tsm-types; 1504 reference 1505 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1506 } 1507 import ietf-l1csm { 1508 prefix l1csm; 1509 reference 1510 "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity 1511 Service Model (L1CSM)"; 1512 } 1514 organization 1515 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1516 Working Group"; 1517 contact 1518 "WG Web: 1519 WG List: 1521 Editor: Young Lee 1522 1523 Editor: Dhruv Dhody 1524 1525 Editor: Qin Wu 1526 "; 1527 description 1528 "This module contains a YANG module for the mapping of 1529 Layer 1 Connectivity Service Module (L1CSM) to the TE and VN 1531 Copyright (c) 2020 IETF Trust and the persons identified as 1532 authors of the code. All rights reserved. 1534 Redistribution and use in source and binary forms, with or 1535 without modification, is permitted pursuant to, and subject to 1536 the license terms contained in, the Simplified BSD License set 1537 forth in Section 4.c of the IETF Trust's Legal Provisions 1538 Relating to IETF Documents 1539 (https://trustee.ietf.org/license-info). 1541 This version of this YANG module is part of RFC XXXX; see the 1542 RFC itself for full legal notices. 1544 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1545 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1546 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1547 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1548 they appear in all capitals, as shown here."; 1550 revision 2020-07-13 { 1551 description 1552 "Initial revision."; 1554 reference 1555 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1556 } 1558 /* 1559 * Augmentation to L1CSM 1560 */ 1562 augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" { 1563 description 1564 "L1CSM augmented to include TE parameters and mapping"; 1565 container te-service-mapping { 1566 presence "Indicates L1 service to TE mapping"; 1567 description 1568 "Container to augment L1CSM to TE parameters and mapping"; 1569 uses tsm-types:te-mapping; 1570 } 1571 } 1573 //augment 1575 augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/" 1576 + "l1csm:uni" { 1577 description 1578 "This augment is only valid for TE mapping of L1CSM UNI to TE 1579 endpoints"; 1580 uses tsm-types:te-endpoint-ref; 1581 } 1583 //augment 1584 } 1586 1588 7.3. Network Models 1590 7.3.1. ietf-l3nm-te-service-mapping 1592 file "ietf-l3nm-te-service-mapping@2020-07-13.yang" 1593 module ietf-l3nm-te-service-mapping { 1594 yang-version 1.1; 1595 namespace 1596 "urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping"; 1597 prefix l3nm-tsm; 1599 import ietf-te-service-mapping-types { 1600 prefix tsm-types; 1601 reference 1602 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1603 } 1604 import ietf-l3vpn-ntw { 1605 prefix l3vpn-ntw; 1606 reference 1607 "I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model"; 1608 } 1610 organization 1611 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1612 Working Group"; 1613 contact 1614 "WG Web: 1615 WG List: 1617 Editor: Young Lee 1618 1619 Editor: Dhruv Dhody 1620 1621 Editor: Qin Wu 1622 "; 1623 description 1624 "This module contains a YANG module for the mapping of Layer 3 1625 Network Model (L3NM) to the TE and VN. 1627 Copyright (c) 2020 IETF Trust and the persons identified as 1628 authors of the code. All rights reserved. 1630 Redistribution and use in source and binary forms, with or 1631 without modification, is permitted pursuant to, and subject to 1632 the license terms contained in, the Simplified BSD License set 1633 forth in Section 4.c of the IETF Trust's Legal Provisions 1634 Relating to IETF Documents 1635 (https://trustee.ietf.org/license-info). 1637 This version of this YANG module is part of RFC XXXX; see the 1638 RFC itself for full legal notices. 1640 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1641 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1642 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1643 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1644 they appear in all capitals, as shown here."; 1646 revision 2020-07-13 { 1647 description 1648 "Initial revision."; 1649 reference 1650 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1651 } 1653 /* 1654 * Augmentation to L3NM 1655 */ 1657 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1658 + "/l3vpn-ntw:vpn-service" { 1659 description 1660 "L3SM augmented to include TE parameters and mapping"; 1661 container te-service-mapping { 1662 presence "Indicates L3 network to TE mapping"; 1663 description 1664 "Container to augment l3nm to TE parameters and mapping"; 1665 uses tsm-types:te-mapping; 1666 } 1667 } 1669 //augment 1671 augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" 1672 + "/l3vpn-ntw:vpn-service" 1673 + "/l3vpn-ntw:vpn-nodes/l3vpn-ntw:vpn-node" 1674 + "/l3vpn-ntw:vpn-network-accesses" 1675 + "/l3vpn-ntw:vpn-network-access" { 1676 description 1677 "This augment is only valid for TE mapping of L3NM network-access 1678 to TE endpoints"; 1679 uses tsm-types:te-endpoint-ref; 1680 } 1682 //augment 1683 } 1685 1687 7.3.2. ietf-l2nm-te-service-mapping 1689 file "ietf-l2nm-te-service-mapping@2020-07-13.yang" 1690 module ietf-l2nm-te-service-mapping { 1691 yang-version 1.1; 1692 namespace 1693 "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping"; 1694 prefix l2nm-tsm; 1696 import ietf-te-service-mapping-types { 1697 prefix tsm-types; 1698 reference 1699 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1700 } 1701 import ietf-l2vpn-ntw { 1702 prefix l2vpn-ntw; 1703 reference 1704 "I-D.ietf-l2nm: A Layer 2 VPN Network YANG Model"; 1705 } 1707 organization 1708 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1709 Working Group"; 1710 contact 1711 "WG Web: 1712 WG List: 1714 Editor: Young Lee 1715 1716 Editor: Dhruv Dhody 1717 1718 Editor: Qin Wu 1719 "; 1720 description 1721 "This module contains a YANG module for the mapping of Layer 2 1722 Network Model (L2NM) to the TE and VN. 1724 Copyright (c) 2020 IETF Trust and the persons identified as 1725 authors of the code. All rights reserved. 1727 Redistribution and use in source and binary forms, with or 1728 without modification, is permitted pursuant to, and subject to 1729 the license terms contained in, the Simplified BSD License set 1730 forth in Section 4.c of the IETF Trust's Legal Provisions 1731 Relating to IETF Documents 1732 (https://trustee.ietf.org/license-info). 1734 This version of this YANG module is part of RFC XXXX; see the 1735 RFC itself for full legal notices. 1737 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1738 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1739 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1740 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1741 they appear in all capitals, as shown here."; 1743 revision 2020-07-13 { 1744 description 1745 "Initial revision."; 1747 reference 1748 "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; 1749 } 1751 /* 1752 * Augmentation to L2NM 1753 */ 1755 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1756 + "/l2vpn-ntw:vpn-service" { 1757 description 1758 "L2SM augmented to include TE parameters and mapping"; 1759 container te-service-mapping { 1760 presence "Indicates L2 network to TE mapping"; 1761 description 1762 "Container to augment l2nm to TE parameters and mapping"; 1763 uses tsm-types:te-mapping; 1764 } 1765 } 1767 //augment 1769 augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" 1770 + "/l2vpn-ntw:vpn-service" 1771 + "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node" 1772 + "/l2vpn-ntw:vpn-network-accesses" 1773 + "/l2vpn-ntw:vpn-network-access" { 1774 description 1775 "This augment is only valid for TE mapping of L2NM network-access 1776 to TE endpoints"; 1777 uses tsm-types:te-endpoint-ref; 1778 } 1780 //augment 1781 } 1783 1785 8. Security Considerations 1787 The YANG modules defined in this document is designed to be accessed 1788 via network management protocol such as NETCONF [RFC6241] or RESTCONF 1789 [RFC8040]. The lowest NETCONF layer is the secure transport layer 1790 and the mandatory-to-implement secure transport is SSH [RFC6242]. 1791 The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement 1792 secure transport is TLS [RFC8446] 1793 The NETCONF access control model [RFC8341] provides the means to 1794 restrict access for particular NETCONF or RESTCONF users to a pre- 1795 configured subset of all available NETCONF or RESTCONF protocol 1796 operations and content. 1798 There are a number of data nodes defined in the YANG moduleS which 1799 are writable/creatable/deletable (i.e., config true, which is the 1800 default). These data nodes may be considered sensitive or vulnerable 1801 in some network environments. Write operations (e.g., ) 1802 to these data nodes without proper protection can have a negative 1803 effect on network operations. These are the subtrees and data nodes 1804 and their sensitivity/vulnerability: 1806 o /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1807 - configure TE Service mapping. 1809 o /l3vpn-svc/sites/site/site-network-accesses/site-network-access/ 1810 te/ - configure TE Endpoint mapping. 1812 o /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1813 - configure TE Service mapping. 1815 o /l2vpn-svc/sites/site/site-network-accesses/site-network-access/ 1816 te/ - configure TE Endpoint mapping. 1818 o /l1-connectivity/services/service/te-service-mapping/te-mapping/ - 1819 configure TE Service mapping. 1821 o /l1-connectivity/access/unis/uni/te/ - configure TE Endpoint 1822 mapping. 1824 o /l3vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1825 - configure TE Network mapping. 1827 o /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1828 network-accesses/vpn-network-access/te/ - configure TE Endpoint 1829 mapping. 1831 o /l2vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ 1832 - configure TE Network mapping. 1834 o /l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn- 1835 network-accesses/vpn-network-access/te/ - configure TE Endpoint 1836 mapping. 1838 Unauthorized access to above list can adversely affect the VPN 1839 service. 1841 Some of the readable data nodes in the YANG module may be considered 1842 sensitive or vulnerable in some network environments. It is thus 1843 important to control read access (e.g., via get, get-config, or 1844 notification) to these data nodes. The TE related parameters 1845 attached to the VPN service can leak sensitive information about the 1846 network. This is apploicable to all elements in the yang models 1847 defined in this document. 1849 This document has no RPC defined. 1851 9. IANA Considerations 1853 This document request the IANA to register four URIs in the "IETF XML 1854 Registry" [RFC3688]. Following the format in RFC 3688, the following 1855 registrations are requested - 1857 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 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-l3sm-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-l2sm-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-l1csm-te-service-mapping 1870 Registrant Contact: The IESG. 1871 XML: N/A, the requested URI is an XML namespace. 1873 URI: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 1874 Registrant Contact: The IESG. 1875 XML: N/A, the requested URI is an XML namespace. 1877 URI: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 1878 Registrant Contact: The IESG. 1879 XML: N/A, the requested URI is an XML namespace. 1881 This document request the IANA to register four YANG modules in the 1882 "YANG Module Names" registry [RFC6020], as follows - 1883 Name: ietf-te-service-mapping-types 1884 Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 1885 Prefix: tsm-types 1886 Reference: [This.I-D] 1888 Name: ietf-l3sm-te-service-mapping 1889 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping 1890 Prefix: l3-tsm 1891 Reference: [This.I-D] 1893 Name: ietf-l2sm-te-service-mapping 1894 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping 1895 Prefix: l2-tsm 1896 Reference: [This.I-D] 1898 Name: ietf-l1csm-te-service-mapping 1899 Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping 1900 Prefix: l1-tsm 1901 Reference: [This.I-D] 1903 Name: ietf-l3nm-te-service-mapping 1904 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping 1905 Prefix: l3nm-tsm 1906 Reference: [This.I-D] 1908 Name: ietf-l2nm-te-service-mapping 1909 Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping 1910 Prefix: l2nm-tsm 1911 Reference: [This.I-D] 1913 10. Acknowledgements 1915 We thank Diego Caviglia, and Igor Bryskin for useful discussions and 1916 motivation for this work. 1918 11. References 1920 11.1. Normative References 1922 [I-D.ietf-ccamp-l1csm-yang] 1923 Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. 1924 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 1925 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-11 (work in 1926 progress), March 2020. 1928 [I-D.ietf-opsawg-l2nm] 1929 Barguil, S., Dios, O., Boucadair, M., Munoz, L., Jalil, 1930 L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- 1931 ietf-opsawg-l2nm-00 (work in progress), July 2020. 1933 [I-D.ietf-opsawg-l3sm-l3nm] 1934 Barguil, S., Dios, O., Boucadair, M., Munoz, L., and A. 1935 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 1936 opsawg-l3sm-l3nm-03 (work in progress), April 2020. 1938 [I-D.ietf-teas-actn-vn-yang] 1939 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1940 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1941 teas-actn-vn-yang-08 (work in progress), March 2020. 1943 [I-D.ietf-teas-yang-te] 1944 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1945 "A YANG Data Model for Traffic Engineering Tunnels and 1946 Interfaces", draft-ietf-teas-yang-te-23 (work in 1947 progress), March 2020. 1949 [I-D.ietf-teas-yang-te-topo] 1950 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1951 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1952 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 1953 progress), June 2019. 1955 [I-D.raza-spring-sr-policy-yang] 1956 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 1957 Matsushima, S., and V. Beeram, "YANG Data Model for 1958 Segment Routing Policy", draft-raza-spring-sr-policy- 1959 yang-02 (work in progress), November 2019. 1961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1962 Requirement Levels", BCP 14, RFC 2119, 1963 DOI 10.17487/RFC2119, March 1997, 1964 . 1966 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1967 DOI 10.17487/RFC3688, January 2004, 1968 . 1970 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1971 the Network Configuration Protocol (NETCONF)", RFC 6020, 1972 DOI 10.17487/RFC6020, October 2010, 1973 . 1975 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1976 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1977 . 1979 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1980 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1981 . 1983 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1984 Ceccarelli, D., and X. Zhang, "Problem Statement and 1985 Architecture for Information Exchange between 1986 Interconnected Traffic-Engineered Networks", BCP 206, 1987 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1988 . 1990 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1991 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1992 . 1994 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1995 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1996 . 1998 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1999 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2000 May 2017, . 2002 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2003 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2004 DOI 10.17487/RFC8299, January 2018, 2005 . 2007 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2008 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2009 . 2011 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2012 Access Control Model", STD 91, RFC 8341, 2013 DOI 10.17487/RFC8341, March 2018, 2014 . 2016 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2017 and R. Wilton, "Network Management Datastore Architecture 2018 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2019 . 2021 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2022 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2023 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2024 2018, . 2026 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 2027 Routing Management (NMDA Version)", RFC 8349, 2028 DOI 10.17487/RFC8349, March 2018, 2029 . 2031 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2032 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2033 . 2035 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2036 Data Model for Layer 2 Virtual Private Network (L2VPN) 2037 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2038 2018, . 2040 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2041 "Common YANG Data Types for Traffic Engineering", 2042 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2043 . 2045 11.2. Informative References 2047 [I-D.ietf-teas-actn-yang] 2048 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 2049 Shin, J., and S. Belotti, "Applicability of YANG models 2050 for Abstraction and Control of Traffic Engineered 2051 Networks", draft-ietf-teas-actn-yang-05 (work in 2052 progress), February 2020. 2054 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2055 and A. Bierman, Ed., "Network Configuration Protocol 2056 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2057 . 2059 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 2060 Classification", RFC 8199, DOI 10.17487/RFC8199, July 2061 2017, . 2063 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2064 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2065 . 2067 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2068 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2069 DOI 10.17487/RFC8453, August 2018, 2070 . 2072 Appendix A. Contributor Addresses 2074 Adrian Farrel 2075 Old Dog Consulting 2077 EMail: adrian@olddog.co.uk 2079 Italo Busi 2080 Huawei Technologies 2082 EMail: Italo.Busi@huawei.com 2084 Haomian Zheng 2085 Huawei Technologies 2087 EMail: zhenghaomian@huawei.com 2089 Anton Snitser 2090 Sedonasys 2092 EMail: antons@sedonasys.com 2094 SAMIER BARGUIL GIRALDO 2095 Telefonica 2097 EMail: samier.barguilgiraldo.ext@telefonica.com 2099 Oscar Gonzalez de Dios 2100 Telefonica 2102 EMail: oscar.gonzalezdedios@telefonica.com 2104 Carlo Perocchio 2105 Ericsson 2107 EMail: carlo.perocchio@ericsson.com 2109 Authors' Addresses 2111 Young Lee (editor) 2112 Samsung Electronics 2114 Email: younglee.tx@gmail.com 2115 Dhruv Dhody (editor) 2116 Huawei Technologies 2118 Email: dhruv.ietf@gmail.com 2120 Giuseppe Fioccola 2121 Huawei Technologies 2123 Email: giuseppe.fioccola@huawei.com 2125 Qin Wu (editor) 2126 Huawei Technologies 2128 Email: bill.wu@huawei.com 2130 Daniele Ceccarelli 2131 Ericsson 2132 Torshamnsgatan,48 2133 Stockholm, Sweden 2135 Email: daniele.ceccarelli@ericsson.com 2137 Jeff Tantsura 2138 Apstra 2140 Email: jefftant.ietf@gmail.com