Subject: [rbridge] Shared VLAN proposal

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 9 Apr 2007 11:03:35 -0700

This is a proposal on how to support "shared VLANs" and resolve the
whole MAC/IP uniqueness question. It avoids the incosistencies of
simply assuming that MAC and IP addresses are always scoped by VLANs,
but does so without requiring any action from any RBridge that is not
directly involved in a "VLAN Group".

By default the per-VLAN IS-IS instances are totally independent from
each
 other. There is no presumed correlation between identicial MAC or IP
addresses when they are in different VLAN instances.

However, RBridges MAY offer the capability of recognized groups of VLANs
that represent a single unique namespace for both MAC and IP addresses
and
where there is a primary or shared VLAN that is accessible from all of
the
other VLANs in the group.

For example, a VLAN group might consist of {Z,A,B,C,D} where Z is the
designated primary VLAN. Endnodes in VLAN A would be capable of sending
ethernet frames within VLAN A, and to VLAN Z. Endnodes in VLAN B could
send to {Z,B}, those in C to {Z,C} and those in D to {Z,D}. While
endnodes
in the shared or primary VLAN (Z) would be able to send to all VLANs in
the
group {Z,A,B,C,D}.

The impact on the RBridge protocol is that RBridges which support a
VLAN Group would have more information in the  IS-IS instances for
the VLAN Group. Specifically:

	Endnodes that are part of the primary VLAN (Z) would be
represented
	in the IS-IS instances for the entire group {A,B,C,D,Z}.

	Endnodes that are part of a non-primary VLAN (for example, A)
would
	also be represented in the instance for the group's primary VLAN
(Z).

RBridge ingress behavior is essentially unchanged. The exception is that
a frame being attempted from one non-primary VLAN (A) to another
non-primary
VLAN (B) can be short-circuited at the source. Because of the sharing
between
the IS-IS instances within the VLAN Group the ingress RBridge MAY
recognize
that the destination is unreachable, whereas without this information it

would merely be unknown (it would also be unreachable, but the ingress
RBridge would not have known that).

For RBridges supporting VLAN Groups, egress behavior is enhanced to
allow
an endnode that otherwise would have been considered to be just the
primary
to also be part of all VLANs in the group, and for an endnode that
otherwise
would have been part of any non-primary VLAN in the group to also be
part
of the group's primary VLAN.

This option requires no supporting action from any RBridge that is not
part of
the VLAN group. The additional information need only be retained in
IS-IS
instances that are part of a VLAN Group. No RBridge is required to
support
VLAN Groups.

The only required enhancement to RBridge protocols is that the endnode
discovery
advertisement needs to explicitly indicate the VLAN associated with the
discovered
endnode. It may also be desirable for each the RBridge discovery
advertisement to
explicitly list any VLAN Group that the RBridge is part of.

All RBridges that are part of a VLAN Group MUST have the same list of
member VLANs
for the VLAN Group.

All RBridges that are part of a VLAN Group MUST participate directly in
the group's
primary VLAN ('Z' in the example), and MUST maintain a VLAN Z IS-IS
instance.

Endnode discoveries by any RBridge within a VLAN Group MUST be
distributed via the
group's primary VLAN.

When an RBridge receives an endnode discovery advertisement for and
endnode that
belongs to the primary VLAN it MUST include that information within each
IS-IS
instance that it maintains for the entire VLAN Group. It MUST enforce
any consistency
rules that are relevant according to that VLAN Group's rules, for
example discovery of
an IP Address within one VLAN might require removal from another VLAN.

Consistency rules of this type reflect the rules of that VLAN Group. The
RBridge protocol 
neither requires nor forbids such VLAN Group specific rules.

When an RBridge receives an endnode discovery advertisement for a
non-primary VLAN, the
endode is only added to the receiving RBRidge's IS-IS instance for the
group's primary
VLAN (Z). The receiving RBridge would also remove any endnode record
that was inconsistent
with the new information, such as the same MAC or IP address having a
conflicting meaning,
from other VLAN IS-IS instances.

Determination as to whether an entry is "conflicting"  is based upon the
rules of the
VLAN Group, and is not part of the RBridge protocol specificatins.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 09 Apr 2007 12:19:34 -0700

Yes.! Thanks, Caitlin.

This seems like the right way to go. It offers the best part of both the 
proposals
I wrote up earlier, without the disadvantages or either, and it's simple.

a) only the RBridges attached to a VLAN in the group need to know about 
the VLAN group
b) packets don't get duplicated

