Subject: RE: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 16 Mar 2003 00:22:45 -0000

Actually if you look at it, with this draft, there is no classical home
network at all. So there is no concept of interception, of DAD for the
home address etc... All you have is an aggregation that can be
advertized at all time by the Has. Looks cool, but:

- the binding cache acts as a second routing table, that actually has
precedence over the classical one. I did not expect you'd do that. I
thought that there'd be a route to the prefix via the home address, and
that the binding would impact the tunnel, not the route. If it's really
a routing table, then, IMHO, the way the binding routes are
redistributed should be considered in more details in the next version.

- additional work could be required to cover the case of multiple HAs.
In MIPv6, the detection of multiple registration id done by DAD on the
home network. Since there is no home network, the detection of double
registration has to be done at the routing protocol level (When the same
net is registered to a 2nd, different HA, it should reject it if it got
a route from the first HA... Something like that. Note that as we
discussed earlier, the fine grained info should be contained in the HAs.

- as you see from both point above, the problems we are facing in MIP
with the interaction of ND and MIP did not go away, they moved. 

Pascal

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: samedi 15 mars 2003 02:11
> To: Ryuji Wakikawa
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt
> 
> 
> Ryuji Wakikawa wrote:
> > 
> > Hello Alex.
> > 
> > > Maybe you have a more detailed view on how HA intercepts packets 
> > > destined to the registered mobile network prefix.  Is it 
> something 
> > > like HA snoops at those packets?  Or is it more like HA uses 
> > > unsolicited broadcasted NA to pretend having MNN's L3 address?
> > 
> > Since HA is an end-router for the prefix on the Internet (i.e. 
> > advertising mobile network prefix by routing protocol), HA will 
> > receive all packets destined to a mobile network prefix. During IP 
> > forwarding procedure, HA looks up binding cache and finds a prefix 
> > binding. Therefore, HA can tunnel all these packets to MR.
> 
> I dont agree with this. I think it is wrong to assume that 
> packets meant for the mobile network will always reach the 
> the HA which has the prefix scoped binding cache entry. you 
> could have a border router in the home link which could 
> receive the packets meant for the mobile network.
> 
> if you want the border router to forward the packets to the
> HA, it needs to know that the HA can reach the mobile router.
> 
> Vijay
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 17 Mar 2003 10:24:04 +0900

Hello Pascal.

Thanks for the mail. 
There was misunderstanding of "returning home link".

Pascal you are right, this id does not have actual home network.
Home link is not general home network, but the link which HA
is managing. 

> redistributed should be considered in more details in the next version.

I think I should clarify how the routes on HA are set up.

HA has a route and a binding like
Route
	destination -> next hop
	mobile network prefix -> gif0 

Binding
	home prefix -> CoA
	MR-A/64(mobile network prefix) -> MR-CoA

HA advertise route of mobile network to routers 
Thus, these routers will have the below route.
Route
	destination -> next hop
	mobile network prefix -> HA

Routers route packets meant for the mobile network to HA. Then,HA intercepts and
conceptually routes them to MR-CoA via the tunnel interface, because HA has the 
route of mobile network prefix and the next hope is the tunnel
interface. At protocol(implementation) point of view, HA searches binding cache
and tunnel packets to MR-CoA.

> discussed earlier, the fine grained info should be contained in the HAs.

MR can register MR-CoA several HAs simultaneously, because our id does not have
"general Home Link". 

Furthermore, the below configuration is possible.
HAs can be placed anywhere on the Internet. There is no restriction such
as home network. MR can have either single egress interface or multiple
egress interfaces. 

 HA1  -------------Internet-------------------HA2
 |                                             |
 +==================== MR =====================+
   tunnel 1             |         tunnel2
                   -------------
                     mobile network

If multiple HAs have binding of MR, each HA advertises the route of
mobile network prefix with different "routing metric". This achieves redundancy
of HA. If the primary HA goes down, all packets destined to mobile
network prefix is routed to another HA, because the mobile network
prefix route advertised by the primary HA is deleted.

MR can register different CoA to each HA. MR can utilize multiple egress 
interfaces simultaneously. This provides multiple network
interface support of MR (efficient bandwidth, low delay, etc).
The decision of interface selection depends on route of
mobile network prefix advertised by HAs.

Consistency of binding on multiple HAs may be possible issues.

Regards,
ryuji

> > > > destined> > destined to the registered mobile network prefix.  Is it 
> > something 

regards,
ryuji

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Mar 2003 20:51:35 -0800

> and tunnel packets to MR-CoA.

IMHO, it is a really inefficient way of routing packets. searching
the binding cache for a route to the mobile network is a lot slower
than having a routing entry in the HA's routing table. (route lookup
is faster).

