RIPE Routing Working Group Recommendations on Route Aggregation

1. Introduction

The Internet is made up of autonomous networks (usually called Autonomous Systems or AS) interconnected with each other.  These autonomous networks will have over time been assigned or allocated address space for use within their own networks, or networks of their customers.  This address space is announced to neighbouring autonomous networks.  Depending on the business or contractual arrangements between these neighbouring autonomous networks, this address space may or may not announced to the neighbouring autonomous networks of these networks.  And so on, across the entire Internet.

The collection of this address space as announced by the organisational entities making up the Internet is known as the Internet Routing Table.

With each AS announcing their address space, and each AS hearing this announcement either directly or indirectly, each end system in the Internet is able to communicate with other end systems, thereby giving the global communications system known as the Internet.

2.  Background

As documented in the CIDR Report [1] and other similar activities, the size of the Internet Routing Table has been of considerable interest to Internet Service Providers and the vendors of Internet routing equipment since the rapid adoption of the Internet as a communications medium in the early 90s.

2.1 The Early Internet

In the early Internet, address space assigned to Autonomous Systems and End Sites fitted into three categories: class A, class B, and class C. The Internet Routing Table contained only these three types of addressing, small organisations receiving a class C, medium sized organisations receiving a class B, and large organisations receiving a class A.  This was known as classful address assignment, and the routing system associated with it understood the different classes.

A major effort in 1994, saw the Internet start the conversion from using this classful prefix system to using a classless system ([2] and [3]). The motivation for this was the rapid depletion of the classful address space, with biggest pressure being on the address space range being used for class B networks (128.0.0.0 to 191.255.0.0).

With the commercialisation of the Internet and prior to the migration to the classless addressing system, organisations which had grown out of their requirements for a single class C network would receive further class C networks, rather than being "upgraded" to a class B network.  This was designed to reduce the pressure on the class B address block.

The result of this was that many organisations had a large amount of class C address blocks for their use - or a large number of /24 prefixes, using today's terminology.  As part of the migration to the classless routing system, the CIDR Report's original motivation was to encourage network operators to merge their contiguous /24 prefixes into a single larger announcement.  This activity is called aggregation and will be explained in detail in subsequent sections.

The CIDR Report was quite successful in encouraging aggregation.  The weekly public e-mail to Operations mailing lists helped point out those ISPs who were making efforts at aggregating their announcements to the Internet.  The results of this peer pressure are visible in the early stages of the graphs available on the CIDR Report website ([1] and [4]).

2.2 Today's Internet

In the classless Internet today, network operators who participate in the Regional Internet Registry (RIR) system will receive allocations from the RIRs (AfriNIC, APNIC, ARIN, LACNIC & RIPE NCC).  These allocations will be of the size requested from the RIRs according to the network operators' requirements, and generally will be of a minimum size, for example a /21.

Following the introduction of the classless allocation system and classless routing in 1994, network operators would receive an address block from their RIR, and would generally announce this address block to the Internet.  This happens in the same way that operators in the early Internet would announce only the class A, class B, or class C they had been assigned.

While there is a widely known and unwritten expectation that the address block allocated by the RIR is what would be announced by the network operator to the Internet, the more common practice today seems to be to still announce /24s (the equivalent of the legacy class Cs).  The result is that around 60% of the Internet Routing Table consists of /24 prefixes.

Some of the /24 announcements are undoubtedly caused by traffic engineering efforts for multihoming (an activity recognised as a requirement in the industry by the authors of RFC1519 - [3]).  However, the majority can be attributed to ISPs "receiving 32 Class Cs from the RIR" and announcing them as such.  (Expected behaviour would be to combine these into a single announcement with a /19 network mask.)

3.  What is Aggregation?

Aggregation is the activity of introducing several contiguous IP addresses as a single address block into the IP routing system (using BGP).  For example, if an enterprise has received 32 IP addresses from their ISP for numbering the systems on their internal LAN, they would announce these 32 IP addresses to their ISP as a single entity.  Each device on the LAN can be represented by the address block, rather than their presence having to be uniquely indicated to the rest of the world.

For example, if the enterprise receives contiguous addresses from 192.0.2.0 to 192.0.2.31, they would announce this to their ISP as 192.0.2.0/27.  This format says that the first 27 bits of the IP address is the network portion, with the final five bits being the host portion.

