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

[Tony Hain]

No, it is just a prefix like any other. While some deployments of PI are
simply to avoid lock-in, in others it needs to be announced in multiple
places. By restricting the length you limit the potential impact to the
routing system. No evaluation of the network topology or plans is necessary
because the prefix length is based on building/lot size.

Tony 


> -----Original Message-----
> From: Houle, Joseph D (Joe), CMO [mailto:jdhoule at att.com]
> Sent: Tuesday, February 14, 2006 6:11 PM
> To: Tony Hain; ppml at arin.net
> Subject: RE: [ppml] Geo PI (draft-hain-ipv6-pi-addr-*)
> 
> 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