BGP Next-Hop Capabilities
draft-decraene-idr-next-hop-capability-00

Network Working Group                                        B. Decraene
Internet-Draft                                                    Orange
Intended status: Standards Track                           March 9, 2015
Expires: September 10, 2015

                       BGP Next-Hop Capabilities
               draft-decraene-idr-next-hop-capability-00

Abstract

   RFC 5492 defines capabilities advertisement for the BGP peer.  In
   addition, it's useful to know the capabilities of the BGP Next-Hop,
   in particular for forwarding plane features.  RFC 5492 is not
   applicable because the BGP peer may be different from the BGP Next-
   Hop, in particular when BGP Route Reflection is used.  This document
   defines a mechanism to advertise such BGP Next Hop Capabilities.

   This document defines a new BGP non-transitive attribute to carry
   Next-Hop Capabilities.  This attribute is deleted when the BGP Next
   Hop is changed.

   This document also defines a Next-Hop capability to advertise the
   ability to handle the Entropy Label defined in RFC 6790.

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 September 10, 2015.

Decraene               Expires September 10, 2015               [Page 1]
Internet-Draft          BGP Next-Hop Capabilities             March 2015

Copyright Notice

   Copyright (c) 2015 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.

1.  Introduction

   [RFC5492] defines capabilities advertisement for the BGP peer.  It's
   also useful to know the capabilities of the BGP Next-Hop, in
   particular for forwarding plane features.  RFC 5492 is not applicable
   because the BGP peer may be different from the BGP Next-Hop, in
   particular when BGP Route Reflection is used.  This document defines
   a mechanism to advertise such BGP Next Hop Capabilities.

   This document defines a new BGP non-transitive attribute to carry
   Next-Hop Capabilities.  This attribute is deleted when the BGP Next
   Hop is changed.

   This document also defines a first application to advertise the
   capability to handle the Entropy Label defined in [RFC6790].  Note
   that RFC 6790 had originally defined a BGP attribute for this but it
   has been latter deprecated in [RFC7447]

2.  BGP Next-Hop Capability Attribute

   The BGP Next-Hop Capabilities Attribute is an optional, non-
   transitive BGP Attribute, of value TBD1.  The attribute consists of a
   set of Next-Hop Capabilities.  Inclusion of a Next-Hop Capability "X"
   indicates that the BGP Next-Hop, encoded in either the NEXT_HOP
   attribute defined in [RFC4271] or the Network Address of Next Hop
   field of the MP_REACH_NLRI attribute defined in [RFC4760], supports
   the capability "X".  This document do not make distinction between
   these two Next-Hop fields and refer to them as BGP Next-Hop.

   A Next-Hop Capability is triple (Capability Code, Capability Length,
   Capability Value) aka a TLV:

Decraene               Expires September 10, 2015               [Page 2]
Internet-Draft          BGP Next-Hop Capabilities             March 2015

                           A Next-Hop Capability.

             +------------------------------+
             | Capability Code (1 octet)    |
             +------------------------------+
             | Capability Length (1 octet)  |
             +------------------------------+
             | Capability Value (variable)  |
             ~                              ~
             +------------------------------+

   Capability Code : a one-octet unsigned binary integer which indicates
   the type of "Next-Hop Capability" advertised and unambiguously
   identifies an individual capability.

   Capability Field: a one-octet unsigned binary integer which indicates
   the length, in octets, of the Value Field.  A length of 0 indicates
   that no Value Field is present.

   Value Field: a variable-length field from 0 to 255 octets.  It is
   interpreted according to the value of the Capability Code field.

   BGP speakers SHOULD NOT include more than one instance of a Next-Hop
   capability with the same Capability Code, Capability Length, and
   Capability Value.  Note, however, that processing of multiple
   instances of such capability does not require special handling, as
   additional instances do not change the meaning of the announced
   capability; thus, a BGP speaker MUST be prepared to accept such
   multiple instances.

   BGP speakers MAY include more than one instance of a capability (as
   identified by the Capability Code) with non-zero Capability Length
   field, but with different Capability Value and either the same or
   different Capability Length.  Processing of these capability
   instances is specific to the Capability Code and MUST be described in
   the document introducing the new capability.

3.  BGP Next-Hop Capabilities Attribute Operation

   The BGP Attribute being non-transitive, as per [RFC4271], a BGP
   speaker which does not understand it will quietly ignore it and not
   pass it along to other BGP peers.

   A BGP speaker which understand the BGP Next-Hop Attribute and does
   not change the BGP Next-Hop, SHOULD NOT change the BGP Next-Hop
   Attribute and SHOULD pass the attribute unchanged along to other BGP
   peers.

