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

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 4 Dec 2006 23:50:02 +0900

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 <[email-masked]> WIDE
>>  Project <[email-masked]>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Dec 2006 16:39:55 +0100

RYUJI WAKIKAWA wrote:
>>>>> Please teach the method of not using routing protocol. Is
>>>>> there draft or RFC ?
>>>> 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.
>> 
> 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.

Right... but there's however no protocol interaction between instances
of NEMOv6 and say OSPF on same machine, other than these entries in the
routing table.  Who decides which routing entry is correct ospf or nemo.
  If both daemons add same entry, or worse, one adds an entry and the
other deletes the same entry - there may be some inconsistencies.

That's why I was suggesting keep these tables separated: binding cache
and routing table, so there's no risk of faulty configuration by
administrator.

Otherwise I agree with you that most of these are implementation issues,
and that my implementation may be different than in your case.

Alex

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 5 Dec 2006 00:50:21 +0900

Hi Alex

<SNIP>

> and routing table, so there's no risk of faulty configuration by

In our implementation, the nemo daemon manages MNP in own binding  
cache DB, too.
The nemo daemon only add/modify/delete the route entry of MNP in the  
routing table according to BC DB.
Some of routing daemons has same design.
A daemon has own routing table in the daemon  and apply only changes  
to the routing table in the kernel.
I will not describe each solutions, but there are several ways to  
distinguish routing entry
between NEMO or OSPF.

> and that my implementation may be different than in your case.

:-)

ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Dec 2006 17:01:54 +0100

RYUJI WAKIKAWA wrote:
> Hi Alex
> 
> <SNIP>
> 
>> Right... but there's however no protocol interaction between 
>> instances of NEMOv6 and say OSPF on same machine, other than these 
>> entries in the routing table.  Who decides which routing entry is 
>> correct ospf or nemo. If both daemons add same entry, or worse, one
>>  adds an entry and the other deletes the same entry - there may be 
>> some inconsistencies.
>> 
>> That's why I was suggesting keep these tables separated: binding 
>> cache and routing table, so there's no risk of faulty configuration
>>  by administrator.
> 
> cache DB, too. The nemo daemon only add/modify/delete the route entry
>  of MNP in the routing table according to BC DB. Some of routing 
> daemons has same design.

I agree some rt daemons have same design: keep separated table and
add/remove from kernel table.

However I don't agree nemo should add entries in the kernel table.  OSPF
is so made to work all in all hosts (one wouldn't deploy OSPF and BGP on
same machine, without "BGP OSPF Interaction" rfc1403).  NEMO came after
OSPF.  Some HA may run OSPF; adding NEMO on that HA has risks of routing
incoherencies, especially if that NEMO implementation adds entries in
the routing table.

Alex

> to the routing table in the kernel. I will not describe each
> solutions, but there are several ways to distinguish routing entry
> between NEMO or OSPF.
> 
>> Otherwise I agree with you that most of these are implementation 
>> issues, and that my implementation may be different than in your 
>> case.
> 
> :-)
> 
> ryuji
> 
>