Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs]

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 24 Mar 2004 11:25:15 -0500

> > => I don't think this is a requirement on the basic spec.
 > > I think this is useful in many cases but I could also
 > > ask the question: How do you preserve communication
 > > when the HA fails ? I think this is a general problem
 > > with MIP solutions when the communication goes through the
 > > HA. There is no good way of detecting such failure and when
 > > it happens, there is no way (other than providing a redundant
 > > HA) to preserve communication in a timely manner.
 > 
 > So i guess that current spec doesn't provides support for 
 > multiple HAs, is
 > this correct?

=> Not for multiple HAs per MR, for the same prefix.
If you can decrypt this sentence I'd be grateful ;)

 > 
 > Well, redundancy is the main goal for multihoming, so if you 
 > don't get
 > redundancy probably you don't need multihoming i guess.

=> No, you're spending too much time in multi6 ;)
Redundancy is one important aim of multihoming.
Redundancy is _the_ aim of multihoming for fixed
sites. But multihoming is also a fact for mobile 
nodes/networks because of the availability of different
access technologies that nodes can connect to. 
The variety of these links offer several different 
services that nodes should utilise. It's quite
a different scenario from enterprise multihoming.

 > >  > So, in brief, if i understand correctly, this configuration
 > >  > poses the full
 > >  > multihoming problem in a configuration that didn't suffered
 > >  > it before.
 > >
 > > => I'm not sure what you mean by "didn't suffer it before"?
 > 
 > I mean that the multihoming problem occurs when a site has 
 > multiple exterior
 > connections and not when an interior subnet has multiple 
 > routers connecting
 > to the rest of the local site.

=> True today. However, at the same time, IPv6 specs
assume that where multiple DRs on the same link exist, 
the MN can choose either DR without associating the 
prefix advertised by that router with its source address.
This is probably because of today's scenarios that you
describe. But in scenarios where the DRs are not 
connected to the same site, this assumption does not 
hold. This is something that could happen with nemo.
In a sense nemo could look like a broken network
if you follow today's specs. 

But of course the problem is not specific to nemo, 
we've just seen it because of nemo provides the 
only realistic scenarios that we can use today. 

 > It is basically related to how far you can inject routing information
 > related to your subnetwork. In multihoming you are assuming 
 > that you can
 > inject routing information in your site, but you cannot 
 > inject it in your
 > isps. If you adopt this restriction that a HA only forwards 
 > packets to one
 > of the prefixes, you are basically partitioning the scope of 
 > the intra site
 > routing information.

=> I understand wht you're saying, but the problem is
that one of the MRs could move away and become separated
from the other MR/rest of the network. This is something
you don't see happening today (unless someone walks 
off with a router on a trolley ;) ). If this happens,
you can't keep sending traffic addressed to the same prefix to
both MRs because you don't know which hosts are connected
to which MRs. 

For instance, if I have two MRs, a phone and a PDA that
I normally carry with me and there are a couple of other
MNNs connected to them. If I leave my PDA at home one day
with another device and take my phone and laptop with
me to work, the HA can't simply forward my laptop traffic
to the PDA because it's not connected to it! 

 > In brief, when the nemo has two different home networks with 
 > different
 > prefixes, the problem is already there, since it is just 
 > like a multihomed
 > site with two isps
 > However, if there is only one home network that has only one 
 > prefix, you are
 > artificially adding a new prefix to solve this multiple MR 
 > issue, and this
 > solution introduces all the problems related to 
 > multiaddressing to this
 > configuration that didn't have it previously.

=> There is no "previous" configuration. This is all
new. There is no established way of assigning the same
prefix to multiple MRs and managing to solve this
for cases where the network is divided. Mobility is 
the key difference between our multihoming scenarios
and multi6 thinking of multihoming. If you assign
the same prefix to all MRs, what do you do when one 
of them goes away with half the network?

 > I guess that i fully agree with your conclusion here.
 > My comments are:
 > 
 > - First: wouldn't be useful to at least some of the multihomed
 > configurations without waiting for a general multihoming 
 > solution to be
 > deployed? 

=> Yes.

 > When there are several prefixes, this probably will require 
 > some support
 > from the CN node, i.e. the general multihoming case

=> CN node? I don't follow that. 

I'm not sure if you read the very long thread with Pascal.
This discussion started by considering cases where the MRs
are relatively fixed in relation to each other. I said
that we need to either:

a. Clarify the spec to explicitly describe that the 
   "one prefix" solution is designed for those cases and
   if the network is divided then tough luck, or, 

b. Have one prefix per MR and the problems that will come
   with that are not nemo specific anyway so eventually
   will be solved. 

Obviously b) solves the same problem too. Neither a)
nor b) solve all cases today. Both a) and b) solve
the problem in question. I hope this is clearer.

 > - Second: from what i understand, all of the multihomed 
 > configurations fail
 > in some way at this stage with the current spec, is this 
 > correct? whether
 > this is because of the general multihoming problem or 
 > because MIP problems
 > or nemo specific issues, i am concluding that the only 
 > configuration that
 > works properly is the one with one MR , one prefix and one 
 > HA, is this
 > correct?

=> No. It works for only one case: The MRs will never
be separated, they always stay on the same link (e.g.
airplane).

 > If this is so, perhaps an option would be to, as i think you 
 > are suggesting,
 > explicitly state that only the 1 MR, 1 HA and 1 Prefix is 
 > expected to work
 > fine in the spec.

=> Sorry, I'm not suggesting that :( Please see 
above. Both a) and b) address the config in question.
Either a) or b) are fine with me...

Hesham

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 18:21:48 +0100

> If you can decrypt this sentence I'd be grateful ;)

It is clear, thanks.
But from the tread, i understood that you cannot use different HA with
different MR for the same prefix (can you decrypt now? :-)

I mean, i understood that the problem is that the same prefix cannot be
registered by different MR in the same or multiple HAs, is this correct?

> => No, you're spending too much time in multi6 ;)

I must admit that my view is very multi6 biased, so sorry of i miss some
important points in the nemo context.

> a different scenario from enterprise multihoming.

Yes, but this is redundancy. Basically, when you have multiple technologies,
what happens is that one technology is no longer available (which is similar
that the link goes down), and you need to use the alternative one.
The only difference that i can see is that the frequency of changes will be
higher and that the probability of using both link simultaneously will be
lower than in the fixed case. This may be interesting because perhaps you
can be able to use a strictly backup setup, that is that you only use one of
the links, you don't require support for load sharing. If you relax the load
sharing requirement, probably we can find a simpler solution.
Is there other differences that i am missing?

> if you follow today's specs.

Ok, you are considering a case with a nemo that has two different home
networks, right?

Well, i would consider this scenario as a regular multihomed network, being
the MR the border routers of the multihomed site and each of the home
networks a different ISP.
In this case, you will have in general two prefixes, and each prefix will be
routable through only one ISP.
This is the general case.
But in any case, the point is that you can avoid the complexities of this
problems in some case, and i guess that the question is if this is worth it.

> to the PDA because it's not connected to it!

Ok, i see. But in this case, when the network splits, who keeps the
addresses? I mean, the prefix is split or one of the parts keeps the prefix
and the other one just have no prefixes at all?

Ah! that is why you want multiple prefixes for the nemo, one with each MR,
right?
So when the network splits each one of them keeps its own prefix.

> of them goes away with half the network?

I think i am understanding the problem that you are considering now
thanks

> => CN node? I don't follow that.

The node outside the multihomed site

> the problem in question. I hope this is clearer.

Perfectly clear, thanks again

The problem with b is that you are not providing a solution that is working
now for the case of multiple MR. Option a at least works in some scenarios.
I would like to explore a bit more a solution like  what Pascal is
proposing, since it would work as long as the nework doesn't split.
I guess that the general solution will be based on b, but proabbly it would
be valuable to provide a solution that works now at least for a reduced set
of cases.

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 19:27:00 +0100

