North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Fred Baker
  • Date: Tue Oct 18 16:35:07 2005
  • Authentication-results: imail.cisco.com; [email protected]; dkim=pass (message from cisco.com verified; );
  • Dkim-signature: a=rsa-sha1; q=dns; l=4456; t=1129668068; x=1130100268;c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;d=cisco.com; [email protected]; z=Subject:Re=3A=20And=20Now=20for=20Something=20Completely=20Different=20(was=20Re=3A=20IPv6=20news)|From:Fred=20Baker=20<[email protected]>|Date:Tue,=2018=20Oct=202005=2012=3A44=3A57=20-0700|Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed|Content-Transfer-Encoding:7bit;b=fr1nLyw2pp8I9lE57Sttem4A6ubOjIaoTgUhKv6uQ3ZO7UMTcbB2XPqgJ7nV8JLEz9CQThVZsd4hj6tonBRXHpZr6SxYCl5ENleOEHB5mnn7OH9wBEAFrXaaW9WiY82uCrg+m0ql5QYm5DGpv5X9H6XvFskpEJlwJUsmMvz3KTE=

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).