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

[Thomas Nadeau <[e-mail]>]

	I totally agree - that is precisely the point I made earlier. 

	--Tom


On Feb 28, 2014:5:35 AM, at 5:35 AM, Shahram Davari <[e-mail]> wrote:

> But having a brand newly invented OAM is friendly ?
> 
> Regards,
> Shahram
> 
> 
> On Feb 27, 2014, at 8:51 PM, "Henderickx, Wim (Wim)" <[e-mail]> wrote:
> 
>> Having different OAM for IP and ETH is not very friendly to the operations people.
>> 
>> From: "S. Davari" <[e-mail]>
>> Reply-To: "S. Davari" <[e-mail]>
>> Date: Friday 28 February 2014 00:50
>> To: Wim Henderickx <[e-mail]>om>, Shahram Davari <[e-mail]>om>, Kanwar Singh <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>rg>, Pradeep Jain <[e-mail]>et>, Vinay Bannai <[e-mail]>om>, Ravi Shekhar <[e-mail]>
>> Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt
>> 
>> I meant using BFD inside the payload. not for the outer tunnel. You could also use Ethernet OAM for L2 endpoints.
>> 
>> Thx
>> SD
>> 
>> 
>> From: "Henderickx, Wim (Wim)" <[e-mail]>
>> To: Shahram Davari <[e-mail]>om>; Kanwar Singh <[e-mail]> 
>> Cc: "[e-mail]" <[e-mail]>rg>; Pradeep Jain <[e-mail]>et>; Vinay Bannai <[e-mail]>om>; Ravi Shekhar <[e-mail]> 
>> Sent: Thursday, February 27, 2014 8:02:45 AM
>> Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt
>> 
>> Because we also need to trace L2 endpoints besides IP endpoint.
>> 
>> From: Shahram Davari <[e-mail]>
>> Date: Thursday 27 February 2014 16:58
>> To: Kanwar Singh <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>rg>, Pradeep Jain <[e-mail]>et>, Vinay Bannai <[e-mail]>om>, Ravi Shekhar <[e-mail]>
>> Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt
>> 
>> 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.
>> 
>>