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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 09:57:45 -0000

>  > > => And what happens when the test doesn't work? Which
>  > > MR do packets get tunnelled to?
>  > > Of course there is no such interaction defined today
>  > > between HAs.
>  >
>  > A type above, I meant "The idea for 'DND' is for HA2 to test the
>  > connectivity to MR2 via MR1".
>  > The test is done prior to accepting MR2's binding. If the
>  > test does not
>  > work, MR2 registration fails. Like DAD.
> 
> => Right so MR2 and the network behind it become
> unreachable because MR1 is possible down! That's not
> good.
If the test works, the registration is accepted and you get the
redundancy you want. 
If MR1 is down, the registration for MR1 was cleaned up so the test is
not even run for MR2.
If that's your point, I do agree that there's a window if MR2 binds just
at the time MR1 dies and before the BCE for MR1 is cleaned up. There's
also a risk of collision like MR1 and MR2 startup at the same time (I
think that that one is a bit more realistic, like you start the
entertainment power in a train or a plane).

It's possible to make the test a bit more complex if the list finds it
worthwhile. HA2 pings MR1 first and then pings MR2 via MR1. If MR1 does
not answer, then accept the registration for MR2. IF MR1 answers but MR2
does not, reject the registration. 

It's also possible to run the test in runtime to check the active
registrations and alert the net admin if something's wrong. The test can
even be run by net admin using existing probes, if they care to do so.

Anyway DND is just a check on whether the net admin did their job
correctly, knowing that since the routers are mobile, there's a slightly
higher risk that something has moved overtime. The test was not never
deemed MANDATORY.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 09:57:45 -0000

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 06:14:01 -0500

> at the time MR1 dies and before the BCE for MR1 is cleaned 
 > up. 

=> Thanks you!

   There's
 > entertainment power in a train or a plane).

=> Exactly. And we're only just discussing this on email.
I'd imagine that there is a few more cases than that.

 > does not, reject the registration. 

=> I didn't intend to try to design a solution right now,
I was trying to show that there are several problems that
are not addressed in this case.

Thanks,
Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 06:14:01 -0500

=> Thanks you!

   There's

Thanks,
Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 12:51:49 -0000

> -----Original Message-----
> From: Soliman Hesham [mailto:[email-masked]]
> Sent: jeudi 18 mars 2004 12:14
> To: Pascal Thubert (pthubert); IETF NEMO WG
> Subject: RE: DND test [was Assigning the same prefix to multiple MRs]
> 
> 
> 
Agreed:
  The test was not designed yet. The requirement for the test is still
not agreed upon. So if this thread ends up anywhere, maybe it's to an
answer to that question: Is there a need for a Duplicate Network
Detection test that would check that when a prefix is registered twice,
you end up on the same link for both registrations?

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 08:03:45 -0500

> you end up on the same link for both registrations?

=> Hmmm, interesting question. However, I think we're
skipping a few steps in attempting to answer this question.
Your question is assuming that the preferred solution for 
a multihome monet (sorry I just don't thing nemo makes english
sense in this sentence) is to assign the same MNP to
all MRs. Given this assumption, it's natural to ask the
question above. 

On the other hand, if we ask: What is the best interim 
step for multihoming in nemo, we might end up with
a different solution and consequently a different set of 
questions. I preferred to ask the latter question than
the first. 

