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

From: "Soliman Hesham" <[email-masked]>
Date: Tue, 30 Mar 2004 10:44:10 -0500

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

=> Actually I was thinking of having both MRs register
simultaneously. I think what you're saying is geared
towards redundancy. While this is valid, I think
that we still need to consider the case where both MRs
are registered. But anyway, this is fine as an example.

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

=> Not really, but this is possible. I was considering 
the case where both prefixes are registered simultaneously.
In this scenario the LFNs will still work fine as you 
describe. But the advantage of both being registered
is that different types of access may be available
to each MR. Do you see a show stopper when both are
registered? I'm curious why you chose to have only
one prefix registered.

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

=> There are multiple points to address here: 

- Who is the admin in your example? The MR can be 
administered by the the entity as the LFN/MNN.

- This goes back to my earlier point about whether different 
access link can really be used for complete redundancy. 
In your example, this doesn't work. The ISP doesn't 
(typically) want to run the voice traffic on a public 
access WLAN because there are no guarantees for quality. 
The choice of access must be done by the end host. 
It's quite natural that the end host will choose the 
link with better performance. 

- There may be cases where the ISP provides Wifi
access to alleviate the load on the cellular network.
But I don't really think that the use of the Wifi
access should/need be enforced. Incentives like 
cost/BW are much more likely to attract users anyway.
So the question is how we to provide the information
to end hosts to make the decision.

- At the end of the day, the ISP has no way
of being sure about the characteristics/requirements
of the application being used by the end host in all cases. 
So forcing things is not really a scalable or a 
generic way to solve the problem. 

 > > => I's impossible to do what I'm trying to do by the
 > > 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

=> My requirement is that hosts should be able to
discover and choose the type of access. See the last 
point above about why the end host must choose. 
I appreciate the fact that ISPs want to influence this
decision, but I don't think this should/could be done
at run time in a generic manner. IMO this is best 
done out of band (e.g. subscription). 

Hesham

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

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 31 Mar 2004 12:15:03 -0300

> registered? I'm curious why you chose to have only

I was considering that each router has only one access technology. So
selecting the router is equivalent to select the technology. I guess you are
considering a more general case, where MR has multiple technologies.

Let me see if i understand the motivations for having multiple prefixes:
You can bind one prefix with one technology, with one link or with one MR. I
am not really sure which is better. I guess that if you bind one prefix with
one technology, you have a simple mechanisms to let the host to select the
technology that fits the needs of its traffic and all of this per
application (or even per packet) since it the selection is contained in the
source address used.
You can bind a prefix to a link, so that even if you have multiple links of
the same technology, you can provide some support for fault tolerance by
selecting the link available through the selection of the source prefix.
You can bind a prefix to a MR, so that if the nemo splits, each MR takes it
prefix with it.

Now, depending on which of these goals you are designing for, it makes more
or less sense to register the same prefix by different MRs, i guess.

> administered by the the entity as the LFN/MNN.

I usually consider that there is a network admin, that configures and
manages MRs and links, and then there are users, who can configure its LFN
at will. So, if the network admin wishes a specific usage of the network
recourses like links, it may not be able to trust the LFN to do what is
specified. For instance, a policy like "use the expensive link only to carry
real time traffic and not for ftp" may makes sense for the network admin but
the user may think otherwise. So, it is probably good to allow the network
admin to enforce some of its policies.

> access WLAN because there are no guarantees for quality.

Ok, i see your point.
I usually define fault tolerance as sending the packets through the
available path as long one exists.
Your definition seems to be more demanding, like use the link available that
matches the QoS required.

> link with better performance.

Yes but this may be conflicting with network admin preferences.
I guess we have a tradeoff here, between empowering the users vs. empowering
the network admin.
I also think that different scenarios will require different parts to be
empowered.
I guess that there will be a need for different approaches.
the other option would be to try to find a solution that provides tools to
both of them to perform path selection, and we should decide who overrules
who.
But i am not sure such solution exists.

> to end hosts to make the decision.

Well, if you bind a prefix with a technology, the selection of the source
address performed by the host may inform the routing system which technology
it is willing to use to carry the packet.
Then what you need is a mechanism to influence the source address selection
policy
RFC 3484 policy table may be a starting point.
You probably need to extend it, in order to have more granularity, perhaps
the port numbers.
You will also need a mechanisms to automatically configure this policy
table, like a dhcp option ( i prefer it to Radv based mechanism)

> generic way to solve the problem.

In a world where users behave according to the common good, this is fine.
In a world with greedy users, this may not work so well, i am afraid.
So, again, i guess the solution depends on the environment.

> point above about why the end host must choose.

I agree with this requirement

> done out of band (e.g. subscription).

I am not talking about the ISP here but about the administrator of the nemo.

regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 31 Mar 2004 12:15:03 -0300

Ok, i see your point.

regards, marcelo