Selective Advertisement of Multiple Paths within BGP
draft-keyupate-idr-bgp-selective-add-paths-00

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]