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

[Gregory Mirsky <[e-mail]>]

Hi Pradeep,
I'd refer you to documents on Seamless BFD that, in many aspects, requirements you've listed. Even though BFD WG would not meet in London, we can have a talk about S-BFD and NVO3 OAM requirements.

                Regards,
                                Greg

From: L2vpn [mailto:[e-mail]] On Behalf Of Pradeep Jain
Sent: Thursday, February 27, 2014 7:38 PM
To: Shahram Davari
Cc: [e-mail]; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt



On Thursday, February 27, 2014, Pradeep Jain <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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]<mailto:[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]<mailto:[e-mail]>>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <