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

Tue Feb 14 18:48:36 EST 2006

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
> > >
> 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml