Following up on an item discussed in the meeting. We agreed that the paragraph in section 4.2.2 (see below) that describes extended P-space in terms of (local)LFA should be removed because this alternative description may confuse the reader more than it enlightens.
Chris From: [email protected] [mailto:[email protected]] On Behalf Of Stewart Bryant Sent: Friday, November 01, 2013 9:46 AM To: [email protected]; [email protected] Subject: Re: candidate-draft-ietf-rtgwg-remote-lfa-03.txt ----------------- Snip ----------------- 4.2.2. Extended P-space 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.e. the repair tunnel end point can be reached either directly or using a per-prefix LFA. [SLI] Lack of precision about independancy of rLFA and LFA alternate choice is rLFA is using extended P space node. I would propose : "Even if extended P-space would be composed on nodes reachable through a per-prefix LFA, this does not conclude that the rLFA would inherit the best LFA to reach the PQ: rLFA an LFA MUST be completely independant. In other words, if S has N1 and N2 as LFAs to protection a destination P, and S wants to use P as PQ to protect a destination D. S must be able to program N1 as LFA to reach P and P through N2 to reach D for manageability reasons (refer to Section 9)." SB> We are talking about different things. This is not about whether SB> or not we use LFA and RLFA together. This is another way SB> of expressing extended P-space. Extended P-space SB> is everything that E can reach on its own + everything that SB> it can reach by forcing the first hop to a directly connected SB> neighbour - which is what a per-prefix LFA is. The SB> para is purely tutorial, and can be removed.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
