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

[Gregory Mirsky <[e-mail]>]

Hi Wim,
I haven't heard any complains from NOCs operating any multi-layer transport network. You have TDM/OTN OAM, Ethernet Service OAM, and IP OAM (sort of). I think this is pretty common though DC operators might see it differently.

                Regards,
                                Greg

From: L2vpn [mailto:[e-mail]] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, February 27, 2014 8:51 PM
To: S. Davari; Shahram Davari; Kanwar Singh
Cc: [e-mail]; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Having different OAM for IP and ETH is not very friendly to the operations people.

From: "S. Davari" <[e-mail]<mailto:[e-mail]>>
Reply-To: "S. Davari" <[e-mail]<mailto:[e-mail]>>
Date: Friday 28 February 2014 00:50
To: Wim Henderickx <[e-mail]<mailto:[e-mail]>>, Shahram Davari <[e-mail]<mailto:[e-mail]>>, Kanwar Singh <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Pradeep Jain <[e-mail]<mailto:[e-mail]>>, Vinay Bannai <[e-mail]<mailto:[e-mail]>>, Ravi Shekhar <[e-mail]<mailto:[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]<mailto:[e-mail]>>
To: Shahram Davari <[e-mail]<mailto:[e-mail]>>; Kanwar Singh <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>; Pradeep Jain <[e-mail]<mailto:[e-mail]>>; Vinay Bannai <[e-mail]<mailto:[e-mail]>>; Ravi Shekhar <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Pradeep Jain <[e-mail]<mailto:[e-mail]>>, Vinay Bannai <[e-mail]<mailto:[e-mail]>>, Ravi Shekhar <[e-mail]<mailto:[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]<mailto:[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.