On 08/16/2017 07:30 AM, Roopa Prabhu wrote:
On Tue, Aug 15, 2017 at 2:37 AM, David Lamparter <equi...@diac24.net> wrote: [snip]I think the reverse is the better option, removing the vpls device information and just going with the route table. My approach to this would be to add a new netlink route attribute "RTA_VPLS" which identifies the vpls device, is stored in the route table, and provides the device ptr needed here. (The control word config should also be on the route.) My reason for thinking this is that the VPLS code needs exactly the same information as does a normal MPLS route: it attaches to an incoming label (decapsulating packets instead of forwarding them), and for TX it does the same operation of looking up a nexthop (possibly with ECMP support) and adding a label stack. The code should, in fact, probably reuse the TX path. This also fits both an 1:1 and 1:n model pretty well. Creating a VPLS head-end netdevice doesn't even need any config. It'd just work like: - ip link add name vpls123 type vpls - ip -f mpls route add \ 1234 \ # incoming label for decap vpls vpls123 \ # new attr: VPLS device as 2345 via inet 10.0.0.1 dev eth0 # outgoing label for encap For a 1:n model, one would simply add multiple routes on the same vpls device.this is a nice model too. But, i don't see how vlans and mac based learning will fit in here. modeling it same as how vxlan l2 overlay tunnels are done seems like a great fit. The vpls driver can learn mac's per pw tunnel labels. And this l2 fdb table per vpls device can also carry dst information similar to how vxlan driver does today.
I think this is a good idea too, I'll implement this concept in mpls and have a look at the way vxlan is done to be able to support the l2 part in vpls driver.
Thanks