marcelo bagnulo wrote:
>> => I understand wht you're saying, but the problem is that one of
>> the MRs could move away and become separated from the other MR/rest
>> of the network. This is something you don't see happening today
>> (unless someone walks off with a router on a trolley ;) ). If this
>> happens, you can't keep sending traffic addressed to the same
>> prefix to both MRs because you don't know which hosts are connected
>>  to which MRs.

I think I've located the "split moving network problem".

I think that, first, moving networks in the NEMO sense have a rigid 
structure, they just don't separate components from one another, a basic 
definition.

I think second that the NEMO context has a kind of support of 
"splitting" which is in fact called "nesting" and which is supported by 
a good understanding about how it works.  A PAN can enter a train 
entering a ferry and all works; all works also whenever the PAN gets off 
the train (splitting?) and into the ferry, or when the train gets off 
and the PAN back or similar.

The only thing that does not work with "nesting" is the "cross-over"
tunnel problem; other things that don't work with the NEMO base protocol
(such as - with a certain interpretation - the "RA confliction" problem)
may exist.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 19:27:00 +0100

Alex

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 18:21:48 +0100

It is clear, thanks.

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 25 Mar 2004 15:20:00 +0900

Hi,

Below, 1 reply to marcelo, and 1 reply to all.

> Is there other differences that i am missing?

Marcelo, did you read 

Title		: Goals and Benefits of Multihoming
	Author(s)	: T. Ernst
	Filename	: draft-multihoming-generic-goals-and-benefits-00.txt
	Pages		: 16
	Date		: 2004-2-11
	
This document attempts to define the goals and benefits of
   multihoming for fixed and mobile hosts and routers. Those goals and
   benefits are illustrated with a set of real-life scenarios.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-benefits-00.txt

?

To all, all the discussions about the "split NEMO" and "multiple MR on a
NEMO-prefix" etc are very good input for
http://www.ietf.org/internet-drafts/draft-ng-nemo-multihoming-issues-03.txt,
which will become a NEMO WG document in his next revision.

I think that the issues should be discussed in that draft, not in the
NEMO Basic Support draft. And I would support, additionaly to the
multihoming problem statement draft, another draft for "multihoming
usages". 

The problem statement draft will ... state ... all the ... problems,
while the usage draft would give a priority to the scenario which are
useful.

I think we can agree on this way of working ?

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 25 Mar 2004 15:20:00 +0900

Hi,

Marcelo, did you read 

?

Thierry.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 16:59:08 +0100

Hi Thierry
> 	Filename	:
> draft-multihoming-generic-goals-and-benefits-00.txt
> 	Pages		: 16
> 	Date		: 2004-2-11
>
http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-bene
fits-00.txt

Some comments.
First, have you read RFC 3582?
This is multihoming goals document defined by multi6
It is somehow different, since it has the benefits of multihoming but also
other goals that a multihoming solution should provide.

