[c-nsp] Difference in IP FRR Link vs Per Prefix Option

[Dhamija Amit]

Hi 
 
I am stuck in one of the scenario mention below:-
 
IGP is ISIS with default metric as 10
 
            P1-----P3
         /    |           |   \
PE1                       PE2
        \     |           |    /
          P2------P4
P1 & P2 - are ALU core devices
P3 & P4 - are Cisco IOS-XR/CRS&GSR.

P3& P4 makes PE2 & PE1 as LFA backup candidate without any issues.
P1 & P2 makes PE1 as LFA backup but doesn't make PE2 as LFA backup , however PE2 is meeting the ineqality 1.

I checked with ALU they are saying since PE2 is not meeting the inequality 2 it will not be consider as LFA backup.

So does it mean that for Link protection ( Inequality 1 & 2) both are required ??if that is the case why cisco is not considering inequality 2 . Could you please help.



Regards
Amit Dhamija




From: Dhamija Amit <amiitdhamija at yahoo.com>
To: 'Phil Bedard' <philxor at gmail.com>; cisco-nsp at puck.nether.net; Adam Vitkovsky <adam.vitkovsky at swan.sk> 
Sent: Thursday, June 6, 2013 10:37 PM
Subject: RE: [c-nsp] Difference in IP FRR Link vs Per Prefix Option


Hi Phil / Adams

Thanks so much for the clarity on Per Prefix vs Per Link

Best Regards
Amit Dhamija
 


--- On Thu, 6/6/13, Adam Vitkovsky <adam.vitkovsky at swan.sk> wrote:


> From: Adam Vitkovsky <adam.vitkovsky at swan.sk>
> Subject: RE: [c-nsp] Difference in IP FRR Link vs Per Prefix Option
> To: "'Dhamija Amit'" <amiitdhamija at yahoo.com>, "'Phil Bedard'" <philxor at gmail.com>, cisco-nsp at puck.nether.net
> Date: Thursday, June 6, 2013, 2:50 PM
> > 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. 
> Yes I believe per-link LFA is concerned only with inequality
> 1, if the
> chosen LFA node happens to have a better path to destination
> other than via
> primary next-hop than you'd get the advantage of node
> protection. 
> 
> 
> > 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. 
> 
> Well yes both flavors (per-link/prefix) will try to find a
> backup path for
> all prefixes in the link state database. 
> How I understood it is that per-link LFA will not run a full
> spf calculation
> which results in less probability of finding an LFA
> candidate and in
> addition to that it will select the first available LFA
> candidate and stop
> the calculation afterwards (which is fine since it's not
> concerned with
> inequality 3 anyways, so whatever it finds first is fine,
> according to the
> limited criteria). 
> 
> 
> > 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.  
> Yes I'd definitely recommend rLFA it's the best thing we
> have currently,
> however it runs on a fairly new code. 
> We did use te-tunnles as backup paths to get the rLFA
> behavior manually and
> it did provide full coverage in ring topologies. 
> But that was prior to migration to safe harbor 4.2.3 as it
> introduced a bug
> on this functionality. 
> 
> 
> adam
> 
>