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

[Adam Vitkovsky]

Hi Amit,

Not sure which router(s) is/are D(destinations) in your calculations. 

I rather refer to inequality 3 and its clear explanation in particular. 

 

Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D)

 

   If Distance_opt(N,D) = Distance_opt(N, E) + Distance_opt(E, D), it is

   possible that N has equal-cost paths and one of those could provide

   protection against E's node failure.  However, it is equally possible

   that one of N's paths goes through E, and the calculating router has

   no way to influence N's decision to use it.  Therefore, it SHOULD be

   assumed that an alternate next-hop does not offer node protection if

   Inequality 3 is not met.

 

 

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