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

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

Huaimo –

My apologies – you are correct – Big-TLV draft does describe the contiguous placement of the two TLVs – I should have read the draft more carefully.

But this is still a very bad idea – for the reasons I have stated.

Thanx.

   Les


From: Huaimo Chen <[e-mail]>
Sent: Friday, December 1, 2023 6:14 AM
To: Les Ginsberg (ginsberg) <[e-mail]>; Yingzhen Qu <[e-mail]>; [e-mail]; lsr <[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 [HC3].

Best Regards,
Huaimo
From: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 30, 2023 3:02 PM
To: Huaimo Chen <[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)

Huaimo –

I am providing a top post reply to one of your responses.
For the others, we disagree. I have explained things as clearly as I can.  I have nothing further to say on those points.

Regarding:

[HC2]: I guess you talk about two TLVs: one TLV (TLV 1) for Link #1 and the other (TLV 2) for Link #2.
TLV 1 contains a key (say key 1) for link #1. TLV 2 contains another key (say key 2) for link #2. Both TLVs already have 255 bytes of information being advertised. You now want to advertise an additional attribute for each link such as Delay: one Delay sub-TLV for Link #1 and another Delay sub-TLV for Link #2. Is my guess correct?
If so, see the figures below for MP-TLV and Big-TLV for TLV 1 and TLV 2.

There are two MP-TLVs for the TLV for Link #1: MP-TLV 0 and MP-TLV 1, each contains Key 1. The overhead is Key 1 in MP-TLV 1.
There are two MP-TLVs for the TLV for Link #2: MP-TLV 0 and MP-TLV 1, each contains Key 2. The overhead is Key 2 in MP-TLV 1.
[cid:image001.png@01DA2459.D4007520]

Big-TLV for TLV for link #1 has a normal TLV of type T and a container TLV 1. The normal TLV contains Key 1. The container TLV does not contain Key 1, but contains type T. The overhead is 2 bytes.
When a node (e.g., node A) originates the Big-TLV for TLV for link #1, it places the container TLV just below the normal TLV in its LSP. After receiving these two TLVs in the LSP (originated by node A), any node supporting Big-TLV obtains all the information for link #1. The LSP received is the same as the one originated since the LSP is not modified all the way from its originator to a receicer.
Big-TLV for TLV for link #2 has a normal TLV of type T and a container TLV 1. The normal TLV contains Key 2. The container TLV does not contain Key 2, but contains type T. The overhead is 2 bytes.
When a node (e.g., node A) originates the Big-TLV for TLV for link #2, it places the container TLV just below the normal TLV in its LSP. After receiving these two TLVs in the LSP (originated by node A), any node supporting Big-TLV obtains all the information for link #2.

[LES3]: This is a really bad idea.
All IS-IS TLVs today are parsed independent of placement (with a few exceptions for TLVs which MUST be in LSP #0). The position of a TLV within a given LSP is of no significance – and the LSP number in which the TLV appears is also of no significance.

[HC3]:  RFC 1195 says:
“Except where explicitly stated otherwise, these variable length fields may occur in any order.”
This indicates that the order of some variable length fields (i.e.,TLVs) can be stated, right?

What you propose requires major changes to parsing logic. It restricts TLVs to be within a single LSP and requires them to be “contiguous”. And it introduces inheritance of key information – meaning the context for a given TLV is no longer self-contained.
All very undesirable changes which will have major impact on the implantation of parsing logic.

[HC3]:  The change required is small and has no major impact on parsing logic.
For any normal TLV of type T, there is not any change for parsing it.
After finishing parsing the normal TLV,  check if there is a container TLV with type T following.
If not, it is done for the TLV; if there is, parse the container TLV.
The originator of a TLV places its normal TLV and container TLV in order within a single LSP when TLV > 255.
Does this violate any protocols?

Further, ISO 10589 recommended from Day 1 that TLV information not be moved from one LSP to another when LSPs were regenerated. This minimizes LSP flooding as a result of topology changes and reduces the transient windows where there are temporarily two copies of the same information in the LSDB.
In deployments of small scale, this recommendation was only of minor importance as most routers only generated one or two LSPs. But as scale has increased the number of LSPs generated by each node has also increased and the importance of adhering to the ISO 10589 guideline has also increased. We have seen major impacts to stability and convergence in real deployments as a result of implementations unnecessarily moving information from one LSP to another.
Your proposal would increase the frequency when information would need to be moved. If the unencapsulated TLV is currently being advertised in an LSP which does not have space available, the unencapsulated TLV would have to be moved to another LSP where more space is available, thus requiring an update to at least two LSPs where only one LSP update should be necessary. This is to be avoided.

[HC3]:  When the size of any normal TLV increases, if it cannot fit in its current LSP, then it needs to be moved too.

As an aside, given that your draft makes no mention of this approach – I could complain that you have either been less than forthcoming or are simply “making this stuff up from one email to the next”.
I could also point out that it is possible for MP to take the same approach – and thereby save the 2 bytes of Big-TLV encapsulation.

[HC3]:  Two options of container TLV have been described in the draft since -00 version. One option (say option 1) does not include a Key, the other (say option 2) includes a Key.

But since this is a bad idea, none of that matters. 😊

[HC3]:  There are 8 statements, 4 on MP-TLV and 4 on BIG-TLV. Refer to
email2Lsr-adoption-mp-tlv-2023-11-24.pdf attached or
https://mailarchive.ietf.org/arch/msg/lsr/0EyBQwKFXPMl0qzXyWR-hsbBhec/

For both options of container TLV, the 6 statements below are TRUE as explained in my previous emails. Refer to email2Lsr-Reply2Les-2023-11-30.pdf attached or
https://mailarchive.ietf.org/arch/msg/lsr/LUD7FPdSu4EbsMNCUGqDaTc5Sy0/

Statement 1 on MP-TLV is TRUE (find the first “[HC2]:”, see the related text)
Statement 2 on MP-TLV is TRUE (find “***For statement 2 on MP-TLV”, see the related text)
Statement 3 on MP-TLV is TRUE (find “***For statement 3 on MP-TLV”, see the related text)
Statement 4 on MP-TLV is TRUE (find “***For statement 4 on MP-TLV”, see the related text)
Statement 1 on Big-TLV is TRUE (find “Backward compatible. N”, see the text following [HC]: and [HC2]:)
Statement 4 on Big-TLV is TRUE (find “No extra operations”, see the text following [HC]: and [HC2]:)

For option 1, all the 8 statements are TRUE (6 above and 2 below) as explained in my previous emails.

Statement 2 on Big-TLV is TRUE (find “General. N”, see the text following [HC]: and [HC2]:)
Statement 3 on Big-TLV is TRUE (find “Small overhead.”, see the text and figures following [HC]: and [HC2]:)


   Les
From: Huaimo Chen <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 30, 2023 6:21 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 [HC2] and attached in .pdf since there are figures.

Best Regards,
Huaimo

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
[HC2]: Good. You recognize that statement 1 on MP-TLV is TRUE.

b)Your other statements  regarding MP are indeed FALSE – my answers to the parallel bullet items regarding Big-TLV explain why.
[HC2]:  A statement is true if what it asserts is the case.
***For statement 2 on MP-TLV,
When any TLV is bigger than 255 bytes and multi-part-TLVs are used for the TLV,
a) must a key be selected by people (LSR WG) for the TLV?
b) is some special code/enhancement required for determining the key for the TLV?

