Network Working Group B. Decraene
Internet-Draft Orange
Updates: 6790 (if approved) K. Kompella
Intended status: Standards Track Juniper Networks, Inc.
Expires: January 7, 2016 W. Henderickx
Alcatel Lucent
July 6, 2015
BGP Next-Hop Capabilities
draft-decraene-idr-next-hop-capability-01
Abstract
RFC 5492 defines capabilities advertisement for the BGP peer. In
addition, it is 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."
Decraene, et al. Expires January 7, 2016 [Page 1]
Internet-Draft BGP Next-Hop Capabilities July 2015
This Internet-Draft will expire on January 7, 2016.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BGP Next-Hop Capabilities Attribute . . . . . . . . . . . . . 3
3. BGP Next-Hop Capabilities Attribute Operation . . . . . . . . 4
4. BGP Next-Hop Capability Code Operation . . . . . . . . . . . 4
5. BGP Next-Hop Attribute Error Handling . . . . . . . . . . . . 5
6. Entropy Label Next-Hop Capability . . . . . . . . . . . . . . 5
6.1. Readable Label Depth . . . . . . . . . . . . . . . . . . 6
6.2. Entropy Label Next-Hop Capability error handling . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 7
7.2. Next-Hop Capability registry . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[RFC5492] defines capabilities advertisement for the BGP peer. It is
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.
Decraene, et al. Expires January 7, 2016 [Page 2]
Internet-Draft BGP Next-Hop Capabilities July 2015
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 Capabilities 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" in a BGP UPDATE message,
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" for the NLRI advertised in this BGP UPDATE. This
document does not make distinction between these two Next-Hop fields
and uses the term 'BGP Next-Hop' to refer to whichever one is used in
a given BGP UPDATE message.
A Next-Hop Capability is a triple (Capability Code, Capability
Length, Capability Value) aka a TLV:
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 Length: a one-octet unsigned binary integer which
indicates the length, in octets, of the Capability Value field. A
length of 0 indicates that no Capability Value Field is present.
Decraene, et al. Expires January 7, 2016 [Page 3]
Internet-Draft BGP Next-Hop Capabilities July 2015
Capability Value: a variable-length field from 0 to 255 octets. It
is interpreted according to the value of the Capability Code.
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 Next-Hop Capabilities 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 that understands the BGP Next-Hop Capabilities
Attribute and does not change the BGP Next-Hop, SHOULD NOT change the
BGP Next-Hop Capabilities Attribute and SHOULD pass the attribute
unchanged along to other BGP peers.
A BGP speaker that understands the BGP Next-Hop Capabilities
Attribute and changes the BGP Next-Hop, MUST remove the received BGP
Next-Hop Capabilities before propagating the BGP UPDATE to other BGP
peers. It MAY attach a new BGP Next-Hop Capabilities attribute
describing the capabilities of the new BGP Next-Hop.
4. BGP Next-Hop Capability Code Operation
A BGP speaker receiving a BGP Next-Hop Capability Code that it
supports may behave as defined in the document defining this
Capability Code. A BGP speaker receiving a BGP Next-Hop Capability
Code that it does not support MUST ignore this BGP Next-Hop
Capability Code. In particular, this MUST NOT be handled as an
error. In both cases, the BGP speaker MUST examine the remaining BGP
Next-Hop Capability Code that may be present in the BGP Next-Hop
Capabilities Attribute.
The BGP Next-Hop Capability Code MUST reflect the capability of the
router indicated in the BGP Next-Hop. If a BGP speaker sets the BGP
Decraene, et al. Expires January 7, 2016 [Page 4]
Internet-Draft BGP Next-Hop Capabilities July 2015
Next-Hop to an address of a different router (e.g. R), it MUST NOT
advertise BGP Next-Hop Capabilities not supported by this router R.
The presence of a Next-Hop Capability SHOULD NOT influence route
selection or route preference of an route, unless tunneling is used
to reach the BGP Next-Hop or the selected route has been learnt from
EBGP (i.e. the Next-Hop is in a different AS). Indeed, it is in
general impossible for a node to know that all BGP routers of the
Autonomous System (AS) will understand a given Next-Hop Capability;
and having different routers, within an AS, use a different
preference for a route, may result in forwarding loops if tunnelling
is not used to reach the BGP Next-Hop.
An implementations MAY allow, by configuration, removing this
attribute when advertising the routes over eBGP.
5. BGP Next-Hop Attribute Error Handling
A BGP Next-Hop Capabilities 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 carried 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 Capabilities
Attribute SHALL be handled using the approach of "attribute discard"
defined in [I-D.ietf-idr-error-handling].
Unknown Next-Hop Capabilities Codes MUST be silently ignored.
A document that specifies a new Next-Hop Capability SHOULD provide
specifics regarding what constitutes an error for that Next-Hop
Capability.
If a Next-Hop Capability is malformed, this Next-Hop Capability Type
MUST be ignored. Others Next-Hop Capabilities MUST be processed as
usual.
6. Entropy Label Next-Hop Capability
The Entropy Label Next-Hop Capability has type code 1 and a length of
0 or 1 octet.
The inclusion of the "Entropy Label" Next-Hop Capability indicates
that the BGP Next-Hop can be sent packets, for all routes indicated
in the NRLI, with a MPLS entropy labels (ELI, EL) added immediately
after the label stack advertised with the NLRI.
Decraene, et al. Expires January 7, 2016 [Page 5]
Internet-Draft BGP Next-Hop Capabilities July 2015
On the receiving side, suppose BGP speaker S has determined that
packet P is to be forwarded according to BGP route R, where R is a
route of one of the labeled address families. And suppose that L is
the label stack embedded in the NLRI of route R. Then to forward
packet P according to route R, S either replaces P's top label with
L, or else pushes L onto the MPLS label stack. If the EL-Capability
is advertised in the BGP UPDATE advertising this route R, S knows
that it may safely place the ELI and an EL on the label stack
immediately beneath L.
A BGP speaker S that sends an UPDATE with the BGP Next-Hop NH MAY
include the Entropy Label Next-Hop Capability only if, for all the
NLRI in the BGP UPDATE, either of the following is true:
o Egress case: NH is the egress of the LSP advertised with the NLRI
and can lookup and its capable of handling the ELI.
o Transit LSR case: NH is a transit LSR for the LSP advertised with
the NLRI (i.e. swap one of the label advertised in the NLRI) and
next downstream BGP Next-Hop(s) has(have) advertised the Entropy
Label Next-Hop Capability (or a similar capability signalled by
protocol X if the route is redistributed, by NH, from X to BGP).
6.1. Readable Label Depth
When stacked LSPs are used and the ingress nests LSP inside this BGP
signaled LSP, it would be useful for ingress LSRs to know how many
additional labels the downstream LSR may read when load-balancing
based on the Entropy Label. In other words, how many labels the
ingress LER may push, in addition to the BGP label(s) advertised in
the Network Layer Reachability Information (NLRI) field, before
pushing an entropy label that will be seen by all downstream LSRs.
This maximum number of additional labels is called the Readable Label
Depth (RLD) of the LSP(s). It is related, yet different, to the RLD
of an node which is defined in [I-D.ietf-mpls-spring-entropy-label]
The RLD of the LSP(s) advertised in the NLRI, may be advertised in
the value field of the Entropy Label Next-Hop Capability. This value
field is optional. If present, the value field is a one-octet
unsigned binary integer which indicates the maximum Readable Label
Depth (RLD) of the LSP(s) advertised in the NLRI. In other words,
this is the maximum number of additional MPLS labels that may be
pushed by the ingress, in addition to the label(s) of the NRLI
advertised in the BGP UPDATE, before pushing the ELI, EL labels, if
it wish that all downstream LSR be capable of performing load-
balancing based on the entropy label.
Decraene, et al. Expires January 7, 2016 [Page 6]
Internet-Draft BGP Next-Hop Capabilities July 2015
S SHOULD advertise a RLD of:
o its own local RLD minus the number of labels advertised in the
NLRI, if S is the egress of the LSP(s) advertised in the NLRI;
o the minimum of:
* its own node RLD minus the number of labels advertised in the
NLRI;
* the RLD of the LSP from itself to BGP NEXT_HOP of its received
route minus the number of labels received in the NLRI(if any);
* the RLD in the received BGP route (if any).
The first term represents the limitation of the new BGP NEXT_HOP (S),
the second term the contribution from the new (sent) BGP NEXT_HOP (S)
toward the old (received) BGP NEXT_HOP (S'), the third term represent
the contribution from the old BGP NEXT_HOP (S') toward the egress.
255 is a reserved value.
Note that the local RLD is meant as a node value. If a router has
multiple line cards with different capabilities, the router SHOULD
advertise the smallest one. However, a router MAY choose to only
consider the line cards that may be used by the BGP routers receiving
the ELC. e.g. if the ELC is advertised over an EBGP session with peer
S', a router MAY consider only the line cards connected to peer S'.
6.2. Entropy Label Next-Hop Capability error handling
If the Entropy Label Next-Hop Capability is present more than once,
it MUST be considered as received once with a length of 0.
If the Entropy Label Next-Hop Capability is received with a length
other than 0 or 1, it is not considered malformed, but its semantics
are exactly the same as if it had a length of 0. This is to allow
for graceful future extension.
7. IANA Considerations
7.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.
Decraene, et al. Expires January 7, 2016 [Page 7]
Internet-Draft BGP Next-Hop Capabilities July 2015
7.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
128-250 Standards Action
251-254 Experimental Use
255 Reserved
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-250 Unassigned
251-255 Experimental This document
255 Reserved This document
8. Security Considerations
This document does not introduce new security vulnerabilities in BGP.
Specifically, an operator who is relying on the information carried
in BGP must have a transitive trust relationship back to the source
of the information. Specifying the mechanism(s) to provide such a
relationship is beyond the scope of this document. Please refer to
the Security Considerations section of [RFC4271] for security
mechanisms applicable to BGP.
9. 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].
The authors wish to thank John Scudder for the discussions on this
topics and Eric Rosen for his review of this document.
Decraene, et al. Expires January 7, 2016 [Page 8]
Internet-Draft BGP Next-Hop Capabilities July 2015
10. References
10.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-19 (work in progress), April 2015.
[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.
10.2. Informative References
[I-D.ietf-mpls-spring-entropy-label]
Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
Shakir, R., Xu, X., Henderickx, W., and J. Tantsura,
"Entropy labels for source routed stacked tunnels", draft-
ietf-mpls-spring-entropy-label-00 (work in progress),
March 2015.
[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.
Authors' Addresses
Bruno Decraene
Orange
Email: bruno.decraene@orange.com
Decraene, et al. Expires January 7, 2016 [Page 9]
Internet-Draft BGP Next-Hop Capabilities July 2015
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
USA
Email: kireeti.kompella@gmail.com
Wim Henderickx
Alcatel Lucent
Copernicuslaan 50
Antwerp 2018, CA 95134
Belgium
Email: wim.henderickx@alcatel-lucent.com
Decraene, et al. Expires January 7, 2016 [Page 10]