Le 10 sept. 2010 à 21:02, Fernando Gont a écrit : > Hi, Rémi, > >>> As for keeping track of flows, as I've just noted to Steven, this >>> is a refinement. But you could probably live assuming that all >>> flows terminate in a period equal to the duration of the flow label >>> space (i.e., when the flowlabel space wraps and you'd reuse a >>> flowlabel value, the flow that was previously using that FL value >>> has already terminated) >>> >>> While I've assumed that RFC3697 holds when wrote draft-gont, FL >>> immutability is not a requirement for the algorithm to work. >> >> Note that my proposal doesn't exclude stateful algorithms (no >> objection to yours in particular). It just authorizes stateless >> algorithms provided they are adequate for the load-balancing purpose. >> > I just wanted to clarify that the algorithm doesn't need additional > state (as sometimes "state" at layer-3 is deemed as a show-stopper :-) ) > > > >>>> R1. Packet sources SHOULD set FLs to non-zero values that >>>> generally differ from a flow to another (e.g. with currently >>>> specified stateful algorithms, or with n-tuple hashes). >>>> >>>> R2. Packet sources MUST set FLs to zero otherwise. >>>> >>>> R3. Intermediate nodes MAY replace null FL values by non-zero FL >>>> values, PROVIDED these non-zero values generally differ from a >>>> flow to another. >>>> >>>> R4. Intermediate nodes MAY replace non-zero FL values by non-zero >>>> FL values, PROVIDED these non-zero values generally differ from a >>>> flow to another. >>>> >>>> R5. Intermediate nodes MAY replace non-zero FL values by null >>>> values ONLY IF found necessary for some identified >>>> policy-dependent security reason (e.g. in some managed >>>> firewalls). >>> I'd make R3 through R5 a "SHOULD NOT.... but if you do, do it this >>> way". -- but could certainly with your "MAY", as stated. >> >> About R3: If part of a network has the ability to identify 5-tuples >> and to compute FLs, replacing null FLs by non-zero FLs seems to me a >> completely acceptable choice. > > As I said, IMHO your "MAY" is acceptable.
> -- BTW, in R3 omit the > "generally" ;-) "Generally" conveys the point that collisions are acceptable provided they are rare enough. In my understanding, it has to apply in the same way in R1, R3, and R4. "Generally differ from a flow to another" was intended to mean "differ from a flow to another with a good probability" (collisions are permitted, but only with a low probability). If the substance is agreed, this should be made clear in resulting drafts. > > > >> About R4: If part of a network has the ability to identify 5-tuples >> and to compute good FLs, and has no confidence in upstream provided >> FLs, I see no objection to its replacing old FLs by supposedly better >> ones for its own load balancing (and, by the same token, for that of >> downstream networks that use upstream FLs). > > Same as above. > > > >> About R5: I agree that SHOULD NOT would be better, with no objection >> to adding "unless found strictly necessary..." > > I guess that if we make the above "MAY"s, this one could be a MAY, too. > > > >>>> R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero >>>> FLs encapsulated packets in encapsulating packets. >>>> >>>> R7. Nodes that tunnel flow aggregates SHOULD set FLs of >>>> encapsulating packets that contain null FLs to a value that >>>> characterize the tunnel itself, and MUST set it to 0 otherwise. >>> Will give these last two another thought. >> >> Look forward to it. > > I'd probably specify these last two in a different document, aimed at > tunnels. I confirm that, despite my preference for a single document, I have no serious objection to 2 documents as proposed by Brian. > However, I'd not that R6 and R7 seem to lead to inconsistency: according > to R6, the tunnel's FL reflects what's being transferred over the > tunnel. According to R7, the tunnel's FL characterizes the tunnel itself. I see. R7 could be made clearer with something like: "R7 encapsulating packets that contain null-FL packets to a value that characterize the tunnel itself for flows of the aggregate that are not individually identified, and if they don't MUST set these FLs to 0. Thanks? Best regards, RD > Will give these last two another thought. > > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: ferna...@gont.com.ar || fg...@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
