Revised Default Values for the BGP 'Minimum Route Advertisement Interval'
draft-jakma-mrai-02

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 22, 2009.

Abstract

This document briefly examines what is known about the effects of the BGP MRAI timer, particularly on convergence. It highlights published work which suggests the MRAI interval as deployed has an adverse effect on the convergence time of BGP.

It then recommends revised, lower default values for the MRAI timer, thought to be more suited to today's Internet environment.

Table of Contents

1.  Requirements Language
2.  Background
    2.1.  The MRAI Timer
    2.2.  Known effects of the MRAI timer on convergence
    2.3.  Interaction with Flap-Damping
    2.4.  Current Status of the MRAI
3.  Risk Evaluation in the Choice of MRAI Time
4.  Recommendations on the MRAI
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” February 2001.).

2.  Background

The proper functioning of the [BGP] (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) routing protocol is of great importance to the Internet. Issues regarding matters of its stability and convergence have been documented widely, such as in [BGP‑STAB] (Li, T. and G. Huston, “BGP Stability Improvements,” June 2007.), [bgp‑converge] (Griffin, T. and B. Premore, “An Experimental Analysis of BGP Convergence Time,” November 2001.) and [Potaroo0607] (Huston, G., “Damping BGP,” June 2007.).

One such issue is the effect of 'Minimum Route Advertisement Interval' (MRAI).

2.1.  The MRAI Timer

The Minimum Route Advertisement Interval (MRAI) timer is specified in RFC4271 (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) [BGP]. This timer acts to rate-limit updates, on a per-destination basis. [BGP] (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) suggests values of 30s and 5s for this interval for eBGP and iBGP respectively. The MRAI must also be applied to withdrawals according to RFC4271 (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) [BGP], a change from the earlier RFC1771.

Some implementations apply this rate-limiting on a per-peer basis, presumably an adequate approximation. Some implementations apply it to withdrawal methods (often called "WRATE" in the literature). Some implementations do not apply MRAI at all.

2.2.  Known effects of the MRAI timer on convergence

The MRAI timer serves to suppress messages which BGP would otherwise send out to describe transitory states, and so allow BGP to converge with significantly fewer messages sent. This beneficial effect of the MRAI timer, in terms of # of messages, increases as the timer is increased until an optimum value is reached, after which the beneficial effect stabilises. [bgp‑converge] (Griffin, T. and B. Premore, “An Experimental Analysis of BGP Convergence Time,” November 2001.) [mrai‑final] (Qiu, J., Hao, R., and X. Li, “An Experimental Study of the BGP Rate-limiting Timer,” June 2003.)

In terms of convergence time, a similar beneficial effect is seen as the MRAI increases to near the same optimum value. However as the timer value is increased past this point, the convergence time increases again linearly. The scale of this increase is significantly worse with WRATE, i.e. applying the MRAI to withdrawals has an adverse effect on BGP convergence time. [bgp‑converge] (Griffin, T. and B. Premore, “An Experimental Analysis of BGP Convergence Time,” November 2001.) [mrai‑final] (Qiu, J., Hao, R., and X. Li, “An Experimental Study of the BGP Rate-limiting Timer,” June 2003.)

The optimum MRAI timer value is dependent on several factors, most particularly the topology in its layout and propagation times. The optimum value will differ between different subsets of the Internet. [mrai‑final] (Qiu, J., Hao, R., and X. Li, “An Experimental Study of the BGP Rate-limiting Timer,” June 2003.)

It is believed to be infeasible to try directly calculate this value. However a useful approximation can be made from the diameter of the topology if it is known, along with some assumptions about the the topology, such as the latency between nodes. [mrai‑internet] (Qiu, J., Hao, R., and X. Li, “The Optimal Rate-Limiting Timer of BGP for Routing Convergence,” April 2005.)

The interaction between extensions to BGP designed to improve convergence, such as those that allow propagation of additional and/or backup paths, and the MRAI timer is as yet unknown. However, it seems reasonable to speculate these extensions might have the effect of leading to a lower optimum MRAI than would be indicated by an approximation based on the diameter of the BGP topology. Further work on these questions would be useful.

2.3.  Interaction with Flap-Damping

As the MRAI helps eliminate some updates, it interacts with flap-damping (Villamizar, C., Chandra, R., and R. Govindan, “BGP Route Flap Damping,” November 1998.) [BGP‑DAMP]. The lower the MRAI timer, the greater the risk of crossing below the threshold of the optimum value. If that threshold is crossed, there will be an increased number of updates somewhere within the BGP system, and hence an increased risk of paths being dampened which otherwise would not.

So, in presence of significant flap-damping deployment and given the uncertainty of what the optimum is, it is reasonable to err towards selecting a value of the MRAI timer significantly higher than the optimum.

