Re: [Monami6] More comments on draft-bagnulo-shim6-mip-00

Nicolas Montavont <montavon@nist.gov> Wed, 27 July 2005 19:03 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrC1-000781-J5; Wed, 27 Jul 2005 15:03:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxrBz-00077n-R2 for monami6@megatron.ietf.org; Wed, 27 Jul 2005 15:03:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23969 for <monami6@ietf.org>; Wed, 27 Jul 2005 15:03:45 -0400 (EDT)
Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxrhH-00083W-4X for monami6@ietf.org; Wed, 27 Jul 2005 15:36:09 -0400
Received: from [129.6.50.9] (scorpion.antd.nist.gov [129.6.50.9]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j6RJ3eqo010136; Wed, 27 Jul 2005 15:03:40 -0400
Message-ID: <42E7D9F5.5000109@nist.gov>
Date: Wed, 27 Jul 2005 15:01:09 -0400
From: Nicolas Montavont <montavon@nist.gov>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050602)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Monami6 BOF proposal <monami6@ietf.org>
Subject: Re: [Monami6] More comments on draft-bagnulo-shim6-mip-00
References: <20050727192858.16120217.ernst@sfc.wide.ad.jp> <d5834a8280a7a7a61d62a792fbf4b465@it.uc3m.es>
In-Reply-To: <d5834a8280a7a7a61d62a792fbf4b465@it.uc3m.es>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: montavon@nist.gov
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.nist.gov id j6RJ3eqo010136
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Content-Transfer-Encoding: quoted-printable
Cc: Monami6 BOF proposal <monami6@ietf.org>
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

Hi Marcelo,

I just have one question and one observation below...

marcelo bagnulo braun wrote:

> Hi Thierry,
>
> thanks for reading and commenting the draft
>
> El 27/07/2005, a las 12:28, Thierry Ernst escribió:
>
>>
>> I start a new thread since the other one "[Monami6] Fwd: I-D
>> ACTION:draft-bagnulo-shim6-mip-00.txt" has diverged from the draft
>> itself.
>> I have some questions that may appear a little bit stupid, but it may
>> help to clarify things:
>>
>
> questions are always welcomed and there ain't such things as stupid 
> questions,
>
>> - why do you consider the Shim6 layer over the Mip6 layer?
>
>
> actually, in the initial discussions we cosnidered both SHIM over MIP 
> and also MIP over SHIM configurations, but we finally thought that 
> cosnidering all the possibilities would result in a major headache for 
> anyone who read the draft. So we decided to keep the configurations 
> that made a clear case and provide a clear benefit. In particular, 
> layering the SHIM over MIP results in the possibility of supporting 
> multiple Hoas
>
>> Couldn't the shim6 layer be cotemplated as an extension of the MIP6
>> layer, I mean both of them sitting together, not one above the other ?
>>
>
> i don't know...
> I mean, i see them as modular items, and we played to see how the 
> interact without integrating them
> I am afraid that integrating them would result in major modifications 
> in the SHIM and in the MIP modules.
> So, the first approach was to see if layering one over the other would 
> result in useful outcomes
>
>> - for Shim, there is a need for a protocol to exchange the set of
>> locators. Couldn't be MIP6 extensions used for such a task (I'm not
>> contemplating MIP6 as the protocol for doing it, I'm rather thinking
>> that given a node for a MIP6 protocol stack, it could be easier to
>> deploy Shim6 for MIP6-enabled nodes than for non-MIP6 enabled nodes.
>>
>
> i think that this would be possible, i.e. allowing coas to be included 
> in the locator set of SHIM. Actually this reminds me to the celp 
> proposal by D. Crocker a while ago.
>
> I guess that we should consider security implications, depending on 
> how CoAs are validated...
>
> This is one of the points where MIP SHIM interaction would need 
> further exploration i guess

and where do you see the discussion and the investigation of this 
interaction? I mean, if you think that this interaction should be done 
in Monami6, we should modify the current charter to explicitly state the 
point. I think this is what Thierry meant.

>
>> - on 050714 you said "the SHIM work currently does not
>> considers the mobility scenario, so adding/removing addresses is still
>> somehow undefined": does Shim6 consider that all the set of locators is
>> known in advance ; can't new locators be added dynamically, or you just
>> mean the operation for doing is undefined ?
>>
>
> well, the charter explicetly says that dynamic locators sets must be 
> supported, and imho there are security mechanisms that could deal with 
> this requirement.
>
> So i would go for the second option, that the operation for doing it 
> is not yet completelly specified.

This is where we may think that it may be too soon to deal with this at 
the BOF. As the specification is still under revision / discussion, it 
is hard to give an accurate evaluation of it, and it is even harder to 
make plan on what a potantial WG group (as Monami6) could bring to this. 
This is why we first would like to focus on existing RFCs related to 
mobility, raise the issues about them and standardize solutions.

Nicolas

>
>> - on 050714 you wrote "SHIM may be useful to  provide some of the
>> features required to multihoming support in the MIP protocol": Could you
>> detail what features you are thinking about ?
>>
>
> I think the the SHIM work can be useful in several aspects:
> - the support of multiple HoAs could be provided using the SHIM 
> support in the CN without requiring additional mechanisms
> - The failure detection mechanisms and the path exploration mechanisms 
> defined by the shim could be used (for HoAs and perhaps for CoAs)
> - The ingress filtering mechanisms could be useful both in the Home 
> network and in the visited network
> - The address selection mechanism (in particular retrial with 
> alternative source address) could also be useful to initiate 
> communications after outaages
>
> IMHO all these mechanisms are worth to be explored and see if the 
> match with the requirements imposed by mip multihoming
>
>
>> Note, I also read  draft-ietf-shim6-l3shim-00.txt and:
>>
>> - Section 2: wouldn't be useful to define what a shim is ?
>> - Section 4: [M6REFER]: reference not present in reference section. Must
>> be a typo
>>
>
> we will check these out, thanks, 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
>


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