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

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 14 Jul 2005 11:52:07 +0200

Hi folks,

we have submitted a draft considering the interaction between SHIM and 
MIP. We think that the shim could be part of a solution for host 
multihoming and some of the possibilities for this are explored in the 
draft.

We would like to have the opportunity to present it in the monami6 bof 
in Paris, do you think this would be ok?

Regards, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 13 de julio de 2005 21:50:01 GMT+02:00
> Para: [email-masked]
> Asunto: I-D ACTION:draft-bagnulo-shim6-mip-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: SHIM - MIPv6 Interaction
> 	Author(s)	: M. Bagnulo, E. Nordmark
> 	Filename	: draft-bagnulo-shim6-mip-00.txt
> 	Pages		: 8
> 	Date		: 2005-7-13
> 	
>    In this note, we explore the interaction between the SHIM protocol
>    and MIPv6 protocol, identifying potential benefits and difficulties.
>    The analysis will consider the two modes of operation of MIPv6: the
>    Bidirectional Tunnel (BT) mode where the communication is routed
>    through the Home Agent and the Route Optimization (RO) mode, where
>    the communication flows directly between the Correspondent node and
>    the mobile node.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-mip-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-bagnulo-shim6-mip-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-bagnulo-shim6-mip-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 14 Jul 2005 20:29:59 +0900

Hi Marcelo,

I didn't read the draft first, but, how does it relate to mobility ?
Monami6 is not simply about host multihoming, but about solving
multihoming issues specifi to MIP or NEMO enabled MNs and MRs

Since Shim6 folks have said they wouldn't spend time looking into the
mobility problem, I fail to see how this is related to Monami6 (I write
this without reading the draft your mention, so my comment may not hold
if you clarify this). 

So, could you clarify on the ML, and match with the current BOF
description and WG charter ? 

Thierry

 On Thu, 14 Jul 2005 11:52:07 +0200
marcelo bagnulo braun <[email-masked]> wrote:

> >    In this note, we explore the interaction between the SHIM
> >    protocol and MIPv6 protocol, identifying potential benefits and
> >    difficulties. The analysis will consider the two modes of
> >    operation of MIPv6: the Bidirectional Tunnel (BT) mode where the
> >    communication is routed through the Home Agent and the Route
> >    Optimization (RO) mode, where the communication flows directly
> >    between the Correspondent node and the mobile node.
> >
> > [email-masked] with the word unsubscribe in the body
> > of the message.
> > You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail
> > 	readers exhibit different behavior, especially when dealing with

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 14 Jul 2005 09:49:34 -0400

Marcelo,

Actually I read the draft and I think it is a really interesting I-D.

And I think it fits very well to the scope of Monami6, since one of our 
goal is also to identify relation between Monami6 and other WGs. The 
success of our meeting also rely on our ability to identify these relations.

I think your work may provide additional requirements for Monami6 when 
developing solutions at one point of time.

I think it would be nice to present it during the BOF, even if maybe it 
is too soon to talk about this. But the conclusion of your presentation 
could be to identify if we should clearly add in our charter the 
production of documents which makes the relation between Monami6 and 
other related WGs.

Otherwise, I'd like to ask you one question about the I-D. At the end of 
paragraph 2, you wrote:

If an alternative CoA is used as alternative locator, then the
   communication will run directly between the MN and the CN in a kind
   of SHIM based RO mode, recovering from the outage.  However, in this
   case, care must be taken because the alternative CoA may become
   unavailable after movement.

I assume that in this case, the communication simply uses the CoA as an 
address (I mean without the MIP6 mechanism) that is why if you change 
this CoA (let say because of a movement), you won't be able to update 
it. And you was able to use this CoA because you set this address in the 
SHIM context. My question is the following: once you change CoA, can't 
you update the SHIM context to use the new CoA in this case? (excuse me 
if my question seems obvious, but I am not familiar with SHIM6...)

Nicolas

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 14 Jul 2005 09:49:34 -0400

Marcelo,

Nicolas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 14 Jul 2005 16:21:07 +0200

Hi Thierry,

> multihoming issues specifi to MIP or NEMO enabled MNs and MRs

well, the idea of the draft is to explore how the SHIM and MIP can 
interact in order to provide multihoming support to MIPv6 nodes.

The point is that as currently specified MIPv6 has some 
limitations/lacks for supporting multihoming. OTOH SHIM provides some 
mechanisms that can help to overcome this limitations. The draft 
explores the interaction between those two, and tries to see if the 
combination can solve some of the problems

> mobility problem,

:-)
well, as i read it, the mobility stuff was out of the shim charter, 
which imho this doesn't means that the shim is not useful to provide 
multihoming support for mobile (MIP) nodes (just that this won't be 
done in the shim wg)

besides, imho it is very important to note that the host multihoming 
problem is much more that supporting multiple addresses in the MIP 
protocol. There are a bunch of additional problems that we need to 
tackle, for instance failure detection, path exploration, identifier 
and locator selection, ingress filtering and so on. Much of these 
problems are being dealt with in the shim arch and imho it would be 
beneficial to explore how suitable are the mechanisms designed in the 
shim wg for dealing with the related problems that appear in the 
provision of host multihoming support.

I hope this clarify your questions, and that you find the draft 
interesting for presentation in the bof

regards, marcelo

