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

["S. Davari" <[e-mail]>]

Cloud provider could easily inject and remove BFD packets encapsulated as overlay. This can easily be done with some reserved MAC or IP address. 

Regards,
Shahram


> On Feb 27, 2014, at 6:25 PM, Kanwar Singh <[e-mail]> wrote:
> 
> 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:
>> 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]>et>, 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]>et>, 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.
>