ForCES BOF: Tuesday, 12/12/00, 2:15pm-3:15pm, Grande Ballroom C Introductions - Abel Weinrib * Welcome: Forwarding and Control Element Separation BOF. * Very tight agenda. As usual with BOFs, not a technical discussion, instead get a flavor from IETF community about interest. Be severe about agenda, save time to gauge interest at the end of the BOF. Agenda: (see slide) * Goals: Gauge IETF interest in doing work in this area. Have discussion. Identify and recruit people to work in this space. First task - finalize charter, submit in IESG. * Non-Goals: Detailed discussion - do this on the mail-list instead. In IETF fashion, do the work on the mail-list. * One picture to set the stage: we think there is interest in the community for standardized interaction between control and forwarding elements. Fast path: packet forwarding. Control Element: compute intensive - routing computations, etc. * Define a standard protocol to allow for separate innovation. * Network Elements become distributed. CE controls multiple FE's. * Mail-list: forces@peach.ease.lsoft.com Subscribe: in body, send "subscribe forces " to listserv@peach.ease.lsoft.com * Website: http://www.sstanamera.com/~forces John Dickey - How do we control the Network in the Box(es)? * Stream of consciousness on what ForCES can do in this space. * Terminology: (see slide) * Life used to be simple. Just 3-4 years ago it seems. * Problem: mom and apple pie stuff. Users, algorithmic requirements, etc. Exceeds Moore's law - can't solve with one processor. * Solution: Distribute and specialize (CS 101). Push most intensive parts of work out to the edge of the box. Migration of functions to control processors and network processors. * Spider drawing: Control processor and distributed network processors. * Make them work together - not such an easy thing to do - control the one network processor from somewhere else. * Don't want to forklift upgrade every switch/chassis. * Communication is intensive, need to have a way to do it. * Must keep per-port cost low. * Familiar solutions for these problems: standard control protocol. Define a set of services provided by the protocol. * Purpose of Foil: not to propose solutions, just identify the problem. * Question: Control between network processor is invisible to the router. Why do we have to categorize the inside protocol? Example: all of the chassis-based vendors use their internal protocols. Why standardize something inside the box. Answer: not inside the box - instead, a protocol in a distributed architecture. The reason this is coming to the IETF is that it is coming outside the box. Maybe have a cloud in between. * Question: can you have one box running BGP, and another box forwarding? Answer: yes. * Question, How much more do you need than an IP-specific version of GSMP? Answer: not much more. We don't think this is especially hard, but there is work to do here. * Question: What if the control processor is embedded with the network processor? Answer: in that case, you don't need a transport to move across the IP network. On the other hand, the abstraction to describe the elements being pushed down may be useful. Dave McDysan - MSF Input to the ForCES BOF * GSMP was mentioned earlier - one of the 2 protocols focused on in the MSF. * GSMP: was originally developed to control ATM switches. Does not do anything to populate an IP forwarding table. * Motivation: would these concepts be applicable in the IP space? * Processor complex, connected by cloud, to forwarding complex. Must manage/configure it. * Physical connotation of the model. And a very logical connotation: may want to take cards from different vendors. * May want different control plane protocols controlling common HW. * Finally, a higher level set of apps. * Walk through this model, show how routing protocols interoperate, what must you push down from the control plane to make it work. * Slide 7: Partitioning - another key tenet. Might have an on-board controller. Part of the benefit is that you could purchase off-board, best-of-breed controllers to implement these functions. * Slide 8: breaks model down, assigns protocols in these examples. * Push info down to logical ports. * MSF website for more info: http://www.msforum.org Todd Anderson - ForCES Requirements * Talk about a draft requirements document. Give a flavor of what might be in scope in this group and get some feedback. * Motivation: Standardize communication between these entities: Interoperability, rapid innovation. * Now, go to an abstract network element to discuss the requirements. * Have CE/FE separation. The way to do this: stick an IP cloud in the middle. * Static problem: membership discovery. But need to handle case where resources added later - dynamic membership discovery. * Send packet between FE's - inter-FE forwarding. Discover the topology. * For external elements, want the NE to look like a single box. * Have different FE's added. * Initial requirement: 10's of FE's - we'll try to design to that. * If these are to be communicated across the cloud, need some kind of protocol here. * Also look at a packet coming in and out on an FE. Example: firewall functionality. Push filters in. After classification, need some way to configure some attributes of ports like IP addresses. Need to be able to configure ports. * Requirement: allow the protocol to configure certain QoS parameters. * Security: dynamic membership: need integrity, authorization, authentication, privacy * Link may go down - CE needs to get notified, may need to send a routing update. Need event notification for link-down events, etc. * Question: functions of forwarding element seem like a narrow list of things a fast path may be called to do. Policing, shaping, NAT, etc. Must limit the scope to make it do-able. What is the value of the protocol if too broad? Answer: Tradeoff in IETF between breadth and getting chartered. Want to have this discussion on the IETF list. This is a starting point. * Question: Protocol proposal only. For voice app, must go through signaling first. Signaling knows origin/destination. A switch and a media gateway are parallel. Answer: part of this is capability discovery. Good to include in requirements, make sure we cover it. * Question: Even if we take simple case like IP forwarding. There are assumptions a vendor can make in a proprietary solution. Might get lower performance. Who decides the benefit here? Answer: The market decides that. May lose something in terms of performance, but you gain in terms of interoperability and flexibility. David Putzolu - ForCES Charter * Proposed charter. * Environment: rapid evolution of networks and services, outsourced components. Places like MSF, CPIX, IEEE P1520. Building blocks approach. * Is this inside a box, between a box? Between a box, like Todd talked about. * Components can evolve at different rates. * Building block approach. Always a tradeoff. I can build a proprietary network, but with interoperability, I get benefits of choice. * WG Objectives (slide 3): main objective - start with requirements, framework, and protocols for control/forwarding separation. * Focus of the charter: basic configuration and control of FE's. * Right now, focus on IP - not ATM, MPLS, etc. * Why not address less or more? Start with well-established area. * GSMP: be careful not to jump directly to solution space. Important area, start with requirements. * Selection or definition as appropriate. Be careful not to get into the kitchen sink protocol. * Dates that appear in the charter. Functional requirements doc - Todd has come up with a start. Volunteer to make it better, or come up to with another doc. * Requirements are key to making more progress. Discussion * BOF Goal: gauge consensus on whether this is an interesting work area for IETF. * Question: follow on COPS-PR protocols? Answer: COPS-PR - once we get into solution space, a potential solution. It would be on the table, as would GSMP. Would not want to work in a vacuum. * Question: Wide variety of network processors. Don't you think it is hard to come up with a CE/FE protocol that address the specific things for each processor? Answer: I tend to not look at it as "specific things for each processor". Each processor implements it in its own way. * Question: IP cloud. In my opinion, control plane must be extremely reliable. Answer: Agreed - reliability is an important requirement. * Question: Requirements I saw are similar to those of GSMP. Why reinvent the wheel? Maybe we need to define the requirements and take it into GSMP. Answer: There are many areas we can examine to re-use, adopt existing work. People have looked at it, and think it is worth considering. No interest in re-inventing the wheel. * Question: Important that we look at the optical domain. Answer: Will take that under advisement. * Question: Reliability is important. Answer: stipulate that reliability a key issue. Scott Bradner, Transport Area Director * Lets pop up a level. As AD, really need to know whether people in the room see this as important IETF work. Want to hear from people who have comments relevant to gauging interest. * Comment: I don't dispute the need to do this. Not sure of fit for org focused on the internet. Other venues, MSF perhaps - enlarge charter. CSIX? * Question: have not heard a compelling reason to put in the IETF? Answer: a variety of people in this room are working in CPIX, MSF. The BOF goal is to focus on a separated CE/FE that would be relevant to the internet. * Comment: I believe this important work and that this is a valid thing to take up here. This will allow the distribution of the control plane to be separate from the distribution of the data plane. * Brief comment: control plane, forwarding plane. Network management. Second, in general we have not been very successful in making interoperability work in the control plane. Now, introduce another dimension. Personally, I'm not optimistic. May create new value for vendors. * Officially out of time. Scott asked for a show of hands of people who think this is interesting IETF work. ~150 hands. Next asked for a show of hands on people who did not think the work is interesting. ~100 hands. * Overall vote approximately 60-40 (well attended BOF: ~300 people). Not overwhelming in favor or against. * Next step: take this back to Routing and Transport area directors, decide next steps. In the mean time, get some discussion going on the mail-list and get consensus on a crisp charter.