Subject: [nvo3] Follow up on draft-tissa-nvo3-oam-fm

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 3 Mar 2014 16:01:56 +0000

There was a question on why payload sample is needed in OAM.

Firstly it is an optional field and not always required.

It is expected to be useful when using L2VNI + L3VNI at the same NVE to provide L3 gateway services to clients on L2VNI. Reference is draft-ietf-nvo3-dataplane-requirements-02, section 3.2.2 second last paragraph, please see below section for reference. At the L2VNI/L3VNI GW the sample payload is needed to make the ECMP path selection on the next domain (i.e L3VNI when L2VNI to L3VNI and vise versa).

Reference second last paragraph of section 3.2.2 of draft-ietf-nvo3-dataplane-requirements-02
"       L2 and L3 VNIs can be deployed in isolation or in combination to
       optimize traffic flows per tenant across the overlay network. For
       example, an L2 VNI may be configured across a number of NVEs to
       offer L2 multi-point service connectivity while a L3 VNI can be co-
       located to offer local routing capabilities and gateway
       functionality. In addition, integrated routing and bridging per
       tenant MAY be supported on an NVE. An instantiation of such service
       may be realized by interconnecting an L2 VNI as access to an L3 VNI
       on the NVE."

---

From: David Allan I <[email-masked]>
Date: Mon, 3 Mar 2014 16:17:01 +0000

HI Tissa:

My understanding of at least one of the proposed NVO3 encaps (VxLAN), is that the entropy has already been encoded in the source port. I would assume any L3 VNI encap would require a similar property for ECMP to perform useful load spreading as ECMP would only examine the outer header.

So the information to utilize distributed gateways would already exist, and sufficient information exists for OAM to fate share in a trail that spanned an L2 and L3 VNI. N'est pas?

That's the view from here!
Dave

From: nvo3 [mailto:[email-masked]] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Monday, March 03, 2014 4:02 PM
To: [email-masked]
Subject: [nvo3] Follow up on draft-tissa-nvo3-oam-fm

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 3 Mar 2014 16:38:42 +0000

Hi David

Thanks for the response and raising a  very important point.

At GW NVE , we need L3 information to select the NVE on the L3 cloud to forward the packet.

Originator NVE has to use the GW Dest IP (GW NVE address) i.e. Packet on  (x space)  use Dest IP of NVEGW and packet on (y space) use Dest NVE B. NVE GW has to make a lookup on the payload to get NVEB address. We will have multiple NVE on the B space.

++++++       ( x space  )          +++++++++++     (y space)                 +++++++++
| NVEA|---------------------- | NVE GW   |  ------------------------ |NVE B     |
++++++                                   +++++++++++                                       +++++++++

If needed we can quickly discuss face to face too, please let me know

Thanks
Tissa

From: David Allan I [mailto:[email-masked]]
Sent: Monday, March 03, 2014 8:17 AM
To: Tissa Senevirathne (tsenevir); [email-masked]
Subject: RE: Follow up on draft-tissa-nvo3-oam-fm

HI Tissa:

From: nvo3 [mailto:[email-masked]] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Monday, March 03, 2014 4:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] Follow up on draft-tissa-nvo3-oam-fm

---

From: David Allan I <[email-masked]>
Date: Mon, 3 Mar 2014 16:49:52 +0000

HI Tissa:

Yes. And a GW would need to examine the client payload of frames received from "x-space" to determine the L3 destination of interest in "y-space". And encode the relevant entropy in the overlay header to permit multipath. Easiest approach for such a GW would be to be able to copy the entropy from the received overlay header.  Same would apply in the reverse direction. So the GWs appear as VTEPs in x-space and in Y-space in the role of next hops to whomever....

That there is a problem is not leaping out at me. You're going to have to clarify. Is this a shortcoming in the drafts?

Cheers
Dave

From: David Allan I [mailto:[email-masked]]
Sent: Monday, March 03, 2014 8:17 AM
To: Tissa Senevirathne (tsenevir); [email-masked]<mailto:[email-masked]>
Subject: RE: Follow up on draft-tissa-nvo3-oam-fm

HI Tissa:

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 3 Mar 2014 19:55:23 +0000

Hi David

Please see in-line

From: David Allan I [mailto:[email-masked]]
Sent: Monday, March 03, 2014 8:50 AM
To: Tissa Senevirathne (tsenevir); [email-masked]
Subject: RE: Follow up on draft-tissa-nvo3-oam-fm

