idnits 2.17.1 draft-keyupate-bess-bgp-l3vpn-cfg-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 42 instances of too long lines in the document, the longest one being 28 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: '...--rw rt str...' == Line 246 has weird spacing: '...--ro rt str...' == Line 254 has weird spacing: '...--rw rt str...' == Line 260 has weird spacing: '...--ro rt str...' == Line 267 has weird spacing: '...--rw rt str...' == (9 more instances...) == 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 (December 27, 2015) is 3014 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2547' is defined on line 923, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 927, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 931, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 962, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-15 ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group K. Patel 3 Internet-Draft D. Jain 4 Intended status: Informational Cisco 5 Expires: June 29, 2016 December 27, 2015 7 Yang Data Model for BGP/MPLS L3 VPNs 8 draft-keyupate-bess-bgp-l3vpn-cfg-02.txt 10 Abstract 12 This document defines a YANG data model that can be used to configure 13 and manage BGP Layer 3 VPNs. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on June 29, 2016. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 64 3. Design of L3VPN Routing Data Model . . . . . . . . . . . . . 3 65 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.2. BGP Specific Configuration . . . . . . . . . . . . . . . 4 67 3.2.1. VPN peering . . . . . . . . . . . . . . . . . . . . . 4 68 3.2.2. Route distinguisher . . . . . . . . . . . . . . . . . 4 69 3.2.3. Import and export route target . . . . . . . . . . . 4 70 3.2.4. Route target retention . . . . . . . . . . . . . . . 5 71 3.2.5. Label Mode . . . . . . . . . . . . . . . . . . . . . 5 72 3.2.6. Nexthop options . . . . . . . . . . . . . . . . . . . 5 73 3.3. VRF Specific Configuration . . . . . . . . . . . . . . . 8 74 3.3.1. VRF interface . . . . . . . . . . . . . . . . . . . . 8 75 3.3.2. Import and export route-targets . . . . . . . . . . . 8 76 3.3.3. Forwarding mode . . . . . . . . . . . . . . . . . . . 8 77 3.3.4. Label security . . . . . . . . . . . . . . . . . . . 8 78 4. BGP Yang Module . . . . . . . . . . . . . . . . . . . . . . . 10 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 84 8.2. Informative References . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 YANG [RFC6020] is a data definition language that was introduced to 90 define the contents of a conceptual data store that allows networked 91 devices to be managed using NETCONF [RFC6241]. YANG is proving 92 relevant beyond its initial confines, as bindings to other interfaces 93 (e.g. ReST) and encodings other than XML (e.g. JSON) are being 94 defined. Furthermore, YANG data models can be used as the basis of 95 implementation for other interfaces, such as CLI and programmatic 96 APIs. 98 This document defines a YANG model that can be used to configure and 99 manage BGP L3VPNs [RFC4364]. There are two parts of the L3VPN BGP 100 model. The first part of the model augments base BGP data model 101 defined in [I-D.shaikh-idr-bgp-model] for BGP specific L3VPN 102 configuration and the second part of the model augments the Routing 103 data model defined in [I-D.ietf-netmod-routing-cfg] for VRF specific 104 L3VPN configuration. This model defines control knobs for 105 configuration for that purpose, as well as a few data nodes that can 106 be used to monitor health and gather statistics. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Definitions and Acronyms 116 AF: Address Family 118 AS: Autonomous System 120 ASBR: Autonomous System Border Router 122 BGP: Border Gateway Protocol 124 L3VPN: Layer 3 VPN 126 NETCONF: Network Configuration Protocol 128 ReST: Representational State Transfer, a style of stateless interface 129 and protocol that is generally carried over HTTP 131 RTFilter: Route Filter 133 VPN: Virtual Private Network 135 YANG: Data definition language for NETCONF 137 3. Design of L3VPN Routing Data Model 139 3.1. Overview 141 L3VPN specific configuration and state data is defined in BGP 142 specific model and VRF specific model. This document does not cover 143 the model for some of the other entities involved in L3 VPNs such as 144 IGPs and MPLS. 146 3.2. BGP Specific Configuration 148 The BGP specific configuration for L3VPNs is augmentation of base BGP 149 model defined in [I-D.shaikh-idr-bgp-model]. In particular, 150 containers for BGP global mode and BGP address family mode are 151 augmented with L3VPN specific attributes and parameters. It is 152 noteworthy that current form of BGP model needs to align with netmod 153 routing model such that BGP entry level container becomes an instance 154 of routing-instance container in netmod routing model. The 155 augmentation proposed in this document are based on current state of 156 BGP yang model as defined in [I-D.shaikh-idr-bgp-model] 158 3.2.1. VPN peering 160 For Peering between PE routers, specific VPN address family needs to 161 be enabled under BGP container in the default routing-instance. Base 162 BGP draft [I-D.shaikh-idr-bgp-model] has l3vpn address family in the 163 list of identity refs for AFs under global and neighbor modes. The 164 same is augmented here for additional knobs. For peering with CE 165 routers the VRF specific BGP configurations such as neighbors and 166 address-family are covered in base BGP config, except that such 167 configuration will be in the context of a VRF. The instance of BGP 168 in this case would be a separate instance in the context of routing 169 instance realizing a VRF. 171 3.2.2. Route distinguisher 173 Route distinguisher (RD) is an unique identifier used in VPN routes 174 to distinguish prefixes across different VPNs. RD is 8 byte field as 175 defined in the [RFC4364]. Where the first two bytes refer to type 176 followed by 6 bytes of value. The format of the value is dependent 177 on type. In the yang model, RDs are defined by augmenting BGP global 178 mode. Note that BGP will be modeled as an instance of routing- 179 protocol under a routing-instance container in the overall routing 180 model. Further a routing-instance is representation of VRF in 181 routing model. Therefore providing RD under BGP global level results 182 into RDs being in the context of VRF under BGP. 184 3.2.3. Import and export route target 186 Route-target (RT) community is an extended community used to specify 187 the rules for importing and exporting the routes for each VRF. This 188 is applicable in the context of an address-family under the VRF. 189 Since BGP instance is in the context of each routing-instance (aka 190 VRF), the import/export rules can be specified per global address- 191 family under BGP. An import rule is modeled as list of RTs or a 192 policy leafref specifying the list of RTs, which must appear in 193 routes a VRF is interested in importing. Similarly an export rule is 194 set or RTs or a policy leafref specifying the list of RTs which 195 should be attached to routes exported from this VRF. In the case 196 where policy is used to specify the RTs, a reference to the policy 197 via leafref is used in this model, but actual definition of policy is 198 outside the scope of this document. 200 3.2.4. Route target retention 202 This configuration is required on ASBRs to retain the VPN routes for 203 certain or all route-targets. Since ASBRs do not require that VRFs 204 be configured, but need to retain the IPv4 VPN prefix information. 205 This configuration augments BGP global AF containers, particularly 206 the VPN address family containers. 208 3.2.5. Label Mode 210 Label mode knobs control the label allocation behavior for VRF 211 routes. Such as to specify Per-CE, Per-VRF and Per-Prefix label 212 allocation. These knobs augment BGP global AF containers in the 213 context of default routing instance. 215 3.2.6. Nexthop options 217 For inter-as VPN peering across ASBRs with option-B method, the 218 bordering ASBR need to rewrite nexthop to self. Similarly for 219 Option-C peering the route reflectors need to keep nexthop unchanged 220 for ebgp routes from remote AS's route-reflector. BGP neighbor and 221 peer-group containers are augmented to provide these knobs. In 222 addition the knobs are added under per address family mode under 223 neighbor and peer-group as well for finer level of granularity. 225 module: ietf-bgp-l3vpn 226 augment /bgp:bgp/bgp:global: 227 +--rw route-distinguisher 228 +--rw config 229 | +--rw rd? string 230 +--ro state 231 +--ro rd? string 232 ... 234 augment /bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-unicast: 235 +--rw import-routes 236 | +--rw config 237 | | +--rw route-targets 238 | | | +--rw rt-list* [rt] 239 | | | +--rw rt string 240 | | +--rw route-policy? string 241 | | +--rw from-default-vrf? boolean 242 | | +--rw advertise-as-vpn? boolean 243 | +--ro state 244 | +--ro route-targets 245 | | +--ro rt-list* [rt] 246 | | +--ro rt string 247 | +--ro route-policy? string 248 | +--ro from-default-vrf? boolean 249 | +--ro advertise-as-vpn? boolean 250 +--rw export-routes 251 | +--rw config 252 | | +--rw route-targets 253 | | | +--rw rt-list* [rt] 254 | | | +--rw rt string 255 | | +--rw route-policy? string 256 | | +--rw to-default-vrf? boolean 257 | +--ro state 258 | +--ro route-targets 259 | | +--ro rt-list* [rt] 260 | | +--ro rt string 261 | +--ro route-policy? string 262 | +--ro to-default-vrf? boolean 263 +--rw import-export-routes 264 +--rw config 265 | +--rw route-targets 266 | | +--rw rt-list* [rt] 267 | | +--rw rt string 268 | +--rw route-policy? string 269 +--ro state 270 +--ro route-targets 271 | +--ro rt-list* [rt] 272 | +--ro rt string 273 +--ro route-policy? string 275 ... 277 augment /bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:l3vpn-ipv4-unicast: 278 +--rw retain-rts 279 +--rw config 280 | +--rw all? empty 281 | +--rw route-policy? string 282 +--ro state 283 +--ro all? empty 284 +--ro route-policy? string 286 ... 288 augment /bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-unicast: 289 +--rw config 290 | +--rw label-mode? bgp-label-mode 291 +--ro state 292 +--ro label-mode? bgp-label-mode 294 ... 296 augment /bgp:bgp/bgp:neighbors/bgp:neighbor: 297 +--rw nexthop-options 298 +--rw config 299 | +--rw next-hop-self? boolean 300 | +--rw next-hop-unchanged? boolean 301 +--rw state 302 +--rw next-hop-self? boolean 303 +--rw next-hop-unchanged? boolean 305 augment /bgp:bgp/bgp:peer-groups/bgp:peer-group: 306 +--rw nexthop-options 307 +--rw config 308 | +--rw next-hop-self? boolean 309 | +--rw next-hop-unchanged? boolean 310 +--rw state 311 +--rw next-hop-self? boolean 312 +--rw next-hop-unchanged? boolean 314 augment /bgp:bgp/bgp:neighbors/bgp:neighbor/bgp:afi-safis/bgp:afi-safi: 315 +--rw nexthop-options 316 +--rw config 317 | +--rw next-hop-self? boolean 318 | +--rw next-hop-unchanged? boolean 319 +--rw state 320 +--rw next-hop-self? boolean 321 +--rw next-hop-unchanged? boolean 323 augment /bgp:bgp/bgp:peer-groups/bgp:peer-group/bgp:afi-safis/bgp:afi-safi: 324 +--rw nexthop-options 325 +--rw config 326 | +--rw next-hop-self? boolean 327 | +--rw next-hop-unchanged? boolean 328 +--rw state 329 +--rw next-hop-self? boolean 330 +--rw next-hop-unchanged? boolean 332 3.3. VRF Specific Configuration 334 VRF specific configuration is defined by augmenting the IETF routing 335 model. The routing-instance defined in the IETF routing model refers 336 to a named VRF instance. 338 3.3.1. VRF interface 340 To associate a VRF instance with an interface, the interface should 341 be defined in the context of routing-instance representing a VRF. 342 This is covered in base routing model [I-D.ietf-netmod-routing-cfg]. 344 3.3.2. Import and export route-targets 346 Under the routing-instance modeled as VRF, statements for import and 347 export route-targets are added as augmented containers. Both import 348 and export sets are modeled as a list of rout-targets as defined in 349 [RFC4364]. In addition, a route-target-policy can be applied at this 350 level to set the route-targets. Policyref to IETF policy model is 351 TBD. 353 3.3.3. Forwarding mode 355 This configuration augments interface list under interface container 356 under a routing-instance as defined in IETF routing model 357 [I-D.ietf-netmod-routing-cfg]. Forwarding mode configuration is 358 required under the ASBR facing interface to enable mpls forwarding 359 for directly connected BGP peers for inter-as option B peering. 361 3.3.4. Label security 363 For inter-as option-B peering across ASs, under the ASBR facing 364 interface, mpls label security enables the checks for RPF label on 365 incoming packets. Ietf-interface container is augmented to add this 366 config. 368 augment /rt:routing/rt:routing-instance: 369 +--rw import-routes 370 | +--rw config 371 | | +--rw route-targets 372 | | | +--rw rt-list* [rt] 373 | | | +--rw rt string 374 | | +--rw route-policy? string 375 | | +--rw from-default-vrf? boolean 376 | | +--rw advertise-as-vpn? boolean 377 | +--ro state 378 | +--ro route-targets 379 | | +--ro rt-list* [rt] 380 | | +--ro rt string 381 | +--ro route-policy? string 382 | +--ro from-default-vrf? boolean 383 | +--ro advertise-as-vpn? boolean 384 +--rw export-routes 385 | +--rw config 386 | | +--rw route-targets 387 | | | +--rw rt-list* [rt] 388 | | | +--rw rt string 389 | | +--rw route-policy? string 390 | | +--rw to-default-vrf? boolean 391 | +--ro state 392 | +--ro route-targets 393 | | +--ro rt-list* [rt] 394 | | +--ro rt string 395 | +--ro route-policy? string 396 | +--ro to-default-vrf? boolean 397 +--rw import-export-routes 398 +--rw config 399 | +--rw route-targets 400 | | +--rw rt-list* [rt] 401 | | +--rw rt string 402 | +--rw route-policy? string 403 +--ro state 404 +--ro route-targets 405 | +--ro rt-list* [rt] 406 | +--ro rt string 407 +--ro route-policy? string 409 ... 411 augment /if:interfaces/if:interface: 412 +--rw forwarding-mode 413 | +--rw config 414 | | +--rw forwarding-mode? fwd-mode-type 415 | +--ro state 416 | +--ro forwarding-mode? fwd-mode-type 417 +--rw mpls-label-security 418 +--rw config 419 | +--rw rpf? boolean 420 +--ro state 421 +--ro rpf? boolean 423 4. BGP Yang Module 425 file "ietf-bgp-l3vpn@2015-12-27.yang" 427 module ietf-bgp-l3vpn { 428 namespace "urn:ietf:params:xml:ns:yang:ietf-bgp-l3vpn"; 429 // replace with IANA namespace when assigned 430 prefix l3vpn ; 432 import ietf-routing { 433 prefix rt; 434 revision-date 2015-10-16; 435 } 437 import ietf-interfaces { 438 prefix if; 439 } 441 import bgp { 442 prefix bgp; 443 } 445 organization 446 "Cisco Systems 447 170 West Tasman Drive 448 San Jose, CA 95134-1706 449 USA"; 451 contact 452 "Keyur Patel keyupate@cisco.com 453 Dhanendra Jain dhjain@cisco.com 454 "; 456 description 457 "This YANG module defines the configuration for the BGP Layer 3 VPNs. 458 It augments the IETF bgp yang model and IETF routing model to add L3VPN specific 459 configuration and operational knobs. 461 Terms and Acronyms 463 AS : Autonomous System 465 ASBR : Autonomous Systems Border Router 467 BGP (bgp): Border Gateway Protocol 468 CE : Customer Edge 470 IP (ip): Internet Protocol 472 IPv4 (ipv4):Internet Protocol Version 4 474 IPv6 (ipv6): Internet Protocol Version 6 476 PE : Provider Edge 478 RT : Route Target 480 RD : Route Distinguisher 482 VPN : Virtual Private Network 484 "; 486 revision 2015-12-27 { 487 description 488 "Initial revision."; 489 reference 490 "RFC XXXX: A YANG Data Model for L3VPN config management"; 491 } 493 grouping bgp-rd-spec { 494 description "Route distinguisher specification as per RFC4364"; 495 leaf rd { 496 type string; 497 description "Route distinguisher value as per RFC4364"; 498 } 499 } 500 grouping bgp-rd { 501 description "BGP route distinguisher"; 502 container route-distinguisher { 503 description "Route distinguisher"; 504 container config { 505 description "Configuration parameters for route distinguisher"; 506 uses bgp-rd-spec ; 507 } 508 container state { 509 config "false" ; 510 description "State information for route distinguisher"; 511 uses bgp-rd-spec ; 512 } 514 } 515 } 517 typedef bgp-label-mode { 518 type enumeration { 519 enum per-ce { 520 description "Allocate labels per CE"; 521 } 522 enum per-prefix { 523 description "Allocate labels per prefix"; 524 } 525 enum per-vrf { 526 description "Allocate labels per VRF"; 527 } 528 } 529 description "BGP label allocation mode"; 530 } 532 typedef fwd-mode-type { 533 type enumeration { 534 enum mpls { 535 description "Forwarding mode mpls"; 536 } 537 } 538 description "Enable forwarding mode under ASBR facing interface"; 539 } 541 grouping forwarding-mode { 542 description "Forwarding mode of interface for ASBR scenario"; 543 container forwarding-mode { 544 description "Forwarding mode of interface for ASBR scenario"; 545 container config { 546 description "Configuration of Forwarding mode"; 547 leaf forwarding-mode { 548 type fwd-mode-type; 549 description "Forwarding mode for this interface"; 550 } 551 } 552 container state { 553 config "false"; 554 description "State information of Forwarding mode"; 555 leaf forwarding-mode { 556 type fwd-mode-type; 557 description "Forwarding mode for this interface"; 558 } 559 } 560 } 562 } 564 grouping label-security { 565 description "Mpls label security for ASBR option B scenario"; 566 container mpls-label-security { 567 description "MPLS label secruity"; 568 container config { 569 description "Configuration parameters"; 570 leaf rpf { 571 type boolean; 572 description "Enable MPLS label security rpf on interface"; 573 } 574 } 575 container state { 576 config "false"; 577 description "State information"; 578 leaf rpf { 579 type boolean; 580 description "MPLS label security rpf on interface"; 581 } 582 } 583 } 584 } 586 grouping route-target-set { 587 description 588 "Extended community route-target set "; 589 container route-targets { 590 description 591 "Route-target"; 592 list rt-list { 593 key "rt"; 594 description 595 "List of route-targets" ; 596 leaf rt { 597 type string { 598 pattern '([0-9]+:[0-9]+)'; 599 } 600 description "Route target extended community as per RFC4360"; 601 } 602 } 603 } 604 leaf route-policy { 605 type string; 606 description 607 "Reference to the policy containing set of routes. 608 TBD: leafref to policy entry in IETF policy model"; 609 } 610 } 612 grouping import-from-default { 613 description "Import from default VRF"; 614 leaf from-default-vrf { 615 type boolean; 616 description "Import from default VRF"; 617 } 618 leaf advertise-as-vpn { 619 when "../from-default-vrf == TRUE" { 620 description "This option is valid only when importing from default VRF"; 621 } 622 type boolean; 623 description "Advertise from-default routes as VPN routes"; 624 } 625 } 627 grouping export-to-default { 628 description "Export routes to default VRF"; 629 leaf to-default-vrf { 630 type boolean; 631 description "Export routes to default VRF"; 632 } 633 } 635 grouping route-import-set { 636 description "Grouping to specify rules for route import"; 637 container import-routes { 638 description "Set of route-targets to match to import routes into VRF"; 639 container config { 640 description 641 "Configuration parameters for import routes"; 642 uses route-target-set ; 643 uses import-from-default; 644 } 645 container state { 646 config "false" ; 647 description 648 "State information for the import routes"; 649 uses route-target-set ; 650 uses import-from-default; 651 } 652 } 653 } 654 grouping route-export-set { 655 description "Groupign to specify rules for route export"; 656 container export-routes { 657 description "Set of route-targets to attach with exported routes from VRF"; 658 container config { 659 description 660 "Configuration parameters for export routes"; 661 uses route-target-set ; 662 uses export-to-default; 663 } 664 container state { 665 config "false" ; 666 description 667 "State information for export routes"; 668 uses route-target-set ; 669 uses export-to-default; 670 } 671 } 672 } 674 grouping route-import-export-set { 675 description "Grouping to specify rules for route import/export both"; 676 container import-export-routes { 677 description "Set of route-targets for import/export both"; 678 container config { 679 description "Both import/export routes"; 680 uses route-target-set; 681 } 682 container state { 683 config "false" ; 684 description "Both import/export routes"; 685 uses route-target-set; 686 } 687 } 688 } 690 grouping route-filter-set { 691 description "Specify route filtering rules for import/export"; 692 uses route-import-set; 693 uses route-export-set; 694 uses route-import-export-set; 695 } 697 grouping bgp-label-mode { 698 description "MPLS/VPN label allocation mode"; 699 container config { 700 description "Configuration parameters for label allocation mode"; 701 leaf label-mode { 702 type bgp-label-mode; 703 description "Label allocation mode"; 704 } 705 } 706 container state { 707 config "false" ; 708 description "State information for label allocation mode"; 709 leaf label-mode { 710 type bgp-label-mode; 711 description "Label allocation mode"; 712 } 713 } 714 } 716 grouping retain-route-targets { 717 description "Grouping for route target accept"; 718 container retain-rts { 719 description "Control route target acceptance behavior for ASBRs"; 720 container config { 721 description "Configuration parameters for retaining route targets"; 722 leaf all { 723 type empty; 724 description "Disable filtering of all route-targets"; 725 } 726 leaf route-policy { 727 type string; 728 description "Filter routes as per filter policy name 729 TBD: leafref to IETF routing policy model"; 730 } 731 } 732 container state { 733 config "false" ; 734 description "State information for retaining route targets"; 735 leaf all { 736 type empty; 737 description "Disable filtering of all route-targets"; 738 } 739 leaf route-policy { 740 type string; 741 description "Filter routes as per filter policy name"; 742 } 743 } 744 } 745 } 747 grouping nexthop-opts { 748 description "Next hop control options for inter-as route exchange"; 749 leaf next-hop-self { 750 type boolean; 751 description "Set nexthop of the route to self when advertising routes"; 752 } 753 leaf next-hop-unchanged { 754 type boolean; 755 description "Enforce no nexthop change when advertising routes"; 756 } 757 } 759 grouping asbr-nexthop-options { 760 description "Nexthop parameters for inter-as VPN options "; 761 container nexthop-options { 762 description "Nexthop related options for inter-as options"; 763 container config { 764 description "Configuration parameters for nexthop options"; 765 uses nexthop-opts; 766 } 767 container state { 768 description "State information for nexthop options" ; 769 uses nexthop-opts; 770 } 771 } 772 } 774 // Augmentations of base models. 776 // Route-distinguisher is added in BGP global level. BGP is supposed to be 777 // under scope of VRF as a routing instance, once BGP model is augmented. 778 // Which means rd defined here will be per VPN per BGP instance. 779 // 780 augment "/bgp:bgp/bgp:global" { 781 description "Route distinguisher under BGP global mode"; 782 uses bgp-rd ; 783 } 785 // route import/export rules in applicable address families. 786 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-unicast" { 787 description "Route import/export rules under BGP Address family mode"; 788 uses route-filter-set; 789 } 791 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv6-unicast" { 792 description "Route import/export rules under BGP Address family mode"; 793 uses route-filter-set ; 794 } 796 /* multicast safi is not in the BGP base model yet. 797 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv6-multicast" { 798 description "Route import/export rules under BGP Address family mode"; 799 uses route-filter-set ; 800 } 802 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-multicast" { 803 description "Route import/export rules under BGP Address family mode"; 804 uses route-filter-set ; 805 } 806 */ 808 // Retain route-target for inter-as option ASBR-B knob. 809 // vpnv4/vpnv6/mvpn address-family only. 810 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:l3vpn-ipv4-unicast" { 811 description "Retain route targets for ASBR scenario"; 812 uses retain-route-targets; 813 } 815 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:l3vpn-ipv6-unicast" { 816 description "Retain route targets for ASBR scenario"; 817 uses retain-route-targets; 818 } 820 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:l3vpn-ipv4-multicast" { 821 description "Retain route targets for ASBR scenario"; 822 uses retain-route-targets; 823 } 825 /* MPVN address family is not in BASE BGP model yet. 826 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-mpvn" { 827 description "Retain route targets for ASBR scenario"; 828 uses retain-route-targets; 829 } 831 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv6-mpvn" { 832 description "Retain route targets for ASBR scenario"; 833 uses retain-route-targets; 834 } 835 */ 837 // Label allocation mode configuration. Certain AFs only. 838 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-unicast" { 839 description "Augment BGP global AF mode for label allocation mode configuration"; 840 uses bgp-label-mode ; 841 } 843 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv6-unicast" { 844 description "Augment BGP global AF mode for label allocation mode configuration"; 845 uses bgp-label-mode ; 847 } 849 //Nexthop options for the inter-as option-B and option-C ASBR peering. 850 augment "/bgp:bgp/bgp:neighbors/bgp:neighbor" { 851 description "Augment BGP NBR mode with nexthop options for inter-as ASBRs"; 852 uses asbr-nexthop-options; 853 } 855 augment "/bgp:bgp/bgp:peer-groups/bgp:peer-group" { 856 description "Augment BGP peer-group mode with nexthop options for inter-as ASBRs"; 857 uses asbr-nexthop-options; 858 } 860 augment "/bgp:bgp/bgp:neighbors/bgp:neighbor/bgp:afi-safis/bgp:afi-safi" { 861 description "Augment BGP NBR AF mode with nexthop options for inter-as ASBRs"; 862 uses asbr-nexthop-options; 863 } 865 augment "/bgp:bgp/bgp:peer-groups/bgp:peer-group/bgp:afi-safis/bgp:afi-safi" { 866 description "Augment BGP peer-group AF mode with nexthop options for inter-as ASBRs"; 867 uses asbr-nexthop-options; 868 } 870 // Add route import-export rules in VRF level (routing instance container in ietf-routing model). 871 augment "/rt:routing/rt:routing-instance" { 872 description "Augment routing instance container for per VRF import/export rules configuration"; 873 uses route-filter-set ; 874 } 876 // bgp mpls forwarding enable required for inter-as option AB. 877 // mpls label secruity for inter-as option-B 878 augment "/if:interfaces/if:interface" { 879 description "BGP mpls forwarding mode configuration on interface for ASBR scenario"; 880 uses forwarding-mode ; 881 uses label-security; 882 } 883 } 885 887 5. IANA Considerations 889 6. Security Considerations 891 The transport protocol used for sending the BGP L3VPN data MUST 892 support authentication and SHOULD support encryption. The data-model 893 by itself does not create any security implications. 895 This draft does not change any underlying security issues inherent in 896 [I-D.ietf-netmod-routing-cfg] and [I-D.shaikh-idr-bgp-model]. 898 7. Acknowledgements 900 The authors would like to thank TBD for their detail reviews and 901 comments. 903 8. References 905 8.1. Normative References 907 [I-D.ietf-netmod-routing-cfg] 908 Lhotka, L., "A YANG Data Model for Routing Management", 909 draft-ietf-netmod-routing-cfg-15 (work in progress), May 910 2014. 912 [I-D.shaikh-idr-bgp-model] 913 Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K., 914 Bansal, D., Clemm, A., Alex, A., Jethanandani, M., and X. 915 Liu, "BGP Model for Service Provider Networks", draft- 916 shaikh-idr-bgp-model-02 (work in progress), June 2015. 918 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 919 Requirement Levels", BCP 14, RFC 2119, 920 DOI 10.17487/RFC2119, March 1997, 921 . 923 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 924 DOI 10.17487/RFC2547, March 1999, 925 . 927 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 928 DOI 10.17487/RFC2629, June 1999, 929 . 931 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 932 Text on Security Considerations", BCP 72, RFC 3552, 933 DOI 10.17487/RFC3552, July 2003, 934 . 936 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 937 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 938 DOI 10.17487/RFC4271, January 2006, 939 . 941 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 942 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 943 2006, . 945 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 946 "Multiprotocol Extensions for BGP-4", RFC 4760, 947 DOI 10.17487/RFC4760, January 2007, 948 . 950 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 951 the Network Configuration Protocol (NETCONF)", RFC 6020, 952 DOI 10.17487/RFC6020, October 2010, 953 . 955 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 956 and A. Bierman, Ed., "Network Configuration Protocol 957 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 958 . 960 8.2. Informative References 962 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 963 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 964 2009, . 966 Authors' Addresses 968 Keyur Patel 969 Cisco 970 170 W. Tasman Drive 971 San Jose, CA 95134 972 USA 974 Email: keyupate@cisco.com 976 Dhanendra Jain 977 Cisco 978 170 W. Tasman Drive 979 San Jose, CA 95134 980 USA 982 Email: dhjain@cisco.com