Re: [Idr] I-D Action: draft-ietf-idr-entropy-label-14.txt

[John Scudder <[e-mail]>]

Hi All,

Version 14 incorporates the changes due to Mach Chen's RTGDIR review. The two places that seem worth calling out are these:

OLD:
When a BGP speaker S has a route R it wishes to advertise with next
hop N to its peer, it SHOULD include the ELCv3 capability if it knows
that the egress of the associated LSP L is EL-capable, otherwise it
MUST NOT include the ELCv3 capability. Specific conditions where S
would know that the egress is EL-capable are if S:

NEW:
When a BGP speaker S has a route R it wishes to advertise with next
hop N to its peer, it MAY include the ELP if it knows that the egress
of the associated LSP L is EL-capable, otherwise it MUST NOT include
the ELP. Specific conditions where S would know that the egress is
EL-capable are if S:

Changes SHOULD to MAY, so it’s a small normative change, but anybody who was compliant with the old one will still be compliant with the new one. And,

OLD:
When a BGP speaker receives a labeled route that includes the ELCv3,
it indicates the associated LSP supports entropy labels. This
implies that the receiving BGP speaker if acting as ingress, MAY
insert an entropy label as per Section 4.2 of [RFC6790].

NEW:
When a BGP speaker receives a labeled route that includes the ELP, it
indicates that it can safely insert an entropy label into the label
stack of the associated LSP. This implies that the receiving BGP
speaker if acting as ingress, MAY insert an entropy label as per
Section 4.2 of [RFC6790].

Tightened up the "LSP supports” language. Thanks to Mach for these improvements.

The other substantive change is to add a new code point to the "BGP Next Hop Dependent Capability Codes" registry:

| 2     | NNHN        |draft-wang-idr-next-next-hop-nodes-00 | [e-mail] |

This addresses the problem that until the draft is published as an RFC, IANA can't create a registry. So, we have to have some other way of giving people code points, if they want to develop extensions using this mechanism. Since the working group agreed the registry policy should be first come, first served, it seemed reasonable that anyone who wishes to can request a code point, and we’ll give them one and keep track of it by including it in revisions of the draft.

Thanks,

—John

> On Mar 1, 2024, at 3:06 PM, [e-mail] wrote:
> 
> Internet-Draft draft-ietf-idr-entropy-label-14.txt is now available. It is a
> work item of the Inter-Domain Routing (IDR) WG of the IETF.
> 
>   Title:   BGP Next Hop Dependent Capabilities Attribute
>   Authors: Bruno Decraene
>            John G. Scudder
>            Wim Henderickx
>            Kireeti Kompella
>            Satya Mohanty
>            James Uttaro
>            Bin Wen
>   Name:    draft-ietf-idr-entropy-label-14.txt
>   Pages:   17
>   Dates:   2024-03-01
> 
> Abstract:
> 
>   RFC 5492 allows a BGP speaker to advertise its capabilities to its
>   peer.  When a route is propagated beyond the immediate peer, it is
>   useful to allow certain capabilities, or other properties, to be
>   conveyed further.  In particular, it is useful to advertise
>   forwarding plane features.
> 
>   This specification defines a BGP transitive attribute to carry such
>   capability information, the "Next Hop Dependent Capabilities
>   Attribute," or NHC.  Unlike the capabilities defined by RFC 5492,
>   those conveyed in the NHC apply solely to the routes advertised by
>   the BGP UPDATE that contains the particular NHC.
> 
>   This specification also defines an NHC capability that can be used to
>   advertise the ability to process the MPLS Entropy Label as an egress
>   LSR for all NLRI advertised in the BGP UPDATE.  It updates RFC 6790
>   and RFC 7447 concerning this BGP signaling.
...