Subject: RE: a), b), c), d), or e)

From: "Christian Huitema" <[email-masked]>
Date: Mon, 27 Aug 2001 15:43:47 -0700

> >          0                   1
> >          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |0|       Pseudo-Random Value           |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >          0                   1
> >          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >         |1|     Diffserv IPv6 Flow Label        |
> >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Could we be a bit parcimonious and reserve a couple of header bits "for
further use"? We don't seem to have a level of consensus in the group
that people can guarantee that either a bunch of random bits, or a
diffserv flow label, are absolutely the best thing since sliced bread.
Not at the same level as the payload type or payload length, in any
case.  It would be nice to be able to invent something like ECN in
2010...

Maybe we could make it something like 4 bits of "label type" and 16 bits
of label value, defining then the possibilities for "0-0", "0-random"
and "1-diffserv" -- whatever that means.

-- Christian Huitema
--------------------------------------------------------------------
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: Tue, 28 Aug 2001 08:46:45 -0500

Christian,

In fact the diffserv requirement is for a 16 bit field, so we could
adopt:

          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |1 0 0 0|   Diffserv IPv6 Flow Label    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

or something similar, to conserve bits.

    Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

"We shall need a number of efficient librarian types 
 to keep us in order." - Alan Turing, 1947.
--------------------------------------------------------------------
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: Tue, 28 Aug 2001 10:03:18 -0500

How would people feel about this encoding for the flow label
(deemed to be immutable end to end)?

          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |0|     Per-microflow unique value      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          0                   1
         |1|     Non-unique value                |

I'm not yet 100% convinced that the second case is sufficient for
diffserv, but at least it would be a more generic approach
than reserving half the space for diffserv.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 28 Aug 2001 21:23:20 +0300 (EEST)

> In fact the diffserv requirement is for a 16 bit field, so we could

I support this, but for different reasons.  IPv6 base header has _way_ too
few "reserved" bits (none), and this would get us 3.  It's arrogant to
believe we might not find use for them in the future.

(you could always define extension headers to do the thing, but it might
be good to reserve some space for enhancements-to-be in the primary header
too).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Aug 2001 16:07:45 -0500

So would you prefer the choice of redefining the flow label
as a "reserved, must be zero" field?

  Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Aug 2001 00:28:17 +0300 (EEST)

> as a "reserved, must be zero" field?

Yes, at least partially.

---

From: Jim Bound <[email-masked]>
Date: Fri, 31 Aug 2001 12:19:58 -0400 (EDT)

Brian et al,

A lot of mail but lots of it are repeating.  The only way my change in
vote for "c" will work is if we do this below per Brian.  But I presented
this case in front of the IETF WG at Minneapolis and folks did not want to
go there and Steve presented good counter arguments to doing it.  It is a
compromise to do the below.

A few statements:

Immutable field:  I agree with Tony 100% if we have a per microflow it
should be immutable for that option and I  mean in the strongest sense
that it is read-only.  I will not post my reasons again but they are in
line with Tony and also that I am not comfortable saying nodes along the
path will return the field to its former value.  AT ALL.......Causing bugs
with per microflows for apps that depend on it is something I could never
support and to trust the edge and core with that without how its to be
done is a bit of a stretch for me and I think for any IETF specifications
sound protocol effect on networks.  Immutable field is the quickest way to
standards track I would argue for per micro-flows.  In the future after
some practical experience that could be re-discussed.

MF Classifiers: We should solve this problem so that all classification is
done only at the header.  The multiple tuple value for classification
beyond the header in Diffserv architecture was a huge mistake to put in
the model and having boxes look at L4+ values is bordering absurdity IMO.

IETF Rants we need to support QOS other standards:  This is simply bogus
logic.  As Bob said the place to change our rules is in POISED not IPng.
If Diffserv made a mistake or neglected to deal with cases like IPsec that
does not mean IPv6 WG MUST support fixes to make it work.  That is the
bogus logic.  It assumes a rule for us in IPv6 WG which DOES NOT EXIST.
Arguing it may be the right thing to do is fair.  I don't agree though.

Are we getting anywhere?  After working on this for many years I feel NO.
The bottom line is can the IPv6 WG agree to the attached compromise in
some form?  That should be the first thing we have to agree on or Thomas
is correct we need to just leave it alone for awhile till we can get
consensus.  We don't have it now IMO.

Should we use the flow for other than QOS?  I think that is a wise vision.
But then we need some kind of compromise for that too.

/jim