[rbridge] Per-VLAN DRB elections?

[Eric Gray (LO/EUS)]

Donald,

	While I agree that symmetric mappings will prevent confusion 
of the type that Radia seems to be concerned about, it is (I believe)
generally felt to be a bad idea to have such mappings within a single
administrative domain.

	As I understand it, the issue is that there are other mechanisms
that are (or may be) aware of VLAN tags as they are locally used and
these mechansism will require "re-mapping" as well.

	Hence, while I am unsure of Radia's reasoning, I am okay with
her
conclusion that it is a really bad idea within an RBridge campus.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Thursday, May 10, 2007 11:20 AM
> To: Radia.Perlman at sun.com
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Per-VLAN DRB elections?
> 
> Hi Radia,
> 
> I don't completely understand your proposal point (d) where you say it
> is fatal if VLAN tags are mapped between each other inside a bridged
> LAN. Assuming the mapping in symmetric, wouldn't Hellos also 
> get mapped
> between VLANs so the two DRs you suggest would see each other and you
> would only end up with only one DR?
> 
> Donald
> 
> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On
> Behalf Of Radia.Perlman at sun.com
> Sent: Wednesday, May 09, 2007 9:12 AM
> To: rbridge at postel.org
> Subject: [rbridge] Per-VLAN DRB elections?
> 
> I think we haven't discussed this one on the list yet.
> 
> Bridges can be configured to not forward certain VLANs on 
> certain links.
> So, a "level 2 cloud" (a bunch of links connected with bridges) can be
> partitioned
> with respect to various VLANs. So, for instance, RBridges R1 
> and R2 can
> be
> neighbors on a cloud with respect to VLAN A, but not with VLAN B. In
> other
> words, a packet tagged with "VLAN A" will get from R1 to R2, but one
> tagged
> with "VLAN B" will not...even if both R1 and R2 think they 
> are connected
> to VLAN B.
> 
> Oh...this is somewhat related to listening instead of participating in
> the bridge spanning tree, which I will clarify in a separate thread.
> 
> 
> Some issues with bridges not forwarding all VLANs:
> 
> a) If the IS-IS DRB (Designated RBridge)
> election messages are tagged with VLAN B, then we will wind up
> with two DRBs for the link (scary)
> 
> b) if R1 is selected DRB for the link, it may not be able to serve all
> endnodes (since
> R1 might not be able to reach certain endnodes on some VLANs
> 
> c) in theory, DRB election should be separately carried out for each
> possible VLAN tag
> (4000 of them). That would be too much.
> 
> d) there was a suggestion that it might be a feature to allow load
> sharing off a layer 2
> cloud by having separate DRBs for different VLANs
> 
> So...here's a first strawman proposal, partially based on my memory of
> hallway conversations:
> 
> a) for the zero configuration case, assume that without configuration,
> the DRB election
> is carried out once, tagged with VLAN 1. Whoever gets elected 
> DRB in the
> DRB election
> tagged with VLAN 1 is DRB for all VLANs on that link.
> 
> b) RBridges may be configured with other VLAN tags to also, 
> on the same
> port, participate
> in an IS-IS election with. DRB priority may be configured to be
> different for different VLANs, so
> R1 might be configured, on port a, to participate in a DRB 
> election for
> VLAN A with priority 7,
> and VLAN B with priority 9
> 
> c) In the core instance of IS-IS, R1 announces not just which VLANs it
> is attached to, but
> the Root bridge ID for that VLAN. That way, if R1 finds out (by seeing
> R2's link state packets)
> that R2 claims to be DRB for VLAN A, with root bridge 89, and 
> R1 thinks
> that it is DRB for VLAN A,
> root bridge 89, then one of them should back off (using system ID as a
> tie breaker), where
> "back off" means "stop acting as DRB", i.e., don't
> encapsulate/decapsulate data packets
> to/from that port with respect to that VLAN
> 
> d) it is absolutely gross misconfiguration, and a disaster, if within
> the layer 2 cloud, a VLAN tag
> can turn into another VLAN tag, because this could cause R1, 
> who is DRB
> for
> that link for VLAN A, to decapsulate a frame onto the link, 
> which might
> pop out to
> R2, who is DRB for that link for VLAN B, to see the packet as "VLAN B"
> 
> I *think* my proposal above has the following properties:
> 
> 1) if a link is genuinely partitioned with respect to VLAN A, 
> then there
> will be two DRBs elected
> for that link, and all endnodes on that link in VLAN A will 
> be reachable
> via one or the other
> DRBs, and no link will be formed
> 
> 2) as long as a VLAN tag can't get converted to another VLAN 
> tag within
> the layer 2
> cloud there will not be loops formed by having two DRBs on the same
> layer 2 cloud
> 
> 3) we can do load sharing (R1 will be DRB for VLAN A and R2 
> will be for
> VLAN B)
> 
> 4) if R1 and R2 wind up both elected as DRB for VLAN A and 
> VLAN A is not
> actually
> partitioned (but R1 can't reach R2), then they'll discover 
> this through
> the core instance
> IS-IS announcements
> 
> 5) the common case can still be zero configuration
> 
> Comments?
> 
> Radia
> 
> 
> 
> _______________________________________________
> 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
>