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]
> > > --------------------------------------------------------------------
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 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 PROTECTED]
> --------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
