Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

donaldsharp
Copy link
Member

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.

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>
Copy link
Contributor

@mjstapp mjstapp left a 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:
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants