idnits 2.17.1 draft-shah-pals-mpls-l2vpn-yang-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 357 has weird spacing: '...rw name str...' == Line 364 has weird spacing: '...ng-type l2v...' == Line 369 has weird spacing: '...t-value str...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PALS Working Group H. Shah 3 Internet-Draft Ciena Corporation 4 Intended status: Standards Track P. Brissette 5 Expires: January 7, 2016 R. Rahman 6 K. Raza 7 Cisco Systems, Inc. 8 Z. Li 9 Z. Shunwan 10 W. Haibo 11 Huawei Technologies 12 I. Chen 13 Ericsson 14 M. Bocci 15 Alcatel-Lucent 16 J. Hardwick 17 Metaswitch 18 S. Esale 19 Junipr Networks 20 K. Tiruveedhula 21 T. Singh 22 Juniper Networks 23 I. Hussain 24 Infinera Corporation 25 B. Wen 26 J. Walker 27 Comcast 28 N. Delregno 29 L. Jalil 30 M. Joecylyn 31 Verizon 32 July 06, 2015 34 YANG Data Model for MPLS-based L2VPN 35 draft-shah-pals-mpls-l2vpn-yang-00.txt 37 Abstract 39 This document describes a YANG data model for Layer 2 VPN services 40 over MPLS networks. These services include Virtual Private Wire 41 Service (VPWS), Virtual Private LAN service (VPLS) and Ethernet 42 Virtual Private Service (EVPN) that uses LDP and BGP signaled 43 Pseudowires. This document mainly focuses on L2VPN VPWS, other 44 services are for future investigations. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on January 7, 2016. 63 Copyright Notice 65 Copyright (c) 2015 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 82 3. L2VPN YANG Model . . . . . . . . . . . . . . . . . . . . . . 4 83 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 84 3.2. L2VPN Common . . . . . . . . . . . . . . . . . . . . . . 6 85 3.2.1. ac-templates . . . . . . . . . . . . . . . . . . . . 7 86 3.2.2. pw-templates . . . . . . . . . . . . . . . . . . . . 7 87 3.3. VPWS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 3.3.1. ac list . . . . . . . . . . . . . . . . . . . . . . . 7 89 3.3.2. pw list . . . . . . . . . . . . . . . . . . . . . . . 7 90 3.3.3. redundancy-grp choice . . . . . . . . . . . . . . . . 7 91 3.3.4. endpoint container . . . . . . . . . . . . . . . . . 8 92 3.3.5. vpws-instances container . . . . . . . . . . . . . . 8 93 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 96 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 99 8.2. Informative References . . . . . . . . . . . . . . . . . 23 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 The Network Configuration Protocol (NETCONF) [RFC6241] is a network 105 management protocol that defines mechanisms to manage network 106 devices. YANG [RFC6020] is a modular language that represents data 107 structures in an XML or JSON tree format, and is used as a data 108 modeling language for the NETCONF. 110 This document introduces a YANG data model for MPLS based Layer 2 VPN 111 services (L2VPN) [RFC4664] as well as switching between the local 112 attachment circuits. The L2VPN services include point-to-point VPWS 113 and Multipoint VPLS and EVPN services. These services are realized 114 by signaling Pseudowires across MPLS networks using LDP 115 [RFC4447][RFC4762] or BGP[RFC4761]. 117 The Yang data model in this document defines Ethernet based Layer 2 118 services. Other Layer 2 services, such as ATM, Frame Relay, TDM, etc 119 are included in the scope but will be covered as the future work 120 items. The Ethernet based Layer 2 services will leverage the 121 definitions used in other standards organizations such as IEEE 802.1 122 and Metro Ethernet Forum (MEF). 124 The goal is to propose a data object model consisting of building 125 blocks that can be assembled in different order to realize different 126 services. The definition work is undertaken initially by a smaller 127 working group with members representing various vendors and service 128 providers. The VPWS service definitions are covered first followed 129 by VPLS services that build on the data blocks defined for VPWS. 131 The data model is defined for following constructs that are used for 132 managing the services: 134 o Configuration 136 o Operational State 138 o Executables (Actions) 140 o Notifications 141 The document is organized to first define the data model for the 142 configuration, operational state, actions and notifications of VPWS. 143 The L2VPN data object model defined in this document uses the 144 instance centric approach whereby VPWS service attributes are 145 specified for a given VPWS instance. 147 2. Specification of Requirements 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 3. L2VPN YANG Model 155 3.1. Overview 157 One single top level container, mpls-l2vpn, is defined as a parent 158 for three different second level containers that are vpws-instances, 159 vpls-instances, and common building blocks of AC-templates(Attachment 160 Circuit templates) and pseudowire-templates. This document defines 161 the vpws-instances and templates for AC and Pseudowires. The 162 definition of vpls-instances and evpn-instances is left for future 163 revisions. 165 The L2VPN services have been defined in the IETF L2VPN working group 166 but leverages the pseudowire technologies that were defined in the 167 PWE3 working group. A large number of RFCs from these working groups 168 cover this subject matter. Hence, it is prudent that this document 169 state the scope of the MPLS L2VPN object model definitions. 171 The following documents are within the scope. This is not an 172 exhaustive list but a representation of documents that are covered 173 for this work: 175 o Requirements for Pseudo-wire Emulation Edge-to-Edge (PWE3) 176 [RFC3916] 178 o Pseudo-wire Emulation Edge-to-Edge (PWE3) Architecture [RFC3985] 180 o IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) 181 [RFC4446] 183 o Pseudowire Setup and Maintenance Using the Label Distribution 184 Protocol (LDP) [RFC4447] 186 o Encapsulation Methods for Transport of Ethernet over MPLS Networks 187 [RFC4448] 189 o Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over 190 an MPLS PSN [RFC4385] 192 o Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge 193 (PWE3) [RFC5254] 195 o An Architecture for Multi-Segment Pseudowire Emulation Edge-to- 196 Edge [RFC5659] 198 o Segmented Pseudowire [RFC6073] 200 o Framework for Layer 2 Virtual Private Networks [RFC4664] 202 o Service Requirements for Layer 2 Provider-Provisioned Virtual 203 Private Networks [RFC4665] 205 o Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery 206 and Signaling [RFC4761] 208 o Virtual Private LAN Service (VPLS) Using Label Distribution 209 Protocol (LDP) Signaling [RFC4762] 211 o Attachment Individual Identifier (AII) Types for Aggregation 212 [RFC5003] 214 o Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual 215 Private Networks (L2VPNs) [RFC6074] 217 o Flow-Aware Transport of Pseudowires over an MPLS Packet Switched 218 Network [RFC6391] 220 o Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and 221 Signaling [RFC6624] 223 o Extensions to the Virtual Private LAN Service (VPLS) Provider Edge 224 (PE) Model for Provider Backbone Bridging [RFC7041] 226 o LDP Extensions for Optimized MAC Address Withdrawal in a 227 Hierarchical Virtual Private LAN Service (H-VPLS) [RFC7361] 229 o Using the generic associated channel label for Pseudowire in the 230 MPLS Transport Profile [RFC6423] 232 o Pseudowire status for static pseudowire [RFC6478] 234 Note that while pseudowire over MPLS-TP related work is in scope, the 235 initial effort will only address definitions of object model for VPWS 236 services that are commonly deployed. 238 The ietf work in L2VPN and PWE3 working group relating to L2TP, OAM, 239 multicast (e.g. p2mp, etree, etc) and access specific protocols such 240 as G.8032, MSTP, etc is out-of-scope for this document. 242 The following is the high level view of the L2VPN data model. 244 template-ref AC // AC 245 template 246 attributes 248 template-ref PW // PW 249 template 250 attributes 252 vpws-instance name // container 254 svc-type 256 // list of AC and PW being used 257 AC-1 // container 258 template-ref AC 259 attribute-override 260 PW-2 // container 261 template-ref PW 262 attribute-override 263 PW-3 // container 264 template-ref PW 265 attribute-override 267 // ONLY 2 endpoints!!! 268 endpoint-A // container 269 AC-1 // reference 271 endpoint-Z // container 272 redundancy-grp // container 273 PW-2 // reference 274 PW-3 // reference 276 Figure 1 278 3.2. L2VPN Common 279 3.2.1. ac-templates 281 The ac-templates container contains a list of ac-template. Each ac- 282 template defines a list of AC attributes that are part of native 283 services but associated and processed within the context of L2VPN. 284 For instance, Ethernet VLAN tag imposition, disposition and 285 translation or CVID-bundling would be part of this template. 287 3.2.2. pw-templates 289 The pw-templates container contains a list of pw-template. Each pw- 290 template defines a list of common pseudowire attributes such as PW 291 MTU, control word support etc. 293 3.3. VPWS 295 3.3.1. ac list 297 Each VPWS instance defines a list of AC which are cross-connected by 298 the service. Each entry of the AC consists of one ac-template with 299 predefined attributes and values, but also defines attributes that 300 override the attributes defined in referenced ac-template. 302 3.3.2. pw list 304 Each VPWS instance defines a list of PW which are cross-connected by 305 the service. Each entry of the PW consists of one pw-template with 306 pre-defined attributes and values, but also defines attributes that 307 override those defined in referenced pw-template. No restrictions 308 are placed on type of signaling (i.e. LDP or BGP) used for a given 309 PW. It is entirely possible to define two PWs, one signaled by LDP 310 and other by BGP. 312 3.3.3. redundancy-grp choice 314 The redundancy-grp is a generic redundancy construct which can hold 315 primary and backup members of AC and PWs. This flexibility permits 316 combinations of - 318 o primary and backup AC 320 o primary and backup PW 322 o primary AC and backup PW 324 o primary PW and backup AC 326 3.3.4. endpoint container 328 The endpoint container holds AC, PW or redundancy-grp references. 329 The core aspect of endpoint container is its flexible personality 330 based on what user decides to include in it. It is future-proofed 331 with possible extensions that can be included in the endpoint 332 container such as Integrated Route Bridging (IRB), PW Headend, 333 Virtual Switch Instance, etc. 335 3.3.5. vpws-instances container 337 The vpws-instances container contains a list of vpws-instance. Each 338 entry of the vpws-instance represents a layer-2 cross-connection of 339 two endpoints. This model defines three possible types of endpoints, 340 ac, pw, and redundancy-grp, and allows a vpws-instance to cross- 341 connect any one type of endpoint to all other types of endpoint. 343 The augmentation of ietf-mpls-l2vpn module is TBD. All IP addresses 344 defined in this module are currently scoped under global VRF/table. 346 module: ietf-mpls-l2vpn 347 +--rw mpls-l2vpn 348 +--rw common 349 | +--rw pw-templates 350 | | +--rw pw-template* [name] 351 | | +--rw name string 352 | | +--rw mtu? uint32 353 | | +--rw cw-negotiation? cw-negotiation-type 354 | | +--rw tunnel-policy? string 355 | +--rw ac-templates 356 | +--rw ac-template* [name] 357 | +--rw name string 358 +--rw vpws-instances 359 | +--rw vpws-instance* [instance-name] 360 | +--rw instance-name string 361 | +--rw description? string 362 | +--rw service-type? l2vpn-service-type 363 | +--rw discovery-type? l2vpn-discovery-type 364 | +--rw signaling-type l2vpn-signaling-type 365 | +--rw bgp-parameters 366 | | +--rw common 367 | | | +--rw route-distinguisher? string 368 | | | +--rw vpn-targets* [rt-value] 369 | | | +--rw rt-value string 370 | | | +--rw rt-type bgp-rt-type 371 | | +--rw discovery 372 | | | +--rw vpn-id? string 373 | | +--rw signaling 374 | | +--rw site-id? uint16 375 | | +--rw site-range? uint16 376 | +--rw pw* [name] 377 | | +--rw name string 378 | | +--rw cw-negotiation? cw-negotiation-type 379 | | +--rw template? pw-template-ref 380 | | +--rw vccv-ability? boolean 381 | | +--rw tunnel-policy? string 382 | | +--rw request-vlanid? uint16 383 | | +--rw vlan-tpid? string 384 | | +--rw ttl? uint8 385 | | +--rw (pw-type)? 386 | | +--:(ldp-pw) 387 | | | +--rw peer-ip? inet:ip-address 388 | | | +--rw pw-id? uint32 389 | | | +--rw transmit-label? uint32 390 | | | +--rw receive-label? uint32 391 | | | +--rw icb? boolean 392 | | +--:(bgp-pw) 393 | | | +--rw remote-pe-id? inet:ip-address 394 | | +--:(bgp-ad-pw) 395 | | +--rw remote-ve-id? uint16 396 | +--rw ac* [name] 397 | | +--rw name string 398 | | +--rw template? ac-template-ref 399 | | +--rw pipe-mode? enumeration 400 | | +--rw link-discovery-protocol? link-discovery-protocol-type 401 | +--rw endpoint-a 402 | | +--rw (ac-or-pw-or-redundancy-grp)? 403 | | +--:(ac) 404 | | | +--rw ac? -> ../../ac/name 405 | | +--:(pw) 406 | | | +--rw pw? -> ../../pw/name 407 | | +--:(redundancy-grp) 408 | | | +--rw (primary) 409 | | | | +--:(primary-pw) 410 | | | | | +--rw primary-pw? -> ../../pw/name 411 | | | | +--:(primary-ac) 412 | | | | +--rw primary-ac? -> ../../ac/name 413 | | | +--rw (backup) 414 | | | | +--:(backup-pw) 415 | | | | | +--rw backup-pw? -> ../../pw/name 416 | | | | +--:(backup-ac) 417 | | | | +--rw backup-ac? -> ../../ac/name 418 | | | +--rw protection-mode? enumeration 419 | | +--:(reroute-mode) 420 | | | +--rw reroute-mode? enumeration 421 | | +--:(reroute-delay) 422 | | | +--rw reroute-delay? uint16 423 | | +--:(dual-receive) 424 | | | +--rw dual-receive? boolean 425 | | +--:(revert) 426 | | | +--rw revert? boolean 427 | | +--:(revert-delay) 428 | | +--rw revert-delay? uint16 429 | +--rw endpoint-z 430 | +--rw (ac-or-pw-or-redundancy-grp)? 431 | +--:(ac) 432 | | +--rw ac? -> ../../ac/name 433 | +--:(pw) 434 | | +--rw pw? -> ../../pw/name 435 | +--:(redundancy-grp) 436 | | +--rw (primary) 437 | | | +--:(primary-pw) 438 | | | | +--rw primary-pw? -> ../../pw/name 439 | | | +--:(primary-ac) 440 | | | +--rw primary-ac? -> ../../ac/name 441 | | +--rw (backup) 442 | | | +--:(backup-pw) 443 | | | | +--rw backup-pw? -> ../../pw/name 444 | | | +--:(backup-ac) 445 | | | +--rw backup-ac? -> ../../ac/name 446 | | +--rw protection-mode? enumeration 447 | +--:(reroute-mode) 448 | | +--rw reroute-mode? enumeration 449 | +--:(reroute-delay) 450 | | +--rw reroute-delay? uint16 451 | +--:(dual-receive) 452 | | +--rw dual-receive? boolean 453 | +--:(revert) 454 | | +--rw revert? boolean 455 | +--:(revert-delay) 456 | +--rw revert-delay? uint16 457 +--rw vpls-instances 459 Figure 2 461 4. YANG Module 463 The L2VPN configuration container is logically divided into following 464 high level config areas: 466 file "ietf-mpls-l2vpn@2015-06-30.yang" 467 module ietf-mpls-l2vpn { 468 namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-l2vpn"; 469 prefix "mpls-l2vpn"; 471 import ietf-inet-types { 472 prefix "inet"; 473 } 475 organization "ietf"; 476 contact "ietf"; 477 description "mpls-l2vpn"; 478 revision "2015-06-30" { 479 description "Initial revision"; 480 reference ""; 481 } 483 /* identities */ 485 identity link-discovery-protocol { 486 description "Base identiy from which identities describing " + 487 "link discovery protocols are derived."; 488 } 490 identity lacp { 491 base "link-discovery-protocol"; 492 description "This identity represents LACP"; 493 } 495 identity lldp { 496 base "link-discovery-protocol"; 497 description "This identity represents LLDP"; 498 } 500 identity bpdu { 501 base "link-discovery-protocol"; 502 description "This identity represens BPDU"; 503 } 505 identity cpd { 506 base "link-discovery-protocol"; 507 description "This identity represents CPD"; 508 } 510 identity udld { 511 base "link-discovery-protocol"; 512 description "This identity represens UDLD"; 513 } 514 /* typedefs */ 516 typedef l2vpn-service-type { 517 type enumeration { 518 enum ethernet { 519 description "Ethernet service"; 520 } 521 enum ATM { 522 description "Asynchronous Transfer Mode"; 523 } 524 enum FR { 525 description "Frame-Relay"; 526 } 527 enum TDM { 528 description "Time Division Multiplexing"; 529 } 530 } 531 description "L2VPN service type"; 532 } 534 typedef l2vpn-discovery-type { 535 type enumeration { 536 enum manual { 537 description "Manual configuration"; 538 } 539 enum bgp-ad { 540 description "Border Gateway Protocol (BGP) auto-discovery"; 541 } 542 } 543 description "L2VPN discovery type"; 544 } 546 typedef l2vpn-signaling-type { 547 type enumeration { 548 enum static { 549 description "Static configuration of labels (no signaling)"; 550 } 551 enum ldp { 552 description "Label Distribution Protocol (LDP) signaling"; 553 } 554 enum bgp { 555 description "Border Gateway Protocol (BGP) signaling"; 556 } 557 } 558 description "L2VPN signaling type"; 559 } 561 typedef bgp-rt-type { 562 type enumeration { 563 enum import { 564 description "For import"; 565 } 566 enum export { 567 description "For export"; 568 } 569 enum both { 570 description "For both import and export"; 571 } 572 } 573 description "BGP route-target type. Import from BGP YANG"; 574 } 576 typedef cw-negotiation-type { 577 type enumeration { 578 enum "non-preferred" { 579 description "No preference for control-word"; 580 } 581 enum "preferred" { 582 description "Prefer to have control-word negotiation"; 583 } 584 } 585 description "control-word negotiation preference type"; 586 } 588 typedef link-discovery-protocol-type { 589 type identityref { 590 base "link-discovery-protocol"; 591 } 592 description "This type is used to identify " + 593 "link discovery protocol"; 594 } 596 typedef pw-template-ref { 597 type leafref { 598 path "/l2vpn/common/pw-templates/pw-template/name"; 599 } 600 description "pw-template-ref"; 601 } 603 typedef ac-template-ref { 604 type leafref { 605 path "/l2vpn/common/ac-templates/ac-template/name"; 606 } 607 description "ac-tempalte-ref"; 608 } 609 /* groupings */ 611 grouping vpws-endpoint { 612 description 613 "A vpws-endpoing could either be an ac or a pw"; 614 choice ac-or-pw-or-redundancy-grp { 615 description "A choice ofattachment circuit or " + 616 "pseudowire or redundancy group"; 617 case ac { 618 leaf ac { 619 type leafref { 620 path "../../ac/name"; 621 } 622 description "reference to an attachment circuit"; 623 } 624 } 625 case pw { 626 leaf pw { 627 type leafref { 628 path "../../pw/name"; 629 } 630 description "reference to a pseudowire"; 631 } 632 } 633 case redundancy-grp { 634 choice primary { 635 mandatory true; 636 description "primary options"; 637 case primary-pw { 638 leaf primary-pw { 639 type leafref { 640 path "../../pw/name"; 641 } 642 description "primary pseudowire"; 643 } 644 } 645 case primary-ac { 646 leaf primary-ac { 647 type leafref { 648 path "../../ac/name"; 649 } 650 description "primary attachment circuit"; 651 } 652 } 653 } 654 choice backup { 655 mandatory true; 656 description "backup options"; 657 case backup-pw { 658 leaf backup-pw { 659 type leafref { 660 path "../../pw/name"; 661 } 662 description "backup pseudowire"; 663 } 664 } 665 case backup-ac { 666 leaf backup-ac { 667 type leafref { 668 path "../../ac/name"; 669 } 670 description "backup attachment circuit"; 671 } 672 } 673 } 674 leaf protection-mode { 675 type enumeration { 676 enum "frr" { 677 value 0; 678 description "fast reroute"; 679 } 680 enum "master-slave" { 681 value 1; 682 description "master-slave"; 683 } 684 enum "independent" { 685 value 2; 686 description "independent"; 687 } 688 } 689 description "protection-mode"; 690 } 691 } 692 leaf reroute-mode { 693 type enumeration { 694 enum "immediate" { 695 value 0; 696 description "immediate reroute"; 697 } 698 enum "delayed" { 699 value 1; 700 description "delayed reroute"; 701 } 702 enum "never" { 703 value 2; 704 description "never reroute"; 706 } 707 } 708 description "reroute-mode"; 709 } 710 leaf reroute-delay { 711 when "../reroute-mode = 'delayed'" { 712 description 713 "Specify amount of time to delay reroute " + 714 "only when delayed route is configured"; 715 } 716 type uint16; 717 description 718 "amount of time to delay reroute"; 719 } 720 leaf dual-receive { 721 type boolean; 722 description 723 "allow extra traffic to be carried by backup"; 724 } 725 leaf revert { 726 type boolean; 727 description 728 "allow forwarding to revert to primary " + 729 "after restoring primary"; 730 /* This is called "revertive" during the discussion. */ 731 } 732 leaf revert-delay { 733 when "../revert = 'true'" { 734 description 735 "Specify the amount of time to wait to revert " + 736 "to primary only if reversion is configured"; 737 } 738 type uint16; 739 description 740 "amount ot time to wait to revert to primary"; 741 /* This is called "wtr" during discussion. */ 742 } 743 } 744 } 746 /* We can define vpls-endpoing-grp that has the same structure as 747 * vpws-endpoing-grp, but has more endpoint options. 748 */ 750 /* L2VPN YANG Model */ 752 container l2vpn { 753 description "l2vpn"; 754 container common { 755 description "common l2pn attributes"; 756 container pw-templates { 757 description "pw-templates"; 758 list pw-template { 759 key "name"; 760 description "pw-template"; 761 leaf name { 762 type string; 763 description "name"; 764 } 765 leaf mtu { 766 type uint32; 767 description "pseudowire mtu"; 768 } 769 leaf cw-negotiation { 770 type cw-negotiation-type; 771 default "preferred"; 772 description 773 "control-word negotiation preference"; 774 } 775 leaf tunnel-policy { 776 type string; 777 description "tunnel policy name"; 778 } 779 } 780 } 781 container ac-templates { 782 description "attachment circuit templates"; 783 /* To be fleshed out in future revisions */ 784 list ac-template { 785 key "name"; 786 description "ac-template"; 787 leaf name { 788 type string; 789 description "name"; 790 } 791 } 792 } 793 } 794 container vpws-instances { 795 description "vpws-instances"; 796 list vpws-instance { 797 key "instance-name"; 798 description "A VPWS instance"; 799 leaf instance-name { 800 type string; 801 description "Name of VPWS instance"; 803 } 804 leaf description { 805 type string; 806 description "Description of the VPWS instance"; 807 } 808 leaf service-type { 809 type l2vpn-service-type; 810 default ethernet; 811 description "VPWS service type"; 812 } 813 leaf discovery-type { 814 type l2vpn-discovery-type; 815 default manual; 816 description "VPWS discovery type"; 817 } 818 leaf signaling-type { 819 type l2vpn-signaling-type; 820 mandatory true; 821 description "VPWS signaling type"; 822 } 823 container bgp-parameters { 824 description "Parameters for BGP"; 825 container common { 826 when "../../discovery-type = 'bgp-ad'" { 827 description "Check discovery type: " + 828 "Can only configure BGP discovery if " + 829 "discovery type is BGP-AD"; 830 } 831 description "Common BGP parameters"; 832 leaf route-distinguisher { 833 type string; 834 description "BGP RD"; 835 } 836 list vpn-targets { 837 key rt-value; 838 description "Route Targets"; 839 leaf rt-value { 840 type string; 841 description "Route-Target value"; 842 } 843 leaf rt-type { 844 type bgp-rt-type; 845 mandatory true; 846 description "Type of RT"; 847 } 848 } 849 } 850 container discovery { 851 when "../../discovery-type = 'bgp-ad'" { 852 description "BGP parameters for discovery: " + 853 "Can only configure BGP discovery if " + 854 "discovery type is BGP-AD"; 855 } 856 description "BGP parameters for discovery"; 857 leaf vpn-id { 858 type string; 859 description "VPN ID"; 860 } 861 } 862 container signaling { 863 when "../../signaling-type = 'bgp'" { 864 description "Check signaling type: " + 865 "Can only configure BGP signaling if " + 866 "signaling type is BGP"; 867 } 868 description "BGP parameters for signaling"; 869 leaf site-id { 870 type uint16; 871 description "Site ID"; 872 } 873 leaf site-range { 874 type uint16; 875 description "Site Range"; 876 } 877 } 878 } 879 list pw { 880 key "name"; 881 description "pseudowire"; 882 leaf name { 883 type string; 884 description "pseudowire name"; 885 } 886 leaf cw-negotiation { 887 type cw-negotiation-type; 888 default "preferred"; 889 description "Override the control-word negotiation " + 890 "preference specified in the " + 891 "pseudowire template."; 892 } 893 leaf template { 894 type pw-template-ref; 895 description "pseudowire template"; 896 } 897 leaf vccv-ability { 898 type boolean; 899 description "vccvability"; 900 } 901 leaf tunnel-policy { 902 type string; 903 description "Used to override the tunnel policy name " + 904 "specified in the pseduowire template"; 905 } 906 leaf request-vlanid { 907 type uint16; 908 description "request vlanid"; 909 } 910 leaf vlan-tpid { 911 type string; 912 description "vlan tpid"; 913 } 914 leaf ttl { 915 type uint8; 916 description "time-to-live"; 917 } 918 choice pw-type { 919 description "A choice of pseudowire type"; 920 case ldp-pw { 921 leaf peer-ip { 922 type inet:ip-address; 923 description "peer IP address"; 924 } 925 leaf pw-id { 926 type uint32; 927 description "pseudowire id"; 928 } 929 leaf transmit-label { 930 type uint32; 931 description "transmit lable"; 932 } 933 leaf receive-label { 934 type uint32; 935 description "receive label"; 936 } 937 leaf icb { 938 type boolean; 939 description "inter-chassis backup"; 940 } 941 } 942 case bgp-pw { 943 leaf remote-pe-id { 944 type inet:ip-address; 945 description "remote pe id"; 946 } 948 } 949 case bgp-ad-pw { 950 leaf remote-ve-id { 951 type uint16; 952 description "remote ve id"; 953 } 954 } 955 } 956 } 957 list ac { 958 key "name"; 959 description "attachment circuit"; 960 leaf name { 961 type string; 962 description "name"; 963 } 964 leaf template { 965 type ac-template-ref; 966 description "attachment circuit template"; 967 } 968 leaf pipe-mode { 969 type enumeration { 970 enum "pipe" { 971 value 0; 972 description "regular pipe mode"; 973 } 974 enum "short-pipe" { 975 value 1; 976 description "short pipe mode"; 977 } 978 enum "uniform" { 979 value 2; 980 description "uniform pipe mode"; 981 } 982 } 983 description "pipe mode"; 984 } 985 leaf link-discovery-protocol { 986 type link-discovery-protocol-type; 987 description "link discovery protocol"; 988 } 989 } 990 container endpoint-a { 991 description "endpoint-a"; 992 uses vpws-endpoint; 993 } 994 container endpoint-z { 995 description "endpoint-z"; 996 uses vpws-endpoint; 997 } 998 } 999 } 1000 container vpls-instances { 1001 /* To be fleshed out in future revisions */ 1002 description "vpls-instances"; 1003 } 1004 } 1005 } 1007 1009 Figure 3 1011 5. Security Considerations 1013 The configuration, state, action and notification data defined in 1014 this document are designed to be accessed via the NETCONF protocol 1015 [RFC6241]. The lowest NETCONF layer is the secure transport layer 1016 and the mandatory-to-implement secure transport is SSH [RFC6242]. 1017 The NETCONF access control model [RFC6536] provides means to restrict 1018 access for particular NETCONF users to a pre-configured subset of all 1019 available NETCONF protocol operations and content. 1021 The security concerns listed above are, however, no different than 1022 faced by other routing protocols. Hence, this draft does not change 1023 any underlying security issues inherent in [I-D.ietf-netmod-routing- 1024 cfg] 1026 6. IANA Considerations 1028 None. 1030 7. Acknowledgments 1032 The authors would like to acknowledge TBD for their useful comments. 1034 8. References 1036 8.1. Normative References 1038 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1039 Requirement Levels", BCP 14, RFC 2119, March 1997. 1041 8.2. Informative References 1043 [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for 1044 Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, 1045 September 2004. 1047 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1048 Edge (PWE3) Architecture", RFC 3985, March 2005. 1050 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1051 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1052 Use over an MPLS PSN", RFC 4385, February 2006. 1054 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1055 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1057 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1058 Heron, "Pseudowire Setup and Maintenance Using the Label 1059 Distribution Protocol (LDP)", RFC 4447, April 2006. 1061 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 1062 "Encapsulation Methods for Transport of Ethernet over MPLS 1063 Networks", RFC 4448, April 2006. 1065 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 1066 Private Networks (L2VPNs)", RFC 4664, September 2006. 1068 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for 1069 Layer 2 Provider-Provisioned Virtual Private Networks", 1070 RFC 4665, September 2006. 1072 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1073 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 1074 4761, January 2007. 1076 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 1077 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 1078 RFC 4762, January 2007. 1080 [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, 1081 "Attachment Individual Identifier (AII) Types for 1082 Aggregation", RFC 5003, September 2007. 1084 [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for 1085 Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", 1086 RFC 5254, October 2008. 1088 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1089 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1090 October 2009. 1092 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1093 Network Configuration Protocol (NETCONF)", RFC 6020, 1094 October 2010. 1096 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1097 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 1099 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 1100 "Provisioning, Auto-Discovery, and Signaling in Layer 2 1101 Virtual Private Networks (L2VPNs)", RFC 6074, January 1102 2011. 1104 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1105 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1106 6241, June 2011. 1108 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1109 Shell (SSH)", RFC 6242, June 2011. 1111 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 1112 J., and S. Amante, "Flow-Aware Transport of Pseudowires 1113 over an MPLS Packet Switched Network", RFC 6391, November 1114 2011. 1116 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 1117 Generic Associated Channel Label for Pseudowire in the 1118 MPLS Transport Profile (MPLS-TP)", RFC 6423, November 1119 2011. 1121 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 1122 "Pseudowire Status for Static Pseudowires", RFC 6478, May 1123 2012. 1125 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1126 Protocol (NETCONF) Access Control Model", RFC 6536, March 1127 2012. 1129 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 1130 Virtual Private Networks Using BGP for Auto-Discovery and 1131 Signaling", RFC 6624, May 2012. 1133 [RFC7041] Balus, F., Sajassi, A., and N. Bitar, "Extensions to the 1134 Virtual Private LAN Service (VPLS) Provider Edge (PE) 1135 Model for Provider Backbone Bridging", RFC 7041, November 1136 2013. 1138 [RFC7361] Dutta, P., Balus, F., Stokes, O., Calvignac, G., and D. 1139 Fedyk, "LDP Extensions for Optimized MAC Address 1140 Withdrawal in a Hierarchical Virtual Private LAN Service 1141 (H-VPLS)", RFC 7361, September 2014. 1143 Authors' Addresses 1145 Himanshu Shah 1146 Ciena Corporation 1148 Email: hshah@ciena.com 1150 Patrice Brissette 1151 Cisco Systems, Inc. 1153 Email: pbrisset@cisco.com 1155 Reshad Rahman 1156 Cisco Systems, Inc. 1158 Email: rrahman@cisco.com 1159 Kamran Raza 1160 Cisco Systems, Inc. 1162 Email: skraza@cisco.com 1164 Zhenbin Li 1165 Huawei Technologies 1167 Email: lizhenbin@huawei.com 1169 Zhuang Shunwan 1170 Huawei Technologies 1172 Email: Zhuangshunwan@huawei.com 1174 Wang Haibo 1175 Huawei Technologies 1177 Email: rainsword.wang@huawei.com 1179 Ing-When Chen 1180 Ericsson 1182 Email: ing-wher.chen@ericsson.com 1184 Mathew Bocci 1185 Alcatel-Lucent 1187 Email: mathew.bocci@alcatel-lucent.com 1189 Jonathan Hardwick 1190 Metaswitch 1192 Email: jonathan.hardwick@metaswitch.com 1194 Santosh Esale 1195 Junipr Networks 1197 Email: sesale@juniper.net 1198 Kishore Tiruveedhula 1199 Juniper Networks 1201 Email: kishoret@juniper.net 1203 Tapraj Singh 1204 Juniper Networks 1206 Email: tsingh@juniper.net 1208 Iftekar Hussain 1209 Infinera Corporation 1211 Email: ihussain@infinera.com 1213 Bin Wen 1214 Comcast 1216 Email: Bin_Wen@cable.comcast.com 1218 Jason Walker 1219 Comcast 1221 Email: jason_walker2@cable.comcast.com 1223 Nick Delregno 1224 Verizon 1226 Email: nick.deregno@verizon.com 1228 Luay Jalil 1229 Verizon 1231 Email: luay.jalil@verizon.com 1233 Maria Joecylyn 1234 Verizon 1236 Email: joecylyn.malit@verizon.com