Personally, I think it's a lot cleaner to have one prefix
per MR and somehow solve the ingress filtering problem.
This is not so difficult in the case where the 2 MRs
belong to the same home domain/link. For instance, an 
ISP might not filter (in the MR's HA) on any of the 
prefixes that are assigned to its domain. So basically
it forwards any packet coming from any prefix derived
from ISP_PREFIX::/26. This would solve the simple multihoming
case where 2 MRs belong to the same home admin domain.
I think this will solve the problem with the scenarios 
that you mention, i.e. plane, train, bus ...etc.

Do you think this will work? This requires hardly any
changes to the spec. We can clearly do without changing
anything, except for mentioning that 2 MRs do not share 
the same prefix. I misstated that before to say 1 prefix
per MR, when what I really meant was two MRs do not share
the same prefix.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 10:13:37 -0500

> There is a draft draft-ng-nemo-multihoming-issues-03 about multihomed
 > NEMO pb statement. During the Seoul meeting, we all agreed on the
 > scenarios described in the slide. And two of scenarios are 
 > actually (N
 > MRs, 1 HA, and 1 Prefix) and (N MRs, N HA, and 1 Prefix).  I want to
 > keep the above two scenarios.  It is too restrict to remove one of
 > scenario at this time.

=> That's fine, so keep it in the draft. I assume 
a solution will come up to solve this case. But that
doesn't mean that we leave it open in the spec.

 > 
 > I don't know whether ISP wants the below configuration for ingress
 > filtering.  How does each HA know which prefixes are assigned to a
 > mobile network(i.e. two MRs in your case)? 

=> I don't see any problem here. Here is a simplified address
plan for a small fictitious ISP:
  ISP acquires PREFIX::/26
  ISP allocates prefixes from SUB-PREFIX::/48 to MRs
  Now there are two options: 
  A. Any prefix derived from SUB-PREFIX::/48 is allowed
     by any HA, or, 
  B. There is a specific entry in the HA's ACL for those 
     special MRs on trains busses...etc that allows this. 

Both can work. There are other factors to consider when building
a system, e.g. whether access control is done by MRs ...etc,
which will affect which choice you make. But none of this 
affects the current solution or the protocol. This will
also work when the network is divided between the MRs.
The point is, we can't assume a restrictive solution and
underspecify it without careful cautions. Either we solve
it properly or use existing practices to solve it in the 
same way it's done today.

 > Do you assume using prefix table?  
 > ISP can not stop a malicious MNN sending packets with a wrong prefix
 > which is within ISP-prefix. The example scenario is that a mobile
 > network has ISP_PREFIX-A,-B, but MNN send DoS packet with the source
 > address of ISP_PREFIX-C.

=> See above.

 > Even we remove the case where 2 MRs share the same mobile network
 > prefix, we still need to confirm whether there is duplicated MR for
 > the prefix or not, like MIP6 has DAD mechanism for HoA. 

=> But that can be addressed with the current spec, i.e.
the prefix table.

   It 
 > is worth to
 > clear this part, but I want to keep multihoming scenarios open.

=> Me too. But there is a difference between open an 
ambiguous. In a standards doc I think we need to be clear.
This doesn't mean we have to solve everything, but we
have to clearly state what works and what doesn't, and why.

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 15:22:24 -0000

> Do you think this will work?

Well, here's one problem that I see:

MIPv6 has the following (p100) " the home agent MUST verify that the
Source
      Address in the tunnel IP header is the mobile node's primary
      care-of address.  "

Our implementation of that text is (high level, there's more to it):
 
1) take source of inner packet
2) find BCE for source. If not found drop packet
3) check primary care of in BCE against tunnel source. If equal
decapsulate else drop.

This compares to Nemo (P27) 
	"The Home Agent has to verify that packets received through the
   bi-directional tunnel belong to the mobile network. (...) The source
address
   of the inner IPv6 header MUST be a topologically correct address with
   respect to the IPv6 prefixes used in the mobile network."

The topological correctness normally means that packets to the source of
the inner packets would be routed via MRHA the tunnel. This is important
because it's one way to find the BCE to perform rge mandated checkings
-Alternate would be to index the BCE by CareOf and hope that there's a
single registration for a given CareOf, which is not guaranteed while
generally true be it to make SA determination simpler-. Anyway, our
current implementation is like:

1) take source of inner packet. 
2) resolve via_gateway (should be MR Home Address) by reverse lookup in
routing table
	(there can be more than one IPv6 adjacency)
3) find BCE for via_gateway(s). If none found drop packet
4) check primary care of in BCE against tunnel source. 
	If equal for at least one adjacency decapsulate else drop.

There is no Home Address Option with the tunnel... You see that if the
source of the inner packet can be anything in a /26, it's not only the
topological correctness that can not be checked properly anymore, it's
finding the BCE in the first place that becomes a problem and you have
to fall back to CoA indexing. 

