This article explains that Junos OS does not fully comply with RFC5340 because the DN bit does not function with OSPFv3 on Junos OS, and indicates what must be done to avoid the issue.

Topology

                    ----------------------PE2--------------------CE2
                    |                      |                      |                        
                    |                      |                      |    
      CE3----------PE3                     |                      |    
                    |                      |                      |    
                    |                      |                      |    
                    ----------------------PE1--------------------CE1

Consider that you have two IGP domains with OSPFv3 configured between PEs and CEs on both sides of the MPLS core, and both OSPFv3 domains communicating with each other across the MPLS core.

If CE3 advertises the OSPFv3 LSA1 to PE3, which redistributes the route into VPNv4 and advertises it to PE1 and PE2, then PE1 and PE2 will in turn advertise LSA3 to CE1 and CE2.

This will cause a routing loop because we do not support a DN bit in OSPFv3.

This DN bit issue is seen only with OSPFv3. OSPFv2 is totally fine, and fully compliant with RFC standards.

To avoid the routing loop, add a domain ID on PE1 & PE2 while configuring VPNv4 route redistribution into OSPFv3 in the policy. Then LSA3 will be translated to LSA5 if the local domain ID is different from the remote domain ID.

When we have LSA5, the route tag will be added automatically and sent to the CEs, which can prevent the loop.

2020-12-21: Modified topology to make it more readable