Huaimo – THis discussion seems to be getting less and less meaningful – but I will respond.
Regarding IID-TLV, thanx for pointing out that this is another case where the use of MP has been explicitly stated. 😊 Regarding RFC 5311 and TLV 22/23, the reason that TLV 23 was defined is because there are restrictions on the use of TLV 22 in the “Extended LSPs” introduced in RFC 5311. This has nothing whatsoever to do with MP or Big-TLV – it really isn’t relevant at all. Your introduction of it into this discussion isn’t helpful. Perhaps you don’t fully understand RFC 5311 – for which I would not blame you. The RFC is a somewhat arcane attempt to extend the 256 LSP limit in the protocol. IT never became popular – somewhat understandably – and I doubt that most people are familiar with it. Trying to use it to clarify/justify anything in the MP/Big-TLV discussion is not appropriate. Les From: Huaimo Chen <huaimo.c...@futurewei.com> Sent: Friday, December 8, 2023 5:46 AM To: Tony Przygienda <tonysi...@gmail.com> Cc: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; li_zhenqi...@hotmail.com; Tony Li <tony...@tony.li>; Linda Dunbar <linda.dun...@futurewei.com>; 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 Tony, Thank you for your reply. My responses are inline below with [HC2]. Best Regards, Huaimo Huaimo, first, I fail to see how 8202 has anything to do with this discussion. [HC2]: RFC 8202 defines Instance Identifier TLV (IID-TLV for short), which has TLV type 7. When IID-TLV > 255 (i.e., its value > 255), RFC 8202 specifies a way or approach to encode/decode it (IID-TLV > 255). So, it is related to this discussion. Did you try to implement and deploy 5311 in real networks and seen the operational impact ? and are you suggesting that we need to have that deployed as precondition for big-tlv idea ? [HC2]: No. RFC 5311 is not a precondition for Big-TLV. 'nuff said ... -- tony On Thu, Dec 7, 2023 at 3:12 PM Huaimo Chen <huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>> wrote: Hi Tony, My responses are inline below with [HC]. Best Regards, Huaimo practically speaking "backwards compatibility" here is restricted by the fact that 1) we have in most largest networks de facto mp-tlv deployed and relied on for operations implemented by all major vendors. 2) we cannot encode mp-tlv deployed in parallel with "something new that we flip over once e'one has it" since the encoding space is limited and there are deployments that consume on some node so many fragments re-encoding twice until cut over would immediately break those networks [HC]: We have encoded TLVs > 255 in two different ways (or say, deployed in parallel) already. RFC 8202 specifies one way for IID-TLV (TLV 7) > 255 on page 4-6 (quoted some text below for your convenience). “A single IID-TLV will support advertisement of up to 126 ITIDs. If multiple IID-TLVs are present in an IIH PDU, the supported set of ITIDs is the union of all ITIDs present in all IID-TLVs.” RFC5311 defines another way for extended IS reachability TLV 22 and MT-ISN TLV 222 > 255, in which two new TLVs: IS Neighbor Attribute TLV 23 and MT IS Neighbor Attribute TLV 223, are defined. Some texts from RFC 5311 are quoted below for your convenience. “If the attribute information does not conflict, it MUST be considered additive.” “In cases where information about the same neighbor/link/attribute appears in both TLV 22 and TLV 23 (or TLV 222 and TLV 223 for the same MTID) then the information in TLV 22 (or TLV 222) MUST be used and the information in TLV 23 (or TLV 223) MUST be ignored.” “Utilization of the new TLVs for neighbor attribute information would provide additional benefits that include: Easier support for a set of TE information associated with a single link that exceeds the 255-byte TLV limit by allowing the interpretation of multiple TLVs to be considered additive rather than mutually exclusive.” These two different ways do not affect each other. There is no flip over. A new way for TLVs > 255 will not affect any existing way. There will not be any flip over. Corollary I: a flag day on such networks is NOT possible unless it's seamlessly flipping to something new while disabling old [HC]: Corollary 1 seems not valid since the Theorem on which Corollary 1 based is not valid. The Theorem is 1) and 2) above. The Theorem is not valid (or true) since 2) is false. Collorary II: no matter how many times something that does not meet those 2 criteria is suggested is repeated ad nauseam it will not make it practically relevant or feasible. [HC]: Corollary 2 seems not valid since the Theorem on which Corollary 2 based is not valid. what we need is documentation to the extent possible of existing mp-tlv and framework for new tlv/sub-tlv/sub.. to describe intended behavior in case of mp-tlv of those. All in distributed fashion without gating it on a single include file ;-) gathering documentation about existing is laudable and could be attempted in an application draft if someone is willing (TonyL's statements about that are true however). mp-tlv draft should probably add that every new draft doing new tlv/sub-tlv has to provide a mp-tlv section then (and make sure that it does not break recursion of all including parent hierarchy in some way [i.e. it's of no use to say that a sub-tlv has mp-tlv capability if the partent doesn't since the parent cannot repeat and will never have space hence for more than one sub-tlv already due to length restrictons) [HC]: Some issues on the draft are raised in the LSR mailing list. all that has been repeated enough already and no matter of wishful thinking and ASCII text will shift this reality on the ground [HC]: More discussions, more understanding on MP-TLV and Big-TLV. -- tony On Tue, Dec 5, 2023 at 8:11 AM Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: Folks – The term “backwards compatibility” is getting abused here. What does “backwards compatibility” mean in the context of a routing protocol like IS-IS? It means that protocol extensions can be advertised and safely used in the presence of legacy nodes (which do not understand the new advertisements). Neither MP nor Big-TLV are backwards compatible. The authors of MP draft do not claim it is backwards compatible. The authors of Big-TLV claim it is “backwards compatible” – but this is a false statement. Any attempt to use Big-TLV advertisements in the presence of legacy nodes will result in inconsistent and potentially dangerous behavior. Big-TLV authors like to say “you can send Big-TLV but not use it until all nodes support it” – but this does meet the criteria for backwards compatibility. If Big-TLV were “backwards compatible” there would be no need for a capability advertisement to determine when it is safe to use the advertisements. Les From: li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> <li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>> Sent: Monday, December 4, 2023 10:35 PM To: Huaimo Chen <huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>>; Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Tony Li <tony...@tony.li<mailto:tony...@tony.li>>; Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Cc: Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: Re: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Hello All, It seems Big-TLV is backward compatible. Backward compatible is an important point that should be considered when we introduce new features in a protocol, especially the widely used protocols like ISIS, BGP etc. ________________________________ Best Regards, Zhenqiang Li China Mobile li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> From: Huaimo Chen<mailto:huaimo.c...@futurewei.com> Date: 2023-12-04 21:57 To: Les Ginsberg (ginsberg)<mailto:ginsberg=40cisco....@dmarc.ietf.org>; Tony Li<mailto:tony...@tony.li>; Linda Dunbar<mailto:linda.dun...@futurewei.com> CC: Yingzhen Qu<mailto:yingzhen.i...@gmail.com>; draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>; lsr<mailto:lsr@ietf.org> Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Hi Les, My responses are inline below with [HC]. Best Regards, Huaimo Linda – When we have polarized positions (for whatever reasons), coming to consensus is often difficult. Each side tends to dismiss the arguments of the other – sometimes regardless of merit. So, maybe the following won’t help – but I am going to give it a try. Point #1: There are existing TLVs for which MP behavior was explicitly stated in existing RFCs and there are already many deployments that conform to those RFCs (see Introduction of MP draft for a list). If we choose to use a different encoding to support > 255 bytes for other codepoints, this both complicates implementations and confuses the definition of new protocol extensions. When defining a new codepoint should I choose MP or should I choose a different encoding? And what criteria can be used to make this choice a sensible one? And since MP is already REQUIRED for those TLVs where it was explicitly defined, we will always have to support that – at least for some codepoints. [HC]: When Big-TLV is used for a TLV > 255, it does not affect the existing MP-TLV that has been used for another TLV > 255. When defining a new codepoint for a new TLV, it seems better to choose Big-TLV if backward compatibility is needed for the new TLV since Big-TLV is backward compatible. I have explained it (i.e. ,“Big-TLV is backward compatible”) in detail. In addition, some other people indicate it in the LSR mailing list. Point #2: MP for IS-Neighbor/Prefix Reachability TLVs has already been implemented by multiple vendors, tested in both partial deployment and full deployment scenarios. We know that it works and we know what the problems are in partial deployment. This cannot be said for new alternatives. With due respect to Huaimo, he tends to characterize the implementation problems to be solved for Big-TLV as “easy to resolve” but given the absence of implementation I think this is an overly optimistic and somewhat naïve POV. (No offense intended) [HC]: It seems that the implementation of an idea/solution in a draft is not required by LSR WG for the draft to be adopted, or even for the draft to become RFC. Point #3: As documented in the IANA section of the MP draft, the problem extends to sub-TLVs of top level TLVs as well. It is then not as simple as reserving one encap TLV to handle the top-level TLV case. We also have to have a solution when a sub-TLV requires more than 255 bytes. MP solves this without additional changes. Big-TLV has yet to discuss this. [HC]: It seems that MP-TLV has to discuss this. Assume: a TLV (e.g., TLV 1) > 255 and its sub-TLV > 255, there are MP-TLVs (e.g., MP-TLV 1 and MP-TLV 2) for the TLV and MP-TLVs (e.g., MP-TLV 3 and MP-TLV 4) for the sub-TLV. All these MP-TLVs are TLVs. If there is another TLV (e.g., TLV 2) > 255 and its sub-TLV > 255 and all these sub-TLVs (i.e., the sub-TLV of TLV 1 and the sub-TLV of TLV 2) have the same type and there are MP-TLVs (e.g., MP-TLV 5, MP-TLV 6) for TLV 2 and MP-TLVs (e.g., MP-TLV 7, MP-TLV 8) for the sub-TLV (of TLV 2) > 255, how do you handle this case? How do you map MP-TLVs (e.g., MP-TLV 3, 4, 7, 8) for the same type of the sub-TLVs to their TLVs (e.g., TLV 1, 2)? If Big-TLV actually solved the partial deployment case, we would have a motivation to look at it more seriously. But it does not. It has the same issue with partial deployment that MP does. So for me, there is no value add to Big-TLV – and it does require additional implementation work – not all of which has even been defined yet. [HC]: Big-TLV actually solved the partial deployment case. I have explained this in detail. In addition, some other people indicate that Big-TLV is backward compatible in the LSR mailing list. It isn’t better – it is just different – and comes with additional implementation costs. [HC]: Big-TLV is better as I have explained in detail. Les From: Tony Li <tony1ath...@gmail.com<mailto:tony1ath...@gmail.com>> On Behalf Of Tony Li Sent: Friday, December 1, 2023 2:44 PM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Cc: Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023) Hi Linda, * Suppose the information to be carried by the Extended IS Reachability (type 22) (in Example 4.1) is larger than 255. Does it mean the recipient will receive 2 TLVs (both with the Type 22) in one LSA? For legacy routers, the second TLV (Type =22) might overwrite the first TLV. Yes, a legacy implementation may well have bugs. The proposal is to fix that: expect MP-TLVs. [Linda] Are you saying only the legacy implementation with bugs will be confused with two TLVs with the same Type in in one LSA? No. All implementations have bugs. This is reality. Implementations that do not understand MP-TLV may be confused. Correct implementations of MP-TLV support will not be confused. * Isn’t it more straightforward to have a new TYPE value for carrying the extra information beyond the 255 bytes? So, the legacy routers can ignore the TLVs with the unrecognized types. You could do that, but code points are not free. We certainly cannot afford another code point for each existing code point. Using just one code point is less than helpful: it forces us to aggregate information that has no business being aggregated. Ignoring information is a non-starter because it makes partial deployments fatal: some of the domain operates with some information and some of the domain operates with different information. [Linda] Why not consider having just one additional TYPE code with sub-types to indicate which original TLVs the value should be appended to? We have considered it. See all of Les’ emails for why it’s a bad idea. If it helps simplify this debate: we know that you work for Futurewei/Huawei and that the discussion has polarized into your Big-TLV faction vs. everyone else. Repetition of previously made points add zero value to the discussion. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
