Bug#695850: ITP: libteam -- library for controlling team network device

[Dmitry Smirnov <onlyjob@member.fsf.org>]

Hi Guus,

You did a fantastic work on "ifenslave" (interface to bonding capabilities in 
kernel) -- thank you.
This new and experimental software has only potential to become an alternative 
to "ifenslave" one day.

> >             URL: https://libteam.org
> 
> That URL does not work, use either http://libteam.org/ or
> https://fedorahosted.org/libteam/.

Thanks for correction. (It's a bit strange as I was copy-pasting from my 
browser' address field...)


> Dramatically different? Many advantages? That tells me nothing. Instead
> please just give a list of *user visible* advantages that libteam has over
> bonding.

Why focus only on user visible changes? Upstream is trying to make 
bonding/teaming safer, easier and more maintainable by moving it to user 
space.

Perhaps the following links will answer your question better than me:

	http://www.pirko.cz/teamdev.pp.pdf
	https://fedorahosted.org/libteam/wiki/CompareToBonding

To provide summary here I quote from above documents:

 Following table compares Bonding vs. Team features:
    https://fedorahosted.org/libteam/wiki/CompareToBonding

[Feature]									[Bonding]		[Team]
 broadcast TX policy						 Yes		 	 Yes
 round-robin TX policy						 Yes		 	 Yes
 active-backup TX policy					 Yes 		 Yes
 LACP (802.3ad) support					 Yes 		 Yes
 Hash-based TX policy						 Yes 		 Yes
 User can set hash function					 No 		 	 Yes
 TX load-balancing support (TLB)			 Yes 		 Yes
 RX load-balancing support (ALB)			 Yes 		 Yes (Wip)
 LACP hash port select						 Yes 		 Yes
 load-balancing for LACP support			 No 			 Yes
 Ethtool link monitoring					 Yes 		 Yes
 ARP link monitoring						 Yes 		 Yes
 NS/NA (IPV6) link monitoring				 No 			 Yes
 ports up/down delays						 Yes 		 Yes
 port priorities and stickiness ("primary" option enhancement)	No		 Yes
 separate per-port link monitoring setup		 No			 Yes
 multiple link monitoring setup				 Limited		 Yes
 lockless TX/RX path						 No (rwlock)	 Yes (RCU)
 VLAN support								 Yes			 Yes
 user-space runtime control					 Limited		 Full
 Logic in user-space						 No			 Yes
 Extensibility							 Hard		 Easy
 Modular design							 No			 Yes
 Performance overhead						 Low			 Very Low
 D-Bus interface							 No			 Yes

---

## Bonding driver

 *  Introduced in 2000
 *  Huge and messy, therefore buggy
 *  All logic is in kernel (monolith)
 *  Does what it should not do (ARP link validation, 802.3ad, ...)
 *  Too many config interfaces
 *  12200 lines
 *  Not fixable due to backward compatibility concerns

---

## Team device overview

 *  Team is coming with modular approach
 *  User-space based controlling
 *  Minimum of the code is in kernel
    * "Puppet"
 *  Control logic is implemented in user-space daemon
    * "Puppeteer"
 *  Enslaved network interfaces are called "ports"

 *  Only necessary fast-path code. (1400 lines)
 *  Netlink communication (generic Netlink). (600 lines)
 *  Team "modes"
    * One mode, one kernel module
    * Determine basic low-level behaviour
    * Well defined API between team core and mode code
    * round-robin, active-backup, ... easy to add more

### Advantages comparing to bonding

 *  Extensibility. Anyone can easily add features/change behaviour
 *  Better system stability (daemon crash is always better than
    kernel panic/memory corruption etc.)
 *  Better debugging posibilities.

The goal of team device is to supersede bonding functionality
and then kill it eventually.

-- 
Regards,
Dmitry.

P.S. I hope that answers your questions. Please let me know if you think 
teaming do not worth time spent on it.