> 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. 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. > 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. > 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. > 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. > 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
