14:06:20 <alagalah> #startmeeting NSHSFC Jul4
14:06:20 <collabot`> Meeting started Mon Jul  4 14:06:20 2016 UTC.  The chair is alagalah. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:20 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:06:20 <collabot`> The meeting name has been set to 'nshsfc_jul4'
14:06:30 <alagalah> #topic Webex no host key ...
14:06:38 <alagalah> #info moving to cisco.webex.com/meet/krb
23:14:45 <Yi> Hi, Ed, I'm here
23:18:34 <Yi> Ed, are you there?
23:23:17 <edwarnicke> Yi: I'm here :)
23:23:39 <edwarnicke> Yi: Have you had a chance to look at https://git.opendaylight.org/gerrit/#/c/41450/
23:26:18 <Yi> I'll take a look
23:26:34 <Yi> so won't we use vbd, right?
23:27:05 <edwarnicke> Yi:  vdb is handling virtual bridge domains
23:27:16 <edwarnicke> Yi: SFC was designed to support multiple renderers
23:27:37 <edwarnicke> Yi: So we are going to use ODL SFC to render service function chains
23:27:41 <edwarnicke> Down to honeycomb
23:28:02 <edwarnicke> Yi: You've worked with the SFC project and model before, correct?
23:28:48 <Yi> I know, but the interfaces should belong to one virtual bridge domain.
23:28:49 <Yi> yes
23:28:59 <edwarnicke> Yi: Not necessarily
23:29:10 <Yi> I'm very familiar with sfc openflow renderer
23:29:12 <edwarnicke> Yi: And whether it does or not is not really SFCs concern
23:29:22 <edwarnicke> Yi: Yes, but things here are much different than OF
23:29:28 <edwarnicke> Yi: We have to work far less hard :)
23:29:47 <edwarnicke> Yi: For example
23:30:04 <edwarnicke> Say that an interface is part of a virtual bridge domain
23:30:33 <edwarnicke> And SFC programs a classifier that places some traffic from that port on a SFC
23:30:50 <edwarnicke> We don't have to worry about any of the VBD stuff... VBD handles that
23:31:36 <edwarnicke> We just have to program an acl on that interface, for our classifier, that puts the correct nsh header on, and sends it off to the next sff
23:31:44 <edwarnicke> (presuming the next sf is on a different sff)
23:31:50 <Yi> I'm confused, can vpp act a classifier currently/
23:32:08 <edwarnicke> Yi: Yes
23:32:17 <edwarnicke> Yi: Though the work for the Honeycomb model is in progress
23:33:26 <Yi> Then vpp lassifier has to coordinate with sfc honeycomb renderer.
23:33:33 <edwarnicke> Yi: Why would it?
23:33:48 <edwarnicke> Yi: Wait
23:33:53 <edwarnicke> Let me rephrase
23:34:12 <edwarnicke> The sfc honeycomb render can configure sff or classifiers as needed
23:34:18 <edwarnicke> Yi:  For example
23:34:35 <edwarnicke> Yi: Say the classifier is somewhere not running vpp, but *some* of the sffs are running vpp
23:34:49 <Yi> currently, sfc classifer needs to know nsp and nsi and steer the traffic to the first SFF and the last SFF.
23:34:53 <edwarnicke> The SFC honeycomb renderer can simply program the pieces for the sffs that are vpp instances
23:34:59 <edwarnicke> Yi: correct
23:35:39 <Yi> SFF must return back the traffic to sfc classifier on the two sides of the service function chain.
23:37:10 <edwarnicke> Yi: No.  SFF must send traffic to the next SFF
23:37:20 <Yi> sfc classifer and sfc renderer are two separate pieces
23:37:52 <edwarnicke> Yi: Or to be more precise, when traffic egresses from the last SF that SFF is responsible for, it must send the traffic to the next SFF
23:38:09 <edwarnicke> Yi: That depends
23:38:26 <Yi> the last SFF and the first SFF must relay the traffic to classifiers.
23:38:30 <edwarnicke> Yi: It is possible for SFC classifier to be performed by an external entity, like GBP
23:38:40 <Yi> yes
23:38:44 <edwarnicke> Yi: Only in the special case of GBP
23:38:52 <edwarnicke> Yi: In the *general* case not
23:39:17 <edwarnicke> Yi: And even then... it may not be optimal to forward to the same point it ingressed as a classifier
23:39:34 <Yi> but sfc openflow renderer did some special thing for gbp and netvirt
23:39:34 <Yi> that is why I say they must coordinate
23:39:59 <edwarnicke> Yi: But you are correct, we would like to properly support that GBP special case where GBP programs the classifier and gives us a 'hint' as to where to send the packet when it egresses the SFC :)
23:40:27 <edwarnicke> Yi: That whole thing was made massively more complex by OF
23:40:36 <edwarnicke> (trust me, I originated that design :) )
23:40:41 <Yi> this is necessary for all the classifiers.
23:40:47 <edwarnicke> Yi: It is not
23:41:09 <edwarnicke> Yi: The GBP case is a special case
23:41:21 <edwarnicke> Yi: The general case for SFC does not do so
23:43:16 <edwarnicke> Yi: If memory serves, the GBP case involves putting what amounts to a datapath locator in the metadata... so that the last SFF can send it off
23:43:33 <edwarnicke> Yi: That requires that a classifier which desires such behavior puts in the correct info in metadata
23:43:41 <edwarnicke> But it is a loose binding
23:43:43 <edwarnicke> Not a tight one
23:45:22 <edwarnicke> Yi: And one can just as validly configure the classifier in SFC, and let the SFC renderer handle it :)
23:47:09 <Yi> Sorry, I is disconnected
23:47:19 <Yi> Sorry, I is disconnected
23:47:50 <Yi> Two questions, for honeycomb/vpp support, do we still need vbd?
23:48:42 <Yi> the second question, can IOS XE renderer be reused for honeycomb renderer?
23:49:57 <edwarnicke> Yi: I'll answer in reverse order ;)
23:50:08 <edwarnicke> Yi: I don't think the IOS XE render can be reused for honeycomb render
23:50:17 <edwarnicke> Yi: But I don't think the honeycomb renderer will be very hard
23:50:34 <edwarnicke> Yi: As to needing vbd
23:50:38 <edwarnicke> Yi: I don't believe we do
23:50:54 <edwarnicke> Yi: Now it *might* be the case that to support the GBP case, we need GBP to do a little bit of work
23:51:03 <edwarnicke> Yi: But not VBD... that would be out of its scope
23:51:29 <Yi> but we need to do honeycomb render from scratch.
23:51:35 <edwarnicke> Yi: That said, we *should* support both the special GBP case where GBP is providing the classifier *and* the general case where SFC renderer is providing it
23:51:51 <edwarnicke> Yi: I believe we do need to do a honeycomb renderer from scratch
23:51:55 <edwarnicke> Yi: But the good news is
23:52:04 <edwarnicke> Yi: It should mostly be model translations, because of the netconf mount
23:53:22 <Yi> no, renderer needs to translate rsp to a lot of honeycomb calls.
23:53:41 <edwarnicke> Yi: Example:  Say an SFC is programmed, with its addendent Service path, and a list of SFs. Each of those SFs is on a SFF.  For each SFF that is a honeycomb/vpp SFF, we can them program the nsh forwarding into each
23:53:50 <edwarnicke> Yi: exactly :)
23:54:20 <edwarnicke> Yi, but each honeycomb node is netconf mounted into the tree
23:55:00 <edwarnicke> Yi: So its basically a matter of listening for RSPs to be written to the data tree, computing the necessary NSH forwarding rules, and writing them to the correct netconf mounted datatree within ODL
14:04:11 <alagalah> #endmeeting