I have reviewed this specification. It is well written and ready to move
forward; I have asked for an IETF Last Call.
I did have two very minor editorial comments, and one personal opinion:
In this case too, the word
"alone" is to be interpreted precisely - a router is allowed to
combine the flow label value with other data in order to produce a
uniformly distributed hash.
I think this would be simpler if you had just said "But the word "alone"
needs to be taken into account - a router is allowed ..."
(There is nothing precise or imprecise about this. You just can't bypass
the key word from the rule.)
The main novelty is that a forwarding node (typically a first-hop or
ingress router) may set the flow label value if the source has not
done so, according to the same recommendations that apply to the
source. This might place a considerable processing load on ingress
routers, even if they adopted a stateless method of flow
identification and label assignment.
I'd prefer to replace the second sentence with "This might place a
considerable processing load on ingress routers that choose to do so,
even ..."
Finally, the personal opinion was that I'd probably have left four bits
from the flow label as reserved values (set to zero on send; included as
flow label bits for all other processing). I'm not asking you to change
the approach or the draft, just stating that I would have left some room
for future developments.
Jari
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
