Bruno - First, without dismissing your comments, this is a WG adoption call - not a Last Call to publish a draft as an RFC (as Tony has pointed out). Could you state unambiguously whether you support adoption or not?
I am in agreement with Tony's responses. I think my earlier reply to you is very much consistent with Tony's reply. Some additional responses inline. From: bruno.decra...@orange.com <bruno.decra...@orange.com> Sent: Tuesday, November 21, 2023 9:27 AM To: Tony Li <tony...@tony.li> Cc: Yingzhen Qu <yingzhen.i...@gmail.com>; draft-pkaneria-lsr-multi-...@ietf.org; lsr <lsr@ietf.org> Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) 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 <tony1ath...@gmail.com<mailto:tony1ath...@gmail.com>> On Behalf Of Tony Li Sent: Tuesday, November 21, 2023 5:45 PM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> Cc: Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>> 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/ [LES:] It is out of scope for the MP draft to specify what risks may be associated with each and every codepoint that has the potential to require use of MP. Such an analysis would be lengthy and inaccurate and bloat the draft to no useful purpose. It took 20 years before MP usage for Neighbor/Prefix advertisements became a realistic deployment scenario. Do you believe that folks 20 years ago could have accurately predicted the risks for these two TLVs? 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. [LES:] While I would like to believe that progress on draft-qgp-lsr-isis-pics-yang will be swift, I think the initial feedback we have received suggests otherwise. There have already been a number of differences of opinion as to appropriate content and this is an important discussion to have because we are setting a template for many such drafts in the future. I also argue that the two drafts are logically not related. The PICS draft is addressing the need for operators to be able to obtain an accurate implementation report for the routers in a network. This isn't specific to the use of MP and in fact isn't directly related to MP at all. MP has only highlighted that in order to safely deploy features in a network operators need such information - which is an existing problem. 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. [LES:] I don't understand your response. Further discussion of the content of the MP draft will happen post adoption - just as it has for every other document which has been adopted in the history of the IETF. Further, the heart of the document is explanatory/informational - not normative. I don't see risk that "early implementations" will not interoperate with implementations based on later versions of the draft because the draft is not altering protocol behavior. There is only one new codepoint introduced in the document (capabilities advertisement) and that has been explicitly defined to not be required so as not to introduce interoperability issues. Les 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
