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