About the P2MP Groups Tab

PCEP-Provisioned P2MP Groups with Service Mapping

Beginning with Junos OS Release 19.4R1, Junos OS has the ability to associate multicast flows (S,G) in the multicast VPN context to a PCEP P2MP LSP provisioned through the PCE, in accordance with draft-ietf-pce-pcep-flowspec-05. You can leverage that Junos OS functionality by provisioning PCEP P2MP groups that you associate with one or more multicast flows (S,G) in a multicast VPN. Once a P2MP group is associated with a particular (S,G) in a multicast VPN, traffic from that particular source IP S going to group IP G, is able to utilize that P2MP group.

The PCE side of this functionality requires specific configuration on the router which is described in the following section.

Required Router Configuration

In Junos OS Release 15.1F6 and later, you can configure the router to automatically send P2MP LSP information to a controller in real time. Without that configuration, you must run device collection for PCE to learn about newly provisioned P2MP LSPs. The configuration is done in the [set protocols pcep] hierarchy for PCEs and PCE groups.

The following configuration statement allows PCEP to report the status of P2MP trees in real time:

For PCEP-provisioning, the following additional configuration statements are also required:

For PCEP P2MP service mapping with flowspec, the following additional configuration statements are required:

• This configuration enables the router to support traffic steering (flowspec), and must be configured on the head-end.

• This configuration enables the router to accept P2MP LSP provisioning with (S,G) for this multicast VPN from an external controller.

Sample configuration on a router with a P2MP group head-end is as follows:

show rsvp session p2mp ingress statistics

Automatic Rerouting Around Points of Failure

For PCEP-provisioned P2MP groups only (including those with flow-mapping information), sub-LSPs are dynamically rerouted around points of failure along the path of the tree. You might not see the Op Status in the network information table change during the reroute as it happens very quickly. The topology map displays a red F on any failed link or node, and you can see how the path is rerouted around those markers.

P2MP Tree Design with Diverse PE to CE Links

Paragon Pathfinder can calculate diverse P2MP tree designs all the way to a customer edge (CE) node or site. Although the path computation extends to the intended endpoints, CE nodes or sites, the sub-LSPs actually terminate on the provider edge (PE) nodes. This ensures that the selection of tail nodes best satisfies the diversity constraints. When the diverse P2MP trees are computed, Paragon Pathfinder considers the shared risk groups and affinity constraints in the PE-CE links.

Figure 1 shows an example topology with P2MP tree design. Two data sources are located at PE nodes (PE1 and PE2). The receiving nodes are located in sites A, B, C, and D with each site having two CE nodes.

Figure 1: P2MP Tree Design with Diverse PE to CE Links Example Topology

Calculating pairs of diverse P2MP LSPs that terminate in the same nodes or sites enables the two data sources to distribute redundant data streams to the CE nodes or sites.

Sites A, B, C, and D could also be depicted as shown in Figure 2, where each site is shown as a pseudo-node. In this context, a pseudo-node is any node or site not discovered or managed by Paragon Pathfinder. The pseudo-nodes can be used as the leaf nodes in tree calculations.

Figure 2: Diverse PE to CE Links Topology with Pseudo-Nodes

The goal is for each sub-LSP in a diverse pair to be routed over a different PE-CE link, transiting a different PE node. Each sub-LSP terminates on the PE node that is the penultimate hop to the destination. An example is shown in Figure 3. The redundant data streams are represented by the two colored paths.

Figure 3: Diverse PE to CE Links Topology with Redundant Data Streams

You can request a tree design with diverse PE to CE links through the REST API. When the tree is created, the Explicit Route Object (ERO) of the route, which is the list of LSRs specified by IP addresses through which the path must pass, is always strict. This is in contrast to a single P2MP group in which a loose path to the address can be specified. The result is that if a link goes down in a diverse P2MP tree, the signaling address remains the same and the operational status of the tunnel remains down. If the link comes back up, the tunnel is restored. You can also delete the tunnel or schedule a new one.

The Path Computation Server (PCS) follows a set of rules when routing LSPs to CE nodes or sites:

• The links connecting to the CE nodes or sites might not have protocols enabled since they do not need to support LSPs. But the PCS must still consider those links for path placement.

• The PCS will never use a pseudo-node marked as an Access node as a transit node. Access nodes are end destination nodes.

• LSPs to CE nodes or sites must be signaled to their penultimate hop, the final PE in the path.

• The ERO pushed to the devices must be trimmed so it does not include the pseudo-node addresses or the PE-CE link identifiers.

Figure 4 shows a sample topology with some CE nodes that are configured as Regular and others that are configured as Access. For example, nodes CE_A1 and CE_B1 are Regular nodes because they need to be used for transit to the alpha and beta sites respectively. CE_D1 and CE_D2 are examples of Access nodes that represent end points, and are not used for transit purposes. In addition to creating the nodes, you must also add links between the CE nodes/sites and the PE nodes in the topology. As the nodes are pseudo-nodes, the links connecting them are pseudo-links. As pseudo-links, their status will remain Unknown in the Status column of the Link tab in the network information table.

Figure 4: Sample Topology with Access and Regular Pseudo-Nodes

Tasks You Can Perform

You can perform the following tasks:

• Add a P2MP Group. See Add a P2MP Group.

• Edit a P2MP Group. See Edit P2MP Group Parameters.

• Delete a P2MP Group—On the P2MP Group tab of the network information table on the Topology page, select the P2MP group you want to delete and click the delete (trash can) icon. A confirmation message appears. Click Yes. The P2MP group is deleted from the network information table.

  Alternatively, you can use the Tunnel tab of the network information table to delete all the sub-LSPs in the P2MP group, which also deletes the group itself.

  Note:

  When you delete a P2MP group, all sub-LSPs that are part of that group are also deleted. If you delete a P2MP group with associated multicast flows (S,G) in a multicast VPN context, the flows are also deleted.

• View Sub-LSPs— From the More list, you can view Sub-LSPs associated with the P2MP group. When you click the Sub-LSPs option, you are redirected to the Tunnel tab where detailed information about the sub-LSPs is displayed. You can perform several tasks such as add, edit, or delete LSPs from the Tunnel tab. For more information, see About the Tunnel Tab.

• Download P2MP Groups information—Click Download to export (download) information about all the P2MP groups in CSV format.

• View detailed information about the P2MP group by clicking More > Show Detail or click the Details icon which appears next to the P2MP group name when you hover over it. A pop-up appears displaying the P2MP tree, flows associated with the group, and link/LSP details that are a part of the selected P2MP group.