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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------