Tony –
I am only expressing my POV on the proposed capability advertisement– which I
have shared with you and other authors privately. I was not discussing what
is/is not in the draft.
A few responses inline to correct misinterpretations on your part.
From: Tony Li <tony1ath...@gmail.com> On Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 1:34 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_ve...@nokia.com>;
lsr <lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
MP-TLVs are sent by routers not simply because they have the ability to do so,
but because the configuration requires them to send more information about an
object than will fit in a single TLV. This means that any attempt to suppress
generation of a MP-TLV based on the current capabilities (advertised or not) of
the routers in the network will not result in a working network. Some
information required by the configuration would be missing – behavior of the
network in such a condition is unpredictable. In addition, suppression of
MP-TLVs triggered by the introduction of a router which does not have support
could result in flooding storms when the state of the network transitions from
“all nodes support” to “some nodes support” (or vice versa).
This is simply dishonest.
[LES:] There is nothing “dishonest” here. It is an accurate description of the
consequences if an implementation attempted to use the capability advertisement
to alter what it sends.
I was not commenting on language in the draft – please confine yourself to what
I said – not what is top of mind for you.
But, since you have brought the draft discussion into the thread, I think it is
accurate to state that the authors of the draft (including you and I) have
privately agreed that no such usage would be made of the capability
advertisement.
My comment here is not about the language in the
yet-to-be-published-new-version-of-the-draft – it was simply to share with
folks reading this email thread that IMO it is not safe to make such a usage.
There has never been any text that even remotely suggested that nodes should
withdraw MP-TLVs if capabilities were not seen. Even if an implementation
gated their advertisement of MP-TLVs based on the capability, it would hardly
be a “flooding storm”. It is a single update from all relevant nodes. One
copy of the full LSDB. If the network can’t support that, then a partition is
also going to collapse it.
The only safe use of such an advertisement would be as informational.
Which is exactly the text that we have agreed to, yet, you are the only author
blocking us from publishing it.
[LES:] My discussion point with you and the other authors is on whether the
proposed capability advertisement should be part of the MP-TLV draft or another
draft that is focused solely on the introduction of such capability
advertisements. I prefer the latter because the introduction of such an
advertisement is unprecedented (and yes – this is easily proven) and as such
deserves to be reviewed by the WG on its own merit – not snuck in as a small
paragraph in the midst of a draft concerned with something else.
Advertisement of “features supported” is unprecedented in IS-IS (existing
advertisements in Router Capability TLV are not advertising feature support –
they are advertising feature specific information used by other routers or
other entities (e.g., controllers ) in performing routing calculations).
This is irrelevant. We tweak semantics all of the time. There is nothing in
the definition of the router capability TLV that prevents what we are
proposing. You are the only one who objects.
[LES:] This isn’t “semantics”. It is a completely new usage.
It introduces the sending of management information in real time protocol
updates – something which is more properly provided via management
applications, on box show commands, and/or vendor documentation.
We have been sending management information in the LSDB since we introduced the
hostname TLV.
[LES:] Fair enough as regards hostname – but that has direct usage in show
commands on all routers as an aid to box identification. Quite different than
advertising a list of “features supported”.
There is also the reality that MP-TLVs are already being sent by multiple
implementations and that existing protocol specifications have explicitly
specified the use of MP-TLVs as valid in a number of existing cases including:
242 Router Capability TLV [RFC7981)
138 GMPLS-SRLG [RFC5307]
139 IPv6 SRLG [RFC6119]
238 Application-Specific SRLG [RFC8919]
Also sub-TLV 16 Application-Specific Link Attributes [RFC8919]
This is also incorrect. The new text of the document specifically excludes all
of these cases from MP-TLV.
[LES:] Again – you misinterpret my post. I am not claiming the draft discusses
these. I am simply discussing the merits (or lack thereof) of introducing the
proposed capability advertisement.
You are the one who has introduced the draft context to this thread.
Les
Therefore, the absence of an MP-TLV supported advertisement cannot be reliably
used to indicate lack of support – it could just mean that the feature support
advertisement itself is not supported.
The absence of the MP-TLV support advertisement indicates that the node does
not declare support for all MP-TLVs. That is both necessary and sufficient.
Tony
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
