Subject: RE: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Oct 2003 16:52:00 +0100

Hi Paul:

I read your draft with great interest, and it seems fair to discuss RO
now that basic nemo has progressed a lot. I found the solution
attractive and very clever. It has a close alternate with MR doing
transparent bridging, where you'd use flooding down the nested tree
(used as a spanning tree) to locate a CareOF and set the states. 

For both approaches, I wonder how the mobility of a subtree works,
because it's all states in the intermediate routers that need to be
maintained. This is BTW the reason why we emulated source route bridging
(with RRH) as opposed to transparent, though transparent looked more
attractive for other reasons, including the HA side.

What do you think?

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: jeudi 2 octobre 2003 16:50
> Cc: [email-masked]
> Subject: [nemo] I-D ACTION:draft-jeong-nemo-ro-ndproxy-01.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
> 	Title		: ND-Proxy based Route Optimization for Mobile
Nodes in
>                           Mobile Network
> 	Author(s)	: J. Jeong et al.
> 	Filename	: draft-jeong-nemo-ro-ndproxy-01.txt
> 	Pages		: 13
> 	Date		: 2003-10-2
> 
> This document specifies a mechanism for enabling mobile nodes in IPv6
> mobile network to perform route optimization.  The route optimization
> is possible because mobile router relays the prefix of its Care-of
> address to its mobile nodes by playing the role of ND-proxy.
> Through binding updates associated with the network prefix of an
> access network, the mobile nodes can perform route optimization.  In
> addition, this document explains how mobile nodes can optimize its
> DNS name resolution through RA-based DNS discovery.  By announcing
> the address of local recursive DNS server, mobile router allows
> mobile nodes to optimize their DNS name resolution.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jeong-nemo-ro-ndproxy-01.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
> 
> 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-jeong-nemo-ro-ndproxy-01.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-jeong-nemo-ro-ndproxy-01.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.

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 03 Oct 2003 09:57:53 +0200

> (used as a spanning tree) to locate a CareOF and set the states. 

I think this approach is attractive in the sense that it doesn't require 
any trust reationship between the MR and the MNNs. And trust is probably 
a huge problem for other solutions of RO in NEMO.

On the other hand, every MNN have to signal their mobility 
independently, which may cause a BU storm when the network moves. Also, 
it would be interesting to know something about how quickly movement on 
the egress side of the root MR will be propagated down to all sub-NEMOs 
and their MNNs. MNNs will suffer from lost packets until the RAs have 
been propagated down, created CoAs and sent BUs. RA mechanism is 
unfortunately unreliable, so it is difficult to verify that all MNNs 
have learnt that the network has moved.

Conclusion: the approach is very useful if the network moves 
occasionally, but not to recommend if it moves often.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 03 Oct 2003 09:57:53 +0200

/Mattias

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 4 Oct 2003 12:27:40 +0900

Hi Pascal,

----- Original Message ----- 
From: "Pascal Thubert (pthubert)" <[email-masked]>
>attractive for other reasons, including the HA side.

I agree with you that the consideration of subtree's mobility is important.
It seems to be related to the smooth handover in MIPv6 and neighbor cache management in ND.
In my current draft, I think, many packet losses can happen when MN moves fast
within other links of a mobile network or other mobile networks.
I'm considering this problem and how to sort out it in next version. :-)
I'll appreciate your comments.
Thanks.

/Paul

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 4 Oct 2003 12:27:40 +0900

Hi Pascal,

----- Original Message ----- 

/Paul

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 4 Oct 2003 12:37:35 +0900

Hi Mattias,

----- Original Message ----- 
From: "Mattias Pettersson" <[email-masked]>
> independently, which may cause a BU storm when the network moves. Also, 

Every mobile node need not perform a BU for RO and 
only mobile node where RO is important does so.

> have learnt that the network has moved.

I completely agree with you in deep mobile network.
Actually, my target application is to support RO for shallow mobile network, 
such as car and bus.
Thanks.

/Paul

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 4 Oct 2003 12:37:35 +0900

Hi Mattias,

----- Original Message ----- 

/Paul