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

[Radia Perlman]

Silvano....I still don't know what problem customers are trying to solve 
with partitioned VLANs.
If it's that they want more than 4000 VLANs, then the design we had (before
Anoop's suggestion) also won't help them with that.
If it is an important problem to use more than 4000 VLANs,
we could (by extending the size of the VLAN tag within a TRILL campus) 
solve that
problem in a much more robust, easily understandable way than 
configuring interswitch
ports to block some VLANs. And I absolutely do not understand any other 
problems
that might be solved with intentionally partitioning VLANs, and it's 
impossible to design
something without understand the problem that needs to be solved.

We do have to carefully consider what "breaks"  (in the
proposal we are currently considering) if a customer does actually configure
bridges in some layer 2 cloud so that VLAN 1 is partitioned.
I believe the only consequence of a customer configuring
bridges so that VLAN 1 is partitioned in some layer 2 cloud  is that core
RBridges that might have connectivity to each
other through some VLAN other than
VLAN 1 will not realize they are adjacent, and will therefore not form 
IS-IS adjacencies, which
means fewer RBridge-RBridge links in the core than there might actually 
be. This might
actually cause the campus to get partitioned (since the only 
connectivity between RBridges
will be using VLAN 1, and if all the links in the cut set require an 
outer tag of other
than 1 in order for RBridges to talk, these links won't be found or
used). It might cause less good paths. However, it will *not* cause 
loops, because if
there is no connectivity for flooding of LSPs, data also won't flow in 
the core.

The advantage of this proposal is simplicity and scalability -- only one 
Hello per port.

As I said, I cannot understand what functionality is lost if all switch 
ports within a layer 2
cloud must be configured to pass VLAN 1, and until we do understand some
important hardship that this rule imposes, I'd say this (Anoop's proposal)
is obviously the right thing to do.

Radia


Silvano Gai wrote:
> Radia,
>
> We are describing to you how VLANs are deployed today in Enterprise
> networks. You may say that "you don't like it", we may agree with you,
> but this does not change how they are deployed.
>
> For RBridges to be successful they need to be able to replace core
> bridges without messing up the existing network configurations.
>
> Today most customers do not deploy VLANs end-to-end and they do reuse
> VLANs number in different part of the enterprise. If RBridges are not
> capable of supporting this, they are not attractive.
>
> Remember that the #1 customer requirement we have for TRILL is: "replace
> core bridges with RBridges to enable Equal Cost Multi Path, all the rest
> MUST remain the same".
>
> GVRP is not deployed; I am not sure which customers Anoop is referring
> to.
>
> -- Silvano
>
>   
>> -----Original Message-----
>> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
>> Sent: Tuesday, July 31, 2007 11:19 AM
>> To: Dinesh G Dutt
>> Cc: Silvano Gai; rbridge at postel.org
>> Subject: Re: [rbridge] Avoiding sending multiple IS-IS Hellos tagged
>>     
> with
>   
>> allthe VLAN tags
>>
>> I don't understand that problem. What you're describing might argue
>>     
> for
>   
>> bridges using a unique
>> spanning tree per VLAN in order to optimize traffic flow for that
>>     
> VLAN,
>   
>> but I don't
>> see what it has to do with wanting to partition VLANs.
>>
>> Radia
>>
>>
>> Dinesh G Dutt wrote:
>>     
>>> Radia Perlman wrote:
>>>       
>>>> 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
>>>>
>>>>         
>>> The primary problem with having a VLAN everywhere is that the root
>>>       
> of
>   
>>> the spanning tree moves around leading to non-optimal forwarding in
>>> enterprise networks. Enterprise networks are carefully engineered
>>> networks and in the event of failure, they want to localize the
>>> effects as much as possible. So, they want each VLAN to be localized
>>> and roots where they want it to be. Having a common VLAN messes up
>>> that arrangement. Also, VLAN 1 is the default VLAN when a switch
>>>       
> comes
>   
>>> up and there is typically lots of customer data on it.
>>>       
>>>> VLANs to *not* be partitioned. With TRILL, if a customer eventually
>>>> replaces
>>>> all bridges, the customer will not be able to partition VLANs
>>>>         
> anymore.
>   
>>> As I raised it in the meeting, this is a side-effect that has not
>>>       
> been
>   
>>> considered before and needs to be carefully thought through. I don't
>>> think many people are aware of this issue with TRILL that doesn't
>>> exist with 802.1Q bridges today.
>>>       
>>>> 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.
>>>>
>>>>         
>>> GVRP is not deployed by a significant majority of customers.
>>>
>>> Dinesh
>>>
>>>       
>
>