> as home network. MR can have either single egress interface or multiple

this is good. but as Pascal said this is not unique to this draft. you
can always assign the home address to a virtual interface and use the
two egress interfaces simultaneously. some mipv6 MN implemenations also
do this. (I am sure you know about this)

>  +==================== MR =====================+

again, nothing prevents you from having this type of configuration
with draft-kniveton-mobrtr...

Vijay

---

From: Christophe Janneteau<[email-masked]>
Date: Wed, 19 Mar 2003 09:58:31 +0100

Hi Vijay,

> than having a routing entry in the HA's routing table. (route lookup

Your point on performance may be true, but I think this is not relevant
for the purpose of how the basic nemo specification should describe the
forwarding of packets on the HA! I would say, that this type of
performance (forwarding) is rather implementation dependent and, IMHO,
should not impact on the way the HA-forwarding is specified.

As explained in draft-petrescu-nemo-mrha-02.txt section 4.1, I tend to
think the opposite  and suggest that forwarding process on HA should
better be expressed in term of the BC (even with a prefix entry) rather
than a route entry on HA. I just copy here the relevant paragraph
(sorry):

>    4.1 Implementation-independent specification terms
>    
>    The specification of the basic network mobility support should be
>    expressed with implementation-independent terms. In other words,
>    clear distinction should be made between the specification of the
>    protocol and a description of a possible implementation of this
>    protocol. Especially, since it is to be based on Mobile IP(v6), the
>    basic NEMO support specification should not make any assumption on
>    how Mobile IP(v6) is implemented but instead re-use (and possibly
>    extend) data structures from the Mobile IP(v6) specification
>    (e.g. Binding Cache), and eventually introduce new ones if
>    needed. Below are two examples of how attention should be payed in
>    the specification of the protocol.
> 
>    The bi-directional approach requires MR's HA to configure a
>    "forwarding information" for the mobile network prefix towards the
>    mobile router.  Since the Mobile IP(v6) specification introduces a
>    dedicated structure, so-called Binding Cache, to store
>    mobility-related "forwading information" on the HA, the
>    specification of basic NEMO support should re-use/extend the
>    Binding Cache to include the new mobility-related "forwarding
>    information" for a mobile network.  Even though a Binding Cache may
>    be implemented as an extension of a routing table, the
>    specification should relate to the Binding Cache and not the
>    routing table.  For instance, the specification should relate to
>    the "forwading information" to be configured on MR's HA for the
>    mobile network prefix in terms of a prefix entry in the Binding
>    Cache instead of an entry in the routing table of MR's HA.
>    Especially, Mobile IP(v6) specification does not specify any
>    routing table for a HA.
> 
>    Similarly, the specification should not assume that a tunnel,
>    e.g. the MRHA bi-directionnal tunnel, is visible as a virtual
>    network interface on the MR or HA. This is an
>    implementation-related consideration that may not be true for all
>    IP(v6)/MobileIP(v6) stacks.
> 
>    Such considerations will allow to clearly draw the line between the
>    specification and a description of a possible implementation, and
>    as a result ease any future implementation of the basic NEMO
>    support as an extention of an existing Mobile IPv6 implementation.

The overall objective here is to ensure the WG will come up with a
specification of basic nemo support, and not a description of one
possible implementation. Would be interesting to get opinion from people
on the list on this (or have this discussed during the meeting today :).

Thanks,
Christophe.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 19 Mar 2003 01:55:29 -0800

>>> and tunnel packets to MR-CoA.

