Speaking as WG member: I agree with Tony. In this case, the “legacy” routers are, in fact, the routers supporting mp-tlv and the draft is merely documenting the behavior as well as adding informational signaling and configuration disablement.
Thanks, Acee > On Dec 5, 2023, at 6:37 AM, Tony Przygienda <[email protected]> wrote: > > 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 > > Corollary I: a flag day on such networks is NOT possible unless it's > seamlessly flipping to something new while disabling old > > 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. > > 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) > > all that has been repeated enough already and no matter of wishful thinking > and ASCII text will shift this reality on the ground > > -- tony > > On Tue, Dec 5, 2023 at 8:11 AM Les Ginsberg (ginsberg) > <[email protected]> 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: [email protected] <[email protected]> > Sent: Monday, December 4, 2023 10:35 PM > To: Huaimo Chen <[email protected]>; Les Ginsberg (ginsberg) > <[email protected]>; Tony Li <[email protected]>; Linda Dunbar > <[email protected]> > Cc: Yingzhen Qu <[email protected]>; > [email protected]; lsr <[email protected]> > 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 > [email protected] > From: Huaimo Chen > Date: 2023-12-04 21:57 > To: Les Ginsberg (ginsberg); Tony Li; Linda Dunbar > CC: Yingzhen Qu; [email protected]; lsr > 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 <[email protected]> On Behalf Of Tony Li > Sent: Friday, December 1, 2023 2:44 PM > To: Linda Dunbar <[email protected]> > Cc: Yingzhen Qu <[email protected]>; > [email protected]; lsr <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
