Hi,
The discussion Jari's issue has died down, so I'd like to propose some revised
text:
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 preferred case is that a flow is defined
by the 5-tuple. However, there are cases in which the complete
5-tuple for all packets is not readily available to a forwarding
node, in particular for fragmented packets. In such cases a flow
can be defined by fewer IPv6 header fields, typically using only
the 2-tuple {dest addr, source addr}. A forwarding node
implementation MAY use this 2-tuple in all cases.
[BC: this version indicates the problem that Jari discovered, but is
agnostic on the question of whether a router could or should solve it
by reassembling the fragmented packet.]
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.
o The deployment of this option MUST be consistent with [RFC4311].
[BC: This last sentence is to cover Jari's point about a router knowing it's
appropriate for it to set the label.]
Comments? If not, I will post the draft in a day or two.]
Regards
Brian Carpenter
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.
>
> 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
--------------------------------------------------------------------
