[ppml] Practical alternatives to v6 deaggregation for ISP/NSPs
Kevin - Your.Org
kevin at your.org
Wed Mar 12 13:30:49 EDT 2008
- Previous message: [ppml] Practical alternatives to v6 deaggregation for ISP/NSPs
- Next message: [ppml] 2008-2 IPv4 transfer policy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mar 12, 2008, at 11:16 AM, mcr at simtone.net wrote: > >>>>>> "Kevin" == Kevin Day <kevin at your.org> writes: > Kevin> What we do now in v4: > > Kevin> We have a /19. One /24 is reserved for anycast, and > Kevin> announced from all our POPs. One /23 is announced at each > Kevin> POP. > > Kevin> This works really well for us. Nearly everyone will accept > Kevin> announcements down to a /24, and for those that don't we > Kevin> announce the full /19 as well. > > So, if your /19 attracts traffic to the wrong POP's ISP, you are > depending upon each of the POP's transit ISP to also have accepted > your > /24s, and that those ISPs either peer directly, or do so through ISPs > that will transit those /24s. Right now, in v4, we have zero problem with transit networks accepting deaggregates. That's what's different in v6. There's no problem where traffic is coming into the wrong POP because the deaggregates are being propagated pretty much globally. All of our transit providers in v4 accept deaggregates, and all of THEIR providers do as well, etc. For the most part, the only networks that are filtering on RIR boundaries are more towards the edges. Withdrawing the covering /19 doesn't even make a perceptible difference in traffic coming in to us, so the number of networks doing it is tiny. > > The second (more architecturally pure) answer is that perhaps you > should have asked for and received PA /48s from each ISP for each POP > and/or end-user PI /48s from ARIN. You'd want at least one PI /48 for > your anycast announcement, I think. We multihome in every POP, so PA space isn't possible for us. > > Kevin> Possible solution #2 - Get more address space. > > well, you need different address space, not more. > Exactly my point, but something that the current policy doesn't allow. > > Fundamentally, ASNs are supposed to convex, and yours are concave. > Possibly, but I don't think our network is unique or doing anything "wrong". None of our transit providers, peers or other entities we do business with have had any issues with the way we're running our network, the only resistance I'm getting is policy based. :) -- Kevin
- Previous message: [ppml] Practical alternatives to v6 deaggregation for ISP/NSPs
- Next message: [ppml] 2008-2 IPv4 transfer policy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list