Hi Les, Ok that helps to clarify the current use case (and name confusion) of RFC7981. I did look at some of the drafts defined in the registry of this Capability TLV bringing in sub-TLVs and while clearly lots of them are used in a run time I did see a few which could be also stated to use mgmt plane instead :).
But back to this topic - do you see that support for Multi-TLV processing could not be disabled by a node ? If so, would this information not be useful in run time ? Thx, R. On Thu, Sep 22, 2022 at 10:30 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > The intent of my response was to get agreement on separating the > discussion of advertising features supported by an implementation from the > content of the multi-tlv draft. > > > > Router capabilities TLV (RFC 4971/7981) is something quite different. In > every case, information advertised in the Router Capability TLV is used at > run time by the protocol. For example, advertising SR Capability is not > there so that the operator can know which implementations include SR > support. It is there so that at run time other routers in the network will > know whether a given router has SR enabled – which influences how (for > example) label stacks are built when forwarding via that node. > > > > What is being proposed here is for the protocol to advertise what features > it supports. This is not information which will be used by the protocol at > run time – it is there solely to inform the network operator of what > support is included in a given implementation. > > This is not what Router Capability TLV does (please do not argue with me > about the TLV name – it was chosen long ago…) and if the WG were to decide > that management information should be sent by the protocol I would > certainly argue that Router Capability TLV is not the correct TLV to be > used. > > > > If you are interested in discussing having the protocol include management > information in the LSPDB – please discuss this in a separate thread – and > note that (with the notable exception of “hostname”) this isn’t done today > – so it is something very new. > > > > Les > > > > > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Thursday, September 22, 2022 12:38 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Tony Li <tony...@tony.li>; Henk Smit <henk.i...@xs4all.nl>; lsr < > lsr@ietf.org> > *Subject:* Re: [Lsr] New Version Notification for > draft-pkaneria-lsr-multi-tlv-01.txt > > > > 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
