[rbridge] draft protocol-10 WGLC Multicast Addresses

[Anoop Ghanwani]

It probably wouldn't hurt, but I'm not sure that this is at all
necessary.
 
Other than the core IS-IS instance, all other frames have a TRILL
header and we can control forwarding behavior using those contents
(and we have already reserved NickName values for that purpose).  
In future, if we define anything that we don't want to be forwarded 
by RBridges, we can always force it to have the TRILL header.
So we are not dependent on MAC addresses...
 
Anoop


________________________________

	From: rbridge-bounces at postel.org
[mailto:rbridge-bounces at postel.org] On Behalf Of Donald Eastlake
	Sent: Wednesday, November 26, 2008 2:09 PM
	To: Developing a hybrid router/bridge.
	Subject: [rbridge] draft protocol-10 WGLC Multicast Addresses
	
	
	Hi, 

	When TRILL started, it had only one multicast address:
All-RBridges. Then it was decided that encapsulated IS-IS frames would
have an Inner.MacDA of All-IS-IS-RBridges and there were two. Now there
are three multicast address: (1) IS-IS frames are not longer
encapsulated and  All-IS-IS-RBridges is their Outer.MacDA, (2)
All-RBridges is the Outer.MacDA for ESADI and multi-destination data
frames, and (3) All-ESADI-RBridges is the Inner.MacDA for ESADI frames.

	I don't think we are going to need any more than these three
multicast addresses for the Base Protocol Specification but multicast
addresses are cheap. 802.1 initially allocated itself a block of 16
addresses for bridging and link protocols (see, for example, 802.1D-2004
Figure 7-10 or the more recent 802.1Q-2005 Table 8-1) with the defined
behavior being that a bridge was required to drop any frame sent to one
of these addresses if the bridge did not understand the protocol(s)
indicated by that address. This sort of behavior has to be specified at
the beginning. Once you start shipping devices that are transparent to
some addresses, you can't practically later say they have to drop them
if they don't know the protocol(s) associated with those addresses.
(This behavior for bridges has been somewhat modified for more recent
complicated cases like provider bridging.) 

	So, I propose that, when we apply, we get a block of 16
addresses with the ones listed in the first paragraph above being the
first three addresses in this block and the remaining 13 being reserved
for future use. And that the protocol specification require RBridges to
drop frames with Outer.MacDA being any of these 13 addresses (unless the
RBridge understands some future use of that address).
	
	
	Thanks,
	Donald
	=============================
	Donald E. Eastlake 3rd   +1-508-634-2066 (home)
	155 Beaver Street
	Milford, MA 01757 USA
	d3e3e3 at gmail.com
	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20081201/b5613b25/attachment.html