[ppml] Geo PI (draft-hain-ipv6-pi-addr-*)

Sat Feb 4 16:47:08 EST 2006

Tony,

I think an approach to lat/long PI addressing such as your 
draft-hain-ipv6-pi-addr-09.txt may be a solid foundation for choosing the PI 
block to assign to each individual organization.  However, I think your 
draft-hain-ipv6-pi-addr-use-09.txt proposals, and previous discussion of 
similar ideas on PPML, have over-engineered the use cases and the 
implications for routing and exchange points.  In particular, I read your 
drafts as requiring that all ISPs in a region would have to agree on the 
level of aggregation for the region and that all ISPs in that region 
interconnect at an exchange point, and also encouraging ISPs to filter 
more-specifics heard from their peers based on how many routes each origin 
AS announces and/or a certain prefix length.  I think that all these 
requirements/suggestions are unnecessarily restrictive stipulations that 
encourage unnecessary opposition to the proposal.

Here's what I see as a more realistic application of Geo PI:

 - Implement some sort of geography-based PI addressing scheme, either one 
like draft-hain-ipv6-pi-addr-09.txt, a population-based scheme like Michael 
Dillon has advocated, or something more like our current system, where RIRs 
allocate PI blocks to individual companies, but choose the particular 
netblock to allocate based on one of the schemes above.  (I'm not sure which 
of those approaches is superior, but we can debate the merits of each 
separately.)
 - Initially, multihomed organizations allocated PI space would probably 
route them the exact same way they do IPv4 PI space today, announcing it in 
BGP to their transit providers, who would advertise it to everyone on the 
planet with a full BGP feed (the DFZ).
 - At some future point, some global tier 1 NSPs* may decide that the 
routing table growth is causing problems for their routers.  At that point, 
they can begin aggregating PI space within their own network, such that 
within a region (which could be a BGP confederation sub-AS, for example) all 
more-specifics for that region are carried, but only the PI aggregate is 
carried outside the region.  In order for an tier 1 NSP to do this 
effectively, they would have to ensure that all of their peers have at least 
two peering points within the region (private peering or exchanged-based, it 
doesn't matter), so that their peers can reach them and their customers' PI 
more-specifics for that region.
 - For transit customers outside the aggregated region, the tier 1 NSP would 
be able to just advertise the PI aggregate.  For peers who only peer outside 
the region, the NSP could do one of several things: they could simply 
advertise the peer their PI aggregate, which opens the possibility of 
providing transit connectivity to the peer; they could carry all 
more-specifics from the aggregated region to the peering router(s), which 
would probably require a multihop BGP session or a tunnel; or they could 
simply not advertise routes from the aggregated region to their peer outside 
that region, requiring the peer to set up a peering point within the 
aggregated region or buy transit connectivity for traffic to that region.
 - When two or more NSPs set up such aggregation, a customer multi-homed to 
both NSPs would be able to announce their PI deaggregate to their transit 
providers just as they do now.  Anyone trying to reach the customer from 
within the region (or from an NSP that doesn't aggregate) would be able to 
choose between the two resulting BGP paths.  Anyone trying to reach the 
customer from outside the region would see the customer's IP space as part 
of a regional aggregate, and would route their traffic towards the region. 
Once the traffic arrived at the region, it would reach a router which would 
be able to choose between the two deaggregated paths, based on the BGP 
metrics (localpref, AS path, MEDs, etc.) set by the origin AS.
 - If the two NSPs the customer multi-homes to decide to aggregate 
differently, it might affect the traffic balance inbound to the multi-homed 
customer, but the customer will still have the leeway to adjust their 
announcements to compensate.  For example, if NSP A aggregates a smaller 
region to a /32, and NSP B aggregates a larger region to a /28, then traffic 
from outside the larger region would prefer NSP A, while traffic from the 
in-between region would prefer NSP B, as the route would still be a 
deaggregate over NSP B in that region.  Once traffic reached the smaller 
region, the origin AS's BGP metrics would take over.

My point here is not that NSPs have to do things this way, but rather that a 
geography-based PI allocation scheme allows them to continue operating with 
the current model as long as they want to, and also gives them the 
flexibility to begin gradually aggregating PI space within their network as 
they see fit (for example by starting with large regions like continents, an 
later aggregating on a more regional basis as needed).  We can implement 
such a geography-based PI allocation scheme *without* requiring everyone (or 
anyone) in a region to set up new interconnections, and without requiring 
anyone to coordinate the precise size of aggregated regions (and thereby the 
length of aggregate prefixes).  IMO that makes it *much* more likely that 
such a system could reach consensus and actually get implemented.

-Scott

* A global tier 1 NSP means one who has a global backbone, don't buy transit 
from anyone, and have full reachability to the rest of the Internet via 
peering arrangements).

P.S. Is there an IETF WG mailing list that draft-hain-ipv6-pi-addr* belong 
to?  If so, I'd like to subscribe and cross-post the above message there as 
well.  TIA.

----- Original Message ----- 
From: "Tony Hain" <alh-ietf at tndh.net>
To: <ppml at arin.net>
Sent: Thursday, February 02, 2006 8:20 PM
Subject: Re: [ppml] 2005-1 status

> An alternative to protocol design in either the routing space or host 
> stacks
> is to reconsider the myth of a global DFZ. The divergence in routeviews
> should already trigger the flag that there is no such thing as a globally
> common DFZ, so arguing PI allocation policy in the context of its impact 
> on
> this mythical entity is bound to drag on.
>
> I just refreshed my geo I-D's
> http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-09.txt
> http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt
>
> Rather than argue about the topology/geography argument, please consider
> that this is:
> 1) an identifiable block
> 2) does not require any changes to existing hosts or routers
> 3) removes any arguments about prefix length vs. organizational size
> 4) allows for simple proxy aggregation where the detail becomes irrelevant
> 5) debases ITU/national arguments over access to sovereign allocations
>
> In the worst case these degenerate to the same number of routing slots as 
> an
> arbitrary RIR allocation process. At the same time they lay a foundation
> where alternative business practices can evolve to better align the costs
> involved.
>
> Comments are always welcome (particularly thoughts about how to resolve 
> the
> altitude problem)
>
> Tony
>
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
>> Scott Leibrand
>> Sent: Thursday, February 02, 2006 6:12 AM
>> To: Bill Darte
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] 2005-1 status
>>
>> Bill and Owen,
>>
>> What if the IETF comes up with a routing architecture / protocol design
>> that allows for effective multihoming with PA space?  That seems more
>> likely to me (in the near term) than a complete replacement of BGP4.
>>
>> IMO policy should recognize the status quo for what it is: the way things
>> are done.  If the status quo needs to change, fine.  That's why we're
>> debating 2005-1.  But I think it's dangerous to make policy with the goal
>> of breaking things so that someone else will be forced to fix them later.
>> IMO we should make policy that meets the current needs of our
>> constituents, and strive to meet their future needs by working through 
>> the
>> IETF process to fix the routing architecture, and then modifying policy 
>> in
>> the future when future interests have emerged and we have a clearer idea
>> of the tradeoffs.
>>
>> -Scott
>>
>> On 02/02/06 at 8:15am -0600, Bill Darte <billd at cait.wustl.edu> wrote:
>>
>> > Owen,
>> >
>> > My personal belief is that you frame the question(s) appropriately in
>> this
>> > post.
>> > If the architecture of the Internet no longer serves the emerging
>> interests
>> > of the constituents, then the architecture should change, rather than
>> trying
>> > to craft discriminating address policy that preserves the status quo.
>> >
>> > On a slightly different topic, with the PI for endsites policy, there 
>> > is
>> no
>> > stipulation about the v4 blocks that exist in the v6 recipients
>> > 'possession'.  You are assuming that that legacy assignment would 
>> > endure
>> in
>> > perpetuity? You have no expectation that the v6 block would require the
>> > legacy v4 blocks, whether PA or PI to be returned?
>> >
>> > I'm not suggesting this be the case...just want this issue to be
>> addressed.
>> >
>> > bd
>> >
>> > > -----Original Message-----
>> > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
>> > > Behalf Of Owen DeLong
>> > > Sent: Thursday, February 02, 2006 12:35 AM
>> > > To: Scott Leibrand; George Kuzmowycz
>> > > Cc: ppml at arin.net
>> > > Subject: Re: [ppml] 2005-1 status
>> > >
>> > >
>> > > _______________________________________________
>> > > PPML mailing list
>> > > PPML at arin.net
>> > > http://lists.arin.net/mailman/listinfo/ppml
>> > >
>> > _______________________________________________
>> > PPML mailing list
>> > PPML at arin.net
>> > http://lists.arin.net/mailman/listinfo/ppml
>> >
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> 