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

[Dhamija Amit]

Hi Adam/Phil

I still have a one concern as per Phil with Per Link you can get Node protection also in some cases depends upon topology.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.

Also i am unable to understand the difference like if i say per prefix router will do SPF computation i.e it tries to find out LFA candidate for each and every prefix in router local IGP routing table.

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.

Thanks
Amit Dhamija


--- On Wed, 6/5/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: "'Phil Bedard'" <philxor at gmail.com>, "'Dhamija Amit'" <amiitdhamija at yahoo.com>, cisco-nsp at puck.nether.net
> Date: Wednesday, June 5, 2013, 1:14 PM
> The presentation is really good
> thanks Phil,
> 
> Right so the per-link LFA computation requires an LFA
> candidate to have
> connectivity to primary next-hop node. 
> So if C would not have valid upstream link to D via F it
> would not be
> considered an LFA candidate right? 
> 
> In other hand if C happens to have a best-path link to D
> (since this is not
> mpls-te and each node on the path makes an independent
> routing decision) if
> C receives traffic destined for D it will forward it
> according to the
> best-path decision to D directly avoiding the original
> primary next-hop F. 
> 
> One think that got my eye is the sentence that the backup
> next-hop must be
> valid for all the prefixes using the particular primary
> next-hop. 
> That restrains the backup path selection for per-link LFA
> even more.
> 
> Since I haven't found that in the presentation I'll mention
> it here for
> further reference. 
> On XR:
> Line-card disjoined considers bundle interfaces as line-card
> disjoined
> interfaces. 
> Also if you start tweaking the default tie-breakers the
> default tie-breakers
> are not considered anymore. 
> So if you'd like to let's say move "lowest backup metric"
> before "line-card
> disjoined" by changing its default index to 20 you have just
> deleted all the
> other tiebreakers. 
> That is to modify the list somehow you have to mention all
> the tiebreakers
> you'd like to be considered with index values defining their
> priorities as
> tiebreakers not specified are not considered. 
> 
> 
> Per RFC 5286
> Inequality 1: Loop-Free Criterion
> Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S,
> D)
> 
> Inequality 3: Criteria for a Node-Protecting Loop-Free
> Alternate
> Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E,
> D)
> 
> So yes for per-link LFA the inequality 1. would be enough. 
> Though for per-prefix LFA with node-protection also
> inequality 3. has to
> hold true for the LFA candidate to be considered for node
> protection. 
> 
> 
> adam
> 
> 
> 
>