[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240529231847.16719-1-ekinzie@labn.net>
Date: Wed, 29 May 2024 19:18:43 -0400
From: Eric Kinzie <ekinzie@...n.net>
To: "David S . Miller" <davem@...emloft.net>,
David Ahern <dsahern@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>
Cc: Eric H Kinzie <ekinzie@...n.net>,
netdev@...r.kernel.org
Subject: [RFC net-next 0/2] MPLS point-to-multipoint
From: Eric H Kinzie <ekinzie@...n.net>
This series introduces point-to-multipoint MPLS LSPs and fixes a bug
related to sending ARPs for MPLS-tagged packets.
ARP/ND: I fixed this problem where it was observed (arp_solicit()),
but I'm not sure if this is a good long-term solution. Other options I
considered were (1) adjust ip[v6]_hdr() to make sure the outer header
is actually IP and (2) add a field to struct sk_buff to track layer
2.5 headers. The first option might add overhead in places where it has
more impact than addressing the problem in ARP. The second option, of
course, makes struct sk_buff bigger and more complicated, which doesn't
seem great, either.
P2MP: This splits up the mpls_forward() function to handle P2MP LSPs if
the route's multicast flag is set. It uses the same array of next-hops in
struct mpls_route that a multipath configuration uses. It is convenient
and I can't think of a use case for p2mp+multipath, but I'm curious if
there are reasons not to overload the next-hop array this way.
Eric H Kinzie (2):
net: do not interpret MPLS shim as start of IP header
net: mpls: support point-to-multipoint LSPs
net/ipv4/arp.c | 15 ++-
net/ipv6/ndisc.c | 13 ++-
net/mpls/af_mpls.c | 218 ++++++++++++++++++++++++++++++--------------
net/mpls/internal.h | 6 +-
4 files changed, 176 insertions(+), 76 deletions(-)
--
2.43.2
Powered by blists - more mailing lists