You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's kind of weird that for the migration to the server preferred address path, the path ID is defined as 0. It might be advantageous to keep the anycast and the unicast path open for a limited amount of time.
We could consider defining this path to have path ID 1?
The text was updated successfully, but these errors were encountered:
Let's tackle that in conjunction with the server/client odd/even split. With that split, we have two options:
Stay strictly compatible with 9000. The client performs a path migration, very similar in nature to a NAT rebinding, and the path ID remains 0.
Create a specific path for the "preferred" address, in which case the client initiates a new path to that address. Since this is a client initiated new path, the path ID should be an even number, probably 2.
It's kind of weird that for the migration to the server preferred address path, the path ID is defined as 0. It might be advantageous to keep the anycast and the unicast path open for a limited amount of time.
We could consider defining this path to have path ID 1?
The text was updated successfully, but these errors were encountered: