17:31:57 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:31:57 <openstack> Meeting started Wed May  7 17:31:57 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:31:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:32:01 <openstack> The meeting name has been set to 'networking_advanced_services'
17:32:07 <SumitNaiksatam> Meeting agenda: #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices
17:32:10 <rkukura> hi
17:32:17 <SumitNaiksatam> #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices
17:32:20 <sballe> hi.
17:32:36 <SumitNaiksatam> sballe: hi
17:33:05 <SumitNaiksatam> #topic Neutron Advanced Services'  Common Framework
17:33:15 <SumitNaiksatam> #link https://review.openstack.org/#/c/92200
17:33:48 <SumitNaiksatam> per our discussion during the past several weeks, and direction from the PTL, the above umbrella blueprint was posted
17:34:17 <SumitNaiksatam> hope there were no surprises with regards to the content in that spec, it was based on the consensus until last week
17:34:23 <SumitNaiksatam> if you get a chance a please review
17:34:34 <banix> SumitNaiksatam: do we need to get this approved, or it simple stands to bring other pieces together?
17:34:35 <SumitNaiksatam> thoughts/questions?
17:34:43 <SumitNaiksatam> banix: ah good point
17:34:50 <sballe> SumitNaiksatam, Is this proposal a step closer towards having a clean integration between Neutron core and the Advanced Services?
17:34:52 <gduan> Hi
17:34:57 <SumitNaiksatam> my understanding is that it probably needs to get approved
17:35:21 <SumitNaiksatam> however, we need to get all the dependent blueprints in
17:35:36 <SumitNaiksatam> we will follow up on the individual components in the agenda of the meeting
17:35:39 <sballe> and interface? or is it more a workflow type of thing e.g. service lyfe cycle
17:35:59 <SumitNaiksatam> sballe: its both
17:36:06 <SumitNaiksatam> banix: does that answer
17:36:12 <sballe> SumitNaiksatam, perfect. thx
17:36:14 <banix> SumitNaiksatam: yes thanks
17:36:20 <s3wong> SumitNaiksatam: well, at the very least, service definition isn't being pointed to the reference link in the doc
17:36:27 <SumitNaiksatam> sballe: there is some amount of integration, though not perfect
17:36:40 <SumitNaiksatam> sballe: this is a step in the process of organic evolution
17:37:10 <SumitNaiksatam> s3wong: ??
17:37:40 <s3wong> SumitNaiksatam: [3] isn't properly pointing to the document with service base definition
17:37:42 <SumitNaiksatam> s3wong:  do you have a new link/
17:37:55 <s3wong> SumitNaiksatam: same service insertion document
17:38:06 <Swami> hi
17:38:14 <SumitNaiksatam> s3wong: ok, need to check
17:38:20 <SumitNaiksatam> s3wong:  will update accordingly
17:38:20 <emagana> hi there.. bit late!
17:38:40 <SumitNaiksatam> most of those references are place holders though, waiting for the gerrit blueprints to be filed
17:38:52 <SumitNaiksatam> sballe: does that answer your question?
17:38:53 <s3wong> SumitNaiksatam: good
17:39:30 <SumitNaiksatam> hi to all those who just joined
17:39:56 <SumitNaiksatam> ok moving on
17:40:23 <SumitNaiksatam> so since we have a high level plan, i propose that we henceforth start tracking in individual item
17:40:28 <sballe> SumitNaiksatam, yes. I am looking at the BP now. I would like to see somewhere that we identify the need for a clean integration with Neutron
17:41:10 <SumitNaiksatam> sballe: the whole discussion iis in the context of Neutron itself
17:41:27 <SumitNaiksatam> sballe: so there are multiple touch points with neutron
17:41:39 <SumitNaiksatam> sballe: or rather with the rest of neutron
17:41:48 <sballe> SumitNaiksatam, I understand but I am told that the LBaaS for example manipulate the Neutron tables directly. There should be an API for that
17:41:55 <SumitNaiksatam> sballe: in every component that is identified
17:42:26 <enikanorov> sballe: why? lbaas is a part of neutron, it has direct access to the DB
17:42:27 <SumitNaiksatam> sballe: sure, that might have been an implementation short cut
17:42:43 <enikanorov> the api is LbaaS DB plugin itself
17:42:49 <enikanorov> no additional layer is needed
17:42:57 <SumitNaiksatam> enikanorov: yes, i agree those are local calls
17:43:07 <SumitNaiksatam> enikanorov: not REST api calls
17:43:45 <SumitNaiksatam> enikanorov: perhaps what sballe is indicating is that services should access neutron through clean interfaces rather than manipulating the db tables
17:43:46 <sballe> SumitNaiksatam, enikanorov IMHO we want to make sure that we have a clean interface and integration between the core of Neutron and the Advanced Services.
17:43:50 <SumitNaiksatam> if indeed that is happening
17:44:01 <sballe> SumitNaiksatam, Yes that was my point. Thx
17:44:04 <SumitNaiksatam> sballe: agreed
17:44:24 <SumitNaiksatam> enikanorov: sound okay, i think we are on the same page, right?
17:44:54 <sballe> SumitNaiksatam, Can we add this item to the BP?
17:45:06 <enikanorov> SumitNaiksatam: i'm actually not sure :)
17:45:11 <SumitNaiksatam> sballe: yes sure, please also feel free to comment
17:45:15 <SumitNaiksatam> enikanorov: ok :-)
17:45:22 <enikanorov> while services are plugins which are within the same process accessing the same DB...
17:45:22 <sballe> SumitNaiksatam, Will do.
17:45:37 <enikanorov> i wonder what additional interfaces are needed to work with it?
17:46:16 <enikanorov> anyway, we can discuss it offline
17:46:39 <SumitNaiksatam> enikanorov: hypothetical example - you might not want lbaas code to maniplulate neutron “port” table directly
17:46:53 <sballe> this was mention by markmcclain1 and mestery at some point when we talked about the neutron/LBaaS connection
17:47:00 <SumitNaiksatam> sballe: is that what you had in mind?
17:47:14 <enikanorov> SumitNaiksatam: well.. we're all gentlemen, we trust other's code, right?
17:47:17 <sballe> SumitNaiksatam, yes along these lines
17:47:21 <enikanorov> or otherwise we would be writing java
17:47:28 <SumitNaiksatam> enikanorov: ha
17:47:35 <cgoncalves> enikanorov: :D
17:47:40 <SumitNaiksatam> ok we are getting philosophical, so we move on
17:47:56 <SumitNaiksatam> this discussion on the drinks table in atlanta :-)
17:48:03 <enikanorov> sure :)
17:48:12 <sballe> perfect. count me in :-)
17:48:31 <SumitNaiksatam> so my earlier question to the team, regarding tracking progress on the individual components listed in the bp (going forward in this meeting)
17:48:33 <SumitNaiksatam> sound okay?
17:48:39 <enikanorov> sure
17:48:42 <sballe> yes
17:48:43 <enikanorov> i can update on flavor fw
17:48:45 <s3wong> Yes
17:48:50 <cgoncalves> SumitNaiksatam: yes, please continue
17:48:52 <SumitNaiksatam> that way we can have some milestones and dates
17:49:03 <SumitNaiksatam> good
17:49:15 <SumitNaiksatam> so start with our favorite topic
17:49:19 <SumitNaiksatam> or rather flavor
17:49:27 <banix> yes
17:49:28 <s3wong> "flavor-ite"
17:49:39 <enikanorov> ok
17:49:46 <SumitNaiksatam> #topic Flavors framework
17:49:52 <SumitNaiksatam> enikanorov: you are the cook!
17:49:56 <SumitNaiksatam> er…chef
17:50:04 <enikanorov> so... i think https://review.openstack.org/#/c/90070/ is in good shape and pretty much everything about the framework itself is covered
17:50:07 <enikanorov> so please review
17:50:19 <SumitNaiksatam> enikanorov: ok
17:50:23 <SumitNaiksatam> questions for enikanorov?
17:50:31 <regXboi> well, I'm going to jump in and say that going up the stack - it looks fine
17:50:32 <enikanorov> however we've found an issue that we didn't though on much
17:50:35 <SumitNaiksatam> enikanorov: my apologies, i have been behind
17:50:40 <regXboi> going down the stack, I have questions
17:50:43 <enikanorov> it's not a blocker for the framework itself
17:51:02 <SumitNaiksatam> regXboi: sure, whats down the stack
17:51:03 <enikanorov> but it's something that should be solved for the integration between flavors and particular service
17:51:05 <banix> welcome regXboi
17:51:13 <s3wong> enikanorov: what is the issue?
17:51:21 <regXboi> what I don't see is a way for someone to pick between different implementations of services by the same provider
17:51:24 <enikanorov> i'm giving an example:
17:51:33 <enikanorov> user creates a service using some flavor
17:51:43 <SumitNaiksatam> enikanorov: please go ahead
17:52:01 <enikanorov> and then tries to create/update some part of it, which chosen implementation doesn't support
17:52:14 <enikanorov> so user gets an 'unsupported' error
17:52:33 <enikanorov> the issue is that user might not know from the flavor that this feature is not supported
17:52:39 <enikanorov> particular example:
17:52:51 <enikanorov> user creates haproxy loadbalancer
17:53:07 <enikanorov> then it tries to add PING health monitor that haproxy doesn't support
17:53:15 <enikanorov> ...
17:53:46 <pcm_> enikanorov: seems to tie in w/my concerns about vendor validation, and client capabilities
17:53:47 <enikanorov> right not it's not very clear to me how to indicate that to a user prior trying and failing
17:53:59 <s3wong> enikanorov: well, I don't think flavor can be this descriptive (which health check type do you support?) - so return unsupported isn't too bad, right?
17:54:04 <enikanorov> one option is to have detailed description of flavors
17:54:15 <enikanorov> s3wong: it's actually bad
17:54:25 <enikanorov> s3wong: because you don't know the provider now
17:54:46 <enikanorov> s3wong: how can you know what you should change to get this damn feature working?
17:55:18 <s3wong> enikanorov: on the flip side, if every supported features need a tag, that makes the flavor language too bloated
17:55:25 <enikanorov> so looks like flavors need to include lots of stuff, or otherwise such failures will be very confusing for a user
17:55:28 <banix> shouldnt you have specified this requirement when you asked for the service ?
17:55:37 <enikanorov> s3wong: that's true as well
17:55:57 <gduan> even a vendor driver supports PING server, the function might work a little differently from vendor to vendor
17:55:58 <enikanorov> banix: right, but should I require each and every kind of feature?
17:56:12 <enikanorov> gduan: yes.
17:56:13 <s3wong> gduan: good point
17:56:24 <enikanorov> so this might be solved by 'get_capabilities' call
17:56:39 <SumitNaiksatam> enikanorov: so we had discussed earlier about different types of attributes
17:56:42 <enikanorov> but we need such method before flavor fw choses the provider
17:56:46 <SumitNaiksatam> or capabilitites
17:56:58 <SumitNaiksatam> there are those which are common to all “types” of services
17:57:01 <pcm_> enikanorov: In my L3 vendor plugins I have a BP on that. How client knows vendor capabilities
17:57:21 <pcm_> enikanorov: Though not sure how to best handle that.
17:57:23 <SumitNaiksatam> then there are those that are common “within" a service type
17:57:40 <SumitNaiksatam> and then there are those which are more specific to drivers
17:57:42 <s3wong> very soon, for more complicated services, get_capabilities will return several pages worth of information
17:57:44 <enikanorov> so, framework itself is flexible enough to handle this problem in various ways
17:58:02 <enikanorov> but when it comes to integration - it better to be solved in some convenient way
17:58:09 <banix> s3wong: which is fine. no?
17:58:23 <gduan> I doubt there is an 'accurate' description of capability
17:58:23 <enikanorov> we don't want to bloat flavors for cloud ops, but we also don't wan't to confuse users
17:58:48 <SumitNaiksatam> enikanorov: hence the suggestion to have different categories of capabilitites
17:58:56 <s3wong> banix: user would have to sniff through the list of capabilities before a user can choose - like a product catalog
17:59:14 <enikanorov> SumitNaiksatam: yeah, the categories are just strings, and it's all about string matching
17:59:29 <SumitNaiksatam> enikanorov: i am suggesting separate API calls perhaps
17:59:32 <enikanorov> so it's more about a general way of how we handle it
18:00:11 <SumitNaiksatam> enikanorov: so you can say, get_service_capabilities(), get_servcice_type_capabilities(), get_service_driver_capabilities()
18:00:20 <enikanorov> for the particular example above i suggest it is solved by adding 'healthmonitor:PING' capability
18:00:22 <s3wong> and then at the end, tenant might say "hey, I know Netscalar can support all the stuff i want, where can I pick that?" :-)
18:00:24 <SumitNaiksatam> something like that, those api names might be off
18:00:41 <enikanorov> s3wong: 'how' can i pick that
18:01:00 <enikanorov> SumitNaiksatam: yes, that's what we will need
18:01:26 <pcm_> Should this BP address this issue? https://review.openstack.org/#/c/89366/1/specs/juno/l3-svcs-vendor-client-cap.rst
18:01:34 <enikanorov> so my concern is
18:01:36 <Kanzhe> enikanorov: then every capability should be scoped with service type.
18:01:44 <enikanorov> flavor maps to several providers
18:01:46 <gduan> enikanorov: who should be define these capability ist?
18:02:10 <gduan> sorry typos
18:02:18 <enikanorov> and then we need precise flavor to let user work with particular feature
18:02:29 <enikanorov> gduan: driver's authors
18:02:53 <SridarK> enikanorov: i think beyond the simple cases, the user could pick based on the vendor and the particular implementation for esoteric needs
18:03:06 <SumitNaiksatam> Kanzhe: there can be common capabilities (base capabilities) and then those that are specific to types
18:03:21 <enikanorov> SridarK: yes, but the main goal of Flavors to hide providers from the user
18:03:39 <s3wong> enikanorov: I think gduan 's point is, who is going to set up the set of meta-tags like healthmonitor:...
18:04:06 <banix> enikanorov: exactly; so we are getting distanced from that
18:04:06 <enikanorov> s3wong: it's done on 1) driver side 2) by cloud operator
18:04:08 <gduan> s3wong: yes, the superset of all possible capability names
18:04:10 <Kanzhe> SumitNaiksatam: sure. Scope can be used to indicate common, type specific, etc.
18:04:15 <SridarK> enikanorov: i agree but i am afraid that we will have something unwieldy on the more complex cases
18:04:36 <gduan> s3wong: then vendor drivers claim they support the subset
18:04:39 <enikanorov> SridarK: choosing provider is also supported by the flavors
18:04:39 <SumitNaiksatam> ok, we need to move on
18:04:43 <s3wong> enikanorov: I am guessing flavor framework would limit the available categories - which can be perceived as limiting vendors (disclaimer: I do NOT work for a network service vendor)
18:04:46 <enikanorov> so, so i'll finish
18:04:52 <SumitNaiksatam> enikanorov: sure
18:04:59 <enikanorov> the issue i've told about is for integration
18:05:03 <banix> SumitNaiksatam: regXboi had a question
18:05:03 <enikanorov> the framework itself is fine
18:05:08 <enikanorov> so please review and approve :)
18:05:24 <regXboi> so the framework is intended to hide provider from user - i get that
18:05:29 <s3wong> enikanorov: yes, I agreed. The framework and workflow is fine
18:05:33 <Kanzhe> enikanorov: why not just provider:model for flavor. and refer to manuals for detail capabilities. :-)
18:05:36 <SumitNaiksatam> yes, all please review, and we need make move forward on this topic
18:05:51 <regXboi> what I don't see is what about specification of a particular instance of a service from a provider
18:05:51 <pcm_> Can folks look at my BP, as it tries to address caps to client?
18:06:00 <regXboi> that may not be flavor, but I'm not seeing it anywhere
18:06:12 <SumitNaiksatam> pcm_: sure, thanks
18:06:19 <s3wong> Kanzhe: I think that's what enikanorov wants to avoid, exposing provider brand/product names
18:06:20 <enikanorov> regXboi: explain?
18:06:29 <SumitNaiksatam> pcm_’s blueprint: https://review.openstack.org/#/c/89366/1/specs/juno/l3-svcs-vendor-client-cap.rst
18:06:34 <regXboi> so flavor is intended to hide provider from user
18:06:39 <enikanorov> yep
18:06:39 <pcm_> SumitNaiksatam: thanks. If it fits, we can use it as a forum for discussion of this part of it.
18:06:43 <s3wong> pcm_: will take a look, sure
18:06:52 <regXboi> what happens in the case where a provider has multiple instances of a service available
18:06:58 <banix> pcm_: will look; thanks.
18:07:03 <regXboi> and wants to allow a user to specify the instance
18:07:13 <enikanorov> regXboi: multiple backends you mean.
18:07:27 <enikanorov> regXboi: provider doesn't allow user to specify particular backend
18:07:33 <regXboi> um
18:07:33 <enikanorov> but it could be sheduled with flavors
18:07:43 <s3wong> regXboi: the scheduling algorithm takes care of that, tenants don't get to choose a particular backend
18:07:48 <enikanorov> say, flavor has a tag: 'connetctions':'unlimited'
18:07:51 <regXboi> that's an assumption I don't quite agree with, but ok
18:08:05 <enikanorov> and that will hint sheduler to place an instance to a performance backend
18:08:31 <enikanorov> regXboi: user is not in control of backends, neither provider, nor particular appliance/device
18:08:47 <enikanorov> regXboi: that's whole point of abstraction
18:08:47 <regXboi> ok, I'll let it drop
18:09:11 <SumitNaiksatam> we can have f2f discussion in the summit as well
18:09:23 <SumitNaiksatam> enikanorov: ok to move on?
18:09:24 <enikanorov> SumitNaiksatam: sure, even more then once i guess
18:09:35 <enikanorov> SumitNaiksatam: that's it from my side if there are no more questions
18:10:09 <s3wong> enikanorov: flavor only get 1/3 of a design session :-)
18:10:16 <SumitNaiksatam> enikanorov: great thanks, that discussion was a full course meal for this meeting!
18:10:21 <SumitNaiksatam> s3wong: we can do more
18:10:40 <SumitNaiksatam> flavor will be part of the adv services common framework discussion
18:11:01 <SumitNaiksatam> so we will get 2/3rd of the time to cover the adv services topics
18:11:07 <SumitNaiksatam> enikanorov: sound okay?
18:11:10 <enikanorov> yes
18:11:19 <SumitNaiksatam> i dont know what the third topic is about
18:11:37 <SumitNaiksatam> i was hoping that proposer would have joined thid forum
18:11:51 <SumitNaiksatam> so we could have had a coherent plan/strategy
18:11:51 <SumitNaiksatam> anyway
18:11:58 <SumitNaiksatam> #topic Base service definition
18:12:07 <SumitNaiksatam> s3wong: over to you
18:12:18 <s3wong> #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit#heading=h.v0wed816g3i1
18:12:39 <SumitNaiksatam> this captures any changes we need to make to base service defintion to support insertion and chaining (and also flavors)
18:12:39 <s3wong> Kanzhe and I decided to merge the two topics into one document
18:12:45 <SumitNaiksatam> s3wong: ok
18:13:03 <SumitNaiksatam> so we are going to have one gerrit spec for this?
18:13:13 <s3wong> SumitNaiksatam: yes
18:13:20 <SumitNaiksatam> ok
18:13:38 <SumitNaiksatam> s3wong:  can you quickly highlight the changes to the base service definition?
18:13:50 <Kanzhe> s3wong: The two topics are service base class definition and service insertion.
18:14:01 <mandeep> SumitNaiksatam: My understanding was that we will have a different gerrit blueprint for chanining
18:14:13 <SumitNaiksatam> mandeep: yes thats a different spec
18:14:14 <mandeep> SumitNaiksatam: I am OK either way, just asking for clarification
18:14:19 <mandeep> SumitNaiksatam: OK
18:14:22 <regXboi> is the list of service ports in service base class ordered or not?
18:14:22 <SumitNaiksatam> mandeep: we will come to that in the agenda
18:14:25 <s3wong> The ServiceBase object is used to maintain the connection mapping of where a service is being inserted
18:14:29 <SumitNaiksatam> mandeep: sorry i think i forgot to add that
18:14:44 <SumitNaiksatam> s3wong: please proceed
18:14:48 <s3wong> regXboi: No - order will be determined by ... the service chaining framework
18:14:56 <regXboi> s3wong: thanks
18:15:10 <Kanzhe> regXboi: servicePorts are not order. This is not serviceChaining.
18:15:20 <regXboi> wasn't thinking of service chaining
18:15:27 <regXboi> was thinking of abstraction
18:15:45 <Kanzhe> regXboi: Do you see a need for ordering?
18:15:50 <SumitNaiksatam> mandeep: added
18:15:51 <regXboi> not sure - was asking
18:15:57 <regXboi> need to think about it some more
18:15:59 <mandeep> SumitNaiksatam: Thanks
18:16:10 <s3wong> I added flavor to track which user defined flavor maps to this service object, and Kanzhe and me had extended ServicePort definition to cover different types of insertion, therefore just having a list of ServicePort seems to be good enough
18:16:42 <SumitNaiksatam> s3wong: ok, does this reconcile with the flavors blueprint?
18:17:20 <s3wong> SumitNaiksatam: yes, I read through enikanorov 's bp before writing the workflow
18:17:25 <SumitNaiksatam> s3wong: nice
18:17:28 <bmelande> s3wong: The service port seems to assume that an external port cannot be another neutron port, only something on a physical device.
18:17:29 <s3wong> so it should work well with the flavor framework
18:18:01 <SumitNaiksatam> bmelande: good point, s3wong can you take note ^^^
18:18:12 <SumitNaiksatam> the next topic is related, so lets move on
18:18:21 <s3wong> bmelande: sorry, that must be due to my poor writing (and lack of detail description). ExternalPort is something that does not belong to the tenant who requests the service
18:18:22 <SumitNaiksatam> #topic Service insertion proposal update
18:18:44 <SumitNaiksatam> Kanzhe: ?
18:18:47 <SumitNaiksatam> : #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit#heading=h.v0wed816g3i1
18:18:53 <s3wong> so if you have a ServiceVM that is managed by the admin, for example, the tenant object still connects to it via the ExternalPort
18:19:10 <Kanzhe> SumitNaiksatam: yes. It is the same doc that s3wong and I put together.
18:19:14 <s3wong> so not limited by the physical / hardware device
18:19:14 <SumitNaiksatam> s3wong: thanks
18:19:32 <SumitNaiksatam> Kanzhe: ok good, any changes over the past week?
18:19:32 <Kanzhe> servicePort is the main abstraction to express service Insertion.
18:19:35 <s3wong> bmelande: will update doc to reflect that
18:19:43 <SumitNaiksatam> Kanzhe: ok good
18:19:51 <Kanzhe> SumitNaiksatam: The main changes is about workflow.
18:20:01 <SumitNaiksatam> Kanzhe: what is the ETA for submitting this to gerrit
18:20:02 <SumitNaiksatam> ?
18:20:24 <Kanzhe> s3wong and I will convert to gerrit in the next day or two.
18:20:35 <SumitNaiksatam> Kanzhe: ok nice
18:20:48 <bmelande> s3wong: Our use case is that service VM has a set of port (owned by special service tenant). Those ports are effectively trunk port. Multiple networks (in tenants owning the service instance) are trunked on the trunk port.
18:20:51 <SumitNaiksatam> Kanzhe: can you please very quicly summarize what is the change to workflow that you are indicating?
18:21:09 <s3wong> SumitNaiksatam: the major change really is about not having admin specific objects, but relying on service agents to give us interface information
18:21:20 <Kanzhe> The main change is to clarify the integration with flavor BP
18:21:35 <SumitNaiksatam> s3wong, Kanzhe: ok
18:21:45 <SumitNaiksatam> perhaps folks need to read through the doc
18:21:52 <SumitNaiksatam> bmelande: can you comment on the doc?
18:21:53 <gduan> bmelande: Erik submitted a code review for trunk port
18:21:55 <s3wong> bmelande: yes, that was the use case we talked about also at the ServiceVM meeting
18:22:39 <s3wong> bmelande: with the absence of trunk port support, one way is the driver for CRS1000v would need to return an ExternalPort per each VLAN
18:22:43 <bmelande> s3wong, SumitNaiksatam,gduan: yes will do, yes he did, yes thats the one we talked about
18:23:09 <SumitNaiksatam> bmelande: ok thanks
18:23:16 <regXboi> one thing that is not quite clear in the google doc
18:23:26 <SumitNaiksatam> regXboi: sure, go ahead
18:23:35 <regXboi> is overlay transport considered L2 or L3 for insertion mode
18:23:49 <regXboi> I can argue both
18:24:25 <s3wong> regXboi: the insertion mode (Lx) depends on whether the service is inserted into a Neutron network or connected to a router
18:24:36 <regXboi> can we add that then?
18:24:37 <SumitNaiksatam> regXboi: i would imagine that is a property of the network
18:24:42 <regXboi> that makes it much cleaner
18:24:52 <regXboi> and yes, then it becomes a property of the network
18:25:07 <s3wong> regXboi: will clarify in the document. Thanks!
18:25:16 <SumitNaiksatam> s3wong Kanzhe: thanks!
18:25:31 <SumitNaiksatam> i know we are rushing here a bit
18:25:38 <SumitNaiksatam> #topic Traffic Steering
18:25:47 <SumitNaiksatam> cgoncalves: over to you
18:25:54 <cgoncalves> #link https://review.openstack.org/#/c/92477
18:26:10 <s3wong> SumitNaiksatam: five minutes for traffic steering, service chaining, and open discussion
18:26:11 <SumitNaiksatam> cgoncalves: thanks for submitting promptly
18:26:13 <s3wong> :-)
18:26:20 <SumitNaiksatam> and also for the pretty ascii! :-)
18:26:21 <cgoncalves> as most of you know I've submitted the proposal. there's the link ^
18:26:32 <SumitNaiksatam> s3wong: sure, why not! :-P
18:26:38 <cgoncalves> SumitNaiksatam: still struggling with the use case pics though
18:26:47 <SumitNaiksatam> s3wong: after all the hours we spent before
18:26:55 <SumitNaiksatam> cgoncalves: pics?
18:27:05 <cgoncalves> SumitNaiksatam: https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit#heading=h.jpcx6ne3dl50
18:27:28 <SumitNaiksatam> oh you mean inserting the figures for the use cases
18:27:35 <SumitNaiksatam> cgoncalves: dont worry about it
18:27:39 <cgoncalves> this wekk I've been thinking on start developing this BP
18:27:39 <SumitNaiksatam> perhaps a reference is good
18:27:41 <s3wong> cgoncalves: sorry for our delay - with ServiceBase now having all the attachment information, perhaps there is something there you can leverage in this bp?
18:27:52 <regXboi> in the BP one question
18:28:04 <cgoncalves> I'd like to hear from you on how do you think it would be best to implement it.
18:28:14 <regXboi> the statement that the abstraction *can be leveraged* implies that there is more than one way to specify a service chain
18:28:22 <regXboi> is that a good idea?
18:28:32 <mandeep> regXboi: Yes
18:28:41 <SumitNaiksatam> regXboi: there are different levels of abstraction
18:28:49 <mandeep> regXboi: There are multi-function boxes that can not support full traffic streeing
18:28:59 <cgoncalves> s3wong: will look again, sure
18:29:05 <mandeep> regXboi: But they can honor the requirements of a chain
18:29:13 <SumitNaiksatam> cgoncalves: thanks
18:29:26 <s3wong> cgoncalves: great. Thanks!
18:29:28 <SumitNaiksatam> cgoncalves: we will continue to discuss this in the summit
18:29:41 <SumitNaiksatam> cgoncalves: i know you cannot make it, but we shepherd it
18:29:45 <regXboi> having more than one way to do something is adding complexity, so I have to ask if it is really necessary
18:29:46 <cgoncalves> SumitNaiksatam: ok, but note that I won't join you all though
18:29:52 <cgoncalves> SumitNaiksatam: ok
18:29:52 <s3wong> cgoncalves: I trust that you and your team will be in Atlanta? perhaps we can meet and discuss?
18:29:56 <regXboi> that's all
18:30:07 <SumitNaiksatam> mandeep regXboi: nice segue to the topic
18:30:11 <cgoncalves> s3wong: we won't make it this time, sorry
18:30:16 <SumitNaiksatam> #topic Service Chaining
18:30:23 <SumitNaiksatam> mandeep: please continue
18:30:34 <SumitNaiksatam> mandeep: i know you have dependency on the earlier items
18:30:36 <mandeep> Following up on comments from regXboi
18:30:56 * regXboi listens
18:31:13 <mandeep> The current proposal for service base, service insertion and servoce chaining
18:31:19 <SumitNaiksatam> we are going to go a few minutes over (hope thats fine with everyone)
18:31:24 <mandeep> allow for a very complete model to be developed in future
18:31:44 <mandeep> But we already have existing services that can provide services in a very common use case
18:32:04 <mandeep> That is "chaining multiple bump-in-the-wire services"
18:32:23 <mandeep> The intent of this proposal is to identify that use case (and it's context)
18:32:50 <mandeep> and define the expectations on the semantics of that service
18:32:57 <regXboi> so you envision this as being for L2 insertions?
18:33:22 <mandeep> that way, the service could be achieved by sterribg traffic between multiple services inserted in a network
18:33:45 <regXboi> mandeep: clarity - that implies that this is for L2 insertions and not for L3 insertions?
18:33:48 <mandeep> (at L2 or L3), or by a multifunction service that can honor the chain semantics
18:34:10 <mandeep> The semantics are defined in terms of BITW model.
18:34:16 <mandeep> That is typically L2
18:34:52 <mandeep> But the implementation may wrap it in L3 or any other tagging mechanims - the abstraction does not imply the implementation
18:35:13 <regXboi> so, I ask because I didn't make the jump from port to L2
18:35:13 <mandeep> The semantics need to be honoured, and the specification is of those semantics
18:35:37 <regXboi> I read this as being applicable to ports on a router
18:36:08 <SumitNaiksatam> regXboi: a lot of the questions you are asking are actually meant to be answered in teh service insertion blueprint
18:36:11 <mandeep> regXboi: Actually you are correct. I was using L2 incorrectly
18:36:38 <regXboi> SumitNaiksatam: it's likely, the topics tend to bleed together
18:36:54 <SumitNaiksatam> regXboi: completely agree
18:37:26 <SumitNaiksatam> regXboi: but at a high level, the thinking was that the service chain blueprint would leverage the service insertion and traffic steering abstractions provided to it
18:37:34 <mandeep> regXboi: The intent is to define a semantic at usage/consumption of the service and not require orchestration/steering if your technology can not support it
18:37:51 <regXboi> mandeep: Understood, though I'm still concerned about having more than one way to accomplish something, but I'll put some more thought into nailing down the issues I foresee
18:37:56 <mandeep> regXboi: But if it is available, that would probably be the simplest mapping
18:38:07 <regXboi> because if they aren't real, then there's no reason to worry
18:38:13 <regXboi> mandeep: agreed
18:38:21 <mandeep> regXboi: OK, I will look into that as well
18:38:37 <SumitNaiksatam> mandeep: we will have the spec in gerrit by next week?
18:38:49 <SumitNaiksatam> mandeep: i know you have a dependency on the service insertion blueprint to land
18:38:54 <mandeep> regXboi: They are real .. that is how for example the current FW service is provided (on the router port)
18:39:00 <mandeep> SumitNaiksatam: Yes
18:39:05 <SumitNaiksatam> mandeep: great, thanks
18:39:15 <SumitNaiksatam> regXboi mandeep: thanks for that discussion
18:39:21 <SumitNaiksatam> #open discussion
18:39:27 <SumitNaiksatam> we are over time as usual
18:39:31 <regXboi> you mean #topic?
18:39:38 <mandeep> :-0
18:39:39 <SumitNaiksatam> regXboi: yes
18:39:43 <SumitNaiksatam> i am getting restless
18:39:44 <mandeep> :-)
18:39:48 <SumitNaiksatam> #topic open discussion
18:40:09 <SumitNaiksatam> anything else to discuss before we meet in person next week?
18:40:29 <s3wong> an official announcement that we won't have meeting next week? :-)
18:40:43 <regXboi> yes - I won't make ATL :(
18:40:46 <mandeep> Perhaps, meet at the PoD?
18:40:50 <SumitNaiksatam> s3wong: yes thaks
18:40:54 <regXboi> so will pick up again in two weeks
18:40:59 <SumitNaiksatam> #announcement no meeting next week :-)
18:41:00 <cgoncalves> s3wong: nooo! :-(
18:41:01 <mandeep> regXboi: I will  be missing too this time :-(
18:41:05 <SumitNaiksatam> regXboi: yes
18:41:25 <SumitNaiksatam> we will miss you both!
18:41:35 <SumitNaiksatam> ok thanks everyone (fwaas folks are waiting)
18:41:39 <SumitNaiksatam> see you in atlanta
18:41:40 <s3wong> thanks!
18:41:44 <SumitNaiksatam> #endmeeting