Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On 12-sep-2005, at 4:55, Matthew Petach wrote:
And no, multiple IP addresses is not good enough.
What requirements do you have that are fundamentally incompatible with using multiple addresses?
How would a default-free content provider with 1000+ peering sessions be handled? Would they be treated as an ISP, even though they have no downstreams, and get PI space?
There are a few corner cases that fall through the cracks in today's policies. A content network like you describe would be one, a transit ISP with customers that all have their own addresses would be another: where would they get the IPv6 addresses to number their routers? However, the number of such networks is so incredibly small that whatever happens to them is completely insignificant with regard to scalability. Still, we need a decent policy for these cases, and JUST these cases but not random people who'd also like a /32.
Or would you expect them to get prefixes from every peer they have, and configure several hundred IP addresses on each server?
Getting address space from a peer doesn't make much sense. But 99.999% of all content networks have 1 or more ISPs that they can get address space from and then announce to any peers.
I'll be blunt. As long as that question is up in the air, none of the major content providers are going to do anything serious in the IPv6 arena.
Well, I have no evidence of them doing anything with IPv6 anyway, so I don't know if this makes a difference. The whole point of IPv6 is that we have a technology that will allow our networks to grow for decades to come. Importing IPv4 mistakes defeats the purpose.
ACLs are already enough of a hassle with one IP address per host.
Ok, let's see... which is more important to keep the internet running, a routing table that fits in our routers, or acl monkeys that get to go home at 5?
On Sep 12, 2005, at 6:58 AM, Iljitsch van Beijnum wrote:
I'll be blunt. As long as that question is up in the air, none of the major content providers are going to do anything serious in the IPv6 arena.
Well, I have no evidence of them doing anything with IPv6 anyway, so I don't know if this makes a difference.
I have a very strong feeling that part of the lack of content providers on IPv6 is due to the lack of multihoming. Whilst this thread is open... perhaps someone can explain to me how shim6 is as good as multihoming in the case of redundancy when one of the links is down at the time of the initial request, so before any shim-layer negotiation happens. I must be missing something, but there's a good chance that the requester is going to have to wait for a timeout on their SYN packets before failing over to another address to try. Or is the requester supposed to send SYNs to all addresses for a hostname and race them off?
:: > Well, I have no evidence of them doing anything with IPv6 anyway, so I :: > don't know if this makes a difference. :: :: I have a very strong feeling that part of the lack of content providers on :: IPv6 is due to the lack of multihoming. :: :: Whilst this thread is open... perhaps someone can explain to me how shim6 is :: as good as multihoming in the case of redundancy when one of the links is :: down at the time of the initial request, so before any shim-layer negotiation :: happens. :: :: I must be missing something, but there's a good chance that the requester is :: going to have to wait for a timeout on their SYN packets before failing over :: to another address to try. Or is the requester supposed to send SYNs to all :: addresses for a hostname and race them off? Or, on top of that, how traffic engineering can be performed with shim6.. And people wonder why more "content" isn't available for v6. Maybe when content providers start asking for a /32 *per datacenter* (ie a /26 or so of initial allocation) those issues might get solved... then again, probably not. -igor (firmly in the shim6 does not adress *most* of the issues camp)
Or, on top of that, how traffic engineering can be performed with shim6..
-igor (firmly in the shim6 does not adress *most* of the issues camp)
Shim6 doesn't do what most end user sites would like to think of as traffic engineering. For a multihomed site, traffic engineering is about inbound or outbound traffic loading. Affecting inbound traffic distribution means that there needs to be a site-specific locus of control that is capable of causing all of the hosts within the domain to alter the destination address that their correspondents are using. This was seen as extremely complicated. Similarly, outbound traffic engineering would require a locus of control that has knowledge of the site's external routing tables and can affect the destination addresses used by the site's hosts. This also seems extremely complicated. Then, there is the inherent conflict: what happens when the remote traffic engineering conflicts with the local traffic engineering? All in all, site traffic engineering is NOT going to be an easy problem to solve in a hop-by-hop forwarding paradigm based on clever manipulation of L3 locators. Architecturally, what one would really like is to not worry about the traffic engineering problem per-se. Rather, what is needed is a mechanism that allows congestion control and mechanisms to feed into the address selection algorithms, so that when a link does become saturated, some traffic (but not all! ;-), shifts to alternate addresses. Tony [Firmly in the camp that not all issues have simple, pragmatic solutions -- and thus not all issues should be solved.]
:: All in all, site traffic engineering is NOT going to be an easy problem :: to solve in a hop-by-hop forwarding paradigm based on clever :: manipulation of L3 locators. Architecturally, what one would really :: like is to not worry about the traffic engineering problem per-se. :: Rather, what is needed is a mechanism that allows congestion control and :: mechanisms to feed into the address selection algorithms, so that when a :: link does become saturated, some traffic (but not all! ;-), shifts to :: alternate addresses. Traffic engineering is not *only* about congestion, in fact, for a large content provider, it's about *policy*. Content providers like the fact that by manipulating the routing policy we can chose to send X amount of traffic to B via peering link Y (provided that prefix is announced by both peers Y and Z). We also like that fact that we can change our announcements so others can only use prefix X through transit provider Y and not transit provider Z, unless transit provider Y goes away (those 2 are obviously not the only uses of such policies, but are just examples). For us (and i'm sure not only us) it's about control, and that control is required for financial, political (and when the 2 intersect), as well as performance engineering reasons, things that are easily done in v4 right now, and can not be done simply in v6 (please correct me if I'm wrong here), unless every datacenter all of a sudden gets a /32 (and if the folks in ARIN have no problems giving a large content provider a /26 (of v6 space) in order to encourage it's adoption, because the current multihoming strategies simply do not work, please do drop me a line) Moving everything to the end-hosts is simply not a good idea imho. -igor
Igor Gashinsky wrote: [snip]
Moving everything to the end-hosts is simply not a good idea imho.
But isn't that what IP is supposed to be about? Smart endpoints, dumb network (a.k.a. the stupid network)? -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
On 13-Sep-2005, at 03:28, Crist Clark wrote:
Igor Gashinsky wrote: [snip]
Moving everything to the end-hosts is simply not a good idea imho.
But isn't that what IP is supposed to be about? Smart endpoints, dumb network (a.k.a. the stupid network)?
And with many peer-to-peer applications, isn't the traffic engineering already effectively performed at the edge? Joe
On Tue, 13 Sep 2005 14:45:31 +0300, Joe Abley said:
And with many peer-to-peer applications, isn't the traffic engineering already effectively performed at the edge?
"already performed ineffectively at the edge" is probably a better description of the true state of affairs. Remember that usually these things bias their behavior in favor of the person running the program, not for the benefit of the ISP who's moving the packets....
On Sep 12, 2005, at 7:43 PM, Tony Li wrote:
Rather, what is needed is a mechanism that allows congestion control and mechanisms to feed into the address selection algorithms, so that when a link does become saturated, some traffic (but not all! ;-), shifts to alternate addresses.
Not disagreeing, but where is that implementation or RFC or draft or discussion? We have something that works in v4 that a lot of places rely on... and that is being taken away in v6 with nothing (that has been mentioned) to replace it. I'm just tired of people whining about the lack of v6 take up when the tools needed for many sites. And yes, I'm fully aware that I (and others) should have been active in multi6... however, it never occurred to me that multihomed sites would be left completely out in the cold with only a token gesture.
On 13-sep-2005, at 0:22, Igor Gashinsky wrote:
:: I must be missing something, but there's a good chance that the requester is :: going to have to wait for a timeout on their SYN packets before failing over :: to another address to try. Or is the requester supposed to send SYNs to all :: addresses for a hostname and race them off?
This aspect isn't nailed down yet, but basically there are two options: depend on the application do try all addresses (which apps should do anyway, but I for one wouldn't want to wait for all these timeouts), or have the shim detect that the first address doesn't work and repair the failure. This adds additional complexity, though, and there is still a timeout, although it isn't a full TCP SYN timeout.
Or, on top of that, how traffic engineering can be performed with shim6..
For outgoing traffic there is no difference with the current situation (as long as there are nog ingress filtering issues). For incoming traffic, it basically starts with DNS load balancing, and the shim itself will have priority mechanisms to choose between different address pairs but this will generally not come into play because the idea is that the shim doesn't do anything unless there is an outage.
And people wonder why more "content" isn't available for v6. Maybe when content providers start asking for a /32 *per datacenter* (ie a /26 or so of initial allocation) those issues might get solved... then again, probably not.
So how is that going to help? The whole idea behind shim6 is that we can't give people all the independent address blocks that they may possibly ask for.
(firmly in the shim6 does not adress *most* of the issues camp)
So where were you the past years in multi6 and months in shim6? Please be part of the solution and not part of the problem. (That goes for John Payne and Daniel Senie too.) I'll be happy to continue any and all discussions of multihoming in IPv6 off-list, but having them on the NANOG list doesn't seem to be very productive.
At 03:19 PM 9/13/2005, you wrote:
So where were you the past years in multi6 and months in shim6? Please be part of the solution and not part of the problem. (That goes for John Payne and Daniel Senie too.)
I was there in the beginning for Multi6. When I saw the direction(s) that were being considered, I decided the whole concept was a non-starter and spent my budget of IETF hours on other areas that had a chance of being useful. Just how many IETF groups do you participate in? In how many different IETF areas? Do you also get other work done? Most folks (perhaps including you) have limited amounts of time to spend on IETF work. Some folks get paid to do such work by their employers, while others don't. At what point does it make sense as a participant in a working group to look at the direction and sense of the room and decide that no amount of arguing is going to keep a trainwreck from occurring? Rereading the paragraph I responded to, however, I'm starting to wonder how close it, and possibly also my response, are to ad hominum territory. I'm not sure I should be having to defend my choices in where to spend or not spend my time on IETF activities.
On 13-sep-2005, at 21:58, Daniel Senie wrote:
So where were you the past years in multi6 and months in shim6? Please be part of the solution and not part of the problem. (That goes for John Payne and Daniel Senie too.)
I was there in the beginning for Multi6. When I saw the direction (s) that were being considered, I decided the whole concept was a non-starter and spent my budget of IETF hours on other areas that had a chance of being useful.
Which is of course your good right. However, in your message earlier today you were spreading FUD about the IPv6 address length, a ship that sailed a decade ago. In my book, that's being part of the problem. Especially since a subset of the NANOG membership may not be familiar enough with the issues to be able to see through all of this.
Just how many IETF groups do you participate in?
There is one that I always make time for, about four others depending on time constraints.
In how many different IETF areas?
Never counted.
Do you also get other work done?
Look up my name on Amazon...
Most folks (perhaps including you) have limited amounts of time to spend on IETF work. Some folks get paid to do such work by their employers, while others don't.
Well, I don't have an "employer" so that doesn't apply in my case. :-)
At what point does it make sense as a participant in a working group to look at the direction and sense of the room and decide that no amount of arguing is going to keep a trainwreck from occurring?
At some point after the requirements discussion, I'd say. I'm not saying everyone and their dog should co-design the protocol, but I think it's reasonable to ask people to take 15 minutes to write down their requirements in a message to the list at that point, rather than whine later. Something similar is happening with the RIR policies. People "just want PI" but they don't want to come up with a policy that makes it possible to give people who really need PI or a PA block one, while at the same time making sure the routing tables aren't going to explode in the future. I don't know why I bother, but let me tell all of you that the size of the v4 table TODAY is a problem. A customer of mine wanted to load balance over two BGP sessions to the same AS, but his linecards crashed because this required two copies of every route in the FIB, which didn't fit in the linecard's memory. These were fairly reasonable Cisco 12000 linecards with 512 MB RAM. Now in v4 the minimum prefix you'll see is a /24. Since a lot of address space is already used in larger blocks, and you need to show decent utilization, there are natural limits to the numbers of /24s in the routing table. However, in v6 these limits don't apply, so ANYONE can get a /48 (I have 3 currently). If you accept those in your routing table that table is going to explode at some point. So just ignoring the issue is not an option. Still, many people just want their own portable block, and don't even want to bother THINKING about the issue.
On Sep 13, 2005, at 3:19 PM, Iljitsch van Beijnum wrote:
On 13-sep-2005, at 0:22, Igor Gashinsky wrote:
:: I must be missing something, but there's a good chance that the requester is :: going to have to wait for a timeout on their SYN packets before failing over :: to another address to try. Or is the requester supposed to send SYNs to all :: addresses for a hostname and race them off?
This aspect isn't nailed down yet, but basically there are two options: depend on the application do try all addresses (which apps should do anyway, but I for one wouldn't want to wait for all these timeouts), or have the shim detect that the first address doesn't work and repair the failure. This adds additional complexity, though, and there is still a timeout, although it isn't a full TCP SYN timeout.
So, move to IPv6 and watch your initial connect times according to keynote et al. increase?
Or, on top of that, how traffic engineering can be performed with shim6..
For outgoing traffic there is no difference with the current situation (as long as there are nog ingress filtering issues). For incoming traffic, it basically starts with DNS load balancing, and the shim itself will have priority mechanisms to choose between different address pairs but this will generally not come into play because the idea is that the shim doesn't do anything unless there is an outage.
Mmmm, DNS load balancing. As a shareholder in my current employer, I am happy to see that market increase. As a network engineer, I keep getting the feeling I'm missing out on some great drugs.
So where were you the past years in multi6 and months in shim6? Please be part of the solution and not part of the problem. (That goes for John Payne and Daniel Senie too.)
I was in denial that multihoming would get this broken. I've joined the mailing list... I'll note that the mailing list archive is not linked anywhere useful, so to save others the guesswork: <http://psg.com/lists/shim6/>
On Tue, 13 Sep 2005, Iljitsch van Beijnum wrote:
On 13-sep-2005, at 0:22, Igor Gashinsky wrote:
(firmly in the shim6 does not adress *most* of the issues camp)
So where were you the past years in multi6 and months in shim6? Please be part of the solution and not part of the problem. (That goes for John Payne and Daniel Senie too.)
pleas don't slam Igor, daniel nor John... I'm of the opinion (possibly wrong and these three can correct me if so) that they thought this would get sorted out because people knew multihoming is important to business... (which I was too until his last IETF :( ) So, my post 1 month ago about this and the followup on this topic were tries to get operators involved in the problem/process. that's happened with atleast john/Patrick/igor and that's a GOOD THING, yes?
I'll be happy to continue any and all discussions of multihoming in IPv6 off-list, but having them on the NANOG list doesn't seem to be very productive.
it is because it's highlighting the problem of lack of support... and need for NANOG-ish operators to GET INVOLVED before they get stuck with something that will not work for them. -Chris
On Mon, 12 Sep 2005 17:41:51 -0400 John Payne <john@sackheads.org> wrote:
On Sep 12, 2005, at 6:58 AM, Iljitsch van Beijnum wrote:
I'll be blunt. As long as that question is up in the air, none of the major content providers are going to do anything serious in the IPv6 arena.
Well, I have no evidence of them doing anything with IPv6 anyway, so I don't know if this makes a difference.
I have a very strong feeling that part of the lack of content providers on IPv6 is due to the lack of multihoming.
No, I would say it is due to the lack of an audience that can _only_ be reached (or even _best_ be reached) using IPv6. Once the audience is there, the content providers will follow. Regards Marshall
Whilst this thread is open... perhaps someone can explain to me how shim6 is as good as multihoming in the case of redundancy when one of the links is down at the time of the initial request, so before any shim-layer negotiation happens.
I must be missing something, but there's a good chance that the requester is going to have to wait for a timeout on their SYN packets before failing over to another address to try. Or is the requester supposed to send SYNs to all addresses for a hostname and race them off?
Marshall Eubanks wrote:
On Mon, 12 Sep 2005 17:41:51 -0400 John Payne <john@sackheads.org> wrote:
On Sep 12, 2005, at 6:58 AM, Iljitsch van Beijnum wrote:
I'll be blunt. As long as that question is up in the air, none of the major content providers are going to do anything serious in the IPv6 arena.
Well, I have no evidence of them doing anything with IPv6 anyway, so I don't know if this makes a difference.
I have a very strong feeling that part of the lack of content providers on IPv6 is due to the lack of multihoming.
No, I would say it is due to the lack of an audience that can _only_ be reached (or even _best_ be reached) using IPv6.
Once the audience is there, the content providers will follow.
Same issue really. Audience isn't going to mature until those issues are sorted.
On Tue, 13 Sep 2005, Christian Kuhtz wrote:
Marshall Eubanks wrote:
On Mon, 12 Sep 2005 17:41:51 -0400 John Payne <john@sackheads.org> wrote:
On Sep 12, 2005, at 6:58 AM, Iljitsch van Beijnum wrote:
I'll be blunt. As long as that question is up in the air, none of the major content providers are going to do anything serious in the IPv6 arena. Well, I have no evidence of them doing anything with IPv6 anyway, so I don't know if this makes a difference. I have a very strong feeling that part of the lack of content providers on IPv6 is due to the lack of multihoming.
No, I would say it is due to the lack of an audience that can _only_ be reached (or even _best_ be reached) using IPv6.
Once the audience is there, the content providers will follow.
Same issue really. Audience isn't going to mature until those issues are sorted.
so.... 'chicken and egg' problem, which was why a month ago I said: "why don't some content providers put up some form of their content on a sidelined v6 path?" Perhaps a 'testing' path or a 'not wholey production' path? Some of the answers were enligtening (to me atleast)... anyway, this has been some good discussion, and 2 more people are now on shim6 :)
anyway, this has been some good discussion, and 2 more people are now on shim6 :)
I've always wondered why NANOGers refer to Internet resources in this way. Do NANOG members not know what a URL is? Perhaps it is because the WWW was invented long after the Internet was and, as you know, there is no technology like good old technology... *sigh* In any case the charter here is not very clear http://www.ietf.org/html.charters/shim6-charter.html There actually is a list archive that can be read by going here: http://psg.com/lists/shim6/threads.html As far as I can tell, the closest thing to an overview of SHIM6 is here: http://tools.ietf.org/wg/shim6/draft-ietf-shim6-arch/draft-ietf-shim6-arch-0... and it is likely an outgrowth of this multi6 document: http://www.potaroo.net/drafts/draft-ietf-multi6-architecture-04.html If you like slideware, Geoff Huston presented something on SHIM6 in August: http://www3.ietf.org/proceedings/05aug/slides/shim6-2.pdf This is probably the place to go for a high level overview. These minutes from the IETF 63 WG meeting are another good way to start reading about SHIM6 with more on the personalities but less verbiage than the list archive http://tools.ietf.org/wg/shim6/minutes.pyht?item=minutes63.html Have fun! --Michael Dillon
Whilst this thread is open... perhaps someone can explain to me how shim6 is as good as multihoming in the case of redundancy when one of the links is down at the time of the initial request, so before any shim-layer negotiation happens.
I must be missing something, but there's a good chance that the requester is going to have to wait for a timeout on their SYN packets before failing over to another address to try. Or is the requester supposed to send SYNs to all addresses for a hostname and race them off?
There are a variety of possible implementations. A full timeout and serial retries are one extreme. Trying all addresses in parallel is another. Anything in between is not out of the bounds of possibility. IMHO, the thing to do is to send out the first SYN and wait 1 RTT, not a full timeout. Then, try two addresses. After the next RTT, try four addresses... It's just binary exponential backoff of another flavor. ;-) My $.02, Tony
participants (12)
-
Christian Kuhtz -
Christopher L. Morrow -
Crist Clark -
Daniel Senie -
Igor Gashinsky -
Iljitsch van Beijnum -
Joe Abley -
John Payne -
Marshall Eubanks -
Michael.Dillon＠btradianz.com -
Tony Li -
Valdis.Kletnieks＠vt.edu