BOD wiki

This is the wiki page create to collect information regarding BODaaS, with the scope of extending it as a service into the Nordic NRENs.

I have created a section for each NREN to enter their information in to.

Please add your thoughts requirements and any other relevant information, arguments etc...
that should be considered for our discussions at the next CTO f2f meeting September 4, in Espoo.

The outcome of the process is intended to be a (hopefully) joint recommendation that we can take to the NORDUnet board meeting September 22.

DeIC

In DeIC we are in favour of the development and implementation of advanced network services and technologies (BoD, SDN, etc.). We are currently engaged in the deployment of BoD and MDVPN which we think should be combined to a large degree. Future activities depend largely on funding possibilities and the interest of our end-users.

FUNET

Funet has deployed a pilot BoD environment and we have one user for the current setup. We also run a pilot MDVPN setup, which is not in real use yet.

We see the possible benefits of BoD mainly in multi-domain connectivity. However, easy multi-domain connectivity can be done with MDVPN too. Currently it looks like that MDVPN may be gaining more momentum (at least in Europe).

We have no plans to extend our current BoD setup, until we see real customer need for the service.

RHnet

It is our experience that BOD is mostly a request for L2 service with dedicated reserved capacity for a limited time and SLAs dealing with jitter and latency.

RHnet is a layer 3 network and does not (and does not have plans to) offer L2 services.  We have had no requests for BOD per se and do not belive that there is any need for this service.  Once it is demonstrated that there is ample capacity via the regular L3 service and that the L2 service would take exactly the same path (just with hops that are invisible) our users so far have been perfectly happy. Today there is very little difference between routing on L3 and switching on L2 .. both are HW assisted. So for us it is a matter of education and measurements, so we can demonstrate that doing L3 is not costing them anything in jitter or latency. Once that is done, we forsee few use-cases willing to pay much higher price for such a service.

SUNET

In general SUNET is not opposed to technical development and experimentation in the network but we we feel that work on BoD has gone on long enough without delivering either concrete use- or business cases to motivate the cost and resources used up to this point. We believe that BoD should only be deployed as a service and research and development continued at current levels provided the following conditions hold:

• that a realistic set of motivating use-cases from actual users/customers be developed and presented to the CTO forum
• that BoD only be considered when there is documented scarcity
• that the BoD solution be based on protocols and technology being standardized in recognized SDOs (IETF, W3C, IEEE, ITU)

We have engaged with our customers and community and have not been able to find any motivating use-cases. We do have cases of private networks (eg the Onsala space observatory) but none of these cases rely on dynamic provisioning and we don't see that changing. We welcome a discussion focused on use-cases.

UNINETT

UNINETT has not registered a user demand for BOD in Norway. What we do see is that there is a certain demand for a L2 service between higher education campuses.

Today UNINETT provides a L3 IP network without any MPLS functionality. (and the DWDM infrastructure is operated by Broadnet). We are looking into implementing MPLS, but foresee some challenges in the short run as we have a diverse router platform. In particular we have some "older" Cisco routers that _may_ not be MPLS capable.

If_/_when_ we implement MPLS we can offer provider-edge 1G L2 ports to customers.

UNINETT also welcomes a discussion based on use-cases.

NORDUnet

It is NORDUnet’s position, and intention, that we separate our work on BoD, into two complimentary efforts:

• Providing a circuit-on-demand capability in the core network(s). Such a capability must allow a range of efforts to exploit it in different ways, making possible a variety of products and services.  The key is the existence of a control plane that allow services to request circuits with certain specifications, using standard protocols, and the circuits can be requested across multiple domains. For now, this means using the NSI protocol framework, putting in place technology that allow us to expose certain capabilities of the network using these protocols, and to participate in topology exchange, circuit management, etc. across domains beyond our control.  Capabilities can be exposed using whatever underlying circuit technology is available in the network (MPLS, OTN, etc). 

• Offering e2e, campus-facing services based on these capabilities.  Such services can range from embedding circuit capabilities directly in end-applicaitons, to offering a web portal (or even access through a NOC) for requesting circuits. Outside SURFnet, European NRENs have so far not engaged in this areas, and developing appropriate service specifications, is an effort which require serious projects, and engagement with user communities. To accomplish this in the Nordic countries, (some) Nordic NRENs must engage and be key stakeholders in an effort (possibly supported by NORDUnet).  Doing so will have to be an exploratory effort, as the best way to offer such services is so far not understood. However, it is clear that for such an exploratory effort to be possible, the basic circuit capability must be present in the network, and a commitment to support it must be present.  It is our hope that at least two Nordic NRENs will engage in this effort, and that we can engage with key partners outside the Nordic areas (i.e., SURFnet) to develop the service portfolio.

With this approach, the focus of NORDUnet will be the further development of the core network capabilities, and the technologies and standards that support it, as well as the multi-domain coordination and deployment of such capabilities.  We will work diligently on linking to similar capabilities in NRENs in GÉANT, on inter-continental infrastructure, and to ensure that multi-domain capabilities are available, linking to other regions, i.e., Asia, South America.  We will work on supporting these capabilities over the technologies we use, and at the capacities supported by our networks.
 
The effort to define the appropriate set of services and match those to user communities, will be seen as primarily NREN & campus efforts, as this is where services must be deployed. NORDUnet will support such efforts, work with pathfinder projects and early adopters, and have NORDUnet engage as part of the community.