idnits 2.17.1 draft-ietf-bess-l3vpn-yang-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 233 has weird spacing: '...et-type rt-...' == Line 486 has weird spacing: '...rouping vpn-p...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2017) is 2354 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) == Unused Reference: 'I-D.ietf-rtgwg-routing-types' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'RFC2547' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 916, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-02 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ni-model-04 -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group D. Jain 3 Internet-Draft K. Patel 4 Intended status: Standards Track P. Brissette 5 Expires: April 21, 2018 Cisco 6 Z. Li 7 S. Zhuang 8 Huawei Technologies 9 X. Liu 10 Jabil 11 J. Haas 12 S. Esale 13 Juniper Networks 14 B. Wen 15 Comcast 16 October 18, 2017 18 Yang Data Model for BGP/MPLS L3 VPNs 19 draft-ietf-bess-l3vpn-yang-02.txt 21 Abstract 23 This document defines a YANG data model that can be used to configure 24 and manage BGP Layer 3 VPNs. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 21, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 74 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 75 3. Design of BGP L3VPN Data Model . . . . . . . . . . . . . . . 4 76 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. VRF Specific Configuration . . . . . . . . . . . . . . . 4 78 3.2.1. VRF interface . . . . . . . . . . . . . . . . . . . . 4 79 3.2.2. Route distinguisher . . . . . . . . . . . . . . . . . 4 80 3.2.3. Import and export route targets . . . . . . . . . . . 5 81 3.2.4. Forwarding mode . . . . . . . . . . . . . . . . . . . 5 82 3.2.5. Label security . . . . . . . . . . . . . . . . . . . 5 83 3.2.6. Yang tree . . . . . . . . . . . . . . . . . . . . . . 5 84 3.3. BGP Specific Configuration . . . . . . . . . . . . . . . 6 85 3.3.1. VPN peering . . . . . . . . . . . . . . . . . . . . . 7 86 3.3.2. VPN prefix limits . . . . . . . . . . . . . . . . . . 7 87 3.3.3. Label Mode . . . . . . . . . . . . . . . . . . . . . 7 88 3.3.4. ASBR options . . . . . . . . . . . . . . . . . . . . 7 89 3.3.5. Yang tree . . . . . . . . . . . . . . . . . . . . . . 7 90 4. BGP Yang Module . . . . . . . . . . . . . . . . . . . . . . . 8 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 96 8.2. Informative References . . . . . . . . . . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 YANG [RFC6020] is a data definition language that was introduced to 102 define the contents of a conceptual data store that allows networked 103 devices to be managed using NETCONF [RFC6241]. YANG is proving 104 relevant beyond its initial confines, as bindings to other interfaces 105 (e.g. ReST) and encodings other than XML (e.g. JSON) are being 106 defined. Furthermore, YANG data models can be used as the basis of 107 implementation for other interfaces, such as CLI and programmatic 108 APIs. 110 This document defines a YANG model that can be used to configure and 111 manage BGP L3VPNs [RFC4364]. It contains VRF sepcific parameters as 112 well as BGP specific parameters applicable for L3VPNs. The 113 individual containers defined in this model contain control knobs for 114 configuration for that purpose, as well as a few data nodes that can 115 be used to monitor health and gather statistics. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2. Definitions and Acronyms 125 AF: Address Family 127 AS: Autonomous System 129 ASBR: Autonomous System Border Router 131 BGP: Border Gateway Protocol 133 CE: Customer Edge 135 PE: Provider Edge 137 L3VPN: Layer 3 VPN 139 NETCONF: Network Configuration Protocol 141 RD: Route Distinguisher 142 ReST: Representational State Transfer, a style of stateless interface 143 and protocol that is generally carried over HTTP 145 RTFilter: Route Filter 147 VPN: Virtual Private Network 149 VRF: Virtual Routing and Forwarding 151 YANG: Data definition language for NETCONF 153 3. Design of BGP L3VPN Data Model 155 3.1. Overview 157 There are two parts of the BGP L3VPN yang data model. The first part 158 of the model defines VRF specific parameters for L3VPN by augmenting 159 the network-instance container defined in the network instance model 160 [I-D.ietf-rtgwg-ni-model] and the second part of the model defines 161 BGP specific parameters for the L3VPN by augmenting the base BGP data 162 model defined in [I-D.ietf-idr-bgp-model]. 164 3.2. VRF Specific Configuration 166 IETF network instance model defines various ni-types, one of which is 167 l3vpn. This provides an anchor point to add a new container l3vpn. 168 Under this container per VPN parameters pertaining to L3VPN are 169 added. 171 3.2.1. VRF interface 173 To associate a VRF instance with an interface, bind-network-instance 174 config should be used. This is covered in the base network instance 175 model [I-D.ietf-rtgwg-ni-model]. 177 3.2.2. Route distinguisher 179 Route distinguisher (RD) is an unique identifier used in VPN routes 180 to distinguish prefixes across different VPNs. RD is 8 byte field as 181 defined in the [RFC4364]. Where the first two bytes refer to type 182 followed by 6 bytes of value. The format of the value is dependent 183 on type. In the yang model, RDs are defined l3vpn container under 184 network-instance. 186 3.2.3. Import and export route targets 188 Route-target (RT) is an extended community used to specify the rules 189 for importing and exporting the routes for each VRF as defined in 190 [RFC4364]. This is applicable in the context of an address-family 191 under the VRF. Under the l3vpn container, statements for import and 192 export route-targets are added for ipv4 and ipv6 address family. 193 Both import and export sets are modeled as a list of rout-targets. 194 An import rule is modeled as list of RTs or a policy leafref 195 specifying the list of RTs to be matched for importing routes into 196 the VRF. Similarly an export rule is set or RTs or a policy leafref 197 specifying the list of RTs which should be attached to routes 198 exported from this VRF. In the case where policy is used to specify 199 the RTs, a reference to the policy via leafref is used in this model, 200 but actual definition of policy is outside the scope of this 201 document. In addition, this section also defines parameters for the 202 import from global routing table and export to global routing table, 203 as well as route limit per VPN instance for ipv4 and ipv6 address 204 family. 206 3.2.4. Forwarding mode 208 This configuration augments interface list under interface container 209 under a network instance as defined in IETF network instance model 210 [I-D.ietf-rtgwg-ni-model]. Forwarding mode configuration is required 211 under the ASBR facing interface to enable mpls forwarding for 212 directly connected BGP peers for inter-as option B peering. 214 3.2.5. Label security 216 For inter-as option-B peering across ASs, under the ASBR facing 217 interface, mpls label security enables the checks for RPF label on 218 incoming packets. Ietf-interface container is augmented to add this 219 config. 221 3.2.6. Yang tree 222 module: ietf-bgp-l3vpn 223 augment /ni:network-instances/ni:network-instance/ni:ni-type: 224 +--:(l3vpn) 225 +--rw l3vpn 226 +--rw rd? union 227 +--ro auto-rd? rt-types:route-distinguisher 228 +--rw ipv4 229 | +--rw unicast 230 | +--rw vpn-targets 231 | | +--rw vpn-target* [route-target] 232 | | | +--rw route-target rt-types:route-target 233 | | | +--rw route-target-type rt-types:route-target-type 234 | | +--rw route-policy? string 235 | +--rw import-from-global 236 | | +--rw enable? boolean 237 | | +--rw advertise-as-vpn? boolean 238 | | +--rw route-policy? string 239 | | +--rw bgp-valid-route? boolean 240 | | +--rw protocol? enumeration 241 | | +--rw instance? string 242 | +--rw export-to-global 243 | | +--rw enable? boolean 244 | +--rw routing-table-limit 245 | | +--rw routing-table-limit-number? uint32 246 | | +--rw (routing-table-limit-action)? 247 | | +--:(enable-alert-percent) 248 | | | +--rw alert-percent-value? rt-types:percentage 249 | | +--:(enable-simple-alert) 250 | | +--rw simple-alert? boolean 251 | +--rw tunnel-params 252 | +--rw tunnel-policy? string 254 augment /if:interfaces/if:interface: 255 +--rw forwarding-mode? enumeration 256 +--rw mpls-label-security 257 +--rw rpf? boolean 259 3.3. BGP Specific Configuration 261 The BGP specific configuration for L3VPNs is defined by augmenting 262 base BGP model [I-D.ietf-idr-bgp-model]. In particular, specific 263 knobs are added under neighbor and address family containers to 264 handle VPN routes and ASBR peering. 266 3.3.1. VPN peering 268 For Peering between PE routers, specific VPN address family needs to 269 be enabled under BGP container in the context of core instance. Base 270 BGP draft [I-D.ietf-idr-bgp-model] has l3vpn address family in the 271 list of identity refs for AFs under global and neighbor modes. The 272 same is augmented here for additional knobs. For peering with CE 273 routers the VRF specific BGP configurations such as neighbors and 274 address-family are covered in base BGP config, except that such 275 configuration will be in the context of a VRF. The instance of BGP 276 in this case would be a separate instance in the context of vrf-root 277 as defined in [I-D.ietf-rtgwg-ni-model]. 279 3.3.2. VPN prefix limits 281 Limits for max number of VPN prefixes for a PE router is defined in 282 the context of VPN address family under BGP. This would be the total 283 number of prefixes in VPN table per AF in the context of BGP 284 protocol. Route table limit for ipv4 and ipv6 address family for 285 each VPN instance is also defined under BGP. The total prefix limit 286 per VPN, including all the protocols is defined in the context of VRF 287 address family under routing instance. 289 3.3.3. Label Mode 291 Label mode knobs control the label allocation behavior for VRF 292 routes. Such as to specify Per-site, Per-vpn and Per-route label 293 allocation. These knobs augment BGP global AF containers in the 294 context of default routing instance. 296 3.3.4. ASBR options 298 This includes few specific knobs for ASBR peering methods illustrated 299 in [RFC4364]. Such as route target retention on ASBRs for inter-as 300 VPN peering across ASBRs with option-B method. Appropriate address- 301 family containers under BGP base model are augmented for this. 303 3.3.5. Yang tree 304 module: ietf-bgp-l3vpn 305 augment /bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:l3vpn-ipv4-unicast: 306 +--rw retain-route-targets 307 | +--rw all? empty 308 | +--rw route-policy? string 309 +--rw vpn-prefix-limit 310 +--rw prefix-limit-number? uint32 311 +--rw (prefix-limit-action)? 312 +--:(enable-alert-percent) 313 | +--rw alert-percent-value? rt-types:percentage 314 | +--rw route-unchanged? boolean 315 +--:(enable-simple-alert) 316 +--rw simple-alert? boolean 318 augment /bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-unicast: 319 +--rw label-mode? bgp-label-mode 320 +--rw routing-table-limit 321 +--rw routing-table-limit-number? uint32 322 +--rw (routing-table-limit-action)? 323 +--:(enable-alert-percent) 324 | +--rw alert-percent-value? rt-types:percentage 325 +--:(enable-simple-alert) 326 +--rw simple-alert? boolean 328 4. BGP Yang Module 330 file "ietf-bgp-l3vpn@2017-10-18.yang" 332 module ietf-bgp-l3vpn { 333 yang-version 1.1; 334 namespace "urn:ietf:params:xml:ns:yang:ietf-bgp-l3vpn"; 335 // replace with IANA namespace when assigned 336 prefix l3vpn ; 338 import ietf-network-instance { 339 prefix ni; 340 revision-date 2017-09-27; 341 } 343 import ietf-routing-types { 344 prefix rt-types; 345 revision-date 2017-10-13; 346 } 348 import ietf-interfaces { 349 prefix if; 351 } 353 import ietf-bgp { 354 prefix bgp; 355 revision-date 2016-06-21; 356 } 358 organization 359 "IETF BGP Enabled Services WG"; 361 contact 362 "BESS working group - bess@ietf.org"; 364 description 365 "This YANG module defines a YANG data model to configure and 366 manage BGP Layer3 VPNs. It augments the IETF bgp yang model 367 and IETF network instance model to add L3VPN specific 368 configuration and operational knobs. 370 Terms and Acronyms 372 AF : Address Family 374 AS : Autonomous System 376 ASBR : Autonomous Systems Border Router 378 BGP (bgp) : Border Gateway Protocol 380 CE : Customer Edge 382 IP (ip) : Internet Protocol 384 IPv4 (ipv4):Internet Protocol Version 4 386 IPv6 (ipv6): Internet Protocol Version 6 388 L3VPN: Layer 3 VPN 390 PE : Provider Edge 392 RT : Route Target 394 RD : Route Distinguisher 396 VPN : Virtual Private Network 397 VRF : Virtual Routing and Forwarding 399 "; 401 revision 2017-10-18 { 402 description 403 "Removed state containers per NMDA aligntment" + 404 "Changes for network instance ni-type alignment" + 405 "Other cleanups"; 406 reference ""; 407 } 408 revision 2017-04-25 { 409 description 410 "Reused ietf-roting-types.yang for vpn route-targets" + 411 " and route distinguisher types"; 412 reference ""; 413 } 415 revision 2016-09-09 { 416 description 417 "Initial revision."; 418 reference 419 "RFC XXXX: A YANG Data Model for BGP L3VPN config management"; 420 } 422 //Label mode 423 typedef bgp-label-mode { 424 type enumeration { 425 enum per-ce { 426 description "Allocate labels per CE"; 427 } 428 enum per-route { 429 description "Allocate labels per prefix"; 430 } 431 enum per-vpn { 432 description "Allocate labels per VRF"; 433 } 434 } 435 description "BGP label allocation mode"; 436 } 438 //RD 439 grouping route-distinguisher-params { 440 description "Route distinguisher value as per RFC4364"; 441 leaf rd { 442 type union { 443 // Either RD value as per IETF routing types or AUTO assigned value 444 type rt-types:route-distinguisher; 445 type enumeration { 446 enum auto-assigned { 447 description "Assigned by system"; 448 } 449 } 450 } 451 description "Route distinguisher value as per RFC4364"; 452 } 453 leaf auto-rd { 454 type rt-types:route-distinguisher; 455 config false; 456 description 457 "Automatically assigned RD value when rd AUTO is configured"; 458 } 459 } 461 //Fwding mode 462 grouping forwarding-mode { 463 description "Forwarding mode of interface for ASBR scenario"; 464 leaf forwarding-mode { 465 type enumeration { 466 enum mpls { 467 description "Forwarding mode mpls"; 468 } 469 } 470 description "Forwarding mode of interface for ASBR scenario"; 471 } 472 } 474 grouping label-security { 475 description "Mpls label security for ASBR option B scenario"; 476 container mpls-label-security { 477 description "MPLS label secruity"; 478 leaf rpf { 479 type boolean; 480 description "Enable MPLS label security rpf on interface"; 481 } 482 } 483 } 485 //per VPN instance table limit under BGP 486 grouping vpn-pfx-limit { 487 description "Per VPN instance table limit under BGP"; 488 container vpn-prefix-limit { 489 description 490 "The prefix limit config sets a limit on the maximum 491 number of prefixes supported in the existing VPN 492 instance, preventing the PE from importing excessive 493 VPN route prefixes. 494 "; 496 leaf prefix-limit-number { 497 type uint32 { 498 range "1..4294967295"; 499 } 500 description 501 "Specifies the maximum number of prefixes supported in the 502 VPN instance IPv4 or IPv6 address family."; 503 } 505 choice prefix-limit-action { 506 description "."; 507 case enable-alert-percent { 508 leaf alert-percent-value { 509 type rt-types:percentage; 510 description 511 "Specifies the proportion of the alarm threshold to the 512 maximum number of prefixes."; 513 } 514 leaf route-unchanged { 515 type boolean; 516 default "false"; 517 description 518 "Indicates that the routing table remains unchanged. 519 By default, route-unchanged is not configured. When 520 the number of prefixes in the routing table is 521 greater than the value of the parameter number, 522 routes are processed as follows: 523 (1)If route-unchanged is configured, routes in the 524 routing table remain unchanged. 525 (2)If route-unchanged is not configured, all routes 526 in the routing table are deleted and then 527 re-added."; 528 } 529 } 530 case enable-simple-alert { 531 leaf simple-alert { 532 type boolean; 533 default "false"; 534 description 535 "Indicates that when the number of VPN route prefixes 536 exceeds number, prefixes can still join the VPN 537 routing table and alarms are displayed."; 538 } 539 } 540 } 542 } 543 } 545 grouping global-imports { 546 description "Grouping for imports from global routing table"; 547 container import-from-global { 548 description "Import from global routing table"; 549 leaf enable { 550 type boolean; 551 description "Enable"; 552 } 553 leaf advertise-as-vpn { 554 type boolean; 555 description 556 "Advertise routes imported from global table as VPN routes"; 557 } 558 leaf route-policy { 559 type string; 560 description "Route policy as filter for importing routes"; 561 } 563 leaf bgp-valid-route { 564 type boolean; 565 description 566 "Enable all valid routes (including non-best paths) to be 567 candidate for import"; 568 } 570 leaf protocol { 571 type enumeration { 572 enum ALL { 573 value "0"; 574 description "ALL:"; 575 } 576 enum Direct { 577 value "1"; 578 description "Direct:"; 579 } 580 enum OSPF { 581 value "2"; 582 description "OSPF:"; 583 } 584 enum ISIS { 585 value "3"; 586 description "ISIS:"; 587 } 588 enum Static { 589 value "4"; 590 description "Static:"; 591 } 592 enum RIP { 593 value "5"; 594 description "RIP:"; 595 } 596 enum BGP { 597 value "6"; 598 description "BGP:"; 599 } 600 enum OSPFV3 { 601 value "7"; 602 description "OSPFV3:"; 603 } 604 enum RIPNG { 605 value "8"; 606 description "RIPNG:"; 607 } 608 } 609 description 610 "Specifies the protocol from which routes are imported. 611 At present, In the IPv4 unicast address family view, 612 the protocol can be IS-IS, static, direct and BGP."; 613 } 615 leaf instance { 616 type string; 617 description 618 "Specifies the instance id of the protocol"; 619 } 620 } 621 } 623 grouping global-exports { 624 description "Grouping for exports routes to global table"; 625 container export-to-global { 626 description "Export to global routing table"; 627 leaf enable { 628 type boolean; 629 description "Enable"; 630 } 631 } 632 } 634 grouping route-target-params { 635 description "Grouping to specify rules for route import and export"; 636 container vpn-targets { 637 description 638 "Set of route-targets to match for import and export routes 639 to/from VRF"; 640 uses rt-types:vpn-route-targets; 641 leaf route-policy { 642 type string; 643 description 644 "Reference to the route policy containing set of route-targets. 645 TBD: leafref to policy xpath in IETF route policy model"; 646 } 647 } 648 } 650 grouping route-tbl-limit-params { 651 description "Grouping for VPN table prefix limit config"; 652 leaf routing-table-limit-number { 653 type uint32 { 654 range "1..4294967295"; 655 } 656 description 657 "Specifies the maximum number of routes supported by a 658 VPN instance. "; 659 } 661 choice routing-table-limit-action { 662 description "."; 663 case enable-alert-percent { 664 leaf alert-percent-value { 665 type rt-types:percentage; 666 description 667 "Specifies the percentage of the maximum number of 668 routes. When the maximum number of routes that join 669 the VPN instance is up to the value 670 (number*alert-percent)/100, the system prompts 671 alarms. The VPN routes can be still added to the 672 routing table, but after the number of routes 673 reaches number, the subsequent routes are 674 dropped."; 675 } 676 } 677 case enable-simple-alert { 678 leaf simple-alert { 679 type boolean; 680 description 681 "Indicates that when VPN routes exceed number, routes 682 can still be added into the routing table, but the 683 system prompts alarms. 684 However, after the total number of VPN routes and 685 network public routes reaches the unicast route limit 686 specified in the License, the subsequent VPN routes 687 are dropped."; 688 } 689 } 690 } 691 } 693 grouping routing-tbl-limit { 694 description "."; 695 container routing-table-limit { 696 description 697 "The routing-table limit command sets a limit on the maximum 698 number of routes that the IPv4 or IPv6 address family of a 699 VPN instance can support. 700 By default, there is no limit on the maximum number of 701 routes that the IPv4 or IPv6 address family of a VPN 702 instance can support, but the total number of private 703 network and public network routes on a device cannot 704 exceed the allowed maximum number of unicast routes."; 706 uses route-tbl-limit-params; 707 } 708 } 710 // Tunnel policy parameters 711 grouping tunnel-params { 712 description "Tunnel parameters"; 713 container tunnel-params { 714 description "Tunnel config parameters"; 715 leaf tunnel-policy { 716 type string; 717 description 718 "Tunnel policy to steer the VPN traffic into specific tunnel"; 719 } 720 } 721 } 723 // Grouping for the L3vpn specific parameters under VRF 724 // (network-instance) 725 grouping l3vpn-vrf-params { 726 description "Specify route filtering rules for import/export"; 727 container ipv4 { 728 description 729 "Specify route filtering rules for import/export"; 730 container unicast { 731 description 732 "Specify route filtering rules for import/export"; 733 uses route-target-params; 734 uses global-imports; 735 uses global-exports; 736 uses routing-tbl-limit; 737 uses tunnel-params; 738 } 739 } 740 container ipv6 { 741 description 742 "Ipv6 address family specific rules for import/export"; 743 container unicast { 744 description "Ipv6 unicast address family"; 745 uses route-target-params; 746 uses global-imports; 747 uses global-exports; 748 uses routing-tbl-limit; 749 uses tunnel-params; 750 } 751 } 752 } 754 grouping bgp-label-mode { 755 description "MPLS/VPN label allocation mode"; 756 leaf label-mode { 757 type bgp-label-mode; 758 description "Label allocation mode"; 759 } 760 } 762 grouping retain-route-targets { 763 description "Grouping for route target accept"; 764 container retain-route-targets { 765 description "Control route target acceptance behavior for ASBRs"; 766 leaf all { 767 type empty; 768 description "Disable filtering of all route-targets"; 769 } 770 leaf route-policy { 771 type string; 772 description "Filter routes as per filter policy name 773 TBD: leafref to IETF routing policy model"; 774 } 775 } 776 } 778 // 779 // VRF specific parameters. 780 // RD and RTs and route import-export rules are added under 781 // network instance container in network instance model, hence 782 // per VRF scoped 783 augment "/ni:network-instances/ni:network-instance/ni:ni-type" { 784 description 785 "Augment network instance for per VRF L3vpn parameters"; 786 case l3vpn { 787 container l3vpn { 788 description "Configuration of L3VPN specific parameters"; 790 uses route-distinguisher-params; 791 uses l3vpn-vrf-params ; 792 } 793 } 794 } 796 // bgp mpls forwarding enable required for inter-as option AB. 797 augment "/if:interfaces/if:interface" { 798 description 799 "BGP mpls forwarding mode configuration on interface for 800 ASBR scenario"; 801 uses forwarding-mode ; 802 uses label-security; 803 } 805 // 806 // BGP Specific Paramters 807 // 809 // 810 // Retain route-target for inter-as option ASBR knob. 811 // vpn prefix limits 812 // vpnv4/vpnv6 address-family only. 813 augment "/bgp:bgp/bgp:global/bgp:afi-safis/" + 814 "bgp:afi-safi/bgp:l3vpn-ipv4-unicast" { 815 description "Retain route targets for ASBR scenario"; 816 uses retain-route-targets; 817 uses vpn-pfx-limit; 818 } 820 augment "/bgp:bgp/bgp:global/bgp:afi-safis/" + 821 "bgp:afi-safi/bgp:l3vpn-ipv6-unicast" { 822 description "Retain route targets for ASBR scenario"; 823 uses retain-route-targets; 824 uses vpn-pfx-limit; 825 } 827 // Label allocation mode configuration. Certain AFs only. 828 augment "/bgp:bgp/bgp:global/bgp:afi-safis/" + 829 "bgp:afi-safi/bgp:ipv4-unicast" { 831 description 832 "Augment BGP global AF mode for label allocation mode 833 configuration"; 834 uses bgp-label-mode ; 835 uses routing-tbl-limit; 836 } 838 augment "/bgp:bgp/bgp:global/bgp:afi-safis/" + 839 "bgp:afi-safi/bgp:ipv6-unicast" { 840 description 841 "Augment BGP global AF mode for label allocation mode 842 configuration"; 843 uses bgp-label-mode ; 844 uses routing-tbl-limit; 845 } 846 } 848 850 5. IANA Considerations 852 6. Security Considerations 854 The transport protocol used for sending the BGP L3VPN data MUST 855 support authentication and SHOULD support encryption. The data-model 856 by itself does not create any security implications. 858 This draft does not change any underlying security issues inherent in 859 [I-D.ietf-rtgwg-ni-model] and [I-D.ietf-idr-bgp-model]. 861 7. Acknowledgements 863 The authors would like to thank TBD for their detail reviews and 864 comments. 866 8. References 868 8.1. Normative References 870 [I-D.ietf-idr-bgp-model] 871 Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K., 872 Bansal, D., Clemm, A., Zhdankin, A., Jethanandani, M., and 873 X. Liu, "BGP Model for Service Provider Networks", draft- 874 ietf-idr-bgp-model-02 (work in progress), July 2016. 876 [I-D.ietf-rtgwg-ni-model] 877 Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 878 Liu, "YANG Network Instances", draft-ietf-rtgwg-ni- 879 model-04 (work in progress), September 2017. 881 [I-D.ietf-rtgwg-routing-types] 882 Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 883 "Routing Area Common YANG Data Types", draft-ietf-rtgwg- 884 routing-types-17 (work in progress), October 2017. 886 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 887 Requirement Levels", BCP 14, RFC 2119, 888 DOI 10.17487/RFC2119, March 1997, 889 . 891 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 892 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 893 2006, . 895 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 896 the Network Configuration Protocol (NETCONF)", RFC 6020, 897 DOI 10.17487/RFC6020, October 2010, 898 . 900 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 901 and A. Bierman, Ed., "Network Configuration Protocol 902 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 903 . 905 8.2. Informative References 907 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 908 DOI 10.17487/RFC2547, March 1999, 909 . 911 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 912 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 913 DOI 10.17487/RFC4271, January 2006, 914 . 916 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 917 "Multiprotocol Extensions for BGP-4", RFC 4760, 918 DOI 10.17487/RFC4760, January 2007, 919 . 921 Authors' Addresses 923 Dhanendra Jain 924 Cisco 925 170 W. Tasman Drive 926 San Jose, CA 95134 927 USA 929 Email: dhjain@cisco.com 931 Keyur Patel 932 Cisco 933 170 W. Tasman Drive 934 San Jose, CA 95134 935 USA 937 Email: keyur@arrcus.com 939 Patrice Brissette 940 Cisco 941 170 W. Tasman Drive 942 San Jose, CA 95134 943 USA 945 Email: pbrisset@cisco.com 947 Zhenbin Li 948 Huawei Technologies 949 Huawei Bld., No.156 Beiqing Rd. 950 Beijing 100095 951 China 953 Email: lizhenbin@huawei.com 955 Shunwan Zhuang 956 Huawei Technologies 957 Huawei Bld., No.156 Beiqing Rd. 958 Beijing 100095 959 China 961 Email: zhuangshunwan@huawei.com 962 Xufeng Liu 963 Jabil 964 8281 Greensboro Drive, Suite 200 965 McLean, VA 22102 966 USA 968 Email: Xufeng_Liu@jabil.com 970 Jeffrey Haas 971 Juniper Networks 973 Email: jhaas@juniper.net 975 Santosh Esale 976 Juniper Networks 977 1194 N. Mathilda Ave. 978 Sunnyvale, CA 94089 979 US 981 Email: sesale@juniper.net 983 Bin Wen 984 Comcast 986 Email: Bin_Wen@cable.comcast.com