One of the great challenges of SDN – that many in my view underplay – is the change in paradigm from having a vendor deliver your network (hardware + software), to having (potentially) an ecosystem deliver your network – and this ecosystem may require you to develop software to perform network tasks or to integrate various SDN components together. This was recognized quite astutely by consultant Jim Metzler, which I discussed in one of my earlier blogs. “Applications can dynamically request services from the network” is what the SDN evangelists will tell you. Jim astutely asked “How exactly do they do that?”. Well ….. the true answer is that either (i) you need to buy [new] apps that do this off the shelf, as it were, or [more likely today] (ii) you need to modify your apps or develop new apps to do this.
Coding – the New Networking?
So are you ready for procuring apps and/or developing software in your network design team now? Don’t worry if you say “no”. Let me first tell you a few customer reactions to this topic, and then let me update you on Cisco Services can help you develop new SDN apps that solve your specific network challenges.
Read More »
Tags: ACI, API, application development, architecture, cisco_services, data center, onePK, SDN, software defined network
As I was thinking about how best to advise you on how to “experiment” with SDN technologies, and more specifically why you should run a formal pilot to evaluate SDN technology options (a topic I covered in my previous blog), I was reminded of this “wipeout” picture I took last year at a “freeride” competition – the “Coe Cup” – at my local ski mountain, Glencoe Moutain Resort, here in the UK. Let me tell you why!
Why you may want to “pilot” new technology adoption!
Tags: ACI, Cisco onePK, cisco_services, network virtualization, OpenFlow, SDN, software defined network
If you were to believe the industry press, you could easily be forgiven for thinking that many companies across the world were rolling software defined networking (SDN) technologies into their networks today. I’m part of Cisco’s Services team and my colleagues across the world are the experts in helping you all design and deploy networks. If there is a large or complex leading (or bleeding!) edge network out there being designed, you can place a safe bet that someone from the Cisco Services team is involved helping our customers achieve their targets. If you’re involved in deploying any type of high technology equipment, you’ll appreciate that there is a world of difference between selling, demoing, and actually making it all work in your environment when it comes to new technology. Our team are in the latter camp.
So what are our consultants telling me about SDN in the real world? Excluding a few notable high profile cases (usually involving hyper-scale data centers) they are not seeing – as yet, to be honest – many early deployments. However they are seeing a growing number of customers interest in learning about and evaluating SDN related technologies – including Cisco ONE, NFV and in particular Application Centric Infrastructure (ACI). And they are providing some early feedback on the use cases of SDN that customers are most interested in. They are all clear, however, on this point: this is the time to learn what SDN and Cisco ONE can do for your network in the future.
So how do you get started in SDN? Let me outline 5 key steps to help you get started. I’ll also point you to a technical white paper written by Mitch Mitchiner and Reema Prasad, two of our Customer Solutions Architects in Cisco Services, two of our experts responsible for making all of this work for you, your team and your business. I also recommend you check out the video link I’ve provided, for an excellent live demo of Cisco ONE technology, first presented at Cisco Live last year. This video gives a live demo of latency-based routing, one of the use cases described in Mitch and Reema’s paper.
Read More »
Tags: architectural approach, Cisco Domain Ten, Cisco ONE, Cisco onePK, cisco_services, network virtualization, NFV, SDN, software defined, software defined network
Over the past few months, the We’re Listening blog has brought you ongoing news about updates to our RMA processes, and the improvements keep on coming. I’ve asked Jim Fuller, Senior Director of Services Entitlement, to return to the blog to share details on the new 3-Way RMA process. The new process represents a significant improvement for many of our customers and partners, and in the spirit of the We’re Listening blog, was undertaken by Jim’s team in direct response to customer and partner feedback. Share your thoughts on other ways we can simplify your interactions with Cisco, and your suggestions may end up as new capabilities featured on the blog!
By Guest Contributor Jim Fuller
Our partners provide constant feedback to tell us how we can improve their experience doing business with Cisco. One of our partners’ number one requests is to help them create an RMA via a single step, versus opening a support case with Cisco to remedy contract updates as a result of RMA transactions.
We heard your feedback, and if you’re a partner who “self-spares” (spares inventory from your depot) or a customer who contracts with a partner who self-spares, your Return Material Authorization (RMA) process just became easier. We’ve introduced Partners 3-Way RMA/Self-Sparing.
With this new process, service contracts are automatically updated with the associated serial number swaps when processing 3-Way RMAs. Available now, the new capabilities provide the following benefits:
1. Delivery of an automated RMA process that supports 3-Way RMA transactions at the time of RMA creation
2. Two serial numbers can now be entered at the time of RMA creation for those partners that self-spare, via the Service Order RMA Tool (SORT):
- The serial number of the claimed defective part from customer network
- The serial number of the spare part used by the partner to replace the claimed defective part on the customer’s network
3. Ability to minimize or even eliminate partner overhead to monitor and coordinate contract swaps
Previously, the Partner Self-Sparing model was not systematically supported making equipment difficult to track. Without a standardized process, contract and installed base updates had to be performed manually via a support case process. Now, systematic contract updates will occur at the time of RMA shipment reflecting the spare part (replacing the claimed defective part) on contract, making it easier to do business with Cisco and drastically reducing support cases.
To date, more than 175 partners globally have been enabled, with an RMA success rate of 95%. In FY14, we’re focused on reducing contract cycles and the number of customer escalations even further.
Please contact your Cisco Partner Support Development Manager (PSDM) for further information about enabling these new capabilities in support of your 3-Way RMA/Self-Sparing needs.
Tags: cisco_services, partners, RMA, we-are-listening
In my first SDN blog, I asserted that “Services” – that is technical support, professional and consultancy services – are the missing “S” in the SDN debate. I’d now like to apply our Cisco Domain TenSM framework “in anger” to examine in more detail the impacts that SDN may have on your IT services and operations. While come of our competitors will only talk about the network switches and new device protocols, l’ll show how it’s not just the network switches that you should be concerned with: your SDN and Cisco ONE journey could involve impacts across multiple “domains”.
As I bogged about Cisco Domain Ten this past year, I’ve positioned it as a mechanism to help you on your data center journey. Let me now extend that use – SDN after all is more than just a data center technology play. My experience with Cisco Domain Ten over the past year has helped me realize that it is, in fact, an excellent framework for considering impacts to more general IT services, and not just to the data center . I’ll also illustrate my case with both service provider and enterprise/business/public sector examples.
The following diagram summarizes the areas impacted – let’s discuss each one.
SDN Impacts – via Cisco Domain Ten
Read More »
Tags: architecture, Cisco Domain Ten, Cisco ONE, Cisco onePK, cisco_services, data center, SDN, SDN controller, software defined network