draft-ietf-idr-next-hop-capability-02.txt   draft-ietf-idr-next-hop-capability-03.txt 
Network Working Group B. Decraene Network Working Group B. Decraene
Internet-Draft Orange Internet-Draft Orange
Updates: 6790 (if approved) K. Kompella Updates: 6790 (if approved) K. Kompella
Intended status: Standards Track Juniper Networks, Inc. Intended status: Standards Track Juniper Networks, Inc.
Expires: August 15, 2018 W. Henderickx Expires: December 28, 2018 W. Henderickx
Nokia Nokia
February 11, 2018 June 26, 2018
BGP Next-Hop dependent capabilities BGP Next-Hop dependent capabilities
draft-ietf-idr-next-hop-capability-02 draft-ietf-idr-next-hop-capability-03
Abstract Abstract
RFC 5492 advertises the capabilities of the BGP peer. When the BGP RFC 5492 advertises the capabilities of the BGP peer. When the BGP
peer is not the same as the BGP Next-Hop, it is useful to also be peer is not the same as the BGP Next-Hop, it is useful to also be
able to advertise the capability of the BGP Next-Hop, in particular able to advertise the capability of the BGP Next-Hop, in particular
to advertise forwarding plane features. This document defines a to advertise forwarding plane features. This document defines a
mechanism to advertise such BGP Next Hop dependent Capabilities. mechanism to advertise such BGP Next Hop dependent Capabilities.
This document defines a new BGP non-transitive attribute to carry This document defines a new BGP non-transitive attribute to carry
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2018. This Internet-Draft will expire on December 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BGP Next-Hop dependent Capabilities Attribute . . . . . . . . 3 2. BGP Next-Hop dependent Capabilities Attribute . . . . . . . . 3
2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Attribute Operation . . . . . . . . . . . . . . . . . . . 4 2.2. Attribute Operation . . . . . . . . . . . . . . . . . . . 4
2.3. Interpreting received Capability . . . . . . . . . . . . 5 2.3. Interpreting received Capability . . . . . . . . . . . . 5
2.4. Attribute Error Handling . . . . . . . . . . . . . . . . 5 2.4. Attribute Error Handling . . . . . . . . . . . . . . . . 5
2.5. Network operation considerations . . . . . . . . . . . . 6 2.5. Network operation considerations . . . . . . . . . . . . 6
3. Entropy Label Next-Hop dependent Capability . . . . . . . . . 6 3. Entropy Label Next-Hop dependent Capability . . . . . . . . . 6
3.1. Entropy Label Next-Hop Capability error handling . . . . 7 3.1. Readable Label Depth . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3.2. Entropy Label Next-Hop Capability error handling . . . . 9
4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 7 4.1. Next-Hop Capabilities Attribute . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4.2. Next-Hop Capability registry . . . . . . . . . . . . . . 9
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
[RFC5492] advertises the capabilities of the BGP peer. When the BGP [RFC5492] advertises the capabilities of the BGP peer. When the BGP
peer is not the same as the BGP Next-Hop, it is useful to also be peer is not the same as the BGP Next-Hop, it is useful to also be
able to advertise the capability of the BGP Next-Hop, in particular able to advertise the capability of the BGP Next-Hop, in particular
to advertise forwarding plane features. This document defines a to advertise forwarding plane features. This document defines a
mechanism to advertise such BGP Next Hop Capabilities. mechanism to advertise such BGP Next Hop Capabilities.
This document defines a new BGP non-transitive attribute to carry This document defines a new BGP non-transitive attribute to carry
skipping to change at page 6, line 40 skipping to change at page 6, line 40
same capabilities or by filtering the BGP Next-Hop Capabilities which same capabilities or by filtering the BGP Next-Hop Capabilities which
are not shared by all anycast nodes. are not shared by all anycast nodes.
For security considerations, a network operator may want to filter For security considerations, a network operator may want to filter
the BGP Next-Hop capabilities advertised to external Autonomous the BGP Next-Hop capabilities advertised to external Autonomous
Systems. Systems.
3. Entropy Label Next-Hop dependent Capability 3. Entropy Label Next-Hop dependent Capability
The Entropy Label Next-Hop Capability has type code 1 and a length of The Entropy Label Next-Hop Capability has type code 1 and a length of
0 octet. 0 or 1 octet.
The inclusion of the "Entropy Label" Next-Hop Capability indicates The inclusion of the "Entropy Label" Next-Hop Capability indicates
that the BGP Next-Hop can be sent packets, for all routes indicated that the BGP Next-Hop can be sent packets, for all routes indicated
in the NRLI, with a MPLS entropy label (ELI, EL) added immediately in the NRLI, with a MPLS entropy label (ELI, EL) added immediately
after the label stack advertised with the NLRI. after the label stack advertised with the NLRI.
On the receiving side, suppose BGP speaker S has determined that 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 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 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 the label stack embedded in the NLRI of route R. Then to forward
skipping to change at page 7, line 24 skipping to change at page 7, line 24
and its capable of handling the ELI during the lookup of the MPLS and its capable of handling the ELI during the lookup of the MPLS
top label. top label.
o Transit LSR case: NH is a transit LSR for the LSP advertised with o Transit LSR case: NH is a transit LSR for the LSP advertised with
the NLRI (i.e. NH swaps one of the label advertised in the NLRI) the NLRI (i.e. NH swaps one of the label advertised in the NLRI)
and next downstream BGP Next-Hop(s) has(have) advertised the and next downstream BGP Next-Hop(s) has(have) advertised the
Entropy Label Next-Hop Capability (or a similar capability Entropy Label Next-Hop Capability (or a similar capability
signalled by protocol P if the route is redistributed, by NH, from signalled by protocol P if the route is redistributed, by NH, from
protocol P into BGP). protocol P into BGP).
3.1. Entropy Label Next-Hop Capability error handling 3.1. Readable Label Depth
When stacked LSPs are used and a LSR nests LSP(s) inside this BGP
signalled LSP, its useful for the ingress LSRs to know how many
labels the BGP Next-Hop and its downstream LSR(s) may read when load-
balancing based on the Entropy Label. In other words, how many
labels the ingress LER may push, before pushing an entropy label that
will be seen by the BGP Next-Hop and its downstream LSR(s).
This maximum number of 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 first octet of 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 MPLS labels that
may be pushed by the ingress, before pushing the ELI, EL labels,
where the BGP Next-Hop and its downstream LSR(s) are capable of
performing load-balancing based on the entropy label.
S SHOULD advertise a RLD of:
o If S is the egress of the LSP(s) advertised in the NLRI: its own
local RLD;
o If S is propagating in BGP a route received in BGP: the minimum
of:
* its own node RLD;
* the RLD of the LSP from itself to the BGP NEXT_HOP of its
received route minus (Number of Labels in the received NLRI -
Number of Labels in the sent NLRI);
* 0 if a RLD is not present in its received routes or the RLD in
the received BGP route minus (Number of Labels in the received
NLRI - Number of Labels in the sent NLRI).
* Note that the first term represents the limitation of the new
BGP NEXT_HOP (S), the second term the contribution of the
LSR(s) between the new BGP NEXT_HOP (S) and the old (received)
BGP NEXT_HOP (S'), the third term represent the contribution
from the old BGP NEXT_HOP (S') toward the egress.
o If S is propagating in BGP a route received in protocol X: the
minimum of:
* its own node RLD;
* the minimum of thg RLD(s) in the received protocol X to reach
the NLRI(s).
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
A, a router MAY consider only the line cards connected to peer A.
Advertisement of the RLD is optional. When used, changes in IGP
routing may trigger BGP re-advertisement and hence will increase BGP
churn. If the RLD is decreased, it SHOULD be readvertised
immediatly. If the RLD is increased is MAY NOT be readvertised
immediatly. We note however that labelled BGP routes are typically
not advertised outside of an administrative domain hence the churn
would be limited to this administrative domain.
3.2. Entropy Label Next-Hop Capability error handling
If the Entropy Label Next-Hop Capability is present more than once, If the Entropy Label Next-Hop Capability is present more than once,
it MUST be considered as received once with a length of 0. it MUST be considered as received once with a length of 0.
If the Entropy Label Next-Hop Capability is received with a length If the Entropy Label Next-Hop Capability is received with a length
other than 0, it is not considered malformed, but its semantics are other than 0 or 1, it is not considered malformed, and its semantics
exactly the same as if it had a length of 0. In other words, are exactly the same as if it had a length of 1. In other words,
additional octets MUST be ignored. This is to allow for graceful additional octets MUST be ignored. This allows for the graceful
future extension. addition of future extensions.
4. IANA Considerations 4. IANA Considerations
4.1. Next-Hop Capabilities Attribute 4.1. Next-Hop Capabilities Attribute
IANA is requested to allocate a new Path Attribute, called "Next-Hop IANA is requested to allocate a new Path Attribute, called "Next-Hop
Capabilities", type Code TBD1, from the "BGP Path Attributes" Capabilities", type Code TBD1, from the "BGP Path Attributes"
registry. registry.
4.2. Next-Hop Capability registry 4.2. Next-Hop Capability registry
skipping to change at page 8, line 37 skipping to change at page 10, line 14
the Security Considerations section of [RFC4271] for security the Security Considerations section of [RFC4271] for security
mechanisms applicable to BGP. mechanisms applicable to BGP.
The advertisement of BGP Next-Hop capabilities to EBGP peers may The advertisement of BGP Next-Hop capabilities to EBGP peers may
disclose, to the peer AS, some capabilities of the BGP node and may disclose, to the peer AS, some capabilities of the BGP node and may
help fingerprinting its hardware model and software version. This help fingerprinting its hardware model and software version. This
may be mitigated by filtering the capability advertised to EBGP may be mitigated by filtering the capability advertised to EBGP
peers. peers.
Security of the Entropy Label capability advertisement is unchanged Security of the Entropy Label capability advertisement is unchanged
compared to [RFC6790] which first defined this signaling. compared to [RFC6790] which originally defined this signaling.
6. Acknowledgement 6. Acknowledgement
The Entropy Label Next-Hop Capability defined in this document is The Entropy Label Next-Hop Capability defined in this document is
based on the ELC BGP attribute defined in section 5.2 of [RFC6790]. 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 The authors wish to thank John Scudder for the discussions on this
topic and Eric Rosen for his in-depth review of this document. topic and Eric Rosen for his in-depth review of this document.
The authors wish to thank Jie Dong and Robert Raszuk for their review The authors wish to thank Jie Dong and Robert Raszuk for their review
skipping to change at page 9, line 41 skipping to change at page 11, line 17
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-mpls-spring-entropy-label]
Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
Shakir, R., and J. Tantsura, "Entropy label for SPRING
tunnels", draft-ietf-mpls-spring-entropy-label-11 (work in
progress), May 2018.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>. December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>. 2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC7447] Scudder, J. and K. Kompella, "Deprecation of BGP Entropy [RFC7447] Scudder, J. and K. Kompella, "Deprecation of BGP Entropy
Label Capability Attribute", RFC 7447, Label Capability Attribute", RFC 7447,
skipping to change at page 10, line 24 skipping to change at page 12, line 7
o Addition of section "Network operation considerations", in o Addition of section "Network operation considerations", in
particular to discuss anycast nodes. particular to discuss anycast nodes.
o Enhanced Security consideration (capability advertised to external o Enhanced Security consideration (capability advertised to external
ASes). ASes).
o Editorial changes and typo corrections. o Editorial changes and typo corrections.
Changes -02: No change. Refresh only. Changes -02: No change. Refresh only.
Changes -03: Addition of the optional Readable Label Depth.
Authors' Addresses Authors' Addresses
Bruno Decraene Bruno Decraene
Orange Orange
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
 End of changes. 11 change blocks. 
22 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/