My opinions (not checked with the co-authors): Margaret Wasserman wrote: > > 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. > 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?
> 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. I suggested that but was overruled by my co-authors. It's not obvious that we can define a one-size-fits-all default. > > Could you also indicate whether the information about previous > 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. > > 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. No, only *some* previous discussions have centered around that. Others have centered around its use of Intserv and/or Diffserv. > 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? 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 > shoud? 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? > > 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? 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. > 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. 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. > And, this means that we would have to have some detailed requirements > 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 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
