idnits 2.17.1 draft-keyupate-bess-bgp-l3vpn-cfg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 29 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 245 has weird spacing: '...-target str...' == Line 250 has weird spacing: '...-target str...' == Line 256 has weird spacing: '...-target str...' == Line 261 has weird spacing: '...-target str...' == Line 267 has weird spacing: '...-target str...' == (10 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 (October 16, 2015) is 3113 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2547' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 795, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 813, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 830, 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: April 18, 2016 October 16, 2015 7 Yang Data Model for BGP/MPLS L3 VPNs 8 draft-keyupate-bess-bgp-l3vpn-cfg-00.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 April 18, 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.3. VRF Specific Configuration . . . . . . . . . . . . . . . 7 73 3.3.1. VRF interface . . . . . . . . . . . . . . . . . . . . 7 74 3.3.2. Import and export route-targets . . . . . . . . . . . 7 75 3.3.3. Forwarding mode . . . . . . . . . . . . . . . . . . . 7 76 4. BGP Yang Module . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 8.2. Informative References . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 YANG [RFC6020] is a data definition language that was introduced to 88 define the contents of a conceptual data store that allows networked 89 devices to be managed using NETCONF [RFC6241]. YANG is proving 90 relevant beyond its initial confines, as bindings to other interfaces 91 (e.g. ReST) and encodings other than XML (e.g. JSON) are being 92 defined. Furthermore, YANG data models can be used as the basis of 93 implementation for other interfaces, such as CLI and programmatic 94 APIs. 96 This document defines a YANG model that can be used to configure and 97 manage BGP L3VPNs [RFC4364]. There are two parts of the L3VPN BGP 98 model. The first part of the model augments base BGP data model 99 defined in [I-D.shaikh-idr-bgp-model] for BGP specific L3VPN 100 configuration and the second part of the model augments the Routing 101 data model defined in [I-D.ietf-netmod-routing-cfg] for VRF specific 102 L3VPN configuration. This model defines control knobs for 103 configuration for that purpose, as well as a few data nodes that can 104 be used to monitor health and gather statistics. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Definitions and Acronyms 114 AF: Address Family 116 AS: Autonomous System 118 ASBR: Autonomous System Border Router 120 BGP: Border Gateway Protocol 122 L3VPN: Layer 3 VPN 124 NETCONF: Network Configuration Protocol 126 ReST: Representational State Transfer, a style of stateless interface 127 and protocol that is generally carried over HTTP 129 RTFilter: Route Filter 131 VPN: Virtual Private Network 133 YANG: Data definition language for NETCONF 135 3. Design of L3VPN Routing Data Model 137 3.1. Overview 139 L3VPN specific configuration and state data is defined in BGP 140 specific model and VRF specific model. This document does not cover 141 the model for some of the other entities involved in L3 VPNs such as 142 IGPs and MPLS. 144 3.2. BGP Specific Configuration 146 The BGP specific configuration for L3VPNs is augmentation of base BGP 147 model defined in [I-D.shaikh-idr-bgp-model]. In particular, 148 containers for BGP global mode and BGP address family mode are 149 augmented with L3VPN specific attributes and parameters. It is 150 noteworthy that current form of BGP model needs to align with netmod 151 routing model such that BGP entry level container becomes an instance 152 of routing-instance container in netmod routing model. The 153 augmentation proposed in this document are based on current state of 154 BGP yang model as defined in [I-D.shaikh-idr-bgp-model] 156 3.2.1. VPN peering 158 For Peering between PE routers, specific VPN address family needs to 159 be enabled under BGP container in the default routing-instance. Base 160 BGP draft [I-D.shaikh-idr-bgp-model] has l3vpn address family in the 161 list of identity refs for AFs under global and neighbor modes. The 162 same is augmented here for additional knobs. For peering with CE 163 routers the VRF specific BGP configurations such as neighbors and 164 address-family are covered in base BGP config, except that such 165 configuration will be in the context of a VRF. The instance of BGP 166 in this case would be a separate instance in the context of routing 167 instance realizing a VRF. 169 3.2.2. Route distinguisher 171 Route distinguisher (RD) is an unique identifier used in VPN routes 172 to distinguish prefixes across different VPNs. RD is 8 byte field as 173 defined in the [RFC4364]. Where the first two bytes refer to type 174 followed by 6 bytes of value. The format of the value is dependent 175 on type. In the yang model, RDs are defined by augmenting BGP global 176 mode. Note that BGP will be modeled as an instance of routing- 177 protocol under a routing-instance container in the overall routing 178 model. Further a routing-instance is representation of VRF in 179 routing model. Therefore providing RD under BGP global level results 180 into RDs being in the context of VRF under BGP. 182 3.2.3. Import and export route target 184 Route-target (RT) community is an extended community used to specify 185 the rules for importing and exporting the routes for each VRF. This 186 is applicable in the context of an address-family under the VRF. 187 Since BGP instance is in the context of each routing-instance (aka 188 VRF), the import/export rules can be specified per global address- 189 family under BGP. An import rule is modeled as list of RTs or a 190 policy leafref specifying the list of RTs, which must appear in 191 routes a VRF is interested in importing. Similarly an export rule is 192 set or RTs or a policy leafref specifying the list of RTs which 193 should be attached to routes exported from this VRF. In the case 194 where policy is used to specify the RTs, a reference to the policy 195 via leafref is used in this model, but actual definition of policy is 196 outside the scope of this document. 198 3.2.4. Route target retention 200 This configuration is required on ASBRs to retain the VPN routes for 201 certain or all route-targets. Since ASBRs do not require that VRFs 202 be configured, but need to retain the IPv4 VPN prefix information. 203 This configuration augments BGP global AF containers, particularly 204 the VPN address family containers. 206 3.2.5. Label Mode 208 Label mode knobs control the label allocation behavior for VRF 209 routes. Such as to specify Per-CE, Per-VRF and Per-Prefix label 210 allocation. These knobs augment BGP global AF containers in the 211 context of default routing instance. 213 module: bgp-l3vpn 215 +--rw bgp? 216 +--rw global 217 ... 218 | +--rw l3vpn:route-distinguisher 219 | +--rw l3vpn:config 220 | | +--rw l3vpn:rd-type? bgp-rd-type 221 | | +--rw l3vpn:as? uint16 222 | | +--rw l3vpn:as-index? uint32 223 | | +--rw l3vpn:as-4byte? uint32 224 | | +--rw l3vpn:as-4byte-index? uint16 225 | | +--rw l3vpn:address? inet:ipv4-address 226 | | +--rw l3vpn:address-index? uint16 227 | +--ro l3vpn:state 228 | +--ro l3vpn:rd-type? bgp-rd-type 229 | +--ro l3vpn:as? uint16 230 | +--ro l3vpn:as-index? uint32 231 | +--ro l3vpn:as-4byte? uint32 232 | +--ro l3vpn:as-4byte-index? uint16 233 | +--ro l3vpn:address? inet:ipv4-address 234 | +--ro l3vpn:address-index? uint16 236 ... 238 | +--rw afi-safis 239 | | +--rw afi-safi [afi-safi-name] 240 | | +--rw ipv4-unicast 241 | | | +--rw l3vpn:export-routes 242 | | | | +--rw l3vpn:config 243 | | | | | +--rw l3vpn:route-targets 244 | | | | | | +--rw l3vpn:route-target-list [route-target] 245 | | | | | | +--rw l3vpn:route-target string 246 | | | | | +--rw l3vpn:route-target-policy? string 247 | | | | +--ro l3vpn:state 248 | | | | +--ro l3vpn:route-targets 249 | | | | | +--ro l3vpn:route-target-list [route-target] 250 | | | | | +--ro l3vpn:route-target string 251 | | | | +--ro l3vpn:route-target-policy? string 252 | | | +--rw l3vpn:import-routes 253 | | | | +--rw l3vpn:config 254 | | | | | +--rw l3vpn:route-targets 255 | | | | | | +--rw l3vpn:route-target-list [route-target] 256 | | | | | | +--rw l3vpn:route-target string 257 | | | | | +--rw l3vpn:route-target-policy? string 258 | | | | +--ro l3vpn:state 259 | | | | +--ro l3vpn:route-targets 260 | | | | | +--ro l3vpn:route-target-list [route-target] 261 | | | | | +--ro l3vpn:route-target string 262 | | | | +--ro l3vpn:route-target-policy? string 263 | | | +--rw l3vpn:import-export-routes 264 | | | | +--rw l3vpn:config 265 | | | | | +--rw l3vpn:route-targets 266 | | | | | | +--rw l3vpn:route-target-list [route-target] 267 | | | | | | +--rw l3vpn:route-target string 268 | | | | | +--rw l3vpn:route-target-policy? string 269 | | | | +--ro l3vpn:state 270 | | | | +--ro l3vpn:route-targets 271 | | | | | +--ro l3vpn:route-target-list [route-target] 272 | | | | | +--ro l3vpn:route-target string 273 | | | | +--ro l3vpn:route-target-policy? string 275 ... 277 | | | +--rw l3vpn:config 278 | | | | +--rw l3vpn:label-mode? bgp-label-mode 279 | | | +--ro l3vpn:state 280 | | | +--ro l3vpn:label-mode? bgp-label-mode 282 ... 284 | | +--rw l3vpn-ipv4-unicast 285 | | | +--rw l3vpn:retain-rts 286 | | | +--rw l3vpn:config 287 | | | | +--rw l3vpn:retain-all? empty 288 | | | | +--rw l3vpn:retain-policy-filter? string 289 | | | +--ro l3vpn:state 290 | | | +--ro l3vpn:retain-all? empty 291 | | | +--ro l3vpn:retain-policy-filter? string 293 3.3. VRF Specific Configuration 295 VRF specific configuration is defined by augmenting the IETF routing 296 model. The routing-instance defined in the IETF routing model refers 297 to a named VRF instance. 299 3.3.1. VRF interface 301 To associate a VRF instance with an interface, the interface should 302 be defined in the context of routing-instance representing a VRF. 303 This is covered in base routing model [I-D.ietf-netmod-routing-cfg]. 305 3.3.2. Import and export route-targets 307 Under the routing-instance modeled as VRF, the default-rib container 308 provides list of address family specific ribs. Default ribs for ipv4 309 and ipv6 address-family are augmented to define the import and export 310 route-target sets. This set is modeled as a list of rout-targets as 311 defined in [RFC4364]. In addition, a route-target-policy can be 312 applied at this level to set the route-targets. Policyref to IETF 313 policy model is TBD. 315 3.3.3. Forwarding mode 317 This configuration augments interface list under interface container 318 under a routing-instance as defined in IETF routing model 319 [I-D.ietf-netmod-routing-cfg]. Forwarding mode configuration is 320 required under the ASBR facing interface to enable mpls forwarding 321 for directly connected BGP peers. 323 module: bgp-l3vpn 325 +--rw routing 326 +--rw routing-instance [name] 327 .... 329 | | +--rw default-rib [address-family] 330 | | +--rw address-family identityref 331 | | +--rw rib-name string 332 | | +--rw l3vpn:export-routes 333 | | | +--rw l3vpn:config 334 | | | | +--rw l3vpn:route-targets 335 | | | | | +--rw l3vpn:route-target-list [route-target] 336 | | | | | +--rw l3vpn:route-target string 337 | | | | +--rw l3vpn:route-target-policy? string 338 | | | +--ro l3vpn:state 339 | | | +--ro l3vpn:route-targets 340 | | | | +--ro l3vpn:route-target-list [route-target] 341 | | | | +--ro l3vpn:route-target string 342 | | | +--ro l3vpn:route-target-policy? string 343 | | +--rw l3vpn:import-routes 344 | | | +--rw l3vpn:config 345 | | | | +--rw l3vpn:route-targets 346 | | | | | +--rw l3vpn:route-target-list [route-target] 347 | | | | | +--rw l3vpn:route-target string 348 | | | | +--rw l3vpn:route-target-policy? string 349 | | | +--ro l3vpn:state 350 | | | +--ro l3vpn:route-targets 351 | | | | +--ro l3vpn:route-target-list [route-target] 352 | | | | +--ro l3vpn:route-target string 353 | | | +--ro l3vpn:route-target-policy? string 354 | | +--rw l3vpn:import-export-routes 355 | | +--rw l3vpn:config 356 | | | +--rw l3vpn:route-targets 357 | | | | +--rw l3vpn:route-target-list [route-target] 358 | | | | +--rw l3vpn:route-target string 359 | | | +--rw l3vpn:route-target-policy? string 360 | | +--ro l3vpn:state 361 | | +--ro l3vpn:route-targets 362 | | | +--ro l3vpn:route-target-list [route-target] 363 | | | +--ro l3vpn:route-target string 364 | | +--ro l3vpn:route-target-policy? string 366 .... 368 | +--rw interfaces 369 | | +--rw interface [name] 370 | | +--rw name if:interface-ref 371 | | +--rw l3vpn:forwarding-mode 372 | | +--rw l3vpn:config 373 | | | +--rw l3vpn:forwarding-mode? fwd-mode-type 374 | | +--rw l3vpn:state 375 | | +--rw l3vpn:forwarding-mode? fwd-mode-type 377 4. BGP Yang Module 379 file "bgp-l3vpn@2013-07-15.yang" 381 module bgp-l3vpn { 382 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-yang"; 383 // replace with IANA namespace when assigned 384 prefix l3vpn ; 386 import ietf-inet-types { 387 prefix inet; 388 } 390 import ietf-routing { 391 prefix rt; 392 revision-date 2015-05-25; 393 } 394 import bgp { 395 prefix bgp; 396 } 398 organization 399 "Cisco Systems 400 170 West Tasman Drive 401 San Jose, CA 95134-1706 402 USA"; 404 description 405 "This YANG module defines the configuration for the BGP Layer 3 VPNs. 406 It augments the IETF bgp yang model and IETF routing model to add L3VPN specific 407 configuration and operational knobs. 409 Terms and Acronyms 411 AS : Autonomous System 413 ASBR : Autonomous Systems Border Router 415 BGP (bgp): Border Gateway Protocol 417 CE : Customer Edge 419 IP (ip): Internet Protocol 421 IPv4 (ipv4):Internet Protocol Version 4 423 IPv6 (ipv6): Internet Protocol Version 6 424 PE : Provider Edge 426 RT : Route Target 428 RD : Route Distinguisher 430 VPN : Virtual Private Network 432 "; 434 revision 2015-10-15 { 435 description 436 "Initial revision."; 437 reference 438 "RFC XXXX: A YANG Data Model for L3VPN config management"; 439 } 441 typedef bgp-rd-type { 442 type enumeration { 443 enum type-0 { 444 description "AS format RD as type-0 in RFC4364"; 445 } 446 enum type-1 { 447 description "4-byte AS format RD as type-1 in RFC4364"; 448 } 449 enum type-2 { 450 description "IPv4 address format RD as type-2 in RFC4364"; 451 } 452 enum auto { 453 description "Automatic RD value assignment"; 454 } 455 } 456 description "BGP route distinguisher format as described in RFC4364"; 457 } 459 grouping rd-value-type0 { 460 leaf as { 461 type uint16; 462 description "AS number 2 bytes"; 463 } 464 leaf as-index { 465 type uint32; 466 description "AS index 4 bytes"; 467 } 468 } 469 grouping rd-value-type1 { 470 leaf as-4byte { 471 type uint32; 472 description "AS number 4 bytes"; 473 } 474 leaf as-4byte-index { 475 type uint16; 476 description "AS index 2 bytes"; 477 } 478 } 480 grouping rd-value-type2 { 481 leaf address { 482 type inet:ipv4-address; 483 description "IPv4 address"; 484 } 485 leaf address-index { 486 type uint16; 487 description "AS index 2 bytes"; 488 } 489 } 491 grouping bgp-rd-spec { 492 description "BGP route-distinguisher as per RFC4364"; 493 leaf rd-type { 494 type bgp-rd-type; 495 description "Route distinguisher format type as per RFC4364"; 496 } 497 uses rd-value-type0 { 498 when "rd-type = 'type-0'" ; 499 } 500 uses rd-value-type1 { 501 when "rd-type = 'type-1'" ; 502 } 503 uses rd-value-type2 { 504 when "rd-type = 'type-2'" ; 505 } 506 } 507 grouping bgp-rd { 508 container route-distinguisher { 509 container config { 510 uses bgp-rd-spec ; 511 } 512 container state { 513 config "false" ; 514 uses bgp-rd-spec ; 515 } 516 } 518 } 520 typedef bgp-label-mode { 521 description "Label allocation mode for prefixes in a VRF"; 522 type enumeration { 523 enum per-ce { 524 description "Allocate labels per CE"; 525 } 526 enum per-prefix { 527 description "Allocate labels per prefix"; 528 } 529 enum per-vrf { 530 description "Allocate labels per VRF"; 531 } 532 } 533 description "BGP label allocation mode"; 534 } 536 typedef fwd-mode-type { 537 type enumeration { 538 enum mpls { 539 description "Forwarding mode mpls"; 540 } 541 } 542 description "Enable forwarding mode under ASBR facing interface"; 543 } 545 grouping forwarding-mode { 546 container forwarding-mode { 547 container config { 548 leaf forwarding-mode { 549 type fwd-mode-type; 550 description "Forwarding mode for this interface"; 551 } 552 } 553 container state { 554 leaf forwarding-mode { 555 type fwd-mode-type; 556 description "Forwarding mode for this interface"; 557 } 558 } 559 } 560 } 561 grouping route-target-set { 562 description 563 "Extended community route-target set "; 564 container route-targets { 565 description 566 "Route-target"; 567 list route-target-list { 568 description 569 "List of route-targets" ; 570 key "route-target"; 571 leaf route-target { 572 type string { 573 pattern '([0-9]+:[0-9]+)'; 574 } 575 } 576 } 577 } 578 leaf route-target-policy { 579 description 580 "Reference to the policy containing set of routes. 581 "TBD: leafref to policy entry in IETF policy model"; 582 type string; 583 } 584 } 586 grouping route-import-set { 587 container import-routes { 588 description "Set of route-targets to match to import routes into VRF"; 589 container config { 590 description 591 "Import routes"; 592 uses route-target-set ; 593 } 594 container state { 595 config "false" ; 596 description 597 "Import routes"; 598 uses route-target-set ; 599 } 600 } 601 } 602 grouping route-export-set { 603 container export-routes { 604 description "Set of route-targets to attach with exported routes from VRF"; 605 container config { 606 description 607 "Export routes"; 608 uses route-target-set ; 609 } 610 container state { 611 config "false" ; 612 description 613 "Export routes"; 614 uses route-target-set ; 615 } 616 } 617 } 619 grouping route-import-export-set { 620 container import-export-routes { 621 container config { 622 description "Both import/export routes"; 623 uses route-target-set; 624 } 625 container state { 626 config "false" ; 627 description "Both import/export routes"; 628 uses route-target-set; 629 } 630 } 631 } 633 grouping route-filter-set { 634 uses route-import-set; 635 uses route-export-set; 636 uses route-import-export-set; 637 } 639 grouping bgp-label-mode { 640 description "MPLS/VPN label allocation mode"; 641 container config { 642 leaf label-mode { 643 type bgp-label-mode; 644 description "Label allocation mode"; 645 } 646 } 647 container state { 648 config "false" ; 649 leaf label-mode { 650 type bgp-label-mode; 651 description "Label allocation mode"; 652 } 653 } 654 } 656 grouping retain-route-targets { 657 description "Grouping for route target accept"; 658 container retain-rts { 659 description "Control route target acceptance behavior for ASBRs"; 660 container config { 661 leaf retain-all { 662 type empty; 663 description "Disable filtering of all route-targets"; 664 } 665 leaf retain-policy-filter { 666 type string; 667 description "Filter routes as per filter policy name"; 668 } 669 } 670 container state { 671 config "false" ; 672 leaf retain-all { 673 type empty; 674 description "Disable filtering of all route-targets"; 675 } 676 leaf retain-policy-filter { 677 type string; 678 description "Filter routes as per filter policy name"; 679 } 680 } 681 } 682 } 684 // Augmentations of base models. 686 // Route-distinguisher is added in BGP global level. BGP is supposed to be 687 // under scope of VRF as a routing instance, once BGP model is augmented. 688 // Which means rd defined here will be per VPN per BGP instance. 689 // 690 augment "/bgp:bgp/bgp:global/" { 691 uses bgp-rd ; 692 } 694 // route import/export rules in applicable address families. 695 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-unicast/" { 696 uses route-filter-set; 697 } 699 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-multicast/" { 700 uses route-filter-set ; 701 } 703 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv6-unicast/" { 704 uses route-filter-set ; 705 } 707 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv6-multicast/" { 708 uses route-filter-set ; 709 } 711 // Retain route-target for inter-as option ASBR knob. 712 // vpnv4/vpnv6/mvpn address-family only. 713 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:l3vpn-ipv4-unicast/" { 714 uses retain-route-targets; 715 } 717 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:l3vpn-ipv6-unicast/" { 718 uses retain-route-targets; 719 } 721 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:l3vpn-ipv4-multicast/" { 722 uses retain-route-targets; 723 } 725 /* MPVN address family is not in BASE BGP model yet. 726 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-mpvn/" { 727 uses retain-route-targets; 728 } 730 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv6-mpvn/" { 731 uses retain-route-targets; 732 } 733 */ 735 // Label allocation mode configuration. Certain AFs only. 736 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv4-unicast/" { 737 uses bgp-label-mode ; 738 } 740 augment "/bgp:bgp/bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:ipv6-unicast/" { 741 uses bgp-label-mode ; 742 } 744 // Add route import-export rules in VRF-AF mode (routing instance default rib per address family). 745 augment "/rt:routing/rt:routing-instance/rt:default-ribs/rt:default-rib/" { 746 uses route-filter-set ; 747 } 749 // bgp mpls forwarding enable required for inter-as option AB. 750 augment "/rt:routing/rt:routing-instance/rt:interfaces/rt:interface/" { 751 uses forwarding-mode ; 752 } 753 } 754 755 5. IANA Considerations 757 6. Security Considerations 759 The transport protocol used for sending the BGP L3VPN data MUST 760 support authentication and SHOULD support encryption. The data-model 761 by itself does not create any security implications. 763 This draft does not change any underlying security issues inherent in 764 [I-D.ietf-netmod-routing-cfg] and [I-D.shaikh-idr-bgp-model]. 766 7. Acknowledgements 768 The authors would like to thank TBD for their detail reviews and 769 comments. 771 8. References 773 8.1. Normative References 775 [I-D.ietf-netmod-routing-cfg] 776 Lhotka, L., "A YANG Data Model for Routing Management", 777 draft-ietf-netmod-routing-cfg-15 (work in progress), May 778 2014. 780 [I-D.shaikh-idr-bgp-model] 781 Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K., 782 Bansal, D., Clemm, A., Alex, A., Jethanandani, M., and X. 783 Liu, "BGP Model for Service Provider Networks", draft- 784 shaikh-idr-bgp-model-02 (work in progress), June 2015. 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, 788 DOI 10.17487/RFC2119, March 1997, 789 . 791 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 792 DOI 10.17487/RFC2547, March 1999, 793 . 795 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 796 DOI 10.17487/RFC2629, June 1999, 797 . 799 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 800 Text on Security Considerations", BCP 72, RFC 3552, 801 DOI 10.17487/RFC3552, July 2003, 802 . 804 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 805 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 806 DOI 10.17487/RFC4271, January 2006, 807 . 809 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 810 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 811 2006, . 813 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 814 "Multiprotocol Extensions for BGP-4", RFC 4760, 815 DOI 10.17487/RFC4760, January 2007, 816 . 818 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 819 the Network Configuration Protocol (NETCONF)", RFC 6020, 820 DOI 10.17487/RFC6020, October 2010, 821 . 823 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 824 and A. Bierman, Ed., "Network Configuration Protocol 825 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 826 . 828 8.2. Informative References 830 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 831 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 832 2009, . 834 Authors' Addresses 836 Keyur Patel 837 Cisco 838 170 W. Tasman Drive 839 San Jose, CA 95134 840 USA 842 Email: keyupate@cisco.com 844 Dhanendra Jain 845 Cisco 846 170 W. Tasman Drive 847 San Jose, CA 95134 848 USA 850 Email: dhjain@cisco.com