Hi Tony,
Orange Restricted From: Tony Li <[email protected]<mailto:[email protected]>> On Behalf Of Tony Li Sent: Wednesday, November 22, 2023 5:03 PM To: DECRAENE Bruno INNOV/NET <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; lsr <[email protected]<mailto:[email protected]>> Subject: Re: draft-pkaneria-lsr-multi-tlv Hi Bruno, We are still waiting to hear whether or not you are in favor of adopting this document. Thank you (I guess). But where is this coming from? I understand that: * You are waiting for the end of the adoption call * I MAY comment on the adoption call (until its end). I don’t believe that I promised that I would comment on the adoption call, so I’m not sure why you are kind of complaining that I haven’t do it yet. To clarify, so far: * I have reviewed the document and sent questions and comments * I have not stated any position on the adoption call One might infer your intentions, Really?? Definitely not me at least. And I’m not even capable of inferring what one would infer. Following this line, one might infer the outcome. It seems that there are existing implementations and just like they did not consult the WG to enable this non-compatible feature, they will not change whatever one might say (not even change the control to enable this mechanism. Plus they would even feel been punished.). C’est la vie. Draft does not really need a code point. The new column in the IANA registry is somewhat useful but probably not required (For past TLVs, history shows that it was not felt as required and this document can document it. For new TLVs, reading the spec should be just fine). So, why not use the Independent Submission stream to document what is essentially a vendor-specific extension which has been defined independently of the IETF? E.g, à la RFC 7348 [1]. That’s probably the fastest way to publication at this point and will save time, work and frustration for everyone. [1] https://datatracker.ietf.org/doc/html/rfc7348 Regards, --Bruno but the chairs need it to be explicit. Regards, Tony On Nov 22, 2023, at 5:37 AM, [email protected]<mailto:[email protected]> wrote: Hi authors, Please find below some specific comments on the document. Thank you for the effort put in the IANA section. (to indicate wo which (sub-) TLV MPL applies to). §1 “However, this has not been done for many legacy TLVs, leaving the situation somewhat ambiguous.” To me the current situation is not ambiguous. The behavior is defined in the spec/RFC. If a behavior is not defined, then it’ is not specified and not allowed. Please rephrase. -- “The intent of this document is to clarify and codify the situation by explicitly making multiple occurences of a TLV the mechanism for scaling TLV contents, except where otherwise explicitly stated.” Similar comment. :s/clarify/specify -- “The mechanism described in this document has not been documented for all TLVs previously” Similar comment. :s/documented/specified -- OLD: so it is likely that some implementations would not interoperate correctly if these mechanisms were used without caution. NEW: so non compliant implementations would not interoperate correctly with compliant implementations (alternatively, that part could be just removed) -- “The mechanism described in this document has been used explicitly by some implementations, so this document is not creating an unprecedented mechanism.” Proprietary non-compliant implementations are not an excuse for RFC. If you need an introduction, you could to the existing TLV specified with MP. (but since this is already stated at the beginning of this section IMO we can just remove that part) -- §4.1 “It is RECOMMENDED that the link identifiers be the first sub-TLVs.” For my information, why is so? · As currently formulated implementations MUST support any order · What the benefit of the ordering given that implementations MUST parse all sub-TLVs? -- §4.1 “Optionally one or more of the following identifiers:” […] “The key information MUST be replicated identically.” Do you mean that all identifiers MUST be replicated? If so, could you please make this point even more explicit e.g., “(i.e., with all identifiers”) -- 5. Procedure for Receiving Multi-part TLVs “If the internals of the TLV contain key information, then replication of the key information should be taken to indicate that subsequent data MUST be processed as if the subsequent data were concatenated after a single copy of the key information.” Given that this section is the key normative part, I’m not found of the “should”. I would suggest :s/should be/is (but “MUST” also works for me) -- §6 “The lack of explicit indication of applicability of Multi-Part TLV procedures to all codepoints to which such procedures could be applied contributes to potential interoperability problems if/when the need arises to advertise more than 255 bytes of information for such a codepoint.” Same comment. If it’s not specified in the existing RFC this is not supported/compliant. This is not a “lack of indication of applicability”. -- “This document makes explicit the applicability of Multi-Part TLV procedures for all existing codepoints” :s/makes explicit/specify -- §7.2 MP-TLV Capability Advertisement “It is presumed that if such support is provided that it applies to all relevant TLVs. It is understood that in reality, a given implementation might limit MP-TLV support to particular TLVs based on the needs of the deployment scenarios in which it is used.” Let’s not presume anything. Let’s specify it. And we need to specify a clear meaning for the capability, otherwise it has limited value. My preference would be that the meaning is “supports MP-TLV” for TLV x, y, z. (or all TLVs). Alternatively, the value would carry the list of TLV supporting MP-TLV (more complex but since it seems that no implementation will act on the content that seems easy to implement). Alternatively, if there is no clear meaning, let’s not bother with the capability. Thanks, Regards, --Bruno Orange Restricted From: DECRAENE Bruno INNOV/NET Sent: Tuesday, November 21, 2023 1:51 PM To: 'Yingzhen Qu' <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: lsr <[email protected]<mailto:[email protected]>> Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Hi all, I have some concerns with regards to the deployment of this extension in brownfield multi-vendor networks as this could result in the formation of persistent forwarding loops. 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] 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. 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. Some of those comments are not new and have already been expressed on this list [2] I would welcome the feedback of authors on the above proposals before the end of this WG adoption call. Thanks, Regards Bruno [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. [2] https://mailarchive.ietf.org/arch/msg/lsr/WIxRR2ZlOJHjxulfXP6Z8nZtKeU/ [3] https://datatracker.ietf.org/doc/html/draft-qgp-lsr-isis-pics-yang From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of Yingzhen Qu Sent: Friday, November 17, 2023 6:24 PM To: [email protected]<mailto:[email protected]>; lsr <[email protected]<mailto:[email protected]>> Subject: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Hi, This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org)<https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/> Please send your support or objection to the list before December 9th, 2023. An extra week is allowed for the US Thanksgiving holiday. Thanks, Yingzhen Orange Restricted ____________________________________________________________________________________________________________ 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. ____________________________________________________________________________________________________________ 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
