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

From: Kanwar Singh <[email-masked]>
Date: Thu, 27 Feb 2014 07:46:34 -0800

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.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 27 Feb 2014 15:58:07 +0000

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" <[email-masked]<mailto:[email-masked]>> wrote:

Dear All,

We have submitted the below draft that proposes Generic OAM and Datapath Failure Detection Mechanism(s) for Overlay Networks.

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.

Revision:       01

Pages:          44
URL:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-01.txt

Diff:              http://www.ietf.org/rfcdiff?url2=draft-jain-nvo3-overlay-oam-01

Abstract:

      Overlay Segment.

      Overlay Segment.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 27 Feb 2014 16:02:45 +0000

Because we also need to trace L2 endpoints besides IP endpoint.

From: Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Thursday 27 February 2014 16:58
To: Kanwar Singh <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pradeep Jain <[email-masked]<mailto:[email-masked]>>, Vinay Bannai <[email-masked]<mailto:[email-masked]>>, Ravi Shekhar <[email-masked]<mailto:[email-masked]>>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Hi

Regards,
Shahram

Dear All,

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 27 Feb 2014 11:03:49 -0500

I had precisely the same question.  Most DCs simply use IP/Enet which allow for the use of the "regular suspects" in the tools department. 

	The other concern I have with specifying new tools on top of the underlay is that the underlay probably is running some diag tools for failure detection/trouble-shooting too (like Ethernet OAM/BFD/etc...), so once again we have the issue to consider of OAM traffic consuming significant amounts of actual BW.  Given how modern applications are built and run, its unlikely we need anything heavy weight in the overlay and can instead allow for application resiliency to handle failure detection, and instead have the "normal" tools available for trouble-shooting on an as-needed basis.

	--Tom

> On Feb 27, 2014, at 7:46 AM, "Kanwar Singh" <[email-masked]> wrote:
> 
>> Dear All,
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 27 Feb 2014 11:05:40 -0500

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) <[email-masked]> wrote:

> From: Shahram Davari <[email-masked]>
> To: Kanwar Singh <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Pradeep Jain <[email-masked]>, Vinay Bannai <[email-masked]>, Ravi Shekhar <[email-masked]>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 27 Feb 2014 16:22:51 +0000

We can do this + we leveraged as much as possible the LSP ping solutions with minor extensions

From: Tom Nadeau <[email-masked]<mailto:[email-masked]>>
Date: Thursday 27 February 2014 17:05
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pradeep Jain <[email-masked]<mailto:[email-masked]>>, Vinay Bannai <[email-masked]<mailto:[email-masked]>>, Ravi Shekhar <[email-masked]<mailto:[email-masked]>>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

--Tom

On Feb 27, 2014:11:02 AM, at 11:02 AM, Henderickx, Wim (Wim) <[email-masked]<mailto:[email-masked]>> wrote:

Hi

Regards,
Shahram

Dear All,

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 27 Feb 2014 08:27:03 -0800

Hi Kanwar, et. al,
the document is certainly interesting and very detailed. But I believe that
it is rather too early to discuss applicability of particular OAM tools
without agreed upon set of requirements for NVO3 OAM and comprehensive gap
analysis.

Regards,
Greg

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 27 Feb 2014 16:57:18 +0000

Hi Greg,

I understand that it might be too early for NVO3, however there are already overlay tunnel implementations deployed and running out there, and the need for OAM extensions for it is undeniable.
So personally I would like to see this being discussed sooner than later so that we don’t end up with dozens of non-interoperable OAM tools.

I think that is why the authors want to discuss this in the L2VPN WG as well: it might be too early for NVO3 but there is a real need to discuss this now.

Thank you.
Jorge

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 27, 2014 at 8:27 AM
To: Kanwar Singh <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pradeep Jain <[email-masked]<mailto:[email-masked]>>, Vinay Bannai <[email-masked]<mailto:[email-masked]>>, Ravi Shekhar <[email-masked]<mailto:[email-masked]>>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Hi Kanwar, et. al,
the document is certainly interesting and very detailed. But I believe that it is rather too early to discuss applicability of particular OAM tools without agreed upon set of requirements for NVO3 OAM and comprehensive gap analysis.

Regards,
Greg

On Thu, Feb 27, 2014 at 7:46 AM, Kanwar Singh <[email-masked]<mailto:[email-masked]>> wrote:
Dear All,

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 27 Feb 2014 17:05:43 +0000

