I had no major objections. A couple of points, however:

> In this document, the multi-homed host does not forward any packet
> between its interfaces.  Therefore forwarding devices are out of
> scope of this document.
>   

You might consider adding a discussion about implications of weak/strong 
host model here.

> Some received configuration objects are
> specific to an interface such as the IP address and the link prefix.
> Others are typically considered by implementations as being global to
> the node, such as the routing information (default gateway), DNS
> servers IP addresses and address selection policies.
>   

How well has the distinction been defined, really? Its clear for some 
things, but is, e.g., clear for all DHCP options?

> A multi-homed host may have multiple routes to a destination.
> However, by default, it does not have any hint concerning which
> interface would be the best to use for that destination.  For
> example, as discussed in
> [I-D.savolainen-6man-fqdn-based-if-selection <http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00#ref-I-D.savolainen-6man-fqdn-based-if-selection>] and
> [I-D.hui-ip-multiple-connections-ps <http://tools.ietf.org/html/draft-blanchet-mif-problem-statement-00#ref-I-D.hui-ip-multiple-connections-ps>], a service provider might want
> to influence the routing table of the host connecting to its network.
> (TBD: expand)
>   
This section really makes two separate points. First, you do not know 
which interface to use for a particular packet. Second, service provider 
routing hints are simply yet another example of configuration data that 
needs to be reconciled between interfaces. It might be better to keep 
these problems separate.

> An address selection policy [RFC3484 <http://tools.ietf.org/html/rfc3484>] is used to choose the right
> source and destination address for a new connection.  It is
> implemented globally in the node IP stack.
>
> As discussed in [RFC4291 <http://tools.ietf.org/html/rfc4291>], a multi-homed host with IPv4 and IPv6
> connectivity might need to receive an update of its default address
> selection policy.  However, that policy is only valid within the
> context of the interface it received it from.  Each network on which
> the node is connected might have a different address policy to push
> to the connecting nodes" The received policies might be conflicting.
> There is currently no standard mechanism to determine what should be
> the behavior of the stack in such case.
>   

Again, there seems to be two issues. The first issue is having a policy 
that tells an application which addresses to use (and indirectly which 
interface to use). The second issue is that if the policy comes, e.g., 
via DHCP on a per-interface basis, then we again have to reconcile the 
different policies on a per-node basis.

My personal classification of problems in the multiple interface space 
includes the following:

1) Access selection, i.e., which network(s) to attach to using the 
physical interface(s) that the host has. Already covered in RFC 5113.

2) Split DNS: If a host is attached to a number of different interfaces, 
how does it resolve a FQDN if more than one interface has provided a DNS 
server address?

3) Configuration reconciliation: how do we merge and use DHCP and other 
configuration information in a node, when the information is received on 
a per-interface basis?

4) Routing: If a host is attached to a number of different interfaces, 
where does a particular IP packet go?

5) Address selection: If a host is attached to a number of different 
interfaces, which addresses should be used for a particular application 
flow?

6) Tunnel multihoming: If a host is attached to a number of different 
interfaces and runs some kind of a tunneling or mobility back to a home 
agent, which interface and addresses should be used for a particular 
packet? Already covered in existing MEXT WG work items.

7) Is there a way for the host and the network to communicate about 
their policies regarding all of the above?

My understanding is that the proposed BOF would be looking at problems 
2, 3, 4, 5, and 7. The others are covered elsewhere.

Jari

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif