Hi, This draft proposes advertisements which are out of spec from the point of existing RFCs and implementations. Enabling one router to send such advertisement while not all routers are upgraded to support this extension will harm the network, potentially very significantly and likely by surprise. That point is not acceptable to me as some networks are critical (e.g., carry emergency calls from both mobile and wireline access). So I believe we need solutions to avoid this.
A first easy solution, from the standpoint of this WG and vendors (rather than operators), is to "delegate" this work to operators. This requires operators to have the ability to control such advertisement. In my opinion, at minimum we need the following change: OLD: It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. NEW: It is REQUIRED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. I would also call for the following text NEW: By default, the sending of MP-TLV for the TLVs extended by this document SHOULD be disabled. As a second step -which could be started now- I would call for solutions allowing for a more automated protection: * Helping operators to know whether the nodes in the IGP support the reception of MP-TLV (on a per TLV basis if this is made granular in draft-pkaneria-lsr-multi-tlv, which is the case today). E.g., draft-qgp-lsr-isis-pics-yang but this could be something else. * Helping nodes to know whether the nodes in the IGP support the reception of MP-TLV (on a per TLV basis if this is made granular in draft-pkaneria-lsr-multi-tlv) and not sending MP-TLV if this is not safe. Yes, this is harder. With this, I do not support nor object adoption of this draft. Note that my concern is not new, and authors had time to accommodate then in a version of the draft or on the mailing list. They did not. So I will likely object RFC publication if the first easy solution is not included in the document and will not take "too late" as an excuse since those points were brought before adoption. Thanks, Regards, --Bruno From: Lsr <lsr-boun...@ietf.org> On Behalf Of Yingzhen Qu Sent: Friday, November 17, 2023 6:24 PM To: draft-pkaneria-lsr-multi-...@ietf.org; lsr <lsr@ietf.org> Subject: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Hi, This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org)<https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/> Please send your support or objection to the list before December 9th, 2023. An extra week is allowed for the US Thanksgiving holiday. Thanks, Yingzhen ____________________________________________________________________________________________________________ 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
