Internet DRAFT - draft-ray-idr-route-constrain-scope
draft-ray-idr-route-constrain-scope
Inter-Domain Routing S. Ray
Internet-Draft A. Sreekantiah
Intended status: Standards Track Cisco Systems, Inc.
Expires: August 18, 2014 February 14, 2014
Signaling AFI-SAFI scope for Constrained Route Distribution
draft-ray-idr-route-constrain-scope-00
Abstract
The Route Constrain address family can be used by a BGP speaker to
signal a neighbor its interest in receiving only the routes with a
matching route target (RT) extended community. This signaling is
afi-safi agnostic; the sender of a route constrain NLRI with an RT
expresses its interest in receiving routes with that RT for all afi-
safi. The ability to further scope a given RT to a list of afi-safi
would simplify network operations; then optimal route filtering would
no longer require that the set of RTs used for different afi-safi be
disjoint.
This document proposes a simple extended community based backward
compatible method to associate the list of afi-safi of interest to a
route constrain NLRI and discusses the operational procedure.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014.
Ray & Sreekantiah Expires August 18, 2014 [Page 1]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Sub-optimality of route constrain in shared RT
deployments . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Unused route advertisement and retention . . . . . . 3
1.1.2. Need for route-refresh on some configuration changes 4
1.2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Use of disjoint set of RTs . . . . . . . . . . . . . 5
1.2.2. New route constrain NLRI . . . . . . . . . . . . . . 5
1.2.3. Using BGP Path Attribute . . . . . . . . . . . . . . 5
2. AFI-SAFI Extended Community . . . . . . . . . . . . . . . . . 6
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Manageability Considerations . . . . . . . . . . . . . . . . 10
5.1. Configuration Management . . . . . . . . . . . . . . . . 10
5.2. Operational Considerations . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
A VPN route (such as VPNv4/VPNv6 unicast [RFC4364], Multicast VPN
[RFC6513], Layer 2 VPN [RFC6624], Flow-spec [RFC5575], etc.) is
retained by a BGP speaker only if the route is of interest to itself
- e.g., if the route belongs to a local VPN, or if it needs to be
sent to one of its neighbors. The VPN membership of a route is
determined by the set of route target (RT) extended communities
attached to the route. Therefore the speaker's neighbors need to
Ray & Sreekantiah Expires August 18, 2014 [Page 2]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
send only those routes to the speaker that carry one or more RTs that
are of interest to the speaker.
[RFC4684] defines a new address family called Route Target Constrain
(RTC) using which a BGP speaker can signal its neighbors the set of
RTs it is interested in. For instance, if one of speaker A's locally
configured VPNs is a member of RT:1:1 (i.e., if a local VRF imports
RT:1:1), then speaker A advertises an RTC NLRI with RT:1:1 to speaker
B. In turn speaker B sends to speaker A only the VPN routes with
RT:1:1. [I-D.ietf-idr-bgp-ipv6-rt-constrain] extends the NLRI
definition to accommodate longer IPv6 Specific Route Target extended
communities [RFC5701].
The scope of an RTC NLRI RT:X:Y spans all address family routes with
RT:X:Y. This design choice makes RTC a standard route filtering
mechanism for all BGP based VPN solutions. On the flip side, RTC can
deliver optimal filtering only when the set of RTs used by an address
family afi=x/safi=y is disjoint from the set of RTs used by any other
address family afi=z/safi=w. The following section illustrates some
of the problems when shared RTs are used.
1.1. Sub-optimality of route constrain in shared RT deployments
1.1.1. Unused route advertisement and retention
+-------------+---+ +---+-------------+
|IPv4 VRF | | RTC:1:1 +---+ RTC:1:1 | |IPv4 VRF |
|export RT:1:1| |<---------------| | <------------ | |import RT:1:1|
+-------------| A +----------------+ B +---------------+ C |-------------+
|IPv6 VRF | |--------------->| | ------------> | |
|export RT:1:1| | VPNv4 unicast +---+ VPNv4 unicast | |
+-------------+---+ VPNv6 unicast VPNv6 unicast +---+
Figure 1: Sub-optimality: Unused route advertisement and retention
Suppose speaker A has local VPNv4 unicast and VPNv6 unicast routes,
both with membership in RT:1:1. Speaker B is a route-reflector with
client speaker C. Speaker C only needs VPNv4 unicast routes with
RT:1:1 for its VPN with membership in RT:1:1. Speaker C sends an RTC
NLRI RT:1:1 to speaker B and speaker B in turn sends an RTC NLRI
RT:1:1 to speaker A. Spearker A sends its VPNv4 unicast and VPNv6
unicast routes with RT:1:1 to speaker B. Speaker B retains routes
from both address families and sends all of them to speaker C.
Speaker C retains only the VPNv4 unicast routes and drops VPNv6
unicast routes.
Ray & Sreekantiah Expires August 18, 2014 [Page 3]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
In this deployment, advertisement of VPNv6 unicast routes are not
needed, but they are still advertised. Second, speaker B (the route-
reflector) does not need to retain any VPNv6 unicast route since its
only client, speaker C, does not need them. But speaker B still
retains the VPNv6 unicast routes. Therefore, route constrain does
not lead to optimal route filtering.
1.1.2. Need for route-refresh on some configuration changes
RTC:1:1
+-------------+---+ RTC:1:1 +---+-------------+
|IPv4 VRF | | +---+ | |IPv4 VRF |
|export RT:1:1| | | | | |import RT:1:1|
+-------------| A +----------------+ B +---------------+ C |-------------+
|IPv6 VRF | | | | | |IPv6 VRF .
|export RT:1:1| | +---+ | |import RT:1:1.
+-------------+---+ VPNv4 unicast +---+.............+
VPNv6 unicast VPNv4 unicast
Figure 2: Sub-optimality: Route refresh
In the deployment shown in Figure 1, in steady state speaker C
retains the VPNv4 unicast routes for RT:1:1 and speaker B has an RTC
NLRI path for RT:1:1 from speaker C. Now suppose the operator adds a
new IPv6 VRF on speaker C that imports RT:1:1 depicted in Figure 2.
Now speaker C needs to get the VPNv6 unicast routes from speaker B
with RT:1:1. At this point, if speaker C advertises the RTC NLRI
RT:1:1 to speaker B again, speaker B would receive an identical path
from speaker C. Standard BGP implementation practice is to ignore
identical updates (i.e., not mark the local prefix for further
processing), in which case speaker B will not send the VPN routes to
speaker C again. Thus, speaker C would need to send a route refresh
message to speaker B and receive all VPNv6 routes (this set of routes
is larger than necessary if RT:1:1 is not the first RT imported by an
IPv6 VRF on speaker C).
There are possible implementation tricks to get around this issue
(e.g., readvertise the RTC NLRI RT:1:1 from speaker C after changing
an attribute such as local-preference). However, a standardized
solution without possible side-effects is much more preferable.
1.2. Solutions
Ray & Sreekantiah Expires August 18, 2014 [Page 4]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
1.2.1. Use of disjoint set of RTs
Not using shared RTs by ensuring that the set of RTs used by one
address family is disjoint from the set of RTs used by any other
address family avoids the problems. However, this constraint poses a
burden on the network operation, especially in large networks that
are run by multiple loosely coupled departments, where configurations
change frequently. Therefore, a protocol level solution is more
preferable.
1.2.2. New route constrain NLRI
[I-D.dong-idr-vpn-route-constrain] proposes a new NLRI format that
includes the safi value (among other fields) and use different afi
values during capability negotiations. This is not a backward
compatible solution. Given many existing (large) deployments of
[RFC4684] based multi-vendor networks, backward compatibility is
necessary. In addition, [I-D.ietf-idr-bgp-ipv6-rt-constrain] solves
the IPv6 specific RT issue in a backward compatible manner that
[I-D.dong-idr-vpn-route-constrain] addresses.
1.2.3. Using BGP Path Attribute
The list of afi-safi that a speaker needs in the scope for a given RT
can be carried in the path attribute of the RTC NLRI. This approach
does not require any change in the NLRI format as the new information
is not carried in the NLRI making the approach backward compatible.
In addition, RTC being a hop-by-hop technique by nature, best path
selection done on, say, a route-reflector, does not lead to missing
information. In this document, we adopt this approach which leads to
a light-weight, backward compatible solution. In addition, if the
policy language supported on the BGP speakers allow attaching
arbitrary extended communities to a route, then the proposed solution
can be deployed on edge routers (i.e., on leafs of the VPN
distribution graph) even without any software upgrade.
While one could define a new BGP path attribute to carry the list of
afi-safi as the scope, use of communities suffices for the present
purpose. Specifically, we propose using a new type of opaque
extended community called AFI-SAFI extended community to encode each
afi-safi pair that is of interest to the speaker and use multiple
extended communities to form the list. Extended communities instead
of standard communities are used since the latter are used widely by
the providers for communicating internal information.
Ray & Sreekantiah Expires August 18, 2014 [Page 5]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
2. AFI-SAFI Extended Community
The AFI-SAFI Community is an Non-Transitive Opaque Extended Community
([RFC4360], [I-D.ietf-idr-extcomm-iana]) defined as follows:
Type Field:
The value of the high-order octet of the extended Type Field is
0x43, which indicates that it is non-transitive. The value of
low-order octet of the extended type field for this community is
TBD.
Value Field:
The first 3 octets of the Value field contains two sub-fields,
described below. The last 3 octets of the Value field are
reserved. The originator of an AFi-SAFI community must set the
reserved octets to 0, and a receiver of an AFi-SAFI community
must ignore the reserved octets.
+--------------------------------------------------+
| Address Family Identifier (2 octets) |
+--------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+--------------------------------------------------+
| Reserved (3 octets) |
+--------------------------------------------------+
Figure 3: AFI-SAFI Extended Community Format
We denote an AFI-SAFI extended community with Address Family
Identifier field x and Subsequent Address Family Identifier field y
as AFI-SAFI-EC:(x/y).
A route carrying AFI-SAFI-EC:(x/y) implies that the route is
correlated to the address family with index x/y. The route itself may
belong to a different address family. The semantics of the
correlation is context dependent. This document defines the
correlation sematics for route constrain routes carrying AFI-SAFI-EC.
3. Operation
Suppose BGP speakers A and B have negotiated route constrain
capability. Speaker A receives an RTC NLRI RT:X:Y from speaker B
with set S of AFI-SAFI-EC attached. We define the following
semantics:
Ray & Sreekantiah Expires August 18, 2014 [Page 6]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
o If S is empty, then speaker A SHOULD send all otherwise eligible
routes from all address families to speaker B.
o If S is nonempty, then speaker A SHOULD send an otherwise eligible
AFI=x/SAFI=y route with RT:X:Y to speaker B ONLY if S contains
AFI-SAFI-EC:(x/y).
o Suppose speaker A has RTC route RT:X:Y with path i with AFI-SAFI-
EC set S_i, for i=1..n.
* If all S_i are nonempty, then speaker A attaches AFI-SAFI-EC
set S to RTC NLRI RT:X:Y that it advertises to its neighbors,
where S is the union of S_i, i=1..n.
* If there is an empty S_i, then speaker A does not attach any
AFI-SAFI-EC to RTC NLRI RT:X:Y that it advertises to its
neighbors.
The essential idea is to treat an RTC NLRI path with no AFI-SAFI-EC
attached as a path with AFI-SAFI-EC for all address families
attached. We illustrate the rules with a couple of examples shown in
Figure 4 and Figure 5.
Ray & Sreekantiah Expires August 18, 2014 [Page 7]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
RTC:1:1
EC: 2/128 +---+
<------------- | |
+----------------+ C |
| -------------> | |
| VPNv6 +---+
|
| RTC:1:1
RTC:1:1 v EC: 1/128
+-------+ (No AFI-SAFI extcomm) +---+ EC: 2/128 +---+
| VPNv4 | <---------------------- | |<------------ | |
| VPNv6 +-------------------------+ B +--------------+ D |
| MVPN | ----------------------> | |------------->| |
+-------+ VPNv4, VPNv6, MVPN +---+ VPNv4, VPNv6 +---+
Router A ^
|
| RTC:1:1
|(No AFI-SAFI EC)+---+
| <------------- | |
+----------------+ E |
-------------> | |
VPNv4, VPNv6, MVPN +---+
Figure 4: Operational rule in asymmetric cases
In Figure 4, speaker B receives RTC NLRI RT:1:1 from neighbors C, D
and E. Neighbor C attaches AFI-SAFI-EC:(2/128) and neighbor D
attaches AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/128). Neighbor E
does not attach any AFI-SAFI-EC to its route.
From the received set of AFI-SAFI-EC, speaker B knows that among all
the routes with RT:1:1, speaker C needs only VPNv6 unicast routes and
speaker D needs only VPNv4 unicast and VPNv6 unicast routes.
However, speaker B does not know which address family routes node E
needs. Therefore, speaker B must request routes with RT:1:1 for all
address families (whose capabilities have been negotiated) from its
neighbors. So speaker B advertises RTC NLRI RT:1:1 to speaker A with
no AFI-SAFI-EC.
Speaker A has VPNv4 unicast, VPNv6 uncast and MVPN routes with RT:1:1
that are eligible for sending to speaker B. Speaker A sends all those
routes to speaker B.
Speaker B now has VPNv4 unicast, VPNv6 uncast and MVPN routes with
RT:1:1 that are eligible for sending to neighbors C, D and E. Among
those routes, speaker B sends only the VPNv6 unicast routes to
neighbor C, VPNv4 unicast and VPNv6 unicast routes to neighbor D and
Ray & Sreekantiah Expires August 18, 2014 [Page 8]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
VPNv4 unicast, VPNv6 unicast and MVPN (i.e., all) routes to neighbor
E.
If speaker E actually only needs VPNv4 unicast routes, it would drop
the VPNv6 unicast and MVPN routes it receives from speaker B for RT
1:1. This sub-optimal behavior improves when speaker E also uses
AFI-SAFI-EC to signal the scope for RT:1:1 and the "island" of
contiguous AFI-SAFI-EC users expands.
RTC:1:1
EC: 2/128 +---+
<------------- | |
+----------------+ C |
| -------------> | |
| VPNv6 +---+
|
| RTC:1:1
RTC:1:1 v EC: 1/128
+-------+ EC: 1/128, EC: 2/128 +---+ EC: 2/128 +---+
| VPNv4 | <---------------------- | |<------------ | |
| VPNv6 +-------------------------+ B +--------------+ D |
| MVPN | ----------------------> | |------------->| |
+-------+ VPNv4, VPNv6 +---+ VPNv4, VPNv6 +---+
Router A ^
|
| RTC:1:1
| EC: 1/128 +---+
| <------------- | |
+----------------+ E |
-------------> | |
VPNv4 +---+
Figure 5: Operational rule in symmetric cases
In Figure 5, speaker B receives RTC NLRI RT:1:1 from neighbors C, D
and E. Neighbor C attaches AFI-SAFI-EC:(2/128), neighbor D attaches
AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/128), and neighbor E attaches
AFI-SAFI-EC:(1/128).
From the received set of AFI-SAFI-EC, speaker B knows that among all
routes with RT:1:1, speaker C needs only VPNv6 unicast routes,
speaker D needs only VPNv4 unicast and VPNv6 unicast routes, and
speaker E needs only VPNv4 unicast routes. Speaker B advertises RTC
NLRI RT:1:1 to speaker A with AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/
128), which is the union of all AFI-SAFI-EC from all paths of the RTC
NLRI.
Ray & Sreekantiah Expires August 18, 2014 [Page 9]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
Speaker A therefore sends only VPNv4 unicast and VPNv6 unicast routes
speaker B.
Among those routes with RT:1:1 that speaker B has, speaker B sends
only the VPNv6 unicast routes to neighbor C, VPNv4 unicast and VPNv6
unicast routes to neighbor D and only VPNv4 unicast routes to
neighbor E. Therefore, when all speakers use AFI-SAFI-EC, optimal
route filtering is restored even in shared RT deployments.
4. IANA Considerations
This document requests assignment of a codepoint from the Non-
Transitive Opaque Extended Community Sub-Types registry for AFI-SAFI
extended community.
5. Manageability Considerations
This section is structured as recommended in [RFC5706].
5.1. Configuration Management
TBD.
5.2. Operational Considerations
TBD.
6. Security Considerations
Procedures and protocol extensions defined in this document do not
affect the BGP security model. See the 'Security Considerations'
section of [RFC4271] for a discussion of BGP security. Also refer to
[RFC4272] and [I-D.ietf-karp-routing-tcp-analysis] for analysis of
security issues for BGP.
7. Acknowledgements
TBD.
8. References
8.1. Normative References
[I-D.ietf-idr-extcomm-iana]
Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", draft-ietf-idr-extcomm-iana-02
(work in progress), December 2013.
Ray & Sreekantiah Expires August 18, 2014 [Page 10]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
4272, January 2006.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
8.2. Informative References
[I-D.dong-idr-vpn-route-constrain]
Li, Z., Dong, J., Ni, H., Chen, M., and G. Liu,
"Constrained Route Distribution for BGP based Virtual
Private Networks(VPNs)", draft-dong-idr-vpn-route-
constrain-02 (work in progress), September 2010.
[I-D.ietf-idr-bgp-ipv6-rt-constrain]
Patel, K., Raszuk, R., Djernaes, M., Dong, J., and M.
Chen, "IPv6 Extensions for Route Target Distribution",
draft-ietf-idr-bgp-ipv6-rt-constrain-04 (work in
progress), August 2013.
[I-D.ietf-karp-routing-tcp-analysis]
Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP and MSDP Issues According to KARP Design
Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
progress), April 2013.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, August 2009.
Ray & Sreekantiah Expires August 18, 2014 [Page 11]
Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community
Attribute", RFC 5701, November 2009.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", RFC
5706, November 2009.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, May 2012.
Authors' Addresses
Saikat Ray
Cisco Systems, Inc.
170, West Tasman Drive
San Jose, CA 95134
US
Email: sairay@cisco.com
Arjun Sreekantiah
Cisco Systems, Inc.
170, West Tasman Drive
San Jose, CA 95134
US
Email: asreekan@cisco.com
Ray & Sreekantiah Expires August 18, 2014 [Page 12]
