[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0e6cc78ebf37fcb4e2455cd331d250091e4c9ecc.camel@nvidia.com>
Date: Tue, 6 Oct 2020 15:00:05 +0000
From: Nikolay Aleksandrov <nikolay@...dia.com>
To: "bridge@...ts.linux-foundation.org"
<bridge@...ts.linux-foundation.org>,
"henrik.bjoernlund@...rochip.com" <henrik.bjoernlund@...rochip.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Roopa Prabhu <roopa@...dia.com>,
"idosch@...lanox.com" <idosch@...lanox.com>,
"jiri@...nulli.us" <jiri@...nulli.us>,
"UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
"kuba@...nel.org" <kuba@...nel.org>
Subject: Re: [net-next v3 0/9] net: bridge: cfm: Add support for Connectivity
Fault Management(CFM)
On Tue, 2020-10-06 at 14:53 +0000, Henrik Bjoernlund 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.
>
> 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'.
>
> v2 -> v3
> The switchdev definition and utilization has been removed as there was no
> switchdev implementation.
> Some compiling issues are fixed as Reported-by: kernel test robot <lkp@...el.com>.
>
Well, funny timing. :) I just finished reviewing v2 half an hour ago. All of my
comments for v2 apply for this v3 set, sorry but you'll have to fix a few more
issues.
Thanks,
Nik
Powered by blists - more mailing lists