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

[Silvano Gai]

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
> >