North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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; header.Fromemail@example.com; 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; firstname.lastname@example.org; z=Subject:Re=3A=20And=20Now=20for=20Something=20Completely=20Different=20(was=20Re=3A=20IPv6=20news)|From:Fred=20Baker=20<email@example.com>|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
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:
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
same block. The two ISPs will only announce the large block. Of
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
communities?) where ISP B will announce the customer's actual block
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,
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
the world. Obviously pretty large. But I feel the number of ISPs
people would actually dual home to (due to reputation, regional
existence, etc) is a few orders of magnitude smaller. ~100,000
(each can be an ASN, I suppose) should cover all needs, doing some
The downside is that end customers are going to lose the ability
to prefer traffic from one ISP versus another for inbound traffic.
alone might be a show-stopper, not sure how important it is. Since
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
Every multi-homer will be needing their own ASN, so that's what
up your routing tables. It's economy there. Btw, a lot of ASNs
one network only. People surely think multihoming is important to
(and I cannot blame them for that).
Hierarchical routing is one possible solution, with a lot of
and problems. Forget about geographic hierarchies; there's always
who do not peer. Visibility radius limitation is another (I cannot
the idea is new, I only don't know what it's called).