Subject: [nemo] multiple prefixes, multihoming and spliting

From: "Soliman Hesham" <[email-masked]>
Date: Sun, 28 Mar 2004 10:51:12 -0500

> > => As I stated before, I think it's cleaner to have
 > > different MNPs for MRs.
 > 
 > First of all, let's first define what is the goal of having 
 > multiple MR, or
 > put in another way, which is the goal of being multihomed.
 > 
 > Because of the nature of multihoming in NEMO, i think that 
 > the support for
 > multiple technologies is a very important goal, so i guess that a
 > multihoming solution should support this. This means that we 
 > have two MR
 > with different access technologies, so packets have to be 
 > forwarded through
 > the router that has a link available.
 > I guess that is expected that links will become available 
 > and unavailable
 > quite often when the network is moving, so it is important 
 > that established
 > connections are preserved when switching technologies (and MRs)
 > 
 > So i think that important requirements for multihoming in 
 > nemo are what some
 > can call transparent support for ubiquity.

=> Agreed.

 > 
 > Now, this is different from the fault tolerance requirement 
 > (despite what i
 > have claimed before :-), since this is very localized 
 > problem, the links
 > that can "fail" are the links between the MR and the access 
 > routers. 

=> Exactly, this is one point I wanted to clarify in
an earlier response to you.

   This
 > would allow a solution that consists in mechanisms based in 
 > the HA, or even
 > in the Home network perhaps in the visited network, but not much more

=> We can also include the MR(s) as a possibility.

 > 
 > An possibility as you mention would be to use multiple 
 > prefixes, one per MR.
 > 
 > The problem here is that one prefix is associated with a MR, 
 > so with an
 > access technology. So when this access technology is 
 > unavailable, this
 > prefix would become unavailable.

=> Right.

 > For example, suppose you have MR1 with Pref1 and MR2 with Pref2
 > There is also a LFN, that in order to be reachable through both
 > technologies, it has to configure two addresses, Pref1:LFN 
 > and Pref2:LFN
 > Suppose now that LFN has established a communication with a 
 > host in the
 > internet, Host1, using Pref1:LFN.
 > suddenly, the network moves and the technology that is using 
 > MR1 is no
 > longer available. How do you preserve the established session?
 > 
 > To do that you can:
 > Modify the external host Host1 to support multiple addresses 
 > per connection.
 > This may be part of a general multihoming solution, but this 
 > will take time
 > to be deployed

=> Well you can use existing solutions to do that: MIP.
But I need to look into it a bit deeper to see how the 
home address config will work.

 > Make some tunnels between the MR so that they forward 
 > packets belonging to
 > the other prefix, which actually you end up with both 
 > routers forwarding the
 > same prefix, which i am not sure this is so clean.

=> That wouldn't solve this problem anyway since one 
of the MRs is not connected to the Internet. What you
need to do is make sure that MR2's HA will accept MR1's
traffic. This can easily work when both HAs are in the 
same ISP's domain. 

 > 
 > There are also other problems with this multiprefixed setup, like for
 > instance how do you select the source address that is 
 > working properly for
 > initiating a communication. Probably you will need a 
 > mechanism in the LFN to
 > retry with different source addresses. This may also be part 
 > of a general
 > multihoming solution, but again may take longer to deploy.

=> It's a part of any multiaddressing solution. Let 
me comment on a couple of points here:

- If MRs are connected to different access technologies 
then we need information to be sent from those MRs to
MNNs to inform them about the implications of selecting
certain addresses. This is essentially the same problem
for multihomed hosts (note by multihomed I mean a host
with more than one interface), except that in the 
multihomed host case this information is internal. 

- Fault detection, router failure ...etc can be achieved
with ND. How timely this is depends on tuning ND information. 

- The fact that adding this stuff will take time is 
in no way discrediting the approach. Note that adding 
this information does not mean we need to wait for 
a full multihoming solution with, for example, location/identifier
split. This is not relevant for the link-local  problems
that we're addressing here. 

 > 
 > So my comment essentially is: the support for ubiquity seems 
 > an important
 > goal and that IMHO can be solved by adding some mechanisms 
 > to specific
 > devices, like the HA, and MR only.

