On Tue, Mar 25, 2008 at 5:54 PM, Brian E Carpenter <[EMAIL PROTECTED]> 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 ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- to unsubscribe send a message to [EMAIL PROTECTED] 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
