Huaimo - Every statement you make below is false. 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.
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. I have taken some time to respond to each point inline below, explaining why it is false. 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 <huaimo.c...@futurewei.com> Sent: Friday, November 24, 2023 5:37 AM To: Yingzhen Qu <yingzhen.i...@gmail.com>; draft-pkaneria-lsr-multi-...@ietf.org; lsr <lsr@ietf.org> 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. 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. 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. 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. 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 <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Yingzhen Qu Sent: Friday, November 17, 2023 12:24 PM To: draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>> 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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
