Subject: [nemo] Same MNP registered for several HoA

From: Romain KUNTZ <[email-masked]>
Date: Fri, 17 Jun 2005 17:26:57 +0900

Dear all,

I am currently performing some multihoming tests with NEMO Basic Support.
The topology I am currently testing is (2,1,1): two MRs registered to the
same HA, registering the same prefix.

I would like to know if there was already a consensus about the fact
that a HA can or cannot allow to bind the same MNP to 2 different HoA
(this is typically what happens in the scenario I mentioned). AFAIK
RFC3963 does not suggest anything about that, nor the drafts about
prefix delegation for NEMO BS.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 17 Jun 2005 14:28:22 +0200

Romain KUNTZ wrote:
> Dear all,
> 
> I am currently performing some multihoming tests with NEMO Basic
> Support. The topology I am currently testing is (2,1,1): two MRs
> registered to the same HA, registering the same prefix.
> 
>  (this is typically what happens in the scenario I mentioned).

Romain, I can not remember about that consensus, sorry, but I have some
remarks.

I am not sure one could require HA to allow or not allow multiple
bindings for same MNP towards different HoAs.  But what one could do is
to require the routing mechanism to *work* according to some new
functionality.

In my understanding, for a certain prefix a router should have a unique
route towards a certain IP address.  If there are two such routes, and
without any other differentiator, only one of those routes will be taken
into account for forwarding.  In practice either the last route or the
first route in the table will actually be used, depending on implementation.

Bindings are like routes.  If one needs multiple bindings (same MNP
different target HoA) then one needs a differentiator for selecting
among those routes when forwarding packets.

For routes, this has been done with traffic engineering I believe.  OSPF
TE, and MPLS come to mind, but I'm not expert.  In these cases the
same-prefix routes are distinguished by bandwidth and other "forced"
constraints (overcoming the simple longest-prefix-matches).

So one may think about OSPF-TE over tunnels, for NEMO, or similar.

Just some remarks...

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 17 Jun 2005 12:50:39 -0700

> prefix delegation for NEMO BS.

the design goal when working on RFC 3963 was that we should not
prevent any mutli-homing scenario. thats why it is kind of silent
on this.

it should be okay to have the same prefix in two different binding
cache entries. the only check that is performed is whether a
particular MR is authorized for a particular prefix. if both MRs
are allowed to use the particular MNP, then binding updates from
both MRs will succeed.

as Alex pointed out, you have to be careful when you create routes
for the MNP. you have to pick one MR (or have both routes and let
your forwarding code figure out which route to use).

I agree this should be considered in prefix delegation.

I am hoping this will be clarified when we do the multi-homing
solution for NEMO.

Vijay

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 22 Jun 2005 19:46:32 +0200

Hi Vijay and Alexandru,

Thanks for your answers,

> are allowed to use the particular MNP, then binding updates from

Ok that was my understanding. I think this behaviour is useful for fault 
recovery when you have a Mobile Network with 2 MR, each MR advertising 
and registering the same prefix. If one of the MR fails, then the HA 
will be able to choose the other MR once the entry in the BC for the 
first one is deleted and the tunnel endpoint updated.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: "T.J.Kniveton" <[email-masked]>
Date: Mon, 27 Jun 2005 15:24:57 -0700

As you guys noted, the draft is pretty silent on the question of using 
the same MNP for more than one MR. It's possible to implement things 
that way, but you'd better "know what you're doing" if you want to try 
it, since it could cause lots of problems. Until now, it's not a 
question that came up very often, though we did consider it also for 
prefix delegation.

TJ