Tag Archives: P2MP

Segment Routing v/s RSVP-TE?

SR (Segment Routing) is new and trending topic these days in Telecom Networks. It’s promising and some vendors are pushing for it because of the way we can leverage SDN Controller to steer the traffic through the Network plus how it will remove need of LDP/RSVPE-TE from core however i think there are still some of the use cases where it lacks some capabilities currently. I hope in future all these areas will be fixed and SR becomes THE Option of choice for all Service Providers. These are all my opinions and it would be good to know your views on it.

1)      Bandwidth Reservation issue –> Using SR we can’t reserve the bandwidth in our Network for each LSP as we can do with RSVP-TE. Bandwidth reservation can be critical in some Service provider/Broadcast networks to provide the customer with dedicated bandwidth. We can argue that Controller at the Top can look at the whole Network and would be able to easily manage the reservations however Controller is a single point of failure and I don’t think we can depend upon Controller for this crucial behaviour.?

2)      Lack of Multicast P2MP Support –> Multicast proposes more challenge for the segment routing. SR can only replace Point to point LDP/RSVP-TE however some of the Telecom Networks uses P2MP Multicast services as part of NG-MVPN and for those we still need to depend on RSVP-TE . Moreover MPLS-based multicast solutions have matured now after many years’ of development. I think keeping 2 Technologies i.e one for P2P L2/L3VPN and other for P2MP MVPN will add complexity only to network.

3)      Depth of MPLS Label Stack –> We know that forwarding packets need to push a SR header with a list of segments(labels). Now there are 2 main types of SR Labels. One is Node and other is Adjacency (link). To provide granularity to route the traffic via 15-20 hops we need to push more Adjacency labels at Ingress PE accordingly. This depth of label stack may be a challenge for some type of devices.

Plz see some of the labels stack present in hardware:  (Courtesy: NANOG.org)

Linux (kernel 4.10): 2-3 SID’s

Low end off the shelf (merchant) silicon, e.g. BCM Trident2: 3-5 SID’s

High end off the shelf (merchant) silicon, e.g BCM Jericho1 : 4-7 SID’s

Vendor’ silicon, e.g. Juniper’ Trio: 4-10+ SID’s

Even though Vendor may be able to support 15-20 Label stack, we can end up in payload efficiency and MTU issues i.e. because of big size of the header will reduce the efficiency of payload.

4)      State Issues –> One major advantage for segment routing proposed was that the State is only maintained at the head-end. No state is maintained at mid-points and tail-ends. This is good in case if we have Node and Adjacency/Link labels only however there are proposals for Prefix segment Labels also which will increase the state on all the points in network and I don’t think behaviour will be different from LDP/RSVP-TE then.

In case of centrally controlled environment where Controller will take care of everything it will be difficult for Operations Teams to troubleshoot in case anything goes wrong in Network as they need to know the architecture of each device whether it is capable of getting around the Label stack issue via that device. We may be thinking of putting low end devices near to Customer edge as PEs and high end in middle of core, however due to label stack issue we may need to put high end routers only everywhere.

I am not against SR however i would be really pleased if these issues can be taken care or already available (i may well be living in old times) however from my perspective, there is scalability issue which limits application scenarios for segment routing. It may be better for cases where service provider is mostly providing  unicast L2/L3VPN services.

Let me know your views on this and how you are using SR in your environment 🙂




Juniper Northstar SDN Controller – Part 2

Following on my earlier blog on Northstar here: https://networkzblogger.com/2017/03/17/juniper-northstar-wan-sdn-controller, recently I got chance to work on next release of it which has among other things is ability to initiate P2MP (Point to Multipoint) LSPs. P2MPs are big use case in Media and Broadcast network and ability to create them via controller would be too helpful. However there is a catch. As discussed in my earlier blog, the NorthStar (NS) Controller relies on PCEP (Path Computation Element Protocol) to deploy a path between the PCC router and PCE (Controller). Currently P2MPs are not initiated by PCEP or its standard is not ratified. So Juniper have come up with another way of configuring it and that’s via Netconf. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple Remote Procedure Call (RPC) layer. The protocol messages are exchanged on top of a secure transport protocol like SSH etc.

In this blog, instead of looking at PCEP based LSPs from Northstar we will explore netconf functionality and what other features have been introduced in new ns version.

Below is our current model which is built using TED (Traffic Engineering Database) by Northstar and if you look closely there are 2 devices which have PCEP session up because they have correct Junos code on it (15.1F6 and later) however all others are having netconf session Up even if they are on Junos 10, 12, 14 etc. which is cool thing. So as long as you have netconf stanza added in Junos config and have ssh connectivity that is all Northstar need to connect to devices.


Lets start by configuring a P2MP LSP via Northstar

You can see 2 options here for provisioning method. One is PCEP and other is Netconf.


We will choose Netconf and fill other bits.


We have kept Path as dynamic however we can choose required path to TE it more. Under Advanced Tab, you will see P2MP Name field, in which we have added the P2MP name.


All others field you can pretty much keep default.

Once you submit it, Northstar will open a netconf session on port 830 towards headend router which is M320 in our case and push and commit the config to it.


You can see above LSP has become Active and its showing the path as well which this LSP is taking. Now one of the biggest difference between PCEP created LSP and one created from Netconf is that Netconf LSPs will be part of startup-config in Junos as the configs are committing to it so it can be slow process getting your LSP up based upon commit time. Also all Netconf created LSPs are basically shown as PCC Controlled. However PCEP just sent LSP state to network to build E2E path rather than config. PCEP LSP config still resides in NS database and LSPs are created within seconds and are PCE Initiated.

M320> show configuration protocols mpls label-switched-path demo-0610
p2mp demo-0610-p2p;
primary demo-0610.p0 {
 apply-groups demo-0610-p2p;

M320> show configuration groups demo-0610-p2p
protocols {
 mpls {
 label-switched-path <*> {
 primary <*> {
 bandwidth 10m;
 priority 7 7;

Ok so that’s for P2MP LSPs which is clean. In 3.1.0 one of the issue we found was related to commit process. Suppose you have 10 LSPs to be created from one source to destination. With Netconf, NS will commit 10 times individually for those LSPs which can be time consuming on some of the MX104s, MX80s with less CPU power. Juniper is looking to change this and putting the commit in batches to decrease the overall time and commit process which would be excellent J

So we have seen now how P2MP LSPs are created via Netconf however we haven’t seen how Netconf parameters are configured on NS as with netconf you can see the analytics data as well which is populated by Telemetry. We will see Telemetry in some other blog.

Under Administration -> Device Profiles we have to set the parameters for individual device.


We enable Netconf and add login details and password. You can test the connectivity as well from NS before actually trying to provision the network.


Apart from P2MP, another thing which has been introduced is while provisioning the LSP you can select which routing method you need to choose. There are many methods starting from default to routebyPCC, etc. default means that NS will calculate the path and routebyPCC means routers will calculate the path and NS won’t be having any say in it.


Another new feature which has been introduced in release 3.1.0 is setting the current path as explicit.

So above P2MP LSP I created was just dynamic however if we want to explicitly make this path as Strict so that LSP doesn’t change path based upon the network conditions we can configure it as below.


If we see the CLI now, NS has filled strict path in it.

M320> show configuration protocols mpls path demo-0610.p0 strict; strict;

Ok that’s all for this blog. I hope you like it and let me know your views if you are looking at using NS for your network and if you are already, what are your use cases J



Mohit Mittal