What are your answers to a) and b)?

If the answers to a) and b) are YES, then what statement 2 on MP-TLV assets is the case, statement 2 on MP-TLV is TRUE.

The answer to a) needs to be YES.
If the answer to a) is NO, then different implementations may use different keys for the TLV and may not interop.
The answer to b) needs to be YES too.
Different types of TLVs have different keys when MP-TLVs are used for these TLVs. Different pieces of codes are required for determining different keys.


***For statement 3 on MP-TLV,
The overhead of MP-TLV used for Extended IS Reachability TLV is calculated based on Section 4.1 (attached below for your convenience) of the draft.
The overhead is the size of the key, which is 46 (= 7 + 3 + 18 + 18) bytes when IPv6 addresses are used and 22 bytes when IPv4 addresses are used.
This is the case from Section 4.1 of the draft.

4.1.  Example: Extended IS Reachability

   As an example, consider the Extended IS Reachability TLV (type 22).
   A neighbor in this TLV is specified by:

   *  7 octets of system ID and pseudonode number
   *  3 octets of default metric

   *  Optionally one or more of the following identifiers:

      -  IPv4 interface address and IPv4 neighbor address as specified
         in [RFC5305]

      -  IPv6 interface address and IPv6 neighbor address as specified
         in [RFC6119]

      -  Link Local/Remote Identifiers as specified in [RFC5307]

   This acts as the key for this entry.  Note that the link identifiers
   are encoded as sub-TLVs and MAY appear in any order. …

   If the remaining space in the TLV is insufficient to advertise all
   other sub-TLVs, then the node MAY advertise additional Extended IS
   Reachability TLVs.  The key information MUST be replicated
   identically.

