Ng Seo Boon

BGP based dydnamic tunnelling is a new tunnel overlay technology making usage of the new BGP Remote Next-Hop attribute. This new overlay sollution is based upon the property of an IP address to be both an identity as a locator. Hence by utilising these properties smartly an overlay network can be built in a similar fashion as MPLS based overlay networks are designed. A major difference in comparison with MPLS based services networks is that BGP based Dynamic Tunneling service networks are purely based around an IP oriented control plane, and that there is no need for MPLS or LDP technology.

By using BGP and an IP based control plane to build the services network dynamically it is possible to implement very scalable, operationally simple and secure Service provider services networks. At the same time proven fast convergence and high availability technologies can still be utilised.

This session will explain the concept and theory of BGP based Dynamic Tunnels, and will explain in a few steps some case studies and usage cases to dely BGP based Dynamic Tunnels as an alternate of a traditionally MPLS centric service provider services network.

Mathieu Paonessa, Jaguar Network

There are a lot of friendly ‘shell access’ exchange deals between network operators. This makes it easier for parties to debug network issues and troubleshoot ‘from the outside’. A point of view outside your network is absolutely essential, seeing what others see is a useful thing with a variety of network problems. Well known examples are ‘it works for even numbered ip address, but not for odd numbered ip address via this and this route’. To encourage and provide a streamlined way of cooperating, the ”NLNOG RING” was created. In essence the deal is very simple: you make a (virtual) machine available to the RING, and you gain access on all servers which are part of the project, hence the name “RING”. A great example would be to launch a traceroute from 80 servers in different networks and quickly get the results instead of waiting till somebody has the time to run some tests for you.

Vincent Ng, Cisco

A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal-cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms are not bandwidth aware and do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This presentation introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as available and maximum allocated multicast bandwidths. The allocation of bandwidth is flexible so each path can have a uniquely defined available multicast bandwidth as a subset of the physical bandwidth, and the paths do not need to have the same physical bandwidth also. This will therefore protect unicast traffic against oversubscription of multicast traffic.