Subject: Re: [mif] Charter Updated Ver. 2

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Mar 2009 10:22:46 +0100

Hui,

Here's some further comments on the charter:
 
> ----------------------------------------------------------------------------------------------------------------------
> Background and Motivation
>  
>    A multi-homed host has multiple network interfaces (physical and/or
>    logical).  For example, a node may be connected to a wired Ethernet
>    LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
>    or one or multiple automatic or manual tunnels. Current laptops and
>    smartphones typically have multiple access network interfaces.
>    A multi-homed host doesn't have any IP mobility function supported 
> like
>    the mobile node specified in the RFC 3775.

Its important that we don't restrict ourselves to the case where there's 
a mobility protocol between the MN and the HA (because that is largely a 
solved problem).

However, I'm not too happy with the last sentence above, because MIF 
should work even when there is such mobility support above. Also, we 
should apply the same rule for mobility and multihoming protocols (hip, 
shim6, mobike).

>    RFC 1122 has speicify the strong model and the weak model for a

typo

>    multi-homed host, the weak model has been widely implemented by
>    the major OSs, but it treat the source and destination of the 
> connection
>    as a host other than interfaces. Strong model recently has been
>    implemented in new OSs. Some mobile OSs has

Some mobile operating systems have ...
> implemented a connection
>    manager which could help the application select which interfaces based
>    on the strong model.

I think we need to start from the basics:

... implemented various techniques to deal with multiple interfaces. 
Some devices employ only one interface at a time and some allow per-host 
configuration of preferences between the interfaces but still use just 
one at a time. Other systems allow per-application preferences or 
implement sophisticated policy managers that can be configured by users 
or controlled externally.

> The policy used by the connection manager could
>    be configured by the host user from the UI interface, and it also 
> can be
>    acquired from the network side either by the operator or the 
> enterprise.
>    Anyhow, what kind of policies and how those policies will be delivered
>    to the host are still under-specified in IETF.

Even the issues related to the use of multiple interfaces is 
under-specified. Start from that, then mention the policies.

>    A multi-homed host receives node configuration information from each
>    of its access networks.  Some configuration objects are global to the
>    node, some are local to the interface.  Various issues arise when
>    multiple configuration objects that are global to the node are
>    received on the many interfaces the multi-homed host has.  Therefore,
>    there is a need to define the appropriate behaviors of an IPv4 and IPv6
>    stack and possibly extend the existing protocols to manage these cases.

Extending existing protocols needs to be specified in more detail. I 
would actually start from saying that we need to specify the behaviour 
of the host better and understand the limitations, if any, set by the 
current protocols. And not talk about any extensions of protocols at 
this stage.

> It is noted that even after received those network policies, user could
> still decide how to discover and which interface will be selected based
> on RFC 5113.

I guess "those network policies" refers to the policy manager stuff from 
earlier, not the configuration objects that the previous text talks 
about? Clarifying the reference would be useful here.

Secondly, there is something wrong about the order here. RFC 5113 talks 
primarily about the selection of interfaces to bring up and networks to 
attach to. What did you mean "after received those network policies"? 
First off, I'm not sure the policy manager gets policy updates on every 
network attachment time, though it might. And in any case, RFC 5113 is 
really about other things than MIF (and not a protocol or behaviour 
description).

Here's an attempted rewrite:

"Note that the MIF deals with the usage of active interfaces. This is 
different from the decision to bring up these interfaces or the decision 
to attach a wireless interface to a particular available radio network 
(see RFC 5113). Mechanisms related to these other decisions are outside 
the scope of MIF.

>    It is also notable that the general host and site multihoming designs
>    (SHIM6 and RRG) is different from the work (policy of the connection
>    manager) to be done here.

Different, but how?

> And the difference between Monami and work
>    here is that there is no agent in the network side to hide the
>    interface's address.eans

Suggested rewrite of the Shim6 and Monami statement:

Multi-homed MIF hosts do not assume any new software on its peers, or 
any new network entity for routing traffic through. This makes MIF 
different from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF 
also does not provide any means for traffic flows to move from one 
interface to another.

> Proposed Work:
> -------------
> The proposed mif Working Group will focus on the following topics
> relevant for multiple interfaces:
>  
>  Problem statement
>  
>    o A document describing the problems caused by the multiple
>    interfaces in the host. (Informaitonal)

typo

>  Current Practices
>  
>    o What the current major host vendors do regarding to multiple
>    interfaces.(Informational)

Good
 
>  Split DNS:
>    o A solution for optimal behaviour of multi-homed host when
>    one or more of its interfaces is facing a DNS service providing
>    interface-local information.
>    (Best Current Practice/Proposed Standard)
>
>  Routing of multiple interfaces:
>  
>    o A multi-homed host may have multiple routes to a destination.
>    However, by default, it may not have enough information to choose
>    the best interfaces for different applications/flows in the host.
>    Thus a IPv4/IPv6 host would need to be provided with more application
>    related specific routing information for interface selection based 
>    on DHCP. (Proposed Standard)
>  
>  Merging of IP layer autoconfiguration:
>    o A multi-homed host received IP layer autoconfiguration information
>    across multiple access networks. Thus it need to merge all those
>    configuration information. (Best Current Practice)

