From: Stephen Hemminger <stephen@networkplumber.org>
To: Henrik Bjoernlund <henrik.bjoernlund@microchip.com>
Cc: <davem@davemloft.net>, <kuba@kernel.org>, <roopa@nvidia.com>,
<nikolay@nvidia.com>, <jiri@mellanox.com>, <idosch@mellanox.com>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<bridge@lists.linux-foundation.org>,
<UNGLinuxDriver@microchip.com>,
Horatiu Vultur <horatiu.vultur@microchip.com>
Subject: Re: [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)
Date: Fri, 4 Sep 2020 15:44:06 -0700 [thread overview]
Message-ID: <20200904154406.4fe55b9d@hermes.lan> (raw)
In-Reply-To: <20200904091527.669109-1-henrik.bjoernlund@microchip.com>
On Fri, 4 Sep 2020 09:15:20 +0000
Henrik Bjoernlund <henrik.bjoernlund@microchip.com> wrote:
> Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14.
>
> Connectivity Fault Management (CFM) comprises capabilities for
> detecting, verifying, and isolating connectivity failures in
> Virtual Bridged Networks. These capabilities can be used in
> networks operated by multiple independent organizations, each
> with restricted management access to each other’s equipment.
>
> CFM functions are partitioned as follows:
> — Path discovery
> — Fault detection
> — Fault verification and isolation
> — Fault notification
> — Fault recovery
>
> The primary CFM protocol shims are called Maintenance Points (MPs).
> A MP can be either a MEP or a MHF.
> The MEP:
> -It is the Maintenance association End Point
> described in 802.1Q section 19.2.
> -It is created on a specific level (1-7) and is assuring
> that no CFM frames are passing through this MEP on lower levels.
> -It initiates and terminates/validates CFM frames on its level.
> -It can only exist on a port that is related to a bridge.
> The MHF:
> -It is the Maintenance Domain Intermediate Point
> (MIP) Half Function (MHF) described in 802.1Q section 19.3.
> -It is created on a specific level (1-7).
> -It is extracting/injecting certain CFM frame on this level.
> -It can only exist on a port that is related to a bridge.
> -Currently not supported.
>
> There are defined the following CFM protocol functions:
> -Continuity Check
> -Loopback. Currently not supported.
> -Linktrace. Currently not supported.
>
> This CFM component supports create/delete of MEP instances and
> configuration of the different CFM protocols. Also status information
> can be fetched and delivered through notification due to defect status
> change.
>
> The user interacts with CFM using the 'cfm' user space client program, the
> client talks with the kernel using netlink. The kernel will try to offload
> the requests to the HW via switchdev API (not implemented yet).
>
> Any notification emitted by CFM from the kernel can be monitored in user
> space by starting 'cfm_server' program.
>
> Currently this 'cfm' and 'cfm_server' programs are standalone placed in a
> cfm repository https://github.com/microchip-ung/cfm but it is considered
> to integrate this into 'iproute2'.
>
> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
> Signed-off-by: Henrik Bjoernlund <henrik.bjoernlund@microchip.com>
Could this be done in userspace? It is a control plane protocol.
Could it be done by using eBPF?
Adding more code in bridge impacts a large number of users of Linux distros.
It creates bloat and potential security vulnerabilities.
next prev parent reply other threads:[~2020-09-04 22:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 9:15 [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM) Henrik Bjoernlund
2020-09-04 9:15 ` [PATCH RFC 1/7] net: bridge: extend the process of special frames Henrik Bjoernlund
2020-09-08 12:12 ` Nikolay Aleksandrov
2020-09-15 8:23 ` henrik.bjoernlund
2020-09-04 9:15 ` [PATCH RFC 2/7] bridge: cfm: Add BRIDGE_CFM to Kconfig Henrik Bjoernlund
2020-09-08 12:18 ` Nikolay Aleksandrov
2020-09-15 8:26 ` henrik.bjoernlund
2020-09-04 9:15 ` [PATCH RFC 3/7] bridge: uapi: cfm: Added EtherType used by the CFM protocol Henrik Bjoernlund
2020-09-08 12:19 ` Nikolay Aleksandrov
2020-09-04 9:15 ` [PATCH RFC 4/7] bridge: cfm: Kernel space implementation of CFM Henrik Bjoernlund
2020-09-04 15:02 ` Jakub Kicinski
2020-09-15 8:51 ` Henrik Bjoernlund
2020-09-08 13:16 ` Nikolay Aleksandrov
2020-09-15 9:36 ` henrik.bjoernlund
2020-09-04 9:15 ` [PATCH RFC 5/7] bridge: cfm: Netlink Interface Henrik Bjoernlund
2020-09-08 13:47 ` Nikolay Aleksandrov
2020-09-15 9:49 ` henrik.bjoernlund
2020-09-04 9:15 ` [PATCH RFC 6/7] bridge: cfm: Netlink Notifications Henrik Bjoernlund
2020-09-08 13:54 ` Nikolay Aleksandrov
2020-09-15 9:59 ` henrik.bjoernlund
2020-09-15 10:24 ` henrik.bjoernlund
2020-09-04 9:15 ` [PATCH RFC 7/7] bridge: cfm: Bridge port remove Henrik Bjoernlund
2020-09-08 13:58 ` Nikolay Aleksandrov
2020-09-15 10:00 ` henrik.bjoernlund
2020-09-04 22:44 ` Stephen Hemminger [this message]
2020-09-06 18:21 ` [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM) Horatiu Vultur
2020-09-07 13:56 ` Nikolay Aleksandrov
2020-09-08 11:04 ` Henrik.Bjoernlund
2020-09-08 11:35 ` Allan W. Nielsen
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=20200904154406.4fe55b9d@hermes.lan \
--to=stephen@networkplumber.org \
--cc=UNGLinuxDriver@microchip.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=henrik.bjoernlund@microchip.com \
--cc=horatiu.vultur@microchip.com \
--cc=idosch@mellanox.com \
--cc=jiri@mellanox.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@nvidia.com \
--cc=roopa@nvidia.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).