draft-ietf-grow-simple-va-08.txt   draft-ietf-grow-simple-va-09.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: November 30, 2012 Ericsson Expires: December 7, 2012 Ericsson
A. Lo A. Lo
Arista Arista
L. Zhang L. Zhang
UCLA UCLA
X. Xu X. Xu
Huawei Huawei
May 29, 2012 June 5, 2012
Simple Virtual Aggregation (S-VA) Simple Virtual Aggregation (S-VA)
draft-ietf-grow-simple-va-08.txt draft-ietf-grow-simple-va-09.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 Forwarding Information Base (FIB) size: ISPs
hardware simply because the FIB has run out of space, and router often must upgrade router hardware simply because the FIB has run out
vendors must design routers that have adequate 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 FIB suppression is an approach to relieving stress on the FIB by NOT
loading selected RIB entries into the FIB. Simple Virtual loading selected RIB entries into the FIB. Simple Virtual
Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that
allows any and all edge routers to shrink their RIB and FIB allows any and all edge routers to shrink their RIB and FIB
requirements substantially and therefore increase their useful requirements substantially and therefore increase their useful
lifetime. lifetime.
S-VA does not increase FIB requirements for core routers. S-VA is S-VA does not increase FIB requirements for core routers. S-VA is
extremely easy to configure considerably more so than the various extremely easy to configure considerably more so than the various
skipping to change at page 2, line 8 skipping to change at page 2, line 10
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 November 30, 2012. This Internet-Draft will expire on December 7, 2012.
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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6
3. Deployment considerations . . . . . . . . . . . . . . . . . . 8 3. Deployment considerations . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
ISPs today manage constant DFRT growth in a number of ways. One way, ISPs today manage constant Default Free Routing Table (DFRT) growth
of course, is for ISPs to upgrade their router hardware before DFRT in a number of ways. One way, of course, is for ISPs to upgrade
growth outstrips the size of the FIB. This is too expensive for many their router hardware before DFRT growth outstrips the size of the
ISPs. They would prefer to extend the lifetime of routers whose FIBs FIB. This is too expensive for many ISPs. They would prefer to
can no longer hold the full DFRT. 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 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. take longer-than-necessary AS paths.
This problem can be mitigated through careful configuration of This problem can be mitigated through careful configuration of
partial defaults, but this can require substantial configuration partial defaults, but this can require substantial configuration
overhead. A second problem with defaulting to providers is that the overhead. A second problem with defaulting to providers is that the
skipping to change at page 4, line 45 skipping to change at page 4, line 46
full 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 BGP protocol RIB, but Edge routers maintain the full DFRT in the BGP protocol RIB, but
suppress certain routes from being installed in RIB and FIB tables. suppress certain routes from being installed in RIB and FIB tables.
Edge routers may install a default route to core routers, to ABRs Edge routers may install a default route to core routers, to ABRs
which are installed on the POP to core boundary or to the ASBR which are installed on the Point of Presence (POP) to core boundary
routers. or to the ASBR routers.
S-VA requires no changes to BGP and no changes to any choice of S-VA requires no changes to BGP and no changes to any choice of
forwarding mechanisms in routers. Configuration is extremely simple: forwarding mechanisms in routers. Configuration is extremely simple:
S-VA must be enabled on the edge router which needs to save its RIB S-VA must be enabled on the edge router which needs to save its RIB
and FIB space. In the same time operator must inject into his intra- and FIB space. In the same time operator must inject into his intra-
domain routing a new prefix further called virtual aggregate (VA- domain routing a new prefix further called virtual aggregate (VA-
prefix) which will be used as the aggregate forwarding reference by prefix) which will be used as the aggregate forwarding reference by
the edge routers performing S-VA. Everything else is automatic. the edge routers performing S-VA. Everything else is automatic.
ISPs can deploy FIB suppression autonomously and with no coordination ISPs can deploy FIB suppression autonomously and with no coordination
with neighbor ASes. with neighbor ASes.
skipping to change at page 6, line 44 skipping to change at page 6, line 44
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 most simple form of deployment is for AS border or constraints), the most simple form of deployment is for AS border or
POP border routers to be configured as FIRs, and for customer facing 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 edge routers respectively in the AS or in the POP to be configured as
FSRs. FSRs.
FIRs must originate a default BGP route to NLRI 0/0 [RFC4271]. The There are two basic network deployment scenarios for S-VA - with and
ORIGIN is set to INCOMPLETE (value 2) and the BGP NEXT_HOP is set to without presence of a default route. In both cases simple VA
match the other BGP routes which are also advertised by said FIR. operates in an identical way however when default route is found and
The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The is eligible to become a less specific prefix by router's
FIR MUST attach a NO_EXPORT Community Attribute [RFC1997] to the configuration the S-VA may use it. That should not prevent detection
default route. 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
[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 FIRs should not FIB-suppress any routes. They may, however, still
use some form of local FIB compression algorithm if deemed necessary. 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, FSRs must detect the VA prefix or prefixes (including 0/0) and
RIB and FIB. Following that FSR may suppress any more specific install it both in loc-RIB, RIB and FIB. Following that FSR may
routes which carry the same next hop as the VA prefix. To guarantee suppress any more specific routes which carry the same next hop as
semantical correctness FSR by default should also be able to detect the VA prefix. To guarantee semantical correctness FSR by default
installation of not matching next hop route and reinstall all the should also be able to detect installation of not matching next hop
more specifics which were previously eligible for suppression to route and reinstall all the more specifics which were previously
maintain semantical forwarding correctness. 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 0/0 is eligible for suppression. However, provided the VA-prefix is eligible for suppression. However, provided that
that there was at least one less specific prefix (e.g., 1.0.0.0/8) there was at least one less specific prefix with different next hop
and the next-hop of such prefix was different from that of the VA between VA-prefix and the prefixes which got suppressed then all
0/0, those more specific prefixes (e.g., 1.1.1.0/24) which are previously suppressed prefixes must be reinstalled.
otherwise subject to suppression would not be eligible for
suppression anymore.
Similarly when IBGP multipath is enabled and when multiple VA Similarly when IBGP multipath is enabled and when multiple VA
prefixes are detected which are multipath candidates under given prefixes are detected which are multipath candidates under given
network condition only those more specific prefixes are subject to network condition only those more specific prefixes are subject to
suppression which have the identical set of next hops as multipath suppression which have the identical set of next hops as multipath
set of VA prefixes. set of VA prefixes.
We illustrate the expected behavior on the figure below. This figure We illustrate the expected behavior on the figure below. This figure
shows an autonomous system with a FIR FIR1 and an FSR FSR1. FSR1 is 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. an ASBR and is connected to two remote ASBRs, EP1 and EP2.
skipping to change at page 9, line 38 skipping to change at page 9, line 49
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.
6. Acknowledgements 6. Acknowledgements
The concept for Virtual Aggregation comes from Paul Francis. In this The concept for Virtual Aggregation comes from Paul Francis. In this
document authors only simplified some aspects of its behavior to document authors only simplified some aspects of its behavior to
allow simpler adoption by some operators. allow simpler adoption by some operators.
Authors would like to thank Clarence Filsfils and Nick Hilliard for Authors would like to thank Clarence Filsfils, Nick Hilliard, S.
their valuable input.
Moonesamy and Tom Petch for their review and valuable input.
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.
 End of changes. 12 change blocks. 
37 lines changed or deleted 47 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/