[trill] AD review of draft-ietf-trill-resilient-trees-08

[Alia Atlas <[e-mail]>]

As is customary, I have done my AD review
of draft-ietf-trill-resilient-trees-08.
First, I would like to thank the authors Mingui, Tissa, Janardhanan, Ayan,
and Anoop
for their work on this document.

Unfortunately, I have several serious concerns about this document.

First, and most importantly, there is not a clear and mandatory algorithm
for computing the backup distribution trees that is given. Sec 3.2.1.1
provides a recommendation that is still not fully specified.
I do see the idea that the root of a backup distribution tree need not be
the same as the root of the primary distribution tree - but I see no
indication of what decides which the root is.  Perhaps it is the root of
the primary distribution tree?    What is computing the backup distribution
trees?  My assumption is that each RBridge does.  Can  a backup
distribution tree be associated with only one primary distribution tree?

Second, I don't believe that the suggested algorithm of raising the link
costs for links used in a primary distribution tree will work to find
maximally disparate paths.  Consider the simpler case with Suurballe's
algorithm  (https://en.wikipedia.org/wiki/Suurballe's_algorithm) that is
just looking for 2 disparate paths.   In that example, the shortest path is
A-B-D-F which gives no disjoint path between A and F - but different pairs
of paths are possible.

Obviously MRT (RFC7811) solves this issue - and it is possible to have
different roots for the RED and BLUE trees by simply creating a proxy node
that attaches to the potential roots.  There may be a bit of work to be
done - but it is similar to other proxy nodes used in RFC7811 and RFC7812.

You may have different solutions - and that is fine - but failing to fully
specify an algorithm and having what is specified not work is not ok.

Third, pulling back and clearly explaining the different pieces of this
technology is badly needed.  For instance:
    (a) The root for a multicast distribution tree computes a backup
distribution tree and identifies the root to use.
    (b) A PLR determines the backup distribution tree (how?)
    (c) Each RBridge computes its part of the backup distribution tree - by
pinning specific links into the backup distribution tree as advertised as
affinity links (??)
    (d) Is traffic looked for on the backup distribution tree?  How does a
merge point/receiver make that decision?

Some of these details are in the draft - but it is quite hard to pull out
clearly.

Are there any implementations of this draft?

Regards,
Alia