Re: [nemo] About Test Specification in IPv6 Ready Logo

RYUJI WAKIKAWA <ryuji.wakikawa@gmail.com> Mon, 04 December 2006 14:50 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrF9J-0000zi-H1; Mon, 04 Dec 2006 09:50:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrF9I-0000zV-5S for nemo@ietf.org; Mon, 04 Dec 2006 09:50:28 -0500
Received: from qb-out-0506.google.com ([72.14.204.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrF9G-0007o0-Tu for nemo@ietf.org; Mon, 04 Dec 2006 09:50:28 -0500
Received: by qb-out-0506.google.com with SMTP id q12so2158777qba for <nemo@ietf.org>; Mon, 04 Dec 2006 06:50:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=QKsK457hx+hAF24OYzAifn75esu2kVL1dunVo3Xga8HpCjp7eizpTu1YqDxTW2R5hoq6x9TMN4gGNi05J6xfr918KJsfwv0KuAtWaGFwDWAPa/olAcE36jZiwgktynSe2Pkp/asEsp8pP6qP7pWXrzkjmOnaqM+7IzQms9fl2pI=
Received: by 10.49.90.18 with SMTP id s18mr13180139nfl.1165243824699; Mon, 04 Dec 2006 06:50:24 -0800 (PST)
Received: from ?172.17.20.28? ( [193.136.189.5]) by mx.google.com with ESMTP id i1sm471079nfe.2006.12.04.06.50.22; Mon, 04 Dec 2006 06:50:23 -0800 (PST)
In-Reply-To: <456ADABD.4070805@motorola.com>
References: <4561A83F.20807@motorola.com> <200611211830.ICF21007.ULVJBHXB@ysknet.co.jp> <F6F35ADE-D2B1-4F55-A130-E51DE4F05B20@iijlab.net> <200611211941.EFI30733.UVJBBLXH@ysknet.co.jp> <C32C0627-0604-4B0B-BD18-B9DDAA4C46A2@iijlab.net> <200611241022.CBC95338.VLBUBJXH@ysknet.co.jp> <5F03AB19-AFFA-4A12-8514-3CD0F501B7B3@iijlab.net> <F5CDD93B-B15C-4C06-87ED-D1644F473916@iijlab.net> <456ADABD.4070805@motorola.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <34A985EA-CE75-4C77-A9A2-C385843EAD73@gmail.com>
Content-Transfer-Encoding: 7bit
From: RYUJI WAKIKAWA <ryuji.wakikawa@gmail.com>
Subject: Re: [nemo] About Test Specification in IPv6 Ready Logo
Date: Mon, 04 Dec 2006 23:50:02 +0900
To: Alexandru Petrescu <alexandru.petrescu@motorola.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: nemo@ietf.org
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Errors-To: nemo-bounces@ietf.org

Hi Alex,

On 2006/11/27, at 21:31, Alexandru Petrescu wrote:

> Keiichi SHIMA wrote:
>> On 2006/11/25, at 13:29, Keiichi SHIMA wrote:
>>>>> So, even in the case 2, we can put a routing entry for the  
>>>>> mobile network prefix by not using any routing protocol.
>>>> Please teach the method of not using routing protocol. Is there
>>>>  draft or RFC ?
>>> Since a mobile node knows its mobile network prefix, it can  
>>> install a routing entry for it after it receives a binding ack  
>>> message.  The home agent of the mobile node will know the mobile  
>>> network prefix stored in a binding update message from the mobile
>>>  node, it can also install a routing entry when it receives the  
>>> binding update message.
>> Some more minor additional notes...
>> The above example is for the explicit mode.  And if we use implicit
>>  mode, then these two entities already know what to do when  
>> registration completes.  So either using a dynamic routing or not  
>> is just a configuration issue for route management and it has  
>> nothing to do with the network model.
>
> I think it is not right for HA to add a routing table entry upon
> reception of MNP in the HA.  IT should add it in the binding cache,
> not in routing table.
>
> The routing table is a data structure touched by other independent
> software (ifconfig add, route add, routing daemon read).

This is totally implementation issue.
For example, on some of implementation, ND information is managed in  
a routing table.

> If MIP6-nemo software adds a routing table entry usually it has no way
> to trigger the routing daemon that reads that routing table.  The
> routing daemon reads the routing table only once (when it starts up),
> creating other internal routing tables.  If mip6-demo adds an entry in
> the kernel routing table then that will not be seen by the routing
> daemon.  Which is bad.

Hmm,,, this is your routing daemon IMPLEMENTATION issue.
There is a program to catch a trigger of routing changes after it  
starts up.

ryuji

> That's why I think the routing table entries between MR and HA must be
> there prior to starting up the mip6-nemo software.  This is normal in
> a way: if the MR is at home, we want the HA to still route packets
> towards LFN, although no BU is sent.
> Alex
>
>> # if I'm not missing something.
>> --- Keiichi SHIMA IIJ Research Laboratory <keiichi@iijlab.net> WIDE
>>  Project <shima@wide.ad.jp>
>
>