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