Subject: [rbridge] A thought about TTLs

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 6 Nov 2006 13:53:58 -0500

Donald,

	To expand on this, it is actually necessary for the protocol 
specification to be very explicit in describing how TTL is handled
- both in establishing the initial value, and in processing by an
intermediate (or egress) RBridge.

	There can be some flexibility in how any individual RBridge
implementation determines an initial value, but it is not sufficient
to leave this entirely to implementation discretion.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake 
--> III Donald-LDE008
--> Sent: Monday, November 06, 2006 1:14 AM
--> To: rbridge at postel.org
--> Subject: [rbridge] A thought about TTLs
--> 
--> Rbridges are in a fundamentally different position in 
--> deciding shim TTLs
--> than IP hosts are in deciding IP TTLs. In particular, a host knows
--> almost nothing about the routing situation while an Rbridge 
--> has explicit
--> link state information.
--> 
--> Thus it would be reasonable to recommend a TTL based on the expected
--> number of hops for unicast or maximum expected number of hops for
--> multicast/broadcast/flooded or on the diameter of the 
--> network (maximum
--> number of Rbridge-Rbridge hops for the two most distant 
--> Rbridges) or the
--> like ... It would even be possible to have Rbridges trim 
--> back the TTL
--> for the copy forwarding to a particularly short branch of a 
--> tree or even
--> when forwarding along a unicast path if that path has 
--> gotten shorter.
--> Such adjustment is probably too much work to mandate but it 
--> seems to me
--> that it should be allowable behavior.
--> 
--> Thanks,
--> Donald
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->