>  I fail to see how this is related to Monami6 (I write

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 14 Jul 2005 16:29:23 +0200

Hi Nicolas,

> Actually I read the draft and I think it is a really interesting I-D.

thanks

> And I think it fits very well to the scope of Monami6, since one of 
> our goal is also to identify relation between Monami6 and other WGs. 
> The success of our meeting also rely on our ability to identify these 
> relations.
>
> I think it would be nice to present it during the BOF, even if maybe 
> it is too soon to talk about this. But the conclusion of your 
> presentation could be to identify if we should clearly add in our 
> charter the production of documents which makes the relation between 
> Monami6 and other related WGs.
>
> Otherwise, I'd like to ask you one question about the I-D. At the end 
> of paragraph 2, you wrote:
>
> I assume that in this case, the communication simply uses the CoA as 
> an address (I mean without the MIP6 mechanism) that is why if you 
> change this CoA (let say because of a movement), you won't be able to 
> update it.

well, actually the text is more vague than this... the point is that 
the SHIM work currently does not considers the mobility scenario, so 
adding/removing addresses is still somehow undefined. So, the point 
that the draft is trying to make is that this particular issue needs 
further study, in order to understand how the shim can deal with this.
imho, there are some modes of operation of the shim that could deal 
with this situation, but i am not ssure if it would be a clean approach 
(architecturally speaking) I mean if we are laying the SHIM over the 
MIP, then maybe it wouldn't be the cleanest approach to expose the CoAs 
to the shim, if you see what i mean.

hope this answers your question.

regards, marcelo

>  And you was able to use this CoA because you set this address in the 
> you update the SHIM context to use the new CoA in this case? (excuse 
> me if my question seems obvious, but I am not familiar with SHIM6...)
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 14 Jul 2005 16:29:23 +0200

Hi Nicolas,

thanks

regards, marcelo

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 14 Jul 2005 10:34:41 -0400

Marcelo,

marcelo bagnulo braun wrote:

>> I think your work may provide additional requirements for Monami6 
>> when developing solutions at one point of time.
>>
> with this situation, but i am not ssure if it would be a clean 
> approach (architecturally speaking) I mean if we are laying the SHIM 
> over the MIP, then maybe it wouldn't be the cleanest approach to 
> expose the CoAs to the shim, if you see what i mean.

I can understand that. What you are saying encourage me even more to 
consider your work in Monami6, because ideally I think all issues 
related to Mobility and Multihoming should be dealt in Monami6. Again, 
this is one of our long-term goal, i.e. to unify all work on the 
combination of Multihoming and mobility.

> hope this answers your question.

Sure.

Nicolas

>> SHIM context. My question is the following: once you change CoA, 
>> can't you update the SHIM context to use the new CoA in this case? 
>> (excuse me if my question seems obvious, but I am not familiar with 
>> SHIM6...)
>>
>
>> Nicolas
>>
>> Thierry Ernst wrote:
>>
>>> Hi Marcelo,
>>>
>>>>> Internet-Drafts are also available by anonymous FTP. Login with 
>>>>> the username

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 14 Jul 2005 10:34:41 -0400

Marcelo,

Sure.

Nicolas

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 15 Jul 2005 13:53:13 +0900

Hello Marcelo

I read this draft and finally got clear picture of SHIM6 and MIP6.  
thanks :-)

However, it looks like both protocols just work without modifications:-)
Can you specify the possible technical problems to support SHIM on MIP6?
Any MIP6 issues which this group should deal with?

ryuji

On 2005/07/14, at 18:52, marcelo bagnulo braun wrote:

> Hi folks,
>
> we have submitted a draft considering the interaction between SHIM  
> and MIP. We think that the shim could be part of a solution for  
> host multihoming and some of the possibilities for this are  
> explored in the draft.
>
> We would like to have the opportunity to present it in the monami6  
> bof in Paris, do you think this would be ok?
>
> Regards, marcelo
>
>> [email-masked] with the word unsubscribe in the  
>> body of the message.
>> readers

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 15 Jul 2005 11:20:19 +0200

Hi Ryuji,

> Any MIP6 issues which this group should deal with?

well, shim is not a protocol yet, so what it is expressed in the draft 
it is just what it seemed reasonable to be expected. However, as it 
results from the analysis performed in the draft, SHIM may be useful to 
provide some of the features required to multihoming support in the MIP 
protocol, being a part of the solution to the host multihoming problem
In order to actually make this happen, maybe some considerations w.r.t. 
to host multihoming and compatibility with mip need to be taken into 
account while the actual SHIM protocol design. IMHO, the goal of the 
work here would be two-folded:
- On one hand identify the key issues that need to be provided by the 
shim in order to be useful for the support of multihoming in mip. such 
requirements need to be expressed to the shim wg so that they take it 
into account in the design
- On the other hand, perhaps there are additional mechanisms, 
heuristics and such that are needed to make the shim to fulfill the 
requirements of host multihoming with mip. In such case, those could be 
defined in the monami wg.

coments?

regards, marcelo

>> and MIP. We think that the shim could be part of a solution for host 
>> multihoming and some of the possibilities for this are explored in 
>> the draft.
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 15 Jul 2005 11:20:19 +0200

Hi Ryuji,

coments?

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 15 Jul 2005 03:24:47 -0700

> However, it looks like both protocols just work without modifications:-)

That's a feature.

> Any MIP6 issues which this group should deal with?

There are a few technical issues to look at for the short term.
One that Marcelo touched on yesterday was whether the CoAs on the MN are 
"visible" to the shim6 layer (meaning that shim6 would communicate them 
to the peers/CNs together with its HoAs), or whether the shim6 layer 
only sees the HoAs. In the latter case the shim6 layer on a CN would 
have the ULID->list of HoAs, and the mip6 layer in the CN would have a 
HoA->CoA mapping - potentially different for different HoAs.

In the latter case shim6 and mip6 are completely separated, in that mip6 
RO works as today. And in the former case, shim6 does some form of RO by 
exchanging the CoAs with the CN.

Another short term issue has to do with the potential to register 
multiple CoAs for a single HoA (with the MN, and potentially with a CN 
as well). I think it makes sense to extend the MIP6 BU exchange to do 
this. But a missing piece would be how the HA can tell which CoA is 
working and which might have failed. Some form of probe/test protocol 
would be needed for this. Perhaps (a subset of) the shim6 test protocol 
could be reused for this purpose (See 
draft-ietf-shim6-reach-detect-00.txt for an outline.), instead of 
defining a new probe/test protocol.

There is also a longer term issue in the back of my mind, relating to 
how RO might evolve.
As we can see today both MIP6 RO and shim6 are capable of exchanging the 
CoAs with a peer. But the assumptions and ways to secure such an 
exchange are different. How do we want this to evolve architecturally?
A possibility would be for shim6 to be able to carry all the locators to 
the peer, and explicitly indicating whether a locator is believed to be 
long-term stable, or whether it can go away on a whim. Using such 
information, one can then carry both multiple HoAs and multiple CoAs to 
a CN, and the CN can have various strategies for when it uses a CoA and 
when it falls back to trying one of the HoAs (which can happen when the 
MN moves so a CoA no longer works, and the locator update packet is lost 
etc)

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 15 Jul 2005 03:24:47 -0700

