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