Re: [mif] Call for volunteers about architecture design

Ok, so, being more generic than MIP, the problem is about simultaneous usage (not sequential) of physical and virtual interfaces, on a single physical interface. This problem is identified in MIF problem statement. 

Pierrick
> -----Message d'origine-----
> De : Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
> Envoyé : mardi 19 mars 2013 15:34
> À : SEITE Pierrick OLNC/OLN
> Cc : Ted Lemon; <mif@ietf.org>
> Objet : Re: [mif] Call for volunteers about architecture design
> 
> Le 19/03/2013 10:13, pierrick.seite@orange.com a écrit :
> > Hi Alex,
> >
> > Except the problem of access discovery and selection, I'm not sure
> > there are multiple provisioning domains issues with sequential use of
> > interfaces.
> 
> I am not sure either.
> 
> If continuous sessions are needed after a handover WiFi-3G (each is in
> a different provisioning domain), then Mobile IP should be used; if
> Mobile IP is used then there is a routing problem at the initial setup
> phase (the default route points to a tunnel interface but the HA should
> be reached with a host-specific route on the real interface).
> 
> There could be advice from HA to mobile to tell it how to set up that
> route (use one the real interface for reaching HA and the tunnel
> interface for all other traffic).  This advice is just another kind of
> advice that should be taken with precaution.
> 
> Or there could be a visual interface on the terminal to set manually
> the default route and other specific routes. (was already said).
> 
> Alex
> 
> 
> > This is something we can do with current terminal... Maybe I'm wrong
> > but, anyway, I guess the architecture work will start with discussion
> > on use-cases to identify what is relevant or not.
> >
> > Pierrick
> >
> >> -----Message d'origine----- De : mif-bounces@ietf.org
> >> [mailto:mif-bounces@ietf.org] De la part de Alexandru Petrescu
> Envoyé
> >> : lundi 18 mars 2013 15:58 À : Ted Lemon Cc :
> >> <mif@ietf.org> Objet : Re: [mif] Call for volunteers about
> >> architecture design
> >>
> >> Le 17/03/2013 12:51, Ted Lemon a écrit :
> >>> On Mar 16, 2013, at 9:38 PM, Alexandru Petrescu
> >>> <alexandru.petrescu@gmail.com> wrote:
> >>>> This kind of problem - make one virtual interface to link all
> other
> >>>> interfaces together, with goals such as bandwidth augmentation, on
> >>>> a Mobile Router (not a Host) - is discussed in the ITS Intelligent
> >>>> Transportation Systems email list ietf.org/mailman/listinfo/its
> >>>>
> >>>> (this is one problem being considered there, but there are other
> >>>> ITS problems considered there.  And there there is thought that
> MIF
> >>>> may consider this case - it seems not.)
> >>>
> >>> I think we should definitely consider this problem in the
> >>> architecture discussion.   Whether it's in-scope or out of scope
> >>>  is another question.
> >>
> >> In addition to simultaneous use of multiple interfaces for bandwidth
> >> augmentation on a low-ratio egress-ingress bandwidth Mobile Router
> >> (its egress bandwith is much lower than ingress bandwidth),
> >>
> >> there is another aspect which deserves mentioning in a mif'ed Host:
> >> the use of Mobile IP and handovers.  This would be such that a Host
> >> to offer highly available connections - when WiFi is available use
> >> WiFi, but if cellular is available then use cellular. This could be
> a
> >> sequential use of interfaces (only one interface is used
> >> exclusively), as opposed to simultaneous use of interfaces.
> >>
> >> The architecture aspect in  this is the difference between
> >> simultaneous vs sequential use of interfaces.  This could be
> >> illustrated with pictures of topology.
> >>
> >> This is something very complex to deal with.
> >>
> >> Alex
> >>
> >>>
> >>>
> >>>
> >>
> >>
> >> _______________________________________________ mif mailing list
> >> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> >
> >
> >
> Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, France Telecom - Orange decline toute responsabilite si
> > ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation. If you have
> > received this email in error, please notify the sender and delete
> this
> > message and its attachments. As emails may be altered, France Telecom
> > - Orange is not liable for messages that have been modified,  changed
> > or falsified. Thank you.
> >
> >
> >
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.