IETF 84 Technical Plenary Vancouver, BC, Canada Monday, 30 July 2012 SESSION AGENDA 1. Welcome - Bernard Aboba 2. Open Internet Endowment Status Report - Lynn St. Amour & Russ Housley 3. IRTF Chair's Report - Lars Eggert 4. IAB Chair's Report - Bernard Aboba 5. RSE Report - Heather Flanagan 6. Technical Session: "Software Defined Networking" 7. IAB Open Microphone Session MINUTES 1. Welcome - Bernard Aboba Bernard Aboba welcomed the audience to the technical plenary and presented the agenda for the session. 2. Open Internet Endowment Status Report - Lynn St. Amour & Russ Housley Slides: http://www.ietf.org/proceedings/84/slides/slides-84-iab- techplenary-5.pdf Russ Housley provided an update on the Open Internet Endowment. Building on the legacy of the Internet's original pioneers and their fundamental commitments to openness, transparency, and collaboration, the Open Internet Endowment seeks to ensure that the Internet remains an open frontier that future innovators can continue to explore, expand, define, and develop responsibly for even greater social good. The endowment was established by the Internet Society with the support and direction of the IETF leadership. The initial focus is the IETF's long-term financial health and continued independence. This "Family Launch" of the endowment begins within the IETF in keeping with culture of participation, and a public launch will come later. Russ invited each IETF attendee to be a "First Supporter" and be recognized on a Virtual Donor Wall. Russ encouraged IETFers to contribute, noting that contributions received at the IETF meeting will be recognized with: - Any gift: OIE Nametag Ribbon - USD 50: OIE Laptop Sticker - USD 100: Limited Edition OIE T-Shirt - USD 200: OIE Insulated Coffee Mug - USD 500: OIE Leather Tablet Sleeve Russ, Lynn St. Amour and Bernard then made the first contributions to the Open Internet Endowment during the Technical Plenary. For more information, see http://www.openinternetendowment.org 3. IRTF Chair's Report - Lars Eggert Slides: http://www.ietf.org/proceedings/84/slides/slides-84-iab- techplenary-2.pdf Lars Eggert reported that two IRTF Research Groups are meeting at IETF 84, as well as one proposed Research Group: - ICCRG: Internet Congestion Control - ICNRG: Information-Centric Networking - SDNRG: Software-Defined Networking (Proposed) Lars announced that the IRTF Open Meeting will be held on Tuesday afternoon, and that the Network Management Research Group (NMRG) will be reviewed with the IAB on Thursday. Lars also announced that the first Applied Networking Research Prize (ANRP) [http://irtf.org/anrp] for 2012 was awarded to Alberto Dainotti. Two additional winners will be announced at IETF 85. 4. IAB Chair's Report - Bernard Aboba Slides: http://www.ietf.org/proceedings/84/slides/slides-84-iab- techplenary-0.pdf Bernard outlined the IAB responsibilities as defined in RFC 2850, as well as the current IAB Programs: - Continuing Programs o Privacy o Internationalization o RFC Editor o IANA Evolution o Liaison Oversight o ITU-T Coordination - New Programs (established at the May IAB Retreat) o IAB Tools and Processes o IP Evolution (formerly an Initiative) o Emergency Services (formerly an Initiative) - Completed Initiatives o DNS o HTTP/Web Evolution o IPv6 for IAB Business Bernard then highlighted some recent technical activities of the IAB, including a workshop on Congestion Control for Interactive Real-Time Communication held on 28 July 2012, the recently posted IPv6 privacy survey [http://www.iab.org/2012/07/23/iab-announces-ipv6-privacy-survey/], and the recent adoption of a draft on Filtering. 5. RSE Report - Heather Flanagan Slides: http://www.ietf.org/proceedings/84/slides/slides-84-iab- techplenary-1.pdf Heather Flanagan reported on her current priorities as RFC Series Editor: 1. Quality of the documents 2. Usability of the Series today 3. Usability of the Series tomorrow 4. Flexibility to adjust to needs of today and tomorrow as they change over time Heather reported on current RSE projects, including: - RFC Format Decision - Style Manual RFC - Style Manual Web page - RFC Editor website, including new wiki at http://www.rfc-editor.org/rse/wiki Heather noted that she is chairing another BOF at IETF 84 on RFC formatting, and encouraged people to look at the summary of conversations to date at http://www.rfc-editor.org/rse/wiki/doku.php?id=rfcformat. 6. Technical Session: "Software Defined Networking" Jon Peterson moderated a panel session on Software Defined Networking with the following speakers: - David Ward, "Programmatic Internet" Slides: http://www.ietf.org/proceedings/84/slides/slides-84-iab- techplenary-3.pdf - Nick Feamster, "The Past, Present, and Future of Software Defined Networking" Slides: http://www.ietf.org/proceedings/84/slides/slides-84-iab- techplenary-6.pdf - Ted Hardie, "Units of Evolution" Slides: http://www.ietf.org/proceedings/84/slides/slides-84-iab- techplenary-4.pdf At the end of the presentations, the microphones were opened for questions from the audience. A summary of the Q-and-A session follows: JAMES KEMPF: I liked your talks, [they were] very good. I've been working in SDN for a while, so I'm pretty familiar with the basics. One thing that Dave said that I think is important is that standards are about interoperability, and the one thing we don't have in the SDN world is a way to talk about topology that is interoperable. So, I can't use various different vendors' equipment or various different pieces of software and have the same kind of topology. I think that IETF could profitably do a working group on an interoperability standard for the network interoperability base (NIB). DOUG OTIS: We fight a lot of this stuff. It's a real problem for us to deal with these software defined networks and stomp them out. The original self-replicating virus was something that got away from MIT, and I'm wondering if this is something that's going to get away from us as well? This could be a very nasty problem to solve. Quite frankly, the browsers today are getting to that point where, how do we control them? So now you're saying that this is wonderful, and there's all these things you can do. Well, you're not the only one who's thinking that. JON PETERSON: I'm not sure that the message coming out of this is unambiguously that this is wonderful. DAVID WARD: The security implications are huge, obviously. TED HARDIE: But they're also not unambiguous. You've changed the attack surface enormously if you go to a model where there's a single controller in the network, compared to having any network element in the network able to inject routes. At the same time, yes, you've concentrated the value and you've concentrated the risk, and that has advantages and disadvantages. DAVID WARD: If we're talking about an operator trying to more efficiently operate their network, the fundamental security of what they push into the devices via a standardized interface across multiple vendors and across a network has the same potential security issues we have today. It's really opening up these programmatic interfaces that allow a different way to interact with the devices and understand the cross-node path that's setting up the additional functionality that may be worth the investment. NICK FEAMSTER: It seems to me that you're definitely changing the attack surface. Not necessarily making it better or worse, but it's certainly different. I think one thing is that you're changing it in some cases into software programs, which may be good or bad depending on what you think about software security. BOB HINDEN: Three comments. I really liked Ted's talk a lot, but I think you left out some important things, like extinction, if you're going to continue the analogy. TED HARDIE: Well, we did start with dinosaurs, Bob. [Laughter] BOB HINDEN: You had the example of one animal evolving into three different things, but I think there's a reason why those are separate animals, and the giraffe doesn't swim in the oceans. The notion that you can reprogram the DNA to make something that does all those things is very optimistic. TED HARDIE: It depends on how well it needs to do it, and I think that's a really good point. I used to, in a previous life, work for Panasonic, which did mobile phones really, really well in Japan. It tailored them to specific niches perfectly. I mean, they had phones that were perfect if you were a 15-year-old girl with a commute time of more than two hours a day. They were really good at honing what they did. But their lunch got eaten by the iPhone, because although the iPhone wasn't nearly as good at that, it was programmable; a phone that also worked for the salary man for a variety of different things. If Dave is a routing guy, then I'm an applications guy, and as an applications guy, you're giving me a new platform here that's the whole network, and that's exciting. It may never be exactly the same as you would've gotten if you'd hardware-programmed something; something that was just a router or just a load balancer. But again, I don't think that's the exciting part. The Transmogrifier gun is producing an imitation of something that we've already got really done. The exciting part is creating things we wouldn't be able to build in the hardware because we'd have to do them in numbers we could never justify in a single buildout. BOB HINDEN: To Dave, the word you you were looking for when you were talking about security was not "challenging." I think "terrifying" is a better word. DAVID WARD: Remain calm at all times. BOB HINDEN: Yes, because the consequences of a world where there's a single program controlling everything and it breaks or is attacked or goes down is sort of terrifying. And, a last comment to Nick: you really need to find a better application than home networks, because I don't really want whoever writes these programs to know what's going on in my home network in order to control it. Find some other usage scenario. When you say you can solve security problems for home networks--what people want to control is who their kids can friend on Facebook, and unless you can figure out how to do the programming on that level--those are the problems we have today. NICK FEAMSTER: To clarify that from a security POV, the characterization of one software program controlling everything is not correct. The idea is that you'd have multiple applications that would run on top of that SDN OS. I think the other thing is that there's plenty of evidence to suggest that people will give up some privacy for the benefits of control. SUE HARES: Ted, in the presentation on the Google network deployment, the information which was cited that fueled the network was BGP and ISIS. You didn't free yourself from the network topologies, that was the network topologies that created the information that you then downloaded. So, how does that match with your view of the network, and how do you feel that's launching into the network? IETFer FROM GOOGLE: I worked on this. This is kind of the evolution thing that he's talking about. We started with a modified version of COAGA, and with standard distributed protocols, and we're slowly migrating away from that. And what Dave said is absolutely correct: there's not a lot of standardized ways of doing topology discovery. We're creating it as we go. SUE HARES: So Dave, if you're creating this as you go, where do you intend to do this? Will the IETF do the requirements and the ONF do the protocols? DAVID WARD: One can never guarantee what's going to be done anywhere, but the charter of the IETF is layer 3 routing protocols. If it doesn't get taken up here because of lack of interest, then it's guaranteed to be taken up somewhere. I strongly suggest it be taken up here. And if folks are interested and want to be involved, we'll be talking about it in the Routing Area meeting, and then hopefully can propose some working groups that can be chartered. ERIC BURGER: Bob addressed the creepiness of the home network thing; I'll address the creepiness of Ted's vision. A lot of people have been saying, "Ooh, one thing in the middle," and Ted made it quite clear that that's not quite the vision, although it could work for a private network. I do see this as an opportunity that would be awesome for operators, because now there would be a mechanism where you'd be able to tell what a packet is and charge for it differently. It reminds me of saying we're going to work on nuclear stuff, and saying that if someone happens to build a bomb and use it, well, it's not my problem. I think we have to think carefully about the kind of stuff we're going to do here, because there's a lot of good that can come out of this. But it could also be redirected into ending the Internet as we know it. And I don't think that would be a good task for the IETF. JON PETERSON: We do try to avoid that. [Applause] TED HARDIE: In one of the discussions of this as a platform, people joked that the earliest thing would be angry packets. [Laughter] TED HARDIE: Certainly I agree that we could do deleterious and silly things with this if we wanted to. But I think that the people who are interested in getting this done and deploying it are the guys who want to run networks. Even for enterprise networking guys like me, most of those services that are being consumed are in cloud-based platforms of some kind. I do really believe that the inter-networking part of this is important and needs to get solved, and that the people who are working on it are fundamentally the ones who want it to work well for the customers. MATT MATHIS: I am stunned at the amount of work going on in the IETF which is being characterized as SDN, and the term referring to it as an architecture hadn't occurred to me either. I am wondering if this in fact is not a new Working Group item, but a new Area entirely, which cuts across existing Areas? JON: That's a question for the IESG on Wednesday night. ANOOP GHANWANI: For Ted, what was the scale of the network? TED HARDIE: For network elements, think in terms of hundreds, not thousands. It's a worldwide network, but thinking about how many nodes probably isn't going to help you get the scale of it. ANOOP GHANWANI: And what about the challenges and problems that you had to overcome as you did this? TED HARDIE: Supposedly, it was completely trouble free. [Laughter] BOB MOSKOWITZ: My interest here is, long ago I was involved in a protocol called RSVP, and COPS, and I've been out of this area for a long time. Are we talking about next-generation in this sort of work? Can you please help me understand, were we shunned here in the past in the IETF in configuring how networks behave with protocols like RSVP, and configuring how policy is expressed, in terms of COPS? How does what you're talking about relate to past work? DAVID WARD: We have a long history of working on interfaces, whether it's generic switch management protocol or COPS; corporate interfaces; XML interfaces. We've done RADIUS work, we've done DIAMETER work: we've done a boatload of work. Each and every one of those protocols has suffered from its ability or inability given the architecture of the protocol. We're using yesterday's technology to solve tomorrow's problems, and certainly that's not ideal. The extensibility of some of the protocols is limiting, especially with the feature sets that they have. The work that's being done in SDN and some of the interfaces that I alluded to absolutely were the earlier dinosaurs that are going to evolve into others. Lessons learned from those protocols are definitely being adhered to. RADIUS being what we use for subscriber policy on BNG back in the dial-up days, it's challenging to wedge other features into that protocol today. That's not the paradigm that people want to go forward. All of those have followed an evolutionary history. I do believe that all of those protocols have taught us extremely valuable lessons and things that we want to extend past what their current architectures can do. BOB MOSKOWITZ: So this is a next-generation type effort in all those things. DAVID WARD: Yup. And I've been given grief over calling things an architecture when it's really more like a mosh pit of protocols. JON PETERSON: Internet Mosh Pit Board. [Laughter] DAVID WARD: One thing we have learned from all those protocols is that we have a natural tendency, once we've formed a TCP session between a box and an application to jam every feature we ever thought of into that one TCP session, because they're so damn hard to create. Well, that might not be the case. And one of the worst things we can do right now is come up with a framework for a generic TLV protocol that can configure all things in all directions to all animals. That would a tragic mistake. BERNARD ABOBA: You chose the home routing case, and there's of course a wireless interface there. I wanted to know how much interaction there is between SDN and say, wireless networks, and in particular SDR (software-defined radio)? NICK FEAMSTER: There's quite a bit of work going on, mostly at Stanford. CHRIS LILJENSTOLPE: Three comments. 1) The attack surface--any operator today already has centralized very juicy targets; they're called the configuration servers. A controller is another nice juicy target. Those juicy targets already exist in the network. 2) Operators already have the capability of being evil in detecting packet types and deciding what they want to do. I'm not sure this changes it other than giving them a different way of tweaking things. We're not introducing anything new that the operators don't already have if they so desire. 3) We talk about this as an application, and it's really not, unless we want to call sockets an application. This is a set of APIs or a set of calls that allows a number of applications to affect the network. This is a set of hooks to allow a multitude of applications and a multitude of controlling entities to give input into the network and take data out of the network. [End of panel session. Applause.] 7. IAB Open Microphone Session Bernard introduced the IAB: - Bernard Aboba, IAB Chair - Jari Arkko - Marc Blanchet - Mary Barnes, IAB Executive Director - Ross Callon - Alissa Cooper - Spencer Dawkins - Joel Halpern - Russ Housley, IETF Chair - David Kessens - Danny McPherson (not present) - Jon Peterson - Dave Thaler - Hannes Tschofenig Lars Eggert (as IRTF Chair) and Heather Flanagan (as RSE) joined the IAB on stage for the open microphone session. A summary of that open microphone session follows: ERIC RESCORLA: I had a trouble tracking during the RSE presentation, can you explain the process that's going to happen for this format thing? HEATHER FLANAGAN: It will be described in much more detail at the BOF tomorrow, so I encourage you attend. But to do a quick summation, we're going to look at 3 drafts tomorrow for different proposals. From there, I hope to take that information and say, "Now we know the requirements, now we know what the issues are, and now we make a recommendation going forward." I'm hoping to have a recommendation by the end of the year. ERIC RESCORLA: How does the recommendation get processed? HEATHER FLANAGAN: Ah, that kind of process question. Are you asking who has the authority to make the change? ERIC RESCORLA: Yes, I'm asking how that's going to get decided. HEATHER FLANAGAN: At the end of the day, I believe it is my decision to make. I will be graded heavily on whether I received consensus and followed the process to do that. ERIC RESCORLA: Wow, I'm really quite surprised to hear that. HEATHER FLANAGAN: Do you think that the RFC Editor is part of the IETF? A sub-set of the IETF? ERIC RESCORLA: I think that the primary purpose of the RFC Editor is to publish IETF documents. And therefore, more say [for the IETF] than, "You took our input and you made a decision" is appropriate here. HEATHER FLANAGAN: Okay. ERIC RESCORLA: My understanding is that it's the IAB who is up here, and the IAB who has ultimate authority for this. So, I guess this is really a question for the IAB: how do they intend to run this process? BERNARD ABOBA: Within the version 2 RFC Editor Model described in RFC 6635, the RSOC (appointed by the IAB) approves policy documents, with the IAB acting as the body for final conflict resolution. This would be a good discussion for the RFC Format BOF. JOEL HALPERN: I think that you're mixing a couple of ideas. The RFC Editor is responsible to a number of bodies, and is responsible for meeting the needs of a number of bodies, including the IETF. If the RFC Editor were to come to a conclusion which didn't work for the IETF, that would be a serious problem, and it would be the IAB's job (either directly or through the RSOC) to make sure that didn't happen. At the same time, in the end, somebody actually has to decide across all those streams. The RFC-interest list is the place this is being discussed, and Heather will be trying to tell what a good answer is, based on all the input. The RSOC and the IAB will be watching to make sure she comes to a good answer. Not the right answer and not the perfect answer, and not the answer the IETF specifically and only wants, because it has to be a broader answer than that. ERIC RESCORLA: I am hearing this sea of delegation, from people to people to people, and no other decision that we make in this organization is made with that kind of delegation, with community input but not community consensus. I guess I'm not really finding this a very satisfactory answer, and the notion that it's been delegated out by some chain of delegation, doesn't really work for me. JOEL HALPERN: I understand what you're saying, but the RFC Editor is responsible to more than just this community, so this community consensus can't be viewed as the only input. ERIC RESCORLA: I understand that. But there's a lot of daylight between this community's consensus and a decision made unilaterally by one person. JOE HILDEBRAND: I agree with Eric, that I'd like to know what the process is ahead of starting that process so that the finish line doesn't move. I would suggest that at least we gather up the IETF portion of the input, perhaps by doing an IETF Last Call on whatever the proposed solution is, as input into whatever that final decision- making process is, so at least we know what the IETF's thoughts about that are. ERIC RESCORLA: Are you suggesting that something that couldn't gather IETF consensus could be an appropriate answer here? JOEL HALPERN: To be really blunt, I don't think the IETF will have consensus, because we have sufficiently divisive views in this community. One of the challenges Heather faces is finding an answer that is good, that can get enough support to be useful, because even rough consensus as we usually practice it is unlikely to emerge. But we have to do the best we can. It's not about ignoring the IETF perspective. That's not what I'm trying to say. ERIC RESCORLA: It sounds like it, Joel. JOEL HALPERN: I know it sounds like that, but I'm trying to point out that if you've watched rfc-interest, you're not going to get anything that looks like rough consensus on any answer. I'd love to have IETF rough consensus. But I'm not going to say that we're not going to decide anything, because that itself would be a decision. [And I'm not going to say we're not going to make a decision] unless we get IETF rough consensus, [because] that would equally be a recipe for paralysis. Heather is trying to thread this needle, and part of the reason we don't have a clearly spelled-out process is that the only thing we know about this is that it's a mess. PHIL HALLAM-BAKER: One of the problems that keeps coming up in all these things is that it is very easy to jam a consensus process by just being the person in the room who says, "I don't agree! I don't agree! I don't agree!" Particularly when it gets into these things that are ideological more than they are technical. One of the things that worries me about this idea that this isn't just the IETF that is going to be using this decision--well, surely an argument there would be if it isn't IETF consensus, why would all these different document streams have to be in the same format anyway? If the other streams are saying, "Yes, we want to have cave man format, and we can't change because we print out all our stuff and we can't afford to buy a new line printer," you know, if they are going to come out with an argument like that, well, I'd say IETF would just go with a different document stream. If on the other hand, they're going to come and decide my way, well, then I'd agree with it, and it's fine. JOEL HALPERN: Phil, don't throw up straw men that nobody has been throwing out there. CULLEN JENNINGS: I'd like to see the IAB be clear about what the appeal process is. The last time I asked this question, what I was told was--and this seems like a surprise to people now--was that if we didn't like what the decision was, the IAB could find a new RFC Editor. And if we didn't like the decision the IAB made on that, we could find a new IAB. That was the appeal process. So if that's still the appeal process, I'm fine with that. But I'd like to know if there's a different appeal process. JOEL HALPERN: That is still *an* appeal process. [Laughter] CULLEN JENNINGS: When I made the comment last time, it was "a" not the "the." BERNARD ABOBA: The process is described in 5620bis [RFC 6635]. It is not that draconian. The RSOC approves policy documents, and the IAB is the body for final conflict resolution. So the RSOC can overrule the RFC Editor, and the IAB has the ability to overrule the RSOC. There are built-in checks and balances in RFC 5620bis. HEATHER FLANAGAN: That's RFC 6635. PETE RESNICK: I want to disagree with Joel. JOEL HALPERN: That's fine. PETE RESNICK: And probably disagree with Phil a little bit. Heather, in this role, is clearly the caller of consensus. She has to call consensus across a bunch of different streams, and yeah, that consensus is likely to be awfully rough. Awfully, awfully, awfully rough. [Laughter] PETE RESNICK: But we do give folks in consensus-calling positions the ability to say, "You know what? This particular issue has been talked to the point where either the problem was addressed, or in my judgment as consensus-caller, this problem is not one we need to consider anymore. The vast majority feel one way or the other." That's the job of the person making the consensus call, and that's how it's going to turn out. The reason I mention that I thought Phil was maybe wrong is yes, we have a nasty habit in this organization of sometimes letting people stomp their feet and yelling, "No no no!" and that seems to break up consensus, but that's because the consensus-caller hasn't put down their foot and said, "Sorry, you keep saying 'no' but we've answered your objection; that issue is closed." So, I think Heather can make than consensus call, and if it turns out that we don't think she made the right consensus call, then we can appeal. But we can't say we don't like the consensus call and therefore we will appeal, unless it's on some weird grounds where we say she made the wrong technical choice. We say she made the wrong consensus call; she didn't hear what the consensus was, and appeal it up the chain. I think this is doable. And I think it will end up with a rough consensus in the end, or at least it should. JOEL HALPERN: I hope you're right, Pete. KAREN O'DONOGHUE: This is echoing what Pete said, but since I'm standing here, I'll go ahead and say it. I think it's time for this community to take a deep breath on this issue, and take a step back. We've been talking about it for 10+ years. It's going to be hard; it's going to be difficult. But it's really time to understand that not everyone is going to get what they want. And maybe this is the time *not* to stand up and yell, "No no no!" [Applause] ERIC RESCORLA: Let me try to explain again the source of my discomfort. In this community, other decisions are made via a quasi-democratic process. There is a clear process for appointing people, and there is a clear appeals chain for objections to decisions that are made. And, the IAB is not appointed solely by the IETF, as you know, and is not responsible solely to the IETF. JOEL HALPERN: Actually, the IAB is appointed by the IETF NomCom. ERIC RESCORLA: Right, the NomCom process, which also has liaisons from a number of other organizations, including ISOC. The chair is selected by ISOC. So in times when you call consensus, first of all, the person calling consensus has the responsibility to call consensus--not simply to listen to people and make a decision. And number two, even though that person is delegated to, there's a clear appeals chain up to people who were selected by the wider community process. What I want to hear is that (A) there's a responsibility for there to be a call for consensus across some specified community, and not just simply the way the FCC does it, and (B) I want to hear there's an appeals chain appointed up to somebody who's appointed by a process that wasn't a delegation. JOEL HALPERN: What I can point out is that while I hope we end up with rough consensus, RFC 6635, which was approved by a consensus process, does not mandate that for this process. But RFC 6635, which defines Heather's job and various other aspects of the situation was specifically approved by this community, by a consensus process. It's not like the IAB just decided it should be different. We did talk to the community. ERIC RESCORLA: I'll re-read the document. BERNARD ABOBA: I think we have enough input for Heather to factor into the BOF. [End of plenary.]