[rbridge] A thought about TTLs
touch at ISI.EDU
Sun Nov 5 22:31:40 PST 2006
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.
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.
> rbridge mailing list
> rbridge at postel.org
Sr. Network Engineer, USAF TSAT Space Segment
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061105/e506234c/signature.bin
More information about the rbridge