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

Shahram Davari <davari@broadcom.com> Fri, 28 February 2014 04:04 UTC

Return-Path: <davari@broadcom.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 C06091A06BE for <l2vpn@ietfa.amsl.com>; Thu, 27 Feb 2014 20:04:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level:
X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] 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 I0e6fPZ4LBOg for <l2vpn@ietfa.amsl.com>; Thu, 27 Feb 2014 20:04:10 -0800 (PST)
Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2813D1A06B6 for <l2vpn@ietf.org>; Thu, 27 Feb 2014 20:04:10 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.97,559,1389772800"; d="scan'208,217"; a="17221822"
Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw1-out.broadcom.com with ESMTP; 27 Feb 2014 20:42:29 -0800
Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 27 Feb 2014 20:04:07 -0800
Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 27 Feb 2014 20:04:07 -0800
From: Shahram Davari <davari@broadcom.com>
To: Pradeep Jain <pradeep@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: AQHPM9Mh8gEtCy0e4EuWLz1WxAmt5prJQcOtgACHZ4CAAADQAIAAJSOA//+JKpCAAQmqAIAACYiA//+BIGY=
Date: Fri, 28 Feb 2014 04:04:06 +0000
Message-ID: <7CE24018-E869-4968-B73B-08796261E551@broadcom.com>
References: <CAPCgso32vYqPEq4upa1FG78quZwBOJpzsCSCYTX2R7XgHzLiNA@mail.gmail.com> <B23247FA-7CED-4F78-8858-076CA83F613C@broadcom.com> <CF351FD5.B21EA%wim.henderickx@alcatel-lucent.com> <D26A6EDE-42D3-45A6-8FFC-3B1850433722@lucidvision.com> <CF34C0FC.7D7B%alohiya@juniper.net> <4A6CE49E6084B141B15C0713B8993F281BFCD485@SJEXCHMB12.corp.ad.broadcom.com> <CAHYfYvLy6ih=3=4BVWSRuajXOt473BVTT2S=c0opg1Zm=Mar4A@mail.gmail.com>, <CAHYfYvL5mPANt56ivvCnyMYfMaPs=GM1cs31VfCK9xAmg9oLpA@mail.gmail.com>
In-Reply-To: <CAHYfYvL5mPANt56ivvCnyMYfMaPs=GM1cs31VfCK9xAmg9oLpA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_7CE24018E8694968B73B08796261E551broadcomcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/3iiTdmv4PrOI3nzAJdj3xzt0xiw
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, 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: Fri, 28 Feb 2014 04:04:11 -0000

Regarding on demand, you could define new state machine for BFD or you could use IP ping or LSP ping. You could even use Ethernet Loopback.

Regards,
Shahram


On Feb 27, 2014, at 7:38 PM, "Pradeep Jain" <pradeep@nuagenetworks.net<mailto:pradeep@nuagenetworks.net>> wrote:



On Thursday, February 27, 2014, Pradeep Jain <pradeep@nuagenetworks.net<mailto:pradeep@nuagenetworks.net>> wrote:
Hi Shahram,

Using BFD mandates that the probes need to be sent continuously. We don't want to impose this restriction and leave it to the user to decide if they want an on-demand probe or a continuous probe, which is what has been defined in the draft..

Regarding the second point about including VNI/VSID in TLV, for the hardware/forwarding plane which is not capable of giving the overlay context of the packet (based on VNI/VSID) to the control plane, we need to rely on the VNI/VSID in the TLV to derive the overlay context in the control plane...

Regards
Pradeep


On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari <davari@broadcom.com<javascript:_e(%7B%7D,'cvml','davari@broadcom.com');>> wrote:

Anil,



I don’t agree. If you use for example BFD for inner IP, and if BFD says connectivity is OK, this implies that the Overlay connectivity is also OK, since BFD is inside the overlay.

Also I am not sure why you are adding the VNI, VSID, etc in the message as TLV, since these value are already in the packet header.



Thx
Shahram



From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)

Cc: l2vpn@ietf.org; Pradeep Jain; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt





Existing ping/traceroute mechanisms don't work in the virtualized environment e.g. ping may report that IP reachability between the ingress and egress tunnel endpoints is fine but the end systems (i.e. VM, physical server etc.) connectivity for a tenant could still be broken. This is because ping only verifies basic connectivity between two endpoints in the underlay but NOT in the context of overlay segments. Hence, we need debugging tools that work in the overlay environment. Think why there was a need to have lsp ping … requirement with IP overlays is not much different.



Question is not whether applications are resilient or not… One can not ignore the fact that operators have to think about having the right tools when that "inevitable" call  comes from their customer about deteriorating application performance or traffic blackhole and there are no tools today specific to overlay network debugging.



- Anil



From: Thomas Nadeau <tnadeau@lucidvision.com>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <