Subject: Re: [rbridge] draft protocol-10 WGLC Multicast Addresses

From: "Anoop Ghanwani" <[email-masked]>
Date: Mon, 1 Dec 2008 18:27:32 -0800

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: [email-masked]
[mailto:[email-masked]] 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
	[email-masked]

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Donald Eastlake" <[email-masked]>
Date: Mon, 1 Dec 2008 22:57:35 -0500

Hi Anoop,

On Mon, Dec 1, 2008 at 9:27 PM, Anoop Ghanwani <[email-masked]> wrote:
> It probably wouldn't hurt, but I'm not sure that this is at all necessary.
>

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Donald Eastlake
> 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

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Mon, 1 Dec 2008 23:31:39 -0800

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:[email-masked]] 
> 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,
> 
> All-RBridges. Then it
> addresses with the

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 02 Dec 2008 09:23:03 -0800

To follow the analogy of SVLAN BPDUs and the behavior of CVLAN BPDUs in 
an SVLAN cloud, since the CVLAN BPDUs are treated as data by the SVLAN 
bridges, the SVLAN Rbridge would encapsulate the CVLAN IS-IS (which has 
a different MAC address than SVLAN IS-IS) in a TRILL header while 
transporting it through the provider RBridge cloud. This will work fine 
without having to reserve a bunch of MAC addresses.

Dinesh
Anoop Ghanwani wrote:
>>> It probably wouldn't hurt, but I'm not sure that this is at 
>>>       
>> all necessary.
>>     
>> [mailto:[email-masked]] On
>>     
>>> was decided that encapsulated IS-IS frames would have an 
>>>       
>> Inner.MacDA of
>>     
>>> and  All-IS-IS-RBridges is their Outer.MacDA, (2) 
>>>       
>> All-RBridges is the
>>     
>>> 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
>>     
>>> 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

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan