Subject: IPv6 Flow Label Specification

From: Margaret Wasserman <[email-masked]>
Date: Tue, 09 Jul 2002 20:28:53 -0400

Hi Jarno, Steve, Alex and Brian,

I have a couple of questions about the latest IPv6 Flow Label
Specification <draft-ietf-ipv6-flow-label-02.txt>.

First, do you intend this specification to be mandatory for all
IPv6 nodes?  I would prefer a statement that nodes SHOULD 
implement this specification, and that nodes that do not implement
this specification MUST set the flow label in all originated 
packets to zero.

Also, should we define a default timeout for cached flow information
(i.e. 10 minutes)?  This would allow nodes to free information on
"recent" flows in a consistent fashion, when no signalling or other
mechanisms are available to indicate how long a flow could live.

Could you also indicate whether the information about previous
flows needs to survive TCP/IP restarts and/or node reboots?

Previous discussions of the flow label have centered around its
potential use for load sharing -- allowing a router to keep 
flows together when choosing between alternate paths.  Is that
still an expected use of this mechanism?  How does this fit with
the requirement in section 5, bullet (1): "The flow state establishment
mechanism MUST covey this classifying information to the IPv6 nodes
that need to perform the classification".  Is a load sharing router
a degenerate case where the information only needs to be conveyed
to the router itself?  Could you maybe add this example to the
document, and explain how it fits into each area of requirement?

Will hosts reuse a flow label if an application indicates that they
shoud?

I'm still concerned about how/if routers may cache forwarding
information based on the flow label.  Is it you intention that this
would be an acceptable use?  What about security information?  
It still seems to me that acceptable uses of the flow label are
tied to just how certain we can be that the flow triplet (label,
src address and dest address) will actually identify a single flow.
And, this means that we would have to have some detailed requirements
for how/if flow labels are reused.

Margaret

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jul 2002 13:37:29 +0200

My opinions (not checked with the co-authors):

> this specification MUST set the flow label in all originated
I thought that was in effect what it did say (i.e. setting the label
to zero does conform to the spec). Do you want to suggest a precise
wording change?

> mechanisms are available to indicate how long a flow could live.

I suggested that but was overruled by my co-authors. It's not obvious
that we can define a one-size-fits-all default.

> flows needs to survive TCP/IP restarts and/or node reboots?

I'd say that the Flow Label Aassignment Process (FLAP, but again I
was overruled on the grounds of too many acronyms :-) should
survive reboots, i.e. the same label should not be assigned again
even after a reboot. I don't see that it matters if the same label
is assigned to the "same" flow after a TCP reset and reconnect, but
normally I'd expect it to be a different label, because there is no
way for the assignment process to know it's the "same" flow back again.

So I think it would be useful to add a note that the assignment process
should survive reboots.

> flows together when choosing between alternate paths.  

No, only *some* previous discussions have centered around that.
Others have centered around its use of Intserv and/or Diffserv.

> Is that

I certainly see nothing in the spec that prevents such use. But after
discussion between the authors, we decided to cut down on the use
cases since this is supposed to be a spec. If we were going to add
this use case, I'd want to add back in the material about the other
use cases that we removed.

My preference is not to do this, and leave the description of the various
use cases for possible future informational documents.

> Will hosts reuse a flow label if an application indicates that they

That would be an API issue within the host. I don't think it
affects the protocol spec. Are you suggesting a change to the text?
> would be an acceptable use?  

If a label truly characterizes a flow, I see no reason why the routing
system shouldn't make use of it. But again, it's a use case not part
of the spec.

> What about security information?

Don't understand the question.

> src address and dest address) will actually identify a single flow.

I don't think we should get into the business of what's "acceptable".
Let's just concentrate on defining the minimum conditions a node must
meet. That is what is holding up implementors.

> for how/if flow labels are reused.

No. That will vary from one use case to another. So we definitely 
*should not* try to specify the reuse rules in the general spec.

   Brian