Subject: [nemo] supported multihoming scenarios

From: Chan-Wah Ng <[email-masked]>
Date: 22 Jul 2003 15:10:18 +0800

Hello, all,

Base on discussion from IETF-57, there is an issue of which multihoming
scenarios should be supported by Basic Solution.  I hereby list them
all, and give a brief description of the issues.  Like to seek working
group consensus on which multihoming scenarios the NMEO basic solution
should be supported.  For detailed analysis of each scenario, please
refer to draft-ng-nemo-multihoming-issues-01.txt and
drfat-charbon-nemo-multihoming-evaluation-00.txt (should be available in
IETF repository soon, otherwise you can always retrieve it from
[http://www.sfc.wide.ad.jp/~julien/papers/draft-charbon-nemo-multihoming-evaluation-00.txt]).

* (0,0,0): Single MR, Single HA, Single Prefix

- No major issue

* (0,0,1): Single MR, Single HA, Multiple Prefixes

- No Major issues

* (0,1,0): Single MR, Multiple HAs, Single Prefix

- Do we support only the case where every HA belongs to the same
administrative domain?
- If HAs belong to different domains, it may interfere with global
routing since different domains now advertise routes to the same
prefix..

* (0,1,1): Single MR, Multiple HAs, Multiple Prefixes

- Do we restrict ourselves to only the case where each prefix is only
registered to HA within the same domain?
- If the same prefix is registered to HAs from different domains, it may
interfere with global routing since different domains now advertise
routes to the same prefix..

* (1,0,0): Multiple MRs, Single HA, Single Prefix

- No major issues

* (1,0,1): Multiple MRs, Single HA, Multiple Prefixes

- No major issues

* (1,1,0): Multiple MRs, Multiple HAs, Single Prefix

- Do we support only the case where every HA belongs to the same
administrative domain?
- If HAs belong to different domains, it may interfere with global
routing since different domains now advertise routes to the same
prefix..

* (1,1,1): Multiple MRs, Multiple HAs, Multiple Prefixes

- Do we restrict ourselves to only the case where each prefix is only
registered to HA within the same domain?
- If the same prefix is registered to HAs from different domains, it may
interfere with global routing since different domains now advertise
routes to the same prefix..

/rgds
/cwng

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 22 Jul 2003 10:43:02 +0200 (CEST)

> - Do we support only the case where every HA belongs to the same

I don't think it is the admin domain which is really pertinent but a more
general concept: The multiple HAs must be located so that the single prefix
is not part of an aggregated prefix where the aggregation occurs between the
HAs.

For example if the HAs are in a single routing domain which uses OSPF or IS-IS
then either the HAs must be part of the same IGP area, or the prefix
assigned to the mobile network must not be aggregated at the area boundary.

> routing since different domains now advertise routes to the same

I think this statement is backwards since there tends to be filtering of
advertised prefixes at AS boundaries. Thus if this were to be done
it is likely that things would not work due to the routes for the
mobile network's prefix are likely to be filtered.

> routes to the same prefix..

same comment as above.

But there is an addition point of view which is that in this case
the mobile network can be viewed as a multihomed site similar a home
being multihomed to both a DLS provider and a cable modem provider.

I'm concerned that the categorization you use don't capture the important
distinction between the case when the MR(s) are independent of the HA(s)
(as is the case in the site multihoming view) and when the MR(s) are
operated by the same entity as the HA(s).
In either case there are existing techniques that can be applied
independently of Nemo, but the techniques would be quite different in
the two cases.

When there are multiple prefixes assigned to the mobile network
this is most likely due to the MR(s) being independent of the HA(s)
i.e. the site multihoming view.

> routing since different domains now advertise routes to the same

see above

> routes to the same prefix..

see above

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 22 Jul 2003 10:43:02 +0200 (CEST)

same comment as above.

see above

see above

  Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 22 Jul 2003 10:33:56 -0700

> - Do we support only the case where every HA belongs to the same

I think this should be a MUST for a single Prefix.

> registered to HA within the same domain?

yes.

> - Do we support only the case where every HA belongs to the same

yes.

> registered to HA within the same domain?

yes.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 22 Jul 2003 10:33:56 -0700

yes.

yes.

yes.

Vijay

---

From: Chan-Wah Ng <[email-masked]>
Date: 23 Jul 2003 18:38:46 +0800

Hello Erik, 

Thank you for your insight.  See response in-line.

> assigned to the mobile network must not be aggregated at the area boundary.

Agreed, it is not specifically the admin domain that gives complexity,
but the interactions with the routing protocols used.  The question is
then do we need to open up NEMO to such complexity?

My recommendation is that the only requirement is for NEMO to support
the case where a single prefix be registered to home agents belonging to
the same routing domain such that there is no additional constraints
impose on the way mobile network prefix is chosen other than it is
aggregated from the said routing domain.  Should implementors want to
support beyond such case, they can do so by whatever legal means. 
However, it will not be taken into consideration when evaluating NEMO
basic solution.

> mobile network's prefix are likely to be filtered.

You are right.  It still means that considerable effort will be needed
so that NEMO can be used with a mobile network with mobile routers
belonging to the different AS/admin/ruting/ICP domain/area.

> i.e. the site multihoming view.

Would you care to elaborate more on the two different point of views? As
far as I see, using the example of a home network with a DSL and a
cable, the DSL-ISP will give your DSL modem an IP address, and cable ISP
will give you another IP address for your cable modem.  So, the IP
addresses belongs to two different ISP of different domain.  

There is actually previous discussion on whether we should expand the
axes and use the following:
y = 0: single HA,
y = 1: multiple HA from same domain
y = 2: multiple HA from different domains
Are you suggesting something along this line?

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 23 Jul 2003 18:38:46 +0800

Hello Erik, 

/rgds
/cwng

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 23 Jul 2003 15:41:02 +0200 (CEST)

> then do we need to open up NEMO to such complexity?

Doesn't cause any additional complexity in the Nemo protocol AFAIK; the
ability to convey a prefix in the BU is one option and the other
option is to run an IGP over the tunnel. That should be sufficient.

My point is that if you want the draft on multihoming to clearly state the 
scenarios and issue, whether or not they effect the Nemo protocol,
they I think you should capture this high level distinction.

If you don't want to capture the scenarios and issue then I don't think the
multihoming draft is needed since the protocol document will provide the
building block (and how to run an IGP over the tunnels can be left as
an exercise to the reader?)

You seem to think adding explanator text and different categorization to
the multihoming draft will somehow effect the Nemo protocol. I fail
to understand why this would be the case.

How and why would the Nemo protocol need to be different in your opinion?

> Are you suggesting something along this line?

First of all "domain" is not the best word, since it is the general issue
whether the prefix is aggregated between the multiple HAs.
But the more important point is that you are approaching the description
from the bottom up and I am suggesting the top down approach which
starts with the control and ownership of the HA(s) and MR(s).

If the HA(s) and MR(s) are controlled by the same entity (for instance an ISP)
then the ISP can decide whether it wants to assign one or multiple prefixes
to the mobile network just like it can make that decision for any other link
in its network. In any case the ISP will make routing work i.e. not introduce
any aggregation between the HA(s) which will filter out the routing
announcements for the mobile prefix(es).
The tools the ISP has for making routing work is to 
 - run their IGP over the tunnels, or
 - use static routing of the tunnels (the prefix in the BUs) perhaps combined
   with some liveness testing protocol applied to the tunnels
The ISP might be less likely to use prefix delegation since the MR(s) can
presumably be configured with the proper prefixes using whatever
management system the ISP uses for the routers.

If the HA(s) and MR(s) and controlled by different entities it might look
a lot more like the HA(s) being controlled by (one or more) ISP and the MR(s) 
being controlled by a subscriber.
(Presumably when there are multiple MR(s) on the same link
they need to be controlled by the same subscriber otherwise there might
be a lack of coordination of the control of the mobile link).
From the top down there are two possible subcases:
 - The MR(s) establishing multiple tunnels to the same ISP (to get additional
   capacity, redundancy, etc) whether or not they are connected to the same
   HA in the ISP (having multiple HAs might improve availability though)
 - The MR(s) making the mobile network a multihomed site (see multi6)
   by connecting to different ISPs.
When there is a subscriber/provider relationship at the MR-HA tunnels
it is rather unlikely that an IGP would be used for routing (due to
the possibility of the subscriber accidentally or intentionally messing
up the IGP for everybody); it is much more likely that the prefix
in BU will be used to provide static routing.
An issue to consider is whether it makes sense to specify a tunnel liveness
protocol so that the HA and MR can detect when one tunnel fails and cause
the other tunnel(s) to be used.
With the subscriber/provider relationship it is likely that prefix delegation
would be used.

Does that high-level description make sense to folks?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 23 Jul 2003 15:41:02 +0200 (CEST)

Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Jul 2003 02:13:36 +0200

[in all my oppinions expressed below, sorry if lack of knowledge.]

Erik Nordmark wrote:
>> Agreed, it is not specifically the admin domain that gives 
>> complexity, but the interactions with the routing protocols used. 
>> The question is then do we need to open up NEMO to such complexity?
>> 
>> 
> 
> Doesn't cause any additional complexity in the Nemo protocol AFAIK; 
> the ability to convey a prefix in the BU is one option and the other
> My point is that if you want the draft on multihoming to clearly 
> state the scenarios and issue, whether or not they effect the Nemo 
> protocol, they I think you should capture this high level 
> distinction.

I tend to agree.

> If you don't want to capture the scenarios and issue then I don't 
> think the multihoming draft is needed since the protocol document 
> will provide the building block (and how to run an IGP over the 
> tunnels can be left as an exercise to the reader?)

Yes, exercise, with a deadline.

> If the HA(s) and MR(s) are controlled by the same entity (for 
[...]
> The ISP might be less likely to use prefix delegation since the MR(s)
>  can presumably be configured with the proper prefixes using whatever

A-ha. But I see prefix delegation in that case too, for same reasons
that DHCP is used today by an ISP that gives an IP address at home.

>  the possibility of the subscriber accidentally or intentionally 
> messing up the IGP for everybody); it is much more likely that the 
> prefix in BU will be used to provide static routing.

As if providing prefix in the BU would prevent a subscriber to
accidentally or intentionally messing the Prefix Table at HA and thus
the other MNP entries of the other subscribers.  (if mechanisms exist
for this prevention, and only for BU's and not for IGP, then sorry).

Doesn't an IGP already have means to avoid that messing up, by the way
of keys for authenticated route updates?

> An issue to consider is whether it makes sense to specify a tunnel 
> liveness protocol so that the HA and MR can detect when one tunnel 
> fails and cause the other tunnel(s) to be used.

Which is the domain not of NEMO IMHO.  I mean it also applies to a
Mobile Host that has two tunnel interfaces up, so it might better be
MIP6?  It's good to have tunnel liveliness reliably maintained by
heartbeat checks, but maybe Mobile IPv6 has already started on that
direction with Binding Cache entries expiration(?).  What Mobile IPv6
hasn't is heartbeats.

Anyways, yes, it's good to have this detection capability specified and
leave open how it's used.

> With the subscriber/provider relationship it is likely that prefix 
> delegation would be used.

Yes.

> Does that high-level description make sense to folks?

Yes, mostly with respect to multi-homing.

One queestion about the subscriber/provider model, is it possible to
have MR at home? If yes, by what means will the HA add real entries in
its real routing table when that "alien" Mobile Router is at home? Is it
assumed that the HA will use information in the Prefix Table in order to
pre-configure an initial routing table (because I thought it was
vice-versa).

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Jul 2003 02:13:36 +0200

I tend to agree.

[...]

Yes.

Alex
GBU

---

From: Chan-Wah Ng <[email-masked]>
Date: 24 Jul 2003 12:08:44 +0800

Hello, Erik,

> they I think you should capture this high level distinction.
Agree.  The draft should capture such issue.  However that does not
means that the NEMO Basic solution must support.  My point is: the
multihoming draft is an informational document with the following two
objectives:

(1) to capture issues of deploying a multihomed mobile network (which
definitely should include all insights the nemo WG can share, including
the points you made above)

(2) to identify which multihoming scenario NEMO basic solution would
support.  It dosen't mean that those not supported will not work with
NEMO, just that it is up to the implementors to make it work (hopefully
issues discussed in the document will be helpful to these implementors).

Are these agreeable?

> to understand why this would be the case.

Nope, I don't think so.  Again, my objectives are stated clearly above.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 24 Jul 2003 12:08:44 +0800

Hello, Erik,

Are these agreeable?

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 24 Jul 2003 14:06:35 +0800

Hello Alex and Erik,

> direction with Binding Cache entries expiration(?).  What Mobile IPv6
What can be done in place of heartbeats is to use a lifetime = period of
intended heartbeat.  Then the BU messages sent can by all effect be
considered as heartbeats.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: 24 Jul 2003 14:06:35 +0800

Hello Alex and Erik,

/rgds
/cwng

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 24 Jul 2003 13:58:10 +0200 (CEST)

> that DHCP is used today by an ISP that gives an IP address at home.

If an ISP has a router (that the ISP controls) at the customer's premises
than prefix delegation might make sense.
But it probably makes less sense if an ISP runs a bunch of routers - some
located in fixed places and others located on trains and plains.
I said "less likely" trying to compare with the case with a provider/subscriber
boundary between the HA(s) and MR(s) - in that case I suspect that prefix
delegation would always be used.

> for this prevention, and only for BU's and not for IGP, then sorry).

I can't quite parse the paragraph. My point is that a mechanism for
authorizing what prefixes can be "advertised" can be added as part of
the BU mechanism, but might not exist in an IGP implementation.

> of keys for authenticated route updates?

AFAIK this is a single key for the whole routing domain i.e. provides for
authentication and authorization at the "I'm a router in the IGP" level,
but that there isn't any existing mechanism to authorize particular routers
to only advertise particular prefixes.
But I could be wrong on this.

> have MR at home? 

Seems a bit odd in that case because the HA(s) will be operated by the ISP
and the MR(s) by the subscriber, thus it seems unlikely that the MR will
actually be on its home link. The only case I can think of is when the home
link is e.g. the DSL link between a household and the ISP and the whole
house goes mobile. 

  Erik

> If yes, by what means will the HA add real entries in

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 24 Jul 2003 13:58:10 +0200 (CEST)

Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 24 Jul 2003 11:08:14 -0700

> But I could be wrong on this.

this is my understanding too.

and for the NEMO protocol (when not using IGP over the 
MR-HA tunnel), we have defined something called the
Prefix Table at the HA. the HA checks the Prefix Table
to see if a particular MR is authorized for the prefixes
it claims. this is necessary to prevent a misbehaving MR 
from claiming prefixes that belong to another MR.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 24 Jul 2003 11:08:14 -0700

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 24 Jul 2003 11:10:10 -0700

> issues discussed in the document will be helpful to these implementors).

this sounds good.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 24 Jul 2003 11:10:10 -0700

this sounds good.

Vijay