Subject: [Fwd: New Version Notification for draft-carpenter-flow-ecmp-02]

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Apr 2010 16:53:31 +1200

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 <[email-masked]>
To: [email-masked]
CC: [email-masked]

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

---

From: Shane Amante <[email-masked]>
Date: Wed, 14 Apr 2010 23:25:42 -0600

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:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Thu, 15 Apr 2010 13:40:56 -0400

Hi Shane,

On 4/15/10 1:25 AM, Shane Amante wrote:
> 
> 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?

This type of scenario is what prompted my question to Brian C. at the
mic in Anaheim.  In a previous life, I was looking at ways to leverage
ECMP for IPv6 traffic when the traditional 5-tuple was unavailable.
Typically, this was due to the payload being encrypted.  The only sane
way was to hash <Src Addr, Dst Addr, Flow Label> as long as the Flow
Label was set by the originating host.  The prototype I hacked together
on the host side set the flow label per socket.  I also threw together a
Quagga-based marking box that did the DPI on unencrypted packets and
assigned a unique Flow Label per <Protocol, Src Port, Dst Port> in order
to allow boxes doing ECMP to use the Flow Label-based 3-tuple.  The cost
of doing the DPI to mark the packets was quite heavy given the arbitrary
extension headers I threw at it.

In the long run, I believe we need a way to create ECMP & LAG hashes out
of *just* the base IPv6 header fields given these constraints on finding
the layer-4 information and the limitation that some routers have of not
having the entire packet available for searching.

Regards,
Brian