Subject: Re: Flow Label

From: Scott Bradner <[email-masked]>
Date: Mon, 24 Dec 2001 19:49:01 -0500 (EST)

I've been watching the discussion over the IPv6 flow label for a while
and (like Perry) have yet to see anything I woukd call a real reason
to be doing anything with it - specifically I've seen no vendors say what 
specific use they would put a FL to.

I find it hard to see why so much time is being spent on this other
than the fear that idle bits are the devil's playground - i.e. the
fear of unassigned bits in the header - I'd rather wait until 
we are real sure that 1/ there is one or more use(s) for the FL that
consensus can be reached on, 2/ have some understanding on what the  FL
characteristics are for those uses

Over the last few years I have seen suggestions ranging from the original
idea of ofloading router forwarding engines (hard to justify in an era
of ASIC-based and network processor-based forwarders, to an ID for the
owner of the content of a packet, to QoS lables (which are hard to
diferentiate from difserv code points in teh real world), to billing
information.  None of these have presented a compelling reason to think
that we understand any FL use well enough to define anything now.

ymmv

Scott
--------------------------------------------------------------------
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: "Subrata Goswami" <[email-masked]>
Date: Mon, 24 Dec 2001 20:27:00 -0800

i guess the flow  bits should officially be reserved.

subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Scott Bradner
Sent: Monday, December 24, 2001 4:49 PM
To: [email-masked]
Subject: Re: Flow Label

ymmv

Scott

---

From: "Perry E. Metzger" <[email-masked]>
Date: 25 Dec 2001 08:47:24 -0500

> i guess the flow  bits should officially be reserved.

My personal taste is that we rename the field "Reserved -- must be
zero" so that people quit coming up with proposals just because, as
one person at Salt Lake City put it, "it is embarrassing that we have a
flow label field but nothing uses it so we should come up with a use"
(one of the most frightening things I've ever heard at an IETF meeting.)

Perry
--
Perry E. Metzger		[email-masked]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Tue, 25 Dec 2001 19:16:23 -0500

>(one of the most frightening things I've ever heard at an IETF meeting.)

I agree with this approach.

I also agree with Perry's statements regarding IPv6 deployment.

IPv6 is already deployed in a large number of systems, and if
things go well, it will be deployed (and used!) in an even
larger number of systems within the next two years.  We need
to stop making experimental changes, finish up our existing
specs and get IPv6 ready for prime time.

Margaret

---

From: "James Kempf" <[email-masked]>
Date: Wed, 26 Dec 2001 09:38:19 -0800

Scott,

The most compelling application I've seen is
for QoS classification when the packet
is encrypted. Most of the other applications
people have cited can probably be handled
by other means, as you point out.

            jak

---

From: "Perry E. Metzger" <[email-masked]>
Date: 26 Dec 2001 13:01:07 -0500

> by other means, as you point out.

Can't we do classification by expressing the traffic type in the
"traffic" field in the encapsulating packet, however?

.pm

---

From: "James Kempf" <[email-masked]>
Date: Wed, 26 Dec 2001 10:25:34 -0800

> "traffic" field in the encapsulating packet, however?

The traffic field gives the classification. The flow label
could serve as a proxy for the port number and
protocol type, according to my understanding of the proposal
to define the flow label field. The traffic field can change when 
the packet goes from one provider's network
to another, depending on the type of QoS deployed by the
provider within their network, the flow label would presumably be used
to determine what traffic classification to use when
the packet is being reclassified since
the flow label is being defined to be immutable. If the
packet is not encrypted, the port number and protocol
type can be read directly, of course.

From a service provider's perspective, it would
be very advatageous to have some way of
assuring QoS classification of encrypted traffic,
since it would greatly reduce the anxiety involved
in peering of voice traffic. This anxiety
seems unreasonable from an engineering
perspective (at least, I find it so), but 
perhaps understandable from a business
perspective.

            jak

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Dec 2001 17:31:29 -0500

> flow label field but nothing uses it so we should come up with a use"

if we do this, please say that:

hosts sending packets must fill the field with zero 
receiving hosts must ignore the field
forwarding engines must leave the field unchanged

else, it will never be possible to use those bits in a standard because
somebody will have already used them.
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 12:02:54 +0100

Margaret Wasserman wrote:
...
> specs and get IPv6 ready for prime time.

And our existing specs contain a big hole: the sloppy text about 
the flow label. That's why this discussion started
(see Jochen Metzler's message of November 15, 2000).

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 13:13:54 +0100

Sometimes, not always. See RFC 2983.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Dec 2001 13:55:34 +0100

Scott,

> specific use they would put a FL to.

I have discussed the flow label with product designers. They are ignoring 
it because the words in RFC 2460 are fuzzy. Yet the IESG has approved 
two standards track documents (RFC 2205 and the diffserv MIB) with 
specific uses for the flow label in support of the IETF's two QOS 
solutions.

We've inadvertently set up a situation where no vendor is going
to speak up.

> fear of unassigned bits in the header - 

A number of us believe that the above fuzziness and inconsistency
needs to be resolved, one way or the other.

> I'd rather wait until
> consensus can be reached on, 

As noted, we've already standardised two...

> 2/ have some understanding on what the  FL

afaik this is the case: locally unique, immutable, and (for intserv)
IANA-assigned as per RFC 3140.

> that we understand any FL use well enough to define anything now.

Disagree. The QOS usages are clear and well-defined. The others are all
pretty dumb.

    Brian

---

From: "James Kempf" <[email-masked]>
Date: Thu, 27 Dec 2001 09:34:54 -0800

Brian,

Comments embedded.

> We've inadvertently set up a situation where no vendor is going

I don't claim to speak for DoCoMo (not a vendor
but a service provider anyway), but I do feel there is value in
precisely
defining the flow label. That IETF standardized usage of the flow label
prior
to actually defining its semantics precisely seems kind of
curious in any event. The alternatives seem to be either define
the semantics consistent with the already standardized usage or
not. Since the fact that there are standards on the
usage seems to indicate that at some point the WGs
involved and the IESG felt that there was some value
in having the semantics be other than "reserved",
it would seem to me to be worthwhile to continue
in that vein, unless there is some major argument
for shifting direction. I've been peripherially following
the flow label discussion since Jochem's original
email, but I've not yet seen any major argument
for shifting direction, though there have been
some good points brought up about deficiencies
in the current proposal for defining the flow label.

> needs to be resolved, one way or the other.

Agreed.

> Disagree. The QOS usages are clear and well-defined. The others are
all

I have not looked at 2205 or the diffsrv MIB, but if the IANA
standardized
values you mentioned are independent of protocol and port number, then
this would be one way to mitigate the point Scott brought up about
the transited network being able to deduce the character of the
traffic even if the packet was encrypted, which I view as a potential
flaw in using the flow label for classifying encrypted traffic. As one
of your previous
postings indicated, getting agreement on values for the traffic
class field would probably be harder, but perhaps under the
pressure of necessity (if the flow field were defined as reserved)
it might evolve.

I hope we can achieve concensus for the current proposal,
and favor it, but if we cannot, then I believe we should
define the flow label as reserved, and reissue the two
specifications that assign usages of the flow label.

            jak

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Dec 2001 11:05:13 -0800

> That IETF standardized usage of the flow label prior to actually
> defining its semantics precisely seems kind of curious in any event.

<rant>

it's commonly called 'second system syndrome' which often produces a
lot of ill defined and not demonstrably necessary 'features'

randy

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Dec 2001 17:47:19 +0700

Date:        Thu, 27 Dec 2001 11:05:13 -0800
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | it's commonly called 'second system syndrome' which often produces a
  | lot of ill defined and not demonstrably necessary 'features'

That's what IPv6 has deleted out of IPv4 .. NCP was the first system...

kre