Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

[Sam Aldrin <[e-mail]>]

We have published a draft a while ago, <http://datatracker.ietf.org/doc/draft-kumar-nvo3-overlay-ping/>, which is on the lines of MPLS lsp ping. Primarily it is IP/udp ping  targeted for overlay networks. For NVo3 FM, there is a draft  <http://datatracker.ietf.org/doc/draft-tissa-nvo3-oam-fm/>, which will be presented in the NVo3 WG session.

Cheers
Sam
Sent from my iPad

> On Feb 27, 2014, at 8:03 AM, Thomas Nadeau <[e-mail]> wrote:
> 
> 
> 	I had precisely the same question.  Most DCs simply use IP/Enet which allow for the use of the "regular suspects" in the tools department. 
> 
> 	The other concern I have with specifying new tools on top of the underlay is that the underlay probably is running some diag tools for failure detection/trouble-shooting too (like Ethernet OAM/BFD/etc...), so once again we have the issue to consider of OAM traffic consuming significant amounts of actual BW.  Given how modern applications are built and run, its unlikely we need anything heavy weight in the overlay and can instead allow for application resiliency to handle failure detection, and instead have the "normal" tools available for trouble-shooting on an as-needed basis.
> 
> 	--Tom
> 
> 
> 
>> Hi
>> 
>> Why don't you use existing IP based OAM messages such as BFD, OWAMP, TWAMP, etc.
>> 
>> Regards,
>> Shahram
>> 
>> 
>> On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <[e-mail]> wrote:
>> 
>>> Dear All,
>>> 
>>> We have submitted the below draft that proposes Generic OAM and Datapath Failure Detection Mechanism(s) for Overlay Networks.
>>> 
>>> We would like to solicit inputs from the members of L2VPN WG.
>>> 
>>> Please review the same and update us with your inputs/feedback.
>>> 
>>> Warm Regards
>>> - Kanwar
>>> 
>>> 
>>> A new version of I-D, draft-jain-nvo3-overlay-oam-01.txt has been successfully submitted by Kanwar Singh and posted to the
>>> IETF repository.
>>> 
>>> 
>>> 
>>> Name:           draft-jain-nvo3-overlay-oam
>>> 
>>> Revision:       01
>>> Title:          Generic Overlay OAM and Datapath Failure Detection
>>> 
>>> 
>>> Document date:  2014-02-12
>>> 
>>> Group:          Individual Submission
>>> 
>>> Pages:          44
>>> URL:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt
>>> 
>>> 
>>> Status:         https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/
>>> 
>>> 
>>> Htmlized:      http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-01
>>> 
>>> 
>>> Diff:              http://www.ietf.org/rfcdiff?url2=draft-jain-nvo3-overlay-oam-01
>>> 
>>> 
>>> 
>>> Abstract:
>>> 
>>> 
>>>    This proposal describes a mechanism that can be used to detect Data
>>> 
>>> 
>>>    Path Failures of various overlay technologies as VXLAN, NVGRE,
>>> 
>>> 
>>>    MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data
>>> 
>>> 
>>>    Plane for given Overlay Segment.  This document defines the following
>>> 
>>> 
>>>    for each of the above Overlay Technologies:
>>> 
>>> 
>>>    o  Encapsulation of OAM Packet, such that it has same Outer and
>>> 
>>> 
>>>       Overlay Header as any End-System's data going over the same
>>> 
>>> 
>>>       Overlay Segment.
>>> 
>>> 
>>>    o  The mechanism to trace the Underlay that is exercised by any
>>> 
>>> 
>>>       Overlay Segment.
>>> 
>>> 
>>>    o  Procedure to verify presence of any given Tenant VM or End-System
>>> 
>>> 
>>>       within a given Overlay Segment at Overlay End-Point.
>>> 
>>> 
>>>    Even though the present proposal addresses Overlay OAM for VXLAN,
>>> 
>>> 
>>>    NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are
>>> 
>>> 
>>>    generic enough to accommodate OAM for any other Overlay Technology.
>