Hi Tony,
> 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. I'm not sure I know what you are talking about. Did you write a draft? > 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? With the help of the management-plane? How did those providers make changes to their configs/features/architecture before? I would expect them to use the same tools. > And the routers will do computations based on the multi-part TLVs. > One level of indirection for a capability does not seem extreme. Not extreme, indeed. But again, I rather not see 20 different minor or irrelevant things in the router-capability TLV. Certainly not at 2 octets per item. 1 Bit would already be (16 times) better. > > 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. Are you talking about a very recent proposal? Linked to the multipart-TLV draft? Or something older? I vaguely remember some idea about "generic transport" in IS-IS (or rather: outside the regular IS-IS instance). henk. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
