17:00:46 <LouisF> #startmeeting service_chaining
17:00:47 <openstack> Meeting started Thu May 18 17:00:46 2017 UTC and is due to finish in 60 minutes.  The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:50 <openstack> The meeting name has been set to 'service_chaining'
17:00:59 <LouisF> hi all
17:01:06 <pcarver> hi
17:01:12 <LouisF> pcarver: hi
17:01:21 <vks1> hi all
17:01:34 <bcafarel> hello
17:01:48 <doonhammer> hi all
17:02:31 <LouisF> #topic agenda
17:02:35 <LouisF> https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting#Agenda_for_the_Networking-SFC_Meeting_.285.2F18.2F2017.29
17:03:13 <LouisF> i was not at the Summit
17:03:35 <LouisF> can anyone provide highlights?
17:04:11 <bcafarel> no sfc presentations then?
17:04:18 <pcarver> I didn't see a lot SFC related, but I was focussed on Contrail and ODL
17:04:44 <LouisF> bcafarel: no
17:04:45 <pcarver> Some folks from Midonet did a hands one workshop with the midonet-cli for layer 2 service insertion
17:04:59 <pcarver> but it didn't involve networking-sfc at all
17:05:36 <LouisF> ok
17:05:41 <pcarver> There was an talk on SFC as part of the ODL day
17:05:55 <pcarver> but again, not specific to networking-sfc
17:06:35 <pcarver> it did rasie some questions about the relationship between OpenStack and MANO stuff
17:06:50 <LouisF> i think we can do a talk on the sfc pike enhancements for the next summit
17:07:03 <LouisF> pcarver: such as?
17:07:55 <LouisF> is this related to tacker?
17:07:57 <pcarver> I don't know the specfics of things like TOSCA and similar, but there were questions about whether the APIs align
17:08:48 <pcarver> slightly related to tacker, but I'm not sure how well that aligns either
17:09:59 <pcarver> I think it may be a case of no clear standard that everyone agrees is the one standard
17:10:34 <LouisF> the NFV network forwarding path (NFP) aligns very well with port chain
17:11:22 <LouisF> i think the NFP is part of a vnffg tosca definition
17:11:51 <doonhammer> LouisF: do you have a link for NFP?
17:12:47 <LouisF> http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd03/tosca-nfv-v1.0-csd03.pdf
17:13:03 <LouisF> its also in the ETSI MANO spec
17:13:05 <vks1> we had shown the demo of chaining in Openstack Summit with GBP
17:13:21 <doonhammer> LouisF: Thanks
17:13:21 <vks1> not this one but earlier ones
17:14:00 <LouisF> vks1: did that use networking-sfc?
17:15:11 <vks1> no we implemented that on CISCO ACI , but was doing chaining like SFC but was bit advanced
17:15:26 <LouisF> Figure 7 of that tosca doc shows NFP  - same as port chain
17:15:58 <LouisF> vks1: do you have a link?
17:16:44 <vks1> which link do you need ? I can point you to that
17:16:50 <LouisF> i think igor's work in SF graph will align with nfv/tosca vnffg
17:17:08 <LouisF> vks1: link to the demo
17:17:16 <vks1> oh ok will send you
17:17:22 <LouisF> vks1: thks
17:17:51 <LouisF> #topic cli work
17:18:02 <LouisF> CLI in python-neutronclient https://review.openstack.org/#/c/409759/
17:18:22 <bcafarel> no recent update?
17:18:44 <LouisF> no - i will contact mohan
17:19:06 <LouisF> #topic API reference
17:19:19 <LouisF> pcarver: what is status?
17:20:12 <pcarver> not much progress, I just haven't been able to spend much time debugging the issues
17:20:22 <LouisF> pcarver: ok thanks
17:20:26 <pcarver> question though
17:20:42 <pcarver> should we move SFC specific exceptions into neutron-lib?
17:21:20 <LouisF> pcarver: how is the handled for other projects?
17:21:25 <pcarver> Are they expected to be used generally or should they remain defined in networking-sfc essentially "privately"
17:22:06 <pcarver> there are some exceptions defined in neutron-lib but I haven't looked at what's not in neutron-lib for other projects
17:22:18 <bcafarel> if the API reference needs to reference them, probably yes, else that would mean a dependency on networking-sfc?
17:22:19 <pcarver> for the BGPVPN API def I didn't encounter the issue
17:22:40 <igordcard> hi, sorry
17:22:47 <bcafarel> but yes the neutron-lib resident experts will probably know :)
17:22:49 <LouisF> igordcard: hi
17:23:06 <pcarver> It's actually the API definition. The API reference is basically complete but Armando wanted the API def as a pre-req to merging the API ref
17:23:42 <igordcard> +1 nfp aligns well with port-chain, sfp does as well
17:24:00 <LouisF> igordcard: agree
17:24:25 <igordcard> but service graphs aligning with vnffg, a bit more difficult...
17:25:07 <LouisF> igordcard: where do you see the differences?
17:25:45 <LouisF> pcarver: can you check  with  neutron-lib on yr question
17:26:02 <igordcard> LouisF: want to discuss now or after the topic?
17:26:17 <LouisF> pcarver: anything to add?
17:26:54 <pcarver> LouisF: yes, just a matter of time. Got bogged down before the summit and now just barely caught up
17:27:05 <pcarver> need to find time to focus on SFC
17:27:19 <LouisF> pcarver: ok thanks
17:27:31 <LouisF> #topic vnffg alignment
17:27:50 <LouisF> igordcard: lets talk about this now
17:28:01 <igordcard> alright so even though an NFP kinda looks like an SFP, when they're grouped together to form graphs a main difference pops out
17:30:04 <igordcard> you can theoretically insert an SFP based on any condition, and so you can depend on another SFP (well this case is even explicitly written in the sfc arch), while in NFP you have an "nfpRule" which is the condition to get into the path but, from what I understand, it's the classifier used to get into the path
17:30:25 <igordcard> so I'm not sure it was designed taking into account that you could make an NFP depend on another NFP
17:30:56 <igordcard> when you look at the VNFFG, it always starts from a single point and everything is a branch of that point
17:31:29 <igordcard> but if nfpRule can be defined as allowing dependencies, then I see no major difference...
17:31:37 <LouisF> the vnffg spc does not really describe how traffic gets into the vnffg
17:33:04 <LouisF> where do you see nfpRule?
17:33:05 <igordcard> what about multiple instances at each node of the NFP, is that possible? I don't quite remember at the moment
17:33:41 <igordcard> usually, this is my guide: http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf
17:34:03 <igordcard> LouisF: 6.4.3.2
17:34:27 <igordcard> yes, NFP supports multiple instances (connection points) at each hop
17:34:55 <LouisF> also http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf
17:36:03 <igordcard> LouisF: hmm, seems like "policy" becomes "nfpRule"
17:37:05 <LouisF> igordcard: yes
17:39:32 <LouisF> igordcard: multiple cp corresponds to ppg
17:40:01 <igordcard> LouisF: yes.. and a cp is a pp?
17:40:16 <LouisF> igordcard: yes
17:41:04 <LouisF> igordcard: although is is unclear from the vnffg spec on the intention behind multiple cps per nfp
17:42:13 <LouisF> ok moving on
17:42:22 <igordcard> LouisF: oh! yes... the cardinality isn't right
17:42:46 <igordcard> LouisF: if N is the length of the NFP, then there is only 1 instance per hop
17:43:16 <igordcard> LouisF: unless the "VNF" wraps multiple instances, which might be the case, I'll have to take a look again
17:43:46 <LouisF> igordcard: yes N = number of CPs in a NFP seems correct
17:44:25 <LouisF> ok need to investigate further, but there is pretty good alignment...
17:44:35 <LouisF> #topic SF tap
17:44:48 <LouisF> vks1: what is status?
17:45:21 <vks1> I have submitted patch fr review
17:45:53 <vks1> you are in the review list :)
17:46:00 <vks1> *reviewer
17:46:00 <igordcard> haven't had much time to focus on the bigger patches, but I'm hoping to have a look in about 2 weeks time.. is that alright?
17:46:01 <LouisF> vks1:  i see you have posted patches https://review.openstack.org/#/c/449954/ and https://review.openstack.org/#/c/465057/
17:46:25 <bcafarel> ack, I am a bit behind on big reviews too
17:46:28 <vks1> yeah correct
17:46:33 <LouisF> vks1: thanks - all please review these
17:47:06 <LouisF> #topic OVN work
17:47:19 <LouisF> doonhammer: what is status?
17:48:57 <doonhammer> LouisF: still working patch through OVN/OVS did check my old networking-ovn and networking-sfc code, the ovn code can be merged the sfc code has a few minor issues bcafarel: reached out to help so not too much work
17:49:38 <LouisF> doonhammer: thanks
17:49:53 <bcafarel> doonhammer: I played a bit to set up an OVN / SFC setup, so should be able to try your branches soon
17:50:00 <doonhammer> LouisF: Biggest issue is we have run out of table space in OVN so I need a patch submitted by mickeys_: to be approved before I can submit the patch
17:50:30 <LouisF> doonhammer: i see
17:50:32 <doonhammer> bcafarel: any issues just reach out and I can help
17:50:39 <bcafarel> doonhammer: will do:)
17:51:14 <LouisF> great - thanks
17:51:21 <bcafarel> apart from the table space extension (independant issue), everything is ok on the OVN side?
17:51:25 <doonhammer> LouisF: Hopefully blp: will review mickeys_ patch soon in the meantime I can apply his patch to my fork'
17:51:59 <LouisF> #topic Non-transparent SF
17:52:02 <LouisF> https://review.openstack.org/#/c/458303/
17:52:07 <doonhammer> LouisF: Just working through issues - I have been testing it against docker and k8s and that works
17:52:18 <LouisF> doonhammer: great
17:52:40 <LouisF> please review
17:52:51 <LouisF> #topic other items
17:53:38 <igordcard> I have to work on a patch before service graphs can be merged.. hoping to finish the first chunk of graphs by next week
17:54:07 <igordcard> the OSC patch might take a bit longer, then I'm moving to NSH
17:54:26 <LouisF> igordcard: thanks
17:54:44 <bcafarel> please check also http://lists.openstack.org/pipermail/openstack-dev/2017-May/116600.html some feedback will be nice
17:55:38 <igordcard> bcafarel: oh, my bad haven't checked the ml often enough lately
17:55:53 <LouisF> bcafarel: will comment on that
17:56:10 <bcafarel> igordcard: np I think you had the summit on your hands at that time
17:56:17 <bcafarel> LouisF: thanks
17:57:42 <LouisF> bcafarel: lets discuss more at next meeting
17:57:50 <LouisF> i have another meeting
17:57:55 <LouisF> thanks all
17:58:17 <LouisF> #endmeeting