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 [email protected] On Mon, Dec 18, 2017 at 4:23 PM, Alia Atlas <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/trill > _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
