ietf
[Top] [All Lists]

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

2009-04-23 13:14:32
Ralph Droms a écrit :
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?

that is the purpose of draft-mrw-mif-current-practices... Some answers
are already there.

Marc.


- 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


-- 
=========
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