Likewise, on a larger scale, if an ISP has received 4,096 IP addresses from the RIR, for example 10.201.48.0 to 10.201.63.255, they would announce these IP addresses as a single address block to their neighbouring networks, so as 10.201.48.0/20.

Both these examples describe what is known as aggregation.  The end network has combined contiguous addresses into a single entity, and this single entity is announced to neighbouring Autonomous Systems.

While these two examples are relatively small scale examples, they indicate the activities of ISPs who participate in the Internet - individual IP addresses are combined into the largest feasible chunk before they are announced to the Internet.

Proxy aggregation is when an ISP, for example, takes contiguous prefix blocks announced to it by other networks (usually by BGP) and aggregates them into a single larger announcement originated from their own network.

4.  The Internet Routing Table

There are but a few contributory factors to the size of the Internet Routing Table.  These are analysed in turn.

4.1 What is Deaggregation?

The RIRs allocate address space to ISPs in blocks, with the expectation that these blocks are announced to the Internet unaltered.  It should be noted that the RIRs have no rules about how this address space should be announced to the Internet.  The industry considers it improper for the RIRs to tell ISPs how to announce address space; in the same way that libraries won't tell their readers how to read the books it lends.

However, many ISPs don't announce their allocations as single blocks as they are expected to, preferring to announce their address space in smaller pieces, even as small as /24s.  This activity is known as deaggregation.

4.2 General Deaggregation

There seem to be several reasons for this deaggregation.  Some providers claim that they have commercial reasons for doing so; some cite routing system security concerns; others claim it reduces bandwidth wasting virus and miscreant activities against their networks.

Routing system security is a general concern for many providers around the Internet.  There is no universally accepted or used system for ensuring that a provider is entitled to originate any address block.  (While the Internet Routing Registry was designed to assist with this, its use has never been made mandatory, and the routing system still works well without it.) The result is that some providers work around their concerns about the relative lack of routing system security by simply announcing the smallest acceptable prefix.  This means that no other autonomous system can announce more specific versions of the same prefixes thereby causing a denial of service on the legitimate user of the address space.  However, the authors are aware of very few such incidents being recorded, so deaggregation for security reasons seems a somewhat overly unfriendly activity compared with the potential risk.

