Hi Donald, Please see inline:
On Tue, Dec 27, 2016 at 6:07 PM, Donald Eastlake <[email protected]> wrote: > 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. > [RP]: Thanks for the prior review and questions - I have picked this up, I have added text (largely derived from this email thread) under section 7 with an upload, posted as draft-rp-trill-parent-selection-02. regards, Ramkumar >> 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
