Given the realities of deploying something like this I am all for advertisement of what I'll call here the "multi-TLV-compliance" flag (assuming we agree that capability implies a change in procedures on reception from other nodes which this draft does not). Being able to see that a customer network deployed something that is _not_ compliant with the RFC (even potentially) can save a lot of head scratching and ghost chasing given that nodes receiving multi-part-TLVs and not processing them correctly will exhibit most vexing behavior that is not observable on LSDB or any of the other tools we normally use.
=--- tony On Thu, Aug 25, 2022 at 6:07 PM Acee Lindem (acee) <acee= 40cisco....@dmarc.ietf.org> wrote: > Speaking as WG member: > > Hi Gunder, Tony, Les, > > I'm also not a fan of the Multi-Part TLV Capability flag. While the intent > of the draft is to encourage multi-part TLV advertisement and usage, the > addition of this flag and the requirement for advertisement will most > likely have the opposite effect. Given that IS-IS implementations are > already advertising multi-part TLVs but none are advertising the proposed > capability flag, implementation of the draft as currently written would > inhibit Multi-Part TLV usage and be a step backwards. Of course, we know > implementations that are already advertising these multi-part TLVs will > most likely ignore the recommendation and continue to advertise them even > when not all IS-IS routers within the scope of the Multi-Part TLV advertise > the capability. > > Rather, I propose that the draft eliminates the capability flag and > introduces a recommended configuration parameter that would allow > Multi-Part TLVs to be suppressed. The recommended default would be FALSE. > This would provide an out if these Multi-Part TLVs did, in fact, have dire > consequences. > > Thanks, > Acee > > On 8/25/22, 6:53 AM, "Lsr on behalf of Van De Velde, Gunter (Nokia - > BE/Antwerp)" <lsr-boun...@ietf.org on behalf of > gunter.van_de_ve...@nokia.com> wrote: > > Inline: GV> > > From: Tony Li <tony1ath...@gmail.com> On Behalf Of Tony Li > Sent: Wednesday, August 24, 2022 5:26 PM > To: Van De Velde, Gunter (Nokia - BE/Antwerp) < > gunter.van_de_ve...@nokia.com> > Cc: lsr <lsr@ietf.org> > Subject: Re: [Lsr] New Version Notification for > draft-pkaneria-lsr-multi-tlv-01.txt > > > Hi Gunter, > > I am having troubles understanding the value of ‘The Multi-part TLV > Capability’ flag. > What would break if ‘Multi-part TLV Capability’ flag would not exist? > > > A system that supported MP-TLVs would not be able to determine that > there were other systems in the area that did not support MP-TLVs. The > system might then advertise MP-TLVs and they would be misinterpreted or > cause system crashes in the systems that did not support them. > > GV> crashes? I really hope that is not happening. > GV> When a legacy router receives MP-TLVs from another system and > legacy router has no support for handling MP-TLV, then yes, things get > misinterpreted. There is nothing wrong with that, is there? Do you have an > example where things go wrong? > > If we want to introduce MP-TLVs, that change would warrant the > existence of the flag. > > GV> I am not convinced yet how a MP-TLV catch-all flag would make ISIS > behave better > > I dispute that a binary flag warrants the word ‘complexity’. > > GV> living without binary flag is simpler and less complex then > dealing with a binary flag. (i.e. what, when, how, why, who sets this flag?) > > Note: thoughts about the flag: What if a system by accident sends > flip-flopping (set/unset/set/unset/etc) of this flag? > > Then other systems might misinterpret the results and generate > inconsistent TLVs. That would be bad. > > GV> correct, no good at all. > > What if an advertising system support multi-tlv for TLV ‘A’ but not > for TLV ‘B’? > > We are not allowing that level of granularity. A system that is going > to support MP-TLVs should take care to operate correctly for ALL TLVs > before advertising that it supports them. > > GV> I suspect that 'ALL TLVs' is a reference to ALL TLVs supported by > the local system. This means that e.g. when new TLVs would be supported > after a system upgrade, that the operator has to be aware and correct the > flag during each single upgrade. > > GV> Unfortunately I remain to have troubles understanding the value > "Multi-part TLV Capability’ flag brings to an ISIS network. > * Without flag it is indeed uncertain if area wide mp-tlv is > supported (sub-optimal). > * but with catch all MP-TLV flag I am not sure we improve ISIS > operation: > ** Who guarantees that the flag is set correctly on all systems at > all times > ** Maybe all systems falls back to advertise single TLV because > another (legacy?) system advertise a wrong flag (sub-optimal) > ** Legacy system with MP-TLV support gets upgraded and now supports > additional TLVs but not with MP-TLV... ?manual intervention? (sub-optimal) > ** what, when, how, why, who sets the MP-TLV flag? What with > flapping of MP-TLV flag (undefined) > > G/ > > 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 >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
