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