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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
