>> > [LES:] Consider the following simple example.
>> >
>> > Node A needs to send 10 sub-TLVs about a particular object –
>> > requiring more than 255 bytes to be sent.
>> >
>> > Some nodes in the network do not support reception of more than 255
>> > bytes/object. Consider two such nodes.
>> >
>> > Node B, based on the local configuration, needs to be able to receive
>> > sub-TLVs 1,3,5,7,9 from A.
>> >
>> > Node C, based on local configuration, needs to be able to receive
>> > sub-TLVs 2,4,6,8,10 from A.
>> >
>> >
>> >
>> > There is no way that A can advertise all 10 sub-TLVs in a way which
>> > allows both B and C to correctly process the sub-TLVs they require.
>> >
-----Original Message-----
From: Christian Hopps <[email protected]>
Sent: Tuesday, March 28, 2023 9:52 AM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: Christian Hopps <[email protected]>; Huaimo Chen
<[email protected]>; [email protected];
[email protected]
Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
"Les Ginsberg (ginsberg)" <[email protected]> writes:
> Chris -
>
> Please see inline - I'll try to conform to your request about ">>>" quoting -
> but given that this style does not identify who made the comment, I have
found
> in the past that this style becomes very hard to follow after a couple of
> replies.
> Though perhaps that could be said of any style. 😊
Well in the ">>>" style my text that you were quoting would have been
"> like this"
and yours would not have anything preceding it.. like mine is here.
anyway, it's a losing battle against html I typically just load these email into
chrome when I need to read them..
>> -----Original Message-----
>> From: Christian Hopps <[email protected]>
>> Sent: Tuesday, March 28, 2023 7:27 AM
>> To: Les Ginsberg (ginsberg) <[email protected]>
>> Cc: Huaimo Chen <[email protected]>; draft-chen-lsr-isis-big-
>> [email protected]; [email protected]
>> Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
>>
>>
>> Hi,
>>
>> So I agree that using this new container TLV along with old TLVs doesn't
help.
>>
>
>>>[LES:] Good - we agree.
>
>> However, it is worth nothing that if *only* the container TLV was used
(i.e.,
>> once a TLV became too large it would be removed and placed inside
>> container TLVs) then it would actually represent a safer way to deploy this
>> "multiple tlv" functionality.
>>
>> If the container only was used, then only routers that understood would
be
>> able to use *any* of the TLV data. This would actually solve the problem
of
>> "newly inserted legacy router brings everything back down" that using a
>> required capability bit being set on all routers has.
>>
>>>[LES:] I don't agree - and here is why. Let's use the example of Neighbor
TLVs.
>>>With what you propose, when a router starts using the container TLV,
those routers who don’t support/understand it would simply not be aware
of the advertisement at all.
>>>This would result in inconsistent routing calculations on different routers
leading to loops/blackholes.
>>>Hardly a benign impact.
You're right, not sure why I thought new routers would know that old routers
weren't acting on the container TLV.
However, that is the missing piece, so it works if we also add a capability bit.
If we have the capability bit you now know which routers are processing the
container TLV and which aren't. That should be enough info to route
correctly.
>>>There is no free lunch here. No matter what encoding scheme you come
up with, unless all routers in the network understand it, things are going to
break.
>
Using a container TLV *and* a capability bit is not a free lunch, but it should
work to allow incremental deployment safely. If that's something we want as
a WG.
Thanks,
Chris.
[as wg-member]
>> This later issue with the capability bit is why no-one wanted to use a it,
and
>> why we currently have this very sub-optimal "solution" of "just do it and
>> hope it works".
>
>>>[LES:] Folks (like me) who implemented MP for TLVs like Neighbor/Prefix
were
>>> following established practice for the protocol i.e., there are multiple
>>> cases where this behavior is explicitly specified (please see MP draft for
a
>>> list)
>>>So it made sense to use the same mechanism for other TLVs.
>>>We are not naïve - we understood very well that if not all routers in the
network supported at least reception of MP TLVs that there would be
deployment issues.
>>>That is why I am working with enthusiasm on the MP draft.
>
> Les
>
>>
>> Thanks,
>> Chris.
>> [as wg-member]
>>
>>
>> P.S. the quoting style used in this thread is fabulously hard to
comprehend in
>> a text based email client.. What's wrong with good old ">>>" quoting style
>> anyway?
>>
>>
>> "Les Ginsberg (ginsberg)" <[email protected]>
writes:
>>
>> > Huaimo –
>> >
>> >
>> >
>> > Please see inline.
>> >
>> >
>> >
>> > From: Huaimo Chen <[email protected]>
>> > Sent: Sunday, March 26, 2023 3:41 AM
>> > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected];
>> > [email protected]
>> > Subject: Re: Comments on draft-chen-lsr-isis-big-tlv-00
>> >
>> >
>> >
>> > Hi Les,
>> >
>> >
>> >
>> > Thanks much for your comments.
>> >
>> > My responses are inline below with HC.
>> >
>> >
>> >
>> > Best Regards,
>> >
>> > Huaimo
>> >
>> >
>> >
>> > From: Les Ginsberg (ginsberg) <[email protected]>
>> > Sent: Thursday, March 23, 2023 3:35 AM
>> > To: [email protected] <[email protected]>;
>> > [email protected] <
>> > [email protected]>
>> > Subject: Comments on draft-chen-lsr-isis-big-tlv-00
>> >
>> >
>> >
>> > Folks -
>> >
>> >
>> >
>> > This draft proposes a new way to handle advertisement of more than
>> > 255 bytes of information about a given object.
>> >
>> > It defines a new "container TLV" to carry additional information
>> > about an object beyond the (up to) 255 bytes of information
>> > advertised in an existing TLV.
>> >
>> >
>> >
>> > The draft is defining a solution to a problem which has already been
>> > addressed without requiring any protocol extensions.
>> >
>> > [HC]: It seems that a protocol includes a set of procedures. Would
>> > you mind telling me which existing protocols can be used to resolve
>> > the problem without requiring any protocol extensions?
>> >
>> >
>> >
>> > [LES:] Please read draft-pkaneria-lsr-multi-tlv-02 carefully.
>> >
>> > Section 1 documents that there are existing RFCs which explicitly
>> > state that multiple TLVs for the same object are allowed to be sent.
>> >
>> > What the draft goes on to discuss is the use of the same mechanism
>> > (sending multiple TLVs for the same object) in cases where existing
>> > RFCs have not explicitly stated this behavior.
>> >
>> >
>> >
>> > It is also a fact that there are multiple implementations from
>> > multiple vendors already shipping that utilize this mechanism for
>> > TLVs such as Neighbor and Prefix reachability.
>> >
>> >
>> >
>> > The existing solution - discussed in https://datatracker.ietf.org/doc
>> > /draft-pkaneria-lsr-multi-tlv/ has already been successfully
>> > implemented and deployed by multiple vendors.
>> >
>> > [HC]: You are a co-author of this draft, called a first draft for
>> > resolving the problem on big TLVs. This first draft contains some
>> > protocol extensions. If there is a solution for the problem without
>> > requiring any protocol extensions, then why do you as a co-author
>> > work on the first draft with protocol extensions?
>> >
>> >
>> >
>> > [LES:] There are no protocol extensions defined in
>> > draft-pkaneria-lsr-multi-tlv-02 (please see the statement in the IANA
>> > section). The draft has been written to clarify existing behavior and
>> > to discuss best deployment practices in cases where not all
>> > implementations support reception of multiple TLVs for a given
>> > object.
>> >
>> >
>> >
>> > The definition of a second solution to the problem is not needed -
>> > and in fact further complicates both implementation and deployment.
>> > Should the existing solution be used? Should the new solution be
>> > used? What is the state of support by all nodes in the network for
>> > each solution?
>> >
>> > [HC]: It seems better to merge the two drafts (i.e., the first draft
>> > and the second draft defining container TLV) into one.
>> >
>> >
>> >
>> > [LES:] This would the worst possible outcome.
>> >
>> > It would define two mechanisms for sending more than 255 bytes of
>> > information about an object.
>> >
>> > This would require implementations to support two different
>> > mechanisms for advertising the same information – also requiring the
>> > ability to control which mechanism should be used in a given
>> > deployment and even raising the possibility that both forms would
>> > need to be sent in parallel. This adds unnecessary complexity to
>> > implementations.
>> >
>> >
>> >
>> > For operators deploying features+scale which require such support,
>> > they would now have to identify not only whether all implementations
>> > in their deployment support sending/receiving more than 255 bytes/
>> > object, but also which form of advertisement is supported – further
>> > complicating deployment considerations.
>> >
>> >
>> >
>> > And since there are explicit statements requiring the current form of
>> > advertisement to be used for some TLVs, behavior would potentially
>> > differ on a per TLV basis.
>> >
>> >
>> >
>> > The motivation for the new solution seems to be the notion that it
>> > supports partial deployment. Text in https://www.ietf.org/archive/id/
>> > draft-chen-lsr-isis-big-tlv-00.html#name-incremental-deployment
>> > states:
>> >
>> >
>> >
>> > "For a network using IS-IS, users can deploy the extension for big
>> > TLV in a part of the network step by step.
>> >
>> > The network has some nodes supporting the extension (or say new
nodes
>> > for short) and the other nodes not
>> >
>> > supporting the extension (or say old nodes for short) before the
>> > extension is deployed in the entire network."
>> >
>> >
>> >
>> > This suggests the authors believe that a network can function with
>> > some nodes using all of the advertisements and some nodes using only
>> > the legacy advertisements, but this is obviously false.
>> >
>> > Fundamental to operation of a link state protocol is that all nodes
>> > in the network operate on identical LSPDBs.
>> >
>> > The suggestion that features will work correctly when some nodes use
>> > attributes advertised in legacy TLVs and the new container TLV while
>> > some nodes use only the attributes advertised in legacy TLVs is
>> > simply incorrect.
>> >
>> > [HC]: Every node in the network has the same LSPDB. The new nodes
>> > understand the new container TLVs and may use them. The old nodes
do
>> > not understand them and do not use them.
>> >
>> >
>> >
>> > [LES:] Consider the following simple example.
>> >
>> > Node A needs to send 10 sub-TLVs about a particular object –
>> > requiring more than 255 bytes to be sent.
>> >
>> > Some nodes in the network do not support reception of more than 255
>> > bytes/object. Consider two such nodes.
>> >
>> > Node B, based on the local configuration, needs to be able to receive
>> > sub-TLVs 1,3,5,7,9 from A.
>> >
>> > Node C, based on local configuration, needs to be able to receive
>> > sub-TLVs 2,4,6,8,10 from A.
>> >
>> >
>> >
>> > There is no way that A can advertise all 10 sub-TLVs in a way which
>> > allows both B and C to correctly process the sub-TLVs they require.
>> >
>> >
>> >
>> > Network functionality is compromised.
>> >
>> >
>> >
>> > It is true that even with the existing solution unless all nodes are
>> > capable of processing more than 255 bytes of information/object
>> > network functionality will be compromised. That is exactly what
>> > motivated the writing of draft-pkaneria-lsr-multi-tlv.
>> >
>> > But your proposal does nothing to make that requirement easier to
>> > address. It in fact makes implementation/deployment even more
>> > difficult – as I have described above.
>> >
>> >
>> >
>> > It is also important to also state that the advertisement of more
>> > than 255 bytes of information is driven by configuration – not a
>> > protocol implementation choice. Suppressing advertisement of some of
>> > the configured information also does not result in a working network.
>> >
>> >
>> >
>> > In short, there is no positive value from the proposed extension –
>> > and it does harm by further complicating implementations and
>> > deployments.
>> >
>> > [HC]: The second draft defines a general mechanism for resolving the
>> > problem. It is backward compatible and simple. It does not do any
>> > harm.
>> >
>> >
>> >
>> > [LES:] You are proposing a second solution for a problem that has
>> > already been solved. In doing so you are introducing new problems and
>> > not solving any existing issues. Saying this “does no harm” is
>> > clearly false.
>> >
>> >
>> >
>> > Les
>> >
>> >
>> >
>> >
>> >
>> > The draft should be abandoned.
>> >
>> >
>> >
>> > Les
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Lsr mailing list
>> > [email protected]
>> > https://www.ietf.org/mailman/listinfo/lsr
