[ppml] "Recommended Practices" procedure

Hello;

On Jun 29, 2006, at 4:53 PM, Scott Leibrand wrote:

> On 06/29/06 at 12:20pm -0700, Owen DeLong <owen at delong.com> wrote:
>
>> --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.
>
> I'm sorry, I made an unstated assumption that you're buying transit  
> from
> two transit providers who don't have any transit providers of their  
> own,
> just peers.  IOW, tier 1 NSPs.  Can you enumerate any failure modes in
> that case, or were you just talking about reachability problems for  
> tier 2
> NSPs?
>

I think that any policy that relies on distinguishing between Tier 1  
and Tier 2
should be automatically out of bounds. Every time the subject comes  
up on (say) NANOG it generates much heat but little light, and I know  
of no tool to enable me to check independently whether or not a  
salesman's claims here are accurate.

Regards
Marshall


>> 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.
>
> I agree.  However, I would recommend suggesting it in a "Recommended
> Practices" document, as doing so doesn't pollute the global table,  
> just
> yours and your peers'.
>
> -Scott
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml