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

[Phil Bedard]

I did test LFA in the lab with IOS-XR and Junos a few months ago but I had
a limited topology and didn't test a scenario where one prefix wouldn't
have a valid LFA and the other would when sharing the same primary
next-hop.   According to that presentation in IOS-XR if you have per-link
enabled it would result in no LFA for all prefixes using that primary
next-hop.   Cisco does recommend using per-prefix LFA.  While the RFC may
mention the per-link candidate LFA passing through the current primary
next-hop node, it doesn't always do so.

There are other scenarios where per-prefix can result in better efficiency
when the protecting node has links to multiple routers.

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.  

Phil 

On 6/6/13 5:01 AM, "Dhamija Amit" <amiitdhamija at yahoo.com> wrote:

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