==================================== #opendaylight-group-policy: gbp_arch ==================================== Meeting started by tbachman at 18:03:36 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-group-policy/2014/gbp_arch/opendaylight-group-policy-gbp_arch.2014-06-27-18.03.log.html . Meeting summary --------------- * attendees: lenrow s3wong readams alagalah Bhushan mickey_spiegel Martin tbachman (tbachman, 18:05:09) * mobility use case (tbachman, 18:05:13) * lenrow asks whether GBP can support mobility applications (tbachman, 18:05:38) * readams says it’s a good use case. If you’re looking at a campus style renderer, having this mobility might be important (tbachman, 18:06:54) * readams says he doesn’t see any particular obstacles. The problem is that underlying systems need features that can implement IP mobility (tbachman, 18:07:40) * lenrow says that for the sake of his conversation, he’s willing to consider a greenfield environment (tbachman, 18:08:26) * the EP registry is the thing that’s informing the rendering side of the world about locations, etc. (tbachman, 18:10:03) * alagalah_ I think I am for the most point? (tbachman, 18:10:40) * mickey_spiegel notes that for mobility may involve 802.1x for identity (tbachman, 18:12:02) * lenrow says that applications like this require upates for devices that have moved (tbachman, 18:13:57) * readams says that moving a device, the update llatency should be on the order of the movement of the device. (tbachman, 18:14:24) * readams says that learning can happen on very short time scales (tbachman, 18:14:44) * Bhushan says that when a device moves from one tower to the other, there is pre-population to handle this (tbachman, 18:15:18) * readams says that you can anticipate the move and pre-provision it (tbachman, 18:16:04) * lenrow is concerned that the GBP’s white-list model will result in dropped packets for these kind of applications (tbachman, 18:19:50) * readams notes that you can put as much policy as you want on a given device (tbachman, 18:21:43) * readams continues — there’s nothing from preventing how it’s being done now using GBP (tbachman, 18:21:59) * Bhushan says you can always choose in the renderer the default policy to implement in the access layer (tbachman, 18:22:36) * mickey_spiegel says that the issue is appllying a contact temporarily until the final contract is resolved (tbachman, 18:23:29) * mickey_spiegel says that using longest match IP address conversation from last week may apply here (tbachman, 18:23:45) * 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 (tbachman, 18:25:02) * (readams says) that this can be extended in the extreme case for total security lockdown (tbachman, 18:25:27) * lenrow asks whether there’s a single system out there that implements such a system as pure white-list model, as GBP does (tbachman, 18:26:26) * Bhushan asks lenrow to define what is secure and insecure (tbachman, 18:27:17) * lenrow thinks we may want to push this conversation to when dvorkinsta can attend (tbachman, 18:28:24) * lenrow says that for sake of today’s discussion, lets forget the whitelist question (tbachman, 18:28:52) * mickey_spiegel says that you can have a contract that matches every destination, and allows whatever you want to allow (tbachman, 18:30:12) * 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 (tbachman, 18:30:33) * lenrow says there’s also a scaling aspect, specifically populating forwarding tables (tbachman, 18:30:56) * 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 (tbachman, 18:32:48) * Bhushan says the only alternative for no latency is to program the rule everywhere, which won’t scale (tbachman, 18:33:11) * lenrow doesn’t want to push this off on the renderer — we need to address how this will be solved (tbachman, 18:36:24) * mickey_spiegel says we’ve talked about 2 ways for proactive (everywhere vs. “follow-you-around”) (tbachman, 18:36:57) * lenrow asks how does EP Registry find out that a device has moved? (tbachman, 18:37:15) * lenrow says there are use cases/scenarios where it helps to be reactive (tbachman, 18:37:35) * mickey_spiegel says that we should also allow people to be reactive (tbachman, 18:38:23) * alagalah_ says that the EP registry is bi-directional, where you have an orchestration system that tells you where it’s going to be (tbachman, 18:39:02) * but that SB will tell the EP registry of migration (tbachman, 18:39:53) * mickey_spiegel says that lenrow may be reading too much into the white-list discussion (tbachman, 18:42:11) * lenrow says that we need clarification from dvorkinista on this (tbachman, 18:43:46) * because lenrow believes that dvorkinista has expressed that this is a truly white-list model (tbachman, 18:44:30) * For a proof of concept for supporting mobile endpoints, should we focus on proactive programming everything everywhere? Proactive follow the endpoint around? Or reactive? (mickey_spiegel, 18:51:53) * my vote is reactive (alagalah_, 18:52:14) * with a view to support all of them (alagalah_, 18:52:39) * my vote is proactive follow the endpoint around (Bhushan_, 18:53:17) * with view to support all of them (Bhushan_, 18:53:28) * my vote is POC reactive, support all three (dlenrow, 18:54:13) * my vote is reactive as well (s3wong, 18:54:24) * 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 (Bhushan_, 18:55:20) * agree that reactive is the simplest to implement as a PoC (Bhushan_, 18:55:42) * alagalah_ would like to start running the meetings using trello to kick it off, so that we can get to the code level (tbachman, 18:58:46) * LINK: https://trello.com/b/edPC5PAe/odl-gbp-helium <= link to the trello board (tbachman, 18:59:02) * Mickey proposes using one policy while resolving another policy (mickey_spiegel, 19:00:12) Meeting ended at 19:00:18 UTC. People present (lines said) --------------------------- * tbachman (50) * Bhushan_ (5) * alagalah_ (5) * mickey_spiegel (4) * odl_meetbot (3) * dlenrow (1) * s3wong (1) Generated by `MeetBot`_ 0.1.4