[nvo3] 答复: 答复: Comments on NVO3 data plane requirements for OAM

Haoweiguo <haoweiguo@huawei.com> Fri, 14 November 2014 07:31 UTC

Return-Path: <haoweiguo@huawei.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B5C1A82E2 for <nvo3@ietfa.amsl.com>; Thu, 13 Nov 2014 23:31:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.755
X-Spam-Level: **
X-Spam-Status: No, score=2.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, GB_SUMOF=1, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
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 v7yLYnthtUKe for <nvo3@ietfa.amsl.com>; Thu, 13 Nov 2014 23:31:33 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B281A8545 for <nvo3@ietf.org>; Thu, 13 Nov 2014 23:31:32 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLP81019; Fri, 14 Nov 2014 07:31:31 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Nov 2014 07:31:29 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 14 Nov 2014 15:31:25 +0800
From: Haoweiguo <haoweiguo@huawei.com>
To: Erik Nordmark <nordmark@sonic.net>, "Larry Kreeger (kreeger)" <kreeger@cisco.com>, Greg Mirsky <gregimirsky@gmail.com>
Thread-Topic: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM
Thread-Index: AQHP/7rqK2j9Co9hbEiSDGlP1VoLbJxftlZe
Date: Fri, 14 Nov 2014 07:31:25 +0000
Message-ID: <DD5FC8DE455C3348B94340C0AB5517334F8101A2@nkgeml501-mbs.china.huawei.com>
References: <D087957A.124DA9%kreeger@cisco.com> <DD5FC8DE455C3348B94340C0AB5517334F80F4E0@nkgeml501-mbs.china.huawei.com>, <5465768E.20203@sonic.net>
In-Reply-To: <5465768E.20203@sonic.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.156.150]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/RBchwAQ2FwQnzKJma9HVVbO4bjI
Cc: "nvo3@ietf.org" <nvo3@ietf.org>
Subject: [nvo3] 答复: 答复: Comments on NVO3 data plane requirements for OAM
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 07:31:36 -0000

Hi Eric,
I would prefer the marking bit in NVO3 header, rather than in outer IP header.
This is for overlay network performance measurements, not for underlay network.
In ingress NVE, marking policy should support discrimination between different tenants,even support discrimation different applications of same tenant.
In this case, marking bit can only be set in NVO3 header. And just as Mach and Greg's description, two bits are necessary, one bit for packet loss detection, another bit for packet latency detection.
Thanks
weiguo

_____________________________
发件人: Erik Nordmark [nordmark@sonic.net]
发送时间: 2014年11月14日 11:27
收件人: Haoweiguo; Larry Kreeger (kreeger); Greg Mirsky
抄送: nvo3@ietf.org
主题: Re: [nvo3] 答复:  Comments on NVO3 data plane requirements for OAM

On 11/11/14 1:51 PM, Haoweiguo wrote:
>
> Hi Larry,
>
> For marking purpose, i think one bit maybe OK, fixed fields in NVO3
> header is precious. I would like it is set in fixed field, rather than
> in option field. Because chipset normally can't process optional
> field, it is hard to realize in-band performance measurement if using
> optional field for marking. For other real time congestion control
> function, maybe more bits are needed.
>

There is some work that describes how the ECN bits in the outer header
can be used for tunnels.
See draft-briscoe-tsvwg-ecn-encap-guidelines

That provides one bit for in-band measurements over the tunnel.

   Erik
>
> Thanks
>
> weiguo
>
> ------------------------------------------------------------------------
> *发件人:* Larry Kreeger (kreeger) [kreeger@cisco.com]
> *发送时间:* 2014年11月12日 4:33
> *收件人:* Haoweiguo; Greg Mirsky
> *抄送:* nvo3@ietf.org
> *主题:* Re: [nvo3] Comments on NVO3 data plane requirements for OAM
>
> Hi Weiguo,
>
> What do you envision this marking looking like?  e.g. is it just a
> single flag bit, or large field with a counter or sequence number, or
> some kind of flow ID?  If not a single flag, how large do you see the
> field being?
>
> If it is more than a flag (and I assume it would be), and is not
> mandatory for all implementations, then it seems to fall into the
> category of optional extensions.
>
> Thanks, Larry
>
> From: Haoweiguo <haoweiguo@huawei.com <mailto:haoweiguo@huawei.com>>
> Date: Tuesday, November 11, 2014 10:18 AM
> To: Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> Cc: "nvo3@ietf.org <mailto:nvo3@ietf.org>" <nvo3@ietf.org
> <mailto:nvo3@ietf.org>>
> Subject: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM
>
> Hi Greg,
>
> I fully agree with you.
>
> The real time OAM is passive performance measurement methods. I would
> like NVO3 data encapsulation has a field for marking and not affect
> forwarding of packets, the marking field is only used for performance
> measurement. The NVO3 packet with this marking flag don't need to be
> sent to control plane, it is different from OAM(ping/Trace) packet
> processing.
>
> Thanks
>
> weiguo
>
> ------------------------------------------------------------------------
> *发件人:* Greg Mirsky [gregimirsky@gmail.com
> <mailto:gregimirsky@gmail.com>]
> *发送时间:* 2014年11月12日 4:07
> *收件人:* Haoweiguo
> *抄送:* nvo3@ietf.org <mailto:nvo3@ietf.org>
> *主题:* Re: [nvo3] Comments on NVO3 data plane requirements for OAM
>
> Hi Weiguo,
> marking groups of packets that belong to the particular flow to
> facilitate measurement of some performance metric, whether loss or
> delay/delay variation, may be viewed as one of passive performance
> measurement methods. But such marking should not alter, at least not
> significantly alter, treatment of data flow in the network. Because of
> that, I believe, OAM flag should not be used for marking as that will
> force punting marked packets from fast forwarding path to the control
> plane. But it might be good to have a field in NVO3 header that may be
> used for marking and not affect forwarding of packets if altered.
>
> Regards,
> Greg
>
> On Tue, Nov 11, 2014 at 12:34 AM, Haoweiguo <haoweiguo@huawei.com
> <mailto:haoweiguo@huawei.com>> wrote:
>
>     Hi All,
>
>     I maybe not clearly said in today’s NVO3 meeting, pls allow me to
>     reiterate the OAM data plane requirements on the mail list.
>
>     Currently NVO3 data plane encapsulation only includes one OAM
>     flag, it is used for Ping/Trace similar applications. This kind of
>     OAM application is initiated by operators for network connectivity
>     verification, normally when network failure occurs. There is
>     another OAM requirements of real time OAM or synthesizing OAM. It
>     can be used for packet loss detection in real time. When ingress
>     NVE receives traffic from local TS, it gets packet statistics, and
>     mark(coloring) the OAM flag relying on local policy when it
>     performs NVO3 encapsulation. When egress NVEs receives the
>     traffic, it decapsulates NVO3 encapsulation, and gets packet
>     statistics with the real time OAM flag marking. By comparing the
>     packet number of ingress NVE and the sum of all egress NVEs,
>     packet loss can be deduced. This method can be applicable for both
>     unicast and multicast traffic. Local policy on ingress NVE is
>     configured by operators or automatically acquired from centralized
>     orchestration.
>
>     Thanks
>
>     weiguo
>
>
>     _______________________________________________
>     nvo3 mailing list
>     nvo3@ietf.org <mailto:nvo3@ietf.org>
>     https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3