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

[[e-mail]]

From: Robert Raszuk <[e-mail]>
Sent: Tuesday, October 4, 2022 6:34 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: [e-mail]; Susan Hares <[e-mail]>; Aijun Wang <[e-mail]>
Subject: Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)


> Entropy Label Capability is related to the capability of the FEC/NLRI.

I see nothing wrong to advertise it per NH itself. Maybe we need both to have finer granularity.

Again, knowing that the BGP NH supports EL does not tell you anything with regards to whether or not you can insert an EL on a given LSP. Cf https://www.rfc-editor.org/rfc/rfc6790.html#section-5.2


> Finally, on a side note, ELC is typically needed/advertised for LSP i.e. PE’s loopback.
> In most ASes this is not millions of routes.

True but to the best of my knowledge not many networks use BGP over BGP over IGP.

Not sure what use case you have in mind.
My use case is inter-AS VPN option C with BGP ELC being attached to 3107 PE loopbacks’ addresses. In this case, the BGP NH is the ASBR and the NLRI/FEC is the PE loopback address in the remote/egress AS. That’s also the use case described in https://www.rfc-editor.org/rfc/rfc6790.html#section-5.2

Regards,
-Bruno

Thx,
R.



On Tue, Oct 4, 2022 at 6:24 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

Please see inline [Bruno]


From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Robert Raszuk
Sent: Thursday, September 29, 2022 8:56 AM
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)

Aijun,

[…]

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.

[Bruno] There may be a misunderstanding on draft-ietf-idr-next-hop-capability:
- As per the name of the draft, draft-ietf-idr-next-hop-capability advertises “BGP Next-Hop dependent capabilities” and not “BGP Next-Hop capabilities”. i.e.
- a capability of the route which is dependent on the BGP NH and subject to change/removal when the BGP NH change.
- not a capability of the BGP NH per-see
- Entropy Label Capability is related to the capability of the FEC/NLRI. The information that the BGP NH be entropy label capable does not say anything related to the EL capability of the FEC/NLRI. So ELC need to be advertised on a per FEC/NLRI basis.

Finally, on a side note, ELC is typically needed/advertised for LSP i.e. PE’s loopback. In most ASes this is not millions of routes.

Cheers,
--Bruno



Cheers,
Robert.

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


Orange Restricted


Orange Restricted

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.