Subject: RE: [nemo] Multiple Egress vs multihoming

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Apr 2003 08:23:06 +0100

Hi Erik, 

We did not really omit that case (ain't it JetSet, see below:). The note
you attach was about static routes. The topic there was whether we
wanted to enter the domain of dynamic routes between the HA and the MR.
The discussion was that dynamic routes seem to be quite inevitable if
you want some forms of multihoming; as a result multihoming => complex
basic spec, slow to mature. But that's the current req draft. I
initially proposed to work on a quick bare bones solution first, based
on TJ's draft with no dynamic protocol and no multihoming, but did not
get much success.

I'd be very happy to include multihoming and dynamic networks, but then,
why not things like IPv4 traversal and RO, where we are actually more
mature? 

I resent tihs morning a mail to Ryuji that I could not find in my nemo
folder, just in case it was lost. 

If the HAs were coordinated by the local (legacy) IGP:

A) Frequent movement of many routers may disrupt the workings of the IGP
in the HA AS
B) The HA coordination would be limited to one AS (your point, right?)
C) We'd loose the on-demand flavour of ND (if the 'wrong HA' does not
have a neighbor entry for the MR, it will look it up, and eventually get
an other HA, which is actually a next hop). I like this half proactive,
half reactive behaviour when it comes to a high rate of movemement.
D) If there are other routers in the AS then the HAs and ARs then we'd
loose the 'self-contained' aspect as well and propagate the impact of MR
mobility throughout a larger space. Plainly wouldn't scale with legacy
IGPs.

The question of a separate layer 3 protocol between the HAs, was in my
mail (3/16) with my comments on Ryuji's draft. I guess that the idea of
such a protocol is already present in MIP or NSIIM as well? 
"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."

In the design list (4/11) I also pointed out that a MANET  type of
protocol could be used for the dynamic solution:
"I believe it's hard to include a dynamic routing protocol without this
kind of prior research. Also, some routing protocols may scale better
than others. Maybe we could use a MANET derived routing protocol such as
OLSR. Maybe we could pass the routing info in the BU like in PSBU or
draft-wakikawa..."

I proposed (4/29) that this protocol be run on a multicast group
regardless of the admin boundaries:
"it's yet an other (simple) routing protocol, and we need to understand
how these routes are injected to the routing table of the HA, and then
redistributed to the others (you need a metric that can be configured on
the HA for instance). I would not use the Routing protocol of the AS of
the HAs to do that, because I'd contain it inside a HA multicast group,
even if that group spans outside of the AS (JetSet)"

You see where this is all leading to:

A) A topology as proposed earlier in the MIP list (was that Greg?) with
no home network.
B) A virtual network that encompasses a group of commonly administered
Mobile Networks. 
C) HAs organised in multicast groups, one per virtual network, many of
them.
D) A routing protocol, maybe with a MANET origin, between the HAs, one
instance per multicast group
E) A registration derived from Ruyji's draft, with maybe a MANET twist
to interoperate with the HA routing protocol
F) Still from Ruyji's drafts, one MNET address per careOf, a number of
MNET addresses per MR.
G) Potentially a new form of anycast, "anyone in a multicast group", for
DHAAD related stuff.

From the bare bones approach, it's quite a quantum leap. Far from an
obvious adaptation of MIPv6 as bare bones was to be. Much more
interesting to design, though. What should we do?

Voila!

Pascal
> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: mercredi 30 avril 2003 05:54
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [nemo] Multiple Egress vs multihoming
> 
> 
> > Same home Address for both makes a single static route, all the 
> > packets to that route. If there's a distribution, it happens at BCE 
> > time, when choosing between multiple parallel 
> registrations, which is 
> > DYNAMIC, this time. The problem is to have both MRs register to the 
> > same HA and make as if there was a single MR with multiple CareOf 
> > (Tarzan). Or else you need to coordinate the HAs, but it 
> seems even a 
> > bigger change from MIPv6 because of ND interaction.
> 
> Pascal,
> 
> I don't understand what you think is the "bigger change".
> 
> Routing protocols already do such "coordination" in the the 
> same route can arrive at the same router (within the home 
> site) from different routers = HAs.
> 
> So I don't understand why routing protocols are excluded from 
> the thinking.
> 
> What am I missing?
> 
> One thing that matters in this multihoming picture which 
> everybody seems to be omitting is the location of the Home 
> Agents with respect to administrative boundaries.
> 
> The case when one or more MRs (one with multiple 
> interfaces/CoAs or two MRs each with a CoA) have separate HAs 
> where the HAs are in the same admin domain can be made to 
> work very well by having the HAs advertise the prefix route 
> for the mobile network into the IGP. (Whether the HAs do this 
> only when the tunnel is "up" or whether a routing protocol is 
> run over the MR-HA tunnels is at some level a detail here.)
> 
> The case (with one or more MRs as above) where the HAs are in 
> different admin domains is quite different. If you want 
> routing to scale you can't use a single prefix for the mobile 
> network in this case since that prefix would need to get 
> advertised in BGP. 
> Essentially this case becomes the site multihoming problem; 
> the mobile network is a site which has to ISPs - one running 
> each HA. Thus to the extent that site multihoming is solved 
> this is also something that the Nemo WG doesn't need to worry about.
> 
>    Erik
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Apr 2003 21:54:42 +0200 (CEST)

