Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Apr 2011 13:40:50 -0400

Here are my detailed comments on the document. I did chat with Brian
directly in Prague about these points as well. Overall, I support this
document. But I think the wording in places needs another round of
revision.

   A flow is a sequence of packets sent from a particular source to a
   particular unicast, anycast, or multicast destination that a node
   desires to label as a flow.  A flow could consist of all packets in a

This is a circular definition. I think it would be useful to give two
definitions, something like the following:

    A Flow is a sequence of packets originating from a particular
    application that should be treated "the same" by the network as
    they are forwarded along to their ultimate destination. Packets
    within a flow should not be reordered, should not be given
    dissimilar QOS treatment, etc. What constitutes a Flow can only be
    defined by the application itself.

    At the network level, routers need to be able to identify packets
    belonging to the same Flow in order to process them
    consistently. At the same time, it may be beneficial to process
    packets between the same src/destination pairs (but from different
    application flows) differently, e.g., to support ECMP or other
    types of load splitting.

Then:    

    Traditionally, flow classifiers have been based on the 5-tuple of the
    source and destination addresses, ports, and the transport
    protocol

add "flow classifiers at the network layer"

   The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a
   node to label packets of a flow.  A Flow Label of zero is used to
   indicate packets not part of any flow.  Packet classifiers can use

reword to say "that have not been labeled" (Packets will almost always
be part of some Flow).

   specification.  However, any node that sets flow label values
   according to a stateful scheme MUST ensure that packets conform to
   Section 3 of the present specification if they are sent outside the
   network domain using the stateful scheme.

The above wording regarding "sent outside the network domain" is
problematic. It hints that maybe you can do things with the Flow Label
within a domain so long as you don't send such packets outside the
domain. We shouldn't even hint that that is acceptable. I'd suggest
removing all references to the "stateful" flow label scheme to one
section. And that section could be very short.
 
   1.  Implementers are advised that forwarding nodes, especially those
       acting as domain border devices, might nevertheless be configured
       to change the flow label value in packets.  This is undetectable,
       unless some future version of IPsec authentication [RFC4302]
       protects the flow label value.

Remove this. Again, the Flow Label is  not allowed to be modified
accept when zero. That is all that needs to be said.

       if the packet will leave their domain.  If it is known to a
       border router that flow labels originated within the domain are
       not uniformly distributed, it will need to set outgoing flow
       labels in the same manner as described for forwarding nodes in
       Section 3.

Remove this. It agains suggests border routers will be resetting Flow
Label values.

   o  Implementers should be aware that the flow label is an unprotected
      field that could have been accidentally or intentionally changed
      en route.  Implementations MUST take appropriate steps to protect
      themselves from being vulnerable to denial of service and other
      types of attack that could result (see Section 6.1).

Can we just move this advice to the Security Considerations section?
IMO, we are giving it too much weight by having it in the main text.

   o  Forwarding nodes such as routers and load balancers MUST NOT
      depend only on Flow Label values being uniformly distributed.  In
      any usage such as a hash key for load distribution, the Flow Label
      bits MUST be combined at least with bits from other sources within
      the packet, so as to produce a constant hash value for each flow
      and a suitable distribution of hash values across flows.

Can't we just come out and say that routers should:

1) use the src/dest/flow/port numbers? this is the most prefered.

2) if you can't use the port numbers, hash on the 3 tuple.

3) you could also say hash on teh src/dest alone as a last resort, but
why the Flow Label RFC would suggest that isn't immediately obvious to
me. :-)

   The use of the Flow Label field does not necessarily signal any
   requirement on packet reordering.  Especially, the zero label does
   not imply that significant reordering is acceptable.

The first sentence above isn't right. One SHOULD NOT reorder packets
from the same flow. Period. 

   An IPv6 node that does not set the flow label to a non-zero value, or
   make use of it in any way, MUST ignore it when receiving or
   forwarding a packet.

I don't understand why this wording is in here. For the stateless
case, nodes should simply ignore the received Flow Label value. We
should probably just say that.

   It is desirable that flow label values should be uniformly
   distributed to assist load distribution.  It is therefore RECOMMENDED
   that source hosts support the flow label by setting the flow label
   field for all packets of a given flow to the same uniformly
   distributed pseudo-random value.  Both stateful and stateless methods
   of assigning a pseudo-random value could be used, but it is outside
   the scope of this specification to mandate an algorithm.  In a
   stateless mechanism, the algorithm SHOULD ensure that the resulting
   flow label values are unique with high probability.

I think we need to specify some recommended algorithms. They can be
SHOULDs (rather than MUST), but saying nothing leaves things too
unclear. In particular, if we think just doing a simple hash based on
the port numbers (or something) is good enough, we should recommend
that.

