Hi Tony, > Some exist today. There are many TLVs where they have never been specified.
My point was: multipart TLVs exist today, before the introduction of the capability advertisement. So when you look at a LSPDB, you still don't know for sure which routers support multipart TLVs. Some might, but don't advertise it. Because their software was written before the new capability existed. >> In the end, every detail, will get its own router capability. > That's correct. It will. That's going to happen independently of this draft. I hope not. And I will oppose those attempts too. > we still do not have an effective management plane and > continue to stuff things into the LSDB that belong in the management plane. Yes. But that does not make it an excuse to put just anything in the LSPDB. I've seen you in this work-group as someone who tried to keep things out of IS-IS that don't belong there. I am surprised to see you want this capability in. > The entire definition of a Flex Algo topology constraint should be > in the management plane. Sure. But at least the routers do make route-calculation decisions based on that information. > That's not an excuse for not trying to do a good job now. That is the whole question. This capability is adding 2 more octets to LSPs. Is that worth it? What if indeed a few dozen drafts will follow to advertise more of these capabilities? Should we define a new top-level TLV for "feature/software support capability"? Not whether something is configured or not (as does the router-capability TLV), but whether a router's software has that capability to begin with. Or should we define a new variable-length bitmask sub-TLV for the existing router capability TLV. Where every bit indicates another piece of software the router supports? Regardless whether we do that or not, this discussion maybe should be done outside the multipart TLV discussion. Maybe another draft should be written about these software-capabilities in general? henk. > Op 11-09-2022 21:32 schreef Tony Li <tony...@tony.li>: > > > 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 _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
