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:[email protected]] Sent: Tuesday, March 04, 2014 5:58 AM To: Tissa Senevirathne (tsenevir); [email protected] 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>
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
