On Wed, Aug 5, 2009 at 12:50 PM, Shane Amante<[email protected]> wrote: > Sam, > > On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote: >>>>>>> >>>>>>> "Shane" == Shane Amante <[email protected]> writes: >> >> Shane> Take a look at the following URL: >> Shane> http://www.sixxs.net/faq/connectivity/?faq=ipv6transit >> Shane> (Note, I can't vouch for the accuracy of the entire list, >> Shane> but it's about the best publicly available list I've seen). >> >> Shane> That list includes some very large networks. >> >> >> Thanks for the data! Naturally that's only part of the answer to >> Margaret's question. We know which companies offer native IPV6 >> transit service. >> We don't know: >> >> 1) How much V6 traffic they have 2) Whether they have V6 >> infrastructure that would scale to their current V6 traffic or say >> their current V4 traffic 3) How much is done in hardware for their V6 >> infrastructure. 4) How much of their network supports V6/how >> widespread their V6 works. Any information you can provide on these >> sorts of questions would be very useful. > > I think question #1 is a little impractical, given that data is highly > sensitive/confidential to each network. However, one likely can Google/Bing > around and find public Exchange points with graphs that show current v6 > traffic (as compared to v4 traffic). Of course, I would highlight that > these are *public* exchange points, thus they will not show v6 traffic going > through private peering connections as well as staying Intra-provider, > (i.e.: customer-to-customer inside a single provider) -- see first sentence > about sensitivity/confidentiality. That said, there have been presentations > at the last couple of IETF's (I forget if it was in 'behave' or 'v6ops' > WG's, or both) surrounding Free Telecom's rollout of '6rd' that show their > v6 traffic, which has some astounding growth and traffic rates. Regardless, > one should consider the following graphs a absolute "floor" of v6 traffic > and there is definitely more, in absolute terms, v6 traffic than is visible > in these graphs. > Here's one example from AMS-IX showing v6 traffic: > http://www.ams-ix.net/technical/stats/sflow/?type=ipv6 > And, here are graphs showing Total traffic load, (I believe this includes > the v6 traffic in the graph above, but am not 100% certain on that point): > http://www.ams-ix.net/technical/stats/ > According to these graphs, v6 traffic is just a fraction of v4 traffic, but > it is definitely growing and, FWIW, it's a lot more than Inter-AS multicast > traffic as seen by other graphs at the AMS-IX Web site. :-/ > > With respect to #2, SP's have been mandating that they only buy v6-capable > HW for the last /several years/ as part of the normal growth/replacement > cycle of network equipment. So, yes, this equipment should scale to support > v6 traffic at the same, (or nearly the same), rates as v4 traffic today. > > #3: All v6 forwarding is done in HW for larger, "PE" or "P" class devices, > which are the subject of this thread. > > #4: Depends on where the carrier is at in their deployment of v6. However, > I would refer you back to question #2, which is even if it's not technically > offered at a given location today, it is only a matter of time given that > the HW is already deployed to do so (and, has been deployed for several > years). > > > To bring this back up a level, while it's /possible/ to encourage vendors to > adopt the IPv6 flow-label as input-keys to their hash-calculations for > LAG/ECMP, it takes [a lot] of time to see that materialize in the field. > Practically, you're probably looking at somewhere between, at best, a 3 - > 5 year window, before it will actually appear in live, production networks,
s/networks/hardware-shipped-by-vendors/ You may see 2-3 year cycle on new asics for this feature to appear... given 1-2 years for haggling/bugs/blah it's safe to say 3-5 yrs before hardware is on the shelf to purchase. Look at jason schiller's presos at IETF/RAWS/RRG that show 5-7 year lifecycle of equipment in a network, so add some years before shipped and deployed hardware is in general coverage in a network. Call it 10+ before it's ubiquitous... > given that it has to be prioritized for development at the vendor, tested, > released in software, then re-tested by the SP and, finally, deployed. and hopefully deployed in the hardware, since that's where this decision is made today (in v4 and v6 by 5-tuple). Software routers are dead in any large SP for an serious workload. (P or PE devices) > That's not an "easy" process that happens in the blink-of-an-eye. That's > not to say that we (SP's) should not "encourage" vendors to do this, anyway, > (we are/will) however if LISP (or other protocols like it that depend on > tunneling) quickly gain traction, we need a way to deal with these traffic > flows in our networks today, without telling customers: "turn off protocol > <FOO>, because we can't deliver your packets". Perhaps one way to satisfy > the parties in this conversation would be something along the following > lines: > - LISP, and other protocols that wish to use tunneling, adopt UDP-lite (or > UDP w/ 0 checksums) as a MUST for near-term deployment; > - LISP, and other protocols that wish to use tunneling, adopt IP-in-IPv6 > tunneling with a flow-label required in the outer IPv6 header as a "SHOULD" > for medium- to long-term deployments. > ... assuming vendors successfully adopt the IPv6 flow-label as input-keys in > their hash calculations at some point in the future, we come back and > deprecate the UDP/IPv6 tunnel method and elevate IP-in-IPv6 w/ flow-labels > to a MUST. > > It likely wouldn't hurt to go back and "tighten up" RFC 3697, as well, in > order that it offers more prescriptive behavior in several places, not least > of which would be: > 1) How to deal with regular IP-in-IPv6 encapsulation, (i.e.: likely by > creating a flow-label based on a "hash" of the incoming, to-be-encapsulated > L3 & L4 header fields), since the RFC only discusses IPsec tunneling; and, > 2) Removing other "gems" (or clarifying them) like the second sentence in > the following: > ---cut here--- > IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow > Label > values assigned by source nodes. Router performance SHOULD NOT be dependent > on the > distribution of the Flow Label values. Especially, the Flow Label bits alone > make > poor material for a hash key. > ---cut here--- 'flow label bits alone make a poor material for a hash key'... isn't this the reverse of saying that we'll (operators) require vendors to use flow-label for hashing on ECMP/LAG? If so, then... I don't think flow-label's going to cut it. -chris > ... specifically, if "router performance" is meant to imply the behavior of > load-balancing on ECMP/LAG paths, then router performance *is* heavily > dependent on the distribution of flow-label values ... > > I've said all I'm going to say on this thread ... > > -shane > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
