Le 10 sept. 2010 à 22:35, Brian E Carpenter a écrit : > On 2010-09-10 20:21, Rémi Després wrote: >> Le 9 sept. 2010 à 23:51, Brian E Carpenter a écrit : >> >>> Rémi, >>> >>> This is quite similar to one possible version of >>> draft-carpenter-6man-flow-update-04 that is spinning >>> around on my hard disk. But I really want to get clarity >>> (if not rough consensus) on the immutability thread before >>> being certain what we should propose. >> >> It certainly makes sense before issuing the new version. >> The idea is to try and identify clearly which consensus we talk about. >> For this, a succinct expression of what we plan to get at the end, like the >> proposed R1 to R7, is intended to be helpful. > > The slight problem with that is until you analyse the implications > of each rule, and write it in RFC 2119 language, you can't be sure > that there is no inconsistency or indeterminancy.
Agreed, the check is necessary. We will have to do it. >> BTW, would you be personally satisfied if R1-R7 would reflect the final >> consensus? > > Oh, I will be personally satisfied if we ever reach rough consensus on > any solution ;-) Then, it's a yes, but without an expressed personal preference.` IMHO, the consensus is easier to detect if some preferences are expressed by those who care. Best regards, RD > > Brian > >> >>> I think the rules about tunnels should be completely separate, >>> and they are really the subject of the other draft, >>> draft-carpenter-flow-ecmp-02. >> >> Having all the FL information in one draft is IMHO more reader friendly, but >> I have no serious objection to the 2-draft approach that you seem to prefer. >> >> RD >> >>> On 2010-09-10 00:09, Rémi Després wrote: >>>> ... >>>> >>>> The best combination I personally get, considering past discussions on a >>>> potential RFC-3697 revision, is so far as follows: >>>> >>>> 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). >>>> >>>> R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero FLs of >>>> 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. >>>> >>>> NOTE: Since most packets of a fragmented TCP datagram don't contain ports >>>> that identify the 5-tuple of their flow, computing new non-zero FL values >>>> implies operation at the datagram layer. >> >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
