Hi Lubomir, after some time I'm sending followup on this. I would like to flesh out and discuss our ideas before we start implementing them to be certain that they will be useful for NetworkManager users.
On 07.09.2015 18:10, Lubomir Rintel wrote: > Hello Stjepan, > > On Mon, 2015-09-07 at 12:05 +0200, Stjepan Groš wrote: >> So, it seems to me that the NetworkManager is the core component on the >> client side that will have to have functionality specified by MIF >> allowing node to use multiple connections in parallel (this, of course, >> doesn't mean that it is the only component that will have to be >> changed). But since we are at the very beginning of this, we would like >> to hear thoughts from developers about this? Did anyone tried to do >> this? Give any thought to this and come out with a possible solution, or >> problems? > We do essentially deal with this to some extent by setting metrics to > the routes we set up. We assign priorities to different device types so > that e.g. Wired Ethernet is preferred over Wi-Fi or Mobile Broadband. > We do also remember order in which routes were added so that newly > activated connections on multi-homed hosts don't "steal" the existing > connections. > > That said, I haven't really had a look (maybe someone else from the > team had?) at the documents you're created and discussed so far so my > understanding of the problem scope might be limited. > First, our task is to implement MIF on Linux/Fedora and we didn't participate in the standardization process, at least not until now. Anyway, I suppose that the best document to read is RFC6418 which summarizes problems associated with multiple interfaces and/or connections that MIF WG tries to address. RFC7556 defines solution architecture and also discusses some issues. So, I'll continue from that point on and use the terminology introduced by the given RFCs. What we in my group were discussing in the past two weeks was how to approach the problem of multiple, sometimes conflicting, connections on a single node. In the end we concluded to approach this using network name spaces which would be controlled by Network Manger. In other words, whenever NetworkManager receives new PvD (think of PvD as a coherent set of network configuration data) it assigns this data to the root network name space but also creates a new network name space in which the given configuration data is the only network configuration. To run a new process (e.g. Firefox) that uses the particular connection (for example VPN) it is enough to use nsenter(1) command in CLI. For GUI, at the moment, we don't know what is the best way/the most user friendly to allow users to run applications in certain name spaces, so this is open to discussions. Few things are also necessary. First, of course, is the way for NetworkManager to discover PvDs (explicit and implicit). The second is that not always it is necessary to create new name space. Sometimes conflicts between different network configuration can be resolved in a single namespace. To solve that problem we would define language and engine that would allow control of NMs behavior when applying network configuration data. For example, at the present moment interface priorities are hardcoded, i.e. if there are WiFi and wired connection, default route from wired connection is used. This policy language would allow this to be specified independently from the code of NM and thus be made much more flexible for different use cases. What do you think about it? Do you have any suggestions or alternative approaches? SG
signature.asc
Description: OpenPGP digital signature
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
