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

[Tom Herbert <[e-mail]>]

On Tue, Nov 18, 2014 at 3:54 PM, Tissa Senevirathne (tsenevir)
<[e-mail]> wrote:
> 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
>
Tissa,

If I am reading this correctly, the OAM message would be composed of
the encapsulation header, followed by 128 bytes of which contains a
pseudo header for switching, followed by a self defining OAM message.
The OAM bit is only used at the receiver to distinguish data messages
for OAM messages for processing. Is this interpretation correct?

Thanks,
Tom

>
>
>
>
> 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]> 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]> 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]>
>>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]] 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];
>>>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]>
>>>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]> wrote:
>>>>>
>>>>>>
>>>>>> One comment in line....
>>>>>>
>>>>>>> On Nov 13, 2014, at 11:47 PM, Vero Zheng <[e-mail]>
>>>>>>>wrote:
>>>>>>>
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> Please see in-line.
>>>>>>>
>>>>>>> BR, Vero
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: nvo3 [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]
>>>>>>>> Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements
>>>>>>>> for OAM
>>>>>>>>
>>>>>>>> On Wed, Nov 12, 2014 at 5:13 PM, Mach Chen <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Tom Herbert [mailto:[e-mail]]
>>>>>>>>>> Sent: Thursday, November 13, 2014 3:11 AM
>>>>>>>>>> To: Marc Binderberger
>>>>>>>>>> Cc: Mach Chen; Greg Mirsky; Haoweiguo; [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]>
>>>>>>>> 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]]
>>>>>>>>>>>>> Sent: Wednesday, November 12, 2014 5:06 PM
>>>>>>>>>>>>> To: Mach Chen
>>>>>>>>>>>>> Cc: Greg Mirsky; Haoweiguo; [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]>
>>>>>>>>>>>>> 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]] On Behalf Of Greg
>>>>>>>>>>>>>> Mirsky
>>>>>>>>>>>>>> Sent: Wednesday, November 12, 2014 8:05 AM
>>>>>>>>>>>>>> To: Haoweiguo
>>>>>>>>>>>>>> Cc: [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]>
>>>>>>>>>>>>> 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]]
>>>>>>>>>>>>>> 发送时间: 2014年11月12日 4:33
>>>>>>>>>>>>>> 收件人: Haoweiguo; Greg Mirsky
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 抄送: [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]>
>>>>>>>>>>>>>> Date: Tuesday, November 11, 2014 10:18 AM
>>>>>>>>>>>>>> To: Greg Mirsky <[e-mail]>
>>>>>>>>>>>>>> Cc: "[e-mail]" <[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]]
>>>>>>>>>>>>>> 发送时间: 2014年11月12日 4:07
>>>>>>>>>>>>>> 收件人: Haoweiguo
>>>>>>>>>>>>>> 抄送: [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]>
>>>>>>>>>>>>> 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]
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> nvo3 mailing list
>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> nvo3 mailing list
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>>> _______________________________________________
>>>>>>>>> nvo3 mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> nvo3 mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>> _______________________________________________
>>>>>>> nvo3 mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> nvo3 mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>
>>>_______________________________________________
>>>nvo3 mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/nvo3
>>
>>_______________________________________________
>>nvo3 mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>