I did test LFA in the lab with IOS-XR and Junos a few months ago but I had a limited topology and didn't test a scenario where one prefix wouldn't have a valid LFA and the other would when sharing the same primary next-hop. According to that presentation in IOS-XR if you have per-link enabled it would result in no LFA for all prefixes using that primary next-hop. Cisco does recommend using per-prefix LFA. While the RFC may mention the per-link candidate LFA passing through the current primary next-hop node, it doesn't always do so.
There are other scenarios where per-prefix can result in better efficiency when the protecting node has links to multiple routers. In IOS-XR 4.3.1 Cisco introduced rLFA (remote LFA) which when used in conjunction with LDP can greatly enhance coverage by bypassing spots where traffic may loop. Phil On 6/6/13 5:01 AM, "Dhamija Amit" <[email protected]> wrote: >Hi Adam/Phil > >I still have a one concern as per Phil with Per Link you can get Node >protection also in some cases depends upon topology.So it means with Per >link we can get node protection in some cased means it will see both >Inequality 1 & 3 if it gets 3 good enough otherwise 1 is a must. > >Also i am unable to understand the difference like if i say per prefix >router will do SPF computation i.e it tries to find out LFA candidate for >each and every prefix in router local IGP routing table. > >With Per Link router will do SPF computation for all the prefixes learned >through Primary next-hop so in terms of prefix coverage is concerned i >don't see any prefix is left for LFA candidate only point is with per >link is that all the prefixes with LFA will share the same backup path. > >Thanks >Amit Dhamija > > >--- On Wed, 6/5/13, Adam Vitkovsky <[email protected]> wrote: > >> From: Adam Vitkovsky <[email protected]> >> Subject: RE: [c-nsp] Difference in IP FRR Link vs Per Prefix Option >> To: "'Phil Bedard'" <[email protected]>, "'Dhamija Amit'" >><[email protected]>, [email protected] >> Date: Wednesday, June 5, 2013, 1:14 PM >> The presentation is really good >> thanks Phil, >> >> Right so the per-link LFA computation requires an LFA >> candidate to have >> connectivity to primary next-hop node. >> So if C would not have valid upstream link to D via F it >> would not be >> considered an LFA candidate right? >> >> In other hand if C happens to have a best-path link to D >> (since this is not >> mpls-te and each node on the path makes an independent >> routing decision) if >> C receives traffic destined for D it will forward it >> according to the >> best-path decision to D directly avoiding the original >> primary next-hop F. >> >> One think that got my eye is the sentence that the backup >> next-hop must be >> valid for all the prefixes using the particular primary >> next-hop. >> That restrains the backup path selection for per-link LFA >> even more. >> >> Since I haven't found that in the presentation I'll mention >> it here for >> further reference. >> On XR: >> Line-card disjoined considers bundle interfaces as line-card >> disjoined >> interfaces. >> Also if you start tweaking the default tie-breakers the >> default tie-breakers >> are not considered anymore. >> So if you'd like to let's say move "lowest backup metric" >> before "line-card >> disjoined" by changing its default index to 20 you have just >> deleted all the >> other tiebreakers. >> That is to modify the list somehow you have to mention all >> the tiebreakers >> you'd like to be considered with index values defining their >> priorities as >> tiebreakers not specified are not considered. >> >> >> Per RFC 5286 >> Inequality 1: Loop-Free Criterion >> Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, >> D) >> >> Inequality 3: Criteria for a Node-Protecting Loop-Free >> Alternate >> Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, >> D) >> >> So yes for per-link LFA the inequality 1. would be enough. >> Though for per-prefix LFA with node-protection also >> inequality 3. has to >> hold true for the LFA candidate to be considered for node >> protection. >> >> >> adam >> >> >> >> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
