When configuring PAN-OS to PAN-OS VPN tunnels, use IKEv2. When using IKEv1, I've seen issues with tunnel droping on some configurations.

From Palo Alto Networks support:

PAN IKEv1 does not support overlapping IKE SA. The phase1 SA will be deleted when its lifetime expires. The phase1 SA rekey will only be triggered when Phase2 SA lifetime expires. It is not a bug. While, IKEV2 support overlapping SA, phase1 SA will be rekeyed before its lifetime expires.

If you have 169.254.11.1/30 defined on your tunnel interface, and if you have 169.254.22.2/30 defined on the peer tunnel interface, then

1. If you have enabled tunnel monitoring on your VPN to monitor 169.254.22.2/30, you will find that 169.254.11.1 can ping 169.254.22.2 even though, in theory, it has not route to it. No other interface on the firewall will be able to ping it though. The act of putting a tunnel monitor on the tunnel means that the firewall will send to that IP down the tunnel when they are sourced from the tunnel IP.
2. If you have not enabled tunnel monitoring on your VPN, you will find that 169.254.11.1 cannot ping 169.254.22.2

You can also set the IP address on each tunnel interface to be a /32 (or just type the IP and don't set a subnet). Subnets are not important for the VPN monitoring if you don't mind the associated security rules looking little odd from the Zone point of view. You can select a /16 and then use the third octet to represent the local firewall and the fourth octet to represent the remote firewall.

Unless you use a correct /30, the rule will need to be SZ_VPN to SZ_Outside as the routing will think that the other IP is out of the normal default gateway interface even though PAN-OS still sends the packet down the tunnel.

E.g. 10.10.1.2 on one firewall and 10.10.2.1 on the second firewall.