Hi Les, > 2) Applicability of advertising what features an implementation supports extends > to much more than just multi-tlv support.
Indeed. Spot on ! And wasn't it the reason for rfc4971 then updated by rfc7981 ? I think having such capabilities flooded via area or entire domain is a very useful thing. It is much better to crash local node then randomly see crashes here and there when it comes to handling new feature. Is the resistance here coming from the fact that multi-part TLVs are used today without such capability and introducing it now would cause a mess ? If so maybe rewording first sentence from section 5 rather then removing section 4 is better solution. Mgmt plane exists here and there. I am yet to see parity in how routers expose information from ISIS and OSPF. So if someone is seriously thinking of self driving networks we will see much more management stuff being sent inline other then expecting that networks will be driven by magic oracles. That experiment of SDN is not going that well I am afraid. Best, R. On Thu, Sep 22, 2022 at 6:40 PM Les Ginsberg (ginsberg) <ginsberg= 40cisco....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
