Subject: Re: [rrg] Host changes vs. network changes

From: [email-masked]
Date: Sun, 6 Dec 2009 04:12:01 EST

Christian,
No question, network related objectives may either be accomplished by  
network- or host-based solutions.
The speed of introduction is hereby an interesting aspect.
Furthermore each way has its pros and cons.
Example: Handling of network congestions. Host-based: The sender can slow  
down the transmission rate (i.e. the service becomes worse). And host-based  
Multihoming is not a big help unless the  ingress router
of the preferred "home" is part of the congested area.
Whereas a network-based solution could detour the congested area (given  
that there is a smarter routing technology as of today).
 
Heiner

In einer eMail vom 06.12.2009 07:07:50 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Dec  1, 2009, Noel Chiappa wrote:

> When it comes to preferring  network-based or host-based solutions, when
> considering  _architectural_ factors, I actually prefer the latter
> (because I want  to move functionality out of the network, to maximize
> long-term  flexibility). However, _engineering_ factors (e.g. the
> difficulty of  changing hosts) has long led me to conclude that _initial_
> deployment  has to be network-based.

We often take it that host changes are harder  than network changes.  But
is this assumption actually valid?   There is, in fact, substantial
evidence that it is not.  Consider IP  version 6, which was deployed in
operating systems well before operators  deployed it in their networks.

Also from an economic standpoint, host  changes appear easier than
network changes:  Given the small number of  operating systems used by
the majority of hosts, and given the highly  automated methods to update
these operating systems, changes to one of the  main operating systems
quickly affect a large number of hosts, hence at a  small cost per host.
Network upgrades are slower and more  expensive.

Furthermore, for the same reason that network operators  would tend to
defer changes, operating system vendors may be eager to adopt  them. This
happens when the change must be bilateral to yield a benefit --  as is
the case with multi-homing support, which we are discussing  here.
Network operators gain no immediate benefit by adopting a  network-based
multi-homing mechanism early on, because the remote part of  the
mechanism does not exist initially.  Operating system vendors, on  the
contrary, can distinguish their product from competition based on  the
new multi-homing support, as the multi-homing support  improves
communications between their operating system relative to the  operating
systems without multi-homing support.

Thus, in my personal  opinion, host-based multi-homing support will have 
a faster impact than  any corresponding network-based support.

-  Christian

_______________________________________________
rrg  mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked]
Date: Tue, 8 Dec 2009 03:20:42 EST

In einer eMail vom 06.12.2009 21:31:09 Westeuropäische Normalzeit schreibt  
[email-masked]:

Personally, I wouldn't expect something called "routing  research
group" to propose a strategy based 100% on host changes and 0%  on
changes to the routing system. 
...unless on April fool's day  :-)

But we  could conceivably propose
something based on changes to both, and that  would surely be
a big mistake.

I cannot catch what you hereby mean. Brian, can you explain ?
 
Heiner

Brian

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 8 Dec 2009 16:58:50 -0500 (EST)

> From: Sam Hartman <[email-masked]>

    > I'm talking about the map reply record in a map request
    > ...
    > My personal opinion is that you can only use that record to establish a
    > new reverse mapping entry when it does travel the mapping system and
    > only if the mapping system is changed to modify it.

Well, this is a complex topic. E.g. if it is signed in some way, you could in
fact rely on it. You can also use it in a 'temporary' way while you look up
the mapping authoritatively. Etc, etc.

	Noel

---

From: [email-masked]
Date: Thu, 10 Dec 2009 06:17:19 EST

Host-based versus network-based: Could it be that this topic stems purely  
from "shim6-multihoming" versus "lack-of-network-based multihoming" ? Imho: 
Both  hosts and network nodes should be able to trigger a change of path.
 
I believe "host-versus-network based" - discussions should also deal  with 
a topological network view where hosts are as well nodes as are  routers. I 
wouldn't be afraid of it - not wrt scalability.
 
Quote from ALayeredMappingSystem.pdf, taken from the  LISP-list :
"It is unimaginable that an EID is individually allocated to one user. As a 
 result, mapping nodes can store the EID prefix-to-RLOC mapping once an 
item,  which will greatly reduce the scale of mapping storage."
 
Why is this unimaginable? Even the writer of this statement hereby  
demonstrates that he can imagine this.
I guess he worries about the update churn if  mappings between  individual 
EIDs and RLOCs are to be disseminated.
However, by utilizing an existing routable RLOC-location information, no  
dissemination is required at all.
DNS and others may map the user name to IPv4 + geogr.coordinates  (RFC1712) 
as of the last point of routing. The geographical  coordinates are a given 
"third instrument". If both the  host as well as  the router complies with 
it, then routing to the egress-(DFZ?)-node can be  done without churnfull 
mappings and without looking looking at the  dest.IP-address.
 
In some way really all solutions are hierarchical. Yes, including the  
present pure-prefix-building mechanism.
I think a more profound analysis of  hierarchical routing  wouldn't be 
inappropriate. E.g. the mentioned .pdf is pretty fond of 2  hierarchical levels. 
Why just 2 ? Why not more than 2 ?
As you know, myself, I am in favor of 1 (flat) level, i.e. flat topology,  
properly sparsed due to some hierarchical process.
 
Heiner