idnits 2.17.1 draft-evenwu-opsawg-yang-composed-vpn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC8309]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 388 has weird spacing: '...er-rate lay...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2018) is 2013 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: 'RFC8174' is mentioned on line 145, but not defined == Missing Reference: 'RFC8340' is mentioned on line 149, but not defined == Missing Reference: 'I-D.chen-opsawg-composite-vpn-dm' is mentioned on line 1795, but not defined == Unused Reference: 'RFC6370' is defined on line 1770, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Downref: Normative reference to an Informational RFC: RFC 8309 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG Working Group R. Even 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: April 24, 2019 Y. Cheng 6 China Unicom 7 October 21, 2018 9 YANG Data Model for Composed VPN Service Delivery 10 draft-evenwu-opsawg-yang-composed-vpn-01 12 Abstract 14 This document defines a YANG data model that can be used by a network 15 operator to configure a VPN service at one layer interconnecting VPN 16 service at another layer and manage how a hybrid VPN service is 17 engineered in the network [RFC8309]. This model is intended to be 18 instantiated at the management system to deliver the overall service. 19 It is not a configuration model to be used directly on network 20 elements. This model provides an abstracted view of VPN service 21 configuration components at different layer. It is up to a 22 management system to take this as an input and generate specific 23 configurations models to configure the different network elements to 24 deliver the service. How configuration of network elements is done 25 is out of scope of the document. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 24, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3 64 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. The Composed VPN Service Model . . . . . . . . . . . . . . . 4 67 3.1. VPN Service Types . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Composed VPN Physical Network Topology . . . . . . . . . 5 69 4. Service Model Usage . . . . . . . . . . . . . . . . . . . . . 6 70 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 8 71 6. Basic Building Blocks . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Access Points . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1.1. Termination Point Basic Information . . . . . . . . . 11 74 6.1.2. Peer CE Node . . . . . . . . . . . . . . . . . . . . 13 75 6.1.3. Routing Protocols . . . . . . . . . . . . . . . . . . 13 76 6.2. Segmented VPN . . . . . . . . . . . . . . . . . . . . . . 13 77 7. Composed VPN YANG Module . . . . . . . . . . . . . . . . . . 14 78 8. Segment VPN YANG Module . . . . . . . . . . . . . . . . . . . 16 79 9. Service Model Usage Example . . . . . . . . . . . . . . . . . 33 80 10. Interaction with other YANG models . . . . . . . . . . . . . 36 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 83 13. Normative References . . . . . . . . . . . . . . . . . . . . 38 84 Appendix A. Acknowledges . . . . . . . . . . . . . . . . . . . . 39 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 87 1. Introduction 89 BGP/MPLS IP Virtual Private Networks (IP VPNs) [RFC4364] have been 90 widely deployed to provide network based Layer 3 VPNs solutions. As 91 MPLS-based Layer 2 services grow in demand, many mobile SPs are 92 interested to extend their conventional L2VPN at the X1 interface in 93 the metro access network into IP VPN capabilities at the S1 interface 94 between access network and core network to provide end-to-end native 95 BGP IP VPN services to their enterprise customers. Another benefit 96 is to enable the sharing of a provider's core network infrastructure 97 between IP and Layer 2 VPN services. 99 This document defines a YANG data model that can be used by a network 100 operator to configure a VPN across multi-domain environment with a 101 VPN service at one layer interconnecting a VPN service at another 102 layer and manage how a hybrid VPN service is engineered in the 103 network [RFC8309]. This model is intended to be instantiated at the 104 management system to deliver the overall service. It is not a 105 configuration model to be used directly on network elements. This 106 model provides an abstracted view of VPN service configuration 107 components at different layer. It is up to a management system to 108 take this as an input and generate specific configurations models to 109 configure the different network elements to deliver the service. How 110 configuration of network elements is done is out of scope of the 111 document. 113 1.1. Terminology 115 The following terms are defined in [RFC6241] and are not redefined 116 here: 118 o client 120 o server 122 o configuration data 124 o state data 126 The following terms are defined in [RFC7950] and are not redefined 127 here: 129 o augment 131 o data model 133 o data node 135 The terminology for describing YANG data models is found in 136 [RFC7950]. 138 1.1.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 1.2. Tree diagram 148 Tree diagrams used in this document follow the notation defined in 149 [RFC8340]. 151 2. Definitions 153 This document uses the following terms: 155 Service Provider (SP): The organization (usually a commercial 156 undertaking) responsible for operating the network that offers VPN 157 services to clients and customers. 159 Customer Edge (CE) Device: Equipment that is dedicated to a 160 particular customer and is directly connected to one or more PE 161 devices via attachment circuits. A CE is usually located at the 162 customer premises, and is usually dedicated to a single VPN, 163 although it may support multiple VPNs if each one has separate 164 attachment circuits. The CE devices can be routers, bridges, 165 switches, or hosts. 167 Provider Edge (PE) Device: Equipment managed by the SP that can 168 support multiple VPNs for different customers, and is directly 169 connected to one or more CE devices via attachment circuits. A PE 170 is usually located at an SP point of presence (PoP) and is managed 171 by the SP. 173 3. The Composed VPN Service Model 175 A Composed VPN service is a collection of VPN sites that are 176 authorized to exchange traffic between each other over a shared 177 infrastructure of a common L3VPN technology. This Composed VPN 178 service model provides a common understanding of how the 179 corresponding composed VPN service is to be deployed in an end to end 180 manner over the shared infrastructure. 182 This document presents the Composed VPN Service Delivery Model using 183 the YANG data modeling language [RFC7950] as a formal language that 184 is both human-readable and parsable by software for use with 185 protocols such as NETCONF [RFC6241] and RESTCONF [RFC8040]. 187 3.1. VPN Service Types 189 From a technology perspective, a set of basic VPN service types 190 include: 192 o Layer 2 VPN Service 194 o Layer 3 VPN Service 196 o VXLAN Service 198 3.2. Composed VPN Physical Network Topology 200 NodeBs of the site 1,2,3,4 in the access metro network are one end of 201 the Layer 2 VPN and communicate with each other via X2 interface. 202 sGW/MME of site 5,6 in the core network are another end of Layer 3 203 VPN and communicate NodeB in site 1,2,3,4 via S1 interface in the 204 access metro network . The Router PE at the edge of the access metro 205 network is performing the VPN stitching between the Layer 2 VPN and 206 the Layer 3 VPN using the technology such as bridging or other 207 interconnection technology. The Router PE uses the logical tunnel 208 interface (lt interface) configured with different logical interface 209 units applied under two different VPN instances. Therefore the end 210 to end VPN connection spanning across the metro access network and 211 the IP core network can be established. 213 +-Site5+ +Site6--+ 214 |sGW/MME |sGW/MME| 215 | | | | 216 +------+////----------------------\\\\ +-------+ 217 ^ ///////// \\\\\\\\\ 218 | ||| L3VPN ||| 219 | || || 220 | \\\\\\\\\ ///////// 221 | +----------------------------------------+ 222 |S1 -| PE | 223 | /// +----------------------------------------+\ 224 | / \ / \ 225 | / \ / \ 226 | | | | | 227 | | | | | 228 | | L2VPN | | L2VPN | 229 | | | | | 230 | | | X2 | | 231 | \ ----------------------------/ / 232 | \ \ / \ / / 233 | \\\ \// \\\ / /// 234 +-----+-----+-----+ +---/-+----+-----+ 235 |NodeB| |NodeB| |NodeB| |NodeB| 236 +-----+ +-----+ +-----+ +-----+ 237 Site1 Site2 Site3 Site4 239 L2VPN interconnection with L3VPN in Mobile Backhaul Network 241 4. Service Model Usage 242 +------------------+ 243 | Orchestration | 244 +------------------+ 245 | | 246 +----------------+ | 247 | Config manager | | 248 +----------------+ | 249 | | 250 | NETCONF/CLI ... 251 | | 252 +------------------------------------------------+ 253 Network 255 ++++++++ Bearer 256 + CE A + ---------------- 257 ++++++++ Connection 258 L2VE|L3VE 259 L2 Site A ++++++++ Bearer ++++++++ 260 + PE A + ------ ---- + CE C + 261 ++++++++ Connection ++++++++ 262 ++++++++ Bearer 263 + CE B + ---------------- L3 Site C 264 ++++++++ Connection 266 L2 Site B 268 The idea of the composed VPN model is to decompose end to end VPN 269 service across multiple-domain enviroment into segmented tunnel or 270 segmented VPN service in each domain. A typical scenario would be to 271 use composed VPN model spanning across multi-domain as an input for 272 an orchestration layer that will be responsible for translating it to 273 an orchestrated per domain configuration of network elements that 274 will be part of the service. The per domain configuration of network 275 elements will be defined as segmented VPN model in each domain. The 276 configuration of network elements can be done via the CLI, NETCONF/ 277 RESTCONF [RFC6241][RFC8040] coupled with YANG data models of a 278 specific configuration (BGP, VRF, BFD, etc.), or some other 279 technique, as preferred by the operator. Another scenario is to use 280 customer facing model such as L3SM service model as an input for an 281 orchestration layer that will be responsible for translating it to 282 the composed VPN model and the composed VPN model can be further 283 broken down into per domain segmented VPN model in each domain. 285 The usage of this composed VPN model is not limited to this example; 286 it can be used by any component of the management system but not 287 directly by network elements. 289 5. Design of the Data Model 291 The YANG data model for the composed VPN has been split into two YANG 292 modules. The first module, "ietf-composed-vpn-svc", defines global 293 parameters and the essential components of a composed VPN that are 294 used to provide end to end connectivity spanning across multiple 295 domains. The second module "ietf-segmented-vpn" defines per domain 296 segmented vpn parameters and associated access point list parameters 297 that are used to connect to the peer device or domain. The segmented 298 vpn list defined in the second module "ietf-segmented-vpn" also 299 provides basic component for the first module "ietf-composed-vpn- 300 svc". 302 The global parameters under composed-vpns container contain generic 303 information about the VPN service such as vpn-id, customer-name, 304 service-topology and operational state. The "vpn-id" provided in the 305 composed-vpn list refers to an internal reference for this composed 306 VPN service, while the customer name refers to a more-explicit 307 reference to the customer. This identifier is purely internal to the 308 organization responsible for the composed VPN service. vpn-topology 309 describes the type of VPN service topology is required for 310 configuration. Our proposed model supports any-to-any, Hub and 311 Spoke.Operation state includes admin-state, oper-state, sync- State 312 and start-time. 314 Two essential components of a composed VPN are segmented vpns list 315 and access points list. A composed-vpn is composed of at least one 316 access points and at least one segmented vpns. A segmented vpn under 317 "segmented-vpn" list is composed of at least one access point. The 318 access point parameters under comosed-vpn level is used to describe 319 end to end connectivity stitching with one or multiple access 320 connectivities in each segmented VPN while the access point 321 parameters under segmented VPN level is used to describe one or 322 multiple access connectivities pertaining to each segment VPN. 324 Figure 1 shows abridged views of the hierarchies. 326 +--rw composed-vpns 327 +--rw composed-vpn* [vpn-id] 328 +--rw vpn-id yang:uuid 329 +--rw vpn-name? string 330 +--rw customer-name? yang:uuid 331 +--rw topo? svpn:topology 332 +--rw service-type? svpn:service-type 333 +--rw technology? svpn:tunnel-type 334 +--rw admin-state? svpn:admin-state 335 +--ro oper-State? svpn:oper-state 336 +--ro sync-state? svpn:sync-state 337 +--rw start-time? yang:date-and-time 338 +--rw segment-vpns* [index] 339 | ... 340 +--rw access-points* [tp-id] 341 +--rw tp-basic 342 +--rw peer-ce-node 343 +--rw routing-protocol* [type] 345 Figure 1: Figure 1 347 6. Basic Building Blocks 349 This section describes the essential components of the composed VPN 350 data model. 352 6.1. Access Points 354 The access points are basic element information in a composed VPN and 355 used to describe any network access connectivity across domains or 356 within a domain. The access points list models a list of access 357 points including the access or attachment information for the remote 358 peer. The access point provided by the remote peer(e.g.,PE) at the 359 composed VPN level are used to describe the network access 360 connectivity across domains. The access point provided by the remote 361 peer(e.g.,PE) at the segmented VPN level are used to describe network 362 access connectivity within a domain. The access point uses working 363 layer and corresponding layer information to describe the different 364 configurations in composed VPN level and the segmented VPN level. 366 As can be seen from Figure 1, the access points list further 367 introduces several generic components of a composed VPN: termination 368 point basic information, peer CE node information, QoS and routing 369 protocols. Section 6.1.1, Section6.1.2 and Section 6.1.3 describes 370 these components in more detail. 372 +--rw access-point* [tp-id] 373 +--rw peer-ce-node 374 | +--rw ce-id? yang:uuid 375 | +--rw ce-node-id? yang:uuid 376 | +--rw ce-tp-id? yang:uuid 377 | +--rw ce-address? inet:ip-address 378 | +--rw location? string 379 +--rw tp-basic 380 | +--rw tp-id yang:uuid 381 | +--rw tp-name? string 382 | +--rw node-id? yang:uuid 383 | +--rw edge-role? edge-role 384 | +--rw topo-role? topo-role 385 | +--rw tp-type? tp-type 386 | +--rw working-layer? layer-rate 387 | +--rw type-spec* [layer-rate] 388 | | +--rw layer-rate layer-rate 389 | | +--rw (spec-value)? 390 | | +--:(lr-eth) 391 | | | +--rw eth 392 | | | +--rw access-type? eth-encap-type 393 | | | +--rw (vlan)? 394 | | | | +--:(qinq) 395 | | | | | +--rw qinq 396 | | | | | +--rw cvlan* uint64 397 | | | | | +--rw svlan? uint64 398 | | | | +--:(dot1q) 399 | | | | +--rw dot1q 400 | | | | +--rw dot1q* uint64 401 | | | +--rw vlan-action? eth-action 402 | | | +--rw action? string 403 | | +--:(lr-ip) 404 | | | +--rw ip 405 | | | +--rw ip-address? inet:ip-address 406 | | | +--rw mtu? uint64 407 | | +--:(lr-pw) 408 | | | +--rw pw 409 | | | +--rw control-word 410 | | | +--rw vlan-action 411 | | +--:(lr-vxlan) 412 | | +--rw vxlan 413 | | +--rw vni? uint32 414 | | +--rw vtep-ip? inet:ip-address 415 | +--rw tp-qos-node 416 | | +--rw qos-config-type? qos-config-type 417 | | +--rw qos-sub-type? qos-sub-type 418 | | +--rw in-profile-id? yang:uuid 419 | | +--rw out-profile-id? yang:uuid 420 | | +--rw in-tp-car* [index] 421 | | | +--rw index uint32 422 | | | +--rw color-type? color-type 423 | | | +--rw action-type? action-type 424 | | | +--rw action? string 425 | | +--rw out-tp-car* [index] 426 | | | +--rw index uint32 427 | | | +--rw color-type? color-type 428 | | | +--rw action-type? action-type 429 | | | +--rw action? string 430 | +--rw flow-services 431 | +--rw qos-config-type? qos-config-type 432 | +--rw qos-sub-type? qos-sub-type 433 | +--rw in-template-id? yang:uuid 434 | +--rw out-template-id? yang:uuid 435 | +--rw flow-service* [class-id] 436 | +--rw class-id yang:uuid 437 | +--rw flow-behavior* [index] 438 | +--rw index uint32 439 | +--rw color-type? color-type 440 | +--rw action-type? action-type 441 | +--rw action? string 442 +--rw routing-protocol* [type] 443 | +--rw type protocol-type 444 | +--rw (para)? 445 | +--:(static) 446 | | +--rw static* [index] 447 | | +--rw index uint32 448 | | +--rw dest-cidr? inet:ip-address 449 | | +--rw egress-tp? yang:uuid 450 | | +--rw route-preference? string 451 | | +--rw next-hop? inet:ip-address 452 | +--:(bgp) 453 | +--rw bgp* [index] 454 | +--rw index uint32 455 | +--rw as-no? uint64 456 | +--rw max-prefix? int32 457 | +--rw max-prefix-alarm? uint32 458 | +--rw peer-address? inet:ip-address 459 +--rw admin-state? admin-state 460 +--ro oper-state? oper-state 462 6.1.1. Termination Point Basic Information 464 The tp-basic list describes the basic information that is used to 465 express attachment point information(e.g., PE information) and QoS 466 requirements( see section 6.1.1.1 for details)of the network access 467 connectivity from the Termination Point (TP) of view. That means the 468 information described here is relative static, no matter which two 469 pair of peer TPs are going to connect. 471 The type-Spec list describes the layered information on the TP, such 472 as ethernet layer information, or the IP layer and VXLAN information 473 if any higher layer protocol is enabled. 475 6.1.1.1. QoS 477 This model supports two kinds of QoS requirements as described in the 478 section 7 and section 8: 480 TP based QoS: Describes the QoS attributes on a termination point. 481 For example, the CAR (committed access rate) definition on the 482 inbound or outbound ports. 484 Flow based QoS: Describes the QoS attributes on a service flow. 485 This enables the fine grained QoS control with the capability of 486 identifying the service flow. 488 Both are applicable to network access connectivity between any two 489 peers within domain or across domain. 491 For TP based QoS, this model defines the following QoS attributes: 493 o "qos-config-type": Specify QoS configuration type. This model 494 support the following setting:standard and custom. 496 o " qos-sub-type": Specify QoS detailed configuration type. This 497 model support the following settings: car, diffserv, 498 diffservdomain,QoS Profile. 500 o "in-profile-id": Identification of the QoS Profile to be used for 501 downstream traffic. Local administration meaning. 503 o "out-profile-id": Identification of the QoS Profile to be used for 504 upsteam trafic. Local administration meaning. 506 o "in-tp-car":describe service bandwidth configurations for 507 downstream traffic. 509 o "out-tp-car": describe service bandwidth configurations for 510 upstream traffic. 512 For Flow based QoS, this model defines the following QoS attributes: 514 o "qos-config-type": Specify QoS configuration type. This model 515 support the following setting:standard and custom. 517 o "qos-sub-type": Specify QoS detailed configuration type. This 518 model support the following settings: car, diffserv, 519 diffservdomain,QoS Profile. 521 o "in-template-id": Identification of the Flow template to be used 522 for downstream flow.Local administration meaning. 524 o "out-template-id": Identification of the Flow template to be used 525 for upstream flow. Local administration meaning. 527 o " flow-service": describe service bandwidth configuration for each 528 service flow. 530 6.1.2. Peer CE Node 532 The peer-ce-node describes CE node information associated with access 533 point including CE node information, TP information,address and 534 location. The peer CE node can be used together with the node-id and 535 node-addr under access-point list to identify the source endpoint and 536 destination endpoint of network access connectivity between any two 537 routers(e.g., PE or ASBR)at the edge of each domain. 539 6.1.3. Routing Protocols 541 The "routing-protocol" list defines which routing protocol must be 542 activated between any two routers(e.g., PE or ASBR)at the edge of 543 each domain. The current model supports the following settings: bgp, 544 rip, ospf, static. In addition, the "routing-protocol" list in this 545 model can be augmented with any possible routing protocols. The BGP 546 and static routing list are examples to show how these two widely 547 used routing protocols are described. 549 6.2. Segmented VPN 551 As a large network grows, it might become desirable to partition the 552 network into multiple domains or segments. The segment-vpn list 553 describes a list of Segmented VPN information from the segment point 554 of view. i.e., specify how it communicates with peered devices 555 outside this Segmented VPN. The segmented VPN information is 556 composed of basic VPN information and a list of access points. The 557 set of access points are ougoing interfaces that customer sites or 558 other segmented VPNs can attach. The Segmented VPN could be a layer 559 2 VPN, or layer 3 VPN,or even a termination point. The segment-vpn 560 list can be used as key component for both "ietf-composed-vpn-svc" 561 and "ietf-segmented-vpn". 563 +--rw segment-vpns 564 +--rw segment-vpn* [index] 565 +--rw index uint32 566 +--rw protect-role? protection-role 567 +--rw vpn-info 568 +--rw (vpn-type)? 569 +--:(wan-vpn) 570 +--rw vpn 571 +--rw vpn-id? yang:uuid 572 +--rw vpn-name? string 573 +--rw topo? Topology 574 +--rw service-type? service-type 575 +--rw technology? tunnel-type 576 +--rw admin-state? admin-state 577 +--ro oper-state? oper-state 578 +--ro sync-state? sync-state 579 +--rw access-point* [tp-id] 580 ... 582 7. Composed VPN YANG Module 584 file "ietf-composed-vpn-svc.yang" 585 module ietf-composed-vpn-svc { 586 namespace "urn:ietf:params:xml:ns:yang:ietf-composed-vpn-svc" ; 587 prefix cvpn ; 588 import ietf-yang-types { 589 prefix yang; 590 } 591 import ietf-segmented-vpn { 592 prefix svpn; 593 } 594 organization "IETF OPSAWG Working Group"; 595 contact " 596 WG Web: 597 WG List: 599 Editor: Roni Even 600 601 Qin Wu 602 603 Ying Cheng 604 "; 605 description "ietf-compsed-vpn"; 606 revision 2018-08-21 { 607 reference "draft-evenwu-opsawg-yang-composed-vpn-00"; 608 } 610 grouping vpn-basic { 611 description "VPNBasicInfo Grouping."; 612 leaf topo { 613 type svpn:topology; 614 description "current support for full-mesh and 615 point_to_multipoint(hub-spoke), others is reserved for 616 future extensions." ; 617 } 618 leaf service-type { 619 type svpn:service-type; 620 description "current support for mpls l3vpn/vxlan/L2VPN 621 overlay, others is reserved for future extensions." ; 622 } 623 leaf technology { 624 type svpn:tunnel-type; 625 description "mpls|vxlan overlay l3vpn|eth over sdh|nop"; 626 } 627 leaf admin-state { 628 type svpn:admin-state; 629 description "administrative status." ; 630 } 631 leaf oper-State { 632 type svpn:oper-state; 633 config false; 634 description "Operational status." ; 635 } 636 leaf sync-state { 637 type svpn:sync-state; 638 config false; 639 description "Sync status." ; 640 } 641 leaf start-time { 642 type yang:date-and-time; 643 description "Service lifecycle: request for service start 644 time." ; 645 } 646 } 648 container composed-vpns{ 649 description ""; 650 list composed-vpn { 651 key "vpn-id"; 652 description "List for composed VPNs."; 653 uses composedvpn; 654 } 655 } 657 grouping composedvpn { 658 description "ComposedVPN Grouping."; 659 leaf vpn-id { 660 type yang:uuid; 661 description "Composed VPN identifier." ; 662 } 663 leaf vpn-name { 664 type string {length "0..200";} 665 description "Composed VPN Name. Local administration meaning" ; 666 } 667 leaf customer-name { 668 type yang:uuid; 669 description 670 "Name of the customer that actually uses the VPN service. 671 In the case that any intermediary (e.g., Tier-2 provider 672 or partner) sells the VPN service to their end user 673 on behalf of the original service provider (e.g., Tier-1 674 provider), the original service provider may require the 675 customer name to provide smooth activation/commissioning 676 and operation for the service." ; 677 } 678 uses vpn-basic; 679 list segment-vpn { 680 key "index"; 681 description "SegVpn list "; 682 uses svpn:segment-vpn; 683 } 684 list access-points { 685 key "tp-id"; 686 description "TP list of the access links which associated 687 with CE and PE"; 688 uses svpn:termination-point; 689 } 690 } 691 } 693 695 8. Segment VPN YANG Module 697 file "ietf-segmented-vpn.yang" 698 module ietf-segmented-vpn { 699 namespace "urn:ietf:params:xml:ns:yang:ietf-segmented-vpn" ; 700 prefix svpn; 701 import ietf-yang-types { 702 prefix yang; 703 } 704 import ietf-inet-types { 705 prefix inet; 706 } 707 organization "IETF OPSAWG Working Group"; 708 contact " 709 WG Web: 710 WG List: 712 Editor: Roni Even 713 714 Qin Wu 715 716 Cheng Ying 717 "; 718 description 719 "This YANG module defines a generic service configuration 720 model for Composed VPNs. This model is common across all 721 vendor implementations."; 722 revision 2018-08-21 { 723 reference "draft-opsawg-evenwu-yang-composed-vpn-00"; 724 } 725 typedef edge-role { 726 type enumeration { 727 enum nop { 728 description "nop"; 729 } 730 enum pe { 731 description "PE"; 732 } 733 enum p { 734 description "P"; 735 } 736 enum uni { 737 description "UNI"; 738 } 739 enum nni { 740 description "NNI"; 741 } 742 enum asbtp { 743 description "AsbTP"; 744 } 745 } 746 description "Edge Point Role."; 747 } 748 typedef topo-role { 749 type enumeration { 750 enum hub { 751 description "hub"; 752 } 753 enum spoke { 754 description "spoke"; 756 } 757 enum other { 758 description "other"; 759 } 760 } 761 description "Topo Node Role."; 762 } 763 typedef protection-role { 764 type enumeration { 765 enum nop{ 766 description "NOP"; 767 } 768 enum main{ 769 description "MAIN"; 770 } 771 } 772 description "Protection Role."; 773 } 774 typedef qos-config-type { 775 type enumeration { 776 enum nop{ 777 description "nop."; 778 } 779 enum template{ 780 description "standard."; 781 } 782 enum agile{ 783 description "custom."; 784 } 785 } 786 description "Qos Config Type."; 787 } 788 typedef qos-sub-type { 789 type enumeration { 790 enum nop{ 791 description "nop"; 792 } 793 enum car{ 794 description "CAR"; 795 } 796 enum qosProfile{ 797 description "Qos Profile"; 798 } 799 enum diffservdomain{ 800 description "diffServDomain"; 801 } 802 enum diffserv{ 803 description "diffServ"; 805 } 806 } 807 description "Qos Detail Type"; 808 } 809 typedef tp-type{ 810 type enumeration { 811 enum nop { 812 description "nop"; 813 } 814 enum ptp { 815 description "PTP"; 816 } 817 enum ctp { 818 description "CTP"; 819 } 820 enum trunk { 821 description "TRUNK"; 822 } 823 enum loopback { 824 description "LoopBack"; 825 } 826 enum tppool { 827 description "TPPool"; 828 } 829 } 830 description "Tp Type."; 831 } 832 typedef layer-rate{ 833 type enumeration { 834 enum lr-unknow { 835 description "Layer Rate UNKNOW."; 836 } 837 enum lr-ip { 838 description "Layer Rate IP."; 839 } 840 enum lr-eth { 841 description "Layer Rate Ethernet."; 842 } 843 enum lr_vxlan { 844 description "Layer Rate VXLAN."; 845 } 846 } 847 description "Layer Rate."; 848 } 849 typedef admin-state { 850 type enumeration { 851 enum active { 852 description "Active status"; 854 } 855 enum inactive { 856 description "Inactive status"; 857 } 858 enum partial { 859 description "Partial status"; 860 } 861 } 862 description "Admin State."; 863 } 864 typedef oper-state { 865 type enumeration { 866 enum up { 867 description "Up status"; 868 } 869 enum down { 870 description "Down status"; 871 } 872 enum degrade { 873 description "Degrade status"; 874 } 875 } 876 description "Operational Status."; 877 } 878 typedef sync-state { 879 type enumeration { 880 enum sync { 881 description "Sync status"; 882 } 883 enum out-sync { 884 description "Out sync status"; 885 } 886 } 887 description "Sync Status"; 888 } 889 typedef eth-encap-type { 890 type enumeration { 891 enum default { 892 description "DEFAULT"; 893 } 894 enum dot1q { 895 description "DOT1Q"; 896 } 897 enum qinq { 898 description "QINQ"; 899 } 900 enum untag { 901 description "UNTAG"; 903 } 904 } 905 description "Ethernet Encap Type."; 906 } 907 typedef protocol-type { 908 type enumeration { 909 enum static { 910 description "Static Routing"; 911 } 912 enum bgp { 913 description "bgp"; 914 } 915 enum rip { 916 description "rip"; 917 } 918 enum ospf { 919 description "ospf"; 920 } 921 enum isis { 922 description "isis"; 923 } 924 } 925 description "Routing Protocol Type"; 926 } 927 typedef tunnel-type { 928 type enumeration { 929 enum NOP{ 930 description "NOP"; 931 } 932 enum MPLS{ 933 description "MPLS"; 934 } 935 enum MPLS-TP{ 936 description "MPLS-TP"; 937 } 938 enum MPLS-SR { 939 description "MPLS Segment Routing"; 940 } 941 enum SRv6 { 942 description "SRv6"; 943 } 945 } 946 description "VPN Tunnel Type."; 947 } 948 typedef service-type { 949 type enumeration { 950 enum l3vpn { 951 description "l3vpn"; 952 } 953 enum l2vpn { 954 description "l2vpn"; 955 } 956 enum hybrid { 957 description "hybrid vpn"; 958 } 959 enum vxlan { 960 description "vxlan"; 961 } 962 } 963 description "VPN Service Type."; 964 } 965 typedef topology { 966 type enumeration { 967 enum any-to-any { 968 description "any to any"; 969 } 970 enum hub-spoke { 971 description "hub and spoke VPN topology."; 972 } 973 enum hub-spoke-disjoint { 974 description "Hub and spoke VPN topology where 975 Hubs cannot communicate with each other "; 976 } 977 enum unknow { 978 description "unknown."; 979 } 980 } 981 description "Topology."; 982 } 984 typedef ethernet-action { 985 type enumeration { 986 enum nop { 987 description "nop"; 988 } 989 enum untag { 990 description "UNTAG"; 991 } 992 enum stacking { 993 description "STACKING"; 994 } 995 } 996 description "Ethernet Action."; 997 } 998 typedef color-type{ 999 type enumeration { 1000 enum green{ 1001 description "green"; 1002 } 1003 enum yellow{ 1004 description "yellow"; 1005 } 1006 enum red{ 1007 description "red"; 1008 } 1009 enum all{ 1010 description "all"; 1011 } 1012 } 1013 description "Color Type."; 1014 } 1015 typedef action-type { 1016 type enumeration { 1017 enum nop{ 1018 description "nop"; 1019 } 1020 enum bandwidth{ 1021 description "bandwidth"; 1022 } 1023 enum pass{ 1024 description "pass"; 1025 } 1026 enum discard{ 1027 description "discard"; 1028 } 1029 enum remark{ 1030 description "remark"; 1031 } 1032 enum redirect{ 1033 description "redirect"; 1034 } 1035 enum recolor{ 1036 description "recolor"; 1037 } 1038 enum addRt{ 1039 description "addRt"; 1040 } 1041 } 1042 description "Action Type"; 1043 } 1044 //----------------------------------------------// 1045 //typedef 1046 //----------------------------------------------// 1047 typedef PWTagMode { 1048 type enumeration { 1049 enum raw{ 1050 description "RAW"; 1051 } 1052 enum tagged{ 1053 description "TAGGED"; 1054 } 1055 } 1056 description "PWTagMode"; 1057 } 1058 grouping QinQVlan { 1059 description "QinQVlan Grouping."; 1060 leaf-list cvlan { 1061 type uint64; 1062 description "cvlan List."; 1063 } 1064 leaf svlan { 1065 type uint64; 1066 description "svlan."; 1067 } 1068 } 1069 grouping Dot1QVlan { 1070 description "Dot1QVlan Grouping."; 1071 leaf-list dot1q { 1072 type uint64; 1073 description "dot1q Vlan List"; 1074 } 1075 } 1076 //TpTypeSpec 1077 grouping tp-type-spec{ 1078 description "Tp Type Spec Grouping."; 1079 leaf layer-rate { 1080 type layer-rate; 1081 description "layer Rate"; 1082 } 1083 choice spec-value { 1084 description "Spec Value"; 1085 case lr-eth { 1086 container eth { 1087 description "ethernetSpec"; 1088 uses ethernet-spec; 1089 } 1090 } 1091 case lr-ip { 1092 container ip { 1093 description "ipSpec"; 1094 uses IpSpec; 1096 } 1097 } 1098 case lr-pw { 1099 container pw { 1100 description "PwSpec"; 1101 uses PwSpec; 1102 } 1103 } 1104 case lr-vxlan { 1105 container vxlan { 1106 description "vxlanSpec"; 1107 uses VxlanSpec; 1108 } 1109 } 1110 } 1111 } 1112 grouping FlowServices { 1113 description "FlowServices Grouping."; 1114 leaf qos-config-type { 1115 type qos-config-type; 1116 description "qos Config Type."; 1117 } 1118 leaf qos-sub-type { 1119 type qos-sub-type; 1120 description "qosDetailType"; 1121 } 1122 leaf in-template-id { 1123 type yang:uuid; 1124 description "in Flow Qos Template ID."; 1125 } 1126 leaf out-template-id { 1127 type yang:uuid; 1128 description "out Flow Qos Template ID."; 1129 } 1130 list flow-service { 1131 key class-id; 1132 description "default in flow and behaviors"; 1133 uses FlowAndBehavior; 1134 } 1135 } 1136 grouping TPQosNode { 1137 description "TPQosNode Grouping."; 1138 leaf qos-config-type { 1139 type qos-config-type; 1140 description "qos Config Type."; 1141 } 1142 leaf qos-sub-ype { 1143 type qos-sub-type; 1144 description "qos Detail Type"; 1145 } 1146 leaf in-profile-id { 1147 type yang:uuid; 1148 description "inQosProfileId"; 1149 } 1150 leaf out-profile-id { 1151 type yang:uuid; 1152 description "outQosProfileId"; 1153 } 1154 list in-tp-car { 1155 key index; 1156 uses FlowBehavior; 1157 description "inTpCar"; 1158 } 1159 list out-tp-car { 1160 key index; 1161 uses FlowBehavior; 1162 description "outTpCar"; 1163 } 1164 } 1166 //CE spec 1167 grouping CeTp { 1168 description "CeTp Grouping."; 1169 leaf ce-id { 1170 type yang:uuid; 1171 description "Site router ID"; 1172 } 1173 leaf ce-node-id { 1174 type yang:uuid; 1175 description "directly connected NE node ID, only valid in 1176 asbr "; 1177 } 1178 leaf ce-tp-id { 1179 type yang:uuid; 1180 description "ce Directly connected TP id, only valid in asbr"; 1181 } 1182 leaf ce-address { 1183 type inet:ip-address; 1184 description "ceIfmasterIp"; 1185 } 1186 leaf location { 1187 type string {length "0..400";} 1188 description "CE device location "; 1189 } 1190 } 1191 //TPBasicInfo 1192 grouping TPBasicInfo { 1193 description "TPBasicInfo Grouping."; 1194 leaf tp-id { 1195 type yang:uuid; 1196 description "An identifier for termination point on a node."; 1197 } 1198 leaf tp-name { 1199 type string {length "0..200";} 1200 description "The termination point Name on a node. It conforms to 1201 name rule defined in system. Example FE0/0/1, GE1/2/1.1, 1202 Eth-Trunk1.1, etc"; 1203 } 1204 leaf node-id { 1205 type yang:uuid; 1206 description "Identifier for a node."; 1207 } 1208 leaf edge-role { 1209 type edge-role; 1210 description "edge role for TP, for example:UNI/NNI "; 1211 } 1212 leaf topo-role { 1213 type topo-role; 1214 description "hub/spoke role, etc"; 1215 } 1216 leaf tp-type { 1217 type tp-type; 1218 description "Type"; 1219 } 1220 leaf working-layer { 1221 type layer-rate; 1222 description "working layer"; 1223 } 1224 list type-spec { 1225 key "layer-rate"; 1226 uses tp-type-spec; 1227 description "typeSpecList"; 1228 } 1229 container tp-qos-node { 1230 description "tp Qos Node."; 1231 uses TPQosNode; 1232 } 1233 container flow-services{ 1234 description "flow services in one TP."; 1235 uses FlowServices; 1236 } 1237 } 1238 grouping RouteProtocolSpec { 1239 description "Routing Protocol Spec Grouping."; 1240 leaf type { 1241 type protocol-type; 1242 description "Protocol type" ; 1243 } 1244 choice para { 1245 description "para" ; 1246 case static { 1247 list static { 1248 key "index"; 1249 uses StaticRouteItem; 1250 description "staticRouteItems" ; 1251 } 1252 } 1253 case bgp { 1254 list bgp { 1255 key "index"; 1256 uses BGPProtocolItem; 1257 description "bgpProtocols" ; 1258 } 1259 } 1260 } 1261 } 1262 grouping BGPProtocolItem { 1263 description "BGPProtocolItem Grouping."; 1264 leaf index { 1265 type uint32; 1266 description "index of BGP protocol item"; 1267 } 1268 leaf as-no { 1269 type uint64; 1270 description "Peer AS Number."; 1271 } 1272 leaf max-prefix { 1273 type int32; 1274 description "maximum number limit of prefixes."; 1275 } 1276 leaf max-prefix-alarm { 1277 type uint32; 1278 description "alarm threshold of BGP rout"; 1279 } 1280 leaf peer-address { 1281 type inet:ip-address; 1282 description "peerIp"; 1283 } 1284 } 1285 grouping StaticRouteItem { 1286 description "StaticRouteItem Grouping."; 1287 leaf index { 1288 type uint32; 1289 description "static item index"; 1290 } 1291 leaf dest-cidr { 1292 type string; 1293 description "address prefix specifying the set of 1294 destination addresses for which the route may be 1295 used. "; 1296 } 1297 leaf egress-tp { 1298 type yang:uuid; 1299 description "egress tp"; 1300 } 1301 leaf route-preference { 1302 type string; 1303 description "route priority. Ordinary, work route have 1304 higher priority."; 1305 } 1306 leaf next-hop { 1307 type inet:ip-address; 1308 description "Determines the outgoing interface and/or 1309 next-hop address(es), or a special operation to be 1310 performed on a packet.."; 1311 } 1312 } 1313 grouping ethernet-spec { 1314 description "Ethernet Spec Grouping."; 1315 leaf access-type { 1316 type eth-encap-type; 1317 description "access frame type"; 1318 } 1319 choice accessVlanValue { 1320 description "accessVlanValue"; 1321 case qinq { 1322 container qinq { 1323 description "qinqVlan"; 1324 uses QinQVlan; 1325 } 1326 } 1327 case dot1q { 1328 container dot1q { 1329 description "dot1q"; 1330 uses Dot1QVlan; 1331 } 1332 } 1333 } 1334 leaf vlan-action { 1335 type ethernet-action; 1336 description "specify the action when the vlan is matched"; 1337 } 1338 leaf action { 1339 type string{length "0..100";} 1340 description "specify the action value."; 1341 } 1342 } 1343 grouping PwSpec { 1344 description "PwSpec Grouping."; 1345 leaf control-word { 1346 type boolean; 1347 default false; 1348 description "control Word."; 1349 } 1350 leaf vlan-action { 1351 type PWTagMode; 1352 description "pw Vlan Action."; 1353 } 1354 } 1355 grouping IpSpec { 1356 description "IpSpec Grouping."; 1357 leaf ip-address { 1358 type inet:ip-address; 1359 description "master IP address"; 1360 } 1361 leaf mtu { 1362 type uint64; 1363 description "mtu for ip layer,scope:46~9600"; 1364 } 1365 } 1366 grouping VxlanSpec { 1367 description "VxlanSpec Grouping."; 1368 leaf vni { 1369 type uint32; 1370 description "vni"; 1371 } 1372 leaf vtep-ip { 1373 type inet:ip-address; 1374 description "vtep ip"; 1375 } 1376 } 1377 grouping FlowAndBehavior { 1378 description "FlowAndBehavior Grouping."; 1379 leaf class-id { 1380 type yang:uuid; 1381 description "flowClassifierId"; 1382 } 1383 list flow-behavior { 1384 key index; 1385 uses FlowBehavior; 1386 description "flowBehaviors"; 1387 } 1388 } 1389 grouping FlowBehavior { 1390 description "FlowAndBehavior Grouping."; 1391 leaf index { 1392 type uint32; 1393 description "index"; 1394 } 1395 leaf color-type { 1396 type color-type; 1397 description "Color Type."; 1398 } 1399 leaf action-type { 1400 type action-type; 1401 description "action Type"; 1402 } 1403 leaf action { 1404 type string; 1405 description "action"; 1406 } 1407 } 1408 grouping VPNBasicInfo { 1409 description "VPNBasicInfo Grouping."; 1410 leaf topo { 1411 type topology; 1412 description "current support for full-mesh and 1413 hub-spoke, others is reserved for 1414 future extensions." ; 1415 } 1416 leaf service-type { 1417 type service-type; 1418 description "current support for mpls l3vpn/vxlan/L2VPN 1419 overlay, others is reserved for future extensions." ; 1420 } 1421 leaf technology { 1422 type tunnel-type; 1423 description "mpls|vxlan overlay l3vpn|eth over sdh|nop"; 1424 } 1425 leaf admin-state { 1426 type admin-state; 1427 description "administrative status." ; 1428 } 1429 leaf oper-state { 1430 type oper-state; 1431 config false; 1432 description "Operational status." ; 1433 } 1434 leaf sync-state { 1435 type sync-state; 1436 config false; 1437 description "Sync status." ; 1438 } 1439 } 1440 grouping VPN { 1441 description "VPN Grouping."; 1442 leaf vpn-id { 1443 type yang:uuid ; 1444 description "VPN Identifier." ; 1445 } 1446 leaf vpn-name { 1447 type string {length "0..200";} 1448 description "Human-readable name for the VPN service." ; 1449 } 1450 uses VPNBasicInfo; 1451 list access-point { 1452 key "tp-id"; 1453 description "TP list of the access links which associated 1454 with CE and PE"; 1455 uses termination-point; 1456 } 1457 } 1458 grouping termination-point { 1459 description "grouping for termination points."; 1460 leaf tp-id { 1461 type yang:uuid; 1462 description "An identifier for termination point on a node."; 1463 } 1464 container peer-ce-node { 1465 description "CE TP Information."; 1466 uses CeTp; 1467 } 1468 container tp-basic { 1469 description "Termination point basic info."; 1470 uses TPBasicInfo; 1471 } 1472 list routing-protocol { 1473 key "type"; 1474 description "route protocol spec."; 1475 uses RouteProtocolSpec; 1476 } 1477 leaf admin-state { 1478 type admin-state; 1479 description "administrative status."; 1481 } 1482 leaf oper-state { 1483 type oper-state; 1484 config false; 1485 description "Operational status." ; 1486 } 1487 } 1488 grouping segment-vpn { 1489 description "SegmentVPN Grouping."; 1490 leaf index { 1491 type uint32; 1492 description "index of segment VPN in a composed VPN."; 1493 } 1494 leaf protect-role { 1495 type protection-role; 1496 description "The protection role of segment VPN, by 1497 default it is set as nop role."; 1498 } 1499 container vpn-info { 1500 description "vpn information"; 1501 choice vpn-type { 1502 description "vpn type."; 1503 case wan-vpn { 1504 container vpn { 1505 description "vpn."; 1506 uses VPN; 1507 } 1508 } 1509 } 1510 } 1511 } 1512 container segment-vpns { 1513 list segment-vpn { 1514 key "index"; 1515 description "Segment Vpn list."; 1516 uses segment-vpn; 1517 } 1518 description 1519 "Container for Segment VPN."; 1520 } 1521 } 1522 1524 9. Service Model Usage Example 1526 This section provides an example of how a management system can use 1527 this model to configure an IP VPN service on network elements. 1529 +-----------------------------------------------------------------------+ 1530 | ------- PE2----- Spoke_Site1 | 1531 | | | 1532 | Hub_Site -----PE1------ASBR1-------- ASBR2 | 1533 | | | 1534 | --------PE3 ---- Spoke_Site2 | 1535 +----------------|----------|--------------|--------|-------------------+ 1536 | | | | 1537 | | | 1538 | | | | 1539 | | | | 1540 | Intra-AS | Inter-AS |Intra-AS| 1541 | | 1542 |<--------Composed VPN ----------->| 1544 In this example, we want to achieve the provisioning of a end to end 1545 VPN service for three sites using a Hub-and-Spoke VPN service 1546 topology. The end to end VPN service is stitched by three segmented 1547 VPN, two are within intra-AS domain, one is within inter AS domain. 1549 The following XML snippet describes the overall simplified service 1550 configuration of this composed VPN. 1552 1553 1554 1555 12456487 1556 hub-spoke 1557 hybrid 1558 1559 1 1560 1561 111 1562 hub-spoke 1563 l2vpn 1564 1565 ASBR1 1566 1567 PE1 1568 1569 1570 hub 1571 1572 TEMPLATE-A 1573 TEMPLATE-B 1574 1575 1576 1577 1578 AS1 1579 1580 1581 1582 1584 1585 2 1586 1587 222 1588 hub-spoke 1589 l3vpn 1590 1591 ASBR2 1592 1593 ASBR1 1594 1595 1596 hub 1597 1598 TEMPLATE-B 1599 TEMPLATE-C 1600 1601 1602 1603 1604 interAS-1 1605 1606 1607 1608 1609 1610 1611 3 1612 1613 333 1614 hub-spoke 1615 l2vpn 1616 1617 PE2 1618 1619 ASBR2 1620 1621 1622 spoke 1623 1624 TEMPLATE-B 1625 TEMPLATE-D 1626 1627 1628 1629 1630 AS2 1631 1632 1633 1634 1636 1637 1639 10. Interaction with other YANG models 1641 As expressed in Section 4, this composed VPN service model is 1642 intended to be instantiated in a management system and not directly 1643 on network elements. 1645 The management system's role will be to configure the network 1646 elements. The management system may be modular and distinguish the 1647 component instantiating the service model (let's call it "service 1648 component") from the component responsible for network element 1649 configuration (let's call it "configuration component"). The service 1650 is built from a combination of networkelements and protocols 1651 configuration which also include various aspects of the underlying 1652 network infrastructure, including functions/devices and their 1653 subsystems, and relevant protocols operating at the link and network 1654 layers across multiple device. Therfore there will be a strong 1655 relationship between the abstracted view provided by this service 1656 model and the detailed configuration view that will be provided by 1657 specific configuration models for network elements. 1659 The service component will take input from customer service model 1660 such as L3SM service model or composed VPN service model and 1661 translate it into segment VPN in each domain and then further break 1662 down the segment VPN into detailed configuration view that will be 1663 provided by specific configuration models for network elements. 1665 11. Security Considerations 1667 The YANG module specified in this document defines a schema for data 1668 that is designed to be accessed via network management protocols such 1669 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1670 is the secure transport layer, and the mandatory-to-implement secure 1671 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1672 is HTTPS, and the mandatory-to-implement secure transport is TLS 1673 [RFC5246]. 1675 The NETCONF access control model [RFC6536] provides the means to 1676 restrict access for particular NETCONF or RESTCONF users to a 1677 preconfigured subset of all available NETCONF or RESTCONF protocol 1678 operations and content. 1680 There are a number of data nodes defined in this YANG module that are 1681 writable/creatable/deletable (i.e., config true, which is the 1682 default). These data nodes may be considered sensitive or vulnerable 1683 in some network environments. Write operations (e.g., edit-config) 1684 to these data nodes without proper protection can have a negative 1685 effect on network operations. These are the subtrees and data nodes 1686 and their sensitivity/vulnerability: 1688 o /composed-vpns/composed-vpn 1690 The entries in the list above include the whole composed vpn 1691 service configurations which the customer subscribes, and 1692 indirectly create or modify the PE,CE and ASBR device 1693 configurations. Unexpected changes to these entries could lead to 1694 service disruption and/or network misbehavior. 1696 o /composed-vpns/composed-vpn/seg-vpns 1698 The entries in the list above include the access points 1699 configurations. As above, unexpected changes to these entries 1700 could lead to service disruption and/or network misbehavior. 1702 o /composed-vpns/composed-vpn/access-points 1704 The entries in the list above include the access points 1705 configurations. As above, unexpected changes to these entries 1706 could lead to service disruption and/or network misbehavior. 1708 12. IANA Considerations 1710 This document registers a URI in the IETF XML registry [RFC3688]. 1711 Following the format in [RFC3688], the following registrations are 1712 requested to be made: 1714 --------------------------------------------------------------------- 1715 URI: urn:ietf:params:xml:ns:yang:ietf-composed-vpn-svc 1716 Registrant Contact: The IESG 1717 XML: N/A; the requested URI is an XML namespace. 1719 URI: urn:ietf:params:xml:ns:yang:ietf-segmented-vpn 1720 Registrant Contact: The IESG 1721 XML: N/A; the requested URI is an XML namespace. 1722 --------------------------------------------------------------------- 1724 This document registers two YANG modules in the YANG Module Names 1725 registry [RFC6020]. 1727 --------------------------------------------------------------------- 1728 Name: ietf-composite-vpn-svc 1729 Namespace: urn:ietf:params:xml:ns:yang:ietf-composed-vpn-svc 1730 Prefix: composite-svc 1731 Reference: RFC xxxx 1732 Name: ietf-segmented-vpn 1733 Namespace: urn:ietf:params:xml:ns:yang:ietf-segmented-vpn 1734 Prefix: segment-vpn 1735 Reference: RFC xxxx 1736 --------------------------------------------------------------------- 1738 13. Normative References 1740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1741 Requirement Levels", March 1997. 1743 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1744 DOI 10.17487/RFC3688, January 2004, 1745 . 1747 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1748 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1749 2006, . 1751 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1752 (TLS) Protocol Version 1.2", RFC 5246, 1753 DOI 10.17487/RFC5246, August 2008, 1754 . 1756 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1757 the Network Configuration Protocol (NETCONF)", RFC 6020, 1758 DOI 10.17487/RFC6020, October 2010, 1759 . 1761 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1762 and A. Bierman, Ed., "Network Configuration Protocol 1763 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1764 . 1766 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1767 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1768 . 1770 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1771 Profile (MPLS-TP) Identifiers", RFC 6370, 1772 DOI 10.17487/RFC6370, September 2011, 1773 . 1775 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1776 Protocol (NETCONF) Access Control Model", RFC 6536, 1777 DOI 10.17487/RFC6536, March 2012, 1778 . 1780 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1781 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1782 . 1784 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1785 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1786 . 1788 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1789 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1790 . 1792 Appendix A. Acknowledges 1794 Geng Liang,Congfeng Xie, Chen Rui, LiYa Zhang,Hui Deng contributed to 1795 an earlier version of [I-D.chen-opsawg-composite-vpn-dm]. We would 1796 like to thank the authors of that document on the operators' view for 1797 the PE-based VPN service configuration for material that assisted in 1798 thinking about this document. 1800 Authors' Addresses 1802 Roni Even 1803 Huawei Technologies,Co.,Ltd 1804 Tel Aviv 1805 Israel 1807 Email: roni.even@huawei.com 1808 Qin Wu 1809 Huawei 1810 101 Software Avenue, Yuhua District 1811 Nanjing, Jiangsu 210012 1812 China 1814 Email: bill.wu@huawei.com 1816 YingCheng 1817 China Unicom 1818 No.21 Financial Street, XiCheng District 1819 Beijing 100033 1820 China 1822 Email: chengying10@chinaunicom.cn