[rbridge] draft protocol-10 WGLC Multicast Addresses
Dinesh G Dutt
ddutt at cisco.com
Tue Dec 2 09:23:03 PST 2008
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:
> 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
>>>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>
--
We make our world significant by the courage of our questions and by
the depth of our answers. - Carl Sagan
More information about the rbridge
mailing list