Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

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

Huaimo -

Please see my replies inline - look for LES2:


From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Huaimo Chen
Sent: Monday, November 27, 2023 8:20 AM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; lsr <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Hi Les,

Thanks for your reply.
My responses are inline below with [HC] and attached in .pdf since there are figures.

Best Regards,
Huaimo



Huaimo -

Every statement you make below is false.
[HC]: There are 8 statements I make: 4 statements on MP-TLV and 4 on Big-TLV.
Each of the 4 statements on MP-TLV is true, right? You do not comment on any of them.
[LES2:] I did not reply regarding your comments on MP-TLV because:

a)We never claimed MP was backwards compatible
b)Your other statements  regarding MP are indeed FALSE - my answers to the parallel bullet items regarding Big-TLV explain why.

Each of the 4 statements on Big-TLV is also true. See my explanations below.


These points have been discussed - in WG meetings, on the mailing list, and in private conversations.
But you persist in repeating false claims.
This is not helpful.
[HC]: "A point has been discussed" means at least two emails/opinions are exchanged for this point.
Have you seen/found at least two emails/opinions for each of these points/claims/statements from the WG meeting minutes, the LSR mailing list, and the private emails exchanged with me?
In fact, some of these points/claims/statements are not discussed at all.
For example, no discussions about the points in statement 2 on MP-TLV and statement 2 on Big-TLV could be found from the WG meeting minutes, the LSR mailing list, and the private emails that I sent and received.


You are, of course, entitled to have whatever opinion you choose regarding MP vs Big-TLV, but making false claims does not help the WG discussion.
Please stop.
[HC]: It seems not good (or professional) to say someone makes false claims and in this way.
Some of these points/claims/statements are not discussed at all. And claims/statements I make are true.
Why do you say:
"These points have been discussed - ....
But you persist in repeating false claims. ...
You are, ..., but making false claims does not help the WG discussion.
Please stop."?


I have taken some time to respond to each point inline below, explaining why it is false.
[HC]: I will explain why each statement is true in detail below.


As I have suggested to you in the past, if you took the time to implement a prototype of your draft and tested against legacy systems (as has been done with MP), you would easily see the truth. The fact that you have not done this - but write a draft that you intend other people to implement - is a failing on your part.

Please see inline.

From: Huaimo Chen <[e-mail]<mailto:[e-mail]>>
Sent: Friday, November 24, 2023 5:37 AM
To: Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; lsr <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Hi Everyone,

The solution in draft-pkaneria-lsr-multi-tlv has the following issues:


  1.  Not backward compatible. Unpredictable behavior with partial deployment, which is stated in both IETF 117 and IETF 118 slides of draft-pkaneria-lsr-multi-tlv
IETF118: https://datatracker.ietf.org/meeting/118/materials/slides-118-lsr-03-1-mptlv-00
IETF117: https://datatracker.ietf.org/meeting/117/materials/slides-117-lsr-2-isis-mptlv-00
The unpredictable behaviors include inconsistent LSDBs and routing loops.

  1.  Not general. When any TLV is bigger than 255 bytes and multi-part-TLVs are used for the TLV, a key must be selected by people (LSR WG) for the TLV and some special code/enhancement is required for determining the key.
  2.  Big overhead. For the first multi-part-TLV example in Section 4.1 of draft-pkaneria-lsr-multi-tlv-02, the overhead will be 46 (= 7 + 3 + 18 + 18) bytes when IPv6 addresses are used and 22 bytes when IPv4 addresses are used.
  3.  Extra operations/configurations for network operators.

These issues are resolved by the proposal in draft-chen-lsr-isis-big-tlv. The proposal is


  1.  Backward compatible. No unpredictable behavior with partial deployment.
[LES:] Given a network where some nodes do not support Big-TLV, assume that a node which does support Big-TLV is required to advertise an additional link attribute (e.g. delay) in support of a given Flex-Algo - say algo 130.
Since that node is already advertising 255 bytes of information about that link, it puts the delay sub-TLV into a Big-TLV.
The nodes which support Big-TLV will correctly process that information and use it in their algo 130 SPFs.
But the legacy nodes which are configured to support algo 130, will ignore Big-TLV and so will not have the delay information as input to their algo 130 SPFs.
Because of this inconsistency, there is a possibility of loops and/or blackholes for algo 130 paths.
Therefore, the statement that there is "no unpredictable behavior with partial deployment" is FALSE.
Just as with MP, it is not safe to use Big-TLV in the presence of legacy nodes.

[HC]: In the case you state above, my statement "No unpredictable behavior with partial deployment" is TRUE.
The new information: additional link attribute (e.g. delay) in support of a given Flex-Algo - say algo 130, is put into a container TLV by a node supporting Big-TLV. The container TLV with the new information is advertised. The nodes not supporting Big-TLV ignore the container TLV. The nodes supporting Big-TLV have the new information.
If all the nodes need to have the same new information for using the new information, every node supporting Big-TLV needs to check if all the nodes support the Big-TLV capability which is distributed by each node supporting Big-TLV. If all the nodes support it, every node uses the new information.
In the case above, the nodes supporting Big-TLV will not use the new information since there are some nodes not supporting Big-TLV. Thus, there are not any loops and/or blackholes for algo 130 paths. There is "No unpredictable behavior with partial deployment". This is different from MP-TLV.


[LES2:] Let's dig deeper.
Your proposal is that upgraded nodes can send Big-TLV at any time, but no node will actually use the information advertised in Big-TLV unless all nodes in the network explicitly indicate that they support Big-TLV.
In order to explicitly indicate support, you now REQUIRE (as in MUST) all nodes to send a new sub-TLV of the Router Capability TLV indicating Big-TLV support. And, because safe use of Big-TLV is per encapsulated codepoint (as I explained below) the new sub-TLV MUST explicitly indicate which codepoints are supported. It is NOT enough for a node to say it supports Big-TLV - it has to indicate which encapsulated codepoints it supports. And until such support is available network-wide, the network will not behave in a predictable manner since information which is required for correct operation is not being used. The fact that such information is advertised doesn't make the network work as intended. In the example I provided above for flex algo, the flex algo topology is compromised. Instead of loops or blackholes, you will either get traffic that travels via non-best paths (because the best paths are unusable due to unprocessed link attribute info) or traffic that is dropped because no usable path can be found even when such a path is actually present.
I stand by my statement that the network behavior is unpredictable with partial deployment.



  1.  General. Neither key selection nor special code/enhancement is required for any TLV when it is bigger than 255 bytes.
[LES:] Support for Big-TLV requires new code to be written. And that code has to be done for each TLV for which you wish to support the use of Big-TLV. The fact that an implementation has added code to use Big-TLV for IS Neighbor advertisements does not mean that you get the same support for Prefix Reachability TLVs for free. You also have to modify the code which supports prefix reachability to use Big-TLV when appropriate. And so on for other TLVs...
Again, this would be obvious if you actually tried to implement Big-TLV support.

This is no different than MP - as has been discussed, MP support is per TLV.

[HC]: The differences between MP-TLV and Big-TLV include:
- MP-TLV: When any TLV is bigger than 255 bytes and multi-part-TLVs are used for the TLV, a key must be selected by people (LSR WG) for the TLV.
- Big-TLV: No key selection when any TLV is bigger than 255 bytes and Big-TLV is used for the TLV.
* MP-TLV: Some special code/enhancement is required for determining the key.
* Big-TLV: No special code/enhancement is required for determining the key.
The first and third (i.e., -MP-TLV and *MP-TLV) items constitute statement 2 on MP-TLV, which is true.
The second and fourth (i.e., -Big-TLV and *Big-TLV) items constitute statement 2 on Big-TLV, which is true.

[LES2:] I do not agree - see comments below for further details.



  1.  Small overhead. The overhead will be 2 bytes.
[LES:] What you are referring to here are the use of link endpoint identifiers, whether they be IPv4 addresses, IPv6 addresses, or Link IDs in an IS Neighbor advertisement. To
understand why they are needed, let's use the example below:

+----+                   +----+
|    |                   |    |
| A  |10.1.1.1---10.1.1.2| B  |
|    |11.1.1.1---11.1.1.2|    |
|    |                   |    |
+----+                   +----+


There are two links between A-B with IPv4 addresses as shown.

An IS-Neighbor advertisement consists of:
TLV
Length
Neighbor system-id
Metric
Length of sub-TLVs
Sub-TLVs

If a link endpoint identifier is NOT included among the sub-TLVs, then it is not possible to tell whether the link attribute sub-TLVs apply to the link (10.1.1.1/10.1.1.2) or the link (11.1.1.1/11.1.1.2). The neighbor system-id alone is ambiguous.
This is key for many link attributes e.g., all of the TE attributes, adjacency SIDs.

