[rbridge] Multiple instance/hierarchical RBridge topologies

[Radia Perlman]

After talking to a bunch of people, I think I understand a feature, and 
here are thoughts on how
to implement it.

The two problems we might solve:

a) ensure that two different RBridged clouds don't accidentally merge

b) allow a hierarchy of RBridged clouds (yes, similar to L2VPN or 
provider backbone bridges)

In the case of b) it would be useful to encapsulate data packets with a 
customer ID, whereas such
a field would not be necessary for a customer campus/CRED/RBridged-cloud.

IS-IS already has a field "area address" that can be configured to keep 
two IS-IS instances separate.
So, for instance,
the default can be area=0, but if there are two different RBridged 
clouds that are intended to be kept
separate, but they are physically close enough that someone is afraid 
they might accidentally merge, then
you can configure the area address in all of the RBridges
in at least one of the clouds to prevent two alien RBridges from talking to
each other.

For hierarchy, we could do the same thing (configure the higher layer 
RBridge cloud to have an
area address something other than 0). That way customer RBridged nets 
would not accidentally merge
with the core instance. But as I'll explain, I think the backbone 
RBridges would need to be slightly
different from the lower-level RBridges.

There are two "community" things that we want to keep separate, and 
let's call them "customers" and
"VLANs within customer". RBridges as currently specified keep VLANs 
separated. However, if
we have a higher level of RBridges connecting customers, each of whom 
are using VLANs, the
core RBridges need to keep separate communities of (customer, VLAN) pairs.

So let's think of a "community" as having a hierarchically assigned 
"community" name, which would be
"customer ID" concatenated with VLAN tag, or (customer, VLAN). The rule 
is that two endnodes can only
talk to each other if they are in the same tuple (customer, VLAN).

This really results in all the same algorithms as RBridges already do in 
terms of filtering so that multicasts
within a VLAN stay within a VLAN, except that it's a bigger field: it's 
(customer, VLAN) now.

Therefore, the difference between case a) and b) above is that RBridges 
also have to know
how many components are in the community tag. In a) RBridges assume the 
community is
specified by the VLAN tag in the inner packet. In b), we need for 
RBridges in the backbone to
add another field to specify another level of hierarchy in the tag. In 
an earlier note, we were suggesting
using a VLAN tag in the outer header. But perhaps it would be more 
cleanly expressed as another
field in the shim header used by the backbone RBridges.

So, here is a suggestion:

Make the "area address" in IS-IS have two parts: (level of hierarchy | 
name).
The default is level=0, and name=0.
Backbone RBridges would use level=1, and name could be anything, but all 
RBridges in the
same cloud all have
to be configured with the same name (0 would work).

RBridges at level 1 will encapsulate data packets with an extra field 
(say 16-bits),
that separates communities. So at level 1, we'd add to the shim a 16-bit 
field, that we could think
of as "customer ID". So if the shim header is 6 bytes at level 0, it 
would be 8 bytes at level 1, since
it would also have the extra "customer" field.

I don't think we'd ever need more than 2 levels, but we might want to 
think about that -- I'd guess
we'd assume 2 "customer ID" fields in the shim at level 2.

At level 1, in the per-VLAN instance which passes around endnode 
information and IP multicast membership,
the only difference would be like having a VLAN tag which is 28 bits (12 
plus 16), and in theory, one
could have 2^28 instances of IS-IS passing around endnode information 
across the backbone.

Comments? I hope I'm being reasonably clear.

Radia