Subject: [rbridge] Notes on draft-touch-trill-prob-00

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 06 Dec 2005 16:00:14 -0800

Some of my own comments below:

Harald Tveit Alvestrand wrote:
> Summary:
> 
> Good start. Much to be done.
> 
> - Key issue:

I've added these to the 'list of issues' for this doc.

Some of the other details raised issue-level items; others are more
edit-level. I'll send a more detailed summary of which are which in a
few days.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 06 Dec 2005 16:59:42 -0800

Hi, all,

There have been a few responses, most recently Harald's, which suggest
we start a list of issues for the problem statement doc. Here's a first
cut - not intended to be complete, but a reasonable start (I hope).

I propose that if you want to discuss an issue, please post a note with
the following subject (e.g.):

	PS issue #3
	ARCH issue #4

That'll help us track things until (and if) we use a proper issues tracker.

PLEASE POST ANY ISSUES I MISSED as "PS issue NWE" or "ARCH issue NEW" ;
I will assign numbers to them and post the master list at
www.postel.org/rbridge

These lists are posted there (in a few minutes) as well...

Joe

- -----------
PS issues:

#1 which version of ethernet is the baseline?
	STP, RSTP, VLAN, provider bridges, wireless,
	shortest path bridging, etc.
	(this will help us determine what terminology to use)

#2 should the solution apply to current ethernet scales or not?
	and if so, what are current ethernet scales?
	Harald proposed as a starting point:
	* 1000 end-hosts in a single bridged LAN of 100 bridges
	* 100.000 end-hosts inside 1000 VLANs served by 10.000 bridges

#3 IF size is an issue...
	what limits the size? STP/RSTP or broadcast traffic, or both?

#4 delivery requirements:
	a) is in-order required?
	b) is no-duplication required?

#6 address MSTP regions (esp sec 2.2)
	as a way to limit STP scale/reconfiguration
IEEE 802.1Q  Multiple Spanning Tree Protocol.
Tutorial available : "Understanding Multiple Spanning Tree Protocol" at
www.cisco.com

#7 differentiate between host reattachment effects
   and bridge reattachment effects; the latter impact the STP more

#8 discuss broadcast vs. subnet broadcast vs. multicast support
	who gets a copy of multicast? all ports, or just subscribed?

#9 which addresses are not forwarded? (related to ARCH #1)

Bridge Group Address 01-80-C2-00-00-00 , used for frames transporting
BPDUs
Pause Frame address 01-80-C2-00-00-01.
Besides I am not sure but addresses 01-80-C2-00-00-00 to 01-80-C2-00-00-0F

#10 use campus (seemed to be agreement at the meeting)
    or use "pool" or "set"

#11 internal/external, inside/outside terminology
    there is one objection to these terms as topological;
    the draft intends to define them sufficiently
    does this need to be addressed further?

#12 address VLAN configuration requirements

#13 need configuration time examples
    e.g. references to published research and a summary that shows how
    small changes can have large effects

#14 add risks of TRANSPARENT (larger trees, slower to converge, etc.)

#15 sec 2.3 should be more clear about referring to computing backups to
use in case of failure - not that extra links makes routing easier.

======================================================================================

ARCH ISSUES

#1 resolve recommendations for the three modes of BSTP messages:
   (is this part of the PS or ARCH?)
	participate
	forward
	block

#2 is an rbridge the DR of the edge STPs?

#3 do rbridges have proxy bridges at their edges (see Radia's post of
10/21/2005)?
(see Guillermo's text below)

#4 Giullermo's subcase?
   address interior packets to egress rather than next-hop
   (isn't egress also in there, in the inner shim header?)

#5 change 'external protocols' section to 'interaction with 802.1D'

- -----

Guillermo's text for ARCH #3:

RBridge indirect participation in bridged island spanning tree.
- ---------------------------------------------------------------
RBridges by default do not participate in spanning tree in other way
than ignoring received BPDUs. It is an objective of RBridge
specification to be independent of bridges specifications as much as
possible.

However it may be convenient for RBridges in some circumstances to
participate in the spanning tree and contend to be root bridge of the
spanning tree formed in the bridged island they are attached to. In
these cases it is possible to build a device that's logically the same
as a bridge glued onto an RBridge. The following schema applies:

                        ?-----------?
       bridged island-----B1----RB1 ?
                        ?-----------?

                        RBridge/bridge box

where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1,
and a link to the bridged LAN. The "RB1" portion of this box acts as an
standard RBridge, it neither forwards, nor initiates spanning tree
messages. The "B1" portion acts as two-port standard 802.1D bridge, and
does participate in spanning tree. Its priority for root election can be
set in the standard way. To minimize configurafion, it may be convenient
in some implementations to make the standard B1 bridge priority a
function of the configurable RBridge priority for IS-IS Designated
RBridge election. In this way Designated RBridge will participate and
contend (as B1) to be elected also as root bridge of the bridged island
and only one priority configuration is required.

If (in environments using such implementations) the default bridge
priority for B1 is lower than standard bridge priority, by default
RBridges/bridges like B1 shown will become roots of their bridged
islands, contending only with other RBridges connected to same island
for root election. It is not mandatory for RBridges be
combined bridge/RBridges.

- -------