netdev - Re: [PATCH 1/2] mpls: add handlers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Aug 2017 22:30:21 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     David Lamparter <equinox@...c24.net>
Cc:     Amine Kherbouche <amine.kherbouche@...nd.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/2] mpls: add handlers

On Tue, Aug 15, 2017 at 2:37 AM, David Lamparter <equinox@...c24.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.