InterOperability gradually moving towards one standardFrancois - do share the same view.
Yes, traditionally, but at slow pace the interoperability which is one aspect / outcome of SDN has been gradually progressing competitively, to keep up the product's agility to adapt.
This however, is per vendor choice. The progress is for sure happening in interoperability, but a single framework adaptability for non-legacy products will surely win the bid.
As rightly said by you, when we get vendor and development community and the marketing communiting come with the new openness - thats the beginning.
Thanks everyone for the good pointsWe at Ciena feel strongly about the need for broad industry collaboration, and the success of these efforts depends on vendors embracing open industry standards. Until we can accomplish this, we will be significantly challenged to deliver on the promise of SDN and NFV.
Another lesson from history - CTIFrancois - This is an excellent article and I couldn't agree with you more. Another similar lesson from Telecomms Switching history can be drawn from the 1990s with the evolution of Computer Telephony Integration (CTI) using APIs for PBXs.
Initially, these APIs were closed to each PBX vendor, but API standards started to emerge such as TAPI, CSTA or TSAPI. It would have been nice to have one standard, however, once again, a silos-mentality on a global scale would have been partly the reason for there being three standards.
Re: The Biggest Obstacle is Culturecjantz, great remarks and insights. That is exactly the thinking that needs to go into an eco-system. Not everything needs to be the same, there are different designs for different purposes and values. Your outline provides a solid framework that can truly develop a "workable" system.
Re: The Biggest Obstacle is CultureAPIs are part of the picture but not the entirety. Ultimately what the industry needs is an ecosystem framework that works on two levels: a "technical" level, and a "commercial" one. On a technical level, it must be possible to construct software, and collective software and hardware systems, from the evolving contributions and innovations of many players. On a commercial level, it must make sense for industry participants broadly to support a framework that permits this: they must, generally, perceive opportunities as well as risks, or they will prefer to defend old models. Open systems featuring strong industry support through open source efforts - buttressed by emerging open interface standards among the major forming system "layers" - respond best to this "techno-commercial" imperative by presenting opportunities for all players. Whether they come from hardware or software legacies they have the chance to compete for value at any point or layer of the new software-plus-hardware system. It is particularly important to note that this "new system" consists of software and hardware layers that do not map one-to-one to any existing ones. Convergence – the breaking of old technology siloes – is a key feature of each forming layer, and programmability is a key attribute of the converging infrastructure layer. So it's important to distinguish transitional steps that individual vendors and operators can take, like leveraging existing or provisional interface structures, from the end game that needs to remain the rallying point. - Chris Janz, Ciena
Re: The Biggest Obstacle is Culturesmkinoshita, I fully agree. Unless there is a major drive for collaboration, the small advantages from technology alignments won't overcame the barriers to true change from silos. I like Francois' comment on shifting from ego-systems to eco-systems. That may be the biggest change requirement of all.
Re: optical vs. IPWell it really depends on how you define SDN. I don't expect the vendors to particularly build all of the intelligence around how a network is orchestrated and programmed. I expect them to give open access to the network elements or an intermediate controller so intelligent applications can do so.
OpenDaylight is actually very good in how they have layered and made accessible through abstraction different areas. So topology data could be gathered using a legacy protocol or something newer but is abstracted so a higher layer application doesn't care about whether the topology data came via different methods. That's where the data models come into play. Ciena is using ODL for the basis of their controller and its elements, which is a good step but then Cisco and Juniper are using their own in-house controllers which are completely different. Maybe that's the point of the original post.
GMPLS/RSVP-TE as an optical control plane protocol is very successful, but as an interoperable one not so much. The real reason is there just wasn't demand for it from customers and operators. The operational silos of transport and routing kept it that way. Now with multi-layer SDN we may be left with "IP/MPLS" and "transport" controllers. :)
If the ask for for a REST or RESTful API for provisioning -- that's a far easier task than SDN. That could be done with existing technologies and products. I thing we had a go at this with Tag switching, then RSVP / GMPLS in the OTN -- but those tried to go beyond the optical UNI into the NNI and so faltered.
Is what we (at least you and I and perhaps the author) are really asking for something like ELMI for the OTN if it is inband -- or EVEN EASIER just a published REST or RESTful API for circuit orders ? If so, apart from ONF, couldn't the author and his company Ciena -- get the ball rolling by publising their API. It seems to me that has no dependency on SDN.
Re: optical vs. IPYes I found it interesting the call for open standards is coming from the leadership of a traditional transport equipment vendor where no vendors interoperate with each other. I don't think the article is calling for that either, it's calling for standardized APIs into closed networks. I'm okay with that at this point, the real key is standardized data models to gather data from and program the underlying network and not having to do it differently for different vendors. I should be able to use the same API call to create a circuit over a Ciena network as an ALU or Infinera network. We are only at this point however because of the lack of those equipment vendors in pushing for, adopting existing standards, and making sure they are interoperable. SDN is the holy grail of punting device-level interoperabilityover the fence.
Right now vendors are forced to develop their own data models and APIs while standards are hashed out, but the key is for customers to drive them to adopt standards when they reach maturity.
Openflow isn't a key enabling technology at any network layer really, it hasn't seen any real adoption or serious development due to its numerous shortcomings. I don't believe it will be in the future either. Most operators don't want a centralized network model, and the reality is the control plane components in a distributed network add very little cost compared to other network components.
Yes, traditionally, but at slow pace the interoperability which is one aspect / outcome of SDN has been gradually progressing competitively, to keep up the product's agility to adapt.
This however, is per vendor choice. The progress is for sure happening in interoperability, but a single framework adaptability for non-legacy products will surely win the bid.
As rightly said by you, when we get vendor and development community and the marketing communiting come with the new openness - thats the beginning.