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.
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
