[rbridge] draft protocol-10 WGLC Multicast Addresses
Dinesh G Dutt
ddutt at cisco.com
Thu Feb 5 05:30:03 PST 2009
Donald,
> Dinesh, every time I read your message above, it seem to support my
> point, not oppose it.
> CVLAN BPDUs and SVLAN BPDUs have different MAC addresses, presumably
> so that customer bridges will ignore and drop SVLAN BPDUs and provider
> bridges know to treat CVLAN BPDUs as data.
>
SVLAN RBridges don't need to know the CVLAN IS-IS MAC address to forward
them as data. They treat one set of MAC addresses as BPDU, to be not
forwarded and the rest as data. If you want regular Rbridges to drop
provider RBridge BPDUs, then yes, you do need to reserve that address now.
In general, I'm not averse to reserving some addresses and I don't
believe I was disagreeing with your point except as stated above,
Dinesh
> So, the closest analogy to a bridge BPDU for an RBridge is a TRILL
> IS-IS Hello. Before the -11 protocol draft, when TRILL IS-IS frames
> were TRILL encapsulated, customer RBridge Hellos and provider RBridge
> Hellos could have been distinguished by using a reserved nickname in
> the provider RBridge Hellos. (Of course, this is all hypothetical
> since there are no provider RBridges currently specified.) Since TRILL
> IS-IS Hellos are no longer encapsulated, it seems to make sense that
> customer RBridge IS-IS frames (including Hellos) would be
> distinguished from provider RBridge IS-IS frames (including Hellos) by
> different destination MAC multicast addresses. Which you confirm when
> you say "the CVLAN IS-IS (which has a different MAC address than SVLAN
> IS-IS)".
>
> While you could get this SVLAN IS-IS multicast MAC address in a new
> allocation, it seems better to get a small block initially and
> allocate such possible later needed MAC addresses out of that block
> and it seems essential to do this if you want to have CVLAN RBridges
> drop these frames. To be specific: assume you what the behavior that
> some future type of frame will be discarded by the currently defined
> 'customer' RBridges. Two obvious ways to do this are based on MAC
> address or, for a TRILL encapsulated frame, nickname. When all TRILL
> frames were encapsulated (which I preferred), there was no particular
> reason not to use nickname. Now that not all TRILL frames are
> encapsulated, it seems desirable to be able to get this behavior with
> MAC address, which requires that some MAC addresses to be dropped by
> all current RBridges be allocated now and this behavior included in
> the protocol spec.
>
> Thanks,
> Donald
>
>
>>> 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
>>
>>
>
>
>
> --
> =============================
> Donald E. Eastlake 3rd +1-508-634-2066 (home)
> 155 Beaver Street
> Milford, MA 01757 USA
> d3e3e3 at gmail.com
>
>
--
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