18:03:36 <tbachman> #startmeeting gbp_arch
18:03:36 <odl_meetbot> Meeting started Fri Jun 27 18:03:36 2014 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
18:03:36 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:36 <odl_meetbot> The meeting name has been set to 'gbp_arch'
18:05:09 <tbachman> #info attendees: lenrow s3wong readams alagalah Bhushan mickey_spiegel Martin tbachman
18:05:13 <tbachman> #topic mobility use case
18:05:38 <tbachman> #info lenrow asks whether GBP can support mobility applications
18:06:54 <tbachman> #info readams says it’s a good use case. If you’re looking at a campus style renderer, having this mobility might be important
18:07:40 <tbachman> #info readams says he doesn’t see any particular obstacles. The problem is that underlying systems need features that can implement IP mobility
18:08:26 <tbachman> #info lenrow says that for the sake of his conversation, he’s willing to consider a greenfield environment
18:10:03 <tbachman> #info the EP registry is the thing that’s informing the rendering side of the world about locations, etc.
18:10:20 <alagalah_> tbachman: please track who says what
18:10:40 <tbachman> #info alagalah_ I think I am for the most point?
18:10:44 <tbachman> (see above)
18:11:01 <alagalah_> tbachman: no need to info that dude
18:11:08 <tbachman> lol
18:11:09 <tbachman> sorry
18:11:14 <tbachman> had an info at the ready
18:11:17 <tbachman> forgot to delete :)
18:11:19 <alagalah_> np
18:12:02 <tbachman> #info mickey_spiegel notes that for mobility may involve 802.1x for identity
18:13:57 <tbachman> #info lenrow says that applications like this require upates for devices that have moved
18:14:24 <tbachman> #info readams says that moving a device, the update llatency should be on the order of the movement of the device.
18:14:44 <tbachman> #info readams says that learning can happen on very short time scales
18:15:18 <tbachman> #info Bhushan says that when a device moves from one tower to the other, there is pre-population to handle this
18:16:04 <tbachman> #info readams says that you can anticipate the move and pre-provision it
18:19:50 <tbachman> #info lenrow is concerned that the GBP’s white-list model will result in dropped packets for these kind of applications
18:21:43 <tbachman> #info readams notes that you can put as much policy as you want on a given device
18:21:59 <tbachman> #info readams continues — there’s nothing from preventing how it’s being done now using GBP
18:22:36 <tbachman> #info Bhushan says you can always choose in the renderer the default policy to implement in the access layer
18:23:29 <tbachman> #info mickey_spiegel says that the issue is appllying a contact temporarily until the final contract is resolved
18:23:45 <tbachman> #info mickey_spiegel says that using longest match IP address conversation from last week may apply here
18:25:02 <tbachman> #info says that in the general case, you can ask what is the domain of possible endpoints with possible identifiers that would be allowed to communicate on the network
18:25:27 <tbachman> #info (readams says) that this can be extended in the extreme case for total security lockdown
18:26:26 <tbachman> #info lenrow asks whether there’s a single system out there that implements such a system as pure white-list model, as GBP does
18:27:17 <tbachman> #info Bhushan asks lenrow to define what is secure and insecure
18:28:24 <tbachman> #info lenrow thinks we may want to push this conversation to when dvorkinsta can attend
18:28:52 <tbachman> #info lenrow says that for sake of today’s discussion, lets forget the whitelist question
18:30:12 <tbachman> #info mickey_spiegel says that you can have a contract that matches every destination, and allows whatever you want to allow
18:30:33 <tbachman> #info there’s a time aspect to that, where you don’t know if there’s a better policy resolution, and during that time, packets are flowing
18:30:56 <tbachman> #info lenrow says there’s also a scaling aspect, specifically populating forwarding tables
18:32:48 <tbachman> #info Bhushan says that this is a trade-off of programming a rule where the endpiont is, and the latency of updating to handle that movement
18:33:11 <tbachman> #info Bhushan says the only alternative for no latency is to program the rule everywhere, which won’t scale
18:36:24 <tbachman> #info lenrow doesn’t want to push this off on the renderer — we need to address how this will be solved
18:36:57 <tbachman> #info mickey_spiegel says we’ve talked about 2 ways for proactive (everywhere vs. “follow-you-around”)
18:37:15 <tbachman> #info lenrow asks how does EP Registry find out that a device has moved?
18:37:35 <tbachman> #info lenrow says there are use cases/scenarios where it helps to be reactive
18:38:23 <tbachman> #info mickey_spiegel says that we should also allow people to be reactive
18:39:02 <tbachman> #info alagalah_ says that the EP registry is bi-directional, where you have an orchestration system that tells you where it’s going to be
18:39:53 <tbachman> #info but that SB will tell the EP registry of migration
18:42:11 <tbachman> #info mickey_spiegel says that lenrow may be reading too much into the white-list discussion
18:43:46 <tbachman> #info lenrow says that we need clarification from dvorkinista on this
18:44:30 <tbachman> #info because lenrow believes that dvorkinista has expressed that this is a truly white-list model
18:51:53 <mickey_spiegel> #info For a proof of concept for supporting mobile endpoints, should we focus on proactive programming everything everywhere? Proactive follow the endpoint around? Or reactive?
18:52:14 <alagalah_> #info my vote is reactive
18:52:39 <alagalah_> #info with a view to support all of them
18:53:17 <Bhushan_> #info my vote is proactive follow the endpoint around
18:53:28 <Bhushan_> #info with view to support all of them
18:54:13 <dlenrow> #info my vote is POC reactive, support all three
18:54:24 <s3wong> #info my vote is reactive as well
18:55:20 <Bhushan_> #info the reason I'm voting for follow endpoint around is because folks may deem Reactive as DoA by showing that it will break their use cases
18:55:42 <Bhushan_> #info agree that reactive is the simplest to implement as a PoC
18:56:12 <Bhushan_> #so ok with reactive as long as we make it clear that it is chosen for simplicity sake and is only for PoC
18:58:46 <tbachman> #info alagalah_ would like to start running the meetings using trello to kick it off, so that we can get to the code level
18:59:02 <tbachman> #link https://trello.com/b/edPC5PAe/odl-gbp-helium <= link to the trello board
19:00:12 <mickey_spiegel> #info Mickey proposes using one policy while resolving another policy
19:00:12 <mickey_spiegel> Would not take it any further than that
19:00:12 <mickey_spiegel> Suggesting broad policy in place while you resolve a tighter policy
19:00:18 <tbachman> #endmeeting