[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>>=
; On 8/10/08 7:23 PM, Brian E Carpenter allegedly wrote:<BR>>> No ;=
-) needed, I think. An identifier needs to be unique for as long as<BR>&g=
t;> it needs to be unique for. If we stipulate that no transport conne=
ction<BR>>> has a lifetime greater than T, then the transport ID on=
ly needs<BR>>> to be unique for T+epsilon. <BR>> <BR>> Except=
that sessions overlap, so if it's a system-wide identifier it has<BR>>=
; to persist until the next reboot (because new sessions will keep pickin=
g<BR>> it up and using it before previous sessions are done with it). =
If it's<BR>> only a session-level identifier it can be more evanescent=
=2E This would<BR>> 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 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 incoming and outgoing call between the=
same two parties cannot get the same Call Reference i.e. transport id&nb=
sp; ?</P>
<P> </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 (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 address aggregation. So l=
et me say that any geo-location id is much more suitable for =
aggregation than IPv4-Unicast addresses. Each geo-patch (squar=
e degree, square minute, square second) is surrounded by 8 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 any two IP prefixes 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> </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 />& 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