[ppml] "Recommended Practices" procedure
Marshall Eubanks
tme at multicasttech.com
Thu Jun 29 17:52:41 EDT 2006
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
More information about the ARIN-PPML
mailing list