Dear Tom and Weiguo, I think what been referred as "out-of-band" usually been characterized as Active OAM, i.e. injected test packets that used to check continuity, verify connectivity or measure particular performance metric. "Out-of-band" usually describes OAM, control or signaling flow that is not identical, co-routed with the data flow. Obviously value of out-of-band OAM is somewhat questionable and that is why ensuring active OAM being in-band, IMO, is one of utmost important requirements.
Regards, Greg 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. > > > 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
