Provision and Manage P2MP Groups

Introduction

P2MP groups, or trees, can be provisioned to help conserve bandwidth. Bandwidth is replicated at branch points.

In the NorthStar Controller, you can provision P2MP groups; view and modify group attributes; and view, add, modify, or delete sub-LSPs. This is a separate workflow from provisioning P2P LSPs, and is initiated from the P2MP Group tab in the network information table.

NorthStar supports two provisioning methods for P2MP groups: NETCONF and PCEP. PCEP provisioning offers the advantage of real-time reporting. Functionality and support for the two provisioning methods are not identical; differences are noted in this documentation. For PCEP-provisioned P2MP groups, NorthStar also supports association with a multicast VPN instance (S,G) flow in its PCEP P2MP service mapping functionality. IMPORTANT: See the release notes for Junos OS release requirements related to PCEP provisioning and PCEP P2MP service mapping.

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 via the NorthStar Controller, in accordance with draft-ietf-pce-pcep-flowspec-05. Beginning with NorthStar Controller Release 5.1.0, you can leverage that Junos OS functionality by provisioning PCEP P2MP groups in NorthStar 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 particular P2MP group. It’s important to understand the effect on the flows of making various configuration changes on the router, so we recommend using your Junos OS documentation as a reference.

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

Required Router Configuration

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

The following configuration statement allows PCEP to report the status of P2MP trees in real time, whether provisioned by NETCONF or by PCEP:

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

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

• set protocols pcep pce pce-id pce-traffic-steering

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

• set routing-instances routing-instance-name provider-tunnel external-controller pccd

  set routing-instances routing-instance-name protocols mvpn sender-site

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

The following is a sample configuration on a router with a P2MP group head end:

Useful Junos OS show Commands

Table 1 includes some useful Junos OS commands and what the output can show you.

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 should not necessarily expect to see the Op Status in the network information table change during the re-route because 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.

View P2MP Groups and Their Sub-LSPs

P2MP group information is displayed in the P2MP Group tab of the network information table, and is also reflected in the topology map.

1. On the tabs bar of the network information table, click the plus sign (+) and select P2MP Group from the drop-down menu as shown in Figure 1.Note

   When you launch the web UI, only the Node, Link, and Tunnel tabs are displayed by default; P2MP Group is one of the tabs you can optionally display.

   Figure 1: Adding the P2MP Group Tab

   

2. The P2MP Group tab is added to the tab bar and the contents are displayed as shown in Figure 2.

   Figure 2: P2MP Group Tab in the Network Information Table

   

   Columns for group attributes are shown across the top. You can add columns and filter the display in the usual ways. See Sorting and Filtering Options in the Network Information Table for more information.

3. Click a row in the table to highlight the path in the topology map.
4. Right-click a row in the table to display either a graphical tree view of the group, the flows associated with the group, or a list of the sub-LSPs that make up the group. Figure 3 shows these options.

   Figure 3: Right-Click a P2MP Group

   

   The tree diagram opens as a separate pop-up as show in Figure 4.

   Figure 4: P2MP Group Graphical Tree Diagram

   

   When you select to view sub-LSPs, the sub-LSPs that make up the group are displayed in a new tab in the network information table. On the list of sub-LSPs, you have all the display options normally available on the Tunnel tab. See Network Information Table Overview for more information.

   Note

   The sub-LSP tab in the network information table is for display purposes only; you cannot perform Add, Modify, or Delete functions from there. But the sub-LSPs are also displayed in the Tunnel tab, where you can perform those actions.

In the P2MP Group tab of the network information table, the Control Type column displays Device Controlled for NETCONF-provisioned groups and PCEInitiated for PCEP-provisioned groups.

Add a P2MP Group

On the P2MP Group tab of the network information table, click Add at the bottom of the table. The Add P2MP Group window is displayed as shown in Figure 5. Red asterisks denote required fields.

Figure 5: Add P2MP Group Window, Properties Tab

Table 2 describes the data entry fields in the Properties tab of the Add P2MP Group window.

The Advanced tab includes the fields shown in Figure 6 and described in Table 3.

Figure 6: Add P2MP Group Window, Advanced Tab

The Design tab includes the Routing Method options shown in Figure 7.

Figure 7: Add P2MP Group Window, Design Tab

For NETCONF-provisioned P2MP, the default routing method is routeByDevice (since it uses NETCONF as the provisioning method). You can select a different routing method in which the PC server calculates the path for all the sub-LSPs. For PCEP-provisioned P2MP, select default as the routing method. The routeByDevice routing method is not available for PCEP-provisioned P2MP because an empty ERO would be sent. The behavior for all routing methods is similar to P2P LSP provisioning.

Note in Figure 7 that the Service Mapping tab is grayed out. That’s because the provisioning method selected was NETCONF in order to display all the possible routing methods. The Service Mapping tab is only available for PCEP provisioning.

When the provisioning method selected is PCEP, the Service Mapping tab is available. It includes the fields shown inFigure 8 and described in Table 4.

Figure 8: Add P2MP Group Window, Service Mapping Tab

The Scheduling tab is identical to the one you use to provision P2P LSPs and is shown in Figure 9.

Figure 9: Add P2MP Group Window, Scheduling Tab

Select Once to set up start and end parameters for a single event. Select Daily to to set up start and end parameters for a recurring daily event. Click the calendar icon beside the fields to select the start and end dates, and beginning and ending times. At the scheduled end time, the group is torn down.

You can view the progress of scheduled P2MP groups in the Tunnel tab of the network information table, using the Op Status and Controller Status columns as shown in Table 5.

Figure 10 shows an example of the network information table Tunnel tab with scheduled tunnels in progress, expired, and pending. Note the Op Status and Controller Status columns.

Figure 10: Tunnel Tab with Scheduled Tunnels

The tunnels remain in the Tunnel tab, even after the scheduled window has ended. This allows you access to historical data about when LSPs were scheduled and torn down. You can filter the Time_Expired tunnels out of your display using either the Filter function at the bottom of the network information table (magnifying glass icon), or the column filtering function available when you right-click in a column heading. See Network Information Table Bottom Tool Bar and Sorting and Filtering Options in the Network Information Table to see how these filtering options work.

The User Properties tab is used for P2MP group to multicast VPN service mapping (not supported for PCEP-provisioned P2MP groups). See Templates for Netconf Provisioning for more information.

Once you are finished defining the group, click Submit. The group is added to the network information table, on the P2MP Group tab.

Modify a P2MP Group

To modify a P2MP group, select the group in the P2MP Group tab of the network information table, and click Modify at the bottom of the table. The Modify P2MP Group window is displayed as shown in Figure 11.

Figure 11: Modify P2MP Group Window, Properties Tab

Using the tabs on the Modify P2MP Group window, you can change the value of attributes (affects all sub-LSPs in the group), add or remove destination nodes (which adds or removes sub-LSPs), and set up or change scheduling for the group. For PCEP P2MP groups with service mapping, you can also use the Service Mapping tab to add or change flows.

To remove sub-LSPs from a group, select the destination node(s) in the Node Z field (Properties tab of the Modify P2MP Group window), and click the minus sign (-). If you remove a sub-LSP from a PCEP P2MP group with service mapping, the mapping remains intact and the tunnel continues to carry traffic.

When you have finished making changes, click Submit.

You can modify other attributes on the individual sub-LSP level (path or Max Hop, for example). To modify sub-LSP attributes, select the tunnel in the Tunnel tab of the network information table and click Modify at the bottom of the table. If you attempt to modify one of the six group-level-only attributes at the sub-LSP level, an error message is displayed when you click Submit and the change is not made.

Delete a P2MP Group

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.

To delete a P2MP group, select the group on the P2MP Group tab of the network information table and click Delete at the bottom of the table. Respond to the confirmation message to complete the deletion.

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.

P2MP Tree Design with Diverse PE to CE Links

NorthStar Controller 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 (the 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, NorthStar considers the shared risk groups and affinity constraints in the PE-CE links.

Figure 12 shows an example topology that could leverage this type of 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, each site having two CE nodes.

Figure 12: 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 would enable the two data sources to distribute redundant data streams to the CE nodes/sites.

Sites A, B, C, and D could also be depicted as shown in Figure 13, 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 NorthStar. The pseudo-nodes can be used as the leaf nodes in tree calculations.

Figure 13: 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 14. The redundant data streams are represented by the two colored paths.

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

You request a tree design with diverse PE to CE links through the REST API. When the tree is created, the ERO of the route 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. Or you could delete the tunnel and schedule a new one.

The 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 not ever 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.

NorthStar cannot discover CE nodes and sites, so you must add them and their associated links to the topology, using either the UI or the REST API.

Adding CE Nodes/Sites and Links Using the UI

In the network information table, Node tab, click Add in the bottom tool bar. The Add Node window is displayed as shown in Figure 15. At this time, this window is exclusively for adding CE nodes/sites as opposed to other node types. These nodes/sites are used for path computation, but not for signaling. The data entry fields are described in Table 6 and Table 7.

Figure 15: Adding a CE Node

Figure 16 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.

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

In addition to creating the nodes, you must also add links between the CE nodes/sites and the PE nodes in the topology, using the Add Link window accessible from the network information table bottom tool bar. Because 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 network information table (Link tab).

Special Notes for the Current NorthStar Release

The following notes apply to the current NorthStar release:

• Hybrid diverse P2MP groups (destination designation includes both PEs and CEs) is not supported.

• You cannot provision diverse P2MP trees using the NorthStar UI. It must be done through the REST API.

• Diverse P2MP with flow mapping is not supported. The workaround for this limitation is to create a diverse tree using the REST API and then assign mapping to individual P2MP groups either using the UI or the REST API.