I'm not sure I get that -- if the binding is from MR-A/64 to MR-CoA, why
does it need to do a binding cache lookup? Is the binding really from
MR-A/64 to HAddr?

> should not impact on the way the HA-forwarding is specified.

you are right, the basic draft should not dictate how to implement things.
However, IETF philosophy also leaves room for implementation considerations
to have a bearing on how the protocol will be described, so that it can
actually be implemented in a fast way, on many modern OS's (especially by
the author(s)), right?

Ryuji was describing how his implementation works, so Vijay was commenting
on that -- not on the spec. If there is an inefficiency identified in
implementation, maybe it can lead to an improvement of the spec itself.

>>    the specification of the protocol.

I'm not sure I catch your drift -- we probably all agree that a base spec
should not dictate the implementation details. On the other hand, there is
precedent for describing how one *can* implement it, or giving hints,
including in Mobile IPv6, which you are citing and describing -- data
structures hint at an implementation, right? And they are designed in a
certain way, not arbitrarily, based on what will work well in practice.

Maybe someone can correct me if I'm out in left field, but I believe in the
IETF we are allowed to consider how something will be implemented before the
spec is finished. After all, it has to be implemented sooner or later, and
might as well be performant.

With that said, of course our good design principles are going to make us
try and keep the implementation details as open as possible.

> on the list on this (or have this discussed during the meeting today :).

Yes, we agree on this point -- the description must be abstracted away from
the implementation. But, I guess my point is, not too far!

TJ

---

From: Christophe Janneteau<[email-masked]>
Date: Wed, 19 Mar 2003 14:22:04 +0100

Hi T.J.,

> certain way, not arbitrarily, based on what will work well in practice.

I have nothing against a protocol specification which would _also_
provide hints on how defined data structures (e.g. Mobile IPv6 BC) may
be implemented (e.g. Mobile IPv6 BC implemented as host routes in a
routing table). On the other hand, I think the protocol description ,on
its own, should not base *too much* on implementation assumption.

For instance, HA-forwarding process in Mobile IPv6 protocol could have
been described in term of extensions to the HA's routing table (e.g.
host routes) but the need has been foreseen to introduce the Binding
Cache, which is the data structure used in the protocol specification.
There may be several reasons for this (I am not aware of all of them but
MIP pioneers may help here :), IMHO, one of them being to clearly
separate routing functions from mobility functions.

I think a similar separation should be preserved in NEMO, and thus
suggest to describe MR's HA behavior in term of the BC and not in term
of its routing table...(although a possible implementation may use the
routing table).

> might as well be performant.

I agree...

Christophe

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Mar 2003 09:06:04 -0800

Christophe Janneteau wrote:
> forwarding of packets on the HA! 

you totally missed my point. I was comparing using binding cache
for forwarding to a network prefix when you have something called
a routing table for forwarding to a network prefix. my opinion is
that it is very inefficient.

FWIW I dont believe in specifications which dont consider the
implementation aspects.

Vijay

---

From: Christophe Janneteau<[email-masked]>
Date: Wed, 19 Mar 2003 18:53:32 +0100

> that it is very inefficient.

I think I clearly understood what you wrote and reacted on that...
But if you say no then...

> FWIW I dont believe in specifications which dont consider the

...and I share this opinion as well! But also hope we can clearly
distinguish between a spec and the description of _a_ possible
implementation....

Please re-read my email or just forget about it :)

Christophe

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Mar 2003 10:44:57 -0800

