draft-ietf-grow-simple-va-06.txt   draft-ietf-grow-simple-va-07.txt 
GROW Working Group R. Raszuk GROW Working Group R. Raszuk
Internet-Draft NTT MCL Internet-Draft NTT MCL
Intended status: Informational A. Lo Intended status: Informational J. Heitz
Expires: November 29, 2012 Arista Expires: November 30, 2012 Ericsson
A. Lo
Arista
L. Zhang L. Zhang
UCLA UCLA
X. Xu X. Xu
Huawei Huawei
May 28, 2012 May 29, 2012
Simple Virtual Aggregation (S-VA) Simple Virtual Aggregation (S-VA)
draft-ietf-grow-simple-va-06.txt draft-ietf-grow-simple-va-07.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 FIB size: ISPs often must upgrade router
hardware simply because the FIB has run out of space, and router hardware simply because the FIB has run out of space, and router
vendors must design routers that have adequate FIB. 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
skipping to change at page 2, line 6 skipping to change at page 2, line 8
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 29, 2012. This Internet-Draft will expire on November 30, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . . 6 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6
3. Deployment considerations . . . . . . . . . . . . . . . . . . . 7 3. Deployment considerations . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
ISPs today manage constant DFRT growth in a number of ways. One way, 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 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 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 ISPs. They would prefer to extend the lifetime of routers whose FIBs
can no longer hold the full DFRT. 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
skipping to change at page 8, line 36 skipping to change at page 8, line 36
are normally fully meshed and do not use route reflection. It are normally fully meshed and do not use route reflection. It
also needs to pointed out that some large networks are also fully also needs to pointed out that some large networks are also fully
meshed today. meshed today.
- Use of add-paths Use of add-paths new BGP encoding will allow to - 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. distribute more then one overall best path from RR to each client.
- Alternate advertisement of VA-prefix S-VA prefix does not need to - Alternate advertisement of VA-prefix S-VA prefix does not need to
be advertised in BGP. The BGP suppression will happen as long as be advertised in BGP. The BGP suppression will happen as long as
we configure the S-VA with next hop(s) and implementation verifies we configure the S-VA with next hop(s) and implementation verifies
that such VA-prefix is installed in the RIB and FIB. 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 4. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
5. Security Considerations 5. Security Considerations
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
skipping to change at page 9, line 39 skipping to change at page 10, line 32
Authors' Addresses Authors' Addresses
Robert Raszuk Robert Raszuk
NTT MCL NTT MCL
101 S Ellsworth Avenue Suite 350 101 S Ellsworth Avenue Suite 350
San Mateo, CA 94401 San Mateo, CA 94401
US US
Email: robert@raszuk.net Email: robert@raszuk.net
Jakob Heitz
Ericsson
300 Holger Way
San Jose, CA 95135
USA
Phone:
Email: jakob.heitz@ericsson.com
Alton Lo Alton Lo
Arista Networks Arista Networks
5470 Great America Parkway 5470 Great America Parkway
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Phone: Phone:
Email: altonlo@aristanetworks.com Email: altonlo@aristanetworks.com
Lixia Zhang Lixia Zhang
UCLA UCLA
3713 Boelter Hall 3713 Boelter Hall
Los Angeles, CA 90095 Los Angeles, CA 90095
US US
Phone: Phone:
Email: lixia@cs.ucla.edu Email: lixia@cs.ucla.edu
Xiaohu Xu Xiaohu Xu
 End of changes. 8 change blocks. 
18 lines changed or deleted 67 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/