Update identification and length

Robert Woody Woodburn <woody@sparta.com> Mon, 04 May 1992 13:44 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01998; 4 May 92 9:44 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa22372; 4 May 92 9:49 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa22366; 4 May 92 9:49 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa16366; 4 May 92 9:30 EDT
Received: from BBN.COM by PARK-STREET.BBN.COM id aa16362; 4 May 92 9:28 EDT
Received: from SPARTA.COM by BBN.COM id aa21954; 4 May 92 9:26 EDT
Received: from crusher.SPARTA.COM by sparta.com (5.65/1.34) id AA09264; Mon, 4 May 92 09:31:01 -0400
Received: by crusher (5.65/1.34) id AA01284; Mon, 4 May 92 09:30:56 -0400
Date: Mon, 4 May 92 09:30:56 -0400
From: Robert Woody Woodburn <woody@sparta.com>
Message-Id: <9205041330.AA01284@crusher>
To: yakov@watson.ibm.com
Cc: idpr-wg@bbn.com
In-Reply-To: yakov@watson.ibm.com's message of Mon, 4 May 92 08:12:17 EDT <9205041241.AA08978@sparta.com>
Subject: Update identification and length

>>>Rather than reinventing the wheel, we may have to think
>>>about TCP....
>>
>>That certainly sounds like an excellent idea. 

(Gee, I wonder why. ;{)

>>I wonder
>>why TCP wasn't used by IDPR from the beginning ?

I believe part of the rationale was to avoid dependence upon TCP/IP,
although I don't see a problem with that, since I suppose TP4 or any
other reliable transport would work just fine in other stacks.  Certainly
there are conceptual advantages if nothing else to having stream oriented 
service compared with a packet oriented interface.

The other problem might be the idea of a layering violation, but I 
personally see routing information distribution (notice I didn't say
routing period) as an application, not really even part of the network 
layer anyway.

Can some opponents of ROT (routing over TCP) please speak up?

wood y