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

Tue Feb 14 21:11:11 EST 2006

Tony:
   And advertise that block in its entirety only from that one
geographic location?  
	Joe Houle

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
Tony Hain
Sent: Tuesday, February 14, 2006 5:49 PM
To: ppml at arin.net
Subject: Re: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*)

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

_______________________________________________
PPML mailing list
PPML at arin.net
http://lists.arin.net/mailman/listinfo/ppml