Hello David
The central issue here is how IOS-XR interprets and conveys information in the CLI in accordance with RFC 4577. It’s a platform-specific behavior which is subtle (and only a sharp eye will catch it 
).
First, let’s look at each component of the operation and see how they fit together.
The OSPF LSA exchange over the sham-link makes the path look intra-area to all routers in that OSPF area. Your mention of T1/T2 which I assume you mean that the OSPF Route Type BGP Extended Community preserves whether a prefix originated from a Type 1 or Type 2 LSA at the source.
BGP VPN-IPv4 Advertisements. Independently, the PE still runs normal OSPF→BGP redistribution. For each OSPF prefix in the VRF, the PE generates a VPN-IPv4 route with:
- A VPN label (allocated for that prefix/VRF pair)
- BGP next hop = the advertising PE’s loopback
- OSPF metric, route type, and other extended communities preserved
The sham-link endpoint addresses themselves must also be advertised as host routes (/32) via BGP, without which the sham link can’t even come up.
Now here’s the key insight to what you’re seeing: RFC 4577 section 4.2.7.4 is explicit about what happens when OSPF’s SPF computes a best path through the sham link (paraphrased):
“If the preferred route for a given address prefix has the sham link as its next hop interface, then… when forwarding a packet, if the preferred route for that packet has the sham link as its next hop interface, then the packet MUST be forwarded according to the corresponding BGP route.”
In other words, OSPF may win the routing decision (because intra-area beats inter-area), but the actual forwarding must use the BGP/VPN label mechanism. The packet is then forwarded using two MPLS labels: an outer transport label (reaching the far-end PE’s loopback across the core) and an inner VPN label (identifying the destination VRF and prefix on the egress PE). P routers switch only on the transport label, and the egress PE delivers the packet to the correct CE, exactly as if it had traveled a real intra-area link.
This brings us to your observation: R5-XR is learning R3’s route via BGP, while R1 shows it as OSPF. Both are correct per the RFC. It’s a display choice, not a forwarding difference.
IOS-XR’s approach is to assign a higher administrative distance to the OSPF version of that route, so the BGP version wins RIB installation. This makes the RFC 4577 substitution explicit in show route. You see the BGP source because that’s what’s actually in the forwarding table.
Classic IOS achieves identical forwarding but hides the substitution in the CLI display. It still shows OSPF as the source even though forwarding uses the BGP mechanism underneath.
The underlying forwarding is identical. It’s just a difference in how each platform chooses to display the same mechanism in the output of the CLI. Both behaviors comply with RFC 4577.
I hope this has been helpful!
Laz