Re: [Idr] Rtgdir early review of draft-ietf-idr-entropy-label-13

[John Scudder <[e-mail]>]

Hi Mach,

A few replies are below (edited for brevity).

> On Dec 11, 2023, at 9:56 PM, Mach Chen <[e-mail]> wrote:
> 
> Hi John,
> 
> Thanks for your prompt response!
> 
> Some replies inline...

[…]

>>> Comments and Questions
>>> In Section 1
>>> It says:
>>> "An NHC carried in a given BGP UPDATE message conveys information that
>>> relates to all Network Layer Reachability Information (NLRI)..." Does
>>> the NLRI include the MP_REACH_NLRI case? If so, how? If not, it's
>>> better to clarify this in the document.
>> 
>> I don't understand this point. Surely, MP_REACH_NLRI is the dominant way of
>> advertising reachable NLRI in BGP updates, the only other way is the legacy
>> encoding for AFI/SAFI 1/1. So, I'm not sure what to clarify here.
> I am thinking about that if the NHC can also apply to MP_REAH_NLRI, then is the "match" checking process based on the NEXT_HOP attribute or the Network Address of Next Hop of MP_REACH_NLRI?

I see your point. At the same time, if we can avoid having this document get into the business of defining exactly what a "next hop" means for a BGP route, I think that would be better. The Section 1 text we are currently discussing is only descriptive, not normative, here is what Section 2.3 has as the normative text: "When a BGP speaker receives a BGP route that includes the NHC, it MUST compare the address given in the header portion of the NHC and illustrated in Figure 1 to the next hop of the BGP route.”

[…]

>>> In Section 3.3,
>>> OLD:
>>> "When a BGP speaker receives a labeled route that includes the ELCv3,
>>> it indicates the associated LSP supports entropy labels." NEW: "When a
>>> BGP speaker receives a labeled route that includes the ELCv3, it
>>> indicates the egress LSR of associated LSP supports entropy labels."
>> 
>> I think this isn't quite right, because of the midpoint case covered in "Is
>> re-advertising a BGP route it received with a valid ELCv3 capability, and is
>> changing the next hop that it has received to N, and knows (for example,
>> through configuration) that the new next hop (normally itself) even if not
>> EL-capable will simply swap labels without popping the BGP-advertised label
>> stack and processing the label below, as with a transit LSR”.
> 
> But what does it mean that an LSP supports entropy labels? Maybe we could change the way of expressing, for example:
> "When a BGP speaker receives a labeled route that includes the ELCv3, it indicates that it can safely insert an entropy label into the label stack of the associated LSP.

I think that's good, I've made the change in my working copy.

Thanks,

--John