We have a special treat, a luncheon keynote speech with Acting Assistant Secretary Joseph Yun. It's a real pleasure to introduce Joe. He really probably needs not much of an introduction with this crowd, but he is our acting leader of foreign affairs when it comes to Southeast Asia and the Asia Pacific generally. He's the current Acting Assistant Secretary in the Bureau of East Asian Affairs at the Department of State. His previous assignment was Principal Deputy Assistant Secretary in that bureau. And as you know, Joe is a career member of the Foreign Service, having served in South Korea, Thailand, France, Indonesia, and Hong Kong. And I would say of the leaders who really know the region and have put in the hard yards, Joe would be at the top of that list. Joe, we're honored to have you here. And I'd like to ask everyone to welcome Assistant Secretary Joe Yun. Do we need this computer here? That's all right, yeah. Well, thank you very much, Ernie. It's great to be back at CSIS. I think many of you know what a tremendous job Ernie has done bringing the Southeast Asian program to CSIS. I mean, it is undisputably the leader of Southeast Asian programs, not just in the US, but worldwide. I understand this is the third South China Sea conference, and we're getting more and more people every day, you know, I mean, every time. And it's beautiful weather out there. I don't know. You guys must have something better to do, you know? But it's really a testimony to what he has created that everyone is here today. As Ernie introduced, I am the Acting Assistant Secretary. As you know, our good friend Danny Russell has been nominated to be Assistant Secretary. So my days are somewhat numbered, you know? I've been doing this now for about five months. And so when I became Acting Assistant Secretary, it's a long title. I called my mom and said, mom, I think I got a promotion. I'm not sure what it is. And he said, what are you now? And I said, well, I'm Acting Assistant Secretary.  Yeah. Well, there it is. We don't have much time, and I do want to leave a lot of discussion, especially questions from you. So I will do away with my usual introduction on how much we've done in Asia. And let's move straight to South China Sea issues. And really, there are about seven points I want to make on South China Sea. Number one is the United States really does not have a position on competing territorial claims. And those are sovereignty issues. And that's a key fact you should know. And this is true throughout Southeast Asia. And in fact, it's true of a lot of the claims issues. We do not have a position to which a claimant, certain island or rocks or maritime features belong to, that we have no position on claims, particular validity of claims. Second point I want to make is that claims, however, must be based on international law. They have to be consistent with international law, including, of course, the law of the Sea Convention on Clause. And underlying that point is a very important point that claims to maritime space in the South China Sea must be derived from land features, that they have to be justified. If you are making a claim to a maritime domain, maritime space, then it must be justified based on land features. The third point I do want to make is that while the United States has no position on sovereignty, the United States still has enormous interest on how these disputes are addressed and how these disputes are settled. So that's the third point. And so you may ask, well, what is our interest in South China Sea? And I would count foremost in that freedom of navigation. This is an enormous global common in which a lot of commerce, by some account, something like 50% of shipping tonnage goes through, South China Sea goes through. And so we rightly have an interest that these commerce must be protected and that there ought to be freedom of navigation within these global commons. Second interest is, of course, low-full exploitation of resources there. That is, for example, we have companies that are working for oil and hydrocarbon exploitation there. If this is lawful, they ought to continue to do their activity despite whether there are claimants or not. So those are our interests that goes beyond, I would say, sovereignty issues, leaving aside who the sovereignty rightfully belongs to. The fourth point really derives from that. That is, we do not believe any claims ought to be forwarded through coercive measures, through threats, and certainly not through use of force. So that's the fourth point. The fifth point I would mention is that, then, how should those claims be forwarded? And we believe they should be done through peaceful means. Example of peaceful means is diplomatic negotiation. Another peaceful mean is through third-party mediation. I would say another peaceful pursuing of those claims is through recognized international arbitration. So those are peaceful means of pursuing those claims. And if you pursue through peaceful means, then certainly there ought to be no threat, no intimidation, and certainly not retaliation. That is, for example, if a country decides to go through it lost, then another party who has competing claims should not intimidate that party that goes through arbitration. Then the other party should not retaliate because you have chosen to go through it lost arbitration. And for us, the way ahead, and this is my last point I'll make on South China Sea, is that we believe that given so many claims of South China Sea that it is very important that there be no immediately, no unilateral attempt to change status quo. And second point I would make on that is that what we need is really rules of the road. How the parties should engage. And this is why we support China US attempt, or beginning of negotiations on code of conduct. This code of conduct is very important because that will set the framework on your behavior, on how you pursue claims, and what happens if there is a dispute. And so we're very, very much supportive of that. Thank you. I understand that there was recently a meeting between China and the Asian states. I think it was in last week in Bangkok where they had a working level meeting on the predecessor to COC was, of course, DOC. And on DOC. And I think there seems to be an understanding that at a future date, maybe sometime this year, they will announce a formal beginning of negotiations on COC. If that's the case, we will genuinely welcome it because we see COC as a key piece of puzzle that will bring peaceful resolution, peaceful negotiations, and peaceful pursuant to these claims. This is an issue that goes back a long ways. And I think behind it, a number of historical issues. Behind it, a number of traditional issues. And I would say over the last few years, things have become a little bit more tense. There have been a number of fishing boat incidents. There have been a number of incidents involving exploration vessels from various partners.  And before that, a number of incidents off the shore of Vietnam. And earlier this year, incidents of Borneo Kalimantan area near Sabah Coast. So this is worrisome for everyone. And I think it is very much up to China and ASEAN to get the issue of COC settled. And certainly, a number of senior US officials, including President Obama in last year's East Asia Summit. And of course, Secretary Clinton has made their views known. And really, on this particular issue, while the negotiations of COC is between ASEAN and China, I would say anyone who uses that global common has an interest in it. And practically, everyone I know of that uses global commons is very supportive of COC. So those are our views on South China Sea. And I'm sure with this many people, there are other views out there. I'll be very happy to entertain them with the help of our friend, Ernie. Thank you very much. Thanks, Joe. Can we sit down? Thank you very much, Joe. I think that was a terrific and very direct outlining of the American, of the US position. Really helpful. And it builds on our discussion this morning. I'd like to open up the floor to questions. After I pose the first one as a chair. And that is that the goal of our discussions over the next two days is to build recommendations that you can use in preparing Secretary Kerry and the president for their trips. And I know Secretary Kerry is planning on a trip to the region in June for the ASEAN regional forum. And the president would plan to go to Brunei and some other places in October for the East Asia summit. Is there, what's the state of current planning and your current thinking on how the United States could be, use these two meetings to advance some of the points that you discussed this morning? I think for us, there are a number of important aspects to it. I think number one is for recognition to everyone to know that this is really, I would say, cockpit of global economy. That any threat there will affect economic growth and development. And I think everyone is trying to understand that. Second thing is high-level engagement. I know that, of course, as you mentioned, Secretary Kerry will be going to ASEAN regional forum. And there will also be, in that venue in Brunei, will also have East Asia summit for a minister's meeting, as well as US ASEAN for a minister's meeting. I think for us, it is important to gain consensus among ASEANs. And of course, over the coming weekend, in fact, Friday and Saturday, President Obama will be seeing President Xi Jinping in California. And so these are broad-level discussions that I think, as our leaders have conveyed their points, I think they will begin to realize the importance of economic stability. And moreover, the importance of what the idea of global commons that is at work here. So I think as we exchange these views, come to an agreement or come to an understanding. To be frank with you, I'm not sure these territorial disputes, whether they're married time or whatever, can ever be fully resolved in the sense one party says, damn, I think you're right. I never thought about that. I don't think that's going to happen, but at least I have a working hypothesis or working idea, operations on how we do not disturb stability in the region. That's the goal. Thank you. Let me open it up. The lady in the red. Hi, Mr. Secretary. Thank you for coming. My name is Nadia Chow, Washington Correspondent for Liberty Times. We know the code of conduct is very important, but Taiwan has never been included during the process of a dialogue. Given the recent incident between the fishing boat incident between the Philippines and Taiwan, do you think it's important to find a way for Taiwan to participate in the dialogue? Will the US encourage that? Thank you. Thank you very much. I'm very aware of course the recent fishing boat incident in which Taiwan's fishing boat captain, I believe, lost his life and has a very, very regretful incident. And that is precisely why I believe we need something like code of conduct. And I think code of conduct, it wends China and the ASEAN agree, is something that becomes operational throughout South China Sea. And certainly, we're not involved and parties other than China and ASEAN are not involved. But there is no reason why other countries cannot say, you know, adhere to that code of conduct. So I'm not sure the importance of actually being on the negotiating table as much as importance between the claimants who are the disputant coming to terms with that. Thank you. OK, I have Chris Nelson and then the gentleman here. Thanks, Joe. Chris Nelson, Nelson Report. Those of us who were just out at the Shangela conference, and forgive me for repeating for those who were here, found it frustrating that in the face of every very explicit question to our Chinese friends about our concerns about the rise of the use of coercion, either explicit or implicit, the basic response was these aren't claims, these are our islands. There's really nothing to discuss. What are you talking about? Are you getting that kind of response when you try to discuss these things with our Chinese friends? Or is there more likelihood of a discussion that recognizes the gravity of the risks that are involved? And what do you anticipate the response may well be out in California when the president does, as they made clear from the NSC briefing last night? They will raise these issues. Thanks. Thank you, Chris. I'm not sure with all the cameras around, I should be commenting what president might say this weekend in California. So I'll stay away from that. But however, in regards to your question, we've discussed this at many levels with our Chinese friends. And of course, they recognize there is a problem here. And I think this is not a secret that we have discussed with them. We press them on the importance of getting code of conduct done. So at every level, and I do expect this issue to come up, I mean, maritime disputes, of course, not unique to South China Sea. We have another one in East China Sea. We have one, for example, Dr. Takeshima between Korea and Japan. I mean, the United States has one, more than one, with Canada, for example. So this is not a unique situation. But I think what is a little bit different on this is that this is a dispute that has such enormous impact on everyone in the region. And this is a dispute that affects livelihood so much, including fishing, hydrocarbon exploitation, and of course, the shipping component. So this is where it is a little bit different and where the international community, I believe, has a stake in a peaceful resolution. I've got a question in from Twitter, actually. This is from Kuala Lumpur. And the question is that there's been a lot of praise for Brunei's diplomacy as ASEAN chair this year. Will they be able to handle the pressure and raise these issues about maritime security at the ASEAN Regional Forum and the East Asia Summit? And how do you see Myanmar's handling of these issues when it chairs ASEAN next year? Well, thank you very much from our fan in KL. ASEAN is, I would say, something of a unique organization. And now I've been doing ASEAN work for four years. And in the beginning, I was totally clueless. They'll probably say I'm clueless now, but I think I've gotten to know it a little bit better over the last few years. And there is a very important search for consensus in ASEAN. And I think that's a really attractive quality about Southeast Asians, that you want to form consensus. And they will search long time. And to me, their capacity for patience is amazing. And so I really do admire ASEAN's about that. And so you will get criticism, especially from non-ASEAN's, that it is moving very slowly, whether it be code of conduct, whether it be connectivity issues, creating single market issues. But I think that's a search for consensus. And given the history, they've had tough history in Southeast Asia, for those of you old enough to remember. And so to me, even the code of conduct, they are deliberating. For example, on DOC, Declaration on Conduct of the Parties, that was signed in 2002. The implementing agreements were agreed in 2012. So it took 10 years from the signing to get to implementing agreement. So I have no illusion, really, even if the code of conduct begin discussion soon, it will take a while. And by that time, Ernie, you and I could be retired. But still, I think the process of doing it is very important for ASEAN. And coming back to question, I think that is the role of the chair, to be an honest broker, to make sure the process and consensus is observed, and really have full admiration of Brunei's friends for that. I mean, as you know, Salton of Brunei has been busy traveling to go to all countries. And he came to Washington, I believe, was in February or March, about two, three months ago. And he's really been getting frequent fly miles doing this. Well, he's on plane, but you know, yeah. And so I think that's a great thing, even a relatively small country like Brunei is pursuing that. Myanmar, as you know, Myanmar will be chair next year. Right now, they are also what we call our dialogue coordinator.  Very few, yeah, you know? What dialogue, I'd actually play a very important role. What dialogue coordinator is that for non-Aseans that have dialogue with ASEAN, like the US, like China, Japan, Korea, they have a coordinator who act as an intermediary. And so it's a turn of Myanmar to be the US dialogue coordinator, and they're doing a great job. I mean, let me tell you the importance of dialogue coordinator. Right now, Thailand is the dialogue coordinator between ASEAN and China, which is why the meetings were held in Bangkok between ASEAN and China last week. And they are doing a great job trying to move this process along, you know, being the go-between, between ASEAN and China on code of conduct, especially.  And for us, engaging ASEAN is a very important pillar of what we call rebalance to Asia. And we've expended considerable effort in that. As you know, we now have two missions in Jakarta, one for Indonesia, one for ASEAN. We've joined all the, you know, conferences and summits that go with ASEAN, including East Asia Summit, you know, Defense Minister's Dialogue and so on. So, ASEAN of today is not the ASEAN of, say, 20 years ago. It's much more dynamic and it is much more inclusive. And I would say much more strategic. Thank you, Joe. The gentleman here. My name is Vishnu Podil, National Advisory Council South Asian Affairs. My observation over the years have been that when these head of states meet, very pleasant, all problems are solved. And they depart with a very beautiful, agreeable communication. And I'm speaking, especially in the context of presidency and President Obama meeting in Los Angeles in a couple of days. And then I'm afraid after that meeting is over, beautiful communication are issued and the whole world is happy. Now everything is going to be great. Then when they go back, after sometime the situation remains as is and nothing much is changed just as Secretary Joseph said that code of conduct was passed 12 years ago, it took 12 years. So is there any strategic plan that we, the United States of America are thinking through about those issues, be it with Putin, be it with Xi or be it with anybody? Thank you very much. I think what you should probably realize, I'm sure many people do, is summits are kind of what the two leaders do. And but there are a lot of work that go on before the summit. And for example, before President Xi comes to Washington, I mean, sorry, to California, you'll notice that Tom Donilon went to Beijing and even before that we had number of exchanges, number of exchanges on agenda and so on. But I would say just sticking with California item for a second, this is something quite different. And to have really day and a half of two leaders sitting down. And this is a little bit different from other summits where deliverables are already there. I think in this case, really the goal is for President Obama and President Xi to get to know each other and to have a broad agenda.  They'll range from security issues like North Korea, Syria, maritime security issues, to some economic issues, cyber security being example, trade and investment being example, to some of the tougher issues like human rights issues and so on. So it's really, if us, the working level is to do our work properly, then we must have proper guidance from our leaders. So at once it's for each president to give guidance. And but more than that, to get to know each other, to get to know familiar. And so I would say this is a different setting than the usual summit. In a usual summit, you're gonna meet for one hour. And in one hour, you will go through the list and in the end come out and as you say, we had great meeting and we accomplished X, Y, and Z. But I will tell you, I've been to some summits which were not as smooth. If the camera won't here, I would tell you more. But I think this is fairly unique in that sense. Thank you. Okay, I've got four hands. I've recognized Dr. DeCastro. Without the mic. I would like to express basically my appreciation for your very candid analysis. Trying not to be candid. Frank, that there's an increase in tension. And as we're discussing the issue right now, you have a situation where you have a standoff at a Yuning Shoal. You have a Yuning Shoal? Well, you have several Chinese vessels, including a frigate, confronting a group of Philippine Marines, of course, occupying a shoal. And the Philippines had received several warnings from the Chinese embassy in Manila that we better vacate that area or else. And the concern is basically this will be a template as China would force the Philippines out of the several islands it occupied in the South China Sea. This is clearly a violation of the principles that we have laid down, unilateral action, coercive diplomacy, and of course, the possible use of force. How is this viewed in Washington? Well, I think I would reiterate the point I made, which is that no party should take unilateral action that would threaten or be coercive and certainly not use of force. And so we do understand the trouble surrounding this shoal and we are in communication with both parties. And so let's see what happens. But again, I think as long as nobody takes the first unilateral action, I think that's what we want for now. Ultimately resolution to this has to wait for negotiations and settlement. But again, it's often the case, I'm not talking about this particular case, that someone feels someone else has taken action first. So there is some element of misunderstanding if you look at examining all these particular incidents. So I think they need clarification, certainly more discussion between the two capitals. And so we are well aware and we have been in touch with both parties. Mike McDevitt. Thanks, Joe, for your clarity with regard to US policy. The question I have for you has to do with something the State Department used to do during the 80s and 90s, issued a series of legal bulletins on excessive claims and what have you with regard to violations of law of the sea. And I think I've forgotten the name of them, but I think the last of them was issued in 1999. It seems to me the South China Sea is a perfect locale for those sorts of legal interpretations of what's going on to be reissued. So are there any plans for the Department of State to start issuing US judgments on excessive claims, excessive baselines, nine dash lines, et cetera? I didn't know we did that in the 80s and 90s. Yeah, go on, yeah. Could you, in the 1980s, and there were very useful law of the sea bulletins that were put out by the office of the geographer and then unfortunately the department ran out of money, which is so often the case. So that's why that was lost. While I'm up, I might make one observation. I had the privilege of serving as the agent of the United States in the Gulf of Maine Maritime boundary delimitation case with Canada, which was the first case to draw a single maritime line for both the water column and the seabed. So in effect, it was the first exclusive economic zone case. And in the world of maritime boundaries and international law, one of the most significant problems, and I very much appreciate your comment on this, because while I understand that the United States does not want to take any position on the validity of the claims or on sovereignty, one of the biggest problems is always whether a nation will even recognize the right of another nation to assert a claim in the first place. And I would argue that in the South China Sea, the United States should be more proactive in encouraging the right of the literal states to at least assert a claim in an area which is so obviously in dispute. Yeah, thank you very much. Very much appreciate, Mike, and your comment on the usefulness of this kind of notes that our legal department used to doubt. Certainly take that back and see whether this is also appropriate for the new century. On your view on whether, especially in South China Sea, countries should have the right to assert their claims and how US will support that. That's, I mean, certainly a good point, but as far as I can tell, I think every country that has claims on South China Sea have asserted their claims. And so I'm not sure we're missing anyone, you know, in terms of claimants. But it's a fair point, thank you. Peter, you had a two finger on this. Thank you very much. Peter Dutton Naval War College, I'll just be brief. The series is called Limits in the Seas. It's still resident on the State Department website and it's extremely useful. One of the reasons that it was discontinued in addition to money is that the two principal authors, Ashley Roach and Robert Smith both retired, actually. They are however both active in writing and retirement and have continued, I urge you to look in, I urge anyone interested to reach out to them because they're doing a wonderful job in continuing the research. This seems to be a fertile ground for recruiting the recruitment for those two, you know? Yeah. Okay, I had Bonnie Glazier next. Thanks so much Joe for your thoughtful remarks. I'd like to ask a question about the issue of using international law and arbitration. I very much support the effort of the Philippines and I'm very pleased that the US government has spoken out in support of this case that's being taken to unclose. Recently Japan has also come out and endorsed this effort and Vietnam has also supported it but no other states have. And I wonder if the United States is encouraging other countries, whether they be claimants or non-claimants to back this process. Because I think that if there are a lot of countries that are endorsing this particular case, maybe we could get China to rethink its approach, which I mean there's an ongoing debate in China about how the nine dashed line should be defined. And if we could tip the balance in favor of a decision to clarify their position, that would be really helpful. And the fact that so few countries have really come out in support of it to me is worrisome and makes it less likely that China is going to feel pressured to do so. Once the decision is handed down by the court, if China doesn't recognize it, then to me that has negative implications for how the dispute is being handled. So I'm curious as to what the US position is on that and what we're doing, thanks. Bonnie, that's a great point. And I think besides Vietnam, there may be a couple of other countries who have come out and supported Philippines arbitration. I think the issue of ASEAN unity on this particular issue is a key one, you know? And as is in many ASEAN things. And I think this gets us back to the kind of consensus that ASEAN is seeking. And I mean, to be frank with you, I'm not sure there is all that much wrong for outside parties to urge ASEAN unity in this. I think they'll take their time on this issue as in other issues. And I mean, certainly it will be interesting to see in the upcoming ministerial meetings what the ASEAN views are. I mean, as you know, this is an issue that I think ASEAN is having a lot of difficulty coming to consensus on, because there are claimants, there are non-claimants, and even within claimants, there is very differing view for the simple reason that for example, you know, Spratlys is disputed among many ASEAN countries.  So to me, the process matters and keeping the process alive, keeping the talks alive.  And keeping dialogue going and meanwhile making sure that most egregious coercion, threats, and certainly use of force is very much avoided. Dr. Thank you. You just made a sixth very important point on US South China's policy. I would like to introduce myself, my position from China. My question is related to your fifth point. In this point, you mentioned that the South China Sea should be resolved by peaceful means out of the state's right to both from China and other claimant states' perspectives. And also US supports to solve the South China Sea through the third party approach, for instance, it lost. So my question is that, what's your opinion? If I say that the Philippine arbitration initiative was encouraged or instructed by the United States, if so, is it still consistent with the US policy of taking North side? Thank you. I think, number one, I would fundamentally disagree that we had any role in any party going to it lost arbitration. I think that is not the case. And so I would say that is absolutely not the case. Okay, Christian? Thank you. You mentioned the Code of Conduct several times and its importance. How confident are you that the COC will be a robust and substantive document that will actually restrain the actors from coercive or assertive actions in the South China Sea? And specifically, what would you like to see in there to make sure that actually happens? I think suddenly there have been several drafts and I think there is a strong feeling among ASEAN that for Code of Conduct to be meaningful, it has to have some teeth. It cannot be just DLC version two, you know? And so, number one, that it has to be somehow legally binding, I think that's a key point. And second point is, because this is about what to do when there are disputes, there has to be some kind of dispute resolution mechanism. And certainly, I know some ASEANs are thinking that way and as I mentioned, this is also about global commons. It's not just between the parties. And so, I would hope at some point, they would reopen to outside views that's beyond China and ASEAN to make it effective so that as we say, everyone's goal is to have peaceful resolution of this issue. So it affords everyone something to really use as they become engaged in economic activity, trade activity, fishing activity and so on. The gentleman at the far right table, I can't see you because of the podium, I'm sorry. Could you please identify yourself? Yes, my name is Lam, I'm a lawyer from Canada and it's for my personal interest. In the same family of a question with the lady in front of me, she suggests that the, on the country in the Southeast Asia, use it loss to solve the problem. But actually, China have a tool because China have used provision 298 of Anglo and the provision 298 of Anglo allow China before the ratification to declare that China doesn't want to be submit to any arbitration. Therefore, we have a problem. I humbly suggest another way to solve the problem. You remember in 1973, there is nine country who signed a final act of international conference on Vietnam in Paris. And on this country, guarantee the integrity of Vietnam. And China is one of the signatory. Therefore, when China invite Paracel in 1974 and spread late in 1988, China in French violate this international treaty that they have signed. Therefore, using the provision seven of these final act, you can reconvoke the conference and try to solve the problem and invite all the other country to join. Thank you. That's a good point. Yeah. We'll certainly, good advice. Thank you very much, Mr. Lam. I'm Tui from Diplomatic Academy of Vietnam. Thank you very much for a very clear position about US interest and position in the South China Sea. But you know from my observation about situation in the South China Sea, we see a lot of point just to lay out disregarded by China. For example, no unilateral attempt, no changing status quo, no freedom of navigation, no about issue of lawful commercial oil and gas activity. One of these issue had been regarded, disregarded by China. You know a lot of issue, right? And my question is, my observation is US strategy and policy in the South China Sea, maybe it's not working well in this aspect. And the South China Sea is not only relating to US interest as you mentioned, but also on US credibility because you lay out the position and other party disregarded. And my question is, whether US should think to add more elements in the current strategy and policy towards the South China Sea. Thank you. I think whether US policies are working or not, I mean that's an interesting question. I mean certainly we've had number of incidents there. And but let's not make it so black and white as any policy issues are. You know, whether it's to do with Middle East, whether it's to do development goals, global health and so on. Our policy is commiserate with the situation. And so I would say that certainly awareness of South China Sea issues and participation of ASEAN in this important issue have greatly increased. And this also counts to success of South China Sea conference Ernie's having. And so I would say there is much more awareness. And I would also go one step further and saying this is not just the US thing, it's an international community thing. And I, you know, as I go to big international meetings and so on, there is tremendous support on the concept that we have laid out which is rule of law, observance of rule of law support for COC. So these incidents as you know will happen, they have happened and so we need a way to deal with it. So I'm not quite sure what you're suggesting, but at the moment also to go to draconian end, I don't think that's helpful either. Yeah, I just wanted to add to that. I have to say, speaking with the ASEAN countries, I'm not sure that if the US implemented its strategy, quote, that you mentioned there fully, that the, I'm not sure all of ASEAN would support that. You know, it's, again, it's this Goldilocks, we're trying to, I think, I see Joe and his team trying to thread the needle a bit here. And it does take some compromise and careful steps. The gentleman from Taiwan. Thank you, Mr. Yuan, for your speech. I'm Yeng Hui Song from Academia Seneca. My question is about related to code of conduct. From Taiwan's perspective, in my view, President Ma would like to see an early conclusion of the COC in the South China Sea with the invitation to Taiwan to participate. But now if the negotiation process for adoption of the COC takes too long, do you think it is consistent with US national interests in the South China Sea to have any parties to the dispute to propose peace initiative in the South China Sea? Certainly including an outsider to the dispute that United States to propose a peace initiative in the South China Sea. Thank you. Personally, I don't see anything wrong with any proposal for peace initiative.  Yeah. And so I think everyone ought to be free to pursue and propose peace initiative. This one doesn't, yeah. That could be the house of representatives calling him. He's got to testify in an hour or two. Dr. Emerson. Don Emerson, Don Emerson, Stanford. You know, the question that I think is lurking between the lines of this conversation, to use Ernie's phrase. Please don't call me Dr. Emerson. Thank you. Is this, is ASEAN the Goldilocks bed? The bed that is neither too long nor too short, okay? Now there are several comments that suggest that although we can regret the impatience of outsiders and we can celebrate the ASEAN way as many of us in the room have done, we can also ask whether the inclusion of outsiders that are marginally less patient and less committed to the ASEAN way. And remember that that is one of the main issues at stake in the effort of the Philippines to move to a codified way that is un-close, right? Then, you know, what comment would you make as to the threshold of impatience beyond which one might really begin to think more creatively with all due respect to ASEAN and its achievements to date as to how we could speed the process and how also the points that you mentioned in your remarks could be included in a COC because some of them, I mean, what has happened to the zero draft? What has happened to the non-paper, right? There is a kind of stunning deafening silence with regard to this and all we are told is that at some future point, perhaps before the end of this year, negotiations on a COC would begin whereas we know that in fact, informally those conversations go back to a time preceding 2002 when the DOC was born. So if you measure it by that status, this is really slow progress. And finally, when Marty Nathalagawa was in town and most recently today at the Asia Pacific Ground Table in Kuala Lumpur, he reiterated his proposal for an Indo-Pacific frame of cooperation based on the TAC, the Treaty of Amity in Cooperation. Now, when we think of expanding beyond ASEAN, you know, two possibilities arise. One is we improve progress by including folks that are a little bit impatient, including perhaps some in the Indian Ocean, I don't know, including conceivably the United States or Taiwan, I don't know, right? The other possibility is that the more cooks are in the kitchen, the worse the broth is going to taste. Could you comment? Thank you very much, Don. As always, very sharp. You know, what Philippines has done, I believe, going to it loss is that they have chosen not to pursue the same thing through the ASEAN. So it's keenly a decision, I believe, that they made is that they are going to pursue this issue through means other than U.S. ASEAN route. And so, and they've also made it clear that pursuing through it loss should not hurt COC either and pursuing through it loss should not, you know, or so these are two independent mechanism. So Philippines is probably among the most frustrated of the parties. And so it's really, I think, a reflection of their pent-up frustration that they are going to it loss route. Now, I think their decision to have, to pursue both ways is, you know, we can respect that. But your question gets to, if they have done it both ways, should there be a linkage or at least, shouldn't ASEAN have something to say about the other paths they have chosen? And again, I mean, I think it is entirely independent. We certainly have supported or have made a case that pursuing it loss is everyone's right. And you certainly would count as part of peaceful resolution or peaceful manner in which that is pursued. And so I think as far as I know, again, ASEANs have not come to a consensus decision. Whether they will or not, I don't know because they also see it as not, you know, it is not part of the ASEAN process. Gregory Ho from Radio Free Asia. Since the China side is forging a little type of relationship with the U.S. in the coming summit, I'm not sure what is the State Department's talking point in response to this so-called little type of power relationship with the U.S. Will the U.S. ignore it, confund it, co-operate it? Or what kind of talking points the State Department would advise the President, Obama, in response to this so-called new theory? Thank you. Not getting into the conversation they will have later in the week. I mean, of course, this new type of relationship or new type of great power relationship is something the Chinese leadership have said they wanted for some time now. I think with probably one of the earlier mention of this phrase was when then Vice President Xi Jinping was in Washington what about 18 months ago or so and it has continued, of course. I think, you know, we are all trying to put flesh on what that might mean. You know, between China and U.S. we have tremendous array of agenda. You know, we just discussed one today, maritime agenda, we have North Korea agenda, we have economic agenda, IP agenda, cybersecurity, what we do in global, outside the region, Syria, Iran and so on. So when we talk about new type of relationship for us it means more cooperative relationship. It means there ought to be understanding and cooperation that we work together not just in the region but outside. We work towards established norms to respect international law and so that is the broadest I can give you on what this means for us and I'm sure the two leaders will have a great discussion on this. Okay, I'd like to thank you Joe for taking the time. Thank you very much for your testimony. Please join me in thanking Acting Assistant Secretary Julian. We have a 15 minute break. Stretch your legs and we're coming back with a panel on recent developments in the South China Sea.


