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

[Mach Chen <[e-mail]>]

Hi John,

Please see my replies inline below...

> -----Original Message-----
> From: John Scudder <[e-mail]>
> Sent: Friday, December 15, 2023 11:29 PM
> To: Mach Chen <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Rtgdir early review of draft-ietf-idr-entropy-label-13
> 
> 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.”

Oh, that's intended to be written like this, I am OK with it.

> 
> […]
> 
> >>> 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.

OK

Now, all my comments are addressed!

Thanks,
Mach


> 
> Thanks,
> 
> --John