> basic spec, slow to mature.

I completely fail to understand how you come to this conclusion.
The basic spec would say how to establish the HA-MR tunnels
and can be utterly silent on the fact that existing routing protocols
can run over these tunnels.
Some people call this modularity.

> A) Frequent movement of many routers may disrupt the workings of the IGP

Unless you have a very different model than I have this isn't true.
The HA<->MR tunnel getting a different CoA would not be visible to
the routing protocol at all.

> B) The HA coordination would be limited to one AS (your point, right?)

Yes. And it might be further limited if OSPF or IS-IS areas are used
within one domain in order to aggregate internal routing.

> half reactive behaviour when it comes to a high rate of movemement.

You seem to have either a conceptual model or an implementation model
of how Nemo interacts with IP routing in a HA and I don't understand.
IP routing reacts to interface changes and the tunnels are interfaces
(conceptually, and they have an ifindex in the MIBs), thus
the IGP would take care of the tunnels goming and going.
Thus unless I misunderstand what you mean with "on-demand" 
the on-demand nature seems to be orthogonal with the IGP vs. not-IGP.

> mobility throughout a larger space. Plainly wouldn't scale with legacy

Nope. See my answer to A).

> such a protocol is already present in MIP or NSIIM as well? 

MIP has a protocol for coordinating between HAs for different Home Addresses?
For the same Home Address?
I've never seen such a thing.

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

We seem to be talking about different models.
In my model each MR (or the different interfaces on the single MR)
have a different home address, even though there is a single prefix
for the mobile network.

The above paragraph as well as A) and D) makes me believe you have
a completely different model in mind where the IGP runs without tunnels
between MR and HA.
Further, in routing protocols there is an issue of who can
advertise which routes; this is solved by configuration today
even though it is typically done at IGP/EGP boundaries and not inside
an IGP. (But the Magma anycast case is one where IGP routers would
be configured with which routes to accept from which peer.)

> protocol could be used for the dynamic solution:

But that is for the "no tunnels" model, right?

> even if that group spans outside of the AS (JetSet)"

Once we actually understand the high-level model for IGP+tunnels
(what I'm advocating as a way to handle multihoming) there are
at least two different ways to do the details:
1. Actually run a routing protocol over the tunnels between MR and HA.
   This consumes some background traffic (for the hello protocol) but
   the benefit is that the hello protocol will detect when there is
   no longer bidirectional connectivity over a tunnel.
2. Not running a routing protocol over the tunnel but instead have
   the establishment of the tunnel make the HA inject the route into the IGP.

> You see where this is all leading to:

No, I don't see because we are making different assumptions and have
different models in mind.
I don't think we want a different routing protocol for this but instead
reuse existing ones. (There is a potential research topic on how to do
routing in a network where lots of things move, so here I am limiting
my concerns to the IETF more short-term issues.)

> A) A topology as proposed earlier in the MIP list (was that Greg?) with

I believe the prefix(es) assigned to a mobile network have a home
in the sense that they fall within a shorter prefix.
And the HoA for each MR's interface may fall in a physical home network
or a virtual home network.

> B) A virtual network that encompasses a group of commonly administered

On what scope? Isn't this the same as the prefix I refer to above?

> C) HAs organised in multicast groups, one per virtual network, many of

Here is where you are defining a new routing protocol, right?

> G) Potentially a new form of anycast, "anyone in a multicast group", for

For G) I think you are conflating the issues around the HoA for the MRs
and the routing advertisement for the mobile network.
DHAAD is useful for the former, but the routing stuff could be layered
cleanly on top of that.

> interesting to design, though. What should we do?

I don't think we need any of what you are proposing because I think
the WG should do the basic tunnels and allow routing to be layered on top
of this. That avoids having to re-invent IP routing and potentially do
it poorly.

   Erik