 Okay. Well, good morning. Good afternoon. Good evening. Everyone, depending on where you're joining us from. And thanks for joining this session. My name is Charles Echoll. I'm a developer advocate at Cisco. And you may ask, well, what's a developer advocate? Well, we have a team at Cisco called DevNet, and it's for helping developers understand the APIs and integration points of our products and our solutions in the building on top of those. So within that space, we have several great developer advocates focusing on different aspects of Cisco technology. And when I joined the team, I came in to advocate for two things that were very important to me. And those are open source and standards. And I saw these as really great ways for us to interact with the developer community around Cisco products and technologies, places where Cisco's contributing to open source projects and then using those open source projects and our products and solutions, especially in ways that are interesting to developers. Also places where we are collaborating and perhaps leading standards efforts to standardize new things, which are then, especially say networking technologies, which are then those standards support for those is incorporated into our products and solutions. So I really advocate for those spaces and working with developers in regards to open source and standards. Okay, so open source and standards, I think when many people think of those, you don't necessarily think as them being directly opposed, but perhaps maybe not that related to each other. However, I believe that standards and open source really can be and should be very closely related and very beneficial to each other. Perhaps in this simplistic picture, I think of the elephant kind of representing a more traditional view of standards, kind of slow moving, but steady. And then the dog on top being perhaps a bit quicker and more agile, but also less predictable and perhaps going in different directions. So here, the fact that you could possibly help each other out and work together is something that I believe is very important and that I certainly advocate for and try to make happen. And that's something that I'd like to talk with you a bit more about. So here we are at an open source conference and so why this focus on standards. Well, really standards have played a key role in most industries, certainly in the networking space where I'm most familiar with the standards. And I think what we see is that industry, they really demand standards compliance from vendors if you're going to offer products in a certain field. Then you need to comply with standards in that area. And this is to ensure interoperability and also to avoid vendor lock-in. So fortunately, vendors work very well together in general in these standards organizations. Even though they may be competitors, I think there's kind of common value in having these standards. And this is both to ensure interoperability between, like, say, a Cisco solution with our partners and with our competitors. But it also just establishes credibility for our product portfolio. And so there's lots of good reasons for vendors to participate well in the standards organizations. So for those of you maybe not quite as familiar with the standards process, you may have at least some notions of how it goes and I'd say traditionally in standards what we've seen is that it takes a while to build consensus and form a standard. Oftentimes that takes a number of years. Now once you get that consensus and you've reached that, then that's the time when you really start to see the standard adopted and supported added into products and solutions and taken to market. The unfortunate reality is that oftentimes even though multiple vendors have solutions that support the same standard, there's just enough ambiguity and uncertainty and kind of subject to interpretation in the specifications that those things don't, those independently designed solutions, even though they implement the same standard, they don't quite work together, at least not in all facets. So it actually takes a while then to get interoperability, interoperable implementations of that standard working. And while in general that does happen, which is fantastic, the problem is as you may have guessed, this can take a really long time and so that's a real challenge. Now contrast that with open source and I think what we've seen here is the ability to transform an industry or a space very, very quickly. In open source communities, we have people coming together, engaging, working together collectively to innovate as a very, very rapid pace. Things aren't subject to kind of meeting schedules and this building of perfect consensus before going forward. A lot of times it's, you know, contribute some code, get someone to review it, commit it, some people try it out, there's this more iterative cycle and that's really fantastic, the type of innovation and speed that we've seen from all of this. And in some cases, this could even result in like a de facto standard, right? If you have enough people contributing to a project, adopting it, integrating it into their product and solutions, that can happen. And just to let you know, I do see a couple of comments and if you have comments or questions, I'll try to answer them as we, you know, so feel free to ask them. If I don't ask them at the time that you state them, let me know or sorry, I'll try to get to them at the end and I'll try to leave time to answer questions at the end. So hopefully, I'll be able to answer all your questions. So while we see all these great benefits and speed and collaborativeness with open source, I'd say there is some complexity involved with it and some real challenges. One thing is typically, when you look at an open source project, the way you go about downloading, building, installing, using it, there's some assembly required there. And because the project is a little bit more say general purpose, perhaps maybe not as well documented as say something that you might get from a vendor who's offering you support for that. You know, it's not universally the case that open source projects have poor documentation. I think as a community, we've been making great strides to focus on this and improve it. But still, the fact of the matter is many people would much rather spend time developing new features, fixing bugs, doing those types of things than going back and documenting them. And you know, it's something that we have to work on as a community, but can make it very difficult for someone who's trying to use our code. Also, even when you have very well documented and great open source projects, generally focus on a specific aspect, provide some specific functionality. They don't actually provide an entire solution. So in order to get a solution, what do you need to do? You need to take multiple different open source projects, perhaps write some code of your own, integrate them all together. That's the more realistic thing. So that's hard to do, especially as all these different projects are moving on their own trajectories with their own release cycles and whatnot. So there are some real complexities and challenges with using open source and building a product on top of it, right? So what I'm seeing or what I believe is that there's a huge opportunity for us to benefit both the standards community and ourselves in the open source community by bringing these two worlds closer together and working more collaboratively. Really to bring that speed and spirit that we see with open source and bring that into standards efforts. And to go and validate a standard as it's evolving, if you're actually implementing it at the same time the specifications being written, that's a great way to validate the correctness and completeness and see if there are any ambiguities in that spec. Raise those issues forward and then get them addressed. Similarly, once a standard is being developed, if we can add support for it into open source projects, remember that industry really relies on these standards. So if our open source projects support those standards, well, that makes the code more usable by those industries. And if at the same time we're writing the standard, we are releasing libraries, utilities, perhaps implementations of those standards, that would make it easier for our product developer then to go and add support for those into their open source or even into their proprietary technologies. So as an example of this, I'd like to look at the network automation space because I think there's an awful lot going on there right now both in open source and in standards. In the keynote, for example, there are several mentions of the Cloud Native Compute Foundation. I'd say one of the fastest growing and largest projects within the Linux Foundation, probably within the world right now. So a lot of attention here in the Cloud Native Compute Foundation. And that's really going across many different layers. If you think kind of going from low level up to higher level in terms of the stack, that's the way this slide is arranged with open source projects on the left and standards on the right. So you see Cloud Native Compute Foundation there. OPNFE was also mentioned and that's kind of covering this whole stack and trying to bring a solution together there. Open Daylight, a controller in this space that I'm familiar with and contribute to, along with other open source controllers, Onos, Open Contrail, in this space, all Linux Foundation projects. So you can see Linux Foundation really has multiple different open source projects at every level of the stack. Similarly, on the right-hand side, if you look at the standards organizations that focus on different areas of this stack, the space is very well covered and the standards organizations need to work closely with each other and in most cases, hopefully, do to put a solution together and cover all the different aspects of network automation, but there's really a great opportunity for people to cross that line, right? That divide between open source and standards and vice versa and work more collaboratively with each other. So an example of a standards organizations that is, I think, making good progress in this area is IETF. For those of you not familiar with IETF, it stands for Internet Engineering Task Force and it's been around, let's see, for over 30 years now, really created with the goal of defining the key protocols on which the internet is based, things like TCPIP, DNS, those kind of core components that are part of the internet and part of really any networking system that we use. Now the goal is really to make the internet continue to evolve and get better to meet the challenges as more and more people are using it for more and more things. So in the networking space, for example, applicable to network automation, there's networking protocols like VXLAN, GRE, but then there's all the network programmability things around Yang models and NetConf and RustConf. These are all standards in the network, I'd say are relevant to network automation and I think are also very, very relevant to the open source projects in this space. Now I wanted to mention this kind of unofficial mantra of the IETF, you know, we reject kings, presidents, voting, we believe in rough consensus and running code. The IETF is a very interesting place in that you participate as an individual and everyone can contribute independent of, say, their company. When I'm there, I don't act as a Cisco employee. I'm me and I'm contributing. I don't need like Cisco to sponsor that, for example. I think very much like open source. I see a lot of similarities actually in the way that the communities are built out and how they work together. Now the challenges in the IETF are, as you may expect, it's a bit slow. And I think it's always been a little bit slow, but that was okay perhaps a number of years ago. Now with the pace of innovation, it's really becoming a problem because if the IETF spends too long working on a standard, by the time that standard's ready, there's perhaps even an alternative that's come out of de facto standard based on an open source project or something like that, so that if you're not developing the standard and the time that it's needed, it's not really useful. Although there was that focus in the mantra on running code, what I've seen and what I think others have seen is that really the majority of the time and the effort is spent on achieving this rough consensus, which is a very important thing that is done in the standards group, but perhaps not like enough emphasis on running code. So we need a bit more of a shift toward that software development practice and actually creating running code. And so these are things that the IETF realized were challenges and that it wanted to be able to address. That was actually started and continued to run these hackathons within IETF. And the goal there is to advance the pace and relevance of the standards that IETF is working on and the way we do that is by really fleshing out important ideas and concepts and then feeding those back into the working group in combination with working on the standard. So as the standard's evolving, we're implementing it, we're iteratively feeding information back in from that implementation experience, I would say, to continue to move things forward. It's also an attempt and working very well to attract more developers, right? Typically in the IETF, the standards people were more like system architects, people who might not actually write or be very close to the developers and those who were implementing and adding support for the standards into the products. Now we're bringing more developers and tends to be a bit of a younger community too and bringing them into the IETF and enabling them to really contribute meaningfully in ways that are important to them. So not just by necessarily reading a SPAC and participating in the meeting to form the rough consensus, but by writing some code and then illustrating through that that something does or doesn't work or something that needs to be addressed by the group. And that's been fantastic. These hackathons are free and open to everyone which really is great because it makes it easier for people to participate and I need to point out they're very collaborative. Oftentimes hackathons might be construed as being very competitive and working against each other. So here the idea is very different. There's no prizes, there's no winners. It's just everyone working together to move the IETF standard process forward and certainly inner working across different working groups and different teams it happens all the time and it's welcome, it's celebrated. That's kind of one of the key reasons for getting everyone in the room together. You can see the... When we first started the hackathon was about five years ago and we had 45 people participating and now that's grown to where we have three or 400 people participating. And if you put that in relation to how many people are coming to an IETF meeting it's typically 1,000 to 1,200 and overall that number has slowly been declining. So here's that increasing aspect of IETF where 40, 30, 40% of the people who are participating in the meeting overall actually show up the weekend before which is when we have these to participate. We're actually going to try this time to do something we've never done before and have a virtual hackathon. It's challenging because a lot of the synergies come from putting people like bringing them together and having them in the room together but that's obviously something we can't do much like we can't meet for this conference together so we're going to try to do what we can. And let's see. So here's an example of how the IETF as a community is embracing and trying to engage developers more. There's actually... We're using GitHub and we created a GitHub org for the hackathon and so then what we did was we... That's where we work on our project presentations and not that all the code needs to be there. If you look, you'll see there's only really a small number of projects there. The majority of the projects tend to have a home somewhere else maybe not even necessarily on GitHub, maybe hosted on GitLab somewhere or Bitbucket, but it's somewhere that people can get access to and that's critical but here we're trying to meet developers where they are and make it easier for them to participate. Along those same lines there was actually a working group created within IETF to look at how can IETF working groups use tools like Git and GitHub more effectively to put some kind of best practices and guidelines in place. Basically the IETF usually uses a bunch of homegrown tools which are very good but they're not intuitive to a developer. So now the idea is let's take tools that developers are already using and let's try to use them to help with our standard process. You can see here there's actually a GitHub URL associated with the charter page of this working group and this is what it looks like. It just spells out those rules for here are some guidelines you don't need to use these but here's kind of some best practices and thoughts about how you would want to make use of GitHub better and a lot of it relates to how do you take a community that's traditionally worked with mainly emails, email aliases and mailing lists and now integrate in a more of a web-based workflow to get GitHub into that. An example of that is this quick working group within IETF. Quick for those of you who aren't familiar with it it's defining a new version of HTTP sometimes called HTTP v3 and it's running on top of actually UDP as a base. It's a very quickly moving very a lot of people collaborating in this space and so it's a really good test and an example of how collaborating with using Git and GitHub has allowed a lot more people to mainly developers to review drafts very quickly and provide comments in a way that is very intuitive to them and doesn't require them to learn all new infrastructure and so I think this working group is really seeing very rapid development despite the fact that it's pretty controversial contentious and very a lot of stakeholders so it's a good success story I think for the IETF and something that we'll continue to see more of. Okay so an example of where this is working relatively well from an open source perspective I would say would be with Open Daylight I mentioned Open Daylight earlier in the presentation it's really a platform I would say for software-defined networking and thought of as an SDN controller or a network controller I don't plan to go into all the details of it but what I'm using here is just a block diagram that shows the components, the various components of Open Daylight and on the next slide what I'll do is light up in green this comes through for most of you those components that are directly related to IETF standards and I'm sure many others actually have relation in them but these ones even by name you can see the IETF standards that are related to it starting from the bottom you have like the virtual and physical devices the actual network equipment above that is this layer where all the different protocols are these are ways for interacting with those network devices you can see NetConf, List, BGP, PSAP, CAPWAP others all IETF standards and there's basically drivers or modules so that you can interact Open Daylight can interact with devices that support those standard protocols and this was critical to making Open Daylight a usable platform for all of these network devices that exist in people's deployed networks today in the middle you see different kind of network services that's where there's Lisp services Service Function Chaining, several IETF standards in that area UNI manager which is implementing standards developed in IETF for network programmability but also in MEF for network services also there's a group in IETF defining standards in that area as well and then moving up the stack all the ways that Open Daylight can interface with applications because that's really the goal of Open Daylight is to provide a platform on which you write network applications and that's using standard protocols REST and then ones that have been developed in the IETF RESTConf and NetConf those are standard protocols that you can use too to interact for higher level applications to interact with Open Daylight so to me this is really a great success story where key standards that are relevant in this phase are being developed and added into the Open Source project I'm just going to transition a little bit and I do see there's a couple questions on IPR and I'll come back and try to answer those at the end I'm not a lawyer but I can give you my take on some of that it's kind of a challenging thing and we could probably spend a lot of time discussing it I'll try to leave several minutes for that at the end we're doing pretty well on time so MEF for those of you who aren't familiar with it was really the place where carrier Ethernet if you've heard that term I'd say MEF developed and brought the whole carrier Ethernet market to space this is how do multiple different service providers who are using network equipment from different vendors how do they offer network services to you as a network connectivity to you as a say as an enterprise or a subscriber and doing that in a standard based way such that you could say yes this equipment actually supports the carrier Ethernet standards or this service provided by the service provider is compliant with those with that standard and really what that did was that helped different service providers interoperate with each other helped the whole industry move from really disparate hard to compare apples to oranges types of service to a more ubiquitous level of service and so the carrier Ethernet market just completely took off and I'd say MEF has pretty much addressed and solved that problem for the industry now what MEF is doing is moving up the stack defining higher level network services non-just basic connectivity services and so that's really the goal of MEF now and so those same networking automation specifications standards and open source projects that we've looked at are very relevant to what MEF is trying to do now as well so as you might have guessed how do we address this and try to make it happen well let's try having some hackathons there as well MEF is not a place where developers would typically go and participate and this was an attempt to try to address that gap I would say so similar to an IETF the idea was hey let's bring these open source hackathons in and let's try to take what the focus which was typically on defining some services and then certify those services let's shift that focus a bit more to actually defining some APIs and then writing code that implements those APIs and making that part of our standards process with that same idea of validating that those APIs are complete and that they're useful and that you can build services on top of them and that's going to enable much more interactive communication between different service providers between subscribers and service providers to really realize this sort of more automated more dynamic network services also collaboration between across different STOs and with open source communities was a real goal of this now this had a really profound impact I would say on MEF and what we saw was the shift from really just focusing on services defining of services and then the certification of equipment and providers of those services to incorporate much more than just that so you see within MEF there was a creation of two completely new components I guess I would say to complement the service and certification approach one was around APIs LSO stands for life cycle service orchestration so these are really APIs that will help with the automation of network services both east west between service providers and north south as you go up and down that network automation stack and then super important and probably the thing I wanted to focus on is the community aspect actually realizing that it's important to work with developers to have very open and collaborative development of SDKs of sample applications of sample clients and servers in this space that actually implement these APIs and start to realize the use of them and make sure that it's not just a service that we're defining on paper that you can really only interact with your certification but that you can interact with the code as well and then just one more example this is not a standards organization but the AIS it's a conference held in Africa the African Internet Summit and it's held annually and the African Internet Summit and the and the Internet Society that works closely with the African Internet Summit really one of the goals there is to help I would say increase awareness of ITF standards and where they're applicable within that space and there's a goal to try to get more people participating like to make it easier for people from from Africa where they be developers or say people in the standard space it tends to be a little bit harder for them in many cases for a number of reasons to participate in the ITF standards meetings either because of challenges related to the logistics of getting there and then also the fact that the ITF meetings tend to not go and be held in Africa they tend to be held in North America and Europe and various parts of Asia so the goal here was let's bring the ITF standards and an event focused on them into Africa and engage developers there really build some technical capacity around those standards work on deploying those standards like getting hands on experience with them and then actually deploying them and that same idea of when you deploy or use a standard or try to implement it you gain experience with it and you can feedback what you've learned into the standards process and so that really enables contribution back from the African community to the ITF standards in new and interesting ways so all of the projects there were related to ITF standards and you can see a number of them here I led the first one here on network programmability that was really focused on implementing those same standards protocols that I mentioned before in the network programmability space namely Yang and Yang models and then Netconf and Resconf were protocols by which you interact with those Yang models and the APIs that are defined by them so it was really great collaboration and just another example of how engaging with developers in this case developers in Africa to really facilitate their participation and contribution back into the standards process so my take away for you and really my call to action for you is I hope that through this discussion and the Q&A session that we'll have afterwards that you agree with me that there's a really great opportunity here for us to bring open source and standards together and for the two communities to really work well together so I'd like to see this champion this combination of open source and standards with the goal really to make standards that are being developed in places like IETF in places like MEF make those standards much more consumable by developers and the way we do that is by developing open source libraries utilities components in parallel with the development of the standard so now you don't just have a specification you actually have code that you can start using right away to help with your understanding of the standard your implementation and deployment of the standard and hopefully with incorporating support for that standard into key open source projects when we get the standards incorporated into key open source projects then that enables this industry that relies on standard space implementations to really use our open source and so that opens up just the space for our open source projects to really be incorporated into the solutions of say these service providers in the case of MEF and now you start to see much more contribution and support and sponsorship coming from these organizations because they can tie back you know they're getting material benefit from the open source projects and those open source projects are really important to their business one way you can do this is you're the next IETF hackathon this will be at IETF 108 which is at the end of July and instead of having the hackathon be the weekend before IETF which it typically is we're going to move it to the entire week before and this is because time zones are so challenging and the weekend is not it's easier for people to give up the weekend when they're all traveling to a place and they get there early and they work together for two days but when everyone's working from home there didn't seem to be that same driver or desire to spend the weekend working on it especially with the differences in time zones so this allows people to carve out time within their week when it's convenient for the individual project team and so we'll have a set of teams working on different projects related to IETF technologies and I would love for you to check it out it'd be great if you have projects where what's happening there is incorporating IETF standards as they're evolving into important open source projects in this space so with that I'm going to go back and spend a little bit of time on the Q&A and I welcome those of you who have questions go ahead and put them in and I'll try to answer them as best I can okay first one says a great point Charles happy that you and Cisco are members of OASIS Open where we are trying hard to merge open source and standards in meaningful ways so that's fantastic OASIS Open I guess another example where these worlds are already making progress of coming together and I think in the keynote we saw a few things the Linux Foundation is doing and really great progress in this area as well so IETF and MEF are two places that I'm very familiar with fortunately there's other places that may be even ahead of what we're doing in IETF and MEF and if so that's fantastic so it's great to hear that there's good work going on there as well next one Charles would love to hear more about how we deal with IPR issues and the merge between open source and standards that has sometimes been a bottleneck yeah so IPR is certainly has been and will continue to be a challenge in standards industries and I think the same reason will be a challenge in open source the model that I'm most familiar with is probably that in the IETF again where the idea is if you have IPR and a space you're obligated to declare that IPR that you have and typically the way this would work would be let's say at Cisco we have some IPR related to a standard that we're proposing or helping the industry propose what we would do is say hey we do have this IPR and we will make it we will license it for fair and reasonable terms and that way people know that there's potential IPR associated with this standard or the key I left out there and again another lawyer so don't hold me to the exact terms of this but you can use our IP for the purpose of implementing the standard and so you're kind of free to do that you're getting a license for that you can't use it just in perhaps other ways but that way it allows the standard and the implementation of the standard to be free of perhaps very any real big negative IPR problems and I would think for open source we can and should be doing something kind of similar but there is that group and sorry that I don't know the name of it I tried to make a note of it the one within Linux foundation the new project that's helping to merge these two worlds together and to help standards like behave a little bit more like an open source project I'm sure they have people in there that are very good at dealing with this and hopefully can do a better job than I am Ray says are there challenges in terms of IP or legal yeah when trying to collaborate between so pretty much the same question I guess and yeah there are I don't think they're new at least you know like I said we had to do this in the standards community and I would think in the open source community they're going to be a little bit similar in standards community you have your rules and procedures and kind of your terms that everyone agrees to in the ITF there's something called the note well and you know that at every single ITF meeting you're operating under those policies and when you contribute something you're basically contributing it to the standard process so when you speak in a meeting when I'm speaking at this conference I'm essentially contributing to to the process there either to the open source community or to the standards organization so I think we probably need to have something like that and it gets a little bit more challenging I think because of the different open source licenses and again I'm an expert here but you know some open source licenses make it very explicit that they're granting you granting you a right to the IP associated potentially associated with that code others it's not quite as clear so I think that's what you'll see open source projects making sure that they use licenses that carry the right IP policies along with them that's one thing we can definitely do to make sure that these two worlds come together a little bit better and John asks how do you see the relationship between standards bodies and the various consortiums being spun up by hyperscalers and hardware manufacturers playing out I don't know because I don't participate real actively in that space it sounds like they are you're saying that they perhaps it's a little bit new of a space I guess compared to some of the others like the networking space we didn't see good collaboration at all between open source and standards it took some time but now we're there IOT there's tons of different consortiums different standards groups I think a place where the Linux foundation can really help to bring those worlds together and the beauty of open source is and even of standards is there so many of them but it's also a challenge at the same time because you don't want to stifle innovation but you want to kind of guide it in certain directions and avoid different solutions if they actually are useful to the community so I think there's a role we can all play by being aware of these things don't ignore consortiums, open source projects in this space if you see them don't purposely ignore them I would reach out to them and engage with them and I think the Linux foundation with its kind of credibility with being able to do this would be a key place to help with that kind of larger problem with those different manufacturers together and ARPID has some IPR answers MEF and LF have an agreement that allows formal collaboration for SDOs and OSS projects so that's fantastic these agreements between LF and SDO allow for implementing standards in code and also push code into upstream standards with open source friendly licenses on interfaces yeah so fantastic ARPID that's great to hear and that makes a lot of sense again by choosing the right and appropriate licenses there that can remove a lot of that ambiguity I think and that's certainly helpful and that's where Linux foundation has great experience here and can really help navigate that space and that's one of the reasons for talking about this conference so thanks a lot for that ARPID that's great any other questions we have a few minutes left if there's anything else if you did ants ask a question and I missed it my apologies but as far as I can tell I got through them if after this session you want to reach out to me at any time my you can reach out to me via email Twitter my email is eckelcu at Cisco.com and on Twitter I'm the same I'm eckelcu as my hashtag you can reach me there if you look at my bio hopefully that's there I don't know if it is but I'm happy to connect with you through this platform too I hope we all so far I'm enjoying using this this new platform and meeting virtually of course I miss seeing all of you in person but this is much better than not having been able to meet at all so excited to have had this opportunity thanks a lot for tuning in and listening and with that let me check the Q&A one more time and if there's nothing new then thanks so much I look forward to engaging with you throughout the rest of the week at various other talks and in the virtual chat rooms and whatnot so yeah thanks for joining please enjoy the rest of the conference