Hi Brian. Changes look mostly good. Some specific comments.
Brian E Carpenter <brian.e.carpen...@gmail.com> writes: > > 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" > Well, using the transport information makes it a layer violation. Do > we really want to open that discussion? What, we can't be honest about what people really are doing and have been doing forever? I don't see why this has to result in some big philosophical discussion... > > > > 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. > We agree that this all belongs together in one short paragraph (see > below). But we don't agree to remove the "MUST ensure...". We believe > this is a mandatory constraint on all hypothetical stateful schemes. A requirement saying you cannot modify the Flow Label (unless it is zero) seems awfully clear to me. Why we then also have to say the above is what I don't understand. State the requirement clearly, unambiguously, and once. That should be sufficient. The part that I object to "if they are sent outside the network domain", as it implies that it must be OK to change it within a network domain. If this spec is trying to say that, I object and would like to know why. > > 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. > We're reluctant to use a normative SHOULD in fact - in the end it's an > implementation choice - but yes, we should give clear suggestions - > see new text. I'm not calling for a SHOULD. But I do think it would be helpful to give one or more example algorithms that could be used. The revised version of the document still doesn't give one. > > 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. > Er, isn't that exactly what the sentence says? Not to me... How can a sender "not otherwise set" a value? It has to set it to something, even if it is just a random value because it doesn't conciously set it... But may that's just me. Below are some additional comments on the revised document itself. Thomas 2011-05-03 Review of -03 Flow label values should be chosen such that their bits exhibit a high degree of variability, making them suitable for use as part of the input to a hash function used in a load distribution scheme. At the same time, third parties should be unlikely to be able to guess the next value that a source of flow labels will choose. s/guess the next value/guess values/ An implementation in which flow labels are assigned sequentially is NOT RECOMMENDED, as it would then be simple for third parties to guess the next value. This then means the examples in gont-security cannot be used? (They generate sequential values....). I think the above is not right, and needs to be more nuanced. I think it would be useful to change "third parties" to "off-path attackers". Those on path will be able to see the values in use, so you are stuck with that. And the algorithm in gont-security presumably are fine to protect against off path attackers. Right? (Thus, I think the above needs tweaking). A node that forwards a flow whose flow label value in arriving packets is zero MAY change the flow label value. reword: A node that forwards a packet whose received flow label value is zero MAY change the flow label value. > 4. Flow State Establishment Requirements > > 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. > Thus, 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. Further details are not discussed in this document. The above is a little awkward in places. Suggest the following: 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. Such state establishment approaches may include signaling to establish state in routers along the path to the destination. In order to avoid interference with nodes implementing the stateless model described in this document, the assignment of label values MUST satisfy the properties described in Section 3. Further details of stateful Flow State establishment are outside the scope of this document. > This specification defines the flow label as immutable once it has > been set to a non-zero value. However, 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. Again, I object to the above as stated. Getting to Ran's point, if we think that border routers will zero out the Flow Label, let's be honest and state that directly and also *why* (and maybe provide some context about whether that is good/bad/etc.). The above IMO is trying to have it both ways, in a way that no one will understand and will easily be misinterpreted. > 9. Acknowledgements Would be good to more clearly identify the text that applies to this version of the document vs. previous versions. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
