Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM

["Tissa Senevirathne (tsenevir)" <[e-mail]>]

Greg

I disagree with you on FM and PM cannot be achieved in ECMP environment. Significant amount of work has gone in to this area during TRILL OAM.  Please check the use of Flow entropy functionality proposed in NVO3 OAM.

https://tools.ietf.org/html/draft-tissa-nvo3-oam-fm-00


From: nvo3 [mailto:[e-mail]] On Behalf Of Greg Mirsky
Sent: Tuesday, November 18, 2014 3:03 PM
To: Tapraj Singh
Cc: [e-mail]
Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM

Hi Tapraj,
though I agree and support with idea of having OAM flag in NVO3 header I have to point to:

  *   absence of WG agreed upon OAM Requirements;
  *   no gap analysis of tools for NVO3 OAM;
  *   OAM flag does not help passive performance measurement marking method (two bit-long field for marking in fixed position).
I agree that PW VCCV and GAL/G-ACh can be viewed as MPLS identification of OAM packet (though not necessarily OAM). But IP clearly doesn't have such identification for OAM and that, in part, why in-band requirement for IP OAM, both FM and Active PM, is not attainable (ECMP environment).
Regards,
Greg

On Tue, Nov 18, 2014 at 1:31 PM, Tapraj Singh <[e-mail]<mailto:[e-mail]>> wrote:
Hi All,

 I totally agree with the point made by Deepak and Tissa here.
Our OAM should follow the data path for services as much as possible and
all
other protocol specific information should be in the OAM protocol specific
TLVs.

LAYER2 OAM

In term of identify the OAM packet, first level of identification for L2
OAM
Should be the MAC address and send level of hierarchy should be the ether
type or OUI.
No other OAM Specific field should be allowed in the packet header.

 Please note that L3 OAM and MPLS also follow the same principle.

Thanks
Tapraj

On 11/17/14 12:39 PM, "Deepak Kumar (dekumar)" <[e-mail]<mailto:[e-mail]>> wrote:

