draft-ietf-grow-bgp-wedgies-01.txt   draft-ietf-grow-bgp-wedgies-02.txt 
GROW T. Griffin GROW T. Griffin
Internet-Draft University of Cambridge Internet-Draft University of Cambridge
Expires: September 27, 2004 G. Huston Expires: October 16, 2005 G. Huston
APNIC APNIC
March 29, 2004 April 14, 2005
BGP Wedgies BGP Wedgies
draft-ietf-grow-bgp-wedgies-01.txt draft-ietf-grow-bgp-wedgies-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions 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 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
It has commonly been assumed that the Border Gateway Protocol (BGP) It has commonly been assumed that the Border Gateway Protocol (BGP)
is a tool for distributing reachability information in a manner that is a tool for distributing reachability information in a manner that
creates forwarding paths in a deterministic manner. In this memo we creates forwarding paths in a deterministic manner. In this memo we
will describe a class of BGP configurations for which there is more will describe a class of BGP configurations for which there is more
than one potential outcome, and where forwarding states other than than one potential outcome, and where forwarding states other than
the intended state are equally stable, and that the stable state the intended state are equally stable, and that the stable state
where BGP converges may be selected by BGP in a non-deterministic where BGP converges may be selected by BGP in a non-deterministic
skipping to change at page 3, line 19 skipping to change at page 3, line 20
This is not a deterministic selection algorithm, as the selected This is not a deterministic selection algorithm, as the selected
primary provider may in turn be using AS path prepending to its primary provider may in turn be using AS path prepending to its
backup upstream provider, and in certain cases the path through the backup upstream provider, and in certain cases the path through the
backup provider may still be selected as the shortest AS path length. backup provider may still be selected as the shortest AS path length.
An alternative approach to routing policy specification uses BGP An alternative approach to routing policy specification uses BGP
communities [RFC1997]. In this case the provider publishes a set of communities [RFC1997]. In this case the provider publishes a set of
community values that allows the client to select the provider's community values that allows the client to select the provider's
local preference setting. The client can use a community to mark a local preference setting. The client can use a community to mark a
route as "backup only" towards the backup provider, and "primary 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 community values with such semantics. In this case the local
preference overrides the AS path length metric, so that if the route 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 marked "backup only", the route will be selected only when there
is no other source of the route. is no other source of the route.
3. BGP Wedgies 3. BGP Wedgies
The richness of local policy expression through the use of The richness of local policy expression through the use of
communities, when coupled with the behavior of a distance vector communities, when coupled with the behavior of a distance vector
protocol like BGP leads to the observation that certain protocol like BGP leads to the observation that certain
skipping to change at page 7, line 27 skipping to change at page 7, line 27
policy writer's intent. However, this is not always the case. The policy writer's intent. However, this is not always the case. The
above examples indicate that the operation of BGP allows multiple above examples indicate that the operation of BGP allows multiple
stable states to exist from a single configuration state, where some stable states to exist from a single configuration state, where some
of these states are not consistent with the policy writer's intent. of these states are not consistent with the policy writer's intent.
These particular examples can be described as a form of "route These particular examples can be described as a form of "route
pinning", where the route is pinned to a non-preferred path. pinning", where the route is pinned to a non-preferred path.
The challenge for the network administrator is to ensure that an The challenge for the network administrator is to ensure that an
intended state is maintained. Under certain circumstances this can intended state is maintained. Under certain circumstances this can
only be achieved by deliberate service disruption, involving the only be achieved by deliberate service disruption, involving the
withdrawal of routes being used to forward traffic, and withdrawal of routes being used to forward traffic, and re-
re-advertising routes in a certain sequence in order to induce an advertising routes in a certain sequence in order to induce an
intended BGP state. However, the knowledge that is required by any intended BGP state. However, the knowledge that is required by any
single network operator administrator in order to understand the single network operator administrator in order to understand the
reason why BGP has stabilized to an unintended state requires BGP reason why BGP has stabilized to an unintended state requires BGP
policy configuration knowledge of remote networks. In effect there policy configuration knowledge of remote networks. In effect there
is insufficient local information for any single network is insufficient local information for any single network
administrator to correctly identify the root cause of the unintended administrator to correctly identify the root cause of the unintended
BGP state, nor is there sufficient information to allow any single BGP state, nor is there sufficient information to allow any single
network administrator to undertake a sequence of steps to rectify the network administrator to undertake a sequence of steps to rectify the
situation back to the intended routing state. situation back to the intended routing state.
It is reasonable to anticipate that as the density of interconnection It is reasonable to anticipate that as the density of interconnection
increases, and also that the capability for policy-based preference increases, and also that the capability for policy-based preference
setting of learned and re-advertised routes will become more setting of learned and re-advertised routes will become more
expressive. It is therefore reasonable to anticipate that the expressive. It is therefore reasonable to anticipate that the
incidence of unintended BGP states will increase, and the ability to incidence of unintended BGP states will increase, and the ability to
understand the necessary sequence of route withdrawals and understand the necessary sequence of route withdrawals and re-
re-advertisements will become more challenging to determine in advertisements will become more challenging to determine in advance.
advance.
Whether this could lead to BGP routing system reaching a point where Whether this could lead to BGP routing system reaching a point where
each network consistently cannot direct traffic in a deterministic each network consistently cannot direct traffic in a deterministic
manner is at this stage a matter of speculation. BGP Wedgies are an manner is at this stage a matter of speculation. BGP Wedgies are an
illustration that a sufficiently complex interconnection topology, illustration that a sufficiently complex interconnection topology,
coupled with a sufficiently expressive set of policy constructs, can coupled with a sufficiently expressive set of policy constructs, can
lead to a number of stable BGP states, rather than a single intended lead to a number of stable BGP states, rather than a single intended
state. As the topology complexity increases it is not possible to state. As the topology complexity increases it is not possible to
deterministically predict which state the BGP routing system may deterministically predict which state the BGP routing system may
converge to. Paradoxically, the demands of inter-domain traffic converge to. Paradoxically, the demands of inter-domain traffic
skipping to change at page 8, line 35 skipping to change at page 8, line 34
introduces no new factors in terms of the security and integrity of introduces no new factors in terms of the security and integrity of
inter-domain routing. inter-domain routing.
The memo illustrates that in attempting to create policy-based The memo illustrates that in attempting to create policy-based
outcomes relating to path selection for incoming traffic it is outcomes relating to path selection for incoming traffic it is
possible to generate BGP configurations where there are multiple possible to generate BGP configurations where there are multiple
stable outcomes, rather than a single outcome. Furthermore, of these stable outcomes, rather than a single outcome. Furthermore, of these
instances of multiple outcomes, there are cases where the BGP instances of multiple outcomes, there are cases where the BGP
selection of a particular outcome is not a deterministic selection. 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 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995. (BGP-4)", RFC 1771, March 1995.
7.2 Informative References 8.2 Informative References
[RFC1997] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Attribute", RFC 1997, August 1996. Communities Attribute", RFC 1997, August 1996.
Authors' Addresses Authors' Addresses
Tim Griffin Tim Griffin
University of Cambridge University of Cambridge
EMail: Timothy.Griffin@cl.cam.ac.uk Email: Timothy.Griffin@cl.cam.ac.uk
Geoff Huston Geoff Huston
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
EMail: gih@apnic.net Email: gih@apnic.net
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 10, line 41 skipping to change at page 10, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement 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 to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/