Tony,
Questions are inserted below: Linda From: Tony Li <tony1ath...@gmail.com> On Behalf Of Tony Li Sent: Friday, December 1, 2023 2:21 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, I have the following concerns about the approach proposed by this draft: * 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? * 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? This would not be an improvement. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
