Re: [mif] Call for volunteers about architecture design

For sequential use of interfaces, I guess mobile IP is not the only solution, today most internet application has figured out how to do session continuity without mobile ip support.
http://datatracker.ietf.org/doc/draft-deng-mif-api-session-continuity-guide/

-Hui
-----Original Message-----
From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Alexandru Petrescu
Sent: Tuesday, March 19, 2013 11:36 PM
To: pierrick.seite@orange.com
Cc: <mif@ietf.org>
Subject: Re: [mif] Call for volunteers about architecture design

Le 19/03/2013 16:03, pierrick.seite@orange.com a écrit :
> 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.

I agree in this sense.

(to me 'simultaneous use' is when we say simultaneous use for bandwidth augmentation.  Distinct HAroute and defroute - what we discuss above - is a method to do mobility registration at the same time as traffic, but does not offer bandwidth augmentation.)

For the pure use of interfaces in a sequential manner, I dont see anything else than a Mobile IP problem, which is solved, as you say.

> This problem is identified in MIF problem statement.

Ok.

Alex

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

_______________________________________________
mif mailing list
mif@ietf.org
https://w