Re: [Softwires] I-D Action: draft-donley-softwire-dslite-flowlabel-02.txt

[Brian E Carpenter <[e-mail]>]

Hi,

The work on updating RFC 3697 has moved on and is currently in IESG discussion.

The editorial impact on draft-donley-softwire-dslite-flowlabel is that
the references to [RFC3697] and [I-D.ietf-6man-flow-update] need to be
replaced by a single reference to [I-D.ietf-6man-flow-3697bis].

The 6man WG consensus is to document only a stateless approach to the
flow label, with a recommendation that the flow label values should belong
to a uniform distribution, so that load balancing will work better. As
far as I can see, this suggestion in draft-donley is consistent
with that:

>    Implementations could use a 20-bit hash of the IPv4 5-tuple such that
>    subsequent IPv4 packets with the same 5-tuple will receive the same
>    flow label.

However, since the discussion in draft-ietf-6man-flow-3697bis is about
using a 20-bit hash of the IPv6 5-tuple, a few extra words may be needed
here, e.g.

    , in the same way that [I-D.ietf-6man-flow-3697bis] recommends a hash
    of the IPv6 5-tuple.

More seriously, I don't understand the following text:

>    As directed by [RFC3697] and [I-D.ietf-6man-flow-update], Flow Label
>    information is only significant to the B4 or AFTR transmitting the
>    particular DS-Lite flow.  Since the Flow Label will be consistently
>    applied to all packets in the flow, however, intermediate devices
>    between the B4 and AFTR can use the Flow Label in packet classifiers
>    to provide quality of service treatment to the flow.

The first sentence isn't obvious to me. The point is that the bits in the
flow label don't have any semantics; you could think of it as a nonce.
How will the downstream nodes know what treatment to apply? Who tells them
that a given new flow is, for example, VoIP? That would need a signaling
mechanism - not forbidden by 3697bis, but not specified either.

I thought that's what diffserv was for.

Regards
   Brian Carpenter