<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=ISO-8859-1">
<META content="MSHTML 6.00.6000.16735" name=GENERATOR></HEAD>
<BODY id=role_body style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial"
bottomMargin=7 leftMargin=7 topMargin=7 rightMargin=7><FONT id=role_document
face=Arial color=#000000 size=2>
<DIV>In einer eMail vom 11.11.2008 21:11:03 Westeuropäische Normalzeit schreibt
christian.vogt@ericsson.com:</DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000
size=2>Heiner,<BR><BR>your proposal is interesting. But I think it is
orthogonal to the new<BR>network protocol stack proposal that I am
making. </FONT></BLOCKQUOTE>
<DIV>Agreed. Orthogonal means, they do not substitute each other. And also :
they do not harm each other.</DIV>
<DIV> </DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000 size=2>I don't
see how one<BR>would enable or improve the other.</FONT></BLOCKQUOTE>
<DIV>Enable: My concept (TARA) wouldn't have any problem with any form of
receiver's identification.</DIV>
<DIV>Improving each other's topic: No. Because they are indeed orthogonal.</DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000
size=2><BR><BR>In fact, whereas your proposal changes the routing system, my
proposal<BR>is fundamentally host-based. The way in which my proposal
will benefit<BR>the routing system is instead:<BR><BR>- by making the use of
provider-allocated addressing in edge networks<BR> more
acceptable, and<BR><BR>- by making (unilateral) IP address translation a more
acceptable<BR> solution for provider-independent addressing in
edge networks<BR> without compromising global routing
scalability.<BR><BR>The reason for (1) is that renumbering becomes simpler
with the new<BR>network protocol stack since it no longer affects
applications/host.</FONT></BLOCKQUOTE>
<DIV>With TARA there is no reason at all to care for prefix building capability
or for renumbering, nor is there any need for caching.</DIV>
<DIV>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.</DIV>
<DIV>I have heard that there are already LISP implementations but I can hardly
imagine that <A href="http://www.cisco.com">www.cisco.com</A> is already off the
BGP table. </DIV>
<DIV>(I could argue more but this is not your topic :-)</DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000
size=2>The<BR>reason for (2) is that the new network protocol stack makes
applications<BR>immune to unilateral IP address translation.</FONT></BLOCKQUOTE>
<DIV>I can imagine that a cleaner split between the layers is an objective by
which the upper layers might benefit.</DIV>
<DIV>This may be an additional problem, and I am sure that TARA would be helpful
here too.</DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Heiner</DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000
size=2><BR><BR>- Christian<BR><BR><BR><BR>On Nov 11, 2008,
HeinerHummel@aol.com wrote:<BR><BR>>> are you thinking of forwarding
packets based on the destination<BR>>> hostname while the packet is
within an edge network? That could, of<BR>>> course, be an
extension to the proposal I am making.<BR>><BR>><BR>> Yes. My saying
since 45 is of course that there is no reason to route<BR>> based on
worldwide user reachability information dissemination,<BR>> i.e. that this
scalability problem can be eliminated completely.<BR>> Provided: Each DFZ
router has a consistent view of a well-sparsed<BR>> internet topology,
while knowing the geo-locations of all viewed <BR>> nodes,<BR>>
and the geolocation related to the IP packets' destination which
<BR>> should<BR>> be the geolocation of that router toward which
forwarding shall/ <BR>> could be<BR>> done without looking at the
destination IP address.<BR>><BR>> That router is - normally - a router
of the service provider at the<BR>> service provider's site. Behind that
point routing could either be <BR>> done<BR>> traditionally, i.e.
based on the destination IPv4 resp. IPv6 address <BR>> or<BR>>
based on something else like: e.g. host name or E.164 without DNS<BR>>
mapping, or... or...or... And of course also based on geolocation<BR>>
information of an intra-domain edge network.<BR>><BR>>> The
proposal<BR>>> right now, however, uses IP addresses for routing; the
hostnames are<BR>>> included only in the first packets of a connection
in order to sync<BR>>> the two peers.<BR>><BR>> I
know.<BR>><BR>> Heiner<BR><BR><BR><BR><BR></FONT></BLOCKQUOTE>
<DIV></DIV>
<DIV> </DIV></FONT></BODY></HTML>