Re: [Idr] draft-jakma-mrai-dep-00 (fwd)

Jeff,

Pls see inline,

> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
> Jeffrey Haas
> Sent: Wednesday, November 26, 2008 10:23 AM
> To: Pedro Marques
> Cc: Yakov Rekhter; idr@ietf.org
> Subject: Re: [Idr] draft-jakma-mrai-dep-00 (fwd)
> 
> On Tue, Nov 25, 2008 at 10:07:33PM -0800, Pedro Marques wrote:
> > The typical example being an SP that acquires a newly preferred peer
> route
> > which them causes it to send withdrawals to other peers (reachable
> converts
> > to unreachable).
> >
> > My understanding is that this behavior has been well document in
> practical
> > observations of BGP convergence.
> 
> That was the example I needed.
> 
> Part of the reason why I suggested separate timers is that the above
> scenario is within the scope of iBGP convergence.  This means that
> within the expcted iBGP MRAI you should be able to safely send
> unreachables quicker to your eBGP peers than you'd otherwise be able
to
> if you were waiting on the (typically longer) eBGP MRAI.

Agreed.

> I'd still recommend different timers but I think I've just been
> convinced that the withdraw timer should have a lower bound of the
iBGP
> MRAI value.

You mean - separate reachable and withdrawl timer for any BGP peer (I or
E) !! Right?

Cheers,
Rajiv

> > In general my recommendation for MRAI values would be 0 for eBGP and
> 0 for
> > iBGP. As the draft correctly explains calculating a value that best
> fits
> > the network is a very tricky business.
> 
> And, as long as you're not worrying about route flap dampening, TCP
> queue lengths and processing delays is often enough to squelch a lot
of
> the updates in networks that are "busy enough".
> 
> -- Jeff
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr