[rbridge] Fwd: Re: WG Review: Transparent Interconnection of Lots ofLinks (trill)

[Greg Daley]

Hi Pekka, 

----- Original Message -----
From: Pekka Savola <pekkas at netcore.fi>
Date: Thursday, June 23, 2005 2:08 pm
Subject: Re: [rbridge] Fwd: Re: WG Review: Transparent Interconnection 
of Lots ofLinks (trill)

> On Wed, 22 Jun 2005, Manfredi, Albert E wrote:
> > But this seems to create confusion. Maybe I'm confused, but I don't
> > think TRILL is going after creating larger layer 2 nets at all, 
> right?> Just attempting to do something more clever than a 
> spanning tree for the
> > layer 2 catenet.
> 
> Maybe not intentionally, but I think that will be the result.  A 
> usage 
> case that has been shown has been a hospital whose network (with 
> thousands of hosts) is a single broadcast domain.
> 
> I think everyone can agree that instead of making such large 
> broadcast 
> domains, the network should be split up by routing instead.

Apart from this particular network, there has been a progression
of activities in IPv6, MAGMA etc, which aim at providing better
link size scalability (actually stability).

The availability of link-local multicast in IPv6 and multicast
snooping has effectively removed the broadcast domain size bottleneck
which was present in IPX, and to some extent in IPv4.

The bottleneck has begun to move to the spanning tree, which 
can benefit from hierarchical division, in order to isolate
the bulk of the network from low-reliability edge device failure.
 
This is not saying that trill is for making huge networks, 
but for the size networks people are likely to want to run, there
are stability (and possible scalability) advantages gained from
using a separate SPF core for shipping packets.

> While TRILL would "fix" the usage case above so that using a 
> single 
> broadcast domain would still "work", that would still be very bad 
> network design, and in the longer term, it would probably be 
> counter-productive.

That is if the goal is to make very large networks.
Within the Trill and Rbridge BoFs this was particularly mentioned
as not being a goal.

> (In our environment, what we've seen recently is *decrease* in the 
> size of broadcast domains/subnets due to the requirements to 
> isolate 
> and filter the traffic from other hosts at the site.  Using a 
> single 
> domain makes this security issue much worse.)

Certainly, there's a different security model for single LANs and
routed networks which provide configuration stability.
The cost is that you need to have per-subnet addressing assignments,
and additional configuration for the filtering.

In environments which do not require this level of differentiation 
between
classes of hosts (single security domain, for example) the cost of
dividing subnets seems to be a lot higher than plugging in a new trill
router.

It's reasonable that if Trill is adopted as a WG, its documents should
mention these restrictions (which are inherent to LANs rather than 
TRILL), but I don't see them as a reason to not develop rbridges,
since deployment scenarios vary widely.


Greg Daley