Hi, Giuseppe: You are the Ops area expert.
Have you ever noticed that if the proposed document doesn’t provide or defend the “key” information for each possible MP-TLV that list in section https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-07#section-9.2, how the receiver can concatenate the sliced MP-TLV together to recover the original TLV that exceeds the 255 bytes. We can take the example of https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-07#section-3.2.1(Extended IS Reachability), which the author try to shun the issues when you compare the version 06 and version 07 The current version of the document say: “ The key consists of the 7 octets of system ID and pseudonode number plus the set of link identifiers which are present.”, but the definition of this TLV say that “ Optionally one or more of the following link identifiers:” is included in this TLV. Then, for the sender, which link identifiers should be included? If different part of the MP-TLV uses the different link identifiers, they will all be valid “Extended IS Reachability” TLV, should the sender threat them as MP-TLV to concatenate them together, or treat them as multi occurrence of the same TLV, replace the previous one with the newest? I would like to hear your analysis. Aijun Wang China Telecom > On Feb 12, 2025, at 17:06, Giuseppe Fioccola > <[email protected]> wrote: > > Hi Les, > Please see inline [GF]. > > Regards, > > Giuseppe > > -----Original Message----- > From: Les Ginsberg (ginsberg) <[email protected]> > Sent: Tuesday, February 11, 2025 6:02 PM > To: Giuseppe Fioccola <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: RE: Opsdir last call review of draft-ietf-lsr-multi-tlv-06 > > Giuseppe - > > Thanx very much for the prompt response. > I think we are in agreement on most things. > > [GF]: Agree. > > Some responses inline. Look for {LES2:]. > >> -----Original Message----- >> From: Giuseppe Fioccola >> <[email protected]> >> Sent: Tuesday, February 11, 2025 12:34 AM >> To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] >> Cc: [email protected]; [email protected]; >> [email protected] >> Subject: RE: Opsdir last call review of draft-ietf-lsr-multi-tlv-06 >> >> Hi Les, >> Thank you for considering my comments. >> Please see my replies inline as [GF] >> >> Regards, >> >> Giuseppe >> >> -----Original Message----- >> From: Les Ginsberg (ginsberg) <[email protected]> >> Sent: Monday, February 10, 2025 6:39 AM >> To: Giuseppe Fioccola <[email protected]>; [email protected] >> Cc: [email protected]; [email protected]; >> [email protected] >> Subject: RE: Opsdir last call review of draft-ietf-lsr-multi-tlv-06 >> >> Giuseppe - >> >> Now that IESG appeal has been resolved, we are resuming work on this >> document. >> Thanx for your patience in waiting for a response to your comments. >> >> V7 has been published. >> Sections 3 and 4 have been rewritten and reordered to hopefully make a >> clearer presentation. >> >> [GF]: Good! >> >> Some responses to specific points inline. >> >> >>> -----Original Message----- >>> From: Giuseppe Fioccola via Datatracker <[email protected]> >>> Sent: Friday, November 15, 2024 3:30 AM >>> To: [email protected] >>> Cc: [email protected]; [email protected]; >>> [email protected] >>> Subject: Opsdir last call review of draft-ietf-lsr-multi-tlv-06 >>> >>> Reviewer: Giuseppe Fioccola >>> Review result: Not Ready >>> >>> This document is quite clear for its scope, but I have concerns >>> about the overall organization of the document and I think that its >>> structure can be improved. >>> >>> The mechanism of Multi-part TLVs in IS-IS is useful when the >>> remaining space in the TLV is insufficient to advertise all the >>> other sub-TLVs, considering that the contents of many critical TLVs >>> may exceed the currently supported limit of >>> 255 octets. >>> >>> I'm wondering whether you already considered the possibility for >>> this document to explicitly update the RFCs (e.g. RFC 5120, RFC >>> 5305...) where no extension mechanism has been previously specified. >> >> [LES:] Every codepoint which is impacted is explicitly listed in >> Section 9.2 where we specify an additional column to indicate MP-TLV >> applicability in the appropriate IANA registry. >> If you examine those registries, you will see they already contain a >> link to the RFC which defines the associated codepoint. >> I think this suffices as an explicit list of the documents which would >> be considered as updated - and is more accurate than any arbitrary >> listing would be. >> >> [GF]: Thank you for the explanation. I just meant the possibility to >> include the updated RFCs in the header of the document too. But I >> understand your choice. >> >>> >>> From an OPSDIR point of view, the document includes a section on >>> "Deployment Considerations" and it is good. In this section, I would >>> provide more operational guidelines to overcome interoperability >>> issues. >>> >> [LES:] Section 5 and 6, as well as Section 8 already provide such >> information. >> >> [GF]: Ok, maybe you can consider to add a pointer to the relevant >> sections so that the reader can easily find such information. > > [LES2:] I think that Section 5 is really talking about deployment > considerations. I would be fine with incorporating that text into Section 8. > Section 6 is describing the correct way for an implementation to process > MP-TLVs when received. This isn't a deployment consideration - it is > necessary for correct processing of the information received - so I think it > isn’t logically linked to Section 8 and should remain as is. > > If this makes sense to you, I will make the necessary changes. > > [GF]: I would incorporate some text into section 8, but I leave it to you. > >> >>> To improve the document structure, I have the following suggestions: >>> >>> - I think it would be better for a reader to have first the general >>> description of the procedures for advertising and receiving MP-TLVs >>> and then the examples of sections 4.1 and 4.2 which can be placed in >>> a separate section. >>> >> [LES:] The reordering/revision of Sections 3 and 4 is aimed at >> accomplishing this. >> >> [GF]: Thanks! >> >>> - Regarding section 5 on "Procedure for Receiving Multi-part TLVs" I >>> would also mention what happens if a node accidentally receives >>> MP-TLVs and does not support it. >>> >> [LES:] Section 4 discusses this - and Section 8.1 discusses an associated >> alarm. >> >> [GF]: Ok, I see. >> >>> - Regarding section 7.1 on "Recommended Controls and Alarms" I >>> suggest to provide further details about the possible controls and >>> alarms for the MP-TLVs with actual examples (e.g. NETCONF YANG, YANG >>> Push...). >>> >> [LES:] There is no plan to define a YANG model for MP-TLV because it >> isn’t a global feature - it is a per codepoint feature. >> As an offshoot of this work, several Protocol Implementaton >> Conformance Statement (PICS) YANG models have been initiated as we >> believe that is the appropriate context in which to provide management >> information. >> See https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-pics-yang/ >> and https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-pics-srmpls-yang/ . >> To fully cover all aspects of the protocol, many more such documents >> will be required. >> >> [GF]: Thank you for the references. >> >>> - I think that section 7.2 on "MP-TLV Capability Advertisement" is >>> relevant for the general description of the mechanism and therefore >>> must be moved earlier in this document, e.g. as a subsection of >>> section 4 on "Procedure for Advertising Multi-part TLVs". >>> >> [LES:] I do not agree. >> The new sub-TLV is an optional extension (though support for it is >> encouraged) and its value is only informational i.e., MP-TLV support >> can be present even in the absence of the advertisement of the new sub-TLV. >> I think its placement in the document is appropriate. >> >> [GF]: I suggested the change because, as a reader of v-06, this >> section clarified a question about the capability advertisement that >> comes to my mind earlier in the document. The organization of v-07 >> improved this aspect. But, in any case, I see the current section 8.2 >> on "MP-TLV Capability Advertisement" more as part of the TLV >> definition than a subsection under "Deployment Considerations". For >> example, it could also be a separate section before section 8. >> > [LES2:] It is currently in the Deployment Considerations Section because it > is an optional advertisement which is not used by the protocol itself. It is > provided only as an informational aid to operators. > But, I see your point. If you think it would be helpful to make this a > separate section (preceding current Section 8) I think that would be fine. > > [GF]: I think it would be good to make it a separate section even if it is an > optional feature. > > Les > >> Les >> >>> > > _______________________________________________ > 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]
