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

Hi Mingui,

I have reviewed the updated draft and still have serious concerns.

1) In Sec 5.3: "Due to the  multi-destination RPF check in TRILL,
local protection can
   only be used at a fork point where the primary and backup trees
   diverge and the set of nodes downstream is identical for both paths.
   If these conditions do not apply, local protection MUST NOT be
used." was added.

But even the example in Figure 4.1 doesn't yield such a set of nodes
downstream that is identical for both paths from any node!

2) Sec 3.2.1: " But it is desirable that every RBridge independently
computes Affinity Links for a backup DT across the whole campus."

   That may be - but there is NO ALGORITHM that describes how an
RBridge would independently compute the Affinity Links.

   There isn't even a description of why an RBridge would declare an
affinity link!  Are you trying to make sure that certain links are
included

   in the backup tree???  Also in Sec 3.2.1, I see

"This document RECOMMENDS achieving the independent *backup tree*

*   determination* method through a
   slight change to the conventional DT
   calculation process of TRILL.
   Basically, after *After* the primary DT is calculated, the
   *every* RBridge will be aware of which links are used in that primary
   tree. When the backup DT is calculated, each RBridge increases the
   metric of these links by
   a proper value (for safety, it's recommended to use the summation
of all original link metrics
   in the campus but not more than 2**23), *2**23,* which gives these links a
   lower priority of being chosen for the backup DT by the Shortest Path
   First calculation. All links on this backup DT can be assigned as
   Affinity Links but this is unnecessary. *may not be necessary.* In
order to reduce the
   amount of Affinity Sub-TLVs flooded across the campus, only those NOT
   picked by the conventional DT calculation process SHOULD be announced
   as Affinity Links."

but it isn't clear

   (i) Does each RBridge compute the backup DT upon receiving the
Backup Tree APPsub-TLV that connects a backup DT

       to the primary DT by specifying the root?

   (ii) If each RBridge is already computing the backup DT by
adjusting the metric of all links in the primary DT,

        how could an RBridge determine to announce an Affinity Link
that "is not picked by the conventional DT

        calculation process".

   (iii) How would the backup tree be certain to have the same set of
downstream nodes to support the multi-destination

        RPF check?

3)  Sec 3.2.1 claims that MRT requires the same root for the trees.
Of course, it is fairly straightforward to have a proxy node connected
in an

inbound direction to all other nodes except an outbound direction to
the primary node, and then compute so that the two MRTs are in reality
rooted

at different nodes.  The point is NOT that you should use MRT (though
it would guarantee maximally disjointness) - but rather that you have
a

barely described algorithm that is going to fail to provide
disjointness in many topologies, and that has no way of guaranteeing
the conditions

that are claimed to be needed for the multi-destination RPF check.

I see no indication that there are implementations of this or modeling
of how well the algorithm will work.

The draft is seriously underspecified and I remain concerned that what
is proposed is at best unusable.

Given the planned time-frame to close TRILL by IETF 101, unless there
are implementations or serious modeling work for

algorithms behind this draft, I do not see a way forward in the TRILL WG.

I see that this draft was adopted by the WG in 2013.  I do not see any
discussion on the list of the draft since then -

until there were requested directorate views.  I do not see how this
draft is covered by the charter - though if there

were serious support behind this draft now and actual implementations
and modeling to show the coverage, I could be

persuaded that it is still relevant and there is enthusiasm to do the
needed work.

If so - then the draft can be taken to rtgwg for discussion as an
individual draft.

Regards,

Alia

On Mon, Jan 22, 2018 at 4:33 AM, Zhangmingui (Martin) <
zhangmingui@huawei.com> wrote:

> Hi Donald,
>
>
>
> Thanks a lot for your comments.
>
>
>
> An updated version has just been uploaded to address these comments.
>
>
>
> Mingui
>
>
>
> *From:* Donald Eastlake [mailto:d3e3e3@gmail.com]
> *Sent:* Wednesday, January 17, 2018 1:49 AM
> *To:* trill@ietf.org
> *Cc:* draft-ietf-trill-resilient-trees@ietf.org; Alia Atlas
> *Subject:* Re: [trill] AD review of draft-ietf-trill-resilient-trees-08
>
>
>
> Hi,
>
>
>
> I've reviewed this draft in light of Alia's comments and have comments as
> follows:
>
>    - It should be clearer that each primary distribution tree may have at
>    most one back-up tree associated with it. This is controlled by the highest
>    priority root bridge RBridge which specified the roots of the back-up trees.
>    - Behavior of an RBridge RB2 for multi-destination frames ingressed at
>    RB1 depends on the protection mode of operation of RB1, particularly the
>    difference between 1:1 and 1+1. Thus, either every RBridge in the campus
>    must be configured with information about the mode of protection being used
>    by every other RBridge (or at least every ingress RBridge) or RBridges must
>    signal what mode they are using. It seems much more in keeping with TRILLs
>    philosophy 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
>    protection 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
>    should not claim that.
>    - Due to the TRILL RPF check, local protection seems limited to
>    RBridges where the primary and backup trees fork.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-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
>
>
>
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>