Re: [v6ops] 答复: FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

[Brian E Carpenter <[e-mail]>]

On 09/11/2017 07:16, joel jaeggli wrote:
> On 11/8/17 09:25, Tom Herbert wrote:
>> On Wed, Nov 8, 2017 at 8:16 AM, joel jaeggli <[e-mail]> wrote:
>>> On 11/8/17 07:33, Tom Herbert wrote:
>>>> On Tue, Nov 7, 2017 at 11:57 PM, Xuxiaohu <[e-mail]> wrote:
>>>>>
>>>>>
>>>>>> -----邮件原件-----
>>>>>> 发件人: v6ops [mailto:[e-mail]] 代表 Van De Velde, Gunter
>>>>>> (Nokia - BE/Antwerp)
>>>>>> 发送时间: 2017年11月8日 4:37
>>>>>> 收件人: Tom Herbert
>>>>>> 抄送: [e-mail]
>>>>>> 主题: Re: [v6ops] FW: New Version Notification for
>>>>>> draft-fioccola-spring-flow-label-alt-mark-01.txt
>>>>>>
>>>>>> In this case, the controlled domain reflects to the fact that it is operator choice
>>>>>> that grabs control of packet handling within its own network.
>>>>>> The operator adds through policy the outer SRv6 header. The operator has in
>>>>>> fact then three options regarding flow label:
>>>>>>
>>>>>> 1) Just do not do anything with Flow-label (leave it default)
>>>>>> 2) Alternate marking only and NO usage of entropy
>>>>>> 3) Alternate marking and entropy (in this case the entropy SHOULD be based
>>>>>> upon 18 bits instead of 20 bits because otherwise paths may be changed when
>>>>>> the marking changes (e.g. periods of 5 minutes per marking period) …. This is
>>>>>> however not a MUST because some operators do not care if because of marking
>>>>>> change.
>>>>>
>>>>> In option 3, it would require a few changes to the RFC6437-compatible behaviors of intermediate routers within a controlled network domain. Hence it seems better and safer to disable the FL-based load-balancing mechanism in this special case, especially when the existing load-balancing mechanism (e.g., five-tuple-based LB) is good enough, IMHO.
>>>>>
>>>> Five-tuple hash requires parsing into the transport layer to get the
>>>> ports. In the proposed use case there will be extension headers (at
>>>> least a routing header) so routers would need to parse over those.
>>>> It's unlikely that such parsing is consistently implemented and
>>>> besides that the whole point of using the flow label for ECMP is to
>>>> obviate the need for routers to perform DPI.
>>>
>>> The flow label is unprotected in the header which makes it hard to use
>>> to hash to stateful endpoints. it would be helpful if nothng ever
>>> changed it or did so consistently but in fact devices that do so exist.
>>>
>> Joel,
>>
>> The problem isn't at stateful endpoints, it's with middleboxes that
>> maintain flow state. The result of a flow label change at an endpoint
>> is OOO packets which any transport protocol is expected to gracefully
>> handle. A middlebox that maintains state expects all packets of the
>> flow to got through it, so if there is a flow label change (or other
>> routing change) packets for the flow may bypass the device (like a
>> firewall or NAT) with the flow state. It's likely they're forwarded
>> through a peer device that doesn't have any state for the flow and so
>> dropped packets ensue.
>>
>> This has created an implicit requirement on network architecture that
>> all packets of a flow need to follow the same path. From a host
>> perspective there are good reasons to change the flow label, for
>> instance we can modulate the the flow label for a failing connection
>> as a form of source routing to try for a better route through the
>> network. However, from a practical perspective I suppose the
>> recommendation should be that by default the flow label should be
>> constant for the lifetime of the flow.
> 
> 6437 says
> 
>    Once set to a non-zero value, the Flow Label is expected to be
>    delivered unchanged to the destination node(s).  A forwarding node
>    MUST either leave a non-zero flow label value unchanged or change it
>    only for compelling operational security reasons as described in
>    Section 6.1.
> 
> Disgusting get out of jail-free card not-withstanding that's
> unequivical. If It changes I cannnot use it for hashing in my load
> balancer function.

Sure. But if a local domain chooses to restrict itself to hashing
18 bits that's its privilege; we don't specify the hash algorithm.
And if the packet is forwarded outside the local domain, the other
two bits need to be set to consistent values for use on the outside.
I think the draft meets those conditions.

   Brian