[rbridge] Shared VLAN proposal

[Radia Perlman]

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:
> 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.
>
>
>
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>