Does anybody have any idea why? Next hop is in inet.0 table (via OSPF) so it should be "usable"...
I do. You need to enable "family mpls" on RR interfaces.
BTW, this approach of changing "resolution-rib" is good for the lab but in production it breaks 6PE and 6VPE which use IPv4-mapped IPv6 /128 address (auto-constructed from remote PE' IPv4 loopback) as BGP NEXT_HOP .
Better approach is to leak only /32 from inet.0 to inet.3 and inet6.3 as below and don't change "resolution-rib":
I thought "resolution-rib" was tghe way recommended by Juniper (and they reviewed my config...!). And I really like the concept (and dislike the concept of leaking routes between ribs - I guess I'm old fashioned)
But yes - I will use 6PE/6VPE so thanks for heads up
Is there any way of making 6PE work with "resolution-rib" idea? Something along the lines:
Which means one cannot use them in IGP/inet6.0 cannot have ipv4-mapped IPv6 prefixes sourced from IGP albeit JUNOS allows You to assign ipv4-mapped IPv6 addresses to links. That being said, assigning ipv4-mapped IPv6 addresses to links is only useful for inter-AS 6PE with eBGP-LU as transport.
Your other option is to rewrite MP-BGP NEXT_HOP to global unicast IPv6 address assigned to PE loopbacks that exist in IGP (and then You can use Your fav "resolution-rib" method) but this is more trouble than it's worth:
1/ MP-iBGP export policy is required to do that on EACH PE
2/ be careful NOT to rewrite MP-BGP NEXT_HOP for IPv4 prefixes (otherwise these prefixes will be hidden), do it only for IPv6 prefixes.
So I've implemented the changes and I'm seeing "interesting" behaviour...
In my lab (which is a vMX on 17.2R1.13) it works perfectly fine.
In production (MX204, 18.1R3.3) - it's a diferent story. Exact same config (different IP addressing) and in the lab both inet-vpn and 6PE work fine. In production vpn next hops are still "unusable" (they are in inet.3 table though). Do I still need family mpls on the interfaces of the RR?
I don't thave that in the lab and it works perfectly...