>I Agree with Tissa below. My Goal also was to point out that instead of
>complicating the header, we can do OAM performance within OAM channel
>itself and this is extensible and can be done in hardware which is why
>mostly things are added in header.
>
>Also, Operators keep asking for new OAM tools (Fault detection,
>verification, isolation, Interworking, alarm, putting service in
>maintenance and perform test)  and Performance tools, eg: (Delay/Jitter,
>Actual Loss Measurement, Synthetic Loss, loopback signaling like TDM,
>Generate frames to verify qos etc.) and so OAM Channel solution will be
>extensible.
>
>Thanks,
>Deepak
>
>On 11/17/14 8:47 AM, "Tissa Senevirathne (tsenevir)" <[e-mail]<mailto:[e-mail]>>
>wrote:
>
>>I think we are complicating OAM beyond what it is needed.
>>
>>As far as packet encapsulation is concern, all what is needed is single
>>bit. This bit is needed to prevent OAM packets leaking out from the
>>domain.
>>
>>Termination of OAM and processing of it happen based on the addressing in
>>the packet.
>>
>>E.g. if Address matches and OAM bit is set then it is an OAM packet
>>addressed to the local MEP/MP.
>>
>>Not other way around. Why? Because we want OAM to be as closely as
>>possible follow the Data path.
>>
>>If we need to have performance and delay measurements, we SHOULD NOT
>>mutate the packet header.
>>
>>Instead OAM specific extensions should be in the OAM shim.
>>
>>As an example. You could have packet fragment (which is sometimes called
>>flow entropy) and at the end of that you can have all of the stuff you
>>need in the world of OAM.
>>
>>Hope this clarify
>>
>>Thanks
>>Tissa
>>-----Original Message-----
>>From: nvo3 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Tom Herbert
>>Sent: Monday, November 17, 2014 8:02 AM
>>To: Marc Binderberger
>>Cc: Greg Mirsky; Mach Chen; Deepak Kumar (dekumar); [e-mail]<mailto:[e-mail]>;
>>Haoweiguo; Larry Kreeger (kreeger); Vero Zheng; Jon Hudson
>>Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM
>>
>>On Mon, Nov 17, 2014 at 12:01 AM, Marc Binderberger <[e-mail]<mailto:[e-mail]>>
>>wrote:
>>> Hello Deepak et al.,
>>>
>>> so this sounds like we need more than just a (2nd) bit for delay
>>>measurement.
>>> Seems we need an optional header extension or a TLV to carry all the
>>> information (timestamps, oam Subtype). Sounds definitely more than a
>>> 32/64bit header could carry (*).
>>>
>>> The optional header extension, when done similar to GUE, has a fixed
>>> position. For the TLV this would be an additional requirement. This
>>> would allow for hardware-stamping.
>>>
>>The alternative is to do active delay measurement using request/reply.
>>We should be able to define the requirements so that an OAM message
>>corresponding to a flow which would be routed in exactly the same way as
>>a data message for the flow. Larry mentioned that we might even want to
>>put a "fake" packet header as the first part of the encapsulated payload
>>of an OAM message for instance.
>>
>>> Now if we introduce such an OAM extension header it could as well
>>> carry the "first" bit we discussed for packet loss measurement (?).
>>>
>>>
>>> Regards, Marc
>>>
>>> (*: at least all proposals so far have a base header that fits into
>>> 32/64 bit, plus IP and potential UDP)
>>>
>>>
>>>
>>>
>>> On Sun, 16 Nov 2014 16:44:54 +0000, Deepak Kumar (dekumar) wrote:
>>>> Hi,
>>>>
>>>> Please see inline +++DK:
>>>>
>>>> On 11/14/14 11:09 AM, "Jon Hudson" <[e-mail]<mailto:[e-mail]>> wrote:
>>>>
>>>>>
>>>>> One comment in line....
>>>>>
>>>>>> On Nov 13, 2014, at 11:47 PM, Vero Zheng <[e-mail]<mailto:[e-mail]>>
>>>>>>wrote:
>>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> Please see in-line.
>>>>>>
>>>>>> BR, Vero
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: nvo3 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Tom Herbert
>>>>>>> Sent: Friday, November 14, 2014 4:27 PM
>>>>>>> To: Mach Chen
>>>>>>> Cc: Greg Mirsky; Haoweiguo; Marc Binderberger; Larry Kreeger;
>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>> Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements
>>>>>>> for OAM
>>>>>>>
>>>>>>> On Wed, Nov 12, 2014 at 5:13 PM, Mach Chen <[e-mail]<mailto:[e-mail]>>
>>>>>>> wrote:
>>>>>>>> Hi Tom,
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Tom Herbert [mailto:[e-mail]<mailto:[e-mail]>]
>>>>>>>>> Sent: Thursday, November 13, 2014 3:11 AM
>>>>>>>>> To: Marc Binderberger
>>>>>>>>> Cc: Mach Chen; Greg Mirsky; Haoweiguo; [e-mail]<mailto:[e-mail]>; Larry
>>>>>>>>> Kreeger
>>>>>>>>> Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements
>>>>>>>>> for OAM
>>>>>>>>>
>>>>>>>>> On Wed, Nov 12, 2014 at 2:11 AM, Marc Binderberger
>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>> wrote:
>>>>>>>>>> Hello Mach,
>>>>>>>>>>
>>>>>>>>>> so for delay measurement you use the color flag to mark a
>>>>>>>>>> single packet, which helps the receiver to pick the right
>>>>>>>>>> packet?  And repeat this every time period T ?
>>>>>>>>>>
>>>>>>>>>>    ...000100000010000001000...
>>>>>>>>> Is there there a draft or description of how this algorithm
>>>>>>>>> would work? Seems like there would need to be quite a bot of
>>>>>>>>> synchronization needed between end points (synchronized clocks,
>>>>>>>>> provisions to correlate measurements correctly with lost
>>>>>>>>> packets, replicated packets, etc.). Also, what is envisioned for
>>>>>>>>> range for the period?
>>>>>>>>
>>>>>>>> Here is a reference
>>>>>>>
>>>>>>> https://datatracker.ietf.org/doc/draft-chen-ippm-coloring-based-ip
>>>>>>> fpm-fr
>>>>>>> amew
>>>>>>> ork/.
>>>>>>>
>>>>>>> Thanks for the pointer. Regarding the need for synchronized clocks
>>>>>>> to measure delay, I consulted our local NTP expert. The host clock
>>>>>>> jitter we currently see in our network is currently usually
>>>>>>> greater than one-way packet delay (in some cases much greater), so
>>>>>>> in his words:
>>>>>>> "measuring one-way packet delays using host clocks is a lost
>>>>>>>cause".
>>>>>>> Please take this as just one data point!
>>>>>
>>>>> <Jon> Thank you. As someone who has managed NTP more times and for
>>>>> more years than I care to admit, this is a very good datapoint to
>>>>>consider.
>>>>> NTP helps many understand that time is relative.
>>>>
>>>> +++DK: As per our experience in carrier Ethernet we supported one way
>>>> delay and never found NTP useful even for our lab networks (I am
>>>> referring software based NTP NTPv3).
>>>> As mentioned below IEEE 1588v2 will vary based on equipment and
>>>> operator networks but in our testing we found it very precise if
>>>>properly deployed.
>>>> IEEE 1588v2 is very precise if phy based timestamping is used. Even
>>>> timestamping at NP level provided great results for one way delay.
>>>>
>>>> If we want to accurately measure two way delay we need 4 timestamp
>>>> total on receiver of frame (this is to avoid processing time that's
>>>> taken for reply by software as hardware can put timestamp at lower
>>>> layer without doing delay and jitter calculation).
>>>> For one way delay we will require 2 timestamp, so lower layer
>>>> hardware can timestamp before packet is punted to software.
>>>>
>>>> As mentioned below I agree 8 byte IEEE 1588 timestamp is required.
>>>>
>>>> We should also look for Synthetic OAM applicability for performance
>>>>('O'
>>>> bit can be overloaded to do both Fault and performance if OAM is
>>>> defined with different oam Subtype for Delay and Loss frames and it
>>>> will not be too deep hardware inspection) as that give large
>>>> flexibility (synthetic/real loss measurement,
>>>> Availability/unavailability, on-demand and pro-active performance) and
>>>>can be run on all flows of ECMP.
>>>>
>>>> Thanks,
>>>> Deepak
>>>>>
>>>>>
>>>>>>
>>>>>> [Vero] Thanks for this. What about the current experience with
>>>>>> 1588v2 then?
>>>>>>>
>>>>>>>> Yes, it does need some synchronization. As for the range, it
>>>>>>>> depends on two
>>>>>>> factors, one is the implementation limitation, the other the
>>>>>>> requirement of the operators. In the above reference, the
>>>>>>> suggested periods are 1s, 10s, 1min, 10min and 1h.
>>>>>>> I think if we were implementing delay measurement in GUE, I would
>>>>>>> advocate add a 64 bit optional field for timestamp, probably
>>>>>>> containing source time stamp, and echoed timestamp for a flow
>>>>>>> (usec resolution and similar in design TCP timestamp option). This
>>>>>>> easily gives a precise RTT, and if clocks are precisely
>>>>>>> synchronized then one way latency could be calculated also.
>>>>>> [Vero] If the source timestamp could be carried, it could also be
>>>>>> used for packet loss calculation/correlation.
>>>>>>
>>>>>>> Thanks,
>>>>>>> Tom
>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Mach
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Tom
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> One question I still have is: why is the measurement done in
>>>>>>>>>> the NVE
>>>>>>> header?
>>>>>>>>>> The outer header is IP/IPv6, so couldn't we use the coloring
>>>>>>>>>> for the
>>>>>>>>>> IP/IPv6 header, assuming this is defined?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>> Marc
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Wed, 12 Nov 2014 09:34:52 +0000, Mach Chen wrote:
>>>>>>>>>>> Hi Tom,
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Tom Herbert [mailto:[e-mail]<mailto:[e-mail]>]
>>>>>>>>>>>> Sent: Wednesday, November 12, 2014 5:06 PM
>>>>>>>>>>>> To: Mach Chen
>>>>>>>>>>>> Cc: Greg Mirsky; Haoweiguo; [e-mail]<mailto:[e-mail]>; Larry Kreeger
>>>>>>>>>>>> (kreeger)
>>>>>>>>>>>> Subject: Re: [nvo3] 答复: Comments on NVO3 data plane
>>>>>>>>>>>> requirements for OAM
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 12, 2014 at 12:55 AM, Mach Chen
>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Hi Greg and all,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Single bit is not sufficient if someone wants to perform
>>>>>>>>>>>>> loss and delay measurement  simultaneously, then two bits
>>>>>>>>>>>>>needed.
>>>>>>>>>>>> Is that necessary? Can they share the same time quantum (as
>>>>>>>>>>>> well as other metrics maybe to be added later)? In all the
>>>>>>>>>>>> protocols mentioned, the reserved bits are a somewhat precious
>>>>>>>>>>>>resource.
>>>>>>>>>>>
>>>>>>>>>>> Yes, it's necessary if there is ECMP.
>>>>>>>>>>>
>>>>>>>>>>> Given one bit is used for both loss and delay measurement, for
>>>>>>>>>>> loss measurement, it periodically set and clear the marking
>>>>>>>>>>> bit, a flow is divided into consecutive blocks, and then the
>>>>>>>>>>> counting and calculating are based on each block. This is fine
>>>>>>>>>>> for loss measurement.
>>>>>>>>>>>
>>>>>>>>>>> For delay measurement, it has to make sure the timestamps
>>>>>>>>>>> (collected at sender and receiver) are for the same packet.
>>>>>>>>>>> Presumably, the time when changing the marking bit is right
>>>>>>>>>>> time to get
>>>>>>> the timestamps.
>>>>>>>>>>> Since there is ECMP, the first packet of a block at the sender
>>>>>>>>>>> may probably different from the first packet at the receiver,
>>>>>>>>>>> thus it will get the mismatched timestamps to calculate the
>>>>>>>>>>>delay.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Mach
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mach
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: nvo3 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Greg
>>>>>>>>>>>>> Mirsky
>>>>>>>>>>>>> Sent: Wednesday, November 12, 2014 8:05 AM
>>>>>>>>>>>>> To: Haoweiguo
>>>>>>>>>>>>> Cc: [e-mail]<mailto:[e-mail]>; Larry Kreeger (kreeger)
>>>>>>>>>>>>> Subject: Re: [nvo3] 答复: Comments on NVO3 data plane
>>>>>>> requirements
>>>>>>>>>>>>> for OAM
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>> 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) [[e-mail]<mailto:[e-mail]>]
>>>>>>>>>>>>> 发送时间: 2014年11月12日 4:33
>>>>>>>>>>>>> 收件人: Haoweiguo; Greg Mirsky
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 抄送: [e-mail]<mailto:[e-mail]>
>>>>>>>>>>>>> 主题: 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 <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>>> Date: Tuesday, November 11, 2014 10:18 AM
>>>>>>>>>>>>> To: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>>> Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>>> 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 [[e-mail]<mailto:[e-mail]>]
>>>>>>>>>>>>> 发送时间: 2014年11月12日 4:07
>>>>>>>>>>>>> 收件人: Haoweiguo
>>>>>>>>>>>>> 抄送: [e-mail]<mailto:[e-mail]>
>>>>>>>>>>>>> 主题: 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
>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> nvo3 mailing list
>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> nvo3 mailing list
>>>>>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>> _______________________________________________
>>>>>>>> nvo3 mailing list
>>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> nvo3 mailing list
>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>> _______________________________________________
>>>>>> nvo3 mailing list
>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> nvo3 mailing list
>>>> [e-mail]<mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>_______________________________________________
>>nvo3 mailing list
>>[e-mail]<mailto:[e-mail]>
>>https://www.ietf.org/mailman/listinfo/nvo3
>
>_______________________________________________
>nvo3 mailing list
>[e-mail]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/nvo3