Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751603AbdFHSKp (ORCPT ); Thu, 8 Jun 2017 14:10:45 -0400 Received: from chaos.universe-factory.net ([31.24.148.19]:57490 "EHLO chaos.universe-factory.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751516AbdFHSKn (ORCPT ); Thu, 8 Jun 2017 14:10:43 -0400 X-Greylist: delayed 327 seconds by postgrey-1.27 at vger.kernel.org; Thu, 08 Jun 2017 14:10:43 EDT Subject: Re: [PATCH net-next v2 6/6] vxlan: allow multiple VXLANs with same VNI for IPv6 link-local addresses From: Matthias Schiffer To: Stephen Hemminger Cc: davem@davemloft.net, jbenc@redhat.com, hannes@stressinduktion.org, pshelar@ovn.org, aduyck@mirantis.com, roopa@cumulusnetworks.com, netdev@vger.kernel.org, dev@openvswitch.org, linux-kernel@vger.kernel.org References: <95533e3ca4958ba2eca3efcc661713638feea220.1492187126.git.mschiffer@universe-factory.net> <20170414103830.111a24a8@xeon-e3> <3c054ae3-ec68-ab20-0928-81e313a53cde@universe-factory.net> Message-ID: <18df22e2-cbf4-e25a-b2d2-87e01281d9f4@universe-factory.net> Date: Thu, 8 Jun 2017 20:05:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <3c054ae3-ec68-ab20-0928-81e313a53cde@universe-factory.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iw4JQ2UWilHTUBmLPwW1aFGT04pq62P0j" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4931 Lines: 123 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iw4JQ2UWilHTUBmLPwW1aFGT04pq62P0j Content-Type: multipart/mixed; boundary="mBReMgN2SIwobkmjBAfw3qa9tc9Kd8b7F"; protected-headers="v1" From: Matthias Schiffer To: Stephen Hemminger Cc: davem@davemloft.net, jbenc@redhat.com, hannes@stressinduktion.org, pshelar@ovn.org, aduyck@mirantis.com, roopa@cumulusnetworks.com, netdev@vger.kernel.org, dev@openvswitch.org, linux-kernel@vger.kernel.org Message-ID: <18df22e2-cbf4-e25a-b2d2-87e01281d9f4@universe-factory.net> Subject: Re: [PATCH net-next v2 6/6] vxlan: allow multiple VXLANs with same VNI for IPv6 link-local addresses References: <95533e3ca4958ba2eca3efcc661713638feea220.1492187126.git.mschiffer@universe-factory.net> <20170414103830.111a24a8@xeon-e3> <3c054ae3-ec68-ab20-0928-81e313a53cde@universe-factory.net> In-Reply-To: <3c054ae3-ec68-ab20-0928-81e313a53cde@universe-factory.net> --mBReMgN2SIwobkmjBAfw3qa9tc9Kd8b7F Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/16/2017 05:15 PM, Matthias Schiffer wrote: > On 04/14/2017 07:38 PM, Stephen Hemminger wrote: >> On Fri, 14 Apr 2017 18:44:46 +0200 >> Matthias Schiffer wrote: >> >>> As link-local addresses are only valid for a single interface, we can= allow >>> to use the same VNI for multiple independent VXLANs, as long as the u= sed >>> interfaces are distinct. This way, VXLANs can always be used as a dro= p-in >>> replacement for VLANs with greater ID space. >>> >>> This also extends VNI lookup to respect the ifindex when link-local I= Pv6 >>> addresses are used, so using the same VNI on multiple interfaces can >>> actually work. >>> >>> Signed-off-by: Matthias Schiffer >> >> Why does this have to be IPv6 specific? >=20 > I'm not familar with IPv4 link-local addresses and how route lookup wor= ks > for them. vxlan_get_route() sets flowi4_oif to the outgoing interface; = does > __ip_route_output_key_hash() do the right thing for link-local addresse= s > when such addresses are used on multiple interfaces? I see some special= > casing for multicast destinations, but none for link-local ones. >=20 Getting back to this (sorry for the delay, I got caught up in other projects), I'm seeing the following pros and cons regarding the support o= f VXLAN over IPv4 link-local addresses: + There should be no technical reason not to support it; as everything is= in the kernel, the usual problems with IPv4 LL (userspace APIs not supporting passing a scope ID as part of the IP address) don't apply here= + The code needed to support IPv4 LL should be easy to add - IPv4 LL semantics aren't as well-defined as for IPv6. While IPv4 LL addresses are usually in the 169.254.x.y range, the Linux kernel allows setting the address scope independently of the range for IPv4. In contras= t to this, we need to judge the validity of the configuration based on syntactic properties of the IP addresses (at least if we don't want to ad= d a lot of more compexity to the validation, and probably other parts of th= e code.) Generally, code that checks for the 169.254.x.y range is uncommon = in the kernel (I think I only found a single instance, somewhere in the SCTP= implementation.) - IPv4 LL addresses are mostly used for zeroconf; I don't really see a usecase for zeroconf addresses + VXLANs - Personally, I have no interest in IPv4 I probably forgot a few more arguments... All in all, I'd like the VXLAN maintainers to decide if we do want IPv4 LL support or not, and if the verdict is to support it, I'll implement it in the next revision of my patchset. Matthias --mBReMgN2SIwobkmjBAfw3qa9tc9Kd8b7F-- --iw4JQ2UWilHTUBmLPwW1aFGT04pq62P0j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEZmTnvaa2aYgexS51Fu8/ZMsgHZwFAlk5kdMACgkQFu8/ZMsg HZwLtBAAmdTtydVvMCvt/RYhvrzfcJhCQt6uhtzWcyk5YgX7wD53M0WIA7kigtTB Mpr+/+/1/oSRGJpbe9X/KtqsglPtAOsvNBQk2eYTmwOCMqPLIz3lNOVH204BZa8+ NnjXTqHL89IQduPFU+MZAeO//aBvCnfRZEDXk9cfHTQFAl8eYAI62yb/txlpQ0RO gSXcD37PbdC3DMY3c0zICY6hDI02iiZyorPsRq/mNDm1NUMjBBj5yMPOetJqtHXg vZk6XY8QxCYicuKeEnM5n4FBljajVPt0LYzxFnYZYZfCwtNZyrjRPvmxEINj51jk NN/mFXgpkeI9VchzCkBiUBynpbevxKLQpj4GmOf/Sl5E/TtK9GTZG5pXFOl3gR4h Acw8G3AW/+zZGIpbHKI1LBowjGo1cvyEj3Vt2JnHF0F6co3ptRmlgbcasuv/d3RY AD0ULKRl74/ggN3zgokWdFjjBiOOljJOOXTlMkIohAG3DkOxkc7O0gmqCKK9av6S gZiI6Bqdk9QkYOjRMYQco3HerxY5HC0OMNQrdnAIxyzF5SAu5R10XYeI3q2x29XQ Nk9gcOt0uHhUuPHiViF/5UxcHls+XUSc5Hnd2DzLQS1dQ5KwvaQyp7YFB1Tsm8yW iBb0nNWWgYVat1AwiS5yako2I+vk/eC04cCyrHAt7c6PzIy+BbA= =WxlP -----END PGP SIGNATURE----- --iw4JQ2UWilHTUBmLPwW1aFGT04pq62P0j--