[rbridge] draft protocol-10 WGLC Maximum Bridge Transit Delay

[James Carlson]

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
nothing underneath?

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

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