Subject: [rbridge] STP and ISIS

From: michsmit at cisco.com ([email-masked])
Date: Wed, 21 Sep 2005 16:36:38 -0700

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
> 
> Tom Sanders wrote:
> > 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?
> 
> Yes, AFAIK.
> 
> > 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?
> 
> 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.

The statement above should be clarified as *known* unicasts do not
follow the spanning tree.  Unicast traffic for unknown destinations will
still follow the spanning tree.

Michael

> Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 21 Sep 2005 16:56:21 -0700

> still follow the spanning tree.

Agreed

The only reason unknown unicasts would follow the tree is because they
are broadcast - though the reason they are broadcast is not because they
are sent on broadcast addresses, but rather flooded because of lack of
knowledge of attached port.

Joe

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 22 Sep 2005 11:00:09 +0200

G. Ib??ez wrote:

I have a doubt since some time on VLAN configuration. One of the main 
aspects driving the routing bridges proposal is to be configuration 
free, like the transparent bridges, opposite to using  routers where IP 
addresses must be  asigned, administered and may change when the host 
moves in the network. However, VLAN configuration of bridges is an 
important aspect and effort, that prevents selfconfiguration of rbridges 
to be achieved. In the Rbridges draft (see extract below), this problem 
is skipped assuming the Rbridges are already configured with the 
information on which VLANs should be supported on which port.
Although the problem of VLAN configuration is complex to handle, by 
ignoring it we risk not to fulfill  one of the main requirements of 
Rbridges: zero configuration.
Regards
Guillermo

Extracted from draft:

"Support of VLANs does traditionally require configuration 
   of the bridges (or in this case RBridges) to know which links belong 
   to which VLANs. In theory some other mechanism might allow an RBridge 
   to know which VLANs should be supported on which port. The RBridge 
   design does not care how RBridges discover which VLANs are supported 
   by each of their ports, but for simplicity we assume here that 
   RBridges (like bridges) are configured with this information."

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 22 Sep 2005 17:09:35 -0700

Rbridges are supposed to work like bridges:

	- zero configuration for a single LAN
	- as easy (or hard) to configure for VLANs

They are not intended to be zero-config VLAN systems any more than
bridges are.

Joe

Guillermo Ib??ez wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

-------------- 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/20050922/d1074c54/signature.bin

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 23 Sep 2005 09:38:53 +0200

IMHO, with this restrictive interpretation of zero configuration we 
solve only half of the configuration problem.    
   Anyway, if this is the prevalent opinion, I suggest to add  this 
clarification  to the draft (zero configuration for single LAN, equal 
configuration for VLANs as standard bridges).
Guillermo

Joe Touch wrote:

>------------------------------------------------------------------------
>

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Fri, 23 Sep 2005 10:05:30 +0200

--On fredag, september 23, 2005 09:38:53 +0200 Guillermo Ib??ez 

> configuration for VLANs as standard bridges).

I think you could in theory get close to zeroconf for VLAN membership.
It would go something like:

- Device attaches
- Bridge broadcasts "who knows this guy" on a reserved "management" VLAN
- Some management function replies "I do - he's in vlan G"
- Bridge configures the port to that VLAN
  (or if no reply - to a "default" VLAN)

(For extra credits, work in where to add 802.1x authentication)

The only config on the bridge would be what answers to believe (security 
makes complete zeroconf impossible, but we all know that by now....)

But this mechanism would be completely orthogonal to what TRILL is about, 
of course. So this is not the right list to discuss it.

                       Harald

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 23 Sep 2005 10:33:27 +0200

Guillermo Ib??ez wrote :
  Your proposal is fine, but I think it only covers configuring per-MAC 
belonging to a VLAN, not per-port, and per-port  is the criteria to 
belong to VLAN most related with the bridges,  where the real splitting 
of the physical network into separate virtual networks is done.  Per MAC 
belonging to VLAN can be considered "external" to the bridge, as your 
proposal shows.
Guillermo

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 23 Sep 2005 07:20:59 -0700

While Harald's suggestion is interesting, IMO it would be part of an
rbridge only after it has been developed for bridges first.

This is not an rbridge issue.

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/20050923/6cf0dd36/signature.bin