On Wed, Aug 5, 2009 at 2:33 PM, Margaret Wasserman<m...@sandstorm.net> 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? 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?
in the extreme it's only needed for +1g flows, but there are lots of places where this may be necessary across smaller links ecmp'd together... Planning for no ECMP is not a plan that's sensible. There must be a way to sensibly hash traffic across more than one path in a network (not just local ecmp on a single LAG or set of links, think about multple lsp's between 2 distant endpoints). >> 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 What was the original reason for removing the ability to do zero checksums on udp in v6? Are we sure that that decision is still sensible/appropriate in today's internet/world? -Chris > 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. > > Margaret > > _______________________________________________ > lisp mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
