Re: [PATCH 2/2] drivers: add vpls support

On Sat, Aug 12, 2017 at 6:40 AM, Amine Kherbouche
[off-list ref] wrote:

On 11/08/2017 17:14, Roopa Prabhu wrote:

quoted

On Fri, Aug 11, 2017 at 5:55 AM, David Lamparter [off-list ref]
wrote:

quoted

On Thu, Aug 10, 2017 at 10:28:37PM +0200, Amine Kherbouche wrote:

quoted

This commit introduces the support of VPLS virtual device, that allows
performing  L2VPN multipoint to multipoint communication over MPLS PSN.

VPLS device encap received ethernet frame over mpls packet and send it
the
output device, in the other direction, when receiving the right
configured
mpls packet, the matched mpls route calls the handler vpls function,
then pulls out the mpls header and send it back the entry point via
netif_rx().

Two functions, mpls_entry_encode() and mpls_output_possible() are
exported from mpls/internal.h to be able to use them inside vpls driver.

Signed-off-by: Amine Kherbouche <redacted>

[snip]

quoted

[...]

quoted

+union vpls_nh {
+     struct in6_addr         addr6;
+     struct in_addr          addr;
+};
+
+struct vpls_dst {
+     struct net_device       *dev;
+     union vpls_nh           addr;
+     u32                     label_in, label_out;
+     u32                     id;
+     u16                     vlan_id;

I looked at VLAN support and decided against it because the bridge layer
can handle this perfectly fine by using the bridge's vlan support to tag
a port's pvid.

yes, agreed. there is no need for vlan here. The bridge can be
configured with the required vlan
mapping on the vpls port.

what if the output device cannot handle vlan encapsulation? because on my
example of configuration in the cover letter, I sent the vpls packets over
a simple physical net device (not a bridge nor a vlan port).

There are already multiple ways vlan encap is added today, eg vlan
device, under a bridge, using tc etc. I don't think every driver
should carry vlan encap info. see vxlan as an example, it does
not....you can use a bridge or tc etc for the vlan to vni map. You
will need a bridge anyways for fwding db, stp etc in such deployments.

We can add vlan in the future if it becomes necessary. I don't see a need today.