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

marcelo bagnulo braun <marcelo@it.uc3m.es> Thu, 28 July 2005 20:22 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyEtL-0000IP-Jd; Thu, 28 Jul 2005 16:22:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyEtH-0000HO-BB for monami6@megatron.ietf.org; Thu, 28 Jul 2005 16:22:03 -0400
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26087 for <monami6@lists.ietf.org>; Thu, 28 Jul 2005 16:21:57 -0400 (EDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 977345E70E for <monami6@lists.ietf.org>; Thu, 28 Jul 2005 22:21:28 +0200 (CEST)
Received: from [163.117.203.154] (unknown [163.117.203.154]) by smtp01.uc3m.es (Postfix) with ESMTP id 43C4D5E7EC for <monami6@lists.ietf.org>; Thu, 28 Jul 2005 22:21:28 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <20050728120823.50ba4853.ernst@sfc.wide.ad.jp>
References: <000001c59272$b66bc3d0$8202a8c0@SWD> <f0647a69c739f35417e1fc522fabf204@it.uc3m.es> <20050727165904.38d2e064.ernst@sfc.wide.ad.jp> <1f5cff65cba3568296f43911a318a5e3@it.uc3m.es> <20050727190033.1c7f3d3c.ernst@sfc.wide.ad.jp> <f7497cc33f3280163ef488e4537e07b5@it.uc3m.es> <20050728120823.50ba4853.ernst@sfc.wide.ad.jp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Message-Id: <183c2d8a60c5cadc75187497af7fb3e0@it.uc3m.es>
Content-Transfer-Encoding: quoted-printable
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: Re: [Monami6] What are the mobility issues vs generic issues ?
Date: Thu, 28 Jul 2005 22:16:27 +0200
To: Monami6 BOF proposal <monami6@ietf.org>
X-Mailer: Apple Mail (2.622)
Content-Transfer-Encoding: quoted-printable
Cc:
X-BeenThere: monami6@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Monami6 BOF proposal <monami6@lists.ietf.org>
List-Id: Monami6 BOF proposal <monami6.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/monami6>
List-Post: <mailto:monami6@lists.ietf.org>
List-Help: <mailto:monami6-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@lists.ietf.org?subject=subscribe>
Sender: monami6-bounces@lists.ietf.org
Errors-To: monami6-bounces@lists.ietf.org

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

>
> 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
> Monami6@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/monami6
>


_______________________________________________
Monami6 mailing list
Monami6@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/monami6