[rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay
james.d.carlson at sun.com
Wed Nov 26 14:21:43 PST 2008
Donald Eastlake writes:
> I've reviewed the draft and will be posting a few suggested changes. This is
> the first.
> 802.1 bridges have a Maximum Bridge Transit Delay. They are required to
> discard frames that have been inside the bridge for longer than this time.
> It is configurable with a recommended value of 1 second and maximum value of
> 4 second. (802.1D-2004 Table 7-3) It would seem like a good idea to put in a
> sentence or two to indicate that RBridges have this parameter configurable
> per RBridge and enforce a maximum RBridge transit delay.
Do modern bridges actually _implement_ such a feature, or do they just
have a knob labeled "Maximum Bridge Transit Delay" that's connected to
I can imagine flushing Ethernet output queues if link status goes down
and stays down for more than a second, thus blocking timely output,
but tracking internal timestamps on individual packets seems like a
wasted effort to me, and may not even be feasible with modern
I'm inclined to say "no" to this, just on the basis that I cannot see
how it would serve any real purpose. It looks like a spec for the
sake of a spec.
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
More information about the rbridge