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
