Hi Sherifsmail,
1- If we used IPFRR to protect MPLS traffic, does this mean there would be a label assigned to backup paths ?
There wont be any backup label assigned as such. When any node runs SPF, it exclude the node/link to be protected and identify the backup path to be used and use the label assigned by the node. See below,
R1------R2-------R3--------R4
\ |
\ |
R5--------------R6
Assume all link are with metric 1.
In the above toology, R1 uses R2 as nexthop to reach R4 due to lowest metric 3. It now identify the loop free alternate path. In simple words, the alternate nexthop should not use self as nexthop during normal or failure condition. In this topology, R5 qualifies the same. As it will not use R1 as nexthop. So R1 will mark R5 as backup path. It now update the local forwarding table with primary label to reach R4 as label assigned/advertised by R2 and mark the label assigned/advertised by R5 as backup label.
If yes then what the difference between this and LDP FRR (not supported on Cisco) as according to what I understand whole objective of LDP is to assign a label so if a label is assigned by IPFRR then technically they should be the same , correct ?
IPFRR is a technique that leverages LDP to tunnel (if required - in case of rLFA for example) the repaired traffic to backup node. Per my understanding, IPFRR and LDPFRR are 2 different naming terminology pointing to same technique - FRR without RSVP-TE.
Have read that IPFRR nearly offer 50msec for ~75% of the link failures
I believe this would be the case with pre-prefix protection (i.e. not per-link protection) , correct ?
LFA and rLFA helps provide FRR (around 50 msec protection) in around 75% failure. In some corner cases, this may not help.
Now If I am right is there a way to find out prefixes that were not protected by IPFRR ?
There is a show command that will let you know the backup path for each prefix.
HTH,
Nagendra
