One document matched: draft-ietf-idr-best-external-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4271 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC3345 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3345.xml">
<!ENTITY RFC4456 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4456.xml">
<!ENTITY RFC1771 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1771.xml">
<!ENTITY RFC5065 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5065.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-idr-best-external-01.txt"
ipr="pre5378Trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Best External">
Advertisement of the best external route in BGP</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Pedro Marques" initials="P.M."
surname="Marques">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Drive</street>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<email>roque@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Rex Fernando" initials="R.F."
surname="Fernando">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Drive</street>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<email>rex@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Enke Chen" initials="E.C."
surname="Chen">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Drive</street>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<email>enkechen@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Pradosh Mohapatra" initials="P.M."
surname="Mohapatra">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Drive</street>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone></phone>
<email>pmohapat@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="February" year="2010" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Network Working Group</workgroup>
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
The base BGP specifications prevent a BGP speaker from
advertising any route that is not the best route for a BGP
destination. This document specifies a modification of
this rule. Routes are divided into two categories, "external"
and "internal". A specification is provided for choosing a
"best external route" (for a particular value of the Network
Layer Reachability Information). A BGP speaker is then allowed
to advertise its "best external route" to its
internal BGP peers, even if that is not the best route for
the destination. The document explains why advertising
the best external route can improve convergence time without
causing routing loops. Additional benefits include reduction of
inter-domain churn and avoidance of permanent route oscillation.
The document also generalizes the notions of "internal" and
"external" so that they can be applied to Route Reflector Clusters
and Autonomous System Confederations.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The base BGP specifications prevent a BGP speaker from
advertising any route that is not the best route for a BGP
destination. This document specifies a modification of
this rule. Routes are divided into two categories, "external"
and "internal". A specification is provided for choosing a
"best external route" (for a particular value of the Network
Layer Reachability Information). A BGP speaker is then allowed
to advertise its "best external route" to its
internal BGP peers, even if that is not the best route for
the destination. The document explains why advertising
the best external route can improve convergence time without
causing routing loops. Additional benefits include reduction of
inter-domain churn and avoidance of permanent route oscillation.
</t>
<t>
The document also generalizes the notions of "internal" and
"external" so that they can be applied to Route Reflector Clusters
<xref target="RFC4456"></xref> and Autonomous System Confederations
<xref target="RFC5065"></xref>. More specifically, two
routers in the same route reflector cluster having an IBGP session
between them are defined to be "internal" peers, whereas two
routers in different clusters having an IBGP session are defined to
be "external" peers. Similarly, two routers in the same member
AS of a confederation having an IBGP session between them are
"internal" peers, whereas two routers in different member
ASs of a confederation having a confed EBGP session between them
are defined to be "external" peers. The definition of "best
external route" ensues from this definition in that it is the
most preferred route among those received from the "external"
neighbors.
</t>
<t>
Advertising the best external route, when different from the best route,
presents additional information into an IBGP mesh which may be of value
for several purposes including:
<list style="symbols">
<t>
Faster restoration of connectivity, by providing additional
paths, that may be used to fail over in case the primary path
becomes invalid or is withdrawn.
</t>
<t>
Reducing inter-domain churn and traffic blackholing due to the
readily available alternate path.
</t>
<t>
Reducing the potential for situations of permanent IBGP route
oscillation, as discussed in some scenarios <xref
target="RFC3345"></xref>.
</t>
<t>
Improving selection of lower MED routes from the same
neighboring AS.
</t>
</list>
</t>
<t>
This document defines procedures to select the best external route for
each destination. It also describes how above benefits are realized
with best external route announcement with the help of certain scenarios.
</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section> <!-- Introduction -->
<section anchor="best_external_selection"
title="Algorithm for selection of best external route">
<t>
Given that the intent in advertising an external route, when the
best route for the same destination is an internal route, is to
provide additional information into the IBGP mesh into which a route
is participating, it is desirable to take into account the routes
received from internal neighbors in the selection process.
</t>
<t>
We propose a route selection algorithm that selects a total order
between routes and which selects the same best route as the
one currently specified <xref target="RFC4271"></xref>.
</t>
<t>
In order to achieve this, we need to introduce the concept of route
group. For a given NLRI, suppose the BGP decision process has run
through all the steps prior to the MED comparison step (as defined
in section 9.1.2.2 of <xref target="RFC4271"></xref>. Look at the
set of routes that are still under consideration at that time. Now
partition this set into a number of disjoint route groups, where
two routes are in the same group if and only if the neighbor AS of
each route is the same.
</t>
<t>
Routes are ordered within a group via MED or subsequent route
selection rules.
</t>
<t>
The order of all routes for the same destination is determined by the
order of the best route in each group.
</t>
<t>
As an example, the following set of received routes:
<figure align="center" anchor="pa_table"
title="Path Attribute Table">
<artwork align="left"><![CDATA[
Path AS MED rtr_id
a 1 10 10
b 2 5 1
c 1 5 5
d 2 20 20
e 2 30 30
f 3 10 20
]]></artwork>
</figure>
</t>
<t>
Would yield the following order (from the most to the least
preferred):
</t>
<t>
b < d < e < c < a < f
</t>
<t>
In this example, comparison of the best route within each group
provides the sequence (b < c < f). The remaining routes are ordered
in relation to their respective group best.
</t>
<t>
The first route in the above ordering is indeed the best route for
a given destination. Eliminating the best route and executing the
above steps leads us to a new total order of the routes.
The route to be advertised to a particular domain
is selected by choosing the most preferred route that is external
to that particular domain in the above order. Note that whenever the
overall best route is external it will automatically be selected by
this algorithm.
</t>
</section> <!-- Algorithm for selection of best-external route -->
<section title="Advertisement Rules">
<t>
<list style="numbers">
<t>
In an AS domain, if a router has installed an internal route as best, it
should advertise its "best external route" (as defined in the draft) to
its internal neighbors.
</t>
<t>
In a Cluster domain, if a router (route reflector) has installed an
external route as best, it should advertise its "best internal route"
to its external neighbors. (Advertising to internal neighbors is
unchanged.)
Similarly, if the route reflector has installed an internal route as
best, it should advertise its "best external route" to its internal
(client) peers. In order for the reflector to be able to advertise
the best external route into the cluster, it is necessary that client-to-client
reflection be disabled, since its advertisement may otherwise
contain the best route within the cluster domain.
</t>
<t>
In a Confederation Member domain, if a router (confederation border
router) has installed an internal route as best, it advertises its
best external route to its internal neighbors. However, if it has
installed an external route as best, it
advertises its best internal route to its external neighbors.
</t>
</list>
</t>
</section> <!-- Advertisement Rules -->
<section anchor="routing_consistency"
title="Consistency between routing and forwarding">
<t>
The BGP protocol, as defined in <xref target="RFC1771"></xref>,
specifies that a BGP speaker shall advertise to its internal peers
the route with the highest degree of preference among routes to the
same destination received from external neighbors.
</t>
<t>
This section discusses problems present with the approach described
in <xref target="RFC1771"></xref> and the next section offers an
alternative algorithm to select a best external route which can be
advertised to an IBGP mesh.
</t>
<t>
The internal update advertisement rules contained in the original
BGP-4 specification <xref target="RFC1771"></xref> can lead to
situations where traffic is forwarded through a route other than
the route advertised by BGP.
</t>
<t>
Inconsistencies between forwarding and routing are highly
undesirable. Service providers use BGP with the dual objective of
learning reachability information and expressing policy over
network resources. The latter assumes that forwarding follows
routing information.
</t>
<t>
Consider the Autonomous system presented in figure 1, where r1 ... r4
are members of a single IBGP mesh and routes a, b, and c are received
from external peers.
</t>
<figure align="center" anchor="full_mesh_topology"
title="Inconsistency in Routing">
<artwork align="left"><![CDATA[
AS 1 (c)
|
+----+ +----+
| r1 |...........| r2 |
+----+ +----+
.
.
.
.
.
.
+----+ +----+
| r3 |...........| r4 | --- ebgp --- AS X
+----+ +----+
/ \
/ \
AS 1 (a) AS 2 (b)
]]></artwork>
</figure>
<t>
<figure align="center" anchor="selection_table"
title="Path Attribute Table - 2">
<artwork align="left"><![CDATA[
Path AS MED rtr_id
a 1 10 1
b 2 5 10
c 1 5 5
]]></artwork>
</figure>
</t>
<t>
Following the rules as specified in <xref target="RFC1771"></xref>,
router r3 will select path (b) received from AS 2 as its overall
best to install in the Loc-Rib, since path (b) is preferable to
path (c), the lowest MED route from AS 1. However for the purposes
of Internal Update route selection, it will ignore the presence of
path (c), and elect (a) as its advertisement, via the router-id
tie-breaking rule.
</t>
<t>
In this scenario, router r4 will receive (c) from r1 and (a) from
r3. It will pick the lowest MED route (c) and advertise it out via
ebgp to AS X. However at this point routing is inconsistent with
forwarding as traffic received from AS X will be forwarded towards
AS 2, while the ebgp advertisement is being made for an AS 1 path.
</t>
<t>
Routing policies are typically specified in terms of neighboring
ASes. In the situation above, assuming that AS 1 is network for
which this AS provides transit services while AS 2 and AS X are
peer networks, one can easily see how the inconsistency between
routing and forwarding would lead to transit being inadvertently
provided between AS X and AS 2. This could lead to persistent
forwarding loops.
</t>
<t>
Inconsistency between routing and forwarding may happen, whenever a
bgp speaker chooses to advertise an external route into IBGP that is
different from the overall best route and its overall best is
external.
</t>
</section>
<section title="Applications">
<section title="Fast Connectivity Restoration">
<t>
When two exits are available to reach a particular destination and
one is preferred over the other, the availability of an alternate
path provides fast connectivity restoration when the primary path
fails.
</t>
<t>
Restoration can be quick since the alternate path is already at
hand. The border router could precompute the backup route and
preinstall it in FIB ready to be switched when the primary goes
away. Note that this requires the border router that's the backup
to also preinstall the secondary path and switch to it on failure.
</t>
</section>
<section title="Inter-Domain Churn Reduction">
<t>
Within an AS, the non availability of backup best leads to a border
router sending a withdraw upstream when the primary fails. This
leads to inter-domain churn and packet loss for the time the
network takes to converge to the alternate path. Having the
alternate path will reduces the churn and eliminates packet loss.
</t>
</section>
<section title="Reducing Persistent IBGP oscillation">
<t>
Advertising the best external route, according to the algorithm
described in this document will reduce the possibility of route
oscillation by introducing additional information into the IBGP
system.
</t>
<t>
For a permanent oscillation condition to occur, it is necessary that
a circular dependency between paths occurs such that the selection of
a new best path by a router, in response to a received IBGP
advertisement, causes the withdrawal of information that another
router depends on in order to generate the original event.
</t>
<t>
In vanilla BGP, when only the best overall route is advertised, as in
most implementations, oscillation can occur whenever there are 2 or
clusters/sub-ASes such that at least one cluster has more than one
path that can potentially contribute to the dependency.
</t>
</section>
</section>
<section title="Acknowledgments">
<t>
This document greatly benefits from the comments of Yakov Rekhter,
John Scudder, Eric Rosen, and Jenny Yuan.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
There are no additional security risks introduced by this design.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629;
here (as shown)
2. simply use a PI
"less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included
files in the same directory as the including file. You can also define
the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be
either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include=
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC4271;
&RFC3345;
&RFC4456;
&RFC5065;
&RFC1771;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 20:32:21 |