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

[roopa <roopa@cumulusnetworks.com>]

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 ?
>
> 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.

> 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.

Thanks,
Roopa