| Hi, Giuseppe:
You are the Ops area expert.
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. On Feb 12, 2025, at 17:06, Giuseppe Fioccola <giuseppe.fioccola=40huawei.com@xxxxxxxxxxxxxx> wrote:
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 PMTo: Giuseppe Fioccola <giuseppe.fioccola@xxxxxxxxxx>; ops-dir@xxxxxxxxCc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxxSubject: RE: Opsdir last call review of draft-ietf-lsr-multi-tlv-06Giuseppe -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
_______________________________________________Lsr mailing list -- lsr@xxxxxxxxTo unsubscribe send an email to lsr-leave@xxxxxxxx
|
