#opendaylight-group-policy: gbp_arch

Meeting started by tbachman at 18:03:36 UTC (full logs).

Meeting summary

    1. attendees: lenrow s3wong readams alagalah Bhushan mickey_spiegel Martin tbachman (tbachman, 18:05:09)

  2. mobility use case (tbachman, 18:05:13)
    1. lenrow asks whether GBP can support mobility applications (tbachman, 18:05:38)
    2. 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)
    3. 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)
    4. lenrow says that for the sake of his conversation, he’s willing to consider a greenfield environment (tbachman, 18:08:26)
    5. the EP registry is the thing that’s informing the rendering side of the world about locations, etc. (tbachman, 18:10:03)
    6. alagalah_ I think I am for the most point? (tbachman, 18:10:40)
    7. mickey_spiegel notes that for mobility may involve 802.1x for identity (tbachman, 18:12:02)
    8. lenrow says that applications like this require upates for devices that have moved (tbachman, 18:13:57)
    9. readams says that moving a device, the update llatency should be on the order of the movement of the device. (tbachman, 18:14:24)
    10. readams says that learning can happen on very short time scales (tbachman, 18:14:44)
    11. Bhushan says that when a device moves from one tower to the other, there is pre-population to handle this (tbachman, 18:15:18)
    12. readams says that you can anticipate the move and pre-provision it (tbachman, 18:16:04)
    13. lenrow is concerned that the GBP’s white-list model will result in dropped packets for these kind of applications (tbachman, 18:19:50)
    14. readams notes that you can put as much policy as you want on a given device (tbachman, 18:21:43)
    15. readams continues — there’s nothing from preventing how it’s being done now using GBP (tbachman, 18:21:59)
    16. Bhushan says you can always choose in the renderer the default policy to implement in the access layer (tbachman, 18:22:36)
    17. mickey_spiegel says that the issue is appllying a contact temporarily until the final contract is resolved (tbachman, 18:23:29)
    18. mickey_spiegel says that using longest match IP address conversation from last week may apply here (tbachman, 18:23:45)
    19. 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)
    20. (readams says) that this can be extended in the extreme case for total security lockdown (tbachman, 18:25:27)
    21. 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)
    22. Bhushan asks lenrow to define what is secure and insecure (tbachman, 18:27:17)
    23. lenrow thinks we may want to push this conversation to when dvorkinsta can attend (tbachman, 18:28:24)
    24. lenrow says that for sake of today’s discussion, lets forget the whitelist question (tbachman, 18:28:52)
    25. mickey_spiegel says that you can have a contract that matches every destination, and allows whatever you want to allow (tbachman, 18:30:12)
    26. 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)
    27. lenrow says there’s also a scaling aspect, specifically populating forwarding tables (tbachman, 18:30:56)
    28. 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)
    29. Bhushan says the only alternative for no latency is to program the rule everywhere, which won’t scale (tbachman, 18:33:11)
    30. lenrow doesn’t want to push this off on the renderer — we need to address how this will be solved (tbachman, 18:36:24)
    31. mickey_spiegel says we’ve talked about 2 ways for proactive (everywhere vs. “follow-you-around”) (tbachman, 18:36:57)
    32. lenrow asks how does EP Registry find out that a device has moved? (tbachman, 18:37:15)
    33. lenrow says there are use cases/scenarios where it helps to be reactive (tbachman, 18:37:35)
    34. mickey_spiegel says that we should also allow people to be reactive (tbachman, 18:38:23)
    35. 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)
    36. but that SB will tell the EP registry of migration (tbachman, 18:39:53)
    37. mickey_spiegel says that lenrow may be reading too much into the white-list discussion (tbachman, 18:42:11)
    38. lenrow says that we need clarification from dvorkinista on this (tbachman, 18:43:46)
    39. because lenrow believes that dvorkinista has expressed that this is a truly white-list model (tbachman, 18:44:30)
    40. 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)
    41. my vote is reactive (alagalah_, 18:52:14)
    42. with a view to support all of them (alagalah_, 18:52:39)
    43. my vote is proactive follow the endpoint around (Bhushan_, 18:53:17)
    44. with view to support all of them (Bhushan_, 18:53:28)
    45. my vote is POC reactive, support all three (dlenrow, 18:54:13)
    46. my vote is reactive as well (s3wong, 18:54:24)
    47. 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)
    48. agree that reactive is the simplest to implement as a PoC (Bhushan_, 18:55:42)
    49. 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)
    50. https://trello.com/b/edPC5PAe/odl-gbp-helium <= link to the trello board (tbachman, 18:59:02)
    51. Mickey proposes using one policy while resolving another policy (mickey_spiegel, 19:00:12)


Meeting ended at 19:00:18 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (50)
  2. Bhushan_ (5)
  3. alagalah_ (5)
  4. mickey_spiegel (4)
  5. odl_meetbot (3)
  6. dlenrow (1)
  7. s3wong (1)


Generated by MeetBot 0.1.4.