--- 1/draft-ietf-grow-va-02.txt 2010-08-31 13:13:47.000000000 +0200 +++ 2/draft-ietf-grow-va-03.txt 2010-08-31 13:13:47.000000000 +0200 @@ -1,27 +1,27 @@ Network Working Group P. Francis Internet-Draft MPI-SWS Intended status: Informational X. Xu -Expires: September 9, 2010 Huawei +Expires: March 4, 2011 Huawei H. Ballani Cornell U. D. Jen UCLA R. Raszuk Cisco L. Zhang UCLA - March 8, 2010 + August 31, 2010 FIB Suppression with Virtual Aggregation - draft-ietf-grow-va-02.txt + draft-ietf-grow-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. Virtual Aggregation (VA) allows ISPs to @@ -29,83 +29,75 @@ magnitude with negligible increase in path length and load. FIB suppression 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), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + 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." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 9, 2010. + This Internet-Draft will expire on March 4, 2011. Copyright Notice Copyright (c) 2010 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 BSD License. + described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5 - 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 6 - 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.4. Temporary Sections . . . . . . . . . . . . . . . . . . . . 7 - 1.4.1. Document revisions . . . . . . . . . . . . . . . . . . 7 - 2. Overview of Virtual Aggregation (VA) . . . . . . . . . . . . . 9 - 2.1. Mix of legacy and VA routers . . . . . . . . . . . . . . . 11 - 2.2. Summary of Tunnels and Paths . . . . . . . . . . . . . . . 11 - 3. Specification of VA . . . . . . . . . . . . . . . . . . . . . 13 - 3.1. VA Operation . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.1.1. Legacy Routers . . . . . . . . . . . . . . . . . . . . 13 - 3.1.2. Advertising and Handling Virtual Prefixes (VP) . . . . 14 - 3.1.3. Border VA Routers . . . . . . . . . . . . . . . . . . 17 - 3.1.4. Advertising and Handling Sub-Prefixes . . . . . . . . 18 - 3.1.5. Suppressing FIB Sub-prefix Routes . . . . . . . . . . 18 - 3.2. New Configuration . . . . . . . . . . . . . . . . . . . . 20 - 4. Usage of Tunnels . . . . . . . . . . . . . . . . . . . . . . . 21 - 4.1. MPLS tunnels . . . . . . . . . . . . . . . . . . . . . . . 21 - 4.2. Usage of Inner Label . . . . . . . . . . . . . . . . . . . 21 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 6.1. Properly Configured VA . . . . . . . . . . . . . . . . . . 22 - 6.2. Mis-configured VA . . . . . . . . . . . . . . . . . . . . 23 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4 + 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Overview of Virtual Aggregation (VA) . . . . . . . . . . . . . 6 + 2.1. Mix of legacy and VA routers . . . . . . . . . . . . . . . 8 + 2.2. Summary of Tunnels and Paths . . . . . . . . . . . . . . . 9 + 3. Specification of VA . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. VA Operation . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.1. Legacy Routers . . . . . . . . . . . . . . . . . . . . 11 + 3.1.2. Advertising and Handling Virtual Prefixes (VP) . . . . 11 + 3.1.3. Border VA Routers . . . . . . . . . . . . . . . . . . 15 + 3.1.4. Advertising and Handling Sub-Prefixes . . . . . . . . 15 + 3.1.5. Suppressing FIB Sub-prefix Routes . . . . . . . . . . 16 + 3.2. New Configuration . . . . . . . . . . . . . . . . . . . . 17 + 4. Usage of Tunnels . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.1. MPLS tunnels . . . . . . . . . . . . . . . . . . . . . . . 18 + 4.2. Usage of Inner Label . . . . . . . . . . . . . . . . . . . 19 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 6.1. Properly Configured VA . . . . . . . . . . . . . . . . . . 19 + 6.2. Mis-configured VA . . . . . . . . . . . . . . . . . . . . 20 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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 @@ -250,107 +242,20 @@ VA router: A router that operates Virtual Aggregation according to this document. Virtual Prefix (VP): A Virtual Prefix (VP) is a prefix used to aggregate its contained regular prefixes (sub-prefixes). The set of sub-prefixes in a VP are not physically aggregatable, and so they are aggregated at APRs through the use of tunnels. VP-List: A list of defined VPs. All routers must agree on the contents of this list (which is statically configured into every VA router). -1.4. Temporary Sections - - This section contains temporary information, and will be removed in - the final version. - -1.4.1. Document revisions - - This document was previously published as both - draft-francis-idr-intra-va-01.txt and draft-francis-intra-va-01.txt. - -1.4.1.1. Revisions from the 01 version of draft-ietf-grow-va - - The specification of how to use tunnels has been incorporated - directly into this draft. Formerly the specifications were provided - in separate drafts ([I-D.ietf-grow-va-mpls], and - [I-D.ietf-grow-va-mpls-innerlabel]). The tunneling types specified - in [I-D.ietf-grow-va-gre] are not included in this draft. - - The simpler "core-edge" style of deployment has been removed from - this draft and specified in a stand-alone draft - [I-D.ietf-grow-simple-va] to simplify its understanding for those - interested in only that style of deployment. - - Added text about usage of uRPF (strict and loose). - - Added text about flapping APR failure scenario. - -1.4.1.2. Revisions from the 00 version of draft-ietf-grow-va - - Removed the notion that FIB suppression can be done by suppressing - entries from the Routing Table (as defined in Section 3.2 of - [RFC4271]), an idea that was introduced in the second version of the - draft. Suppressing from the Routing Table breaks PIM-SM, which - relies on the contents of the unicast Routing Table to produce its - forwarding table. - -1.4.1.3. Revisions from the 00 version (of - draft-francis-intra-va-00.txt) - - Added additional authors (Jen, Raszuk, Zhang), to reflect primary - contributors moving forwards. In addition, a number of minor - clarifications were made. - -1.4.1.4. Revisions from the 01 version (of - draft-francis-idr-intra-va-01.txt) - - 1. Changed file name from draft-francis-idr-intra-va to - draft-francis-intra-va. - 2. Restructured the document to make the edge suppression mode a - specific sub-case of VA rather than a separate mode of operation. - This includes modifying the title of the draft. - 3. Removed MPLS tunneling details so that specific tunneling - approaches can be described in separate documents. - -1.4.1.5. Revisions from 00 version - - o Changed intended document type from STD to BCP, as per advice from - Dublin IDR meeting. - o Cleaned up the MPLS language, and specified that the full-address - routes to remote ASBRs must be imported into OSPF (Section 3.1.3). - As per Daniel Ginsburg's email - http://www.ietf.org/mail-archive/web/idr/current/msg02933.html. - o Clarified that legacy routers must run MPLS. As per Daniel - Ginsburg's email - http://www.ietf.org/mail-archive/web/idr/current/msg02935.html. - o Fixed LOCAL_PREF bug. As per Daniel Ginsburg's email - http://www.ietf.org/mail-archive/web/idr/current/msg02940.html. - o Removed the need for the extended communities attribute on VP - routes, and added the requirement that all VA routers be - statically configured with the complete list of VPs. As per - Daniel Ginsburg's emails - http://www.ietf.org/mail-archive/web/idr/current/msg02940.html and - http://www.ietf.org/mail-archive/web/idr/current/msg02958.html. - In addition, the procedure for adding, deleting, splitting, and - merging VPs was added. As part of this, the possibility of having - overlapping VPs was added. - o Added the special case of a core-edge topology with default routes - to the edge as suggested by Robert Raszuk in email - http://www.ietf.org/mail-archive/web/idr/current/msg02948.html. - Note that this altered the structure and even title of the - document. - - o Clarified that FIB suppression can be achieved by not loading - entries into the Routing Table, as suggested by Rajiv Asati in - email - http://www.ietf.org/mail-archive/web/idr/current/msg03019.html. - 2. Overview of Virtual Aggregation (VA) For descriptive simplicity, this section starts by describing VA assuming that there are no legacy routers in the domain. Section 2.1 overviews the additional functions required by VA routers to accommodate legacy routers. A key concept behind VA is to operate BGP as normal, and in particular to populate the RIB with the full DFRT, but to suppress many or most prefixes from being loaded into the FIB. By populating @@ -693,22 +598,23 @@ an ISP somewhere advertised a very large prefix (a /4, say), then this would cause APRs to throw out all VPs that are smaller than this. For this reason, VPs MUST be set through static configuration only. 3.1.2.4. Non-APR Routers A non-APR router MUST install at least the following routes: 1. Routes to VPs (identifiable using the VP-List). + 2. Routes to all sub-prefixes that are not covered by any VP in the - VP-list. + VP-List. If the non-APR has a tunnel to the BGP NEXT_HOP of any such route, it MUST use the tunnel to forward packets to the BGP NEXT_HOP. When an APR fails, routers must select another APR to send packets to (if there is one). This happens, however, through normal internal BGP convergence mechanisms. 3.1.2.5. Adding and deleting VPs @@ -811,30 +717,29 @@ attractive according to the normal BGP best path selection algorithm. 2. If the router is an APR, a route for every sub-prefix within the VP MUST be FIB-installed (subject to the above limitation that there be a tunnel). 3. If a non-APR router has a sub-prefix route that does not fall within any VP (as determined by the VP-List), then the route MUST be installed. This may occur because the ISP hasn't defined a VP covering that prefix, for instance during an incremental deployment buildup. - 4. If an ASBR is using strict uRPF to do ingress filtering, then it MUST install routes for which the remote ASBR is the BGP NEXT_HOP [RFC2827]. Note that only a APR may do loose uRPF filtering, and then only for routes to sub-prefixes within its VPs. 5. All other sub-prefix routes MAY be suppressed. Such "optional" sub-prefixes that are nevertheless installed are referred to as Popular Prefixes. Note, however, that whether or not to install a given sub-prefix SHOULD NOT be based on whether or not there is - an active route to a VP in the VP-list. This avoids the + an active route to a VP in the VP-List. This avoids the situation whereby, during BGP initialization, the router receives some sub-prefix routes before receiving the corresponding VP route, with the result that it installs routes in its FIB that it will only remove a short time later, possibly even overflowing its FIB. 3.1.5.1. Selecting Popular Prefixes Individual routers MAY independently choose which sub-prefixes are Popular Prefixes. There is no need for different routers to install