Re: [Monami6] What are the mobility issues vs generic issues ?

[Masafumi Watari <[e-mail]>]

Hi Marcelo,

(Could someone fix the "reply-to: [e-mail]."  I'm
receiving duplicated mails.)

On 2005/07/29 5:16, marcelo bagnulo braun wrote:
> 
> El 28/07/2005, a las 5:08, Thierry Ernst escribió:
> 
>>
>>
>>> But i mean, i don't see how this is meaningful for a bof
>>> presentation... As i said, imho in a bof the problem space is to be
>>> explored and imho the shim could contribute with a significant part to
>>> solve the problem in hand...
>>
>>
>> The problem space is explored in the pb statements drafts, those draft
>> will need to be improved, but I don't think the BOF can be devoted to
>> improve the drafts. The BOF should be devoted to set up the WG, and one
>> of the miltestone of the WG is to publish such a PB Statement draft as a
>> WG document. I count on you to improve this WG PB Statement draft if the
>> WG is set up. If the WG is not set up, then, I don't see any venue for
>> such work going on. So, I think that if you think this pb deserves
>> consideration, the best is to push for this WG to be created with an
>> acceptable set of milestones including this PB statement document.
>>
> 
> I am all for the presentation of the pb statement draft but...
> 
> The question is: why other solutions drafts can be presented and the 
> shim solution/approach cannot be presented?

I think this is going into a loop.  If shim can provide a solution to
provide multiple CoA registration, which the WG is looking for as a
short term problem to solve, then it should be presented.  Otherwise
we would first need a charter that explicitly says we need both
mechanisms.

>>>>>>> I mean, in the included agenda there is a section where solutions
>>>>>>
>>>>>> will> be presented:
>>>>>>
>>>>>>> So, my question to you is why do you think that it is ok to
>>>>
>>>> present>>> these proposed solutions and not the shim approach?
>>>>
>>>>>>>
>>>>>>> IMHO, it is ok to explore the solution space in a bof and the
>>>>
>>>> shim>>> should be presented, just as any of the other approaches....
>>>>
>>>>>>
>>>>>> Well, 1st Shim6 is not a solution but an approach, am I right on
>>>>>> this ?
>>>>>>
>>>>>
>>>>> not sure what would be the difference, but in the draft presented
>>>>
>>>> you> can find a proposal to support multiple HoAs in MIP
>>>>
>>>> Ah, OK, then I may see where we don't understand each other.  The
>>>> support of multiple HoAs is not a MIP-specific issue (please refer
>>>> to draft-montavont-mobileip-multihoming-pb-statement).
>>>
>>>
>>>
>>> I copy your sentence above: The support of multiple HoAs is not a
>>> MIP-specific issue
>>>
>>> HoAs are defined by the MIP spec, right?
>>> so how come that the support of multiple Hoas is not MIP specific???
>>>
>>> sorry but, it seems a contradiction to me
>>
>>
>> Where is the contradiction ? The HoA and the CoAs are mobility terms,
>> there have a meaningful significance only when a CoA is bound to the
>> HoA, i.e. when the MN wants to maintain his sessions when located on
>> another link than the home link.
>>
>> When located on the home link, you can call it a HoA if you want, but
>> this is just a global address right, as the MN doesn't send BUs, etc.
>>
>> To me, having multiple HoA just mean having multiple global addresses,
>> which is a multihoming configuration which is bring some issues, but not
>> specific to mobility.
> 
> 
> Well, i don't think it is so simple.
> When the MN is roaming the MIP protocol makes a clear distinction 
> between the CoAs and the HoAs, and it is not the same for a MN to start 
> a communication using the CoA or the HoA as upper layer identifier. That 
> is exactly why, there is a big difference in the mechanisms required to 
> support multiple CoAs and multiple HoAs.
> The MIP protocol makes a great deal of difference in what is a CoA and 
> what is a HoA. In order to support multiple HoAs, the constraints 
> imposed by the role of being a MIP HoAs must be respected by the 
> mechanism (for instance regarding to periodical RR checks for instance, 
> that for the HoA must always be performed with the same HoA, while the 
> CoA can actually change)
> 
> So supporting multiple HoAs is imho very much related with the HoA role 
> of MIP and so it is very much related with MIP

This is clear to me.  One thing I don't understand is that if shim is
layered above ip, then wouldn't shim6 still work to provide its multiple
HoA and failover mechanisms even after multiple CoA mechanism is
defined?  Or is shim6 also target to provide such mechanism?

regards,
watari

