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

[Sam Aldrin <[e-mail]>]

http://datatracker.ietf.org/doc/draft-aldrin-bfd-seamless-use-case/ to start off with
On Feb 27, 2014, at 9:45 PM, Gregory Mirsky <[e-mail]> wrote:

> 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]> 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]> 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)" <
>