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

[Sam Aldrin <[e-mail]>]

Hi Greg,

I do not think solution will get ahead of requirements :D
But it is good to think through solutions as long it feeds into better requirements and explore reusability of existing solutions/architecture.

-sam
On Feb 27, 2014, at 9:32 PM, Gregory Mirsky <[e-mail]> wrote:

> Hi Sam,
> wholeheartedly agree with “The goal is to have 'the' solution meeting the requirements.” Yes! Let’s work on requirements, draft-ashwood-nvo3-oam-requirements seems as good start already, and then feed into draft-ietf-nvo3-gap-analysis.
>  
>                 Regards,
>                                 Greg
> From: L2vpn [mailto:[e-mail]] On Behalf Of Sam Aldrin
> Sent: Thursday, February 27, 2014 9:25 PM
> To: Henderickx, Wim (Wim)
> Cc: [e-mail]; Vinay Bannai; Ravi Shekhar
> Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt
>  
> Performing OAM at overlay layer is very important. Extrapolating faults from underlying layers may provide certain degree of measurement but cannot completely fulfill the need. This applies to NVo3 as well, IMO.
> If there are existing mechanisms, one should be able to make use of it, without having to redo the same.
>  
> Having said that, we initially published a solution draft around Berlin IETF. We now have three drafts targeting solution (excluding BFD :D). The goal is to have 'the' solution meeting the requirements. If BFD or any other existing solutions meet those, it would be good to outline that (informational doc?)
>  
> Looking forward to a good discussion about OAM solution in the NVo3 WG session.
>  
> -sam
> On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) <[e-mail]> wrote:
> 
> 
> Having different OAM for IP and ETH is not very friendly to the operations people.
>  
> From: "S. Davari" <[e-mail]>
> Reply-To: "S. Davari" <[e-mail]>
> Date: Friday 28 February 2014 00:50
> To: Wim Henderickx <[e-mail]>om>, Shahram Davari <[e-mail]>om>, 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
>  
> I meant using BFD inside the payload. not for the outer tunnel. You could also use Ethernet OAM for L2 endpoints.
> 
> Thx
> SD
>  
>  
> From: "Henderickx, Wim (Wim)" <[e-mail]>
> To: Shahram Davari <[e-mail]>om>; Kanwar Singh <[e-mail]> 
> Cc: "[e-mail]" <[e-mail]>rg>; Pradeep Jain <[e-mail]>et>; Vinay Bannai <[e-mail]>om>; Ravi Shekhar <[e-mail]> 
> Sent: Thursday, February 27, 2014 8:02:45 AM
> Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt
>  
> 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.