Hi Henk, > 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.
True, but irrelevant. The point is that if a router does advertise the capability, then you can reasonably infer that it is ready to receive multi-part TLVs. > I hope not. And I will oppose those attempts too. Example: MPLS MNA is coming. It’s a bundle of independent network actions, plus user defined actions. The MPLS WG is going to need a capability for each action. I expect that they will come here (LSR) and ask. >> 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. That’s what we’ve been doing for decades. Yes, I’m advocate for putting things elsewhere, but that proposal has met with crickets. You don’t get it both ways: no capabilities in the protocol and nowhere else does not work. If the IGP is not a dump truck, then what else is? > 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. Because the thought of trying to deploy this capability at scale without this attribute seems impossible. Consider the case of Tier 1 providers who have large IS-IS deployments. Are you really going to evaluate 2000+ nodes without some kind of help? >> 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. And the routers will do computations based on the multi-part TLVs. One level of indirection for a capability does not seem extreme. >> 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? Yes. > What if indeed a few dozen drafts will follow to advertise > more of these capabilities? They are coming regardless. > Should we define a new top-level TLV for "feature/software support > capability"? No, since duplicating an existing TLV is wasteful of TLV code points. The current capability TLV is both necessary and sufficient. > 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? That’s coming. See above. > 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? Please feel free. My proposal was shot down. T _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
