[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [RRG] Re: Does every host need a FQDN name in the future?//re:[RR=



G] draft-rja-ilnp-intro-01.txt
Date: Tue, 12 Aug 2008 21:37:52
Message-ID: <07AC07D8080C132534161@kabelmail.de>
MIME-Version: 1.0
X-Priority: 3 (Normal)
Content-Type: multipart/alternative;
	boundary="----=_Next_Part_000_12082008193752.000007AC"
X-PRIORITY: 3

This is a multi-part message in MIME format.

------=_Next_Part_000_12082008193752.000007AC
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






-------- Kabel E-Mail Reply ---------------
From: brian.e.carpenter@gmail.com
To : swb@employees.org
Date: 11.08.2008 23:56:31

On 2008-08-12 07:58, Scott Brim wrote:
=2E...
> On 8/10/08 7:23 PM, Brian E Carpenter allegedly wrote:
>> No ;-) needed, I think. An identifier needs to be unique for as long a=
s
>> it needs to be unique for. If we stipulate that no transport connectio=
n
>> has a lifetime greater than T, then the transport ID only needs
>> to be unique for T+epsilon.=20
>=20
> Except that sessions overlap, so if it's a system-wide identifier it ha=
s
> to persist until the next reboot (because new sessions will keep pickin=
g
> it up and using it before previous sessions are done with it). If it's
> only a session-level identifier it can be more evanescent. This would
> make the multipath design more interesting.

That's why I specifically said "transport ID". Not host ID. Our thinking
has been somewhat constrained by the TCP/IP assumptions that
transport ID =3D network ID + port number, and that network ID =3D host I=
D
=3D host locator.

Brian
-------------------------------------------------------------------------=
--------------
Indeed: Thinking has been somewhat constrained by the above TCP/IP assump=
tions.
New ideas means finding identifiers outside from these assumptions.
Transport ID: Could it be of interest to have a look at the CALL REFERENC=
E and its very neat Call Reference bit mechanism which takes care that a =
simultaneously established incoming and outgoing call between the same tw=
o parties cannot get the same Call Reference i.e. transport id  ?
=20
Network ID:
In a world where users roam (eventually routers, at least partially?, too=
 ?), the only stable anchor is the location itself, for which there exist=
s already a most stable (geo-) location id (longitude/latitude). It will =
be reliable forever, no matter which turmoils, policital or economical, m=
ight come.
I am aware that IETF-folks are fond of  address aggregation. So let me sa=
y that  any geo-location id is much more suitable for  aggregation than I=
Pv4-Unicast addresses. Each  geo-patch (square degree, square minute, squ=
are second) is surrounded by 8 adjacent geo-patches (North,South, East,We=
st, NE, NW,SE,SW) which can recursively be repeated for these altogether =
9 geo-patches again and again.
Whereas any two IP prefixes which start out differently have no relations=
hip at all - and never will.
Remember, Rhekter's law speaks about two possibilities, not just one.
=20
Heiner

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: & ftp://psg.com/pub/lists/rrg

------=_Next_Part_000_12082008193752.000007AC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><META http-equiv=3DContent-Type content=3D"text/html; charset=
=3Diso-8859-1"></HEAD>
<BODY bgColor=3D#ffffff><FONT face=3D"verdana,arial" size=3D"2">
<P><BR><BR><BR><BR><BR>-------- Kabel E-Mail Reply ---------------<BR>Fro=
m: brian.e.carpenter@gmail.com<BR>To : swb@employees.org<BR>Date: 11.08.2=
008 23:56:31<BR><BR>On 2008-08-12 07:58, Scott Brim wrote:<BR>....<BR>&gt=
; On 8/10/08 7:23 PM, Brian E Carpenter allegedly wrote:<BR>&gt;&gt; No ;=
-) needed, I think. An identifier needs to be unique for as long as<BR>&g=
t;&gt; it needs to be unique for. If we stipulate that no transport conne=
ction<BR>&gt;&gt; has a lifetime greater than T, then the transport ID on=
ly needs<BR>&gt;&gt; to be unique for T+epsilon. <BR>&gt; <BR>&gt; Except=
 that sessions overlap, so if it's a system-wide identifier it has<BR>&gt=
; to persist until the next reboot (because new sessions will keep pickin=
g<BR>&gt; it up and using it before previous sessions are done with it). =
If it's<BR>&gt; only a session-level identifier it can be more evanescent=
=2E This would<BR>&gt; make the multipath design more interesting.<BR><BR=
>That's why I specifically said "transport ID". Not host ID. Our thinking=
<BR>has been somewhat constrained by the TCP/IP assumptions that<BR>trans=
port ID =3D network ID + port number, and that network ID =3D host ID<BR>=
=3D host locator.<BR><BR>Brian<BR>---------------------------------------=
------------------------------------------------</P>
<P>Indeed: Thinking has been somewhat constrained by the above TCP/IP ass=
umptions.</P>
<P>New ideas means finding identifiers&nbsp;outside from these assumption=
s.</P>
<P>Transport ID: Could it be of interest to have a look at the CALL REFER=
ENCE and its very neat Call Reference bit mechanism which takes care that=
 a simultaneously established&nbsp;incoming and outgoing call between the=
 same two parties cannot get the same Call Reference i.e. transport id&nb=
sp; ?</P>
<P>&nbsp;</P>
<P>Network ID:</P>
<P>In a world where users roam (eventually routers, at least partially?, =
too ?), the only stable anchor is the location itself, for which there&nb=
sp;exists already a most stable (geo-) location id&nbsp;(longitude/latitu=
de). It will be reliable forever, no matter which turmoils, policital or =
economical, might come.</P>
<P>I am aware that IETF-folks are fond of&nbsp; address aggregation. So l=
et me say that &nbsp;any geo-location id is much more suitable for&nbsp; =
aggregation than IPv4-Unicast addresses. Each&nbsp;&nbsp;geo-patch (squar=
e degree, square minute, square second) is surrounded by&nbsp;8&nbsp;adja=
cent geo-patches (North,South, East,West, NE, NW,SE,SW) which can recursi=
vely be repeated for these altogether 9 geo-patches again and again.</P>
<P>Whereas&nbsp;any two&nbsp;IP prefixes&nbsp;which start out differently=
 have no relationship at all - and never will.</P>
<P>Remember, Rhekter's law speaks about two possibilities, not just one.<=
/P>
<P>&nbsp;</P>
<P>Heiner</P>
<P><BR>--<BR>to unsubscribe send a message to rrg-request@psg.com with th=
e<BR>word 'unsubscribe' in a single line as the message text body.<BR>arc=
hive: <HTTP: rrg lists psg.com />&amp; ftp://psg.com/pub/lists/rrg<BR></P=
></FONT></BODY></HTML>


------=_Next_Part_000_12082008193752.000007AC--


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg