I have reviewed this draft.

I think it is in good shape and can move forward once we resolve one issue. Here's the issue:

A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the flow label value.  In that case, it is
RECOMMENDED that the forwarding node sets the flow label field for a
flow to a uniformly distributed value as just described for source
nodes.
o  The same considerations apply as to source hosts setting the flow
   label; in particular, the normal case is that a flow is defined by
   the 5-tuple.
o  This option, if implemented, would presumably be used by first-hop
   or ingress routers.  It might place a considerable per-packet
   processing load on them, even if they adopted a stateless method
   of flow identification and label assignment.  This is why the
   principal recommendation is that the source host should set the
   label.
I think this recommendation is problematic. I agree that the first hop router should insert the flow label, but requiring it to do fragment reassembly in order to find the 5-tuple is a big burden, and I'm not sure its even called for.

The RFC 2119 language above is fine. But I'd like to change the part about normal case being the 5-tuple. I think the normal case should be the 2-tuple under these circumstances. The source has access to the 5-tuple; a router is not guaranteed to have access to it.

In addition, I'm not sure I understand how a router knows that it is a first hop router. Are there cases where a device might mistakenly believe it is a first hop router at a point where the traffic has already been load-balanced to multiple routers? Are there situations where the multiple first hop routers are used from the same host? The document should provide some guidance about operational conditions where the recommendations for the first hop router can be applied. The document should state how such functionality is turned on (per configuration? automatically?) and provide assurances that problematic conditions can be avoided.

Jari

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to