Hi Henk, > > If we want to introduce MP-TLVs, that change would warrant the existence of > > the flag. > > Multipart TLVs already exist today.
Some exist today. There are many TLVs where they have never been specified. > 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. In particular, the current proposal on the table is to have the capability apply to the TLVs where multi-part has not been previously defined. > > 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 proposing that level of specificity. It’s all or nothing. > It seems these days we have more people in the LSR work-group that prefer to > write drafts > than that prefer to write code. Ok, I’m offended. > 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. That’s correct. It will. That’s going to happen independently of this draft. > 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. Thank you, but we still (40 years in?) do not have an effective management plane and continue to stuff things into the LSDB that belong in the management plane. > 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. There’s tons of stuff. The entire definition of a Flex Algo topology constraint should be in the management plane. Almost everything that is in the router capability TLV should be in the management plane. We stepped down this slippery slope a long, long, time ago. > 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. And it’s still there. > 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 ….. Excellent point: things don’t progress. So if you want to move forward, you need to be very careful. That’s all that we’re suggesting. > 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. I know that it will take more than 2 years. Deployment alone is another 2 years. And I’m sorry that you don’t like it. There are lots of things out there that could be better. That’s not an excuse for not trying to do a good job now. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
