RE: draft-wang-6man-flow-label-reflection

"Aijun Wang" <wangaijun@tsinghua.org.cn> Mon, 17 November 2014 01:10 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769F71A001B for <ipv6@ietfa.amsl.com>; Sun, 16 Nov 2014 17:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.76
X-Spam-Level: **
X-Spam-Status: No, score=2.76 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HOST_MISMATCH_COM=0.311, MIME_CHARSET_FARAWAY=2.45] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKdyDag7zQzC for <ipv6@ietfa.amsl.com>; Sun, 16 Nov 2014 17:10:28 -0800 (PST)
Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 030431A0015 for <ipv6@ietf.org>; Sun, 16 Nov 2014 17:10:25 -0800 (PST)
Received: from ctbriwangaij (unknown [219.142.69.77]) by app1 (Coremail) with SMTP id Z0GX06BrhgDzOGlUGJA5AA==.57939S4; Mon, 17 Nov 2014 07:53:41 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Jeroen Massar' <jeroen@massar.ch>, 'Sheng Jiang' <jiangsheng@huawei.com>, '6man WG' <ipv6@ietf.org>
References: <5465C0AC.10801@massar.ch> <5D36713D8A4E7348A7E10DF7437A4B923AF75421@nkgeml512-mbx.china.huawei.com>, <546681A0.9070703@massar.ch> <5D36713D8A4E7348A7E10DF7437A4B923AF75695@nkgeml512-mbx.china.huawei.com> <5466928E.6070800@massar.ch> <008801d00070$580df030$0829d090$@org.cn> <5466BFB0.303@massar.ch>
In-Reply-To: <5466BFB0.303@massar.ch>
Subject: RE: draft-wang-6man-flow-label-reflection
Date: Mon, 17 Nov 2014 09:10:05 +0800
Message-ID: <008601d00203$4175c8e0$c4615aa0$@org.cn>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0087_01D00246.4F9908E0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdAAdKBWPSvcVClySEO/wSQoJbi4xwAQMR6w
Content-Language: zh-cn
X-CM-TRANSID: Z0GX06BrhgDzOGlUGJA5AA==.57939S4
X-Coremail-Antispam: 1U3129KBjvJXoWxur1UKryrur1DCryrCFyUKFg_yoW5Wry3pa yYg3s7K3Z3JFy3C34kJw40gFyFv3yrJr47AryDKa1Iy3s8CF1YqFnxK3y3urWDCFZ7Wa90 vrZIvFs8u3ZxZaDanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjPqb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwASzI0EjI02j7AqF2xKxwAv7VCjz4 8v1sIEY20_GF1lx4CE17CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/00yfAAjUh-R6-kOrnxeMhXO4AXc
X-Mailman-Approved-At: Sun, 16 Nov 2014 23:33:53 -0800
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 01:10:33 -0000

Hi, Jeroen

Please see the reply inline below.

> -----Original Message-----
> From: Jeroen Massar [mailto:jeroen@massar.ch]
> Sent: Saturday, November 15, 2014 10:51 AM
> To: Aijun Wang; 'Sheng Jiang'; '6man WG'
> Subject: Re: draft-wang-6man-flow-label-reflection
> 
> On 2014-11-15 02:05, Aijun Wang wrote:
> > Hi, Jeroen:
> >
> > Service Provider wants to apply the same policy to the upstream and
> > downstream of one session, or more accurately, apply the policy to
> > downstream of one session based on the recognition of it upstream
packet.
> >
> > The flow label can be used to identify the unique session between one
> > pair of IPv6 hosts, and alleviate the burden for the network device to
> > recognize the downstream packet, for example, http response packet. We
> > think this is one appropriate use case for the flow label.
> 
> The Flow Label as defined tells you nothing about the contents of the
flow.
> Hence nothing to prioritise on there. You will still have to look at the
typical five
> tuple and likely deeper when everything is just going to look like HTTP.
> 
【Aijun】: with the reflection mechanism, we only need to the deeper
information of upstream packet, not necessary for the corresponding
downstream packet. For downstream packets of the same session, the 3-tuple
info(src, dst, flow label) is enough for upper layer traffic recognition. 
We also consider other usage scenarios for flow label reflection, for detail
information, you can review the presentation document(the link on the
current IETF website connect to the wrong file, then I attached it via
e-mail.) 

> Oh, and IPv6 Errors (ICMPv6) are part of that flow, but the Flow Label
will not
> include those.
> 
【Aijun】:ICMP Errors packets are often regenerated by the router, not the
original data packet destination(3-tuple information has been changed). So
the process for flow label reflection would be different and we will
consider it more carefully later.
For PTB error message in ECMP environment, especially for the load balancer
before server farm, we recommend the load balancer to deal with specially
such PTB error message, that is to say, send this error message to all
servers that have the same address. Such method is more simple and less
influences to redefine the meaning of this field. Servers that receive the
PTB error message should all reduce their following packet size according to
the recommending MTU value.



> And as you say "Service Provider" though, sounds like you are opening that
can
> of worms called Net Neutrality.
【Aijun】: SFC, NFVRG etc group in IETF are all considering how to deal with
various traffic flow in more flexible manner, this is the development trend.
It is not enough for service provider to consider only the ip src and ip
dest information. 
> 

> Greets,
>  Jeroen