Tony - For me, your discussion with Henk highlights two points:
1)There are different POVs on whether advertising management information (like multi-tlv support) in the LSPDB is a good idea 2)Applicability of advertising what features an implementation supports extends to much more than just multi-tlv support. Therefore, introduction of such advertisements should be removed from the multi-tlv draft. If you and/or others want to pursue this idea, then a new draft focused on this new use of the protocol should be written. In this way the WG will have the opportunity to discuss the merits of such a significant protocol extension independently - which is appropriate. And the work on how to support multi-tlv - which I think is both useful and non-controversial - can proceed. I hope this is something on which we can easily agree - even if we do not agree on whether feature support should/should not be advertised in the LSPDB. A few more comments inline. > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Tony Li > Sent: Tuesday, September 13, 2022 1:44 PM > To: Henk Smit <henk.i...@xs4all.nl> > Cc: lsr <lsr@ietf.org> > Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv- > 01.txt > > > Hi Henk, > > >> 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? > > > I did. You don’t remember it. It was that memorable. [LES:] Sorry, I am not aware that you (or anyone else) has written a draft proposing advertisement of feature support in the LSPDB. Could you provide a reference? > > > >> 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? > > > There is no management plane. We had the chance at one, but we had the > great schism between OpenConfig and the IETF. So now we have nothing > that we can rely on. [LES:] I sympathize with your POV here. From an industry standpoint the schism is most unfortunate. But making the protocol itself responsible for sending management info is not a solution. Les > > > > How did those providers make changes to their > configs/features/architecture before? > > I would expect them to use the same tools. > > > They have configuration databases, but they do NOT have good tools that tell > them about router capabilities. They MAY be able to do something ad hoc > based on software release numbers, but this is far from a good solution. > > > >> 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. > > > I am happy to go with one bit. However, there is no place to encode that > single bit today. > > > >>> 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). > > > This was outside of IS-IS entirely. Several people disliked it so much that > they > wanted it thrown out of the WG. > > T > > _______________________________________________ > 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
