Subject: [rbridge] A thought about TTLs

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 6 Nov 2006 01:13:49 -0500

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 05 Nov 2006 22:31:40 -0800

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

Eastlake III Donald-LDE008 wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

-- 
----------------------------------------
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/20061105/e506234c/signature.bin