[rbridge] Avoiding sending multiple IS-IS Hellos tagged withallthe VLAN tags

[Anoop Ghanwani]

Silvano,

Dealing with partitioned VLANs will create all kinds
of complexity.  Even 802.1Q bridges don't really deal 
with that (assumming one is using something like 
GVRP/MVRP as required by the standard).  

It only works in 802.1Q devices if doing static 
configuration.  We can always allow for that mode
of operation as an option but the default should
always be to treat the partitioned case as a mis-
configuration.

However, in the general case, I have to hunt for 
a VLAN in order to make sure my core IS-IS packets
get through.  And if there's a reconfiguration in
the L2 topology, I might have to hunt for yet another
VLAN (one that was previously partitioned but is
now connected).

Current design works in any configuration but it
does not scale and it could take very long for the
network to converge.

I don't like having to send per-VLAN IS-IS hellos.
It would require too much CPU power on the switch.

Anoop

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
> Sent: Tuesday, July 31, 2007 8:39 AM
> To: Radia Perlman; rbridge at postel.org
> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged withallthe VLAN tags
> 
> Radia,
> 
> The fact that VLAN 1 (or any other VLANs) is partitioned is NOT a
> misconfiguration. It is a reality in today networks. TRILL 
> cannot change
> this.
> 
> I disagree with this proposal.
> 
> I think we should stick with the current design that works in any
> configuration. When we will gain implementation and deployment
> experience we will optimize.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
> On
> > Behalf Of Radia Perlman
> > Sent: Monday, July 30, 2007 7:15 PM
> > To: rbridge at postel.org
> > Subject: [rbridge] Avoiding sending multiple IS-IS Hellos 
> tagged with
> > allthe VLAN tags
> > 
> > I had a conversation with Anoop, and he is (quite understandably)
> > uneasy about sending IS-IS Hellos tagged with every VLAN. So he
> > made the following suggestion, which I think makes sense.
> > 
> > a) declare that bridges must be configured
> > so that VLAN 1 (default VLAN) must not be
> > partitioned on a layer 2 cloud. We will detect the misconfiguration
> > if it occurs (see d)) so that we at least do not have 
> loops, but TRILL
> > will not
> > stand on its head to support what will be declared a gross
> > misconfiguration.
> > 
> > b) Run the IS-IS election tagged with VLAN 1. Each RBridge has
> > the following information in its IS-IS Hello:
> > 
> > . I am R1
> > . I hear Hellos from {R2, R3, R7, R11}
> > . If I am DRB, the pseudonode name will be R1.59
> > . My priority for the set of VLANs {A, D, W} is 7
> > . My priority for the set of VLANs {B, C, F, G, H} is 3
> > 
> > c) If R1 becomes DRB for at least one of the VLANs on the cloud,
> > then R1 announces, in R1's LSP on behalf of pseudonode R1.59,
> > the ID of the root bridge on the primary spanning tree
> > instance for that layer 2 cloud, along with the set of 
> VLANs for which
> > R1 is DRB on that cloud.
> > 
> > Note: The current draft spec isn't clear what information R1 reports
> in
> > the pseudonode
> > LSP and what it reports in its own LSP.
> > I'm suggesting reporting the bridge ID and
> > set of VLANs in the pseudonode LSP.
> > 
> > d) If R2 thinks itself is DRB for VLAN A on a port with root bridge
> r11,
> > and R2 sees an LSP for R1.59 that has the same root bridge 
> and VLAN A
> > listed as one of the VLANs, this indicates that VLAN 1 on that layer
> > 2 cloud is partitioned. So one of R1 or R2 should stop forwarding
> > data to/from that cloud for VLAN A. Use ID as a tie breaker, so
> > if R2's IS-IS system ID is lower than R1's, then R2 stops forwarding
> VLAN
> > A
> > traffic to and from the port that has root bridge r11.
> > This is the behavior that will occur if VLAN 1 on that port is
> > actually partitioned. If VLAN 1 is *not* partitioned, then R1 and R2
> would
> > have seen each other's Hellos and not both think they are 
> DRB for VLAN
> A
> > (or
> > any other VLAN).
> > 
> > e) This proposal supports multiple DRBs on a cloud for load 
> splitting
> > based on VLANs, since the RBridges can have different priorities
> > for different VLANs. It still requires only sending one 
> Hello, tagged
> > with VLAN 1. R2 should
> > not panic if R2 notices that R1.59 has the same root bridge as on
> > a port on which R2 is DRB, if R1.59's listed set of VLANs does not
> > include any VLANs for which R2 is DRB on the link with
> > that root bridge. If there is only partial overlap
> > of VLAN IDs, say the overlap is VLANs {D, F, and H},
> > then (the loser based on ID tie-breaker) will stop 
> forwarding traffic
> > to/from that link that is tagged with VLANs D, F, or H.
> > 
> > f) If some VLAN, say VLAN C, is actually partitioned, then the
> > result of this is that some VLAN C endnodes on that layer 2 cloud
> > will be orphaned. We will choose NOT to solve that.
> > 
> > 
> > The result of this proposal is that
> > RBridges will only need to send IS-IS Hellos tagged
> > with VLAN 1, and the only thing it does NOT solve (over
> > the current proposal of sending Hellos with every possible 
> VLAN tag on
> > each port) is that sometimes endnodes might get orphaned if you have
> > a partitioned VLAN.
> > 
> > 
> > We *could* in that case, if someone *actually wanted* to have VLAN A
> > partitioned on that cloud, configure the RBridges on that layer 2
> > cloud to explicitly run a different election
> > for VLAN A (and note in the pseudonode LSP that VLAN A had
> > an explicit election tagged with VLAN A so that if there were
> > two DRBs they wouldn't panic). But I'd prefer not solving this case
> and
> > keeping it simpler (and safer).
> > 
> > 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
>