netdev-owner@vger.kernel.org wrote on 05/30/2013 12:41:41 PM:

From: Stephen Hemminger <stephen@networkplumber.org>

The source port is not related to what some application receives.
A RFC conforming VXLAN endpoint will never send traffic back tot the
senders source
port. If VXLAN traffic got an ICMP response form an router like
DESTINATION_UNREACHABLE there should be a match on destination port as 

well.

It'd be sent to the source port of the sender and it need not be bound to
a remote port -- for example, a netfilter rule blocking the destination
would send an administratively-prohibited ICMP error to a UDP
application that did not trigger the traffic that caused the error.

Quite simply, VXLAN uses UDP so it needs to follow the rules of UDP.

But I don't think there's particular advantage in splitting it up 30,000
ways when 10 ways would be both practical, for binding, and spread
traffic to 10 flows potentially.

Port ranges are critical to retaining scaling in multi-path 

infrastructure.

Otherwise all traffic will arrive on a single queue in NIC.

I agree, but I don't think there need to be so many, and whatever
the VXLAN draft says, it can't  start causing problems for existing
UDP applications. VXLAN simply shouldn't be using ports allocated
to other applications; it can only do this because the implementation
is not using the real UDP stack to send the packets, but it still
should follow the rules  just as all other UDP servers must do. How
that's enforced is an implementation issue, but I think it must be
enforced.

I think it should be binding to all ports it uses as sources, and
the default range should be min and max of the bind port. People
who need to spread flows have the capability, but that doesn't mean
they need it on by default, or that it has to be so many, or that
it has carte blanche to interfere with existing UDP applications.

                                                                +-DLS