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

[Robert Raszuk <[e-mail]>]

One typo:

s/get renamed as non-transitive-next-hop-capability/get renamed as
transitive-next-hop-capability/

Apologies,
R.

On Thu, Sep 29, 2022 at 8:56 AM Robert Raszuk <[e-mail]> wrote:

> 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 <[e-mail]>
> 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) <[e-mail]> 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 <[e-mail]> on behalf of Robert Raszuk <
>> [e-mail]>
>> *Date: *Wednesday, September 28, 2022 at 7:09 AM
>> *To: *Aijun Wang <[e-mail]>
>> *Cc: *Susan Hares <[e-mail]>, IDR List <[e-mail]>
>> *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 <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>