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:[email protected]] Sent: Thursday, November 28, 2013 7:17 PM To: 'Phil Bedard'; [email protected]; 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 <[email protected]> To: 'Phil Bedard' <[email protected]>; [email protected]; Adam Vitkovsky <[email protected]> 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 <[email protected]> wrote: > From: Adam Vitkovsky <[email protected]> > Subject: RE: [c-nsp] Difference in IP FRR Link vs Per Prefix Option > To: "'Dhamija Amit'" <[email protected]>, "'Phil Bedard'" <[email protected]>, [email protected] > 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 > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