I would actually start with just the last of these three (split dns, 
dhcp routes, merging) solution level documents, and then do the other 
two once that one is successfully completed.
 
> The BoF proposes to discuss the above items and gauge interest in
> forming a working Group. There is already work in progress addressing
> the identified problems, which is expected to be the starting point
> for the deliverables.
>  
> The proposed activity will be complementary to the existing IETF
> Working Groups, notably the DHC,6MAN and MEXT WGs.
>
> Approximate Timeline for Deliverables:
> -------------------------------------
>     * April 2009 WG approved by IESG
>     * 2H09 Submit problem statement I-D to IESG
>     * 1H10 Submit current practices I-D to IESG
>     * 2H10 Submit Split DNS I-D to IESG
>     * 2H10 Submit Merging of IP layer autoconfiguration I-D to IESG
>     * 2H10 Submit Routing of multiple interfaces I-D to IESG
>     * 2H10 Recharter or close WG
> ------------------------------------------------------------------------
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>   

Jari

---

From: Kevin Chin <[email-masked]>
Date: Tue, 3 Mar 2009 11:38:49 -0800

Thanks for submitting comments.

Absolutely agree with:
 Jari wrote:
"Note that the MIF deals with the usage of active interfaces. This is
different from the decision to bring up these interfaces or the decision to
attach a wireless interface to a particular available radio network (see RFC
5113). Mechanisms related to these other decisions are outside the scope of
MIF. "
Also aligned with this statement (particularly last sentence -- session
continuity being out of scope):
 Jari wrote:
"Multi-homed MIF hosts do not assume any new software on its peers, or any
new network entity for routing traffic through. This makes MIF different
from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does not
provide any means for traffic flows to move from one interface to another. "

The use of "network policies" is ambiguous; the assumption of a single
unified "network policy" mechanism should be clarified. In cases there is
more than 1 network policy or device-based policy, the resolution of such
potentially conflicting behavior is (should be) out of scope of MIF. Policy
and configuration objects are distinct concepts.

Jari wrote:
"I guess "those network policies" refers to the policy manager stuff from
earlier, not the configuration objects that the previous text talks about?
Clarifying the reference would be useful here."
thanks-
Kevin

On Tue, Mar 3, 2009 at 1:22 AM, Jari Arkko <[email-masked]> wrote:

>>   A multi-homed host doesn't have any IP mobility function supported like
> Its important that we don't restrict ourselves to the case where there's a
> mobility protocol between the MN and the HA (because that is largely a
> solved problem).
>
> However, I'm not too happy with the last sentence above, because MIF should
> work even when there is such mobility support above. Also, we should apply
> the same rule for mobility and multihoming protocols (hip, shim6, mobike).
>
>>   the major OSs, but it treat the source and destination of the connection
> ... implemented various techniques to deal with multiple interfaces. Some
> devices employ only one interface at a time and some allow per-host
> configuration of preferences between the interfaces but still use just one
> at a time. Other systems allow per-application preferences or implement
> sophisticated policy managers that can be configured by users or controlled
> externally.
>
>>   be configured by the host user from the UI interface, and it also can be
>>   acquired from the network side either by the operator or the enterprise.
> Extending existing protocols needs to be specified in more detail. I would
> actually start from saying that we need to specify the behaviour of the host
> better and understand the limitations, if any, set by the current protocols.
> And not talk about any extensions of protocols at this stage.
>
> earlier, not the configuration objects that the previous text talks about?
> Clarifying the reference would be useful here.
>
> attach to. What did you mean "after received those network policies"? First
> off, I'm not sure the policy manager gets policy updates on every network
> attachment time, though it might. And in any case, RFC 5113 is really about
> other things than MIF (and not a protocol or behaviour description).
>
> different from the decision to bring up these interfaces or the decision to
> attach a wireless interface to a particular available radio network (see RFC
> 5113). Mechanisms related to these other decisions are outside the scope of
> MIF.
>
> Multi-homed MIF hosts do not assume any new software on its peers, or any
> new network entity for routing traffic through. This makes MIF different
> from Shim6, Mobile IPv6 multi-address extensions, and HIP. MIF also does not
> provide any means for traffic flows to move from one interface to another.
>
> Proposed Work:
>> -------------
>>   related specific routing information for interface selection based   on
>> DHCP. (Proposed Standard)
> I would actually start with just the last of these three (split dns, dhcp
> routes, merging) solution level documents, and then do the other two once
> that one is successfully completed.
>

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Mar 2009 21:39:58 +0800

Hi, Jari,

Thanks for your detail revision, it help us a lot.
I agree with all your revisions here, charter update will be posted soon.

Best regards,

-Hui
2009/3/3 Jari Arkko <[email-masked]>

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Mar 2009 21:42:05 +0800

Hi, Kevin

Thanks for your pointing out our vagues here,
It help us to progress.

Best regards,

-Hui

2009/3/4 Kevin Chin <[email-masked]>

>> should work even when there is such mobility support above. Also, we should
>> apply the same rule for mobility and multihoming protocols (hip, shim6,
>> mobike).
>>