[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