Subject: Under IESG review: draft-ietf-ipv6-flow-label-07.txt

From: Alex Zinin <[email-masked]>
Date: Tue, 5 Aug 2003 15:46:45 -0700

This one needs a look too. I thought we concluded that IntServ
doesn't scale, and the doc talks about per-flow processing at
transit IPv6 nodes...

Token holder: Ross
Please send comments by Wed night.

-- 
Alex
http://www.psg.com/~zinin/

---

From: Ross Callon <[email-masked]>
Date: Wed, 06 Aug 2003 13:50:07 -0400

>Please send comments by Wed night.

General Comments

It seems to me that the flow label has a purpose, and two possible
uses. To me the document seems to be not totally clear or perhaps
even wrong regarding which of the uses is the main one. 

The purpose is to identify flows. For example, this allows the flow to
be identified using only fields which are in fixed positions in the IPv6 
Header. This purpose seems to me to be well defined in the document. 

Now that you have an indicator regarding what flow a particular packet
belongs to, what use would you have for this information?

One possible use is for hashing packets, for example to spread traffic
across equal cost multi-paths without re-ordering packets from any one 
flow. This seems like a pretty straightforward and sensible use, which 
requires close to zero change to the Internet architecture, and which 
is briefly mentioned in the document. 

The other possible use is for an explicit flow set up procedure. However,
since the flow are per-{source-address; destination-address; flow field}
triplet, it would seem that this won't scale much better than the current
int-serve specification. Thus it is not clear whether this will end up being
useful in practice. At best I would call this experimental. 

In some places in the document it appears that the flow field is for the
purpose of identifying flows, and that either of the two uses might be
sensible reasons that you might want to identify flows. In other places
in the document it looks like the second purpose (which to me seems
the more speculative) is the reason for the flow field.

I think that it would make sense to clearly separate these. 

More specific comments
 >> Section 1:

First three paragraphs do a good job of defining the purpose of the 
flow ID (to allow efficient flow classification based only on fields in
the fixed part of the IPv6 header). 

Fourth paragraph, first sentence: 
         The minimum level of IPv6 flow support consists 
         of labeling the flows.

In a sense this is reasonable, but I am not sure precisely what it means. 
Does this mean:

         In order to be an IPv6 conformant node, IPv6 source
         nodes MUST be able to label outgoing flows.

or does this mean:

         In order to claim conformance to the IPv6 flow 
         label specification, IPv6 source nodes MUST support 
         labeling outgoing flows.

Or does this mean something else? 

 >> Sections 2 and 3. 

This seems reasonable, and again defines the purpose of the
flow label in a reasonable way, as well as defining some very
reasonable requirements, for example specifying how a source
should set the flow value. 

 >> Proposed New Section Between section 3 and 4:

It seems to me that the most obviously worthwhile of the 
potential uses of the flow label field is to allow routers to split 
traffic on multiple paths (for example, for load sharing and traffic 
engineering purposes), without having to look past the IPv6
header. 

One example of where this might be very useful is in the case
of encapsulation, for example <anything> over IPsec over IPv6 
or <anything> over GRE over IPv6 encapsulations. In this case 
there might be a potentially very large number of high layer flows 
which will be encapsulated with the same IPv6 source and 
destination addresses in the outer IPv6 header. If you can hash
only on the outer IPv6 addresses, then you could get a lot of 
traffic which is forced to take the same path. If you allow a finer
grain flow label to be placed in the flow label field, then you can
get a much more even distribution of traffic across, for example,
equal cost multi-paths. 

I think that it is worth having a section on this possibility. I don't
think that this requires all that much text. 

There is one question which I have, which could be cleared up
in such a section: Specifically, the second sentence of section 
2 states:

         A Flow Label of zero is used to indicate packets
         not part of any flow. 

Suppose that I am an IPv6 router which is hashing on source
address, destination address, and flow label, and I am using
the hash to split traffic among several paths. 

If I see a packet with a flow label of zero, which of the following do
I assume:

         - the node does not implement any flow labelling ability, and 
           therefore I must hash only on source and destination address.

         - the node does implement flow labelling, and is telling me 
           that the packet is not part of any flow, and can therefore be
           forwarded on any path without regard for re-ordering. 

If we assume the latter, then implementation of the flow labelling
capability must be supported by all IPv6 source nodes (at least
to the point of sticking a non-zero value in the flow field), since 
otherwise their packets might be re-ordered by nodes which 
assume that their packets are not part of any flow.

I would suggest using zero to indicate that flow labelling is not 
supported (and thus routers better keep the packets in order 
based only on source and destination addresses). If we also 
want to indicate that some packets are not part of a flow, we 
might give them a random value, or a different special value. 

 >> Section 4:

The flow state establishment requirements in section 4 seem to be 
very much incomplete. If there were a complete set of flow state
establishment requirements, then I think that the requirements 
specified in this section are reasonable ones, and would be 
included in the set. However, the two requirements specified in 
section 4 seem to be such a small subset of the complete set of
requirements that I don't see why it is worth listing them at all. I
think that it would be cleaner just to say that methods and
requirements for explicit flow establishment are outside of the 
scope of this document.

Naturally if section 4 were removed, then the last phrase of the
first paragraph of the abstract would also need to be removed
(page 1, phrase "and the requirements for flow state establishment 
methods"). Similarly the second to last paragraph of section 1 
would need to be abbreviated. 

 >>Section 5:

First paragraph, last sentence:

         Even if the flow label were encrypted, its presence 
         as a constant value in a fixed position might assist 
         traffic analysis and cryptoanalysis.

The flow label is supposed to be unstructured -- in the sense that if
I am not the source node, then I don't know anything about how the source
set the label, except that a different value means a different flow. As such,
I don't understand what encryption would do to change the interpretation of
a flow label. If two labels were encrypted to the same exact value, then it 
would seem clear that they can't be un-encrypted back to different values. 
If two flow labels were encrypted to different values, then as a node in the 
middle observing the packets going by I don't detect any difference. 

Section 5.1, second paragraph (top of page 5), first sentence:

         Note that there is no guarantee that flow labels sent by a node are
         not set in any manner that the node wants to, such as reusing flow
         labels, against the recommendations in this document. 

This seems to be a rather awkward sentence, and should probably
be re-written. 

Additional Topic: Somewhere in the security section (probably in a new
subsection at the end) it might be worth mentioning that in those locations
where a firewall or filtering router is employed which looks past the IP
header to higher level headers, the flow label does nothing to eliminate the
need to continue to look at the higher headers. 

Ross

---

From: Alex Zinin <[email-masked]>
Date: Wed, 6 Aug 2003 12:50:19 -0700

Ross,

  Thanks a lot for the comments!
  I'll forward this to the IESG.