> of its routing table...(although a possible implementation may use the

disagree. MIPv6 uses binding cache for /128 addresses. and that is
perfect. in NEMO basic support, you need to redirect traffic for
a /64 prefix, which is exactly the same as having a network route
with a next hop (or an outgoing interface).

Vijay

---

From: Christophe Janneteau<[email-masked]>
Date: Thu, 20 Mar 2003 11:48:37 +0100

Hi Vijay,

> with a next hop (or an outgoing interface).

We agree on the fact that NEMO's HA must redirect traffic for a prefix
(/64 or others). Now the question is how the specification should
describe this, and here it seems we disagree. I would prefer to have the
_specification_ (I am not talking about implementation here) describing
the forwarding for the prefix with the sole use of the Binding Cache
(i.e. prefix entry in the BC) since I can see the following problems if
we go for the approach you suggest, i.e. use a /64 nemo prefix in the
HA's routing table:

o Case 1: This routing table entry would looks like:

Prefix    NextHop    OutputIFC
nemo/64   MR_HoA     eth0 (inteface towards MR's home link)

Then the specification should describe a coordination between the
parsing of the routing table and the parsing of the BC (to recover
MR-CoA from nexthop=MR_HoA). This would mix routing and mobility
functions that I think make the protocol more complex. In addition, as
said by someone earlier on the mailing list, this would suggest a
departure from traditional parsing of the routing table since only
NextHop but not outputIFC should be considered in that case...

o Case 2: This routing table entry would looks like:

Prefix    NextHop    OutputIFC
nemo/64   ::         MR_HA_tunnel_ifc

No NextHop is specified but the output interface is directly said to be
the MR-HA tunnel. Here we would not need anymore parsing of the BC
(departure from Mobile IPv6) but would have to update the tunnel
endpoint in the routing table each time MR moves. The problem with this
approach is that it assumes a tunnel (e.g. MR-HA tunnel) is implemented
as a virtual network interface....which is not true for all (currently
used) IPv6 stack. This would make the spec too implementation specific
in my opinion, and make porting of some existing Mobile IPv6
implementations to NEMO quite difficult...

Again I have nothing against an implementation that would use approaches
1 or 2, but i think this should not be THE description of the protocol,
but only a possible implemtation (e.g. in annex of the nemo spec).

If you see good reasons to go for a description like 1 or 2 as the HA
behavior, please let me know...I may miss something :)

Thanks,
Christophe

---

From: Keisuke UEHARA <[email-masked]>
Date: Fri, 21 Mar 2003 01:21:51 +0900 (JST)

Hi TJ and all,

I'm a co-author of the draft (draft-wakikawa-nemo-basic-00.txt).

From: "T.J. Kniveton" <[email-masked]>
Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no homenetwork ?)
Date: Wed, 19 Mar 2003 01:55:29 -0800
> >> Ryuji Wakikawa wrote:
<SNIP>
> does it need to do a binding cache lookup? Is the binding really from

The binding is from MR-A/64 to MR-CoA.  The Ryuji's description is the
conceptual one.  You can implement this mechanism as followings:

    Case 1:
	When HA receives a BU (MR-A/64 -> MR-CoA) from MR, HA setups the
	tunnel and the route entry (MR-A/64 -> tunnel).
	Then, when HA receives a packet addressed to MR-A/64 (ex. MR-A),
	HA forwards it according to its routing table.

    Case 2:
	When HA recives a BU, HA creates BC.  Then, when HA receives a
	packet addressed to MR-A/64, HA encapsulates it and resend to
	MR-CoA.

Case 1 is more simple than Case 2.  Because BC (Routing Table) setup
and forwarding function are separated.
Case 2 can be implemented as an extension of Mobile IPv6.

It is possible to implement this mechanism with other way, of cause.
This is a really implementation issue, NOT a protocol issue.

Kei

---

From: Keisuke UEHARA <[email-masked]>
Date: Fri, 21 Mar 2003 01:26:16 +0900 (JST)

Hello,

From: Christophe Janneteau <[email-masked]>
Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt-> no homenetwork ?)
Date: Thu, 20 Mar 2003 11:48:37 +0100
> implementations to NEMO quite difficult...

Yes, this is exact that I want to say previous mail.

Regards,
Kei

---

From: Ryuji Wakikawa<[email-masked]>
Date: Fri, 21 Mar 2003 04:34:09 +0900

Hi Vijay

At Tue, 18 Mar 2003 20:51:35 -0800,
> than having a routing entry in the HA's routing table. (route lookup

Can you elaborate on the performance difference between binding cache
and routing table? Processing steps of searching are almost same. 

> do this. (I am sure you know about this)

OK. Actually my MN implmentation can handle this:-)

ryuji

---

From: Ryuji Wakikawa<[email-masked]>
Date: Fri, 21 Mar 2003 04:39:29 +0900

Hi Christophe.

