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

[Thomas Graf <tgraf@suug.ch>]

On 06/05/15 at 07:54pm, roopa wrote:
> On 6/5/15, 8:26 AM, Robert Shearman wrote:
> >
> >It isn't clear to me what the strategy here is for dealing with tunnel
> >encaps that aren't bound to an interface.
> >
> >Thomas, I presume you would prefer not to force the user to keep track of
> >changes to the output interface and nexthop corresponding to the
> >destination of the outer IP header? And I presume that Eric is opposed to
> >the option of using a virtual interface here, i.e. falling back to the
> >approach I proposed?
> >
> >In which case, what will the nexthop output interface be set to?
> >Logically, it should have no interface. At the moment, the code assumes
> >that a nexthop will have a valid interface and I don't have a feel for
> >what the impact would be of changing that.
> 
> The nexthop interface is the final output interface. Any reason it should
> not be ?

Yes, the information used to determine the encapsulation and the
route used to select the outgoing interface might be coming from
different components. A simple and typical example is if you are
running quagga to for your underlay which determines which interface
to use for which tunnel endpoints. On top of that, somebody is
maintaining your virtual networks which is only aware of the tunnel
endpoint IP addresses but does not want to manage how to actually
reach them. So you would have:

ip route add 10.1.1.0/24 via tunnel 20.1.1.1 id 100 [dev vxlan0]
ip route add 20.1.1.1/24 dev eth0 

I've put "dev vxlan0" in brackets for now to indicate that it is
optional. I'm also using VXLAN as an examples as I think it's
easier to understand this separation of concern here. The point
is, whoever is adding the route with the encap information may
not know what interface to use to reach 20.1.1.1 and we may want
to rely on existing routes.

I think we want to support three models:

1. nexthop has encap and outgoing interface
   ip route add 10.1.1.0/24 via tunnel 20.1.1.1 dev eth0
   ip route add 20.1.1.1/24 dev eth0 

2. nexthop has endpoint but no dev
   ip route add 10.1.1.0/24 via tunnel 20.1.1.1
   ip route add 20.1.1.1/24 dev eth0 

   This would indicate to the routing subsystem to perform a
   fib lookup on 20.1.1.1 to determine the outgoing interface.

3. virtual tunnel interface to share configuration among routes
   ip route add 10.1.1.0/24 via tunnel 20.1.1.1 dev vxlan0
   ip route add 20.1.1.1/24 dev eth0

I think all of them are intuitive and easy to implement. This will
also allow to incorporate the bridge model.

> >However, with that resolved I'd be happy to work on a series together. The
> >remaining issue is whether to optimise for small encap that reside in the
> >same memory block as the fib_info, which aren't refcounted but instead are
> >copied around, or larger encaps that reside in their own memory block that
> >are refcounted and only a pointer passed around.
> I would prefer the latter (as shown in my incomplete patch) simply because
> it stays separate from fib_info and allows for extending it in the future.

I'm with Roopa on this one. Simply because it allows to keep the RX
and TX path more symmetric and it allows non-FIB users as well.

> >If the latter, then there really isn't much left in my patch series that
> >can be reused, other than references to the places in the code that need
> >to be changed to support multipath and to make fib_info matching work
> >correctly.

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?