From: Roopa Prabhu <roopa@cumulusnetworks.com>
To: David Ahern <dsa@cumulusnetworks.com>
Cc: netdev@vger.kernel.org, nicolas.dichtel@6wind.com
Subject: Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
Date: Sat, 28 Jan 2017 17:00:41 -0800 [thread overview]
Message-ID: <588D3EB9.1070107@cumulusnetworks.com> (raw)
In-Reply-To: <1485559258-4856-1-git-send-email-dsa@cumulusnetworks.com>
On 1/27/17, 3:20 PM, David Ahern wrote:
> This series closes a couple of gaps between IPv4 and IPv6 with respect
> to multipath routes:
>
> 1. IPv4 allows all nexthops of multipath routes to be deleted using just
> the prefix and length; IPv6 only deletes the first nexthop for the
> route if only the prefix and length are given.
>
> 2. IPv4 returns multipath routes encoded in the RTA_MULTIPATH attribute.
> IPv6 returns a series of routes with the same prefix and length - one
> for each nexthop. This happens for both dumps and notifications.
>
> IPv6 does accept RTA_MULTIPATH encoded routes, but installs them as a
> series of routes.
>
> Patch 2 addresses the first item by allowing IPv6 multipath routes to be
> deleted using just the prefix and length. Patch 3 addresses the second
> allowing IPv6 multipath routes to be returned encoded in the RTA_MULTIPATH.
>
> Patch 1 adds the NLM_F_APPEND flag to notifications when the flag is
> present in the request. The lack of this flag was noted testing route
> appends and comparing to IPv4.
>
> Patch 4 prints IPv6 addresses in compressed format when showing route
> replace errors. This was noticed testing REPLACE failures.
>
> The end result for multipath routes:
> 1. Route Add
> - one notification with RTA_MULTIPATH attribute
>
> 2. Route Replace
> - notification for first route and all siblings that have
> succeeded. This is needed regardless of success of remaining
> nexthops to maintain add/delete consistency should a failure
> happens on the second or following nexthop (ie., need to tell
> userspace that original route has been replaced and then the
> failure logic deletes all routes inserted thus far).
>
> 3. Route Delete
> - for multipath route only given nexthops are deleted. This path
> is hit when DELETE contains RTA_MULTIPATH. All other route deletes,
> all nexthops are deleted for given prefix and length (and any
> other specs if given)
>
> - one notification sent per nexthop deleted. This is unavoidable
> since IPv6 alllows a single nexthop to be deleted within a multipath
> route
>
> 4. Route Appends
> - IPv6 allows nexthops to be appended to an existing route. In this
> case one notification is sent per nexthop added
thanks for listing all of these...I think you mentioned this case to me..
but I don't remember now why this notification is
sent per nexthop added. This is an update to an existing multipath route.
so seems like the notification should be a RTM_NEWROUTE with the full RTA_MULTIPATH route
(similar to route add)
Same holds for replace, I know the code might be tricky here...but the route replace
is also an update to an existing multipath route and hence should be a RTM_NEWROUTE
with the full multipath route (RTA_MULTIPATH) that changed (from userspace semantics POV)
I don't have a better solution, but with the above still being different, wondering
if its worth the risk changing the api for just a few notifications.
>
> Addresses some of the inconsistencies also noted by Roopa at netdev0.1:
> https://www.netdev01.org/docs/prabhu-linux_ipv4_ipv6_inconsistencies_talk_slides.pdf
>
> v3
> - removed the need for a user API to opt-in to change. Requiring an
> API just shifts the difference from same API with different
> behavior to different API to achieve equivalent behavior
>
> - route notifications changed to use RTA_MULTIPATH for add and replace
>
> - upated commit messages and cover letter
>
> v2
> - fixed locking in patch 1 as noted by DaveM
> - changed user API for patch 2 to require an rtmsg with RTM_F_ALL_NEXTHOPS
> set in rtm_flags
> - revamped explanation of patch 2 and cover letter
>
> David Ahern (4):
> net: ipv6: add NLM_F_APPEND in notifications when applicable
> net: ipv6: Allow shorthand delete of all nexthops in multipath route
> net: ipv6: Add support to dump multipath routes via RTA_MULTIPATH
> attribute
> net: ipv6: Use compressed IPv6 addresses showing route replace error
>
> include/net/ip6_fib.h | 4 +-
> include/net/netlink.h | 1 +
> net/ipv6/ip6_fib.c | 19 +++++-
> net/ipv6/route.c | 163 ++++++++++++++++++++++++++++++++++++++++++++------
> 4 files changed, 165 insertions(+), 22 deletions(-)
>
next prev parent reply other threads:[~2017-01-29 1:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 23:20 [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes David Ahern
2017-01-27 23:20 ` [PATCH net-next v3 1/4] net: ipv6: add NLM_F_APPEND in notifications when applicable David Ahern
2017-01-27 23:20 ` [PATCH net-next v3 2/4] net: ipv6: Allow shorthand delete of all nexthops in multipath route David Ahern
2017-01-27 23:20 ` [PATCH net-next v3 3/4] net: ipv6: Add support to dump multipath routes via RTA_MULTIPATH attribute David Ahern
2017-01-27 23:20 ` [PATCH net-next v3 4/4] net: ipv6: Use compressed IPv6 addresses showing route replace error David Ahern
2017-01-29 1:00 ` Roopa Prabhu [this message]
2017-01-29 18:02 ` [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes David Ahern
2017-01-29 23:55 ` Roopa Prabhu
2017-01-30 1:29 ` David Ahern
2017-01-30 2:20 ` Roopa Prabhu
2017-01-30 2:57 ` David Ahern
2017-01-30 11:13 ` Nicolas Dichtel
2017-01-30 15:59 ` David Ahern
2017-01-30 15:49 ` Roopa Prabhu
2017-01-30 16:12 ` David Ahern
2017-01-30 18:45 ` Roopa Prabhu
2017-01-30 21:16 ` Stephen Hemminger
2017-01-30 23:53 ` David Ahern
2017-01-30 23:56 ` Stephen Hemminger
2017-01-31 0:02 ` David Ahern
2017-01-30 11:08 ` Nicolas Dichtel
2017-01-30 15:45 ` Roopa Prabhu
2017-01-30 16:41 ` Nicolas Dichtel
2017-01-30 11:07 ` Nicolas Dichtel
2017-01-30 15:23 ` David Ahern
2017-01-30 17:03 ` Nicolas Dichtel
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=588D3EB9.1070107@cumulusnetworks.com \
--to=roopa@cumulusnetworks.com \
--cc=dsa@cumulusnetworks.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.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).