Hi Jorge,
I understand the motivation. Please check E-VPN Operations, Administration and Maintenance  Requirements and Framework<http://datatracker.ietf.org/doc/draft-salam-l2vpn-evpn-oam-req-frmwk/?include_text=1> and NVO3 Operations, Administration, and Maintenance Requirements<http://datatracker.ietf.org/doc/draft-ashwood-nvo3-oam-requirements/?include_text=1> respectively from l2vpn and nvo3 WGs.

                Regards,
                                Greg

From: L2vpn [mailto:[email-masked]] On Behalf Of Rabadan, Jorge (Jorge)
Sent: Thursday, February 27, 2014 8:57 AM
To: Greg Mirsky; Kanwar Singh
Cc: [email-masked]; Pradeep Jain; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Hi Greg,

I understand that it might be too early for NVO3, however there are already overlay tunnel implementations deployed and running out there, and the need for OAM extensions for it is undeniable.
So personally I would like to see this being discussed sooner than later so that we don't end up with dozens of non-interoperable OAM tools.

Thank you.
Jorge

Hi Kanwar, et. al,

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 27 Feb 2014 09:40:26 -0800

We have published a draft a while ago, <http://datatracker.ietf.org/doc/draft-kumar-nvo3-overlay-ping/>, which is on the lines of MPLS lsp ping. Primarily it is IP/udp ping  targeted for overlay networks. For NVo3 FM, there is a draft  <http://datatracker.ietf.org/doc/draft-tissa-nvo3-oam-fm/>, which will be presented in the NVo3 WG session.

Cheers
Sam
Sent from my iPad

> On Feb 27, 2014, at 8:03 AM, Thomas Nadeau <[email-masked]> wrote:
> 
>

---

From: Anil Lohiya <[email-masked]>
Date: Thu, 27 Feb 2014 18:18:35 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pradeep Jain <[email-masked]<mailto:[email-masked]>>, Vinay Bannai <[email-masked]<mailto:[email-masked]>>, Ravi Shekhar <[email-masked]<mailto:[email-masked]>>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

--Tom

Hi

Regards,
Shahram

Dear All,

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Shahram Davari <[email-masked]>
Date: Thu, 27 Feb 2014 19:19:44 +0000

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:[email-masked]] On Behalf Of Anil Lohiya
Sent: Thursday, February 27, 2014 10:19 AM
To: Thomas Nadeau; Henderickx, Wim (Wim)
Cc: [email-masked]; Pradeep Jain; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

- Anil

--Tom

Hi

Regards,
Shahram

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: David Allan I <[email-masked]>
Date: Thu, 27 Feb 2014 22:04:02 +0000

Other than allowing an OAM packet to be distinguished, I'm having trouble understanding the purpose of the nested header.  The MEP is still the receiving NVE, so it is not testing (for example) NVE to guest OS stack....

And IMO SFC will introduce new requirements as the guest OS will be a MIP.

So at this point I'm not sold!

Cheers
Dave

- Anil

--Tom

Hi

Regards,
Shahram

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: "S. Davari" <[email-masked]>
Date: Thu, 27 Feb 2014 15:50:54 -0800 (PST)

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)" <[email-masked]>
To: Shahram Davari <[email-masked]>; Kanwar Singh <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; Pradeep Jain <[email-masked]>; Vinay Bannai <[email-masked]>; Ravi Shekhar <[email-masked]> 
Sent: Thursday, February 27, 2014 8:02:45 AM
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Hi

Regards, 
Shahram

Dear All,

---

From: Kanwar Singh <[email-masked]>
Date: Thu, 27 Feb 2014 18:25:58 -0800

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 <[email-masked]>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:[email-masked]] *On Behalf Of *Anil Lohiya
> *Sent:* Thursday, February 27, 2014 10:19 AM
> *To:* Thomas Nadeau; Henderickx, Wim (Wim)
> *Cc:* [email-masked]; 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 <[email-masked]>
> *Date: *Thursday, February 27, 2014 8:05 AM
> *To: *"Henderickx, Wim (Wim)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Pradeep Jain <
> [email-masked]>, Vinay Bannai <[email-masked]>, Ravi
> Shekhar <[email-masked]>
> *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) <
> [email-masked]> wrote:
>
>
>
> *From: *Shahram Davari <[email-masked]>
> *Date: *Thursday 27 February 2014 16:58
> *To: *Kanwar Singh <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Pradeep Jain <
> [email-masked]>, Vinay Bannai <[email-masked]>, Ravi
> Shekhar <[email-masked]>
> *Subject: *Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt
>
>
>
> Hi
>
>
>

---

From: Pradeep Jain <[email-masked]>
Date: Thu, 27 Feb 2014 19:38:13 -0800

