Tony P – You say:
<snip> What you say however is valid in the sense that we have to give thought to the fact that we do not want change on a single fragment block a previous change on a fragment if both are not related and never will. <end snip> We agree on this. So… you obviously are enthused about the proposal in your draft – I am not. But it seems we agree that the current state of the proposal at best incomplete (yeah – I know – it’s only V0). So instead of arguing with each other, I say I will wait until you have a more mature proposal. For your part, please don’t try to get me to agree with a proposal which (at least currently) has significant flaws. Les From: Tony Przygienda <[email protected]> Sent: Wednesday, July 15, 2026 2:37 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Tony Li <[email protected]>; Hegde, Shraddha <[email protected]>; [email protected]; [email protected] Subject: Re: [Lsr] New draft on Originator Sequence Number Checksum inline On Wed, Jul 15, 2026 at 7:39 AM Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: Tony – I agree with what you say below, but... In a perfect (distributed) world all nodes in the network would receive all LSP updates within a single "SPF interval" and trigger an SPF at the "same time". But we cannot guarantee that will happen. OSNC is trying to mitigate the consequences of a distributed network by trying to guarantee that no node in the network triggers an SPF until it has received all of the LSPs in a single "batch" as defined by the originator. But you still can't guarantee that the batch will arrive at every node at the "same time". And what is the definition of a “batch”. You cannot limit a batch simply to cases where you move a single TLV. To do so would require you to delay any other updates until you were “certain” that the TLV move had been processed network-wide – which you have no way to determine. Consider Node A which has generated 10 LSPs - and updates two of them (quickly) in the following order: A.00-2 includes an update to a prefix admin tag (minimal impact on convergence) A.00-4 includes a new adjacency (significant impact on convergence) NOTE: Does not matter whether you treat this as two different batches (different OSNC in each LSP) or as one batch (same OSNC in both LSPs). Nodes B and C are multiple hops away from Node A - potentially on different flooding paths. We have the following possible combinations: B supports OSNC - C does not. [B(OSNC) C] B and C support OSNC [B(OSNC) C(OSNC)] Neither B nor C supports OSNC [B C] (AKA legacy) Case 0: A.00-2 and A.00-4 arrive at B and C at the "same time". All combinations behave the same Case 1: A.00-4 arrives at B and C at the "same time" but A.00-2 is delayed in arriving at both nodes. [B(OSNC) C] Node C Converges faster than Node B [B(OSNC) C(OSNC)] Both nodes delay convergence [B C] Both nodes converge quickly Conclusion: OSNC has not helped. Partial deployment makes things worse it really depends what you define as "convergence". if you consider computation triggered with anything that arrived as convergence generating any kind of results then it's not "convergence", it's possibly just random stuff firing on inconsistent view of topology when fragments interdepend, consider fragment#1: slides adjacency out fragment#2: slides same adjacency in Node A gets 1 but not 2 and computes, link is down Node B gets 2 but not 1 and computes, same link is visible twice if that's convergence then it's for OSPF for A a link flap and for node B seeing actually LSP/TLV it should throw away since it's incorrect encoding of the adjacency So, yes, it's really fast but neither good nor cheap since the resulting effect can lead to multi-seconds (or worse) massive reconvergence of things that depend on IGP's view of topology. And it does today in our experience. if you want fast you have it already today, but unless I see a solution that makes stuff less "fast" but good and cheap by preventing spurious flaps (and other effects when interdependent fragments don't arrive as a "batch" or "transaction" as better word) we simply disagree what "convergence" is and as I said, I don't think we will make any further real progress in this thread What you say however is valid in the sense that we have to give thought to the fact that we do not want change on a single fragment block a previous change on a fragment if both are not related and never will. I can imagine multiple ways to achieve that in the encoding but I'm more than happy to hear ideas from others first. However, the discussion gets tricky quickly since a change in a single fragment _may_ have implication on change in single another fragment at a later date, as quick example fragment #0@1: capability X not supported, single fragment changed, nothing here fragment #0@2: capability X supported, single fragment changed, nothing here fragment #2@1: adding some TLVs that are valid only _if_ capability X is supported if fragment#2@1 shows up but #1@2 is not there yet the TLV makes no sense at best, causes damage at worst. Yes, ultimately e'thing will settle assuming flooding works fine but in the meantime interesting effects can arise we have no solution for today -- tony Case 2: A.00-2 arrives at B and C at the "same time" but A.00-4 is delayed in arriving at node B only. {B(OSNC) C] Node C Converges faster than Node B [B(OSNC) C(OSNC)] Both nodes delay convergence {B C] Both nodes converge quickly Conclusion: OSNC has not helped. Partial deployment makes things worse No doubt there are other examples – some of which may be more favorable to OSNC - but the point here is that there are cases where partial deployment can make things worse. Adding complexity and not being able to guarantee improved results is not a winning combination. Les From: Tony Li <[email protected]<mailto:[email protected]>> On Behalf Of Tony Li Sent: Tuesday, July 14, 2026 5:02 PM To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Cc: Tony Przygienda <[email protected]<mailto:[email protected]>>; Hegde, Shraddha <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Lsr] New draft on Originator Sequence Number Checksum Hi Les, \Well no. If some nodes in the network do NOT use LSPs they receive for several seconds while other nodes use them immediately this will certainly negatively impact convergence. That has been clearly demonstrated in real networks in the past. I don’t see how you can safely enable what you propose unless all nodes in the area support it. I’m not following this line of reasoning. Today, thanks to the vagaries of flooding, different segments arrive at different times. There’s not a lot that the transmitter can do to ensure that the intermediate nodes do The Right Thing, whatever that may be. Different implementations will SPF at different times, creating inconsistent results. In other words, things are not safe today. The whole point of this exercise is to try to help everyone align on convergence. What we’d really like is for everything to flood and then somehow magically everyone SPFs at the exact same time. Unfortunately, this only happens at Hogwarts. The proposal on the table is to convey some amount of temporal dependency so that receivers can make a slightly more intelligent decision about when to SPF. I’m not seeing how more information makes the situation worse. Cheers, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
