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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 15:46:35 +0100

>      current solution fails, or, 

Do you know when the current solution fails?  Maybe we can make it an 
issue and track it.  I don't think that the scenario depicted by Marcelo 
fails in any NEMO way; it might fail in another multi-homing way, but 
not a NEMO way.

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

Yes.

>  > multiaddressing, i guess.

Yes.

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

I think that hosts that have stable addresses in the DNS are LFN's and 
probably MH's but in no case MR's.  So I would say we don't necessarily 
want MR's to have a unique single address in the DNS because a router 
usually does not host e2e applications of the sort a human user would 
use (like web browsing, or like being reachable).

So the issue mentioned would be a Mobile IPv6 for MH issue, or a multi6 
for hosts(?) issue, no?

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

Right, when HA fails there is no way to preserve reachability at
permanent home address and this is again, not a NEMO problem since NEMO
assumes there's always an HA (from a set of HA's on the hom elink) and
since NEMO reqs/goals say NEMO tries to preserve reachability at a
permanent HoAddress.

Providing redundant HA's, as you say, can be done in many different
ways, like HMIPv6, or like HAHA, or like other micro-mobility protocols,
and I think none of those is a competitor to NEMO base support, they
_may_ base upon it, no?

Removing the HA from the conceptual picture of NEMO is removing Mobile 
IPv6 altogether; but seems that the goal of multi-homing activities in 
NEMO is just to make sure that NEMO does not prohibit mutli-homing; I 
don't think that multi-homed moving networks can be used with anything 
else than Mobile IP, no?

Do you think a logic like:
"NEMO does not support multi-homing, so get rid of Mobile IPv6" is valid?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 15:46:35 +0100

Yes.

Yes.

Alex

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 16:51:03 +0100

> HA) to preserve communication in a timely manner.

So i guess that current spec doesn't provides support for multiple HAs, is
this correct?

> need to deal with the HA.

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

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

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.

> short in many multihoming cases.

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? At least this may be useful because the deployment of a general
multihoming solution will take some time, i guess. For instance, all the
cases where there is only one prefix seems to me that can be solved locally
i.e. within the scope of the home network and nemo. I think that we could
try to solve all this cases within nemo, and to provide local solutions for
this. Perhaps not in the basic spec, though
When there are several prefixes, this probably will require some support
from the CN node, i.e. the general multihoming case

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

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 16:51:03 +0100

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 17:22:09 +0100

marcelo bagnulo wrote:
> i am concluding that the only configuration that works properly is 
> the one with one MR , one prefix and one HA, is this correct?

This is not correct.  That 1-1-1 configuration is not the _only_
configuration that works properly with the NEMO base protocol.

With NEMO base protocol it is also possible to have 1 MR that has two
home addresses on the ingress interface and two different moving network
prefixes towards a unique ingress interface.

It is also possible to have two home addresses on two different egress
interfaces and two MNP's on a unique ingress interface.

It is also possible to have two home addresses on two different egress
interfaces and two MNP's on two different ingress interfaces.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 17:22:09 +0100

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 18:54:06 +0100

Small correction "ingress" to "egress", see one-liner below

Alexandru Petrescu wrote:

> marcelo bagnulo wrote:
> 
>> i am concluding that the only configuration that works properly is the 
>> one with one MR , one prefix and one HA, is this correct?
> 
> 
                         ^ sorry I meant egress

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 18:54:06 +0100

^ sorry I meant egress