Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label]

From: "Jim Fleming" <[email-masked]>
Date: Wed, 2 Jan 2002 08:36:34 -0800

These are four interesting words:

restores
uncertainty
preventing
usage

Restores implies that something used to be some way
and it is now restored to be that way. That is not the case
with technology very few people use. As for uncertainty,
there does not seem to be any uncertainty when one looks
at working code. Fortunately, people writing code and
compiling their own operating systems are not prevented
from using any data structure the way they want. When a
large number of people start doing things in a similar manner
a standard emerges. It seems unlikely that people could
decide in advance what the standards will be and impose
those on the population.

Regarding the 20-bit Flow Label, in the bloated 40 byte
IPv6 Header, one approach may be to divide the Flow
Label into a 4-bit Length Field, an 8-bit StarGate and an
8-bit Identification Field similar to IPv4. The 4-bit Length
Field can then be used to define the number of bytes of
data carried in the useless, right-most, 64-bits of the IPv6
128-bit Address Fields. Those fields used to have MAC
addresses but now some claim they have random numbers.
The Protocol Field could of course further define the one
to sixteen bytes of data carried directly in the IPv6 header.
While 16 bytes be small for protocols involving huge files,
streaming protocols and other object-oriented applications
may find that 16 bytes is a nice size, and they could use
the IPv6 header more efficiently.

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Alex Conta" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 02, 2002 4:29 AM
Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label]

> Alex,
>
> I don't agree. This restores the uncertainty that is preventing any
> current usage.
>
>    Brian
>
> Alex Conta wrote:
> >
> > Making the field "immutable" by "default", but "mutable" when a router
> > is so instructed by a flow setup and flow processing mechanism is a
> > compromise that would satisfy all current and future possible cases.
> >
> > Therefore I think last sentence of the first paragraph
> >
> >     All routers MUST pass the field on unchanged when forwarding a
> > packet.
> >
> > should be something like:
> >
> >     All routers MUST leave the field unchanged, by default, when
> > forwarding a packet.
> >     A specific flow setup/processing mechanism MAY give a "mutable"
> > character to the field,
> >     by requesting routers, supporting the mechanism, to change the field
> > in certain ways.
> >     Routers supporting such a mechanism MUST follow the steps indicated
> > by the flow
> >     setup and flow processing mechanism.
> >
> > Alex
> >
> > Brian E Carpenter wrote:
> > >
> > > Taking Scott's suggestion, here's another try:
> > >
> > > I'd like to propose the following as the
> > > complete and total replacement of Section 6 of RFC 2460.
> > >
> > >    The 20-bit Flow Label field in the IPv6 header MAY be set by a
> > >    source to uniquely label sets of packets. Nodes that do not support
> > >    the Flow Label field MUST set the field to zero when originating a
> > >    packet, and MUST ignore the field when receiving a packet. All
routers
> > >    MUST pass the field on unchanged when forwarding a packet.
> > >
> > >    This specification does not further define the meaning of the
> > >    Flow Label.
> > >
> > >  [and delete Appendix A, which is unhelpful.]
> > >
> > >        Brian
> > > --------------------------------------------------------------------
> > > 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]
> > > --------------------------------------------------------------------
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
> On assignment at the IBM Zurich Laboratory, Switzerland
> Board Chairman, Internet Society http://www.isoc.org
>
>
> --------------------------------------------------------------------
> 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: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Jan 2002 13:29:43 +0100

Alex,

   Brian

Alex Conta wrote:
> >    packet, and MUST ignore the field when receiving a packet. All routers

---

From: Alex Conta <[email-masked]>
Date: Wed, 02 Jan 2002 16:13:28 -0500

Brian,

Let's take one simple example:

**begin of example

let's consider three neighboring routers: R1, R2, R3, forwarding one
flow, characterized by
src=a, dst=b, flow-label=10000, from R1 to R2, to R3. 

Input interfaces are I1 (on R1), I2 (on R2), I3 (on R3). 
Output interfaces are O1(R1), O2(R2), O3(R3). 

    flow--->I1[R1]O1--->I2[R2]O2--->I3[R3]O3--->flow

If for R2's I2's classification engine, flow label value 10, is
significantloy better than 10000, R2 could notify R1, to change the
value 10000 to 10, when forwarding the flow on interface O1 towards I2.
R2 would also remember that on forwarding the flow internally from I2 to
O2, it has to restore the value to 10000. Consequetly, R2 would classify
the flow on I2, with value 10 instead of 10000, and forward it further
on O2 after changing the value 10 to value 10000. The flow would arrive
to R3 through I3, with flow label value 10000. 

**end of example.

How is the mutability used by R1, and R2, affect R3 which is not part of
the signaling between R1, and R2? It does not!

There are cases in which network (forwarding) devices are the best to
know what are the most optimum values for the flow label field. An
adequate flow setup mechanism can take care of any local flow label
value modification, and in the same time, restore flow label values to
eliminate the effects on the rest of the network.  

How would you ensure that such devices can maximize their potential, if
you do not leave any window of flexibility?

Regards,
Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Jan 2002 16:10:53 +0100

Alex,

What you describe is the argument for the mutability of
DSCPs (plus the need for out of band magic to restore
the original value). I just don't see a win in having the
same property, and resultant complexity, in the flow label
as well.

   Brian

---

From: "Jim Fleming" <[email-masked]>
Date: Thu, 3 Jan 2002 10:30:22 -0800

This all sounds very abstract, is there any working code ?

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Alex Conta" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 03, 2002 7:10 AM
Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label]

routers