New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zebra: Attempt to explain the rnh tracking code better #15586
base: master
Are you sure you want to change the base?
Conversation
I got asked today what was going on in the rnh code. I had to take time off of what I was doing and rewrap my head around this code, since it's been a long time. As that this question may come up again in the future I am trying to document this better so that someone coming behind us will be able to read this and get a better idea of what the algorithm is attempting to do. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great idea to try to capture this in ... words. Had a couple of questions
* rnh 1.1.3.4 | ||
* rnh 4.5.6.7 | ||
* Now imagine that you have in the tree these | ||
* prefix's: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"prefix's" -> "prefixes" ?
* 1.1.1.1/32 | ||
* 1.1.1.0/24 | ||
* 1.1.0.0/16 | ||
* 0.0.0.0/0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might be a bit clearer if this list were reversed, so that the default, all-zeroes, prefix would be at the "top", and the /32 would be at the bottom?
* This function would start at the 1.1.1.1/32 node, | ||
* perform a LPM and settle on the 1.1.1.0/24 node | ||
* as where it belongs. The code would update appropriate | ||
* interested parties and additionally also mark the sequence |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the discussion about the sequence number wasn't clear to me?
so if 1.1.1.2/32 is being deleted, and there's a 1.1.1.2 rnh, the rnh needs to be moved to some other (valid) prefix. the text "it would get to the 1.1.1.0/24 node and since the seqno matches we would know that it is not necessary to reconsider this node" was what confused me: the sequence number is on the rnh, not the prefix, not the "node". it might be clearer to say something like "seeing a matching sequence number on the 1.1.1.2 rnh, we know it's not necessary to reconsider the rnh."
I got asked today what was going on in the rnh code. I had to take time off of what I was doing and rewrap my head around this code, since it's been a long time. As that this question may come up again in the future I am trying to document this better so that someone coming behind us will be able to read this and get a better idea of what the algorithm is attempting
to do.