From: David Miller <davem@davemloft.net>
To: dsahern@kernel.org
Cc: netdev@vger.kernel.org, roopa@cumulusnetworks.com,
sharpd@cumulusnetworks.com, idosch@mellanox.com,
dsahern@gmail.com
Subject: Re: [PATCH RFC net-next 00/18] net: Improve route scalability via support for nexthop objects
Date: Sun, 02 Sep 2018 10:34:38 -0700 (PDT) [thread overview]
Message-ID: <20180902.103438.4279864720888716.davem@davemloft.net> (raw)
In-Reply-To: <20180901004954.7145-1-dsahern@kernel.org>
From: dsahern@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 :-)
next prev parent reply other threads:[~2018-09-02 21:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-01 0:49 [PATCH RFC net-next 00/18] net: Improve route scalability via support for nexthop objects dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 01/18] net: Rename net/nexthop.h net/rtnh.h dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 02/18] net: ipv4: export fib_good_nh and fib_flush dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 03/18] net/ipv4: export fib_info_update_nh_saddr dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 04/18] net/ipv4: export fib_check_nh dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 05/18] net/ipv4: Define fib_get_nhs when CONFIG_IP_ROUTE_MULTIPATH is disabled dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 06/18] net/ipv4: Create init and release helpers for fib_nh dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 07/18] net: ipv4: Add fib_nh to fib_result dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 08/18] net/ipv4: Move device validation to helper dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 09/18] net/ipv6: Create init and release helpers for fib6_nh dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 10/18] net/ipv6: Make fib6_nh optional at the end of fib6_info dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 11/18] net: Initial nexthop code dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 12/18] net/ipv4: Add nexthop helpers for ipv4 integration dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 13/18] net/ipv4: Convert existing use of fib_info to new helpers dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 14/18] net/ipv4: Allow routes to use nexthop objects dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 15/18] net/ipv6: Use helpers to access fib6_nh data dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 16/18] net/ipv6: Allow routes to use nexthop objects dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 17/18] net: Add support for nexthop groups dsahern
2018-09-01 0:49 ` [PATCH RFC net-next 18/18] net/ipv4: Optimization for fib_info lookup dsahern
2018-09-01 20:43 ` Stephen Hemminger
2018-09-04 15:27 ` David Ahern
2018-09-01 0:49 ` [PATCH iproute2-next] ip: Add support for nexthop objects dsahern
2018-09-01 20:37 ` Stephen Hemminger
2018-09-04 15:30 ` David Ahern
2018-09-02 17:34 ` David Miller [this message]
2018-09-04 15:57 ` [PATCH RFC net-next 00/18] net: Improve route scalability via " David Ahern
2018-12-11 12:52 ` Jan Maria Matejka
2018-12-12 20:27 ` David Ahern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180902.103438.4279864720888716.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=dsahern@kernel.org \
--cc=idosch@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=roopa@cumulusnetworks.com \
--cc=sharpd@cumulusnetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).