=> This may well be the end result, but setting 
that as a goal is premature IMO. Especially when we
don't understand all the problems in this space.

 > If you adopt a multiprefix solution, a clean support will 
 > require support
 > from the external hosts. Other solutions like the tunnel 
 > based solutions,
 > are not so clean i am not so sure that are cleaner than the 
 > single prefixed
 > ones. 

=> I didn't understand the "other" solution, why is tunnelling
needed? and why is it not clean?

   Additionally, a multiprefix solution will require 
 > support from LFN.
 > 
 > So, my bet would be to try to explore a single prefixed solution that
 > provides transparent support for ubiquity and see how we can 
 > address the
 > case when it splits.

=> I'm going to consider both approaches and see 
what ends up being more scalable in the long term.
At the moment I can't see the single prefix case
as being realistic for a general multihoming solution.
Since the easy case (of MRs being fixed in relation
to each other) is solveable by either approach, 
I don't see why we should end up with a single prefix
solution for the "short" term and another solution
for the long term. 

Hesham

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by other is 
strictly prohibited.  If you are not the inteded recipient please contact
the sender and delete all copies.
========================================================

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 29 Mar 2004 02:00:50 +0200

> => We can also include the MR(s) as a possibility.

indeed

[...]

> => Well you can use existing solutions to do that: MIP.

Been there before, and i haven't been able to make it work if you use RR
check.
A detailed analysis of how i would build a multihoming support solution
using MIP can be found at: draft-bagnulo-multi6-mnm-00.txt
Basically the conclusion is that a connection can survive only 7 minutes
after the HoA is unreachable because BCE lifetime expiring. After 7 min,
the connection is down.

> traffic. This can easily work when both HAs are in the

Indeed, you need 4 tunnels (to solve both ingress filtering and
reachability)
BAsically the type of solution that i am considering is RFC 3178, RFC 2260

> multihomed host case this information is internal.

Well, this is one step more that i was considering. I was mainly focusing in
fault tolerance, you are also including policing. Policing can be done by
the hosts or by the routing system. If you do host based policing, the path
selection is performed by the host and there is harder to enforce it by the
routing system. This would be more like the multiprefix approach.
The single prefix approach, allows the routers to define and enforce
policing.
Both approaches have drawbacks and benefits, but i guess that allowing the
network administrator to enforce policy is an important benefit.

> in no way discrediting the approach.

Agreed, but adding stuff usually increases the complexity of the solution

> Note that adding

Agree, but it depends on which stuff are waiting for. Some of the stuff may
require a full multihoming solution.

> don't understand all the problems in this space.

Agree. I was just stating where would i focus my energy when addressing this
problem.

> needed?

I have in mind something like RFC 3178, RFC2260

> and why is it not clean?

You were the one who introduced the clean word :-)

No, it is just that when you start adding tunnels to a solution it starts
getting messier IMHO, You end up with MTU problems, fragmenting overhead
manual config and so on.

So, i am just saying that while is seems a clean approach to assign a prefix
to each MR, then when you start trying to provide fault tolerance support,
you need other stuff that may turn the solution a bit more messier, so we
have to look at the complete picture to compare.

> what ends up being more scalable in the long term.

Fine. I am willing to provide my opinion if you find it usefull

> as being realistic for a general multihoming solution.

After trying to solve the problems of a generic solution that requires
multiprefix i can see lots of the difficulties that this approach presents
:-)

> solution for the "short" term and another solution

Actually, i see it more like that you can solve the ubiquity problem with a
single prefix, but you need multiprefixes to support general fault
tolerance. But i guess that you will want ubiquity more often than fault
tolerance, and i see ubiquity support much more urgent than fault tolerance,
but i may be wrong.

I mean, the only reason that i can see so far that is worth all the effort
of multiaddressing is preserving routing system scalability, which is why
the generic multihoming approach requires it. Other problems that can be
solved with alternative approaches, i would look very into them before going
to multiaddressing.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 29 Mar 2004 02:00:50 +0200

indeed

[...]

Regards, marcelo