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

From: "Donald Eastlake" <[email-masked]>
Date: Wed, 26 Nov 2008 16:30:58 -0500

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.

Thanks,Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: James Carlson <[email-masked]>
Date: Wed, 26 Nov 2008 17:21:43 -0500

> 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              <[email-masked]>
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
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Donald Eastlake" <[email-masked]>
Date: Fri, 28 Nov 2008 20:21:56 -0500

Hi Jim,

See below...

> have a knob labeled "Maximum Bridge Transit Delay" that's connected to

It is my impression that low end 802.1D bridges don't implement this
but mid and high end 802.1Q bridges do. Typically, when a frame is
received, a control block is created with the VLAN, priority, time of
receipt, and other control information. When a frame is de-queued for
transmission, the time is checked and frame discarded if it is too
old. This time check doesn't need to be, and probably isn't, extremely
accurate.

> how it would serve any real purpose.  It looks like a spec for the

In bridges, I think it is required to back up the assurances of
Spanning Tree Protocol. I think bridges also flush the output queue
and any input queue associated with a port when the port goes down.
Generally, it seems like good hygiene not to keep a frame for a long
time and then release it...

> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

It would certainly be easy enough to make this a SHOULD rather than
being mandatory the way it is in 802.1, not that people seem to pay
that much attention to what is mandatory in 802.1. But perhaps it
really isn't necessary for RBridges... Anyone else have an opinion on
this.

Thanks,
Donald