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