Hi Tom, Pls see inline with [weiguo]. Thanks weiguo ________________________________________ 发件人: Tom Herbert [[email protected]] 发送时间: 2014年11月12日 8:22 收件人: Greg Mirsky 抄送: Larry Kreeger (kreeger); Haoweiguo; [email protected] 主题: Re: [nvo3] Comments on NVO3 data plane requirements for OAM
On Tue, Nov 11, 2014 at 4:03 PM, Greg Mirsky <[email protected]> wrote: > Hi Tom, > I see very little use for out-of-band performance measurement as it result > hardly characteristic of monitored service. Perhaps we compare > out-or-service and in-service measurement. Marking is to facilitate Passive > performance measurement which is obviously in-service and in-band OAM. By out of band I mean not piggy backed on a data packet, but still can follow same path (for example ping to test path). [weiguo]: Yes,exactly. Current NVO3 OAM consideration only relates to out of band OAM, not piggy backed on data packet. So i would like to add a additional passive measurement method, i.e., in-band OAM. As > example of passive measurement it has limitations as well as advantages. > Marking method does not require tagging data packets with anything but mark > in the way that should not alter network treatment of unmarked packet. All > timestamps and counters are to be collected at observation points. Marking > helps to correlate collected information and perform measurements. > How would get a time stamp from just a single mark on a packet? [weiguo]: For packet loss statistics purpose, no time stamp is needed. A bit in NVO3 header is enough for packet loss. The flag is used to separaring packets between different statistics period. For example, if statistic period is 10 seconds, first period packets the flag is set to 1 on ingress NVE, second period the flag is set to 0, third period the flag is set to 1 again, then repeat again and again, until the statistics behavior terminated. Ingress NVE and egress NVE need to send their statistics for each period to a centralized point, the centralized point compares the statictics of packet number, the difference number is packet loss. > Regards, > Greg > > On Tue, Nov 11, 2014 at 1:42 PM, Tom Herbert <[email protected]> wrote: >> >> On Tue, Nov 11, 2014 at 12:33 PM, Larry Kreeger (kreeger) >> <[email protected]> wrote: >> > 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. >> > >> I assume this is a request for in-band measurement as opposed to some >> out of band summary mechanism which seems to be more typical of OAM. >> If we are adding loss counters/delay metrics to every data packet, >> this is starting to look like the sort of data we meed for congestion >> control and in fact might be a subset of that. >> >> Tom >> >> > 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
