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

[Radia Perlman]

I'd like to understand what problem customers are attempting to solve with
partitioned VLANs, and what hardship it would present to require at 
least one of the
VLANs to *not* be partitioned. With TRILL, if a customer eventually replaces
all bridges, the customer will not be able to partition VLANs anymore. 
Also, from
what Anoop was explaining to me, the GVRP protocol would automatically
configure the switch-to-switch links to join all the islands of VLANs. 
So it would
seem as though it can't be that fatal to solving customer problems to 
require
*one* VLAN on a layer 2 cloud to not be partitioned.

I'd guess that most of the time partitioned VLANs would be a result of 
misconfiguration,
or intentional configuration in one topology that becomes partitioning 
when the spanning
tree reconfigures.

The only thing I can imagine solve with intentionally partitioned VLANs 
is that the
VLAN space is too small, so they have to reuse the same number in 
different parts of
their cloud. In that case, I'd think a much cleaner solution would be 
expanding the
size of the VLAN, which would be easy with TRILL.

At any rate, everything involves tradeoffs. The plus side of the 
one-Hello-on-VLAN-1
proposal is simplicity and efficiency, since there only needs to be a 
single hello.

So anyway---what problem are customers solving with intentionally 
partitioned VLANs
on a layer 2 cloud?

Radia




Silvano Gai wrote:
> 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
>>