GROW Working Group R. Raszuk
Internet-Draft A. Lo
Intended status: Informational Cisco
Expires: January 5, 2012 L. Zhang
UCLA
X. Xu
Huawei
July 4, 2011
Simple Virtual Aggregation (S-VA)
draft-ietf-grow-simple-va-03.txt
Abstract
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. Simple Virtual
Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that
allows any and all edge routers to shrink their RIB and FIB
requirements substantially and therefore increase their useful
lifetime.
S-VA does not increase FIB requirements for core routers. S-VA is
extremely easy to configure considerably more so than the various
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
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Raszuk, et al. Expires January 5, 2012 [Page 1]
Internet-Draft S-VA July 2011
This Internet-Draft will expire on January 5, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Raszuk, et al. Expires January 5, 2012 [Page 2]
Internet-Draft S-VA July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5
1.2. Requirements notation . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . . 6
3. Deployment considerations . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Raszuk, et al. Expires January 5, 2012 [Page 3]
Internet-Draft S-VA July 2011
1. Introduction
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
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
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 install a default route to core routers, to ABRs which
are installed on the POP to core boundary or to the ASBR routers.
S-VA requires no changes to BGP and no changes to any choice of
forwarding mechanisms in routers. Configuration is extremely simple:
S-VA must be enabled on the edge router which needs to save it's RIB
and FIB space. In the same time operator must inject into his intra-
domain routing a new prefix further called virtual aggregate (VA-
prefix) which will be used as the aggregate forwarding reference by
Raszuk, et al. Expires January 5, 2012 [Page 4]
Internet-Draft S-VA July 2011
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
The scope of this document is limited to Intra-domain S-VA operation.
In other words, the case where a single ISP autonomously operates
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.
There are no topological restrictions placed on the mix of routers.
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"
[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
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 [RFC2119].
1.3. Terminology
RIB/FIB-Installing Router (FIR): An router that does not suppress
any routes, and advertises itself as a default route for 0/0.
Typically a core router, POP to core boundary router or an ASBR
would be configured as an FIR.
RIB/FIB-Suppressing Router (FSR): An S-VA router that installs a
route to 0/0, and may suppress other routes. Typically an edge
router would be configured as an FSR.
Raszuk, et al. Expires January 5, 2012 [Page 5]
Internet-Draft S-VA July 2011
Install and Suppress: The terms "install" and "suppress" are used to
describe whether a protocol local RIB entry has been loaded or not
loaded into the global RIB and FIB. In other words, the phrase
"install a route" means "install a route into the global RIB and
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
of S-VA.
Global Routing Information Base (RIB): The term global RIB is used
to indicate the router's main routing information base. That RIB
is normally used to populate FIB tables of the router. It needs
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
There are three types of routers in S-VA, FIB-Installing routers
(FIR), FIB-Suppressing routers (FSR), and optionally legacy routers.
While any router can be an FIR or an FSR (there are no topology
constraints), the most simple form of deployment is for AS border or
POP border routers to be configured as FIRs, and for customer facing
edge routers respectively in the AS or in the POP to be configured as
FSRs.
FIRs must originate a default BGP route to NLRI 0/0 [RFC4271]. The
ORIGIN is set to INCOMPLETE (value 2) and the BGP NEXT_HOP is set to
match the other BGP routes which are also advertised by said FIR.
The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The
FIR MUST attach a NO_EXPORT Community Attribute [RFC1997] to the
default route.
FIRs should not FIB-suppress any routes. They may, however, still
use some form of local FIB compression algorithm if deemed necessary.
FSRs must detect the VA prefix 0/0 and install it both in loc-RIB,
RIB and FIB. Following that FSR may suppres any more specific routes
which carry the same next hop as the VA prefix. To guarantee
semantical correctness FSR by default 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.
Raszuk, et al. Expires January 5, 2012 [Page 6]
Internet-Draft S-VA July 2011
Generally, any more specific route which carries the same next hop as
the VA-prefix 0/0 is eligible for suppression. However, provided
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 | +----+
| | |EP1 |
| /---+---| |
| To ----\ +----+ +----+ / | +----+
| Other \|FIR1|----------|FSR1|/ |
|Routers /| | | |\ |
| ----/ +----+ +----+ \ | +----+
| \---+---|EP2 |
| | | |
| | +----+
+------------------------------------------+
Suppose that FSR1 has been enabled to perform S-VA. Originally it
receives all routes from FIR1 (doing next hop self) as well as
directly connected EBGP peers EP1 and EP2. FIR1 now will advertise a
VA prefix 0/0 with next hop set to himself. That will trigger
detection of such prefix on FSR1 and suppression all routes which
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
will not suppres any EBGP routes received from his peers EP1 and EP2
due to next hop being different from the one assinged to VA-prefix.
3. Deployment considerations
The simplest deployment model of S-VA is it's 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 it's
clients within the POP. In such model of operation an observation
Raszuk, et al. Expires January 5, 2012 [Page 7]
Internet-Draft S-VA July 2011
can be made that such ABRs do have full routing knowledge and client
to ABR distance is negligable as compared with client to intra-domain
exit distance.
Therefor 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 deploymet consideration should be given to networks which may
utilize route reflection. In the event of enabling IBGP multipath a
special care must be taken that both outbound prefixes as well as VA-
prefixes would pass via said route reflectors to their clients.
In order to addess the above aspects the following solutions could be
considered:
- Use of intra-POP S-VA
- Full mesh Small or medium side networks where S-VA can be deployed
are normally fully meshed and do not use route reflection. It
also needs to pointed out that some large networks are also fully
meshed today.
- 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.
4. IANA Considerations
There are no IANA considerations.
5. Security Considerations
The authors are not aware of any new security considerations due to
S-VA.
6. Acknowledgements
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.
Raszuk, et al. Expires January 5, 2012 [Page 8]
Internet-Draft S-VA July 2011
Authors would like to thank Clarence Filsfils for his valuable input.
7. References
7.1. Normative References
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
7.2. Informative References
[I-D.ietf-grow-va]
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
Robert Raszuk
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Phone:
Email: raszuk@cisco.com
Alton Lo
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Phone:
Email: altonlo@cisco.com
Raszuk, et al. Expires January 5, 2012 [Page 9]
Internet-Draft S-VA July 2011
Lixia Zhang
UCLA
3713 Boelter Hall
Los Angeles, CA 90095
US
Phone:
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
Raszuk, et al. Expires January 5, 2012 [Page 10]