>> On the other hand, having multiple CoAs, which is also a mutihoming
>> configuration, brings a mip-specific issue when the MN wants to register
>> more than one CoA with the same HoA. So, the mip-specific issue is
>> called"Binding Multiple CoAs to a given HoA".
>>
>> Marcelo, would you react according to
>> draft-montavont-mobileip-multihoming-pb-statement where there is
>> no "multiple HoA" issue ? There is some text about this
>> configuration under the "Path Selection" issue, which is not ranged
>> under the MIP issue.
>>
> 
> As i read it, registering multiple CoAs was a MIP issue because the 
> perceived solution was a modification in the MIP protocol. OTOH, the 
> mmultiple HoA support can perhaps be solved without changing MIP.
> 
> Actually, now that you make this cosnideration, i can think of way of 
> dealing with multiple CoAs without modifying MIP and i can also think in 
> ways of supporting multiple HoAs just modifying MIP, so, at this point i 
> would argue that they are pretty much at the same level.
> ...
 >
>>> In the charter it is clearly stated that:
>>>
>>> Basically, mobile nodes with multiple interfaces (likely bound to
>>> distinct HAs) would end up into having multiple home addresses and
>>>                                         ^^^^^^^^^^^^^^^^^^^^^^^
>>
>>
>> So what ? It is discussed as a configuration, not as an  issue that the
>> WG will have to deal with.
>>
>>> /or care-of addresses. Such multihoming configuration results in a
>>> multitude of paths and a number associated issues: multiple path
>>> establishment, path selection and path redirection as multiple
>>> pairs of home addresses and care-of addresses would have to be
>>> maintained between the mobile node and its home agent(s). Some of
>>> the issues are very specific to mobility and generally apply to
>>> both mobile hosts operating Mobile IPv6 and mobile routers
>>> operating NEMO Basic Support. It is however expected that
>>> Mobile IPv6 and NEMO Basic Support would be affected by small
>>> straight forward changes (e.g. multiple CoAs registration),
>>> whereas additional non-MIP-specific mechanisms may be needed
>>> to fully benefit from the multihoming configuration.
>>>
>>> Also in the problem statement draft the case of multiple HoAs is
>>> clearly considered
>>
>>
>> You speak about configuration or issues ? So far, we have not written
>> anywhere that we want to solve the issues that are related with
>> having multiple HoAs (i.e. having multilple global addresses, see my
>> earlier comment).
>>
>>> So, why do say that the multiple HoAs case is out of the scope of the
>>> BoF?
>>
>>
>> Either you don't understand the scope of Monami6 for some reasons
>> based on past assumptions or different perceptions, or either I didn't
>> explain things correctly.
>>
>>> I mean, IMHO MIPv6 multihoming is much more than just registering
>>> multiple CoAs, as it is described in the charter that i quoted above
>>> and it is explained in the problem statement draft... are you
>>> proposing to make a whole WG to define how to register multiple CoAs?
>>>
>>> I guess that the point of a MIP multihoming wg would be to solve the
>>> mip multihoming problem, in all its complexity and trying to deal with
>>> most of the problems identifed in the problem statement.
>>
>>
>> I think I wrote the following several times already: the pb statement is
>> trying to be exhaustive into LISTING the issues that are coming with
>> multihoming nodes operating MIP6 or NEMO BS (i.e. when they have
>> multiple HoAs or CoAs.). The PB statement is expected to be one of the
>> deliverable of the WG. The WG would work on the very MIP and NEMO
>> specific issues (such as registering multiple CoAs with a HoA), and, for
>> the other issues, it will seek help or place requirements with other
>> WGs. So, I take the issues coming with Multiple CoAs as not failing into
>> the issues the Monami6 WG wants to solve, but as issues that would be
>> solve somewhere (and with which Monami6 should cooperate).
>>
>>>>  so it's perfect if Shim6 is doing is, in which case
>>>> Monami6 would have to guarentee the interaction, which is exactly
>>>> what the charter is attempting to say.
>>>>
>>>> So, I think we agree on the far-end implications, but possibly not
>>>> on the meaning of the monami6 wording.
>>>>
>>>
>>> perhaps we don't agree on the goal of a wg for dealing with mip
>>> multihoming.
>>
>>
>> Yes, it seems we don't.
>>
>>> we seem to agree with what the problem is, since i guess we both
>>> somehow agree with the problem statement draft, but you seem not to be
>>> interested in solving the whole problem described there, but just
>>> registering multiple CoAs, is this correct?
>>
>>
>> Not just "registering multiple CoAs", but also the other mobility
>> specific issues.  In draft montavont we have a set of issues. If you
>> think that there are additional mobility issues, please comment on
>> another thread, this will help to understand your point.
>>
> 
> ok, i think we finally agreed that what we disagree is in the scope of 
> the proposed work.
> 
> IMHO, as i mentioned to Nicolas, if we think that supporting MIP 
> multihoming is important (and i think it is) then the goal of the 
> proposed working group should be to provide mip multihoming support. 
> This implies to solve as much of the problems identified in the pb 
> statement draft, not just the easy or direct ones.
> 
> Regards, marcelo
> 
> 
> 
>> Thierry
>>
>>
>>
>>
>>
>> _______________________________________________
>> Monami6 mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/monami6
>>
> 
> 
> _______________________________________________
> Monami6 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/monami6
> 

_______________________________________________
Monami6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/monami6