That's a feature.

    Erik

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 21 Jul 2005 06:05:26 +0900

Dear all,

Investigating further the interaction between Shim6 and MIP6 is of
course an approach that I support, but as of today, I fail to see how to
discuss this point with respect to the objectives of the BOF, which are:

- explaining the problem considered by Monami6 and the need to solve it
- explaining our approach into solving it (i.e. the charter)
- get Monami6 approved as a WG

So, I don't see how a slot to discuss the interaction between Shim6 and
MIP6 currently fits our objectives. It may just be missleading or
confusing. But, if the WG is approved, yes, this is something I think we
should take a look at, at IETF64.

If I'm wrong in this, or in any case where you think it should be
discussed at Paris meeting, please explain how you think this would fit
with the objectives of the BOF, and particularly, which of the issues
raised in draft-montavont-mobileip-multihoming-pb-statement this is
related to. Otherwise, I cannot support the request.

I have some more comments to Erik's mail:

On Fri, 15 Jul 2005 03:24:47 -0700
Erik Nordmark <[email-masked]> wrote:

> > Can you specify the possible technical problems to support SHIM on
> > MIP6? Any MIP6 issues which this group should deal with?
> 
> One that Marcelo touched on yesterday was whether the CoAs on the MN
> are "visible" to the shim6 layer (meaning that shim6 would communicate
> them to the peers/CNs together with its HoAs), or whether the shim6
> layer only sees the HoAs. In the latter case the shim6 layer on a CN
> would have the ULID->list of HoAs, and the mip6 layer in the CN would
> have a HoA->CoA mapping - potentially different for different HoAs.

This is an issue which I supported should be covered by Shim6, however,
as far as I remember, the Shim6 WG excluded to work on issues specific
to mobility. The Shim6 WG charter says

  Compatibility will remain for existing mobility mechanisms. It will be
possible to use Mobile IPv6 on a node that also supports Shim6. However,
any optimization or advanced configurations are out of scope of shim6.

  So, I take this as the possible interactions between Shim6 and MIP6
could serve as an input to the Shim6 WG, but that the Shim6 WG will not
host such work. I'm wrong on this or not ? If not, are you considering
this to be dealt with the potential Monami6 WG ? If so, we should
discuss this and I would welcome some new text to put in the Monami6
charter. Then I could understand a need for such a slot in Paris.

> In the latter case shim6 and mip6 are completely separated, in that
> mip6 RO works as today. And in the former case, shim6 does some form
> of RO by exchanging the CoAs with the CN.
> 
> would be needed for this. 

This is an interesting point, and I agree with the need to address this
issue. I think this falls into the issues studied in
draft-montavont-mobileip-multihoming-pb-statement

Also, it could be considered as part of the listed WG output as
expressed by the Monami6 proposed charter.

> Perhaps (a subset of) the shim6 test
> protocol could be reused for this purpose (See 

This is a valid suggestion, but this needs further investigation.  

> As we can see today both MIP6 RO and shim6 are capable of exchanging
> the CoAs with a peer. But the assumptions and ways to secure such an 
> A possibility would be for shim6 to be able to carry all the locators
> to the peer, and explicitly indicating whether a locator is believed
> to be long-term stable, or whether it can go away on a whim. Using
> such information, one can then carry both multiple HoAs and multiple
> CoAs to a CN, and the CN can have various strategies for when it uses
> a CoA and when it falls back to trying one of the HoAs (which can
> happen when the MN moves so a CoA no longer works, and the locator
> update packet is lost etc)

Thierry.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2005 11:22:52 +0200

Hi Thierry,

> related to. Otherwise, I cannot support the request.

The point is that the SHIM work is a potential solution to some of the 
problems defined in draft-montavont-mobileip-multihoming-pb-statement 
(and to some other problems that are not in the draft but need to be 
included in order to really solve the problem, as i detailed in the 
mail i sent commenting this draft)

In particular, the running the shim and MIP is a mechanisms that can be 
used to preserve the established communications through failures in the 
HoA used in the communication (this means that it can be used to 
provide the fault tolerance capabilities required described in sections 
5.2, 5.4, 5.7, 5.8 and 5.9 of 
draft-montavont-mobileip-multihoming-pb-statement)
In addition, the mechanisms defined in the SHIM wg to deal with ingress 
filtering could be applied to deal with the ingress filtering issue 
described in section 6.1.2 of 
draft-montavont-mobileip-multihoming-pb-statement

In addition, you will be needing mechanisms for path failure detection 
(not included in draft-montavont-mobileip-multihoming-pb-statement but 
that are needed to provide proper multihoming support) that the shim 
can provide, as some mechanisms for exploring alternative available 
paths in order to rehome to alternative paths after an outage.

So, there are clearly multiple issues of the ones describe in 
draft-montavont-mobileip-multihoming-pb-statement for which the shim 
seems to be a reasonable candidate for providing a solution

The proposal then is to present the shim as a possible solution for 
some of the problems described in 
draft-montavont-mobileip-multihoming-pb-statement, just as the multiple 
CoAs drafts or the mmi and so on.

Is this a good enough justification for you?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2005 11:22:52 +0200

Hi Thierry,

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 24 Jul 2005 09:45:47 -0700

> - get Monami6 approved as a WG

Thierry,

The last bullet isn't specified in the monami6 BoF text, so I find it 
odd that you list it as a top objective above.

I would think that the purpose of the BoF is to explore the problem 
statement, understand what pieces of the problem is worked on in other 
WGs, and use that as input to determine whether a new WG is needed or 
whether something should be added to the charter of an existing WG.
(This interpretation seems to match what is in the monami6.txt BoF 
description AFAICT.)

> host such work. I'm wrong on this or not ?

I don't think things are that black and white. It would behoove us 
collectively to figure out how to incrementally and in a modular way 
solve the key issues that are at the intersection point between mobility 
and multihoming (and I thought the BoF was an attempt to start to have 
that discussion, but for some odd reason you seem to reject this.)

Once we have a better understanding of the whole space, they we can 
figure out 1) what needs to be added and 2) in what WG to do that,

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 24 Jul 2005 09:45:47 -0700

Thierry,

    Erik

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 25 Jul 2005 12:27:07 +0900

Dear Erik, all,

