Subject: [rbridge] Comments on draft-ietf-trill-prob-01.txt

From: ddutt at cisco.com (Dinesh G Dutt)
Date: Mon, 06 Nov 2006 09:37:46 -0800

Hi,

Here are some comments based on the last call for 
draft-ietf-trill-prob-01.txt. Some general comments first.

- From my understanding of spanning tree, I think the document has 
multiple inaccuracies about the spanning tree protocol used in current 
802.1D bridges:
    - First, there is an assumption that there can be transient loops 
with spanning tree (Section 3.3). This is quite untrue. There is no 
chance of loops with spanning tree. There can be poor implementations or 
bugs that can cause loops, but spanning tree protocol itself cannot 
create loops.
    - Second, the convergence time of spanning tree is quite impressive 
these days, thanks to Rapid Spanning Tree (802.1w). It is in the order 
of sub-second.
    - Backup paths (section 2.3) have been deployed quite widely in 
Cisco switches using "uplinkfast" enhancement to STP.

- There is an incorrect use of terminology or concepts from IEEE 
standards. There has been extensive discussion on the mailing list about 
this. Some examples in this document:
    - Use of "cache", say in section 2.5. The correct terminology is 
"filtering database"
    - You talk about "autolearning" in section 3.1. I don't think the 
802.1D standard talks about "autolearning" What do you mean ?

More specific comments:

- You mention 802.1D as "Other Ethernet Extensions" (section 2.4) after 
having talked about spanning tree this far. 802.1D is the basic bridging 
standard and so is incorrect to refer to it under the section titled 
"Other Ethernet extensions".

- Section 2.4: There is no mention of other Ethernet protocols such as 
802.1au (Congestion Notification), 802.3ad (Link Aggregation), 802.3x 
(PAUSE). What is the relation of TRILL to these protocols ?

- Section 2.5:I don't know were these number come from, but with 256/512 
ports Ethernet switches available, it does not take 10,000 bridges to 
reach 100,000 nodes. I also don't understand if the mention of 1,000 
VLANs is intended as a limit. Many customers don't have enough of 4,000 
VLANs and deploy private VLANs.

- Section 2.5: You state: "Similar challenges exist in the ARP protocol, 
where link layer forwarding is not updated appropriately when nodes move 
to ports on other bridges. Again, the compartmentalization available in 
network routing, like that of network layer ASes, can help hide the 
effect of migration"

    I don't understand this para.

- Section 3.1: Please include that there must be support for non-IP 
protocols that are currently supported by Ethernet bridges.

- Section 3.2: Use of VLANs in TRILL needs to be clarified. For example, 
there can be a VLAN tag in the outer MAC header as well as the inner 
MAC. Again, this has been the subject of extensive discussion on the 
mailing list.

- Section 3.2: What about VLAN pruning ? Should that be supported as 
well by TRILL ?

- Section 3.3: Use of TTL alone isn't sufficient to fix problems caused 
by transient loops during topology changes. Again, this has been the 
subject of intense discussion on the mailing list. A form of interlock 
protocol must ensure that there are no transient broadcast or multicast 
loops during topology changes.

- Section 3.4: Interaction with spanning tree protocol as discussed 
under the subject "Traffic Storms" should be included here.

- Section 3.4: Please include RSTP in the list of protocols that cannot 
be modified. Current list is only STP & MSTP.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Nov 2006 15:59:57 -0800

Dinesh,

Thanks for your post.

Most should be easy to incorporate, so I trimmed them from the list.
Some notes/questions on others below:

> draft-ietf-trill-prob-01.txt. Some general comments first.
...
> (PAUSE). What is the relation of TRILL to these protocols ?

We haven't talked about them per-se. The 802.1 extensions are link
technology independent; the 802.3 ones do not appear to be (e.g.,
802.3ad seems GigE specific). I didn't think we were doing anything link
technology dependent.

I'm assuming control frames would be passed transparently, but I didn't
know whether we were requiring any of these on the paths inside the
rbridge, or whether they need to be interfaced to the routing protocols.

Any others have a position on this? IMO, 802.1* protocols are on the
table, but 802.3* ones shouldn't be if possible.

The goal is to support any frame that exists on an conventional ethernet
(D, D-2004, w, Q, Q-REV, v, s, etc. - though as far as I'm able to tell,
s is a supplement to Q, not subsumed in Q, and w is subsumed in D-2004).
This goes to your earlier question about support for other ethernet
control protocols, and your question below as well about VLAN pruning.

IMO, 802.1 D-2004 ought to be a minimum, but I'd add Q-REV, v, s

> VLANs and deploy private VLANs.

The numbers are intended to reflect current scales; the goal is to imply
that this is NOT about scaling better than existing solutions. I can
update the numbers, adjust the text to refer to them as approximate, or
both.

Again, any others have a position on this?

> MAC. Again, this has been the subject of extensive discussion on the 

Yes; how the two are handled should be addressed.

> - Section 3.2: What about VLAN pruning ? Should that be supported as 

Can you define "support"? Does this mean transparently-forward, or
participate in? I didn't expect such protocols to go beyond the ingress
unless they were transparently forwarded; I didn't expect us to tie
these protocols into the interior IP routing.

Comments from others?

> loops during topology changes.

TTL *must* be decremented before a packet is emitted; this can happen
before or after it is copied in multicast/broadcast. In that case (which
we might point out more explicitly), can you explain how TTL is not
sufficient?

> under the subject "Traffic Storms" should be included here.

A short summary would be useful, if you can provide one ;-)

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061106/ddcc05a4/signature-0001.bin