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

[James Carlson]

Donald Eastlake writes:
> > 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?
> 
> 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.

Under what conditions would that be expected to happen?

I suspect that one good reason to avoid bothering with such a feature
on high-end switches is that the amount of buffering required to reach
a 1 second delay at high line rates becomes prohibitive -- in other
words, you'll ordinarily drop on queue entry well before that happens
in all but pathological cases, so why bother caring?

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

We're not using STP here, though, so we don't need to back up its
assurances.

As for avoiding a too-old release, I don't think that's easy to avoid
with modern hardware due to the funky 802 flow control mechanism.  If
the other end is having trouble, you can end up with a really old
frame caught in your transmission craw.  It'd require some fancy
footwork in most implementations I've seen to detect that sort of edge
case, reset, and restart.

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

That 'one second delay' smells to me too much like the old IP TTL
specification, and likely dates back to the same rules of thumb.

I think that SHOULD is a fairly strong statement; it means that
implementors who choose not to implement that feature need to have a
clear explanation of why they don't, if they're going to try to follow
the spirit of the RFC.  I don't think it ought to be a SHOULD unless
it's something that's required for interoperability in most cases, but
can be avoided in a few.  As 2119 says:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Do RBridge implementors really need to weigh the pros and cons of
implementing the delay time check in order to achieve
interoperability?

MAY is closer to the intent of saying, "here's something that's common
in this field and that may be helpful in an implementation, but that
is not known to be required for the sake of interoperability of
RBridges."

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