Thanks,
Chris.
"Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes:
> Chris -
>
> <snip>
> 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.
>
> 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.
> <end snip>
>
> No - this does not work.
> Customer deploys some features. They expect all routers in the network to
be able to correctly calculate topology and correctly forward for the features
they support.
> They do not deploy a feature and expect only a subset of the routers in the
network that are configured to support the feature to correctly calculate
paths.
>
> There is no way to successfully support incremental deployment.
>
> I already gave an example in my comments below:
>
>> >> > [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.
>> >> >
>
> Les
>
>> -----Original Message-----
>> From: Christian Hopps <cho...@chopps.org>
>> Sent: Tuesday, March 28, 2023 9:52 AM
>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
>> Cc: Christian Hopps <cho...@chopps.org>; Huaimo Chen
>> <huaimo.c...@futurewei.com>; draft-chen-lsr-isis-big-
tlv.auth...@ietf.org;
>> lsr@ietf.org
>> Subject: Re: [Lsr] Comments on draft-chen-lsr-isis-big-tlv-00
>>
>>
>> "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> 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 <cho...@chopps.org>
>> >> Sent: Tuesday, March 28, 2023 7:27 AM
>> >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
>> >> Cc: Huaimo Chen <huaimo.c...@futurewei.com>; draft-chen-lsr-isis-
big-
>> >> tlv.auth...@ietf.org; lsr@ietf.org
>> >> 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)" <ginsberg=40cisco....@dmarc.ietf.org>
>> writes:
>> >>
>> >> > Huaimo –
>> >> >
>> >> >
>> >> >
>> >> > Please see inline.
>> >> >
>> >> >
>> >> >
>> >> > From: Huaimo Chen <huaimo.c...@futurewei.com>
>> >> > Sent: Sunday, March 26, 2023 3:41 AM
>> >> > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org;
>> >> > draft-chen-lsr-isis-big-tlv.auth...@ietf.org
>> >> > 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) <ginsb...@cisco.com>
>> >> > Sent: Thursday, March 23, 2023 3:35 AM
>> >> > To: lsr@ietf.org <lsr@ietf.org>;
>> >> > draft-chen-lsr-isis-big-tlv.auth...@ietf.org <
>> >> > draft-chen-lsr-isis-big-tlv.auth...@ietf.org>
>> >> > 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
>> >> > Lsr@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/lsr
