[rbridge] Proposed resolution of DRB election/MTU testing

[James Carlson]

Ali Sajassi (sajassi) writes:
> point that I am driving at. If you need to have two types of TRILL
> hellos messages (e.g., neighbor discovery vs.. protective), then that's

As Radia said, we're evolving this, but, yes, that's essentially true.

> O.K. My point is that we should be able to use the same IS-IS hello
> message with MTU padding for both because I don't think the frame size
> can exceed 1522 bytes !! (please refer to my email on scenarios for
> TRILL access/trunk ports regarding why it cannot exceed 1522).

Even if you don't exceed 1522, there can be problems.  I observed
problems with old gear in our lab that didn't support anything over
1500.  There's no guaranteed-good magic number near or above 1500 that
I know about that could possibly be used here.

That's part of the point.  Specifications are nice to have, and it's
wonderful that someone is out there 'demanding' that everyone support
at least 1522 octets in a message, but none of that actually forces
this to be true.  There are no specification police who will round up
old gear and ship it to a detention facility.

Thus, either we merely assert that certain minimums are required, and
allow the system to fail miserably (and catastrophically) when
confronted with something that's slightly out of spec *OR* we make the
protocols protective of unknown conditions in a harsh world.

I would like to see us opt for the latter.  It's my experience that
specification alone doesn't make it so.

> 1) .1Q network is running STP/RSTP: In this case, there is only a single
> active topology in the .1Q network and we can have a single VLAN that
> covers the entire active topology (e.g., VLAN 1). Then just monitoring

That's correct.  We could.  Doing so would demand that customers run
their networks in a particular way to suit our application.  Customers
would be required to configure some particular VLAN to cover the
entire L2 topology.

I'd certainly like to see that happen.  It'd be a great
simplification.  However, if you read through the list archives,
you'll see that a substantial majority of the working group believes
that forcing our collective will onto existing networks where people
are expected to deploy RBridges will not in fact work.

Instead, they won't deploy.  And that'd be a problem.

An equivalent alternative to this single-global-VLAN proposal is to
require that all RBridges in a given L2 area be interconnected either
by direct links or by repeaters alone, with no intervening bridges.
Any STP-type bridges that exist must be on the outside of the RBridge
cloud.

That also solves the problem and is sufficient, but greatly
constrains the deployment scenarios, particularly in the case where
there's a backbone bridged network.

> 2) .1Q network is running MSTP: In this case, there are several active
> topologies (one per MSTI). So, in this case, we can just have a single
> VLAN per MSTI that covers the entire active topology for that MSTI. If
> there are 2 or 3 MSTIs for 4K VLANs (which is typical), then you only
> need to monitor 2 or 3 VLANs rather than 4K VLANs. We should know the
> number of MSTIs because we have this info from BPDU in root-collision
> detection procedure.

MSTP is unclear to me.  I *think* all we really need to know is the
core instance bridge ID ... but I could certainly be wrong.  I haven't
seen MSTP in use anywhere, and I have no code that supports it.

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