idnits 2.17.1 draft-evenwu-opsawg-yang-composed-vpn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 80 instances of too long lines in the document, the longest one being 35 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 451 has weird spacing: '...n-class lay...' == Line 486 has weird spacing: '...ndwidth uin...' == Line 540 has weird spacing: '...percent dec...' == Line 557 has weird spacing: '...-system uin...' == Line 583 has weird spacing: '...n-class lay...' == (3 more instances...) == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 8, 2019) is 1870 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: 'I-D.chen-opsawg-composite-vpn-dm' is mentioned on line 2851, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 3 errors (**), 0 flaws (~~), 9 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 B. Wu 4 Intended status: Standards Track Q. Wu 5 Expires: September 9, 2019 Huawei 6 Y. Cheng 7 China Unicom 8 March 8, 2019 10 YANG Data Model for Composed VPN Service Delivery 11 draft-evenwu-opsawg-yang-composed-vpn-03 13 Abstract 15 This document defines a YANG data model that can be used by a network 16 operator to configure a VPN service that spans multiple 17 administrative domains and that is constructed from component VPNs in 18 each of those administrative domains. The component VPNs may be 19 L2VPN or L3VPN or a mixture of the two. This model is intended to be 20 instantiated at the management system to deliver the end to end 21 service (i.e., performing service provision and activation functions 22 at different levels through a unified interface). 24 The model is not a configuration model to be used directly on network 25 elements. This model provides an abstracted common view of VPN 26 service configuration components segmented at different layer and 27 administrative domain. It is up to a management system to take this 28 as an input and generate specific configurations models to configure 29 the different network elements within each administrative domain to 30 deliver the service. How configuration of network elements is done 31 is out of scope of the document. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 9, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 4 70 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Service Model Usage . . . . . . . . . . . . . . . . . . . . . 6 73 4. The Composed VPN Service Model . . . . . . . . . . . . . . . 7 74 4.1. VPN Service Types . . . . . . . . . . . . . . . . . . . . 7 75 4.2. Composed VPN Physical Network Topology . . . . . . . . . 7 76 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 9 77 5.1. VPN Hierarchy . . . . . . . . . . . . . . . . . . . . . . 15 78 5.2. Access Point(AP) . . . . . . . . . . . . . . . . . . . . 16 79 5.2.1. AP peering with CE . . . . . . . . . . . . . . . . . 16 80 5.2.2. AP peering for inter-domains connection . . . . . . . 17 81 6. Composed VPN YANG Module . . . . . . . . . . . . . . . . . . 19 82 7. Segment VPN YANG Module . . . . . . . . . . . . . . . . . . . 21 83 8. Service Model Usage Example . . . . . . . . . . . . . . . . . 53 84 9. Interaction with other YANG models . . . . . . . . . . . . . 56 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 57 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 58 89 12.2. Informative References . . . . . . . . . . . . . . . . . 60 90 Appendix A. Acknowledges . . . . . . . . . . . . . . . . . . . . 60 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 93 1. Introduction 95 In some cases, a VPN service needs to span different administrative 96 domains. This will usually arise when there are internal 97 administrative boundaries within a single Service Provider's (SP's) 98 network. The boundaries may reflect geographic dispersal or 99 functional decomposition, e.g., access, metro, backhaul, core, and 100 data center. 102 In particular, the different domains could deploy Layer 2 or Layer 3 103 technologies or both, and could establish layer-dependent 104 connectivity services. For example, some SPs offer a L2VPN service 105 in the metro access network and extend it across the core network as 106 an IP VPN to provide end-to-end BGP IP VPN services to their 107 enterprise customers. 109 Some SPs integrate Mobile Backhaul Network and Core networks to 110 provide mobile broadband services. These require stitching multiple 111 layer-dependent connectivity services at different administrative 112 domain boundaries. 114 This document defines a YANG data model that can be used by a network 115 operator to construct an end-to-end service across multiple 116 administrative domains. This service is delivered by provisioning 117 VPN services utilising Layer 2 or Layer 3 technologies in each 118 domain. 120 This model is intended to be instantiated at the management system to 121 deliver the overall service per [RFC8309]. It is not a configuration 122 model to be used directly on network elements. This model provides 123 an abstracted common view of VPN service configuration components 124 segmented at different layers and administrative domains. It is up 125 to a management system to take this as an input and generate specific 126 configurations models to configure the different network elements 127 within each administrative domain to deliver the service. How 128 configuration of network elements is done is out of scope of the 129 document. END 131 1.1. Terminology 133 The following terms are defined in [RFC6241] and are not redefined 134 here: 136 o client 138 o server 140 o configuration data 142 o state data 144 The following terms are defined in [RFC7950] and are not redefined 145 here: 147 o augment 149 o data model 151 o data node 153 The terminology for describing YANG data models is found in 154 [RFC7950]. 156 1.1.1. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in BCP 161 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 1.2. Tree diagram 166 Tree diagrams used in this document follow the notation defined in 167 [RFC8340]. 169 2. Definitions 171 This document uses the following terms: 173 Service Provider (SP): The organization (usually a commercial 174 undertaking) responsible for operating the network that offers VPN 175 services to clients and customers. 177 Customer Edge (CE) Device: Equipment that is dedicated to a 178 particular customer and is directly connected to one or more PE 179 devices via attachment circuits. A CE is usually located at the 180 customer premises, and is usually dedicated to a single VPN, 181 although it may support multiple VPNs if each one has separate 182 attachment circuits. The CE devices can be routers, bridges, 183 switches, or hosts. 185 Provider Edge (PE) Device: Equipment managed by the SP that can 186 support multiple VPNs for different customers, and is directly 187 connected to one or more CE devices via attachment circuits. A PE 188 is usually located at an SP point of presence (PoP) and is managed 189 by the SP. 191 Administrative Domain: A collection of End Systems, Intermediate 192 Systems, and subnetworks operated by a single organization or 193 administrative authority. The components which make up the domain 194 are assumed to interoperate with a significant degree of mutual 195 trust among themselves, but interoperate with other Administrative 196 Domains in a mutually suspicious manner [RFC1136]. 198 A group of hosts, routers, and networks operated and managed by a 199 single organization. Routing within an Administrative Domain is 200 based on a consistent technical plan. An Administrative Domain is 201 viewed from the outside, for purposes of routing, as a cohesive 202 entity, of which the internal structure is unimportant. 203 Information passed by other Administrative Domains is trusted less 204 than information from one's own Administrative Domain. 206 Administrative Domains can be organized into a loose hierarchy 207 that reflects the availability and authoritativeness of routing 208 information. This hierarchy does not imply administrative 209 containment, nor does it imply a strict tree topology. 211 Routing Domain: A set of End Systems and Intermediate Systems which 212 operate according to the same routing procedures and which is 213 wholly contained within a single Administrative Domain [RFC1136]. 215 A Routing Domain is a set of Intermediate Systems and End Systems 216 bound by a common routing procedure; namely: they are using the 217 same set of routing metrics, they use compatible metric 218 measurement techniques, they use the same information distribution 219 protocol, and they use the same path computation algorithm" An 220 Administrative Domain may contain multiple Routing Domains. A 221 Routing Domain may never span multiple Administrative Domains. 223 An Administrative Domain may consist of only a single Routing 224 Domain, in which case they are said to be Congruent. A congruent 225 Administrative Domain and Routing Domain is analogous to an 226 Internet Autonomous System. 228 Access point(AP): Describe an VPN's end point characteristics and 229 its reference to a Termination Point (TP) of the Provider Edge 230 (PE) Node; used as service access point for connectivity service 231 segment in the end-to-end manner and per administrative domain. 233 Site: Represent a connection of a customer office to one or more VPN 234 services and contain a list of network accesses associated with 235 the site. Each network access can connect to different VPN 236 service. 238 Segment VPN Describe generic information about a VPN in a single 239 administrative domain, and specific information about APs that 240 connect the Segment VPN to sites or to other Segment VPNs. 242 Composed VPN Describe generic end-to-end information about a VPN 243 that spans multiple administrative domains, and specific customer- 244 facing information about APsconnecting to each site. 246 3. Service Model Usage 248 + 249 Customer Facing Interface | L2SM or L3SM 250 +------v----------------+ 251 | Service orchestration | 252 +------+----------------+ 253 | Composed VPN 254 +------v---------------+ 255 | Network Orchestrator | 256 +----+---+-------------+ 257 | | 258 +---------+ +-----------+ 259 | | 260 +------+--------+ +------+---------+ 261 |Config manager1| | Config manager2| 262 +------+--------+ +------+---------+ 263 | | 264 +---------+-----------+ +----------+----------+ 265 | AS1 L2VPN | | AS2 L3VPN | 266 +-------+ | +------+ +------+ | | +------+ +------+ | +-------+ 267 | Site1 +----+ PE11 +---+ PE12 +------+ PE21 +---+ PE22 +----+ Site2 | 268 +-------+ | +------+ +------+ | | +------+ +------+ | +-------+ 269 +---------------------+ +---------------------+ 271 Figure 1: Service Model Usage 273 In the above use case, the network orchestrator controls and manages 274 the two distinct network domains, each controlled or managed by their 275 own management system or domain controller. There are two typical 276 ways to deploy the composed VPN model: 278 One typical scenario would be to use the model as an independent 279 model. The orchestration layer could use composed VPN model as an 280 input, and translate it to segmented VPN model for each 281 administrative domain. And the domain management system could 282 further configure network elements based on configuration obtained 283 from the segment VPN. 285 The other scenario is to use customer facing model such as L3SM 286 service model as an input for the service orchestration layer that 287 will be responsible for translating the parameters of VPN and site in 288 L3SM model to the corresponding parameters of the composed VPN model, 289 then with extra provisioning parameters added ,the composed VPN model 290 can be further broken down into per domain segmented VPN model and 291 additional Access point configuration. 293 The usage of this composed VPN model is not limited to this example; 294 it can be used by any component of the management system but not 295 directly by network elements. 297 4. The Composed VPN Service Model 299 A composed VPN represents an end-to-end IP or Ethernet connectivity 300 between the access points of PE where the AP can interconnect with 301 the enterprise customer's network or other types of overlay network. 302 The Composed VPN model provides a common understanding of how the 303 corresponding composed VPN service is to be deployed in an end to end 304 manner over the multi-domain infrastructure. 306 This document presents the Composed VPN Service Delivery Model using 307 the YANG data modeling language [RFC7950] as a formal language that 308 is both human-readable and parsable by software for use with 309 protocols such as NETCONF [RFC6241] and RESTCONF [RFC8040]. 311 4.1. VPN Service Types 313 From a technology perspective, a Composed VPN can be classified into 314 three categories based on the domain specific VPN types including 315 L2VPN and L3VPN, see Figure 2. And in each category, the 316 interworking option may vary depending on the inter-domain 317 technology, such as IP or MPLS forwarding. In some cases, the number 318 of transit domain can be zero or multiple. 320 +----------+----------+---------+ +--------+---------------+ 321 | Composed | Domain 1 | Domain 2|..|Domain N| Interworking | 322 | VPN | (source)|(transit)| | (dest) | Option | 323 |----------+----------+---------+ +--------+---------------+ 324 |L3VPN | L2VPN | L2VPN |..|L3VPN | Option A | 325 |----------+----------+---------+ +--------+---------------+ 326 |L3VPN | L3VPN | L3VPN |..|L3VPN | OptionA/B/C | 327 |----------+----------+---------+ +--------+---------------+ 328 |L2VPN | L2VPN | L2VPN |..|L2VPN | OptionA/B/C | 329 +----------+----------+---------+ +--------+---------------+ 331 Figure 2: Composed VPN classification 333 4.2. Composed VPN Physical Network Topology 335 Figure 3 describes a scenario where connectivity in the form of an 336 L3VPN is provided across a Mobile Backhaul Network. The network has 337 two ASes: connectivity across AS A is achieved with an L2VPN, and 338 across AS B an L3VPN. The ASes are interconnected, and the composed 339 VPN is achieved by interconnecting the L2VPN with the L3VPN. 341 +---------------------------Composed VPN: L3VPN 1----------------------+ 342 | (AP 1,2,7,8) | 343 | | 344 | | 345 | | 346 |+---SegVPN:VLL1.1(AP 1,3)---+ +------ SegVPN:L3VPN1.3 ----+ 347 | VLL1.2(AP 2,4) | | (AP 5,6,7,8) | 348 | | | | 349 | | | | 350 | ------------------- | | ------------------- | 351 | / AS A | |Inter-AS link| | AS B | 352 | | | | | | +------+ | 353 | +------+ | | | | |PE2 /-\ 354 /-\| PE1 | ++++++++| |++++++++ | |AP8| 355 |AP1| | + ASBRA /-\ /-\ ASBRB+ | \-/ 356 \-/| | + |AP3 _______|AP5 + +------+ 357 +------+ + \-/ \-/ + | 358 | + /-\ _______ /-\ + | 359 | + |AP4 |AP6 + | 360 +------+ +++++++ \-/ \-/+++++++ +------+ 361 /-\| | | | | /-\ 362 |AP2|PE4 | | | |PE3 |AP7| 363 \-/| | | | | \-/ 364 +------+ | | +------+ 365 \ / \ / 366 ------------------- ------------------- 368 Figure 3: Mobile Backhaul Network Scenario 370 The Composed VPN is a service that provides connectivity between AP1, 371 AP2, AP7 and AP8. As the APs of the VPN are spanning the two 372 domains, the ASBR A and B and their associated links are required to 373 be identified. Based on the decomposition, two Segment VPN could be 374 constructed to provide per domain connections. Segment VPN 1.1 and 375 Segment VPN 1.2 are connections between AP 1,2,3,4 in the domain A of 376 access metro network, which are L2VPN. Segment VPN 1.3 is the 377 connection between AP 5,6,7,8 in the core network, which is L3VPN. 378 The ASBR A and B at the edge of the access metro network is 379 performing the VPN stitching between Layer 2 VPN and Layer 3 VPN 380 using the technology such as bridging or other interconnection 381 technology. 383 The operator can predefine several VPN provisioning policies based on 384 the offered business. The policy description may include the naming, 385 path selection, VPN concatenation rules,and resource pools, such as 386 route target, route distinguisher. How VPN provision policies 387 configuration of network elements is done is out of scope of the 388 document. 390 5. Design of the Data Model 392 The idea of the composed VPN model is to decompose an end-to-end 393 L2VPN or L3VPN service across multiple administrative domains into 394 point-to-point VPN segments or multi-point VPN segments in each 395 administrative domain, and to stich these segments together by using 396 different interworking options. Therefore, a complete composed VPN 397 instance consists of: 399 o One composed VPN with corresponding composed VPN set of parameter 401 o Two or more APs, each with a corresponding set of AP parameters 403 o One or more segment VPN with corresponding segment VPN set of 404 parameter 406 Similar to the L3SM [RFC8299] and L2SM [RFC8466] modelling structure, 407 the composed VPN model consists of two main components, the VPN 408 component and the AP component. 410 The figure below describes the overall structure of the YANG module: 412 module: ietf-composed-vpn-svc 413 +--rw composed-vpns 414 +--rw composed-vpn* [vpn-id] 415 +--rw vpn-id yang:uuid 416 +--rw vpn-name? string 417 +--rw customer-name? yang:uuid 418 +--rw topo? svpn:vpn-topology 419 +--rw service-type? svpn:service-type 420 +--rw tunnel-type? svpn:tunnel-type 421 +--rw admin-state? svpn:admin-state 422 +--ro oper-State? svpn:oper-state 423 +--ro sync-state? svpn:sync-state 424 +--rw start-time? yang:date-and-time 425 +--rw segment-vpn* [vpn-id] 426 | +--rw vpn-id yang:uuid 427 | +--rw vpn-name? string 428 | +--rw service-type? service-type 429 | +--rw topo? vpn-topology 430 | +--rw tunnel-type? tunnel-type 431 | +--rw admin-state? admin-state 432 | +--ro oper-state? oper-state 433 | +--ro sync-state? sync-state 434 | +--rw access-point* [tp-id] 435 | +--rw tp-id yang:uuid 436 | +--rw tp-common-attribute 437 | | +--rw tp-id? yang:uuid 438 | | +--rw tp-name? string 439 | | +--rw node-id? yang:uuid 440 | | +--rw access-point-type? access-point-type 441 | | +--rw inter-as-option? enumeration 442 | | +--rw topology-role? topology-role 443 | +--rw peer-remote-node 444 | | +--rw remote-id? yang:uuid 445 | | +--rw location? string 446 | | +--rw remote-tp-address? inet:ip-address 447 | | +--rw remote-node-id? yang:uuid 448 | | +--rw remote-tp-id? yang:uuid 449 | +--rw tp-connection-specific-attribute 450 | | +--rw connection* [connection-class] 451 | | | +--rw connection-class layer-rate 452 | | | +--rw (connection-type)? 453 | | | +--:(lr-eth) 454 | | | | +--rw eth 455 | | | | +--rw access-type? eth-encap-type 456 | | | | +--rw (accessVlanValue)? 457 | | | | | +--:(qinq) 458 | | | | | | +--rw qinq 459 | | | | | | +--rw cvlan* uint64 460 | | | | | | +--rw svlan? uint64 461 | | | | | +--:(dot1q) 462 | | | | | +--rw dot1q 463 | | | | | +--rw dot1q* uint64 464 | | | | +--rw vlan-action? ethernet-action 465 | | | | +--rw action? string 466 | | | +--:(lr-ip) 467 | | | | +--rw ip 468 | | | | +--rw ip-address? inet:ip-address 469 | | | | +--rw mtu? uint64 470 | | | +--:(lr-pw) 471 | | | +--rw pw 472 | | | +--rw control-word? boolean 473 | | | +--rw vlan-action? pwtagmode 474 | | +--rw security-attribute 475 | | | +--rw security 476 | | | +--rw authentication 477 | | | +--rw encryption {encryption}? 478 | | | +--rw enabled? boolean 479 | | | +--rw layer? enumeration 480 | | | +--rw algorithm? string 481 | | | +--rw (key-type)? 482 | | | +--:(psk) 483 | | | +--rw preshared-key? string 484 | | +--rw qos-attribute 485 | | | +--rw svc-input-bandwidth uint64 486 | | | +--rw svc-output-bandwidth uint64 487 | | | +--rw svc-mtu uint16 488 | | | +--rw qos {qos}? 489 | | | +--rw qos-classification-policy 490 | | | | +--rw rule* [id] 491 | | | | +--rw id string 492 | | | | +--rw (match-type)? 493 | | | | | +--:(match-flow) 494 | | | | | | +--rw match-flow 495 | | | | | | +--rw dscp? inet:dscp 496 | | | | | | +--rw exp? inet:dscp 497 | | | | | | +--rw dot1p? uint8 498 | | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix 499 | | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix 500 | | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix 501 | | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix 502 | | | | | | +--rw l4-src-port? inet:port-number 503 | | | | | | +--rw peer-remote-node* string 504 | | | | | | +--rw l4-src-port-range 505 | | | | | | | +--rw lower-port? inet:port-number 506 | | | | | | | +--rw upper-port? inet:port-number 507 | | | | | | +--rw l4-dst-port? inet:port-number 508 | | | | | | +--rw l4-dst-port-range 509 | | | | | | | +--rw lower-port? inet:port-number 510 | | | | | | | +--rw upper-port? inet:port-number 511 | | | | | | +--rw src-mac? yang:mac-address 512 | | | | | | +--rw dst-mac? yang:mac-address 513 | | | | | | +--rw protocol-field? union 514 | | | | | +--:(match-application) 515 | | | | | +--rw match-application? identityref 516 | | | | +--rw target-class-id? string 517 | | | +--rw qos-profile 518 | | | +--rw (qos-profile)? 519 | | | +--:(standard) 520 | | | | +--rw profile? string 521 | | | +--:(custom) 522 | | | +--rw classes {qos-custom}? 523 | | | +--rw class* [class-id] 524 | | | +--rw class-id string 525 | | | +--rw direction? identityref 526 | | | +--rw rate-limit? decimal64 527 | | | +--rw latency 528 | | | | +--rw (flavor)? 529 | | | | +--:(lowest) 530 | | | | | +--rw use-lowest-latency? empty 531 | | | | +--:(boundary) 532 | | | | +--rw latency-boundary? uint16 533 | | | +--rw jitter 534 | | | | +--rw (flavor)? 535 | | | | +--:(lowest) 536 | | | | | +--rw use-lowest-jitter? empty 537 | | | | +--:(boundary) 538 | | | | +--rw latency-boundary? uint32 539 | | | +--rw bandwidth 540 | | | +--rw guaranteed-bw-percent decimal64 541 | | | +--rw end-to-end? empty 542 | | +--rw protection-attribute 543 | | +--rw access-priority? uint32 544 | +--rw routing-protocol* [type] 545 | +--rw type protocol-type 546 | +--rw (para)? 547 | +--:(static) 548 | | +--rw static* [index] 549 | | +--rw index uint32 550 | | +--rw dest-cidr? string 551 | | +--rw egress-tp? yang:uuid 552 | | +--rw route-preference? string 553 | | +--rw next-hop? inet:ip-address 554 | +--:(bgp) 555 | +--rw bgp* [index] 556 | +--rw index uint32 557 | +--rw autonomous-system uint32 558 | +--rw address-family* address-family 559 | +--rw max-prefix? int32 560 | +--rw peer-address? inet:ip-address 561 | +--rw crypto-algorithm identityref 562 | +--rw key-string 563 | +--rw (key-string-style)? 564 | +--:(keystring) 565 | | +--rw keystring? string 566 | +--:(hexadecimal) {hex-key-string}? 567 | +--rw hexadecimal-string? yang:hex-string 568 +--rw access-point* [tp-id] 569 +--rw tp-id yang:uuid 570 +--rw tp-name? string 571 +--rw node-id? yang:uuid 572 +--rw access-point-type? access-point-type 573 +--rw inter-as-option? enumeration 574 +--rw topology-role? topology-role 575 +--rw peer-remote-node 576 | +--rw remote-id? yang:uuid 577 | +--rw location? string 578 | +--rw remote-tp-address? inet:ip-address 579 | +--rw remote-node-id? yang:uuid 580 | +--rw remote-tp-id? yang:uuid 581 +--rw tp-connection-specific-attribute 582 | +--rw connection* [connection-class] 583 | | +--rw connection-class layer-rate 584 | | +--rw (connection-type)? 585 | | +--:(lr-eth) 586 | | | +--rw eth 587 | | | +--rw access-type? eth-encap-type 588 | | | +--rw (accessVlanValue)? 589 | | | | +--:(qinq) 590 | | | | | +--rw qinq 591 | | | | | +--rw cvlan* uint64 592 | | | | | +--rw svlan? uint64 593 | | | | +--:(dot1q) 594 | | | | +--rw dot1q 595 | | | | +--rw dot1q* uint64 596 | | | +--rw vlan-action? ethernet-action 597 | | | +--rw action? string 598 | | +--:(lr-ip) 599 | | | +--rw ip 600 | | | +--rw ip-address? inet:ip-address 601 | | | +--rw mtu? uint64 602 | | +--:(lr-pw) 603 | | +--rw pw 604 | | +--rw control-word? boolean 605 | | +--rw vlan-action? pwtagmode 606 | +--rw security-attribute 607 | | +--rw security 608 | | +--rw authentication 609 | | +--rw encryption {encryption}? 610 | | +--rw enabled? boolean 611 | | +--rw layer? enumeration 612 | | +--rw algorithm? string 613 | | +--rw (key-type)? 614 | | +--:(psk) 615 | | +--rw preshared-key? string 616 | +--rw qos-attribute 617 | | +--rw svc-input-bandwidth uint64 618 | | +--rw svc-output-bandwidth uint64 619 | | +--rw svc-mtu uint16 620 | | +--rw qos {qos}? 621 | | +--rw qos-classification-policy 622 | | | +--rw rule* [id] 623 | | | +--rw id string 624 | | | +--rw (match-type)? 625 | | | | +--:(match-flow) 626 | | | | | +--rw match-flow 627 | | | | | +--rw dscp? inet:dscp 628 | | | | | +--rw exp? inet:dscp 629 | | | | | +--rw dot1p? uint8 630 | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix 631 | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix 632 | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix 633 | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix 634 | | | | | +--rw l4-src-port? inet:port-number 635 | | | | | +--rw peer-remote-node* string 636 | | | | | +--rw l4-src-port-range 637 | | | | | | +--rw lower-port? inet:port-number 638 | | | | | | +--rw upper-port? inet:port-number 639 | | | | | +--rw l4-dst-port? inet:port-number 640 | | | | | +--rw l4-dst-port-range 641 | | | | | | +--rw lower-port? inet:port-number 642 | | | | | | +--rw upper-port? inet:port-number 643 | | | | | +--rw src-mac? yang:mac-address 644 | | | | | +--rw dst-mac? yang:mac-address 645 | | | | | +--rw protocol-field? union 646 | | | | +--:(match-application) 647 | | | | +--rw match-application? identityref 648 | | | +--rw target-class-id? string 649 | | +--rw qos-profile 650 | | +--rw (qos-profile)? 651 | | +--:(standard) 652 | | | +--rw profile? string 653 | | +--:(custom) 654 | | +--rw classes {qos-custom}? 655 | | +--rw class* [class-id] 656 | | +--rw class-id string 657 | | +--rw direction? identityref 658 | | +--rw rate-limit? decimal64 659 | | +--rw latency 660 | | | +--rw (flavor)? 661 | | | +--:(lowest) 662 | | | | +--rw use-lowest-latency? empty 663 | | | +--:(boundary) 664 | | | +--rw latency-boundary? uint16 665 | | +--rw jitter 666 | | | +--rw (flavor)? 667 | | | +--:(lowest) 668 | | | | +--rw use-lowest-jitter? empty 669 | | | +--:(boundary) 670 | | | +--rw latency-boundary? uint32 671 | | +--rw bandwidth 672 | | +--rw guaranteed-bw-percent decimal64 673 | | +--rw end-to-end? empty 674 | +--rw protection-attribute 675 | +--rw access-priority? uint32 676 +--rw routing-protocol* [type] 677 +--rw type protocol-type 678 +--rw (para)? 679 +--:(static) 680 | +--rw static* [index] 681 | +--rw index uint32 682 | +--rw dest-cidr? string 683 | +--rw egress-tp? yang:uuid 684 | +--rw route-preference? string 685 | +--rw next-hop? inet:ip-address 686 +--:(bgp) 687 +--rw bgp* [index] 688 +--rw index uint32 689 +--rw autonomous-system uint32 690 +--rw address-family* address-family 691 +--rw max-prefix? int32 692 +--rw peer-address? inet:ip-address 693 +--rw crypto-algorithm identityref 694 +--rw key-string 695 +--rw (key-string-style)? 696 +--:(keystring) 697 | +--rw keystring? string 698 +--:(hexadecimal) {hex-key-string}? 699 +--rw hexadecimal-string? yang:hex-string 701 5.1. VPN Hierarchy 703 The composed VPN and segment VPN contain the following common 704 parameters: 706 o vpn-id: Refers to an internal reference for this VPN service 708 o vpn-service-type: Combination of L3VPN service type and L2VPN 709 service type per [RFC8466] and [RFC8299], including VPWS,VPLS,EVPN 710 and L3VPN. 712 o vpn-topology: Combination of L3VPN topology and L2VPN topology, 713 including hub-spoke, any-to-any and point-to-point. 715 o Tunnel-type:MPLS,MPLS-TP,SR,SRv6 717 Suppose a composed VPN is a L3VPN which could initially has sites 718 connected to a single SP domain and may later add more sites to other 719 domains in the SP network. Thus, a composed VPN could has one 720 segment VPN at the beginning, and later has more segment VPNs. 722 5.2. Access Point(AP) 724 As the site containers of the L3SM and L2SM represent the connection 725 characteristics that the CE connects to the provider network from the 726 perspective of the customer, AP represents the connection 727 characteristics that the PE connects to VPN from the perspective of 728 the provider. Therefore, there are two main aspects relates to the 729 AP modelling: 731 o The AP component under composed VPN container describes the intent 732 parameters mapping from the L3SM and L2SM, and the AP component 733 under the segment VPN container describes the configuration 734 parameters of the specific domain derived from the decomposition 735 of composed VPN model. 737 o In a specific segment VPN, the AP component not only describes the 738 CE-PE connection, but also defines inter-domain connection 739 parameters between ASBR peer. The connection between PE and ASBR 740 is related to configuration of network elements and not part of 741 segment VPN model. 743 5.2.1. AP peering with CE 745 The AP parameters contains the following group of parameters: 747 Basic AP parameters: topology role could be hub role, leaf role 749 Connection: has a knob to accommodate either Layer2 or Layer 3 data 750 plane connection 752 Control plane peering: has a knob to accommodate either Layer 2 753 protocol or Layer 3 routing protocol 755 QoS profile and QoS-classification-policy: has a knob to 756 accommodate either Layer 2 QoS profile and qos-classification- 757 policy or Layer 3 QoS profile and Qos-classification-policy, to 758 describe both per AP bandwidth and per flow QoS. 760 Security Policy: has a knob to accommodate either Layer 2 QoS 761 profile and qos-classification-policy or Layer 3 QoS profile and 762 qos-classification-policy, to describe both per AP bandwidth and 763 per flow QoS. 765 Although both the composed VPN and segment VPN use the AP to describe 766 the connection parameters of the CE and the PE, the AP parameter of 767 the composed VPN may not be directly mapped to the AP parameters of 768 the segment VPN. For example, a composed VPN is a L3VPN with one of 769 its AP which specifies the IP connection parameters and per flow QOS 770 requirement. During decomposition, depending on the capability of 771 the accessed domain which the segment VPN resides, the AP of the 772 segment VPN could only support Ethernet connection and per port 773 bandwidth guarantee. Therefore, the AP could only configure with L2 774 connection and per AP bandwidth setting. 776 5.2.2. AP peering for inter-domains connection 778 The AP which describes the inter-domains connection could only exist 779 in segment VPN. There are three options in connecting segment VPN 780 across inter-domain link. With L3VPN, L2VPN or mixture, the option 781 could be: 783 +------------+----------------+------------+----------+ 784 |Interworking| AP type |AP CP |AP DP | 785 | Option | |remote peer | | 786 +------------+----------------+------------+----------+ 787 | Option A | ASBR LTP | ASBR | Interface| 788 +------------+----------------+------------+----------+ 789 | Option B | ASBR | ASBR | LSP label| 790 +------------+----------------+------------+----------+ 791 | Option C | PE,ASBR | remote PE | LSP label| 792 +------------+----------------+------------+----------+ 794 The AP parameters contains the following group of parameters: 796 Basic AP parameters: Inter-AS interworking option could be Option 797 A, Option B or Option C. 799 Connection: only specifies in Options A, Option B and C use 800 dynamically allocated MPLS labels. 802 Control plane peering: BGP peering or static routing. 804 QoS profile and QoS-classification-policy: only applicable in 805 Options A, Option B and C can only use MPLS EXP to differentiate 806 the traffic. 808 Security policy: Options A use the similar mechanism like CE-PE 809 peering, Option B could use BGP authentication to secure control 810 plane communication and enable mpls label security, and Option C 811 depends on the trust between the inter-domains. 813 5.2.2.1. Secure inter-domain connection 815 This model is applied to a single SP. Although there are different 816 domain separation, implicit trust exists between the ASs because they 817 have the same operational control, for example from orchestrator's 818 perspective. 820 The model specifies different security parameters depending on the 821 various Inter-AS options: 823 o Option A uses interfaces or subinterfaces between autonomous 824 system border routers (ASBRs) to keep the VPNs separate, so there 825 is strict separation between VPNs. 827 o Option B can be secured with configuration on the control plane 828 and the data plane. On the control plane, the session can be 829 secured by use of peer authentication of BGP with message digest 5 830 (MD5) and TCP Authentication Option(TCP-AO), maximum route limits 831 per peer and per VPN, dampening, and so on. In addition, prefix 832 filters can be deployed to control which routes can be received 833 from the other AS. On the data plane, labeled packets are 834 exchanged. The label is derived from the MP-eBGP session; 835 therefore, the ASBR announcing a VPN-IPv4 prefix controls and 836 assigns the label for each prefix it announces. On the data 837 plane, the incoming label is then checked to verify that this 838 label on the data plane has really been assigned on the control 839 plane. Therefore, it is impossible to introduce fake labels from 840 one AS to another. The Authentication parameter could be set 841 under the BGP peering configuration. An MPLS label security could 842 be enabled under the connection node. 844 o Option C can also be secured well on the control plane, but the 845 data plane does not provide any mechanism to check and block the 846 packets to be sent into the other AS. On the control plane, model 847 C has two interfaces between autonomous systems: The ASBRs 848 exchange IPv4 routes with labels via eBGP. The purpose is to 849 propagate the PE loopback addresses to the other AS so that LSPs 850 can be established end to end. The other interface is the RRs 851 exchange VPN-IPv4 routes with labels via multihop MP-eBGP. The 852 prefixes exchanged can be controlled through route maps, equally 853 the route targets. On the data plane, the traffic exchanged 854 between the ASBRs contains two labels. One is VPN label set by 855 the ingress PE to identify the VPN. The other is PE label 856 Specifies the LSP to the egress PE. The Authentication and 857 routing policy parameter could be set under the BGP peering 858 configuration. 860 The security options supported in the model are limited but may be 861 extended via augmentation. 863 5.2.2.2. Inter-domain QoS decomposition 865 The APs connected between the domains are aggregation points, and 866 traffic from different CEs of the combined VPN cross-domain will 867 interact through these aggregation points. To provide consistent QoS 868 configuration, when several domains are involved in the provisioning 869 of a VPN, topology, domain functionality and other factors need to be 870 considered. 872 Option A can achieve most granular QoS implementation since IP 873 traffic passes the inter-domain connection. Thus, Option A can set 874 configuration with per sub-interface and IP DSCP. Option B and 875 Option C only provide MPLS EXP differentiation. QoS mechanisms that 876 are applied only to IP traffic cannot be carried. 878 In some cases, there is need to re-mark packets at Layer 3 to 879 indicate whether traffic is in agreement. Because MPLS labels 880 include 3 bits that commonly are used for QoS marking, it is possible 881 for "tunnel DiffServ" to preserve Layer 3 DiffServ markings through a 882 service provider's MPLS VPN cloud while still performing re-marking 883 (via MPLS EXP bits) within the cloud to indicate in- or out-of- 884 agreement traffic. 886 6. Composed VPN YANG Module 888 file "ietf-composed-vpn-svc.yang" 889 module ietf-composed-vpn-svc { 890 namespace "urn:ietf:params:xml:ns:yang:ietf-composed-vpn-svc" ; 891 prefix composed-vpn ; 892 import ietf-yang-types { 893 prefix yang; 894 } 895 import ietf-segment-vpn { 896 prefix segment-vpn; 897 } 898 organization "IETF OPSAWG Working Group"; 899 contact " 900 WG Web: 901 WG List: 903 Editor: Roni Even 904 905 Bo Wu 906 907 Qin Wu 908 909 Ying Cheng 910 "; 912 description "ietf-compsed-vpn"; 913 revision 2018-08-21 { 914 reference "draft-evenwu-opsawg-yang-composed-vpn-00"; 915 } 917 grouping vpn-basic { 918 description "VPNBasicInfo Grouping."; 919 leaf topo { 920 type segment-vpn:vpn-topology; 921 description "current support for full-mesh and 922 point_to_multipoint(hub-spoke), others is reserved for 923 future extensions." ; 924 } 925 leaf service-type { 926 type segment-vpn:service-type; 927 description "current support for mpls l3vpn/vxlan/L2VPN/hybrid 928 VPN overlay, others is reserved for future extensions." ; 929 } 930 leaf tunnel-type { 931 type segment-vpn:tunnel-type; 932 description "mpls|vxlan overlay l3vpn|eth over sdh|nop"; 933 } 934 leaf admin-state { 935 type segment-vpn:admin-state; 936 description "administrative status." ; 937 } 938 leaf oper-State { 939 type segment-vpn:oper-state; 940 config false; 941 description "Operational status." ; 942 } 943 leaf sync-state { 944 type segment-vpn:sync-state; 945 config false; 946 description "Sync status." ; 947 } 948 leaf start-time { 949 type yang:date-and-time; 950 description "Service lifecycle: request for service start 951 time." ; 952 } 953 } 955 container composed-vpns{ 956 description ""; 957 list composed-vpn { 958 key "vpn-id"; 959 description "List for composed VPNs."; 960 uses composedvpn; 961 } 962 } 964 grouping composedvpn { 965 description "ComposedVPN Grouping."; 966 leaf vpn-id { 967 type yang:uuid; 968 description "Composed VPN identifier." ; 969 } 970 leaf vpn-name { 971 type string {length "0..200";} 972 description "Composed VPN Name. Local administration meaning" ; 973 } 974 leaf customer-name { 975 type yang:uuid; 976 description 977 "Name of the customer that actually uses the VPN service. 978 In the case that any intermediary (e.g., Tier-2 provider 979 or partner) sells the VPN service to their end user 980 on behalf of the original service provider (e.g., Tier-1 981 provider), the original service provider may require the 982 customer name to provide smooth activation/commissioning 983 and operation for the service." ; 984 } 985 uses vpn-basic; 986 list segment-vpn { 987 key "vpn-id"; 988 description "SegVpn list "; 989 uses segment-vpn:VPN; 990 } 991 list access-point { 992 key "tp-id"; 993 description "TP list of the access links which associated 994 with CE and PE"; 995 uses segment-vpn:pe-termination-point; 996 } 997 } 998 } 999 1001 7. Segment VPN YANG Module 1003 file "ietf-segment-vpn.yang" 1004 module ietf-segment-vpn { 1005 namespace "urn:ietf:params:xml:ns:yang:ietf-segment-vpn"; 1006 prefix segment-vpn; 1007 import ietf-yang-types { 1008 prefix yang; 1009 } 1010 import ietf-inet-types { 1011 prefix inet; 1012 } 1013 import ietf-key-chain { 1014 prefix keychain; 1015 } 1016 import ietf-netconf-acm { 1017 prefix nacm; 1018 } 1020 organization 1021 "IETF OPSAWG Working Group"; 1022 contact 1023 "WG Web: 1024 WG List: 1026 Editor: 1027 Roni Even 1028 1029 Bo Wu 1030 1031 Qin Wu 1032 1033 Cheng Ying 1034 "; 1035 description 1036 "This YANG module defines a generic service configuration 1037 model for segment VPNs."; 1039 revision 2019-01-30 { 1040 reference 1041 "draft-opsawg-evenwu-yang-composed-vpn-02"; 1042 } 1044 feature encryption { 1045 description 1046 "Enables support of encryption."; 1047 } 1049 feature qos { 1050 description 1051 "Enables support of classes of services."; 1052 } 1054 feature qos-custom { 1055 description 1056 "Enables support of the custom QoS profile."; 1057 } 1059 feature hex-key-string { 1060 description 1061 "Support hexadecimal key string."; 1062 } 1064 identity protocol-type { 1065 description 1066 "Base identity for protocol field type."; 1067 } 1069 identity tcp { 1070 base protocol-type; 1071 description 1072 "TCP protocol type."; 1073 } 1075 identity udp { 1076 base protocol-type; 1077 description 1078 "UDP protocol type."; 1079 } 1081 identity icmp { 1082 base protocol-type; 1083 description 1084 "ICMP protocol type."; 1085 } 1087 identity icmp6 { 1088 base protocol-type; 1089 description 1090 "ICMPv6 protocol type."; 1091 } 1093 identity gre { 1094 base protocol-type; 1095 description 1096 "GRE protocol type."; 1097 } 1099 identity ipip { 1100 base protocol-type; 1101 description 1102 "IP-in-IP protocol type."; 1104 } 1106 identity hop-by-hop { 1107 base protocol-type; 1108 description 1109 "Hop-by-Hop IPv6 header type."; 1110 } 1112 identity routing { 1113 base protocol-type; 1114 description 1115 "Routing IPv6 header type."; 1116 } 1118 identity esp { 1119 base protocol-type; 1120 description 1121 "ESP header type."; 1122 } 1124 identity ah { 1125 base protocol-type; 1126 description 1127 "AH header type."; 1128 } 1130 identity customer-application { 1131 description 1132 "Base identity for customer application."; 1133 } 1135 identity web { 1136 base customer-application; 1137 description 1138 "Identity for Web application (e.g., HTTP, HTTPS)."; 1139 } 1141 identity mail { 1142 base customer-application; 1143 description 1144 "Identity for mail application."; 1145 } 1147 identity file-transfer { 1148 base customer-application; 1149 description 1150 "Identity for file transfer application (e.g., FTP, SFTP)."; 1151 } 1152 identity database { 1153 base customer-application; 1154 description 1155 "Identity for database application."; 1156 } 1158 identity social { 1159 base customer-application; 1160 description 1161 "Identity for social-network application."; 1162 } 1164 identity games { 1165 base customer-application; 1166 description 1167 "Identity for gaming application."; 1168 } 1170 identity p2p { 1171 base customer-application; 1172 description 1173 "Identity for peer-to-peer application."; 1174 } 1176 identity network-management { 1177 base customer-application; 1178 description 1179 "Identity for management application 1180 (e.g., Telnet, syslog, SNMP)."; 1181 } 1183 identity voice { 1184 base customer-application; 1185 description 1186 "Identity for voice application."; 1187 } 1189 identity video { 1190 base customer-application; 1191 description 1192 "Identity for video conference application."; 1193 } 1195 identity qos-profile-direction { 1196 description 1197 "Base identity for QoS profile direction."; 1198 } 1199 identity outbound { 1200 base qos-profile-direction; 1201 description 1202 "Identity for outbound direction."; 1203 } 1205 identity inbound { 1206 base qos-profile-direction; 1207 description 1208 "Identity for inbound direction."; 1209 } 1211 identity both { 1212 base qos-profile-direction; 1213 description 1214 "Identity for both inbound direction 1215 and outbound direction."; 1216 } 1218 typedef access-point-type { 1219 type enumeration { 1220 enum ce-peering { 1221 description 1222 "indicates access type with connection to CE"; 1223 } 1224 enum remote-as-peering { 1225 description 1226 "indicates access type with connection to ASBR with opion A,B,C "; 1227 } 1228 } 1229 description 1230 "The access-point-type could be peering with CE or ASBR 1231 depending on which network that a PE interconnects with."; 1232 } 1234 typedef bgp-password-type { 1235 type string; 1236 description 1237 "Authentication Type (None, Simple Password, Keyed MD5, 1238 Meticulous Keyed MD5, Keyed SHA1, Meticulous Keyed SHA1"; 1239 } 1241 typedef topology-role { 1242 type enumeration { 1243 enum hub { 1244 description 1245 "hub"; 1246 } 1247 enum spoke { 1248 description 1249 "spoke"; 1250 } 1251 enum other { 1252 description 1253 "other"; 1254 } 1255 } 1256 description 1257 "Topo Node Role."; 1258 } 1260 typedef qos-config-type { 1261 type enumeration { 1262 enum template { 1263 description 1264 "standard."; 1265 } 1266 enum customer { 1267 description 1268 "custom."; 1269 } 1270 } 1271 description 1272 "Qos Config Type."; 1273 } 1275 typedef address-family { 1276 type enumeration { 1277 enum ipv4 { 1278 description 1279 "IPv4 address family."; 1280 } 1281 enum ipv6 { 1282 description 1283 "IPv6 address family."; 1284 } 1285 } 1286 description 1287 "Defines a type for the address family."; 1288 } 1290 typedef tp-type { 1291 type enumeration { 1292 enum phys-tp { 1293 description 1294 "Physical termination point"; 1296 } 1297 enum ctp { 1298 description 1299 "CTP"; 1300 } 1301 enum trunk { 1302 description 1303 "TRUNK"; 1304 } 1305 enum loopback { 1306 description 1307 "LoopBack"; 1308 } 1309 enum tppool { 1310 description 1311 "TPPool"; 1312 } 1313 } 1314 description 1315 "Tp Type."; 1316 } 1318 typedef layer-rate { 1319 type enumeration { 1320 enum lr-unknow { 1321 description 1322 "Layer Rate UNKNOW."; 1323 } 1324 enum lr-ip { 1325 description 1326 "Layer Rate IP."; 1327 } 1328 enum lr-eth { 1329 description 1330 "Layer Rate Ethernet."; 1331 } 1332 enum lr_vxlan { 1333 description 1334 "Layer Rate VXLAN."; 1335 } 1336 } 1337 description 1338 "Layer Rate."; 1339 } 1341 typedef admin-state { 1342 type enumeration { 1343 enum active { 1344 description 1345 "Active status"; 1346 } 1347 enum inactive { 1348 description 1349 "Inactive status"; 1350 } 1351 enum partial { 1352 description 1353 "Partial status"; 1354 } 1355 } 1356 description 1357 "Admin State."; 1358 } 1360 typedef oper-state { 1361 type enumeration { 1362 enum up { 1363 description 1364 "Up status"; 1365 } 1366 enum down { 1367 description 1368 "Down status"; 1369 } 1370 enum degrade { 1371 description 1372 "Degrade status"; 1373 } 1374 } 1375 description 1376 "Operational Status."; 1377 } 1379 typedef sync-state { 1380 type enumeration { 1381 enum sync { 1382 description 1383 "Sync status"; 1384 } 1385 enum out-sync { 1386 description 1387 "Out sync status"; 1388 } 1389 } 1390 description 1391 "Sync Status"; 1393 } 1395 typedef eth-encap-type { 1396 type enumeration { 1397 enum default { 1398 description 1399 "DEFAULT"; 1400 } 1401 enum dot1q { 1402 description 1403 "DOT1Q"; 1404 } 1405 enum qinq { 1406 description 1407 "QINQ"; 1408 } 1409 enum untag { 1410 description 1411 "UNTAG"; 1412 } 1413 } 1414 description 1415 "Ethernet Encap Type."; 1416 } 1418 typedef protocol-type { 1419 type enumeration { 1420 enum static { 1421 description 1422 "Static Routing"; 1423 } 1424 enum bgp { 1425 description 1426 "bgp"; 1427 } 1428 enum rip { 1429 description 1430 "rip"; 1431 } 1432 enum ospf { 1433 description 1434 "ospf"; 1435 } 1436 enum isis { 1437 description 1438 "isis"; 1439 } 1440 } 1441 description 1442 "Routing Protocol Type"; 1443 } 1445 typedef tunnel-type { 1446 type enumeration { 1447 enum MPLS { 1448 description 1449 "MPLS"; 1450 } 1451 enum MPLS-TP { 1452 description 1453 "MPLS-TP"; 1454 } 1455 enum MPLS-SR { 1456 description 1457 "MPLS Segment Routing"; 1458 } 1459 enum SRv6 { 1460 description 1461 "SRv6"; 1462 } 1463 } 1464 description 1465 "VPN Tunnel Type."; 1466 } 1468 typedef service-type { 1469 type enumeration { 1470 enum l3vpn { 1471 description 1472 "l3vpn"; 1473 } 1474 enum l2vpn { 1475 description 1476 "l2vpn"; 1477 } 1478 } 1479 description 1480 "VPN Service Type."; 1481 } 1483 typedef vpn-topology { 1484 type enumeration { 1485 enum point-to-point { 1486 description 1487 "point to point"; 1488 } 1489 enum any-to-any { 1490 description 1491 "any to any"; 1492 } 1493 enum hub-spoke { 1494 description 1495 "hub and spoke VPN topology."; 1496 } 1497 enum hub-spoke-disjoint { 1498 description 1499 "Hub and spoke VPN topology where 1500 Hubs cannot communicate with each other "; 1501 } 1502 } 1503 description 1504 "Topology."; 1505 } 1507 typedef ethernet-action { 1508 type enumeration { 1509 enum nop { 1510 description 1511 "nop"; 1512 } 1513 enum untag { 1514 description 1515 "UNTAG"; 1516 } 1517 enum stacking { 1518 description 1519 "STACKING"; 1520 } 1521 } 1522 description 1523 "Ethernet Action."; 1524 } 1526 typedef color-type { 1527 type enumeration { 1528 enum green { 1529 description 1530 "green"; 1531 } 1532 enum yellow { 1533 description 1534 "yellow"; 1535 } 1536 enum red { 1537 description 1538 "red"; 1539 } 1540 enum all { 1541 description 1542 "all"; 1543 } 1544 } 1545 description 1546 "Color Type."; 1547 } 1549 typedef action-type { 1550 type enumeration { 1551 enum nop { 1552 description 1553 "nop"; 1554 } 1555 enum bandwidth { 1556 description 1557 "bandwidth"; 1558 } 1559 enum pass { 1560 description 1561 "pass"; 1562 } 1563 enum discard { 1564 description 1565 "discard"; 1566 } 1567 enum remark { 1568 description 1569 "remark"; 1570 } 1571 enum redirect { 1572 description 1573 "redirect"; 1574 } 1575 enum recolor { 1576 description 1577 "recolor"; 1578 } 1579 enum addRt { 1580 description 1581 "addRt"; 1582 } 1583 } 1584 description 1585 "Action Type"; 1586 } 1588 typedef pwtagmode { 1589 type enumeration { 1590 enum raw { 1591 description 1592 "RAW"; 1593 } 1594 enum tagged { 1595 description 1596 "TAGGED"; 1597 } 1598 } 1599 description 1600 "PWTagMode"; 1601 } 1603 grouping QinQVlan { 1604 description 1605 "QinQVlan Grouping."; 1606 leaf-list cvlan { 1607 type uint64; 1608 description 1609 "cvlan List."; 1610 } 1611 leaf svlan { 1612 type uint64; 1613 description 1614 "svlan."; 1615 } 1616 } 1618 grouping Dot1QVlan { 1619 description 1620 "Dot1QVlan Grouping."; 1621 leaf-list dot1q { 1622 type uint64; 1623 description 1624 "dot1q Vlan List"; 1625 } 1626 } 1628 grouping tp-connection-type { 1629 description 1630 "Tp Type Spec Grouping."; 1631 choice connection-type { 1632 description 1633 "Spec Value"; 1634 case lr-eth { 1635 container eth { 1636 description 1637 "ethernetSpec"; 1638 uses ethernet-spec; 1639 } 1640 } 1641 case lr-ip { 1642 container ip { 1643 description 1644 "ipSpec"; 1645 uses ipspec; 1646 } 1647 } 1648 case lr-pw { 1649 container pw { 1650 description 1651 "PwSpec"; 1652 uses pwspec; 1653 } 1654 } 1655 } 1656 } 1658 grouping security-authentication { 1659 container authentication { 1660 description 1661 "Authentication parameters."; 1662 } 1663 description 1664 "This grouping defines authentication parameters for a site."; 1665 } 1667 grouping security-encryption { 1668 container encryption { 1669 if-feature "encryption"; 1670 leaf enabled { 1671 type boolean; 1672 default "false"; 1673 description 1674 "If true, traffic encryption on the connection is required."; 1675 } 1676 leaf layer { 1677 when "../enabled = 'true'" { 1678 description 1679 " Require a value for layer when enabled is true."; 1680 } 1681 type enumeration { 1682 enum layer2 { 1683 description 1684 "Encryption will occur at Layer 2."; 1685 } 1686 enum layer3 { 1687 description 1688 "Encryption will occur at Layer 3. 1689 For example, IPsec may be used when 1690 a customer requests Layer 3 encryption."; 1691 } 1692 } 1693 description 1694 "Layer on which encryption is applied."; 1695 } 1696 leaf algorithm { 1697 type string; 1698 description 1699 "Encryption algorithm to be used."; 1700 } 1701 choice key-type { 1702 default "psk"; 1703 case psk { 1704 leaf preshared-key { 1705 type string; 1706 description 1707 " Pre-Shared Key(PSK) coming from customer."; 1708 } 1709 } 1710 description 1711 "Type of keys to be used."; 1712 } 1713 description 1714 "Encryption parameters."; 1715 } 1716 description 1717 "This grouping defines encryption parameters for a site."; 1718 } 1720 grouping security-attribute { 1721 container security { 1722 uses security-authentication; 1723 uses security-encryption; 1724 description 1725 "Site-specific security parameters."; 1726 } 1727 description 1728 "Grouping for security parameters."; 1730 } 1732 grouping flow-definition { 1733 container match-flow { 1734 leaf dscp { 1735 type inet:dscp; 1736 description 1737 "DSCP value."; 1738 } 1739 leaf exp { 1740 type inet:dscp; 1741 description 1742 "EXP value."; 1743 } 1744 leaf dot1p { 1745 type uint8 { 1746 range "0..7"; 1747 } 1748 description 1749 "802.1p matching."; 1750 } 1751 leaf ipv4-src-prefix { 1752 type inet:ipv4-prefix; 1753 description 1754 "Match on IPv4 src address."; 1755 } 1756 leaf ipv6-src-prefix { 1757 type inet:ipv6-prefix; 1758 description 1759 "Match on IPv6 src address."; 1760 } 1761 leaf ipv4-dst-prefix { 1762 type inet:ipv4-prefix; 1763 description 1764 "Match on IPv4 dst address."; 1765 } 1766 leaf ipv6-dst-prefix { 1767 type inet:ipv6-prefix; 1768 description 1769 "Match on IPv6 dst address."; 1770 } 1771 leaf l4-src-port { 1772 type inet:port-number; 1773 must 'current() < ../l4-src-port-range/lower-port or current() > ../l4-src-port-range/upper-port' { 1774 description 1775 "If l4-src-port and l4-src-port-range/lower-port and 1776 upper-port are set at the same time, l4-src-port 1777 should not overlap with l4-src-port-range."; 1779 } 1780 description 1781 "Match on Layer 4 src port."; 1782 } 1783 leaf-list peer-remote-node { 1784 type string; 1785 description 1786 "Identify a peer remote node as traffic destination."; 1787 } 1788 container l4-src-port-range { 1789 leaf lower-port { 1790 type inet:port-number; 1791 description 1792 "Lower boundary for port."; 1793 } 1794 leaf upper-port { 1795 type inet:port-number; 1796 must '. >= ../lower-port' { 1797 description 1798 "Upper boundary for port. If it 1799 exists, the upper boundary must be 1800 higher than the lower boundary."; 1801 } 1802 description 1803 "Upper boundary for port."; 1804 } 1805 description 1806 "Match on Layer 4 src port range. When 1807 only the lower-port is present, it represents 1808 a single port. When both the lower-port and 1809 upper-port are specified, it implies 1810 a range inclusive of both values."; 1811 } 1812 leaf l4-dst-port { 1813 type inet:port-number; 1814 must 'current() < ../l4-dst-port-range/lower-port or current() > ../l4-dst-port-range/upper-port' { 1815 description 1816 "If l4-dst-port and l4-dst-port-range/lower-port 1817 and upper-port are set at the same time, 1818 l4-dst-port should not overlap with 1819 l4-src-port-range."; 1820 } 1821 description 1822 "Match on Layer 4 dst port."; 1823 } 1824 container l4-dst-port-range { 1825 leaf lower-port { 1826 type inet:port-number; 1827 description 1828 "Lower boundary for port."; 1829 } 1830 leaf upper-port { 1831 type inet:port-number; 1832 must '. >= ../lower-port' { 1833 description 1834 "Upper boundary must be 1835 higher than lower boundary."; 1836 } 1837 description 1838 "Upper boundary for port. If it exists, 1839 upper boundary must be higher than lower 1840 boundary."; 1841 } 1842 description 1843 "Match on Layer 4 dst port range. When only 1844 lower-port is present, it represents a single 1845 port. When both lower-port and upper-port are 1846 specified, it implies a range inclusive of both 1847 values."; 1848 } 1849 leaf src-mac { 1850 type yang:mac-address; 1851 description 1852 "Source MAC."; 1853 } 1854 leaf dst-mac { 1855 type yang:mac-address; 1856 description 1857 "Destination MAC."; 1858 } 1859 leaf protocol-field { 1860 type union { 1861 type uint8; 1862 type identityref { 1863 base protocol-type; 1864 } 1865 } 1866 description 1867 "Match on IPv4 protocol or IPv6 Next Header field."; 1868 } 1869 description 1870 "Describes flow-matching criteria."; 1871 } 1872 description 1873 "Flow definition based on criteria."; 1874 } 1875 grouping service-qos-profile { 1876 container qos { 1877 if-feature "qos"; 1878 container qos-classification-policy { 1879 list rule { 1880 key "id"; 1881 ordered-by user; 1882 leaf id { 1883 type string; 1884 description 1885 "A description identifying the 1886 qos-classification-policy rule."; 1887 } 1888 choice match-type { 1889 default "match-flow"; 1890 case match-flow { 1891 uses flow-definition; 1892 } 1893 case match-application { 1894 leaf match-application { 1895 type identityref { 1896 base customer-application; 1897 } 1898 description 1899 "Defines the application to match."; 1900 } 1901 } 1902 description 1903 "Choice for classification."; 1904 } 1905 leaf target-class-id { 1906 type string; 1907 description 1908 "Identification of the class of service. 1909 This identifier is internal to the administration."; 1910 } 1911 description 1912 "List of marking rules."; 1913 } 1914 description 1915 "Configuration of the traffic classification policy."; 1916 } 1917 container qos-profile { 1918 choice qos-profile { 1919 description 1920 "Choice for QoS profile. 1921 Can be standard profile or customized profile."; 1922 case standard { 1923 description 1924 "Standard QoS profile."; 1925 leaf profile { 1926 type string; 1927 description 1928 "QoS profile to be used."; 1929 } 1930 } 1931 case custom { 1932 description 1933 "Customized QoS profile."; 1934 container classes { 1935 if-feature "qos-custom"; 1936 list class { 1937 key "class-id"; 1938 leaf class-id { 1939 type string; 1940 description 1941 "Identification of the class of service. 1942 This identifier is internal to the 1943 administration."; 1944 } 1945 leaf direction { 1946 type identityref { 1947 base qos-profile-direction; 1948 } 1949 default "both"; 1950 description 1951 "The direction to which the QoS profile 1952 is applied."; 1953 } 1954 leaf rate-limit { 1955 type decimal64 { 1956 fraction-digits 5; 1957 range "0..100"; 1958 } 1959 units "percent"; 1960 description 1961 "To be used if the class must be rate-limited. 1962 Expressed as percentage of the service 1963 bandwidth."; 1964 } 1965 container latency { 1966 choice flavor { 1967 case lowest { 1968 leaf use-lowest-latency { 1969 type empty; 1970 description 1971 "The traffic class should use the path with the 1972 lowest latency."; 1973 } 1974 } 1975 case boundary { 1976 leaf latency-boundary { 1977 type uint16; 1978 units "msec"; 1979 default "400"; 1980 description 1981 "The traffic class should use a path with a 1982 defined maximum latency."; 1983 } 1984 } 1985 description 1986 "Latency constraint on the traffic class."; 1987 } 1988 description 1989 "Latency constraint on the traffic class."; 1990 } 1991 container jitter { 1992 choice flavor { 1993 case lowest { 1994 leaf use-lowest-jitter { 1995 type empty; 1996 description 1997 "The traffic class should use the path with the 1998 lowest jitter."; 1999 } 2000 } 2001 case boundary { 2002 leaf latency-boundary { 2003 type uint32; 2004 units "usec"; 2005 default "40000"; 2006 description 2007 "The traffic class should use a path with a 2008 defined maximum jitter."; 2009 } 2010 } 2011 description 2012 "Jitter constraint on the traffic class."; 2013 } 2014 description 2015 "Jitter constraint on the traffic class."; 2016 } 2017 container bandwidth { 2018 leaf guaranteed-bw-percent { 2019 type decimal64 { 2020 fraction-digits 5; 2021 range "0..100"; 2022 } 2023 units "percent"; 2024 mandatory true; 2025 description 2026 "To be used to define the guaranteed bandwidth 2027 as a percentage of the available service bandwidth."; 2028 } 2029 leaf end-to-end { 2030 type empty; 2031 description 2032 "Used if the bandwidth reservation 2033 must be done on the MPLS network too."; 2034 } 2035 description 2036 "Bandwidth constraint on the traffic class."; 2037 } 2038 description 2039 "List of classes of services."; 2040 } 2041 description 2042 "Container for list of classes of services."; 2043 } 2044 } 2045 } 2046 description 2047 "QoS profile configuration."; 2048 } 2049 description 2050 "QoS configuration."; 2051 } 2052 description 2053 "This grouping defines QoS parameters for a segment network."; 2054 } 2056 grouping remote-peer-tp { 2057 description 2058 "remote-peer-tp Grouping."; 2059 leaf remote-id { 2060 type yang:uuid; 2061 description 2062 "Router ID of the remote peer"; 2063 } 2064 leaf location { 2065 type string { 2066 length "0..400"; 2068 } 2069 description 2070 "CE device location "; 2071 } 2072 leaf remote-tp-address { 2073 type inet:ip-address; 2074 description 2075 "TP IP address"; 2076 } 2077 leaf remote-node-id { 2078 type yang:uuid; 2079 description 2080 "directly connected NE node ID, only valid in 2081 asbr "; 2082 } 2083 leaf remote-tp-id { 2084 type yang:uuid; 2085 description 2086 "Directly connected TP id, only valid in asbr"; 2087 } 2088 } 2090 grouping tp-connection-specific-attribute { 2091 description 2092 "tp connectin specific attributes"; 2093 list connection { 2094 key "connection-class"; 2095 leaf connection-class { 2096 type layer-rate; 2097 description 2098 "connection class and has one to one 2099 relation with the corresponding layer."; 2100 } 2101 uses tp-connection-type; 2102 description 2103 "typeSpecList"; 2104 } 2105 container security-attribute { 2106 description 2107 "tp security Parameters."; 2108 uses security-attribute; 2109 } 2110 container qos-attribute { 2111 description 2112 "tp Qos Parameters."; 2113 uses segment-service-basic; 2114 uses service-qos-profile; 2115 } 2116 container protection-attribute { 2117 description 2118 "tp protection parameters."; 2119 leaf access-priority { 2120 type uint32; 2121 default "100"; 2122 description 2123 "Defines the priority for the access. 2124 The higher the access-priority value, 2125 the higher the preference of the 2126 access will be."; 2127 } 2128 } 2129 } 2131 grouping tp-common-attribute { 2132 description 2133 "tp-common-attribute Grouping."; 2134 leaf tp-id { 2135 type yang:uuid; 2136 description 2137 "An identifier for termination point on a node."; 2138 } 2139 leaf tp-name { 2140 type string { 2141 length "0..200"; 2142 } 2143 description 2144 "The termination point Name on a node. It conforms to 2145 name rule defined in system. Example FE0/0/1, GE1/2/1.1, 2146 Eth-Trunk1.1, etc"; 2147 } 2148 leaf node-id { 2149 type yang:uuid; 2150 description 2151 "Identifier for a node."; 2152 } 2153 leaf access-point-type { 2154 type access-point-type; 2155 description 2156 "access-point-type, for example:peering with CE "; 2157 } 2158 leaf inter-as-option { 2159 type enumeration { 2160 enum optiona { 2161 description 2162 "Inter-AS Option A"; 2163 } 2164 enum optionb { 2165 description 2166 "Inter-AS Option B"; 2167 } 2168 enum optionc { 2169 description 2170 "Inter-AS Option C"; 2171 } 2172 } 2173 description 2174 "Foo"; 2175 } 2176 leaf topology-role { 2177 type topology-role; 2178 description 2179 "hub/spoke role, etc"; 2180 } 2181 } 2183 grouping routing-protcol { 2184 description 2185 "Routing Protocol Grouping."; 2186 leaf type { 2187 type protocol-type; 2188 description 2189 "Protocol type"; 2190 } 2191 choice para { 2192 description 2193 "para"; 2194 case static { 2195 list static { 2196 key "index"; 2197 uses static-config; 2198 description 2199 "staticRouteItems"; 2200 } 2201 } 2202 case bgp { 2203 list bgp { 2204 key "index"; 2205 uses bgp-config; 2206 description 2207 "bgpProtocols"; 2208 } 2209 } 2210 } 2211 } 2212 grouping bgp-config { 2213 description 2214 "BGP Protocol Grouping."; 2215 leaf index { 2216 type uint32; 2217 description 2218 "index of BGP protocol item"; 2219 } 2220 leaf autonomous-system { 2221 type uint32; 2222 mandatory true; 2223 description 2224 "Peer AS number in case the peer 2225 requests BGP routing."; 2226 } 2227 leaf-list address-family { 2228 type address-family; 2229 min-elements 1; 2230 description 2231 "If BGP is used on this site, this node 2232 contains configured value. This node 2233 contains at least one address family 2234 to be activated."; 2235 } 2236 leaf max-prefix { 2237 type int32; 2238 description 2239 "maximum number limit of prefixes."; 2240 } 2241 leaf peer-address { 2242 type inet:ip-address; 2243 description 2244 "peerIp"; 2245 } 2246 leaf crypto-algorithm { 2247 type identityref { 2248 base keychain:crypto-algorithm; 2249 } 2250 mandatory true; 2251 description 2252 "Cryptographic algorithm associated with key."; 2253 } 2254 container key-string { 2255 description 2256 "The key string."; 2257 nacm:default-deny-all; 2258 choice key-string-style { 2259 description 2260 "Key string styles"; 2261 case keystring { 2262 leaf keystring { 2263 type string; 2264 description 2265 "Key string in ASCII format."; 2266 } 2267 } 2268 case hexadecimal { 2269 if-feature "hex-key-string"; 2270 leaf hexadecimal-string { 2271 type yang:hex-string; 2272 description 2273 "Key in hexadecimal string format. When compared 2274 to ASCII, specification in hexadecimal affords 2275 greater key entropy with the same number of 2276 internal key-string octets. Additionally, it 2277 discourages usage of well-known words or 2278 numbers."; 2279 } 2280 } 2281 } 2282 } 2283 } 2285 grouping static-config { 2286 description 2287 "StaticRouteItem Grouping."; 2288 leaf index { 2289 type uint32; 2290 description 2291 "static item index"; 2292 } 2293 leaf dest-cidr { 2294 type string; 2295 description 2296 "address prefix specifying the set of 2297 destination addresses for which the route may be 2298 used. "; 2299 } 2300 leaf egress-tp { 2301 type yang:uuid; 2302 description 2303 "egress tp"; 2304 } 2305 leaf route-preference { 2306 type string; 2307 description 2308 "route priority. Ordinary, work route have 2309 higher priority."; 2310 } 2311 leaf next-hop { 2312 type inet:ip-address; 2313 description 2314 "Determines the outgoing interface and/or 2315 next-hop address(es), or a special operation to be 2316 performed on a packet.."; 2317 } 2318 } 2320 grouping ethernet-spec { 2321 description 2322 "Ethernet Spec Grouping."; 2323 leaf access-type { 2324 type eth-encap-type; 2325 description 2326 "access frame type"; 2327 } 2328 choice accessVlanValue { 2329 description 2330 "accessVlanValue"; 2331 case qinq { 2332 container qinq { 2333 description 2334 "qinqVlan"; 2335 uses QinQVlan; 2336 } 2337 } 2338 case dot1q { 2339 container dot1q { 2340 description 2341 "dot1q"; 2342 uses Dot1QVlan; 2343 } 2344 } 2345 } 2346 leaf vlan-action { 2347 type ethernet-action; 2348 description 2349 "specify the action when the vlan is matched"; 2350 } 2351 leaf action { 2352 type string { 2353 length "0..100"; 2354 } 2355 description 2356 "specify the action value."; 2357 } 2358 } 2360 grouping pwspec { 2361 description 2362 "PwSpec Grouping."; 2363 leaf control-word { 2364 type boolean; 2365 default "false"; 2366 description 2367 "control Word."; 2368 } 2369 leaf vlan-action { 2370 type pwtagmode; 2371 description 2372 "pw Vlan Action."; 2373 } 2374 } 2376 grouping ipspec { 2377 description 2378 "IpSpec Grouping."; 2379 leaf ip-address { 2380 type inet:ip-address; 2381 description 2382 "master IP address"; 2383 } 2384 leaf mtu { 2385 type uint64; 2386 description 2387 "mtu for ip layer,scope:46~9600"; 2388 } 2389 } 2391 grouping VPN { 2392 description 2393 "VPN Grouping."; 2394 leaf vpn-id { 2395 type yang:uuid; 2396 description 2397 "VPN Identifier."; 2398 } 2399 leaf vpn-name { 2400 type string { 2401 length "0..200"; 2402 } 2403 description 2404 "Human-readable name for the VPN service."; 2405 } 2406 leaf service-type { 2407 type service-type; 2408 description 2409 "The service type combines service types from 2410 RFC8299 (L3SM) and RFC8466 (L2SM),for example L3VPN,VPWS etc. 2411 It could be augmentated for future extensions."; 2412 } 2413 leaf topo { 2414 type vpn-topology; 2415 description 2416 "The VPN topology could be full-mesh,point-to-point 2417 and hub-spoke, others is reserved for future extensions."; 2418 } 2419 leaf tunnel-type { 2420 type tunnel-type; 2421 description 2422 "Tunnel Type:LDP：LDP Tunnel,RSVP-TE：RSVP-TE Tunnel 2423 SR-TE：SR-TE Tunnel,MPLS-TP：MPLS-TP Tunnel,VXLAN：VXLAN Tunnel 2424 "; 2425 } 2426 leaf admin-state { 2427 type admin-state; 2428 description 2429 "administrative status."; 2430 } 2431 leaf oper-state { 2432 type oper-state; 2433 config false; 2434 description 2435 "Operational status."; 2436 } 2437 leaf sync-state { 2438 type sync-state; 2439 config false; 2440 description 2441 "Sync status."; 2442 } 2443 list access-point { 2444 key "tp-id"; 2445 description 2446 "TP list of the access links which associated 2447 with PE and CE or ASBR"; 2448 uses pe-termination-point; 2449 } 2450 } 2451 grouping pe-termination-point { 2452 description 2453 "grouping for termination points."; 2454 uses tp-common-attribute; 2455 container peer-remote-node { 2456 description 2457 "TP Peering Information, including CE 2458 peering and ASBR peering."; 2459 uses remote-peer-tp; 2460 } 2461 container tp-connection-specific-attribute { 2462 description 2463 "Termination point basic info."; 2464 uses tp-connection-specific-attribute; 2465 } 2466 list routing-protocol { 2467 key "type"; 2468 description 2469 "route protocol spec."; 2470 uses routing-protcol; 2471 } 2472 } 2474 grouping segment-service-basic { 2475 leaf svc-input-bandwidth { 2476 type uint64; 2477 units "bps"; 2478 mandatory true; 2479 description 2480 "From the customer site's perspective, the service 2481 input bandwidth of the connection or download 2482 bandwidth from the SP to the site."; 2483 } 2484 leaf svc-output-bandwidth { 2485 type uint64; 2486 units "bps"; 2487 mandatory true; 2488 description 2489 "From the customer site's perspective, the service 2490 output bandwidth of the connection or upload 2491 bandwidth from the site to the SP."; 2492 } 2493 leaf svc-mtu { 2494 type uint16; 2495 units "bytes"; 2496 mandatory true; 2497 description 2498 "MTU at service level. If the service is IP, 2499 it refers to the IP MTU. If CsC is enabled, 2500 the requested 'svc-mtu' leaf will refer to the 2501 MPLS MTU and not to the IP MTU."; 2502 } 2503 description 2504 "Defines basic service parameters for a site."; 2505 } 2507 container segment-vpns { 2508 list segment-vpn { 2509 key "index"; 2510 description 2511 "Segment Vpn list."; 2512 leaf index { 2513 type uint32; 2514 description 2515 "index of segment VPN in a composed VPN."; 2516 } 2517 uses VPN; 2518 } 2519 description 2520 "Container for Segment VPN."; 2521 } 2522 } 2523 2525 8. Service Model Usage Example 2527 This section provides an example of how a management system can use 2528 this model to configure an IP VPN service on network elements. 2530 +-----------------------------------------------------------------------+ 2531 | ------- PE2----- Spoke_Site1 | 2532 | | | 2533 | Hub_Site1-----PE1------ASBR1-------- ASBR2 | 2534 | | | 2535 | --------PE3 ---- Spoke_Site2 | 2536 +----------------|----------|--------------|--------|-------------------+ 2537 | | | | 2538 | 2539 | Inter-AS link| 2540 | | | | 2541 | | | | 2542 | Intra-AS | Inter-AS |Intra-AS| 2543 | | 2544 |<--------Composed VPN ----------->| 2546 Composed VPN Service Model Usage Example 2548 In this example, we want to achieve the provisioning of an end to end 2549 VPN service for three sites using a Hub-and-Spoke VPN service 2550 topology. The end to end VPN service is stitched by two segmented 2551 VPN. 2553 The following XML snippet describes the overall simplified service 2554 configuration of this composed VPN. 2556 2557 2558 2559 12456487 2560 hub-spoke 2561 hybrid 2562 2563 1 2564 111 2565 hub-spoke 2566 l2vpn 2567 2568 ap1-tp1 2569 PE1 2570 hub 2571 2572 Hub_Site1 2573 2574 2575 2576 1514 2577 10000000 2578 10000000 2579 2580 2581 2582 bgp 2583 2584 AS1 2585 2586 2587 2588 2589 ap1-tp2 2590 ASBR1 2591 hub 2592 2593 ASBR2 2594 2595 Option A 2596 2597 2598 1514 2599 10000000 2600 10000000 2601 2602 2603 2604 bgp 2605 2606 AS1 2607 2608 2609 2610 2611 2612 2 2613 222 2614 hub-spoke 2615 l3vpn 2616 2617 ap2-tp2 2618 PE2 2619 spoke 2620 2621 Spoke_Site1 2622 2623 2624 1514 2625 10000000 2626 10000000 2627 2628 2629 bgp 2630 2631 ASXXX 2632 2633 2634 2635 2636 ap2-tp1 2637 PE3 2638 spoke 2639 2640 Spoke_Site2 2641 2642 2643 1514 2644 10000000 2645 10000000 2646 2647 2648 bgp 2649 2650 ASXXX 2651 2652 2653 2654 2655 ap2-tp3 2656 ASBR2 2657 hub 2658 2659 ASBR1 2660 2661 2662 1514 2663 10000000 2664 10000000 2665 2666 2667 bgp 2668 2669 interAS-1 2670 2671 2672 2673 2674 2675 2677 9. Interaction with other YANG models 2679 As expressed in Section 4, this composed VPN service model is 2680 intended to be instantiated in a management system and not directly 2681 on network elements. 2683 The management system's role will be to configure the network 2684 elements. The management system may be modular and distinguish the 2685 component instantiating the service model (let's call it "service 2686 component") from the component responsible for network element 2687 configuration (let's call it "configuration component"). The service 2688 is built from a combination of network elements and protocols 2689 configuration which also include various aspects of the underlying 2690 network infrastructure, including functions/devices and their 2691 subsystems, and relevant protocols operating at the link and network 2692 layers across multiple device. Therefore there will be a strong 2693 relationship between the abstracted view provided by this service 2694 model and the detailed configuration view that will be provided by 2695 specific configuration models for network elements. 2697 The service component will take input from customer service model 2698 such as L3SM service model [RFC8299] or composed VPN service model 2699 and translate it into segment VPN in each domain and then further 2700 break down the segment VPN into detailed configuration view that will 2701 be provided by specific configuration models for network elements. 2703 10. Security Considerations 2705 The YANG module specified in this document defines a schema for data 2706 that is designed to be accessed via network management protocols such 2707 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 2708 is the secure transport layer, and the mandatory-to-implement secure 2709 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 2710 is HTTPS, and the mandatory-to-implement secure transport is TLS 2711 [RFC5246]. 2713 The NETCONF access control model [RFC6536] provides the means to 2714 restrict access for particular NETCONF or RESTCONF users to a 2715 preconfigured subset of all available NETCONF or RESTCONF protocol 2716 operations and content. 2718 There are a number of data nodes defined in this YANG module that are 2719 writable/creatable/deletable (i.e., config true, which is the 2720 default). These data nodes may be considered sensitive or vulnerable 2721 in some network environments. Write operations (e.g., edit-config) 2722 to these data nodes without proper protection can have a negative 2723 effect on network operations. These are the subtrees and data nodes 2724 and their sensitivity/vulnerability: 2726 o /composed-vpns/composed-vpn 2728 The entries in the list above include the whole composed vpn 2729 service configurations which the customer subscribes, and 2730 indirectly create or modify the PE,CE and ASBR device 2731 configurations. Unexpected changes to these entries could lead to 2732 service disruption and/or network misbehavior. 2734 o /composed-vpns/composed-vpn/segment-vpn 2736 The entries in the list above include the access points 2737 configurations. As above, unexpected changes to these entries 2738 could lead to service disruption and/or network misbehavior. 2740 o /composed-vpns/composed-vpn/access-point 2742 The entries in the list above include the access points 2743 configurations. As above, unexpected changes to these entries 2744 could lead to service disruption and/or network misbehavior. 2746 11. IANA Considerations 2748 This document registers a URI in the IETF XML registry [RFC3688]. 2749 Following the format in [RFC3688], the following registrations are 2750 requested to be made: 2752 --------------------------------------------------------------------- 2753 URI: urn:ietf:params:xml:ns:yang:ietf-composed-vpn-svc 2754 Registrant Contact: The IESG 2755 XML: N/A; the requested URI is an XML namespace. 2757 URI: urn:ietf:params:xml:ns:yang:ietf-segment-vpn 2758 Registrant Contact: The IESG 2759 XML: N/A; the requested URI is an XML namespace. 2760 --------------------------------------------------------------------- 2762 This document registers two YANG modules in the YANG Module Names 2763 registry [RFC6020]. 2765 --------------------------------------------------------------------- 2766 Name: ietf-composite-vpn-svc 2767 Namespace: urn:ietf:params:xml:ns:yang:ietf-composed-vpn-svc 2768 Prefix: composed-svc 2769 Reference: RFC xxxx 2770 Name: ietf-segmented-vpn 2771 Namespace: urn:ietf:params:xml:ns:yang:ietf-segment-vpn 2772 Prefix: segment-vpn 2773 Reference: RFC xxxx 2774 --------------------------------------------------------------------- 2776 12. References 2778 12.1. Normative References 2780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2781 Requirement Levels", March 1997. 2783 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2784 DOI 10.17487/RFC3688, January 2004, 2785 . 2787 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2788 (TLS) Protocol Version 1.2", RFC 5246, 2789 DOI 10.17487/RFC5246, August 2008, 2790 . 2792 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2793 the Network Configuration Protocol (NETCONF)", RFC 6020, 2794 DOI 10.17487/RFC6020, October 2010, 2795 . 2797 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2798 and A. Bierman, Ed., "Network Configuration Protocol 2799 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2800 . 2802 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2803 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2804 . 2806 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 2807 Protocol (NETCONF) Access Control Model", RFC 6536, 2808 DOI 10.17487/RFC6536, March 2012, 2809 . 2811 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2812 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2813 . 2815 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2816 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2817 . 2819 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2820 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2821 May 2017, . 2823 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2824 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2825 DOI 10.17487/RFC8299, January 2018, 2826 . 2828 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2829 Data Model for Layer 2 Virtual Private Network (L2VPN) 2830 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2831 2018, . 2833 12.2. Informative References 2835 [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing 2836 Domains: A model for routing in the Internet", RFC 1136, 2837 DOI 10.17487/RFC1136, December 1989, 2838 . 2840 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2841 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2842 . 2844 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2845 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2846 . 2848 Appendix A. Acknowledges 2850 Geng Liang,Congfeng Xie, Chen Rui, LiYa Zhang,Hui Deng contributed to 2851 an earlier version of [I-D.chen-opsawg-composite-vpn-dm]. We would 2852 like to thank the authors of that document on the operators' view for 2853 the PE-based VPN service configuration for material that assisted in 2854 thinking about this document. 2856 Authors' Addresses 2858 Roni Even 2859 Huawei Technologies,Co.,Ltd 2860 Tel Aviv 2861 Israel 2863 Email: roni.even@huawei.com 2865 Bo Wu 2866 Huawei 2867 101 Software Avenue, Yuhua District 2868 Nanjing, Jiangsu 210012 2869 China 2871 Email: lana.wubo@huawei.com 2872 Qin Wu 2873 Huawei 2874 101 Software Avenue, Yuhua District 2875 Nanjing, Jiangsu 210012 2876 China 2878 Email: bill.wu@huawei.com 2880 YingCheng 2881 China Unicom 2882 No.21 Financial Street, XiCheng District 2883 Beijing 100033 2884 China 2886 Email: chengying10@chinaunicom.cn