All, I am actually finding this capability useful. If for nothing else then to help the operator to see what is going on in the area. On any node simple show command will clearly show who is willing and capable to receive MP-TLVs and who is not.
Analogy to including hostnames Tony brought here as an example is spot on and along the same lines. Of course how node uses that info could be discussed further. I would also not object to put that capability into a separate document. Thx, R. On Thu, Aug 25, 2022 at 6:06 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
