One document matched: draft-ietf-grow-va-auto-03.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-03.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">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="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street> 170 West Tasman Drive</street>
<city> San Jose</city>
<region> CA </region>
<code> 95134 </code>
<country> USA </country>
</postal>
<phone> </phone>
<email>raszuk@cisco.com</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="22" month="February" year="2011"/>
<abstract>
<t>
Virtual Aggregation as specified in
<xref target="I-D.ietf-grow-va"></xref>
requires configuration of a static "VP-List" on all routers.
The VP-List allows routers to know which prefixes may or may not
be FIB-installed.
This draft specified an optional method of determining this that
requires far less configuration.
Specifically, it requires the configuration of a "VP-Range" in
ASBRs connected to transit and peer ISPs.
An Extended Communities Attribute is used to convey to other routers
that a given route can be FIB-suppressed.
This draft has no changes from the 02 draft.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
As the current VA specification stands
(<xref target="I-D.ietf-grow-va"></xref>),
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 Virtual Prefixes (VP),
and they need not FIB-install routes
to prefixes that fall within VPs for which they are not an Aggregation
Point Router (APR).
The same VP-List must be installed in every router.
</t>
<t>
This draft specifies an optional alternative to the VP-List that requires
far less configuration.
Specifically, a list of one or more "VP-Ranges"
is configured in ASBRs --- typically ASBRs that do not connect to
customer networks.
These ASBRs then simply tag routes as to whether the route can be
suppressed.
This is simpler than the current configured VP-List approach in
two regards. First, fewer routers need to be configured.
Second, the VP-Range is simpler than the VP-List.
In most cases,
once an ISP is past its initial VA roll-out phase, the VP-Range consists
of a single 0/0 entry.
</t>
<t>
This draft uses terms defined in
<xref target="I-D.ietf-grow-va"></xref>.
</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-can-suppress-tag" title="Specification">
<t>
With the "VP-Range" approach to determining suppressability, certain
ASBRs are designated as "tagging routers". Tagging routers explicitly
tag routes with an Extended Communities Attribute that indicates
whether the route can be FIB-suppressed.
All ASBRs that connect to one or more transit provider ISPs MUST be tagging
routers.
ASBRs that connect to one or more peer ISPs SHOULD be tagging routers.
ASBRs that connect to customer networks SHOULD NOT be tagging routers.
</t>
<t>
Tagging routers are configured with a "VP-Range" list.
This consists of the ranges of IP address that are collectively
covered by all VPs in the AS.
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 may consist of multiple entries.
</t>
<t>
Tagging routers SHOULD
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>
Tagging routers MUST NOT tag VP routes with can-suppress (where a VP route
is that route to the VP that the router originates in its role as
an APR).
</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>
The can-suppress tag itself is an Extended Communities Attribute
<xref target="RFC4360"></xref> to be assigned by IANA.
The Transitive Bit
MUST be set to value 1 (the community is non-transitive across ASes).
</t>
<t>
Routers install or suppress FIB entries according to the following
rules. Note that tagging routers conceptually follow these rules
after tagging (or not tagging) the route.
Note also that these rules apply only to the route used by the
router as the best route.
In other words, if a router receives two routes for the same
prefix, and one route is tagged can-suppress and the other is not,
the router follows these rules only with respect to the route that
it selects as the best route.
<t><list style="numbers"> <!-- or hanging -->
<t>
Routes without the can-suppress tag MUST be FIB-installed.
</t>
<t>
APRs MUST FIB-install routes for sub-prefixes that fall within
the APR's VPs, whether or not the route is tagged can-suppress.
</t>
<t>
Otherwise, routers MAY FIB-suppress routes tagged as can-suppress.
</t>
</list></t>
</t>
</section> <!-- "sec-can-suppress-tag" -->
<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='Oct' day='25' 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-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-grow-va-01.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>
</references>
<references title='Informative References'>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 18:25:45 |