A question for the WG.
Underneath the diagram of the TEP's, there is reference to the fact that the
input keys to the modulo(N) hash are quite large, which could be problematic
for HW implementations. However, below that, in the last bullet in Section 2,
there is a statement about adding the flow-label to the existing 5-tuple hash
which would increase the input keys from 296 bits to 316 bits, which seems
somewhat contradictory to what was said above. Perhaps we could change the
existing recommendation around to be as follows:
---snip---
o At intermediate router(s) that perform ECMP or LAG for packets
whose source address is a TEP, the hash MUST minimally include
the triple {dest addr, source addr, flow label} to meet the
[RFC3697] rules. In practice, since the routers are assumed to be
unaware of tunneled traffic, this means intermediate router(s)
SHOULD add the flow label to the existing 5-tuple hash of the
outer IP header.
---snip---
More generally, this really raises the question of the practicality of
searching for Layer-4 protocol, source & destination port info in headers and
using them as input keys for LAG + ECMP when forwarding IPv6, particularly on
high-speed core routers. Ultimately, if the flow-label was known to denote a
proper "microflow" (as defined by RFC 2474), then it would make HW
implementations much simpler in that they have a known & fixed set of header
fields, specifically: {dest address, src address + flow-label}, they would use
as input keys for LAG + ECMP. Arguably, it makes adding Extension Headers
easier in the future, as well, given that we don't have to worry as much about
intermediate routers being unable to look past them ... Of course, the
downside is this effectively boxes out any other (future) use of the
flow-label. Thoughts?
-shane
On Apr 14, 2010, at 22:53 MDT, Brian E Carpenter wrote:
> Shane Amante and I have updated this draft, and we'd like
> the 6man WG to consider it as a potential BCP (or
> alternatively, suggest another WG for it, but it does seem
> like IPv6 maintenance).
>
> We think this version responds to the discussion in Anaheim
> and the comments we've received; the main differences from the
> 01 draft are
>
> a) link aggregation is now explicitly covered
> b) normative keywords added
>
> Brian
>
> -------- Original Message --------
> Subject: New Version Notification for draft-carpenter-flow-ecmp-02
> Date: Wed, 14 Apr 2010 21:49:34 -0700 (PDT)
> From: IETF I-D Submission Tool <idsubmiss...@ietf.org>
> To: brian.e.carpen...@gmail.com
> CC: sh...@level3.net
>
>
> A new version of I-D, draft-carpenter-flow-ecmp-02.txt has been
> successfully submitted by Brian Carpenter and posted to the IETF
> repository.
>
> Filename: draft-carpenter-flow-ecmp
> Revision: 02
> Title: Using the IPv6 flow label for equal cost multipath
> routing and link aggregation in tunnels
> Creation_date: 2010-04-14
> WG ID: Independent Submission
> Number_of_pages: 8
>
> Abstract:
> The IPv6 flow label has certain restrictions on its use. This
> document describes how those restrictions apply when using the flow
> label for load balancing by equal cost multipath routing, and for
> link aggregation, particularly for tunneled traffic.
>
>
>
>
> The IETF Secretariat.
>
>
>
>
> --
> Regards
> Brian Carpenter
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
