--- 1/draft-ietf-grow-simple-va-08.txt 2012-06-05 15:14:10.617342036 +0200 +++ 2/draft-ietf-grow-simple-va-09.txt 2012-06-05 15:14:10.637342441 +0200 @@ -1,33 +1,34 @@ GROW Working Group R. Raszuk Internet-Draft NTT MCL Intended status: Informational J. Heitz -Expires: November 30, 2012 Ericsson +Expires: December 7, 2012 Ericsson A. Lo Arista L. Zhang UCLA X. Xu Huawei - May 29, 2012 + June 5, 2012 Simple Virtual Aggregation (S-VA) - draft-ietf-grow-simple-va-08.txt + draft-ietf-grow-simple-va-09.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. + most costly stresses is Forwarding Information Base (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 @@ -43,21 +44,21 @@ 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." - This Internet-Draft will expire on November 30, 2012. + This Internet-Draft will expire on December 7, 2012. Copyright Notice Copyright (c) 2012 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 @@ -71,32 +72,33 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6 3. Deployment considerations . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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. + ISPs today manage constant Default Free Routing Table (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 @@ -116,22 +118,22 @@ 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 POP to core boundary or to the ASBR - routers. + 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 forwarding mechanisms in routers. Configuration is extremely simple: 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- 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. @@ -209,45 +211,52 @@ 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. + 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 + [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 suppress 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. + FSRs must detect the VA prefix or prefixes (including 0/0) and + install it both in loc-RIB, RIB and FIB. Following that FSR may + suppress 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. 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. + the VA-prefix is eligible for suppression. However, provided that + there was at least one less specific prefix with different next hop + between VA-prefix and the prefixes which got suppressed then all + previously suppressed prefixes must be reinstalled. 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 suppression which have the identical set of next hops as multipath set of VA prefixes. 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 an ASBR and is connected to two remote ASBRs, EP1 and EP2. @@ -345,22 +355,23 @@ 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 its behavior to allow simpler adoption by some operators. - Authors would like to thank Clarence Filsfils and Nick Hilliard for - their valuable input. + Authors would like to thank Clarence Filsfils, Nick Hilliard, S. + + Moonesamy and Tom Petch for their review and 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.