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 PROTECTED]>
To: "Alex Conta" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, January 03, 2002 7:10 AM
Subject: Re: Proposed update to RFC 2460 [was Re: Flow Label]


> 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
>
> Alex Conta wrote:
> >
> > 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
> >
> > Brian E Carpenter wrote:
> > >
> > > 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 PROTECTED]
> --------------------------------------------------------------------

--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to