idnits 2.17.1 draft-chen-opsawg-composite-vpn-dm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 418 has weird spacing: '...ifierId yan...' -- The document date (October 24, 2016) is 2741 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) ** Downref: Normative reference to an Informational RFC: RFC 4110 == Outdated reference: A later version (-19) exists of draft-ietf-l3sm-l3vpn-service-model-18 == Outdated reference: A later version (-06) exists of draft-wu-opsawg-service-model-explained-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSA Working Group R. Chen 3 Internet-Draft L. Zhang 4 Intended status: Standards Track H. Deng 5 Expires: April 27, 2017 Huawei Technologies 6 L. Geng 7 China Mobile 8 C. Xie 9 China Telecom 10 October 24, 2016 12 YANG Data Model for Composite VPN Service Delivery 13 draft-chen-opsawg-composite-vpn-dm-00 15 Abstract 17 The operator facing data model is valuable to reduce the operations 18 and management. This document describes the YANG data model of the 19 composite VPN for operators to provision, optimize, monitor and 20 diagnose the end to end PE-based VPN services across multiple 21 autonomous systems (ASes). The model from this document are limited 22 to multiple ASes within one service provider. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 27, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Use Cases and Usage . . . . . . . . . . . . . . . . . . . . . 4 67 4. Data Model Design Requirements . . . . . . . . . . . . . . . 5 68 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 7 69 5.1. Composite VPN . . . . . . . . . . . . . . . . . . . . . . 7 70 5.2. Access Point . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2.1. Termination Point Basic Information . . . . . . . . . 10 72 5.2.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.2.3. Routing Protocol . . . . . . . . . . . . . . . . . . 11 74 5.3. Segmental VPN . . . . . . . . . . . . . . . . . . . . . . 11 75 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 46 81 10.2. Informative References . . . . . . . . . . . . . . . . . 46 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 84 1. Introduction 86 Internet Service Providers (ISPs) have significant interest on 87 providing Provider Edge (PE) based virtual private network (VPN) 88 services, in which the tunnel endpoints are the PE devices. In this 89 case, the Customer Edge (CE) devices do not need to have any special 90 VPN capabilities. Customers can reduce support costs by outsourcing 91 VPN operations to ISPs and using the obtained connectivity. 93 Typically, customers require either layer 2 or layer 3 connectivity 94 services to exchange traffic among a collection of sites. The ISP 95 gets the requirement and deploys the end to end VPN with an 96 orchestrator across multiple autonomous systems (AS) within its 97 administration. 99 The YANG data model[RFC7950] described in 100 [I-D.ietf-l3sm-l3vpn-service-model] is used for communication between 101 customers and network operators. It facilitates customers to request 102 the layer 3 VPN service while concealing many provider parameters 103 they do not need to know. 105 However, the network operators have a different view of the managed 106 network. An operator facing data model is required to reduce the 107 operations and management while still having full control on the 108 network. So that the operators can provision, optimize, monitor and 109 diagnose the VPN deployment based on the existing network 110 infrastructure. Standardization of such a operator facing data model 111 can help operators to operate and manage the VPN deployment in a 112 standard way, and facilitate automation of optimization and diagnosis 113 by standardizing the communication among multi-vendor services such 114 as inventory, provisioning, monitoring, analysis and so on. 116 This document describes the generic VPN data model from the 117 operators' view for the PE-based VPN service configuration. It aims 118 at providing a simplified configuration on how the requested VPN 119 service is to be deployed over the shared network infrastructure. 120 This data model is limited to PE-Based VPNs as described in RFC 4110 121 [RFC4110] with the combination of layer 2 and layer 3 VPN services 122 across multiple ASes within one ISP. 124 2. Definitions 126 o Customer Facing Service: The highly abstracted service which can 127 be easily understood and consumed by the customer. With the 128 emerging of cloud computing, customers require fast, easy to use, 129 and on demand service from network operators. 131 o Operator Facing Service: The service provided for the operator to 132 analyse, optimize, monitor and diagnose the network. It usually 133 provides more detailed information related to the operations and 134 management. 136 o Segmental VPN service: The VPN service deployed for one VPN 137 segment within one AS. 139 o Composite VPN service: The VPN service deployed within the ISP 140 administrative domain across one or more segments. It could be a 141 combination of layer 2 and layer 3 VPN services for each segment. 143 3. Use Cases and Usage 145 In practice, ISP may have various scenarios for the end to end VPN 146 service deployment depending on the network infrastructure and the 147 customer sites connectivity requirements. It will consequently 148 generate requirements of the generic Composite VPN service delivery 149 model design. The Composite VPN data model described in this 150 document covers the following scenarios: 152 o Multi-AS VPN Service: Customer sites are located in different 153 autonomous systems(AS). ISP need to operate and manage the VPN 154 service across multiple ASes. There are several different 155 deployment scenarios in this case, e.g. single provider and 156 multiple providers. This document only considers a single 157 provider has multiple ASes which is less complex than the multi- 158 provider and multi-AS case. 160 o Composite L2 and/or L3 VPN Service: Although the customer may 161 request either layer 2 or layer 3 VPN service, the network 162 infrastructure among customer sites may require different VPN 163 service in the corresponding AS. So, an end to end VPN service 164 within the ISP domain may be a composition of multiple segmental 165 layer 2 and layer 3 VPN services. For example, a typical use case 166 is that the enterprise need a layer 3 VPN connection to the remote 167 data center. The end to end VPN connection may go across the 168 metro access network and the IP core network. So the actual 169 deployment of the customer's request in ISP network maybe the 170 Virtual Private Wire Service (VPLS) in the metro access network 171 and the L3VPN in the IP WAN. 173 o Dynamic Site Insertion: The customer site that is not in the 174 previously provisioned VPN can be quickly included. 176 A typical usage of this operator facing model is as a description of 177 the end to end PE based VPN service for a network orchestration layer 178 [I-D.wu-opsawg-service-model-explained] which can then be translated 179 to Segmental VPN information for the configuration of domain 180 controllers. As shown in the following figure, while, for example, 181 users may send highly abstracted layer 3 VPN service requests to the 182 service orchestrator, it cannot provide enough information for 183 operators to operate and manage an end to end VPN service. The 184 operator facing interface enables configuration of VPN deployment by 185 introducing more network knowledge and governance policies. For 186 example : 188 o Add the operational requirements for operation visualization, 189 monitoring, and diagnosis. This requires more information on the 190 Segmental VPN deployment in each AS. 192 o Optimize the VPN deployment of the customer's requests based on 193 the exiting networking, e.g. deploy the L3VPN request from the 194 customer to multiple VPN segments (IP Radio Access Network, Packet 195 Transport Network, IP Core) in the end to end environment. 197 o Manage various policies for different customers. 199 Customer Facing + 200 Model | 201 +------v-------+ +-------------+ 202 | Service | | Application | 203 | Orchestrator | | BSS/OSS | 204 +------+-------+ +------+------+ 205 | | 206 Operator Facing +--------+ +---------+ 207 Model | | 208 +----v---v-----+ 209 | Network | 210 | Orchestrator | 211 +----+---+-----+ 212 | | 213 +---------+ +-----------+ 214 | | 215 +------+------+ +------+------+ 216 | Controller1 | | Controller2 | 217 +------+------+ +------+------+ 218 | | 219 +---------+-----------+ +----------+----------+ 220 | AS1 L2VPN | | AS2 L3VPN | 221 +-------+ | +------+ +------+ | | +------+ +------+ | +-------+ 222 | Site1 +----+ PE11 +---+ PE12 +------+ PE21 +---+ PE22 +----+ Site2 | 223 +-------+ | +------+ +------+ | | +------+ +------+ | +-------+ 224 +---------------------+ +---------------------+ 226 4. Data Model Design Requirements 228 In order to describe the operator facing interface for the end to end 229 PE based VPN service, the data model design should address the 230 following requirements: 232 1. As the operator facing model, the model need to facilitate the 233 operator to provision, optimize, monitor and diagnose the end to 234 end PE-based VPN services across multiple autonomous systems. 235 The model should be described from the operator's view of the 236 VPN, not from the customer's view. For example, when the 237 customer requests a VPN service, this can be expressed as a set 238 of sites with the interconnected VPN. Both the sites and the VPN 239 model only consist of information that can be provided by the 240 customer. For the same VPN service, the operator need to know 241 information for operations and management, e.g. the access points 242 on the PE, the VPN segment in each AS, and even the inter- 243 connection between two ASes. 245 2. The model facilitates that the operator can quickly find all the 246 information related to one end-to-end VPN of a particular 247 customer. So that the operator can easily deal with one end to 248 end VPN deployment. For example, the operator can trace how a 249 VPN service request from the customer is really deployed 250 (possibly across several ASes) in the network infrastructure. So 251 when a connection failure happens, the operator can quickly 252 determine where the problem is. 254 3. The model must be able to express various number of Segmental VPN 255 composition. As described in Section 3, the operator need to 256 operate and manage VPN among customer sites located in different 257 autonomous systems(AS). In this case, an end to end VPN service 258 deployed across multiple ASes, each of which can be described as 259 a Segmental VPN. So the model should have the flexibility to 260 describe both single AS and multi-AS VPN cases. 262 4. The model should include the basic information about the end to 263 end VPN service. On one hand the operator can easily understand 264 the deployment of one customer request. On the other hand, the 265 overall information contains many parameters that can be referred 266 and reused by many associated Segmental VPN models. This could 267 be an abstract of the customer facing VPN model with information 268 can be reused from operator's view. 270 5. The model should allow to define one or multiple Segmental VPN 271 information for each AS among the sites. As described in 272 Section 3, an end to end VPN service within the ISP domain may 273 consist of multiple segmental layer 2 and layer 3 VPN services. 274 So the Segmental VPN description should have the capability to 275 address the type of technology in use, and the corresponding 276 parameters that will be used for the operations and management. 278 6. The model should facilitate operators to know the Access Point 279 (AP) information for both Composite VPN and Segmental VPN. The 280 AP of a Composite VPN is the interface between the provider 281 network and the customer network. The AP of the Segmental VPN is 282 the interface between two adjacent Segmental VPNs. The AP 283 information is crucial because it has to match the remote peer 284 for connectivity, and it usually contains information that is 285 useful for the operations and management. For example, the AP 286 may indicate what's the peer connected, and the routing protocol 287 that is used for exchanging routing information, and so on. 289 7. The VPN provisioning policy is optional but recommended in the 290 model. The operator can predefine several VPN provisioning 291 policies based on the offered business. The policy description 292 may include the naming, path selection, VPN concatenation rules, 293 and resource pools, such as route target, route distinguisher, 294 VLAN, and IP address. So when the customer requests a VPN, the 295 system can automatically generate the end to end VPN planning 296 according to the provisioning policies. To be simple, the model 297 can only have an ID index refers to the VPN provisioning policy 298 defined in other service applications. 300 8. The capability to describe the various QoS requirements should be 301 supported by the model. There can be two kinds of QoS 302 configuration. 304 * The AP based QoS: describes the QoS requirements on the access 305 point. For example, the CAR (committed access rate) 306 definition on the inbound or outbound ports. 308 * The flow based QoS: describes the QoS requirements on a flow. 309 This enables the fine grained QoS control with the capability 310 of identifying the flow. 312 5. Design of the Data Model 314 The PE-based VPN service is modeled with a recursive pattern. The 315 VPN service deployed within each AS is modeled as a Segmental VPN 316 object including the VPN description information within this AS and 317 the Access Points (AP) that are used to connect to the peered device 318 or AS. As an end to end VPN service within the ISP domain, it's then 319 modeled as a Composite VPN object with the overall VPN information 320 and the APs that are used to connect to the peered customer sites. 322 5.1. Composite VPN 324 The composedVPN top container contains the business type, VPN basic 325 information, a list of segment VPN information, a list of access 326 point information and and some overall information. The id MUST be 327 unique for the reference of this composed VPN service. The tenantID 328 associates this VPN service to a dedicated customer. The 329 businessTypeID can associate composed VPN with a business template. 330 The vpnBasicInfo object here includes basic information for this 331 Composite VPN service. I.e., all the properties (e.g., topology, 332 serviceType) in this object describe the overview that the customer 333 want, no matter with any segment VPN information. The 334 accessPointList describes a list of APs that are used to connect to 335 the peered customer sites. A Composite VPN includes one or more 336 Segmental VPN. 338 +--rw composedVpns* [id] 339 +--rw id yang:uuid 340 +--rw name? string 341 +--rw description? string 342 +--rw tenantId? yang:uuid 343 +--rw businessTypeID? yang:uuid 344 +--rw vpnBasicInfo 345 | ... 346 +--ro operStatus? CommonTypes:OperStatus 347 +--ro syncStatus? CommonTypes:SyncStatus 348 +--rw startTime? yang:date-and-time 349 +--rw segVpnList* [index] 350 | ... 351 +--rw accessPointList* [id] 352 ... 354 5.2. Access Point 356 The accessPointList models a list of APs including the access or 357 attachment information for the remote peer. AP is provided by the PE 358 either in the Composite VPN view or in the Segmental VPN view. The 359 AP uses working layer and corresponding layer information to describe 360 the different configurations in Composite VPN level and the Segmental 361 VPN level. 363 +--rw accessPointList* [id] 364 +--rw id yang:uuid 365 +--rw name? string 366 +--rw description? string 367 +--rw neID? yang:uuid 368 +--rw containingMainTPID? yang:uuid 369 +--rw tpBasicInfo 370 | +--rw edgePointRole? CommonTypes:EdgePointRole 371 | +--rw topologyRole? CommonTypes:TopoNodeRole 372 | +--rw Type? CommonTypes:TpType 373 | +--rw workingLayer? CommonTypes:LayerRate 374 | +--rw typeSpecList* [layerRate] 375 | | +--rw layerRate CommonTypes:LayerRate 376 | | +--rw (specValue)? 377 | | +--:(LR_Ethernet) 378 | | | +--rw ethernetSpec 379 | | | +--rw accessType? CommonTypes:EthernetEncapType 380 | | | +--rw (accessVlanValue)? 381 | | | | +--:(QinQVlan) 382 | | | | | +--rw qinqVlan 383 | | | | | +--rw cvlanList* uint64 384 | | | | | +--rw svlanList? uint64 385 | | | | +--:(DOT1Q) 386 | | | | +--rw dot1q 387 | | | | +--rw dot1qVlanList* uint64 388 | | | +--rw vlanAction? CommonTypes:EthernetAction 389 | | | +--rw actionValue? string 390 | | +--:(LR_IP) 391 | | | +--rw ipSpec 392 | | | +--rw masterIp? string 393 | | | +--rw mtu? uint64 394 | | +--:(LR_Vxlan) 395 | | +--rw vxlanSpec 396 | | +--rw vni? uint32 397 | | +--rw vtepIP? string 398 | +--rw adminStatus? CommonTypes:AdminStatus 399 | +--rw tpQosNode 400 | | +--rw qosConfigType? QosConfigType 401 | | +--rw qosDetailType? QosDetailType 402 | | +--rw inTpCar* [index] 403 | | | +--rw index uint32 404 | | | +--rw dataKind? dataKind 405 | | | +--rw actionType? ActionType 406 | | | +--rw action? string 407 | | +--rw outTpCar* [index] 408 | | | +--rw index uint32 409 | | | +--rw dataKind? dataKind 410 | | | +--rw actionType? ActionType 411 | | | +--rw action? string 412 | | +--rw inQosProfileId? yang:uuid 413 | | +--rw outQosProfileId? yang:uuid 414 | +--rw flowServices* [index] 415 | | +--rw qosConfigType? QosConfigType 416 | | +--rw flowQosTemplateID? yang:uuid 417 | | +--rw flowServices* [flowClassifierId] 418 | | +--rw flowClassifierId yang:uuid 419 | | +--rw flowBehaviors* [index] 420 | | +--rw index uint32 421 | | +--rw dataKind? dataKind 422 | | +--rw actionType? ActionType 423 | | +--rw action? string 424 | +--rw addtionalInfo* [name] 425 | +--rw name string 426 | +--rw value? string 427 +--rw peerCeTp 428 | +--rw ceID? yang:uuid 429 | +--rw ceDirectNeID? yang:uuid 430 | +--rw ceDirectTPID? yang:uuid 431 | +--rw ceIfmasterIp? string 432 | +--rw location? string 433 +--rw routeProtocolSpec* [type] 434 | +--rw type CommonTypes:RouteProtocolType 435 | +--rw (para)? 436 | +--:(staticRouting) 437 | | +--rw staticRouteItems* [index] 438 | | +--rw index uint32 439 | | +--rw destinationCidr? string 440 | | +--rw egressTP? yang:uuid 441 | | +--rw routePreference? string 442 | | +--rw nextHopIp? string 443 | +--:(bgp) 444 | +--rw bgpProtocols* [index] 445 | +--rw index uint32 446 | +--rw peerAsNumber? uint64 447 | +--rw bgpMaxPrefix? int32 448 | +--rw bgpMaxPrefixAlarm? uint32 449 | +--rw peerIp? string 450 +--ro operStatus? CommonTypes:OperStatus 452 5.2.1. Termination Point Basic Information 454 The tpBasicInfo describes the basic information that is used to 455 express the design intent of the VPN from the Termination Point (TP) 456 of view. That means the information described here is relative 457 static, no matter which exact peer TP is going to connect. 459 The typeSpecList describes the layered information on the TP. It 460 describes in detail on the ethernet layer information, or the IP 461 layer and VxLan information if any higher layer protocol is enabled. 463 5.2.2. QoS 465 This model support two kinds of QoS description as described in the 466 section 4: 468 o TP based QoS: describes the OoS requirements on a termination 469 point. For example, the CAR (committed access rate) definition on 470 the inbound or outbound ports. 472 o Flow based QoS: describes the QoS requirements on a flow. This 473 enables the fine grained QoS control with the capability of 474 identifying the flow. 476 5.2.3. Routing Protocol 478 The routeProtocolSpec object describes information of the routing 479 protocol that is used to exchange the routing information with the 480 remote peer. This object is extensible with any possible routing 481 protocols. The BGP and static routing listed are examples to show 482 how these two widely used solutions are described. 484 5.3. Segmental VPN 486 The segVpnList describes a list of Segmental VPN information which is 487 only from the segment point of view. I.e., the description here 488 takes care about how the Segmental VPN looks like and how it can 489 communicate with peered devices outside this Segmental VPN. The 490 segment information is composed of basic VPN information and a list 491 of APs. The set of APs in the description are interfaces that 492 customer sites or other segment VPNs can attach. In different 493 scenarios, each Segmental VPN could be a layer 2 VPN, or layer 3 VPN, 494 or even a termination point. 496 +--rw segVpnList* [index] 497 +--rw index uint32 498 +--rw vpnType? string 499 +--rw vpnRole? VPNTypes:ProtectionRole 500 +--rw vpnInfo 501 +--rw (vpnType)? 502 +--:(wanVpn) 503 +--rw vpn 504 +--rw id? yang:uuid 505 +--rw name? string 506 +--rw description? string 507 +--rw vpnBasicInfo 508 | +--rw topology? CommonTypes:Topology 509 | +--rw serviceType? VPNTypes:ServiceType 510 | +--rw technology? VPNTypes:VPNTunnelType 511 | +--rw adminStatus? CommonTypes:AdminStatus 512 +--ro operStatus? CommonTypes:OperStatus 513 +--ro syncStatus? CommonTypes:SyncStatus 514 +--rw accessPointList* [id] 515 ... 517 6. YANG Module 519 file "ietf-nvo-vpn.yang" 520 module ietf-nvo-vpn { 521 namespace "urn:ietf:params:xml:ns:yang:ietf-nvo-vpn" ; 522 prefix VPN ; 523 import ietf-yang-types { 524 prefix yang; 525 } 527 import ietf-nvo-common-types { 528 prefix CommonTypes; 529 } 530 import ietf-nvo-tp { 531 prefix TP; 532 } 534 import ietf-nvo-vpn-types { 535 prefix VPNTypes; 536 } 538 organization "" ; 539 contact ""; 540 description "ietf-nvo-vpn"; 541 revision 2016-10-24 { 542 reference "draft-chen-opsawg-composite-vpn-dm-00"; 543 } 545 container nvoVPNMgr{ 546 description ""; 547 list composedVPNs { 548 key "id"; 549 description ""; 550 uses VPN:ComposedVPN; 551 } 552 } 554 grouping ComposedVPN { 555 description "ComposedVPN Grouping."; 557 leaf id { 558 type yang:uuid ; 559 description "UUID-STR for service ." ; 560 } 562 leaf name { 563 type string {length "0..200";} 564 description "Human-readable name for the service." ; 565 } 566 leaf description { 567 type string {length "0..200";} 568 description "Detailed specification for the servcie." ; 569 } 570 leaf tenantId { 571 type yang:uuid; 572 description "UUID-STR for tenant." ; 573 } 574 leaf businessTypeID { 575 type yang:uuid; 576 description "business Type Name" ; 577 } 579 container vpnBasicInfo { 580 description "VPN BASIC INFO"; 581 uses VPNTypes:VPNBasicInfo; 582 } 584 leaf operStatus { 585 type CommonTypes:OperStatus; 586 config false; 587 description "Operational status." ; 588 } 590 leaf syncStatus { 591 type CommonTypes:SyncStatus; 592 config false; 593 description "Sync status." ; 594 } 596 leaf startTime { 597 type yang:date-and-time; 598 description "Service lifecycle: request for service start 599 time." ; 600 } 602 list segVpnList { 603 key "index"; 604 description "SegVpn list "; 605 uses VPN:SegmentVPN; 606 } 608 list accessPointList { 609 key "id"; 610 description "TP list of the access links which associated 611 with CE and PE"; 612 uses TP:Tp; 613 } 614 } 616 grouping SegmentVPN { 617 description "SegmentVPN Grouping."; 618 leaf index { 619 type uint32; 620 description "index of segment VPN in a composed VPN."; 621 } 623 leaf vpnType { 624 type string {length "0..30";} 625 description "value: nop/wanVpn"; 626 } 628 leaf vpnRole { 629 type VPNTypes:ProtectionRole; 630 description "value: nop|vpn"; 631 } 633 container vpnInfo { 634 description "vpn information"; 635 choice vpnType { 636 description "vpn type."; 637 case wanVpn { 638 container vpn { 639 description "vpn."; 640 uses VPN:VPN; 641 } 642 } 643 } 644 } 645 } 647 grouping VPN { 648 description "VPN Grouping."; 650 leaf id { 651 type yang:uuid ; 652 description "UUID-STR for VPN." ; 653 } 654 leaf name { 655 type string {length "0..200";} 656 description "Human-readable name for the service." ; 657 } 659 leaf description { 660 type string {length "0..200";} 661 description "Detailed specification for the servcie." ; 662 } 664 container vpnBasicInfo { 665 description "vpn basic info" ; 666 uses VPNTypes:VPNBasicInfo; 667 } 669 leaf operStatus { 670 type CommonTypes:OperStatus; 671 config false; 672 description "Operational status." ; 673 } 675 leaf syncStatus { 676 type CommonTypes:SyncStatus; 677 config false; 678 description "Sync status." ; 679 } 681 list accessPointList { 682 key "id"; 683 description "TP list of the access links which associated 684 with CE and PE"; 685 uses TP:Tp; 686 } 687 } 688 } 689 691 file "ietf-nvo-common-types.yang" 692 module ietf-nvo-common-types { 693 namespace "urn:ietf:params:xml:ns:yang:ietf-nvo-common-types" ; 694 prefix CommonTypes ; 695 import ietf-yang-types { 696 prefix yang; 697 } 699 organization "" ; 700 contact ""; 701 description "ietf-nvo-common-types"; 702 revision 2016-10-24 { 703 reference "draft-chen-opsawg-composite-vpn-dm-00"; 704 } 706 typedef AdminStatus { 707 type enumeration { 708 enum active { 709 description "Active status"; 710 } 711 enum inactive { 712 description "Inactive status"; 713 } 714 enum partial { 715 description "Partial status"; 716 } 717 } 718 description "AdminStatus"; 719 } 721 typedef OperStatus { 722 type enumeration { 723 enum up { 724 description "Up status"; 725 } 726 enum down { 727 description "Down status"; 728 } 729 enum degrade { 730 description "Degrade status"; 731 } 732 } 733 description "OperStatus"; 734 } 736 typedef SyncStatus { 737 type enumeration { 738 enum SYNC { 739 description "Sync status"; 740 } 741 enum OUT-SYNC { 742 description "Out sync status"; 743 } 744 } 745 description "SyncStatus"; 746 } 748 typedef Topology { 749 type enumeration { 750 enum full-mesh { 751 description "full-mesh"; 752 } 753 enum point_to_multipoint { 754 description "point_to_multipoint"; 755 } 756 enum point_to_point { 757 description "point_to_point"; 758 } 759 enum complex { 760 description "complex"; 761 } 763 } 764 description "Topology"; 765 } 767 typedef Technology { 768 type enumeration { 769 enum mpls { 770 description "mpls"; 771 } 772 enum rosen_multivpn { 773 description "rosen_multivpn"; 774 } 775 enum ng_multivpn { 776 description "ng_multivpn"; 777 } 778 enum vxlan_overlay_l3vpn { 779 description "vxlan_overlay_l3vpn"; 780 } 781 enum eth_oversdh { 782 description "eth_oversdh"; 783 } 784 } 785 description "Technology"; 786 } 788 typedef TopoNodeRole { 789 type enumeration { 790 enum other { 791 description "other"; 792 } 793 enum hub { 794 description "hub"; 795 } 796 enum spoke { 797 description "spoke"; 798 } 799 } 800 description "TopoNodeRole"; 801 } 803 typedef TpType{ 804 type enumeration { 805 enum nop { 806 description "nop"; 807 } 808 enum PTP { 809 description "PTP"; 810 } 811 enum CTP { 812 description "CTP"; 813 } 814 enum TRUNK { 815 description "TRUNK"; 816 } 817 enum LoopBack { 818 description "LoopBack"; 819 } 820 enum TPPool { 821 description "TPPool"; 822 } 823 } 824 description "TpType"; 825 } 827 typedef LayerRate{ 828 type enumeration { 829 enum LR_UNKNOW { 830 description "LR_UNKNOW"; 831 } 832 enum LR_IP { 833 description "LR_IP"; 834 } 835 enum LR_ETHERNET { 836 description "LR_ETHERNET"; 837 } 838 enum LR_VXLAN { 839 description "LR_VXLAN"; 840 } 841 } 842 description "LayerRate"; 843 } 845 typedef EthernetEncapType { 846 type enumeration { 847 enum DEFAULT { 848 description "DEFAULT"; 849 } 850 enum DOT1Q { 851 description "DOT1Q"; 852 } 853 enum QINQ { 854 description "QINQ"; 855 } 856 enum UNTAG { 857 description "UNTAG"; 858 } 860 } 861 description "EthernetEncapType"; 862 } 863 typedef EthernetAction { 864 type enumeration { 865 enum nop { 866 description "nop"; 867 } 868 enum UNTAG { 869 description "UNTAG"; 870 } 871 enum STACKING { 872 description "STACKING"; 873 } 874 } 875 description "EthernetAction"; 876 } 878 typedef RouteProtocolType { 879 type enumeration { 880 enum staticRouting { 881 description "staticRouting"; 882 } 883 enum bgp { 884 description "bgp"; 885 } 886 enum rip { 887 description "rip"; 888 } 889 enum ospf { 890 description "ospf"; 891 } 892 enum isis { 893 description "isis"; 894 } 895 } 896 description "RouteProtocolType"; 897 } 899 typedef QosPriorityType { 900 type enumeration { 901 enum nop { 902 description "nop"; 903 } 904 enum 802dot1p { 905 description "802dot1p"; 906 } 907 enum dscp { 908 description "dscp"; 909 } 910 enum mplsExp { 911 description "mplsExp"; 912 } 913 enum cos { 914 description "cos"; 915 } 916 enum ipPrecedence { 917 description "ipPrecedence"; 918 } 919 } 920 description "QosPriorityType"; 921 } 923 typedef ColorType { 924 type enumeration { 925 enum nop { 926 description "nop"; 927 } 928 enum green { 929 description "green"; 930 } 931 enum yellow { 932 description "yellow"; 933 } 934 enum red { 935 description "red"; 936 } 937 } 938 description "ColorType"; 939 } 941 grouping nvStringList{ 942 description "nvStringList Grouping."; 944 list nvstringList { 945 key "name"; 946 uses CommonTypes:nvstring; 947 description "nvStringList"; 948 } 949 } 951 grouping nvstring { 952 description "nvstring Grouping."; 953 leaf name { 954 type string; 955 description "string name "; 956 } 957 leaf value { 958 type string; 959 description "string value"; 960 } 961 } 963 typedef FlowClassifierType { 964 type enumeration { 965 enum nop { 966 description "nop"; 967 } 968 enum 802dot1p { 969 description "802dot1p"; 970 } 971 enum dscp { 972 description "dscp"; 973 } 974 enum cos { 975 description "cos"; 976 } 977 enum mpls-exp { 978 description "mpls-exp"; 979 } 980 enum sourceIP { 981 description "sourceIP"; 982 } 983 enum destinationIP { 984 description "destinationIP"; 985 } 986 } 987 description "FlowClassifierType"; 988 } 990 grouping ObjectIdentifiers { 991 description "ObjectIdentifiers Grouping."; 993 list ObjectIdentifiers { 994 key "obejctId"; 995 uses CommonTypes:ObjectIdentifier; 996 description "ObjectIdentifiers"; 997 } 998 } 1000 grouping ObjectIdentifier { 1001 description "ObjectIdentifier Grouping."; 1003 leaf objectType { 1004 type CommonTypes:ObjectType; 1005 description "objectType"; 1006 } 1008 leaf obejctId { 1009 type yang:uuid; 1010 description "obejctId"; 1011 } 1013 leaf roleLable { 1014 type string {length "0..200";} 1015 description "here is the route role"; 1016 } 1017 } 1019 typedef ObjectType { 1020 type enumeration { 1021 enum nop { 1022 description "nop"; 1023 } 1024 enum SEG-VPN { 1025 description "SEG-VPN"; 1026 } 1027 enum TP { 1028 description "TP"; 1029 } 1030 enum TPL { 1031 description "TPL"; 1032 } 1033 enum NE { 1034 description "NE"; 1035 } 1036 enum BUSINESSTYPE { 1037 description "BUSINESSTYPE"; 1038 } 1039 enum COMPOSED-VPN { 1040 description "COMPOSED-VPN"; 1041 } 1042 enum SUBNETWORK { 1043 description "SUBNETWORK"; 1044 } 1045 } 1046 description "ObjectType"; 1047 } 1048 typedef EdgePointRole { 1049 type enumeration { 1050 enum nop { 1051 description "nop"; 1052 } 1053 enum PE { 1054 description "PE"; 1055 } 1056 enum P { 1057 description "P"; 1058 } 1059 enum UNI { 1060 description "UNI"; 1061 } 1062 enum NNI { 1063 description "NNI"; 1064 } 1065 enum AsbTP { 1066 description "AsbTP"; 1067 } 1068 } 1069 description "EdgePointRole"; 1070 } 1072 typedef DomainRole { 1073 type enumeration { 1074 enum nop { 1075 description "nop"; 1076 } 1077 enum external { 1078 description "external"; 1079 } 1080 enum internal { 1081 description "internal"; 1082 } 1083 enum asb { 1084 description "asb"; 1085 } 1086 } 1087 description "DomainRole"; 1088 } 1090 grouping CommandResult { 1091 description "this is the common result which is send back by 1092 server by RPC response"; 1093 leaf resultCode { 1094 type int32; 1095 description "resultCode"; 1097 } 1098 leaf-list successResourceList { 1099 type yang:uuid; 1100 description "successResourceList"; 1101 } 1102 list failedResourceList { 1103 uses CommonTypes:FailedNode; 1104 description "failedResourceList"; 1105 } 1106 leaf errorReason { 1107 type string {length "0..200";} 1108 description "errorReason"; 1109 } 1110 } 1112 grouping FailedNode { 1113 description "fail reason for each object."; 1114 leaf resourceId { 1115 type yang:uuid; 1116 description "failed object."; 1117 } 1118 leaf errorReason { 1119 type string {length "0..200"; } 1120 description "errorReason"; 1121 } 1122 } 1124 grouping SLA { 1125 description "SLA"; 1126 leaf latency { 1127 type uint32; 1128 description "delay,unit:ms."; 1129 } 1130 } 1132 typedef ConnectionDirection { 1133 type enumeration { 1134 enum CD-UNI { 1135 description "CD-UNI"; 1136 } 1137 enum CD-BI { 1138 description "CD-BI"; 1139 } 1140 } 1141 description "ConnectionDirection"; 1142 } 1143 typedef ObjectDirection { 1144 type enumeration { 1145 enum IN { 1146 description "IN"; 1147 } 1148 enum OUT { 1149 description "OUT"; 1150 } 1151 enum BI-DIRECTION { 1152 description "BI-DIRECTION"; 1153 } 1154 } 1155 description "ObjectDirection"; 1156 } 1158 typedef DiversityType { 1159 type enumeration { 1160 enum NOP { 1161 description "NOP"; 1162 } 1163 enum PE-DIFF { 1164 description "PE-DIFF"; 1165 } 1166 enum MAIN-TP-DIFF { 1167 description "MAIN-TP-DIFF"; 1168 } 1169 } 1170 description "DiversityType"; 1171 } 1172 } 1173 1175 file "ietf-nvo-qos-types.yang" 1176 module ietf-nvo-qos-types { 1177 namespace "urn:ietf:params:xml:ns:yang:ietf-nvo-qos-types"; 1178 prefix QosTypes; 1180 import ietf-yang-types { prefix yang; } 1182 organization ""; 1183 contact ""; 1184 description "ietf-nvo-qos-types"; 1185 revision 2016-10-24 { 1186 reference "draft-chen-opsawg-composite-vpn-dm-00"; 1187 } 1189 /***************************************************************** 1190 * Type definitions 1191 *****************************************************************/ 1192 typedef qosPriorityType { 1193 type enumeration { 1194 enum nop{ 1195 description "nop"; 1196 } 1197 enum 802dot1p{ 1198 description "802dot1p"; 1199 } 1200 enum dscp{ 1201 description "dscp"; 1202 } 1203 enum mplsExp{ 1204 description "mplsExp"; 1205 } 1206 enum cos{ 1207 description "cos"; 1208 } 1209 enum ipPrecedence{ 1210 description "ipPrecedence"; 1211 } 1212 } 1213 description "qosPriorityType"; 1214 } 1216 typedef classifierDetailType { 1217 type enumeration { 1218 enum nop{ 1219 description "nop"; 1220 } 1221 enum ipPrefixList{ 1222 description "ipPrefixList"; 1223 } 1224 } 1225 description "classifierDetailType"; 1226 } 1228 typedef ActionType { 1229 type enumeration { 1230 enum nop{ 1231 description "nop"; 1232 } 1233 enum bandwidth{ 1234 description "bandwidth"; 1235 } 1236 enum pass{ 1237 description "pass"; 1238 } 1239 enum discard{ 1240 description "discard"; 1241 } 1242 enum remark{ 1243 description "remark"; 1244 } 1245 enum redirect{ 1246 description "redirect"; 1247 } 1248 enum recolor{ 1249 description "recolor"; 1250 } 1251 enum addRt{ 1252 description "addRt"; 1253 } 1254 } 1255 description "ActionType"; 1256 } 1258 typedef QosConfigType { 1259 type enumeration { 1260 enum nop{ 1261 description "nop"; 1262 } 1263 enum template{ 1264 description "template"; 1265 } 1266 enum agile{ 1267 description "agile"; 1268 } 1269 } 1270 description "QosConfigType"; 1271 } 1273 typedef flowClassifierType { 1274 type enumeration { 1275 enum nop{ 1276 description "nop"; 1277 } 1278 enum aluFlowClassifier{ 1279 description "aluFlowClassifier"; 1280 } 1281 } 1282 description "flowClassifierType"; 1283 } 1285 typedef QosDetailType { 1286 type enumeration { 1287 enum nop{ 1288 description "nop"; 1289 } 1290 enum car{ 1291 description "car"; 1292 } 1293 enum qosProfile{ 1294 description "qosProfile"; 1295 } 1296 enum diffServDomain{ 1297 description "diffServDomain"; 1298 } 1299 enum diffServ{ 1300 description "diffServ"; 1301 } 1302 enum aluDiffServ{ 1303 description "aluDiffServ"; 1304 } 1305 } 1306 description "QosDetailType"; 1307 } 1309 typedef ClassifierType { 1310 type enumeration { 1311 enum 802dot1p{ 1312 description "802dot1p"; 1313 } 1314 enum dscp{ 1315 description "dscp"; 1316 } 1317 enum cos{ 1318 description "cos"; 1319 } 1320 enum mpls-exp{ 1321 description "mpls-exp"; 1322 } 1323 enum sourceIP{ 1324 description "sourceIP"; 1325 } 1326 enum destinationIP{ 1327 description "destinationIP"; 1328 } 1329 } 1330 description "ClassifierType"; 1331 } 1333 typedef OrchPermitType { 1334 type enumeration { 1335 enum readUse{ 1336 description "readUse"; 1337 } 1338 enum crud{ 1339 description "crud"; 1340 } 1341 } 1342 description "OrchPermitType"; 1343 } 1345 typedef ruleType { 1346 type enumeration { 1347 enum 802dot1p{ 1348 description "802dot1p"; 1349 } 1350 enum dscp{ 1351 description "dscp"; 1352 } 1353 enum cos{ 1354 description "cos"; 1355 } 1356 enum mpls_exp{ 1357 description "mpls_exp"; 1358 } 1359 enum source_ip{ 1360 description "source_ip"; 1361 } 1362 enum destination_ip{ 1363 description "destination_ip"; 1364 } 1365 } 1366 description "ruleType"; 1367 } 1369 typedef MatchModeType { 1370 type enumeration { 1371 enum nop{ 1372 description "nop"; 1373 } 1374 enum match{ 1375 description "match"; 1376 } 1377 enum unmatch{ 1378 description "unmatch"; 1379 } 1380 } 1381 description "MatchModeType"; 1382 } 1383 typedef qosBehaviorType { 1384 type enumeration { 1385 enum qosCarBehavior{ 1386 description "qosCarBehavior"; 1387 } 1388 enum qosServiceChainBehavior{ 1389 description "qosServiceChainBehavior"; 1390 } 1391 } 1392 description "qosBehaviorType"; 1393 } 1395 typedef qosBehaviorDirectionType { 1396 type enumeration { 1397 enum upstream{ 1398 description "upstream"; 1399 } 1400 enum downstream{ 1401 description "downstream"; 1402 } 1403 enum bidirectional{ 1404 description "bidirectional"; 1405 } 1406 } 1407 description "qosBehaviorDirectionType"; 1408 } 1410 typedef dataKind { 1411 type enumeration { 1412 enum green{ 1413 description "green"; 1414 } 1415 enum yellow{ 1416 description "yellow"; 1417 } 1418 enum red{ 1419 description "red"; 1420 } 1421 enum all{ 1422 description "all"; 1423 } 1424 } 1425 description "dataKind"; 1426 } 1428 typedef profileType { 1429 type enumeration { 1430 enum profile{ 1431 description "profile"; 1432 } 1433 } 1434 description "profileType"; 1435 } 1437 typedef ruleOperatorType { 1438 type enumeration { 1439 enum and{ 1440 description "and"; 1441 } 1442 enum or{ 1443 description "or"; 1444 } 1445 } 1446 description "ruleOperatorType"; 1447 } 1449 /***************************************************************** 1450 * Groupings 1451 *****************************************************************/ 1452 grouping TPQosNode { 1453 description "TPQosNode Grouping."; 1455 leaf qosConfigType { 1456 type QosConfigType; 1457 description "qosConfigType"; 1458 } 1459 leaf qosDetailType { 1460 type QosDetailType; 1461 description "qosDetailType"; 1462 } 1463 list inTpCar { 1464 key index; 1465 uses FlowBehavior; 1466 description "inTpCar"; 1467 } 1468 list outTpCar { 1469 key index; 1470 uses FlowBehavior; 1471 description "outTpCar"; 1472 } 1473 leaf inQosProfileId { 1474 type yang:uuid; 1475 description "inQosProfileId"; 1476 } 1477 leaf outQosProfileId { 1478 type yang:uuid; 1479 description "outQosProfileId"; 1480 } 1481 } 1483 grouping FlowAndBehavior { 1484 description "FlowAndBehavior Grouping."; 1486 leaf flowClassifierId { 1487 type yang:uuid; 1488 description "flowClassifierId"; 1489 } 1490 list flowBehaviors { 1491 key index; 1492 uses FlowBehavior; 1493 description "flowBehaviors"; 1494 } 1495 } 1497 grouping FlowBehavior { 1498 description "FlowAndBehavior Grouping."; 1500 leaf index { 1501 type uint32; 1502 description "index"; 1503 } 1504 leaf dataKind { 1505 type dataKind; 1506 description "dataKind"; 1507 } 1508 leaf actionType { 1509 type ActionType; 1510 description "actionType"; 1511 } 1512 leaf action { 1513 type string; 1514 description "action"; 1515 } 1516 } 1518 grouping FlowClassifierRule { 1519 description "FlowClassifierRule Grouping."; 1521 leaf index { 1522 type uint32; 1523 description "index"; 1524 } 1525 leaf matchMode { 1526 type MatchModeType; 1527 description "matchMode"; 1528 } 1529 leaf type { 1530 type ClassifierType; 1531 description "type"; 1532 } 1533 leaf-list flowClassifierValue { 1534 type string; 1535 description "flowClassifierValue"; 1536 } 1537 leaf appendix { 1538 type string; 1539 description "appendix"; 1540 } 1541 } 1543 grouping BandWidthNode { 1544 description "BandWidthNode Grouping."; 1546 leaf cir { 1547 type uint32; 1548 description "cir"; 1549 } 1550 leaf pir { 1551 type uint32; 1552 description "pir"; 1553 } 1554 leaf cbs { 1555 type uint32; 1556 description "cbs"; 1557 } 1558 leaf pbs { 1559 type uint32; 1560 description "pbs"; 1561 } 1562 } 1564 grouping FlowServices { 1565 description "FlowServices Grouping."; 1567 leaf qosConfigType { 1568 type QosConfigType; 1569 description "qosConfigType"; 1570 } 1571 leaf flowQosTemplateID { 1572 type yang:uuid; 1573 description "flowQosTemplateID"; 1574 } 1575 leaf qosDetailType { 1576 type QosTypes:QosDetailType; 1577 description "qosDetailType"; 1578 } 1579 leaf inFlowQosTemplateID { 1580 type yang:uuid; 1581 description "inFlowQosTemplateID"; 1582 } 1583 leaf outFlowQosTemplateID { 1584 type yang:uuid; 1585 description "outFlowQosTemplateID"; 1586 } 1588 list flowServices { 1589 key flowClassifierId; 1590 description "default in flow and behaviors"; 1591 uses FlowAndBehavior; 1592 } 1593 } 1594 } 1595 1597 file "ietf-nvo-tp.yang" 1598 module ietf-nvo-tp { 1599 namespace "urn:ietf:params:xml:ns:yang:ietf-nvo-tp"; 1600 prefix TP; 1602 import ietf-yang-types { 1603 prefix yang; 1604 } 1606 import ietf-nvo-common-types { 1607 prefix CommonTypes; 1608 } 1610 import ietf-nvo-vpn-routeprotocol { 1611 prefix RouteProtocol; 1612 } 1614 import ietf-nvo-tp-types { 1615 prefix TPTypes; 1616 } 1618 organization ""; 1619 contact ""; 1620 description "This module contains a collection of YANG definitions 1621 for tp"; 1622 revision 2016-10-24 { 1623 reference "draft-chen-opsawg-composite-vpn-dm-00"; 1624 } 1626 container nvoTPMgr{ 1627 description "nvo tp management"; 1628 list tps { 1629 key "id"; 1630 uses TP:Tp; 1631 description "tp retrieve functions"; 1632 } 1633 } 1635 grouping Tp { 1636 description "model of TP"; 1637 leaf id { 1638 type yang:uuid; 1639 description "yang:uuid-str for TP"; 1640 } 1641 leaf name { 1642 type string {length "0..200";} 1643 description "Must abbey to name rule defined in system. 1644 Example FE0/0/1, GE1/2/1.1, Eth-Trunk1.1, etc"; 1645 } 1646 leaf description { 1647 type string {length "0..200";} 1648 description "description for this tp."; 1649 } 1651 leaf neID { 1652 type yang:uuid; 1653 description "yang:uuid-str for NE "; 1654 } 1656 leaf containingMainTPID { 1657 type yang:uuid; 1658 description "uuid-str for main interface"; 1659 } 1660 container tpBasicInfo { 1661 description "Tp non-instance basic info"; 1662 uses TPTypes:TPBasicInfo; 1663 } 1664 container peerCeTp { 1665 description "CE TP Information"; 1666 uses TPTypes:CeTp; 1667 } 1669 list routeProtocolSpec { 1670 key "type"; 1671 description "route protocol spec"; 1672 uses RouteProtocol:RouteProtocolSpec; 1673 } 1675 leaf operStatus { 1676 type CommonTypes:OperStatus; 1677 config false; 1678 description "Operational status." ; 1679 } 1680 } 1682 grouping TpInventory { 1683 description "inventory model of TP"; 1684 leaf tpID { 1685 type yang:uuid; 1686 description "uuid of tp"; 1687 } 1688 leaf detailType { 1689 type string {length "0..100";} 1690 description "tp detail type. reported by controller"; 1691 } 1692 leaf maxBandWidth { 1693 type uint64; 1694 description "max bandwidth"; 1695 } 1696 leaf-list potentialLayers { 1697 type CommonTypes:LayerRate; 1698 description "capability of tp to create VPN, reported by 1699 controller"; 1700 } 1701 } 1702 } 1703 1705 file "ietf-nvo-tp-types.yang" 1706 module ietf-nvo-tp-types { 1707 namespace "urn:ietf:params:xml:ns:yang:ietf-nvo-tp-types"; 1708 prefix TPTypes; 1710 import ietf-nvo-common-types {prefix CommonTypes;} 1711 import ietf-yang-types { prefix yang; } 1712 import ietf-nvo-qos-types { prefix QosTypes;} 1714 organization ""; 1715 contact ""; 1716 description "ietf-nvo-tp-types"; 1717 revision 2016-10-24 { 1718 reference "draft-chen-opsawg-composite-vpn-dm-00"; 1720 } 1722 //LayerRate parameters. 1723 grouping PwSpec { 1724 description "PwSpec Grouping."; 1726 leaf controlWord { 1727 type boolean; 1728 default false; 1729 description "controlWord"; 1730 } 1731 leaf pwVlanAction { 1732 type TPTypes:PWTagMode; 1733 description "pwVlanAction"; 1734 } 1735 } 1737 grouping IpSpec { 1738 description "IpSpec Grouping."; 1740 leaf masterIp { 1741 type string; 1742 description "master IP address"; 1743 } 1744 leaf mtu { 1745 type uint64; 1746 description "mtu for ip layer,scope:46~9600"; 1747 } 1748 } 1750 grouping EthernetSpec { 1751 description "EthernetSpec Grouping."; 1753 leaf accessType { 1754 type CommonTypes:EthernetEncapType; 1755 description "access frame type"; 1756 } 1758 choice accessVlanValue { 1759 description "accessVlanValue"; 1760 case QinQVlan { 1761 container qinqVlan { 1762 description "qinqVlan"; 1763 uses TPTypes:QinQVlan; 1764 } 1765 } 1766 case DOT1Q { 1767 container dot1q { 1768 description "dot1q"; 1769 uses TPTypes:Dot1QVlan; 1770 } 1771 } 1772 } 1774 leaf vlanAction { 1775 type CommonTypes:EthernetAction; 1776 description "Frame type that can be accepted. not needed 1777 now"; 1778 } 1780 leaf actionValue{ 1781 type string{length "0..100";} 1782 description "action value"; 1783 } 1784 } 1786 grouping QinQVlan { 1787 description "QinQVlan Grouping."; 1789 leaf-list cvlanList { 1790 type uint64; 1791 description "cvlanList"; 1792 } 1793 leaf svlanList { 1794 type uint64; 1795 description "svlanList"; 1796 } 1797 } 1799 grouping Dot1QVlan { 1800 description "Dot1QVlan Grouping."; 1802 leaf-list dot1qVlanList { 1803 type uint64; 1804 description "dot1qVlanList"; 1805 } 1806 } 1808 grouping VxlanSpec { 1809 description "VxlanSpec Grouping."; 1811 leaf vni { 1812 type uint32; 1813 description "vni"; 1814 } 1816 leaf vtepIP { 1817 type string; 1818 description "vtep ip"; 1819 } 1820 } 1822 //CE spec 1823 grouping CeTp { 1824 description "CeTp Grouping."; 1826 leaf ceID { 1827 type yang:uuid; 1828 description "Site router ID"; 1829 } 1831 leaf ceDirectNeID { 1832 type yang:uuid; 1833 description "direction connected NE ID, only valid in 1834 asbr "; 1835 } 1837 leaf ceDirectTPID { 1838 type yang:uuid; 1839 description "ce Direct TP id, only valid in asbr"; 1840 } 1842 leaf ceIfmasterIp { 1843 type string; 1844 description "ceIfmasterIp"; 1845 } 1847 leaf location { 1848 type string {length "0..400";} 1849 description "CE device location "; 1850 } 1851 } 1853 //TPBasicInfo 1854 grouping TPBasicInfo { 1855 description "TPBasicInfo Grouping."; 1857 leaf edgePointRole { 1858 type CommonTypes:EdgePointRole; 1859 description "edge role for TP, for example:UNI/NNI "; 1860 } 1861 leaf topologyRole { 1862 type CommonTypes:TopoNodeRole; 1863 description "hub/spoke role, etc"; 1864 } 1866 leaf Type 1867 { 1868 type CommonTypes:TpType; 1869 description "Type"; 1870 } 1872 leaf workingLayer { 1873 type CommonTypes:LayerRate; 1874 description "working layer"; 1875 } 1877 list typeSpecList { 1878 key "layerRate"; 1879 uses TPTypes:TpTypeSpec; 1880 description "typeSpecList"; 1881 } 1883 leaf adminStatus { 1884 type CommonTypes:AdminStatus; 1885 description "administrative status."; 1886 } 1888 container tpQosNode { 1889 description "tpQosNode"; 1890 uses QosTypes:TPQosNode; 1891 } 1893 container flowServices{ 1894 description "flow services in one TP"; 1895 uses QosTypes:FlowServices; 1896 } 1898 list addtionalInfo { 1899 key "name"; 1900 uses CommonTypes:nvstring; 1901 description "addtionalInfo"; 1902 } 1903 } 1905 //TpTypeSpec 1906 grouping TpTypeSpec{ 1907 description "TpTypeSpec Grouping."; 1908 leaf layerRate { 1909 type CommonTypes:LayerRate; 1910 description "layerRate"; 1911 } 1913 choice specValue { 1914 description "specValue"; 1915 case LR_Ethernet { 1916 container ethernetSpec { 1917 description "ethernetSpec"; 1918 uses TPTypes:EthernetSpec; 1919 } 1920 } 1921 case LR_IP { 1922 container ipSpec { 1923 description "ipSpec"; 1924 uses TPTypes:IpSpec; 1925 } 1926 } 1927 case LR_Vxlan { 1928 container vxlanSpec { 1929 description "vxlanSpec"; 1930 uses TPTypes:VxlanSpec; 1931 } 1932 } 1933 } 1934 } 1936 //----------------------------------------------// 1937 //typedef 1938 //----------------------------------------------// 1939 typedef PWTagMode { 1940 type enumeration { 1941 enum RAW{ 1942 description "RAW"; 1943 } 1944 enum TAGGED{ 1945 description "TAGGED"; 1946 } 1947 } 1948 description "PWTagMode"; 1949 } 1950 } 1951 1953 file "ietf-nvo-vpn-routeprotocol.yang" 1954 module ietf-nvo-vpn-routeprotocol { 1955 namespace "urn:ietf:params:xml:ns:yang:ietf-nvo-vpn-routeprotocol"; 1956 prefix RouteProtocol; 1957 import ietf-yang-types { prefix yang; } 1958 import ietf-nvo-common-types { 1959 prefix CommonTypes; 1960 } 1962 organization ""; 1963 contact ""; 1964 description "ietf-nvo-vpn-routeprotocol"; 1965 revision 2016-10-24 { 1966 reference "draft-chen-opsawg-composite-vpn-dm-00"; 1967 } 1969 grouping RouteProtocolSpec { 1970 description "RouteProtocolSpec Grouping."; 1972 leaf type { 1973 type CommonTypes:RouteProtocolType; 1974 description "Protocol type" ; 1975 } 1976 choice para { 1977 description "para" ; 1978 case staticRouting { 1979 list staticRouteItems { 1980 key "index"; 1981 uses RouteProtocol:StaticRouteItem; 1982 description "staticRouteItems" ; 1983 } 1984 } 1985 case bgp { 1986 list bgpProtocols { 1987 key "index"; 1988 uses RouteProtocol:BGPProtocolItem; 1989 description "bgpProtocols" ; 1990 } 1992 } 1993 } 1994 } 1996 grouping StaticRouteItem { 1997 description "StaticRouteItem Grouping."; 1999 leaf index { 2000 type uint32; 2001 description "static item index"; 2002 } 2003 leaf destinationCidr { 2004 type string; 2005 description "destination ip cidr. "; 2006 } 2007 leaf egressTP { 2008 type yang:uuid; 2009 description "egress tp"; 2010 } 2011 leaf routePreference { 2012 type string; 2013 description "route priority. Ordinary, work route have 2014 higher priority."; 2015 } 2016 leaf nextHopIp { 2017 type string {length "0..200";} 2018 description "nextHopIp"; 2019 } 2020 } 2022 grouping BGPProtocolItem { 2023 description "BGPProtocolItem Grouping."; 2025 leaf index { 2026 type uint32; 2027 description "index of BGP protocol item"; 2028 } 2029 leaf peerAsNumber { 2030 type uint64; 2031 description ""; 2032 } 2033 leaf bgpMaxPrefix { 2034 type int32; 2035 description ""; 2036 } 2037 leaf bgpMaxPrefixAlarm { 2038 type uint32; 2039 description "alarm threshold of BGP rout"; 2040 } 2041 leaf peerIp { 2042 type string; 2043 description "peerIp"; 2044 } 2045 } 2046 } 2047 2049 file "ietf-nvo-vpn-types.yang" 2050 module ietf-nvo-vpn-types { 2051 namespace "urn:ietf:params:xml:ns:yang:ietf-nvo-vpn-types" ; 2052 prefix VPNTypes ; 2054 import ietf-nvo-common-types { 2055 prefix CommonTypes; 2056 } 2058 organization ""; 2059 contact ""; 2060 description "ietf-nvo-vpn-types"; 2061 revision 2016-10-24 { 2062 reference "draft-chen-opsawg-composite-vpn-dm-00"; 2063 } 2065 typedef ProtectionRole { 2066 type enumeration { 2067 enum NOP{ 2068 description "NOP"; 2069 } 2070 enum MAIN{ 2071 description "MAIN"; 2072 } 2073 } 2074 description "ProtectionRole"; 2075 } 2077 grouping VPNBasicInfo { 2078 description "VPNBasicInfo Grouping."; 2080 leaf topology { 2081 type CommonTypes:Topology; 2082 description "current support for full-mesh and 2083 point_to_multipoint(hub-spoke), others is reserved for 2084 future extensions." ; 2085 } 2087 leaf serviceType { 2088 type VPNTypes:ServiceType; 2089 description "current support for mpls l3vpn/vxlan/L2VPN 2090 overlay, others is reserved for future extensions." ; 2091 } 2093 leaf technology { 2094 type VPNTypes:VPNTunnelType; 2095 description "mpls|vxlan overlay l3vpn|eth over sdh|nop"; 2096 } 2098 leaf adminStatus { 2099 type CommonTypes:AdminStatus; 2100 description "administrative status." ; 2101 } 2102 } 2104 typedef VPNTunnelType { 2105 type enumeration { 2106 enum NOP{ 2107 description "NOP"; 2108 } 2109 enum MPLS{ 2110 description "MPLS"; 2111 } 2112 enum MPLS-TP{ 2113 description "MPLS-TP"; 2114 } 2115 } 2116 description "VPNTunnelType"; 2117 } 2119 typedef ServiceType { 2120 type enumeration { 2121 enum l3vpn { 2122 description "l3vpn" ; 2123 } 2124 enum l2vpn { 2125 description "l2vpn" ; 2126 } 2127 } 2128 description "ServiceType"; 2129 } 2130 } 2131 2133 7. IANA Considerations 2135 TBD 2137 8. Security Considerations 2139 TBD 2141 9. Acknowledgements 2143 TBD 2145 10. References 2147 10.1. Normative References 2149 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2150 Requirement Levels", BCP 14, RFC 2119, 2151 DOI 10.17487/RFC2119, March 1997, 2152 . 2154 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 2155 Provider-Provisioned Virtual Private Networks (PPVPNs)", 2156 RFC 4110, DOI 10.17487/RFC4110, July 2005, 2157 . 2159 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2160 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2161 . 2163 10.2. Informative References 2165 [I-D.ietf-l3sm-l3vpn-service-model] 2166 Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 2167 Model for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 2168 service-model-18 (work in progress), October 2016. 2170 [I-D.wu-opsawg-service-model-explained] 2171 Wu, Q., LIU, S., and A. Farrel, "Service Models 2172 Explained", draft-wu-opsawg-service-model-explained-03 2173 (work in progress), September 2016. 2175 Authors' Addresses 2177 Rui Chen 2178 Huawei Technologies 2179 Bantian, Longgang District 2180 Shenzhen 518129 2181 China 2183 Email: chenrui@huawei.com 2185 Liya Zhang 2186 Huawei Technologies 2187 Wuhan 2188 China 2190 Email: zhangliya@huawei.com 2191 Hui Deng 2192 Huawei Technologies 2193 Beijing 2194 China 2196 Email: denghui02@hotmail.com 2198 Liang Geng 2199 China Mobile 2200 No.32 Xuanwumen West Street 2201 Beijing 100053 2202 China 2204 Email: liang.geng@hotmail.com 2206 Chongfeng Xie 2207 China Telecom 2208 Beijing 2209 China 2211 Email: xiechf@ctbri.com.cn