Subject: [Idr] BGP MRAI Configuration

From: Ahmed Elmokashfi <[email-masked]>
Date: Tue, 02 Sep 2008 12:53:31 +0200

Folks,

We are pursuing some work along the lines of studying BGP
scalability in terms of churn evolution. One of the key mechanisms
used by BGP to dampen the churn is the MRAI timer (Minimum Route
Advertisement Interval).

>From different vendors' specifications we find that:

1- Cisco enables MRAI by default for both route announcements and route
withdrawals.
2- Juniper has a  similar parameter called out-delay which is disabled
by default.

Of course these are default configurations,  and we don't know if
ISPs use them without any change. We would appreciate any input on the
following questions:

A- Is it common that ISPs change MRAI default configurations? If yes,
then what decides the MRAI settings for both e-BGP and i-BGP sessions?
B- Does anybody use a configuration where only route announcements are
rate limited, and not explicit route withdrawals?
C- Are there configurations where rate limiting is applied only to a
subset of session?

Best regards,

Ahmed Elmokashfi
Simula Research Laboratory.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Robin Whittle <[email-masked]>
Date: Tue, 02 Sep 2008 22:28:20 +1000

Hi Ahmed,

This may not answer your questions, but you might be interested in a
discussion on this list and the RRG list in June 2007 about the MRAI
timer, path hunting and the history of how the RFCs changed.

I keep links to this discussion at:

http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_hunting_MRAI_disc

The discussion started on the RRG:

  http://psg.com/lists/rrg/2007/maillist.html#00146

and moved to the IDR list:

  http://www.ietf.org/mail-archive/web/idr/current/msg02414.html

Tony Li gave his understanding of path hunting:

  http://www.ietf.org/mail-archive/web/idr/current/msg02422.html

    - Robin

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 2 Sep 2008 09:58:35 -0400

>   http://www.ietf.org/mail-archive/web/idr/current/msg02422.html

The biggest words of wisdom, IMO, are these:

"As always, I think that the RFC is a fine goal, and that implementors
frequently take short cuts that may or may not be warranted. I'm not
throwing rocks at them because frankly, many of those rocks would end up
back in my lap. As I noted earlier, implementing MRAI per the letter of
the spec is non-trivial, and I sympathize with those who decided not to
implement it."

The BGP timers are non-trivial when you think about them in terms of
*per-peer*.  RFC 4271 got some wiggle room from previous versions of the
spec:

: This can only be achieved by keeping a separate timer for each common
: set of destinations.  This would be unwarranted overhead.  Any technique
: that ensures[...]

Thus, when analyzing MRAI implementations, it's a good idea to observe
what happens to multiple peers when reachability has cause to churn.
The behavior is probably not what you'd expect.

One unfortunate thing about RFC 4271 is that it didn't catch a bit of
common wisdom that MRAI shouldn't apply to explicit withdrawals.  The
"bad news should travel faster" observation wasn't proved to some
people's satisfaction.

-- Jeff