Subject: RE: Flow label draft issues & new text

From: [email-masked]
Date: Tue, 13 Aug 2002 20:25:17 +0300

kre,

How about this (changes in the second sentence):

"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. This implies that IPv6 nodes unable to classify a packet to an existing flow SHOULD NOT establish any flow-specific state unless so instructed by a flow state establishment method. 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."

I also fixed the grammar nit you pointed out, thanks.

	Jarno

> -----Original Message-----
> From: ext Robert Elz [mailto:[email-masked]]
> Sent: 5. elokuuta 2002 16:20
> To: Rajahalme Jarno (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: Flow label draft issues & new text 
> 
> 
>     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
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Wed, 14 Aug 2002 14:19:09 +0700

Date:        Tue, 13 Aug 2002 20:25:17 +0300
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | How about this (changes in the second sentence):

Looks OK to me.   But I understood what it meant the first time, so
I'm perhaps not the best judge...   Do those who thought that the
text perviously meant that nodes couldn't label packets they were
originating still read that into this version?   (Margaret, itojun .... ?)

kre

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Aug 2002 10:39:45 -0400

> "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. This implies that IPv6 nodes unable to classify a
> packet to an existing flow SHOULD NOT establish any flow-specific
> state unless so instructed by a flow state establishment
> method. 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."

How does the above text relate to the idea (which I thought the WG was
interested in) in allowing the Flow Label field to be used for load
balancing (i.e., hash the src/dest/label to select the next-hop when
there are more than one). Seems like load balancing might not be
allowed by the above wording. Is that the intent?

Note in the case of simple load balancing, there is no flow state
establishment method.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Aug 2002 17:50:41 +0200

It's a matter of interpretation (you could ask the same question
about some ways of using the flow label for diffserv classification).

In my interpretation, a server load balancing mechanism that recognizes
and caches new labels is a flow state establishment method.

   Brian

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Aug 2002 14:05:30 -0400

> about some ways of using the flow label for diffserv

It would be far better if different readers didn't have to think too
hard about this. General comment. IMO, what is needed is a very short
and simple specification that says exactly what hosts (and routers)
are supposed to implement today. And *nothing* more. In particular, no
weasle wording that requires laywerish reading of the text to decide
what the intent is or what may or may not be allowed in the future.

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Aug 2002 11:19:17 +0200

Thomas Narten wrote:
> are supposed to implement today. And *nothing* more. 

That is what it is supposed to be. I'm particularly concerned that
people building hardware classifiers should know what to do.

> In particular, no

It is not supposed to be weasel words. It's supposed to be a minimal
set of conditions. Personally, I was quite happy with the -02 version,
but I don't think any of the recent changes are harmful.

  Brian

---

From: Robert Elz <[email-masked]>
Date: Thu, 22 Aug 2002 19:47:37 +0700

Date:        Wed, 21 Aug 2002 14:05:30 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

[quoting Brian]
  | > It's a matter of interpretation (you could ask the same question
  | > about some ways of using the flow label for diffserv
  | > classification).

Actually, my take would be that what the text is attempting to restrict
is the forming of state - not using the flow label.   So, using (a hash of)
the flow label for choosing among alternate equivalent routes would be
just fine - as no state is being left behind when that's done.   The issue
is creating some kind of state (memory if you like) when there's no defined
way to delete it.

  | It would be far better if different readers didn't have to think too
  | hard about this.

True.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Aug 2002 16:11:25 +0200

> is creating some kind of state (memory if you like) when there's no defined

Well yes, although I've not been sure from the start of this discussion
why that is any business of *this* working group. Worrying about that
really belongs to whatever WG standardizes a specific use of the label.
All we need to do, imho, is establish the appropriate boundary
conditions, and that is what the current text aims to do.

    Brian

---

From: Robert Elz <[email-masked]>
Date: Fri, 23 Aug 2002 14:49:00 +0700

Date:        Thu, 22 Aug 2002 16:11:25 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Well yes, although I've not been sure from the start of this discussion
  | why that is any business of *this* working group.

Even before I deleted your quote from my earlier message, I wasn't sure
what the "that" which shouldn't be this WG's business was supposed to be.

Once again, as I understand it, the point is to prevent nodes from
gathering state about flows that they have no setup/protocol/definition
of (which is needed, because there's no way to flush that).

A rule like this, one which applies in the absence of any flow setup,
can't really go in some flow specification doc, can it?   So, it can't
really be specified by diffserv, intserv, mpls, or anyone else who may
have an interest in the flow label.

They can specify how to use it when the protocol they define is being
used, but they can't really specify how to not use it when it isn't.
That is, you wouldn't want intserv telling diffserv that the flow label
can't be used like foobar, would you?

The general prohibition needs to be in the general flow label spec.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Aug 2002 13:09:59 +0200

> The general prohibition needs to be in the general flow label spec.

To be clear, I'm not objecting to the proposed text, because I think it's
harmless (i.e. it doesn't appear to prevent any of the uses of
the flow label that seem likely to get standardised in future). And it's
good advice (because an implementation that ignores it may get
unpredictable results). But I have a little difficulty in seeing
it as effective use of virtual ink.

However my real concern right now is to avoid continuing to
embellish the draft, because I'm afraid of it becoming restrictive.

   Brian