P2MP - Re-Merge via Signaling

In a P2MP MPLS LSP network, the term re-merge refers to the case of an ingress (headend) or transit node (re-merge node) that creates a re-merge branch intersecting the P2MP LSP at another node down the tree. This may occur due to events such as an error in path calculation, an error in manual configuration, or network topology changes during the establishment of the P2MP LSP.

In case P2MP LSP re-merge is needed, the re-merge node initiates the pruning of the re-merge sub-LSPs through signaling using one of the following options:

• no-re-merge -- This CLI configuration statement, when enabled at the ingress (headend) router, avoids the path computation of P2MP sub-LSPs, which creates a re-merge condition. When this CLI configuration statement is configured at the ingress, configuring the no-p2mp-re-merge CLI configuration statement at the transit router is not required.
• no-p2mp-re-merge -- This CLI configuration statement, when enabled at the transit router, changes the default behavior of allowing the P2MP sub-LSP sessions re-merge to rejecting the re-merge. This CLI configuration statement is primarily required when the ingress (headend router) is not a Juniper device.
• single-abr -- This command, when enabled, reduces the re-merge condition beyond the interarea, or interdomain, or inter-AS RSVP P2MP LSPs.