Re: [Fwd: I-D Action:draft-ietf-6man-flow-ecmp-01.txt]

[Thomas Narten <[e-mail]>]

Looking at the revised document, here are some additional comments.

   One lightweight approach to ECMP or LAG is this: if there are N
   equally good paths to choose from, then form a modulo(N) hash
   [RFC2991] from a consistent set of fields in each packet header
   that are certain to have the same values throughout the duration of
   a flow, and use the resulting output hash value to select a
   particular

would be nice to have a term better than "consistent". The point is,
you want to use fields that stay constant for a given flow.

   distribution, due to the pseudo-random nature of ephemeral ports.
   Ephemeral port numbers are quite well distributed [Lee10] and will

is "pseudo-random" right here? IN fact, do we even need that last part
of the sentence?

   o The flow label in the outer packet SHOULD be set by the sending
      TEP to a pseudo-random 20-bit value in accordance with [RFC3697]
      or its replacement.  The same flow label value MUST be used for

Don't like this psuedo-random requirement here. And, the TEP should be
setting the Flow Label in *exactly* the same way as 3697bis
recommends. Tunnels are no different...

      * Note that this rule is a recommendation, to permit individual
         implementers to take an alternative approach if they wish to
         do so.  For example, a simpler solution than a pseudo-random
         value might be adopted if it was known that the load balancer
         would

	 Carpenter & Amante Expires August 14, 2011 [Page 6]
	 
	 Internet-Draft Flow Label for tunnel ECMP/LAG February 2011


         continue to provide uniform distribution of flows with it.
         Such an alternative MUST conform to [RFC3697] or its
         replacement.


This is too wishy washy. It also suggests that the TEP setting the
Flow Label knows about the algorithm used by the load balancer. That
will rarely (never?) be the case and this document shouldn't suggest
this. 

      the relevant flow label into the outer IPv6 header.  A user flow
      could be identified by the ingress TEP most simply by its
      {destination, source} address 2-tuple (coarse) or by its 5-tuple
      {dest addr, source addr, protocol, dest port, source port} (fine).
      At present, ironically, there would be little advantage for IPv6
      packets in using the {dest addr, source addr, flow label} 3-tuple.

Ambiguous. Advantages compared to what?

Also, the Flow classification should simply follow the recommendation
in 3697bis, which says use  the 5 tuple, or, at a minimum, the 3
tuple. The 

      The choice of n-tuple is an implementation detail in the sending
      TEP.

No it's not. What may be a detail is the actual algorithm used. But
which fields to use should be a clear recommendation (e.g., taken from
3697bis).

      *  This stateless method creates a small probability of two
         different user flows hashing to the same flow label.  Since RFC
         3697 allows a source (the TEP in this case) to define any set
         of packets that it wishes as a single flow, occasionally
         labeling two user flows as a single flow through the tunnel is
         acceptable.

This should be fine. There is no problem with treating packets from 2
different flows the same way. The problem occurs if packets from
within one flow are treated differently.

   o  At intermediate router(s) that perform load distribution, the hash
      algorithm used to determine the outgoing component-link in an ECMP
      and/or LAG toward the next-hop MUST minimally include the 3-tuple
      {dest addr, source addr, flow label}.  This applies whether the
      traffic is tunneled traffic only, or a mixture of normal traffic
      and tunneled traffic.

Be more clear: should be 5 tuple, next best is 3. Defer to 3697bis.

Thomas