Huaimo, first, I fail to see how 8202 has anything to do with this discussion.
Did you try to implement and deploy 5311 in real networks and seen the operational impact ? and are you suggesting that we need to have that deployed as precondition for big-tlv idea ? 'nuff said ... -- tony On Thu, Dec 7, 2023 at 3:12 PM Huaimo Chen <huaimo.c...@futurewei.com> wrote: > Hi Tony, > > > > My responses are inline below with [HC]. > > > > Best Regards, > > Huaimo > > > > 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 > > > > *[HC]: We have encoded TLVs > 255 in two different ways (or say, deployed > in parallel) already. * > > *RFC 8202 specifies one way for IID-TLV (TLV 7) > 255 on page 4-6 (quoted > some text below for your convenience). * > > “A single IID-TLV will support advertisement of up to 126 ITIDs. If > > multiple IID-TLVs are present in an IIH PDU, the supported set of > > ITIDs is the union of all ITIDs present in all IID-TLVs.” > > *RFC5311 defines another way for extended IS reachability TLV 22 and > MT-ISN TLV 222 > 255, in which two new TLVs: IS Neighbor Attribute TLV 23 > and MT IS Neighbor Attribute TLV 223, are defined. Some texts from RFC 5311 > are quoted below for your convenience.* > > “If the attribute information does not conflict, it MUST be > > considered additive.” > > “In cases where information about the same neighbor/link/attribute > > appears in both TLV 22 and TLV 23 (or TLV 222 and TLV 223 for the > > same MTID) then the information in TLV 22 (or TLV 222) MUST be used > > and the information in TLV 23 (or TLV 223) MUST be ignored.” > > “Utilization of the new TLVs for neighbor attribute information would > > provide additional benefits that include: > > Easier support for a set of TE information associated with a single > > link that exceeds the 255-byte TLV limit by allowing the > > interpretation of multiple TLVs to be considered additive rather > > than mutually exclusive.” > > *These two different ways do not affect each other. There is no flip over. * > > *A new way for TLVs > 255 will not affect any existing way. There will not be > any flip over.* > > > > > > Corollary I: a flag day on such networks is NOT possible unless it's > seamlessly flipping to something new while disabling old > > > > *[HC]: Corollary 1 seems not valid since the Theorem on which Corollary 1 > based is not valid. The Theorem is 1) and 2) above. The Theorem is not > valid (or true) since 2) is false.* > > > > 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. > > > > *[HC]:* *Corollary 2 seems not valid since the Theorem on which Corollary > 2 based is not valid.* > > > > 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) > > *[HC]: Some issues on the draft are raised in the LSR mailing list.* > > > > all that has been repeated enough already and no matter of wishful > thinking and ASCII text will shift this reality on the ground > > *[HC]: More discussions, more understanding on MP-TLV and Big-TLV.* > > > > -- tony > > > > On Tue, Dec 5, 2023 at 8:11 AM Les Ginsberg (ginsberg) <ginsberg= > 40cisco....@dmarc.ietf.org> 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:* li_zhenqi...@hotmail.com <li_zhenqi...@hotmail.com> > *Sent:* Monday, December 4, 2023 10:35 PM > *To:* Huaimo Chen <huaimo.c...@futurewei.com>; Les Ginsberg (ginsberg) < > ginsb...@cisco.com>; Tony Li <tony...@tony.li>; 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: 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 > > li_zhenqi...@hotmail.com > > > > *From:* Huaimo Chen <huaimo.c...@futurewei.com> > > *Date:* 2023-12-04 21:57 > > *To:* Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; Tony > Li <tony...@tony.li>; 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 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 <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 > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