At Wed, 19 Mar 2003 09:58:31 +0100,
> should not impact on the way the HA-forwarding is specified.

I totaly agree with you.

> on the list on this (or have this discussed during the meeting today :).

I think our id meets this texts.

regards,
ryuji

---

From: Ryuji Wakikawa<[email-masked]>
Date: Fri, 21 Mar 2003 04:56:36 +0900

Hi TJ.

At Wed, 19 Mar 2003 01:55:29 -0800,
T.J. Kniveton <[email-masked]> wrote:
<snip>
> implementation, maybe it can lead to an improvement of the spec itself.

We really don't know the performance difference between BC and routing
table. Do you have any reasons that routing table search is much
faster than searching BC?

> try and keep the implementation details as open as possible.

I think this section 4.1 does not point the implmenetation, but it
also recommend that the base spec should not rely on an exisiting
routing protocol.

I want to say that the base spec should not assume a routing protocols
at home link. Even if routes of a home network domain are configured
"manually" (i.e. w/out any routing protocls running), MR must be able
to return to the home network.

regards,
ryuji

---

From: Alexandru Petrescu<[email-masked]>
Date: Thu, 20 Mar 2003 19:14:10 +0100

Ryuji Wakikawa wrote:
>> IMHO, it is a really inefficient way of routing packets. 
>> searching the binding cache for a route to the mobile network is
>>  a lot slower than having a routing entry in the HA's routing 
>> table. (route lookup is faster).
> 
> 
> Can you elaborate on the performance difference between binding 
> cache and routing table? Processing steps of searching are almost 
> same.

The only difference I can see is that an execution averages shorter
times if you use an exact prefix instead of a variable longest-prefix
match.

Of course, it all depends on too many other factors that are very
often overlooked in the implementation.  I don't think we can use
speed of search as a differentiator between styles of writing specs.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2003 14:45:53 -0800

> and routing table? Processing steps of searching are almost same.

I have a nice patricia tree for the routing table.....

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2003 14:48:41 -0800

jeez.. how did we get into this discussion? I guess I am partly
to blame. anyway, for the rest of the WG, what we are discussing
is highly implementation specific. Christophe has a point there.

having said that, I prefer using a routing table entry to route
to a /64 prefix instead of using the binding cache entry. one of
the reasons is that in the platform that we use for MIPv6 HA,
there is a highly efficient data structure for the routing table,
but a not so efficient data structure (in terms of searching the
data structure) for the binding cache. I think this would be
true for most home agents.

route lookups are fast on any router (otherwise who is going to
use your router?), and they continue to improve.

to forward packets to the mobile network prefix, one can use a
combination of binding cache and routing table, only the routing
table or only the binding cache. I agree with that. also, tunnel
interface betwen the MR and the HA can be conceptual.

what I would like to see is a routing table entry for the mobile
router's network prefix with the outgoing interface pointing to
the tunnel interface (MR_HA, MR_CoA). this works well with IPsec
too (as shown in draft-ietf-mobileip-mipv6-ha-ipsec-03.txt).
this however requires that we change the tunnel end point
information whenever the MR changes its CoA. we already do this
with MIPv6. the tunnel end point information inside the SADB is
updated as the MN moves. we basically resuse IPsec in tunnel
mode, where the MR - HA tunnel becomes a IPsec tunnel. we do the
same here.

if you implement the tunnel as a virtual interface it is easy to
update the end point information in the interface data structure.
if you implement it using the binding cache, it is again easy to
update the information in the binding cache.

