Re: [RRG] map change due to a path failure?

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2008-03-26 11:48, William Herrin wrote:
> On Tue, Mar 25, 2008 at 5:54 PM, Brian E Carpenter
> <brian.e.carpenter@gmail.com> wrote:
>>  However, we want to avoid map flapping by design (you will remember
>>  that BGP4 route flapping was a big problem).
> 
> Brian,
> 
> At the risk of picking nits, we want to avoid the single-device update
> rate and system convergence problems associated with route flapping.
> That doesn't necessarily mean we need to avoid map flapping itself,
> just that it can't be allowed to cause those systemic problems.
> 
> In TRRP, for example, a map which is flapping consumes almost the same
> resources as one which is not. The ITR is going to re-query the map
> after the TTL expires regardless and the processing difference between
> verifying the map and updating the map is not much. Even that is
> limited to the ITRs actively communicating with the flapping origin.
> 
> 
>>  I would
>>  suggest that a loss of connectivity should persist for
>>  a long time, maybe 30 minutes, before the ETR changes the
>>  map. I'd expect BGP to handle any outages on a shorter timescale.
> 
> More path failures happen in the last mile than anywhere else. When
> the path between you and one of your ETRs breaks, BGP can't do
> anything about it. You either change the map to reflect that the lost
> ETR is no longer a valid waypoint for your packets or you implement
> some very complex technology in the ETR so it notices and tries to
> reincapsulate and reach you via one of the other ETRs that you've
> listed.
> 
> Not that the latter is a bad idea per se, but it will tend to be less
> reliable than updating the map.

You've got me worried.

Yes, assuming that the most likely point of link failure is between
ETR and the user site border, then BGP in the RLOC space isn't
going to help. And if the sender notices that the receiver, which
it only knows by its EID, has gone unreachable, there is nothing
it can do about it; there's nobody to complain to.

But if we fix that by having the ETR send a map update (actually
a map withdrawal) and we need that to propagate in less than the
TCP timeout, haven't we just turned the mapping system into
a dynamic routing protocol? However, it has to handle
several orders of magnitude more entries than BGP.

    Brian

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg