[rbridge] On 802.1 Registration Protocols

[Eastlake III Donald-LDE008]

IEEE 802.1D defines a general attribute registration protocol (GARP). A
block of 16 multicast addresses is reserved for different applications
of this protocol but only two applications have been defined:
registration of multicast addresses (GARP Multicast Registration
Protocol, GMRP) and registration of VLANs (GARP VLAN Registration
Protocol, GVRP (specified in 802.1Q)). These protocols, speaking very
generally, allow a bridge or end station to send a frame which indicates
that it wishes to received traffic for a particular multicast group or
VLAN or no longer wishes to receive such traffic. The initial version of
this allowed only one attribute per request frame but 802.1Q has been
amended to require a different format for these messages which can
encoding multiple attributes per frame. The amended version is called
multiple registration protocol, MRP, and the two applications, when
using MRP frames, are called MMRP and MVRP.

802.1 bridges which don't understand GARP/MRP frames are required to
forward them like other multicast frames.

One could imagine various extremely complex interactions between
Rbridges and such GARP/MRP messages. But I think we want to make Rbridge
interactions with GARP/MRP that are specified in TRILL as simple as
reasonably possible given the constraint that bridges should be
incrementally replaceable with Rbridges in realistic scenarios.

The current base protocol draft says that such registration frames are
treated like any other non-IP-derived multicast. I think this works well
enough for multicast registration frames (multicast address
01-80-C2-00-00-20), which are rarely used in practice, and for the 14
reserved registration protocol multicast addresses (01-80-C2-00-00-22
through 01-80-C2-00-00-2F). Frames treated this way are VLAN constrained
and no worse than a broadcast frame.

However, just treating a VLAN registration frame like other
non-IP-derived multicast seems, to me, to have serious problems.
	The 802.1 standard prohibits VLAN tags on native VLAN
registration frames and, since the purpose of such frames is frequently
to turn on connectivity for a VLAN, it would make no sense to consider
their distribution to be VLAN constrained. However, if VLAN registration
frames are just flooded without VLAN constraint, they become, in effect,
super-broadcast frames that could easily be used for denial of service.
In fact, since VLAN connectivity information for Rbridges is flooded via
IS-IS, it is not clear there is any need to forward VLAN registration
frames between them at all.
	VLAN registration is not useful for Rbridge-to-Rbridge links but
could be useful if sent to bridges and useful at an ingress Rbridge port
if that port is configured to allow dynamic VLAN registration, which is
the recommended default configuration for 802.1Q ports (except for VLAN
1 which is fixed enabled in the default).
	In principal, VLAN registration frames could be recognized by
end stations; but use of them in that way is fairly rare. My opinion is
that it would be OK to require configuration at an Rbridge to get it to
send such frames on a port where it does not see a bridge.

So my current thought is that Rbridges which receive a VLAN registration
frame and which are configured to pay attention to such frames (which
would be the recommended default, as it is with 802.1Q bridges) should,
for VLANs which are set to dynamic registration (which should be the
recommended default, as it is with 802.1Q bridges), run the registration
state machine and appropriately enable/disable VLAN output on that port.
	This VLAN enablement status will be flooded to all other
Rbridges in the link state database so there is no need to encapsulate
or forward or generate VLAN registration frames between RBridges.
	Rbridges that see a bridge out a port should send MVRP messages
to that bridge. Of course, it should be possible to configure them per
port to not send such messages or to send them on ports where they do
not see a bridge (presumably end station ports). Perhaps they should
also be configurable to alternatively send the older GVRP messages.

Donald
====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 Donald.Eastlake at motorola.com