Subject: Re: [mif] mif Digest, Vol 4, Issue 40

From: yonghao sun <[email-masked]>
Date: Thu, 19 Feb 2009 15:30:33 +0800

Hi,Hui
  After reading your draft,I have a question.Can we add some certain
 softwares of application layer to solve the global configration information
problem?
Best Wishes!
Yonghao Sun
2009/2/19, [email-masked] <[email-masked]>:
> Send mif mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/mif
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mif digest..."
>
>
> Today's Topics:
>
>   1. Focusing the Charter Re:  Charter Updated Ver. 2 (George Tsirtsis)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Feb 2009 17:48:32 +0000
> From: George Tsirtsis <[email-masked]>
> Subject: [mif] Focusing the Charter Re:  Charter Updated Ver. 2
> To: Hui Deng <[email-masked]>
> Cc: mif <[email-masked]>
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset=UTF-8
>
> 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
> >> >
> >> >
> >
> >
>
>
> ------------------------------
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>
>
> End of mif Digest, Vol 4, Issue 40
> **********************************
>

---

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

Hi, yonghao,

Can you make a scenario how it works?

thanks

-Hui

2009/2/19 yonghao sun <[email-masked]>