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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Robert –

If you are suggesting that – based on the current state of advertised support for a given feature (such as Multi-tlv) by all routers in the network - that routers should dynamically modify what they send, this is VERY DANGEROUS – and should not be done.
It can lead to flooding storms as all routers attempt to enable/disable the sending of information which was previously suppressed/unsuppressed.

Let’s not go there please.

    Les

From: Robert Raszuk <[e-mail]>
Sent: Thursday, September 22, 2022 1:37 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: Tony Li <[e-mail]>; Henk Smit <[e-mail]>; lsr <[e-mail]>
Subject: 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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, September 22, 2022 12:38 PM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Henk Smit <[e-mail]<mailto:[e-mail]>>; lsr <[e-mail]<mailto:[e-mail]>>
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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Tony Li
> Sent: Tuesday, September 13, 2022 1:44 PM
> To: Henk Smit <[e-mail]<mailto:[e-mail]>>
> Cc: lsr <[e-mail]<mailto:[e-mail]>>
> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lsr