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

[Thomas Graf <tgraf@suug.ch>]

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