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