Subject: RE: [nemo] Multiple Egress vs multihoming

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Apr 2003 13:15:50 +0100

Hi Chan-Wah 

> I beg to differ.  Requirement 13.1 does not equate to 
> "Multiple MRs with different HAs advertising same prefix".  
> Why in the first place would two MR choose to advertise the 
> same network prefix if they does not belong to the same 
> administration domain?

It's one way of being multihomed. You have a mobile network in a train.
One prefix. But you want redundancy (load sharing?) so you serve it by
not 1 but 2 MRs. They share the same home network. But may end up on
different HAs if DHAAD is being used or of configured that way. That was
my understanding of the requirement.

But I agree it can be understood differently; IMHO, we should build a
clear taxonomy of all cases (I mean list them, and name them). And then
see what we keep for basic nemo. 

> 
> For static:
> Why would we require both MR to be on at the same time?  If 
> one MR is down, its corresponding HA will not receive any BU 
> from that MR, and thus cannot establish a route to that MR.  
> Hence it will respond to any packet that is destined to the 
> mobile prefix with a ICMP destination unreachable or ICMP 
> redirect messgae.  Just as in the case of w non-mobile, 
> multiple router scenario.
> 

Say you have one prefix, P, and 2 MRs, with home address A1 and A2,
respectively
The static routes in the HA look like "ipv6 route P A1" and "ipv6 route
P A2" meaning that P is reachable via either MR at equal cost. 
Static Route are permanent things. The routes are always there.
Including if the MR is at home, or power off. 
This is no big deal if there's a single MR. If it's joinable (home or
registered), you'll get to P. If not, since there's no alternate path to
P, there's no harm having the route. This keeps the routing protocols
quiet and allows for a large number of MRs/movements. 
This is the way things happen unless you add a dynamicity like the MR
exposes itself when at home, and the HA exposes the MR when the MR is
registered. But this is not static routes anymore (I guess it's the
model you have in mind).
If you have 2 MRs, and 2 real static routes of equal cost, the router
behaviour is a round robin traffic splitting, unless you add policies to
the picture.
If the HA has static routes to the mobile network via two MRs, and only
one is reachable, half of the packets are dropped. Now, it's a pain.

> In addition, I don't understand why DHAAD would require 
> co-ordination of both MRs, unless you are saying the two MR 
> must discover the same HA. 
> Question then is why?
> 
That's if they register the same home address. This allows to have a
single static route and alleviates the problem mentioned above. But
then, even if we create a support for multiple careofs, you still have
to have them on a single home agent, because of DAD. Unless you create a
new coordication between HAs. 

Anyway, you see that this leads us into complex grounds (much more then
other items we dropped in order to release a quick spec for basic :)
Pendora's box.

Pascal

---

From: Chan-Wah Ng <[email-masked]>
Date: 24 Apr 2003 11:08:03 +0800

Hello again, Pascal,

> my understanding of the requirement.

I completely agree that your interpretation is one of the possible
scenario of requriement 13.1.  However, there are other equally pausible
scenarios. IMHO, dropping R13.1 because one of its interpretation is
deemed too complex (which is arguable in the first place) is too drastic
an action.

> see what we keep for basic nemo. 
I raise both hands in agreement to that :)

> one is reachable, half of the packets are dropped. Now, it's a pain.

Okay.  Let's consider non-mobile case.

Suppose you have a subnet that has two routers, R1 and R2. Somehow their
egress links are all connected (directly or indirectly) to a border
router, or gateway, RG.  Static routes are used.  If R2 is down, how
would RG respond?

Now change R1=MR1, R2=MR2, RG=HA. Is there any differences?  If not,
NEMO is not introducing any new problems that does not occur in non-NEMO
case.  So having requirement R13.1 does not dictates the basic solution
to solve a problem that is already in existence in non-mobile case.  

> new coordication between HAs. 

The catch is why must they share the same home-address.  I am not
convince that this is the case.  Perhaps you can convince me on that
with the responsd to the wired-scanrio above, based on your expertise in
routers operations.

-- 
Chan-Wah Ng <[email-masked]>
Panasonic Singapore Laboratories

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 24 Apr 2003 16:03:10 +0900

Hi all, Pascal, Chan-Wah,

> In the v 00 of the requirements, Thierry had the multihoming included. 
> This was discussed at the WG and you'll find the summary at
> http://www.nal.motlabs.com/nemo/ietf56/chat-ietf56.txt
>
> Since the requirement draft is the base for the design, I suggest we
> finalize that one first, what do you think?

OK, I'm the onw to blame here, I'm due to submit the new version ASAP.
Please wait a couple of days more. Sorry for the delay.

> > my understanding of the requirement.

This requirement allows another scenario. I have a car. I want distinct
ISPs at the same time, not for redundancy. One MR will be my mobile
phone and the ISP a cellular operator. The second one will be the
built-in MR in my car. It has a 802.11xx interface, and DHRC.  The ISP
for DHRC is the RoadInfrastrucure company.  The ISP of the 802.11xx is
maybe the same as the one I have in my house.  I can use 802.11xx in the
gaz station, in the parking lot. So, I have 3 distinct HAs here. What I
don't know yet is if I have one or more prefix.

> deemed too complex (which is arguable in the first place) is too drastic

I agree with Chan-Wah. 

Not that R13.1 doesn't say that a solution must be provided, but it
allow it to work (at last meeting I was agreeing that "MUST support" is
not the best way to express this requirement).

> I raise both hands in agreement to that :)

You mean you are volunteering here ? :-) 
FYI, this is something we are currenrly investigating here. But we
expect this to take time.

> > other items we dropped in order to release a quick spec for basic :)

Thierry.