draft-ietf-grow-simple-va-05.txt   draft-ietf-grow-simple-va-06.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 A. Lo
Expires: November 4, 2012 Arista Expires: November 29, 2012 Arista
L. Zhang L. Zhang
UCLA UCLA
X. Xu X. Xu
Huawei Huawei
May 3, 2012 May 28, 2012
Simple Virtual Aggregation (S-VA) Simple Virtual Aggregation (S-VA)
draft-ietf-grow-simple-va-05.txt draft-ietf-grow-simple-va-06.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 6
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 4, 2012. This Internet-Draft will expire on November 29, 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
skipping to change at page 4, line 49 skipping to change at page 4, line 49
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 install a default route to core routers, to ABRs which
are installed on the POP to core boundary or to the ASBR routers. 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 it's 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.
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.
skipping to change at page 6, line 21 skipping to change at page 6, line 21
Legacy Router: A router that does not run S-VA, and has no knowledge Legacy Router: A router that does not run S-VA, and has no knowledge
of S-VA. of S-VA.
Global Routing Information Base (RIB): The term global RIB is used Global Routing Information Base (RIB): The term global RIB is used
to indicate the router's main routing information base. That RIB to indicate the router's main routing information base. That RIB
is normally used to populate FIB tables of the router. It needs is normally used to populate FIB tables of the router. It needs
to be highlighted that unless FIB compression is used global RIB to be highlighted that unless FIB compression is used global RIB
and FIB tables are in sync. and FIB tables are in sync.
Local/Protocol Routing Information Base (loc-RIB): The term local Local/Protocol Routing Information Base (loc-RIB): The term local
RIB is used to indicate the protocol's table where product of SPF RIB is used to indicate the protocol's table where product of SPF
or BGP best path selection is kept before being installed in or BGP best path selection is kept before being installed in
global RIB. In some protocol's implementations for example BGP global RIB. For example, in some protocol implementations BGP
loc-RIB can be further divided into Adj-RIBs-In, the Loc-RIB, and loc-RIB can be further divided into Adj-RIBs-In, the Loc-RIB, and
the Adj-RIBs-Out. the Adj-RIBs-Out.
2. Operation of S-VA 2. Operation of S-VA
There are three types of routers in S-VA, FIB-Installing routers There are three types of routers in S-VA, FIB-Installing routers
(FIR), FIB-Suppressing routers (FSR), and optionally legacy routers. (FIR), FIB-Suppressing routers (FSR), and optionally legacy routers.
While any router can be an FIR or an FSR (there are no topology While any router can be an FIR or an FSR (there are no topology
constraints), the most simple form of deployment is for AS border or constraints), the most simple form of deployment is for AS border or
POP border routers to be configured as FIRs, and for customer facing POP border routers to be configured as FIRs, and for customer facing
skipping to change at page 6, line 46 skipping to change at page 6, line 46
ORIGIN is set to INCOMPLETE (value 2) and the BGP NEXT_HOP is set to ORIGIN is set to INCOMPLETE (value 2) and the BGP NEXT_HOP is set to
match the other BGP routes which are also advertised by said FIR. match the other BGP routes which are also advertised by said FIR.
The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The
FIR MUST attach a NO_EXPORT Community Attribute [RFC1997] to the FIR MUST attach a NO_EXPORT Community Attribute [RFC1997] to the
default route. default route.
FIRs should not FIB-suppress any routes. They may, however, still FIRs should not FIB-suppress any routes. They may, however, still
use some form of local FIB compression algorithm if deemed necessary. use some form of local FIB compression algorithm if deemed necessary.
FSRs must detect the VA prefix 0/0 and install it both in loc-RIB, FSRs must detect the VA prefix 0/0 and install it both in loc-RIB,
RIB and FIB. Following that FSR may suppres any more specific routes RIB and FIB. Following that FSR may suppress any more specific
which carry the same next hop as the VA prefix. To guarantee routes which carry the same next hop as the VA prefix. To guarantee
semantical correctness FSR by default should also be able to detect semantical correctness FSR by default should also be able to detect
installation of not matching next hop route and reinstall all the installation of not matching next hop route and reinstall all the
more specifics which were previously eligible for suppression to more specifics which were previously eligible for suppression to
maintain semantical forwarding correctness. maintain semantical forwarding correctness.
Generally, any more specific route which carries the same next hop as Generally, any more specific route which carries the same next hop as
the VA-prefix 0/0 is eligible for suppression. However, provided the VA-prefix 0/0 is eligible for suppression. However, provided
that there was at least one less specific prefix (e.g., 1.0.0.0/8) that there was at least one less specific prefix (e.g., 1.0.0.0/8)
and the next-hop of such prefix was different from that of the VA and the next-hop of such prefix was different from that of the VA
0/0, those more specific prefixes (e.g., 1.1.1.0/24) which are 0/0, those more specific prefixes (e.g., 1.1.1.0/24) which are
otherwise subject to suppression would not be eligible for otherwise subject to suppression would not be eligible for
suppression anymore. suppression anymore.
Similarly when IBGP multipath is enabled and when multiple VA Similarly when IBGP multipath is enabled and when multiple VA
prefixes are detected which are multipath candidates under given prefixes are detected which are multipath candidates under given
network condition only those more specific prefixes are subject to network condition only those more specific prefixes are subject to
suppresion which have the identical set of next hops as multipath set suppression which have the identical set of next hops as multipath
of VA prefixes. set of VA prefixes.
Let's illustrate the expected behaviour on the figure below. This We illustrate the expected behavior on the figure below. This figure
figure shows an autonomous system with a FIR FIR1 and an FSR FSR1. shows an autonomous system with a FIR FIR1 and an FSR FSR1. FSR1 is
FSR1 is an ASBR and is connected to two remote ASBRs, EP1 and EP2. an ASBR and is connected to two remote ASBRs, EP1 and EP2.
+------------------------------------------+ +------------------------------------------+
| Autonomous System | +----+ | Autonomous System | +----+
| | |EP1 | | | |EP1 |
| /---+---| | | /---+---| |
| To ----\ +----+ +----+ / | +----+ | To ----\ +----+ +----+ / | +----+
| Other \|FIR1|----------|FSR1|/ | | Other \|FIR1|----------|FSR1|/ |
|Routers /| | | |\ | |Routers /| | | |\ |
| ----/ +----+ +----+ \ | +----+ | ----/ +----+ +----+ \ | +----+
| \---+---|EP2 | | \---+---|EP2 |
skipping to change at page 7, line 43 skipping to change at page 7, line 43
| | +----+ | | +----+
+------------------------------------------+ +------------------------------------------+
Suppose that FSR1 has been enabled to perform S-VA. Originally it Suppose that FSR1 has been enabled to perform S-VA. Originally it
receives all routes from FIR1 (doing next hop self) as well as receives all routes from FIR1 (doing next hop self) as well as
directly connected EBGP peers EP1 and EP2. FIR1 now will advertise a directly connected EBGP peers EP1 and EP2. FIR1 now will advertise a
VA prefix 0/0 with next hop set to himself. That will trigger VA prefix 0/0 with next hop set to himself. That will trigger
detection of such prefix on FSR1 and suppression all routes which detection of such prefix on FSR1 and suppression all routes which
have the same next hop as VA prefix and which otherwise would be have the same next hop as VA prefix and which otherwise would be
installed in RIB and FIB. However it needs to be observed that FSR1 installed in RIB and FIB. However it needs to be observed that FSR1
will not suppres any EBGP routes received from his peers EP1 and EP2 will not suppress any EBGP routes received from his peers EP1 and EP2
due to next hop being different from the one assinged to VA-prefix. due to next hop being different from the one assigned to VA-prefix.
3. Deployment considerations 3. Deployment considerations
The simplest deployment model of S-VA is it's use within the POP. In The simplest deployment model of S-VA is its use within the POP. In
such model the POP to core boundary routers (usually RRs in the data such model the POP to core boundary routers (usually RRs in the data
path) would act as FIRs and would inject VA-prefix 0/0 to all of it's path) would act as FIRs and would inject VA-prefix 0/0 to all of its
clients within the POP. In such model of operation an observation clients within the POP. In such model of operation an observation
can be made that such ABRs do have full routing knowledge and client can be made that such ABRs do have full routing knowledge and client
to ABR distance is negligable as compared with client to intra-domain to ABR distance is negligible as compared with client to intra-domain
exit distance. exit distance.
Therefor under the above intra POP S-VA deployment model clients can Therefore under the above intra POP S-VA deployment model clients can
be configured that even in the event of lack of ABR to ABR be configured that even in the event of lack of ABR to ABR
advertisement symmetry there is still no need to monitor if more advertisement symmetry there is still no need to monitor if more
specific unsuppressed route would cover suppressed one. Thus in this specific unsuppressed route would cover suppressed one. Thus in this
particular deployment model there is no need to detect and reinstall particular deployment model there is no need to detect and reinstall
the previously suppressed ones. the previously suppressed ones.
Another deploymet consideration should be given to networks which may Another deployment consideration should be given to networks which
utilize route reflection. In the event of enabling IBGP multipath a may utilize route reflection. In the event of enabling IBGP
special care must be taken that both outbound prefixes as well as VA- multipath a special care must be taken that both outbound prefixes as
prefixes would pass via said route reflectors to their clients. well as VA-prefixes would pass via said route reflectors to their
clients.
In order to addess the above aspects the following solutions could be In order to address the above aspects the following solutions could
considered: be considered:
- Use of intra-POP S-VA - Use of intra-POP S-VA
- Full mesh Small or medium side networks where S-VA can be deployed - Full mesh Small or medium side networks where S-VA can be deployed
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
skipping to change at page 8, line 47 skipping to change at page 8, line 48
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
The concept for Virtual Aggregation comes from Paul Francis. In this The concept for Virtual Aggregation comes from Paul Francis. In this
document authors only simplified some aspects of it's behaviour to document authors only simplified some aspects of its behavior to
allow simpler adoption by some operators. allow simpler adoption by some operators.
Authors would like to thank Clarence Filsfils for his valuable input. Authors would like to thank Clarence Filsfils and Nick Hilliard for
their valuable input.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996. Communities Attribute", RFC 1997, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 18 change blocks. 
27 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/