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

[Dhamija Amit]

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