Also, this document should not be requiring (or  even use SHOULD) to
say pseudo randomness is necessary. This document has not made the
case for that.

   An OPTIONAL algorithm for generating such a pseudo-random value is
   described in [I-D.gont-6man-flowlabel-security].

   [[ NOTE TO RFC EDITOR: The preceding sentence should be deleted, and
   the reference should be changed to Informative, if the cited draft is
   not on the standards track at the time of publication. ]]

I'd prefer that this document provide a suggested algorithm.

   A source node which does not otherwise set the flow label MUST set
   its value to zero.

Better: just say that the default value should be zero, unless set
explicitely.

   A node that forwards a flow whose flow label value in arriving
   packets is zero MAY set the flow label value.  In that case, it is

s/MAY set/MAY change/

   A node that sets the flow label MAY also take part in a flow state
   establishment method that results in assigning specific treatments to
   specific flows, possibly including signaling.  Any such method MUST
   NOT disturb nodes taking part in the stateless model just described.
   Further details are not discussed in this document.

I don't understand what does this is really intended to mean. IMO,
just say the first sentence, and then say the details of stateful are
out of scope for this document.

   would cause a stateful mechanism to behave incorrectly.  For this
   reason, stateless mechanisms should not use the flow label alone to
   control load distribution, and stateful mechanisms should include

s/stateless mechanisms/stateless classifiers/

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Apr 2011 20:57:52 +1200

Thomas,

Thanks for your three sets of comments. The authors will work on
new versions to respond to them. That will take two or three
weeks, I think.

Regards
   Brian

On 2011-04-06 05:40, Thomas Narten wrote:
> Here are my detailed comments on the document. 
...

---

From: Scott Brim <[email-masked]>
Date: Wed, 6 Apr 2011 11:48:57 -0400

>    defined by the application itself.

Sorry, Thomas, I don't think this will work.  First, I don't think we can
define a "flow" by what the network should do with it, whatever it is.  If
something is definable, then it has attributes independent of how other
things behave toward it.  It seems that a flow is anything the node labels
with the same flow label.  If so (as in your last sentence), then that's the
only definition you have.  Also, a flow doesn't necessarily originate from a
single application.  It could be multiple.  Some environments don't even
have applications.  My inclination would be to decline this definition
change.

The rest looks good.

Thanks ... Scot

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 Apr 2011 14:49:56 -0400

Hi Scott.

> define a "flow" by what the network should do with it, whatever it
> is.

Well, we are defining a flow by what the network SHOULD NOT do with
packets belonging to the same flow. I.e., packets within a Flow should
not be reordered. That seems to be the key requirement/principle. (Are
there other attributes?)

> If something is definable, then it has attributes independent of how
> other things behave toward it.  It seems that a flow is anything the
> node labels with the same flow label.

Right.

> If so (as in your last sentence), then that's the only definition
> you have.  Also, a flow doesn't necessarily originate from a single
> application.  It could be multiple.

Agreed.

> Some environments don't even have applications.  My inclination
> would be to decline this definition change.

What I think is worth highlighting is that what constitutes a flow can
only be defined by the source of the traffic (i.e., the application(s)
or whatever is at the higher layer). The source node may be using
heuristics to label flows that don't completely match up with what the
application thinks.  That is not necessarily a problem (it's reality),
but I think its useful to make that distinction.

I.e., ideally, the higher layers are what label individual flows. But
if that doesn't happen, the sending node can use heuristics (like
looking at port numbers to fill in the Flow Label) and do pretty well.

Thomas

---

From: Scott Brim <[email-masked]>
Date: Wed, 6 Apr 2011 16:22:02 -0400

> not be reordered. That seems to be the key requirement/principle. (Are

Last sentence first: Yes and the text that was there was

  "A flow is a sequence of packets sent from a particular source to a
  particular unicast, anycast, or multicast destination that a node
  desires to label as a flow."

... but what the network should/should not do SHOULD be farther down in the
draft where such things are already discussed, not in the (very small,
simple) definition of a flow at the beginning, no?

But let's not spend a lot of time on it.

Completely agree on the rest.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Apr 2011 19:37:45 +1200

>> looking at port numbers to fill in the Flow Label) and do pretty well.

We got a pretty clear message a few discussions ago to drop the
speculative text in RFC 3697 about how hosts would support the ability
of applications to do this. So the idea is to be silent on this.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 12 Apr 2011 15:46:41 -0700

Thomas,

Finally catching up on email after IETF.

> definitions, something like the following:

Like Scott, I don't have any difficulty with the current text, nor find it circular.    My preference is to leave it as is.

I agree with the rest of your proposed changes.  Thanks for taking a another close look.

Bob