I had a look at this draft. Specific comments below.
> The IPv6 w.g. chairs believe there are some important open issues that they
> would like to see the working group discuss as part of the working group
> last call on the "IPv6 Flow Label Specification"
> <draft-ietf-ipv6-flow-label-03.txt>.
>
> The current draft allows flow labels to be used in ways that go beyond the
> consensus that was reached when the working group agreed to make this
> document a working group document. This consensus was that the flow label
> would be set by a source node to label a set of packets (with same source
> and destination addresses) that the source wanted to be treated as a
> flow. The flow label in this definition did not have any defined
> structure. The main application for this was to make it easier for other
> nodes to recognize flows without having to search to one or more headers to
> find the transport port numbers.
I think the draft in its current form is a response to the discussion that came
up around flow labels. The current draft contains a few MUSTs, specifically:
- The Flow Label value set by the source MUST be delivered unchanged to the
destination node(s). (IMHO *the* most important requirement).
- IPv6 nodes MUST NOT assume mathematical or other non-mathematical
properties of the Flow Label assigned by source nodes.
- If an IPv6 node is not provided flow-specific treatment, it MUST ignore
the field when receiving or forwarding a packet.
- A source node MUST keep track of the Flow Label values it is currently
using or has recently used.
- When a new flow is instatiated, a unique Flow Label MUST be selected for
it (note: I presume this is if the Flow Labels are
being used, that is, I don't think this is meant to require *all* IPv6 nodes
to use flow labels).
- An IPv6 source node MUST provide a facility for selecting and assigning
unique Flow Label values, and for storing the Flow Label.
- The facility MUST be used whenever a lable needs to be assigned for a new
flow.
- A flow state establishment method MUST provide the means for flow state
cleanup from the IPv6 nodes providing the flow-specific treatment.
I think these cover the WG's original concensus on what should be in the draft.
The rest of the draft consists of specific requirements on other protocols that
are involved in managing flow label usage. As a whole, I find the requirements
quite sensible and I believe they will be very useful for guiding development of
flow label usage in other working groups.
It would be possible to separate out the specification of the flow label per se
by taking the above list of MUSTs and putting them in a separate document, but
the document would then be quite short (maybe only a page) and the context would
missing.
I do think, however, that other working groups might find reference to this
document easier if the requirements on flow label usage were better organized
and listed as specifically numbered items rather than be embedded in text.
>The current draft has a number of
> features that go beyond this model and permit many other modes. Examples
> include:
>
> - Allowing for other standard specifications to define properties and/or
> structure of the flow label field.
I actually don't see this. The MUST NOT requirement cited above specifically
prohibits assuming any structure to the flow label, for example.
> - A strong focus on the assignment of flow label via signaling protocols.
The focus is on requirements for signalling protocols, and I think that is
valuable. I've been recently thinking about how to use flow labels, and one
question that comes up is how to get agreement between two end nodes about what
the flow labels should be. This is an important part of the architecture, and
the document does a good job in outlining requirements for it.
> - Allowing a specific flow label value to be assigned via a signaling
> protocol to identify flows with different source and destination
> addresses.
>
This is a concern. I agree that keeping a simple flow label usage might be
better for now, until we have more experience. However, I can also see an
argument that it might simplify signaling in certain cases, for example,
multi-user voice sessions such as a teleconference.
> The draft may be trying to accommodate uses of the flow label that were not
> agreed to by the working group.
>
> There are a number of other areas in the draft that need additional
> discussion and/or clarification. These include:
>
> - No default time out for the life time for specific flow label values.
> - No requirement that signaling mechanisms must include a lifetime
> when providing flow label setup information.
I believe the issue here is flow label state, and not flow labels per se. I
agree that the document should state that flow label state should be soft state,
and that there should be a requirement that flow label state have a specific
lifetime.
However, as the document is trying to set up requirements, I believe specifying
a default lifetime for all applications would be inappropriate. I think it is
enough to require that signaling protocols and applications specify a default.
The default may differ depending on the application.
> - No default mechanisms if flow label values requested via a signaling
> mechanisms conflict with existing flow label values.
> - Security considerations need to discuss the impact of labeling flows
> of encrypted traffic.
>
It is not immediately clear to me whether additional requirements in this area
are needed, but it would not hurt to spend some time considering these.
jak
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
