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) [[email protected]]
*发送时间:* 2014年11月12日 4:33
*收件人:* Haoweiguo; Greg Mirsky
*抄送:* [email protected]
*主题:* 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 <[email protected] <mailto:[email protected]>>
Date: Tuesday, November 11, 2014 10:18 AM
To: Greg Mirsky <[email protected] <mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
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 [[email protected]
<mailto:[email protected]>]
*发送时间:* 2014年11月12日 4:07
*收件人:* Haoweiguo
*抄送:* [email protected] <mailto:[email protected]>
*主题:* 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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
