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

[doc] Simplify MSEE failover handling in ER gateway bypass design. #619

Merged
merged 2 commits into from
Sep 27, 2024

Conversation

r12f
Copy link
Collaborator

@r12f r12f commented Sep 2, 2024

The current MSEE failover handling in ER gateway bypass design is reverse route table based, which is flexible, powerful, but a bit complicated.

With this change, we are going to simplify the MSEE failover handling using tunnel learning. There are 1 minor issue we could not address with this design, but we will update the design later which is compatible with this design and having the problem solved.

@r12f r12f changed the title Simplify MSEE failover handling in ER gateway bypass design. [doc] Simplify MSEE failover handling in ER gateway bypass design. Sep 2, 2024
Copy link
Collaborator

@marian-pritsak marian-pritsak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not a good design to have an implicit forwarding decision. If you think that is a desired behavior, DASH should have at least a setting to enable or disable the tunnel DIP learning. Then we can support other options like ECMP and be able to choose between them.


1. Step 1: Update the DIP list in the reverse tunnel object, which will cover all the new flows.
2. Step 2: Request a full flow resimulation, which will cover the existing flows.
When the next packet from MSEE comes in for a flow, the flow will be resimulated and the reverse tunnel will be updated accordingly, by picking up the new MSEE tunnel information.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the next packet is from the opposite side of the connection?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is expected to forward the packet according to the non-updated flow.

let me see if this is missed in the doc.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

found it! this behavior is captured in the section 5.2.3.3. below.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The packet is already in slow path because the flow it belongs to was marked for resimulation. Slow path doesn't know what the old destination was.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old destination should be known, because it is in the existing flow.

@r12f
Copy link
Collaborator Author

r12f commented Sep 27, 2024

thanks Marian!

@r12f r12f merged commit 6d963e5 into sonic-net:main Sep 27, 2024
3 checks passed
@r12f r12f deleted the user/r12f/ergw branch September 27, 2024 04:17
r12f added a commit that referenced this pull request Oct 2, 2024
Per HLD update: #619. This PR adds
the reverse tunnel information on ENI.

The packet transformation requires data plane app to create the flow,
hence not included in this PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants