[trill] Shepherd review of draft-ietf-trill-revilient-trees-05

[Donald Eastlake <[e-mail]>]

I've review this draft and I have one big comment and number of
smaller comments:

Major Comment:
--------------

Backwards compatibility: The biggest problem that I see has to do with
backward compatibility. What happens if one or more RBridges in the
campus do not implement resilient trees? Or even do not implement the
Affinity sub-TLV? It seems like you need to be able to detect these
conditions and either adapt to them or not try to do the resilient
tree alternative distribution trees.  This is related to the
incremental deployment question. There is an Affinity sub-TLV support
bit in the TRILL-VER sub-TLV but this does not seem to be mentioned in
the document.  Note that at the beginning of 3.2.1.1 it says "it is
desirable that every RBridge independently computes Affinity Links for
a backup DT across the whole campus" which would require every RBridge
in the campus to implement resilient tress. So, while maybe some sort
of local repair can be done when the local RBridge support, I think
the global repair requires support throughout the campus.

It seems to me that either the document needs to be changed to either
(1) make support mandatory or (2) state that you don't try any of the
resiliency features (or at least the global ones) unless the
resilience is supported by all the RBridges (or at least all the
RBridges other than singly connected leaves). In either case, there
needs to be a capability bit (probably an Extended Capability bit) to
indicate resilient trees support. And you really have to provide for
"(2)" above because it will always be possible that you have a legacy
RBridge in a campus. (Of course, as a practical matter, it will
commonly be the case that all the RBridges in a campus support exactly
the same capabilities.)

I recommend that we NOT make resilient tree support mandatory. I think
that would be a substantial change and require a new WG Last Call.

Medium Comments:
---------------

Section 3.2 and subsections:

If you are going to provide for manually configured alternative tree
and automatically computer alternative trees and allow the root for an
alternative tree to be different from the root for the primary tree,
it seem to me that some RBridge (presumably the highest priority tree
root) needs to announce something like {primary tree nickname,
alternative tree nickname, flags} where flags could indicate manually
configured or automatically configured and have some spare bits for
future uses.

I don't think it makes sense to have two alternative algorithms, as
specified in 3.2.1 and 3.2.2, for automatically computing a maximally
disjoint alternative tree when the two algorithms are so similar.
Maybe it would make sense to have two radically different algorithms
if you could point to some circumstances under which each was superior to the
other. But if you are going to have multiple algorithms, it seems like
you need a way for some designated RBridge (the highest priority tree
root?) to announce what algorithm is in use and you would need
algorithm identifiers and a registry and ...  I do not think it would
be worth it to have all that mechanism. Of the algorithms in 3.2.1 and
3.2.2, I think I favor the one in 3.2.1 a little. (The one in 3.2.2 at
least would need a maximum cost to avoid link cost overflowing and
wrapping around.) I would suggest that the increment to link cost in
3.2.1 of the sum of the cost of all links in the campus is too
conservative. I think it would be adequate for the increment to be 1
plus the total cost of the highest leaf-to-leaf cost in the primary
tree.

Section 4.1 on pruning: Maybe it is just me, but I don't quite
understand why pruning for an alternative tree should be based on the
pruned primary tree. What exactly happens when a TRILL Data packet is
sent on an alternative tree? Presumably, the "egress nickname" field
is changed from the nickname designating the primary tree to the
nickname designating the alternative tree. So, generally, the packet
will be forwarded down the alternative tree and it seems to me that it
should be sent down any branch where there are RBridges interested in
the packet VLAN/FGL further down that branch. What does the primary
tree have to do with it except in the local repair case?

Minor Comments:
---------------

Title page: "Updates: RFC 6325" You are just supposed to list the RFC
number without "RFC" before it in Updates and Obsoletes items on the
front page. I guess the change required to RFC 6325 is in Section
5.3.1 about changing the egress nickname of a TRILL Data packet in
flight. This should be mentioned in the Introduction (probably at the
end of the Introduction).

Section 1, page 5, at the top: It sounds a bit like the repair of the
failed link itself. It's more like routing is being repaired by
bypassing the failed link.

Section 2.1, top of page 6: Should clarify that the Affinity Sub-TLV
is distributed in an LSP.

Section 2.1, at the end: I'm not really comfortable with saying you
"MUST NOT" declare an Affinity Link between non-adjacent RBridges.
Since such a declaration would just be ignored, it usually just means
some wasted LSP space, so I think it should be "SHOULD NOT".

Section 2.2: I think it might avoid confusion when you talk about
"removing incoming links" to say that outgoing links/adjacencies are
not removed. (The figure is clear.)

Section 5.2.1: Although it is fairly obvious, I think you should point
out that item 1 requires a very reliable and steady data packet stream.

Section 5.3: The last two sentences should be deleted. It says pretty
much the same thing in the first paragraph of Section 5.

Section 5.3.3: This walkthrough starts talking about RBridges but does
not indicate what Figure the reader should look at to follow what is
being said.

Section 5.4: The precision and the limits for the configuration of Ts
should be given.

Minor updates:
    The CMT draft has been published as RFC 7783.
    RFC 7180 has been obsoleted by RFC 7780.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]