Hi Tony, > If we want to introduce MP-TLVs, that change would warrant the existence of > the flag. Multipart TLVs already exist today. As discussed here, after introducing a "software capability TLV", if a router doesn't advertise any of those new capabilities, we still don't know whether that router supports multipart TLVs or not. So the new capability seems to have limited value. > I dispute that a binary flag warrants the word 'complexity'. You might think of a single bit now. But people might want to add more. What TLVs on a router can and can not be received multipart? What about sub-TLVs? > 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. It seems these days we have more people in the LSR work-group that prefer to write drafts than that prefer to write code. I fear a large amount of drafts about router capabilities to advertise support for every bit, every TLV and every sub-TLV in LSPs. In the end, every feature, every detail or option in a feature, will get its own router capability. I'm happy nobody wants routers to react to advertised software capabilities. But if routers don't react to info in a LSP, I don't think that info belongs in the control-plane. It belongs in the management-plane. > We have been sending management information in the LSDB since > we introduced the hostname TLV. That's a different thing, imho. It's a single exception. It's very useful to identify LSPs and routers. I don't see other management information we should put in LSPs. Twenty-five years ago, you and me were the first people to implement support for wide metrics. I came up with a strategy to migrate a running network. I introduced the "metric-style [wide|narrow]" command. That was supposed to be a temporary thing. Just for use in the next 1-2 years, when every IS-IS network was migrating to wide metrics. When I came back to work, in 2015, I saw that the Nokia SR-OS routers still have narrow metrics as the default setting. I laughed. Now I am back at cisco, and I see that IOS-XR also has narrow metrics as the default. I cried. FYI, both OSes had their FCS many years after 1997. If I am not mistaken, JunOS has "metric-style both" as the default. So on all these 3 OSes, you need to explicitly configure "metric-style wide". Twenty five years after the migration ..... I fear that the same will happen with your router-capability. The new capability will have some value now. To help migrate to a network where all boxes support multipart TLVs. But 1-2 years from now, all (major) IS-IS implementations will support multipart TLVs for all TLVs. And then the new router-capability will have no use anymore. But routers all around the world will still advertise it. I predict that 25 years from now, 23 years after all IS-IS implementations started to support multi-part TLVs, routers will still advertise your capability. I don't like that. henk.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
