On Tue, Jul 14, 2026 at 12:35 AM Tony Przygienda <[email protected]> wrote:
> > > On Mon, Jul 13, 2026 at 7:11 PM Les Ginsberg (ginsberg) < > [email protected]> wrote: > >> Tony – >> >> >> >> No “mud-slinging” from me. >> > > Les, ack > > >> >> >> But as the owner of an implementation – and having chatted about your >> proposal with some colleagues – it isn’t obvious to me why such issues >> cannot be addressed at the originator (and in fact are already addressed). >> >> Perhaps I am missing something – which is why I ask that you provide some >> detailed examples (not just the high level abstract that you have provided >> so far). >> > > ack. the proposal was published last minute as initial draft. consider it > as such. As I said, we do have a "much better" (in some metrics) solution > but we judged it too complex in terms of practical deployment (for now). I > argued for the OGID last minute as I said, you found it pretty quickly ;-) > However, beyond that, anything you start to consider becomes really complex > IME since it starts to build a "perfect transaction" algebra. But I'm more > than interested in your suggestions of something relatively simple > that works better than the proposal. I would suggest to look up the theory > of "consistent cut snapshots" in distributed systems since this is > basically the problem we're tackling (modulo colored channel we are > thankfully spared, especially since flooding is anything but FIFO ;-) and > is a well understood and solved problem in distributed databases since long > time. But we do not have space for proper vector clock algebra in the > encoding and hence the "we can only do a (good enough)" approximation here > IMO rather than the full enchilada that would deliver a "perfect" solution. > Les, I realized having thought about the problem for quite a bit I ended up bits loose with my language here. So to be more precise: "vector clock" normally means "vector of single clocks of different distributed systems". However, this problem is really "congruent" once we consider each fragment of a node a "clock" with sequence number ticking and a consistent cut is where a remote node receives a "consistent cut" of fragments (while there are no involved asynchronous channels within a node itself producing the vector). You already alured to it with the 6/4 problem, so to expand as an example # is fragment nr. @ is seqnr, all within a single node #1 @ 1 | #2 @ 1 | transaction 1 #3 @ 1 #4 @ 1 | transaction 2 -> which means it will encode transaction 1 clocks for #1 and #2 within it #1 @ 2 | transaction 3 -> now the "vector clock is" [ #1@2, #2@1, #3@1, #4@1 ] so what we are really sending are the full vectors "mashed together as a hash" that represent consistent cuts. The space saving "mashing" prevents us from understanding what are the clock values or even the changed fragments we need or even omit the clocks not changed between transactions (SK techniques) but given the very small encoding space it seems to me it's about as well as we can do. A better approach would allow us to e.g. know that "we miss fragment #4" to have a consistent cut and prioritize the handling somehow etc but alas, vectors are not small (and if you think further you will start to derive the mathematically densest compression of differential vector clock here or think about "catalogs" but things get complex quickly or start to generate double volume of flooding in certain approaches). I hope that clarifies things a bit > >> >> >> Changing the fundamentals of flooding is far from a trivial undertaking. >> I would not want to invest in that until it is clear that it is needed. >> > > no qualms here. > and here my English was slippery as well. When I said "no qualms" it was not "I'm more than happy to hack flooding anytime", it was more agreeing with you that any flooding behavior change needs very serious discussion, whether change is optional or not. > No'one was claiming this is the table from the mountain with the perfect > solution cast in stone. So consider it a starting point and do argument > away. > > "link flapping" we see despite all the implementation techniques (and > more) is real and visible (although not very common) and it can cause > noticeable disturbances as you know from regular link flaps. This is grave > enough. Further "examples" will IMO contribute nothing except red herring > arguments about 2ndary effects. The problem is always the same. multiple > TLVs sprinkled around changing independently or something sliding into the > next fragment due to sliding or re-packing. Everything after that is 2nd > order computation on such inconsistent cuts and triggers lots of > detrimental stuff further down the pipeline of instrumentation relying on > IGPs view of topology state. > > -- tony > > >> >> >> Les >> >> >> >> >> >> *From:* Tony Przygienda <[email protected]> >> *Sent:* Monday, July 13, 2026 9:47 AM >> *To:* [email protected] >> *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Shraddha Hegde < >> [email protected]>; [email protected] >> *Subject:* Re: [Lsr] Re: New draft on Originator Sequence Number Checksum >> >> >> >> >> >> >> >> On Mon, Jul 13, 2026 at 5:51 PM [email protected] <[email protected]> >> wrote: >> >> comments inline >> >> >> >> Sent from my iPhone >> >> >> >> On Jul 13, 2026, at 11:08 AM, Les Ginsberg (ginsberg) <ginsberg= >> [email protected]> wrote: >> >> >> >> Tony/Shraddha – >> >> >> >> Thanx for the replies. >> >> >> >> As I see it, fundamentally you are trying to change the current flooding >> model – which is per LSP – to be “per LSP Batch”. >> >> Not sure I want to go down that road…and there are certainly strategies >> associated with LSP Generation that can minimize the occurrence of this >> problem. >> >> >> >> I think a better way to start this discussion would be for you folks to >> go into more detail on the problematic cases and why they cannot be >> addressed at the source. >> >> I would hope/ask that you focus the discussion there to start with – >> rather than starting with a solution which even you folks admit needs >> significantly more work. >> >> >> >> JD: I agree. This is the way the process is supposed to work. >> Presenting an ill-considered solution and saying “voila” considered bad >> form. >> >> >> >> @JD: the 'ill-considered' seems simply a bit of mud slinging given you >> probably don't know or think through all the likely problems encountered >> (although the ones Shraddha described are serious and for practical >> purposes detailed enough) and neither seem to have a better proposal to >> extend. >> >> >> >> Further, the problems we see otherwise can be all simply described as >> "either something slid in a fragment or two independent fragments changed >> with inter-dependent information" and only one arrived on flooding and then >> some piece of logic hanging of IGP like SPF acted on it and triggered >> spurious triggers. So if you know your RFCs, deploy IGPs at scale and think >> a bit you'll quickly see where we have it today already and how we have >> ongoing proliferation of e.g. link information being sprinkled in lots of >> TLVs on an ongoing basis which for all practical purposes end up depend on >> each other. And that's AFAIS is really enough in the context of the problem >> encountered. >> >> >> >> --- tony >> >> >> >> >> >> >> >> Thanks. >> >> >> >> Les >> >> >> >> >> >> *From:* Tony Przygienda <[email protected]> >> *Sent:* Monday, July 13, 2026 1:59 AM >> *To:* Hegde, Shraddha <[email protected]> >> *Cc:* Les Ginsberg (ginsberg) <[email protected]>; [email protected] >> *Subject:* Re: [Lsr] Re: New draft on Originator Sequence Number Checksum >> >> >> >> for 3. Les, thanks for comments. Despite having implemented (obviously) >> pretty much e'thing you mention and even more clever things to deal with >> the fragment movement we still encounter the problem in the field and hence >> propose this TLV. Some affected operators may chime in. We do not only see >> link flaps but other problems manifesting due to fragment shifting BTW. >> >> >> >> We have also a proposal dealing perfectly with the transaction order/no >> delay necessary etc but it's significantly more complex and we judged that >> this is the goldi locks between extreme complexity and something that >> should improve the situation noticeably from the current state. From the >> more complex proposal I suggested and we are discussing through possibly >> including the transaction ID which will solve your example as in >> >> >> >> fragment 4 -> transaction ID 1 >> >> fragment 6 -> transaction ID 2 >> >> >> >> so when 6 floods in first and then 4 the node knows that it has still to >> use the 6 to validate the checksum and 4 with ID 1 checksum does not >> matter. >> >> >> >> tricky part are of course reboots/attacks and so on and very high >> frequency fragments being regenerated for which the timer is the simplified >> heuristic since the complete solution is practically speaking much more >> complex than this draft >> >> >> >> -- tony >> >> >> >> On Mon, Jul 13, 2026 at 6:49 AM Hegde, Shraddha <shraddha.hegde= >> [email protected]> wrote: >> >> Hi Les, >> >> >> >> Thanks for detailed review and valuable comments. >> >> >> >> 1. This is a valid scenario and as per the current proposal there >> will be a delay in computing SPF , eventually the timeout will cause the >> SPF to be triggered. >> >> This delay is not desirable and the proposal can be improved to do >> better in this case. >> >> My thought is to indicate the fragment movement case in the TLV with a >> flag and let receiver apply delay only when needed. >> >> Will update draft once window opens. >> >> 2. I agree when there are unrelated changes to multiple LSPs the >> existing mechanisms should be good enough >> >> >> 3. I don't agree the current mechanisms are good enough to handle >> the fragment movement case. There are a number of new TLVs/sub-TLVs being >> proposed in IETF and every time a new feature is to be enabled in the >> network, operator has the risk that it might cause fragment movement and >> cause disruptions in the network. The sender deterministically knows the >> fragment movement got triggered and can do better to let other nodes >> gracefully handle it. >> >> >> >> Rgds >> >> Shraddha >> >> >> ------------------------------ >> >> *From:* Les Ginsberg (ginsberg) <[email protected]> >> *Sent:* Wednesday, July 8, 2026 5:33 AM >> *To:* Hegde, Shraddha <[email protected]>; [email protected] < >> [email protected]> >> *Subject:* RE: New draft on Originator Sequence Number Checksum >> >> >> >> Shraddha – >> >> >> >> Some questions/comments regarding this draft. >> >> >> >> 1)I am struggling to see how what you propose works in the following >> scenario. >> >> >> >> Node A currently has generated/flooded 10 LSPs at Level-1. >> >> At Time T0, it updates LSP A.00-04 , recomputes the OSNC – which is >> “1234” – and includes that in the new version of A.00-04 and floods the LSP. >> >> >> >> A short time later – say T0 + 20 ms - Node A now updates LSP.00-06 with >> information unrelated to the previous change to LSP #4. >> >> It recomputes the OSNC – which is now “5678” – and includes that in the >> new version of A.00-06 and floods that LSP. >> >> >> >> You cannot control the order in which the LSP updates are received as the >> LSPs are propagated through the area. >> >> >> >> Some nodes may receive LSPs in the following order: >> >> A.00-04(OSNC 1234) >> >> A.00-06(OSNC 5678) >> >> >> >> Nodes which try to validate their database against the received OSNC will >> succeed as they process each received LSP. >> >> >> >> But some nodes may receive LSPS in the following order: >> >> A.00-06(OSNC 5678) >> >> A.00-04(OSNC 1234) >> >> >> >> Nodes which receive the LSPs in this order will fail the OSNC validation. >> >> >> >> The problem here is that the receivers do not know the order in which the >> LSPs were generated. So any set of LSPs which were not part of an “atomic >> update” on the originator will have different OSNC values and receivers >> don’t know which one is the latest. >> >> >> >> How are you intending to address this problem?? >> >> >> >> 2)The problem you are trying to address (updates to a single object – >> such as a neighbor) which impact multiple LSPs is not the only case in >> which updates to multiple LSPs may occur. >> >> A node may (for example) add a new neighbor to one LSP and a new prefix >> to another LSP. There is far less motivation to treat these as an atomic >> update – yet you are imposing requirements on the receiver that these two >> unrelated updates cannot be processed by the receiver until/unless both are >> received. >> >> >> >> 3)The issue of movement of information about a single object is well >> known and was considered even in ISO 10589. Section 7.3.4.4 states: >> >> *“Once a particular adjacency has been assigned to a particular LSP >> Number, it is desirable that it not be moved to another LSP Number. This is >> because moving an adjacency from one LSP to another can cause temporary >> loss of connectivity to that system. This can occur if the new version of >> the LSP which originally contained information about the adjacency (which >> now does not contain that information) is propagated before the new version >> of the other LSP (which now contains the information about the adjacency).* >> >> *…* >> >> *If it is necessary to move an adjacency from one LSP to another, the >> SRMflags (see 7.3.15) for the two new LSPs shall be set as an atomic >> action.”* >> >> >> >> In addition, implementations have for many years included the capability >> to flood a limited number of LSPs “back-to-back” as a means of insuring >> that when other routers in the network trigger the Decision process, they >> would be more likely to have all the updated topology information. >> >> Also, implementations provide the ability to delay the start of the >> Decision process by a modest amount of time (e.g., 50 milliseconds) to >> allow time for multiple LSPs to be received before a new SPT is calculated. >> >> All of this has been demonstrated to reliably improve convergence. >> >> >> >> So, while the concern you raise regarding moving an object such as a >> neighbor from one LSP to another is legitimate, it has already been >> considered in existing implementations. >> >> >> >> Given the added complexity the draft’s solution imposes on receivers, the >> difficulties in dealing with cases when the order of receipt does not match >> the order of generation, and the significant potential for negatively >> impacting convergence – it is difficult to be enthused about this proposal. >> >> It seems to me to be an example where “striving for perfection is the >> enemy of the good”. >> >> >> >> Les >> >> >> >> >> >> *From:* Hegde, Shraddha <[email protected]> >> *Sent:* Monday, July 6, 2026 10:05 PM >> *To:* [email protected] >> *Subject:* [Lsr] New draft on Originator Sequence Number Checksum >> >> >> >> WG, >> >> >> >> A new draft is posted on Originator Sequence number >> >> >> >> >> >> >> >> The proposal defines a new TOP level TLV that carries checksum of LSP-ID, >> sequence number and size of all the self originated LSPs. This is to be >> used by the receiver to get the information about the senders database. Pls >> review details from the draft below >> >> >> >> https://datatracker.ietf.org/doc/draft-hegde-lsr-isis-osnc/ >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-isis-osnc/__;!!NpxR!jKnJ-5wj-zweoNDtMG8kZVwCP1dGlm2X1VJDpQULPfi9AxNixaFa45znEdKVp0w54EJC1KVHFS5y0HgMdufNTKoLohX_v_Vq$> >> >> >> >> Shraddha Hegde >> >> Distinguished Engineer >> >> *HPE Networking* >> >> E: [email protected] >> >> <image001.png> >> >> >> >> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
