Les <http://www.verizon.com/>
*Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347* On Thu, Dec 7, 2023 at 1:07 PM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > Huaimo – > > > > There are some things on which people can legitimately have different > opinions – the meaning of backwards compatibility is not one of them. > > > > Your position seems to be that so long as I introduce a capability > advertisement that controls whether a new advertisement is used when > received that I can declare it “backwards compatible”. By that definition > everything is “backwards compatible”. > > This makes the term “backwards compatibility” meaningless. > > > > This POV is neither useful nor sensible. > Gyan> > If we made the sending of MP TLV a MUST it would provide the similar type of backwards compatibility as BIG TLV with the capability TLV. Advantage of doing it inside the protocol is that we eliminate configuration of enable/disable state default variations and are able to ensue backwards compatibility. So it’s similar but not the same. I guess MP TLV could introduce a similar capability TLV for backwards compatibility and then the backwards compatibility would be identical. > > NEW: It is REQUIRED that implementations which support the sending of > MP-TLVs provide configuration controls to enable/disable generation of > MP-TLVs. > > > > > > *From:* Huaimo Chen <[email protected]> > *Sent:* Thursday, December 7, 2023 6:07 AM > *To:* Les Ginsberg (ginsberg) <[email protected]>; > [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) > > > > Hi Les, > > > > My responses are inline below with [HC]. > > > > Best Regards, > > Huaimo > > > > 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. > > *[HC]: Big-TLV is backwards compatible according to your definition of > “backwards compatibility”.* > > > > 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. > > *[HC]: Using Big-TLV advertisements in the presence of legacy nodes will > not result in any inconsistent or potentially dangerous behavior. I have > explained this in detail in the LSR mailing list. * > > > > 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. > > *[HC]: Big-TLV capability advertisement is a part of the Big-TLV > solution/extension.* > > *Capability advertisements seem used for backwards compatibility by other > protocols. Is there any restriction in IS-IS that does not allow any IS-IS > extension to use a capability advertisement for backwards compatibility?* > > *Using a capability for Big-TLV backwards compatibility is suggested by > Chris in the LSR mailing list.* > > *https://mailarchive.ietf.org/arch/msg/lsr/cXyGnSJSdEQR9BVxykXhiuUWtgE/* > <https://mailarchive.ietf.org/arch/msg/lsr/cXyGnSJSdEQR9BVxykXhiuUWtgE/> > > > > Les > > > > > > > > *From:* Les Ginsberg (ginsberg) <[email protected]> > *Sent:* Tuesday, December 5, 2023 2:11 AM > *To:* [email protected]; Huaimo Chen <[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) > > > > 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 <[email protected]> > > *Date:* 2023-12-04 21:57 > > *To:* 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: [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
