[ppml] "Recommended Practices" procedure
Scott Leibrand
sleibrand at internap.com
Thu Jun 29 16:53:40 EDT 2006
- Previous message: [ppml] "Recommended Practices" procedure
- Next message: [ppml] "Recommended Practices" procedure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 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
- Previous message: [ppml] "Recommended Practices" procedure
- Next message: [ppml] "Recommended Practices" procedure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list