bound@zk3.dec.com Thu, 13 January 1994 02:21 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18205; 12 Jan 94 21:21 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18201; 12 Jan 94 21:21 EST
Received: from world.std.com by CNRI.Reston.VA.US id aa23878; 12 Jan 94 21:21 EST
Received: by world.std.com (5.65c/Spike-2.0) id AA10842; Wed, 12 Jan 1994 20:33:08 -0500
Errors-To: catnip-request@world.std.com
X-Orig-Sender: catnip-request@world.std.com
Reply-To: catnip@world.std.com
Precedence: bulk
Return-Path: <bound@zk3.dec.com>
Received: from inet-gw-2.pa.dec.com by world.std.com (5.65c/Spike-2.0) id AA10805; Wed, 12 Jan 1994 20:33:04 -0500
Received: by inet-gw-2.pa.dec.com; id AA07286; Wed, 12 Jan 94 17:29:48 -0800
Received: by xirtlu.zk3.dec.com; id AA15445; Wed, 12 Jan 1994 20:29:40 -0500
Message-Id: <9401130129.AA15445@xirtlu.zk3.dec.com>
To: catnip@world.std.com
In-Reply-To: Your message of "Wed, 12 Jan 94 11:29:51 EST." <199401121629.AA11373@world.std.com>
Date: Wed, 12 Jan 1994 20:29:34 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: bound@zk3.dec.com
X-Mts: smtp
Rob, >First: the NLPID as defined uses the low 4 bits as flags; this means >we are using a block of 16 NLPID values in effect. This is NG. The flags >need to be moved elsewhere. There is also a need for another flag for >Error-report Suppression. I agree on the MLPID flags being moved. Could they be first octets in the header? Error-report suppression seems like could idea. Why not make it as part of one of the support protocols options? --- >TTLs: some feedback and further thinking leads me to believe that >scaling the TTL when translating datagrams is not such a good idea >(although it must be done when going to and from IPX). It would be >better to keep it to hop count. I think the TTL should just become a hop count in any proprosal as this is how it is used by most. During translation of protocolthe TTL as a hop count would not be decremented unless the point of translation was in fact a hop. >We still want a nominal time associated with it, for when a router >hangs onto a datagram for a longer than usual time (typically waiting >for some kind of subnetwork setup). Probably 1/10 second is good; it >must be less than IP's (1 sec) and less than CLNP (500 msec) This will be handled by the transport layer or should in my opinion. >It also seems that 8 bits is really sufficient. It is a log function >of network size. If a net with 1 billion hosts has a topological diameter >of (say) 30, then a diameter of 250 with the same branchiness implies >something like 10^82 hosts. (There are something like 10^78 neutrons >in the observable universe if I recall correctly. :-) As a log function it should work... I would be interested on more comments on this. /jim