17:02:02 <LouisF> #startmeeting service_chaining
17:02:03 <openstack> Meeting started Thu May 19 17:02:02 2016 UTC and is due to finish in 60 minutes.  The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:07 <openstack> The meeting name has been set to 'service_chaining'
17:02:14 <pcarver> hi
17:02:17 <LouisF> hi all
17:02:17 <doonhammer> HI
17:02:19 <yamahata> hello
17:02:20 <igordcard> hi
17:02:39 <LouisF> cathy is out today
17:02:58 <mohankumar__> hi
17:03:26 <LouisF> she posted an agenda
17:03:44 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
17:04:18 <LouisF> #topic use-case documentation
17:04:53 <LouisF> pcarver: i believe you were going to provide some input here?
17:05:10 <LouisF> doonhammer: do you have a use-case to share?
17:05:26 <pcarver> LouisF: unfortunately I haven't collected anything yet. It's on my todo list.
17:05:45 <doonhammer> <LouisF> Working on them will have something by Monday
17:06:05 <LouisF> great - can you add a page to the wiki
17:06:39 <LouisF> ok moving on
17:06:45 <igordcard> talking about use cases, I would like to inquiry about how the team is planning to support SFC encapsulation (since NSH is in the plans)
17:06:45 <doonhammer> LouisF: Sure
17:07:31 <s3wong> hello --- sorry, a bit late
17:08:00 <LouisF> igordcard: currently the ovs driver uses mpls to encapsulate the nsp, nsi
17:08:29 <LouisF> the nsp uses the mpls.label and nsi uses mpls.ttl
17:08:35 <igordcard> LouisF: yes, but doesn't actually achieve sfc-encap
17:08:36 <vishnoianil> LouisF, i am double shifting with opendaylight tsc meeting,so my response will be slow
17:08:42 <LouisF> vishnoianil: ok
17:08:52 <igordcard> LouisF: I can send an email to the ML after, or there won't be enough time at the meeting
17:09:04 <LouisF> igordcard: ok
17:09:20 <scsnow> hi
17:09:53 <igordcard> but in the context of use cases, let me share this etherpad link for further analysis and discussion: https://etherpad.openstack.org/p/networking-sfc-and-sfc-encapsulation
17:10:08 <LouisF> regarding ovs support for nsh - patches exist but it may be some time before is makes into an official ovs release
17:10:28 <LouisF> igordcard: thanks
17:10:52 <pcarver> The MPLS encap is really just a temporary thing. At least that was how I understood it.
17:11:04 <LouisF> pcarver: that is correct
17:11:21 <pcarver> It's not true MPLS, it's just using an MPLS tag to identify a chain.
17:11:31 <LouisF> pcarver: exactly
17:11:54 <pcarver> when OvS supports NSH we do expect to use it
17:12:45 <LouisF> pcarver: that is the plan
17:13:14 <igordcard> my concern here is that simply adding NSH doesn't add anything else besides metadata support, since the advantage of having multiple SFPs cannot be exploited with the current networking-sfc model
17:13:35 <LouisF> the usage of nsp, nsi is per the ietf nsh draft
17:14:30 <LouisF> igordcard: can you elaborate
17:14:57 <pcarver> igordcard: on the subject of use cases above, can you provide any use cases that can't be represented by the current networking-sfc API?
17:14:58 <LouisF> a port chain is an sfp
17:15:21 <igordcard> LouisF: essentially, how can you link port-chains together to form, essentially, a graph? (not like the ETSI's VNFFG though)
17:15:24 <pcarver> If we had a use case that we can't handle then we could figure out what changes would be needed in order to support it
17:15:40 <LouisF> pcarver: +1
17:16:07 <igordcard> pcarver: in the etherpad above I present the reasons for having sfc-encap, and the n-sfc model bottlenecks it
17:16:15 <igordcard> and how the n-sfc*
17:17:00 <LouisF> igordcard: sfc-encap is currently supported by the ovs driver
17:17:07 <igordcard> LouisF: that was my initial understanding, but after further analysis it is a mix between SFP and RSP
17:17:34 <igordcard> LouisF: it is an SFP because, indeed, you specify a path and you can have multiple possible instances for a PPG (for a single SPI/SI)
17:17:59 <igordcard> LouisF: but, it is also not fully an SFP since you can't link it to other SFPs to form an SFC
17:18:25 <igordcard> LouisF: so it falls back to an RSP (you define your chain from the beginning to the end, function by function)
17:19:47 <LouisF> igordcard: the port-chain abstraction is an SFP, that actual path taken (RSP) is detemined in the data-plane
17:20:00 <igordcard> LouisF: when I say sfc-encap, I'm talking about the concept, not the act of inserting an SFC header
17:21:01 <LouisF> igordcard: i don't follow
17:21:04 <igordcard> LouisF: correct, but if you look at it from an SFC perspective, the SFP is incomplete or there an additional resource to "glue" SFPs needs to exist
17:21:59 <igordcard> SFCs are made up of SFPs, if we can't connect SFPs to form an SFC, then there is a gap in the model
17:22:49 <LouisF> port-chains can be joined to make more complex graphs as necessary
17:23:06 <igordcard> LouisF: as in ETSI VNFFG?
17:23:12 <LouisF> igordcard: yes
17:23:21 <igordcard> LouisF: then it means networking-sfc is an RSP API
17:23:59 <LouisF> the port-chain maps directly to an ETSI MANO network forwarding path (NFP)
17:24:09 <igordcard> VNFFG is made up of RSPs, you classify once in the beginning of the RSP, and then hop function by function until the end. The graph is the list of all of these possible RSPs
17:24:55 <LouisF> the concept of rsp is not mentioned in the ETSI MANO doc
17:25:22 <LouisF> rsps are only mentioned in the ietf nsh draft
17:26:18 <igordcard> how many times can we classify after entering a VNFFG?
17:27:41 <LouisF> igordcard: the ETSI MANO spec does not mention classification
17:28:03 <LouisF> correct me if i'm wrong
17:29:05 <doonhammer> It might help if igordcard could contribute some use cases and then we can design to the use cases?
17:29:29 <LouisF> igordcard: can you add a use-case description in the wikie
17:29:35 <igordcard> LouisF: yes when I said RSP it was actually NFP, which maps nicely to IETF's RSP
17:29:49 <doonhammer> otherwise we have an infinity of possibilities - hard to design for
17:30:09 <igordcard> possible use cases are covered by RFC 7498 and 7665, but I can try to get some more besides the one at the etherpad
17:30:22 <LouisF> igordcard: ok thanks
17:30:39 <igordcard> doonhammer: yes, which is why I'm trying to keep it close to standardization efforts
17:30:49 <LouisF> #action paul, john igor to add use-cases to wiki
17:31:15 <igordcard> and since there is interest in NSH, it should be usable to its full extent (at the networking layer)
17:31:41 <doonhammer> igordcard the IETF use cases need more detail - they are fairly weak (IMHO)
17:32:12 <LouisF> lets come back to this next week after we have the use-cases documented, i'd like to move on
17:32:23 <igordcard> LouisF: sure, I'll send an email too
17:32:31 <LouisF> igordcard: thanks
17:32:52 <LouisF> #topic flow-classifier priority
17:33:19 <LouisF> mohankumar: you have a blueprint i think?
17:33:21 <mohankumar> LouisF,  Filled a bug for it
17:33:24 <mohankumar> https://bugs.launchpad.net/networking-sfc/+bug/1582238
17:33:25 <openstack> Launchpad bug 1582238 in networking-sfc "Add "priority” field in flow-classifier" [Undecided,In progress]
17:33:26 <LouisF> ok bug
17:33:51 <mohankumar> please add your comments
17:34:31 <scsnow> who will work on implementation of this spec?
17:34:38 <mohankumar> it help to prioritize fc when multiple FC are added in chain
17:34:49 <LouisF> i think we can fold this into the common classifier work
17:35:25 <s3wong> LouisF: we probably want to experiment this on the SFC classifier first, right?
17:35:43 <LouisF> s3wong: we can certainly do that
17:35:46 <s3wong> LouisF: the common classifier discussion on Tuesday was mostly on creating a new channel :-)
17:36:15 <LouisF> s3wong: has that meeting date been finalized?
17:36:31 <s3wong> LouisF: the first one was, then TBD :-)
17:36:32 <mohankumar> LouisF ,  SFC needs it . Although  can be extend to common classifier
17:37:14 <LouisF> mohankumar: ok all please review the bug
17:37:33 <s3wong> LouisF, mohankumar: the idea is SFC classifier would come in consideration alongside with QoS, FWaaS...etc; so nothing is preventing you from adding existing one first, and we can put that on the table when discussing common classifier with the wider community
17:37:47 <LouisF> who is interested on working on the implementation?
17:38:01 <LouisF> s3wong: +1
17:38:35 <mohankumar> LouisF : i  take it
17:38:58 <LouisF> mohankumar: will you also to the ovs driver work?
17:39:52 <mohankumar> LouisF , For the ovs driver i may need some help if someone help can be share and do
17:40:08 <scsnow> I think I can help with ovs driver
17:40:21 <mohankumar> scsnow , thanks !
17:40:22 <LouisF> scsnow: great thanks
17:40:30 <s3wong> LouisF, mohankumar: what is the ovs driver work? OVS driver work pertaining to adding priority to classifier?
17:40:46 <LouisF> s3wong: yes
17:41:53 <LouisF> the flow classifier priority need to be mapped to ovs flow rule priority
17:42:09 <s3wong> LouisF: sure, makes sense
17:42:41 <LouisF> mohankumar: scsnow need to add unit test cases also
17:42:49 <scsnow> sure
17:42:55 <mohankumar> Yes Louisf : sure
17:43:45 <scsnow> is that correct, that currently multiple flow classifiers can be assigned to port chain and it's handled correctly by ovs driver?
17:44:03 <LouisF> scsnow: yes
17:44:07 <mohankumar> scsnow : yes
17:44:12 <scsnow> ok, good
17:44:43 <igordcard> AND or OR logic?
17:44:54 <LouisF> #action mohan pavel to work on flow-classifier priority
17:45:03 <scsnow> igordcard, and
17:45:17 <igordcard> scsnow: thanks
17:46:18 <LouisF> ok moving on
17:47:21 <LouisF> #topic move chain id generation from ovs driver to port chain plugin
17:48:20 <LouisF> currently the chain id (nsp) is generated in  the ovs driver but it should really be in  the plugin as it is common functionality for all backend drivers
17:48:42 <s3wong> LouisF: I don't think anyone would argue against that
17:48:53 <LouisF> we are working on a patch to do this work
17:49:10 <igordcard> fully agree with it, but I have a question: besides NSH do you plan to support other encap protos?
17:49:45 <LouisF> igordcard: the focus is on nsh
17:50:01 <LouisF> expect a patch for review soon
17:50:49 <igordcard> LouisF: okay, if it wasn't then stuff like length constraints for SPIs/SIs would be something to keep in mind when generating these IDs
17:50:49 <LouisF> moving  on
17:51:07 <LouisF> igordcard: agree
17:52:11 <LouisF> #topic SF insertion type/mode
17:52:23 <s3wong> igordcard: but it still isn't driver specific, right? So what we are doing here still makes sense, correct?
17:52:53 <igordcard> s3wong: not driver specific, no, since if they claim to support NSH, they should do it in a standard way
17:53:05 <s3wong> igordcard: OK. Cool.
17:53:06 <LouisF> igordcard: +1
17:53:49 <LouisF> this next topic will take some discussion so best if we hold this for next week
17:54:05 <s3wong> LouisF: insertion type/mode?
17:54:42 <LouisF> s3wong: whether it is bump-in-wire, l2, l3
17:54:56 <mohankumar> LouisF , the topic about dynamic SF insertion to chain ?
17:55:10 <LouisF> mohankumar: no
17:55:37 <s3wong> LouisF: good topic. I am working with FWaaS folks, and am urging them to go with an insertion "plugin" with networking-sfc as default backend driver
17:56:04 <scsnow> can someone help with reviewing https://review.openstack.org/#/c/311509/ -- that's because we force openflow13 protocol for all commands when using ovs-ofctl
17:56:33 <mohankumar> LouisF , okay
17:56:41 <scsnow> we need to determine acceptable approach how to fix that correctly
17:56:48 <s3wong> scsnow: sure. Just added myself as reviewer
17:57:04 <doonhammer> s3wong coming from a ngfw vendor that seems the best approach for most use cases
17:57:04 <LouisF> scsnow: ok will review
17:57:27 <LouisF> ok lets discuss more next week
17:57:30 <igordcard> is the insertion type feature only for a "legacy mode", i.e. only when sfc encap is disabled?
17:57:59 <s3wong> doonhammer: yep... as vendor also, FWaaS insertion method is just directly writing L2agent extension themselves with iptables/Linux-bridge as backend, very inflexible
17:58:36 <doonhammer> s3wong: agreed does not solve customer problems
17:59:15 <LouisF> igordcard: for non-sfc aware SFs
17:59:38 <s3wong> LouisF: is there an insertion spec or idea/email-thread to lay groundwork for discussion?
17:59:40 <igordcard> LouisF: thanks
17:59:48 <LouisF> also new driver capability discovery spec https://review.openstack.org/#/c/317635
17:59:55 <LouisF> please review
17:59:59 <LouisF> thanks all
18:00:04 <LouisF> bye
18:00:05 <scsnow> bye
18:00:10 <LouisF> #endmeeting