Hi Marc, I agree, marking is one of passive performance measurement methods. Originally it was referred to as 'coloring' but later, in part because among Ethernet folks 'coloring' describes flow policing and drop eligibility marking process, we've changed to 'marking'. But Mach corrected me and pointed to valid scenario when not one but two bits required to concurrently measure loss and latency/jitter. So, we'll settle with two bits for passive performance measurement. Can we refer to it as Marker field? And it should have no role in routing/forwarding/qos decision making.
Regards, Greg On Wed, Nov 12, 2014 at 12:43 AM, Marc Binderberger <[email protected]> wrote: > 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