On Thursday, February 27, 2014, Pradeep Jain <[email-masked]>
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 <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> > wrote:
>
>  Anil,
>
>
>
> *To: *"Henderickx, Wim (Wim)" <
>
>
>

---

From: "S. Davari" <[email-masked]>
Date: Thu, 27 Feb 2014 19:48:05 -0800

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 <[email-masked]> 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 <[email-masked]> 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.
>> 
>> 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 <[email-masked]>
>> To: "Henderickx, Wim (Wim)" <[email-masked]>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 28 Feb 2014 04:04:06 +0000

Regarding on demand, you could define new state machine for BFD or you could use IP ping or LSP ping. You could even use Ethernet Loopback.

Regards,
Shahram

On Feb 27, 2014, at 7:38 PM, "Pradeep Jain" <[email-masked]<mailto:[email-masked]>> wrote:

On Thursday, February 27, 2014, Pradeep Jain <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

Anil,

Thx
Shahram

- Anil

From: Thomas Nadeau <[email-masked]>
Date: Thursday, February 27, 2014 8:05 AM
To: "Henderickx, Wim (Wim)" <

---

From: Anil Lohiya <[email-masked]>
Date: Fri, 28 Feb 2014 04:22:35 +0000

Shahram,

BFD can not replace the functionality provided by the overlay oam mechanism e.g. bfd can't provide the functions such as control and data plane validation, ECMP path discovery, traceroute etc.

regarding including vni, vsid etc. in TLV – control and data plane maybe out of sync due to different reasons and we can not assume that the VNI in the outer header is what user intended to validate against in its echo request. So, adding VNI explicitly in the TLV makes sure that egress is really validating what the user intended it to.

thanks
- Anil

From: Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 27, 2014 11:19 AM
To: Anil Lohiya <[email-masked]<mailto:[email-masked]>>, Thomas Nadeau <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pradeep Jain <[email-masked]<mailto:[email-masked]>>, Vinay Bannai <[email-masked]<mailto:[email-masked]>>, Ravi Shekhar <[email-masked]<mailto:[email-masked]>>
Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Anil,

Thx
Shahram

Cc: [email-masked]<mailto:[email-masked]>; Pradeep Jain; Vinay Bannai; Ravi Shekhar

- Anil

--Tom

Hi

Regards,
Shahram

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 28 Feb 2014 04:50:52 +0000

Having different OAM for IP and ETH is not very friendly to the operations people.

From: "S. Davari" <[email-masked]<mailto:[email-masked]>>
Reply-To: "S. Davari" <[email-masked]<mailto:[email-masked]>>
Date: Friday 28 February 2014 00:50
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>, Shahram Davari <[email-masked]<mailto:[email-masked]>>, Kanwar Singh <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pradeep Jain <[email-masked]<mailto:[email-masked]>>, Vinay Bannai <[email-masked]<mailto:[email-masked]>>, Ravi Shekhar <[email-masked]<mailto:[email-masked]>>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Thx
SD

________________________________
From: "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>
To: Shahram Davari <[email-masked]<mailto:[email-masked]>>; Kanwar Singh <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Pradeep Jain <[email-masked]<mailto:[email-masked]>>; Vinay Bannai <[email-masked]<mailto:[email-masked]>>; Ravi Shekhar <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 27, 2014 8:02:45 AM
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Hi

Regards,
Shahram

Dear All,

Warm Regards

- Kanwar

IETF repository.

Abstract:

   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.

   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.

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 27 Feb 2014 21:25:06 -0800

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) <[email-masked]> wrote:

> From: "S. Davari" <[email-masked]>
> Reply-To: "S. Davari" <[email-masked]>
> To: Wim Henderickx <[email-masked]>, Shahram Davari <[email-masked]>, Kanwar Singh <[email-masked]>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 28 Feb 2014 05:25:52 +0000

Hi Wim,
I haven't heard any complains from NOCs operating any multi-layer transport network. You have TDM/OTN OAM, Ethernet Service OAM, and IP OAM (sort of). I think this is pretty common though DC operators might see it differently.

                Regards,
                                Greg

From: L2vpn [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Wim)
Sent: Thursday, February 27, 2014 8:51 PM
To: S. Davari; Shahram Davari; Kanwar Singh
Cc: [email-masked]; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Thx
SD

Hi

Regards,
Shahram

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 28 Feb 2014 05:32:39 +0000

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:[email-masked]] On Behalf Of Sam Aldrin
Sent: Thursday, February 27, 2014 9:25 PM
To: Henderickx, Wim (Wim)
Cc: [email-masked]; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

-sam
On Feb 27, 2014, at 8:50 PM, Henderickx, Wim (Wim) <[email-masked]<mailto:[email-masked]>> wrote:

