--- 1/draft-ietf-grow-simple-va-06.txt 2012-05-29 01:14:15.073425330 +0200 +++ 2/draft-ietf-grow-simple-va-07.txt 2012-05-29 01:14:15.093426279 +0200 @@ -1,23 +1,25 @@ GROW Working Group R. Raszuk Internet-Draft NTT MCL -Intended status: Informational A. Lo -Expires: November 29, 2012 Arista +Intended status: Informational J. Heitz +Expires: November 30, 2012 Ericsson + A. Lo + Arista L. Zhang UCLA X. Xu Huawei - May 28, 2012 + May 29, 2012 Simple Virtual Aggregation (S-VA) - draft-ietf-grow-simple-va-06.txt + draft-ietf-grow-simple-va-07.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 @@ -41,52 +43,52 @@ 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 29, 2012. + This Internet-Draft will expire on November 30, 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 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. 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 + 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Deployment considerations . . . . . . . . . . . . . . . . . . 7 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 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. A common approach taken by lower-tier ISPs is to default route to @@ -296,20 +298,58 @@ 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. + In some deployment scenarios BGP routes could be used to resolve + other BGP routes - commonly process called double or multi-level BGP + recursion. If such recursion involves specific route resolution + policy a special care must be taken to either automatically or + manually exclude such routes matching given policy from suppression. + + Route resolution over default route is a special case. Most network + operating systems can be configured by the operator to enable route + resolution over default route(s). In simple-va all default routes + are intra-domain routes and their objective it to shift full lookup + from edge router to more powerful pop to core boundary router or exit + ASBR. In those cases simple-va should be configured in concert with + global configuration regarding resolution via default route. In the + event of actually using default for next hop resolution the worse + case scenario is that the packets may be forwarded one more hop then + dropped if more specific destination route is not found there. + + Operators are advised to keep effect in mind when choosing a policy + for use of default route for next hop resolution. + + Selected BGP routes in the RIB may be redistributed to other + protocols. If they no longer exist in the RIB, they will not be + redistributed. This is especially important when the conditional + redistribution is taking place based on the length of the prefix, + community value etc .. In those cases where redistribution policy is + in place simple-va code should refrain from suppressing prefixes + matching such policy. + + In the case where operator injects a default at the pop to core + boundary into the pop or alternatively when intra-domain default + route is injected into autonomous system by set of ASBRs peering with + their upstreams a special care needs to be take to make sure that any + aggregate subnet is advertised only from the BGP speakers which + inject the default route and therefor attract traffic to non existing + destinations. This will allow to completely mitigate potential + forwarding issue while not specific to simple-va, but applicable to + the general use of default routes. + 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 @@ -344,28 +383,37 @@ Authors' Addresses Robert Raszuk NTT MCL 101 S Ellsworth Avenue Suite 350 San Mateo, CA 94401 US Email: robert@raszuk.net + Jakob Heitz + Ericsson + 300 Holger Way + San Jose, CA 95135 + USA + + Phone: + Email: jakob.heitz@ericsson.com Alton Lo Arista Networks 5470 Great America Parkway Santa Clara, CA 95054 USA Phone: Email: altonlo@aristanetworks.com + Lixia Zhang UCLA 3713 Boelter Hall Los Angeles, CA 90095 US Phone: Email: lixia@cs.ucla.edu Xiaohu Xu