On Wed, Jul 15, 2026 at 5:35 PM Les Ginsberg (ginsberg) <[email protected]> wrote:
> 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. > Les, ack. But as I described, this is not as obvious as it seems. I don't want to clutter this thread further with examples how what looks initially like a "single fragment" change only becomes "all those fragments must be in sync because this fragment may be present in different versions". This leads then to an "interdependency matrix" between TLVs (and ultimately fragments since the TLVs can shift) which could be quite a hell on wheels to implement and debug rather than fire of OSNC with every change. We already tossed internally ideas like "what if we encode _how_ many fragments changed with this OSNC and number is 1 then if this is just the last OGID + 1 we see we don't need to do anything" 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, I don't think I forced you to "agree" to anything except maybe that there is a real operational problem we face and gave an example of (and things get worse with e'thing being added as garbage truck'ing into IGPs) and this is the best starting point to work on it we see given the trade-off envelope here bar any better suggestion and/or productive contribution we'd welcome of course. If you don't "agree" on the fact there is an operational problem that we see in reality then we are in different universes and we can let it rest at that. And if you're not willing to consider anything but perfect we can of course always implement and deploy it first and once it works in deployment publish a draft mildly suggesting a codepoint that's in the field already ... Been known to happen as you know ;-) --- tony > > > 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]> 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]> *On Behalf Of *Tony Li > *Sent:* Tuesday, July 14, 2026 5:02 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Tony Przygienda <[email protected]>; Hegde, Shraddha < > [email protected]>; [email protected]; [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]
