Jari,
Thanks for the review.
On 2011-06-21 04:09, Jari Arkko wrote:
> 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.
Yes, this is an embarassingly good catch. I think we need to add some language
to the recommendation that source hosts SHOULD set their own flow labels,
pointing out that in a fragmented case this is the only way to do things
properly. Reverting to the 2-tuple is a serious penalty since a lot of
the entropy in headers is in one of the port numbers.
> 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.
As far as routers go, I think we have to say that an implementor has
to choose between a reassembly-based solution using the 5-tuple and
simply using the 2-tuple (maybe also the fragmentation ID - there is
some scope for ingenuity here).
> 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?
It's surely a configuration issue - enable flow labelling should
be configurable. Otherwise we have to be far too clever, as your
following points show.
> 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.
I'd like to hear from my co-authors and the WG before producing a new version.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
