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

[Bob Hinden <[e-mail]>]

Thomas,

Finally catching up on email after IETF.

On Apr 5, 2011, at 10:40 AM, Thomas Narten wrote:

> 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:

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


> 
>    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