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

["Tissa Senevirathne (tsenevir)" <[e-mail]>]

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.

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..."
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.

[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:[e-mail]]
Sent: Tuesday, March 04, 2014 5:58 AM
To: Tissa Senevirathne (tsenevir); [e-mail]
Subject: RE: Follow up on draft-tissa-nvo3-oam-fm

HI Tissa:

There was a question unanswered in your message apologies.... In line:
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.

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..."
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>