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

"Rabadan, Jorge (Jorge)" <jorge.rabadan@alcatel-lucent.com> Thu, 27 February 2014 16:57 UTC

Return-Path: <jorge.rabadan@alcatel-lucent.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231B51A0382 for <l2vpn@ietfa.amsl.com>; Thu, 27 Feb 2014 08:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkMDm_2sm0c0 for <l2vpn@ietfa.amsl.com>; Thu, 27 Feb 2014 08:57:24 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 17ECE1A036E for <l2vpn@ietf.org>; Thu, 27 Feb 2014 08:57:24 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1RGvJZl009694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Feb 2014 10:57:21 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1RGvIux021970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 17:57:19 +0100
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.116]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 27 Feb 2014 17:57:18 +0100
From: "Rabadan, Jorge (Jorge)" <jorge.rabadan@alcatel-lucent.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Kanwar Singh <kanwar@nuagenetworks.net>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt
Thread-Topic: Request for comments: draft-jain-nvo3-overlay-oam-01.txt
Thread-Index: AQHPM9i/8gEtCy0e4EuWLz1WxAmt5prIu14A
Date: Thu, 27 Feb 2014 16:57:18 +0000
Message-ID: <CF34AC31.36220%jorge.rabadan@alcatel-lucent.com>
In-Reply-To: <CA+RyBmWr6oa-eVY5+7ydGNxeFSRWze+QpC3Si+vVjaC=3yciXA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.5.121010
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_CF34AC3136220jorgerabadanalcatellucentcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/EvjVFCWpK2q1PKLqlo0B14IHZZg
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Pradeep Jain <pradeep@nuagenetworks.net>, Vinay Bannai <vbannai@paypal.com>, Ravi Shekhar <rshekhar@juniper.net>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 16:57:30 -0000

Hi Greg,

I understand that it might be too early for NVO3, however there are already overlay tunnel implementations deployed and running out there, and the need for OAM extensions for it is undeniable.
So personally I would like to see this being discussed sooner than later so that we don’t end up with dozens of non-interoperable OAM tools.

I think that is why the authors want to discuss this in the L2VPN WG as well: it might be too early for NVO3 but there is a real need to discuss this now.

Thank you.
Jorge


From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Thursday, February 27, 2014 at 8:27 AM
To: Kanwar Singh <kanwar@nuagenetworks.net<mailto:kanwar@nuagenetworks.net>>
Cc: "l2vpn@ietf.org<mailto:l2vpn@ietf.org>" <l2vpn@ietf.org<mailto:l2vpn@ietf.org>>, Pradeep Jain <pradeep@nuagenetworks.net<mailto:pradeep@nuagenetworks.net>>, Vinay Bannai <vbannai@paypal.com<mailto:vbannai@paypal.com>>, Ravi Shekhar <rshekhar@juniper.net<mailto:rshekhar@juniper.net>>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Hi Kanwar, et. al,
the document is certainly interesting and very detailed. But I believe that it is rather too early to discuss applicability of particular OAM tools without agreed upon set of requirements for NVO3 OAM and comprehensive gap analysis.

Regards,
Greg


On Thu, Feb 27, 2014 at 7:46 AM, Kanwar Singh <kanwar@nuagenetworks.net<mailto:kanwar@nuagenetworks.net>> 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.