[Netext] next steps for netext

[sgundave at cisco.com (Sri Gundavelli)]

Hi Raj:

Just one comment.



On Mon, 6 Apr 2009, Basavaraj.Patil at nokia.com wrote:

>
> Hi Jari,
>
> I think the discussion (or argument as you put it) at the BoF was useful. It
> highlighted the fact that there is a good amount of misunderstanding on what
> can be done w.r.t multihoming or inter-technology handovers.
> There are some aspects of multihoming that can be clearly separated, i.e the
> flow mobility vs the ability of having a host attached via multiple
> interfaces to the same LMA or dynamically establishing additional moobility
> sessions. We could narrow down aspects of multihoming which could fit into
> the scope of the charter.
> There has been some discussion (online and offline) about the
> inter-technology handovers. The intent of the work item within Netext is to
> clarify host behavior to support such handovers.
> There is obviously quite a strong view of making host changes to support any
> of the features (multihoming or intertechnology handovers). I believe that
> there will be a class of hosts which will have the capability to support
> multihoming and support inter-technology handovers. As long as we do not
> break the PMIP6 RFC (5213), I think it makes sense to specify these
> features.

> For unmodiified hosts, we can agree that they will not be able to
> perform inter-tech handovers or be support any of the multihoming scenarios.

No. RFC-5213 support inter-tech handoffs. Potentially, an "unmodified
host" can leverage that feature. As we discussed earlier, we have a major
terminology problem, on what is "modified" vs "un modified". If I use
Windows SDK and implement a virtual interface, no one can claim the host
is now modified. Its an application, or a configuration such as using
bridge ctl utuility in Linux. Its not changing any of the IETF
specifications. We also need to revisit this in the context of connection
mgr requirements in both client-based and network-based mobility models,
which is a common requirement, or other intefaces such as MIF, for
flow template push to the terminal.

I share the same view with respect to all your other comments. We need
to seperate the cases of flow mobility vs basic handoff as allowed in
5213. In the BOF, we discussed mostly flow mobility and not the basic
handoff cases supported today in 5213.

Sri