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

[Thomas Narten <[e-mail]>]

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