[ppml] "Recommended Practices" procedure

[Owen DeLong]

--On June 29, 2006 4:53:40 PM -0400 Scott Leibrand <sleibrand at internap.com>
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?
> 
Even in that case, it doesn't solve the problem.  One of the providers
will still be the only one advertising the larger block to their peers
unless they have gotten together on a shared multihoming block for
customers that want to do this.

In that case, if the one advertising the aggregate goes away completely,
the nobody outside of the other one will be able to reach you.

Thus my statement that it's workable, but, not as robust as PI space.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060629/c5e0840b/attachment.sig>