Hi,

--94eb2c0d13649979d10562e8599f--

I've reviewed this draft in lig=
ht of Alia's comments and have comments as follows:

- I= t should be clearer that each primary distribution tree may have at most on= e back-up tree associated with it. This is controlled by the highest priori= ty root bridge RBridge which specified the roots of the back-up trees. =
- Behavior of an RBridge RB2 for multi-destination frames ingressed at RB= 1 depends on the protection mode of operation of RB1, particularly the diff= erence between 1:1 and 1+1. Thus, either every RBridge in the campus must b= e configured with information about the mode of protection being used by ev= ery other RBridge (or at least every ingress RBridge) or RBridges must sign= al what mode they are using. It seems much more in keeping with TRILLs phil= osophy to use signaling which could, for example, be accomplished by use a = 2-bit field in the Extended Capabilities which would be zero if no protecti= on is supported and various non-zero values for various protection modes.
- I think the method given in the draft for calculating a back-up tree= is reasonable and will provide substantial protection although it does not= guarantee that the primary and backup trees are maximally disjoint and sho= uld not claim that.
- Due to the TRILL RPF check, local protection se= ems limited to RBridges where the primary and backup trees fork.

Thanks,

Donald

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= =C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)

=C2=A0155 Bea= ver Street, Milford, MA 01757 USA

=C2=A0d3e3e3@gmail.com

Donald

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= =C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)

=C2=A0155 Bea= ver Street, Milford, MA 01757 USA

=C2=A0d3e3e3@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=C2=A0draft-i= etf-trill-resilient-trees-08. First, I would like to thank the aut= hors Mingui, Tissa, Janardhanan, Ayan, and Anoopfor their work o= n this document.=C2=A0=C2=A0Unfortunately, I have= several serious concerns about this document.Fir= st, 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 t= he root of the primary distribution tree - but I see no indication of what = decides which the root is.=C2=A0 Perhaps it is the root of the primary dist= ribution tree?=C2=A0 =C2=A0 What is computing the backup distribution trees= ?=C2=A0 My assumption is that each RBridge does.=C2=A0 Can=C2=A0 a backup d= istribution tree be associated with only one primary distribution tree?=C2= =A0Second, I don't believe that the suggested= algorithm of raising the link costs for links used in a primary distributi= on tree will work to find maximally disparate paths.=C2=A0 Consider the sim= pler case with Suurballe's algorithm=C2=A0 (https://en.wikip= edia.org/wiki/Suurballe's_algorithm ) that is just looking for = 2 disparate paths.=C2=A0 =C2=A0In that example, the shortest path is A-B-D-= F which gives no disjoint path between A and F - but different pairs of pat= hs are possible.Obviously MRT (RFC7811) solves th= is 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.= =C2=A0 There may be a bit of work to be done - but it is similar to other p= roxy nodes used in RFC7811 and RFC7812.You ma= y have different solutions - and that is fine - but failing to fully specif= y an algorithm and having what is specified not work is not ok.<= br>Third, pulling back and clearly explaining the different piec= es of this technology is badly needed.=C2=A0 For instance:=C2=A0= =C2=A0 (a) The root for a multicast distribution tree computes a backup di= stribution tree and identifies the root to use.=C2=A0 =C2=A0 (b)= A PLR determines the backup distribution tree (how?)=C2=A0 =C2= =A0 (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 (??)=C2=A0 =C2=A0 (d) Is traffic looked for on th= e backup distribution tree?=C2=A0 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 th= ere any implementations of this draft?Regards,Alia

_______________________________________________

trill mailing list

trill@ietf.org

https://www.ietf.org/mailman/listinfo/trill