And it accomplishes this by having RBridges that are in the VLAN group 
pretend to be in all
the relevant other VLANs. This way they receive multicasts, including 
IS-IS endnode announcements, for all the VLANs they should be receiving.

To say it in other words,

a) There is a VLAN group consisting of {Z=primary, A, B, C, D}

b) An RBridge is configured to know about this group iff it attaches to 
a link in one of
those VLANs

c) "Core RBridges" (by which I mean those that are forwarding packets 
that are already
encapsulated) forward a multicast frame tagged with a VLAN in that group 
exactly as
it would have without there being a VLAN group

d) For an RBridge RB1 that attaches to one of the VLANs in the group:

   . If RB1 is attached to a secondary VLAN, say VLAN C, RB1 claims, in 
its core instance
     of IS-IS, that RB1 is actually attached to both VLAN C and VLAN Z. 
This causes
     multicast packets tagged with VLAN C or VLAN Z to get delivered to RB1.

   . If RB1 is attached to the primary VLAN Z, the RB1 claims, in its 
core instance of
     IS-IS, to also be connected to VLANs A, B, C, and D. That way RB1 
will receive
     any multicast packet tagged with any of the VLANs in the group

e) The per-VLAN instance of IS-IS in which endnode membership is announced
is not changed; there is still one for A, one for B, one for C, one for 
D, and one for Z.
Because RB1, in Z, has announced it is part of A, B, C, and D as well, 
RB1 will receive
endnode announcements for all of the VLANs A, B, C, and D

f) If RB1 receives, from endnode S in VLAN Z, a unicast for destination 
D, RB1 checks to
find D in its endnode databases for all of the VLANs in the group (Z, A, 
B, C, and D). If
it finds D in VLAN C, with egress RBridge RB2, then RB1 encapsulates the 
packet with
inner VLAN tag Z (the source's VLAN), and specifies egress RBridge=RB2.

RB2 receives this unicast for D, and forwards it to D even though the 
frame is marked
as VLAN=Z, and D is in VLAN C. RB2 removes the VLAN tag, changes it to C, or
leaves it as Z, whatever is appropriate, and presumably RB2 is 
configured to know which
of these three is appropriate for the outgoing port.

If RB1 cannot find D in any of the endnode tables for {Z, A, B, C, or 
D}, then RB1
floods the packet tagged with VLAN=Z (the source's VLAN).

g) If any rbridge RB1 receives a multicast packet from a source in any
VLAN, whether that VLAN is part of a group or not, RB1 floods the packet 
tagged
with the source's VLAN

**********
One thing I'd like to add is for RBridges that are part of a group to 
announce the group
in their core instance. Core RBridges would ignore this. It would not 
change their behavior, so
there is no disadvantage (other than a trivial amount of space in the 
core instance LSP).
The advantages are:
a) perhaps one could avoid configuring every RBridge, and an RBridge 
could be willing
to take the word of another RBridge what the VLAN groupings should be
b) at the very least, it would be a good debugging tool, and a way of 
detecting misconfiguration

I'd suggest the TRILL spec just say that you SHOULD put the information 
into the core
instance of IS-IS if you are configured, and not say anything about what 
any RBridge would
do with the information.

**********
So -- what do people think about this?

Radia

Caitlin Bestler wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 9 Apr 2007 13:18:07 -0700

Radia Perlman wrote:

> 
> I'd suggest the TRILL spec just say that you SHOULD put the
> information into the core instance of IS-IS if you are
> configured, and not say anything about what any RBridge would
> do with the information.
> 
The TRILL spec would merely add the information to the RBridge
discovery data. It could explicitly state that any RBridge could
choose to not retain information that it would have no use of.

The same would apply to the additional attribute in the endnode
discovery. If it's not relevant to you, discard or ignore it.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 09 Apr 2007 13:36:24 -0700

Actually, with IS-IS, R1 can't delete information from R2's LSP If R1 is 
not interesting in it.
Anyone participating in the flooding of R1's LSP must keep R1's LSP 
intact. Someone
downstream might be interested in that information. Even once R1's 
neighbors acknowledge
they've received R2's LSP, R1 must still retain the information in case 
one of R1's neighbors
goes down and loses state.

With the per-VLAN instance of IS-IS, since the topology is a single hop, 
R1 would
never need to forward R2's LSP to anyone else, so in theory R1 could ignore
R2's endnode announcements.

Radia