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

[David Allan I <[e-mail]>]

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>