We want that planning preparation time so that the fire for Scribburns can be done safely. We only have one burn association in South Dakota right now, but there's a need for more. And all it takes is a handful of willing people to get something started so that they can neighbor up and work together to combat this. So the Mid-Missouri River Scribburn Association, it's the first ever Scribburn Association in South Dakota. It was started in 2015, 2016 we did the first scheduled Scribburns here in the River Breaks. Our burn association, it's a landowner driven association. We have a nine member board, I'm on the board and I'm the extension liaison. I'm also a volunteer firefighter from Gregory. The people that from the association would come out have done a dozen burns, whatever the number is, many. They would give you advice on, yes this will work, if you do that, no this isn't going to work, that fire line isn't big enough, whatever. We handle a lot of the burn plans, meeting with the landowners, handling the paperwork side of it and then once it comes to do the actual burn on the day of the burn then we also help with that. And then with the association we have some equipment that could come to the fire to assist the landowner and we will volunteer to come and assist the landowner. You are the landowner, you are the boss, but we would assist you with anything that we could and give you advice of how to pull off a safe prescribed burn. Before we will do a prescribed burn on that ranchers property, as part of our burn plan we do require proof of liability insurance so we have to have a proof of their ranch liability policy and we make that very well known with them up front. But that's also the reason for the prescribed burn plan, that's kind of their insurance policy as well. If you have a plan and you follow that plan your liability is greatly reduced.


