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.
> 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 ;-)
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
--------------------------------------------------------------------
