Continuing on its tradition of contributing and committing to open source and open standards over the last 25 years, today Cisco announced “OpFlex” – a new open standards-based protocol for Application Centric Infrastructure that has been submitted into the IETF standardization process. We believe this will accelerate multi-vendor innovation in data center and cloud networks to drive operational simplicity, lower costs and increased agility.
Why is this required?
Traditional SDN models today function on the basis of an imperative control model with a centralized controller and distributed network entities that support the lowest common denominator feature set across vendors such as bridges, ports and tunnels. As the network scales, the controller becomes a bottleneck due to the need to maintain increased state, and starts to impact performance and resiliency. Likewise, because the applications, ops and infrastructure requirements need to be translated into network configuration, it impacts agility and introduces a manual learning process, requiring app developers to describe their requirements in low-level constructs.
If we contrast that with the vision of the ACI model with the Application Policy Infrastructure Controller (APIC), ACI adopts a declarative management approach. This model abstracts applications, operations and infrastructure providing simplification and agility. By distributing complexity to the edges, it also increases better scalability, and allows for resiliency – i.e. the data forwarding can still continue to happen even if there is no controller. It further provides ease of use with self-documenting policies automatically deployed or cleaned up from devices as necessary. All of these help circumvent the issues seen in traditional SDN models.
For this declarative model to work across a multi-vendor environment, to translate and map policy definition into the infrastructure, there has hitherto been no standard protocol to do that across physical/virtual switches, routers and L4-L7 network services. This vacuum has led to the development of “OpFlex” – a new open standard recently submitted to the IETF.
Who is contributing to OpFlex?
Several industry leaders and practitioners are actively involved in the standardization process. These include Microsoft, IBM, Citrix and SunGard Availability Services, in addition to Cisco.
Read More »
Tags: APIC, application centric infrastructure, AVI networks, Canonical, citrix, Embrane, F5, IBM, ietf, Microsoft, OpFlex, Shashi Kiran, SunGard Availability Services
March is a rather event-laden month for Open Source and Open Standards in networking: the 89th IETF, EclipseCon 2014, RSA 2014, the Open Networking Summit, the IEEE International Conference on Cloud (where I’ll be talking about the role of Open Source as we morph the Cloud down to Fog computing) and my favorite, the one and only Open Source Think Tank where this year we dive into the not-so-small world (there is plenty of room at the bottom!) of machine-to-machine (m2m) and Open Source, that some call the Internet of Everything.
There is a lot more to March Madness, of course, in the case of Open Source, a good time to celebrate the 1st anniversary of “Meet Me on the Equinox“, the fleeting moment where daylight conquered the night the day that project Daylight became Open Daylight. As I reflect on how quickly it started and grew from the hearts and minds of folks more interested in writing code than talking about standards, I think about how much the Network, previously dominated, as it should, by Open Standards, is now beginning to run with Open Source, as it should. We captured that dialog with our partners and friends at the Linux Foundation in this webcast I hope you’ll enjoy. I hope you’ll join us in this month in one of these neat places.
As Open Source has become dominant in just about everything, Virtualization, Cloud, Mobility, Security, Social Networking, Big Data, the Internet of Things, the Internet of Everything, you name it, we get asked how do we get the balance right? How does one work with the rigidity of Open Standards and the fluidity of Open Source, particularly in the Network? There is only one answer, think of it as the Yang of Open Standards, the Yin of Open Source, they need each other, they can not function without the other, particularly in the Network. Open Source is just the other side, the wild side!
Tags: Big Data, cloud, Eclipse, Fog, IEEE, ietf, internet of things, IoE, IoT, Linux, Linux Foundation, M2M, network, Open Daylight, open source, open standards, social networking, virtualization, Yin Yang
Recently Cisco made significant efforts around open sourcing our H.264 implementation, including covering the MPEG-LA licensing costs for distribution and working with Mozilla to add support for H.264. However, in this attempt to unstick the logjam that has occurred in the standards bodies, the Internet Engineering Task Force (IETF) failed to reach consensus on the selection of a common video codec.
Cisco’s Jonathan Rosenberg explored this topic more in a recent Collaboration blog post. Read on to find out how we’re planning to move forward and why this conversation is definitely not over!
Tags: Cisco, collaboration, firefox, Google, H.264, html5, ietf, Jonathan Rosenberg, Mozilla, open source, video, WebRTC
Cisco recently announced that we would open source our H.264 implementation under favorable open source terms, and more importantly, provide a binary distribution of that implementation that could be downloaded and integrated into browsers and other applications. We said we’d cover the MPEG-LA licensing costs for this distribution as well. Mozilla responded by saying that, based on this, they would add H.264 to Firefox, using our technology.
Part of our motivation for making this announcement was to unstick the logjam that has occurred in the standards bodies. The Internet Engineering Task Force (IETF) is defining the standards for how real-time voice and video will work natively in the browser. Selection of a common video codec is part of that process. The group has been highly divided on this topic, with two camps – one (including Cisco), in favor of industry standard H.264, and others in favor of Google’s VP8 technology.
We hoped that our announcement, and Mozilla’s agreement to support H.264 as a common codec, would provide enough impetus to sway the standards to a concrete decision so that the industry could move forward. Alas, that was not the case. Despite what we felt was a fairly objective analysis on the reasons why H.264 was a better choice for the overall success of real-time communications on the web (click here for a recording), the IETF failed to reach consensus.
Obviously, we’re very disappointed by this. Read More »
Tags: Cisco, collaboration, firefox, Google, H.264, html5, ietf, Mozilla, open source, video, WebRTC
What’s new and exciting with EIGRP (Enhanced Interior Gateway Routing Protocol)? Actually, lots… First a bit a background on EIGRP.
EIGRP is an advanced distance vector routing protocol used extensively by enterprise customers. It is very popular because it is simple to deploy and support. Some major attributes are:
- EIGRP does not mandate many network design requirements and is therefore perceived as “forgiving” and “flexible”. For example, EIGRP does not require support for multiple routing sub-domains or Areas.
- While route summarization is a recommended best practice to minimize route table size, it is optional with EIGRP.
- EIGRP can scale to support thousands of routers in a Hub and Spoke configuration. The Hub and Spoke design is especially popular in WAN networks.
For additional information on EIGRP, please click here. There is also a great BLOG that compares EIGRP and OSPF that I think you will find informative and is posted here.
While EIGRP has a large customer following, some customers have hesitated because of concerns of EIGRP being “proprietary”, which would prevent them from multi-vendor network support. In some cases this has caused customers to design their networks to limit usage of EIGRP, even though they would like to deploy it ubiquitously. One result has been non-optimal network design and traffic flow, resulting from multiple IGP (Interior Gateway Protocol) redistribution points.
That brings me back to what is new and exciting with EIGRP. Read More »
Tags: EIGRP, Enhanced Interior Gateway Protocol, ietf, ietf working group, IGP, Interior Gateway Protocol, ipv4, IPv6, IPv6 deployment, OSPF, WAN, WAN networks