One document matched: draft-ietf-grow-va-auto-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<!-- zzzz next line -->
<rfc category="info" ipr="trust200811" docName="draft-ietf-grow-va-auto-00.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev="VA Auto Config">Proposal for Auto-Configuration in Virtual Aggregation</title>
<author initials ='P' surname ='Francis' fullname='Paul Francis'>
<organization abbrev="MPI-SWS">Max Planck Institute for Software Systems</organization>
<address>
<postal>
<street>Gottlieb-Daimler-Strasse</street>
<city>Kaiserslautern</city>
<!-- <region>NY</region> -->
<code>67633</code>
<country>Germany</country>
</postal>
<phone>+49 631 930 39600</phone>
<email>francis@mpi-sws.org</email>
</address>
</author>
<author initials ='X' surname ='Xu' fullname='Xiaohu Xu'>
<organization abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street>
No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
</street>
<city>Beijing</city>
<region>Beijing</region>
<code>100085</code>
<country>P.R.China</country>
</postal>
<phone>+86 10 82836073</phone>
<email>xuxh@huawei.com</email>
</address>
</author>
<author initials ='H' surname ='Ballani' fullname='Hitesh Ballani'>
<organization abbrev="Cornell U.">Cornell University</organization>
<address>
<postal>
<street>4130 Upson Hall</street>
<city>Ithaca</city>
<region>NY</region>
<code>14853</code>
<country>US</country>
</postal>
<phone>+1 607 279 6780</phone>
<email>hitesh@cs.cornell.edu</email>
</address>
</author>
<author initials ='D' surname ='Jen' fullname='Dan Jen'>
<organization abbrev="UCLA">UCLA</organization>
<address>
<postal>
<street> 4805 Boelter Hall </street>
<city>Los Angeles</city>
<region>CA</region>
<code> 90095 </code>
<country>US</country>
</postal>
<phone> </phone>
<email>jenster@cs.ucla.edu</email>
</address>
</author>
<author initials ='R' surname ='Raszuk' fullname='Robert Raszuk'>
<organization abbrev="Self">Self</organization>
<address>
<postal>
<street> </street>
<city> </city>
<region> </region>
<code> </code>
<country> </country>
</postal>
<phone> </phone>
<email>robert@raszuk.net</email>
</address>
</author>
<author initials ='L' surname ='Zhang' fullname='Lixia Zhang'>
<organization abbrev="UCLA">UCLA</organization>
<address>
<postal>
<street> 3713 Boelter Hall </street>
<city>Los Angeles</city>
<region>CA</region>
<code> 90095 </code>
<country>US</country>
</postal>
<phone> </phone>
<email>lixia@cs.ucla.edu</email>
</address>
</author>
<!-- zzzz set date zzzz -->
<date day="18" month="October" year="2009"/>
<abstract>
<t>
Virtual Aggregation as specified in
<xref target="I-D.ietf-grow-va"></xref>
requires a certain amount of configuration, namely
virtual prefixes (VP), a VP list, type of tunnel,
and popular prefixes.
This draft proposes optional approaches to auto-configuration of
popular prefixes and the VP list, and discusses the pros and
cons of each.
If these proposals are accepted, they will be incorporated into
<xref target="I-D.ietf-grow-va"></xref>.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Virtual Aggregation as specified in
<xref target="I-D.ietf-grow-va"></xref>
requires a certain amount of configuration, namely:
<t><list style="numbers">
<t>
Each Aggregation Point Router (APR) must be configured with the VPs
for which it is an APR.
</t>
<t>
Every router must be configured with the VP list (a list of all VPs).
This allows the router to know which prefixes can and cannot be
FIB-suppressed.
</t>
<t>
Every router should be configured with a list of prefixes that
should be FIB-installed (for instance because they have large
traffic volumes).
</t>
<t>
Every router should be configured as to the tunnel type.
</t>
</list></t>
</t>
<t>
Of these four items, the first and last cannot be automated.
Both, however, represent a relatively small amount of configuration.
The second and third are more significant, and this draft
proposes mechanisms for partially or fully automating them.
If any of these proposals are accepted, they will be incorporated
into the main VA draft.
In any event, they would be considered as optional.
The manually configured VP-list would still be mandatory, though
an ISP could choose not to use it if one of the options described
here is available.
(<xref target="I-D.ietf-grow-va"></xref>).
</t>
<t>
All of the approaches described in this draft involve tagging
routes with a standard extended communities attribute.
There are three such tags, the "should-install" tag, the
"VP-route" tag, and the "can-suppress" tag.
The should-install tag is for the purpose of automating the
configuration of popular prefixes that are popular by virtue
of having high traffic volume.
The VP-route and can-suppress tags represent two alternatives
for the VP-list.
Note that usage of the should-install tag (popular prefixes config)
is completely
orthogonal with usage of either the VP-route or can-suppress tag
(replacement for VP-list config).
</t>
<section title="Requirements notation">
<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"/>.
</t>
</section>
</section>
<section anchor="sec-syntax" title="Syntax for the tags">
<t>
All three tags can be conveyed with an Extended
Communities Attribute
<xref target="RFC4360"></xref> to be assigned by IANA.
For all three tags, the Transitive Bit
MUST be set to value 1 (the community is non-
transitive across ASes).
</t>
</section> <!-- "sec-syntax" -->
<section anchor="sec-popular" title="Config of Popular Prefixes">
<t>
Broadly speaking, a Popular Prefix is any prefix that does not have
to be FIB-installed, but should never-the-less be FIB-installed.
For instance:
<t><list style="hanging">
<t>
Prefixes for customer networks should be installed (so that traffic
to customers does not incur the extra delay associated with the
detour through an APR).
Since customer routes are in any event tagged with a community
attribute for routing policy reasons, the decision to FIB-install
them is entirely local and requires no standardization.
</t>
<t>
If an ASBR chooses its external peer as a next-hop for a given
prefix, then it should FIB-install that prefix.
</t>
</list></t>
</t>
<t>
Prefixes to which there is a large volume of traffic should
also be FIB-installed. This is to reduce the additional load
the results from the extra hop(s) that packets must take on
the APR detour.
Installing these prefixes is not trivial. The volume
of traffic must be measured, the high-volume prefixes identified,
and routers configured to FIB-install these prefixes.
Furthermore, the router where the prefix must be FIB-installed is
typically different from where the high-volume is measured.
Normally, the highest volume for any given prefix will be seen
at the egress routers for that prefix. However, the ingress
router is where FIB installation should take place.
</t>
<t>
The proposal is to identify high-volume prefixes at ASBRs and RRs
(routers that forward iBGP updates), and to tag routes to these
prefixes with
a community attribute that effectively means "should FIB-install".
How to identify high-volume prefixes is a local matter, but one
way would be by examining netflow records from the router.
In principle, however, a router could internally detect high-volume
prefixes.
Identification of high-volume prefixes need only be done for either:
<t><list style="numbers">
<t>
Outgoing traffic on ASBRs peering with non-customer
networks (peers or transits).
</t>
<t>
Route Reflectors, probably limited to traffic that is routed towards
the edge.
</t>
</list></t>
</t>
<t>
Either way, the set of routers where this identification must take place
is limited.
</t>
<section anchor="sec-op-should" title="Operation of the should-install tag">
<section anchor="sec-op-send" title="Sending the should-install tag">
<t>
For routers implementing this optional feature,
it must be possible to configure a router to attach the community
attribute (the "should-install
tag") to routes for a given prefix.
In practice, this may be automatically done by the system that receives
and analyzes netflow records, or it may be done manually by a network
administrator.
Once configured as such, the router must attach the should-install
tag to BGP updates containing the prefix.
The update may be
generated immediately after the configuration takes place,
or it may be put off until the next time the update is normally transmitted.
</t>
<t>
If the configuration is removed, the router must not attach the
should-install tag to subsequent updates containing the prefix.
An update without the should-install tag may be
generated immediately after the configuration is removed,
or it may be put off until the next time the update is normally transmitted.
</t>
</section> <!-- "sec-op-send" -->
<section anchor="sec-op-receive" title="Receiving the should-install tag">
<t>
If the best-path route to a given prefix
(that doesn't otherwise have to be FIB-installed),
has the should-install
tag, then the router locally decides whether or not to
FIB-install the prefix. If there is no room in the FIB for a new prefix,
the router may choose to remove an existing FIB entry (for instance,
the oldest entry) to make room for the new entry.
</t>
</section> <!-- "sec-op-receive" -->
</section> <!-- "sec-op-should" -->
<section anchor="sec-should-discuss" title="Discussion">
<t>
The time-frame over which should-install tags are attached and
removed should be quite long, at least hours if not days.
Evidence shows that high-volume prefixes tend to stay high-volume
on average over long periods of times (days or even weeks)
<xref target="nsdi09"></xref>.
</t>
<t>
There are a number of limited
scenarios whereby a should-install tag is
not successfully conveyed to all routers in an AS.
This does not result in non-delivery of packets, only
inefficiencies.
</t>
<t>
Consider the case where an AS is using Route Reflectors (RRs), and
is using ASBRs to transmit should-install tags.
Imagine two ASBRs, BR1 and BR2, that advertise routes to some prefix
P.
Further, both BR1 and BR2 are clients of the same RR.
Assume that there is high-volume to prefix P at BR1 but not at BR2.
As a result, BR1 attaches the should-install tag and BR2 does not.
If the RR for any reason prefers the route via BR2 over BR1, then
it the should-install tag will not be passed on by the RR.
(Although note that a likely outcome of this is that BR2 will start
to see high volumes of traffic to P, and eventually will set the
should-install tag.)
</t>
<t>
Next consider the same topology as above (BR1 and BR2 both clients
of the same RR), but now assume that it is the RR that is
used to transmit should-install tags.
Assume that the RR detects high-volume to prefix P and attaches
the should-install tag for routes to P.
Assume that both BR1 and BR2 choose their respective external peers
as the next hop to P, and of course advertise this next hop to
the RR.
The RR selects and advertises a best path, say via BR1.
When the RR advertises this best path to BR2, BR2 ignores it
and so does not FIB-install the route.
The end result here is that packets detour through an APR and
then are tunneled back to the ASBR.
(Though as mentioned earlier in this section, prefixes where the
next hop is an external peer should
be FIB-installed as a matter of local policy.)
</t>
</section> <!-- "sec-should-discuss" -->
</section> <!-- "sec-popular" -->
<section anchor="sec-config-vp" title="Config of the VP list">
<t>
As the current VA specification stands,
routers have to know which prefixes they must FIB-install and
and which they need not FIB-install. The VP-list tells them this: they must
FIB-install routes to VPs, and they need not FIB-install routes
to prefixes that fall within VPs for which they are not an APR.
The same VP-list must be installed in every router
(though it is not a problem that they differ for brief periods during
modification of the VP-list).
Configuration of the VP-list is not nearly as hard as configuration
of popular prefixes, but it is nevert-the-less a significant
task that we'd just as soon do without.
</t>
<t>
There are two basic approaches to automating this configuration.
One is to have APRs tag the routes to VPs that they originate,
and let routers effectively reconstruct
the VP-list from these tags.
This approach has the advantage that no configuration what-so-ever
is required to solve the problem.
</t>
<t>
The other is to have ASBRs
tag the routes that need not be installed.
This can be done by configuring a list of one or more "VP-ranges"
in the ASBRs.
This is simpler than the current configured VP-list approach in
two regards. First, fewer routers need to be configured (only
ASBRs interfacing with peer and provider (non-customer) networks.
Second, the VP-range is simpler than the VP-list. In most cases,
once an ISP is past its initial VA roll-out phase, it would consist
of a single 0/0 entry.
</t>
<t>
These two approaches are discussed in the following sections.
</t>
<section anchor="sec-vp-tag" title="VP-route tag">
<t>
Routers that receive a route with the communities attribute indicating
the VP-route tag must FIB-install the associated prefix (VP).
They may FIB-suppress any sub-prefixes that fall within the VP.
</t>
<t>
Prefixes that do not fall within any known VP must be FIB-installed.
During BGP initialization (i.e. before the End-of-RIB marker is
received <xref target="RFC4724"></xref>), however,
the full set of VPs is not yet known.
Therefore, what routers do with prefixes that do not fall within any known
VP during initialization is a local matter.
</t>
<t>
There are two basic strategies, install by default and suppress
by default. Each has pros and cons, though the latter is generally
prefered.
With install by default, some prefixes will be installed only to be
removed later (when the parent VP is learned).
This can actually ultimately
slow down convergence, since it takes time to modify the FIB.
Also, this could result in the FIB filling up with entries.
</t>
<t>
The problem with suppress by default is that entries that ultimately
will be installed are not immediately installed. Instead, they are
installed only after the End-of-RIB marker.
This approach, however, does avoid the pitfalls of install by default,
and ultimately could converge faster because FIB churn
is avoided.
There are also several mitigating factors that should make suppress
by default work well in practice.
First, if the router uses Graceful Restart
<xref target="RFC4724"></xref>,
then in any event forwarding can continue to take place even when the
BGP session is restarted.
Second, the router can have a policy whereby prefixes with a
should-install tag are automatically installed.
In this way, high-volume prefixes are installed and so most traffic
will in fact be forwarded by the End-of-RIB.
Finally, if the router has a policy that customer prefixes are
always installed, then flows between customers are also correctly
forwarded by the End-of-RIB.
</t>
<t>
Another issue with the VP-route tag is what to do if all APRs for
a given VP stop operating (i.e. crash) and so all VP routes are
withdrawn.
Strictly speaking, the router would immediately start installing
the sub-prefixes within that VP.
This could lead to the FIB filling up.
Also, if the APR is thrashing (going up and down), then all routers in the
AS could end up repeatedly adding and removing the same set of
prefixes.
</t>
<t>
How to deal with this is a local matter.
There are two questions the router must answer:
<t><list style="numbers"> <!-- or hanging -->
<t>
How should hysteresis be applied to the (implicit) VP list to avoid FIB churn?
</t>
<t>
How are FIB entries prioritized in the case where the FIB is full?
</t>
</list></t>
</t>
<t>
Regarding VP list hysteresis, perhaps the simplest thing to do is to
use standard route flap damping on the VP routes
<xref target="RFC2439"></xref>.
Alternatively, the router could simply not install sub-prefixes for
a recently known VP for some period of time (minutes) after which the
VP route was withdrawn, or only install sub-prefixes slowly (to minimize
the impact of churn).
</t>
<t>
Regarding FIB entry prioritization, routers must in any event install
VP routes and sub-prefixes within the VPs for which the router is an APR.
If the FIB does not have room for at least these entries, then VA has
simply been configured incorrectly in the AS, and the administrator must
fix this.
Beyond these necessary FIB entries, prioritization is a local matter.
A reasonable prioritization, however,
is the following: 1) customer routes, 2) routes with should-install tag,
3) routes for sub-prefixes of recently withdrawn VPs, 4) other.
</t>
</section> <!-- "sec-vp-tag" -->
<section anchor="sec-can-install-tag" title="Can suppress tag">
<t>
With this approach, some set of ASBRs are configured
with a "VP range".
This is the ranges of IP address that are covered by all VPs.
In a mature deployment of VA, the range would amount to all IP
addresses, in which case the VP range is simply 0/0.
Early in VA deployment, when an ISP is still in the testing
or roll-out phase, the VP range would consist of multiple entries.
At a minimum, the set of ASBRs so configured are those with peers
in peer or transit ASes.
If the AS has a policy that customer routes are always FIB-installed,
then it is not necessary to configure routers that connect to customer
ASes.
</t>
<t>
VP-range configured ASBRs must
tag any route whose prefix falls within the VP range
with a "can-suppress" tag, with the following exceptions:
<t><list style="numbers"> <!-- or hanging -->
<t>
Routers must never tag a VP route with can-suppress.
</t>
<t>
If the ISP has a policy of FIB-installing customer routes, then routes
received from customers should not be tagged with can-suppress.
</t>
</list></t>
</t>
<t>
A router receiving a route with a can-suppress tag first determines
if it must FIB-install the prefix.
It would have to do this for instance
if the prefix falls within a VP for which it is an APR.
If the router does not have to install the prefix, then it may
suppress the prefix at its own discretion.
</t>
<t>
When the can-suppress approach is used, then routers must FIB-install
any prefixes not tagged as can-suppress.
The primary reason for this is so that VP routes are always installed.
</t>
<t>
Note that in the case where all VP routes for a given VP are withdrawn,
routers would not be able to FIB-install the (now unreachable) sub-prefixes.
This is because, with the can-suppress approach, routers do not actually
know which routes are VPs.
</t>
</section> <!-- "sec-can-install-tag" -->
</section> <!-- "sec-config-vp" -->
<section anchor="sec-iana" title="IANA Considerations">
<t>
IANA must assign type values for the Extended Communities Attributes
that convey the tags.
</t>
</section>
<section anchor="sec-consider" title="Security Considerations">
<t>
As of this writing, there are no known new security threats
introduced by this draft.
</t>
</section>
</middle>
<back>
<references title='Normative References'>&rfc2119;
<reference anchor='I-D.ietf-grow-va'>
<front>
<title>FIB Suppression with Virtual Aggregation</title>
<author initials='P' surname='Francis' fullname='Paul Francis'>
<organization />
</author>
<author initials='X' surname='Xu' fullname='Xiaohu Xu'>
<organization />
</author>
<author initials='H' surname='Ballani' fullname='Hitesh Ballani'>
<organization />
</author>
<author initials='D' surname='Jen' fullname='Dan Jen'>
<organization />
</author>
<author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
<organization />
</author>
<author initials='L' surname='Zhang' fullname='Lixia Zhang'>
<organization />
</author>
<date month='May' day='23' year='2009' />
<abstract><t>The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers, easily by an order of magnitude with negligible increase in path length and load. FIB suppression deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-grow-va-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-grow-va-00.txt' />
</reference>
% <reference anchor='RFC1997'>
%
% <front>
% <title>BGP Communities Attribute</title>
% <author initials='R.' surname='Chandrasekeran' fullname='Ravishanker Chandrasekeran'>
% <organization>cisco Systems, Inc.</organization>
% <address>
% <postal>
% <street>170 W. Tasman Dr.</street>
% <city>San Jose</city>
% <region>CA</region>
% <code>95134</code>
% <country>US</country></postal>
% <email>rchandra@cisco.com</email></address></author>
% <author initials='P.' surname='Traina' fullname='Paul Traina'>
% <organization>cisco Systems, Inc.</organization>
% <address>
% <postal>
% <street>170 W. Tasman Dr.</street>
% <city>San Jose</city>
% <region>CA</region>
% <code>95134</code>
% <country>US</country></postal>
% <email>pst@cisco.com</email></address></author>
% <author initials='T.' surname='Li' fullname='Tony Li'>
% <organization />
% <address>
% <email>tli@skat.usc.edu</email></address></author>
% <date year='1996' month='August' />
% <abstract>
% <t>Border Gateway Protocolis an inter-autonomous system routing protocol designed for TCP/IP internets. This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet.</t></abstract></front>
%
% <seriesInfo name='RFC' value='1997' />
% <format type='TXT' octets='8275' target='ftp://ftp.isi.edu/in-notes/rfc1997.txt' />
% </reference>
%
<reference anchor='RFC4360'>
<front>
<title>BGP Extended Communities Attribute</title>
<author initials='S.' surname='Sangli' fullname='S. Sangli'>
<organization /></author>
<author initials='D.' surname='Tappan' fullname='D. Tappan'>
<organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<date year='2006' month='February' />
<abstract>
<t>This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4360' />
<format type='TXT' octets='24145' target='ftp://ftp.isi.edu/in-notes/rfc4360.txt' />
</reference>
<reference anchor='RFC4724'>
<front>
<title>Graceful Restart Mechanism for BGP</title>
<author initials='S.' surname='Sangli' fullname='S. Sangli'>
<organization /></author>
<author initials='E.' surname='Chen' fullname='E. Chen'>
<organization /></author>
<author initials='R.' surname='Fernando' fullname='R. Fernando'>
<organization /></author>
<author initials='J.' surname='Scudder' fullname='J. Scudder'>
<organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<date year='2007' month='January' />
<abstract>
<t>This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.</t><t> The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4724' />
<format type='TXT' octets='32343' target='ftp://ftp.isi.edu/in-notes/rfc4724.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC2439'>
<front>
<title>BGP Route Flap Damping</title>
<author initials='C.' surname='Villamizar' fullname='Curtis Villamizar'>
<organization>ANS</organization>
<address>
<email>curtis@ans.net</email></address></author>
<author initials='R.' surname='Chandra' fullname='Ravi Chandra'>
<organization>Cisco Systems</organization>
<address>
<email>rchandra@cisco.com</email></address></author>
<author initials='R.' surname='Govindan' fullname='Ramesh Govindan'>
<organization>ISI</organization>
<address>
<email>govindan@isi.edu</email></address></author>
<date year='1998' month='November' />
<area>Routing</area>
<keyword>border gateway protocol</keyword>
<keyword>BGP</keyword>
<keyword>routing</keyword>
<abstract>
<t>
A usage of the BGP routing protocol is described which is capable of
reducing the routing traffic passed on to routing peers and therefore
the load on these peers without adversely affecting route convergence
time for relatively stable routes. This technique has been
implemented in commercial products supporting BGP. The technique is
also applicable to IDRP.
</t>
<t>
The overall goals are:
<list>
<t>
o to provide a mechanism capable of reducing router processing load
caused by instability
</t>
<t>
o in doing so prevent sustained routing oscillations
</t>
<t>
o to do so without sacrificing route convergence time for generally
well behaved routes.
</t></list></t>
<t>
This must be accomplished keeping other goals of BGP in mind:
<list>
<t>
o pack changes into a small number of updates
</t>
<t>
o preserve consistent routing
</t>
<t>
o minimal addition space and computational overhead
</t></list></t>
<t>
An excessive rate of update to the advertised reachability of a
subset of Internet prefixes has been widespread in the Internet.
This observation was made in the early 1990s by many people involved
in Internet operations and remains the case. These excessive updates
are not necessarily periodic so route oscillation would be a
misleading term. The informal term used to describe this effect is
"route flap". The techniques described here are now widely deployed
and are commonly referred to as "route flap damping".
</t></abstract></front>
<seriesInfo name='RFC' value='2439' />
<format type='TXT' octets='86376' target='ftp://ftp.isi.edu/in-notes/rfc2439.txt' />
<format type='HTML' octets='101394' target='http://xml.resource.org/public/rfc/html/rfc2439.html' />
<format type='XML' octets='86783' target='http://xml.resource.org/public/rfc/xml/rfc2439.xml' />
</reference>
<reference anchor="nsdi09">
<front>
<title>Making Routers Last Longer with ViAggre</title>
<author initials="H" surname="Ballani" fullname="Hitesh Ballani">
<organization />
</author>
<author initials="P" surname="Francis" fullname="Paul Francis">
<organization />
</author>
<author initials="T" surname="Cao" fullname="Tuan Cao">
<organization />
</author>
<author initials="J" surname="Wang" fullname="Jia Wang">
<organization />
</author>
<date month="April" day=" " year="2009" />
</front>
<seriesInfo name="ACM Usenix NSDI 2009" value="http://www.usenix.org/events/nsdi09/tech/full_papers/ballani/ballani.pdf" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 18:27:25 |