On Tue, Nov 11, 2014 at 7:04 PM, Haoweiguo <[email protected]> wrote: > 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. >
Can you just keep a running count of packets received on the tunnel and return that periodically (I believe this is something like what circuit breaker does)? Tom >> 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
