[doc] Simplify MSEE failover handling in ER gateway bypass design. #619
Conversation
r12f
changed the title
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
What if the next packet is from the opposite side of the connection?
There was a problem hiding this comment.
it is expected to forward the packet according to the non-updated flow.
let me see if this is missed in the doc.
There was a problem hiding this comment.
found it! this behavior is captured in the section 5.2.3.3. below.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
The old destination should be known, because it is in the existing flow.
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.