Subject: [rbridge] STP and ISIS

From: toms.sanders at gmail.com (Tom Sanders)
Date: Wed, 21 Sep 2005 12:04:36 +0530

Hi,

Going through draft-perlman-rbridge-03.txt raised a doubt in my mind.
Please let me know if my understanding of the matter is indeed
correct:

As per the draft, spanning tree algos concentrate a lot of traffic on
certain links as it marks some ports as blocked and only the ones that
are in the forwarding state can pass traffic. But as per my limited
knowledge, wouldnt STP mark only the redundant links as blocked? If we
dont mark them as blocked, then wouldnt that result in transient
loops, etc.

Then the draft says that there are other issues as well because of
which the group has decided to use a link state routing protocol; more
specifically ISIS because of the advantages it offers against OSPF
(TLV encoded, runs over L2, etc).

So, is the proposal to totally do away with STP et. al and run only
ISIS instead? The spanning tree is then computed with the topology
information provided by ISIS. Is this correct?

If this is so, then we will once again mark some ports as blocked,
etc. How different is this from calculating the spanning tree via the
STP protocol?

Thanks
-- 
Toms.

---

From: mike at linx.net (Mike Hughes)
Date: Wed, 21 Sep 2005 13:06:52 +0100

--On 21 September 2005 12:04 +0530 Tom Sanders <toms.sanders at gmail.com>

> information provided by ISIS. Is this correct?

The proposal is to give a more optimal alternative for spanning tree in a
"campus" L2 network.

The problem with spanning tree, as you correctly assert, is that you end up
with blocked links. In more complex L2 topologies, you can end up with
significant numbers of blocked links. Blocked links = wasted bandwidth,
which is especially expensive/wasteful at something like 10Gig/nx10Gig.

Blocked links also mean sub-optimal, rather than shortest path, forwarding
within the network.

The proposal (almost) completely replaces STP within a "campus" L2 network
of switches/bridges. (I say almost, as it looks like a spanning tree will
still need to be used for things like network layer broadcast frames.)

It has the potential to be more efficient, and more elegant, as for known
unicasted frames, delivery will be done via the shortest/most optimal path.
The proposed encapsulation of payload will also add a TTL to manage
temporary forwarding loops during convergence.

While rbridge was originally concieved for managing redundancy and mobility
within a campus, I can think of other applications, such as within L2 metro
networks (like the one I operate) where moving to an L3 routed solution is
not an option.

Regards,
Mike
-- 
Mike Hughes     Chief Technical Officer  London Internet Exchange
mike at linx.net   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 21 Sep 2005 14:50:18 -0700

> information provided by ISIS. Is this correct?

Yes, AFAIK.

> etc. How different is this from calculating the spanning tree via the

The difference is that the spanning tree will be used only for broadcast
messages. There may also be more than one spanning tree, e.g., one per
origin. In either case, the spanning tree is NOT used for forwarding
unicast traffic; the ISIS-configured routing tables are.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050921/ab2521cc/signature.bin

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 22 Sep 2005 21:12:13 -0700

I agree with what Mike said, but just to clarify...although there are 
spanning trees computed in order
to send multicast packets, and packets for unknown destinations, and IP 
multicasts, the spanning
trees (yes, multiple ones) are computed from the information already 
distributed in the link
state protocol. There's no need for an extra protocol to compute a 
spanning tree.

Radia

---

From: dino at cisco.com (Dino Farinacci)
Date: Fri, 23 Sep 2005 13:06:21 -0700

>> state protocol. There's no need for an extra protocol to compute a 

    This should be a major goal of the solution space. Bridges need to stay
    simple and self-configuring. And we can achieve this with IS-IS.

Dino