Yes,
In fact what is happening is that OSPF is advertising the loopbacks with a /32 mask (default ospf type loopback), but the 2 PEs are advertising a label to P1 (using LDP) with the correct mask. When P1 receives the label mapping infos from the PEs it cannot find a match in its routing table since it has OSPF routes with /32. That's why P1 does not allocate any label to the loopbacks in the LFIB:
P1#sh mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
18 No Label 4.4.4.4/32 835 Fa1/0 34.34.34.4
19 No Label 2.2.2.2/32 689 Fa0/0 23.23.23.2
Normally the PEs should instruct P1 to POP the topmost label (transport label) of the stack letting the last label (VPN label) intact when transmitting the packet. If you see "No Label" it means all labels are removed before transmitting the packets. The packets are then sent to the PE untagged and the PE doesn't know in which VRF to forward since it doesn't see any VPN label.
You can also verify this while you debug mpls packets on P1, you will see only "RX" packets arriving but 0 MPLS packets leaving ("no "TX").
You can also use OAM (enabled by default on IOS) to verify the state of the LSP between the 2 PEs and you will see that the LSP is broken on P1:
PE1#traceroute mpls ipv4 4.4.4.4 255.255.255.255
Tracing MPLS Label Switched Path to 4.4.4.4/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 23.23.23.2 MRU 1500 [Labels: 18 Exp: 0]
B 1 23.23.23.3 MRU 1504 [No Label] 32 ms
B 2 23.23.23.3 MRU 1504 [No Label] 40 ms
B 3 23.23.23.3 MRU 1504 [No Label] 40 ms
B 4 23.23.23.3 MRU 1504 [No Label] 32 ms
.....
To solve this you can either restore the masks of the PEs loopbacks to /32 or change the OSPF network type of these loopbacks to point-to-point.
You can then try again these last commands (also the debugging on P1) and you will see the difference.
Best Regards,
Nicolas.