So good afternoon everyone, I'm going to get started. So my name is Adrian Hoban from Intel. I'm here with my guest speaker today, Alan Kavanaugh from Ericsson. And we're going to talk about software defined infrastructure and what it means in an open stack environment. So to do that, I think let's introduce software defined infrastructure first. Now really what this represents is the start at the low level, start at the storage network and computer sources you've got in your infrastructure. And what we need to do at the first layer of SDI is to be able to offer up a pool set of resources that we can partition. And we need the right level of granularity and abstraction in order to do that. Moving up the SDI stack, this is really where we have to get into orchestration and to look at how we use orchestration as a way to optimally provision between the application requirements and the infrastructure capabilities. Now when you need to do this, you have to look at provisioning based on a whole set of infrastructure attributes, so be it power, performance, where your workload is located, utilization on the server. You have to take all of this into account when you're looking at providing an SDI environment. But what really helps to make this SDI is the application view of the environment. So in this case, we're moving into very much an API defined infrastructure. It's policy provisioned, dynamically automated. And the big picture key here is all of this working successfully is that the application through SLA-related provisioning can be deployed effectively on your infrastructure. So that's quite a move forward from where we're at today with traditional environments. What the result of all of this, of course, is it drives faster innovation. It helps to lower cost as a result of that. So if you can suffer to find your infrastructure, then you have much more flexibility. I'd like to talk about where we're at right now. And there's lots of discussions on this at the summit this week. So when you think about the way applications are developed right now, so they're typically monolithic, vertically integrated appliances, generally deployed with proprietary hardware and software systems. And that's moving to an environment where these can be virtualized. They can be deployed on common infrastructure, deployed across industry standards, high volume servers, and all with the management planes sitting out on the side, helping you to orchestrate and manage and provision all of this. So one of the key things or initiatives happening in the industry comes from Etsy, the European Telecommunication Standards Institute. And within Etsy, there is a specification body working on network function virtualization. So what I want to do with this slide is talk through that sort of end-to-end reference architecture. The chart that I'm showing, it's a bit of a night chart, but it has been derived from the end-to-end reference architecture. It shows the various components that are involved in the telco system. So some of the acronyms might be familiar to me, guys. So let's start at the top with the OSS-BSS. This is where the operation support system and the business support systems come together to be that portal into the telco providers infrastructure. There's a service layer, which is just under that. And the service layer is where these DNS actually get loaded. That's part of how you would add one to the system. On the right-hand side of this picture is NFVO, the top right. So that's a network function virtualization orchestrator. And it forms the top part of that management and orchestration subsystem. And NFVO needs to pull from that service catalog when it wants to try and do things like onboarding and start the instantiation process. Moving down the stack, you see that NFVO talks to Vim on the left-hand side. Or sorry, excuse me, on the right-hand side. That's the virtualized infrastructure manager. I just wanted to call out where OpenStack fits in this picture. And it's mostly in this area. There are some places where you could say it moves up or down a little bit. But OpenStack, you can mostly think of it as being a Vim component. Now as such, if you look at the flow that's happening here, OpenStack is required then to take the request that have come through its API from the NFVO in order to provision the VNF. What that really means is how do you get that VNF deployed in your infrastructure? Now I want to talk through the workflow a little bit because it's important to understand what the responsibility of OpenStack in this VIM environment is and really what it's not responsible for. So if you look at, let's say, if you start with the onboarding and you load up a VNF package into this service catalog, what that really means is you typically have your virtual machine wrapped in some type of container. It could be something like OVF, the open virtualization format, the DMTF standard. With that service catalog entry, you also have a VNF descriptor that could be represented by SIM models or others. You also need to have a network service descriptor. Now the network service descriptor at the catalog level specifies how multiple VNS should come together to deliver an actual service. And they end up referencing the various VMs that you want to deploy. So the NFVO's job is to take a service entry in the catalog, decompose the network service descriptor and the virtual network function descriptor, decompose that into the request that it needs to make to the VIM, so down through an open stack in our environment. So a very first step for onboarding, that's going to be something like a glance image import. You want to get that virtual machine into your environment. Later on, when you want to do the instantiation job, you will have NFVO talking to your VIM and it's going to say, do something like some new neutron commands to create the ports for your virtual network. It's going to get to Nova and do a Nova Boot command. It's going to get, here's the port IDs. And what that delivers then is the VNF actually get landed somewhere in the infrastructure. Lots of things have to come together to make that an effective and accurate decision. But open stacks role is pretty much done at that point from a VNF provisioning perspective. These other components then start to kick in on top of that. So be it an element management system that you would use to control the VNF from the NFV manual layer on the right-hand side, you can have a VNF manager that can come in either direct to the element management systems or into the VNF themselves. And the spec is kind of somewhat open on that. It is also possible for the existing OSS-VSS methods to get into these virtual network functions to go down that traditional path as well. And that's enabled because there's feedback loops going right back through the system. So the higher layer is know where you've deployed your VNF. So all of that together is really what the NFV reference architecture is. So to put that in an SDI context, really SDI is focusing just on this layer of the overall environment. So for SDI, we're talking about a holistic view of the virtual infrastructure manager, the infrastructure itself, be it compute network storage resources and also the connectivity between them, which in this case is represented by this line, but it could also imply things like network controllers. So when we think about applying SDI, NFV and SDN related requirements to OpenStack, we're certainly not in our own in this environment. This is a quick scan of the ecosystem that's involved that shows you the number of open source software packages, standard development organizations that are all actively working on various aspects related to SDN, NFV and SDI. What I want to try and call out here though is that this is not a case that requirements get developed in all these different bodies and they somehow get submitted to OpenStack and somebody does the work and we make some progress that way. What has to happen is that all of these communities need to collaborate quite openly. There are a number of items getting set up. So in OpenStack, there's an NFV working group has been running for almost six months now and there's going to be some meetings later in the week where we're going to get to discuss how these various bodies should work together and how do we be effective in adding the additional requirements to OpenStack that are needed for SDI. Now, I want to move next into sort of given that positioning and we've got all of these requirements being developed, what are the reference solutions start to look like? So on the left-hand side of the picture here we're showing a typical deployment that you might have in maybe a cloud or an enterprise environment. So starting with the server at the bottom and building on that with your host platform be it a Linux solution with some KVA or QEMU in play. V-switch potentially accelerated with DPK which I'll talk more about in a moment. And then your traditional data center type workload apps on top of it. Now these can be managed and provisioned through things like OpenStack or OpenDalight as an open source SDN controller. Where the NFV picture comes in with the Etsy pieces. So we've just talked about a number of these boxes up here on the right-hand side. And you'll see that these guys still very much connect directly to the appliance. But from an OpenStack perspective it is a very similar intersex into this type of a teleco data center deployment. We've got OpenStack and OpenDalight coming in. They have to manage and provision where the VNFs go and how they get set up. That means that there's a lot of commonality that we have to build on. And in fact it's one of the reasons why NFV itself has picked off such momentum because it looks at trying to extract some huge value that has gone into the enterprise space through virtualization technologies and others. And when we look at OpenStack there is a lot of commonality. So really for us at this point it's about trying to figure out what the right extensions we need to make that can work with a more traditional OpenStack view of a thermonelastic cloud deployment. So as an example, the type of requirements that could come in could relate to say performance-related provisioning particularly around determinism of the workload itself. That doesn't mean the determinism of OpenStack. That means the determinism of the VNF. From the perspective of what OpenStack needs to do in order to land it effectively on a platform. There are various items like manageability, responsiveness. So things like alarm generation that may come up through this right-hand side of the picture and how they get back up through an OpenStack environment into OSSVFS. So lots of things really actually interesting challenging problems to solve in this space.  For this talk we're just gonna focus on that STI more of that through the networking layers. So with that, let's have another look at this stack. So if you think about how this is deployed today and you've got various technologies that have some really exciting developments in around OpenStack like network virtualization and overlay technology. And with some advancements happening around service-functioning chaining that really tie into some of that network service descriptor items that talked about for the VNF catalog. So they're all in progress and making some good strides. There are some new requirements that are gonna come in that I think we need to work collaboratively on. The first of those is to start thinking about if these apps become special apps, they become service applications. What will it take to give a service application the right level of, let's say, access, be it at the picture point you wanna plug it in in your network, or the right level of privileges within your environment. A service VM needs to be a different thing from a management perspective than, let's say, a regular tenant VM. A really important topic, and it probably underpins a lot of SDI, and that's unified scheduling. If you think about what we've got in Nova today, there's been some fantastic strides in relation to how the scheduler has been developed. The number of filters that you've got in there, it's been extended quite a bit over subsequent releases. But it's still very much dominated by computer-related resource considerations. From an SDI perspective, we really have to start looking at the holistic view of it.  And today, the scheduler we've got isn't gonna consider any of those things. So we have to move forward and work together with the community to look at what is the endpoint we want to get to for the scheduler and then help to pay down the technical debt that has been built up in the community around this, on a path to delivering on this, kind of, I guess, end game of having this unified scheduling of resources. We have to do some work with the applications. From the first, or sorry, with the infrastructure to enable applications to have the visibility into the capability on the platform. So if you go back to that original picture that I showed where you've got the sort of left-hand side of monolithic vertically integrated appliances, they are complete control of the platform.  In a typical cloud-type deployment, you don't, you try to hide all of that. So what we've gotta find is the right level of abstraction that allows you to get access to various features such as PCIe device capabilities if you have accelerated in there. You've got particular NICs that you've done some validation with. If you're leveraging features in the chip set or in the CPU. There are certain things that a user in application is gonna want awareness from in an NSV environment. So it's really important that we're providing the right awareness at the API level for those things to take place. Again, it's back to what's driving success in all of this and it comes down to policy. So in this context, policy in SLA, if I look at it on, let's say, the right-hand side here. We're talking here about the networking policy. So it could tie to the group-based policy work which has been making some great extensions in OpenStack. So OpenStack's role up here is to provide an API and a framework that we can properly articulate and describe what that policy and what the network-level SLA needs to be within the platform. Then the requests have to come down to other layers such as OpenDale ID, the SDN controller, where configuration and management happens. And ultimately then, the policy and SLA enforcement happens in the infrastructure and at the server. And that's the real sort of control point that tries to instantiate the application-related request that you want coming in from the top. So if you think about the implication for that, as a, let's say if you look at the networking in particular because this is the SDI discussion. So if you look very much at that networking side, the V-switch becomes one of the critical components in your network. There's an increase in east-west traffic. So folks that would kind of be paying attention to the stats that happen in data centers might say, yes, that's true, but it doesn't necessarily mean that that's within the server. East-west is within a data center. So it could be going out of, let's say, a virtual machine or some other construct in the server, out through your virtual switch and onto the fabric going somewhere else within the data center. That counts as east-west. But if you put it in the context that the core density is growing at quite an impressive rate in the platform, the opportunity for co-locating virtual machines with the right scheduling, a smartness, is actually improving. That does drive a need for that type of traffic to be managed at the V-switch. So that then becomes the policy enforcement point where we need to be able to manage items like your server-level assurance, your access control, and then the performance, of course, is really critical in all of that. So a bit of a segue into one of the capabilities that we look at that can help with performance. It's the Data Plane Developer Kit, our development kit. It's an open-source software, VSD licensed. It's on as dptk.org. And really what dptk offers you is a whole set of libraries and capabilities that you can integrate into part of your Data Plane workload. So for instance, a pole mode driver so you can extract data out of the mix really, really quickly and get it all the way up into user space. There are packet flow classification libraries in there to help you partition up your work, your flows as you see them coming into the system. There's a number of queuing functions to help you with the management of the queues that you might want to come off after you've done that classification.  The chart on the left is, it really shows the kind of performance improvements we get with a very, I guess the lightweight packet forwarding sample application built on dptk just to show you how quickly you can get packets in and out of the system. The quicker we can do this, the more time is left for the other workloads to actually do what you really want them to do. Now, if you think about what are some of the implications actually to talk about, it's not just libraries here and drivers that you need to leverage. There's also a sort of design paradigm that you typically use if you want to be a dptk enabled app. You would look to do things such as flow pinning. You might want to core CPU pin to a particular core. You have to look at your new malocation. In fact, if you want to get to super fast data rates, at least to lower the cycle count it takes to get the packets up to your workload where you actually want to do the real stuff, then you've got to optimize your platform. And by optimizing for the platform, that gets you the type of performance and determinism that we need in an SDI environment. So what does that mean then? So Numa, for instance, non-uniform memory architecture. So Numa is really all about being aware that the fact that in a multi-socket system, the memory you have can be more closely associated with one socket than the other. So in this case, socket one, this is the local memory first and other memory is the first, the remote memory. So if you've got an application that has been set up to access local memory, that's a much faster, lower latency type of memory access. The same application could, of course, be accessing memory on the remote sockets, which is still fast, but it's just not as quick or as low latency as you can get if you do this configuration properly. So if you can optimize for this kind of platform resource awareness, then driving up your sort of the efficiency by which you use your memory is really powerful and helping to make sure that that BNF application runs effectively. And what we need out of an SDI layer is the configuration, the tuning knob capability in order to be able to set this up. The SDI layer itself, and by extension, OpenStack doesn't need to know about the application or what else has been used. Another interesting point on this too is this isn't just about NFV because any cloud enterprise-style workload can take advantage of this. So if you're assuming it can be co-located on a socket, this is effective. Now, so what has happened in Juneau now is that we've actually put in some work with the community that allows you to co-locate these processes on the same server, on the same socket on the server. So a couple of benefits from it. So I mentioned the memory, but you also happen to get a lot of cash benefits out of doing this, particularly if these processes have to do a lot of inter-process communication or some kind of sharing between them. So the real message here is effectively deploying this makes a lot of sense from many, many workload considerations. And what we need at the API level is that this is sort of exposed up through the API such that we can still embrace the sort of cloud design primitives but can allow workloads to be very tightly coupled to the platform capabilities. There are two other items I'll mention very briefly, it's huge page tables. So, excuse me, with huge page tables, what it means is when you're doing a memory access, there's a part of the memory sub-system called a translation look-aside buffer. Now what a TLB does is it's effectively a cache for memory address translation. So if you're going from let's say, host physical to guest physical, that's normally stored in a page table. Literally it's an entry that you would normally have to access through a memory access. But a TLB would allow you to cache that locally by using huge pages, going from something like 4K bytes up to something like one gigabyte of page table entry size. That allows you to cache much more of memory. So it reduces your TLB miss ratio. That could be the chance of having a TLB miss, which means you don't have to have memory access every time you want to do the address translation. That's a really great performance improvement in a virtual environment. So with that said, let's have a little look at bringing it back in DPDK and how you might associate that with a v-switch and what you actually need out of your STI environment. So from an OpenStack perspective, really all it configures in this environment is this part here on the left. So to put that in more context, in OpenStack for STI, we do not need OpenStack to be a DPDK where are enabled. In fact, OpenStack has no concept of DPDK nor should it ever have it. But what it does need is the ability to connect virtual machines with items like v-switches that have an accelerated with DPDK style primitives. A traditional way of doing it, connecting a VM to your guest down to your whole stream of v-switches, something like VertIO framework, the QEMU style. Which is fine, it's effective, works pretty well, but not very high performing. There are a couple of approaches that really helped improve that. And this is really what we want to push into OpenStack. There are some patches for it now, but we want to work through the Kilo cycle to try and land this in the trunk. So there are two approaches to a thing called user space v-host. From QEMU 2.1 onwards, including 2.1, there is a capability called v-host user. And v-host user is this sort of really efficient path to get your data into the virtual machine. In the dbdk.org releases, there is the similar capability that has been developed called dbdk user space v-host. Confusing names, the same idea in terms of what we want to enable. What we want from OpenStack is to enable the configuration of these other sort of connectivity options. And what that comes down to is this binding types, the virtual interface binding types in Nova, and suitable configuration in the neutron side to help with sort of patching up what a v-switch might need. Because you may not always have, let's say, Ethernet style interfaces that you might want to patch work with. Okay, so that's a key part of what we want to enable for this. Now, if you combine this with a view on, let's say, the Numer related work I just mentioned, the CPU pinning, which would allow you to tie down, not just co-locate workflows on a single socket, but literally tie down your virtual CPU to your physical CPU. So if you will co-locate all of that together, that really helps you to get the maximum performance and efficiency out of your software defined infrastructure. Moving on from these two items, which by the way, on the second one with this v-host user style, one of the great benefits of that is that the virtual machine can go completely unmodified. So it's still accessing the v-switch through a virtual interface in the guest. If you go to the additional step of making your guest dpdk-enabled as well, that's when you can start making use of effectively memory sharing between the guest and the host, all managed in the sort of dpdk v-host style interface path. So if you're looking at the type of performance improvements you can get through v-switches with that, you're going from something in the region of, let's say, at the base point over here on the left, moving to something like 2x-h type of a number for using a standard guest with a dpdk-v-host style interface. And then mileage varies, of course, but depending on how you configure your system and the size of packets, et cetera, you can get all the way up to something close to 10x improvement if you put dpdk in the guest. So that's a variation. You really have to decide what it is that you want from your workload, what the right level of requirements there. And that has to come back again to the policy that we set up, what the service level assurance requests are that you want for that particular workload, the requirements you're going to ask for within the platform so that you can help enable it. And all of this has to get provision in a way that's very much interface-driven. With that, I'll hand over to Alan Kavana. Cool. All right, thanks, Adrian. So my name is Alan Kavana. I'm the guest speaker today from Erison. So, I mean, like Erison is pretty much banging a lot, basically, for OpenStack and NFE, right? So there's a couple of main reasons, actually, why we're actually really here, like to endorse NFE within OpenStack. And why OpenStack is one of the main, like, cloud, ISS management platforms that we've actually endorsed, as opposed to cloud stack and some other ones out there. So I think one of the main things that we really want to focus on is that, you know, when we're packaging a distro, whether it's coming from Ubuntu, Miradis, or Red Hat, we want that distro to be able to service and the application service type on workload. So today, a lot of the services and applications that are actually used in OpenStack for them, what OpenStack is really built for, is what we consider like enterprise endpoint IP applications, right? So you typically have your classic treater web service, and the endpoint delivery basically is a web server or a database, right? Now on NFE, it's a little bit different, right? So it's not to say it cannot be achieved in OpenStack, but some of the little small nuances and configurations and differences, although subtle are very important. And they're very important for a couple of different reasons, right? And the main reason it really boils down to SLA. And I'm actually gonna talk a little bit around that on my next few slides. But the main message that we are trying to do here with partners, you know, like Intel and some other people like Red Hat and Ubuntu, is basically to make sure that we have one OpenStack distribution that can actually fulfill telco and enterprise workloads, jobs, and applications, right? And then we also want to enable like an SDN solution. So we wanna have an SDN solution that's agnostic of the existing network, physical and virtual requirements that the application actually needs. And today in Neutron, we don't actually have that. So I'm gonna talk a little bit about some of the small nuances that you know Neutron doesn't actually address today that we actually really need to have supported basically on the plugin and also on the API layer. So the NFE transformation has already started, right? So I think what we kind of started to see around 2010, 2011 when NFE started to kick off was what you traditionally had, you know, from a vendor like Ericsson, Nokia, Cisco, Juniper, Alcatel, Lucifer, right? When a customer came to Wilson Day basically bought a box, they really bought an appliance. And in SLA the appliance was a piece of software based on a specific hardware build. And the reason why that was done was really for characteristics and determinism. And that's really, really important actually, you know? So what we do is when we ship an actual product and someone actually comes and orders that like from a portal and we actually ship that to them, we guarantee that the application will work exactly as I have said based on the SLA because we have cooked the application and the hardware for that specific build environment, right? So what OpenSAC and NFE have forced vendors like us and traditional Selco vendors is to actually take a couple of steps ahead. So what does the couple of steps ahead really mean? Well, what it means is we no longer basically have an application that's baked on a specific hardware build. So there's no more DSP, ASIC based chip sets. They're not cooked specifically for a given vendor. They're for any vendor out there. And what we really have to be able to do, we have to be able to take the application and make sure we get the exact same SLA, the exact same determinism of performance characteristics as if it was exactly what it was yesterday. So there's a couple of techniques that we actually use then to try and achieve some of those things, right? So what was really virtualization brought about for? Virtualization when it was really brought about by AWS was really so you could oversubscribe services on top of the cloud. So you could oversubscribe CPU, memory, disk.io allocation. In NFE, it's a little bit different. So you probably heard Adrian mention key words like CPU core pinning, new miss scheduling, and they all come back to performance characteristics and having deterministic run times. And a lot of VNF applications actually need that because they require real time characteristics. Unlike when you have your enterprise application workloads where they're stateless, small VMs, small RAM allocation, in NFE, it's the opposite. They are big VMs or big containers are required to run on bare metal. They actually require specific implementation, let's say PCI cards that we actually certify and make sure every NF actually is provisioned on the box and therefore we endorse the SLA. So what we're really doing is we're using OpenStack for two key things. We're taking the application, we're making sure that it can be provisioned and configured on a cloud infrastructure service without actually knowing the physical underlay and we're using the virtualization layer to actually say, well, I don't care if it's a Dell or if it's HP or if it's your own cook stuff or something you actually buy from Ericsson, the virtualization layer will take care of actually hiding and abstracting what the actual CPU and physical infrastructure really is. But there's a couple of little nuances as well with that and we're gonna touch on that as well. So what we really want to be able to do, there's a couple of small little things that I'm missing, right? And you heard Adrian talk about policy and Adrian talked about policy on the network layer but there's also policy on top of OpenStack. So policy really means is that when you actually provision an application that a specific job and the person actually provisioning the job, let's say from a service catalog is allowed to do specific actions or cannot do specific actions. So it could be that you make sure that when you want to provision the application and you actually utilize the SLA that you say it's been certified to run on a specific host operating system, let's say Ubuntu 14.04. And the reason for that is that we want to make sure and go back and say the VNF will actually work and endorse all the SLA characteristics that we would traditionally get when we actually provision that as if it was a dedicated cook box from a vendor but we'll make sure it works on the cloud as long as you can give us some small little guarantees that you'll make sure that it'll actually be provisioned on a specific host with this specific hypervisor with this specific V-switch for example, right? And the reason for that is that the workloads are very different. Persistent, telco, non-persistent, enterprise data workloads, right? So what does provisioning and configuration of a VNF really mean? A lot of people actually think of VNF as a single VM. It's actually not the case. So let's take an example like a BRAS. Most people here are familiar with what a BRAS is. It consists of a couple of line cards that take subscriber traffic in and out from the one basically to the edge. It consists of controlled cards which do the routing and data management. And then it consists of another card for subscriber management. So that typically could be three applications, three VMs or three containers. So what the VNF really is, it's a cluster. It's a cluster of services and applications or cluster of VMs or containers. And typically what most telco vendors actually do is they subscribe how the VNF is actually provisioned on a cloud infrastructure using something called OVF. And that's open virtualization format. And that's a file, think of it as a configuration file, kind of a little bit like Puppet Manifest, but it's standardized for that VNF and for any VNF from any vendor. And then typically what you have then inside, for example, on a service catalog on the PAS is you have another thing called a network service descriptor. So yet again, this is another etsy little terminology. And really what it is that defines how the applications like the line card, like the control card, like the service management, subscriber management cards, are all connected together on the network level. And the reason why that's important is because the catalog basically will take that inside on the PAS and the platform is a service and it will correlate all those things and translate that to API calls. So what we're really saying is that as long as the VNF is actually provisioned to a PAS, the PAS will actually work as long as OpenSec can actually support those specific attributes on the APIs. Ah, but that's where the small problem that we have today in OpenSec. There's a small number of attributes in Novarton and Neutron and Cinderanglans and then a couple of other projects as well that the attributes are not exposed. And the problem with that is then when we want to provision the VNF and deploy a VNF, we can't actually come and specify, can you please make sure that the VNF is actually allocated this specific PCI card with this specific link type. Well, that is a big problem for persistent, performant and deterministic workloads like the telco applications. So if I just take you through a couple of examples as well because security is another big one as well, you know and there has been a couple of discussions this week now that will happen around OpenSec security and the two that I'm really, I would say fond of is really got to do a host attestation. So there is a thing called TPM and it uses a small little key called TXT. And what TXT is actually typically used to do, it's used to certify and validate the firmware and drivers on a specific card. And the reason why that's important for telcos is to make sure that the workloads are run and provisioned in secure environments. Now we didn't have that problem a couple of years ago because when I shipped you a box, all the firmware was tested and certified and validated and you couldn't change it. But in the cloud, we have the opposite problem. The administrator can actually swap out the firmware. He could actually provision a bare metal blade using Ironic. You know, nice little hacker comes on board, start changing some of the firmware that he has access to. The blade basically gets put back into service. Along comes an administrator who wants to provision a telco workload. Yeah, we're gonna have some issues there, right? So the other thing we also want to be able to do is host attestation, right? So you can imagine in glance, you're gonna have like lots and lots and lots of images. And what we really want to be able to do is attest that that specific image has not actually been tampered with. That when the application is provisioned on a specific hypervisor with a specific host operating system, it has been attested and it has not been tampered with in any way. Another key one is VLAN trunking, right? So I think this is like one of the big ones that has been like ongoing. It's like a head wound in neutron for over one year, right? For two cycles, you know, a lot of people have been trying to push this through. And the reason why VLAN trunking is really needed is because in neutron today, there's typically two ways that you actually provision a VM in a network. You order specify the VLAN ID, which is not really applicable because it's really on the provider edge side. Or you let neutron decide what VLAN ID tags it randomly wants to assign from neutron DB. Yeah, that's typically not good for VNX, right? Because what the VNX actually have cooked inside the application is they have their own VLAN IDs. Some they actually use for out of band management. Some they actually use for tagging if it's control traffic. Some they actually use for tagging if it's user plan traffic. So what we really want to be able to do is you want to be able to say to neutron, hey, this is a VNF. Here's the three VMs or containers. Please make sure they're connected over a trunk network. And therefore what neutron will actually do will blindly actually say, I don't care what VLAN ID tagged comes down on the V switch. I'm not gonna swap it out. It's a trunk port. So there are another like massive missing features. Small little features that we really need to make sure that we're exposed basically on the API. So if I go a little bit forward then I talk about what's some of the main missing parts really for NFE, right? So Adrian kind of touched a little bit on scheduling, right? So the main one in scheduling that we have today if you actually look at the Nova filters like weight metric base, they're not good enough. What we really need to be able to do is we actually need to make the scheduler unified. So what that really means is that you don't have, place the VM force based on Nova, but then you figure out, oh, I'm sorry, the network attachment point doesn't actually have like a 20 gig link. Or I'm connected all on the same top of rack switch when I actually need redundant top of rack switches. So what we really want is a unified scheduler across all the common projects in OpenStack between compute, storage and network. So there is one actually up there in Stackforge. It's called the solver scheduler. It's been driven by a couple of people, actually I'm also involved in it. And I would actually encourage people to actually contribute, go and take a look at it and play around with it. And really what it is, it's a constraint based scheduler. And the most important thing with the constraint based scheduler is it's allowing us to actually expose additional attributes that we don't actually have in Nova and Neutron and Cinder today. So if I just go through some of them that's important like local storage. So you can imagine that some specific telco workloads like a transparent cache would actually benefit from actually having an onboard disk locally attached as opposed to having remote central storage, right? So small little feature sets that we'd really like to have instantiated and actually noted and have those attributes basically exposed on the API and make sure that when we actually do job placement and schedule placement for a VNF, as long as we can meet these specific constraints, I can certify my SLA on runtime in a cloud environment. So if I go through one example, so let's say for example I have a VNF and the VNF is a transparent cache. So the first thing you want to be able to do on the API call he says, I want to have local onboard storage. I don't want to take a blade that has no storage, has to have local storage. I also want to be able to have a PCI device type that has a specific capabilities. And I also want to be able to specify and say, hey, this specific transparent cache has been certified on various PCI device from various vendors with these specific drivers. So I want to be able to express all that information so I can endorse my SLA. And the next two are really, really important, right? So if you actually think today, like we have the concept of affinity and anti-affinity and nova, but we do not have that in Cinder and we don't have it in Neutron. And the reason why that's important for Telco is that most things are deployed in pairs or triples or even more. And typically that's for redundancy and high availability. So you can actually see that a lot of the VNFs are actually like they're based on actually having high availability and redundancy on the infrastructure. And we need to be able to expose some of those attributes that we can specify to open so I can say, hey, it's okay to deploy my VNF but please make sure you put me on a box that has a specific CPU type. PCI vendors, here's the ones I support. You decide which one you basically wanna install me on and I basically wanna make sure that I have a host that's connected on two or more top of rack switches as opposed to just all being connected on one top of rack switch. So, I mean, NFE really isn't hard, right? So I think like, you know, some of the things that like we have actually been struggling with when we come through opensack is probably more got to do with culture and more got to do with explaining use cases and requirements that we really have, right? So we're not trying to reinvent new technology in opensack. We're not basically trying to reinvent KVM or ESX, right? All those things are good. Really what we're really saying to people is, hey guys, it boils down to a couple of small points. The first one is API exposure. We can't just consider, you know, it's not just good enough to say, hey, I wanna be able to create a port, assign an IP address in the subnet. I wanna be able to do a little bit more than that. You know, so I wanna actually enrich all the northbound interface APIs in opensack. So the VNF can actually specify and say, hey, I want to basically sit on a blade that has DPDK-enabled V-switch. I wanna be able to sit in a blade that the V-switch will actually support VLAN trunking. I wanna be able to sit on a blade that actually has a non-board SSD drive from vendor X, Y, and Z, et cetera, et cetera. All we're talking about is exposing those attributes through opensack above. Next one is cloud abstraction of requirements, right? So I'm also not saying that the application has to know about the underlay, right? What we are trying to address is that we're allowing opensack to keep the existing cloud abstractions that they actually have, but those abstractions actually need to be exposed up. So in the scheduler, for example, I need to be able to specify some small little constraints from my VNF to actually be provisioned on in a cloud environment. Unified scheduling, right? So I wanna move away from having just a novice scheduler, a neutron scheduler, a synder scheduler. I wanna have one unified scheduler. So there is one project out there actually being proposed called Gantt. It's still a little bit immature, but it has good promise, and also I've been taking a look at the solver scheduler, and I think there's actually good promise as well with that. So the main thing is we want to be able to make sure that where the job has been placed, we don't just force pick the Nova compute host blade and not actually worry about the networking and the storage later. We actually need to make sure that the blade is picked based on compute, network, and storage characteristics and attributes. So why do we really want to do all this? It's pretty simple. We wanna do it because it's SLA-driven placement. That's really what we wanna be able to do. So when you come to a vendor like Ericsson for a VNF, we will say, here's a VNF of BRAS. It's been certified on all these specific platforms, on all these specific PCI device vendors, these specific storage blades, knock yourself out. All we ask is that when you wanna provision the VNF, if you want to get the SLA, you have to make sure that those constraints are met. Okay? So there is a program. I don't know if people are aware of this OP NFV that got kicked off last week. And the reason why I'm mentioning this here, it's really important because it's a multi-vendor industry initiative. It's not an Ericsson initiative. It's not an Intel initiative. It's not a Dell initiative, a HP initiative. It's an industry initiative. It's about taking all the network equipment vendors together and making sure that a VNF can actually be certified on many, many, many different physical and virtual on host, small little product vendors, all part of an ecosystem, on the physical and virtual layers, okay? So I talked a little bit around policy. So policy for me actually starts really on the top. So I wanna be able to have policy and governance from my application at pre and post runtime. That's really, really important, right? So think of it a bit like having business logic in the platform as a service and actually be able to specify some constraints of who gets the provision what and who gets the change what and what specific constraints that actual application gets to actually be installed on. So that's really applicable for enterprise and also for telco workloads. And then we'll have a quick summary and then we do some Q and A. So I mean, like, you know, for me, the most important thing that I really open sac actually needs to actually get behind, you know, that like Ericsson in particular, like myself and some of the guys in my team where we're still pushing is we need to enrich the APIs. I mean, that really is key for service exposure. We need to actually have a lot more attributes and metadata basically expose and endorse on open stack on the Norban interface APIs. Yeah, to add to that, I think we follow up on a lot of Alan's points. We need to make sure that we can have the right tuning knobs in open stack so that we can configure the enhanced properties and capabilities within the server and at the V switch level. Yeah. Like I said, the unified scheduler really, really is important, right? So we need to have a scheduler like on top of all the cross projects. So when we actually do job placement, it shouldn't just be based on the blade. It should be based on the compute blade, the networking requirements and also the storage requirements as well. Yeah, so ultimately to be successful here, it's all about this policy based and SLA based provisioning and placement and enforcement of the application requirements through a comprehensive API framework. Good. So let's take some questions if we have time before we get kicked out. Or we're going to get kicked out. Questions? No, no. Yep, go ahead. You mentioned this data SDK, right? So is it a user space library where pre-compiled application does it need a special compiler? No special compiler needed. It's a user space, primarily user space libraries. Yep. We can chat offline if we're getting kicked out. Okay, good. Let's go.