NOTE: I am speaking here as a WG member – not as a co-author of the draft.
I am very much in agreement with Gunter’s POV – and I would caution that even
those who may find the idea of advertising “Multi-part TLV Capability’
appealing should temper their expectations.
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).
The only safe use of such an advertisement would be as informational.
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). 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.
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]
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.
I do not see value in introducing such an advertisement.
Les
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Tony Li
Sent: Wednesday, August 24, 2022 8:26 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_ve...@nokia.com>
Cc: lsr <lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt
Hi Gunter,
I am having troubles understanding the value of ‘The Multi-part TLV Capability’
flag.
What would break if ‘Multi-part TLV Capability’ flag would not exist?
A system that supported MP-TLVs would not be able to determine that there were
other systems in the area that did not support MP-TLVs. The system might then
advertise MP-TLVs and they would be misinterpreted or cause system crashes in
the systems that did not support them.
IS-IS has been working well for many years. Why would that suddenly change and
mandate existence and complexity of a ‘Multi-part TLV Capability’ flag?
If we want to introduce MP-TLVs, that change would warrant the existence of the
flag. I dispute that a binary flag warrants the word ‘complexity’.
Note: thoughts about the flag: What if a system by accident sends flip-flopping
(set/unset/set/unset/etc) of this flag?
Then other systems might misinterpret the results and generate inconsistent
TLVs. That would be bad.
What if an advertising system support multi-tlv for TLV ‘A’ but not for TLV ‘B’?
We are not allowing that level of granularity. A system that is going to
support MP-TLVs should take care to operate correctly for ALL TLVs before
advertising that it supports them.
Tony
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
