Subject: [rbridge] A thought about TTLs

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 6 Nov 2006 17:30:01 -0500

Joe,

	The protocol specification cannot be silent on the setting of
a value for TTL.  For one thing, any value less than the max, should
be compared with the expected number of hops as a sanity check - one
way or another (meaning if the boxes don't do it, the user will have
to do it themselves).

	For example, if an implementer decided that 16 hops was the 
most they could realistically expect to see in an RBridge CRED, they
might set it to 16.  If it subsequently turns out that a network is 
larger than they expected, I sincerely hope that they made this a
configurable value.  If there is going to be a need to configure a
value for this in most implementations, then we might as well say so
up front so that there is likely to be a standard MIB object that
corresponds to this value.

	Clearly the simplest thing to do, therefore, is to set TTL to
the maximum possible value.  Simple, but probably not sane.

--
Eric

--> -----Original Message-----
--> From: Joe Touch [mailto:touch at ISI.EDU] 
--> Sent: Monday, November 06, 2006 5:12 PM
--> To: Gray, Eric
--> Cc: Eastlake III Donald-LDE008; rbridge at postel.org
--> Subject: Re: [rbridge] A thought about TTLs
--> 
--> That argument holds as well for packets in the Internet. 
--> There are two
--> cases:
--> 
--> 	1- loops are common, and we want to reduce the looped traffic
--> 
--> 	2- loops are not common, and we want to reduce effort in
--> 	predicting the expected TTL
--> 
--> I sincerely hope that 2 is what we're designing for.
--> 
--> As to 1, if a vendor wants that as value added, that's 
--> fine. But I would
--> not encourage the WG to endorse that approach as an 
--> optimization, since
--> if (when) it fails it has more substantial consequences than longer
--> loops, since legitimate traffic will be silently dropped even when
--> routing is correct. If a vendor wants to take that risk, 
--> that's fine,
--> but the WG shouldn't engineer a spec for it, IMO.
--> 
--> Joe
--> 
--> Gray, Eric wrote:
--> > Joe,
--> > 
--> > 	I tend to agree with Donald's comments (which are not 
--> included here,
--> > because of the difficulty I have in responding to your 
--> mail generally).
--> > 
--> > 	To your point, it might be possible for RBridges to use 
--> some factor
--> > (such as +2 hops, or *2 hops) over the actual expected 
--> tunnel length, but
--> > it is unreasonable to use any number much larger than 
--> that for the purpose
--> > preserving frames that are taking some tortuous, but not 
--> looping, path in
--> > a changing network.
--> > 
--> > --
--> > Eric
--> > 
--> > Earlier, you said:
--> > --> The whole point of a TTL is that things could change 
--> en-route, which
--> > --> means that a rbridge might want to scope the TTL 
--> down, but this could
--> > --> end up dropping a packet that would have had a 
--> legitimate, nonlooping
--> > --> path that's unexpectedly longer later.
--> > --> 
--> > --> IMO, let the TTL be what it is - loop prevention for 
--> unicast, and
--> > --> diameter scope for broad/multicast. Don't try to 
--> overthink it beyond
--> > that.
--> > --> 
--> > --> Joe
--> > 
--> > --> -----Original Message-----
--> > --> From: rbridge-bounces at postel.org 
--> > --> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> > --> Sent: Monday, November 06, 2006 1:32 AM
--> > --> To: Eastlake III Donald-LDE008
--> > --> Cc: rbridge at postel.org
--> > --> Subject: Re: [rbridge] A thought about TTLs
--> > --> 
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> rbridge at postel.org
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > --> 
--> 
--> -- 
--> ----------------------------------------
--> Joe Touch
--> Sr. Network Engineer, USAF TSAT Space Segment
--> 
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Nov 2006 14:36:14 -0800

> the maximum possible value.  Simple, but probably not sane.

Why is/should it be different than in an IP network?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061106/6ba3969b/signature.bin