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