Last Modified: 2004-05-18
The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures.
GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol.
GOALS: -----
(i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure.
(ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values.
(iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit.
(iv). Determine the effect of IGP extensions on the stability of the Internet routing system.
(v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs.
Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms
| Done | Publish Risk, Interference and Fit (RIFT) document as WG I-D | |
| Done | Publish Embedding Globally ...Considered Harmful as WG I-D | |
| Done | Publish MED Considerations Draft as WG I-D | |
| Done | Publish Collection Communities as WG I-D | |
| Done | Submit Collection Communities to IESG for BCP | |
| Sep 04 | Submit MED Considerations to IESG for Info | |
| Sep 04 | Submit Embedding Globally ...Considered Harmful to IESG for Info | |
| Dec 04 | Submit the RIFT document to IESG for Info |
|
Global Routing Operations (grow) THURSDAY, August 5, 2004 (1530-1730) ==================================== CHAIR(s): Geoff Huston <gih@telstra.net> David Meyer <dmm@1-4-5.net> MINUTES: Jeffrey Haas <jhaas@nexthop.com> Plug for xml2rfc Agenda: Charter update Review and status of work items - active drafts - inactive drafts BGP Status Reports Active drafts: bgp-med-considerations - ready for last call, but missing a diagram. needs last call grow-collection-communities - waiting for input from AD. comments from Sue Hares. grow-embed-addr - waiting for input from AD grow-rift - started after vienna routing wg meeting. presupposed answer to question trying to analyze. design team formed - hasn't been too functional recently. Current draft needs revision, David Meyer hasn't had a chance to work on it recently. Please look at controversial sections: fit for different kinds of signalling applications. David Meyer will try to rewrite that particular section. Please read it. Eric Rosen: Is this still needed? it's purpose was to kill something anyway. David Meyer: Need to ask AD. They chartered it. Eric Rosen: Let it expire? Yakov Rekhter: WG consensu to let it expire? David Meyer: Consensus of room inconclusive - take it to list. Expired / inactive drafts bounded-longest-match - bgp-redistribution - Will take it to list to see if we let it lapse to individual submissions Geoff Huston (with APNIC hat on): Routing table status report The various views, although differing, follow the same general progression. We see an interesting drop in the table in 2000 from the previous Internet boom expoential-like growth. Afterwards it appears roughly linear. How much address space does this carry? [2/2000 - current time] 1 billion-1.3 billion /32's. Approximately 1/4 of the IPv4 address space. There is some banding going on - apparently from flapping /8's. Interesting that the /8's are flapping. 2002 had a decrease from the linear growth in address use, but 2003 resumed the linear growth. More specifics - how much are more specifics of existing advertisements? 2001 - 55% of the entries "added nothing". More recently, this has declined to 51%. David Meyer: Has this analysis been done with paths as well? Geoff Huston: Yes. The difference is just a few percentage points. Once the routes reach route-views, the more specifics make no difference. Growth of ASNs 17000 unique ASN's. Majority originate some routes Very few are transit only Systematic filtering is happening or something similar. Some views of the Internet have a consistently smaller numbers. The difference is up to 1000. AT&T/Verio is one of the views that this is true. This leads to the observation that strong prefix filtering may result in some information loss, but this begs the question of whether this results in loss of forwarding information. Average AS Path Length: Most folk who peer with route views have an average AS distance of 4 ASes. As the number of ASes increases, the interconnectivity density increases. The inference is that once you count past 4, you count past the average diameter of the Internet. Aggregation potential: [2002-2004] If you eliminate more specifics that eliminate shared as paths, including the ones with prepending, we would be carrying (today) 98k entries in the RIB. If you were more aggressive and eliminate additional prepending, we lose only another 2k. There are around 8-9k entries which are more specifics with a different AS Path. The bulk of the more specifics share the same AS Path - and thus do not add to the useful information advertised. (Note that this comes from a single view.) George Michelson: Does this graph elected to say the more .. Geoff Huston: The bigger the table, the longer the period. Thus, we're adding more specifics more quickly. George: Thus eliminating more specifics buys us more time? Geoff Huston: Another interesting thing to match is the rate of updates against covered more specifics. If the updates are flapping in more specifics, you can make some judgement about who is contributing to the load. IPv6 routing table is slightly linear (12 months). Starts at 400 and a few weeks ago is 640. Much more massive instability from Geoff Huston's view of BGP. There are also some massive breaks. Perhaps observing the IPv6 summits would account for some spikes in the table. Thus, the table is very small and growth is driven by external events. The amount of addresses spanned is much harder. In ipv6 there are two sets of addresses. RIR's use 2001/16. They allocate a /32. 6bone uses 3ffe/16, they allocate a /24. Thus the 6bone space and it's dynamicism heavily affects the observed address spanned. Unique ASN's - ~450 today comapared to > 8K in IPv4. The curve shape more closely matches the observed address usage. If the goal was strong matching for aggregation 1-as to 1-prefix, this seems to be occuring. Aggregation potential - they are very very close and thus not many that you can eliminate. The v6 table doesn't exhibit same properties as v4 table. Thus, aggregation is working. Current snapshot of observed address space. IETF (multicast, etc). Not routed space that has been handed out is dominated by class A historical allocations from IANA. No one is trying to figure out if they should be reclaimed. Most of the recently allocated RIR space has been allocated is actually being routed. (Class A space) Historic B space doesn't match this. Not much of this is being routed. Current ASN's: We're about 1/2 through the allocatable ASN's. Old ASN's don't die. Recently allocated ones correlate strongly to the ones routed. Amount of 6bone space that is routed is checker-boarded. Only a small amount of RIR allocated space is routed in 6bone. Tony Li: I've done similar computation to what Geoff Huston has done, he deserves a round of applause. ---- Global Routing Operations (grow) THURSDAY, August 5, 2004 (1530-1730) ==================================== CHAIR(s): Geoff Huston <gih@telstra.net> David Meyer <dmm@1-4-5.net> AGENDA o Administriva 5 minutes - Mailing list: majordomo@lists.uoregon.edu subscribe grow - Scribe? - Blue Sheets o Agenda Bashing 5 minutes Meyer o Charter update 5 minutes o Review and status of work items 45 minutes Active Drafts ------------- draft-ietf-grow-bgp-med-considerations-01.txt 5 minutes McPherson/Gill draft-ietf-grow-collection-communities-04.txt 5 minutes Meyer draft-ietf-grow-embed-addr-03.txt 5 minutes Plonka draft-ietf-grow-rift-01.txt 10 minutes Meyer Expired/Inactive Drafts ----------------------- draft-grow-bounded-longest-match-01.txt 10 minutes draft-hardie-bounded-longest-match-05.txt Hardie/White draft-ietf-grow-bgp-redistribution-01.txt 10 minutes Bonaventure et al o BGP Status Reports 20 minutes Huston/All |