And Now for Something Completely Different (was Re: IPv6 news)

Fred Baker fred at cisco.com
Tue Oct 18 19:44:57 UTC 2005


the principal issue I see with your proposal is that it is DUAL  
homing vs MULTI homing. To make it viable, I think you have to say  
something like "two or more ISPs must participate in a multilateral  
peering arrangement that shares the address pool among them". The  
location of the actual peering is immaterial - doing one for Santa  
Barbara County in California might actually mean peering at One  
Wilshire Way in LA, for example. However, the peering arrangement  
would have to be open to the ISPs that serve the community;  
otherwise, it would be exposed to anti-trust litigation (if Cox and  
Verizon, the Cable Modem and DSL providers in Santa Barbara, did  
this, but it was not open to smaller ISPs in the community, the  
latter might complain that it had the effect of locking out  
competition).

But yes, communities of a rational size and density could get an  
address block, the relevant ISPs could all advertise it into the  
backbone, and the ISPs could determine among themselves how to  
deliver traffic to the homes, which I should expect would mean that  
they would deliver directly if they could and otherwise hand off to  
another ISP, and that handoff would require an appropriate routing  
exchange. Can you say "lots of long prefixes within a limited  
domain"? They would want to configure the home's address block on its  
interior interface and route to it through their own networks. Note  
that NAT breaks this... this requires end to end connectivity. I  
should expect that they would not literally expect the homes to run  
BGP (heaven forfend); I could imagine the "last mile" being the last  
bastion of RIP - the home sends a IP update upstream for its interior  
address, and the ISP sends a default route plus routes to its own  
data centers down.

The biggest issue here might be the effect on cost models in routing.  
Today, hot potato routing makes a some relationships relatively cheap  
while other relationships are more expensive; this reverses those.  
Today, if a datagram is handed to me that will be delivered in your  
network, I hand it to you at my earliest opportunity and you deliver  
it. In this model, I can't tell who will deliver it until I get  
relatively close to the community. Hence, I will carry the packet to  
that exchange point, and only then hand it to you. Funny. I described  
this in an internet draft nearly a decade ago, and got dumped on  
because of this issue - something about living in an ivory tower and  
playing with people's livelihoods, as I recall. I'll see if I can  
resurrect that, if you like.

On Oct 18, 2005, at 10:40 AM, Church, Chuck wrote:





>
> Nanog,
>
>     I've been thinking a bunch about this IPv6 multihoming issue.
> It seems that the method of hierarchical summarization will keep the
> global tables small for all single-homed end user blocks.  But the
> multihomed ones will be the problem.  The possible solution I've been
> thinking about is 'adjacency blocks', for lack of a better term.  In
> theory, the first customer to home to two different ISPs causes a new
> large address block to be advertised upstream by these two ISPs.
> Further customers homing to these two ISPs get an allocation out of  
> this
> same block.  The two ISPs will only announce the large block.  Of  
> course
> there are issues involving failure and scalability...
>     Failure would involve an ISP losing contact with end customer,
> but still announcing the aggregate upstream.  This can be solved by
> requiring that two ISPs must have a direct peering agreement, before
> they can accept dual-homed customers.  Or a possible method (maybe  
> using
> communities?) where ISP B will announce the customer's actual block  
> (the
> small one) to it's upstreams, if notified by ISP A that it's not
> reachable by them.  When ISP A resumes contact with end customer,  
> ISP B
> retracts the smaller prefix.
>     Scalability is an obvious issue, as the possible number of these
> 'adjacency blocks' would be N * (N-1), where N is the number of  
> ISPs in
> the world.  Obviously pretty large.  But I feel the number of ISPs  
> that
> people would actually dual home to (due to reputation, regional
> existence, etc) is a few orders of magnitude smaller.  ~100,000  
> prefixes
> (each can be an ASN, I suppose) should cover all needs, doing some
> simple math.
>     The downside is that end customers are going to lose the ability
> to prefer traffic from one ISP versus another for inbound traffic.   
> That
> alone might be a show-stopper, not sure how important it is.  Since  
> IPv6
> is a whole new ballgame, maybe it's ok to change the rules...
>     Looking for any thoughts about it.  I'm sure there's things I
> haven't considered, but the people I've bounced it off of haven't seen
> any obvious problems.  Flame-retardant clothes on, just in case  
> though.
>
>
> Chuck
>
>
>
>
>
>
>> Every multi-homer will be needing their own ASN, so that's what
>>
>>
>>
>>
>>
> clutters
>
>
>
>
>
>> up your routing tables. It's economy there. Btw, a lot of ASNs
>>
>>
>>
>>
>>
> advertise
>
>
>
>
>
>> one network only. People surely think multihoming is important to  
>> them
>> (and I cannot blame them for that).
>>
>>
>>
>>
>>
>
>
>
>
>
>
>> Hierarchical routing is one possible solution, with a lot of  
>> drawbacks
>> and problems. Forget about geographic hierarchies; there's always
>>
>>
>>
>>
>>
> people
>
>
>
>
>
>> who do not peer. Visibility radius limitation is another (I cannot
>>
>>
>>
>>
>>
> believe
>
>
>
>
>
>> the idea is new, I only don't know what it's called).
>>
>>
>>
>>
>
>
>
>
>







More information about the NANOG mailing list