[ppml] "Recommended Practices" procedure

[Azinger, Marla]

Well put.

Marla

-----Original Message-----
From: Jason Schiller (schiller at uu.net) [mailto:jason.schiller at mci.com]
Sent: Thursday, June 29, 2006 10:47 AM
To: brian.knight at us.mizuho-sc.com
Cc: stephen at sprunk.org; Azinger, Marla; ppml at arin.net
Subject: Re: [ppml] "Recommended Practices" procedure


Not that I am in favor of de-aggregation but...

I see the problem very simply, either it is OK to consume one slot (or
more) in the global routing table to make multihoming work or it
isn't.

If it is OK to consume one slot (or more) in the global routing table to
make multihoming that that should be equally true if the slot contains
either a PA or a PI prefix.

Why and end site prefers PI or PA is a very personal question with no
standard answer.  One possible reason is cost, another is administartion,
a third is the number of organization they need to interact with, never
mind if they qualify or can corectly fill out the paper work.  The fact of
the matter is that there are some customers that easily qualify getting
their own space from the RIR and beg us to give them PA space.

The only difference I see between PI and PA space is that if deaggregation
occurs, you can depend on the fact that all of PI is likely to be
deaggregated and not have an aggregate, and all of PA is likely to have
aggregates, and may or may not be deaggregated.  

This is only important if you later decide that deaggegrgation was a bad
idea and change the policy.  You can filter out the more specific PA
address and fall back to the aggregates, you can filter the more specific
PI addresses and break reachibility.  

___Jason




==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller at uu.net
UUNET / Verizon                         jason.schiller at verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Thu, 29 Jun 2006 brian.knight at us.mizuho-sc.com wrote:

> Date: Thu, 29 Jun 2006 12:07:23 -0500
> From: brian.knight at us.mizuho-sc.com
> To: stephen at sprunk.org, marla_azinger at eli.net
> Cc: ppml at arin.net
> Subject: Re: [ppml] "Recommended Practices" procedure
> 
> > What makes punching holes in PA space more attractive than PI space for 
> > them?
> > 
> > This is not an idle question.  While there are many obvious technical and 
> > business reasons for multihomers getting PI space, I'm unable to identify 
> > _any_ reasons for the end site to prefer PA.
> 
> What if the site is unable to justify PI space?
> 
> My organization cannot justify any space under the adopted proposal 2005-1,
> and we multihome today.  Unless the policy is changed or ISP's allow us to
> announce PA space, we can't move to v6.
> 
> Personally speaking, I wouldn't mind a requirement to obtain PI space if I
> knew it was required to multihome and it was easy to justify such space.  I
> don't think my organization would have a problem with it, either.
> 
> I would support a measure similar to the APNIC proposal mentioned by Randy.
> 
> > You're missing the point.  PIv6 is all about giving people the _ability_
> to 
> > multihome.  Multihoming in PA space (v4 or v6) is not an option for both 
> > technical and business reasons.
> 
> Honest questions follow.
> 
> Is the goal simply to prevent carving up /32's?  How will that measure
> control routing table size?
> 
> Or, put another way: To the DFZ router operators, what is the difference if
> the /48 comes from the ISP or from ARIN?
> 
> It seemed that many people had been comfortable with multihoming in PA
> space.  When did that change?
> 
> -Brian Knight
> Sr. Network Engineer
> Mizuho Securities USA, Futures Division
> http://www.mizuho-sc.com/
> 
> * Please note that I do not speak for my employer - only for myself.
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>