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

Reply via email to