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

Hi Alia,

Thanks for your review and comments. We'll see what we can do to
improve the draft.

Donald (document Shepherd)
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Mon, Dec 18, 2017 at 4:23 PM, Alia Atlas <akatlas@gmail.com> wrote:
> 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
>
>
>
>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>