Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

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) <ginsberg@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 <robert@raszuk.net>
> *Sent:* Thursday, September 22, 2022 12:38 PM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> *Cc:* Tony Li <tony.li@tony.li>; Henk Smit <henk.ietf@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.com@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-bounces@ietf.org> On Behalf Of Tony Li
> > Sent: Tuesday, September 13, 2022 1:44 PM
> > To: Henk Smit <henk.ietf@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
>
>