> per MR, when what I really meant was two MRs do not share
Sorry, I disagree, and I would appreciate other advices on this.

My take is that we should not forbid something to everybody just because
some people might do it wrong - if they fail to apply what is
commonplace for fixed network, i.e. subnets are generally not ubiquitous
-. 

If it's done wrong, it's a config issue that can be found and fixed. If
it's done right, you get the redundancy you want, so there's a real
benefit that is guaranteed for all LFNs with no change in their stack.

Hopefully I made my position clear and so did you. Let's see if someone
else is willing to give his own view?

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 15:22:24 -0000

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 10:13:37 -0500

=> See above.

   It 

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 10:41:29 -0500

> 3) check primary care of in BCE against tunnel source. If equal

=> ok.

 > because it's one way to find the BCE to perform rge mandated 

=> Right, and this is where you have a range to play with.
You could either have a specific entry for that MR, or allow
a larger range of prefixes into the network (e.g. if the MR
on the train or plane does access control)

 > generally true be it to make SA determination simpler-. 

=> Right, so there should only be one CoA. But I agree that
this might add some complexity to the process of accepting
the BU from the MR in the first place (need to make sure
that the MR is not stealing another MR's CoA). However, 
in MIPv6 the assumption was made that there is no need for
a CoA test when sending a BU to the HA. Whether this is 
right or not, since nemo is based on MIPv6 we can follow
the same assumption? Basically any vulnerability would
apply to MIPv6 anyway so I wonder if we need to make nemo
more secure than MIPv6.

 > 	If equal for at least one adjacency decapsulate else drop.

=> Ok.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 10:41:29 -0500

=> ok.

=> Ok.

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 16:08:15 -0000

> apply to MIPv6 anyway so I wonder if we need to make nemo
You know, the problem is when detunnelling a packet. At that time, the
home address is not the source of the packet like in MIP6. MIPv6 does
not mandate that the BCE be indexed by CareOf and it's not needed in
terms of implementation, since we have the home address in the packet
anyway.

Today Nemo does not make any assumption on whether the CareOf is used to
index the BCE, either. But if the reverse lookup of the inner source can
not be used, now you are making that assumption. I see the cost, but
fail to see the value?

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 18 Mar 2004 16:08:15 -0000

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 21:12:30 -0500

> not be used, now you are making that assumption. I see the cost,

=> Yes that's the assumption for this scenario to work.
What is the cost? 

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 21:12:30 -0500

Hesham

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 22 Mar 2004 07:54:41 -0000

> Pascal Thubert (pthubert) wrote:
> > Agreed:
> Good question. Today, I can manually enter two routing table entries
> towards the same prefix but through different next-hops. Is there a
need
> for the system to check when a prefix is registered twice and warn me
I
> did so, or ban me from doing so?
> 
Agreed again :)

I'm still unsure whether I missed something but my summary of all this
discussion is that Nemo basic support inherits the current capabilities
and limitations of the existing technology that it derives from. It's
neither better nor worse. Nemo is an hybrid technology, half L2 centric
as MIP and half L3 since routes are discovered an installed.

Yet, since the routers are mobile, it may happen that for some reasons,
router pairs that are expected and configured to share an ingress link
and an ingress prefix actually split over time. It may be helpful to
provide an optional test with Nemo to help discover such a situation.
Note that existing management tooling can also be used, so it's all a
matter of having the test automated, built in the protocol, versus
leaving it externalized.

An analogy is whether it is helpful to detect that a Home Address is
duplicated in MIP, which is a configuration error for most cases that I
can see as of today, and which, as was pointed out in the thread with
Hesham, is only partially done, depending on whether the duplication
affects the SAs and whether the duplicated MNs bind remotely to a same
HA (in which case the protocol fails to detect the problem) or not.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 22 Mar 2004 07:54:41 -0000

need
I
Agreed again :)

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 22 Mar 2004 08:01:18 -0000

> => Yes that's the assumption for this scenario to work.

Broken ingress filtering, CaO indexing (which I suspect yields a number
of problematic race conditions), broken existing implementations...

