[trill] Parent node shift draft - relationship to resilient trees draft.

[R Parameswaran <[e-mail]>]

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.


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.

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.

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.

thanks,

Ramkumar