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

[Harald Tveit Alvestrand]

Summary:

Good start. Much to be done.

- Key issue: Are you baselining "the current Ethernet" off 802.1D-1998 
(with the STP protocol), 802.1D-2004 (with the RSTP protocol), or are you 
thinking about some network that incorporates devices of both types? I 
couldn't tell.
Also, the problem statement does not mention VLAN (802.1Q - another moving 
target - current version is -2003). Where does it fit?

- Key issue: Should we attach strict numbers to the "should scale as large 
as current Ethernet solutions"? I'd like to have the numbers in there 
somewhere (very round numbers), like saying the protocol MUST function 
effectively in deployments of:

 * 1000 end-hosts in a single bridged LAN of 100 bridges
 * 100.000 end-hosts inside 1000 VLANs served by 10.000 bridges

Those numbers were pulled from a hat - but naming numbers works better at 
pointing out whether we agree or just think we do.....

Details, dumped while I read through the document:

- Section 1: I think "host reattachment" doesn't affect the STP convergence 
at all; it is bridge reattachment that does you in. Host reattachment 
matters because of the time required to "unlearn" MAC addresses - but 
that's a different issue than STP.

- Section 1, term "Ethernet link subnet" - I think the 802.1D-2004 term is 
"Bridged Local Area Network" - 802.1D uses "Network" to refer to a bridged 
net and "LAN" to refer to a non-bridged component of that network. I think 
we should avoid inventing terms unless we have to.

- Section 1: I think "operating at the link layer" should be "offering an 
Ethernet service" - with a reference to IEEE 802-2001 section 7.1 for a 
defintion of what that is. (That's a reference to ISO/IEC 15802-1; you're 
caught in a twisty little maze of standards, all interdependent...)

- Section 2.1: The diagram becomes less untidy if you switch the bridges 
marked A and B - then, lines don't cross....

- Section 2.4: I don't think STP is the main culprit limiting the size of 
an Ethernet domain, and we shouldn't say that it is; I think that with 
normal hosts, it's the broadcast traffic that matters most..... other 
opinions?

- Section 2.4: I can't parse "grouped modularity". Rephrase?

- Section 3.1, "No change to Link capabilities", should mention the 
ordering and duplication guarantees of Ethernet: in-order delivery and no 
duplicated packets.

- The way section 3.2 reads now, it looks as if you want to autoconfigure 
VLANs. While that may be possible for inter-bridge bridges (.1Q ports), I 
don't think it's possible for bridges with end-user ports. Note that 
letting ports autoconfigure to .1Q is a security risk! We should probably 
move this mention to the section (3.6) on how we want to deal with VLANs - 
too many different issues, interwined.

- Section 3.3: I wouldn't call TTL "loop avoidance", it's more like "loop 
effect mitigation".

- Section 3.4: May want to be explicit again that we want to require 
absolutely no modification to bridges running (R)STP.

- I don't think section 3.7 adds much... and I think the main point is 
equivalence *as seen from the end-users*.

- section 3.9: the more important issue that makes stealing the IP TTL 
field impossible is that there is traffic that is not IP....

No promise that this is anywhere near a final set of comments. But I 
thought it would provide value to the participants to share these now.

                   Harald






-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20051125/eecfc779/attachment.bin