[rbridge] draft protocol-10 WGLC Multicast Addresses

[Anoop Ghanwani]

Donald, 

With respect to the example you mention below...

It is true that the BPDUs from C-VLAN Bridges are
treated as data by S-VLAN Bridges, but they have 
an S-tag in them when transported over provider
bridges.  In our case, if we wanted to
design such a hierarchy, we would have to depend
on the TRILL header to separate traffic from
different belonging to different "customers"
including the control traffic.  In other words,
we would have no choice but to encapsulate the
customer IS-IS frames with a TRILL header.

In any case, as I stated earlier, I don't see
it hurting anything to reserve the block of MAC
addresses.

Anoop

> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3 at gmail.com] 
> Sent: Monday, December 01, 2008 7:58 PM
> To: Anoop Ghanwani
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses
> 
> Hi Anoop,
> 
> On Mon, Dec 1, 2008 at 9:27 PM, Anoop Ghanwani 
> <anoop at brocade.com> wrote:
> > 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...
> 
> You are probably right that you could figure out some way to do
> whatever you wanted with reserved nick names or other tweaking of the
> TRILL header but it might not be very simple or efficient.
> 
> Just as an example, if you wanted to specify Provider RBridges that
> related to the current RBridge specification the same way Provider
> Bridges relate to customer Bridges, one obvious way to do this would
> include a new multicast address (All-Provider-IS-IS-RBridges?) for
> provider core IS-IS messages, they same way Provider Bridges use a
> different multicast address for their BPDUs and, as I understand it,
> simply forward customer Bridge BPDUs...
> 
> This could alternatively be done as you suggest, but that would
> require encapsulating the Provider RBridge IS-IS messages with a funny
> TRILL Header and, I think, some people on this list really like
> dispatching on the multicast address and don't like encapsulating
> IS-IS...
> 
> Donald
> 
> > 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
>