Hi Les,
Please see inline [GF].
Regards,
Giuseppe
-----Original Message-----
From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>
Sent: Tuesday, February 11, 2025 6:02 PM
To: Giuseppe Fioccola <giuseppe.fioccola@xxxxxxxxxx>; ops-dir@xxxxxxxx
Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
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
> <giuseppe.fioccola=40huawei.com@xxxxxxxxxxxxxx>
> Sent: Tuesday, February 11, 2025 12:34 AM
> To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; ops-dir@xxxxxxxx
> Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx;
> lsr@xxxxxxxx
> 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) <ginsberg@xxxxxxxxx>
> Sent: Monday, February 10, 2025 6:39 AM
> To: Giuseppe Fioccola <giuseppe.fioccola@xxxxxxxxxx>; ops-dir@xxxxxxxx
> Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx;
> lsr@xxxxxxxx
> 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 <noreply@xxxxxxxx>
> > Sent: Friday, November 15, 2024 3:30 AM
> > To: ops-dir@xxxxxxxx
> > Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx;
> > lsr@xxxxxxxx
> > 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
>
> >
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
