When creating a static mLDP tunnel, the user must configure the P2MP tunnel ID.
*A:SwSim2>config>router# tunnel-interface
— no tunnel-interface ldp-p2mp p2mp-id sender sender-address
— tunnel-interface ldp-p2mp p2mp-id sender sender-address [root-node]
This p2mp-id can coincide with a dynamic mLDP p2mp-id (the dynamic mLDP is created by the PIM automatically without manual configuration required). If the node has a static mLDP and dynamic mLDP with same label and p2mp-id, there is collisions and OAM errors.
Do not use a static mLDP and dynamic mLDP on same node. If it is necessary to do so, ensure that the p2mp-id is not the same between the two tunnel types.
Static mLDP FECs originate at the leaf node. If the FEC is resolved using BGP, it is not forwarded downstream. A static mLDP FEC is only created and forwarded if it is resolved using IGP. For optimized Option C, the static mLDP can originate at the leaf node because the root is exported from BGP to IGP at the ASBR; therefore the leaf node resolves the root using IGP.
In the optimized Option C scenario, it is possible to have a static mLDP FEC originate from a leaf node as follows:
A dynamic mLDP FEC can also originate from a separate leaf node with the same FEC:
In this case, the tree and the up-FEC merge the static mLDP and dynamic mLDP traffic at the ASBR. The user must ensure that the static mLDP p2mp-id is not used by any dynamic mLDP LSPs on the path to the root.
Figure 1 illustrates the scenario where one leaf (LEAF-1) is using dynamic mLDP for NG-MVPN and a separate leaf (LEAF-2) is using static mLDP for a tunnel interface.
In Figure 1, both FECs generated by LEAF-1 and LEAF-2 are identical, and the ASBR-3 merges the FECs into a single upper FEC. Any traffic arriving from ROOT-1 to ASBR-3 over VPRN-1 is forked to LEAF-1 and LEAF-2, even if the tunnels were signaled for different services.