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