Subject: Re: [nemo] Multiple Egress vs multihoming

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 May 2003 17:53:36 +0100

> > 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.
> 
> 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.
> 

Well... the req draft still includes multihoming, that's the problem.
And we've been discussing whether multihoming made sense without dynamic
routes, which is a name for the dynamic update by the MR to the HA about
its prefixes. Seems multihoming will require dynamic routes (see my 1st
mail on 4/23 on this thread). Now we are working on a taxonomy of
multihoming cases. Actually I'm more interested in a taxonomy of the
problems than of the cases. Chan Wah and Julien have been helping a lot
clearing up the issue.

> > 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
> 
> 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.
> 

Right. The movement we've been talking was home/leave-home/back-home. An
other case is register, deregister. That's the kind of action that may
cause trouble in the IGP.

Anyway, one thing is a given HA's AS or at least it's area, as you
mention later. A second is a home link. (A third would be a newly
created HA group for HA to HA advertisements). There's often a confusion
between the first 2, even though everybody understands what they are.
The confusion is about the impact of a registration. Everybody agrees
that it should be contained between the HAs and should not impact the
rest of the world. In other words, that the HAs should globally
advertise the aggregation of the mobile networks. 

The impact of the movement I'm talking about can be limited to the HAs
if:
- there's no involvement of the IGP (today this means use ND and static
routes only)
Or if
- the HAs and MR form their own AS (this is the confusion, assuming home
link is AS).

On the other hand, a multicast group of HAs may span over different ASs
and if each member advertises the aggregation we're talking about, the
impact of registrations and movements are contained. I'm talking about
yet an other routing protocol, capable of aggregation, running over
multicast groups that span over AS boundaries. A functional group.

> > C) We'd loose the on-demand flavor 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 behavior 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.
> 

Traditional IGPs are all proactive. They assume a quite stable topology
and may not cope with mobile networks so easily, for the reasons
mentioned above. An interface (tunnel) state change causes a
recomputation of everyone's states within an area/AS. 

Say on the other hand that you use something like AODV or DSR over a
multicast group of HAs. When a MR registers a mobile network to a HA,
the information does not have to be proactively flooded. Only if another
HA gets a packet that needs to be forwarded to that mobile network will
it look up a route, on demand. All the HA(s) that got registrations will
source an answer to that flooding. 

If you look at it, when you hardcode static routes to the mobile
networks via the associated MR home addresses, what happens at ND level
on the home link is very much the same. If the wrong HA does not have
the MR in its neighbor cache, it floods a lookup, on demand. This is why
I like very much with that model. Scales well with MNet 'mobility'.

> > 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.
> 
> Nope. See my answer to A).
> 
> > 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?
> 
> MIP has a protocol for coordinating between HAs for different 
> Home Addresses? For the same Home Address? I've never seen 
> such a thing.
> 

I think I've seen a mention to it in the MIP ML. Can't remember when
exactely.

> > "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."
> 
> 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.
> 

Right. This was about Ryuji's model. The Home Address is actually an
address on the Mobile Network. I'm advocating  forone such address per
parallel CareOf as ID.

> 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.)
> 
> 

Right again :) What we call dynamic mobile networks is when there's a
form of advertisement by the mobile router to the HA about the mobile
network (as opposed to delegation by HA or static routes in the HA). The
problems you mention will have to the addresses, together with
redistribition if the IGP over the tunnel is not the home net IGP. In
Vijay's model it is. In Ryuji's, the advertisement is the BU itself. But
even that is a simple routing protocol and has to provide a model for
trust and redistribution...

> > In the design list (4/11) I also pointed out that a MANET  type of 
> > protocol could be used for the dynamic solution:
> 
> But that is for the "no tunnels" model, right?

I meant that if the HA to HA is a Manet, maybe the MRs could participate
as well, over their tunnels. As an alternate to Vijay's or Ryuji's
approach. Just to say the problem is not clear cut yet. Which makes
basic a complex thing if we want multihoming, if I'm right that
multihoming requires dynamic networks...

> 
> 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.

This is what I called Vijay's model since he defends draft-kniveton

> 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.
> 

This is what Vijay and Alex call static routes, though I think it's a
misleading term.

> > 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 no home network.
> 
> 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.

I meant as implied by Ryuji, no concept of returning home for a MR. But
yes, the aggregation you mention has to be there, that seems kind of
obvious in the background technology.

> > B) A virtual network that encompasses a group of commonly 
> administered 
> > Mobile Networks.
> 
> On what scope? Isn't this the same as the prefix I refer to above?

Could be a bunch of them

> 
> > C) HAs organised in multicast groups, one per virtual 
> network, many of 
> > them.
> 
> Here is where you are defining a new routing protocol, right?

:)

> 
> > 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.
> 
> 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.

Yes. I'm not sure I understand what's wrong. I agree it's orthogonal but
still it's needed, right? 

> 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.
> 

Never argued that against the MRHA tunnel and layering a routing
protocol over it. Do you still think the second sentence  is relevant is
the light of this discussion?

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 May 2003 20:54:13 +0200

Pascal Thubert (pthubert) wrote:
>> 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.
>> 
> 
> 

I do not see anything in the reqs draft related to multi-homing (R12 and
  R13.1-3) that can not be satisfied by a simple basic nemo protocol.

As they are now, those requirements are fine with me.

That does not mean that those multi-homing requirements should be
refined such as to make the basic kind of solution impossible to work
with multiple egress interfaces.

That is also to support to trying to modify the "requirements" in
the title of the draft to "goals".  This has already been suggested at
the NEMO meeting and I find it to be a good idea.  In the particular
case of multi-homing requirements, it would be fine to have it as a
_goal_ to support multiple egress interfaces and multiple Mobile
Routers, point bar.

The simplest of the basicest nemo solutions would be lean and fit those
multi-homing goals. On another hand, a strong requirement, such as "MUST
support _any_ number of egress interfaces, any number of MRs, any number
of HAs, with MRs switching between various HAs" would easily drive into
building a network that does everything based on "NEMO multi-homing" and
does no dynamic routing protocol nor the other modules.

On another hand, yes, the draft on requirements should be updated in
order to be kept alive after the 6-month expiration; but that can be
updated with other simple modifications, like better format, coherency
(R12-R13), add a Change section, eliminate the redundant "Location
Privacy", etc.

My two cents worth,

Alex
GBU

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 May 2003 13:57:18 +0200 (CEST)

> multicast groups that span over AS boundaries. A functional group.

Pascal,

This sounds like an interesting research topic but seems to be outside 
of the scope of the WG.
The WG has shorter term deliverables around tunneling HA-MR,
and a deliverable around the possible approaches for route optimization,
but nothing about defining some new routing protocol running over a 
multicast-discovered overlay of HAs.

If there are multihoming issues that need to be written down
and considered for the HA-MR tunneling case, the WG should do that.
(And I personally think this is just an issue of not preventing
multihoming by assuming e.g. one prefix per MR).
But so far I've seen no plausible argument that the WG can't do that
and instead should embark on some unknown new model for routing.

So let's focus on the WG deliverables.

  Erik