[rrg] Agenda request: Presentation on new host stack architecture

[HeinerHummel at aol.com]

In einer eMail vom 11.11.2008 21:11:03 Westeuropäische Normalzeit schreibt  
christian.vogt at ericsson.com:

Heiner,

your proposal is interesting.  But I think it is  orthogonal to the new
network protocol stack proposal that I am  making. 
Agreed. Orthogonal means, they do not substitute each other. And also :  they 
do not harm each other.
 

I don't  see how one
would enable or improve the other.
Enable: My concept (TARA) wouldn't have any problem with any form of  
receiver's identification.
Improving each other's topic: No. Because they are indeed orthogonal.



In fact, whereas your proposal changes the routing system, my  proposal
is fundamentally host-based.  The way in which my proposal  will benefit
the routing system is instead:

- by making the use of  provider-allocated addressing in edge networks
more  acceptable, and

- by making (unilateral) IP address translation a more  acceptable
solution for provider-independent addressing in  edge networks
without compromising global routing  scalability.

The reason for (1) is that renumbering becomes simpler  with the new
network protocol stack since it no longer affects  applications/host.
With TARA there is no reason at all to care for prefix building capability  
or for renumbering, nor is there any need for caching.
Note, LISP promises to reduce the scalability problem. So far I haven't  seen 
a single line from when on the BGP routing table will start to shrink and  
how this is done so that at some later point in time its size is zero.
I have heard that there are already LISP implementations but I can hardly  
imagine that _www.cisco.com_ (http://www.cisco.com)  is already off the  BGP 
table. 
(I could argue more but this is not your topic :-)

The
reason for (2) is that the new network protocol stack makes  applications
immune to unilateral IP address translation.
I can imagine that a cleaner split between the layers is an objective by  
which the upper layers might benefit.
This may be an additional problem, and I am sure that TARA would be helpful  
here too.
But first of all, the scalability problem is a networking layer internal  
problem and I am afraid that the term  SPLITTING has lead the RRG  onto the wrong 
track. Instead        ADDING    l o c a t i on   is needed and is  
concurrently sufficient to get rid of the whole problem.
 
 
Heiner



- Christian



On Nov 11, 2008,  HeinerHummel at aol.com wrote:

>> are you thinking of forwarding  packets based on the destination
>> hostname while the packet is  within an edge network?  That could, of
>> course, be an  extension to the proposal I am making.
>
>
> Yes. My saying  since 45 is of course that there is no reason  to route
> based on  worldwide user reachability information dissemination,
> i.e. that this  scalability problem can be eliminated completely.
> Provided: Each DFZ  router has a consistent view of a well-sparsed
> internet topology,  while knowing the geo-locations of all viewed  
> nodes,
>  and the geolocation related to the IP packets' destination which   
> should
> be the geolocation of that router toward which  forwarding shall/ 
> could be
> done without looking at the  destination IP address.
>
> That router is - normally - a router  of the service provider at the
> service provider's site. Behind that  point routing could either be  
> done
> traditionally, i.e.  based on the destination IPv4 resp. IPv6 address  
> or
>  based on something else like: e.g. host name or E.164 without DNS
>  mapping, or... or...or... And of course also based on geolocation
>  information of an intra-domain edge network.
>
>> The  proposal
>> right now, however, uses IP addresses for routing; the  hostnames are
>> included only in the first packets of a connection  in order to sync
>> the two peers.
>
> I  know.
>
> Heiner







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.irtf.org/pipermail/rrg/attachments/20081111/3fbbfca8/attachment.htm>