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

From: Donald Eastlake <[email-masked]>
Date: Wed, 4 Feb 2009 23:01:15 -0500

See below...

On Tue, Dec 2, 2008 at 12:23 PM, Dinesh G Dutt <[email-masked]> wrote:
>
> 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:

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.

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

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

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 05 Feb 2009 05:30:03 -0800

Donald,
> 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

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 5 Feb 2009 09:49:05 -0500

OK, thanks,
Donald

On Thu, Feb 5, 2009 at 8:30 AM, Dinesh G Dutt <[email-masked]> wrote:
> 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
>>