Re: [Monami6] Fwd: I-D ACTION:draft-bagnulo-shim6-mip-00.txt

marcelo bagnulo braun <marcelo@it.uc3m.es> Wed, 27 July 2005 16:59 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpGB-0007rA-Bh; Wed, 27 Jul 2005 12:59:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpGA-0007pC-IL for monami6@megatron.ietf.org; Wed, 27 Jul 2005 12:59:58 -0400
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14047 for <monami6@lists.ietf.org>; Wed, 27 Jul 2005 12:59:53 -0400 (EDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 10EC64AB51 for <monami6@lists.ietf.org>; Wed, 27 Jul 2005 18:59:26 +0200 (CEST)
Received: from [163.117.203.38] (unknown [163.117.203.38]) by smtp02.uc3m.es (Postfix) with ESMTP id AF7324AB4C for <monami6@lists.ietf.org>; Wed, 27 Jul 2005 18:59:23 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <20050727190033.1c7f3d3c.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>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Message-Id: <f7497cc33f3280163ef488e4537e07b5@it.uc3m.es>
Content-Transfer-Encoding: quoted-printable
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: Re: [Monami6] Fwd: I-D ACTION:draft-bagnulo-shim6-mip-00.txt
Date: Wed, 27 Jul 2005 18:41:03 +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 27/07/2005, a las 12:00, Thierry Ernst escribió:


>
>> and i am not sure what do you mean by long standing... in which way
>> the other solutions being presented are long standing?
>
> Solutions that exist for a long time and have been implemented, and 
> even
> tested in real-life trials. I think Shim6 is still a little bit behind
> this.
>

i feel we are going way too fine grained here for a bof presentation... 
are you telling that the all the drafts that are being presented have 
been tested in real life? Do you have any references (pointers) to that 
real life trails of those solutions?
besides what do you consider to be long time? 1 year, 2 years? and this 
long time in which status...? i mean SHIM has been a wg draft for about 
6 months now, and there is a whole wg working in its design, can you 
say that any similar amount of effort is being invested in any of the 
other solutions?

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


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

>
>
> So, the purpose of Monami6 is:
>
> - Develop Standard Track specifications for the mobility-specific 
> issues
> that work both for mobile hosts operating Mobile IPv6 and mobile 
> routers
> operating NEMO Basic Support and their variant (FMIPv6, HMIPv6, etc),
>

right, supporting multiple HoAs seems to be a core MIP specific issue

> - Seek for help or push the other WGs to standardize solutions not
> specific to mobility.
>
> So, Shim6 is a valid solution for an issue which should potentialy be
> solved in another WG. The charter basically try to say that Monami6 
> will
> seek help and place requirements on other WGs for such issues. It may
> eventualy solve the issue by itself if not other WG is chartered to do
> it.
>
>>> Second, the other drafts are clearly extensions to MIP, right ?
>>>
>>> MIP6 and NEMO BS are standards, combining some of the features like
>>> MCoA
>>> into a standard can give us a RFC by early 2006. What's the time
>>> line for Shmi6 ? I don't know.
>>>
>>> If you could explain on the ML what Shim6 can bring by early 2006,
>>> this would help.
>>>
>
>> But the point is that supporting multiple HoAs will imply
>> modifications in the CN (i.e. all the hosts in the internet)
>
> Agree.
>
>> So, any solution for this problem will take some time to deploy.
>
> Agree.
>
>> The point being made is that the shim will be deployed for supporting
>> site multihoming, so if the shim can also provide support to mip
>> multihoming, the deployment effort would be greatly reduced. Not
>> exploring the possibility of using the shim and finding out what can
>> it provides may imply important additional deployment cost for
>> supporting MIP multihoming
>
> Agree with you all the way long.
>
>> So, i see it exactly the opposite way, shim would provide a faster
>> track to deploy modifications that involve CNs, since it would be more
>> reasons to deploy it than (i.e. site multihoming)
>
> The point is that a this moment we have no intention to solve the
> multiple HoA probem,

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

So, why do say that the multiple HoAs case is out of the scope of the 
BoF?

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



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

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?

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