Dear WG I agree with Bruno about the concerns with brownfield multi vendor forwarding loops regarding deployment of MP TLV extension.
+1 one comments by Bruno Comments in-line <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347* On Tue, Nov 21, 2023 at 7:51 AM <[email protected]> wrote: > Hi all, > > > > > > I have some concerns with regards to the deployment of this extension in > brownfield multi-vendor networks as this could result in the formation of > persistent forwarding loops. > > > > As a constructive proposal, and as mitigations, I would like the document > be improved with the following changes: > > 1. Sending MUST be controlled by configuration [1] > 2. For existing TLVs (and “any level of sub-TLVs”), details the TLV > which could be advertised with no risks for the network and TLVs which must > not be advertised before all nodes be upgraded. > 3. Given this document typically may require global support before > this be enabled, I think this draft would be a good candidate for the > addition of the relevant yang module as per draft-qgp-lsr-isis-pics-yang > [3]. I personally don’t see a problem with adding a normative reference to > an individual draft, but if I’m wrong, an option for the chairs to consider > would be to pause this adoption call and start an adoption call for > draft-qgp-lsr-isis-pics-yang. > > Gyan> I agree with a. that sending must be controlled by configuration. > I agree completely that there should be listing of TLVs at any level top or > sub TLV that are supported at no risk and the ones that must not be > advertised before nodes are upgraded. Also am in agreement on c. don’t see > any harm. > Some of those comments are not new and have already been expressed on this > list [2] > > > > I would welcome the feedback of authors on the above proposals before the > end of this WG adoption call. > > > > Thanks, > > Regards > > Bruno > > > > [1] > > 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. > > Gyan> Agreed > > [2] https://mailarchive.ietf.org/arch/msg/lsr/WIxRR2ZlOJHjxulfXP6Z8nZtKeU/ > > > > [3] https://datatracker.ietf.org/doc/html/draft-qgp-lsr-isis-pics-yang > > > > *From:* Lsr <[email protected]> *On Behalf Of *Yingzhen Qu > *Sent:* Friday, November 17, 2023 6:24 PM > *To:* [email protected]; lsr <[email protected]> > *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 > > > > 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. > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