I believe the draft is properly balanced for that matter. I personally
would have left the text that said that Nemo does not bar multihoming
(amongst other things) but there's clearly no protocol action designed
to prevent it and I'm happy with that.

I'm very positive on your suggestion to document the potential caveats
related to multihoming. This could happen in the problem statement or in
a later usage draft, either one I guess.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 22 Mar 2004 08:01:18 -0000

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 22 Mar 2004 03:32:45 -0500

> Broken ingress filtering, 

=> I've showed two ways of doing ingress filtering. I don't
think that was broken. I think the current solution is 
more broken actually since it doesn't clearly state the 
applicability of the "anycast prefix".

   CaO indexing (which I suspect 
 > yields a number
 > of problematic race conditions), 

=> I don't think so. You get the same performance as MIPv6,
which is your base anyway. 

  broken existing implementations...

=> That shouldn't be a reason for a draft...

 > 
 > I believe the draft is properly balanced for that matter. 

=> I think it's buggy.

   I 
 > personally

=> I think the draft needs to clearly state the cases where
the current solution will not work.

 > related to multihoming. 

=> Great. So why are you against putting this in the draft?

   This could happen in the problem 
 > statement or in

=> This would be ok if the draft didn't already include
a semi solution for the problem. But since it does, 
I think this should be addressed in the current draft.

I've already said all I have on this issue, so I think
it's up to the WG to decide how this should be addressed.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 22 Mar 2004 03:32:45 -0500

=> I think it's buggy.

   I 

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 24 Mar 2004 07:12:33 -0500

Hi Marcelo, 

 > If i understand the scenario that you are proposing, there are more
 > problems, not only ingress filtering.

=> First of all, I want to be clear on what I'm proposing.
I suggested two options:
  a. Clean up the spec by either explicitly stating when the 
     current solution fails, or, 
  b. Provide another option like the one below. 

As I stated in an earlier response to Thierry, my proposal
has its own problems, however, I don't think any of 
those problems are nemo-specific.

 > 
 > Let me see if i get this right:
 > The scenario that you are proposing would be the following
 > 
 >              P::/26
 >       ----|-------------- Home network
 >           |
 >         +---+
 >         |HA |
 >         +---+
 >   route  |  \ route to
 >   P:P1:: |   \ P:P2::
 >          |    \
 >       +---+   +---+
 >       |MR1|   |MR2|
 >       +---+   +---+
 >   P:P1::|        |P:P2::
 >   ---------------------- Mobile network
 > 
 > So, each of the MR of the NEMO has one prefix assigned and 
 > announces it in
 > the NEMO.
 > The HA has one prefix registered per each MR, so this means 
 > that it forwards
 > packets addressed to P:P1:: only through MR1 and  the HA 
 > forwards packets
 > addressed to P:P2:: only through MR2
 > Is this the configuration that you are proposing?

=> Correct.

 > 
 > If this is so, this presents all the problems of 
 > multiaddressing, i guess.

=> Yes.

 > In order to be reachable through both MR, the hosts within 
 > the NEMO will
 > have to configure two addresses, one with P:P1:: and another 
 > one with P:P2.
 > This is so because if they only configure an address with 
 > P:P1:: they will
 > be only be reachable through MR1, since the HA only has MR1 
 > registered for
 > this prefix.

=> Correct. This also brings up another issue: are 
we considering the case where hosts want to have a stable 
address in the DNS ? This is another interesting restriction
and I'm not sure that this is currently addressed.

 > 
 > Well this multiaddressing configuration presents complex 
 > challenges, for
 > instance how do you preserve established communications when 
 > the MR that you
 > were using fails.

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

 > Also, in case that one of the MR is down, you need a smart 
 > way to select the
 > source address that is working on the reverse path, which imposes new
 > mechanisms in the MNN

=> If redundancy is a requirement, yes. But I don't
think this would solve the problem because we still
need to deal with the HA.

 > 
 > 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"?
