[Netext] next steps for netext

Hi Marco,

Fully agree. Unless the enhancements we develop in netext disables
mobility support for legacy/unmodified nodes (where I mean here is all
the nodes that RFC5213 provides support now), it is worthwhile at
least analysing these solutions, IMHO.

Regards,

Carlos

2009/4/7 Marco Liebsch <marco.liebsch at nw.neclab.eu>:
> We should take RFC4831 as reference doc, which is the design goals document,
> not RFC4830, as it's the PS. It says what is acceptable, in my
> understanding. Referring
> to section 3.7, which is about Support for Unmodified Hosts, it first says
> 'Support' for
> unmodified hosts. That's what RFC5213 does. It does not exclude modified
> hosts.
> More important, the same section says: "Note that this goal does NOT mean
> that the
> mobile node has no software at all associated with mobility."... That looks
> pretty clear.
>
> In my opinion, important is that unmodified hosts are supported, which is a
> requirement
> we meet. To support enhanced use cases, some supporting software seems to be
> acceptable in my opinion and obviously also according to RFC4831. We should
> distinguish modification for mobility management, which is not what we want
> to do,
> and enabling local functions, such as the use of multiple interfaces, where
> you have
> to add routes, configure interfaces etc. to enable the use case.
>
> marco
>
>
> Hesham Soliman schrieb:
>>
>>
>>>>
>>>> => I think you're distinguishing between modified and unmodified based
>>>> on
>>>> whether the modification affects IETF protocols or not. That's fine, but
>>>> for
>>>> those that did not attend the BoF, our conclusions were that you will
>>>> either
>>>> end up modifying the host (i.e. Adding new SW) and adding new signalling
>>>> on
>>>> L2 to handle the multihoming cases, or you can stick with MIP.
>>>> My opinion, and at least half the room's was that this is not a good way
>>>> to
>>>>
>>>
>>> We can discuss what implies host changes and why this is such a big deal
>>> anyway. But I don't think that half the room was in agreement as such. At
>>> least from the count of hands raised for the question about whether we
>>> should work on multihoming and intertech handovers it was about 18-9 (in
>>> favor).
>>
>> => I think the question changed a few times :) The final question (which
>> was
>> specific to whether people wanted to work with this or not) showed a split
>> room. The host changes are not a big deal but they are mentioned here
>> because they
>> were one of the very few reasons for using NETLMM in the first place: Host
>> changes (adding new SW to the host) and signalling from the MN. You can
>> see
>> them in section 4 of RFC 4830.
>>
>>
>>>>
>>>> go and that it's better to stick with MIP instead of relying on a
>>>> solution
>>>> that will:
>>>> - work on some L2s and not others,
>>>>
>>>
>>> We have no ability to specify changes to L2 anyway. However if some L2s
>>> do
>>> have such capability, why would we not specify how multihoming would work
>>> in
>>> such scenarios.
>>>
>>
>> => Because we already have a solution that works in all L2s, doesn't
>> require
>> L2 changes that we don't control and doesn't cause confusing host config
>> solutions.
>>
>>>>
>>>> - Require additional SW and config on the host which is not done
>>>> anywhere
>>>> today, and
>>>>
>>>
>>> Why is there as much of a concern about additional SW or config? After
>>> all
>>> everything (or most of it anyway) that we do in the IETF requires
>>> configurations, protocol changes, changes to SW etc. There is nothing
>>> unique
>>> about this.
>>
>> => Sure, but see above and see RFC 4830. These were the reasons for using
>> PMIP in the first place. We can't have it both ways, or can we? :)
>>
>>
>>>>
>>>> - Require L2 signalling which is out of our scope in IETF
>>>>
>>>
>>> Agree. We cannot do anything about L2s. But we could specify
>>> (informatively)
>>> what L2 capabilities would enable these features if that is the
>>> conclusion
>>> that we arrive at.
>>>
>>
>> => We can, but I don't know why we should do that when a solution already
>> exists. Especially when the alternative is inferior in terms of its
>> applicability.
>>
>> Hesham
>>
>>
>>>
>>> -Raj
>>>
>>>
>>>>
>>>> This is why I think we should stick with the charter that Jari sent.
>>>>
>>>>
>>>> Hesham
>>>>
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> NetExt mailing list
>>>>> NetExt at mail.mobileip.jp
>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>
>>>>
>>>>
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>