Sam,
On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote:
"Shane" == Shane Amante <sh...@castlepoint.net> 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, 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. 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---
... 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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
