On Fri, Jul 18, 2025 at 7:30 PM Les Ginsberg (ginsberg) <[email protected]> wrote:
> Please see inline. > > > > *From:* Tony Przygienda <[email protected]> > *Sent:* Friday, July 18, 2025 2:24 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* [email protected]; lsr <[email protected]> > *Subject:* Re: [Lsr] Review comments for > draft-prz-lsr-hierarchical-snps-00: Detailed comments > > > > Inline > > > > On 17 Jul 2025, at 23:15, Les Ginsberg (ginsberg) < > [email protected]> wrote: > > > > Here are some more detailed comments – many of which are editorial. > > > > Proceeding in section order through the document. > > > > *Introduction* > > > > It seems to me that the mechanisms defined here are potentially applicable > to PSNPs as well as CSNPs - but you do not discuss this. Is this > intentional? > > > > The use of the term "level" in regards to the merkle hash is a bit > confusing given that we have a protocol which supports multiple levels. > Perhaps replace "level" with "ordinal"?? (Open to other suggestions) > > > > > > Yeah, I agree, a synonym for level would be better. Ordinal is bit stilted > ;-) [though stilted language is normally my specialty;-). What about > “rank” or “grade”, “degree” ? > > > > *[LES:] “degree” works for me* > ok, will adapt > > > > > *Section 2 Suggested Dynamic Leaf Partitioning* > > > > Paragraph 2 has an error: > > > > *"LSP ID + Fragment + Seq# + CSUM + Lifetime length which amounts to 8 + 2 > + 2 + 2 = 14 bytes each"* > > > > should be > > > > *"LSP ID + Fragment + Seq# + CSUM + Lifetime length which amounts to 8 + 2 > + 4 + 2 = 16 bytes each"* > > > > i.e., the Seq# is 4 bytes in length > > > > > > Ah, perfect catch > > > > As to previous note, observe that CSUM e.g. is NOT guaranteed either to be > unique so there is the corner, corner case in the protocol where some node > reboots, issues same LSP with same sequence# but different content _but_ > checksum ends up matching > > > > If you consider that “fine” then there is the discussion whether HSNP > should just hash the CSUMs ;-) but I’d think that would start to be a > bit of a lax approach ;-() > > *[LES:] See my response to Tony Li. I think the consequences of duplicate > checksums are much less severe.* > yes, the more stuff covers the riskier for sure. see my other response > > > > > *Definition of the hashes* > > > > You describe an encoding of: > > > > *Start ID (7 bytes)* > > *End ID (7 bytes)* > > *Hash (4 bytes)* > > *Total 18 bytes* > > > > This suggests two things: > > > > - The ID range is meant to include all LSPs generated by the nodes > including pseudo-node LSPs > - The range is inclusive > > > > But the actual encoding shown in Figure 2 puts "00" into the 7th ID byte > (pseudo-node ID) which seems very odd. It suggests either that you do not > intend to include pseudo-node LSPs in your compression or that you are > deviating from existing representation of the range (in existing CSNPs) by > having the end ID identify only the last node - not the actual last LSPID > that is included. > > > > Actaully the intention would be to go to 6 bytes here and include all the > pseudo nodes in the range of the node given that there is so little info in > pseudo nodes. > > > > You think that’s a reasonable idea ? > > > > > > There is indeed virtually no discussion of pseudo-node LSPs in the > document. > > > > My intuition suggests that a more accurate representation of the range > would use only the 6 bytes of systemid and that there is no need to include > the pseudo-node id as it is being ignored anyway i.e., > > > > *+--------------------------------------------+* > > *| Start System ID: 1000.0000.008E.00 |* > > *+--------------------------------------------+* > > *| End System ID: 1000.0000.00A0.00 |* > > *+--------------------------------------------+* > > > > actually is meant to indicate all LSPs (including pseudo-node LSPs) > generated > > by the system ids in the range of (1000.0000.008E - 1000.0000.00A0) > (inclusive) - in which case: > > > > *+--------------------------------------------+* > > *| Start System ID: 1000.0000.008E |* > > *+--------------------------------------------+* > > *| End System ID: 1000.0000.00A0 |* > > *+--------------------------------------------+* > > > > would make more sense. > > > > Am I understanding this correctly? > > > > > > Ah, I see, reading on you suggest same thing. Yes, I’m all for it > > > > > > *Packing/Re-packing* > > > > You state > > > > *" it is desirable to produce one packet on a miss on the merkle hash of > first level leaf and hence such leaves will pack initially 80 LSP > fragments"* > > > > This seems targeted to an environment where most systems generate > something less than 80 LSPs / node (including pseudo-node LSPs). This > probably is a reasonable assumption for many deployments/nodes, but > certainly does not apply to ABRs (L1/L2 routers) who are leaking a large > number of prefixes nor does it apply to nodes with a large number of > neighbors. I am not arguing about the number - nor am I quibbling about the > calculation of how many hashes can fit in an lsp-mtu sized HSNP. I just > find that the discussion of packing/repacking (Section 2.1) pays little > attention to the cases which don't fit within the assumptions. > > > > > > Given that there is an understandable desire to have neighbors choose the > same ranges of IDs for a given hash ordinal (as this limits the cases in > which the hash has to be recalculated on receipt of an HSNP) it would seem > beneficial if the "rules" for packing/repacking were more strict. > Otherwise, the likelihood that different implementations will realize the > benefits of consistent packing decreases significantly. > > > > Do I understand this correctly? > > > > Yes,. And it bears discussion. I did not go in this draft. to excruciating > levels of correctness because I assumed we will have father discussions > like this one > > > > So I hope you are in Madrid because that needs a beer and a napkin > > > > *[LES:] Sadly – won’t be in Madrid. But hopefully we can arrange a > discussion soon.* > let's discuss on mike then and after madrid set up a call or something >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
