Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
Marshall Eubanks wrote: On Mon, 12 Sep 2005 17:41:51 -0400 John Payne [EMAIL PROTECTED] 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.
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Tue, 13 Sep 2005, Christian Kuhtz wrote: Marshall Eubanks wrote: On Mon, 12 Sep 2005 17:41:51 -0400 John Payne [EMAIL PROTECTED] 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 :)
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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 pgpBULKwOkfCk.pgp Description: PGP signature
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
--- Mikael Abrahamsson [EMAIL PROTECTED] wrote: The shimming model is a way to solve this by the endsystems knowing about multihoming, instead of the network. I personally think this is a better idea and scales much better. Let's have the network moving packets as its primary goal, not solving how do I reach this prefix equations. Waitaminute - isn't the whole *purpose* of layer 3 that the network makes these routing decisions? If there are N routers in an ISP, I would expect the ISP to connect to X endsystems, where 10N X 1000N. How does knowing about X endsystems scale better than knowing about N intermediate systems? Am I missing something here? David Barak http://www.listentothefranchise.com __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
At 10:17 AM 9/10/2005, Joe Abley wrote: On 10-Sep-2005, at 09:18, Patrick W. Gilmore wrote: [Perhaps this thread should migrate to Multi6?] multi6 hasn't existed for some time. The level-3 shim approach to multi-homing that was the primary output of multi6 is being discussed in shim6. Suppose they not only have no plan but couldn't really put together a plan to support 200 customers? Does this mean Google, or any other content provider, is unworthy of globally routeable space? Yes, according to the current RIR policies. [So the determination of unworthy above has been made, in effect, by RIR members.] IPv6 is a nice idea, and as soon as people realize that ISPs are not the only organizations who have a need to multi-home - and I mean really multi-home, not stupid work-arounds - then it might actually start to happen. It's not as though this line of thinking hasn't been followed many, many times before. The counter-argument goes like this: 1. There is more v6 space than there is v4 space, by virtue of the fact that the address is 96 bits wider. Could the IPv6 proponents get their stories straight? On the one hand, the talk is of 128 bit address space, then on the other hand the talk is of security-by-obscurity by handing out /48's to everyone and having networks really sparsely populated. So given the address space is so massive that 1/2 of the bits are effectively a local subaddress, perhaps the talk should be of doubling the number of bits, not quadrupling. Yes, I understand you can slice and dice however desired, but it sure seems like the proponents play fast and loose with the numbers when making their arguments, and it's tiresome. 2. Because there is vastly more v6 space than v4 space, if entitlement to PI space in v6 was opened up the chances are many more people would have v6 PI space than currently have v4 PI space. The rules today have not resulted in and overly huge number of multihomers. The IPv6 crowd evangelists on the one hand insist there's no need for NAT, while on the other hand provided no solution to multihoming, and what's been evolving in the various fixes for that are less palatable than running a multiport NAT box. The choice is simple: live with NAT or provide portable address space. The marketplace is not likely, IMO, to accept shim6. End systems should not be making decisions on where packets go beyond the local network segment. This has been tried before. It was called Token Ring Source Route Bridging. It was a bad idea then, and it's a bad idea now to have end stations deal with routing. SRB came into being to save the network elements from the burden of keeping track of the functioning of the network. Then Ethernet switches came along, spanning tree, and so forth. 3. Every PI assignment/allocation takes up a routing slot in every router in the DFZ. That's true today. Router memory complement has increased over time. So what? Cost of processing power and memory are a tiny fraction of what they were when the routing table was in the 20,000 prefix range. 4. Given 2 and 3, there is potential for the amount of state in the DFZ to exceed the capabilities of the network to hold and process it (e.g. enormous RIBs, soaring processor requirements for dealing with updates, etc). Processors in current routers are well below the fastest on the market. There's plenty of horsepower headroom. There's plenty of opportunity to expand the amount of memory. It's possible that the number of PI assignments might not be that high, and the scaling properties in practice might not be so bad. However, you only get to find this out after you've opened the floodgates, and if it turns out that it doesn't scale, it's hard to push the water back into the reservoir. What floodgates? Are we flooded today? The rules today for getting portable space are NOT all that difficult to meet. The goal in shim6 is to find a mechanism which provides all the functional benefits of multi-homing without holding all the state in DFZ routers. That multihoming was not properly addressed as a core goal to solve in IPv6 is one of the failings in the whole effort. The shim6 approach is, IMO, not going to fly. A multiported NAT box for $179 or less (present product in the marketplace) provides a simple solution without the end stations being involved. Sure, it uses NAT. There seems to be some ongoing perception that various protocol/ research organisations have no idea about the value of multi-homing for enterprises in the real network, and hence ignore it. While that might have once been the case (I certainly remember thinking so around 1997 whilst shouting on the ipng list), I don't believe it's the case today. Sadly, because folks wouldn't listen then, IPv6 lacks a useful multihoming solution beyond what we have in IPv4. Gluing on band-aids is not going to solve it. Relying on Moore's Law to continue to make routing equipment keep up is
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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.
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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.
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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/
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
Waitaminute - isn't the whole *purpose* of layer 3 that the network makes these routing decisions? If there are N routers in an ISP, I would expect the ISP to connect to X endsystems, where 10N X 1000N. How does knowing about X endsystems scale better than knowing about N intermediate systems? Am I missing something here? I think there's some misunderstanding. Nothing has to know about X endsystems. Nor did anything have to know about N routers before. In the shim6 approach, a host only needs to know about its correspondent hosts. From a scalability perspective, this is unchanged from previously, only the constants are bigger. Tony
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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.
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
The rules today have not resulted in and overly huge number of multihomers. I suspect that is a matter of perspective. Even if 10% of all sites are multihomed, and we continue in the IPv4 multihoming model, then we will end up with slow exponential growth of the routing table which eventually overtakes and buries us. The IPv6 crowd evangelists on the one hand insist there's no need for NAT, while on the other hand provided no solution to multihoming, and what's been evolving in the various fixes for that are less palatable than running a multiport NAT box. The choice is simple: live with NAT or provide portable address space. The marketplace is not likely, IMO, to accept shim6. Why not? I should point out that another perspective on shim6 that should be more to your liking: in actuallity, shim6 is just another incarnation of NAT. It turns each host into a NAT that sits just underneath the transport layer. This seems like a fine compromise to running a multiport NAT or (worse) a distributed multiport NAT. End systems should not be making decisions on where packets go beyond the local network segment. This has been tried before. It was called Token Ring Source Route Bridging. It was a bad idea then, and it's a bad idea now to have end stations deal with routing. SRB came into being to save the network elements from the burden of keeping track of the functioning of the network. Then Ethernet switches came along, spanning tree, and so forth. That would fly in the face of other requests already made here. I tend to agree that routing should stay in the routing subsystem and that those asking for routing features would be most likely to get them if they asked routing to provide the functionality. That's true today. Router memory complement has increased over time. So what? Cost of processing power and memory are a tiny fraction of what they were when the routing table was in the 20,000 prefix range. Flatly not true. Paid for a line card lately? Processors in current routers are well below the fastest on the market. There's plenty of horsepower headroom. There's plenty of opportunity to expand the amount of memory. Processors are not just for protocol processing. There are also impacts on the costs of forwarding, as each prefix ends up in the high speed static RAM associated with your forwarding engine. Such silicon is not cheap, and while we are currently ahead of the problem, we can easily let the problem grow without bound and leave ourselves in a very bad spot. Scaling the routing subsystem is in everyone's best interest. That multihoming was not properly addressed as a core goal to solve in IPv6 is one of the failings in the whole effort. No doubt. However, the fact of the matter is that we are where we are. The shim6 approach is, IMO, not going to fly. A multiported NAT box for $179 or less (present product in the marketplace) provides a simple solution without the end stations being involved. Sure, it uses NAT. If, in fact, this is the choice of the market, then the issue is solved and PI space is unnecessary. A fine outcome in my book. Relying on Moore's Law to continue to make routing equipment keep up is going to be a necessity. Moore's Law has not, and does not apply to routers. Thus, costs are going up non-trivially. Tony
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
on Sat Sep 10 03:39:59 2005 Christopher L. Morrow writes On Sat, 10 Sep 2005, Patrick W. Gilmore wrote: [Perhaps this thread should migrate to Multi6?] perhaps... then jason can argue this instead of me :) The most basic question is if there will be a problem if we solve the multihoming question in the traditional IPv4 way? And if so, should we solve the problem by throwing hardware at it and hoping that when it becomes a problem the hardware will be sufficiently advanced to be able to solve it? We can solve the multihoming question in the traditional IPv4 way, de-aggregation. We can argue if that means give end sites a /32, or allow provider independent /48s, but the fact of the matter is a prefix whatever size creates routing state. The sheer size of the IPv6 space allows for lots of routing state. On the other side, if you remove the routing state then you have a trade off where the information you previously attained through routing state must now be detected in the forwarding plane. We are seeing this now with respect to how end systems detect an outage. draft-ietf-shim6-reach-detect-00.txt The problem as I see it is that the IETF community is focused on the protocol design, how end hosts signal shim6 capabilities, and failure detection. They are not focused on operational requirements such as 1. The ability to inter-AS traffic engineering polices 2. To be able to configure and manage inter-AS traffic engineering polices at the network level and not on each individual host 3. The need for transit ASes to leverage traffic engineering. This is evident by the fact that the language in RFC-3582 that attempted to document traffic engineering requirements was down graded to .goals. in order to get adopted. The problem as I see it, is that there are only a few providers making this claim that these requirements are indeed requirements and need to be solved before there will be wide spread adoption of IPv6. Most people involved in IETF either don.t care about multihoming, feel that simple fail-over will solve the problem for 90% of the Internet, or only are concerned with things that affect the protocol, and they believe multihoming isn.t one of them. The process to define how these things work will be done in the IETF, in the shim6 working group... if this might be important to you, perhaps you will want to join the discussion and make your rerquirements/views/issues well known now, before the protocol is specified. ___Jason
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On 11-sep-2005, at 20:59, Brandon Butterworth wrote: So how do you know it's 4 million and not 4.1? Could be 4.1 or even 4.2. And therein lies the problem. I'm assuming those working on 4byte ASs know, if it's more we'll have to migrate again which would be silly so soon I don't think the people working on 32-bit AS numbers are privvy to information that the rest of us isn't. But in any event, 32-bit AS numbers allow for 4 billion ASes, not 4 million. We know that 125k works today That's quite a bit less than current SUP720-3BXL I haven't seen the specs for that one, so I don't know if it can hold 500k _prefixes_ or 500k _paths_. Big difference. Also, not everyone is going to buy new hardware immediately. so the storage requirements should sort themselves out according to Moore in 7 x 1.5 years, so that would work in 2013. Processing scales non-linearly, though. If we need it then it will exist, if not then we won't be able to do that and will do something else instead That's not good engineering. It's a very bad idea to start a course of action without knowing whether you can finish it. Although we don't have as much time as we used to have, we still have SOME time to come up with new stuff that will make multihoming in IPv6 scale.
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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?
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
:: 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)
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
So how do you know it's 4 million and not 4.1? Could be 4.1 or even 4.2. And therein lies the problem. My point, we don't know so some arbitrary or technology limits will have to do as there isn't financial reason to make something bigger in any event, 32-bit AS numbers allow for 4 billion ASes, not 4 million. Of course. So we know it's somewhere between 4G and current 20K. If the current policies apply then ASs may not increase greatly but prefixes will be lots less. Sounds like no problem for multi homing as we do now if nothing more acceptable is agreed. Otherwise people will just ignore V6 until it's too late V6 could have saved lots of upgrades for those about to hit the ~250K V4 limit of existing Ciscos If we need it then it will exist, if not then we won't be able to do that and will do something else instead That's not good engineering. It's what people do though, good engineering is pointless if it doesn't get used we still have SOME time to come up with new stuff that will make multihoming in IPv6 scale. As long as it doesn't involve pushing the problem onto the hosts, C J don't always get it right, I'd hate to see 1M times more machines relying on M or L. brandon
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Mon, 12 Sep 2005 17:41:51 -0400 John Payne [EMAIL PROTECTED] 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?
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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.]
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
:: 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
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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 [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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.
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
:: 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). :: :: :: This also seems like it achievable via DNS hacks on your side. Again, :: this seems like it can be done locally. Wonderful.. so now we have to do routing in DNS, a protocol that's not exactly designed for rapid convergence (yes, neither is BGP, but it's a *lot* faster then DNS). Just brilliant. :: While I realize that the status quo is always the most comfortable, you :: should also recognize that the status quo is simply not sustainable from :: an architectural viewpoint. Thus, the charter of multi6/shim6 is to :: change the model into one that is sustainable, and the fact that certain :: features and functionality will be lost is an unfortunate necessity. While the status quo is not sustainable if growth continues for 4+ years, deciding to fix the problem by pretending that there was never a good reason for it in the first place, and moving it to a different place is not a very good architectural solution either. :: Well, I cannot disagree with you. However, this is the direction that :: the IETF has chosen after careful and lengthy discussions. Those of us :: who had alternative ideas have long since lost the battle and are :: resigned to the inevitable, of which shim6 seems like the best of a bad :: lot. And I hope this thread points out why more content isn't v6 enabled.. And no, I'm not saying that the evil greedy bastards did this on purpose, unfortunately, it's simply yet another example of things being created without operator involvement (and yes, we, the operators, are at fault for that). See you on [EMAIL PROTECTED] -igor
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sun, 11 Sep 2005, Mikael Abrahamsson wrote: On Sat, 10 Sep 2005, Patrick W. Gilmore wrote: Content providers and other large business, without who's funds the Internet would fail, have a right not to be tied to a single provider. And while I The shimming model is a way to solve this by the endsystems knowing about multihoming, instead of the network. I personally think this is a better idea and scales much better. Let's have the network moving packets cause each end node knows about the upstream network 'problems' so well? giving them full routes too are we? ( I don't want to fight this arguement here, I'm just making a rhetorical question, one I hope there will be a presentation this nanog to also argue over :) )
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sun, Sep 11, 2005 at 06:32:58AM +0200, Mikael Abrahamsson wrote: Giving each entity who wants to multihome an AS of their own and own address block, doesn't scale. Think this in the way of each home in the world being multihomed, it just doesn't scale. IPv6 solved the addressing problem, not the routing problem, in the current model. Let's try to fix the routing problem NOW instead of 5-10 years down the road. To quote some stats from the latest weekly routing table report to hit nanog: BGP routing table entries examined: 169983 Total ASes present in the Internet Routing Table: 20445 Origin-only ASes present in the Internet Routing Table: 17787 Origin ASes announcing only one prefix:8431 This says that although there are 170k prefixes on the Internet, there are only 20k entities who actually need to announce IP space. There is only one explanation for such a large difference (8.5x) between these two numbers, namely that people who are announcing IP space need multiple blocks in order to accomodate their needs. Yes there are some people who are doing things like announcing discontiguous blocks from the same ASN and relying on the network to get bits to the right spot, but the majority of these prefixes are due to IP rationing, which forces growth into multiple blocks. By eliminating this, the vast majority of users will only need to announce 1 prefix, ever. I don't know about you, but I'd be quite happy to get the number of prefixes down to ~ 20k and growing at the rate of new ASN allocations. :) Obviously nothing we currently have is going to scale to handle millions of users wanting to multihome their cable modem and their DSL at the network level, but at least the current system will keep scaling for quite a while. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On 10-Sep-2005, at 21:42, Patrick W. Gilmore wrote: On Sep 10, 2005, at 10:17 AM, Joe Abley wrote: Yes, according to the current RIR policies. [So the determination of unworthy above has been made, in effect, by RIR members.] And this is why v6 has failed and will continue to fail. It'll only continue to fail (for this reason) as long as the various RIR memberships don't vote for change. [...] 2. Because there is vastly more v6 space than v4 space, if entitlement to PI space in v6 was opened up the chances are many more people would have v6 PI space than currently have v4 PI space. This assumption has more holes in it than swiss cheese. It doesn't need to a foregone conclusion; it just needs to have significantly non-zero probability, since if it turns out to be true then we're all screwed. Right now there are lots of multi-homed organisations who use NAT, and whose PI address space deployed internally comes from RFC1918. If you imagine all those enterprises using a globally-unique, PI v6 block instead, then perhaps the thinking behind the speculation in (2) above becomes clearer. [ObCheese: most of the 450 or so kinds of cheese made in Switzerland don't have holes.] Ignoring the problems with #2, what is made of the idea that each AS might only have a single block, since blocks are so much larger? (And lots of other questions I'm sure you guys have already covered which are probably not on-topic for NANOG.) This is an RIR policy issue, not an IETF protocol issue. If the members of RIRs all pushed for the idea that I have a globally- unique ASN is also appropriate justification for a /32 allocation, then I would imagine that the policy might change. It's possible that the number of PI assignments might not be that high, and the scaling properties in practice might not be so bad. However, you only get to find this out after you've opened the floodgates, and if it turns out that it doesn't scale, it's hard to push the water back into the reservoir. The goal in shim6 is to find a mechanism which provides all the functional benefits of multi-homing without holding all the state in DFZ routers. Perhaps the goal ... was chosen poorly? Perhaps. This will surely become clear with the benefit of hindsight :-) Joe
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On 11-sep-2005, at 8:31, Patrick W.Gilmore wrote: Giving each entity who wants to multihome an AS of their own and own address block, doesn't scale. Think this in the way of each home in the world being multihomed, it just doesn't scale. We disagree. And your hyperbole doesn't come close to proving your argument. Well then, why don't you do the following: 1. Give us a maximum number of multihomers. 2. Tell us how a routing table of that size (assuming 1 route per AS) will scale based on reasonable extrapolations of today's technology.
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
Hi, On Sep 11, 2005, at 12:52 AM, Richard A Steenbergen wrote: This says that although there are 170k prefixes on the Internet, there are only 20k entities who actually need to announce IP space. There is only one explanation for such a large difference (8.5x) between these two numbers, namely that people who are announcing IP space need multiple blocks in order to accomodate their needs. This is an interesting assertion. I thought the majority of announced prefixes was due to folks punching holes in their registry allocated blocks in order to do traffic engineering of one form of another (multi-homing being a form of traffic engineering). Can you point at the data which backs up your assertion (I'm not disputing it, just a curious)? Thanks, -drc
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sep 11, 2005, at 10:26 AM, Iljitsch van Beijnum wrote: On 11-sep-2005, at 8:31, Patrick W.Gilmore wrote: Giving each entity who wants to multihome an AS of their own and own address block, doesn't scale. Think this in the way of each home in the world being multihomed, it just doesn't scale. We disagree. And your hyperbole doesn't come close to proving your argument. Well then, why don't you do the following: 1. Give us a maximum number of multihomers. Unknown. Somewhat less than the number of hosts on the Internet, somewhat more than one. My bet is closer to the latter than the former. In fact, I would think it's the same for v4. Do you disagree? And if so, why? 2. Tell us how a routing table of that size (assuming 1 route per AS) will scale based on reasonable extrapolations of today's technology. Right, 'cause we all know tomorrow's problems need to be solved with today's technology. But let's try it anyway. As per RAS' post, reducing the growth of the table to equal the growth of ASNs would be a huge win. A problem which is, in fact, solvable with today's technology. So, despite your completely silly and unreasonable constraints (kinda like each home in the world being multihomed), the problem is still solvable. Keeping small providers, hosters, enterprises, schools, etc., who do not want to be tied to a single provider from multihoming is a huge loss. I guess you could argue forcing people to single-home is not a bad thing. As one of the people who pay for transit, I tell you it is not. Period. And no, multiple IP addresses is not good enough. -- TTFN, patrick
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sep 11, 2005, at 12:51 PM, David Conrad wrote: On Sep 11, 2005, at 12:52 AM, Richard A Steenbergen wrote: This says that although there are 170k prefixes on the Internet, there are only 20k entities who actually need to announce IP space. There is only one explanation for such a large difference (8.5x) between these two numbers, namely that people who are announcing IP space need multiple blocks in order to accomodate their needs. This is an interesting assertion. I thought the majority of announced prefixes was due to folks punching holes in their registry allocated blocks in order to do traffic engineering of one form of another (multi-homing being a form of traffic engineering). Can you point at the data which backs up your assertion (I'm not disputing it, just a curious)? How about the CIDR report? Notice that even with maximal aggregation per AS, the average AS still announces multiple blocks. It's really not that hard to see if you spend some time perusing the full table. -- TTFN, patrick
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
1. Give us a maximum number of multihomers. 4 Million 2. Tell us how a routing table of that size (assuming 1 route per AS) will scale based on reasonable extrapolations of today's technology. SUP720-3BXL says 1M (500K v6) now, doesn't seem too much of a stretch to 4M over many years brandon
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On 11-sep-2005, at 19:06, Patrick W. Gilmore wrote: 1. Give us a maximum number of multihomers. Unknown. Somewhat less than the number of hosts on the Internet, somewhat more than one. My bet is closer to the latter than the former. Well, if you don't know the number of multihomers you can't be sure that their routes will fit inside a RIB or a FIB. It's that simple. In fact, I would think it's the same for v4. Do you disagree? And if so, why? I believe that in IPv4 today there is a lot of unrealized multihoming potential. Today, multihoming is difficult because you need address space and you have to set up BGP, and people think it's hard to get an AS number. If all of those difficulties were to go away, I think a lot more people would multihome. And of course the internet is becoming a critical resource for more and more organizations, which in itself should lead to more multihoming. 2. Tell us how a routing table of that size (assuming 1 route per AS) will scale based on reasonable extrapolations of today's technology. Right, 'cause we all know tomorrow's problems need to be solved with today's technology. But let's try it anyway. Who is using hyperbole now? You're perfectly welcome to apply Moore's law, but a while ago there was someone who argued that he could install 50k routes in a second in his implementation. That's not what existing J and C gear can do, so I'm assuming there are reasons why their performance isn't better than it is today. So if you say you can handle 1M routes in 2 years and 8M in another 5, no argument from me. But if you make it 20M in 2 years and 500M in another 5, I'll want to see how that's going to happen. As per RAS' post, reducing the growth of the table to equal the growth of ASNs would be a huge win. But a one time one, so it's meaningless. In v6 the AS-to-prefix ratio is already 1.4 so we're already there. A problem which is, in fact, solvable with today's technology. What is a problem that is in fact solvable with today's technology? So, despite your completely silly and unreasonable constraints (kinda like each home in the world being multihomed), the problem is still solvable. You haven't produced either of the two figures required to show that multihoming scales, so you don't get to reach this conclusion. Keeping small providers, hosters, enterprises, schools, etc., who do not want to be tied to a single provider from multihoming is a huge loss. I agree. And no, multiple IP addresses is not good enough. What requirements do you have that are fundamentally incompatible with using multiple addresses?
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On 11-sep-2005, at 20:34, Brandon Butterworth wrote: 1. Give us a maximum number of multihomers. 4 Million So how do you know it's 4 million and not 4.1? 2. Tell us how a routing table of that size (assuming 1 route per AS) will scale based on reasonable extrapolations of today's technology. SUP720-3BXL says 1M (500K v6) now, doesn't seem too much of a stretch to 4M over many years We know that 125k works today (I'm being a bit conservative because in IPv6 the addresses are longer) so the storage requirements should sort themselves out according to Moore in 7 x 1.5 years, so that would work in 2013. Processing scales non-linearly, though.
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
1. Give us a maximum number of multihomers. 4 Million So how do you know it's 4 million and not 4.1? Could be 4.1 or even 4.2. I'm assuming those working on 4byte ASs know, if it's more we'll have to migrate again which would be silly so soon So about 4M it must be. We know that 125k works today That's quite a bit less than current SUP720-3BXL (I'm being a bit conservative because in IPv6 the addresses are longer) so the storage requirements should sort themselves out according to Moore in 7 x 1.5 years, so that would work in 2013. Processing scales non-linearly, though. If we need it then it will exist, if not then we won't be able to do that and will do something else instead just as V4 users are doing when they discover V6 doesn't do what they want (let's not rehash whether what they want is reasonable or sensible) brandon
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sun, 11 Sep 2005, Richard A Steenbergen wrote: On Sun, Sep 11, 2005 at 06:32:58AM +0200, Mikael Abrahamsson wrote: Giving each entity who wants to multihome an AS of their own and own address block, doesn't scale. Think this in the way of each home in the world being multihomed, it just doesn't scale. To quote some stats from the latest weekly routing table report to hit nanog: BGP routing table entries examined: 169983 Total ASes present in the Internet Routing Table: 20445 Origin-only ASes present in the Internet Routing Table: 17787 Origin ASes announcing only one prefix:8431 This says that although there are 170k prefixes on the Internet, there are only 20k entities who actually need to announce IP space. There is only one explanation for such a large difference (8.5x) between these two numbers, namely that people who are announcing IP space need multiple blocks in order to accomodate their needs. Actually, you've missed two crucial lines from the report: Prefixes after maximum aggregation: 97203 Unique aggregates announced to Internet: 82000 That implies that 73k (170k - 97k) worth of announcements are related to traffic engineering tricks, multihoming, poor education or simply 'because'. ( A decade on and there are still books/routers/courses/people which don't grok CIDR ) A further 15k (97k - 82k) worth of announcements seem to be duplicates; multiple paths being naturally seen or intentionally announced. Of the 82k worth of possibly unique prefixes, 8k worth of those are from ASes announcing solely one route. The remaining 74k prefixes are announced by 9k ASes; 8 each. the majority of these prefixes are due to IP rationing, which forces growth into multiple blocks. An interesting question to ask, before you point at IP rationing being the main cause, is how many entities that have received IP allocations also have ASes? In other words, these ASes having 8+ prefixes each may in some cases be a single ISP announcing the routes of 5 seperate customer entities. A further question to ask would be, considering that issuing IPs is the RIR's business, why haven't the RIRs noticed a tendency for certain entities to keep coming back for more IP space, and thus why haven't the RIRs been putting aside aggregatable IP space for these entities or been notifying their membership on the possible need for a change in addressing policies to avoid such problems ? Certainly, I'll agree that IP rationing (via RIR policies) is responsible for a certain, hopefully small, percentage of non-aggregatable prefixes. But I don't think that IP rationing is responsible for the majority of such prefixes. -- Bruce Campbell Then again, I may be biased ;)
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sun, Sep 11, 2005 at 09:51:47AM -0700, David Conrad wrote: Hi, On Sep 11, 2005, at 12:52 AM, Richard A Steenbergen wrote: This says that although there are 170k prefixes on the Internet, there are only 20k entities who actually need to announce IP space. There is only one explanation for such a large difference (8.5x) between these two numbers, namely that people who are announcing IP space need multiple blocks in order to accomodate their needs. This is an interesting assertion. I thought the majority of announced prefixes was due to folks punching holes in their registry allocated blocks in order to do traffic engineering of one form of another (multi-homing being a form of traffic engineering). Can you point at the data which backs up your assertion (I'm not disputing it, just a curious)? Come on now, the majority of people don't know what traffic engineering is. :) As much as I complain about stupid people announcing their /16s as /24s for no reason, it isn't the majority of prefixes. When was the last time you saw an ordinary average customer with only 1 prefix and perfect usage? Yes you're probably right that the majority of prefixes are probably from folks who don't have direct allocations, but that is because they are smaller customers using provider IP space. They aren't announcing a dozen /23s and /24s because they are doing TE, it just happens to be the way that the IPs were allocated as their usage grew over time. I'm not citing any specific study here, this is just common sense if you've ever been in the ISP business. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sun, 11 Sep 2005, Christopher L. Morrow wrote: cause each end node knows about the upstream network 'problems' so well? giving them full routes too are we? ( I don't want to fight this arguement here, I'm just making a rhetorical question, one I hope there will be a presentation this nanog to also argue over :) ) Considering convergence time right now of our current BGP based system, firing off a beacon packet all ways you know to the other host (if you yourself have multiple or if the other end have multiple, or both) if your packet stream has been interrupted for 2 seconds the current path between the hosts, is probably much quicker anyway. I have no idea if this is in the current shim model, just thinking out loud. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
I don't think is failing ... On the other way around: looking at the adoption perspectives and compared with other technologies, transition stages, and so on, is going much faster than expected ... Regards, Jordi De: Patrick W. Gilmore [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Sat, 10 Sep 2005 14:42:33 -0400 Para: [EMAIL PROTECTED] CC: Patrick W. Gilmore [EMAIL PROTECTED] Asunto: Re: Multi-6 [WAS: OT - Vint Cerf joins Google] On Sep 10, 2005, at 10:17 AM, Joe Abley wrote: [Perhaps this thread should migrate to Multi6?] multi6 hasn't existed for some time. The level-3 shim approach to multi-homing that was the primary output of multi6 is being discussed in shim6. Guess I'm behind. I'll have to subscribe to shim6. Suppose they not only have no plan but couldn't really put together a plan to support 200 customers? Does this mean Google, or any other content provider, is unworthy of globally routeable space? Yes, according to the current RIR policies. [So the determination of unworthy above has been made, in effect, by RIR members.] And this is why v6 has failed and will continue to fail. The Internet is no longer an academic experiment. It is not run by the 'best technology'. It is run by the best business results. Content providers and other large business, without who's funds the Internet would fail, have a right not to be tied to a single provider. And while I admit I am not up-to-date on v6 multi-homing strategies, the ones I have seen are either evil, unworkable or ridiculous, and simply will not fly. 's not as though this line of thinking hasn't been followed many, many times before. The counter-argument goes like this: 1. There is more v6 space than there is v4 space, by virtue of the fact that the address is 96 bits wider. 2. Because there is vastly more v6 space than v4 space, if entitlement to PI space in v6 was opened up the chances are many more people would have v6 PI space than currently have v4 PI space. This assumption has more holes in it than swiss cheese. 3. Every PI assignment/allocation takes up a routing slot in every router in the DFZ. 4. Given 2 and 3, there is potential for the amount of state in the DFZ to exceed the capabilities of the network to hold and process it (e.g. enormous RIBs, soaring processor requirements for dealing with updates, etc). Ignoring the problems with #2, what is made of the idea that each AS might only have a single block, since blocks are so much larger? (And lots of other questions I'm sure you guys have already covered which are probably not on-topic for NANOG.) It's possible that the number of PI assignments might not be that high, and the scaling properties in practice might not be so bad. However, you only get to find this out after you've opened the floodgates, and if it turns out that it doesn't scale, it's hard to push the water back into the reservoir. The goal in shim6 is to find a mechanism which provides all the functional benefits of multi-homing without holding all the state in DFZ routers. Perhaps the goal ... was chosen poorly? There seems to be some ongoing perception that various protocol/ research organisations have no idea about the value of multi-homing for enterprises in the real network, and hence ignore it. While that might have once been the case (I certainly remember thinking so around 1997 whilst shouting on the ipng list), I don't believe it's the case today. That is _absolutely_ the impression I get from speaking to v6 supporters today. The profess otherwise, but the solutions and technologies they suggest disprove their protestations. Guess I better get over to shim6 and see what I'm missing out on. -- TTFN, patrick The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
In message [EMAIL PROTECTED], JORDI PALET MARTINEZ w rites: I don't think is failing ... On the other way around: looking at the adoption perspectives and compared with other technologies, transition stages, and so on, is going much faster than expected ... About 4 years ago, I predicted that v6 would be very significant 8-10 years from then. I think we're right on track. As someone else noted, Windows Vista will have v6 enabled by default. There's also a version-independent network API. As a consequence, most applications written for Vista will be v6-capable. Vista will ship next year; 4-5 years after that, most desktops will be running it, and hence will support v6, including the applications. We're also seeing planning for conversion (i.e., the U.S. Defense Department) and deployment in some parts of the world. An obvious corollary to this is that ISPs should be planning their v6 offerings now, too. This means routers, databases, operation support systems, CPE for cable and DSL ISPs, etc. Those that don't are likely to find themselves bypassed. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Mon, 12 Sep 2005, Steven M. Bellovin wrote: An obvious corollary to this is that ISPs should be planning their v6 offerings now, too. This means routers, databases, operation support systems, CPE for cable and DSL ISPs, etc. Those that don't are likely to find themselves bypassed. and ISP's should plan on how to do traffic management/engineering in that new world (so start poking your head into the current v6 multihoming 'solution' == shim6) , and vendors should plan on performance at the current level or likely better for bandwidth, pps, route-changes/sec, routing table size... (listen to your customers who are hopefully saying this too?) Oh, and some security thought should probably be had as well... both for applications/os's and networking equipment. -Chris
Multi-6 [WAS: OT - Vint Cerf joins Google]
[Perhaps this thread should migrate to Multi6?] On Sep 9, 2005, at 11:55 PM, Christopher L. Morrow wrote: On Fri, 9 Sep 2005, Daniel Golding wrote: Getting back on-topic - how can this be? I thought only service providers (with downstream customers) could get PI v6 space. Isn't this what policy proposal 2005-1 is about? Can someone (from ARIN?) explain the current policy? what if they didn't ask for a prefix but instead just hammered their providers for /48's? What's the difference to them anyway? (provided we are just talking about them lighting up www.google.com in v6 of course) If they wanted to start offering more 'services' (ip services perhaps?) then they could say they were a 'provider' (All they need is a plan to support 200 customers to get a /32) and start the magic of /32-ness... Suppose they not only have no plan but couldn't really put together a plan to support 200 customers? Does this mean Google, or any other content provider, is unworthy of globally routeable space? IPv6 is a nice idea, and as soon as people realize that ISPs are not the only organizations who have a need to multi-home - and I mean really multi-home, not stupid work-arounds - then it might actually start to happen. -- TTFN, patrick
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sat, 10 Sep 2005, Patrick W. Gilmore wrote: [Perhaps this thread should migrate to Multi6?] perhaps... then jason can argue this instead of me :) On Sep 9, 2005, at 11:55 PM, Christopher L. Morrow wrote: On Fri, 9 Sep 2005, Daniel Golding wrote: Getting back on-topic - how can this be? I thought only service providers (with downstream customers) could get PI v6 space. Isn't this what policy proposal 2005-1 is about? Can someone (from ARIN?) explain the current policy? what if they didn't ask for a prefix but instead just hammered their providers for /48's? What's the difference to them anyway? (provided we are just talking about them lighting up www.google.com in v6 of course) If they wanted to start offering more 'services' (ip services perhaps?) then they could say they were a 'provider' (All they need is a plan to support 200 customers to get a /32) and start the magic of /32-ness... Suppose they not only have no plan but couldn't really put together a plan to support 200 customers? Does this mean Google, or any other content provider, is unworthy of globally routeable space? apparently that's the plan yes, or so say the current decision makers/policy-makers/'the-man'... take it up with them, in fact, everyone should be thinking this through as you are/have and thinking about the implications of the current policies related to v6 address allocations, subnetting 'standards' and even multi-homing. IPv6 is a nice idea, and as soon as people realize that ISPs are not the only organizations who have a need to multi-home - and I mean really multi-home, not stupid work-arounds - then it might actually start to happen. Agreed, so... hopefully others will start to participate in the process to change things for the 'better'. To make sure that the policies/procedures are more closely aligned with operational requirements/needs. It seems that lots of folks are of the belief that: 1) its not important to worry about this 'today' 2) the 'right decision' will get made and 'things will just work out' 3) 'certainly someone else will argue my point for me' (or some combination of that grouping...) It looks to me, and I'm new at this so I may be wrong, that none of the above really is true :( The current train for ipv6 is on the tracks and headed your way whether you like it or not, and it's not headed your way to pick you up :( The process/standards bodies need more operators to get involved so that standards we can deploy/live-with make it to fruitition. Thanks for the tee :) -Chris
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On 10-Sep-2005, at 09:18, Patrick W. Gilmore wrote: [Perhaps this thread should migrate to Multi6?] multi6 hasn't existed for some time. The level-3 shim approach to multi-homing that was the primary output of multi6 is being discussed in shim6. Suppose they not only have no plan but couldn't really put together a plan to support 200 customers? Does this mean Google, or any other content provider, is unworthy of globally routeable space? Yes, according to the current RIR policies. [So the determination of unworthy above has been made, in effect, by RIR members.] IPv6 is a nice idea, and as soon as people realize that ISPs are not the only organizations who have a need to multi-home - and I mean really multi-home, not stupid work-arounds - then it might actually start to happen. It's not as though this line of thinking hasn't been followed many, many times before. The counter-argument goes like this: 1. There is more v6 space than there is v4 space, by virtue of the fact that the address is 96 bits wider. 2. Because there is vastly more v6 space than v4 space, if entitlement to PI space in v6 was opened up the chances are many more people would have v6 PI space than currently have v4 PI space. 3. Every PI assignment/allocation takes up a routing slot in every router in the DFZ. 4. Given 2 and 3, there is potential for the amount of state in the DFZ to exceed the capabilities of the network to hold and process it (e.g. enormous RIBs, soaring processor requirements for dealing with updates, etc). It's possible that the number of PI assignments might not be that high, and the scaling properties in practice might not be so bad. However, you only get to find this out after you've opened the floodgates, and if it turns out that it doesn't scale, it's hard to push the water back into the reservoir. The goal in shim6 is to find a mechanism which provides all the functional benefits of multi-homing without holding all the state in DFZ routers. There seems to be some ongoing perception that various protocol/ research organisations have no idea about the value of multi-homing for enterprises in the real network, and hence ignore it. While that might have once been the case (I certainly remember thinking so around 1997 whilst shouting on the ipng list), I don't believe it's the case today. The real problem is that there is no simple answer that doesn't have potentially nasty consequences. Joe
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sat, 10 Sep 2005, Marshall Eubanks wrote: Google == AS 15169 which has 100 prefixes announced in my BGP. I suspect they could qualify for IPv6 address space under any criteria. I know they could arrange to qualify, simply by buying an appropriate ISP. They've got the cash. most likely, but I was really saying: Do they even NEED PI space? (for this discussion, or rather the start of it, I don't think so... -Chris
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sep 10, 2005, at 10:17 AM, Joe Abley wrote: [Perhaps this thread should migrate to Multi6?] multi6 hasn't existed for some time. The level-3 shim approach to multi-homing that was the primary output of multi6 is being discussed in shim6. Guess I'm behind. I'll have to subscribe to shim6. Suppose they not only have no plan but couldn't really put together a plan to support 200 customers? Does this mean Google, or any other content provider, is unworthy of globally routeable space? Yes, according to the current RIR policies. [So the determination of unworthy above has been made, in effect, by RIR members.] And this is why v6 has failed and will continue to fail. The Internet is no longer an academic experiment. It is not run by the 'best technology'. It is run by the best business results. Content providers and other large business, without who's funds the Internet would fail, have a right not to be tied to a single provider. And while I admit I am not up-to-date on v6 multi-homing strategies, the ones I have seen are either evil, unworkable or ridiculous, and simply will not fly. 's not as though this line of thinking hasn't been followed many, many times before. The counter-argument goes like this: 1. There is more v6 space than there is v4 space, by virtue of the fact that the address is 96 bits wider. 2. Because there is vastly more v6 space than v4 space, if entitlement to PI space in v6 was opened up the chances are many more people would have v6 PI space than currently have v4 PI space. This assumption has more holes in it than swiss cheese. 3. Every PI assignment/allocation takes up a routing slot in every router in the DFZ. 4. Given 2 and 3, there is potential for the amount of state in the DFZ to exceed the capabilities of the network to hold and process it (e.g. enormous RIBs, soaring processor requirements for dealing with updates, etc). Ignoring the problems with #2, what is made of the idea that each AS might only have a single block, since blocks are so much larger? (And lots of other questions I'm sure you guys have already covered which are probably not on-topic for NANOG.) It's possible that the number of PI assignments might not be that high, and the scaling properties in practice might not be so bad. However, you only get to find this out after you've opened the floodgates, and if it turns out that it doesn't scale, it's hard to push the water back into the reservoir. The goal in shim6 is to find a mechanism which provides all the functional benefits of multi-homing without holding all the state in DFZ routers. Perhaps the goal ... was chosen poorly? There seems to be some ongoing perception that various protocol/ research organisations have no idea about the value of multi-homing for enterprises in the real network, and hence ignore it. While that might have once been the case (I certainly remember thinking so around 1997 whilst shouting on the ipng list), I don't believe it's the case today. That is _absolutely_ the impression I get from speaking to v6 supporters today. The profess otherwise, but the solutions and technologies they suggest disprove their protestations. Guess I better get over to shim6 and see what I'm missing out on. -- TTFN, patrick
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sep 10, 2005, at 1:58 PM, Christopher L. Morrow wrote: most likely, but I was really saying: Do they even NEED PI space? (for this discussion, or rather the start of it, I don't think so... I disagree. (Or, more precisely, I don't think _anyone_ needs v6 space right now 'cause it ain't really used. But assuming you want to use it, Google needs is, IMHO.) Care to explain why you think so? -- TTFN, patrick
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
on topic of IPv6 end-user assignments and value of multihoming At 6:23 AM -0400 9/10/05, Marshall Eubanks wrote: However, there are two proposals to ARIN to allow direct micro assignments to end sites, these are supposed to be merged into one by the 16th of this month, so people interested should go over to the ARIN ppml and comment. Marshall - good pointer... It is worth repeating that folks who hold an opinion on this matter either way should quickly get involved, whether that is via mailing-list or in person at the upcoming NANOG/ARIN meeting in LA. Thanks! /John
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
On Sat, 10 Sep 2005, Patrick W. Gilmore wrote: Content providers and other large business, without who's funds the Internet would fail, have a right not to be tied to a single provider. And while I Giving each entity who wants to multihome an AS of their own and own address block, doesn't scale. Think this in the way of each home in the world being multihomed, it just doesn't scale. IPv6 solved the addressing problem, not the routing problem, in the current model. Let's try to fix the routing problem NOW instead of 5-10 years down the road. The shimming model is a way to solve this by the endsystems knowing about multihoming, instead of the network. I personally think this is a better idea and scales much better. Let's have the network moving packets as its primary goal, not solving how do I reach this prefix equations. http://www.ietf.org/html.charters/shim6-charter.html -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
