Re: [Idr] WGLC is for "BGP Router Capabilities Attribute” [was: Re: WG LC for draft-ietf-idr-entropy-09 (8/29 to 9/12/2023)]

[Robert Raszuk <[e-mail]>]

Hey Kaliraj,

In my opinion it is never a good thing to standardize multiple ways to do
the same thing.

And it seems that what currently started as "ELCv1/ELCv2 bug" fix exploded
to unbounded container (as we already see completely opaque to BGP) to
carry various node's characteristics.

So in my honest opinion we should progress MNH draft and not push ELCv3 as
you say "fix".

Cheers,
Robert


On Mon, Sep 25, 2023 at 8:43 AM Kaliraj Vairavakkalai <[e-mail]>
wrote:

> > The question was - if MNH can signal EL why do we need ELCv3 at all.
> Why don't we just use the MNH attribute instead ?
>
>
>
> That is a good question.
>
>
>
> I believe the urgency with ELCv1/ELCv2 bug could be the reason. These are
> already present in shipping code.
>
>
>
> So I think we need a timely fix for the problem with existing “ELCv1/ELCv2
> + PNH(attr 14)” usage, that is independent of MNH.
>
>
>
> ELCv2/ELCv3 has followed the same mechanism as MNH, regarding how validity
> of the attribute is verified,
>
> by carrying the PNH-address in the attribute to cross check at receiver.
> This shows that WG is already in agreement on that part of MNH draft.
>
>
>
> Thanks,
>
> Kaliraj
>
> Juniper Business Use Only
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Saturday, September 23, 2023 at 3:23 PM
> *To: *Kaliraj Vairavakkalai <[e-mail]>
> *Cc: *Jeffrey Haas <[e-mail]>, John Scudder <[e-mail]>,
> [e-mail] <[e-mail]>, Sue Hares <[e-mail]>
> *Subject: *Re: [Idr] WGLC is for "BGP Router Capabilities Attribute”
> [was: Re: WG LC for draft-ietf-idr-entropy-09 (8/29 to 9/12/2023)]
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
> > My speculation is that if IDR adopts the multi-next-hop work, it would
> be appropriate to include something like the work in draft-ietf-idr-entropy
> as part of the multi-next-hop proposal.  I.e., the two pieces of state
> should be tightly coupled into a single path attribute.
>
>
>
> Pls see
> https://www.ietf.org/archive/id/draft-kaliraj-idr-multinexthop-attribute-09.html#section-5.4.3.1
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-kaliraj-idr-multinexthop-attribute-09.html*section-5.4.3.1__;Iw!!NEt6yMaO-gk!Gpbyv8DmF3PYhUm2kyzyd7BIB3tJ1XoR0LGGy4wZv1pj2CyCAVpLp3e0zmououR_Ip_yc8VXhgL8Lfb6$>
>
>
>
> MNH does include EL capability tightly coupled per nexthop leg in the same
> attribute.
>
> So the ELCv3 does not need to apply to the MNH. If that was the question
> being asked.
>
>
>
>
>
> The question was - if MNH can signal EL why do we need ELCv3 at all. Why
> don't we just use the MNH attribute instead ?
>
>
>
> Thx,
>
> R.
>
>
>
>
>