Subject: [nemo] RE: multiple prefixes, multihoming and spliting

From: "Soliman Hesham" <[email-masked]>
Date: Sun, 28 Mar 2004 21:36:09 -0500

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

=> That's why I said I need to look into it to see
how the _HoA_ config will work. I think you've 
considered the case of having multiple HoAs to provide
multihoming support for the home site. I'm talking about
switching CoAs. This is a different approach. I'm _not_
concerned with multihoming for the _home_site_.  

Like I said, I'll put it all in a draft. It's hard
to explain it all on email.

 > >
 > > - 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.
 > 
 > Well, this is one step more that i was considering. I was 
 > mainly focusing in
 > fault tolerance, you are also including policing. 

=> This is not policing, it's a matter of providing
the right information for hosts to do policy-based
src address selection. 

   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.

=> I's impossible to do what I'm trying to do by the 
administrator. It has to be done by the end host.

 > > - The fact that adding this stuff will take time is
 > > in no way discrediting the approach.
 > 
 > Agreed, but adding stuff usually increases the complexity of 
 > the solution

=> Sure, I still think it's inevitable though.
This might change after a deep analysis.

 > > 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.
 > 
 > Agree, but it depends on which stuff are waiting for. Some 
 > of the stuff may
 > require a full multihoming solution.

=> Not the default router - host interface, this is needed
in all cases independently of the rehoming protocol.

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

=> Ok, if we want to look at the complete picture
we should also consider the cases where the 2 MRs are
not fixed in relation to each other.

 > > => I'm going to consider both approaches and see
 > > what ends up being more scalable in the long term.
 > 
 > Fine. I am willing to provide my opinion if you find it usefull

=> Please continue to do that.

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: Tue, 30 Mar 2004 15:14:36 +0200

[Trim the cc list]

> concerned with multihoming for the _home_site_.

Ok.

So, the idea would be:

Recycling an old figure...

              P::/26
       ----|-------------- Home network
           |
         +---+
         |HA |
         +---+
   route  |  \ route to
   P:P1:: |   \ P:P2::
          |    \
       +---+   +---+
       |MR1|   |MR2|
       +---+   +---+
   P:P1::|        |P:P2::
   ---------------------- Mobile network

(it doesn't matter if there is only one or more HAs)

So, the nemo has as many prefixes as MR and each MR registers its own prefix
to the HA
Only one MR can register one prefix (i.e. not two different MR can register
simultaneously the same prefix)

When both MR are working, LFN can use any of the two prefixes and this will
determine the reverse path of the packets.

Now when MR1 is no longer available (or its link is no longer available),
the idea would be that MR2 registers P:P2:: on the HA so that packets are no
longer forwarded to MR1 but to MR2.

This would provide transparent ubiquity support while not requiring the
simultaneous registration of the same prefix by different HA

This would also allow that when the network splits, each MR takes its prefix
with it.

Is this what you are considering?

> the right information for hosts to do policy-based

well it is also policing. for instance i guess that the netwrok admin would
want to ba able to stop the users from using the GPRS access when a wi fi
access is available or something. I mean, especially in wireless
environments, path selection may have economical impact, so the network
admin probably wants to be able to influence in which link is used, don't
you think?

> administrator. It has to be done by the end host.

well, let's first discuss whether this is a requirement and then we can
discuss if we can do it or it is impossible

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 30 Mar 2004 15:14:36 +0200

[Trim the cc list]

Ok.

So, the idea would be:

              P::/26

Regards, marcelo