[ppml] Practical alternatives to v6 deaggregation for ISP/NSPs

On Mar 12, 2008, at 12:14 AM, Scott Leibrand wrote:

> Kevin,
>
> A couple thoughts:
>
> You could try announcing your deaggregates (/36 or whatever), in  
> addition to announcing the /32, and *without* no-export set.  This  
> is what I envision we'll do when we deploy IPv6.  Most people I've  
> talked to agree that, as long as you're announcing the /32, that  
> should be allowed, and it's up to everyone to decide whether or not  
> to accept the more-specifics.  If you're paying a transit provider  
> to do so, they should accept them, and should accept the same more- 
> specifics from their peers.  As long as your ISPs (or their transit  
> providers) peer with each other, and accept the more-specifics from  
> each other, you should have full reachability, and you shouldn't  
> have to transport the packets yourself (you're paying your ISPs to  
> do that).
>

That doesn't work though... Imagine this scenario:

POP A = 2001:1234:1000/36.
POP B = 2001:1234:2000/36.

POP A <---> Transit 1 <--> Big NSP 1 <---> Big NSP 2 <--> Transit 2  
<---> POP B

POP A announces to Transit 1 2001:1234:1000/36.
I convince Transit 1 to accept that, because I'm paying them to. They  
in turn announce it to Big NSP 1.
Transit 1 may or may not have enough pull with the Big NSP 1 to make  
them make exceptions to their filters. Even in the most optimistic  
case, assume they do.
Big NSP 2 probably isn't going to accept deaggregates of all of Big  
NSP 1's customers, so Big NSP 2 doesn't accept it.
POP B advertises that /32 and 2001:1234:2000/36 to Transit 2.

Transit 2's view of the world is:

2001:1234::/32 -> POP B.
2001:1234:2000/36 -> POP B.

The /36 for POP A got filtered out several hops before it reached  
Transit 2, so Transit 2 has no choice but to send traffic for  
2001:1234:1000/36 to POP B.

I can ensure that my direct upstreams accept all my deaggregates, I  
can't ensure that they get propagated to all my other upstreams at  
other POPs. There are any number of intermediaries between the transit  
providers at each POP, and if ALL of them accept the deaggregates then  
it means that nobody is doing any filtering at all. If you don't  
believe my example with just two "Big NSPs", add 5 of them.. do you  
really believe that many of them are going to accept deaggregates from  
customers of customers of customers....? (And no, that's not entirely  
unreasonable, even in v4 right now, our path from our Amsterdam POP to  
our Tokyo POP is 7 ASNs long)

You are right, if all of our upstreams peer with each other then it  
probably does work. But, for example, our small upstream provider in  
Sydney probably doesn't peer with our upstream provider in Berlin.  
There are a lot of networks between those two, and there's no way  
every one is going to accept deaggregates from everyone else unless  
they just aren't filtering at all. Personal experience and views from  
the SIxXS GRH pages seem to indicate that people are filtering  
already. I'm also not really that comfortable in basing my network on  
unrelated party's peering. If one gets into a peering war with  
another, I don't want my network to go down.

> Alternately, you could perhaps give back your /32, and instead get a  
> PI /48 from ARIN (under the end user policy) for each site (or  
> perhaps a contiguous /44 to get you a /48 per site).  I'm not sure  
> if that policy applies in your case, or if that would be a better  
> idea overall in your situation than using a /32, but it seems more  
> reasonable than trying to get additional /32's or "critical  
> infrastructure" blocks.
>

Well... For one, we need to be able to assign /48's to our customers,  
so I'm not sure an end-user allocation is going to work for us.  
Secondly, I don't believe current policy allows for getting more than  
one /48 without using up the first.

We could ask for a /44, but from the sounds of it, that will cause  
people who are filtering on RIR allocations to filter at /44.


I went through the same lines of thinking myself when I started with  
this... It's only when actually trying to do it that I'm running into  
these problems.

I really appreciate your reply though,  it shows others are coming up  
with the same potential solutions that I did.

-- Kevin