These problems apply already, some apply to IPv6 in general, 
and others to using MIPv6 through an HA, which is what this 
spec is doing.
In the configuration that Pascal proposed, redundancy is 
achievable, but there are other problems. 

 > 
 > I am sure that i don't fully grasp the complete problem of 
 > detecting a
 > duplicate prefix in the same HA that you are discussing, so 
 > i cannot make
 > any consideration about the solution for this problem, but 
 > the proposed
 > configuration really presents complex issues.
 > Of course, once that multi6 develops a solution for the 
 > general case, it
 > should also cover this case too.

=> I think that either way a generic solution for multihoming
is needed to address both cases, i.e. when two DRs are advertising
the same prefixes or different ones. Both scenarios are real
and affect multihomed hosts and mobile networks. 

What we're doing here is band aiding the "easier" case
and the question is how we do that. But whatever solution
you pick (out of the ones discussed on this thread) falls
short in many multihoming cases. 

Hesham

 > Regards, marcelo

---

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

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

 > 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: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 24 Mar 2004 17:52:55 -0000

> From: marcelo bagnulo [mailto:[email-masked]]
> Sent: mercredi 24 mars 2004 18:23
> To: Alexandru Petrescu
> Cc: Soliman Hesham; Pascal Thubert (pthubert); IETF NEMO WG
> Subject: RE: [nemo] RE: DND test [was Assigning the same prefix to
multiple MRs]
> 
> > > If this is so, this presents all the problems of multiaddressing,
i
> > > guess. In order to be reachable through both MR, the hosts within
the
> > > NEMO will have to configure two addresses, one with P:P1:: and
> > > another one with P:P2. This is so because if they only configure
an
> > > address with P:P1:: they will be only be reachable through MR1,
since
> > > the HA only has MR1 registered for this prefix.
> >
> > This is, as you say, a problem of having a host to confnigure two
> > addresses; it is not a NEMO problem.
> 
> Yes, but if we impose that when there are multiple MR you need to have
> multiple prefixes one per MR, you are imposing all the problems of
> multiaddressing in a configuration that perhaps don't require multiple
> addresses.
> 
> My point is that if we can avoid multiaddressing, we are avoiding lots
of
> complex problems, so perhpas we shoudl try to do it at least in some
of the
> scenarios.
> Makes sense?

Sure does to me :) Let's not avoid the case where the MRs do not split.
If they split, who says which device (LFN) stays with which router, and
which 'side' should win the prefix from the HA standpoint. So I agree
that case is broken. But if they do not, there's an opportunity for high
availability that we should not bar, either.

Note that a LFN host may keep using an address for quite some time,
'permanently' if it's a DNS address, thus the value of IP mobility. So
if the LFN does not move with the MR that owns the prefix, the
communication is broken. Thus the assumption is that a LFN sticks to its
MR. The same way, 2 MRs serving the same prefix for redundancy reasons
stick together. Otherwise it's broken. 

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 24 Mar 2004 17:52:55 -0000

multiple MRs]
i
the
an
since
of
of the

Pascal

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 24 Mar 2004 21:24:00 -0500

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

=> The draft is vague on this. Pascal said yes you can
and I was saying this has problems that are not described.

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

=> There are other differences. You might want to use 
more than one access simultaneously by the same
node. Not only for redundancy but because different
applications prefer different access technologies.
I don't see a WLAN access as providing complete
redundancy to a cellular access since VoIP is not 
really feasible on WLAN for example. So it's a 
bit different to having 2 E1s which are providing 
1+1 redundancy.

 > The node outside the multihomed site

=> I don't think any special support is needed in the 
CN. For the multiaddress case you need special support in
MNNs. But if both MRs are willing to reverse tunnel
for all addresses (i.e. the same home ISP) then 
the multi prefix case works as well as the single prefix
case. This is the scenario being discussed.

 > The problem with b is that you are not providing a solution 
 > that is working
 > now for the case of multiple MR. 

=> Not really, b) works for the scenario where both MRs
have the same home ISP, which is the assumption behind a)
anyway. You can't have the same prefix when both MRs are 
connected to different home ISPs.

  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.

=> Like I said, either case can work, my problem is that 
the current spec is vague on either case.

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 24 Mar 2004 21:24:00 -0500

Hesham