Hi Margaret,
Apologies for the delay, but it took some time to follow-up with some
vendors. See below.
On Aug 5, 2009, at 12:33 MDT, Margaret Wasserman wrote:
Hi Shane,
On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
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".
ECMP of LISP flows is an optimization that only matters when there
is a large amount of LISP traffic, right?
ECMP _and_ LAG. But, in short, you're correct. However, given the
dominant link speed deployed in today's networks is 10G, (which are
then lashed together in N x 10G LAG and/or ECMP paths), then we
clearly don't want anything near that size of single flows on these
links otherwise this will have a detrimental effect on the performance
of other "well-behaved" traffic that is being evenly spread over
parallel links.
Do you think there is a reasonable chance that LISP would be widely-
enough to deployed to require this optimization in less than 3-to-5
years?
My crystal ball is out-of-service. In other words, that's difficult
to say, given that LISP is currently pursuing a "Experimental" track.
However, assuming the experiment is successful, then it's pretty safe
to assume folks would want to quickly turnaround (with the methods &
protocols already developed and tested during the Experiment) and turn
that straight into a production service. So, IMO, it's best if we try
to get this "good enough" from the beginning and not hamper its
deployment by requiring networks to adapt before LISP, for example,
could really take off (at least, in the short-term).
Furthermore, given the LISP folks believe this is the first
"iteration" of LISP, there may be 'natural' points in the LISP
evolution path (for example, to support better mapping functions)
where it makes sense to consider evolving the encapsulation (for
example, to support flow-labels instead of UDP encaps), as well. I
would argue, though, to get to those 'natural' points people will need
to experiment with LISP to find out what works, and doesn't work, and
bring that back to the IETF community to figure when & how to evolve
LISP.
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.
I would agree to this statement if one of two things were to
happen: (1) we were to remove "(or UDP w/0 checksums) -- making UDP-
Lite a MUST in the near term", or (2) we were to satisfy ourselves
that using zero checksums will not represent an operational problem
for LISP, or for other applications that need to co-habitate with
LISP, and we were to add a normative dependency on a document (like
Marshall's, with edits) that would allow the use of UDP w/0
checksums over IPv6 in some cases, with LISP being an example of a
case where this was appropriate.
Based on my conservations with several vendors, flow-based load-
balancing over LAG/ECMP paths is currently NOT accounting for the
following in their input-keys to LAG/ECMP hash algorithms:
1) IPv6 flow-label; or,
2) UDP-lite (since, UDP-lite uses a different protocol ID [137]
compared to standard UDP [17]). In other words, if routers see UDP-
lite (Protocol ID: 137), the router will revert back to just using Src/
Dst IPv6 Addresses and will not have the benefit of being exposed to
the finer granularity of micro-flows that are denoted by varying the
Src/Dst Layer-4 (UDP-lite) ports.
Therefore, I'll have to revise my original recommendation in the first
bullet above that we only consider UDP with 0 checksums as the
preferred short-term solution when IPv6 is being used as the outer
encapsulation, (unless someone has a better idea that haven't been
brought forth, yet).
-shane
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
