The right tool for the job: Choosing where to use RSVP-TE or SR.

              · · · · ·

I noted that at NANOG64 this week in San Francisco, there are talks (both from Juniper) about both SPRING/Segment Routing and RSVP-TE. These are both protocols/technology approaches (since one can’t really call SR a protocol) that I’ve been involved in the evolution of over the last few years. A question that I’ve been asked more times than I’d like is why we chose to look at a new approach (SR) rather than go with a technology that exists RSVP-TE.


RFC5218, RSVP-TE and Segment Routing.

              · · · · · ·

After my presentation at UKNOF on SR, Mark Townsley asked me whether I’d be interested in presenting to his class at the Ecole Polytechnique in Paris, around the thinking (from an ops perspective) of delivering the 5218 concept of “net positive value” through the SR technology, and how the existing protocols that are available might measure up against the criteria that 5218 gives us to consider. We managed to co-ordinate logistics, and I presented to INF566 on Wednesday afternoon, which was a really cool experience.


SPRING Forward(ing)

              · · · · · ·

I recently gave a talk at UKNOF relating to Segment Routing/SPRING and the operational challenges that we are trying to resolve through it. You can see it on YouTube below - or the slides are on this site - SPRING Forward(ing) - UKNOF27   


Some Initial Thoughts on the Software-Defined Network (SDN).

              · · · · ·

At one of the Ericsson R&D days, Professor Scott Shenker - who's an academic at the University of California in Berkeley, presented on a concept that he calls the "software defined network'. Now, if you haven't seen the presentation - it's definitely worth watching (it's on YouTube, here), and provides quite an engaging look at the problem of network scaling from the perspective of academia, and especially in terms of a comparison to the more rigorous disciplines of computer science, like OS design.


Visualising MPLS-TE Networks

              · · ·

For all network deployments, there is a requirement to present information relating to both topology, and various utilisation statistics to some human operator. In many cases, this process has become so ingrained in network requirements that there are almost ubiquitous solutions to the visualising data - for example, link utilisation is almost always presented via some framework or tool powered by RRDTool. Other tools, such as network "weathermap" diagrams linking this utilisation information into an overview of a network topology are also seen in many NOCs.