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