[ppml] "Recommended Practices" procedure

Another consideration is that a PA /48 need not be accepted globally to be
usable for multihoming.  If both your transit providers accept your /48
from you and from each other, you can be guaranteed reachability.  (You
may not be able to do the kind of traffic engineering you might want,
though.)

As a result of this, I would maintain that you (as a hypothetical
enterprise wishing to multihome with PA space) should (eventually) be able
to find two transit providers willing to take your money and guarantee
that they'll listen to your /48 from each other.  If you can't, then
perhaps you need to offer them more money (or get PI space).  :)

Now back to "Recommended Practices", it would be fairly easy to construct
a routing policy to do this across the board.  On each peering link, allow
pe:er::pr:ef:ix/32 le 48
yo:ur::pr:ef:ix/32 le 48
PI::ne:tb:lo:ck/XX le 48
and
ev:er:yt:hi:ng::el:se/32

-Scott

On 06/29/06 at 1:47pm -0400, Jason Schiller (schiller at uu.net)...:

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