***For statement 4 on MP-TLV,
The operations that network operators do, using CLI or some tools, include:

  1.  check whether all the nodes in the network support MP-TLV;
  2.  check which node supports MP-TLV for which codepoint (since Multi-Part TLV procedures are potentially applicable to any codepoint that allows sub-TLVs to be included as part of the information advertised. Refer to Section 6 of the draft); and
  3.  enable MP-TLV on every node if all the nodes support MP-TLV or enable MP-TLV on every node if all the nodes support MP-TLV for the same sets of codepoints.
These operations are derived from the draft.


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.

[HC2]: You say:
“The fact that such information is advertised doesn’t make the network work as intended.”
When LSDBs on the nodes are not the same, what do you think the network intends to work?
From your second last sentence above (i.e.,
Instead of loops or blackholes, you … such a path is actually present.),
the intent you want seems to find and use the best paths using inconsistent LSDBs even though this may lead to routing loops or blackholes. This intent seems not right.

Here we talk about whether there is an unpredictable behavior with partial deployment.
There is “No unpredictable behavior with partial deployment” when the capability for every encapsulated codepoint is indicated and distributed in a new sub-TLV of the Router Capability TLV indicating Big-TLV support. In one option, one bit flag is used to indicate the capability for one encapsulated codepoint. In another (improved) option, one bit flag is used to indicate the capability for a group of encapsulated codepoints (i.e., this one bit flag set to 1 indicates the capability for each of the encapsulated codepoints in the group is supported).


  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.

[HC2]: For statement 2 on MP-TLV, refer to my explanation on ***For statement 2 on MP-TLV above.
For statement 2 on Big-TLV, see my explanation in detail below.


  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:image002.png@01DA2459.D4007520]
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:image003.png@01DA2459.D4007520]
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.

[HC2]: I guess you talk about two TLVs: one TLV (TLV 1) for Link #1 and the other (TLV 2) for Link #2.
TLV 1 contains a key (say key 1) for link #1. TLV 2 contains another key (say key 2) for link #2. Both TLVs already have 255 bytes of information being advertised. You now want to advertise an additional attribute for each link such as Delay: one Delay sub-TLV for Link #1 and another Delay sub-TLV for Link #2. Is my guess correct?
If so, see the figures below for MP-TLV and Big-TLV for TLV 1 and TLV 2.

There are two MP-TLVs for the TLV for Link #1: MP-TLV 0 and MP-TLV 1, each contains Key 1. The overhead is Key 1 in MP-TLV 1.
There are two MP-TLVs for the TLV for Link #2: MP-TLV 0 and MP-TLV 1, each contains Key 2. The overhead is Key 2 in MP-TLV 1.
[cid:image001.png@01DA2459.D4007520]

Big-TLV for TLV for link #1 has a normal TLV of type T and a container TLV 1. The normal TLV contains Key 1. The container TLV does not contain Key 1, but contains type T. The overhead is 2 bytes.
When a node (e.g., node A) originates the Big-TLV for TLV for link #1, it places the container TLV just below the normal TLV in its LSP. After receiving these two TLVs in the LSP (originated by node A), any node supporting Big-TLV obtains all the information for link #1. The LSP received is the same as the one originated since the LSP is not modified all the way from its originator to a receicer.
Big-TLV for TLV for link #2 has a normal TLV of type T and a container TLV 1. The normal TLV contains Key 2. The container TLV does not contain Key 2, but contains type T. The overhead is 2 bytes.
When a node (e.g., node A) originates the Big-TLV for TLV for link #2, it places the container TLV just below the normal TLV in its LSP. After receiving these two TLVs in the LSP (originated by node A), any node supporting Big-TLV obtains all the information for link #2.
[cid:image004.png@01DA2459.D4007520]



  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.

[HC2]: Refer to ***For statement 4 on MP-TLV above, which gives more operations. Operations a), b) and c) there are extra.

If all the nodes need to have the same new information for using the new information, every node will check if all the nodes support the big TLV capability which is distributed by the nodes supporting it.  If all the nodes support it, every node uses the new information.

If it is not required that all the nodes must have the same new information for using the new information, the nodes supporting the big TLV capability can use the new information, the nodes not supporting the big TLV capability ignore the new information.

It seems that “a legacy node is introduced or removed” happens during migration/upgrade stage. After migration/upgrade is done, the network is stable, it should not happen.

   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