 The importance of network programmability has been well established. Now we are going to look at some very interesting scenarios in the telecommunication and the internet world where we will see how an operator or a customer or an enterprise or even a third party could program another operator, enterprise, customer or a third party infrastructure. We'll start off with the basic motivation of it then we evaluate how much worth it is going to deliver and we'll see some specific requirements through an example. So the motivation is already understood. We need to increase the level of programmability of the infrastructure to create more opportunities which would come with some issues and challenges. The issues and challenges could encompass the operation support system, the business support system because these could be impacted in very strange ways. Likewise, the overall reliability is going to be different from the vendor specific lifelong one-time provision services and we need to have a fault detection mechanism and a continuous monitoring and administration service. Then the services that we shall be providing through network programmability would have to be created, offered, shelved and then removed. So this involves robust and very high level vision of how the overall service infrastructure is going to be like. Programming is going to be need dependent on the level of programmability the network is going to be implementing. While doing so, it is important to understand that the customer who is going to pay for these services has to be taken into confidence because visibility on the customer end is mandatory. Now let's look at the specific example of how introducing programmability could introduce some value. This is a four quadrant representation in which we have high and low levels of programmability and high and low levels of values by introducing programmability. So we are not interested in C and D because these are quite understood. We have low level of programmability and low level of value. So we are going to ignore it. We've got high level of programmability and low level of value. That is actually what we are going to ignore. So let's look at specific cases A and B. A is more of a traditional infrastructure. We have the infrastructure which can't be programmed much. So if we introduce programmability there, the overall benefit that we could possibly reap in terms of value is low. But in B, we are talking about the future networks where we have highly programmable infrastructure. So we need to have more programmability, a high level of programmability and correspondingly a high level of value. Now moving from the traditional infrastructure to the future infrastructure actually is going to involve multiple pathways because we could move from incremental changes to altogether obviating the hardware, which is non-programming supportive and replace it with something that is purely programming based. Let's look at another perspective. We have the business support system and the operation support system interlinked through user APIs. The network management system and the end node management system are part of the OSS, which in turn manage and provide connectivity to the network elements such as routers, switches and so forth. So if we look at this traditional architecture, it would now be overhauled with the introduction of the software defined networking, network function virtualization achieved through programmability, the overlap of STN and NFV and a new way of looking at the changing behavior or alterable behavior of all these things would require some innovative thinking. So at the crossroads of the three, we can think about network programmability where the entities involving a broad range from the customer end to the third party could all be programmed. So what are the development requirements which would appear now? First of all, the business processes or the workflows are going to change. Then the information exchange between the more traditional entities is now going to be modified and the performance requirements of these network elements which are programmable are now going to be redefined and this has to be done by staff with varied level of programming expertise required. So what is programmability in terms of networking? Easier said than done, but at the abstract level, as is a more classical computer science statement that combining algorithms with the data structures is what programs are all about. So if you look at the data structures which would be implemented on the network elements, on the OSS and BSS include the protocols that network elements support on its interface, the management interface, management information base, the MIB or the database to administer the network elements, then the software is going to implement its own data structures like heap, like stack, like queue, like tree, whatever. Then the operation support system would have a connectivity arrangement where it would define the addresses, IP, MAC, port numbers, identifies, etc. And then the device locations, facilities would be represented by proper database resource records and then the business support sub system would have consumers and each consumer would have a profile. And last but not the least, the business processes would also be represented through data structures. Now let's look at the way the future networks would be operated and the traditional present operated networks are being compared. If we contrast these, these could be contrasted across a range of features and attributes, possibly through some I could go through. For instance, we have the manually ordered and provisioned services in the present managed and operated networks. In future managed and operated networks, we'd have the portals or cloud triggered services which are automatically instantiated. Then let's look at possibly the relationship between the present and future networks. The networks are largely independent of applications except specific telco services. But now, when future networks, the networks are going to be programmable by the applications themselves including third party applications. Then let's look at the control plane. In present networks, we have the distributed, purely distributed control plane but referring to the software defined networking and network function virtualization. We'd have a mix of centralized and distributed control planes. If we look at the management of devices, it's more hardware centric device management but we'll have the software centric network abstraction. The example we just looked at, the MIB management information base which is used by SNMP, Central Network Management Protocol. Then we could think about periodic software releases in present networks but in future based networks which are at the crossroads of SDN, NFV and the innovation based technology and application definition. We'd have continuous service process which are sandboxed or secured and this is going to be integrated with the live environment as in DevOps. Now, this particular module has reference from operational opportunities and challenges of SDN, NFV, programmable infrastructure. It's a report from the Alliance of Telecommunication. It's a US based concern which provides industry solutions. Their report comprises many use cases and scenarios. We are going to look at each one of these in due course of time.