Subject: [rbridge] A thought about TTLs

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

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
-->

---

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

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

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- 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/4c6a0bd1/signature.bin