Re: [mif] WG Review: Multiple InterFaces (mif)

Giyeong Son a écrit :
> I think we may need to understand what are the real problems that
> people/organizations (i.e. carriers, ISPs and vendors and users) have
> been currently struggling with in terms of simultaneous use of multiple
> networks. 
there is a first cut in draft-blanchet-mif-problem-statement.

Please provide text/comments to it.

Marc.

> I think, Ralph seems to have clearly brought applicable practical use
> cases and/or criteria. So, with the use cases it might be worth to
> clarify if MIF will address and provide some recommendation for (at
> least) BCP which can answer to those use cases. If MIF does not
> (instead, only addresses partially, such as conflicting configurations
> and/or others), there may need other working group for focusing on BCP
> for the end-to-end practice of simultaneous use of multiple
> networks/interfaces. I believe that there is no working groups currently
> where can provide this kind of recommendation. They may be also willing
> to address partially from their perspective, similar with MIF if MIF
> want to tackle the problem partially.
>
> I think that we already know that simultaneous use of multiple networks
> is very crucial issue in various aspects by various organizations. Most
> of current carriers/ISPs/mobile device (including laptop) manufactures
> seems to be willing to hear about efficient, reliable and best common
> practice to handle the problem.
>
> Giyeong
>  
>
> -----Original Message-----
> From: mif-bounces(_at_)ietf(_dot_)org 
> [mailto:mif-bounces(_at_)ietf(_dot_)org] On Behalf Of
> Ralph Droms
> Sent: April 23, 2009 12:08 AM
> To: Christian Vogt
> Cc: mif; Margaret Wasserman; Sam Hartman; Scott Brim; David W. Hankins;
> Keith Moore; Hui Deng; IETF Discussion
> Subject: Re: [mif] WG Review: Multiple InterFaces (mif)
>
> Christian - I think address selection is part but not all of the
> problem.
>
> I would be happy to see a summary of current practice in dealing with
> simultaneous attachment to multiple networks.  How does an iPhone decide
> between its WiFi and dell interfaces?  How does an RG that can reach
> multiple next hop routers on its WAN interface select which router to
> forward to?  How does a laptop choose between its WiFi and wired
> interfaces?
>
> - Ralph
>
> On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote:
>
> > On Apr 22, 2009, Margaret Wasserman wrote:
> >
> > > This topic, address selection, is not currently handled by 
> > > applications.
> > > In many cases, it is handled entirely by the stack (through ordering 
> > > of the destination ddresses in DNS replies and source address 
> > > selection in the IP stack), and in other cases the application 
> > > chooses a destination address with the stack choosing a source 
> > > address.  There are certain cases (sometimes in solutions to the 
> > > problems that we are discussing
> > > here) where applications do choose both the destination and sourece 
> > > address, but they are not common.
> > Margaret -
> >
> > From a system perspective, you are certainly right:  Applications 
> > typically do get help from the operating system in selecting their 
> > addresses.  From an OSI layering perspective, though, address 
> > selection still is performed at application layer.  In fact, if an 
> > application wants to do a complete job, especially a peer-to-peer 
> > application, it needs to select both source and destination address 
> > itself, possibly after running STUN, TURN, or ICE.
> >
> > My main point, though, was that we are talking about two orthogonal 
> > issues -- conflicting configuration and address selection.  This holds
> > independently of the fact that an application may let the operating 
> > system accomplish part or all of address selection.
> >
> > Whether we take this to mean that both issues should be tackled in the
> > same working group is a different story.  I personally don't see the 
> > orthogonality of the two issues as a reason not to tackle both issues 
> > in the same working group.  We just ought to be aware that the issues 
> > are separate, and the charter should describe them as such.  This 
> > said, there might be work-load- or work-scope-specific reasons that 
> > suggest splitting the work into separate working groups, like those 
> > brought up by Lars, Sam, and Scott.  Those arguments should be 
> > discussed as well.
> >
> > - Christian
> >
> >
> >
> > _______________________________________________
> > mif mailing list
> > mif(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/mif
> _______________________________________________
> mif mailing list
> mif(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/mif
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute non-public 
> information. Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in error, 
> please immediately reply to the sender and delete this information from your 
> system. Use, dissemination, distribution, or reproduction of this 
> transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> mif mailing list
> mif(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/mif

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf