|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: geography to get PI in v6 (was: ULA and RIR cost-recovery)
On 25-nov-04, at 13:46, [email protected] wrote: The problem with this scheme is that it's only aggregatable if there's some POP that lots of carriers connect to in the proper geographic areas. What is the carriers' incentive to show up -- peer? -- at such points, rather than following today's practices? Leaving aside the specifics of any particular geopgraphic addressing scheme for the moment... Right. There are several ways to do this. This is what it seems like on first glance. However, if we take a different approach we arrive at the same result but with a very different mindset.If we adopt a geographic addressing scheme for a part of the IPv6 space we are really saying that we expect a part of the IPv6 network topology to be geographically based. The idea is that we need to aggregate, because if we let anyone and everyone have a PI block without aggregation in IPv6 bad things will happen to the global routing table. The obvious thing to aggregate on is the ISP used. This is what we do every day. Unfortunately, you don't get provider independence this way. With provider aggragation out the window, it turns out that it doesn't really matter much on what you aggregate. For instance, we can aggregate on the first byte of the IPv4 address. So all destinations that have 192 as the first number in their address are aggregated together, just like 193, 194 and so on. Suppose we have three routers: Router A contains all more specifics for 192/8 and the 193 and 194 aggregates Router B contains all more specifics for 193/8 and the 192 and 194 aggregates Router C contains all more specifics for 194/8 and the 192 and 193 aggregates So all traffic towards any destination within 192/8 will have to flow through router A, and so on. This works very well if router A is close to the destinations in question, but it gets problematic when there aren't any routers covering the aggregate for a certain destination close to that destination. So if destination X with address 192.0.0.1 is in Paris, and router A is also in Paris, this works out great. If router A is in London or Frankfurt, this isn't quite optimal but the scenic routing isn't too bad. But if router A happens to be in Auckland, this is not so great. There are two ways to solve this: 1. Have router A instances everywhere. This basically means multiplying the number of routers by the number of aggregates used. Not so great. 2. Rather than aggregate arbitrarily, do it based on geography so there only need to be a few router A instances. No. You are assuming a single aggregation level. But there can be many: city, state/province, country, continent. If I have traffic for Amazon, all I need to know is that it should make its way across the Atlantic. At the US East Coast, there are probably aggregates for all the US states, and finally in or close to Seattle all more specifics must be present.While it is convenient to think og geographical divisions in terms of boundaries, in real world networks the geographical divisions are defined by peering points which the real world refers to as "major cities". So if we do adopt a geographic addressing scheme it makes no sense at all for the RIRs to allocate these addresses to entities that happen to be inside a specific geographic boundary. Should there not be an interconnect with other networks in Seattle, then the more specifics must be present in a wider area. So peering within the target area isn't required, although it makes for better aggregation of course. Peering can change. Geography can't. (Unless you live in an earthquake-prone region.)However, it makes perfect sense to allocate these geographic addresses to an entity who is peering at one or more of the peering points within a geographic boundary. The advantage of doing geographic aggregation like this (i.e., the aggregates are only used within ISP networks and not announced to other ISPs) is that everyone can implement the aggregation as desired without global coordination, but the PI benefits start as soon as end-users get the geographically aggregatable address space. So it makes no sense to adopt unaggregatable PI space, geographically aggregatable provider independent (GAPI) address space is always better.
|