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<mailto:ginsb...@cisco.com>>
Sent: Thursday, March 23, 2023 3:35 AM
To: lsr@ietf.org<mailto:lsr@ietf.org> <lsr@ietf.org<mailto:lsr@ietf.org>>;
draft-chen-lsr-isis-big-tlv.auth...@ietf.org<mailto:draft-chen-lsr-isis-big-tlv.auth...@ietf.org>
<draft-chen-lsr-isis-big-tlv.auth...@ietf.org<mailto: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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-pkaneria-lsr-multi-tlv%2F&data=05%7C01%7Chuaimo.chen%40futurewei.com%7C6e9af0fb3bcd4bef57a408db2b7125a4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638151537195561122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=23RCLltpVh%2BmKSaVzz6v%2FprNKtUU%2Bqx0FEik6x7qvHs%3D&reserved=0>
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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-chen-lsr-isis-big-tlv-00.html%23name-incremental-deployment&data=05%7C01%7Chuaimo.chen%40futurewei.com%7C6e9af0fb3bcd4bef57a408db2b7125a4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638151537195561122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AwI4YHL1uPDwbqPoCtjvobS424RT3OGNWdUxM9XclUY%3D&reserved=0>
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
