[rbridge] draft protocol-10 WGLC Multicast Addresses

Donald Eastlake d3e3e3 at gmail.com
Thu Feb 5 06:49:05 PST 2009 

OK, thanks,
Donald

On Thu, Feb 5, 2009 at 8:30 AM, Dinesh G Dutt <ddutt at cisco.com> wrote:
> 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
>
>



-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com

More information about the rbridge mailing list