From: dsah...@kernel.org Date: Fri, 31 Aug 2018 17:49:35 -0700 > Examples > 1. Single path > $ ip nexthop add id 1 via 10.99.1.2 dev veth1 > $ ip route add 10.1.1.0/24 nhid 1 > > $ ip next ls > id 1 via 10.99.1.2 src 10.99.1.1 dev veth1 scope link > > $ ip ro ls > 10.1.1.0/24 nhid 1 scope link > ...
First of all, this whole idea is awesome! But, you knew that already. :) However, I worry what happesn in a mixed environment where we have routing daemons and tools inserting nexthop based routes, and some doing things the old way using and expecting inline nexthop information in the routes. That mixed environment situation has to function correctly. Older apps have to see the per-route nexthop info in the format and layout they expect (gw/dev pairs). They cannot be expected to just studdenly understand the nexthop ID etc. Otherwise the concept and ideas are fine, so as long as you can resolve the mixed environment situation I fully support this work and look forward to it being in a state where I can integrate it :-)
