Hi Keith, This is a kind reminder.
Also, I stumbled upon VPP-320, and especially https://gerrit.fd.io/r/#/c/1676/ which adds a 6 Bytes of plugin_metadata in the opaque1 union, which has been reopened for nsh-proxy. I feel this might be a good way to go which would ensure no collision between the uses of the flowtable and the rest of vpp (if such was indeed your fear). What do you think ? Regards, On 11/10/16 17:42, Andrew 👽 Yourtchenko wrote: > On 11/10/16, gannega <gabriel.ga...@qosmos.com> wrote: >> Hi, >> >> One question for Keith first: >> >> The flowtable currently uses the first opaque field as a buffer to store >> the data associated to the flow, but Andrew told me today that you >> advised against this kind of behavior. > Yeah - Keith, that was my impression from our last call - i.e. that we > should use opaque just as an unique ID to index into other data > structures, rather than storing the "business logic" data. Please > correct me with a cluebat if I misunderstood and put the wrong words > in your mouth ! > > >> The idea is that the flowtable is configured to redirect packets to a >> working node (which uses the buffer and the infos provided by the >> flowtable), and then reset the opaque buffer to its original value. >> If the flow has been offloaded for some reason (meaning it does not need >> to be forwarded to the working node), the the opaque buffer is left >> untouched. >> >> I wonder if you could have a look and advise me on this. >> The code is accessible here : https://github.com/GabrielGanne/vpp-flowtable >> Do not hesitate to contact me if you need any info on this. >> >> >> I'll see how to separate ingress/outgress for acl. My first idea would >> be to use the sw_if_index_current of flow_data which contains >> vnet_buffer(b0)->sw_if_index[VLIB_RX]. >> It might be enough for your need. > The case I have in mind is "deny any" outbound on ethernet1, "permit > tcp 22 and create state" ingress on ethernet1, and "permit any any" > ingress and egress on ethernet2. > > say we perform an ssh from a host on ethernet1 to a host on ethernet2. > > The "tricky" packet is the SYNACK for the tcp connection - it will > always match an existing flow in the table (because even if the flow > did not exist, it would get created by the "permit any" ingress ACL on > ethernet2. > > The way to tackle this would be to add a breadcrumb mark "first > packet" to the packet that has just created a session - then I could > force the packet down the ACL lookup rather than forwarding it. But > then in case we drop this packet, then we would also need the > possibility to undo the session creation that it has caused. Can there > be already additional "non-first" packets that had matched the session > entry and snuck in ? I don't know but assuming extreme multicoreness, > that could be a possibility. > > That said, maybe "first packet" breadcrumb + ability to retroactively > delete the flow could be enough - though of course in this case we > can't just send the packets down the "error-drop" node, so it would > not be as plug and play... Need to think further. > >> I'll also have a look at your suggestion about splitting into two ipv4/6 >> nodes. It will generate less branches and might prove good performance >> wise. > I'd say maybe wait with that - it might be worth doing it at the very > last moment, to avoid the bigger maintenance cost of having to change > things in more than one place. Maybe better to perf-test first! > >> >> Thanks again, and tell us when you come to Paris, we'll have a beer >> together. > Indeed, very nice meeting you on the phone, will ping you when I get > the travel details final! > > --a > > >> Best regards, >> >> >> On 11/09/16 16:01, Andrew 👽 Yourtchenko wrote: >>> Ok, ack for tomorrow 4pm, will await for the webex info! >>> >>> --a >>> >>>> On 9 Nov 2016, at 15:36, Ole Troan <o...@cisco.com> wrote: >>>> >>>> [Took the list off while we were figuring out a time]. >>>> >>>>> Christophe can't make it tomorrow morning, nor on Monday. >>>>> >>>>> How about Tuesday 15 morning ? 10 am is ok for me. >>>> Please go ahead with 4pm tomorrow. >>>> I'll try to make it. >>>> >>>> Off to IETF next week. >>>> >>>> Cheers, >>>> Ole >>>> >>>>>> On 11/09/16 15:21, Ole Troan wrote: >>>>>> No chance of doing it in the European morning? >>>>>> Say 10am or 11am UTC+1? >>>>>> >>>>>> Cheers, >>>>>> Ole >>>>>> >>>>>> >>>>>>> On 9 Nov 2016, at 12:28, Andrew 👽 Yourtchenko <ayour...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Gabriel, >>>>>>> >>>>>>> Excellent! How about we meet tomorrow 4 pm then ? Or we can push the >>>>>>> meeting to Monday if that time tomorrow is inconvenient for you. >>>>>>> >>>>>>> --a >>>>>>> >>>>>>>> On 9 Nov 2016, at 11:37, gannega <gabriel.ga...@qosmos.com> wrote: >>>>>>>> >>>>>>>> Hi Andrew, >>>>>>>> >>>>>>>> I work in Paris, so we're in the same timezone, and of course i'm >>>>>>>> interested to discuss all this with you. >>>>>>>> I'll update github with the current state of my work, and look at >>>>>>>> your >>>>>>>> plugins so that I understand what you did a bit before. >>>>>>>> >>>>>>>> I'm working on this with Christophe Fontaine (added in CC). >>>>>>>> >>>>>>>> We can arrange a meeting tomorrow afternoon if it suits you. >>>>>>>> Friday's a day off. >>>>>>>> Any time after that should probably be good. >>>>>>>> >>>>>>>> BR, >>>>>>>> >>>>>>>> >>>>>>>>> On 11/09/16 10:53, Andrew 👽 Yourtchenko wrote: >>>>>>>>> Hi Gabriel, >>>>>>>>> >>>>>>>>> This looks interesting, and nice to meet you! >>>>>>>>> >>>>>>>>> I'm working on stateful ACL session tracking: >>>>>>>>> >>>>>>>>> https://github.com/vpp-dev/vpp/tree/acl/plugins/l2sess-plugin >>>>>>>>> >>>>>>>>> which plugs into the ACL plugin: >>>>>>>>> >>>>>>>>> https://github.com/vpp-dev/vpp/tree/acl/plugins/acl-plugin >>>>>>>>> >>>>>>>>> Definitely would be interesting to chat. I am using the 5-tuple mask >>>>>>>>> in >>>>>>>>> the L2 classifier table for flow entries and was thinking too about >>>>>>>>> having some application-specific data (like, for example, TCP state >>>>>>>>> for the TCP sessions, etc.) as I am getting now to work on the >>>>>>>>> actual >>>>>>>>> tracking of the state. >>>>>>>>> >>>>>>>>> My current thinking i that if upon the session creation the flow >>>>>>>>> gets >>>>>>>>> assigned a unique number, with the constraint that a lowest >>>>>>>>> available >>>>>>>>> one gets chosen, then the app-specific data storage can be simply >>>>>>>>> done >>>>>>>>> in vectors close to a particular application needing that data, >>>>>>>>> indexed by this unique number. >>>>>>>>> >>>>>>>>> Classifier conveniently gives a u32 opaque, which is moved around >>>>>>>>> with >>>>>>>>> the packet at least in the L2 case in L2 opaque - so it seems to >>>>>>>>> allow >>>>>>>>> for a nice loose coupling, and get things done with the least >>>>>>>>> amount >>>>>>>>> of new code. >>>>>>>>> >>>>>>>>> But would be interesting to chat more about this. Which timezone >>>>>>>>> are >>>>>>>>> you in ? I am in CET. >>>>>>>>> We could chat on IRC in #fdio. >>>>>>>>> >>>>>>>>> --a >>>>>>>>> >>>>>>>>>> On 11/9/16, gannega <gabriel.ga...@qosmos.com> wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'm currently working on writing a flowtable node for vpp (It can >>>>>>>>>> be >>>>>>>>>> found in vppsb or on github >>>>>>>>>> <https://github.com/GabrielGanne/vpp-flowtable>). >>>>>>>>>> >>>>>>>>>> In short, it inserts itself between given interface and >>>>>>>>>> ethernet-input, >>>>>>>>>> and basically provides a buffer associated to the flow which can >>>>>>>>>> be >>>>>>>>>> written externally. >>>>>>>>>> >>>>>>>>>> I heard that some people were working on stateful features such as >>>>>>>>>> ACL. >>>>>>>>>> Would you be interested to see if those could work together ? >>>>>>>>>> >>>>>>>>>> In any case, I'd be happy to know what you think of it and what >>>>>>>>>> might be >>>>>>>>>> missing. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Gabriel Ganne >>>>>>>> -- >>>>>>>> Gabriel Ganne >>>>>>> _______________________________________________ >>>>>>> vpp-dev mailing list >>>>>>> vpp-dev@lists.fd.io >>>>>>> https://lists.fd.io/mailman/listinfo/vpp-dev >>>>> -- >>>>> Gabriel Ganne >> -- >> Gabriel Ganne -- Gabriel Ganne This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Ce message et toutes ses pièces jointes (ci-après le "message")sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur par courrier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers. Tout message électronique est susceptible d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
