netdev - Re: [PATCH WIP RFC 0/3] mpls: support for ler

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150608225843.GA4602@pox.localdomain>
Date:	Tue, 9 Jun 2015 00:58:43 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	roopa <roopa@...ulusnetworks.com>
Cc:	Robert Shearman <rshearma@...cade.com>, ebiederm@...ssion.com,
	netdev@...r.kernel.org,
	Vivek Venkatraman <vivek@...ulusnetworks.com>
Subject: Re: [PATCH WIP RFC 0/3] mpls: support for ler

On 06/08/15 at 08:17am, roopa wrote:
> ack, that sounds intuitive.
> With RTA_ENCAP and the mpls examples i was using it looks something like the
> below for (1)
> ip route add 10.1.1.0/30 encap mpls 200 via 10.1.1.1 dev eth0
> 
> The tunnel dst is parsed and understood by the light weight tunnel driver,
> which I think will
> end up having to do the lookup (needs more thought)...for (2) and (3).

I think we only want to perform the nested fib lookup if no dev
is specified. If a tunnel device is specified, that device will
do the fib lookup and can cache the route in the encap socket.

> >Your nexthop implementation seemed more correct based on the chunks
> >I went through. Can we combine the two series and make the RTA_OIF
> >in the nexthop optional if an RTA_ENCAP was provided and provide a
> >route lookup instead?
> 
> yes, we can do that.
>  Robert can correct me if i misunderstood, both our patches had similar code
> to handle RTA_ENCAP.
> Only difference was in the way we stored the encaped data, mine was a
> pointer to tunnel state and his was embedded in fib_nh. His patch today
> assumes there is a tunnel device.
> And mine assumes the output device is specified in the ipv4 fib route.

I'll immediately ACK any series that supports both models and rebase
my patches on top of it. I think we are on the right track overall.

> I am trying to get my code on github to collaborate better. Stay tuned
> (hopefully end of day today).

Cool

> While we are on this conversation, Though the code already supports nested
> attributes (with the example robert showed), I introduced explicit nested
> attributes for mpls in my version,
> and it seemed like it is better to introduce two attributes RTA_ENCAP_TYPE
> and RTA_ENCAP and
> type determines the nested policy for RTA_ENCAP
> RTA_ENCAP_TYPE /* MPLS, VXLAN etc */

+1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html