[rbridge] Disable transit for a VLAN was (RE: Shared VLAN learning: What is it and why should wecare?)

[Silvano Gai]

I changed the subject because I want us to clarify one of the
confusions:

"It is not possible to configure an RBridge to act as a transit node for
a particular VLAN".

In other words: "an RBridge that does not have any port/node in VLAN A
MUST act as a transit for VLAN A if other RBridges require so".

This is different from IEEE 802.1Q in which you can decide which switch
act as transit for which VLAN.

-- Silvano


> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Radia Perlman
> Sent: Saturday, March 31, 2007 11:40 PM
> To: Russ White
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Shared VLAN learning: What is it and why should
> wecare?
> 
> I don't understand a lot of what's being said on this thread, and I
> suspect everyone is
> talking about subtly different solutions to a fairly esoteric set of
> somewhat related problems (sharing
> an IP router, sharing addresses in an IP subnet, NAT'ting VLAN IDs,
> ...). As Dale Carder mentioned,
> and gave us some pointers, there are several somewhat overlapping
> proposals floating around the industry.
> I believe there isn't a single cleanly stated problem, or a single
> cleanly statable solution.
> 
> So TRILL should do something. Whatever it is, I want to be able to
> understand what it is that RBridges should do.
> 
> But to answer Russ's questions (see at bottom of this note) -- the
> current RBridge protocol
> spec assumes that *all* RBridges filter based on VLAN tag.
> So an RBridge in the core, even if it doesn't attach to VLAN A, knows
> which other RBridges do. This
> allows efficient distribution of VLAN A traffic, for instance, the
IS-IS
> announcements of VLAN A endnode
> information.
> 
> The reason we need to let all the RBridges know what VLANs are in a
> group, say {Z, A, B, C, D},
> where Z is the primary, is so that an RBridge in
> the core knows that something tagged with VLAN Z needs to be
transmitted
> to all links in any of the
> 5 VLAN tags {Z, A, B, C, D} and something tagged with one of the
> secondaries, say A, needs to go to
> A and Z.
> 
> An example -- suppose there is an IP router R on VLAN Z (the primary).
> When R does an ARP for an
> endnode "d" in the IP subnet, R has no idea about VLANs, and the
RBridge
> RB1 that R attaches to, although
> RB1 might know that there's a grouping of VLANs, doesn't know which
VLAN
> to transmit the ARP to.
> Perhaps RB1 could duplicate broadcast packets tagged with Z, sending a
> copy to each of {Z, A, B, C, D}.
> 
> So RBridges in the core have to know to send the ARP along the
> distribution tree to all ports that are
> in any of the VLANs in the set.
> 
> In theory we could ignore VLAN tags, except at the final hop, and
then,
> as Russ said, it
> would be just an optimization for the RBridges in the core to know
about
> the groupings. But I still think things would be weird
> if the final RBridges had inconsistent configurations of the VLAN
> groupings, so I think it's a good idea to
> make sure all the RBridges agree on the groupings.
> 
> To summarize, it's good for them to agree because of three reasons:
> a) we can do optimal delivery of multicasts, filtering within the core
> rather than just at the final hop
> b) we detect misconfiguration
> c) we allow more central configuration (we don't need to configure all
> the RBridges, though that's a bit
> dangerous if all the RBridges that have been configured go down, since
> suddenly the groupings might disappear)
> 
> Radia
> 
> 
> 
> As for Russ's last questions:
> 
> >> 3. Does this have a larger impact on multicast, or smaller?
> 
> I don't understand the question, though given that he put a smiley
face
> in, perhaps
> it was a joke. I'm hoping that someone, tomorrow, will inform me that
all
> this
> SVL/FID stuff was a joke...
> 
> Radia
> 
> 
> 
> 
> Russ White wrote:
> 
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >
> >
> >
> >
> >>To avoid requiring configuration of all RBridges with these FIDs,
and
> >>still allow multicast filtering, I propose we have RBridges
advertise,
> >>in their IS-IS core instance, FIDs that they are configured with. So
at
> >>least one RBridge will say "Hey guys,
> >>I think VLANs Z, A, B, C, and D form a FID with primary=Z" and the
other
> >>RBridges will, I guess
> >>believe him.
> >>
> >>
> >
> >I'm trying to sort through this entire thing, and I wanted to ask:
> >
> >1. The reason we'd want to configure this on all rbridges would be to
> >optimize traffic flow?
> >
> >2. If 1 is true, and we didn't do the configuration on all rbridges,
how
> >much less efficient would the rbridge network be?
> >
> >3. Does this have a larger impact on multicast, or smaller?
> >
> >:-)
> >
> >Russ
> >
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v1.4.3 (Darwin)
> >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> >iD8DBQFGDVS6ER27sUhU9OQRAnbCAJ99um0k9+At9V+z97fksfH4gUVoGACgw7Mg
> >DSuMdrc10XgRmx8w4PdN/f4=
> >=ItDw
> >-----END PGP SIGNATURE-----
> >
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge