Brian,
On Jun 25, 2011, at 7:06 PM, Brian E Carpenter wrote:
> 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.
I'm not comfortable with the words "in all cases" in the last sentence.
Perhaps change "in all cases" to "in these cases"? (IOW, I don't believe
you're trying to relax the rule that use of the 5-tuple is generally preferred
to construct a hash for the flow-label where _practical_).
> [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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
