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.
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.
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.
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.
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: [email protected]
Reply-To: [email protected]
To: [email protected]
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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
