ForCES WOrking Group, Monday July 21, 2014 (Toronto, Canada) Time: 1520-1650 EDT Physical Coordinates: Manitoba Room, Fairmont Royal York CHAIRS: Damascene Joachimpillai (dj@verizon.com) Jamal Hadi Salim (hadi@mojatatu.com) Number of attendees: 76 Minutes taken by Lucas Bates jabber scribe was Yaakov Stein Administrivia (Chairs) WG Status drag-joachimpillai-ForCES-interfelfb Evangelos ForCES-based proof of concept virtualization in mobility arch drag-cao-dataplane-acceleration-framework wrap up and adjourn 1525: overview of Agenda 1527: administrivia/overview - behind in charter by 8 months - recover in 4 months before shutdown/recharter - aim to have Honoululu as last meeting (done all pubs by March) Adrian: Will consider good success if all drafts complete before Honolulu -Docs are moving to publication (3) -Outstanding docs (Inter-FE doc, subsidiary management) Question/Kostas: Why are we shutting down? Response/Jamal: We have five chartered items which should be done. Response/Adrian: People in room not indicative of participation in WG. Response/Kostas: Appears to be a double standard in WG participation Response/Adrian: WGs have a duty to complete charter and disband, and can always recharter 1537: Jamal presenting v4 of draft for InterFE LFB Updates from v3 * Reminder of message layout Main header description (Message layout: main header) LFB Layouts: Egress: One main table, looked up by interFE ID (shows VLAN, DMAC, SMAC) Ingress: strips metadata Dropped concept of fragmentation Prototyping Linux kernel implemention Jamal asks for WG adoption. No objections. Move passed to adopt as WG doc. 1544: Kostas asks about last tutorial Response/Jamal: Tutorial might be available at Honolulu 1545: Yaakov Stein: has some documentation that is useful (SDN NFV) 1545: Evangelos is planning a webinar within the next couple of months. Jamal: Should talk to EDU team 1547: Bhumip Khasnabish (vumip1@gmail.com) Presents ForCES LFB Subsidiary Management Jamal: Feedback is required on this document Bhumip Plans to address comments and questions posed within the last week in the next update. Questions can be posed to ML. No other drafts on this topic have been produced, so Bhumip calls on chairs for WG adoption. Jamal recurses as he is co-author DJ moves to accept this as WG adopt. No objections. 1551: Evangelos presents ForCES Packet Parallelization Overview of status: last call finished. New draft Should be published this week. Jamal has provided a large number of comments and done an in depth review. Just finished making the updates, will publish new draft within a day or two Comments: General fixes in text, explicitly define Core Parallelization LFB only appear once, others (see slides) New doc is ready for next step. 1555: Evangelos presents Bits-n-bytes demo description New Proof of Concept details: using ForCES model, can describe componnets of NFV diagram using LFBs. Can define LFBs that describe hypervisors, LFBs can request and reserve virtual resources, etc. Use ForCES model to model the components and LFBs to instantiate. 1559: Jamal asks about blue sheets 1559: Jamal describes LFBs for those not familiar with them. 1559: Yaakov thinks ForCES is stronger than OpenFlow for being able to overcome limitations of not being hard-coded to specific LFBs Kostas: it's not about being better, it is about being complete Yankov: stronger for NFV, as opposed to OpenFlow Kostas: Doesn't think OpenFlow is useless for anything Jamal: we can do more. You can model OpenFlow with ForCES Question (Parviz Yegani) Juniper Networks: Can LFB mapping equally apply? Jamal: You can map many things Parviz: Interfaces in diagram are already defined. Can you use ForCES to reference all these interfaces really? Jamal: Yes, Evangelos' presentation will describe why/how Parviz: Is this indicative of next steps or to use to recharter? Kostas: have position paper @ IECT on this paper DJ: Provided models, using ForCES to exhange info between entities on diagram, one can send info many ways Jamal: take an info model you define, use ForCES model and protocol to communicate Parviz: So: using for specific interface or for all interfaces indicated? Jamal/Evangelos: All. Where LFBs exist on diagram, ForCES is being used. Ram Dantu: Good model as descibed illustrating power of ForCES. Can we use the description from Evangelos to be something to help recharter WG? Jamal: Let's defer answer - I dont want to fight the AD. 1612: Evangelos continues Will demonstrate we can manage virtual containers and can instantiate control functions inside Motivations: be able to use LFBs as modeling language to describe operational parameters and capabilities Jamal: Asking if Parviz's quetion is answered Parviz: if you want to really take something from the meeting, should be focuses on ForCES can help take the design to next step. WG docs are already being published. Because of nature of work and interaction between LFBs, someone should say this belongs to IETF or other WG. Should think about next step. Jamal: wanted to show it's possible Mehmet Ersue: had difficulties with documentation inside ETSI and would prefer to not recommend anything. 1617: Evangelos continues Use ForCES to separate software from hardware can be implemented almost anywhere: container, vm, hardware, barebone hardware Last motivation is to separate planes (control, managemer, forwarding, operational) to foster innovation Bigger picture: to use one model to manage, control, instantiation of resources. Use common protocol to make it easier to build Use case: packet gateway & service gateway Explanation of the PGW/SGW interface diagram Can reuse GTPu LFB in multiple places in the setup. Question: can you collapse SGW? DJ: Yes, you can, but one aspect won't work easily as a result Description of logical, physical demo setup and architecture. Description of demo sequence. Wrap up and questions NameNotRecorded : Is this a demo you ran before? Evangelos: Different from a demo six months back. We did not have virtual containers and control application is different now. Did not do NFV part. No GTPc, no interaction between sgw and pgw these are now control applications using these lfbs and automatically setting up apps. Kostas: Clarification on differences? Jamal: More mature demonstration Parviz: splitting the planes, you are not really enabling NFV Jamal: Yes, NFV is about separating hw from sw Kostas: it has already happened. DJ: Must wrap up - we need to move to next presentation 1627: Sri Gundavelii (Cisco) present separation of control and data plane in mobile architectures Description of inter-access Description of mobility in wifi access domain: (I.e comcast now offers public wifi hotspots on customer routers) Move control plane to virtualized instance in data center, same for the home network. Data plane will remain the same. Can use Openflow, ForCES to communicate Q: Yaakov: Similar to work being done by BBF, should compare notes. Sri: Awesome. NameNoteRecorded: data paths can also be virtualized, i don't see difference Sri: Separation of the plane is the important part. it gives you options. you don't put data plane in cloud NameNoteRecorded: data plane *can* be virtualized 1640: Zhen Cao (China Mobile) presents Controlling Data Path acceleration behaviours using ForCES Explanation of forwarding gap cover forwarding gap by data plane accelearation, using tricks to create "fast paths" Explanation of fast path across devices Explanation of current data plane accelrtion arch Description of DPDK shortfalls Description of relationships to ForCES To virtualize or not? Next steps for the draft: submit new ForCES scenario and maybe a solution draft consider this to be a WG direcction? Jamal: can see good info RFC, but should discuss online as a direction for r echartering Parviz: before jumping to solution stage, should gather requirements, then develop solution Jamal: have some requirements to generate RFC. clustering vs. single box Parviz: already in charter? Jamal: nothing new to add so this cant be a basis for recharter Zhen: agree with Jamal: more as informational, but should do gap analysis DJ: if you start doing LFB library model, you may see more gaps than if you don't. create a library model to cover use cases and try to see if it is sufficient? Jamal: try to publish RFC Q: DPDK vs other methods? A: how to build a control plane bw fe and ce Q5: more a nice example of how to use ForCES rather than an extension? (Rick Taylor) A: Yup Kostas: should be a core of the work, and then gradually expand outwards from simple to complex? should get word out about the core. Jamal: Please post on the list for more information Kostas: should start forming a couple of small groups to look at aspects. volunteers to put in some time on this. 1658: Wrap up