Re: [Bridge] [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)

2020-09-17 Thread Henrik.Bjoernlund--- via Bridge
Hi Nik,

Thanks a lot for reviewing.

-Original Message-
From: Nikolay Aleksandrov  
Sent: 7. september 2020 15:56
To: step...@networkplumber.org; Horatiu Vultur - M31836 

Cc: bridge@lists.linux-foundation.org; Henrik Bjoernlund - M31679 
; da...@davemloft.net; 
linux-ker...@vger.kernel.org; j...@mellanox.com; net...@vger.kernel.org; Roopa 
Prabhu ; ido...@mellanox.com; k...@kernel.org; UNGLinuxDriver 

Subject: Re: [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity 
Fault Management(CFM)

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe

>On Sun, 2020-09-06 at 20:21 +0200, Horatiu Vultur wrote:
>> The 09/04/2020 15:44, Stephen Hemminger wrote:
>> > On Fri, 4 Sep 2020 09:15:20 +
>> > Henrik Bjoernlund  wrote:
>> >
>> > > Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14.
>> > >
>> > >
>[snip]
>> > > 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  
>> > > Signed-off-by: Henrik Bjoernlund  
>> > > 
>>
>> 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.
>
>Hi,
>I also had the same initial thought - this really doesn't seem to affect the 
>bridge in any way, it's only collecting and transmitting information. I get 
>that you'd like to use the bridge as a passthrough device to switchdev to 
>program your hw, could you share what would be offloaded more specifically ?
>

Yes.

The HW will offload the periodic sending of CCM frames, and the reception.

If CCM frames are not received as expected, it will raise an interrupt.

This means that all the functionality provided in this series will be offloaded 
to HW.

The offloading is very important on our HW where we have a small CPU, serving 
many ports, with a high frequency of CFM frames.

The HW also support Link-Trace and Loop-back, which we may come back to later.

>All you do - snooping and blocking these packets can easily be done from user- 
>space with the help of ebtables, but since we need to have a software 
>implementation/fallback of anything being offloaded via switchdev we might 
>need this after all, I'd just prefer to push as much as possible to user-space.
>
>I plan to review the individual patches tomorrow.
>
>Thanks,
> Nik


[Bridge] [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)

2020-09-17 Thread Henrik Bjoernlund via Bridge
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  
Signed-off-by: Henrik Bjoernlund  

Henrik Bjoernlund (7):
  net: bridge: extend the process of special frames
  bridge: cfm: Add BRIDGE_CFM to Kconfig.
  bridge: uapi: cfm: Added EtherType used by the CFM protocol.
  bridge: cfm: Kernel space implementation of CFM.
  bridge: cfm: Netlink Interface.
  bridge: cfm: Netlink Notifications.
  bridge: cfm: Bridge port remove.

 include/uapi/linux/cfm_bridge.h |  75 +++
 include/uapi/linux/if_bridge.h  | 125 +
 include/uapi/linux/if_ether.h   |   1 +
 include/uapi/linux/rtnetlink.h  |   2 +
 net/bridge/Kconfig  |  11 +
 net/bridge/Makefile |   2 +
 net/bridge/br_cfm.c | 936 
 net/bridge/br_cfm_netlink.c | 690 +++
 net/bridge/br_device.c  |   4 +
 net/bridge/br_if.c  |   1 +
 net/bridge/br_input.c   |  31 +-
 net/bridge/br_mrp.c |  19 +-
 net/bridge/br_netlink.c | 126 -
 net/bridge/br_private.h |  82 ++-
 net/bridge/br_private_cfm.h | 242 +
 15 files changed, 2326 insertions(+), 21 deletions(-)
 create mode 100644 include/uapi/linux/cfm_bridge.h
 create mode 100644 net/bridge/br_cfm.c
 create mode 100644 net/bridge/br_cfm_netlink.c
 create mode 100644 net/bridge/br_private_cfm.h

-- 
2.28.0



Re: [Bridge] [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)

2020-09-08 Thread Allan W. Nielsen via Bridge

Hi,

On 08.09.2020 11:04, Henrik Bjoernlund - M31679 wrote:

On Sun, 2020-09-06 at 20:21 +0200, Horatiu Vultur wrote:

The 09/04/2020 15:44, Stephen Hemminger wrote:
> On Fri, 4 Sep 2020 09:15:20 + Henrik Bjoernlund
>  wrote:

Hi, I also had the same initial thought - this really doesn't seem to
affect the bridge in any way, it's only collecting and transmitting
information. I get that you'd like to use the bridge as a passthrough
device to switchdev to program your hw, could you share what would be
offloaded more specifically ?

Yes.

The HW will offload the periodic sending of CCM frames, and the
reception.

If CCM frames are not received as expected, it will raise an interrupt.

This means that all the functionality provided in this series will be
offloaded to HW.

The offloading is very important on our HW where we have a small CPU,
serving many ports, with a high frequency of CFM frames.

The HW also support Link-Trace and Loop-back, which we may come back to
later.


All you do - snooping and blocking these packets can easily be done
from user- space with the help of ebtables, but since we need to have
a software implementation/fallback of anything being offloaded via
switchdev we might need this after all, I'd just prefer to push as
much as possible to user-space.

In addition to Henriks comment, it is worth mentioning that we are
trying to push as much of the functionallity to user-space (learnings
from the MRP discussions).

This is why there are currently no in-kernel users of the CCM-lose
singnal. When a CCM-defect is happening the network typically needs to
be re-configured. This we are trying to keep in user-space.


I plan to review the individual patches tomorrow.

Thanks.

/Allan


Re: [Bridge] [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)

2020-09-06 Thread Horatiu Vultur via Bridge
The 09/04/2020 15:44, Stephen Hemminger wrote:
> 
> On Fri, 4 Sep 2020 09:15:20 +
> 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. 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  
> > Signed-off-by: Henrik Bjoernlund  

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


Re: [Bridge] [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)

2020-09-04 Thread Stephen Hemminger
On Fri, 4 Sep 2020 09:15:20 +
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. 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  
> Signed-off-by: Henrik Bjoernlund  

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.