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

[Silvano Gai]

I said it wrong, sorry, retrying:

"It is not possible to configure an RBridge to NOT 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.

There is only one topology in RBridges, i.e. the core topology. In
Spanning Tree potentially there are many active topologies. In RBridge
the per VLAN instance only acts as "VLAN Pruning".

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Silvano Gai
> Sent: Sunday, April 01, 2007 7:54 AM
> To: Radia Perlman; Russ White
> Cc: rbridge at postel.org
> Subject: [rbridge] Disable transit for a VLAN was (RE: Shared VLAN
> learning:What is it and why should wecare?)
> 
> 
> 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
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge