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. 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) 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. 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. It isn’t better – it is just different – and comes with additional implementation costs. Les From: Tony Li <tony1ath...@gmail.com> On Behalf Of Tony Li Sent: Friday, December 1, 2023 2:44 PM To: Linda Dunbar <linda.dun...@futurewei.com> Cc: 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 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 https://www.ietf.org/mailman/listinfo/lsr
