Hello Greg and Weiguo, ah, I see. Thanks for the links and the explanation!
While this is "OAM" maybe we can give it a more explicit name to avoid confusion? "Performance Measurement"? "Passive OAM"? Or maybe "Coloring"? Anyway, so this is something different than what I thought. For a single bit I guess a full TLV is a bit overkill ;-) So the data plane header needs a "flag field", okay. NVGRE, Geneve, GUE, VxLAN(-gpe) all have a flag/reserved field, shouldn't be a problem to add this flag, IMHO. Regards, Marc On Tue, 11 Nov 2014 18:37:04 -0800, Greg Mirsky wrote: > Hi Marc, > thank you for your thorough review and thoughtful comments. > How passive performance measurement may work discussed in IP Flow > Performance Measurement Framework and IP Flow Performance Measurement > Report. > > I still believe that "original OAM flag" is to be used for active OAM, e.g. > continuity check, proactive and on-demand, performance measurement. In some > way, the GAL in MPLS is that "original OAM flag". But active OAM, IMO, > should be complemented by use of passive measurement methods. Often these > viewed as reading counters, IPFIX. But marking is method that expands and > improves passive performance measurements through ability to correlate > measurements taken at individual nodes along a path of the flow. > > Regards, > Greg > > > On Tue, Nov 11, 2014 at 6:24 PM, Marc Binderberger <[email protected]> wrote: >> Hello Greg and Weiguo, >> >>> agree with Weiguo, single bit flag in fixed position would be sufficient >>> and HW-friendly. >> >> a single bit just turns on and off - but it seems we have two different >> ideas >> of OAM under discussion meanwhile. And both ideas claim they need an "OAM" >> flag. >> >> Makes already 2 bits :-) >> >> >>> 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. >> >> Really? How is this working? To do any processing of this real-time OAM >> you >> still need to punt a copy of the NVO3 packet or at least the OAM-related >> information to the generic CPU, i.e. get it out of the fast/hw forwarding >> plane. >> >> >> And then you need some information in the NVO3 packet, I assume? >> Timestamps, >> Counters etc.? I don't think this will fit into any of the headers >> discussed >> so far unless you use a TLV approach. >> >> >>>> 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 >> >> If your optional field is defined to be the "first option TLV" then this is >> no difference from a larger fixed header. Still not sure what the chipset >> is >> supposed to process. >> >> If the NVO3 group thinks this kind of OAM is sort of a must then of course >> it >> makes sense to define the (fixed) base header with this OAM data. My >> problem >> here is ... >> >>>> marking. For other real time congestion control function, maybe more >> bits >>>> are needed. >> >> ... that you already indicate there may be more/different OAM data in the >> future. Using a fixed header likely means a new, larger fixed header to >> incorporate the additional OAM, which makes older implementations >> incompatible. >> >> >> What the (fixed?) base header should support is the principle mechanism - >> we >> seem to discuss a "punt, don't forward" and a "punt & forward" OAM, if I >> understand it right (?). >> >> At least the more "fancy" OAM seems a fit for optional TLV (with some >> position restriction). >> >> >> This initial OAM we are talking about here, is this just packet loss? So >> you >> would need to carry some sequence number? >> >> >> >> Regards, Marc >> >> >> >> >> >> On Tue, 11 Nov 2014 16:04:30 -0800, Greg Mirsky wrote: >>> 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
