Hi Tony, Thanks for your replies. Much appreciated
Please see inlines [Bruno] In any case, that's fine to have a different perspective because we do (e.g., vendor vs operator) Orange Restricted From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Tuesday, November 21, 2023 5:45 PM To: DECRAENE Bruno INNOV/NET <[email protected]> Cc: Yingzhen Qu <[email protected]>; [email protected]; lsr <[email protected]> Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) 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: a. 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. [Bruno] Personally, I'd prefer that the LSR WG works on making a good long term specification for people using it rather than accommodate short term aspects such as pre-standard implementations. (Plus some implementations have no problem with claiming support for an RFC while not following the spec (e.g., RFC 3107).) If we are to the point that 1) the argument to adopt MP-TLV is because it's already implemented by some implementations, plus that 2) we can't change anything in the draft because there are pre-standard implementations (even if agree that it would be better cf "[LES:] In principle I agree." [A]) then let's just rubberstamp those implementations and close the WG. Furthermore, it is highly unlikely that any implementation is going to actually comply just because of our choice of adjective here. [Bruno] Exactly my above point: existing implementations may not bother and claims compliancy anyway. So, what's the problem with changing the text in the draft? 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. [Bruno] In my perspective, the control is required to not break existing networks. I agree with you that this is not required for interoperability with other MP-TLV implementations, but to me this is required for interoperability with RFCs having specified the existing TLVs a. b. 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. [Bruno] I was referring to Les email [A], in particular "[LES:] Again, this depends on the codepoint. In the case of Neighbor/Prefix Reachability advertisements, the impact on forwarding is highly likely (as your wording states). " [A] https://mailarchive.ietf.org/arch/msg/lsr/jZJi3xe8BcEpmlAG-P_LfSf-FgY/ b. c. 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. [Bruno] At worst that may only delay RFC publication. All other steps would not be delayed so I don't think that this would delay the feature. Plus draft-qgp-lsr-isis-pics-yang seems short to me and could probably even be made even shorter if needed. So eventually it could be progressed quickly. 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. [Bruno] Indeed. And the related question is whether the WG is allowed to modify the content of that document or whether the document is as-is because there exist pre-standards implementations. Regards, --Bruno Regards, Tony ____________________________________________________________________________________________________________ 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
