draft-ietf-grow-simple-va-09.txt   draft-ietf-grow-simple-va-10.txt 
GROW Working Group R. Raszuk GROW Working Group R. Raszuk
Internet-Draft NTT MCL Internet-Draft NTT MCL
Intended status: Informational J. Heitz Intended status: Informational J. Heitz
Expires: December 7, 2012 Ericsson Expires: January 6, 2013 Ericsson
A. Lo A. Lo
Arista Arista
L. Zhang L. Zhang
UCLA UCLA
X. Xu X. Xu
Huawei Huawei
June 5, 2012 July 5, 2012
Simple Virtual Aggregation (S-VA) Simple Virtual Aggregation (S-VA)
draft-ietf-grow-simple-va-09.txt draft-ietf-grow-simple-va-10.txt
Abstract Abstract
The continued growth in the Default Free Routing Table (DFRT) All BGP routers in the Default Free Zone (DFZ) are required to carry
stresses the global routing system in a number of ways. One of the all the routes in the Default Free Routing Table (DFRT). A technique
most costly stresses is Forwarding Information Base (FIB) size: ISPs is described that allows some BGP routers not to install all of those
often must upgrade router hardware simply because the FIB has run out routes into the Forwarding Information Base (FIB).
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 Some routers in an Autonomous System (AS) announce an aggregate (the
loading selected RIB entries into the FIB. Simple Virtual VA prefix) in addition to the routes they already announce. This
Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that enables other routers not to install the routes covered by the VA
allows any and all edge routers to shrink their RIB and FIB prefix into the FIB as long as those routes have the same next-hop as
requirements substantially and therefore increase their useful the VA prefix.
lifetime.
S-VA does not increase FIB requirements for core routers. S-VA is The VA prefixes that are announced within an AS are not announced to
extremely easy to configure considerably more so than the various any other AS.
tricks done today to extend the life of edge routers. S-VA can be
deployed autonomously by an ISP (cooperation between ISPs is not
required), and can co-exist with legacy routers in the ISP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 7, 2012. This Internet-Draft will expire on January 6, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5 1.2. Requirements notation . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment considerations . . . . . . . . . . . . . . . . . . 8 3. Deployment considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
ISPs today manage constant Default Free Routing Table (DFRT) growth A technique called Simple Virtual Aggregation (S-VA) is described.
in a number of ways. One way, of course, is for ISPs to upgrade It allows some routers not to have to store some routes in the
their router hardware before DFRT growth outstrips the size of the Forwarding Information Base (FIB) while still advertising and
FIB. This is too expensive for many ISPs. They would prefer to receiving the full Default Free Routing Table (DFRT) in BGP.
extend the lifetime of routers whose FIBs can no longer hold the full
DFRT.
A common approach taken by lower-tier ISPs is to default route to
their providers. Routes to customers and peer ISPs are maintained,
but everything else defaults to the provider. This approach has
several disadvantages. First, packets to Internet destinations may
take longer-than-necessary AS paths.
This problem can be mitigated through careful configuration of
partial defaults, but this can require substantial configuration
overhead. A second problem with defaulting to providers is that the
ISP is no longer able to provide the full DFRT to its customers.
Finally, provider defaults prevents the ISP from being able to detect
martian packets. As a result, the ISP transmits packets that could
otherwise have been dropped over its expensive provider links.
An alternative is for the ISP to maintain full routes in its core
routers, but to filter routes from edge routers that do not require a
full DFRT. These edge routers can then default route to the core or
exit routers. This is often possible with edge routers that
interface to customer networks. The problem with this approach is
that it cannot be used for all edge routers. For instance, it cannot
be used for routers that connect to transits. It should also not be
used for routers that connect to customers which wish to receive the
full DFRT.
This draft describes a very simple technique, called Simple Virtual
Aggregation (S-VA), that allows any and all edge routers to have
substantially reduced FIB requirements even while still advertising
and receiving the full DFRT over BGP. The basic idea is as follows.
Core routers in the ISP maintain the full DFRT in the FIB and RIB.
Edge routers maintain the full DFRT in the BGP protocol RIB, but
suppress certain routes from being installed in RIB and FIB tables.
Edge routers may install a default route to core routers, to ABRs
which are installed on the Point of Presence (POP) to core boundary
or to the ASBR routers.
S-VA requires no changes to BGP and no changes to any choice of A typical scenario is as follows. Core routers in the ISP maintain
forwarding mechanisms in routers. Configuration is extremely simple: the full DFRT in the FIB and RIB. Edge routers maintain the full
S-VA must be enabled on the edge router which needs to save its RIB DFRT in the BGP Loc-RIB, but do not install certain routes in the RIB
and FIB space. In the same time operator must inject into his intra- and FIB. Edge routers may install a default route to core routers,
domain routing a new prefix further called virtual aggregate (VA- to Area Border Routers (ABR) which are installed on the Point of
prefix) which will be used as the aggregate forwarding reference by Presence (POP), to core boundary routers or to Autonomous System
the edge routers performing S-VA. Everything else is automatic. Border Routers (ASBR).
ISPs can deploy FIB suppression autonomously and with no coordination
with neighbor ASes.
In configurations where BGP routes are used to resolve other routes S-VA must be enabled on an edge router that needs to save its RIB and
or where BGP routes are redistributed to other protocols which both FIB space. The core routers must announce a new prefix called
happen via RIB simple-va can rather then suppressing routes before virtual aggregate (VA-prefix).
they are installed in global RIB flag them as "suppress eligible".
That will allow for seamless route resolution or redistribution while
in the same time FIB size will continue to be limited as previously
flagged routes will not be send from RIB to FIB.
1.1. Scope of this Document 1.1. Scope of this Document
The scope of this document is limited to Intra-domain S-VA operation. The VA-prefix is not intended to be announced from one AS into
In other words, the case where a single ISP autonomously operates another, only between routers of the same AS.
S-VA internally without any coordination with neighboring ISPs.
Note that this document assumes that the S-VA "domain" (i.e. the unit
of autonomy) is the AS (that is, different ASes run S-VA
independently and without coordination). For the remainder of this
document, the terms ISP, AS, and domain are used interchangeably.
This document applies equally to IPv4 and IPv6 both unicast and
multicast address families.
S-VA may operate with a mix of upgraded routers and legacy routers. S-VA can be used for IPv4 and IPv6 both unicast and multicast address
There are no topological restrictions placed on the mix of routers. families.
S-VA functionality is local to the router on which it is enabled and
routing correctness is guaranteed.
Note that S-VA is a greatly simplified variant of "full VA" S-VA need not operate on every router in an AS.
[I-D.ietf-grow-va]. With full VA, all routers (core or otherwise)
can have reduced FIBs. However, full VA requires substantial new
configuration and operational complexity compared to S-VA. Full VA
also requires the use of MPLS LSPs between all routers. Note that
S-VA was formerly specified in [I-D.ietf-grow-va]. It has been moved
to this separate draft to simplify its understanding.
1.2. Requirements notation 1.2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Terminology 1.3. Terminology
RIB/FIB-Installing Router (FIR): An router that does not suppress RIB/FIB-Installing Router (FIR): A router that does not suppress any
any routes, and advertises itself as a default route for 0/0. routes and announces the VA-prefix. Typically a core router, a
Typically a core router, POP to core boundary router or an ASBR POP to core boundary router or an ASBR would be configured as an
would be configured as an FIR. FIR.
RIB/FIB-Suppressing Router (FSR): An S-VA router that installs a RIB/FIB-Suppressing Router (FSR): An S-VA router that installs the
route to 0/0, and may suppress other routes. Typically an edge VA-prefix, and does not install into its FIB routes that are
router would be configured as an FSR. covered by and have the same next-hop as the VA-prefix. Typically
Install and Suppress: The terms "install" and "suppress" are used to an edge router would be configured as an FSR.
describe whether a protocol local RIB entry has been loaded or not
loaded into the global RIB and FIB. In other words, the phrase Suppress: Not to install a route that is covered by the VA-prefix
"install a route" means "install a route into the global RIB and into the global RIB or FIB
FIB", and the phrase "suppress a route" means "do not install a
route from BGP into the global RIB and FIB".
Legacy Router: A router that does not run S-VA, and has no knowledge Legacy Router: A router that does not run S-VA, and has no knowledge
of S-VA. of S-VA.
Global Routing Information Base (RIB): The term global RIB is used Global Routing Information Base (RIB): All the routing protocols in
to indicate the router's main routing information base. That RIB a router install their selected routes into the RIB. The routes
is normally used to populate FIB tables of the router. It needs in the RIB are used to resolve next-hops for other routes, to be
to be highlighted that unless FIB compression is used global RIB redistributed to other routing protocols and to be installed into
and FIB tables are in sync. the FIB.
Local/Protocol Routing Information Base (loc-RIB): The term local Local/Protocol Routing Information Base (loc-RIB): The Loc-RIB
RIB is used to indicate the protocol's table where product of SPF contains the routes that have been selected by the local BGP
or BGP best path selection is kept before being installed in speaker's Decision Process as in [RFC4271].
global RIB. For example, in some protocol implementations BGP NLRI: Network Layer Reachability Information [RFC4271]
loc-RIB can be further divided into Adj-RIBs-In, the Loc-RIB, and
the Adj-RIBs-Out.
2. Operation of S-VA 2. Operation of S-VA
There are three types of routers in S-VA, FIB-Installing routers There are three types of routers in S-VA, FIB-Installing routers
(FIR), FIB-Suppressing routers (FSR), and optionally legacy routers. (FIR), FIB-Suppressing routers (FSR) and optionally, legacy routers.
While any router can be an FIR or an FSR (there are no topology While any router can be an FIR or an FSR, the simplest form of
constraints), the most simple form of deployment is for AS border or deployment is for AS border routers to be configured as FIRs and for
POP border routers to be configured as FIRs, and for customer facing customer facing edge routers to be configured as FSRs.
edge routers respectively in the AS or in the POP to be configured as
FSRs.
There are two basic network deployment scenarios for S-VA - with and
without presence of a default route. In both cases simple VA
operates in an identical way however when default route is found and
is eligible to become a less specific prefix by router's
configuration the S-VA may use it. That should not prevent detection
of any other potential prefix with different next hop as the next hop
of default route.
In the event of FIRs originating a default BGP route to NLRI 0/0 When a FIR announces a VA-prefix, it sets the path attributes as
[RFC4271]. The ORIGIN is set to INCOMPLETE (value 2) and the BGP follows: The ORIGIN MUST be set to INCOMPLETE (value 2). The
NEXT_HOP is set to match the other BGP routes which are also NEXT_HOP MUST be set to the same as that of the routes which are
advertised by said FIR. The ATOMIC_AGGREGATE and AGGREGATOR intended to be covered by the VA-prefix. The ATOMIC_AGGREGATE and
attributes are not included. The FIR MUST attach a NO_EXPORT AGGREGATOR attributes SHOULD NOT be included. The FIR MUST attach a
Community Attribute [RFC1997] to the default route. NO_EXPORT Community Attribute [RFC1997]. The NLRI SHOULD be 0/0.
FIRs should not FIB-suppress any routes. They may, however, still A FIR SHOULD NOT FIB-suppress any routes.
use some form of local FIB compression algorithm if deemed necessary.
FSRs must detect the VA prefix or prefixes (including 0/0) and An FSR must detect the VA-prefix or prefixes (including 0/0) and
install it both in loc-RIB, RIB and FIB. Following that FSR may install them in all of Loc-RIB, RIB and FIB. The FSR MAY suppress
suppress any more specific routes which carry the same next hop as any more specific routes that carry the same next-hop as the VA-
the VA prefix. To guarantee semantical correctness FSR by default prefix.
should also be able to detect installation of not matching next hop
route and reinstall all the more specifics which were previously
eligible for suppression to maintain semantical forwarding
correctness.
Generally, any more specific route which carries the same next hop as Generally, any more specific route which carries the same next-hop as
the VA-prefix is eligible for suppression. However, provided that the VA-prefix is eligible for suppression. However, provided that
there was at least one less specific prefix with different next hop there is at least one less specific prefix with different next-hop
between VA-prefix and the prefixes which got suppressed then all between the VA-prefix and the suppressed prefixes then those
previously suppressed prefixes must be reinstalled. suppressed prefixes must be reinstalled.
Similarly when IBGP multipath is enabled and when multiple VA For example, consider 3 prefixes. VA-prefix is the least specific
prefixes are detected which are multipath candidates under given and covers prefix2. prefix2 is less specific than prefix3 and covers
network condition only those more specific prefixes are subject to it. Like Russian dolls. If they all have the same next-hop, then
suppression which have the identical set of next hops as multipath you can just send the biggest one with all the others inside.
set of VA prefixes. However, if the middle one, prefix2 has a different next-hop, then
you have to take it out and send it separately. However, you must
remember to take out the smallest doll, prefix3 and also send it
separately.
We illustrate the expected behavior on the figure below. This figure Similarly, when IBGP multipath is enabled and when multiple VA
shows an autonomous system with a FIR FIR1 and an FSR FSR1. FSR1 is prefixes form a multipath, only those more specific prefixes of which
an ASBR and is connected to two remote ASBRs, EP1 and EP2. the set of next-hops are identical to the set of next-hops of the VA-
prefix multipath are subject to suppression.
The expected behavior is illustrated in Figure 1. This figure shows
an autonomous system with a FIR FIR1 and an FSR FSR1. FSR1 is an
ASBR and is connected to two external ASBRs, EP1 and EP2.
+------------------------------------------+ +------------------------------------------+
| Autonomous System | +----+ | Autonomous System | +----+
| | |EP1 | | | |EP1 |
| /---+---| | | /---+---| |
| To ----\ +----+ +----+ / | +----+ | To ----\ +----+ +----+ / | +----+
| Other \|FIR1|----------|FSR1|/ | | Other \|FIR1|----------|FSR1|/ |
|Routers /| | | |\ | |Routers /| | | |\ |
| ----/ +----+ +----+ \ | +----+ | ----/ +----+ +----+ \ | +----+
| \---+---|EP2 | | \---+---|EP2 |
| | | | | | | |
| | +----+ | | +----+
+------------------------------------------+ +------------------------------------------+
Figure 1
Suppose that FSR1 has been enabled to perform S-VA. Originally it Suppose that FSR1 has been enabled to perform S-VA. Originally it
receives all routes from FIR1 (doing next hop self) as well as receives all routes from FIR1 (doing next-hop-self) as well as from
directly connected EBGP peers EP1 and EP2. FIR1 now will advertise a EP1 and EP2. FIR1 now will advertise a VA prefix 0/0 with next-hop
VA prefix 0/0 with next hop set to himself. That will trigger set to itself. That will cause FSR1 to suppress all routes with the
detection of such prefix on FSR1 and suppression all routes which same next-hop as the VA-prefix. However, FSR1 will not suppress any
have the same next hop as VA prefix and which otherwise would be routes received from EP1 and EP2, because their next-hops are
installed in RIB and FIB. However it needs to be observed that FSR1 different from that of the VA-prefix.
will not suppress any EBGP routes received from his peers EP1 and EP2
due to next hop being different from the one assigned to VA-prefix.
3. Deployment considerations
The simplest deployment model of S-VA is its use within the POP. In
such model the POP to core boundary routers (usually RRs in the data
path) would act as FIRs and would inject VA-prefix 0/0 to all of its
clients within the POP. In such model of operation an observation
can be made that such ABRs do have full routing knowledge and client
to ABR distance is negligible as compared with client to intra-domain
exit distance.
Therefore under the above intra POP S-VA deployment model clients can
be configured that even in the event of lack of ABR to ABR
advertisement symmetry there is still no need to monitor if more
specific unsuppressed route would cover suppressed one. Thus in this
particular deployment model there is no need to detect and reinstall
the previously suppressed ones.
Another deployment consideration should be given to networks which Several FIRs may announce different S-VA prefixes. For example, in a
may utilize route reflection. In the event of enabling IBGP POP, each edge router can announce into the POP an S-VA prefix that
multipath a special care must be taken that both outbound prefixes as covers the addresses of the customers it services.
well as VA-prefixes would pass via said route reflectors to their
clients.
In order to address the above aspects the following solutions could Several FIRs may announce the same S-VA prefix. In this case an FSR
be considered: must choose to install only one of them. For example, two redundant
ASBRs, both of which announce the complete DFRT may each also
announce the default route as an S-VA prefix into the AS.
- Use of intra-POP S-VA S-VA may be used to split traffic among redundant exit routers. For
- Full mesh Small or medium side networks where S-VA can be deployed example, referring to Figure 1, suppose EP1 and EP2 are two redundant
are normally fully meshed and do not use route reflection. It ASBRs that announce the complete DFRT. Each may also announce two
also needs to pointed out that some large networks are also fully S-VA prefixes into the AS: 0/1 and 128/1. EP1 might announce 0/1
meshed today. with higher preference and EP2 might announce 128/1 with higher
- Use of add-paths Use of add-paths new BGP encoding will allow to preference. FIR1 will now install into is FIB 0/1 pointing to EP1
distribute more then one overall best path from RR to each client. and 128/1 pointing to EP2. If either one of EP1 or EP2 were to fail,
then FSR1 would switch the traffic to the other exit router with a
single FIB installation of one S-VA prefix.
- Alternate advertisement of VA-prefix S-VA prefix does not need to 3. Deployment considerations
be advertised in BGP. The BGP suppression will happen as long as
we configure the S-VA with next hop(s) and implementation verifies
that such VA-prefix is installed in the RIB and FIB.
BGP routes may be used to resolve nexthops for static routes or other BGP routes may be used to resolve next-hops for static routes or
BGP routes. Because the default route does not imply reachability of other BGP routes. Because the default route does not imply
any destination, a router can be configured not to resolve nexthops reachability of any destination, a router can be configured not to
using the default route. In this case, simple-va should not suppress resolve next-hops using the default route. In this case, S-VA should
a route that may be used to resolve a nexthop for another route. not suppress from installation into the RIB a route that may be used
to resolve a next-hop for another route. It may still suppress it
from installation into the FIB
Selected BGP routes in the RIB may be redistributed to other Selected BGP routes in the RIB may be redistributed to other
protocols. If they no longer exist in the RIB, they will not be protocols. If they no longer exist in the RIB, they will not be
redistributed. This is especially important when the conditional redistributed. This is especially important when the conditional
redistribution is taking place based on the length of the prefix, redistribution is taking place based on the length of the prefix,
community value etc .. In those cases where redistribution policy is community value etc .. In those cases where redistribution policy is
in place simple-va code should refrain from suppressing prefixes in place S-VA code should refrain from suppressing from installation
matching such policy. into the RIB routes matching such policy. It may still suppress them
from installation into the FIB.
A router may originate a network route or an aggregate route into A router may originate a network route or an aggregate route into
BGP. Some addresses covered by such a route may not exist. If this BGP. Some addresses covered by such a route may not exist. If this
router were to receive a packet for an unreachable address within an router were to receive a packet for an unreachable address within an
originated route, it must not send that packet to the default route. originated route, it must not send that packet to the VA-prefix
There are several ways to achieve this. One is to have the FIR route. There are several ways to achieve this. One is to have the
aggregate the routes instead of the FSR. Another is to install a FIR aggregate the routes instead of the FSR. Another is to install a
blackhole route for the nonexistent addresses on the originating blackhole route for the nonexistent addresses on the originating
router. This issue is not specific to simple-va, but applicable to router. This issue is not specific to S-VA, but applicable to the
the general use of default routes. general use of default routes.
Like any aggregate, an S-VA prefix may include more address space
than the sum of the prefixes it covers. As such, the S-VA prefix may
provide a route for a packet for which no real destination exists.
An FSR will forward such a packet to the FIR.
If an S-VA prefix changes its next-hop or is removed, then many
routes may need to be downloaded into the FIB to achieve convergence.
4. IANA Considerations 4. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
5. Security Considerations 5. Security Considerations
The authors are not aware of any new security considerations due to The authors are not aware of any new security considerations due to
S-VA. S-VA.
skipping to change at page 10, line 17 skipping to change at page 7, line 29
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996. Communities Attribute", RFC 1997, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Protocol 4 (BGP-4)", RFC 4271, January 2006. Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
7.2. Informative References 7.2. Informative References
[I-D.ietf-grow-va] [I-D.ietf-grow-va]
Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation", L. Zhang, "FIB Suppression with Virtual Aggregation",
draft-ietf-grow-va-06 (work in progress), December 2011. draft-ietf-grow-va-06 (work in progress), December 2011.
Authors' Addresses Authors' Addresses
 End of changes. 36 change blocks. 
237 lines changed or deleted 152 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/