[ppml] 2005-1 status

Tony Hain alh-ietf at tndh.net
Thu Feb 2 20:20:04 EST 2006


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




More information about the ARIN-PPML mailing list