Decraene               Expires September 10, 2015               [Page 3]
Internet-Draft          BGP Next-Hop Capabilities             March 2015

   A BGP speaker which understand the BGP Next-Hop Attribute and change
   the BGP Next-Hop, MUST remove the received BGP Next-Hop Attribute
   before propagating the BGP UPDATE other BGP peers.  It MAY attach a
   new BGP Next-Hop attribute describing the capabilities of the new BGP
   Next-Hop.

4.  BGP Next-Hop Attribute Error Handling

   A BGP Next-Hop Capability Attribute is considered malformed if the
   length of the Attribute is not equal to the sum of all (BGP Hop
   Capability Length +2) of each capability carrier in this attribute.
   Note that "2" is the length of the fields "Type" and "Length" of each
   BGP Next Hop Capability.

   A BGP UPDATE message with a malformed BGP Next-Hop Capability
   Attribute SHALL be handled using the approach of "attribute discard"
   defined in [I-D.ietf-idr-error-handling].  [Note: To be Discussed.
   Treat as withdraw would be safer if one implementation allow changing
   route preference based on BGP Next-Hop Capability.  But this is the
   case of any attribute.]

   If a Next-Hop Capability is malformed, this Next-Hop Capability Type
   MUST be ignored.  Others Next-Hop Capabilities MUST be processed as
   usual.[Note: To be Discussed]

5.  Entropy Label Next-Hop Capability

   The Entropy Label Next-Hop Capability have type code 1 and a length
   of 0 octet.

   The inclusion of the "Entropy Label" Next-Hop Capability indicates
   that the BGP Next-Hop can be sent packets with a MPLS entropy label
   as an egress LSR for all routes in that NLRI.

   A BGP speaker S that originates an UPDATE MAY include the Entropy
   Label Next-Hop Capability only if either of the following is true:

   A1: S sets the BGP NEXT_HOP attribute to itself AND S can process
   entropy labels.  In other words, the BGP Next-Hop can process entropy
   labels.

   A2: S sets the BGP NEXT_HOP attribute to itself AND S swaps the
   advertised label without popping the advertised label(s) stack AND S
   knows that the egress can process the entropy label (typically when
   redistributing a route received with the indication that the egress
   can be sent the entropy label (e.g. received via BGP with the
   "Entropy Label" Next-Hop Capability attached, or via LDP with the ELC

Decraene               Expires September 10, 2015               [Page 4]
Internet-Draft          BGP Next-Hop Capabilities             March 2015

   TLV...).  In other words, the BGP Next-Hop may or may not be able to
   process entropy labels, but it will not have to process it.

6.  IANA Considerations

6.1.  Next-Hop Capabilities Attribute

   IANA is requested to allocate a new Path Attribute, called "Next-Hop
   Capabilities", type Code TBD1, from the "BGP Path Attributes"
   registry.

6.2.  Next-Hop Capability registry

   The IANA is requested to create and maintain a registry entitled
   "Next-Hop Capabilities".

   The registration policies [RFC5226] for this registry are:

       1-63    IETF Review
     64-127    First Come First Served

   IANA is requested to make the following initial assignments:

                   Registry Name: Next-Hop Capability.

    Value      Meaning                                  Reference
    ---------- ---------------------------------------- ---------
          0    Reserved                                 This document
          1    Entropy Label                            This document
      2-127    Unassigned
    128-255    Private Use                              This document

7.  Security Considerations

   This document does not introduce new security vulnerabilities in BGP.
   Please refer to the Security Considerations section of [RFC4271] for
   security mechanisms applicable to BGP.

8.  Acknowledgement

   The Entropy Label Next-Hop Capability defined in this document is
   based on the ELC BGP attribute defined in section 5.2 of [RFC6790].

Decraene               Expires September 10, 2015               [Page 5]
Internet-Draft          BGP Next-Hop Capabilities             March 2015

9.  References

9.1.  Normative References

   [I-D.ietf-idr-error-handling]
              Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
              "Revised Error Handling for BGP UPDATE Messages", draft-
              ietf-idr-error-handling-18 (work in progress), December
              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.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760, January
              2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, November 2012.

9.2.  Informative References

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, February 2009.

   [RFC7447]  Scudder, J. and K. Kompella, "Deprecation of BGP Entropy
              Label Capability Attribute", RFC 7447, February 2015.

Author's Address

   Bruno Decraene
   Orange

   Email: bruno.decraene@orange.com

Decraene               Expires September 10, 2015               [Page 6]