draft-ietf-grow-va-02.txt   draft-ietf-grow-va-03.txt 
Network Working Group P. Francis Network Working Group P. Francis
Internet-Draft MPI-SWS Internet-Draft MPI-SWS
Intended status: Informational X. Xu Intended status: Informational X. Xu
Expires: September 9, 2010 Huawei Expires: March 4, 2011 Huawei
H. Ballani H. Ballani
Cornell U. Cornell U.
D. Jen D. Jen
UCLA UCLA
R. Raszuk R. Raszuk
Cisco Cisco
L. Zhang L. Zhang
UCLA UCLA
March 8, 2010 August 31, 2010
FIB Suppression with Virtual Aggregation FIB Suppression with Virtual Aggregation
draft-ietf-grow-va-02.txt draft-ietf-grow-va-03.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. FIB suppression vendors must design routers that have adequate FIB. FIB suppression
is an approach to relieving stress on the FIB by NOT loading selected is an approach to relieving stress on the FIB by NOT loading selected
RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to
skipping to change at page 1, line 40 skipping to change at page 1, line 40
magnitude with negligible increase in path length and load. FIB magnitude with negligible increase in path length and load. FIB
suppression deployed autonomously by an ISP (cooperation between ISPs suppression deployed autonomously by an ISP (cooperation between ISPs
is not required), and can co-exist with legacy routers in the ISP. is not required), and can co-exist with legacy routers in the ISP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on March 4, 2011.
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.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 6 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Temporary Sections . . . . . . . . . . . . . . . . . . . . 7 2. Overview of Virtual Aggregation (VA) . . . . . . . . . . . . . 6
1.4.1. Document revisions . . . . . . . . . . . . . . . . . . 7 2.1. Mix of legacy and VA routers . . . . . . . . . . . . . . . 8
2. Overview of Virtual Aggregation (VA) . . . . . . . . . . . . . 9 2.2. Summary of Tunnels and Paths . . . . . . . . . . . . . . . 9
2.1. Mix of legacy and VA routers . . . . . . . . . . . . . . . 11 3. Specification of VA . . . . . . . . . . . . . . . . . . . . . 10
2.2. Summary of Tunnels and Paths . . . . . . . . . . . . . . . 11 3.1. VA Operation . . . . . . . . . . . . . . . . . . . . . . . 11
3. Specification of VA . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. Legacy Routers . . . . . . . . . . . . . . . . . . . . 11
3.1. VA Operation . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.2. Advertising and Handling Virtual Prefixes (VP) . . . . 11
3.1.1. Legacy Routers . . . . . . . . . . . . . . . . . . . . 13 3.1.3. Border VA Routers . . . . . . . . . . . . . . . . . . 15
3.1.2. Advertising and Handling Virtual Prefixes (VP) . . . . 14 3.1.4. Advertising and Handling Sub-Prefixes . . . . . . . . 15
3.1.3. Border VA Routers . . . . . . . . . . . . . . . . . . 17 3.1.5. Suppressing FIB Sub-prefix Routes . . . . . . . . . . 16
3.1.4. Advertising and Handling Sub-Prefixes . . . . . . . . 18 3.2. New Configuration . . . . . . . . . . . . . . . . . . . . 17
3.1.5. Suppressing FIB Sub-prefix Routes . . . . . . . . . . 18 4. Usage of Tunnels . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. New Configuration . . . . . . . . . . . . . . . . . . . . 20 4.1. MPLS tunnels . . . . . . . . . . . . . . . . . . . . . . . 18
4. Usage of Tunnels . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. Usage of Inner Label . . . . . . . . . . . . . . . . . . . 19
4.1. MPLS tunnels . . . . . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
4.2. Usage of Inner Label . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6.1. Properly Configured VA . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.2. Mis-configured VA . . . . . . . . . . . . . . . . . . . . 20
6.1. Properly Configured VA . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Mis-configured VA . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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 7, line 20 skipping to change at page 6, line 20
VA router: A router that operates Virtual Aggregation according to VA router: A router that operates Virtual Aggregation according to
this document. this document.
Virtual Prefix (VP): A Virtual Prefix (VP) is a prefix used to Virtual Prefix (VP): A Virtual Prefix (VP) is a prefix used to
aggregate its contained regular prefixes (sub-prefixes). The set aggregate its contained regular prefixes (sub-prefixes). The set
of sub-prefixes in a VP are not physically aggregatable, and so of sub-prefixes in a VP are not physically aggregatable, and so
they are aggregated at APRs through the use of tunnels. they are aggregated at APRs through the use of tunnels.
VP-List: A list of defined VPs. All routers must agree on the VP-List: A list of defined VPs. All routers must agree on the
contents of this list (which is statically configured into every contents of this list (which is statically configured into every
VA router). 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) 2. Overview of Virtual Aggregation (VA)
For descriptive simplicity, this section starts by describing VA For descriptive simplicity, this section starts by describing VA
assuming that there are no legacy routers in the domain. Section 2.1 assuming that there are no legacy routers in the domain. Section 2.1
overviews the additional functions required by VA routers to overviews the additional functions required by VA routers to
accommodate legacy routers. accommodate legacy routers.
A key concept behind VA is to operate BGP as normal, and in 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 particular to populate the RIB with the full DFRT, but to suppress
many or most prefixes from being loaded into the FIB. By populating many or most prefixes from being loaded into the FIB. By populating
skipping to change at page 16, line 31 skipping to change at page 14, line 4
an ISP somewhere advertised a very large prefix (a /4, say), then 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 would cause APRs to throw out all VPs that are smaller than
this. For this reason, VPs MUST be set through static configuration this. For this reason, VPs MUST be set through static configuration
only. only.
3.1.2.4. Non-APR Routers 3.1.2.4. Non-APR Routers
A non-APR router MUST install at least the following routes: A non-APR router MUST install at least the following routes:
1. Routes to VPs (identifiable using the VP-List). 1. Routes to VPs (identifiable using the VP-List).
2. Routes to all sub-prefixes that are not covered by any VP in the 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 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. 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 When an APR fails, routers must select another APR to send packets to
(if there is one). This happens, however, through normal internal (if there is one). This happens, however, through normal internal
BGP convergence mechanisms. BGP convergence mechanisms.
3.1.2.5. Adding and deleting VPs 3.1.2.5. Adding and deleting VPs
skipping to change at page 19, line 4 skipping to change at page 16, line 28
attractive according to the normal BGP best path selection attractive according to the normal BGP best path selection
algorithm. algorithm.
2. If the router is an APR, a route for every sub-prefix within the 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 VP MUST be FIB-installed (subject to the above limitation that
there be a tunnel). there be a tunnel).
3. If a non-APR router has a sub-prefix route that does not fall 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 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 be installed. This may occur because the ISP hasn't defined a VP
covering that prefix, for instance during an incremental covering that prefix, for instance during an incremental
deployment buildup. deployment buildup.
4. If an ASBR is using strict uRPF to do ingress filtering, then it 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 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 [RFC2827]. Note that only a APR may do loose uRPF filtering, and
then only for routes to sub-prefixes within its VPs. then only for routes to sub-prefixes within its VPs.
5. All other sub-prefix routes MAY be suppressed. Such "optional" 5. All other sub-prefix routes MAY be suppressed. Such "optional"
sub-prefixes that are nevertheless installed are referred to as sub-prefixes that are nevertheless installed are referred to as
Popular Prefixes. Note, however, that whether or not to install Popular Prefixes. Note, however, that whether or not to install
a given sub-prefix SHOULD NOT be based on whether or not there is 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 situation whereby, during BGP initialization, the router receives
some sub-prefix routes before receiving the corresponding VP some sub-prefix routes before receiving the corresponding VP
route, with the result that it installs routes in its FIB that it route, with the result that it installs routes in its FIB that it
will only remove a short time later, possibly even overflowing will only remove a short time later, possibly even overflowing
its FIB. its FIB.
3.1.5.1. Selecting Popular Prefixes 3.1.5.1. Selecting Popular Prefixes
Individual routers MAY independently choose which sub-prefixes are Individual routers MAY independently choose which sub-prefixes are
Popular Prefixes. There is no need for different routers to install Popular Prefixes. There is no need for different routers to install
 End of changes. 12 change blocks. 
133 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/