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/
