Hi Ramkumar, On Mon, Nov 28, 2016 at 2:50 AM, R Parameswaran <[email protected]> wrote: > > With regard to draft-rp-trill-parent-selection-01, this email tries to > answer the question posed at the mike at IETF 97 Trill meeting - how does > this draft relate to draft-ietf-trill-resilient-trees? > > This is examined below from two different considerations - overlap and > extensibility. > > In summary, there is not much direct functional overlap between the two drafts > that I can see, and draft-rp-trill-parent-selection-01.txt could possibly be > extended to handle backup DT calculation for node failure scenarios. Details > of these are broken out below: > > A. Considerations for Overlap: > > At a high level, draft-ietf-trill-resilient-trees relates to link > protection, and > defines the notion of a primary distribution tree (DT) and a backup > distribution tree, > where these trees are intentionally kept link disjoint to the extent possible, > and the backup tree is pre-programmed in the hardware, and activated upon > failure of the primary distribution tree.
I believe that is correct. > draft-ietf-trill-resilient-trees considers the following algorithmic > approaches > to the building the backup distribution tree: > > 1. Pure operator config for links on the backup DT/manual generation of > affinity sub-TLV - this is very tedious and unlikely to scale or be > implemented > in practice, and hence is disregarded in the analysis here. > > 2. Section 3.2.1.1a: Use of MRT algorithms (which will produce conjugate > trees - > link disjoint trees with roots for primary and backup trees that > are coincident on the same physical rBridge). > > 3. Section 3.2.1.1b: Once the primary DT is constructed, the links used in the > primary DT are additively cost re-weighted, and a second SPF is run to > derive the links comprising the backup DT. Affinity sub-TLV is used to > mark links on the back-up DT which are not also on the primary DT. This > approach can handle conjugate trees as well as non-conjugate trees (link > disjoint trees that are rooted at different physical nodes). > > 4. Section 3.2.2: A variation on the section 3.2.1.1b approach, but without > affinity sub-TLV advertisement. Once the primary DT is constructed, costs > for links on the primary DT are multiplied by a fixed multiplier to prevent > them from being selected in a subsequent SPF run, unless there > is no other choice, and the subsequent SPF yields links on the backup DT. > > All of the approaches above yield maximally link disjoint trees, when applied > as prescribed. > > Approach 4 above does not seem to use affinity sub-TLVs and instead seems to > depend upon a network wide agreement on the alternative tree computation > algorithm being used. > > Approaches 2 and 3 uses affinity sub-TLV on the backup DT, for links that are > not already on the primary DT. The primary DT does not appear to use affinity > sub-TLVs. Additionally, from an end-to-end perspective the backup DT comes > into picture when the primary DT fails (this is effectively true even in the > 1+1 protection mechanism and in the local protection case), and then again, > only until the primary DT is recalculated. Once the primary DT is > recalculated, the backup DT is recalculated as well, and can change > corresponding to the new > primary DT. > > draft-ietf-trill-resilient-trees cannot directly prevent/mitigate a > parent node shift > on the primary DT at a given parent node, and while usage of the affinity > sub-TLV on the backup DT might confer a parent affinity on some nodes > on the backup DT, these are not necessarily the nodes on which the > network operator > may want/prefer an explicit parent affinity. Further, the backup DT is > only used on > a transient basis, from a forwarding perspective. > > Given the above, I don't see much of a functional overlap between > draft-ietf-trill-resilient-trees, and the draft-rp-trill-parent-selection-01 > draft. OK. > The two drafts can probably co-exist (personal opinion) as they have different > goals, and solve different problems. Maybe its good to have some text in one > of them, explaining the relationship to the other. Since trill-resilient-trees is much further along in the process, it might be better to add any such text to trill-parent-selection. > B. Extensibility considerations: > > As called out in section 3, draft-ietf-trill-resilient-trees focuses on link > protection. However, the draft alludes to the possibility of using backup DTs > for node protection, but considers it out of scope, while calling out some > problems with doing so. > > On the other hand, draft-rp-trill-parent-selection-01 does not explicitly > define the notion of a backup DT, and focuses on protecting parent child > relationships on the primary DT, but possibly can be extended to define the > notion of a backup DT for node protection. > > In draft-rp-trill-parent-selection-01, if a sibling of the configured parent > node (the node on which child affinity was explicitly configured) goes down, > there is not much point in computing the backup DT corresponding to the downed > node, because the forwarding state on the configured parent, and on other > nodes in the network, will not change because of the already imposed affinity > sub-TLV, binding the child nodes listed in the affinity sub-TLV to the parent > originating the affinity sub-TLV, regardless of the presence or absence of the > sibling node. > > But, implementations may need to take care to not disturb the hardware > programming already in place, while the tree computation reconverges to > (nearly) the same outcome as the prior computed tree, when the sibling > node goes down. > > However, in the case where the parent node on which child affinity was > configured goes down, it makes sense to configure a back-up DT with simply the > Trill default parent selection rules, but with the tree calculation now > excluding the configured parent node with the child affinity. The > backup DT can be > pre-programmed, and when the configured parent node is seen to go down, > its affinity sub-TLVs can be discarded, and hardware programming can switch to > forwarding with the backup DT state. > > There are other considerations that need to be thought through (e.g > what if any other node (not parent, not sibling) goes down - do we > need a backup tree?) , but > draft-rp-trill-parent-selection-01 can possibly be extended in this > direction if there > is interest in pursuing this further. In any case, feedback is welcome. Those are some interesting ideas. We could probably work on the after/if the draft is adopted by the WG. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] > thanks, > Ramkumar _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
