TODO: remove bridging/bonding and InfiniBand

Bonding and InfiniBand are done. Bridging isn't, but after removing
the bonding and generic infrstructure parts of that section, there
wasn't really enough left to be worth keeping.

diff --git a/TODO b/TODO
index 0ae4cb7..2348b3c 100644 (file)
--- a/TODO
+++ b/TODO
@@ -432,63 +432,6 @@ that handle different system proxy handlers.  Some of the proxy handlers are:
   GNOME/KDE: how do these desktop environments retrieve proxy configuration?
 
 
-* Bridging and Bonding Support
-
-The largest complication here is that NetworkManager normally operates on
-physical interfaces, while bridging and bonding involve tying multiple physical
-interfaces together into a logical interface.  This has interesting implications
-for the D-Bus API and the NM device model.  The first complication is that
-we may need to do 802.1x port authentication on an interface before it can
-communicate with the other side of the link, and those credentials may be
-different for each interface; thus we may need to do separate 802.1x
-operations on each interface that is part of a bridge/bond before adding each
-one to the master bridge/bond interface.
-
-In this way bridge/bond interfaces may be treated the same way as NetworkManager
-treats VPN interfaces already; one or more physical interface NMConnections must
-be activated before the master bridge/bond interface's NMConnection can be
-activated, though this all happens internally.
-
-To enable bridging and bonding in the NMConnection itself, we should create
-new NMSettingBridge and NMSettingBond classes that contain information specific
-to each.  Both settings would contain a 'components' property with an
-'array of string' type which would contain the UUIDs of the Connections of
-physical interfaces that compose the bridge or bond.  Thus NetworkManager would
-have the necessary information to tie lower-level interface configuration
-(802.1x, MTU, MAC address locking, duplex mode, speed, etc) to each physical
-interface that will be part of the bridge/bond, configure the interface with
-it, and then configure the master bridge/bond interface at upper layers using
-configuration specific for the bridge/bond interface (like IP details).  Thus
-for a single active bridge, two or more NMConnections would be activated; one
-for each physical interface component of the bridge/bond, and one for the master
-bridge/bond interface itself.
-
-NMSettingBridge would contain at least the following keys:
-
-  components: (array of string) UUIDs of component connections
-  stp:        (boolean) on to enable STP, off to disable
-
-NMSettingBond would contain at least the following keys:
-
-  components: (array of string) UUIDs of component connections
-  mode:       (string) one of "balance-rr", "active-backup", "balance-xor",
-                  "broadcast", "802.3ad", "balance-tlb", or "balance-alb"
-  monitor-interval: (uint) Specifies link monitoring interval (in milliseconds);
-                       NM will always enable netlink carrier monitoring if this
-                       value is non-zero so this property only affects speed and
-                       duplex checking
-
-In the future we may consider adding other bonding parameters like "up-delay"
-and "down-delay".
-
-Then we'd add a 'component' (boolean) property to NMSettingConnection to
-indicate that the component interface connections were in fact components of
-a bridge or bond and shouldn't be automatically started by NetworkManager or
-displayed as separate connections in the user interface.
-
-TO BE CONTINUED
-
-
 * Better Tablet/Mobile Behavior
 
 There are a few components to this:
@@ -539,71 +482,3 @@ Consequently the same behavior should be used when a better connection becomes
 available.  This behavior should be suspended when special connections like
 Internet Connection Sharing ones are started, where clearly the priorities
 are different (ie, for Mobile Hotspot 3G > WiFi).
-
-
-* IP over Infiniband (IPoIB)
-
-These interfaces are similar to Ethernet interfaces with a few distinct
-differences:
-
-  1) they have 64-bit MAC addresses (GUIDs in Infiniband parlance)
-  2) DHCP clients need to be modified to handle IPoIB
-  3) they have a different ARP type and different L2 options
-
-By default the interfaces do not have IP capability, but they gain that
-capability when certain kernel modules (ib_ipoib.ko) are loaded, which causes
-the IP-capable interface is created.  The IP-capable interfaces apparently have
-ARPHRD_INFINIBAND set, which is likely what NM should use to identify them.
-
-One outstanding question is whether NM should (a) detect all Infiniband
-interfaces and load ib_ipoib.ko only when there is a defined NMConnection for
-an Infiniband interface, or (b) whether NM should automatically load ib_ipoib.ko
-for every Infiniband interface, or (c) whether NM should only manage Infiniband
-interfaces that already have associated IP-capable interfaces (ie, something
-else is responsible for loading ib_ipoib.ko).  Depending on our implementation,
-(a) might not be possible, because if IPoIB connections are treated similar to
-plain Ethernet connections, we may not have any information about whether a
-specific NMConnection is Infiniband other than the MAC address.
-
-It turns out that on some distros other components (like system services) may
-load ib_ipoib.ko for us.  For exmaple, the 'rdma' package on Fedora/RHEL systems
-contains /etc/rc.d/init.d/rdma which uses values in /etc/rdma/rdma.conf to load
-ib_ipoib.ko at system startup if the user has requested it via IPOIB_LOAD=yes.
-For the time being, if the some other component of the system loads IP for us,
-NetworkManager should probably still recognize the Infiniband interface, but
-leave it in unmanaged mode if there is no available IPoIB interface associated
-with the Infiniband one.  i.e. for now, NM should not automatically load
-ib_ipoib.ko.
-
-The second question is whether to fold IPoIB support into the NMDeviceEthernet
-class as was done for s390 network interfaces, or whether to create a subclass
-of NMDevice:
-
-1) extend NMDeviceEthernet: this would involve loosening the assumption that
-hardware addresses (the 'hw-address'/'perm-hw-address' properties of
-NMDeviceEthernet and the 'mac-address'/'cloned-mac-address' properties of
-NMSettingWired) are 48 bits wide and instead can be either 48 or 64 bits wide.
-
-2) create a new NMDevice subclass for Infiniband devices tailored to Infiniband
-specific behavior and attributes.  This would be a lot more code since we'd have
-to duplicate much of what NMDeviceEthernet already does, plus add the
-Infiniband device class to libnm-glib.  This also would be the least invasive
-from an API standpoint since the existing API would be unchanged, except for
-the addition of a new value in the NMDeviceType enum, which clients should
-ignore if they don't understand it.  (Need to coordinate additions to this enum
-between 0.8.x and 0.9.x since 0.9.x has more device types, but we want to make
-sure new device types get the same number for both branches).
-
-For Infiniband specific options we could either fold them into NMSettingEthernet
-or create a new NMSettingInfiniband class.  Current Infiniband specific options
-are partitions/P_Keys, datagram vs. connected mode, and MTU.  The default MTU
-varies with the 'mode'; for datagram it is currently 2044, while for connected
-mode it is currently 65520.  Given that we only have 2 IB-specific options
-we should probably just fold them into NMSettingEthernet similar to what was
-done for s390-specific options.
-
-For some general (and also Red Hat/Fedora specific) information see:
-
-http://tools.ietf.org/html/rfc4392
-http://rhkernel.org/#RHEL6+2.6.32-71.18.2.el6/Documentation/infiniband/ipoib.txt
-