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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
