Subject: [nemo] Fw: I-D ACTION:draft-watari-nemo-nested-cn-00.txt

From: Masafumi Watari <[email-masked]>
Date: Fri, 15 Oct 2004 23:40:51 +0900 (JST)

Hello,

I've submitted a draft based on the presentation I made during the SD
meeting.  Please find the document in the URL below.

http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-00.txt

I hope that the draft helps the problem statement of Neste NEMO, and
that the solution for RO considers the differenent cases metioned in
the draft.

Thanks,

Masafumi Watari

Subject: I-D ACTION:draft-watari-nemo-nested-cn-00.txt
From: [email-masked]
To: [email-masked]
Date: Thu, 14 Oct 2004 16:19:27 -0400
List-Id: i-d-announce.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Route Optimization with Nested Correspondent Nodes
	Author(s)	: M. Watari, T. Ernst
	Filename	: draft-watari-nemo-nested-cn-00.txt
	Pages		: 18
	Date		: 2004-10-14
	
This document aims at assisting the problem statement of route
   optimization in nested mobile networks.  We describe the paths
   packets would take using existing Mobile IPv6 and NEMO Basic Support
   mechanisms when one or both end nodes of a communication flow are
   located in a nested NEMO.  One of both of the end nodes may
   themselves be either mobile nodes performing Mobile IPv6, or standard
   IPv6 nodes performing no mobility function at all.  The path can
   become extremely suboptimal if no optimization is provided.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-watari-nemo-nested-cn-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-watari-nemo-nested-cn-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-watari-nemo-nested-cn-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.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 19 Oct 2004 11:24:06 +0200

Dear Masafumi,

	I think that the draft is useful and helps in the description of the
problem statement in nested NEMOs, so thanks for providing it.

	I have a couple of comments. First, in the case A (LFN and standard
IPv6 CN), you say that

 "To avoid tunneling through any HA, Correspondent Routes (CRs) may be
  placed near CNs to handle bindings.  CRs are routers enhanced which
  the ability to handle bindings for a mobile network, allowing a
  direct tunnel to the MR providing a certain level of optimization."

IMHO, CRs are not the only solution that may be used to provide a
certain level of optimisation. There are other solutions, like using
some kind of ad-hoc routing within the nesting, RRH, etc, that can
reduce the number of tunnels to only one. I'd suggest to maintain the
sentence "Route optimization would require collaboration among the MRs"
and maybe rewrite the other part to just provide examples, like the one
of CRs and maybe others. 

	In the case I (VMN and standard IPv6 CN), maybe it's worth IMHO to
point that the VMN could also use its CoA (looking at RFC3775, I think
that it is an implementation dependant behaviour) to some
communications. For example, if a VMN attaches to a NEMO, for
short-lived communications (e.g. DNS requests), it may prefer to use its
CoA as source address. Therefore, IMHO, I think it would be useful to
add some text pointing that also.

	What do you think?

	Kind Regards,

	Carlos J.

El vie, 15-10-2004 a las 16:40, Masafumi Watari escribió:
> ______________________________________________________________________
> ______________________________________________________________________
> Content-Type: text/plain
> Content-ID: <[email-masked]>
> 
> 
> ______________________________________________________________________
-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: Christophe Janneteau <[email-masked]>
Date: Tue, 19 Oct 2004 14:52:05 +0200

Hi Masafumi, Carlos,

Masafumi, thanks for the draft. I think it helps in explaining the 
overhead of the NEMO basic support protocol with nested moving networks. 
  Especially, I liked that the many different scenarios (location/type 
of CN and MNN) have been considered.

Few comments below, somehow inline with Carlos' ones:

> and maybe rewrite the other part to just provide examples, like the one

I agree that CR is not the only solutions, and I also understand that it 
is not the objective of the draft to list solutions nor discuss them in 
details.  So, IMHO, I would suggest to remove from the draft any 
references to solutions (such as CR, or others).

This would provide a draft focusing _only_ on the issues with the 
current protocols (highlighting the need for RO) but free of any 
solution. Only then, IMHO, the draft could provide the needed 
necessary-unbiased foundations for the problem statement discussion in 
the WG.

So I would propose to remove the two following paragraphs:

o in 2.1:
    "Route optimization would require collaboration among the MRs.  To
    avoid tunneling through any HA, Correspondent Routes (CRs) may be
    placed near CNs to handle bindings.  CRs are routers enhanced which
    the ability to handle bindings for a mobile network, allowing a
    direct tunnel to the MR providing a certain level of optimization."

o in 3:
    "The models generally assumed for route optimization are optimization
    among all MRs in both NEMOs, and a bi-directional tunnel between the
    two root-MRs."

Another comment on section 5.3:
   - What is the HA4 mentioned in the text? It does not appear in Fig 
13, nor in fig 16.
   - Fig.16: the path down to CN seems to be missing in the figure. 
Should it not be like:

VMN - MR3 - MR2 - MR1 - MR1_HA - MR2_HA - MR3_HA - VMN_HA - MR3_HA - 
MR2_HA - MR1_HA - MR1 - MR2 - MR3 - CN

Thanks,
Christophe.

---

From: Masafumi Watari <[email-masked]>
Date: Thu, 21 Oct 2004 00:13:48 +0900 (JST)

Hello Carlos,

Thank you for your comments.

Yes, I agree CR is not the only solution and that the text is somewhat
off the focus of the draft.  I will remove that.  Actually, I was
writing a solution draft, but then I changed my mind and forgot to
remove it...

I will also add some text about the use of CoA for VMNs.

Thank you!

Masafumi Watari

On Tue, 19 Oct 2004 11:24:06 +0200,

---

From: Masafumi Watari <[email-masked]>
Date: Thu, 21 Oct 2004 00:40:38 +0900 (JST)

Hi Christophe,

Thank you for your comments.
Please see my reply inline;

On Tue, 19 Oct 2004 14:52:05 +0200,

>     among all MRs in both NEMOs, and a bi-directional tunnel between the

I guess my intension was to kind of summerize some general solutions
often seen in proposals, but I as mentioned in my previous mail, I
will remove these.

>    - What is the HA4 mentioned in the text? It does not appear in Fig 

It should be VMN_HA.  I will fix that.

> MR2_HA - MR1_HA - MR1 - MR2 - MR3 - CN

Yes, correct...
I will fix this as well.

Thanks again,

Masafumi Watari