RE: And Now for Something Completely Different (was Re: IPv6 news)
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).
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).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Fred! On Tue, 18 Oct 2005, Fred Baker wrote:
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,
That assumes they can agree on how to get traffic to/from the world and the local IX. One of our local ISPs goes the cheap way and uses an overloaded (and therefore cost effective) link to a cheap tier 2. Another pays a premium price to have a lightly loaded link for it's customers. They will never agree on their business model, not should they have to. By forcing local ISPs to use the same routing prefix you force them to share the same routing strategy to the outside world. For semi-isolated communities this is a big issue. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDVV4g8KZibdeR3qURAuhjAKCuvsd/ZmXebyyTNkfdQ3tBbQvdmACg1OnL RE0lRoxSElVzNaZFpdYcObA= =b5O1 -----END PGP SIGNATURE-----
participants (3)
-
Church, Chuck -
Fred Baker -
Gary E. Miller