now, onto your mail

 > nemo/64   MR_HoA     eth0 (inteface towards MR's home link)

we dont want to use this. I dont like Case 1 either.

 > In addition, as

noooo, you can have a routing table entry where only the outgoing
interface is specified.

 > endpoint in the routing table each time MR moves.

uh... the tunnel information is not stored in the routing table.
a tunnel is created as a separate interface and is given a name.
then you enter the name of the interface as the outgoing interface
in the route entry. when you do a lookup by the lname you get the
actual tunnel information.

 > The problem with this

thats the funny part. MIPv6 and MIPv6 ha-mn-ipsec draft kind of
assume a tunnel interface between the MN_CoA and the HA. they also
argue for updating the tunnel end point as the MN moves. I like
this model.....

 > but only a possible implemtation (e.g. in annex of the nemo spec).

I agree with you here. the reason we are discussing this because
there was claimed benefit (both on the mailing list and at the WG
meeting) in using a prefix scoped binding cache entry instead of
a routing entry. I am trying to figure out what it is.

Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: Fri, 21 Mar 2003 00:24:43 +0100

> I have a nice patricia tree for the routing table.....

Which routing table?  And who is Patricia for that matter anyways.

Alex

---

From: Alexandru Petrescu<[email-masked]>
Date: Fri, 21 Mar 2003 00:54:41 +0100

Vijay Devarapalli wrote:
> combination of binding cache and routing table,

So a good sequence of steps of search should be specified.  Something
like: first search RT, then search BC.  What is the difference between
that, and a search algorithm on a tree that says: first look right,
then look left.  I would say very little difference.  And if I think
the latter is not usually done, maybe the former shouldnt be
either.  That's one of the reasons I would suppose it is difficult to
make a spec where one talks both about RT and BC.  Just a suggestion.

> meeting) in using a prefix scoped binding cache entry instead of a
>  routing entry. I am trying to figure out what it is.

So, in my oppinion, if we talk about both RT and BC,  I think there is
no benefit to have a BCE with something else than the default length.
What do you think?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2003 16:03:00 -0800

> Which routing table?  And who is Patricia for that matter anyways.

Practical Algorithm To Retrieve Information Coded In Alphanumeric. try 
google. better still, look at GateD code.

Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: Fri, 21 Mar 2003 01:19:33 +0100

> google. better still, look at GateD code.

Sounds reasonable.

We might want to assume that Mobile IPv6 for mobile networks relates 
in now way to Patricia, or am I biased here?

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2003 16:29:38 -0800

Partricia tree is a very widely used data structure for implementing
routing table/forwarding table. binding cache is most often a hash
list. works well for a few entries. performs very poorly when the
binding cache is huge.

lets go off the list....

Vijay

Alexandru Petrescu wrote:
>>>> cache
> We might want to assume that Mobile IPv6 for mobile networks relates in 
> now way to Patricia, or am I biased here?
>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Mar 2003 16:46:01 -0800 (PST)

Vijay,

I don't want to belabor this either, but it seems
to me that what you pointing out is two different
implementation approaches, rather than fundamental
differences in needed functionality. Couldn't a
bind cache entry be implemented as a host route,
for example? 

The reason I ask is *mainly* to try to figure out
whether we're arguing about terminology as implied
by implementation, rather than actual differences
in performance with one approach vs. another...

	       Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2003 16:59:54 -0800

> bind cache entry be implemented as a host route,

sure. you would also need a flag in the host route entry
telling the forwarding code to add a tunnel or a routing
header when it comes across this host route.

> in performance with one approach vs. another...

we started discussing the differences and ended up discussing
the actual implementations.

Vijay

---

From: Keisuke UEHARA <[email-masked]>
Date: Fri, 21 Mar 2003 14:34:23 +0900 (JST)

Hi Vijay,

From: Vijay Devarapalli <[email-masked]>
Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ?
Date: Thu, 20 Mar 2003 14:45:53 -0800
> I have a nice patricia tree for the routing table.....

And you can implement BC using the nice tree algorithm, if you wish.

I try to make clear the discussion:

There are 2 issues:

      (1) How to distribute the routing information for MR-A/64?
      (2) How to forward the packet addressed to a node on the Mobile
	  Network (for example MR-A, LFN).

These two are quite difference. 

For (1), Routing protocols like OSPF can be used.  Of cause, you can
use static configuration way.  It is an operational issue.

For (2), as mentiond in previous my mail, we can use routing table
instead of BC.  It is implementation issue.

In the draft, BC is introduced as a concept.  When the HA receives
then BU, HA have to manage the binding informatin somehow during the
Binding is valid.  And when the HA recevies a packet addressed to the
mobile network, HA have to forward the packet to MR-A using tunnel.
How the tunnel is setup and used are implementation issue.

I hope my mail is useful to clarify the discussion.

Regards,
Kei