I think that this your document provides an interesting p.o.v. since it
provides aspects more related to mobility which are not present in rfc 3582
(since it only deals with fixed networks.

A couple of specific comments.

First, i am not sure that a multi-prefixed node should be included in the
multihomed host case.
I think that a multihomed host is a host that have multiple paths to the
internet and it has a mean to select which one to use.
so if a host has multiple interfaces, it clearly has multiple paths to the
internet and it has to select one of them
In the case of a multiprefixed host, this is not clear. IMHO you are
assuming a bit too much here. Even in the case that the host is in a
multihomed site with one prefix per isp, it is not clear for now that the
source address prefix selection performed by the host will imply the
ISP/path used to route the packet.

I would prefer a more general definition of multihomed node, like a host
with multiple access to the Internet.

I don't really see the difference between load sharing and load balancing

> which will become a NEMO WG document in his next revision.

IMHO an essential part is missing in this document i.e. an identification of
the nemo specific issues of multihoming.

As i understand it, we should first identify the nemo specific issues
related with multihoming and then try to figure out if they can be addressed
using existent tools or we need new ones.

IMHO it is a complex task, but it is the relevant point here.

I think that Goals and benefits doc highlights some aspects that i am not
sure that are nemo specific, but they are more relevant in nemo
environments.

For instance, when you are using multiple routers to use different wireless
technologies, the problem is quite different than the one that multi6 is
dealing with. Basically in this case, the problem is much more local than
the general multi6 problem, since you need to use the link between the HA
and the MR that is available. In other words, the direct links between the
nemo and the home network is very unstable and are expected to "fail" (i.e.
not to be available) frequently- so if you find a solution that allows using
one link or the other it seems to be good enough. OTOH, because of the high
frequency of "outages" (non available links) it is very important that
communications are preserved when one link becomes unavailable

So, i think that this is very reasonable and probably frequent scenario for
nemo, so it seems reasonable that nemo optimizes this case. That is, the
case when the direct links between the nemo and its providers are not
available.
(Note that the multi6 solution has to deal with ISP wide failure case and IX
point wide failure case and so on)

The other point that Hesham has mentioned is that even if an alternative
link is available, perhaps this link is not good enough for preserving an
established communication. I guess that the difference here is that the
differences between the link capacities can be much more greater in nemo
than in the fixed case. so probably you need to impose more policy
enforcement mechanisms

Well, i guess that we should work on identifying this points and then decide
what to do to provide multihoming in nemo, makes sense?

Regards, marcelo

Thierry.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 16:59:08 +0100

Hi Thierry

Some comments.

Regards, marcelo

Thierry.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 17:09:01 +0100

just one more nemo specific issue in multihoming...
having to support Hesham scenario of split network seems pretty nemo
specific too
Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En nombre de marcelo
> bagnulo
> Enviado el: jueves, 25 de marzo de 2004 16:59
> Para: Thierry Ernst
> CC: [email-masked]; [email-masked]; [email-masked]
> Asunto: RE: [nemo] RE: DND test [was Assigning the same prefix to
> multiple MRs]
>
>
> Hi Thierry
> > Marcelo, did you read
> >

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 17:09:01 +0100

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 26 Mar 2004 15:57:49 +0900

On Thu, 25 Mar 2004 16:59:08 +0100

> http://www.ietf.org/internet-drafts/draft-multihoming-generic-goals-and-bene

Thanks Marcelo for the comments !  We will surely take them into account.

> First, have you read RFC 3582?

Before writing version -00, no, after, yes. 

> (since it only deals with fixed networks.

Yes, but also, the document focus on the p.o.v. of the mobile entity,
and the ability to switch between interfaces, which any node would be
doing when IPv6 will be deployed in vehicles and at home.

> ISP/path used to route the packet.

No, it doesn't necessarily, but it may. We didn't want to forget any
possibility. Also, thinking about the NEMO cases where distinct
NEMO-prefix are advertised by distinct MR in the **same** mobile
network, there is clearly a choice of path to be made.

> with multiple access to the Internet.

I agree with this definition when we want to keep things generic, but in
order to analyse the details, we needed a bit more detailed definition. 

> I don't really see the difference between load sharing and load balancing

We either ;-) so we rephrased it in version -01. Will be published soon.
 
> the nemo specific issues of multihoming.

What do you mean ? The document may not be well structured yet, but it
does analyse the nemo specific issues.  A part (a copy-paste from
draft-charbon-nemo) is clearly focusing on those specific to NEMO Basic
Support.

> using existent tools or we need new ones.

At least, this is the intent of the soon-to-be-published
draft-nemo-ietf-multihoming. So, we will try to make sure we do it
right. 

> sure that are nemo specific, but they are more relevant in nemo

Agree. That's why the bulk of people working on this draft, who are
either from MIP6 or NEMO, did publish it as draft-multihoming, and not
to any of the MIP6 or NEMO WG. 

> what to do to provide multihoming in nemo, makes sense?

That is exactly the purpose of draft-nemo-ietf-multihoming-problem-statement.
Thanks, 
Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 26 Mar 2004 15:57:49 +0900