L3VPN Routing Working Group H. Jeng
Internet-Draft AT&T
Intended status: Standards Track R. Bonica
Expires: March 19, 2014 Y. Rekhter
Juniper Networks
September 15, 2013
Covering Prefixes Outbound Route Filter for BGP-4
draft-bonica-l3vpn-orf-covering-prefixes-00
Abstract
This document defines a new ORF-type, called the "Covering Prefixes
ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtual
Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS VPN
environments.
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 March 19, 2014.
Copyright Notice
Copyright (c) 2013 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
Jeng, et al. Expires March 19, 2014 [Page 1]
Internet-Draft ORF Shortest Conveing September 2013
(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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 3
3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability In Virtual Hub-and-Spoke VPNs . . . . . . . . . 5
4.1. CP-ORF Clean-up . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Problem Statement
[RFC5291] provides a mechanism through which a BGP [RFC4271] speaker
can send a set of Outbound Route Filters (ORFs) to a peer. The peer
uses those ORFs to filter routing updates that it sends to the BGP
speaker.
The ORF mechanism allows the speaker to realize the "route pull"
paradigm with BGP, where the speaker, on demand, can pull certain
routes from the peer.
This document defines a new ORF-type, called the "Covering Prefixes
ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtual
Hub-and-Spoke VPN [I-D.ietf-l3vpn-virtual-hub]. However, it may also
be applicable in other BGP/MPLS VPN [RFC4364] environments.
1.1. Terminology
This document uses the terms "Address Family Identifier (AFI)" and
"Subsequent Address Family Identifier (SAFI)". In the context of
this document, the meaning of these terms is the same as in
[RFC4760].
This document also uses the terms "VPN IP default route"," V-hub" and
"V-spoke". In the context of this document, the meaning of these
terms is the same as in [I-D.ietf-l3vpn-virtual-hub].
Jeng, et al. Expires March 19, 2014 [Page 2]
Internet-Draft ORF Shortest Conveing September 2013
2. CP-ORF Encoding
[RFC5291] augments the BGP ROUTE-REFRESH message so that it can carry
ORF entries. When the ROUTE-REFRESH message carries ORF entries, it
includes the following fields:
o AFI
o SAFI
o When-to-refresh (IMMEDIATE or DEFERRED)
o ORF Type
o Length (of ORF entries)
The ROUTE-REFRESH message also contains a list of ORF entries. Each
ORF entry contains the following fields:
o Action (ADD, REMOVE, or REMOVE-ALL)
o Match (PERMIT or DENY)
The ORF entry may also contain Type-specific information. Type-
specific information is present only when the Action is equal to ADD
or REMOVE. It is not present when the Action is equal to REMOVE-ALL.
When the BGP ROUTE-REFRESH message carries CP-ORF entries, the
following conditions must be true:
o ORF Type MUST be equal to CP-ORF. (The value of CP-ORF is TBD.
See Section 5 for details.)
o AFI MUST be equal to either IPv4 or IPv6
o SAFI MUST be equal to "MPLS-labeled VPN address" [IANA.SAFI]
o Match field MUST be equal to PERMIT
Figure 1 depicts the encoding of the CP-ORF type-specific
information.
+--------------------------------+
| Sequence (32 bits) |
+--------------------------------+
| VPN Route Target (64 bits) |
+--------------------------------+
| Import Route Target (64 bits) |
Jeng, et al. Expires March 19, 2014 [Page 3]
Internet-Draft ORF Shortest Conveing September 2013
+--------------------------------+
| Host Address (32 or 128 bits) |
+--------------------------------+
Figure 1: CP-ORF Type-specific Encoding
The Sequence field specifies the relative ordering of the entry among
all CP-ORF entries.
The VPN Route Target field is used by the recipient of CP-ORF to
identify the set of routes to which CP-ORF applies. See Section 3
for details.
The Import Route Target also is used by the recipient of CP-ORF. The
CP-ORF recipient marks routes selected by CP-ORF with the value of
the Route Target extended community before advertising them to the
originator of the CP-ORF. See Section 3 for details.
If the AFI field in the ROUTE-REFRESH message is equal to IPv4, the
Host Address field MUST contain exactly 32 bits and MUST represent an
IPv4 host address. If the AFI field in the ROUTE-REFRESH message is
equal to IPv6, the Host Address field MUST contain exactly 128 bits
and MUST represent an IPv6 host address.
3. Processing Rules
When a BGP speaker receives a ROUTE-REFRESH message that contains a
CP-ORF, and that ROUTE-REFRESH message that violates any of the
encoding rules specified in Section 2, the BGP speaker MUST log the
event and ignore the entire ROUTE-REFRESH message.
Otherwise, the BGP speaker processes each CP-ORF entry as indicated
by the Action field. If the Action is equal to ADD, the BGP speaker
adds a CP-ORF entry in the position specified by the Sequence field.
If the Action is equal to REMOVE, the BGP speaker removes a CP-ORF
entry. If the Action is equal to REMOVE-ALL, the BGP speaker removes
all CP-ORF entries.
Whenever the BGP speaker advertises routes to a peer, it evaluates
each route in terms of each CP-ORF entry received from that peer. A
route matches the selection criteria of a CP-ORF if the following
statements are true:
o the route is more specific than a /64 (i.e., the route more
specific than an IP VPN default route)
o the route carries RT whose value is the same as the CP-ORF VPN
Route Target
Jeng, et al. Expires March 19, 2014 [Page 4]
Internet-Draft ORF Shortest Conveing September 2013
o the route covers the CP-ORF Host Address
When evaluating whether the route covers the CP-ORF Host Address, the
BGP speaker ignores Route Distinguishers. For example, assume that
the CP-ORF Host Address is equal to 192.0.2.1. Assume also that the
RIB contains routes for the following IPv4 VPN prefixes, and that all
of these routes carry an RT whose value is the same as the CP-ORF VPN
Route Target:
o 1:0.0.0.0/64.
o 2:192.0.2.0/88
o 3:192.0.2.0/89
For the purposes of this search, 2:192.0.2.0/88 and 3:192.0.2.0/89
cover 192.0.2.1. This is because the search algorithm ignores Route
Distinguishers. However, 1:0.0.0.0/64 does not cover 192.0.2.1,
because the search algorithm requires a prefix length greater than /
64.
If a route matches the selection criteria of a CP-ORF, the BGP
speaker places the route into the Adj-RIB-Out associated with the
peer from which CP-ORF was received. When placing the route into the
Adj-RIB-Out, the speaker applies the following rules:
o all BGP attributes except for Route Targets are unchanged
o The Route Target specified by the CP-ORF Import Route Target is
added to the list or Route Targets that the route already carries
As a result of placing the route into the Adj-RIB-Out, the route is
advertised to the peer.
4. Applicability In Virtual Hub-and-Spoke VPNs
In a Virtual Hub-and-Spoke environment, VPN sites are attached to
Provider Edge (PE) routers, V-hubs and V-spokes. PE routers, V-hubs
and V-spokes can exchange VPN routes through an iBGP mesh.
Alternatively, they can exchange customer routes using Route
Reflectors (RR).
For the purposes of this document, assume that RED-VPN sites are
attached to PE routers, V-hub1 and V-spoke1. All of these devices
advertise RED-VPN routes to a RR. They mark these routes with a
route target, which we will call RT-RED.
Jeng, et al. Expires March 19, 2014 [Page 5]
Internet-Draft ORF Shortest Conveing September 2013
V-hub1 serves the RED-VPN. Therefore, V-hub1 advertises a VPN IP
default route for the RED-VPN to the RR, carrying the route target
RT-RED-FROM-HUB1.
V-spoke1 establishes a BGP session with the RR, negotiating the CP-
ORF capability, as well as the Multiprotocol Extensions Capability
[RFC2858] . Upon establishment of the BGP session, the RR does not
advertise any routes to V-spoke1. The RR will not advertise any
routes until it receives either a ROUTE-REFRESH message or a BGP
UPDATE message containing a Route Target Membership NLRI [RFC4684].
Immediately after the BGP session is established, V-spoke1 sends the
RR a BGP UPDATE message containing a Route Target Membership NLRI.
The Route Target Membership NLRI specifies RT-RED-FROM-HUB1 as its
route target. In response to the BGP-UPDATE message, the RR
advertises the VPN IP default route for the RED-VPN to V-spoke1.
This route still carries the route target RT-RED-FROM-HUB1. V-spoke1
subjects this route to its import policy and accepts it because it
carries the route target RT-RED-FROM-HUB1.
Now, V-spoke1 begins normal operation, sending all of its traffic
through V-hub1. At some point, V-spoke1 determines that it might
benefit from a more direct route to a destination. (Criteria by
which V-spoke1 determines that it needs a more direct route are
beyond the scope of this document.)
In order to discover a more direct route, V-spoke1 assigns a unique
numeric identifier to the flow. V-spoke1 then sends a ROUTE-REFRESH
message to the RR, containing the following information:
o AFI is equal to IPv4 or IPv6, as appropriate
o SAFI is equal to "MPLS-labeled VPN address"
o When-to-refresh is equal IMMEDIATE
o Action is equal to ADD
o Match is equal to PERMIT
o ORF Type is equal to CP-ORF
o CP-ORF Sequence is equal to the identifier associated with the
flow
o CP-ORF VPN Route Target is equal to RT-RED
o CP-ORF Import Route Target is equal to RT-RED-FROM-HUB1
Jeng, et al. Expires March 19, 2014 [Page 6]
Internet-Draft ORF Shortest Conveing September 2013
o CP-ORF Host Address is equal the destination address associated
with the flow
Upon receipt of the ROUTE-REFRESH message, the RR must ensure that it
carries all routes belonging to the RED-VPN. In at least one special
case, where all of the RR clients are V-spokes and none of the RR
clients are V-hubs, the RR will lack some or all of the required RED-
VPN routes. So, the RR sends a BGP UPDATE message containing a Route
Target Membership NLRI for VPN-RED to all of its peers. This causes
the peers to advertise VPN-RED routes to the RR, if they have not
done so already.
Next, the RR installs the CP-ORF and refreshes routes for V-spoke1.
If the RR maintains any routes matching the CP-ORF selection
criteria, it advertises those routes. As it advertises those routes,
it adds the CP-ORF Import Route Target to the list of route targets
that they carry. The advertised routes may specify either V-hub1 or
any other node as the NEXT-HOP.
V-spoke1 subjects the advertised routes to its import policy and
accepts them because they carry the route target RT-RED-FROM-HUB1.
V-spoke1 may repeat this process whenever it discovers another flow
that might benefit from a more direct route to its destination.
4.1. CP-ORF Clean-up
Each CP-ORF consumes memory and compute resources on the device that
supports it. Therefore, in order to obtain optimal performance, the
V-spoke periodically evaluates all CP-ORFs that it has originated and
removes unneeded CP-ORFs. The V-spoke determines that a CP-ORF is
unneeded if its forwarding table includes no route satisfying the
following criteria:
o Covers the CP-ORF Host Address
o Carries the same route target as the CP-ORF VPN Route Target
o Has prefix length greater than 64 (i.e., is not a default route)
o Has NEXT-HOP different from that of any VPN IP default route
(i.e., different from any V-hub with which the V-Spoke is
associated)
When the V-spoke finds an unneeded CP-ORF, it removes the CP-ORF, as
described below, and adds CP-ORF Host Address to a list of addresses
known to be reachable only through the V-hub. The Host Address
remains on that list for a configurable period of time. While the
Jeng, et al. Expires March 19, 2014 [Page 7]
Internet-Draft ORF Shortest Conveing September 2013
Host Address is on that list, flows directed toward it will not be
considered as candidates for a more direct route.
Also, the V-spoke removes all CP-ORFs when a configurable period of
time has elapsed since their installation. When it does this, it
does not add CP-ORF Host Address to the list of addresses known to be
reachable only through a V-hub. If the V-spoke once again determines
that a flow directed towards the Host Address might benefit from a
more direct route, it will send another CP-ORF.
In order to removed unneeded CP-ORFs, the V-spoke sends a single
ROUTE Refresh message containing the following information:
o AFI is equal to IPv4 or IPv6, as appropriate
o SAFI is equal to "MPLS-labeled VPN address"
o When-to-refresh is equal IMMEDIATE
o Action is equal to REMOVE
o Match is equal to PERMIT
o ORF Type is equal to CP-ORF
o A list of CP-ORFs, with one element representing each unneeded CP-
ORF
The recipient of this message responds to it as described in
[RFC5291].
5. IANA Considerations
IANA is requested to assign a All Covering Prefixes ORF Type from the
BGP Outbound Route Filtering (ORF) Types Registry.
6. Security Considerations
Each CP-ORF consumes finite memory and compute resources on the
control plane of the V-hub. Therefore, the V-hub MUST take the
following steps to protect itself from oversubscription:
o When negotiating the ORF capability, advertise willingness to
receive the CP-ORF only to known, trusted iBGP peers
o Enforce a per-peer limit on the number of CP-ORFs that can be
installed at any given time. Ignore all requests to add CP-ORFs
beyond that limit
Jeng, et al. Expires March 19, 2014 [Page 8]
Internet-Draft ORF Shortest Conveing September 2013
7. Acknowledgements
The authors wish to acknowledge Han Nguyen and James Uttaro for their
comments and contributions.
8. Normative References
[I-D.ietf-l3vpn-virtual-hub]
Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter,
Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS
VPNs", draft-ietf-l3vpn-virtual-hub-08 (work in progress),
July 2013.
[IANA.SAFI]
IANA, "abbrev="Subsequent Address Family Identifiers
(SAFI) Parameters"", , <http://www.iana.org/assignments/
safi-namespace/safi-namespace.xhtml#safi-namespace-2>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
Capability for BGP-4", RFC 5291, August 2008.
[RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
Route Filter for BGP-4", RFC 5292, August 2008.
Authors' Addresses
Jeng, et al. Expires March 19, 2014 [Page 9]
Internet-Draft ORF Shortest Conveing September 2013
Huajin Jeng
AT&T
Email: hj2387@att.com
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia 20170
USA
Email: rbonica@juniper.net
Yakov Rekhter
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, California 94089
USA
Email: yakov@juniper.net
Jeng, et al. Expires March 19, 2014 [Page 10]