Anyone familiar with FRR in either MPLS-IP or MPLS-TP (or both)?

I come from an MPLS-IP background, have never worked with MPLS-TP, but my new job is requiring me to learn about it. I came across some 4-5 year old internal documentation that I don't think is correct, but I don't know if it's incorrect because it's old and things have changed or if this documentation has always been wrong. I've tried to do some reading but have already spent maybe 2 hours on this and haven't found anything that would tell me one way or the other, and I don't want to spend too much more time on this right now, so if someone who knows FRR in MPLS-TP can chime in here that would be great.

The first thing I thought was odd was a warning that FRR could cause conflicts with ERP. I was told that in the MPLS-TP world FRR actually builds backup LSPs so they're ready in the event that a change in the path occurs. In my experience that wasn't the case in MPLS-IP.

I don't remember ever needing to look up an equivalent command in Cisco IOS, but for example in Alcatel TiMOS you could do a command show router mpls lsp <LSP ID> path <PATH ID> detail and the output would show you every hop and whether or not it had node and/or link protection. Example:

Actual Hops : 10.20.1.1, If Index : 2 @ n Record Label : N/A -> 10.20.1.2, If Index : 2 @ n Record Label : 131071 -> 10.20.1.4, If Index : 2 Record Label : 131071 -> 10.20.1.6, If Index : 2 Record Label : 131071 

... now maybe ALU was building backup LSPs in the background and simply grouping them under the one LSP being shown to the user, but I don't have ALU support where I am now so I can't go ask. So I accepted the answer I was given - that MPLS-TP does build these LSPs in advance - and moved on with my reading.

Next this internal documentation says FRR only protects the next segment/link or the next hop along the LSP, and that in order to protect later hops/links other workarounds are needed. Again, going back to the ALU command I just mentioned the output clearly showed whether or not there was node or link protection for every hop along the path (the @ and n in the output above).

So then I'm wondering if these differences are just due to vendor-specific implementations that don't exactly follow the RFCs or is this part of the FRR RFCs? In the very first RFC I can find regarding FRR (RFC 5286) I see this: "The alternate next-hop can protect against a single link failure, a single node failure, failure of one or more links within a shared risk link group, or a combination of these."

That RFC hasn't been obsoleted so I think I'm safe in thinking the internal documentation I'm reading is either incorrect or a vendor specific implementation, but to be certain I'd have to read about 250 pages of RFC docs. Hopefully one of you out there can narrow my search or has already been down a similar rabbit hole and can share your results?