On Thu, May 30, 2013 at 12:44:24PM +0100, Thomas Graf wrote:

On 05/30/13 at 11:42am, Mike Rapoport wrote:

quoted

On Thu, May 30, 2013 at 1:56 AM, Stephen Hemminger
[off-list ref] wrote:

quoted

On Wed, 29 May 2013 13:52:55 +0300
Mike Rapoport [off-list ref] wrote:

quoted

Frankly, I had a long hesitation about the userspace implementation.
From one side it seems very logical to use ip/iplink_vxlan for vxlan
device manipulations. Moreover, since the remotes are used pretty much
the same way as the group address, adding the remotes management to
ip/iplink_vxlan makes a lot of sense. Besides, creation of stand alone
tool for remote list manipulation in vxlan seemed to me little bit far
fetched.

On the other hand, I quite agree with you that
ip link add vxlan0 ... dstadd 192.168.1.1
or
ip link set vxlan0 ... dstdel 192.168.1.1
looks weird at least.

Don't like add/delete semantics here either.
Maybe replace or modify,

I think that replace or modify do not express the actual operation
meaning. My intention with dstadd was "add remote host X to
pseudo-multicast group". Replace/modify maybe nice to have features to
avoid doing delete+ add.

The alternative would be to require iproute2 to always provide the
full list of remote addresses like we do we route nexthops.

I do like the add/del though and don't see a problem with requiring
an ''ip link set [..] dstadd/dstdel''

I'm feeling Ok about "ip link set [..] dstadd/dstdel". What does bother
me is that you can't have different parameters for "ip link add" and "ip
link set" for vxlan (and other iplink) utility. So, one can use
ip link add [..] dstdel
which does not make sense...

quoted

quoted

or has this grown enough that having its own
command line tool "vxlan ..." makes sense?

Say, misc/vxlan that will handle remote destinations management? Or
should it take care of some vxlan parameters currently implemented in
ip/iplink_vxlan and bridge/fdb?

What do we gain from a separate tool?

--
Sincerely yours,
Mike.