[rrg] Locator Path Liveness concerns

[Dino Farinacci]

> 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