public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: "bridge@lists.linux-foundation.org" 
	<bridge@lists.linux-foundation.org>,
	"henrik.bjoernlund@microchip.com"
	<henrik.bjoernlund@microchip.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Roopa Prabhu <roopa@nvidia.com>,
	"idosch@mellanox.com" <idosch@mellanox.com>,
	"jiri@resnulli.us" <jiri@resnulli.us>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
	"kuba@kernel.org" <kuba@kernel.org>
Subject: Re: [net-next v3 0/9] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)
Date: Tue, 6 Oct 2020 15:00:05 +0000	[thread overview]
Message-ID: <0e6cc78ebf37fcb4e2455cd331d250091e4c9ecc.camel@nvidia.com> (raw)
In-Reply-To: <20201006145338.1956886-1-henrik.bjoernlund@microchip.com>

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@intel.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


      parent reply	other threads:[~2020-10-06 15:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-06 14:53 [net-next v3 0/9] net: bridge: cfm: Add support for Connectivity Fault Management(CFM) Henrik Bjoernlund
2020-10-06 14:53 ` [net-next v3 1/9] net: bridge: extend the process of special frames Henrik Bjoernlund
2020-10-06 14:53 ` [net-next v3 2/9] bridge: cfm: Add BRIDGE_CFM to Kconfig Henrik Bjoernlund
2020-10-06 14:53 ` [net-next v3 3/9] bridge: uapi: cfm: Added EtherType used by the CFM protocol Henrik Bjoernlund
2020-10-06 14:53 ` [net-next v3 4/9] bridge: cfm: Kernel space implementation of CFM Henrik Bjoernlund
2020-10-06 14:53 ` [net-next v3 5/9] " Henrik Bjoernlund
2020-10-06 14:53 ` [net-next v3 6/9] " Henrik Bjoernlund
2020-10-06 14:53 ` [net-next v3 7/9] bridge: cfm: Netlink Interface Henrik Bjoernlund
2020-10-06 14:53 ` [net-next v3 8/9] bridge: cfm: Netlink Notifications Henrik Bjoernlund
2020-10-06 14:53 ` [net-next v3 9/9] bridge: cfm: Bridge port remove Henrik Bjoernlund
2020-10-06 15:00 ` Nikolay Aleksandrov [this message]

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=0e6cc78ebf37fcb4e2455cd331d250091e4c9ecc.camel@nvidia.com \
    --to=nikolay@nvidia.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=henrik.bjoernlund@microchip.com \
    --cc=idosch@mellanox.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --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