Hi Tom, > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Wednesday, November 12, 2014 5:06 PM > To: Mach Chen > Cc: Greg Mirsky; Haoweiguo; [email protected]; Larry Kreeger (kreeger) > Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM > > On Wed, Nov 12, 2014 at 12:55 AM, Mach Chen <[email protected]> > wrote: > > Hi Greg and all, > > > > > > > > Single bit is not sufficient if someone wants to perform loss and > > delay measurement simultaneously, then two bits needed. > > > Is that necessary? Can they share the same time quantum (as well as other > metrics maybe to be added later)? In all the protocols mentioned, the reserved > bits are a somewhat precious resource.
Yes, it's necessary if there is ECMP. Given one bit is used for both loss and delay measurement, for loss measurement, it periodically set and clear the marking bit, a flow is divided into consecutive blocks, and then the counting and calculating are based on each block. This is fine for loss measurement. For delay measurement, it has to make sure the timestamps (collected at sender and receiver) are for the same packet. Presumably, the time when changing the marking bit is right time to get the timestamps. Since there is ECMP, the first packet of a block at the sender may probably different from the first packet at the receiver, thus it will get the mismatched timestamps to calculate the delay. Best regards, Mach > > Tom > > > > > > > Best regards, > > > > Mach > > > > > > > > From: nvo3 [mailto:[email protected]] On Behalf Of Greg Mirsky > > Sent: Wednesday, November 12, 2014 8:05 AM > > To: Haoweiguo > > Cc: [email protected]; Larry Kreeger (kreeger) > > Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for > > OAM > > > > > > > > Dear All, > > agree with Weiguo, single bit flag in fixed position would be > > sufficient and HW-friendly. > > > > Regards, > > > > Greg > > > > > > > > On Tue, Nov 11, 2014 at 3:51 PM, Haoweiguo <[email protected]> > 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. > > > > 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]> > > Date: Tuesday, November 11, 2014 10:18 AM > > To: Greg Mirsky <[email protected]> > > Cc: "[email protected]" <[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]] > > 发送时间: 2014年11月12日 4:07 > > 收件人: Haoweiguo > > 抄送: [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]> > 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] > > 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
