Internet DRAFT - draft-keyupate-idr-bgp-selective-add-paths
draft-keyupate-idr-bgp-selective-add-paths
Network Working Group K. Patel
Internet-Draft A. Lindem
Intended status: Standards Track Cisco Systems
Expires: September 19, 2016 March 18, 2016
Selective Advertisement of Multiple Paths within BGP
draft-keyupate-idr-bgp-selective-add-paths-00.txt
Abstract
Originally, a BGP speaker was only allowed to advertise one path to
any given address prefix. If the BGP speaker advertised a second
path to a given prefix, the second path was considered to be a
replacement for the first. The BGP ADD-PATH capability was defined
to enable a BGP speaker to advertise multiple paths to a given
address prefix, without one path replacing any of the others.
However, whether a BGP speaker advertises multiple paths for any
given prefix is always a matter of local policy for that BGP speaker.
In certain situations, it is desirable to allow a BGP speaker to
signal to its peers that the peers may advertise multiple
simultaneous paths for certain prefixes but not for others. This
document defines a new BGP capability, the Selective ADD-PATH
capability, that allows a BGP speaker to signal to its peers whether
a particular prefix is or is not eligible to have multiple paths
advertised.
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 September 19, 2016.
Patel & Lindem Expires September 19, 2016 [Page 1]
Internet-Draft BGP Add-Path Selective Advertisement March 2016
Copyright Notice
Copyright (c) 2016 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Selective ADD-PATH Capability . . . . . . . . . . . . . . . . 4
3. Selective ADD-PATH Extended Community . . . . . . . . . . . . 5
4. Selective Add-Path Use Case . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informational References . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[I-D.ietf-idr-add-paths] defines a BGP extension, ADD-PATH, that
allows a BGP speaker to advertise multiple simultaneous paths for the
same address prefix. Without this extension, only one path at a time
can be advertised; if a BGP speaker advertises a second path for a
Patel & Lindem Expires September 19, 2016 [Page 2]
Internet-Draft BGP Add-Path Selective Advertisement March 2016
given prefix, that path is considered to be replacement for the
previously advertised path.
Sometimes it would desirable for a BGP speaker to be able to signal
to its peers that the peers may advertise multiple simultaneous paths
for certain prefixes but not for others. This document specifies a
mechanism by which a BGP speaker can perform this signaling. A new
BGP Extended Community ([RFC4360], [RFC7153]), known as the Selective
ADD-PATH Extended Community is defined. A BGP speaker can signal
that a particular prefix is eligible to have multiple simultaneous
paths advertised by adding this Extended Community to its own
advertisements of the paths to that prefix.
This draft also defines a new BGP Capability, the Selective ADD-PATH
Capability.
As an example of the use of Selective ADD-PATH, consider the topology
of Figure 1.
+----+
P1--> | R1 |
P2--> +----+ \ +----+ +----+
-- | RR | -- | R3 |
+----+ / +----+ +----+
P1--> | R2 |
P2--> +----+
Figure 1: Selective ADD-PATH Example
Suppose that RR is a route reflector that doesn't change the nexthops
of the prefixes that it reflects. Let R1, R2 and R3 be clients of
RR.
Suppose R1 sends RR an UPDATE: <NLRI=P1, NH=R1> and <NLRI=P2, NH=R1>.
Suppose R2 sends RR an UPDATE: <NLRI=P1, NH=R2> and <NLRI=P2, NH=R2>.
Also suppose that it is desired to advertise multiple paths for P1,
but not for P2.
This can be achieved using Selective ADD-PATHS, as follows. First,
all three BGP sessions (R1-RR, R2-RR, and R3-rr) will negotiate both
the ADD-PATH Capability and the Selective ADD-PATH Capability.
When R1 and R2 originate their advertisements for prefix P1, they
will attach the Selective ADD-PATH Extended Community. But when R1
and R2 originate their advertisements for prefix P2, they will not
attach the Selective ADD-PATH Extended Community.
Patel & Lindem Expires September 19, 2016 [Page 3]
Internet-Draft BGP Add-Path Selective Advertisement March 2016
As a result, RR will know that when advertising NLRI to R3, it may
advertise multiple simultaneous paths to P1, but that it may
advertise only a single path to P2.
This mechanism does not require the RR to advertise all the paths to
P1; the actual number of paths advertised is a matter of local policy
at RR.
1.1. 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].
2. Selective ADD-PATH Capability
The Selective ADD-PATH Capability is a new BGP Capability [RFC5492],
whose code point is to be allocated by IANA. The Capability Length
field of this capability is variable. The Capability Value field
consists of one or more of the following tuples:
+------------------------------------------------+
| Address Family Identifier (2 octets) |
+------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+------------------------------------------------+
The meaning and use of the fields are as follows:
Address Family Identifier (AFI):
This field is the same as the one used in [RFC4760].
Subsequent Address Family Identifier (SAFI):
This field is the same as the one used in [RFC4760].
A BGP Speaker that wishes to announce or receive multiple
simultaneous paths for any prefix MUST exchange the ADD-PATH
Capability defined in [I-D.ietf-idr-add-paths]. A BGP Speaker that
wishes to signal that only certain prefixes are eligible to have
multiple simultaneous paths, MUST additionally exchange the Selective
ADD-PATH Capability defined in this draft. The Capability Value
field MUST specify the AFI/SAFI of the prefixes in question.
Patel & Lindem Expires September 19, 2016 [Page 4]
Internet-Draft BGP Add-Path Selective Advertisement March 2016
If a particular AFI/SAFI is not listed in the Capability value field,
the procedures in this document MUST NOT be applied to prefixes of
that AFI/SAFI. However, note that since the ADD-PATH Capability has
also been exchanged, every UPDATE will still contain an NLRI
containing a "path identifier", as specified in
[I-D.ietf-idr-add-paths].
When processing a received Selective ADD-PATH Capability on a
particular BGP session, a BGP speaker MUST ensure that it has already
received the ADD-PATH Capability defined in [I-D.ietf-idr-add-paths]
on that session. Otherwise, the BGP speaker MUST treat the received
Selective ADD-PATH Capability as an unsupported Capability, and
follow the error handling rules for unsupported Capabilities in
[RFC5492].
3. Selective ADD-PATH Extended Community
We define a new Transitive Opaque Extended Community ([RFC4360],
[RFC7153]) known as the Selective ADD-PATH Extended Community. The
sub-type code point for this Extended Community will be assigned by
IANA.
If Selective ADD-PATH Capability negotiation for a given AFI/SAFI has
not taken place, but the Selective ADD-PATH Extended Community is
included with a prefix of that AFI/SAFI, the Selective ADD-PATH
Extended Community will be ignored. However, the occurrence of the
unexpected Extended Community SHOULD be logged. Also, the Extended
Community SHOULD NOT be stripped from the path, but rather SHOULD be
propagated along with the path.
Upon successful Selective ADD-PATH Capability negotiation for a
particular AFI/SAFI, a BGP speaker MUST NOT announce multiple paths
for any prefix of that AFI/SAFI unless at least one of the following
conditions holds:
o It has at least one received UPDATE for that prefix that includes
the Selective ADD-PATH Extended Community in its attributes.
o It is the originator of an UPDATE for that prefix, and it has been
configured to attach the Selective ADD-PATH Extended Community to
that UPDATE.
If at some later time, these conditions no longer hold for a given
prefix, the BGP speaker MUST withdraw all but the best path for that
prefix.
It is to be expected that if a BGP speaker has received multiple
paths for a given prefix, either all the paths will have the
Patel & Lindem Expires September 19, 2016 [Page 5]
Internet-Draft BGP Add-Path Selective Advertisement March 2016
Selective ADD-PATH Extended Community or none of them will. However,
the rules above require the Selective ADD-PATH procedures to be
applied to that prefix if even one received path for that prefix has
the Selective ADD-PATH Extended Community.
4. Selective Add-Path Use Case
A use case is a BGP deployment where underlay and overlay routes are
associated with the same AFI/SAFI and, for scaling reasons, it is
desired that multiple paths are advertised and installed only for the
underlay routes. For direct BGP sessions, the ingress routers would
only advertise multiple paths for the underlay routes. However, if
the topology includes BGP Router Reflectors [RFC4456], it is likely
that multiple ingress routers will advertise the same overlay routes.
In this case, the mechanism describe herein would be useful in
limiting multi-path best-path computation and advertisement to the
underlay routes.
5. IANA Considerations
This document defines a new Capability for BGP, the "Selective ADD-
PATH" Capability. We request IANA to assign a code point for this
Capability from "First Come, First Served" range of the BGP
"Capability Codes" registry at http://www.iana.org/assignments/
capability-codes/capability-codes.xhtml. This document should be the
reference.
This document also defines a new Extended Community for BGP, the
Selective ADD-PATH Extended Community. We request IANA to assign a
code point for this community from the "First Come, First Served"
range of the "Transitive Opaque Extended Communities Sub-Type"
registry at http://www.iana.org/assignments/bgp-extended-communities/
bgp-extended-communities.xhtml. This document should be the
reference.
6. Security Considerations
This extension to BGP does not change the underlying security issues
inherent in the existing [RFC4724] and [RFC4271].
6.1. Acknowledgements
The authors would like to thank Eric Rosen for his review and
comments.
Patel & Lindem Expires September 19, 2016 [Page 6]
Internet-Draft BGP Add-Path Selective Advertisement March 2016
7. References
7.1. Normative References
[I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-13 (work in progress), December 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <http://www.rfc-editor.org/info/rfc4360>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <http://www.rfc-editor.org/info/rfc5492>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <http://www.rfc-editor.org/info/rfc7153>.
7.2. Informational References
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<http://www.rfc-editor.org/info/rfc4456>.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
DOI 10.17487/RFC4724, January 2007,
<http://www.rfc-editor.org/info/rfc4724>.
Authors' Addresses
Patel & Lindem Expires September 19, 2016 [Page 7]
Internet-Draft BGP Add-Path Selective Advertisement March 2016
Keyur Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: keyupate@cisco.com
Acee Lindem
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: acee@cisco.com
Patel & Lindem Expires September 19, 2016 [Page 8]
