draft-ietf-grow-simple-va-02.txt   draft-ietf-grow-simple-va-03.txt 
Network Working Group P. Francis GROW Working Group R. Raszuk
Internet-Draft MPI-SWS Internet-Draft A. Lo
Intended status: Informational X. Xu Intended status: Informational Cisco
Expires: September 3, 2011 Huawei Expires: January 5, 2012 L. Zhang
H. Ballani
Cornell U.
R. Raszuk
Cisco
L. Zhang
UCLA UCLA
March 2, 2011 X. Xu
Huawei
July 4, 2011
Simple Virtual Aggregation (S-VA) Simple Virtual Aggregation (S-VA)
draft-ietf-grow-simple-va-02.txt draft-ietf-grow-simple-va-03.txt
Abstract Abstract
The continued growth in the Default Free Routing Table (DFRT) The continued growth in the Default Free Routing Table (DFRT)
stresses the global routing system in a number of ways. One of the stresses the global routing system in a number of ways. One of the
most costly stresses is FIB size: ISPs often must upgrade router most costly stresses is FIB size: ISPs often must upgrade router
hardware simply because the FIB has run out of space, and router hardware simply because the FIB has run out of space, and router
vendors must design routers that have adequate FIB. FIB suppression vendors must design routers that have adequate FIB.
is an approach to relieving stress on the FIB by NOT loading selected
RIB entries into the FIB. Simple Virtual Aggregation (S-VA) is a FIB suppression is an approach to relieving stress on the FIB by NOT
simple form of Virtual Aggregation (VA) that allows any and all edge loading selected RIB entries into the FIB. Simple Virtual
routers to shrink their FIB requirements substantially and therefore Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that
increase their useful lifetime. S-VA does not change FIB allows any and all edge routers to shrink their RIB and FIB
requirements for core routers. S-VA is extremely easy to requirements substantially and therefore increase their useful
configure---considerably more so than the various tricks done today lifetime.
to extend the life of edge routers. S-VA can be deployed
autonomously by an ISP (cooperation between ISPs is not required), S-VA does not increase FIB requirements for core routers. S-VA is
and can co-exist with legacy routers in the ISP. There are no extremely easy to configure considerably more so than the various
changes from the 01 version to this version. 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 January 5, 2012.
This Internet-Draft will expire on September 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5 1.2. Requirements notation . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Deployment considerations . . . . . . . . . . . . . . . . . . . 7
2.2. Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
ISPs today manage constant DFRT growth in a number of ways. One way, ISPs today manage constant DFRT growth in a number of ways. One way,
of course, is for ISPs to upgrade their router hardware before DFRT of course, is for ISPs to upgrade their router hardware before DFRT
growth outstrips the size of the FIB. This is too expensive for many growth outstrips the size of the FIB. This is too expensive for many
ISPs. They would prefer to extend the lifetime of routers whose FIBs ISPs. They would prefer to extend the lifetime of routers whose FIBs
can no longer hold the full DFRT. can no longer hold the full DFRT.
A common approach taken by lower-tier ISPs is to default route to A common approach taken by lower-tier ISPs is to default route to
their providers. Routes to customers and peer ISPs are maintained, their providers. Routes to customers and peer ISPs are maintained,
but everything else defaults to the provider. This approach has but everything else defaults to the provider. This approach has
several disadvantages. First, packets to Internet destinations may several disadvantages. First, packets to Internet destinations may
take longer-than-necessary AS paths. This problem can be mitigated take longer-than-necessary AS paths.
through careful configuration of partial defaults, but this can
require substantial configuration overhead. A second problem with This problem can be mitigated through careful configuration of
defaulting to providers is that the ISP is no longer able to provide partial defaults, but this can require substantial configuration
the full DFRT to its customers. Finally, provider defaults prevents overhead. A second problem with defaulting to providers is that the
the ISP from being able to detect martian packets. As a result, the ISP is no longer able to provide the full DFRT to its customers.
ISP transmits packets that could otherwise have been dropped over its Finally, provider defaults prevents the ISP from being able to detect
expensive provider links. Simple Virtual Aggregation (S-VA) solves martian packets. As a result, the ISP transmits packets that could
these problems because the full DFRT is used by core routers. otherwise have been dropped over its expensive provider links.
An alternative is for the ISP to maintain full routes in its core 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 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 full DFRT. These edge routers can then default route to the core or
routers. This is often possible with edge routers that interface to exit routers. This is often possible with edge routers that
customer networks. The problem with this approach is that it cannot interface to customer networks. The problem with this approach is
be used for all edge routers. For instance, it cannot be used for that it cannot be used for all edge routers. For instance, it cannot
routers that connect to transits. It should also not be used for be used for routers that connect to transits. It should also not be
routers that connect to customers which wish to receive the full used for routers that connect to customers which wish to receive the
DFRT. full DFRT.
This draft describes a very simple technique, called Simple Virtual This draft describes a very simple technique, called Simple Virtual
Aggregation (S-VA), that allows any and all edge routers to have Aggregation (S-VA), that allows any and all edge routers to have
substantially reduced FIB requirements even while still advertising substantially reduced FIB requirements even while still advertising
and receiving the full DFRT over BGP. The basic idea is as follows. 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. Core routers in the ISP maintain the full DFRT in the FIB and RIB.
Edge routers maintain the full DFRT in the RIB, but suppress certain Edge routers maintain the full DFRT in the BGP protocol RIB, but
routes from the FIB. Edge routers install a default route to core suppress certain routes from being installed in RIB and FIB tables.
routers. Label Switched Paths (LSP) are used to transmit packets Edge routers install a default route to core routers, to ABRs which
from a core router, through the edge router, to the Next Hop remote are installed on the POP to core boundary or to the ASBR routers.
Autonomous System Border Router (ASBR). ASBRs strip the tunnel
header (MPLS or IP) before forwarding tunneled packets to the remote
ASBR (in much the same way MPLS Penultimate Hop Popping (PHP) strips
the LSP header before forwarding packets to the tunnel target).
S-VA requires no changes to BGP and no changes to MPLS forwarding S-VA requires no changes to BGP and no changes to any choice of
mechanisms in routers. Configuration is extremely simple: S-VA must forwarding mechanisms in routers. Configuration is extremely simple:
be enabled, and routers must told whether they are FIB-suppressing S-VA must be enabled on the edge router which needs to save it's RIB
routers or not. Everything else is automatic. ISPs can deploy FIB and FIB space. In the same time operator must inject into his intra-
suppression autonomously and with no coordination with neighbor ASes. domain routing a new prefix further called virtual aggregate (VA-
prefix) which will be used as the aggregate forwarding reference by
the edge routers performing S-VA. Everything else is automatic.
ISPs can deploy FIB suppression autonomously and with no coordination
with neighbor ASes.
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 scope of this document is limited to Intra-domain S-VA operation.
In other words, the case where a single ISP autonomously operates In other words, the case where a single ISP autonomously operates
S-VA internally without any coordination with neighboring ISPs. S-VA internally without any coordination with neighboring ISPs.
Note that this document assumes that the S-VA "domain" (i.e. the unit 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 of autonomy) is the AS (that is, different ASes run S-VA
independently and without coordination). For the remainder of this independently and without coordination). For the remainder of this
document, the terms ISP, AS, and domain are used interchangeably. document, the terms ISP, AS, and domain are used interchangeably.
This document applies equally to IPv4 and IPv6. 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 may operate with a mix of upgraded routers and legacy routers.
There are no topological restrictions placed on the mix of routers. There are no topological restrictions placed on the mix of routers.
In order to avoid loops between upgraded and legacy routers, however, S-VA functionality is local to the router on which it is enabled and
legacy routers must be able to terminate tunnels. routing correctness is guaranteed.
Note that S-VA is a greatly simplified variant of "full VA" Note that S-VA is a greatly simplified variant of "full VA"
[I-D.ietf-grow-va]. With full VA, all routers (core or otherwise) [I-D.ietf-grow-va]. With full VA, all routers (core or otherwise)
can have reduced FIBs. However, full VA requires substantial new can have reduced FIBs. However, full VA requires substantial new
configuration and operational complexity compared to S-VA. Note that 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 S-VA was formerly specified in [I-D.ietf-grow-va]. It has been moved
to this separate draft to simplify its understanding. 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
FIB-Installing Router (FIR): An S-VA router that does not suppress RIB/FIB-Installing Router (FIR): An router that does not suppress
any routes, and advertises itself as a default route for 0/0. any routes, and advertises itself as a default route for 0/0.
Typically a core router or route reflector would be configured as Typically a core router, POP to core boundary router or an ASBR
an FIR. would be configured as an FIR.
FIB-Suppressing Router (FSR): An S-VA router that installs a route RIB/FIB-Suppressing Router (FSR): An S-VA router that installs a
to 0/0, and may suppress other routes. Typically an edge router route to 0/0, and may suppress other routes. Typically an edge
would be configured as an FSR. router would be configured as an FSR.
Install and Suppress: The terms "install" and "suppress" are used to Install and Suppress: The terms "install" and "suppress" are used to
describe whether a RIB entry has been loaded or not loaded into describe whether a protocol local RIB entry has been loaded or not
the FIB. In other words, the phrase "install a route" means loaded into the global RIB and FIB. In other words, the phrase
"install a route into the FIB", and the phrase "suppress a route" "install a route" means "install a route into the global RIB and
means "do not install a route into the 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.
Routing Information Base (RIB): The term RIB is used rather sloppily Global Routing Information Base (RIB): The term global RIB is used
in this document to refer either to the loc-RIB (as used in to indicate the router's main routing information base. That RIB
[RFC4271]), or to the combined Adj-RIBs-In, the Loc-RIB, and the is normally used to populate FIB tables of the router. It needs
Adj-RIBs-Out. to be highlighted that unless FIB compression is used global RIB
and FIB tables are in sync.
Local/Protocol Routing Information Base (loc-RIB): The term local
RIB is used to indicate the protocol's table where product of SPF
or BGP best path selection is kept before being installed in
global RIB. In some protocol's implementations for example BGP
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 (there are no topology
constraints), the simplist form of deployment is for border routers constraints), the most simple form of deployment is for AS border or
to be configured as edge routers, and for non-border routers (for POP border routers to be configured as FIRs, and for customer facing
instance the routers used as route reflectors) to be configured as edge routers respectively in the AS or in the POP to be configured as
core routers. S-VA, however, does not mandate this deployment per FSRs.
se.
FIRs must originate a BGP route to NLRI 0/0 [RFC4271]. The ORIGIN is FIRs must originate a default BGP route to NLRI 0/0 [RFC4271]. The
set to INCOMPLETE (value 2), the AS number of the FIR's AS is used in ORIGIN is set to INCOMPLETE (value 2) and the BGP NEXT_HOP is set to
the AS_PATH, and the BGP NEXT_HOP is set to the router's own address. match the other BGP routes which are also advertised by said FIR.
The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The
FIR MUST attach a NO_EXPORT Communities Attribute [RFC1997] to the FIR MUST attach a NO_EXPORT Community Attribute [RFC1997] to the
route. default route.
FIRs must not FIB-suppress any routes. FIRs should not FIB-suppress any routes. They may, however, still
use some form of local FIB compression algorithm if deemed necessary.
FSRs must FIB-install a route to 0/0. When transmitting a packet to FSRs must detect the VA prefix 0/0 and install it both in loc-RIB,
a FIR (i.e. based on a 0/0 FIB lookup), the packet must be tunneled. RIB and FIB. Following that FSR may suppres any more specific routes
This is to prevent loops that would otherwise occur when a packet which carry the same next hop as the VA prefix. To guarantee
transits multiple FSRs on the way to the core, some of which have semantical correctness FSR by default should also be able to detect
FIB-installed the route for the destination, and others of which have installation of not matching next hop route and reinstall all the
not. FSRs may FIB-install any other routes. They should install any more specifics which were previously eligible for suppression to
routes for which their eBGP neighbor is the NEXT_HOP. There are a maintain semantical forwarding correctness.
couple reasons for this, which can be illustrated in the figure
below. This figure shows an autonomous system with a FIR FIR1 and an Generally, any more specific route which carries the same next hop as
FSR FSR1. FSR1 is an ASBR and is connected to two remote ASBRs, EP1 the VA-prefix 0/0 is eligible for suppression. However, provided
and EP2. that there was at least one less specific prefix (e.g., 1.0.0.0/8)
and the next-hop of such prefix was different from that of the VA
0/0, those more specific prefixes (e.g., 1.1.1.0/24) which are
otherwise subject to suppression would not be eligible for
suppression anymore.
Similarly when IBGP multipath is enabled and when multiple VA
prefixes are detected which are multipath candidates under given
network condition only those more specific prefixes are subject to
suppresion which have the identical set of next hops as multipath set
of VA prefixes.
Let's illustrate the expected behaviour on the figure below. This
figure shows an autonomous system with a FIR FIR1 and an FSR FSR1.
FSR1 is an ASBR and is connected to two remote ASBRs, EP1 and EP2.
+------------------------------------------+ +------------------------------------------+
| Autonomous System | +----+ | Autonomous System | +----+
| | |EP1 | | | |EP1 |
| /---+---| | | /---+---| |
| To ----\ +----+ +----+ / | +----+ | To ----\ +----+ +----+ / | +----+
| Other \|FIR1|----------|FSR1|/ | | Other \|FIR1|----------|FSR1|/ |
|Routers /| | | |\ | |Routers /| | | |\ |
| ----/ +----+ +----+ \ | +----+ | ----/ +----+ +----+ \ | +----+
| \---+---|EP2 | | \---+---|EP2 |
| | | | | | | |
| | +----+ | | +----+
+------------------------------------------+ +------------------------------------------+
Suppose that FSR1 does not FIB-install routes for which EP1 and EP2 Suppose that FSR1 has been enabled to perform S-VA. Originally it
are next hops. In this case, when EP2 sends a packet to FSR1 for receives all routes from FIR1 (doing next hop self) as well as
which the next hop is EP1, FSR1 will first tunnel the packet to FIR1, directly connected EBGP peers EP1 and EP2. FIR1 now will advertise a
which will tunnel it right back to FSR1. This trombone routing is VA prefix 0/0 with next hop set to himself. That will trigger
avoided if local ASBRs FIB-install routes where their neighbor remote detection of such prefix on FSR1 and suppression all routes which
ASBRs are the BGP NEXT_HOP. have the same next hop as VA prefix and which otherwise would be
installed in RIB and FIB. However it needs to be observed that FSR1
In addition, FSR1 cannot filter source addresses using strict unicast will not suppres any EBGP routes received from his peers EP1 and EP2
Reverse Path Forwarding (uRPF) unless it FIB-installs the routes due to next hop being different from the one assinged to VA-prefix.
learned from the remote ASBR. Note, however, that FSRs cannot do
loose uRPF. Rather, this must be done by FIRs.
The above observations lead to the following rules: FSRs that are
ASBRs should FIB-install all routes for which the neighbor is the BGP
NEXT_HOP. FSRs that are ASBRs must FIB-install any routes that are
used for uRPF.
2.1. Tunnels
S-VA works with both MPLS and IP-in-IP tunnels. There are
potentially up to two tunnels required for a packet to traverse an AS
with S-VA. The first tunnel is that from an FSR to a FIR (for the
0/0 default). This is called the default tunnel. The second tunnel
targets the remote ASBR which is the BGP NEXT_HOP, although the
tunnel header is stripped by the local ASBR before transmitting to
the remote ASBR. This is the exit tunnel. The start of the exit
tunnel is an ingress local ASBR in the case where the ingress local
ASBR has FIB-installed the associated route. Otherwise, the start of
the exit tunnel is a FIR.
The target address of the default tunnel is always the FIR. If MPLS
is used, the FIRs must initiate LSPs to themselves using either the
Label Distribution Protocol (LDP) [RFC5036]. RSVP-TE [RFC3209] may
also be used.
If IP-in-IP tunnels are used, then the BGP Encapsulation Extended 3. Deployment considerations
Community (BGPencap-Attribute) ([RFC5512]) is used to convey the
ability to accept tunnels at the target address (the BGP NEXT_HOP).
For the exit tunnels, again either MPLS or IP-in-IP can be used. In The simplest deployment model of S-VA is it's use within the POP. In
the case of IP-in-IP, the inner label defined in [RFC4023] and such model the POP to core boundary routers (usually RRs in the data
signaled in BGP with [RFC3107] is used by the local ASBR to identify path) would act as FIRs and would inject VA-prefix 0/0 to all of it's
the remote ASBR which is the BGP NEXT_HOP for the packet. clients within the POP. In such model of operation an observation
Specifically, when a local ASBR, which can be either an FSR or a FIR, can be made that such ABRs do have full routing knowledge and client
advertises an eBGP-received route into iBGP, it sets the BGP NEXT_HOP to ABR distance is negligable as compared with client to intra-domain
as itself. It assigns a label to the route. This label is used as exit distance.
the inner label in packets tunneled to the local ASBR, and is used to
identify the remote ASBR from which the route was received. When
receiving a packet with this label, the local ASBR strips off the
label, and forwards the native packet to the remote ASBR indicated by
the label.
In the case of MPLS, the inner label may or may not be used. If it Therefor under the above intra POP S-VA deployment model clients can
is used, then an LSP is established to the IP address of the local be configured that even in the event of lack of ABR to ABR
ASBR as described above for FIRs. The BGP NEXT_HOP is set to be advertisement symmetry there is still no need to monitor if more
itself (the same address that serves as the FEC in the LSP). The specific unsuppressed route would cover suppressed one. Thus in this
inner label is established as described in the previous paragraph for particular deployment model there is no need to detect and reinstall
IP-in-IP tunnels, but with the encapsulation defined in [RFC3032]. the previously suppressed ones.
If the inner label is not used, then the local ASBR must initiate a Another deploymet consideration should be given to networks which may
Downstream Unsolicited LSP for each remote ASBR. The FEC for the LSP utilize route reflection. In the event of enabling IBGP multipath a
is the remote ASBR address that is used in the BGP NEXT_HOP field. special care must be taken that both outbound prefixes as well as VA-
When a packet is received on one of these LSPs, the local ASBR strips prefixes would pass via said route reflectors to their clients.
the MPLS header, and forwards the packet to the remote ASBR indicated
by the label.
2.2. Legacy Routers In order to addess the above aspects the following solutions could be
considered:
S-VA may be operated with a mix of legacy and S-VA-upgraded routers. - Use of intra-POP S-VA
The legacy routers, however, must be able to forward tunneled - Full mesh Small or medium side networks where S-VA can be deployed
packets. In the case of MPLS tunnels, this means that they must are normally fully meshed and do not use route reflection. It
fully participate in MPLS signaling. If a legacy router is an ASBR, also needs to pointed out that some large networks are also fully
then it must also initiate tunnels to itself and be able to detunnel meshed today.
packets (without the inner label). - Use of add-paths Use of add-paths new BGP encoding will allow to
distribute more then one overall best path from RR to each client.
- Alternate advertisement of VA-prefix S-VA prefix does not need to
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.
3. IANA Considerations 4. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
4. 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.
5. Acknowledgements 6. Acknowledgements
The concept for S-VA comes from Robert Raszuk. The concept for Virtual Aggregation comes from Paul Francis. In this
document authors only simplified some aspects of it's behaviour to
allow simpler adoption by some operators.
6. Normative References Authors would like to thank Clarence Filsfils for his valuable input.
[I-D.ietf-grow-va] 7. References
Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation", 7.1. Normative References
draft-ietf-grow-va-00 (work in progress), May 2009.
[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.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)",
RFC 4023, March 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 7.2. Informative References
Specification", RFC 5036, October 2007.
[RFC5512] Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and [I-D.ietf-grow-va]
BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009. Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation",
draft-ietf-grow-va-05 (work in progress), June 2011.
Authors' Addresses Authors' Addresses
Paul Francis
Max Planck Institute for Software Systems
Gottlieb-Daimler-Strasse
Kaiserslautern 67633
Germany
Phone: +49 631 930 39600
Email: francis@mpi-sws.org
Xiaohu Xu
Huawei Technologies
No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
Beijing, Beijing 100085
P.R.China
Phone: +86 10 82836073
Email: xuxh@huawei.com
Hitesh Ballani
Cornell University
4130 Upson Hall
Ithaca, NY 14853
US
Phone: +1 607 279 6780
Email: hitesh@cs.cornell.edu
Robert Raszuk Robert Raszuk
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: Phone:
Email: raszuk@cisco.com Email: raszuk@cisco.com
Alton Lo
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Phone:
Email: altonlo@cisco.com
Lixia Zhang Lixia Zhang
UCLA UCLA
3713 Boelter Hall 3713 Boelter Hall
Los Angeles, CA 90095 Los Angeles, CA 90095
US US
Phone: Phone:
Email: lixia@cs.ucla.edu Email: lixia@cs.ucla.edu
Xiaohu Xu
Huawei Technologies
No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
Beijing, Beijing 100085
P.R.China
Phone: +86 10 82836073
Email: xuxh@huawei.com
 End of changes. 41 change blocks. 
229 lines changed or deleted 193 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/