Ketan –
I have uploaded V18 of the draft which reverts the changes in Section 8.1.
I believe all open issues you have raised have now been addressed.
Please let me know if that is not correct.
Les
From: Ketan Talaulikar <[email protected]>
Sent: Friday, April 25, 2025 10:11 AM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: The IESG <[email protected]>; [email protected];
[email protected]; [email protected]; [email protected]
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-lsr-multi-tlv-14: (with
DISCUSS and COMMENT)
Hi Les,
Thanks to you and your co-authors for the patience and diligence as we discuss
through my comments/suggestions. I believe all of my concerns in DISCUSS are
addressed - as in either with updates to the document, or with responses (where
we ultimately go with the WG consensus).
However, there is one change in section 8.1 below where I have some concerns
about the proposed text - more details below.
I will update my ballot shortly after we close that one outstanding thing.
Please also check inline below with KT3 for responses on some of the points.
On Fri, Apr 25, 2025 at 8:26 AM Les Ginsberg (ginsberg)
<[email protected]<mailto:[email protected]>> wrote:
Ketan -
Thanx very much for your time and diligence in working to close on the
remaining issues.
I have posted V17 of the draft which I hope addresses all of the open DISCUSS
points.
Please see my responses inline below. "LES3"
> -----Original Message-----
> From: Ketan Talaulikar <[email protected]<mailto:[email protected]>>
> Sent: Tuesday, April 22, 2025 10:50 AM
> To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>
> Cc: The IESG <[email protected]<mailto:[email protected]>>;
> [email protected]<mailto:[email protected]>;
> lsr-
> [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>
> Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-lsr-multi-tlv-14: (with
> DISCUSS and COMMENT)
>
Hi Les,
Thanks for your quick response and also for your patience while I was away.
I've trimmed out the parts where we have reached an agreement.
Please check inline below with KT2 for further follow ups.
I'll update the ballot once we've reached a conclusion on the open points.
On Sat, Apr 12, 2025 at 3:00 AM Les Ginsberg (ginsberg)
<[email protected]<mailto:[email protected]>> wrote:
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks to the authors, first for taking up this work, and next for taking it
> through a "rigorous" WG process while focusing on technical aspects.
>
> However, there are still some aspects in the document that I would like to
> have
> a discussion on (inline using idnits output of v14):
>
> 152 This document specifies a means for extending TLVs where no
> extension
> 153 mechanism has been previously explicitly specified, and defines
> this
> 154 mechanism as the default extension mechanism for future TLVs. The
> 155 mechanism described in this document is applicable to top level
> TLVs
> 156 as well as any level of sub-TLVs which may appear within a top
> level
> 157 TLV.
>
> <discuss-1> Given that a TLV is bounded at 255 bytes, by definition its
> sub-TLVs (at first and subsequent levels) are bounded to an even smaller
> limit.
> This implies that if > 255 bytes need to be encoded in a 1st level sub-TLV,
> then we would need two parts of the parent TLV as well. While this is
> implicit, some text on this would be helpful - I would not be surprised if
> this gets missed by people working on future specifications. Taking it
> further,
> this aspect imposes some design restriction on the level of
> sub-TLV/sub-sub-TLV/... that can be designed for future extensions due to the
> reducing bounds as we go deeper. At some point, the overhead of the
> "process of breaking into parts" may start to bring in higher overheads than
> the actual information being conveyed. This brings in challenges in protocol
> encoding design (specifically with many layer of sub-TLVs). I would like to
> discuss why this document isn't providing such a guidance as well (or at least
> touching upon this aspect). Perhaps a recommendation would be to not go
> more
> than 2-3 level deep as there is a risk of hiting these limits?
>
[LES:] The scope of this document is quite intentionally limited to specifying
MP-TLV. It does not introduce any encoding changes or new limitations
to the protocol. Nesting level of sub-TLVs is a legitimate concern, but is
independent of MP-TLVs. Your comment about "overhead" is applicable to a
single TLV as well. I do not see that a discussion of this concern is
appropriate in this draft.
KT> The document does specify a mechanism on how TLV space is expanded and it
indicates the replication of the fixed and "keys" part at every
TLV/sub-TLV/sub-sub-TLV level (i.e., it takes away more space in doing so).
Therefore, as an extension, at least some text that touches upon its
implications for multiple nested TLV/sub-TLV usage is warranted in my view.
Such text will provide guidance to future developers working on ISIS extensions
and is something that can be quoted/pointed to. E.g., when some extension is
buried too deep in the TLV hierarchy, there may be a case to "pull it up" at
the top-level even if it might not be the best choice from a pure data model
perspective. Please consider this as an effort towards providing guidance to
new participants in a standards track ISIS document.
[LES2:] Hopefully I can say this without offending you…
IS-IS has always been frugal as regards the space used for encoding
information. This is because we have always been conscious both of the 255
octet TLV limit and the overall limit of LSP space.
You may recall examples of this in cases where some other protocol (e.g., BIER)
proposes an encoding for advertising information in the IGPs and uses the same
format for OSPF and IS-IS. We always insist this be revised for IS-IS.
Your major experience is with OSPF – and so you may think that the introduction
of MP-TLV would require extra diligence in this regard – but I am telling you
this is not the case.
As a WG member, I would not allow inefficient encoding to progress – completely
independent of any MP-TLV considerations. And I think you can examine the
output of IS-IS RFCs over that last 25 years as proof that the WG is already
diligent in this regard.
So your well intentioned concern is simply not appropriate.
KT2> Les, you are preaching to the choir :-) ... I am familiar with the
importance of efficient encoding in ISIS. I also agree that this consideration
applies even outside of MP TLV. I was looking for a reference to these
considerations for the benefit of new participants but I didn't find them -
this is "ISIS tribal knowledge" so I'll leave it to the WG wisdom. That said,
this isn't really a DISCUSS criteria anymore. We can consider this closed.
> 289 For example, suppose that a router receives an LSP with a
> Multi-Part
> 290 Extended IS Reachability TLV. The first part contains key
> 291 information K with sub-TLVs A, B, and C. The second part contains
> 292 key information K with sub-TLVs D, E, and F. The receiving router
> 293 must then process this as having key information K and sub-TLVs A,
> B,
> 294 C, D, E, F, or, because ordering is irrelevant, sub-TLVs D, E, F,
> A,
> 295 B, C, or any other permutation.
>
> <Discuss-2> What if there is a single instance sub-TLV within an MP-TLV? In
> this case, the ordering would be important if for some reason (or error) the
> sender were to send multiple copies of that single instance sub-TLV and the
> guidance is to 'use the first, ignore the rest'. Therefore, should the
> receiver
> not have to process based on the ordering in the LSP(s) and that the sender
> also is deliberate about the ordering of the parts in the LSP(s)?
>
> 310 Specifying how to handle such cases is the responsibility of the
> 311 document which defines the TLV. If such a document is not explicit
> 312 in how to handle such cases, it is RECOMMENDED that the first
> 313 occurrence in the lowest numbered LSP be used. In the case of
> IIHs,
> 314 it is RECOMMENDED that the first occurrence in the IIH be used.
>
[LES:] Order has never mattered in IS-IS. Whether an advertisement is present
in LSP #1 or LSP #200 has no impact on processing of that information.
Similarly, order of sub-TLVs within a TLV is of no significance.
The recommendation to use "the first occurrence in the lowest numbered LSP"
is addressing pathological/transient cases where information is duplicated.
It provides a deterministic resolution for such cases, but it does not
guarantee that the choice is "correct" i.e., that it is the latest information.
No rule will guarantee that in such cases.
KT> This isn't about correctness. It is about consistency across routers in the
network.
[LES2:] Well, you started this discuss asserting that:
“Therefore, should the receiver
not have to process based on the ordering in the LSP(s) and that the sender
also is deliberate about the ordering of the parts in the LSP(s)?...”
And I repeat that order does not matter.
Now you seem focused on trying to standardize behavior in the event of
duplicate/conflicting information.
Please be more precise in your comments.
As regards the use of RECOMMENDED in this paragraph, individual codepoints can
choose to specify a different deterministic method to handle
duplicate/conflicting information for that codepoint.
I am not suggesting that they should (quite the contrary) – but if they have
some reason to do so and they specify it clearly this is not an issue for the
protocol.
That is why we chose RECOMMEND here.
I stand by that choice.
KT2> We have a disconnect. Let me take a step back to clarify. When the text is
referring to the sub-TLVs A, B, C, D, E, F are they unique ones (i.e.,
different codepoints)? If so, I think the text is correct. However, I can read
the same text as just 6 different sub-TLVs where B and E may be of the same
type - and in that case, the rules of using the first instance in the lowest
LSP ID still applies for non-MP types (before concatenation happens). Can you
please clarify?
[LES3:] I have revised the text to indicate all of the codepoints (A,B,C...)
are unique.
KT3> Thank you for that clarification. This taken along with the text about the
default normative behavior for TLVs where MP-TLV applicability is "N" takes
care of my concerns.
> <Discuss-3> Why RECOMMENDED (as in SHOULD) and not a MUST to ensure
> we arrive
> at interoperable implementations down the line? Was there a proposal placed
> before the WG to make this a MUST and some objection received on it?
>
[LES:] We are not specifying normative behavior here - that is left to the
document which defines the codepoint. And there are existing examples of
different strategies
specified. This document is not the place for such normative statements.
KT> Well, the document is specifying normative behavior for those TLVs where
the respective spec is not already explicitly on this aspect. I am not getting
into the past. Neither should it be the responsibility of this document to try
to grandfather all the myriad ways in which things are being handled by
old/current implementations. The point is to move implementations forward
towards interoperability, and hence the MUST instead of SHOULD will help
achieve that goal in this regard. To me, this is in the same spirit as RFC8918.
[LES2:] RFC 8918 addressed a behavior that was clearly broken. That is not the
case here. Please do not use this analogy.
I believe my response above applies.
KT2> It is important that we have a default normative behavior for such cases
that is solid. I would encourage you to consider using a MUST in this case.
Also, refer to this:
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
[LES3:] I have removed "RECOMMENDED" and stated the behavior in a normative
manner consistent with the IESG link you provided.
Thanx.
KT3> Thank you. I believe this will help us achieve consistency in the handling
of such (error or transient) conditions.
> 399 8. Deployment Considerations
>
> <Discuss-4> I would like to discuss why this document is not recommending
> that
> implementations and deployments move to RFC7356 as a long term approach
> to
> scaling IS-IS to carry more information. RFC7356 is referenced in the
> introduction, but some (short) additional text with references to its specific
> sections may be a helpful guide. I see that the authors (and some other WG
> members) had pointed to this work as "the long term solution", but the
> document has not captured that aspect.
>
[LES:] As an author of RFC 7356 I appreciate your interest. 😊
But this document is dealing with the current version of the protocol with its
current limitations. It is not a position paper on what the future of the
protocol should be.
KT> I disagree with your positioning of this document. There were more than one
proposal in front of the WG, and this particular one was picked for the 8-bit
TLV space encoding due to good reasons. It comes with its various challenges -
space, interoperability, etc. - so it is not perfect but pragmatic. At the same
time, during the WG discussion there were times when the topic of a long term
solution has come up (a few of the threads below) that concluded with pointing
to RFC7356 as a "clean" solution (albeit introducing in existing deployments is
challenging). So, I am wondering why the WG (not just the authors) would not
want to at least mention that RFC7356 provides the long term solution? I will
leave the recommendation part to the WG (though I personally strongly favor it).
https://mailarchive.ietf.org/arch/msg/lsr/rCHObOHT18sg61Dn60SJlvUWodU/
https://mailarchive.ietf.org/arch/msg/lsr/987n5mHQptaPpmc0EjnJ-p9yZGM/
[LES2:] Thanx for the email pointers – but they only reinforce my point.
Those emails were an attempt to separate the discussion of what we need to do
to address the 255 octet limit using the current version of the protocol from a
discussion of how a new /not backwards compatible version of the protocol would
address the issue.
My argument was – and continues to be – that is a separate topic – does not
belong in the MP-TLV specification.
RFC 7356 is mentioned in the draft – so that request from you is already met.
Further discussion of how RFC 7356 (or some other solution) would address the
issues is out of scope.
The draft is focused on what needs to be done with the current version of the
protocol.
KT2> Yes, RFC 7356 is indeed referenced and it also talks about 16-bit length
values. Like I said, I will leave this to the authors if you would like to add
something further. In any case, please consider this as a general comment and
not a DISCUSS.
[ LES3:] I added some text to clarify that RFC 7356 is not backwards compatible
and therefore there is still a need to address the problem using the current
8-bit TLVs.
KT3> This is much better text. Thanks.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 147 The mechanism described in this document has not been documented
> for
> 148 all TLVs previously, so there is risk that interoperability
> problems
> 149 could occur. This document provides the necessary protocol
> 150 definition.
>
> <major> The above text is incomplete. I would suggest that this paragraph
> simply puts forward references to document sections that are dealing with
> interoperability challenges and backwards compatibility aspects.
>
[LES:] This text is in the "Introduction".
It therefore is expected that the text here is meant to introduce what follows.
The substance of the draft is - and is expected to be - in the subsequent
sections.
I do not understand your objection.
KT> A text suggestion to clarify my point:
The mechanism described in this document has not been documented for all TLVs
previously. The associated interoperability challenges are described in
Sections 7 and 8.
[LES2:] I have added some text – not quite as you suggested – but hopefully
meets your goal.
KT2> My concern was with the text that says "so there is risk that
interoperability problems could occur" - can this be taken off as well? The
further sections in the document do cover the challenges along with the
solution.
[LES3:] I removed the text as you suggested.
> 265 5. Procedure for Receiving Multi-Part TLVs
>
> 267 A router that receives a MP-TLV MUST accept all of the information
> in
> 268 all of the parts. The order of arrival and placement of the TLV
> 269 parts in LSP fragments is irrelevant. Multiple TLV parts MAY occur
> 270 in a single LSP or parts MAY occur in different LSPs.
>
> 272 The placement of the TLV parts in an IIH is irrelevant.
>
> <major> Does "placement" here also cover "ordering"? Is the intention
> here that it is not required that all parts be encoded consequtively in an
> LSP (or across LSP fragments), and that no specific ordering is expected?
> Please
> also see my discussion point 2.
>
[LES:] Yes - it covers "ordering".
Rereading the text, that seems very clear to me.
I do not understand your confusion.
KT> My point is that ordering is relevant when dealing with non-MP sub-TLVs
spread across multiple parts of a MP-TLV. So, the receiver cannot just ignore
the ordering. If it does so, it will not be able to pick the "right" (e.g., the
first instance in the lowest number LSP) non-MP sub-TLV instance for
consistency across routers.
[LES2:] I still cannot understand your point. The statement as you write it is
incorrect. Order of sub-TLVs at a given level of hierarchy does not matter.
Perhaps a specific example of what is troubling you would help??
KT2> Please see my latest response on Discuss-2 above. That clarification
should cover this comment as well.
[ LES3:] Hopefully the clarification about "unique" codepoints also addresses
this issue.
KT3> Yes, it does.
> 351 For example, if there are mutiple TLVs associated with the
> 352 advertisement of a neighbor and some routers do not use all of the
> 353 link attributes advertised, then constrained path calculations
> based
> 354 on those attributes are likely to produce inconsistent results and
> 355 produce forwarding loops or dropped traffic.
>
> <minor> More specifically, this is for a distributed constraints path
> calculation (as in FlexAlgo)? For P2P TE computations, this may not present a
> loop but yes results might be not what is desired.
>
[LES:] Sure. But this is only an example of problems which may occur,
not a comprehensive list of all possible problems - which could fill many pages.
KT> It is important to specify the scope as ISIS calculations. That would help
address this comment. The current text refers to "constrained path
calculations" which could be construed as covering something that a TE
controller does as well.
[LES2:] This seems to me to be another aspect of your belief that controllers
don’t have to understand MP-TLVs – which I think is misguided.
Controllers have to correctly parse all of the information advertised by IS-IS.
They may choose, based on local policy, to ignore some attributes – but if they
cannot correctly parse the information advertised then they are applying that
policy on incomplete or incorrect information.
KT2> There is perhaps another disconnect here. I am not making any statements
about controllers not having to parse/support all TLVs (including MP-TLVs). My
point was about distributed constrained path calculations vs a non-distributed
(could be controller or local TE compute on a router) constrained path
calculation. Here is a suggestion:
CURRENT
For example, if there are multiple TLVs associated with the advertisement of a
neighbor and some routers do not use all of the link attributes advertised,
then constrained path calculations based on those attributes are likely to
produce inconsistent results and produce forwarding loops or dropped traffic.
SUGGEST
For example, if there are multiple TLVs associated with the advertisement of a
neighbor and some routers do not use all of the link attributes advertised,
then distributed constrained path calculations by IS-IS implementations based
on those attributes are likely to produce inconsistent results and produce
forwarding loops or dropped traffic.
This is just a suggestion. I hope my point is clarified and will leave it to
the authors to wordsmith as appropriate.
[LES3:] I have reworded the text in a way that I think applies to any
implementation (router or controler).
KT3> This works.
> 365 Routers which support MP-TLV for codepoints for which existing
> 366 specifications do not explicitly define such support, but for which
> 367 MP-TLV is applicable, SHOULD include this sub-TLV in a Router
> 368 Capability TLV.
>
> <major> Why is this not a MUST even if it is for informational purposes?
> Likely someone is relying on this information to be accurate. Please also see
> the next comment.
>
[LES:] This has been answered previously.
Here is my earlier reply to Eric:
<snip>
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.
<end snip>
KT> I am with Eric on this. The purpose of this document should not be to
grandfather existing implementation choices that were made in the absence of
this spec. If some implementation is claiming compliance to this spec, then I
don't see why it cannot be mandated to advertise the capability as well. There
is no harm in adding text that there MAY be implementations which support
MP-TLV before this specification but do not advertise the capability. On the
second point, we should not preclude how this information is used by the
operator (or other systems) - the goal of ISIS
[LES2:] There is a fundamental disagreement here.
The advertisement says “This implementation might have MP-TLV support for a
codepoint you are interested in.”
As such, it is merely a hint to the operator.
Making this mandatory would mean that an implementation that actually has
MP-TLV support for a given codepoint would be considered unusable/non-compliant
simply because it did not advertise the sub-TLV which says “I have MP-TLV for
some codepoint.”
I do not agree to this.
KT2> This is a comment so we go with the WG consensus. However, I am leaning on
the IESG statement on BCP14 keywords usage here. Perhaps adding some text that
suggests that this is a recommendation since there are implementations that
already do support the MP TLV processing but do not advertise this capability -
therefore, it would be problematic to assume non support of MP Capability
implies non support of MP TLV processing? I leave this to the authors.
[LES3:] I left this text unchanged.
KT3> Sure. We will go with the WG consensus on this one.
> 420 8.1. Recommended Controls and Alarms
>
> 422 It is RECOMMENDED that implementations which support the sending
> of
>
> <major> Why not MUST instead of RECOMMENDED (i.e., SHOULD) for the
> global
> control knob? This would be the bare minimum control that is required for the
> operator?
>
[LES:] Once again, you are trying to reopen something which was debated
at considerable length previously. The authors feel strongly that it is not
within the purview of an RFC to mandate how implementations implement
configuration. It is also unenforceable. The choice to use RECOMMENDED was
intentionally made and we do not want to revisit this choice.
KT> This is only about a global control for MP-TLV (not the TLV specific one)
that we are talking about. You are of course correct that IETF cannot enforce
the choices that implementations make. However, there is always a balance to
strike. In this case, in my view, the global control knob is something that can
be made a MUST. Again, there is no requirement on this document having to
grandfather everything that implementations are doing currently, but to set an
appropriate future direction.
[LES2:] We are not in agreement. Don’t have much new to say.
KT2> Similar response as before. Please consider adding some reason or if not
changing to MUST. To be clear, this is a non-blocking comment.
[LES3:] I revised the wording (and the section title) - removing "RECOMMENDED"
. I think the language is now consistent with the updated IESG guidance you
highlighted.
KT3> I have some concerns with this change. The term "useful" may be seen as
dilution from the WG consensus that was "RECOMMENDED". I think it is best to
revert the text in the body of section 8.1 also to what came from the WG (same
as what we decided for the previous comment) rather than trying to wordsmith it
based on the IESG guidance. As a reminder, this was a non-blocking comment in
the first place.
Thanks,
Ketan
Thanx again for the thorough review.
Les
Thanks,
Ketan
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
