Joel,
On May 7, 2010, at 07:28 MDT, Joel M. Halpern wrote:
> The more I think about "encouraging" locally defined use of the flow label,
> the less I like it.
>
> The basic problem is that in the context we are discussing, is for use by
> routers.
> If you have locally defined flow label usage, then
> 1) Any vendor selling to an operator has to somehow manage to support their
> locally defined behavior.
> 2) Operators MUST configure all their routers to properly understand their
> flow label meaning.
Why wouldn't I tell my vendors that I want the _default_ behavior on PE's to be
that they automatically set the flow-label to a pseudo-random hash of the
incoming 5-tuple hash on all inbound IPv6 interfaces? Sure, vendors could
create a global and/or interface-specific knob for those operators who feel
some reason to disable said default behavior (or, do something else "creative"
to create a flow-label value). However, I suspect operators would not want to
do that since it would clearly break LAG and ECMP in their networks.
> 2') Given that it can not be counted on, even the global interpretation such
> as the use of non-zero flow-labels for ECMP/LAG balancing would be to be off
> by default, since there would be no default expect ability to match that use.
I disagree. I would expect it to default to "on". :-)
> 3) This is quite fragile. Given that there is no indication in the packet of
> what meaning of flow-label was intended, there is nothing that will alert an
> operator if (as seems periodically inevitable some of the routers are
> attempting to apply a different interpretation than the operator intends.
I agree the current -03 draft, as written, is still a bit fragile. As one
example, this rule:
---snip---
6. When a locally defined scheme other than the pseudo-random scheme
is used, packets leaving the FL domain might contain a label that
would be misinterpreted elsewhere. Therefore, the boundary
egress FL router SHOULD set the label according to the pseudo-
random mechanism defined in rule 1. If not, it MUST set the
label to the default value of zero.
---snip---
I think it's operationally infeasible to expect such a FL domain NOT using a
pseudo-random hash in the flow-label to consistently "reset" the flow-label to
a pseudo-random hash or to the default of zero on egress. Misconfigurations,
bugs, etc. will happen in the real-world. Thus, unless I /explicitly/ trust an
adjacent flow-label domain is doing the right thing (i.e.: using a proper
pseudo-random hash of the 5-tuple), then I'd always default to setting the
flow-label value upon ingress to my network.
Regardless, I think these problems in the draft _can_ be addressed should the
WG agree to pursue Option 2, (locally defined use case).
> Basically, from a vendor's perspective, a multiplicity of local
> interpretations of flow label is a serious impediment to implementing any
> usage of flow label at all.
>
> One could argue that as long as the routers are all from one vendor, they
> will support the same local interpretation. I hope we are not going there!
>
> Hence, to be clear and specific, I support approach 1, and oppose approach 2.
I hope I can persuade you to change your opinion. :-)
-shane
> Yours,
> Joel
>
>
> Brian E Carpenter wrote:
>> Hi,
>> This is revised again according to discussion on the list, and some
>> off-list discussion with Shane Amante in particular.
>> Firstly, since there seemed to be a feeling that a full update
>> of RFC 3697 is better than publishing a set of changes, this is
>> now just informational, although written using normative language.
>> The major next step would be a 3697bis draft.
>> Secondly, it offers the WG a binary choice as the main decision:
>> "There appear to be two viable approaches:
>> 1. Definitively forbid locally defined use of the flow label.
>> Strengthen RFC 3697 to say that hosts SHOULD set a pseudo-random
>> label value, which would clarify and limit its possible uses. In
>> particular, its use for load balancing and possibly as a nonce
>> would be encouraged.
>> 2. Encourage locally defined use of the flow label. This approach
>> would make the flow label mutable and would exclude any use case
>> depending on end-to-end immutability. It would encourage
>> applications of a pseudo-random flow label, such as load
>> balancing, on a local basis, but it would exclude end-to-end
>> applications such as [I-D.blake-ipv6-flow-label-nonce]."
>> Please, can we focus on this choice rather than the fine details,
>> initially? Also, please read the draft as a whole; looking at diffs
>> would be quite confusing.
>> Brian + Sheng
>> -------- Original Message --------
>> Subject: I-D Action:draft-carpenter-6man-flow-update-03.txt
>> Date: Thu, 6 May 2010 18:00:01 -0700 (PDT)
>> From: internet-dra...@ietf.org
>> Reply-To: internet-dra...@ietf.org
>> To: i-d-annou...@ietf.org
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> Title : Update to the IPv6 flow label specification
>> Author(s) : B. Carpenter, S. Jiang
>> Filename : draft-carpenter-6man-flow-update-03.txt
>> Pages : 11
>> Date : 2010-05-06
>> Various published proposals for use of the IPv6 flow label are
>> incompatible with its existing specification in RFC 3697. This
>> document proposes changes to the specification that permit additional
>> use cases. The concept of flow label domains is introduced, with the
>> label possibly being rewritten at domain boundaries.
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-carpenter-6man-flow-update-03.txt
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