When using MP, it is necessary to include link endpoint identifiers in each of the TLVs associated with that link.
For the same reason, when using Big-TLV, the link endpoint identifiers have to be included in the encapsulated IS Neighbor TLV(s). Big-TLV encap itself does not provide this information.

There is however one difference between MP and Big-TLV: Big-TLV consumes an additional 2 bytes of encapsulation. So Big-TLV is slightly less efficient than MP.

The important point here is that the claim of "small overhead" for Big-TLV as compared to MP is false.


[HC]: When MP-TLVs are used for a TLV bigger than 255 bytes, the overhead is the key or the size of the key (SK) for each additional MP-TLV, refer to the figure below.
[cid:image001.png@01DA2131.5AD14830]
When Big-TLV is used for a TLV bigger than 255 bytes, the overhead is the type of the TLV and a reserved byte (i.e., 2 bytes) for each container TLV, refer to the figure below.
[cid:image002.png@01DA2131.5AD14830]
The size of the key for any TLV bigger than 255 is bigger than 2 bytes in general.
My statement (overhead of MP-TLV is big and overhead of Big-TLV is small) is true.

[LES2:] Let's take a deeper look using the example topology I showed above.
Assume that I already have 255 bytes of information being advertised for each link and I now want to advertise an additional attribute for each link - let's use Delay as the example.

What does the Big-TLV encoding look like?
According to you, if I look at what Node A would send for each link we would have:

Big-TLV type/length
IS-Neighbor Type/Length
Neighbor System ID: B
Metric Value: 10
Delay sub-TLV for Link #1

Big-TLV type/length
IS-Neighbor Type/Length
Neighbor System ID: B
Metric Value: 10
Delay sub-TLV for Link #2

How can I tell which Big-TLV advertisement is for Link #1 and which is for Link #2?
The neighbor system-id is the same in both.
The metric is the same in both.
The answer is I can't tell.
In order to correctly associate the additional sub-TLV (Delay) with the correct link I need to include link endpoint identifiers inside of the Big-TLV encapsulation - just as was done in the unencapsulated IS Neighbor advertisements for each link.




  1.  No extra operations/configurations for network operators.
[LES:] This claim is dependent on the false claim #1 above that Big-TLV is safe to deploy in the presence of legacy nodes - which is not true.
Safe use of Big-TLV will require a means for operators to control when use of Big-TLV can be enabled - just as with MP.

[HC]: Claim #1 is true as I explained above. This claim #4 is true. Safe use of Big-TLV does not require a means for operators to control when use of Big-TLV can be enabled.
Operations for using MP-TLV include:

  1.  Nodes in a network are upgraded to support MP-TLV, but MP-TLV is disabled by default.
  2.  A network operator checks whether all the nodes in the network support MP-TLV using CLI or some tools.
  3.  The network operator enables MP-TLV on every node if all the nodes support MP-TLV.
Operations for using Big-TLV include:

  1.  Nodes in a network are upgraded to support Big-TLV, but Big-TLV is enabled by default.
The extra operations in the second and third step for using MP-TLV are not needed for using Big-TLV.

[LES2:] If you assume that network operators feel comfortable with all of the following:


  *   Sending of new advertisements that (hopefully) won't be used
  *   Strict adherence by all updated nodes to not using Big-TLV info until all nodes indicate support
  *   Uncontrolled oscillation of the use of the Big-TLV info as a legacy node is introduced or removed

then maybe an additional knob may not be required.
But based on my experience, operators prefer to have the ability to suppress new functionality - if for no other reason than to isolate the network from bugs which were (unintentionally) introduced.
So, I am willing to give you a "maybe" on this point - but I am betting operators will ask for a knob even if you claim it isn't required.

   Les



   Les


In summary

draft-pkaneria-lsr-multi-tlv
draft-chen-lsr-isis-big-tlv
Backward compatible
No
Yes
General
No
Yes
Overhead
Big
Small
Extra operations
Yes
No

IF the adoption of draft-pkaneria-lsr-multi-tlv prevents the adoption of draft-chen-lsr-isis-big-tlv, THEN I oppose the adoption of draft-pkaneria-lsr-multi-tlv.

Best Regards,
Huaimo





From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Yingzhen Qu
Sent: Friday, November 17, 2023 12:24 PM
To: [e-mail]<mailto:[e-mail]>; lsr <[e-mail]<mailto:[e-mail]>>
Subject: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Hi,

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org)<https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/>

Please send your support or objection to the list before December 9th, 2023. An extra week is allowed for the US Thanksgiving holiday.

Thanks,
Yingzhen