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