Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:[email protected]] > Sent: Wednesday, November 12, 2014 6:11 PM > To: Mach Chen > Cc: Tom Herbert; Greg Mirsky; Haoweiguo; [email protected]; Larry Kreeger > Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM > > Hello Mach, > > so for delay measurement you use the color flag to mark a single packet, which > helps the receiver to pick the right packet? And repeat this every time > period > T ?
Yes > > ...000100000010000001000... > > > One question I still have is: why is the measurement done in the NVE header? > The outer header is IP/IPv6, so couldn't we use the coloring for the IP/IPv6 > header, assuming this is defined? Regarding NVE header of IP/IPv6 header, I am not sure which is better. One challenge for using IPv4/IPv6 header is that there is not too much bits that can be used for marking, especially for IPv4. Best regards, Mach > > > Thanks & Regards, > Marc > > > > On Wed, 12 Nov 2014 09:34:52 +0000, Mach Chen wrote: > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
