[rbridge] Notes on draft-touch-trill-prob-00
Harald Tveit Alvestrand
harald at alvestrand.no
Fri Nov 25 06:39:30 PST 2005
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
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
- 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
- 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
- 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20051125/eecfc779/attachment.bin
More information about the rbridge