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

From: George Tsirtsis <[email-masked]>
Date: Wed, 18 Feb 2009 17:48:32 +0000

Hi Hui,

I am changing subject to make the threads easier to follow.
Comments in line starting with GK>

On Wed, Feb 18, 2009 at 4:45 PM, Hui Deng <[email-masked]> wrote:
> Thanks, George,
>
> Your comments are good remindness. reply inline please
>
> 2009/2/18 George Tsirtsis <[email-masked]>
>>
>> Hi Hui et.al.,
>>
>> This looks like an interesting BOF so thanks for taking the initiative.
>>
>> I have two main comments with respect to the charter.
>>
>> I think it is unusual for a charter of this type (i.e., new work
>> rather than explicit update of a specific protocol) to identify the
>> exact protocol on which the solution is going to be based (you are
>> talking about using DHCP below). I would think that protocol selection
>> is something that the WG (if formed) is going to have to talk about.
>
> At the moment, there are no suggestions to use other protocol, and
> some people prefer would like to use it, could this be OK?
>

GT> I would think not but it is not for me to say. You may want to
double check with your AD to make sure. BTW, I have seen at least one
more proposal in this thread (talking about a policy box in the
network) which I would expect it would not use DHCP. Personally, I do
not like such God-boxes but the proposal does seem to exist. On the
other hand I do not see how DHCP will help either but I will keep an
open mind.

GT> The bottom line is that instead of talking about which protocol to
use maybe it would be productive to expand on what kind of "policy"
you are talking about. For example, you could discuss whether the
policy you want to provide to the host requires global knowledge or
not. i.e., does the policy provider need to know which interfaces are
available and/or active on the host? at what time frame (i.,e., is
this real time policy or long term guidelines)? or it does not matter
at all, and instead the policy is interface specific and does not
depend on any other interface on the host?
Answers to such questions will probably point to the type of protocol
required ...that's if you decide you need a protocol at all.

>>
>> Having said that, I think the charter and the presentations during the
>> BOF, should be very specific on exactly what approach the work should
>> take.
>> At the moment the charter and the people posting here seem to be torn
>> between:
>> - a protocol-free host requirements type work, and
>> - protocol-based policy work,
>> the two things requiring rather different way of thinking.
>
> I haven't see a protocol-free work proposed here, can you help to elaborate
> a little more.

GT> If you look at the Proposed Work part of your charter only one
item requires new protocol work (the DHCP one). Everything else is
about how the host should handle multiple interfaces based on existing
information.This is what all your BCP and INFO documents are all
about. Am I missing something?

> thanks
>
>>
>> I think this BOF will improve its chances of success if it is clear on
>> which of the two approaches it might want to take.
>
> yes, as you said, thanks for your remindness.
>
> Regards,
>
> -Hui
>
>>
>> Best Regards
>> George
>>
>> On Tue, Feb 17, 2009 at 6:12 AM, Hui Deng <[email-masked]> wrote:
>> > Hello, all
>> >
>> > The charter has been updated based on the comments from the mailing
>> > list:
>> > Thanks Jari, Marcelo, Kevin, Ruri, Peny, Behcet, Yonggeun, Teemu,
>> > Pierrick,
>> > Qin, Jacni, Gerardo, Tao, Kai for their comments.
>> >
>> > Please help to comment on it,
>> >
>> > thanks
>> >
>> > -Hui
>> >
>> >
>> > ----------------------------------------------------------------------------------------------------------------------
>> > 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.
>> >
>> >    RFC 1122 has speicify the strong model and the weak model for a
>> >    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 implemented a connection
>> >    manager which could help the application select which interfaces
>> > based
>> >    on the strong model. 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.
>> >
>> >    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.
>> >    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.
>> >
>> >    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. And the difference between Monami and work
>> >    here is that there is no agent in the network side to hide the
>> >    interface's address.
>> >
>> > 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)
>> >  Current Practices
>> >
>> >    o What the current major host vendors do regarding to multiple
>> >    interfaces.(Informational)
>> >
>> >  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)
>> >
>> > 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
>> >
>> >
>
>

---

From: Hui Deng <[email-masked]>
Date: Thu, 19 Feb 2009 23:32:32 +0800

Hi, George,

Thanks to seperate thread to make it easy discussion.
Comments inline starting with ==>

2009/2/19 George Tsirtsis <[email-masked]>

> other hand I do not see how DHCP will help either but I will keep an

==> Let's avoid to put God-boxes, we would better focus on what policy
it really need firstly as you said below. for DHCP, you will be able to see
DNS and routing proposal soon, I guess Teemu just posted splict dns related
draft.

> required ...that's if you decide you need a protocol at all.

==> your suggestion are valuable here, I hope that current two solutions
(DNS, and routing) could answer those questions. one thing you remind
me is that whether those policies need lifetime or not. As you said,
the policy are more interface specific, it may be delivered to the interface

when it is actived, or may not depends on another interface of the host.

> about. Am I missing something?

==> Yes, to make the smallest set for starting point of the bof, we limit
out work
to only three work at the moment,   the other possible protocol work would
be
Split DNS.

Thanks for your suggestions.

-Hui

<snip>