Erik Nordmark <[email-masked]> wrote:

> > course an approach that I support, but as of today, I fail to see
> > how to discuss this point with respect to the objectives of the BOF,
> > which are:
> > 
> > - explaining the problem considered by Monami6 and the need to solve
> > it- explaining our approach into solving it (i.e. the charter)

Erik, I'm not sure which text you are refering to, the most up to date
in on http://www.nautilus6.org/ietf . Our objective is to set up a new
WG since the BOF has been announced. I cc Margaret just to be sure that
this is a common understanding from our corresponding AD. 

> (This interpretation seems to match what is in the monami6.txt BoF 

Originaly, yes, we are limiting ourselves to explore the problem
statement, but for a while already, we are orienting ourselves to the
actual set up of a WG, with a specific set of milestones are can be
read on http://www.nautilus6.org/ietf

> > 
> > This is an issue which I supported should be covered by Shim6,
> > however, as far as I remember, the Shim6 WG excluded to work on
> > issues specific to mobility. The Shim6 WG charter says
> > 
> > possible to use Mobile IPv6 on a node that also supports Shim6.
> > However, any optimization or advanced configurations are out of
> > scope of shim6.
> > 
> > could serve as an input to the Shim6 WG, but that the Shim6 WG will
> > not host such work. I'm wrong on this or not ?
> 
> solve the key issues that are at the intersection point between
> mobility and multihoming 

What I meant to say is that the signal I received by the Shim6 WG was
clear about saying that the mobility issues wouldn't be dealt by the
Shim6 WG. If things have changed since April, then I'm sorry I didn't
see the changes in the objectives. If on the other hand the objectives
have not changed, I would like to understand the approach you are
considering. If the idea is to include the exploration of the shim as a
WG item into the prospective Monami6 WG, then I would be willing to
support this once the charter is properly worded in such as way. To the
condition it doesn't break the other objectives of Monami6.

> (and I thought the BoF was an attempt to
> start to have that discussion, but for some odd reason you seem to
> reject this.)

I'm not rejecting anything, I think we are not synchronized on the
purpose of the BOF. As chair, I just need to make sure that we can reach
the objectives of the BOF as it is currently expressed and agreed
between the people involved in the set up.
 
> figure out 1) what needs to be added and 2) in what WG to do that,

It depends wha ist the problem you want to address. The first expected
output of the prospective Monami6 WG is a problem statement document, so
this is inline with what you just wrote. Also, we have identified the
need to standardize a solution for registering multiple CoAs with a HA.
Such a standard is needed by some commercial deployment of the mobility
technologies.

Some of the other issues discussed in the draft-montavont PB draft  need
further exploration; it is the purpose of the PB document, as a WG
document, to bring the answer whether other standard solutions need to
be developped by Monam6 WG.

So, unless we still disagree on the purpose of the BOF as it is
expressed in http://www.nautilus6.org/ietf, the request to speak about
the interaction between Shim6 and MIP6 can only be proceeded if you
clarify what are the objective of the slot request with respect to the
BOF description.

Note: I'm not opposing anything, I want to ensure consistency of the
BOF slots.

Thierry

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 25 Jul 2005 13:11:25 +0200

Hi Thierry,

> clarify what are the objective of the slot request with respect to the

In a previous mail i described upon your request, some of the problems 
of those described in the problem statement are suscueptible to be 
solved by the SHIM approach. I did that because that what you asked as 
justification for presenting this draft in this bof. I copy this here, 
in case that you missed it.

