Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)

Aijun,

> No !

Yes !

Transitiveness is an important characteristic of BGP Attribute. And there
are actually a valid reasons why next-hop-capability defines it as
non-transitive.

I am not convinced that authors of next-hop-capability draft should make it
transitive as it may break a number of other use cases (or at least make
them fragile).

Sure next-hop-capability draft could define a new attribute as transitive
for EL and perhaps other use cases.

On the other hand draft-scudder-idr-entropy-label could also add a few
lines to make it more generic and perhaps could get renamed as
non-transitive-next-hop-capability draft if this is what you are really
after. The advantage could be keeping more next-hop information under the
same attribute code-point.

Frankly speaking IMHO next hop capabilities really belong to underlay
signalling and not the overlay. And by underlay I mean not only via
extensions to IGPs, but use of proposals like DROID (draft-li-lsr-droid).
There is really no need (not to say it is a waste) to repeat the same
attribute with each advertisement of millions of routes. But we are where
we are. Optimal and well architected solutions can not be deployed
overnight.

Cheers,
Robert.

On Thu, Sep 29, 2022 at 2:05 AM Aijun Wang <wangaijun@tsinghua.org.cn>
wrote:

> Hi, Acee:
>
> Then I can conclude that you, Robert and also others that support
> forwarding this draft are preferring to the short term solutions, given
> that all you know there existing already one more generic solution which
> can be revised easily to solve the problem.
>
> Then begin the Loop—“Publication(RFC6790)—Depreciate(RFC7114)—Depreciate
> Depreciated(draft-scudder-idr-entropy-label)—Depreciate Depreciate
> Depreciated(draft-ietf-idr-next-hop-capability)”
>
> Can anyone call the above procedures efficient? more productive?
> reasonable selection by IDR experts?
>
> No! Please select the best approach to make the IETF standards more
> influential, not the opposite.
>
> Aijun Wang
> China Telecom
>
> On Sep 28, 2022, at 19:51, Acee Lindem (acee) <acee@cisco.com> wrote:
>
> 
>
> Hi Sue, Aijun, Robert,
>
>
>
> If it helps in gauging consensus, I support adoption of
> draft-scudder-entropy-label-01 for the same reasons as Robert. The
> progression of ietf-idr-next-hop-capability is a separate matter which
> should be discussed in a separate thread.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <
> robert@raszuk.net>
> *Date: *Wednesday, September 28, 2022 at 7:09 AM
> *To: *Aijun Wang <wangaijun@tsinghua.org.cn>
> *Cc: *Susan Hares <shares@ndzh.com>, IDR List <idr@ietf.org>
> *Subject: *Re: [Idr] WG adoption call for
> draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
>
>
>
> Aijun,
>
>
>
> Work on RFC6790 started in 2008.
>
>
>
> Mean time there are real networks running which need signalling solutions.
> This is not green field nor IETF only game to produce RFCs.
>
>
>
> There are practical aspects of protocol extensions addressing real needs.
> And even if I-D.ietf-idr-next-hop-capability would become an RFC tomorrow
> it is non-transitive so not only upgrade to egress and ingress is needed
> but also BGP RRs RSs ASBRs with no-next-hop-self etc ... would need to
> recognize it in order to propagate it.
>
>
>
> Lastly, I am not sure what is the time unit - when you are referring to
> "hurry" in IDR WG :)
>
>
>
> Best,
>
> Robert
>
>
>
> On Wed, Sep 28, 2022 at 12:58 PM Aijun Wang <wangaijun@tsinghua.org.cn>
> wrote:
>
> Hi, Robert:
>
>
>
> Then for the advertisement of such capabilities, the journey will be:
>
> 1) RFC6790
>
> 2) RFC 7447(depreciated RFC6790)
>
> 3) RFC****(depeciated RFC7447 again, based on the final document of
> draft-scudder-idr-entropy-label-01)
>
> 4) RFC####(depeciated RFC**** again, based on the final document
> of [I-D.ietf-idr-next-hop-capability]
>
>
>
> Can the IDR experts spend their energies in more efficient manners?
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Sep 28, 2022, at 17:14, Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi Aijun,
>
>
>
> Signalling capability to process entropy labels IMO should be signalled in
> a transitive manner. Requirement that BGP nodes like RRs which do not
> modify the next hop understand the attribute is not justified.
>
>
>
> On that basis alone I think the proposed document should progress. The
> fact that it evolved with time from RFC6790 and got deployed is another
> factor.
>
>
>
> If/when next-hop-capability adds transitive option and get's deployed I
> guess this doc could be moved to historical however for now it attempts to
> address real deployments by allocating valid codepoint for it.
>
>
>
> Thx,
>
> R.
>
>
>
> On Wed, Sep 28, 2022 at 2:23 AM Aijun Wang <wangaijun@tsinghua.org.cn>
> wrote:
>
> Hi, Sue:
>
>
>
> Want to ask where are the consensus on the list for this draft? Given this
> draft has contradicted with the existing WG draft which has been pointed
> out by several several service providers?
>
> As also mentioned in your list questions, there is necessary to discuss
> the short term and long term improvements of BGP next hop in the coming
> interim meeting, then what’s the reason to adopt this document in hurry?
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> On Sep 28, 2022, at 01:14, Susan Hares <shares@ndzh.com> wrote:
>
> The chairs have reviewed the IDR WG discussion and feedback from
> implementers on draft-ietf-idr-entropy-label-01.txt.
>
>
>
> The consensus from this review is that we should:
>
> 1) adopt draft-scudder-idr-entropy-label-01 as
>
> draft-ietf-idr-entropy-label-01
>
>
>
>
>
> 2) Hold a discussion of BGP Next-Hop technology to discuss
>
> the needs for current and future standards on BGP Next Hop.
>
>
>
> During this interim we will discuss the open proposals for
>
> BGP Next HOPS to determine what technology goes forward
>
> toward standardization.
>
>
>
> IDR needs the feedback from implementers and operators
>
> about the short term and long-term improvements to
>
> BGP Next hop.
>
>
>
> Cheerily, Sue
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>