Hi Tony, From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Monday, September 9, 2024 7:20 PM To: DECRAENE Bruno INNOV/NET <[email protected]> Cc: Les Ginsberg <[email protected]>; Les Ginsberg <[email protected]>; Yingzhen Qu <[email protected]>; lsr-chairs <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)
Hi Bruno, As you know, there are several TLVs that have been MP-TLV for a very long time (e.g. ROUTER CAPABILITY). Having these be MP is a practical operational necessity already today. Disabling this on any node would likely break any network that has some fairly common features (e.g. FlexAlgo) enabled. [Bruno] I meant for the newly defined MP-TLV. The one for which MP handling is changed by this document. TLVs which have been defined with MP-TLV from day one do not create interop issue. It’s the change of behavior when handling TLV X of a new implementation which create an interop issue with the handling of TLV X from old implementations. If it’s just a wording issue, I’m confident that someone can craft the right wording. What is the point of a knob that cannot be turned off? [Bruno] I agree that the point is to be able to turn it off. Then you’re back to requiring per-TLV configuration. No thanks. [Bruno2] Nope. I’ve written down my proposed change and it does not include that. If you are ok with a required _single_ configuration controls to enable/disable generation of MP-TLVs (for the TLVs extended by this draft) we are good. Per-TLV configuration is out of scope of this thread. Also, I don’t think we’re trying to create any “newly defined MP-TLV”. The point is to codify what has been done and create a default path moving forward. [Bruno2] RFC5305 does not support MP-TLV for TLV 22 and draft-ietf-lsr-multi-tlv acknowledges that. Specification of MP-TLV for TLV 22 is introduced and defined in draft-ietf-lsr-multi-tlv --Bruno T ____________________________________________________________________________________________________________ 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.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