HI Tissa:

[Tissa] What is the definition of Entropy in the above ? especially in the context "able to copy the entropy from the received overlay header..."

Cheers
Dave

HI Tissa:

---

From: Haoweiguo <[email-masked]>
Date: Tue, 4 Mar 2014 11:15:29 +0000

Hi Tissa,

I think this draft is very similar to TRILL OAM framework. The entropy data in TRILL OAM is for flow-based load balancing to ensure OAM packet forwarding same path
as detected data packet in ECMP case.
For NVO3 network, flow-based load balancing relies on NVO3 outer header,so this entropy data has no any use for load balancing.

In hierarchical NVO3 network scenario, the interworking gateway gateway relies on destination NVE IP
address and source UDP port(or GRE key) to make the ECMP path selection, if the source UDP port is allocated in random mode on interworking
gateway, the entropy data can be used for the gateway to acquire source UDP port(in VXLAN case) and destination NVE IP. But if ingress NVE knows the Udp port on interworking gateway in beforehand, it can carry the information in OAM TLV message directly instead of entropy data.

thanks

weiguo

________________________________
发件人: Tissa Senevirathne (tsenevir) [[email-masked]]
发送时间: 2014年3月4日 3:55
收件人: David Allan I; [email-masked]
主题: Re: [nvo3] Follow up on draft-tissa-nvo3-oam-fm

Hi David

Please see in-line

HI Tissa:

Yes. And a GW would need to examine the client payload of frames received from “x-space” to determine the L3 destination of interest in “y-space”. And encode the relevant entropy in the overlay header to permit multipath. Easiest approach for such a GW would be to be able to copy the entropy from the received overlay header.  Same would apply in the reverse direction. So the GWs appear as VTEPs in x-space and in Y-space in the role of next hops to whomever….

[Tissa] What is the definition of Entropy in the above ? especially in the context “able to copy the entropy from the received overlay header…”

That there is a problem is not leaping out at me. You’re going to have to clarify. Is this a shortcoming in the drafts?

Cheers
Dave

HI Tissa:

So the information to utilize distributed gateways would already exist, and sufficient information exists for OAM to fate share in a trail that spanned an L2 and L3 VNI. N’est pas?

That’s the view from here!
Dave

“       L2 and L3 VNIs can be deployed in isolation or in combination to
       on the NVE.”

---

From: David Allan I <[email-masked]>
Date: Tue, 4 Mar 2014 13:57:38 +0000

HI Tissa:

There was a question unanswered in your message apologies.... In line:
Thanks for the response and raising a  very important point.

[Tissa] What is the definition of Entropy in the above ? especially in the context "able to copy the entropy from the received overlay header..."
For VxLAN at least, a hash of the customer payload is put in the source port of the VX LAN excapsulating header, such that 5 tuple ECMP on the transport layer has the additional entropy information available to it.  That was the entropy I was referring to. SO my point was that there was no point in encapsulating the x bytes of customer header in an OAM frame, it is not needed,  the basic information has already been distilled and is present in the VXLAN header.

I hope that's clear
Dave

<snipped to end>

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 5 Mar 2014 07:50:15 +0000

Hi David

Thanks for the response. If consensus is to remove the optional payload sample we can remove it ; it is not needed for majority of cases.

Having said that, I still do not agree below with your argument for this specific case that client payload sample is not needed. In other words, leaving OAM a side, it is a good discussion to have on how a packet would go through this specific use case in section 3.2.2 of the data-plane document.

Below is the relevant section from the thread, see my Answer/question on [Tissa-2], below within the context.

---------------------------------------------------------------
At GW NVE , we need L3 information to select the NVE on the L3 cloud to forward the packet.

[Tissa-2] GW need the actual destination IP address of the L3-NVE that packet needed to be forwarded. Source port alone is not enough. I am not clear if we do not have the payload how could the GW decide which L3-NVE that it needed the packet to be forwarded. Assuming there are more than one L3-NVE on the L3 side, GW needed to derive that information some how.

From: David Allan I [mailto:[email-masked]]
Sent: Tuesday, March 04, 2014 5:58 AM
To: Tissa Senevirathne (tsenevir); [email-masked]
Subject: RE: Follow up on draft-tissa-nvo3-oam-fm

HI Tissa:

I hope that's clear
Dave

<snipped to end>