The 09/04/2020 15:44, Stephen Hemminger wrote: > > On Fri, 4 Sep 2020 09:15:20 +0000 > Henrik Bjoernlund <henrik.bjoernlund@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> > > Signed-off-by: Henrik Bjoernlund <henrik.bjoernlund@xxxxxxxxxxxxx> Hi Stephen, > > Could this be done in userspace? It is a control plane protocol. > Could it be done by using eBPF? I might be able to answer this. We have not considered this approach of using eBPF. Because we want actually to push this in HW extending switchdev API. I know that this series doesn't cover the switchdev part but we posted like this because we wanted to get some feedback from community. We had a similar approach for MRP, where we extended the bridge and switchdev API, so we tought that is the way to go forward. Regarding eBPF, I can't say that it would work or not because I lack knowledge in this. > > Adding more code in bridge impacts a large number of users of Linux distros. > It creates bloat and potential security vulnerabilities. -- /Horatiu