Thx
SD

Hi

Regards,
Shahram

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Shahram Davari <[email-masked]>
Date: Fri, 28 Feb 2014 05:35:57 +0000

But having a brand newly invented OAM is friendly ?

Regards,
Shahram

On Feb 27, 2014, at 8:51 PM, "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>> wrote:

Thx
SD

Hi

Regards,
Shahram

Dear All,

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 27 Feb 2014 21:36:58 -0800

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 <[email-masked]> 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: Shahram Davari <[email-masked]>
Date: Fri, 28 Feb 2014 05:37:40 +0000

I didn't suggest extrapolation. I think you even don't know your OAM is running at which later.

Regards,
Shahram

On Feb 27, 2014, at 9:25 PM, "Sam Aldrin" <[email-masked]<mailto:[email-masked]>> wrote:

-sam

Thx
SD

Hi

Regards,
Shahram

Dear All,

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 27 Feb 2014 21:39:23 -0800

and where does it say 'you said it'.

On Feb 27, 2014, at 9:37 PM, Shahram Davari <[email-masked]> wrote:

> On Feb 27, 2014, at 9:25 PM, "Sam Aldrin" <[email-masked]> wrote:
>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 28 Feb 2014 05:45:43 +0000

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:[email-masked]] On Behalf Of Pradeep Jain
Sent: Thursday, February 27, 2014 7:38 PM
To: Shahram Davari
Cc: [email-masked]; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Regards
Pradeep

Anil,

Thx
Shahram

- Anil

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 27 Feb 2014 21:50:09 -0800

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 <[email-masked]> 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
>  
> On Thursday, February 27, 2014, Pradeep Jain <[email-masked]> wrote:
> Hi Shahram,
>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 28 Feb 2014 06:02:19 +0000

This is basically the same procedure as people OAM IP/MPLS networks. If it is not friendly why do we keep on extending these mechanisms

From: Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Friday 28 February 2014 06:35
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>
Cc: "S. Davari" <[email-masked]<mailto:[email-masked]>>, Kanwar Singh <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pradeep Jain <[email-masked]<mailto:[email-masked]>>, Vinay Bannai <[email-masked]<mailto:[email-masked]>>, Ravi Shekhar <[email-masked]<mailto:[email-masked]>>
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Regards,
Shahram

Thx
SD

Hi

Regards,
Shahram

Dear All,

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 28 Feb 2014 06:05:07 +0000

I let NOC people comment on there own, but this is feedback I received from people operating these deployments. In this space you basically have IP and ETH, so lets optimise this rather than making life difficult for people.

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday 28 February 2014 06:25
To: Wim Henderickx <[email-masked]<mailto:[email-masked]>>, "S. Davari" <[email-masked]<mailto:[email-masked]>>, Shahram Davari <[email-masked]<mailto:[email-masked]>>, Kanwar Singh <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Vinay Bannai <[email-masked]<mailto:[email-masked]>>, Ravi Shekhar <[email-masked]<mailto:[email-masked]>>
Subject: RE: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Hi Wim,
I haven’t heard any complains from NOCs operating any multi-layer transport network. You have TDM/OTN OAM, Ethernet Service OAM, and IP OAM (sort of). I think this is pretty common though DC operators might see it differently.

                Regards,
                                Greg

Cc: [email-masked]<mailto:[email-masked]>; Vinay Bannai; Ravi Shekhar

Thx
SD

Hi

Regards,
Shahram

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 28 Feb 2014 06:08:57 +0000

Hi Wim,
I think it is reasonable to start with requirements before diving into discussion of a solution. Input from operators would be most valuable.

                Regards,
                                Greg

From: Henderickx, Wim (Wim) [mailto:[email-masked]]
Sent: Thursday, February 27, 2014 10:05 PM
To: Gregory Mirsky; S. Davari; Shahram Davari; Kanwar Singh
Cc: [email-masked]; Vinay Bannai; Ravi Shekhar
Subject: Re: Request for comments: draft-jain-nvo3-overlay-oam-01.txt

Hi Wim,

                Regards,
                                Greg

Thx
SD

Hi

Regards,
Shahram

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 28 Feb 2014 07:59:39 +0000

sure

Date: Friday 28 February 2014 07:08

Hi Wim,

                Regards,
                                Greg

Hi Wim,

                Regards,
                                Greg

Thx
SD

Hi

Regards,
Shahram

Warm Regards

- Kanwar

IETF repository.

Abstract:

---

From: Pradeep Jain <[email-masked]>
Date: Thu, 27 Feb 2014 19:04:06 -0800

Hi Shahram,

Regards
Pradeep