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
