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

From: [email-masked]
Date: Tue, 11 Nov 2008 14:16:59 EST

In einer eMail vom 11.11.2008 09:51:36 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Nov  11, 2008, [email-masked] wrote:

> Imagine the following: IP  packets are forwarded down to the (egress)  
> router (to which the  destination user is somehow attached) without  
> looking at the  destination IP address ! This also means: the  
> destination  information  may be what so ever: an IPv4 address, an  
> IPv6  address, or even a USER NAME !! Wouldn't this fit to your  
>  proposal perfectly?

Heiner,

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

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

---

From: Christian Vogt <[email-masked]>
Date: Tue, 11 Nov 2008 22:10:34 +0200

Heiner,

your proposal is interesting.  But I think it is orthogonal to the new
network protocol stack proposal that I am making.  I don't see how one
would enable or improve the other.

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. The
reason for (2) is that the new network protocol stack makes applications
immune to unilateral IP address translation.

- Christian

On Nov 11, 2008, [email-masked] wrote:

> 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