[Netext] next steps for netext

[sgundave at cisco.com (Sri Gundavelli)]

Hi Teemu,


On Wed, 22 Apr 2009, teemu.savolainen at nokia.com wrote:

> Hi Sri,
>
> Sorry for even longer delay. I believe we are in sync, so no other comments. Would the "We can always state our requirements on the host.." take a form of Informational/BCP document?
>

As you know, this topic on host requirements is being discussed. We
have to agree upon the following:

- MN notifying the attachment and handover preferences to the network,
   here the events are clear per 5213
- And additionally any flow specific preferences, if we converge on the
   new extensions
- The type of interface for this layer to achieve this and that
   determines how we specify our requirements, informative or in a
   standards track doc.


Regards
Sri



> Best regards,
>
> 	Teemu
>
>> -----Original Message-----
>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>> Sent: 16 April, 2009 00:14
>> To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>> Cc: Patil Basavaraj (Nokia-D/Dallas); netext at mail.mobileip.jp
>> Subject: RE: [Netext] next steps for netext
>>
>> Hi Teemu,
>>
>> Sorry for the delayed response. Please see inline.
>>
>>>
>>> There are many OS'es, some of which are proprietary and/or
>> used in embedded and/or strongly controlled devices - in such
>> cases it may not be possible just to run a tool or just
>> install application to do the trick even if the device is
>> based on open OS (and especially not by the end users of those
>> systems). These kinds of devices are pretty common in some
>> environments where PMIP6 is planned to be used.. Support for
>> PMIP6 based inter-access handovers would definitely be
>> considered as a change that would need to be justified,
>> implemented, and verified.
>>>
>>
>> You make good points. I agree with you and Domagoj that to be
>> able to say we have a complete solution for inter-tech
>> handoffs, there has to be some support from the host. As you
>> earlier put it, the solution has to assume few things on the
>> host, with respect configuration or might require some special
>> application support. But, before we call it a "host change",
>> lets make sure we certainly require changes to 4861 or other
>> IETF specs, as that appears to be the definition of "host
>> change", in the absence of a standard definition of "standard
>> host". We can always state our requirements on the host for
>> supporting  a given feature and move on.
>>
>> A solution such as a using virtual interface, to most part,
>> allows the host to be able to perform handoffs, between
>> interfaces. Should not be an issue. However, we might still
>> require the following, that may qualify as a "host change",
>> but depends on how the solution is built.
>>
>> - Handoff hint exchange between the network and the host. Notifying
>>   the purpose of a given attachment, handoff vs new attachment.
>>
>> - For flow management, network and the host being in sync w.r.t to
>>   what flows are being moved around.
>>
>> - Connection Manager, a common component which cant be avoided, CMIP
>>   or PMIP.
>>
>> As you pointed out to your docs, broadly the above
>> requirements should be sufficient. May be MN-AR interface doc
>> would have helped here, but we killed it.
>>
>>
>>> From my perspective the L2 changes are not very feasible approach:
>>> existing L$
>>
>> Depends on how we build that interface layer. May be an
>> application interface, or some minimal extensions to ND
>> options, need not be
>> L2 change.
>>
>>
>>
>>
>> Regards
>> Sri
>>
>>
>>
>>
>>
>>
>>
>>
>>> In the context of IETF - and wider - discussion, I have been
>> concerned about the message I often hear: that PMIP6 would not
>> require host changes for inter-access mobility. The problem is
>> that some actually read that message literally.
>>>
>>> In
>> http://tools.ietf.org/html/draft-premec-netlmm-intertech-handov
>> er-01 we describe at least some of the impacts (with also
>> solution considerations & proposals):
>>> - multihoming & handoffs (when the address should be moved from one
>>> access to another, when to ask for different address for different
>>> access, when to have same address on multiple accesses simultanously
>>> and also have mechahisms for flow distribution)
>>> - overlapping IPv4 address spaces (how to know if 192.168.0.1 on two
>>> interfaces is logically the same or different address)
>>> - different MTUs
>>> - zero physical interface situation (i.e. the transition period when
>>> old access goes away and before the new access comes available)
>>>
>>> From my perspective the L2 changes are not very feasible
>> approach: existing L2s would need to be changed (=very
>> difficult to get done), and future L2 developers would also
>> need to take care of this dependency. It is easier to handle
>> mobility for IP at L3.
>>>
>>> Some people have been concerned on interoperability, but I
>> don't think that is an issue: the hosts that would not
>> implement suggested host changes (virtual interfaces, possibly
>> required L3 signaling for advanced handoff scenarios) would
>> work just as they do if they don't support client mobile IP
>> either - they simply do not get seamless inter-technology
>> handovers, but will need to manage with application level
>> reconnection/multihoming techniques.
>>>
>>> Best regards,
>>>
>>> 	Teemu
>>