[ppml] "Recommended Practices" procedure

[Azinger, Marla]

Yes, I get what you are saying.  The fact being overlooked here is that no matter how it boils down, I have customers that do not want PI space.  I understand that there are some enterprises that think PI space is their dream answer.  But not everyone has the same dream.

Marla

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Owen DeLong
Sent: Thursday, June 29, 2006 12:21 PM
To: Scott Leibrand; Jason Schiller (schiller at uu.net)
Cc: ppml at arin.net; brian.knight at us.mizuho-sc.com
Subject: Re: [ppml] "Recommended Practices" procedure




--On June 29, 2006 2:56:25 PM -0400 Scott Leibrand <sleibrand at internap.com>
wrote:

> 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.)
> 
If their upstreams don't accept it, then, no, you aren't guaranteed
reachability.  You're just slightly less subject to MOST of the things
that take out PART of one of the providers.

However, I've discussed this issue with Marla at length, and, it boils down
to her belief that her customers perceive getting PI space as a complicated
and expensive process.  I suggested several ways she could work around this
issue to both her company's and her customers benefit.  She remains
unconvinced.

I think the cooperating filter policy suggestion is about the best way to
handle this.  If two ISPs want to cooperate and open holes in their PA
blocks with each other, that doesn't mean anyone else has to.  Yes, it
does mean multihoming for those customers is slightly less reliable than
for customers using PI space, but, I don't see a big downside to that.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.