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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Agree.

-Hui

2009/4/23 Giyeong Son <gson@xxxxxxx>:
> 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.
>
> 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@xxxxxxxx [mailto:mif-bounces@xxxxxxxx] 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@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/mif
>
> _______________________________________________
> mif mailing list
> mif@xxxxxxxx
> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/mif
>
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]