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

[william(at)elan.net]

Actually I noticed that even without PI, ARIN most often makes IPv6
allocations to ISPs in the same city/region that they are nearby.

On Tue, 14 Feb 2006, Tony Hain wrote:

> I realize that ARIN policy does not talk about routability, but would it
> make sense in the PI case to talk about a get-started approach where PI
> allocations were made from 1000::/4 using the geo algorithm and limiting the
> accepted prefixes in that block to /40? Any organization that could not
> claim unique possession to at least one physical lot of 100 meters in any
> direction would not make the cut. No exchange points or business practice
> changes required...
>
> If that still feels like too many PI entries, make the limit a /36 which
> would cut it back to those organizations with a 400 meter footprint.
>
> Tony
>
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
>> Tony Hain
>> Sent: Sunday, February 05, 2006 10:28 PM
>> To: 'Scott Leibrand'; ppml at arin.net
>> Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*)
>>
>> Scott Leibrand wrote:
>>> 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.
>>
>> Exchange points are discussed, but would only really be required to
>> suppress
>> the basement multi-homer. There are business model issues tied up in this
>> that will take a long time to resolve if they ever do. In the short term
>> just basing PI allocations on this model would at least allow for the
>> option
>> later where random PI assignments would be difficult to sort out.
>>
>>>
>>> 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.)
>>
>> To judge there needs to be some agreed on goals. The IETF effort in that
>> space showed how there can never be agreement since the requirements of
>> the
>> ISP community and the end site community are in direct conflict.
>>
>>>  - 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).
>>
>> A presumption for all approaches is that organizations that have an AS
>> entry
>> in BGP will have at least one prefix. Hopefully one will be sufficient,
>> but
>> I am hearing noise that some organizations want hundreds to deal with
>> their
>> VPN scenario.
>>
>>>  - 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.
>>
>> I didn't want to get into the details of engineering the region more than
>> to
>> point out that some interchange will have to happen.
>>
>>>  - 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.
>>
>> The business models will develop based on what makes sense for that
>> specific
>> 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.
>>
>> I don't expect transit providers to even consider aggregation until there
>> is
>> an exchange point in the region acting as their customer and fronting for
>> the local distribution of traffic. Fortunately it is not required to get
>> started and can come along when it makes more sense to aggregate than to
>> buy
>> bigger routers.
>>
>> Thanks for the feedback,
>> Tony
>>
>>
>>>
>>> -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