[rbridge] A thought about TTLs

[Joe Touch]

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

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