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

Marshall Eubanks tme at multicasttech.com
Wed Feb 15 10:16:36 EST 2006


Hello;

On Feb 14, 2006, at 6:48 PM, 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

What does this mean ? That you need a physical space of 10^4 (100 x  
100) meters ?
Did you mean to say  100 square meters ? Or that you need to be  
within 100 meters
of the center of the block ?

And, who would attest to this ? One advantage of, say, zip codes is  
that there is
an outside entity that instantiates them. If I say I have a rack at  
103deg32min17.15sec West,
39deg44min22.4sec North, how do I prove that ? Normal surveying  
methods don't work inside
a building, and anyway are pretty expensive in this context.

If I am allowed to just make it up (i.e., you trust my GPS reading),  
then what's the point ?
You can bet a lot of people would just make it up.

Regards
Marshall

> 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
>>>>
>>
>> _______________________________________________
>> 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




More information about the ARIN-PPML mailing list