I agree that retaining the option and using it for debugging would be a good thing. However, given that multi-part TLVs are already in use, the absence of the advertisement doesn’t necessarily mean that the IS-IS router doesn’t support multi-part TLVs. Rather, it presence would mean that beyond a shadow of a doubt, they are supported.
Similarly, for backward compatibility, an IS-IS router would not be required to strictly enforce the requirement that all IS-IS routers within the scope of the Multi-Part TLV advertise the capability. Thanks, Acee From: Lsr <lsr-boun...@ietf.org> on behalf of Robert Raszuk <rob...@raszuk.net> Date: Thursday, August 25, 2022 at 12:18 PM To: "Acee Lindem (acee)" <acee=40cisco....@dmarc.ietf.org> Cc: Gunter Van de Velde <gunter.van_de_ve...@nokia.com>, Tony Li <tony...@tony.li>, lsr <lsr@ietf.org> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt 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<mailto: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<mailto:lsr-boun...@ietf.org> on behalf of gunter.van_de_ve...@nokia.com<mailto:gunter.van_de_ve...@nokia.com>> wrote: Inline: GV> From: Tony Li <tony1ath...@gmail.com<mailto: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<mailto:gunter.van_de_ve...@nokia.com>> Cc: lsr <lsr@ietf.org<mailto: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<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
