--- 1/draft-ietf-grow-bgp-wedgies-01.txt 2006-02-04 23:23:52.000000000 +0100 +++ 2/draft-ietf-grow-bgp-wedgies-02.txt 2006-02-04 23:23:52.000000000 +0100 @@ -1,50 +1,50 @@ GROW T. Griffin Internet-Draft University of Cambridge -Expires: September 27, 2004 G. Huston +Expires: October 16, 2005 G. Huston APNIC - March 29, 2004 + April 14, 2005 BGP Wedgies - draft-ietf-grow-bgp-wedgies-01.txt + draft-ietf-grow-bgp-wedgies-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each + of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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. + 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 September 27, 2004. + This Internet-Draft will expire on October 16, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2005). Abstract It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable, and that the stable state where BGP converges may be selected by BGP in a non-deterministic @@ -103,21 +103,21 @@ This is not a deterministic selection algorithm, as the selected primary provider may in turn be using AS path prepending to its backup upstream provider, and in certain cases the path through the backup provider may still be selected as the shortest AS path length. An alternative approach to routing policy specification uses BGP communities [RFC1997]. In this case the provider publishes a set of community values that allows the client to select the provider's local preference setting. The client can use a community to mark a route as "backup only" towards the backup provider, and "primary - preferred' to the primary provider, assuming both providers suppoprt + preferred' to the primary provider, assuming both providers support community values with such semantics. In this case the local preference overrides the AS path length metric, so that if the route is marked "backup only", the route will be selected only when there is no other source of the route. 3. BGP Wedgies The richness of local policy expression through the use of communities, when coupled with the behavior of a distance vector protocol like BGP leads to the observation that certain @@ -301,40 +301,39 @@ policy writer's intent. However, this is not always the case. The above examples indicate that the operation of BGP allows multiple stable states to exist from a single configuration state, where some of these states are not consistent with the policy writer's intent. These particular examples can be described as a form of "route pinning", where the route is pinned to a non-preferred path. The challenge for the network administrator is to ensure that an intended state is maintained. Under certain circumstances this can only be achieved by deliberate service disruption, involving the - withdrawal of routes being used to forward traffic, and - re-advertising routes in a certain sequence in order to induce an + withdrawal of routes being used to forward traffic, and re- + advertising routes in a certain sequence in order to induce an intended BGP state. However, the knowledge that is required by any single network operator administrator in order to understand the reason why BGP has stabilized to an unintended state requires BGP policy configuration knowledge of remote networks. In effect there is insufficient local information for any single network administrator to correctly identify the root cause of the unintended BGP state, nor is there sufficient information to allow any single network administrator to undertake a sequence of steps to rectify the situation back to the intended routing state. It is reasonable to anticipate that as the density of interconnection increases, and also that the capability for policy-based preference setting of learned and re-advertised routes will become more expressive. It is therefore reasonable to anticipate that the incidence of unintended BGP states will increase, and the ability to - understand the necessary sequence of route withdrawals and - re-advertisements will become more challenging to determine in - advance. + understand the necessary sequence of route withdrawals and re- + advertisements will become more challenging to determine in advance. Whether this could lead to BGP routing system reaching a point where each network consistently cannot direct traffic in a deterministic manner is at this stage a matter of speculation. BGP Wedgies are an illustration that a sufficiently complex interconnection topology, coupled with a sufficiently expressive set of policy constructs, can lead to a number of stable BGP states, rather than a single intended state. As the topology complexity increases it is not possible to deterministically predict which state the BGP routing system may converge to. Paradoxically, the demands of inter-domain traffic @@ -357,43 +356,49 @@ introduces no new factors in terms of the security and integrity of inter-domain routing. The memo illustrates that in attempting to create policy-based outcomes relating to path selection for incoming traffic it is possible to generate BGP configurations where there are multiple stable outcomes, rather than a single outcome. Furthermore, of these instances of multiple outcomes, there are cases where the BGP selection of a particular outcome is not a deterministic selection. -7. References +7. IANA Considerations -7.1 Normative References + [Note to RFC Editor: Please remove this section prior to publication] + + This document has no associated IANA actions or considerations. + +8. References + +8.1 Normative References [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. -7.2 Informative References +8.2 Informative References - [RFC1997] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities - Attribute", RFC 1997, August 1996. + [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP + Communities Attribute", RFC 1997, August 1996. Authors' Addresses Tim Griffin University of Cambridge - EMail: Timothy.Griffin@cl.cam.ac.uk + Email: Timothy.Griffin@cl.cam.ac.uk Geoff Huston Asia Pacific Network Information Centre - EMail: gih@apnic.net + Email: gih@apnic.net Intellectual Property Statement 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 @@ -417,18 +422,18 @@ 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 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. Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.