Hi Tony Some 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 11:46 AM 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. > Gyan> What Bruno is trying to provide I think strengthens the draft with the MUST normative language for enable/disable configuration controls. As this is pre standard implementation if the devices go out of compliance immediately that is “ok” as I see it all during incubation period trailblazing the new features and comes with the territory. So they would just have to upgrade to RFC standard version to be back to compliance. During the I-D standards progression there are changes and updates to the draft pre and post adoption before publication which is normal and any out of compliance devices would just have to upgrade to now be in compliance. From a risk versus reward perspective operators would much rather upgrade to get the latest updated features such as the knob for required enable / disable state for the sake of stability to circumvent an network outage. The control is not necessary for interoperability but it is necessary for stability. I don’t think this is overextending of the SDO standardization arm overstepping boundaries. > > > > 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. > > Gyan> I think that documenting of every implementation caveats and tlv and > sub TLV advertised should have a section in the draft detailing the > implementation extension supporting MP TLV. I think this would greatly > help the draft. Due to the nature of the solution as it’s far from perfect > I think at a minimum providing as much detail about the implementations is > important for operators and as well beneficial to vendors as well. > > > 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. > Gyan> This draft is far from perfect however it does have hope and I think providing the details of the tlv and sub tlvs being implemented will help the draft tremendously. As this draft is far from perfect it does open the door to other solutions such as Big TLV and maybe others that might crop up. > > 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
