[ppml] Practical alternatives to v6 deaggregation for ISP/NSPs
Kevin - Your.Org
kevin at your.org
Wed Mar 12 13:30:49 EDT 2008
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
> /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. :)
More information about the ARIN-PPML