John, I agree. The basic spec should be lean and mean. Do you see anywhere that we have over-defined things?
Brian [EMAIL PROTECTED] wrote: > > Hi Margaret & authors, > > A high-level question - I think that many of your comments could/should > be handled by applications which use the flowspec. I am not so sure > that the draft, draft-ietf-ipv6-flow-label-02.txt, should define > these things. > > For example, I much prefer that the application (or signaling > protocol) set the following: > > 1) cached flow info timeout > 2) re-use of flow label values > > Additionally, signaling protocols making use of the flow spec should (must?) > define how routers are expected to use the flow label. > > In NSIS, we are starting to discuss these issues, and I would worry if > the IPv6 WG goes into too much detail with regards of how the flow label > is used, etc. > > thanks, > John > > > -----Original Message----- > > From: ext Margaret Wasserman [mailto:[EMAIL PROTECTED]] > > Sent: 10 July, 2002 03:29 > > To: Rajahalme Jarno (NRC/Helsinki); Steve Deering; Alex Conta; Brian > > Carpenter > > Cc: [EMAIL PROTECTED] > > Subject: IPv6 Flow Label Specification > > > > > > > > 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 PROTECTED] --------------------------------------------------------------------
