If a BGP update indicates that the destination locator is no longer
available, the router doing the forwarding has two choices:
1) drop the packet on the floor and wait for someone upstream (e.g.,
the originating ITR) to notice (perhaps after being prodded) and
stop using the bad destination locator
Agree and simple.
2) pop the encapsulation (keeping the source locator), re-do the
lookup of the destination EID to discover all possible locators, use
information at that router to pick a new destination locator and, if
a viable one exists, re-encapsulate using the new destination
locator and the original source locator.
[waiting while the screams of horror and outrage at choice 2 die
down.]
I couldn't scream because you made me pass out. ;-) You really don't
want to do this or else every router on the path between two sites
would have to store mappings. And if you did that, it would be per-EID
state. Which is exactly what we have today without the encapsulation
step.
So you really don't want to do this.
And if you aggregated many EID-prefixes into a handle of some sort and
wanted per-packet rerouting, that handle would be called a label and
we have that with MPLS today.
My impression is that efforts on LOC/ID separation have been focused
on the first choice (for valid reasons), however the second choice
more closely mirrors the behavior of the existing routing system in
which every router can make routing decisions based on the
destination _identifier_.
When a packet is encapsulated from ITR to ETR, you still have the
rerouting system available, it's just not based on the host endpoint
but the site endpoint.
Dino
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
