Widely deployed from the core to the edge, IP/MPLS has achieved huge success as a mature, standards-based technology now deployed by virtually every service provider worldwide. As a result, the industry has chosen to extend IP/MPLS and develop a transport profile called MPLS-TP (MPLS Transport Profile). MPLS-TP is the packet transport technology of choice being developed by the IETF to allow service providers to cost effectively migrate existing transport networks to packet based solutions.
Recently EANTC conducted an MPLS-TP Interoperability Event which focused on testing and demonstrating interoperability of key IP/MPLS and Carrier Ethernet features between multiple vendor platforms. This represented a critical technology demonstration for service providers as they begin their migration to packet transport networks.
Read More »
Tags: asr 9000, carrier packet transport, cpt, EANTC, ietf, interoperability, IP/MPLS, isocore, itu-t, MPLS OAM, MPLS-TP, p-ots, Service Provider, standards, Y.1731
There has been a lot of buzz recently about a second OAM (Operations, Administration, and Maintenance) solution for MPLS-TP that will cause interoperability problems between MPLS-TP and MPLS. It is accurate that there is an alternative OAM based on ITU-T Y.1731 (Ethernet OAM) proposed by a number of vendors and countries and indeed, it will cause interoperability issues. As a strong believer in standards, I certainly hope that a second approach does not occur because vendors and customers do not need the additional cost burden that a lack of interoperability causes. The fact is that only the draft recommendation for MPLS-TP OAM based on Y.1731 has begun the first step in a very long approval ITU process -- but nothing more – and in my estimates will take well over a year and could easily take up to two years to standardize. IETF MPLS OAM is widely deployed in MPLS networks today and will simply be extended as MPLS-TP is deployed as a next generation transport solution. In fact, recent interoperability testing of MPLS-TP took place at the MPLS World Congress earlier this month in Paris.
I believe that after careful consideration most operators will see the benefit of having a single end-to-end methodology to operate and manage converged packet optical transport networks, which MPLS-TP using MPLS OAM provides. Operators who select another method that is perceived to meet their short term needs now my ultimately learn that it fails to provide everything they had expected, and that having multiple OAM methods (one for Ethernet and another for MPLS) is not cost effective. It will be interesting to see what happens moving forward. At the very least, operators should make an informed decision on which approach is right for them.
Read More »
Tags: EANTC, ietf, interoperability, isocore, itu-t, light reading, mpls, MPLS OAM, MPLS-TP, Service Provider, standards, Study Group 15, Y.1731, Y1731
As server virtualization continues its takeover, increasing attention is being paid to how we connect all those virtual machines as they zoom around the data center. Because server virtualization breaks the one application/one server model, new tools are necessary to facilitate operations and management. Additionally, the fact that workloads are now mobile introduces new challenges.
Over the years, we have released a number of industry firsts for virtual machine networking, including the Nexus 1000V virtual switch for VMware vSphere, OTV to support inter-DC workload mobility, and FabricPath to better support VM-networking in the data center.
There seems to be a lot of confusion out there regarding the technologies and standards related to access layer technologies, so, for this post, I wanted to dig into the VM-networking and where the related IEEE standards are going. Specifically, I am going to look at our old friend 802.1Q and two emerging standards: 802.1Qbg Edge Virtual Bridging and 802.1Qbh Bridge Port Extension.
Read More »
Tags: Data Center Business Advantage, nexus, standards, virtualization
“WARNING! This is app is in beta!”
Hey how come all these apps for my phone say that.
Lol what’s wrong with that and what is it?
That’s the mobile phone text message that greeted me on New Year’s Eve and for a moment stopped me in my tracks. Then, I burst out laughing for a good 20 seconds.
The text was from my college age daughter, who is really smart and consumer-tech savvy, and knows pretty much everything there is to know about using consumer devices. Yet, I realized, she doesn’t really know the jargon of tech, and a word like beta is a mystery to her. And why should she know our strange vernacular? Why on earth would we in the tech industries expect her to understand an esoteric term like “beta,” which in turn requires at least a superficial description of the software development process to properly explain it?
(You twist down a path needing to explain that there’s an “alpha” that precedes beta, and before long you’re waxing poetic about the agile development movement, Scrum stand-up meetings, and pigs and chickens and how chickens can’t talk but pigs can. Not the kind of banter you really need when you’re trying to get something like Angry Birds installed on your new phone.)
So it got me to thinking: When is jargon needed and when isn’t it? It seems to me that words like “beta” don’t belong at all in the consumer world, even though some consumers are beginning to understand what the term means, at least with regard to their phones (mainly, I find that people think of a “beta” for phone apps as meaning “discounted price, but buggy”).
But sometimes jargon does fill a void and serve a purpose.
While having a spirited conversation with some younger indie/alternative music fans this past week, I was suddenly struck that they use a super-geeky standards term – MP3 — all the time without a second thought. Not only that, but it’s a nickname term with an arcane history, which emerged from the need to have sound accompany video (you might remember when Internet “movies” were created using sequenced silent JPEGs). The ISO standards organization’s Motion Picture Experts Group (MPEG) created multiple schemes (also called “layers” ) for audio encoding, and one of them, MPEG-1 (later 2) Audio Layer III, took hold for music. Since it needed a file extension definition, it naturally got .mp3, and thus the file extension name became the nickname for the format and was eventually baked into a million conversations about music that happen even day among ordinary mortals. I know our Cisco audience will totally enjoy reading an early RFC document so here is one: RFC3003
On the other hand, there is the FireWire story. There was a need to name the thing, but the official term, which is IEEE-1394, was way too geeky for consumers to swallow. That’s why IEEE-1394 got remarketed as “FireWire” by Apple and “i.LINK” by Sony. (Oh, for those who want the spec for bedtime reading: IEEE-1394-2008 IEEE Standard for a High-Performance Serial Bus.)
All of the above underscores how much worlds of Internet and other engineering standards and technologies have become the hidden underpinnings that make everything tick in our homes, from the video that is delivered on our TVs via cable or satellite, to conferencing technologies that bring us together like ūmi telepresence for the home, to how our music is delivered, to how our cooktops work, to how our electricity is metered. With all of these technologies and standards flying around, I think all of us need to be careful not to outright terrify people with techie names. So that is one of my jargon-related resolutions this year: Use jargon appropriate the to audience, and keep it simple enough that it doesn’t confuse or alarm.
Caveat: In the business and technology area, terms like IPv6, 802.11n, MPLS, SNMP, Multicast, WAAS, etc are quite necessary as a way to communicate about standards and technologies that are supported. As long as it’s the right audience, a rich alphabet soup of names on a page is wonderful.
That brings me, though, to the other jargon-related resolution I have for 2011, which is around jargon-laden navigation. Sometimes, I see us (and our colleagues in all regions of technology) taking shortcuts where we’ll invent new names to “make things simpler” and somehow hope that, though Jedi mind tricks, customers will magically understand what these names or labels represent, and be able to navigate through a forest of them.
I’m not going to give you any examples of this second sort of jargon terms, because instead I would like you to nominate your favorites. What names for things do you see deep in the Cisco.com web sites that you believe make your navigation confusing or otherwise disorient you? Comment on this blog, and I’ll then add some of my own favorites that we’re working on addressing.
Cheers, and Happy New Year.
P.S. Yeah, I just know one of the original MPEG group members is going to read this and call out multiple historical simplifications that I made. I will be honored to make any corrections needed.
P.P.S. By the way, Jennifer McAdams has interesting blog from last year about how Internet standards are born and how Cisco helps.
Tags: jargon, standards, webexperience
The first part of December has been very busy for me in terms of engagements focused on Cloud Standards specifically the ITU-T Focus Group on Cloud Computing, where I am a Vice Chair; and as a presenter at the OMG-hosted Telecom Cloud Conference representing the ITU-T.
Well let’s start with the ITU-T Focus Group Cloud Computing meeting. My colleagues and I were greeted by quite a bit of snow at the third ITU Focus Group Cloud Computing Meeting held on November 30-December 3 and hosted by France Telecom-Orange:
We received 42 contributions with focus in orchestration; cloud management; cloud security; cloud broker functionality and cloud benefits. These contributions were towards the five output documents produced in the second meeting.
- Introduction to the cloud ecosystem: definitions, taxonomies, use cases, high level requirements and capabilities. The scope of this deliverable is to provide an introduction to the Cloud ecosystems, focusing on integration and support of Cloud Computing model and technologies in telecommunication ecosystems. The major changes include the addition of the value proposition, requirements and capabilities clauses.
- Functional requirements and reference architecture. The scope of this deliverable is to define the functional requirement and reference architecture of cloud computing, which includes the functional architecture, functional entities and reference points.
- Overview of SDOs involved in cloud computing. The scope of this document is to provide an overview of SDOs; to map the FG cloud working group and output documents to these SDOs ; and , to be as a base to produce a gap analysis that will result in a unique areas that can be under the ITU-T purview, specifically from telecom perspective.
- Cloud security, threat & requirements: Security Cloud has started to be discussed from reviews of other SDOs which are related Cloud Security activities in CSA, DMTF, CloudAudit, NIST, GICTF, etc. After the observation of the existing activities, the FG Cloud tentatively identify security threats from view points of Cloud user and Cloud service provider. Considering the identified security threats, the FG Cloud also studied security requirements to be considered for Cloud Computing Technology.
- Infrastructure and network enabled cloud. Position existing network infrastructure capability is a unique opportunity for service providers to provide bundled offers combining Network and IT resources. In addition, service providers can leverage their network asset to address network availability and performance for secure end to end cloud services. Another opportunity for service providers is to evolve network resource allocation and control to more dynamic in order to meet the needs to provision on-demand cloud services.
Read More »
Tags: Asia Cloud Computing Association, cloud, Cloud Computing, Cloud Open Standards Alliance, itu-t, Object Management Group, standards