Hi Les, Agree that we have discussed all this also on the WG mailer previously - so they are not new. I also agree that these two points are wider beyond the scope of this document (agreed at adoption) - just that they are perhaps a "next step".
That is why I've said that these points are non-blocking - the document clearly states that these are outside the scope as well. I hope we (the WG) will tackle those aspects in separate document(s). Thanks, Ketan On Thu, Jul 4, 2024 at 12:23 AM Les Ginsberg (ginsberg) <[email protected]> wrote: > Ketan – > > > > Thanx for the support. > > Responses inline. > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Wednesday, July 3, 2024 9:56 AM > *To:* Yingzhen Qu <[email protected]> > *Cc:* lsr <[email protected]>; lsr-chairs <[email protected]> > *Subject:* [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 > - 7/15/2024) > > > > Hi All, > > > > I thank the authors for the work on this draft and support its > publication. This work was very much needed for the enablement of new > feature sets in ISIS networks and the specification will aid > interoperability. > > > > My only "grudge" is something that I have brought up previously on this > draft [1] and perhaps there may still be some interest in the WG/authors to > take care of them? > > > > 1) Mandate that the non-key part is identical in all the parts and if not > recommend that the value in the first part is taken. Or, say something > about handling this condition than saying "error and out of scope". > > > > *[LES:] The authors discussed this aspect.* > > *What we decided was that the scope of this draft was to clearly define > the generic aspects of multi-tlv – not to discuss the peculiarities of any > specific codepoint.* > > *With that in mind, Section 4 – and specifically the examples provided – > is meant only to illustrate what a “key” is.* > > *There is considerably more that could be said about each specific > codepoint – but we believe that is out of scope for this document.* > > > > > > 2) Since the early versions of the draft, a lot of effort has been put on > cataloguing TLV/sub-TLVs and their applicability for MP. From there, it is > only one more step to actually specify the "key" and "non-key" parts of > TLVs (where this is not done already) in an appendix section. This is > important for interoperability. The draft today covers two of the most > prominent TLVs but does not cover the others. > > > > *[LES:] Again, the intent of this document is to clearly describe the > generic Multi-TLV mechanism – not to discuss the specifics of each > codepoint. To do so would expand the scope of the document beyond any > reasonable boundaries.* > > *For example, in the case of Neighbor TLVs (such as TLV 22), there are a > wide variety of implementation strategies.* > > *Some implementations send only LinkIDs all the time.* > > *Some implementations send endpoint addresses (when available) and not > Link IDs.* > > *Some implementations send endpoint addresses and Link IDs.* > > *All of these options are valid – but may impact interoperability > depending on the “generosity” of the receivers.* > > *And some commonality is required – independent of Multi-TLV – in order > for two-way connectivity check to work correctly.* > > > > *It is not in the scope of this document to include such a discussion – > and the use of Multi-TLV does not introduce new issues in this regard.* > > *This is why we restricted ourselves to only discussing “what a key is” in > the examples.* > > *The discussion – even for the two examples - is not exhaustive and is not > meant to be.* > > > > *If there is a significant interoperability issue with a particular > codepoint, some other document will have to be written/updated to address > that.* > > > > * Les* > > > > That said, I won't hold this document if I am in the rough on this. > > > > Thanks, > > Ketan > > > > [1] https://mailarchive.ietf.org/arch/msg/lsr/qQkeAHnw2qjrGoySbES4EVafgY4/ > > > > > > On Tue, Jul 2, 2024 at 11:39 AM Yingzhen Qu <[email protected]> > wrote: > > Hi, > > > > This email begins a 2 week WG Last Call for the following draft: > draft-ietf-lsr-multi-tlv-01 - Multi-part TLVs in IS-IS > <https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/> > > > > Please review the document and indicate your support or objections by July > 15th, 2024. > > Authors, > > > > Please indicate to the list, your knowledge of any IPR related to this work. > > > > Thanks, > > Yingzhen > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
