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.
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. 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: >> 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. > > >> 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. > > >> 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
