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

["William Herrin" <bill@herrin.us>]

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.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin@dirtside.com bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
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