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

From: Thierry Ernst <[email-masked]>
Date: Wed, 27 Jul 2005 19:28:58 +0900

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:

- why do you consider the Shim6 layer over the Mip6 layer?
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 ?

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

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

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

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 

Thierry

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 27 Jul 2005 18:58:06 +0200

Hi Thierry,

thanks for reading and commenting the draft

> I have some questions that may appear a little bit stupid, but it may

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

> 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

> 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

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

> 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

> - Section 4: [M6REFER]: reference not present in reference section. 

we will check these out, thanks, marcelo

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 27 Jul 2005 15:01:09 -0400

Hi Marcelo,

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

marcelo bagnulo braun wrote:

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

> 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

> - the support of multiple HoAs could be provided using the SHIM 
> support in the CN without requiring additional mechanisms
> IMHO all these mechanisms are worth to be explored and see if the 
> match with the requirements imposed by mip multihoming
>
>

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 27 Jul 2005 15:01:09 -0400

Hi Marcelo,

Nicolas

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Jul 2005 08:11:48 -0700

> layer, I mean both of them sitting together, not one above the other ?

That would be a good topic to discuss at the monami6 BoF, wouldn't it :-)

> deploy Shim6 for MIP6-enabled nodes than for non-MIP6 enabled nodes.

Likewise.

Let's get real. If monami6 is going to go anywhere then folks would at 
least need to understand how MIP6 might interact with other pieces in 
the multihoming landscape.

Which is why I find it mind boggling that we can't discuss how MIP6+mcoa 
could relate to shim6.
Once we can move past that particular point, I can offer some technical 
answers to your questions.

> - Section 2: wouldn't be useful to define what a shim is ?

Hmm "shim" seems to be in rather common usage to describe thin 
layers/sublayers that are inserted in the stack.

> - Section 4: [M6REFER]: reference not present in reference section. Must

Oops.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Jul 2005 08:11:48 -0700

Likewise.

Oops.

    Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 28 Jul 2005 21:45:20 +0200

Hi Nicolas,

> interaction?

i think that if we come to the conclusion that the shim can help for 
MIP multihoming, then the work about shim-mip interaction should be 
done in monami imho

>  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.
>
>>
>> supported, and imho there are security mechanisms that could deal 
>> with this requirement.
>>
> 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.

imho, this is exactly why we need to discuss this now, so if we come 
with additional requirements for the shim in order to provide a better 
support for mobility, we can tell them to the shim guys, so it gets 
done from the start.
As i mentioned already, imho a very important point that needs to 
consider is deployment effort. If we get the shim to be be deployed 
from the start with all the features required to support mip 
multihoming, the deployment effort will be greatly simplified.

Regards, marcelo

>> - The failure detection mechanisms and the path exploration 
>> mechanisms defined by the shim could be used (for HoAs and perhaps 
>> for CoAs)