However, given that flap-damping increasingly is discouraged [RIPE‑378] (Smith, P. and P. Panigl, “RIPE RRG: Recommendations on Route-flap Damping,” May 2006.) in Internet routing, this particular need to be conservative in the choice of MRAI timer value may be less important.

2.4.  Current Status of the MRAI

The current recommended value of 30s may be far higher than is optimal for the Internet, based on observations of certain parameters related to its topology. In [mrai‑final] (Qiu, J., Hao, R., and X. Li, “An Experimental Study of the BGP Rate-limiting Timer,” June 2003.) it is suggested that the optimal value may be between 5s ('semi-safe') to 15s ('safe'). The estimation of the 'safe' value here is of no relevance if WRATE is universally deployed, as in such a case the 'semi-safe' value will be the same as the 'safe' value. Further empirical work by the same authors [mrai‑internet] (Qiu, J., Hao, R., and X. Li, “The Optimal Rate-Limiting Timer of BGP for Routing Convergence,” April 2005.) suggests that the optimal, Internet MRAI may be below 5s.

Further, [BGP‑STAB] (Li, T. and G. Huston, “BGP Stability Improvements,” June 2007.) and [Potaroo0607] (Huston, G., “Damping BGP,” June 2007.) argue that operational conditions (e.g. different routers using different MRAI values) mean the MRAI is having an adverse effect even on the number of messages sent, and so further exacerbating convergence problems in the global BGP system, such as path hunting. The [BGP‑STAB] (Li, T. and G. Huston, “BGP Stability Improvements,” June 2007.) document goes further still and argues that MRAI be deprecated in favour of some better way of damping BGP UPDATES, however there are no clear proposals before the IDR as of this writing for such changes to BGP.

3.  Risk Evaluation in the Choice of MRAI Time

Though there is an optimum value for the MRAI, it's unlikely that it can be determined empirically or otherwise for the general Internet. It may even not be possible, as the optimum MRAI will differ for different subsets of the Internet. Some degree of guesstimation at a reasonable value for the MRAI is required, which is an exercise in risk; whether to err towards fast convergence at the risk of a disproportionate increase in BGP messaging, or to err to the side of an optimal number of messages at the expense of convergence.

Arguably, economising on bandwidth and control-plane processing power is of less importance than the convergence time of BGP, compared to times past. Presuming this, any new recommendations for the MRAI should seek to err slightly to the side of convergence, rather than erring towards minimising BGP traffic.

Further, if we assume most implementations apply the MRAI to withdrawals, then the Internet BGP topology effectively is WRATE-enabled, and [mrai‑final] (Qiu, J., Hao, R., and X. Li, “An Experimental Study of the BGP Rate-limiting Timer,” June 2003.) suggests there is even less benefit to erring toward a higher MRAI.

There may be risks in mismatched MRAI values between speakers in an AS as revised MRAI values are deployed. The MRAI values in RFC4271 (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) [BGP] were deliberately specified to be lower for iBGP than for eBGP, so as to allow interior routing to converge while minimising the effect on eBGP state. So with mismatched values there is an increased risk that the external stability of an AS's routes would be affected by transient, internal states.

This last risk suggests that the existing iBGP/VPN values should be the lower-bound for any conservative revision of the eBGP MRAI value.

The most definite risk of lowering the MRAI is the increased risk of flap-damping, if the value is set too much below the optimum. Therefore, taking into account estimations of that optimum is required. That said, at least one BGP implementation by default does not apply any MRAI at all.

4.  Recommendations on the MRAI

The suggested default values for the MinRouteAdvertisementIntervalTimer given in RFC4271 (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) [BGP] are revised to be 5s or less for eBGP connections, and 1s or less for iBGP connections, for use on Internet topologies.

These values may not be suitable for topologies which differ from the Internet, be that in scale, arrangement or otherwise. Such non-Internet, BGP topologies likely would have lower optimum values, assuming they are always significantly smaller in scale than the Internet BGP topology. Hence, implementations SHOULD allow the MRAI value to be configured administratively on a per-AFI/SAFI basis, as well as a per-peer basis.

Given the beneficial effects on convergence time, implementations MAY exempt withdrawals from the MRAI timer.

5.  IANA Considerations

There are no requests made to IANA in this document.

6.  Security Considerations

This document raises no new security considerations.

7.  Acknowledgements

The author would like to thank Manav Bhatia for his helpful review and comments; as well as Robert Raszuk, Samita Chakrabarti, Danny McPherson and Jeffrey Haas for their useful comments; dissenting or otherwise.

The authors of the cited documents are thanked for their contributions to the understanding of BGP, of which this document is a simple summary.

8.  References

8.1. Normative References

8.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.