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

[Kanwar Singh <[e-mail]>]

Hi Shahram,



Regarding BFD for Inner IP, it seems you are suggesting that BFD needs to
be running in between two End-System(s) (i.e. Guest VM/Tenant) using the
Overlay. But, Cloud providers would  not necessarily want to rely on
applications running in Guest OS/Tenant  to verify connectivity of their
Networks. In-fact, in most cases Cloud Providers won't even have access to
Guest / Tenant VMs to launch such applications.



Thanks,

Kanwar


On Thu, Feb 27, 2014 at 11:19 AM, Shahram Davari <[e-mail]>wrote;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:[e-mail]] *On Behalf Of *Anil Lohiya
> *Sent:* Thursday, February 27, 2014 10:19 AM
> *To:* Thomas Nadeau; Henderickx, Wim (Wim)
> *Cc:* [e-mail]; 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 <[e-mail]>
> *Date: *Thursday, February 27, 2014 8:05 AM
> *To: *"Henderickx, Wim (Wim)" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>rg>, Pradeep Jain <
> [e-mail]>gt;, Vinay Bannai <[e-mail]>om>, Ravi
> Shekhar <[e-mail]>
> *Subject: *Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt
>
>
>
>
>
> The question is, and perhaps the draft could explain this, is why existing
> tools a) are insufficient and b) cannot be modified.
>
> Operationally speaking, b is preferred if you ask me as learning a new
> tool/model for diagnosis and trouble-shooting is expensive and painful.
>
> For example, if we took the tact of reinventing say IP ping for every
> underlying transport, then we'd have 50 tools by now.
>
>
>
> --Tom
>
>
>
>
>
>
>
> On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) <
> [e-mail]> wrote:
>
>
>
>   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]>gt;, 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.
>
>
>