Hi Acee <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 1:19 PM Acee Lindem <[email protected]> wrote: > Speaking as WG member: > > I agree with Tony, the WG intent should be to make the current defacto > solution transparent and provide for backward compatible improvements. > Gyan> I agree with transparency however providing the additional controls on the advertisement aids the deployment in cases where some TLV or sub TLV maybe more risky for the extension than others. I think that provides nice flexibility to operators. > > I’d add that in either case, upgrades will be required for full > interoperability and one might as well update to get the support rather > than to disable it. > Gyan> I agree with upgrading all devices for full support however when their is a mix of upgraded and legacy devices not supporting that’s where the disable advertisement knob can be critical for operators for flexibility during migration until all devices are upgraded. > > Thanks, > Acee > > > On Nov 21, 2023, at 11:45, Tony Li <[email protected]> wrote: > > > Hi Bruno, > > Thank you for your comments. > > > 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] > > [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. > > > > As you know, some systems already generate multi-part TLVs. And they lack > any controls for doing this today. The language that you’re suggesting > would make these systems immediately out of compliance, thereby punishing > them for providing leading technology. Furthermore, it is highly unlikely > that any implementation is going to actually comply just because of our > choice of adjective here. The control is clearly not necessary for > interoperability and we should not overuse our ability to place > requirements on implementations. We all know that the real power comes from > customers who place requirements on vendors and the requirements that we > place in RFCs are only meaningful when describing the requirements for > correct operation of our protocols. Overextending ourselves dilutes our > interoperability requirements. > > > > 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. > > > > What is ’no risk’? We are not competent to make that assesment. That > requires knowing everything about every implementation, past, present, and > future and testing the full cross product of those implementations in all > possible scenarios. > > > > 1. > 2. 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. > > > > That would stall this document indefinitely, pending progress on the YANG > model. Please recall that this document is already two years old and that > this is an adoption call, NOT WGLC. > > The question on the table is not whether this document is perfect. The > question is whether this is worth continuing to work on and whether this > document is the correct basis for that work. I would like to see this > document published sometime this century. > > Regards, > Tony > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
