Subject: RE: Flow label draft issues & new text

From: [email-masked]
Date: Mon, 5 Aug 2002 09:53:49 +0300

kre,

You got my point exactly, any suggestions on how to make the text clearer about this?

	Jarno

> -----Original Message-----
> From: ext Robert Elz [mailto:[email-masked]]
> Sent: 2. elokuuta 2002 11:59
> To: Brian E Carpenter
> Cc: [email-masked]; Margaret Wasserman; Rajahalme Jarno
> (NRC/Helsinki); [email-masked]; [email-masked];
> [email-masked]; Hinden Bob (IPRG)
> Subject: Re: Flow label draft issues & new text 
> 
> 
>     Date:        Fri, 02 Aug 2002 10:40:18 +0200
>     From:        Brian E Carpenter <[email-masked]>
>     Message-ID:  <[email-masked]>
> 
>   | I think in the end this is an argument about nothing. 
> 
> I think I agree with that.
> 
>   | > This implies that IPv6 nodes SHOULD NOT establish any 
> flow-specific
>   | > state unless so instructed by a specific flow state 
> establishment method. 
>   | 
>   | What Margaret and itojun refer to are flow state 
> establishment methods that
>   | happen to consist of algorithms built into the sending 
> node (rather than
>   | signaling mechanisms or pre-configured flow states).  
> These algorithms
>   | must avoid duplicate labels, just as signaled or pre-configured
>   | methods must. 
> 
> Yes, when you consider only the source nodes.   There the method you
> describe is correct, and the concerns expressed aren't a problem.
> The wording could perhaps be improved to make that clear.
> 
> But...
> 
>   | So the sentence is in fact a no-op and can be deleted.
> 
> I don't agree with that - I read the relevant sentence as 
> being directed
> at intermediate nodes (routers), not at the end nodes 
> (hosts).   That is,
> I thought that it was trying to say that routers should not 
> just "notice"
> that there seems to be a flow passing by, and attempt to do 
> magic things
> to that flow, because there's no way to flush the state they 
> establish to
> do that.   That is, there needs to be some kind of setup 
> mechanism (anything
> from RSVP to an RFC) that defines just how the flows are 
> established, and
> when they should be torn down again.
> 
> Don't delete it, just make its scope clearer.
> 
> kre
> 
> 

--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Mon, 05 Aug 2002 20:19:44 +0700

Date:        Mon, 5 Aug 2002 09:53:49 +0300
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | any suggestions on how to make the text clearer about this?

[email-masked] said:
  |  Send text. 

Me and my big keyboard...

Well..

   The method by which the flow state is cleared from the IPv6 nodes is
   to be defined by the flow state establishment method used to set up
   the state.

That's fine.

   This implies that IPv6 nodes SHOULD NOT establish any
   flow-specific state unless so instructed by a specific flow state
   establishment method.

That's fine too, provided that you assume that the reader has actually
read the definitions, and noticed:

   Flow state             A control mechanism used to set up the flow
   establishment method   state. A flow state establishment method can
                          be either
                          - Dynamic, under source or destination node
                          control (e.g. RSVP),
                          - Quasi-dynamic, under network management
                          control,
                          - Static, through manual configuration, or
                          - Algorithmic (e.g. load spreading)

(grammar nit: I don't think "either" is correct to describe a choice
among more than 2 things, make it "any of").

The problem is that many simply assume that they know what all the words
mean, and treat the definitions section, like acknowledgments, and
security considerations, as something of no relevance, and skip it.

So, perhaps add

	In particular, nodes should not simply react to observing
	the flow labels of traffic passing through.  This is not
	a flow state establishment method, and, in particular, gives no
	hint as to when packets may now be part of a different flow than
	previous packets similarly labeled.

The rest ...

   With some flow state establishment methods,
   signaling new state simultaneously clearing the old state from the
   new path may be sufficient. A mechanism with a sufficiently long
   timeout period before reusing the Flow Label values can also be used.

is also OK, that's just hints to flow state setup types (ie: working
groups and the link) as to what they might like to define in their protocols.

kre