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

[Adam Vitkovsky]

Hi Amit,

Now I guess I see what you mean. 

Well I don't see a reason for inequality 2 to hold true. 

The only rule should be that N is not considering S as possible next hop
towards D (i.e. going backwards creating loop) if that holds true that N is
a LFA on the path from S to D. 

 

 

adam

From: Dhamija Amit [mailto:amiitdhamija at yahoo.com] 
Sent: Thursday, November 28, 2013 7:17 PM
To: 'Phil Bedard'; cisco-nsp at puck.nether.net; Adam Vitkovsky
Subject: Re: [c-nsp] Difference in IP FRR Link vs Per Prefix Option

 

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
> 
>