draft-ietf-grow-simple-va-07.txt | draft-ietf-grow-simple-va-08.txt | |||
---|---|---|---|---|
skipping to change at page 1, line 16 | skipping to change at page 1, line 16 | |||
Expires: November 30, 2012 Ericsson | Expires: November 30, 2012 Ericsson | |||
A. Lo | A. Lo | |||
Arista | Arista | |||
L. Zhang | L. Zhang | |||
UCLA | UCLA | |||
X. Xu | X. Xu | |||
Huawei | Huawei | |||
May 29, 2012 | May 29, 2012 | |||
Simple Virtual Aggregation (S-VA) | Simple Virtual Aggregation (S-VA) | |||
draft-ietf-grow-simple-va-07.txt | draft-ietf-grow-simple-va-08.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 3, line 10 | skipping to change at page 3, line 10 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3. Deployment considerations . . . . . . . . . . . . . . . . . . 7 | 3. Deployment considerations . . . . . . . . . . . . . . . . . . 8 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 | 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 | 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. | |||
skipping to change at page 4, line 44 | skipping to change at page 4, line 44 | |||
used for routers that connect to customers which wish to receive the | used for routers that connect to customers which wish to receive the | |||
full DFRT. | full DFRT. | |||
This draft describes a very simple technique, called Simple Virtual | This draft describes a very simple technique, called Simple Virtual | |||
Aggregation (S-VA), that allows any and all edge routers to have | Aggregation (S-VA), that allows any and all edge routers to have | |||
substantially reduced FIB requirements even while still advertising | substantially reduced FIB requirements even while still advertising | |||
and receiving the full DFRT over BGP. The basic idea is as follows. | 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. | 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 | Edge routers maintain the full DFRT in the BGP protocol RIB, but | |||
suppress certain routes from being installed in RIB and FIB tables. | suppress certain routes from being installed in RIB and FIB tables. | |||
Edge routers install a default route to core routers, to ABRs which | Edge routers may install a default route to core routers, to ABRs | |||
are installed on the POP to core boundary or to the ASBR routers. | which are installed on the POP to core boundary or to the ASBR | |||
routers. | ||||
S-VA requires no changes to BGP and no changes to any choice of | S-VA requires no changes to BGP and no changes to any choice of | |||
forwarding mechanisms in routers. Configuration is extremely simple: | forwarding mechanisms in routers. Configuration is extremely simple: | |||
S-VA must be enabled on the edge router which needs to save its RIB | 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- | and FIB space. In the same time operator must inject into his intra- | |||
domain routing a new prefix further called virtual aggregate (VA- | domain routing a new prefix further called virtual aggregate (VA- | |||
prefix) which will be used as the aggregate forwarding reference by | prefix) which will be used as the aggregate forwarding reference by | |||
the edge routers performing S-VA. Everything else is automatic. | the edge routers performing S-VA. Everything else is automatic. | |||
ISPs can deploy FIB suppression autonomously and with no coordination | ISPs can deploy FIB suppression autonomously and with no coordination | |||
with neighbor ASes. | with neighbor ASes. | |||
In configurations where BGP routes are used to resolve other routes | ||||
or where BGP routes are redistributed to other protocols which both | ||||
happen via RIB simple-va can rather then suppressing routes before | ||||
they are installed in global RIB flag them as "suppress eligible". | ||||
That will allow for seamless route resolution or redistribution while | ||||
in the same time FIB size will continue to be limited as previously | ||||
flagged routes will not be send from RIB to FIB. | ||||
1.1. Scope of this Document | 1.1. Scope of this Document | |||
The scope of this document is limited to Intra-domain S-VA operation. | The scope of this document is limited to Intra-domain S-VA operation. | |||
In other words, the case where a single ISP autonomously operates | In other words, the case where a single ISP autonomously operates | |||
S-VA internally without any coordination with neighboring ISPs. | S-VA internally without any coordination with neighboring ISPs. | |||
Note that this document assumes that the S-VA "domain" (i.e. the unit | Note that this document assumes that the S-VA "domain" (i.e. the unit | |||
of autonomy) is the AS (that is, different ASes run S-VA | of autonomy) is the AS (that is, different ASes run S-VA | |||
independently and without coordination). For the remainder of this | independently and without coordination). For the remainder of this | |||
document, the terms ISP, AS, and domain are used interchangeably. | document, the terms ISP, AS, and domain are used interchangeably. | |||
skipping to change at page 8, line 36 | skipping to change at page 8, line 45 | |||
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 | BGP routes may be used to resolve nexthops for static routes or other | |||
other BGP routes - commonly process called double or multi-level BGP | BGP routes. Because the default route does not imply reachability of | |||
recursion. If such recursion involves specific route resolution | any destination, a router can be configured not to resolve nexthops | |||
policy a special care must be taken to either automatically or | using the default route. In this case, simple-va should not suppress | |||
manually exclude such routes matching given policy from suppression. | a route that may be used to resolve a nexthop for another route. | |||
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 | Selected BGP routes in the RIB may be redistributed to other | |||
protocols. If they no longer exist in the RIB, they will not be | protocols. If they no longer exist in the RIB, they will not be | |||
redistributed. This is especially important when the conditional | redistributed. This is especially important when the conditional | |||
redistribution is taking place based on the length of the prefix, | redistribution is taking place based on the length of the prefix, | |||
community value etc .. In those cases where redistribution policy is | community value etc .. In those cases where redistribution policy is | |||
in place simple-va code should refrain from suppressing prefixes | in place simple-va code should refrain from suppressing prefixes | |||
matching such policy. | matching such policy. | |||
In the case where operator injects a default at the pop to core | A router may originate a network route or an aggregate route into | |||
boundary into the pop or alternatively when intra-domain default | BGP. Some addresses covered by such a route may not exist. If this | |||
route is injected into autonomous system by set of ASBRs peering with | router were to receive a packet for an unreachable address within an | |||
their upstreams a special care needs to be take to make sure that any | originated route, it must not send that packet to the default route. | |||
aggregate subnet is advertised only from the BGP speakers which | There are several ways to achieve this. One is to have the FIR | |||
inject the default route and therefor attract traffic to non existing | aggregate the routes instead of the FSR. Another is to install a | |||
destinations. This will allow to completely mitigate potential | blackhole route for the nonexistent addresses on the originating | |||
forwarding issue while not specific to simple-va, but applicable to | router. This issue is not specific to simple-va, but applicable to | |||
the general use of default routes. | 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. | |||
End of changes. 8 change blocks. | ||||
34 lines changed or deleted | 29 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/ |