Stewart proposed in another thread making this algorithm text part of an appendix (see snippet below.) I want to emphasize the importance of adding more quantitative content to the normative sections of the text, by illustrating an example of the confusion created by some of the current text.
Today I was in a discussion regarding the criteria for evaluating for use as a tunnel endpoint, a node Y in extended-P space which is reachable from source S by way of S's neighbor N1. Some confusion arose during the discussion over whether or not the node Y should be rejected for consideration if policy had been applied rejecting N1 as a (local)LFA for reaching Y. We agreed that the evaluation of Y as a tunnel endpoint for remote LFA should not depend on the policy applied to the (local)LFA to reach Y. However, the text below in section 4.2.2 leads to confusion on this point. "Another way to describe extended P-space is that it is the union of ( un-extended ) P-space and the set of destinations for which S has a per-prefix LFA protecting the link S-E." I think this text should be removed and replaced with precise quantitative criteria for membership in extended P-space. It is likely that remote LFA will be deployed together with (local)LFA with policy determining which type of alternate to use (draft-litkowski-rtgwg-lfa-manageability). Describing remote LFA in terms of (local)LFA will create confusion for someone trying to apply policy. Quantitative criteria avoid this confusion. If this text creates such confusion among experts, it is likely to create even more confusion among end-users of the technology, when trying to figure out what is really going on in their network. While one might argue that this behavior is up to the vendor to document, confusing text in the base rlfa draft will make that task much more difficult. --------- A response to this algorithm text showed up in another thread so I am cutting and pasting Stewart Bryant's response from 10/2/13 to this thread to keep things organized. [SB] "I plan to put in the algorithm text, although having discussed this with Mike, our inclination is to include this as an appendix since it is not required for interoperability that you do the computation that way." --------- Chris From: [email protected] [mailto:[email protected]] On Behalf Of Chris Bowers Sent: Wednesday, September 04, 2013 4:22 PM To: [email protected] Subject: algorithm description for draft-ietf-rtgwg-remote-lfa As has been pointed out in other email threads, the current version of draft-ietf-rtgwg-remote-lfa-02.txt lacks a formal description of the algorithm being proposed. Below is a such a formal algorithm description, based on my reading of the current draft. It would help progress this draft forward if the authors would correct any errors in this pseudo-code representation of the algorithm. The pseudo-code below avoids unnecessary SPF computations, but for the sake of readability, it does not otherwise try to optimize the code. Remote LFA algorithm Compute_and_Store_Forward_SPF(node root) Compute_Forward_SPF(root) foreach node z in network store D_opt(root,z) Compute_and_Store_Reverse_SPF(node root) Compute_Reverse_SPF(root) foreach node z in network store D_opt(z,root) Compute_Neighbor_SPFs() foreach interface intf in self if (intf.remote_node != fail_intf.remote_node) Compute_and_Store_Forward_SPF(intf.remote_node) Compute_Extended_P_Space() foreach node y in network y.in_extended_P_space = false if (D_opt(self, y) < D_opt(self, fail_intf.remote_node) + D_opt(fail_intf.remote_node,y)) y.in_extended_P_space = true foreach interface intf in self if (intf.remote_node != fail_intf.remote_node) if ( D_opt(intf.remote_node, y) < D_opt(intf.remote_node, self) + D_opt(self,fail_intf.remote_node) + D_opt(fail_intf.remote_node,y) ) y.in_extended_P_space = true Compute_Q_Space() Compute_and_Store_Reverse_SPF(fail_intf.remote_node) foreach node y in network if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + D_opt(self,fail_intf.remote_node) ) y.in_Q_space = true else y.in_Q_space = false Intersect_Extended_P_and_Q_Space() foreach node y in network if ( y.in_extended_P_space && y.in_Q_space ) y.valid_tunnel_endpoint = true else y.valid_tunnel_endpoint = false Apply_Downstream_Constraint() foreach node y in network if (y.valid_tunnel_endpoint) Compute_and_Store_Forward_SPF(y) if ((D_opt(y,dest) < D_opt(self,dest)) y.valid_tunnel_endpoint = true else y.valid_tunnel_endpoint = false Compute_Neighbor_SPFs() Compute_Extended_P_Space() Compute_Q_Space() Intersect_Extended_P_and_Q_Space() if (guarantee_no_looping_on_worse_than_protected_failure) Apply_Downstream_Constraint() ********** I would also like to propose that the following text to be inserted after the last paragraph of section 4.2.1. "Computing Repair Paths". It should be noted that using the Q-space of E as a proxy for the Q-space of each destination can result in failing to identify valid remote LFAs. The extent to which this reduces the effective protection coverage is topology dependent. *********** Thanks, Chris
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