> De: marcelo bagnulo braun <[email-masked]>
> Fecha: 21 de julio de 2005 11:22:52 GMT+02:00
> Para: Monami6 BOF proposal <[email-masked]>
> Cc: Monami6 BOF proposal <[email-masked]>
> Asunto: Re: [Monami6] Fwd: I-D ACTION:draft-bagnulo-shim6-mip-00.txt
> Responder a: Monami6 BOF proposal <[email-masked]>
>
> Hi Thierry,
>
...
> In particular, the running the shim and MIP is a mechanisms that can 
> be used to preserve the established communications through failures in 
> the HoA used in the communication (this means that it can be used to 
> provide the fault tolerance capabilities required described in 
> sections 5.2, 5.4, 5.7, 5.8 and 5.9 of 
> In addition, the mechanisms defined in the SHIM wg to deal with 
> ingress filtering could be applied to deal with the ingress filtering 
> issue described in section 6.1.2 of 
> draft-montavont-mobileip-multihoming-pb-statement, just as the 
> multiple CoAs drafts or the mmi and so on.
>

I didn't receive any reply to this email, so i would like to know if 
this is enough to justify the presentation of this draft as a 
prospective approach to solve the aforementioned problems?

I guess this could easily fit in the slot reversed for "Solutions that 
could be considered " where several other solution approaches are to be 
presented.

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Jul 2005 14:26:59 -0700

> this is a common understanding from our corresponding AD. 

I was referring to the text at http://www.ietf.org. Wouldn't it make 
sense to have that page updated with the latest information?

> Shim6 WG. 

Again you are operating in a black and white mode.
There was a question whether solving mobility issues was to be a 
requirement in the shim6 charter. The answer from the BoF/WG was "no".

But the fact that it isn't a requirement doesn't mean that it will not 
be dealt with; it just doesn't guarantee (from a charter perspective) 
that it will be done.

Many people active in shim6 are interested in finding the commonality 
between multihoming and mobility, even though it isn't required in the 
charter.

> If things have changed since April, then I'm sorry I didn't

I think that Monami6 should look at both multiple CoAs and multiple HoAs 
and understand the interrelationships between MIP/Nemo and shim6.

> between the people involved in the set up.

It's hard to be synchronized when the BoF description at www.ietf.org is 
not up to date. Makes me wonder why we have that BoF description.

> clarify what are the objective of the slot request with respect to the

Hmm - I thought the purpose of a BoF is to understand the scope and 
interrelationships with work going on elsewhere (other WGs, other SDOs) 
and given this the discussion of the interaction of shim6 and mip6 seems 
to fit the area that the BoF is trying to address.

    Erik

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 26 Jul 2005 11:27:27 +0900

> > Erik, I'm not sure which text you are refering to, the most up to
> > date in on http://www.nautilus6.org/ietf . Our objective is to set
> > up a new WG since the BOF has been announced. I cc Margaret just to
> > be sure that this is a common understanding from our corresponding
> > AD. 
> 

Sure, and I've sent the updated information to [email-masked]
yesterday, as this was the deadline for doing so. As you now, we cannot
update directly the information availabla on the ietf.org and we cannot
decently bother [email-masked] with any delta in the agenda/ BOF
description. So, I consider the page http://www.nautilus6.org/ietf as
the master page where the most complete, accurate and up-to-date
information is. Of course, people not on the mailing list may not find
this out very quickly, but I've kept monami6 ML members informed. If
this way is going against the recommended way, we can discuss on the
wgchairs ML.

> > What I meant to say is that the signal I received by the Shim6 WG
> > was clear about saying that the mobility issues wouldn't be dealt by
> > the Shim6 WG. 
> 

Very good. I may have understood things differently, but - from an
long-term Internet deployment point of view - I'm very much relieved you
say so.

However, this is not directly linked with the present discussion which
is about the relevance of draft-bagnulo-shim6-mip-00 with respect to the
objectives of the monami6 BOF.

> > see the changes in the objectives. If on the other hand the
> > objectives have not changed, I would like to understand the approach
> > you are considering. If the idea is to include the exploration of
> > the shim as a WG item into the prospective Monami6 WG, then I would
> > be willing to support this once the charter is properly worded in
> > such as way. To the condition it doesn't break the other objectives
> > of Monami6.
> 
> I think that Monami6 should look at both multiple CoAs and multiple
> HoAs and understand the interrelationships between MIP/Nemo and shim6.

I definetely agree on this and it is the intention behind the wording of
the proposed charter:

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

  "- Seek for help or push the other WGs to standardize solutions not
   specific to mobility,"

These two objectives are related to the issues detailed in
draft-montavont-mobileip-multihoming-pb-statement.

> > purpose of the BOF. As chair, I just need to make sure that we can
> > reach the objectives of the BOF as it is currently expressed and
> > agreed between the people involved in the set up.
> 
> It's hard to be synchronized when the BoF description at www.ietf.org
> is not up to date. Makes me wonder why we have that BoF description.

So my earlier comment on this.

> > expressed in http://www.nautilus6.org/ietf, the request to speak
> > about the interaction between Shim6 and MIP6 can only be proceeded
> > if you clarify what are the objective of the slot request with
> > respect to the BOF description.
> 
> interrelationships with work going on elsewhere (other WGs, other
> SDOs) and given this the discussion of the interaction of shim6 and
> mip6 seems to fit the area that the BoF is trying to address.

As I wrote, I'm not opposed to discuss such topic in monami6, but we
still have to figure out how it best match the purpose of the BOF. I
think it's now a general assumption amongt the people involved in the
BOF set up that discussing interaction between MIP6 nd SHIM6 comes a bit
earlier as we must first focus on the WG set up, and then on the actual
work. 

If I'm wrong, I will let Nicolas, ChanWah and Ryuji answer this.

Thierry

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Jul 2005 19:58:18 -0700

> earlier as we must first focus on the WG set up, and then on the actual

I'm a bit lost here. What do you mean by "comes a bit earlier" - I don't 
think you mean the BoF should be postponed until we can have the 
discussion about the interaction between mip6 and shim6.

And how can you focus on the WG setup when part of a BoF as I understand 
it is to determine whether there is a need and interest to have a WG; 
ignoring discussions of what is and isn't done in other WGs as it 
relates to the topic of the BoF sure doesn't give me confidence in that 
a WG would be needed.

So please help clarify what you meant by the above.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Jul 2005 19:58:18 -0700

Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 26 Jul 2005 10:32:32 +0200

Hi Thierry,

> earlier as we must first focus on the WG set up, and then on the actual

Could you point me out messages from other people questioning the 
presentation of this draft in the monami bof?

> If I'm wrong, I will let Nicolas, ChanWah and Ryuji answer this.

Well, i forward here a message from Nicolas, supporting the 
presentation of this draft and another message from Chan-Wah supporting 
the discussion of the relations between Monami6 and other WGs (MIP6, 
NEMO, Shim6)

Inicio mensaje reenviado:

> De: Nicolas Montavont <[email-masked]>
> Fecha: 14 de julio de 2005 16:34:41 GMT+02:00
>>> The success of our meeting also rely on our ability to identify 
>>> these relations.
>>>
....

Inicio mensaje reenviado:

> De: Chan-Wah Ng <[email-masked]>
> Fecha: 21 de julio de 2005 05:42:41 GMT+02:00
> Asunto: Re: [Monami6] updated goal / agenda
> On Thu, 2005-07-21 at 06:30 +0900, Thierry Ernst wrote:
>> On Tue, 19 Jul 2005 09:33:42 -0400
>> Nicolas Montavont <[email-masked]> wrote:
>>
>>>> In any case, any discussion on the mailing list is good as long as 
>>>> it
>>>> is relevant. So discussion MCOA (draft-wakikawa) and MMI
>>>> (draft-montavont) are good topics on which I would appreciate more
>>>> input by all people who have already registered the Monami6 ML (91
>>>> people as of today)
>>>>
>>>>
>>> I would add that discussion on draft-ernst-goals-and-benefits and
>>> draft-montavont-mobileip-pb-statement would be good as well.
>>
>> Sure, and this is already listed on the proposed agenda.
>>
>> Regarding the other points, based on this thread, I prospose to change
>> the "solution" items, and add one more about "interaction with the
>> other WGs" in our draft agenda:
>>
>>
>> OLD:
>> o Solutions that should be standardized
>>    draft-wakikawa-mobileip-multiplecoa
>>    Multiple Care-of Address Registration
>>
>> o Other solutions that should be considered
>>
>> NEW
>> o Solutions that could be considered and possibly combined
>>    into 1 or several standards:
>>   1. draft-wakikawa-mobileip-multiplecoa
>>      Multiple Care-of Address Registration
>>   2. draft-montavont-mip6-mmi
>>      Mobile IPv6 for Multiple Interfaces (MMI)
>>   3. draft-nomadv6-mobileip-filters
>>      Filters for Mobile IPv6 Bindings (NOMADv6) [version -02 Expired]
>>   4. draft-montavont-mobileip-ha-filtering
>>      Home Agent Filtering for Mobile IPv6
>>
>
> I would prefer to specify to which problem these solution(s) solve, as 
> a
> draft example just to illustrate what I mean,
>
> <example>
> o Solutions that could be considered and possibly combined
>    into 1 or several standards:
>   1. draft-wakikawa-mobileip-multiplecoa
>      Providing mechanism for multiple CoA registrations at HA/CN
> </example>
>
> Or even better,
>
> <example>
> o Solutions that could be considered and possibly combined
>    into 1 or several standards:
>   1. Mechanism for multiple CoA registrations at HA/CN
>      (draft-wakikawa-mobileip-multiplecoa)
> </example>
>
>> o Discuss relations between Monami6 and other WGs (MIP6, NEMO, Shim6)
>
>>
>> But since ChanWah and Nicolas don't seem to agree on the need for 
>> this,
>> I think we need to discuss this further.
>>
>
> Hmm ... I thought both Nicolas and myself agree to have this item, but
> Thierry disagrees.
>
> However, I understand your arguments in your mail of another thread, 
> and
> I am not at all strong about this.  I mean, as of today, we have a 2.5
> hrs time slot.  If the agenda is not fully packed, it is, IMHO, a
> worthwhile discussion item.
>
> /rgds
> /cwng
>

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 26 Jul 2005 17:39:18 +0900

marcelo bagnulo braun <[email-masked]> wrote:
> > think it's now a general assumption amongt the people involved in
> > the BOF set up that discussing interaction between MIP6 nd SHIM6
> > comes a bit
> > earlier as we must first focus on the WG set up, and then on the
> > actual work.
> 

Hi Marcelo,

Their position on this issue may have changed, but as I wrote, I will
let them express their own opinions. 

I would like this discussion to match to the BOF description and
proposed WG charter which represent the current consensus rather than on
past intentions and discussions.

Thanks,
Thierry

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 26 Jul 2005 18:01:56 +0900

> > comes a bit earlier as we must first focus on the WG set up, and
> > then on the actual work. 
> 
> I'm a bit lost here. What do you mean by "comes a bit earlier" - I
> don't think you mean the BoF should be postponed until we can have the

Surely not.

> And how can you focus on the WG setup when part of a BoF as I
> understand it is to determine whether there is a need and interest to
> have a WG; ignoring discussions of what is and isn't done in other WGs
> as it relates to the topic of the BoF sure doesn't give me confidence
> in that a WG would be needed.
> 

Erik, could you first comment on the BOF description and the WG proposed
charter rather than on possibly outdated assumptions of the purpose of
the BOF ? Please find it on http://www.nautilus6.org/ietf.

Briefly, the idea is that the are existing RFCs (Mobile IPv6 and NEMO
Basic Support) and there is some interest to deploy them in the very
short term with basic and straight forward features that can be ranged
in a "multihoming" category.

There is a need to register multiple CoAs, which is not allowed by the
current specifications.  The"multiple CoAs registration" issue and the
candidate solution are well understood by the IETF communities. We want
to extend MIP6 and NEMO BS with this capabilities.

At the same time, we want to conduct an overall analysis of the behavior
of MIP6 and NEMO BS under multihoming configurations. We intend to solve
some of the issues, not the others. The issues we want to solve would
be the very straight forward extensions to MIP6 and NEMO. For the other
issues, we just want to explain them correctly and to identify possible
solutions or WGs. This is where the interaction between Shim6 and MIP6
is very much concerned. 

Since next meeting is a BOF to set up a WG, it is not, IMHO, appropriate
to discuss the interactions between MIP6 and other WGs; what is
appropriate is to discuss the proposed charter.

Thierry

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 26 Jul 2005 11:27:01 +0200

El 26/07/2005, a las 11:01, Thierry Ernst escribió:
...

>  The issues we want to solve would

Well, my understanding was that the proposed work was to solve the host 
multihoming problem, in particular the issues described in 
draft-montavont-mobileip-multihoming-pb-statement.
In order to address the issues presented in this draft, much more than 
registering multiple CoAs is needed, i am afraid.
In particular, supporting multiple HoAs will require considerable 
modifications in the CN AFAICT. Now, the shim seems to provide some of 
the required features for supporting multiple HoAs, and its deployment 
will also imply modifying the CNs. So, i guess that only becuase of 
deployment configurations, it makes much sense to try to explore 
whether the shim is useful, just in order to avoid two modifications of 
all the installed base.

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Wed, 27 Jul 2005 08:16:22 +0200

Hi Marcelo and all,

IMHO; We should discuss the shim6 work that is related to MONAMI6. 

BUT, 

We still don't know whether ADs & others aggree with our PB-drafts. Do
we? Or else what is their opinion on having MONAMI6 WG or work with
MIP6/NEMO WG?

After seeing the outcome of this BOF, we should discuss identified
shim6 drafts in details. We too have lot to discuss (see the proposed
agenda) to finalise the way we should work.

We have been discussing multi-homing issues within mip6, mip4 & nemo for
the last two years, without seeing any outcome, but with lots of
discussions. I am looking forward to hear in Paris, at least, "the
decision" to work on these issues within IETF. 

I aggreed with the proposed agenda, we should allocate more time to
discuss our charter and PB drafts. 

regards

Koojana

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of marcelo 
>bagnulo braun
>Sent: Tuesday, July 26, 2005 10:33 AM
>To: Monami6 BOF proposal
>Cc: Margaret Wasserman
>Subject: Re: [Monami6] Fwd: I-D ACTION:draft-bagnulo-shim6-mip-00.txt
>
>
>Hi Thierry,
>
>
>> BOF set up that discussing interaction between MIP6 nd SHIM6 comes a 
>> bit earlier as we must first focus on the WG set up, and then on the 
>> actual work.
>
>>> Regarding the other points, based on this thread, I prospose to 
>>> change the "solution" items, and add one more about 
>"interaction with 
>>> the other WGs" in our draft agenda:
>>>
>>>
>>> OLD:
>> [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>>
>
>
>[email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Wed, 27 Jul 2005 08:16:22 +0200

Hi Marcelo and all,

BUT, 

regards

Koojana

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 27 Jul 2005 09:39:10 +0200

Hi Koojana,

> discuss our charter and PB drafts.

But according to this logic, during the BOF we should ONLY discuss 
about the problem statement draft, right?

I don't think this is a good approach. Exploring the solution space is 
an important item in the bof since this exploration allows to 
understand the difficulty of the problem and also allows to estimate if 
we are going to be able to provide some form of solution...

I mean, in the included agenda there is a section where solutions will 
be presented:

Solutions that could be considered and possibly combined into 1 or 
several standards:
Mechanism for multiple CoA registrations at HA/CN
draft-wakikawa-mobileip-multiplecoa-04.txt
Ryuji Wakikawa
Mobile IPv6 for Multiple Interfaces (MMI)
draft-montavont-mip6-mmi-02.txt
Nicolas Montavont
Home Agent Filtering for Mobile IPv6
draft-montavont-mobileip-ha-filtering-v6-00.txt [HTML]
Nicolas Montavont
Filters for Mobile IPv6 Bindings (NOMADv6)
draft-nomadv6-mobileip-filters-02.txt
Koojana Kuladinithi

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

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 27 Jul 2005 09:39:10 +0200

Hi Koojana,

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 27 Jul 2005 16:59:04 +0900

On Wed, 27 Jul 2005 09:39:10 +0200

> about the problem statement draft, right?

I think the motivations, pb statement, and charter outline would already
take most of our time. Discussing the solutions might be optional,
indeed. More below.

> understand the difficulty of the problem and also allows to estimate
> if we are going to be able to provide some form of solution...

Sure. But on the agenda we have listed concrete and long standing
solutions.  More below.

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

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. 

(as I wrote several times, the door is not closed, but we should first
reach a consensus that speaking about the MIP-SHIM intereaction at the
BOF would be using our time efficiently and with consistency with the
objectives of the BOF).

Thierry

Thierry

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 27 Jul 2005 11:13:10 +0200

> Sure. But on the agenda we have listed concrete and long standing

Using the SHIM to support multiple hoas seems a very concrete solution 
to me.
and i am not sure what do you mean by long standing... in which way the 
other solutions being presented are long standing?

> 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

> If you could explain on the ML what Shim6 can bring by early 2006, this

But the point is that supporting multiple HoAs will imply modifications 
in the CN (i.e. all the hosts in the internet)

So, any solution for this problem will take some time to deploy.

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

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)

Regards, marcelo

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 27 Jul 2005 18:49:30 +0900

Hi Marcelo and Thierry

If there are required modification or extension to MIP/NEMO in order  
to support SHIM6,
we should address these issues in MONAMI BOF.

ryuji

On 2005/07/27, at 18:13, marcelo bagnulo braun wrote:

> Using the SHIM to support multiple hoas seems a very concrete  
> solution to me.
> and i am not sure what do you mean by long standing... in which way  
> the other solutions being presented are long standing?
>
>
> not sure what would be the difference, but in the draft presented  
> you can find a proposal to support multiple HoAs in MIP
>
>
> But the point is that supporting multiple HoAs will imply  
> modifications in the CN (i.e. all the hosts in the internet)
>
> 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
>
> track to deploy modifications that involve CNs, since it would be  
> more reasons to deploy it than (i.e. site multihoming)
>
> Regards, marcelo
>
>
>
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 27 Jul 2005 18:49:30 +0900

Hi Marcelo and Thierry

ryuji

---

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

> Using the SHIM to support multiple hoas seems a very concrete solution

It's an approach, not a solution. You draft draft-bagnulo-shim6-mip-00
says:

   SHIM [1] is a host-based mechanism to provide site-multihoming
   support. 

   which refer to:

   [1]  Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach",
        draft-ietf-shim6-l3shim-00 (work in progress), October 2004.

  where it is written:

   This document specifies a particular approach to IPv6 multihoming.
   The approach is based on using a multihoming shim placed between the
   IP endpoint sublayer and the IP routing sublayer, and, at least
   initially, using routable IP locators as the identifiers visible
   above the shim layer.  The approach does not introduce a "stack name"
   type of identifier, instead it ensures that all upper layer protocols
   can operate unmodified in a multihomed setting while still seeing a
   stable IPv6 address.

   This document does not specify the mechanism for authenticating and
   authorizing the "rehoming" - this is specified in the HBA document.

   Nor does it specify the messages used to establish multihoming state.

   The document does not even specify the packet format used for the
   data packets.  Instead it discusses the issue of receive side
   demultiplexing and the different tradeoffs.  The resolution of this
   issue will affect the packet format for the data packets.

So, is this an approach, or a solution ? I think it's one step before
the proper solution. Anyway, you didn't reply my question regarding the
time line.

> 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 mean, in the included agenda there is a section where solutions
> >will> be presented:

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

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

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

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

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

Thierry

---

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

Hi Marcelo,

I did miss that mail you sent on 21, as you pointed to me on 25 - sorry
about this. Please read my answer below:

On Thu, 21 Jul 2005 11:22:52 +0200
marcelo bagnulo braun <[email-masked]> wrote:

> > discussed at Paris meeting, please explain how you think this would
> > fit with the objectives of the BOF, and particularly, which of the
> > issues raised in draft-montavont-mobileip-multihoming-pb-statement
> > this is related to. Otherwise, I cannot support the request.
> 

First, I would like to clarify one thing: the draft is trying to be
exhaustive about the issues; it doesn't mean we intend to solve all the
issues.

> draft-montavont-mobileip-multihoming-pb-statement

OK, this is one of the generic issues, on we don't intend to solve this
has claimed by the proposed charter:

 specific to mobility,

unless no WG is taking it.

> paths in order to rehome to alternative paths after an outage.

Agree with you. The text should express this issue explictly, and I
guess the issue would belong to the "generic" category, so not one of
the issue Monami6 would have to solve directly.

> seems to be a reasonable candidate for providing a solution

Agree that Shim6 is a valid solution to these issues, but again, it's
not the purpose of Monami6 to solve them; however our mission would be
to examine the interactions with other WGs, i.e. with Shim6 in the
present case.

> multiple CoAs drafts or the mmi and so on.

The difference is that MCoA is an issue MIP-explicit issue, so we want
to solve it whereas I guess the other your mention would be solved in
the Shim6 WG, right ? So, Monami6, as a WG, would have to interact with
Shim6 to ensure compatibility with MIP and NEMO.

> Is this a good enough justification for you?

It's a good justification for us to keep a close eye on Shim6 work, but
not appropriate, I think, to discuss the Shim6 approach at the next BOF.

Can we please speak about the Monami6 charter instead ?

Thierry

---

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

> tested in real-life trials. I think Shim6 is still a little bit behind

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

> 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

> operating NEMO Basic Support and their variant (FMIPv6, HMIPv6, etc),

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

> 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

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

---

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

Hi Ryuji,

I guess that the whole point of a bof is to explore a problem and find 
out if there some work that can be done to provide a solution (and of 
course if there interest in doing it)

Exploring the shim as a potential solution and how would this affect 
the interaction with mip seemed a reasonable thing to analyze (to me)

i cannot say if this would affect mip, since we are exploring the 
problem space. The idea of the presentation was to discuss this, i 
guess.

Regards, marcelo

El 27/07/2005, a las 11:49, Ryuji Wakikawa escribió:

>>>> will
>>> this

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 28 Jul 2005 12:08:23 +0900

I renamed this thread from 
[Fwd: I-D ACTION:draft-bagnulo-shim6-mip-00.txt]

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

These solutions have been introduced to the IETF for the 1st time years
ago. Multi6 didn't even existed, unless I'm mistaken.

I will not speak about HA filtering and the Nomad solutions because I'm
not involved, so other folks will give details if you want, but
regarding Multiple CoA registration, the draft is implemented under
Shisa, and undergoing under Linux, and has been tested and demonstrated
during the ITS World Congress at Nagoya last year (on a MR with
multiple interfaces)

> 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. 
 
> >>>> 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....
> >>>
> >you> can find a proposal to support multiple HoAs in MIP
> >
> > support of multiple HoAs is not a MIP-specific issue (please refer
> > to draft-montavont-mobileip-multihoming-pb-statement).
> 
> 

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.

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.

So, if there is a mobility specific issues that we have failed to
discuss in the draft, then yes, we would like to discuss this point in
order to improve the draft.

I'm not sure my explanation is satisfactory, but I guess you get
my point.

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

See my earlier comment.

> > 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.
> >
> >>> MIP6 and NEMO BS are standards, combining some of the features
> >like>> MCoA
> >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
> >more> reasons to deploy it than (i.e. site multihoming)
> >

So what ? It is discussed as a configuration, not as an  issue that the
WG will have to deal with. 

> Also in the problem statement draft the case of multiple HoAs is 

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 

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.

> and it is explained in the problem statement draft... are you
> proposing to make a whole WG to define how to register multiple CoAs?
> 
> 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).

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

Yes, it seems we don't. 
 
> 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. 

Thierry

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Thu, 28 Jul 2005 07:19:26 +0200

>> (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?
>
>These solutions have been introduced to the IETF for the 1st 
>time years ago. Multi6 didn't even existed, unless I'm mistaken.
>
>I will not speak about HA filtering and the Nomad solutions 
>because I'm not involved, so other folks will give details if 
>you want, but regarding Multiple CoA registration, the draft 
>is implemented under Shisa, and undergoing under Linux, and 
>has been tested and demonstrated during the ITS World Congress 
>at Nagoya last year (on a MR with multiple interfaces)
>
Regarding nomad stuff, our implementation is on linux and we have done
few trials for user accepatance (not with ISPs) and for technical
evaluation (in Finland & Germany). You will find more details under
related work (nomad project) at monami6 page.

Considering the amount of work that was already there related to
Multiple CoAs registrations (by different people), it's better to
discuss how to make a common work. And also, that's the immediate thing
that relates to mobility (I mean mip & nemo)as far as I can understand.

Koojana

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Thu, 28 Jul 2005 07:19:26 +0200

Koojana

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Jul 2005 01:58:46 -0700

> this is a common understanding from our corresponding AD. 

I was referring to the text at http://www.ietf.org
But I've since read the above web page in detail.

But I think the above is beside the point of the goals of the BoF and 
whether there is a WG with a reasonable charter lurking in the monami6 
space.

> between the people involved in the set up.

Your web page lists are goals for the BoF several items. Among them
> # to discuss which issues should be addressed by a Monami6 WG, which ones should be addressed by other WGs, and which ones should possibly be investigated in a IRTF WG.
> # to discuss the scope of the prospective WG.

To me this seems like you'd want the BoF to look at all the issues that 
are at the intersection point of mobility and multihoming. Discussing if 
which of the issues should be addresses where would seem to require at 
least having a list of all the issues.

And it was this text that led me and Marcelo to offer the draft as input 
to discussion in the BoF.

So I don't understand why the draft is not germane to the goals of the 
BoF? Have the organizers of the BoF already decided that the BoF/WG 
could only look at the multiple CoA case (and not worry about multiple 
HoAs for instance)

BoFs that work well IMHO try to understand the domain into which the 
proposed work will fit, so it would seem to be that a discussion around 
draft-bagnulo-shim6-mip-00.txt would be helpful to the BoF finding the 
proper scope (whatever that might turn out to be).

> clarify what are the objective of the slot request with respect to the

See above.

> Note: I'm not opposing anything, I want to ensure consistency of the

You mean I should interpret your "NO" as a "YES"? :-)

    Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 28 Jul 2005 22:16:27 +0200

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

> which is a multihoming configuration which is bring some issues, but 

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

> configuration under the "Path Selection" issue, which is not ranged

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Jul 2005 22:48:22 -0700

marcelo bagnulo braun wrote:

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

Marcelo, the multiple CoA spec has existed for a long time. shim6
is very new compared to that.

Vijay

---

From: Masafumi Watari <[email-masked]>
Date: Fri, 29 Jul 2005 11:41:49 +0900

Hi Marcelo,

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

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

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

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

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 29 Jul 2005 21:28:13 +0200

Hi Watari,

El 29/07/2005, a las 4:41, Masafumi Watari escribió:

> defined?

I think so

>   Or is shim6 also target to provide such mechanism?
>

well, you could use the SHIM to register multiple CoAs, indeed. This 
was one of the questions that araise, whether we should expose the CoAs 
to the shim or not. I guess that we should understand the pros and cons 
of each approach.

Regards, marcelo

[email-masked]