Eric -
Thanx very much for your careful review and your kind words. I fully agree - Yingzhen deserves kudos for her excellent shepherd's report. Please see responses inline. I'll wait for your agreement to my responses before publishing an updated version. > -----Original Message----- > From: Éric Vyncke via Datatracker <nore...@ietf.org> > Sent: Monday, April 7, 2025 7:58 AM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-lsr-multi-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; > yingzhen.i...@gmail.com > Subject: [Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-multi-tlv-13: > (with > COMMENT) > > Éric Vyncke has entered the following ballot position for > draft-ietf-lsr-multi-tlv-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> > positions/<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-lsr-multi-tlv-13 > CC @evyncke > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks (and congratulations) to Yingzhen Qu for the shepherd's > detailed > write-up including the WG consensus (and the history) *and* the justification > of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## COMMENTS (non-blocking) > > ### Abstract > > s/New technologies are adding new information/New specifications and IS-IS > extensions are adding new information/ > [LES:] It seems to me that it is the demands of the industry which drive the need for protocol extensions - which then leads to new specifications. So I think the current wording in the draft is preferred. ?? > ### Section 1 > > Unsure whether IS-IS is used over the public Internet in `The continued growth > of the Internet` :-) > [LES:] The intent here is to say that Internet growth leads to greater scale - which is what requires the protocol extensions defined in this document. This does not imply that where IS-IS itself is used has changed. Again, I prefer to leave the current wording unchanged. > In the first paragraph, it is unclear whether the 255 applies per TLV or for > the whole set of TLV (even if the reader can have a guess, let's be clear). [LES:] I have revised the text to say: "The original TLV definition limits each TLV to a maximum of 255 octets of payload..." > > s/Any future *document* *which* proposes/Any future *IETF specification* > *that* > proposes/ ? > > Should there be an exhaustive list rather than `Some examples of this are` ? > [LES:] I think not. The "exhaustive list" is specified in the IANA section where we specify MP applicability for all codepoints. > Please introduce "LSP" before first use. > [LES:] Done. > Strongly suggest to indicate that the MP-TLV capability is negotiated (as I > had > big ??? in mind until section 7). [LES:] MP-TLV is NOT negotiated - and there is no practical way to do that. Safe use of MP-TLV for a particular codepoint requires all nodes in the network to support it - as discussed in Section 8. But having implementations dynamically enable/disable MP-TLV based on some advertised state is extremely problematic. It can lead to highly undesirable oscillation in the event a node which does/does not support MP-TLV is added/removed from the network. This is a non-goal. Which is why Section 7 states: "This advertisement is for informational purposes only. Implementations MUST NOT alter what is sent or how what is received is processed based on these advertisements." > > ### Section 4 > > Bear with my lack of IS-IS expertise, but can a IIH message be fragmented in > several layer-2 packets ? If so, how can a node differentiate between recent > and old TLV in "MP-TLV" bundle (i.e., are these TLV parts of a unique bundle > or > separates ones) ? > [LES:] No - IIHs do not support fragmentation. Occurrences of MP-TLV in an IIH are within a single PDU. > `Breaking of a single sub-TLV or other data unit across TLVs MUST NOT be > done` > what is the expected behavior when receiving such a TLV ? > [LES:] The result of doing so is to send an invalid TLV. Defining how this is to be handled is the responsibility of the document which defines the codepoint, but RFC 8918 provides general guidance. I will add a reference. > ### Section 5 > > Does the basis IS-IS specification cover the case when several TLV having the > same Type have conflicting values ? Should there be text about this corner > case > ? [LES:] This is discussed in Section 5 - specifically the last paragraph. > > ### Section 6 > > Be more assertive and use "MUST" in `Therefore any new codepoints defined > by > future protocol extensions will explicitly indicate the applicability of > MP-TLV > procedures to the new codepoints` > [LES:] I am not convinced this is necessary or appropriate. With the changes to the IANA registries, IANA will require this to be specified before a new RFC defining a new applicable codepoint can be published. The text here is simply describing the effect of the registry changes. > ### Section 7 > > I find this section under-specified , e.g., isn't the following wishful > thinking `It is presumed that if such support is provided that it applies to > all relevant codepoints`? > [LES:] We are trying to describe what real implementations will do. We do not expect any implementation to add MP-TLV support for every applicable codepoint before claiming to support this new RFC. This is because there is substantial work - much of it unique to each codepoint - before MP-TLV support for a given codepoint is realized. The new capability advertisement only provides a Boolean indication - not a codepoint specific indicator - which is why it is used only as an indicator that an implementation provides MP-TLV for "some" (or if you prefer "at least one") applicable codepoints. One can debate the usefulness of such an advertisement, but the WG consensus was that it was better to have an indication that an implementation has some MP-TLV support than to have none at all. > Why not a "MUST" in `SHOULD include this sub-TLV in a Router Capability TLV` > ? > [LES:] A number of reasons: 1)There are existing implementations which support MP-TLV for some codepoints - requiring this advertisement would introduce backwards compatibility issues 2)Given that this sub-TLV is for informational purposes only, requiring it to be sent seems inappropriate. Implementations which want to be helpful to operators will likely choose to send it, but if they do not claiming that such an implementation is non-conformant serves no useful purpose. > ### Section 8 > > s/presence of routers *which* do not correctly/presence of routers *that* do > not correctly/ > > Please explain the consequences (or when it can be bypassed) of the 2 > "SHOULD". [LES:] The first sentence in Section 8 discusses this - as does the second paragraph of Section 7. The exact consequences are specific to each codepoint. > > ### Section 9.1 > > Suggest adding informative references to the IANA registries URIs. > [LES:] Well - if you insist 😊. I do note that IANA itself does not typically do this when updating IANA sections which create new registries. ?? > ### Section 9.2 > > Should there be guidance for the designated experts ? > [LES:] Guidance is provided in RFC 7370 - which is explicitly stated at the top of https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml > ## NITS (non-blocking / cosmetic) > > ### Section 1 > > `PDU` acronym is never used, so do not introduce it ;) [LES:] Well, now that I have expanded "LSP", PDU is used - so I think we are OK. 😊 Les > > > > _______________________________________________ > Lsr mailing list -- lsr@ietf.org<mailto:lsr@ietf.org> > To unsubscribe send an email to lsr-le...@ietf.org<mailto:lsr-le...@ietf.org>
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