Another claimed reason for deaggregation is the claim that it reduces denial of service attacks and miscreant activities aimed at a service provider network.  It is well known that there are many virus and worm ridden systems around the Internet that simply carry out scans of contiguous address blocks (whether routed or not) looking for other systems to infect.  This creates a "background noise" of traffic aimed at an address block.  In the authors' experience, the announcement of a /16 address block can attract up to 2Mbps of this noise - in developing parts of the Internet, such bandwidth is an expensive proposition for ISPs, so they only announce what they are actually using.  As each /24 is consumed by their infrastructure and their customers, they'd announce the /24 to the Internet (and quite often this /24 is not sequential to any previous internal assignments).  Even when the original /19 allocation was entirely used, the ISP makes no effort to aggregate it (in their eyes nothing is broken, so doesn't require fixing), with the resulting impact on the size of the global Routing Table.

It is likely that the blanket "we have commercial reasons for deaggregation" claimed by some providers includes concerns about both of the previous scenarios.  It is also quite likely that there are other commercial reasons; one example heard in previous years was that appearing in the top 10 of the CIDR Report was considered a positive reflection on the size and quality of the ISP's business.

4.3 iBGP and eBGP

A further reason for deaggregation seems to be a failure to appreciate the difference between BGP as used inside the SP network (iBGP), and BGP as used for inter-domain routing (eBGP).  iBGP is intended to carry all the ISP's customer prefixes and local infrastructure prefixes (hosting LANs, etc), as well as prefixes learned from other SP networks.  eBGP is intended to announce reachability between domains, and this can simply be achieved by each ISP announcing the address blocks they have been allocated by the RIRs.  Quite often ISPs happily leak their iBGP routing information into eBGP, with the resulting impact on the size of the Internet Routing Table.

Perhaps the most interesting location where the differences between an ISP's iBGP and eBGP can be examined would be at the University of Oregon Route Views project [5].  This project has views of the Internet Routing Table as seen by many different ISPs around the world.  Some ISPs choose to send their eBGP view, others choose to send their iBGP view.  The Route Views project makes no demands on what should or should not be sent.  This then provides an interesting insight into aggregation efforts made by ISPs, the extent of iBGP for some of the larger ISPs, and the filtering efforts made by other ISPs to remove iBGP views received from their peers across the Internet routing infrastructure.

4.4 Deaggregation to aid Multihoming

The need to deaggregate as part of traffic engineering activities for networks who multihome is an oft quoted reason or absolute justification for the size of the Internet Routing Table.  It seems that standard multihoming practice these days is to take any address allocation or assignment, chop it into individual /24s, and announce these /24s out of all external network links.

A /24 is chosen for this activity as there is a belief that most ISPs will filter IP prefixes on a /24 boundary (being the size of the legacy class C address), even though there is little evidence to back this belief up, as a cursory glance at the CIDR Report [1] will show.

Furthermore, the theory behind announcing an address block only as /24s is that this will somehow make multihoming work.  In the authors' experience this is not the case, as successful traffic engineering and load balancing is only achieved by announcing appropriate sub-prefixes of an allocated address block depending on traffic levels generated by devices occupying these sub-prefixes.

The result of this scatter gun approach is a further contribution to the increase in the size of the Internet Routing Table.

4.5 Legacy Assignments

Often blamed for the Internet Routing Table size are legacy assignments. These are assignments made by the IANA prior to the establishment of the RIR system.  However, the main contributor to the Internet Routing Table from legacy assignments was from the 192/8 block, the first /8 block in the former class C space.  After the clean up (where many operators aggregated their classful addresses where possible) post-migration to classless routing, the 192/8 address block has remained at contributing around 5,500 prefixes to the Internet Routing Table.  This compares more than favourably with other /8 blocks which the RIRs use for allocations to ISPs, where completed blocks often contribute 8000 or 9000 prefixes each.

Looking into the former class B space (128/8 up to 191/8), there is significant deaggregation in the legacy class B assignments, but more than likely caused by issues discussed in the previous two sections.  The same is true for legacy assignments in the former class A space.

5.  Impacts of the Routing Table Size

Why should the size of the Internet Routing Table matter?  In the discussion so far, little more than prudence has been mentioned in what should be announced to the Internet.  But there are many issues facing Autonomous Systems participating in the Internet today.

5.1 Router Memory

Throughout the history of the Internet, routing equipment vendors have specified routing equipment to be sufficient for the networks of the day. In the rapidly growing Internet, this has caused anguish for operators at various stages.  A rapidly growing Internet has seen routers with sufficient memory to carry the full table one year become obsolete the following year; even with the router being upgraded to maximum memory it still has not sufficient capacity to store the table as it stands.

Newer model routers with larger memory are the natural replacements, meaning a very short shelf life of a router compared with other components in the Internet.  These equipment upgrades result in upheaval in the service provider networks.

5.2 Router Processing Power

Another resource under pressure is that of the router CPU (control plane). The larger the Internet Routing Table is, the longer it takes the router CPU to process on initial establishment of the BGP session with neighbouring Autonomous Systems, and the more time the router CPU requires to process changes in this Routing Table due to topology changes.  Faster CPUs reduce this time, so the network operator is faced with having to upgrade router CPUs, often by fork-lift upgrades (swapping entire chassis), just to keep the same routing performance within their network.

A typical scenario was presented in [6] following a request to provide a prediction on the size of routers needed in five years time - the shelf life of existing router hardware is reducing with the increasing size of the table and the increasing number of routing information updates being seen on the Internet.

5.3 Routing Convergence

Routing convergence is when the network has finally figured out the best path to a particular destination.  It needs to happen every time a route is withdrawn or re-announced; this computation takes time.

The two keys factors affecting the time it takes for routing to converge are the router CPU and routing table size.  The more prefixes there are in the Internet Routing Table, the more work a router will have to do to find the new routes.  This time can be reduced by using a faster CPUs, usually by going to the expense and inconvenience of upgrading the control plane; replacing the entire router chassis (so-called fork-lift upgrade) introduces even greater costs for the operator, not to mention the impact of network down-time.  The alternative is by reducing the size of the Internet Routing Table through aggregating prefixes into as few announcements as possible.

Slow convergence means slow recovery in the event of network failure, and results in a much more customer visible network issue.

5.4 Network Performance

The performance of the network is something that network operators don't consider has anything to do with prefix announcements to the Internet.

However, it is relatively easy to demonstrate that failure to announce the aggregate makes the overall Internet experience of the end users of the local network somewhat poorer than if the aggregate was announced.

A typical and common situation that the authors have encountered is where a network operator announces prefixes in their internal BGP out to the Internet (by external BGP).  Customer prefixes are injected into the internal BGP when the link to the customer is active, and then withdrawn when the link to the customer is inactive.  The problem with leaking the internal BGP out to the Internet is that these customer prefixes have to be withdrawn from all the routers which carry the full Internet Routing Table across the entire Internet.  And this withdrawal does not happen instantly [7] or uniformly, with the attendant problems this causes.  When the customer link returns, their prefix is re-injected into their provider's internal BGP, and then further announced out to the Internet. The propogation of the out-bound announcement again doesn't happen instantly.

The result of all this is that the End User sees the Internet as being not immediately available once their link returns.  Support calls to their service provider are handled negatively because as far as the service provider is concerned there is nothing wrong.

If the service provider had not leaked their internal BGP to the Internet, but instead announced their aggregate and any necessary traffic engineering sub-prefixes, their customer would not have seen the delays in the restoration of usability of their Internet connection.

6. Solutions

Various solutions to the problem of the growth of the Internet routing table have been proposed and attempted over recent years.

6.1 The CIDR Report

The CIDR Report originally was one technique employed to hold the Internet Routing Growth in check.  The idea behind the CIDR Report was to encourage ISPs to aggregate.  Its effectiveness was primarily through peer pressure, naming and shaming.  It was effective in the early years of the migration from classful to classless Internet, but in recent years, there is some evidence of ISPs using their prominent position in the CIDR Report as positive marketing regarding their status and influence in the Internet!

In recent years the CIDR Report has been greatly enhanced over the early reporting tool, with the associated website [1] having a user interface to allow network operators to check their aggregation efforts.  The CIDR Report even includes a tool which will take the routing table view it has for a particular ASN and suggest aggregation possibilities.  There is little reason for any network operator to be unaware of their announcements to the Internet Routing Table, and also little excuse for them not knowing how to improve their aggregation efforts.

6.2 Filtering

Another technique employed is the filtering on the RIR minimum allocation sizes per address block allocated by the IANA to the RIRs.  For example, if an RIR's smallest allocation from a particular /8 block was a /21, the network operators would filter routing announcements received from external networks such that prefixes smaller than the /21 would be rejected.  One positive result is that operators announce larger prefixes (and even their aggregate blocks) to get around these filters.

Effects of general prefix filtering can be seen on the CIDR Report website [4], which has views of the full Internet Routing Table as seen from many different Autonomous Systems.

It's not clear how many network operators employ filtering based on RIR minimum allocation sizes, nor is it clear if such filtering is completely useful in achieving its intention of limiting routing table size.  Very clearly, if a network operator has received the minimum allocation from their RIR, their ability to traffic engineer for multihoming is somewhat restricted - they cannot subdivide their address block for traffic engineering purposes if their upstream provider filters on the RIR minimum allocation boundaries.

6.3 The "CIDR Police"

In the late 90s and early 00s, a small group of volunteers analysed the various routing table announcement reports, and gave their time freely to work with ISPs who were announcing more prefixes than they apparently needed to [8].  They would look for ISPs announcing contiguous /24 prefixes, and suggest that merging these into a single larger announcement would be beneficial to the Internet Routing Table.  This met with varying levels of success, ranging from cooperation and appreciation to hostility and even abuse from the network operators concerned.

Around the time of the Internet "bust" in 2001, the volunteers behind the "CIDR Police" effort moved on to other priorities facing them.  While recent years have seen some discussion about restarting the "CIDR Police" effort, nothing has yet materialised at the time of writing.

6.4 BGP Features

The Internet community (mainly the ISPs and the equipment vendors) have also worked to add features within BGP to assist with aggregation efforts. These are discussed in turn.

6.4.1 The NO_EXPORT BGP Community

The first aid for multihoming and prefix aggregation came in the form of the NO_EXPORT BGP Community, described as part of the BGP Community Attribute specification [9].  A prefix tagged with this community would not be advertised by one eBGP speaker to another.

The idea is that a service provider would leak sub-prefixes to their upstream or peer provider to aid with traffic engineering; but tag these sub-prefixes with the "no_export" community to indicate to their upstream that these sub-prefixes should not be announced to any other autonomous system.  Many providers use this community for traffic engineering purposes, but the usage is perhaps not as widespread as it could be.

6.4.2 The NOPEER BGP Community

The next aid to assist with the traffic engineering and aggregation quandary was the NOPEER BGP Community.  This was introduced relatively recently [10], but has had no support from the equipment vendors (no known implementations), and apparently little demand from any Internet Service Providers.

The idea here is that a service provider who wishes to deaggregate to support traffic engineering for multihoming would tag such "traffic engineering" sub-prefixes with the NOPEER community.  Upstream ISPs would then propagate or discard these prefixes depending on whether the eBGP relationship would be deemed as a peer or not.

Internet Service Providers generally have three types of relationships with other providers in the Internet: upstream, bi-lateral peer, or customer.  Support of the NOPEER community would be provided by the providers indicating in their router configurations whether the BGP peering was with an upstream, bi-lateral peer, or customer.  Upstream and customer BGP peerings would see the NOPEER tagged prefixes being propagated on the peering, whereas bi-lateral peerings would see the NOPEER tagged prefixes being discarded.  This allows the edge provider attempting to carry out traffic engineering do so all the way to the "Internet core", but not see the "Internet core" having to carry the sub-prefixes being required for this traffic engineering.

There are estimated to be around ten service providers at the core of the Internet who have a no-fee peering relationship with each other [11], and with the bulk of the Internet's ASNs appearing at the edge rather than the transit core, the impact of the edge providers using the NOPEER community with attendant support in the transit core could be quite significant on the size of the routing table as seen at the "Internet core".

6.4.3 The "AS_PATHLIMIT:" Attribute

The latest contribution to assist with traffic engineering needs for multihoming ISPs has been the proposal to introduce an AS_PATHLIMIT attribute [12].

The idea here is to restrict the propagation of a prefix to a particular AS radius, as determined by the value of the AS_PATHLIMIT attribute.  The attribute contains the maximum number of ASNs that can appear in the AS path (as well as the ASN which introduced the attribute).  Each AS would compare the value of the attribute with the number of ASNs in the AS_PATH. If the number of ASNs in the AS_PATH is greater than the value of the AS_PATHLIMIT, the prefix would not be processed internally in the network, or propagated to eBGP peers.  This would allow service providers to do localised traffic engineering with out other providers at more distant points in the Internet having to see those specific traffic engineering prefixes.

6.4.4 Provider-Specific Communities

Many transit providers permit their customers to use BGP communities to signify a degree of prefix propagation greater than NO_EXPORT, but less then permitting it into the global routing tables.  This often includes options such as "all regional peers", "all peers" (but not their transit providers), or in some cases even just specific peers with which the customer is multihomed.

Provider-specific communities are usually documented either on the provider's website, or sometimes as part of the Route Object within the Internet Routing Registry system.  The community values are not coordinated, although several ISPs do attempt to use similar values to achieve the same effect, following the spirit of RFC1998 [13] describing InternetMCI's community usage in the mid 90s.  Known examples of provider-specific communities are documented at [14].

Care needs to be taken to ensure that BGP policies on routers are carefully maintained, as route propagation needs to match the intent of the community.  Unintended leakage of routes can propagate into the global routing tables, negating the intent of this form of restricted propagation.

7. Recommendations

The latter part of this document describes the RIPE Routing Working Group recommendations for making routing announcements to the Internet.  It is hoped and expected that all network operators will follow these recommendations so that the growth of the Internet Routing Table is kept in check, and will only be as much as is absolutely essential.

7.1 Initial Allocations

When the network operator receives an IP address allocation from the RIR or an assignment from their upstream ISP, the expectation of the entire Internet community is that these IP addresses are combined into the largest feasible block and announced as such to the rest of the Internet.

For example, if a network operator receives a /21 from their RIR, they should configure BGP to announce only this /21 to neighbouring Autonomous Systems.

7.2 Subsequent Allocations

Whenever possible, the RIRs attempt to make allocations to their LIR members which are contiguous with previous allocations.  When the network operator receives a new allocation or assignment which is the same size as the original allocation and is contiguous with it, they should combine the two address block and announce them as an aggregate.

For example, suppose a network operator was originally allocated a /21 and now receives the neighbouring /21.  If the two /21s fall on the correct bit boundary, they can be combined into a /20.  They should then announce this /20 to their neighbouring ASNs, and remove the announcement of the original /21.

If the subsequent allocation is not contiguous, or is contiguous but falls foul of bit boundaries, or is of a different size to the previous allocation, then there is no aggregation which can be carried out and the network operator should announce the two address blocks separately.

7.3 Multihoming

If the network operator has a multihomed network, they will have a requirement to subdivide their address block (or blocks) to aid traffic engineering.  If the operator needs to do this, they must still announce their address block, as without this announcement they will get no backup should the alternative link or links fail.  The subdivision of this address block should be done prudently - tutorials have been presented at various network operations fora over the last few years explaining how this could be done, achieving maximum traffic engineering effect but with out harshly impacting the Internet Routing Table [15].

7.4 BGP Enhancements

The various BGP enhancements described in Section 6.4 should also be considered where appropriate, and where supported by the router vendors. Most of the ISPs outside the transit core will find a use for the NO_EXPORT and NOPEER BGP Communities, as well as the new "AS_PATHLIMIT BGP:" Attribute, allowing them to limit the number of traffic engineering related sub-prefixes being propagated across the Internet.

7.5 Proxy Aggregation

Proxy aggregation needs to be handled very carefully.  Aggregating announcements originated by other ASNs can lead to undesirable effects, especially with the traffic engineering desires of the other ASNs, and with "black-holing" their traffic in the event of link failure.  Proxy aggregation only makes sense when the network operator has ascertained that the aggregation will not impact the operations of the affected networks (for example, the affected network may be multihomed onto the same upstream provider only).

7.6 IP version 6

While these recommendations have focused entirely on the IPv4 Internet, they are equally applicable to the use of IPv6.  Participation in the IPv6 Internet is no different from participation in the IPv4 Internet, and the expectations on networks or Autonomous Systems are exactly the same in both cases.

8. Conclusion

Aggregation is a necessary activity for network operators participating in today's Internet.  What was taken for granted following the migration to the classless Internet in the early 90s no longer seems to be a standard activity for most network operators.  The result is rampant growth of the Internet Routing Table, causing issues which impact every participant in the Internet.

BGP analysis activities such as those at [16] show the potential savings on the size of the Internet Routing Table - and these savings are potentially significant, anything from 30% to 50% depending on the measurements made and the view of the Internet Routing Table being used.

9. Acknowledgments

Thanks to the LINX membership for the original idea (LINX's experiment with a Routing Aggregation Policy [17]) and to Mike Hughes for the initial text which formed the basis of this document.  Thanks to Leo Vegoda, Geoff Huston, Gaurab Raj Upadhaya and Duncan Rogerson for their helpful comments and suggestions.

Y. References

[1] The CIDR Report | Original Idea: Tony Bates | Maintained by: Geoff Huston

[2] RFC 1518 - An Architecture for IP Address Allocation with CIDR | Tony Li and Yakov Rekhter

[3] RFC 1519 - Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy | Vince Fuller, Tony Li, Jessica Yu and Kannan Varadhan

[4] Routing Table Status Report | Geoff Huston - APRICOT 2005/APNIC 19

[5] The Route Views Project | University of Oregon

[6] Routing Update | Geoff Huston - APRICOT 2006/APNIC 21

[7] Delayed Internet Routing Convergence | Craig Labovitz, Abha Ahuja, Abhijit Bose and Farnam Jihanian - Sigcomm 2000

[8] CIDR Police - Please Pull Over and Show Us Your BGP Announcements | Barry Greene and Hank Nussbacher - NANOG 27

[9] RFC 1997 - BGP Communities Attribute | Ravi Chandra and Paul Traina

[10] RFC 3765 - NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control | Geoff Huston

[11] AS Path Analysis | Vijay Kuhmar Adhikari, Gaurab Raj Upadhaya and Bill Woodcock - SANOG 8

[12] AS-PATHLIMIT Attribute | Joe Abley, Tony Li and Rex Fernando

[13] RFC1998 - An Application of the BGP Community Attribute in Multihome Routing | Enke Chen and Tony Bates

[14] BGP Community Guide

[15] BGP Multihoming Techniques | Philip Smith - NANOG 35

[16] Aggregation Potential

[17] The Routing Aggregation Policy - A Failed Social Experiment at the LINX | Nigel Titley - APNIC 21

Z. Authors

The authors can be contacted as follows:

Philip Smith | pfs@cisco.com
Rob Evans | rhe@nosc.ja.net
Mike Hughes | mike@linx.net