)]}'
{"doc/source/specs/igmp_application_and_multicast_support.rst":[{"author":{"_account_id":13070,"name":"Eran Gampel","email":"eran@gampel.net","username":"Gampel"},"change_message_id":"7f3842c6fdae15ede5705020a8d0f3d4cfb32ac3","unresolved":false,"context_lines":[{"line_number":34,"context_line":"that other VMs on the same subnet and neighbouring networks on other compute"},{"line_number":35,"context_line":"nodes will also receive the relevant packets."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Use cases:"},{"line_number":38,"context_line":"----------"},{"line_number":39,"context_line":" * Data replication"},{"line_number":40,"context_line":"   A single node sending data that needs to be replicated accross multiple"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a57f1b5_13175aee","line":37,"range":{"start_line":37,"start_character":4,"end_line":37,"end_character":9},"updated":"2016-02-11 08:19:46.000000000","message":"Another use case could be VMs using mcast auto discovery protocols like SSDP ...\n\nMessaging pub sub could be sending data via mcast","commit_id":"f38a966bb8628c8f5d42cf69147289807e497512"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"3a91f9e8bfd1cddbbaed0a281da9fb39ab0f9f86","unresolved":false,"context_lines":[{"line_number":34,"context_line":"that other VMs on the same subnet and neighbouring networks on other compute"},{"line_number":35,"context_line":"nodes will also receive the relevant packets."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Use cases:"},{"line_number":38,"context_line":"----------"},{"line_number":39,"context_line":" * Data replication"},{"line_number":40,"context_line":"   A single node sending data that needs to be replicated accross multiple"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a57f1b5_4b0aeb22","line":37,"range":{"start_line":37,"start_character":4,"end_line":37,"end_character":9},"in_reply_to":"3a57f1b5_13175aee","updated":"2016-02-11 13:14:59.000000000","message":"Done","commit_id":"f38a966bb8628c8f5d42cf69147289807e497512"},{"author":{"_account_id":13070,"name":"Eran Gampel","email":"eran@gampel.net","username":"Gampel"},"change_message_id":"60ef2cbe8e4c7cf9cd12d55de34c37684534d469","unresolved":false,"context_lines":[{"line_number":39,"context_line":" * Data replication"},{"line_number":40,"context_line":"   A single node sending data that needs to be replicated accross multiple"},{"line_number":41,"context_line":"   other server, e.g. backups."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":" * Monitoring"},{"line_number":44,"context_line":"   A server sending statistical information e.g. CPU, memory, and bandwidth"},{"line_number":45,"context_line":"   usage, to multiple monitoring agents."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a57f1b5_85ef7286","line":42,"updated":"2016-02-11 13:03:49.000000000","message":"video streaming","commit_id":"f38a966bb8628c8f5d42cf69147289807e497512"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"3a91f9e8bfd1cddbbaed0a281da9fb39ab0f9f86","unresolved":false,"context_lines":[{"line_number":39,"context_line":" * Data replication"},{"line_number":40,"context_line":"   A single node sending data that needs to be replicated accross multiple"},{"line_number":41,"context_line":"   other server, e.g. backups."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":" * Monitoring"},{"line_number":44,"context_line":"   A server sending statistical information e.g. CPU, memory, and bandwidth"},{"line_number":45,"context_line":"   usage, to multiple monitoring agents."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a57f1b5_ab035f0c","line":42,"in_reply_to":"3a57f1b5_85ef7286","updated":"2016-02-11 13:14:59.000000000","message":"Done","commit_id":"f38a966bb8628c8f5d42cf69147289807e497512"},{"author":{"_account_id":13070,"name":"Eran Gampel","email":"eran@gampel.net","username":"Gampel"},"change_message_id":"7f3842c6fdae15ede5705020a8d0f3d4cfb32ac3","unresolved":false,"context_lines":[{"line_number":116,"context_line":"        (via logical tunnel port)"},{"line_number":117,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src!\u003d10.0.0.100 actions\u003doutput:VM2"},{"line_number":118,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src\u003d\u003d10.0.0.100 actions\u003doutput:VM3"},{"line_number":119,"context_line":"  match\u003d actions\u003doutput:CONTROLLER"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"These are examples of packets that are sent to the relevant VM ports, including"},{"line_number":122,"context_line":"being sent to another compute node, and including source-based filtering. In"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a57f1b5_f3f39e9c","line":119,"range":{"start_line":119,"start_character":17,"end_line":119,"end_character":23},"updated":"2016-02-11 08:19:46.000000000","message":"Can we just identify in flow that this is IGMP commands(join ..) and just send those commands to the controller    \n\nWhy do we need to send the unknown multicast group is sent to the controller, why not just dropping it","commit_id":"f38a966bb8628c8f5d42cf69147289807e497512"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"3a91f9e8bfd1cddbbaed0a281da9fb39ab0f9f86","unresolved":false,"context_lines":[{"line_number":116,"context_line":"        (via logical tunnel port)"},{"line_number":117,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src!\u003d10.0.0.100 actions\u003doutput:VM2"},{"line_number":118,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src\u003d\u003d10.0.0.100 actions\u003doutput:VM3"},{"line_number":119,"context_line":"  match\u003d actions\u003doutput:CONTROLLER"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"These are examples of packets that are sent to the relevant VM ports, including"},{"line_number":122,"context_line":"being sent to another compute node, and including source-based filtering. In"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a57f1b5_c86341db","line":119,"range":{"start_line":119,"start_character":17,"end_line":119,"end_character":23},"in_reply_to":"3a57f1b5_f3f39e9c","updated":"2016-02-11 13:14:59.000000000","message":"In any case, an IGMP packet has to be sent to the controller for processing, since there will probably be internal datastructures that need to be updated.\n\nIn any case, this is just an example. During implementation, it can also be decided to drop the packet, or make this decision configurable.","commit_id":"f38a966bb8628c8f5d42cf69147289807e497512"},{"author":{"_account_id":13070,"name":"Eran Gampel","email":"eran@gampel.net","username":"Gampel"},"change_message_id":"60ef2cbe8e4c7cf9cd12d55de34c37684534d469","unresolved":false,"context_lines":[{"line_number":209,"context_line":"Additional Configuration"},{"line_number":210,"context_line":"------------------------"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Every subnet can be marked whether it supports multicast. If a subnet is marked"},{"line_number":213,"context_line":"not to support multicast, the router ports connected to that subnet are not"},{"line_number":214,"context_line":"multicast routers. They treat IGMP packets as regular routed IP packets. They"},{"line_number":215,"context_line":"do not send periodic general queries, and no multicast packets are never routed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a57f1b5_45ff3a67","line":212,"range":{"start_line":212,"start_character":1,"end_line":212,"end_character":35},"updated":"2016-02-11 13:03:49.000000000","message":"How will you configure it via the Neutron API ?\nConfiguration conf file ?\n\nIf we use conf file it make more sense to have it as a global enable disable  \n\nIn the Neturon terminology it make more sense to set this configuration on the Network","commit_id":"f38a966bb8628c8f5d42cf69147289807e497512"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"3a91f9e8bfd1cddbbaed0a281da9fb39ab0f9f86","unresolved":false,"context_lines":[{"line_number":209,"context_line":"Additional Configuration"},{"line_number":210,"context_line":"------------------------"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Every subnet can be marked whether it supports multicast. If a subnet is marked"},{"line_number":213,"context_line":"not to support multicast, the router ports connected to that subnet are not"},{"line_number":214,"context_line":"multicast routers. They treat IGMP packets as regular routed IP packets. They"},{"line_number":215,"context_line":"do not send periodic general queries, and no multicast packets are never routed"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a57f1b5_4813d166","line":212,"range":{"start_line":212,"start_character":1,"end_line":212,"end_character":35},"in_reply_to":"3a57f1b5_45ff3a67","updated":"2016-02-11 13:14:59.000000000","message":"In essence, every router port needs to know its configuration. Whether its on the subnet (and then it gets it from the connected subnet), router (router configuration), network (network to which the router belongs), or global (reads it from the configuration file or via oslo), is a detail that can be covered once we know what can be done on the Neutron side, and can be made more fine-grained if necessary.\n\nNote that I purposefully didn\u0027t cover every possible configuration option in the RFC. These are parameters that set the timings and repetitions, and not the general overall behaviour. (Except enable/disable, which is mentioned here explicitly).\n\nIn any case, I think this is somewhat beyond the scope of this document.","commit_id":"f38a966bb8628c8f5d42cf69147289807e497512"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"429295c81131b000a006c3632f3f20903f21a7d4","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"IGMP Application and Multicast Support"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/dragonflow/+spec/igmp-app"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_227d496e","line":8,"updated":"2016-02-11 15:19:08.000000000","message":"We need a section that describe how this can be \"offloaded\" also to the physical network and not just between VMs.\nI feel you need to give it some more thought.\n\nAlso, i think we need more info on the DB/publish subscribe and how exactly are you going to use it.\nHow do you sync information and how do you keep your data in the distributed DB (tables description and so on).\nIts important details for this spec .","commit_id":"51a24a9ddbec1e768b33ad010c7b64dd06a5b31c"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"47b8686742f5606c57bf27f1812b6583c9f93b41","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"IGMP Application and Multicast Support"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/dragonflow/+spec/igmp-app"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_42396540","line":8,"in_reply_to":"3a57f1b5_227d496e","updated":"2016-02-11 15:25:48.000000000","message":"I\u0027ll review the Synchronisation accross compute nodes and North-South Communication sections, and add this information.","commit_id":"51a24a9ddbec1e768b33ad010c7b64dd06a5b31c"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/dragonflow/+spec/igmp-app"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This blueprint describes the addition of an IGMP application and improvement"},{"line_number":14,"context_line":"in virtual multicast packet handling to Dragonflow."},{"line_number":15,"context_line":"We describe how Dragonflow can implement multicast routers using OVS, by"},{"line_number":16,"context_line":"handling IGMP and multicast packets while ensuring that only group members"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_2fd3203a","line":13,"updated":"2016-02-19 16:32:54.000000000","message":"I think this needs some more focus, some parts are over descriptive while some points are still unanswered.\n\nThe idea of having this design is that we can understand the details and not only the high level.\nI agree with most of Eshed points, i will try to point what sections needs more work","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11364,"name":"Fei Rao","email":"milo.frao@gmail.com","username":"milo.frao"},"change_message_id":"6f847dea9a8a93553ed5a40bf9a3ff05521d8e3a","unresolved":false,"context_lines":[{"line_number":15,"context_line":"We describe how Dragonflow can implement multicast routers using OVS, by"},{"line_number":16,"context_line":"handling IGMP and multicast packets while ensuring that only group members"},{"line_number":17,"context_line":"within the tenant network receive packets of a multicast group."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Problem Description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Currently, multicast packets are treated as broadcast packets. They are"},{"line_number":23,"context_line":"duplicated and sent to every VM on the subnet. Additionally, multicast"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dae33548_2fa4c806","line":20,"range":{"start_line":18,"start_character":0,"end_line":20,"end_character":19},"updated":"2016-02-19 07:48:06.000000000","message":"I think supporting multicast is a common feature for Neutron. It\u0027s necessary to abstract new APIs to manage VM join/leave the group.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"884be257d04cf8bd4c2601c0b9a812ac9fd94d05","unresolved":false,"context_lines":[{"line_number":15,"context_line":"We describe how Dragonflow can implement multicast routers using OVS, by"},{"line_number":16,"context_line":"handling IGMP and multicast packets while ensuring that only group members"},{"line_number":17,"context_line":"within the tenant network receive packets of a multicast group."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Problem Description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Currently, multicast packets are treated as broadcast packets. They are"},{"line_number":23,"context_line":"duplicated and sent to every VM on the subnet. Additionally, multicast"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_a0c53d3d","line":20,"range":{"start_line":18,"start_character":0,"end_line":20,"end_character":19},"in_reply_to":"bae84128_098c2634","updated":"2016-02-22 06:49:49.000000000","message":"I think the point Raofei was trying to make (and please correct me if i am wrong Raofei) is that we want to be able to define multicast groups without actually using IGMP by the VMs.\n\nSo a user/admin can pick a group of VMs and add them or remove them from a specific multicast group.\n\nI agree and think that this is a valid use case, and i believe thats actually the preferred use case in most solutions that i know that support this.\n\nI think however that this should be relatively easy to add, since you define a table that should map multicast groups to logical ports that are part of it in the DB, changing this table manually should be allowed.\n\nOf course there are cases we need to make sure to cover, for example IGMP has a \"keep alive\" on joins, we dont want to delete these ports that were added manually if they dont send IGMP and so on..\n\nThe Neutron part is less relevant for this spec","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"f89dc15d403465eec5c1f35f1bddf0b909331611","unresolved":false,"context_lines":[{"line_number":15,"context_line":"We describe how Dragonflow can implement multicast routers using OVS, by"},{"line_number":16,"context_line":"handling IGMP and multicast packets while ensuring that only group members"},{"line_number":17,"context_line":"within the tenant network receive packets of a multicast group."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Problem Description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Currently, multicast packets are treated as broadcast packets. They are"},{"line_number":23,"context_line":"duplicated and sent to every VM on the subnet. Additionally, multicast"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_74bad4c1","line":20,"range":{"start_line":18,"start_character":0,"end_line":20,"end_character":19},"in_reply_to":"bae84128_a0c53d3d","updated":"2016-02-22 08:13:23.000000000","message":"Will add some DF DB configuration for this.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"04ab3783e41dd72b26ff40b4adad0a7e64c7f613","unresolved":false,"context_lines":[{"line_number":15,"context_line":"We describe how Dragonflow can implement multicast routers using OVS, by"},{"line_number":16,"context_line":"handling IGMP and multicast packets while ensuring that only group members"},{"line_number":17,"context_line":"within the tenant network receive packets of a multicast group."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Problem Description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Currently, multicast packets are treated as broadcast packets. They are"},{"line_number":23,"context_line":"duplicated and sent to every VM on the subnet. Additionally, multicast"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_098c2634","line":20,"range":{"start_line":18,"start_character":0,"end_line":20,"end_character":19},"in_reply_to":"dae33548_2fa4c806","updated":"2016-02-21 15:16:40.000000000","message":"I disagree. In any case, a VM and a process running on that VM will have to register to a multicast group. Adding an abstraction API only adds overhead and an unnecessary configuration stage.\n\nIf we want to block a VM from joining a multicast group, it can be done using security groups.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":39,"context_line":"if necessary, i.e. VMs exist on those networks that subscribe to the"},{"line_number":40,"context_line":"particular multicast group."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Forwarding of the multicast packets will be done in the overlay network,"},{"line_number":43,"context_line":"using the MAC (L2) population to discover which Compute Nodes need to"},{"line_number":44,"context_line":"receive a copy of each packet."},{"line_number":45,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_8f3cec30","line":42,"updated":"2016-02-19 16:32:54.000000000","message":"This section is good, i would have added here that we are proposing two solutions here (and maybe its best to split their specs) one is for IGMP over the overlay network (and this should be tenant aware) \n\nThe other is IGMP/Multicast over the physical network, its important to understand that each one needs special handling.\nFor the first one we could already implement this with what we have.\n\nNow, if we have the second, think that we can also use this mechanism to send broadcast traffic for a certain virtual network (map it to a multicast group) so this might be also a nice use case to add below","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":49,"context_line":" * Data Replication - Replicating data of a single node to a group of other"},{"line_number":50,"context_line":"   nodes, e.g. for backup, disaster recovery, etc."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":" * Monitoring - A node broadcasting statistical information (e.g. CPU, memory,"},{"line_number":53,"context_line":"   bandwidth usage, etc.) to a group of monitoring agents"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":" * Automatic Service Discovery - Nodes discover services on the network, e.g."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_6f0c0895","line":52,"updated":"2016-02-19 16:32:54.000000000","message":"This looks good, maybe add the use case mentioned above","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11364,"name":"Fei Rao","email":"milo.frao@gmail.com","username":"milo.frao"},"change_message_id":"6f847dea9a8a93553ed5a40bf9a3ff05521d8e3a","unresolved":false,"context_lines":[{"line_number":60,"context_line":""},{"line_number":61,"context_line":" * Media Streaming"},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Proposed Change"},{"line_number":64,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"We will implement the Dragonflow IGMP Proxy application, in a manner similar"},{"line_number":67,"context_line":"to other Dragonflow applications (e.g. DHCP), following the specifications"},{"line_number":68,"context_line":"according to [1] as detailed below."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The IGMP Proxy application is optional, and needs to be enabled by the user."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Multicast packet filtering and routing"},{"line_number":73,"context_line":"--------------------------------------"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Extend the Dragonflow pipeline with flows that implement the following:"},{"line_number":76,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"dae33548_cf3a7c98","line":73,"range":{"start_line":63,"start_character":0,"end_line":73,"end_character":38},"updated":"2016-02-19 07:48:06.000000000","message":"Dragonflow will support vlan network as well, so how do you consider manage the physical switch configuration, such as igmp spoofing in one solution?","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"04ab3783e41dd72b26ff40b4adad0a7e64c7f613","unresolved":false,"context_lines":[{"line_number":60,"context_line":""},{"line_number":61,"context_line":" * Media Streaming"},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Proposed Change"},{"line_number":64,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"We will implement the Dragonflow IGMP Proxy application, in a manner similar"},{"line_number":67,"context_line":"to other Dragonflow applications (e.g. DHCP), following the specifications"},{"line_number":68,"context_line":"according to [1] as detailed below."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The IGMP Proxy application is optional, and needs to be enabled by the user."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Multicast packet filtering and routing"},{"line_number":73,"context_line":"--------------------------------------"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Extend the Dragonflow pipeline with flows that implement the following:"},{"line_number":76,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_e9774238","line":73,"range":{"start_line":63,"start_character":0,"end_line":73,"end_character":38},"in_reply_to":"dae33548_cf3a7c98","updated":"2016-02-21 15:16:40.000000000","message":"In general different VLANs are at least different subnets. So this solution is built-in.\n\nDealing with physical networks will be handled in a different spec, since it requires detailed review.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"884be257d04cf8bd4c2601c0b9a812ac9fd94d05","unresolved":false,"context_lines":[{"line_number":60,"context_line":""},{"line_number":61,"context_line":" * Media Streaming"},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Proposed Change"},{"line_number":64,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"We will implement the Dragonflow IGMP Proxy application, in a manner similar"},{"line_number":67,"context_line":"to other Dragonflow applications (e.g. DHCP), following the specifications"},{"line_number":68,"context_line":"according to [1] as detailed below."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The IGMP Proxy application is optional, and needs to be enabled by the user."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Multicast packet filtering and routing"},{"line_number":73,"context_line":"--------------------------------------"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Extend the Dragonflow pipeline with flows that implement the following:"},{"line_number":76,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_40227102","line":73,"range":{"start_line":63,"start_character":0,"end_line":73,"end_character":38},"in_reply_to":"dae33548_cf3a7c98","updated":"2016-02-22 06:49:49.000000000","message":"you mean IGMP spoofing or snooping?\nEither way as Omer pointed out we are only talking about encapsulated inner traffic, the physical layer doesnt see the multicast traffic.\n\nOf course as i suggested below, we also need to write spec for how to use physical network IGMP to our advantage.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":93,"context_line":"   routers, where its TTL will be reduced by 1 and its in_port changed to the"},{"line_number":94,"context_line":"   router\u0027s port."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":" * An alternative approach assumes the topology is known in advance, so the"},{"line_number":97,"context_line":"   IGMP Proxy application can calculate the distance (in hops) to registered"},{"line_number":98,"context_line":"   ports and then forward the MCP directly to ports that fall within the"},{"line_number":99,"context_line":"   acceptable distance, while reducing the TTL accordingly."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_52cf27b0","line":96,"updated":"2016-02-19 16:32:54.000000000","message":"Dont understand this, can you pleas explain?","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"f89dc15d403465eec5c1f35f1bddf0b909331611","unresolved":false,"context_lines":[{"line_number":93,"context_line":"   routers, where its TTL will be reduced by 1 and its in_port changed to the"},{"line_number":94,"context_line":"   router\u0027s port."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":" * An alternative approach assumes the topology is known in advance, so the"},{"line_number":97,"context_line":"   IGMP Proxy application can calculate the distance (in hops) to registered"},{"line_number":98,"context_line":"   ports and then forward the MCP directly to ports that fall within the"},{"line_number":99,"context_line":"   acceptable distance, while reducing the TTL accordingly."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_b4ebbcaf","line":96,"in_reply_to":"bae84128_20848dd2","updated":"2016-02-22 08:13:23.000000000","message":"This depends on the tenant\u0027s configuration. Tenant defines subnets, routers, and router ports.\n\nFor instance, tenant defines subnet A, B, and C, and routers X and Y. Router X has ports in A and B, and router Y has ports in B and C. The distance between hosts in A and C is 2 hops (Bot router X and Y are in the shortest path).","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"884be257d04cf8bd4c2601c0b9a812ac9fd94d05","unresolved":false,"context_lines":[{"line_number":93,"context_line":"   routers, where its TTL will be reduced by 1 and its in_port changed to the"},{"line_number":94,"context_line":"   router\u0027s port."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":" * An alternative approach assumes the topology is known in advance, so the"},{"line_number":97,"context_line":"   IGMP Proxy application can calculate the distance (in hops) to registered"},{"line_number":98,"context_line":"   ports and then forward the MCP directly to ports that fall within the"},{"line_number":99,"context_line":"   acceptable distance, while reducing the TTL accordingly."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_20848dd2","line":96,"in_reply_to":"bae84128_29900a43","updated":"2016-02-22 06:49:49.000000000","message":"i am not sure how the hop number can be bigger then 1 in dragonflow between two VMs","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"04ab3783e41dd72b26ff40b4adad0a7e64c7f613","unresolved":false,"context_lines":[{"line_number":93,"context_line":"   routers, where its TTL will be reduced by 1 and its in_port changed to the"},{"line_number":94,"context_line":"   router\u0027s port."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":" * An alternative approach assumes the topology is known in advance, so the"},{"line_number":97,"context_line":"   IGMP Proxy application can calculate the distance (in hops) to registered"},{"line_number":98,"context_line":"   ports and then forward the MCP directly to ports that fall within the"},{"line_number":99,"context_line":"   acceptable distance, while reducing the TTL accordingly."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_29900a43","line":96,"in_reply_to":"bae84128_52cf27b0","updated":"2016-02-21 15:16:40.000000000","message":"If we know the topology in advance, i.e. the distance between any two VMs on the network and the distance between the subnets they\u0027re on, we can calculate the distance the packet will pass, in hops, and send it directly to the target subnet with the number of hops removed from the ttl.\n\nIn a pure virtual system, e.g. on dragonflow, we have this information. When dealing with physical networks, we don\u0027t.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":145,"context_line":"  match\u003dip_dst\u003d224.0.0.y actions\u003doutput:VM1,output:ComputeNode2"},{"line_number":146,"context_line":"        (via logical tunnel port)"},{"line_number":147,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src!\u003d10.0.0.100 actions\u003doutput:VM2"},{"line_number":148,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src\u003d\u003d10.0.0.100 actions\u003doutput:VM3"},{"line_number":149,"context_line":"  match\u003d actions\u003doutput:CONTROLLER"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"These are examples of packets that are sent to relevant ports on the local"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_72d18bcd","line":148,"updated":"2016-02-19 16:32:54.000000000","message":"I think that the idea of not sending to the source is wrong.\nIt over complicate the solution for every possible source.\n\nWhat i would suggest, and this is something we are going to do anyway is to duplicate the packets to all the possible outputs (including the source which must reside on this machine) and then in our port security we throw traffic that has the same source port and dst port (using the registers we have that classify the source port and dst port)\nThis will reduce the number of flows and reduce complexity of this solution","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"04ab3783e41dd72b26ff40b4adad0a7e64c7f613","unresolved":false,"context_lines":[{"line_number":145,"context_line":"  match\u003dip_dst\u003d224.0.0.y actions\u003doutput:VM1,output:ComputeNode2"},{"line_number":146,"context_line":"        (via logical tunnel port)"},{"line_number":147,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src!\u003d10.0.0.100 actions\u003doutput:VM2"},{"line_number":148,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src\u003d\u003d10.0.0.100 actions\u003doutput:VM3"},{"line_number":149,"context_line":"  match\u003d actions\u003doutput:CONTROLLER"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"These are examples of packets that are sent to relevant ports on the local"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_89c67647","line":148,"in_reply_to":"bae84128_72d18bcd","updated":"2016-02-21 15:16:40.000000000","message":"1. I would rather avoid making a copy of a packet if I don\u0027t have to.\n2. We have to filter packets according to source IP anyway. This is required by IGMPv3. I don\u0027t think this would complicate matters much.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"884be257d04cf8bd4c2601c0b9a812ac9fd94d05","unresolved":false,"context_lines":[{"line_number":145,"context_line":"  match\u003dip_dst\u003d224.0.0.y actions\u003doutput:VM1,output:ComputeNode2"},{"line_number":146,"context_line":"        (via logical tunnel port)"},{"line_number":147,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src!\u003d10.0.0.100 actions\u003doutput:VM2"},{"line_number":148,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src\u003d\u003d10.0.0.100 actions\u003doutput:VM3"},{"line_number":149,"context_line":"  match\u003d actions\u003doutput:CONTROLLER"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"These are examples of packets that are sent to relevant ports on the local"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_a0fd3d3c","line":148,"in_reply_to":"bae84128_89c67647","updated":"2016-02-22 06:49:49.000000000","message":"1. No copy is being made, this is just a simulation.\n\n2. I dont see why we need to filter packets according to source ip, you can filter them according to port numbers (logical port ids)","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"f89dc15d403465eec5c1f35f1bddf0b909331611","unresolved":false,"context_lines":[{"line_number":145,"context_line":"  match\u003dip_dst\u003d224.0.0.y actions\u003doutput:VM1,output:ComputeNode2"},{"line_number":146,"context_line":"        (via logical tunnel port)"},{"line_number":147,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src!\u003d10.0.0.100 actions\u003doutput:VM2"},{"line_number":148,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src\u003d\u003d10.0.0.100 actions\u003doutput:VM3"},{"line_number":149,"context_line":"  match\u003d actions\u003doutput:CONTROLLER"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"These are examples of packets that are sent to relevant ports on the local"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_547990f5","line":148,"in_reply_to":"bae84128_a0fd3d3c","updated":"2016-02-22 08:13:23.000000000","message":"The filtering can indeed be done according to ports and not IPs. But I still think the multicast application is responsible to make sure as few multicast packets and simulations are made.\n\nIn any case, if this proves to be too difficult, we can always fall back on the security group solution. I\u0027ll add that as an option - but I would prefer the spec to reflect the ideal implementation.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":153,"context_line":"We forward MCP on unknown multicast group to the controller (i.e. the IGMP"},{"line_number":154,"context_line":"Proxy application in Dragonflow) to enable reactive programming."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"For the sake of clarity and simplicity, we have omitted filtering by tenant"},{"line_number":157,"context_line":"and network from this example."},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"IGMP packet handling"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_f2dbdb19","line":156,"updated":"2016-02-19 16:32:54.000000000","message":"This is an important point, need to make sure that this support multi tenancy and that the multicast IPs can actually overlap between tenants.\n\nIts not clear to me from this section how are you handling the actual traffic, how you duplicate it in the destination and how you update to which to send it in the source.\n\nHow this all combine with the current pipeline","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":194,"context_line":"distributed database, in a specific *Multicast* table."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"All IGMP-A instances on all compute nodes subscribe to changes on the"},{"line_number":197,"context_line":"*Multicast* table and update their local flows per these changes."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"For performance optimization, we provide a configurable parameter"},{"line_number":200,"context_line":"\u003caggregated membership report interval\u003e that defines the minimal time"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_0d046413","line":197,"updated":"2016-02-19 16:32:54.000000000","message":"This is a critical part in the spec, we need to understand how this table looks like, what are the changes and how they effect the flows.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":208,"context_line":"to the IGMP specs [1]:"},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"* MCR is required to join the multicast group 224.0.0.22"},{"line_number":211,"context_line":"* MCR is required to implement the IGMP protocol as a group member"},{"line_number":212,"context_line":"  host[1]"},{"line_number":213,"context_line":"* MCR is required to respond to general and group-specific queries"},{"line_number":214,"context_line":"* MCR should advertise its group membership"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_ed902098","line":211,"updated":"2016-02-19 16:32:54.000000000","message":"This is the virtual router i assume?\n\nWe also want to be able to configure this per router if we allow IGMP or not, and probably this should also be policy level configuration per tenant, if we allow this tenant to create IGMP routers\n\nI would also put a quota on the maximum allowed multicast groups per tenant.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"04ab3783e41dd72b26ff40b4adad0a7e64c7f613","unresolved":false,"context_lines":[{"line_number":208,"context_line":"to the IGMP specs [1]:"},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"* MCR is required to join the multicast group 224.0.0.22"},{"line_number":211,"context_line":"* MCR is required to implement the IGMP protocol as a group member"},{"line_number":212,"context_line":"  host[1]"},{"line_number":213,"context_line":"* MCR is required to respond to general and group-specific queries"},{"line_number":214,"context_line":"* MCR should advertise its group membership"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_e9ae2284","line":211,"in_reply_to":"bae84128_ed902098","updated":"2016-02-21 15:16:40.000000000","message":"Yes, this is regarding the virtual router.\n\nWhy do we want a quota on maximum allowed multicast groups? What\u0027s the use-case?","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":16983,"name":"Eshed Gal-Or","email":"eshed.galor@huawei.com","username":"eshedg"},"change_message_id":"8ef0a70d7b2a5e141b707a58ed74b11da84c1155","unresolved":false,"context_lines":[{"line_number":222,"context_line":"compatibility to IGMPv1 and IGMPv2."},{"line_number":223,"context_line":"A configuration parameter will define which IGMP version is provided."},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"North-South Communication"},{"line_number":226,"context_line":"-------------------------"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"At the moment, communication to and from networks external to openstack is not"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dae33548_ebfca673","line":225,"updated":"2016-02-18 22:00:39.000000000","message":"this section needs some more work.  \nit might be better to limit the scope of this bp to east-west, and leave the north-south to another bp.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"04ab3783e41dd72b26ff40b4adad0a7e64c7f613","unresolved":false,"context_lines":[{"line_number":222,"context_line":"compatibility to IGMPv1 and IGMPv2."},{"line_number":223,"context_line":"A configuration parameter will define which IGMP version is provided."},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"North-South Communication"},{"line_number":226,"context_line":"-------------------------"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"At the moment, communication to and from networks external to openstack is not"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_29b76ad9","line":225,"in_reply_to":"bae84128_0d658444","updated":"2016-02-21 15:16:40.000000000","message":"This section will be removed, to be handled in a different spec.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"bdca8bc6a56bc3ee9f67fb4d27e97f9fa391266b","unresolved":false,"context_lines":[{"line_number":222,"context_line":"compatibility to IGMPv1 and IGMPv2."},{"line_number":223,"context_line":"A configuration parameter will define which IGMP version is provided."},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"North-South Communication"},{"line_number":226,"context_line":"-------------------------"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"At the moment, communication to and from networks external to openstack is not"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_0d658444","line":225,"in_reply_to":"bae84128_8d37d4e2","updated":"2016-02-19 16:34:48.000000000","message":"off this spec","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":222,"context_line":"compatibility to IGMPv1 and IGMPv2."},{"line_number":223,"context_line":"A configuration parameter will define which IGMP version is provided."},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"North-South Communication"},{"line_number":226,"context_line":"-------------------------"},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"At the moment, communication to and from networks external to openstack is not"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_8d37d4e2","line":225,"in_reply_to":"dae33548_ebfca673","updated":"2016-02-19 16:32:54.000000000","message":"I agree, this is more complicated and needs more thought and detail description, i would leave this part of this spec.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":16983,"name":"Eshed Gal-Or","email":"eshed.galor@huawei.com","username":"eshedg"},"change_message_id":"8ef0a70d7b2a5e141b707a58ed74b11da84c1155","unresolved":false,"context_lines":[{"line_number":258,"context_line":"Additional Configuration"},{"line_number":259,"context_line":"------------------------"},{"line_number":260,"context_line":""},{"line_number":261,"context_line":"Every subnet can be marked whether it supports multicast. If a subnet is marked"},{"line_number":262,"context_line":"not to support multicast, the router ports connected to that subnet are not"},{"line_number":263,"context_line":"multicast routers. They treat IGMP packets as regular routed IP packets. They"},{"line_number":264,"context_line":"do not send periodic general queries, and no multicast packets are never routed"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dae33548_8b7ebae1","line":261,"updated":"2016-02-18 22:00:39.000000000","message":"this section needs to be more decisive about the solution.  if people disagree, they can comment their disagreement and suggest better alternative.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":261,"context_line":"Every subnet can be marked whether it supports multicast. If a subnet is marked"},{"line_number":262,"context_line":"not to support multicast, the router ports connected to that subnet are not"},{"line_number":263,"context_line":"multicast routers. They treat IGMP packets as regular routed IP packets. They"},{"line_number":264,"context_line":"do not send periodic general queries, and no multicast packets are never routed"},{"line_number":265,"context_line":"to that subnet. This change will require Neutron integration to support Neutron"},{"line_number":266,"context_line":"API for this configuration."},{"line_number":267,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_cd171cec","line":264,"updated":"2016-02-19 16:32:54.000000000","message":"Maybe rephrase this section with the actual configuration changes and then maybe small explanation.\n\nExample:\n\nSubnet - igmp_support (True/False)\n\nPersonally i would do this per router, i dont mind to do it per subnet but it complicate the solution and i dont thinks in the virtual world its a \"real\" use case, but could be wrong, you can leave it like that","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":266,"context_line":"API for this configuration."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"The IGMPv3 standard defines timers and counters that can be configured. These"},{"line_number":269,"context_line":"configuration parameters can be defined on each switch or router. In case this"},{"line_number":270,"context_line":"is not possible due to integration issues with Neutron, these parameters can be"},{"line_number":271,"context_line":"set globally on the IGMP application. Additionally, the Dragonflow and the IGMP"},{"line_number":272,"context_line":"application can verify that these values are legal and consistent."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_0d946435","line":269,"updated":"2016-02-19 16:32:54.000000000","message":"You are now writing a spec for Dragonflow, how the API looks like in Neutron is for another patch.\n\nOf course we want this to be configurable from Neutron, but lets stick with how we define it in Dragonflow.\n\nPersonally i want to see less configuration files and more configuration done in our DB.\nIts updates better, its easier to manage and orchestrate and deploy.\n\nPlease add the IGMP Configuration Table specification and all the timers/configuration that are needed, it can be a list.\nAlso how we define this in Dragonflow model (changes needed to Lrouter or Lswitch? )","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"04ab3783e41dd72b26ff40b4adad0a7e64c7f613","unresolved":false,"context_lines":[{"line_number":266,"context_line":"API for this configuration."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"The IGMPv3 standard defines timers and counters that can be configured. These"},{"line_number":269,"context_line":"configuration parameters can be defined on each switch or router. In case this"},{"line_number":270,"context_line":"is not possible due to integration issues with Neutron, these parameters can be"},{"line_number":271,"context_line":"set globally on the IGMP application. Additionally, the Dragonflow and the IGMP"},{"line_number":272,"context_line":"application can verify that these values are legal and consistent."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_49b46ed0","line":269,"in_reply_to":"bae84128_0d946435","updated":"2016-02-21 15:16:40.000000000","message":"Will do.\nWhere should I suggest the changes to Neutron DB?","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":16983,"name":"Eshed Gal-Or","email":"eshed.galor@huawei.com","username":"eshedg"},"change_message_id":"8ef0a70d7b2a5e141b707a58ed74b11da84c1155","unresolved":false,"context_lines":[{"line_number":273,"context_line":""},{"line_number":274,"context_line":"OVS multicast snooping"},{"line_number":275,"context_line":"----------------------"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"OVS has support for multicast snooping. This means that it sniffs IGMP packets"},{"line_number":278,"context_line":"on the network, and can automatically avoid sending multicast packets to VMs"},{"line_number":279,"context_line":"that do not require it on OVS ports[2]. However, it does not support sending"}],"source_content_type":"text/x-rst","patch_set":4,"id":"dae33548_abc9fe27","line":276,"updated":"2016-02-18 22:00:39.000000000","message":"I am not sure why this section exists... is it just as an acknowledgement to the OVS MC-snooping functionality?","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"04ab3783e41dd72b26ff40b4adad0a7e64c7f613","unresolved":false,"context_lines":[{"line_number":273,"context_line":""},{"line_number":274,"context_line":"OVS multicast snooping"},{"line_number":275,"context_line":"----------------------"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"OVS has support for multicast snooping. This means that it sniffs IGMP packets"},{"line_number":278,"context_line":"on the network, and can automatically avoid sending multicast packets to VMs"},{"line_number":279,"context_line":"that do not require it on OVS ports[2]. However, it does not support sending"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_69b172e1","line":276,"in_reply_to":"dae33548_abc9fe27","updated":"2016-02-21 15:16:40.000000000","message":"Yes.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"628effe63992732a82fc025c53f5e701f270346d","unresolved":false,"context_lines":[{"line_number":277,"context_line":"OVS has support for multicast snooping. This means that it sniffs IGMP packets"},{"line_number":278,"context_line":"on the network, and can automatically avoid sending multicast packets to VMs"},{"line_number":279,"context_line":"that do not require it on OVS ports[2]. However, it does not support sending"},{"line_number":280,"context_line":"IGMP queries, nor automatically forwarding multicast packets between subnets"},{"line_number":281,"context_line":"over virtual routers. This is the added value of this blueprint."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_edf2e099","line":280,"updated":"2016-02-19 16:32:54.000000000","message":"I havent seen any section about the physical world, how we map between these virtual overlay multicast packets to potential physical network IP multicast packets.\n(Also done for broadcast)\nI think this is the real value that we can show here and we need this described in detail\n(If you think its too much for this spec we can think about splitting these to two parts)","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"04ab3783e41dd72b26ff40b4adad0a7e64c7f613","unresolved":false,"context_lines":[{"line_number":277,"context_line":"OVS has support for multicast snooping. This means that it sniffs IGMP packets"},{"line_number":278,"context_line":"on the network, and can automatically avoid sending multicast packets to VMs"},{"line_number":279,"context_line":"that do not require it on OVS ports[2]. However, it does not support sending"},{"line_number":280,"context_line":"IGMP queries, nor automatically forwarding multicast packets between subnets"},{"line_number":281,"context_line":"over virtual routers. This is the added value of this blueprint."},{"line_number":282,"context_line":""},{"line_number":283,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bae84128_09ba66c0","line":280,"in_reply_to":"bae84128_edf2e099","updated":"2016-02-21 15:16:40.000000000","message":"Will be handled in another spec.","commit_id":"55062836ac982388bf595d225ac6b3312ace6f24"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"348bcaf0b6e197ac68bf1ed712d741114cb308c3","unresolved":false,"context_lines":[{"line_number":148,"context_line":"::"},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"  match\u003dip_dst\u003d224.0.0.x actions\u003doutput:VM1,output:VM2,output:VM3"},{"line_number":151,"context_line":"  match\u003dip_dst\u003d224.0.0.y actions\u003doutput:VM1,output:ComputeNode2"},{"line_number":152,"context_line":"        (via logical tunnel port)"},{"line_number":153,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src!\u003d10.0.0.100 actions\u003doutput:VM2"},{"line_number":154,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src\u003d\u003d10.0.0.100 actions\u003doutput:VM3"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bae84128_605fb541","line":151,"updated":"2016-02-22 06:52:59.000000000","message":"We need to consider using special tunnel_ids for managing this instead of re-classifying the traffic with IPs\n\nWe should also consider how this whole is working with the other pipeline, like security groups which is still not clear.\n\nAs commented in the previous patch it will be good to see how the pipeline looks with these new tables","commit_id":"635f031a341ef441145fa0cf85854334b7f4e794"},{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"f240a02330cc516fc6c6797b209f92db4d0097b3","unresolved":false,"context_lines":[{"line_number":148,"context_line":"::"},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"  match\u003dip_dst\u003d224.0.0.x actions\u003doutput:VM1,output:VM2,output:VM3"},{"line_number":151,"context_line":"  match\u003dip_dst\u003d224.0.0.y actions\u003doutput:VM1,output:ComputeNode2"},{"line_number":152,"context_line":"        (via logical tunnel port)"},{"line_number":153,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src!\u003d10.0.0.100 actions\u003doutput:VM2"},{"line_number":154,"context_line":"  match\u003dip_dst\u003d224.0.0.z,ip_src\u003d\u003d10.0.0.100 actions\u003doutput:VM3"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bae84128_97c83a24","line":151,"in_reply_to":"bae84128_605fb541","updated":"2016-02-22 08:38:23.000000000","message":"The IPs in this case are the multicast groups. Why do we need tunnel ids?\n\nThe multicast app \u0027hijacks\u0027 the MCPs from the classification table. The only other app we need is security groups, so we need to make sure they play well together. I\u0027ll add that.","commit_id":"635f031a341ef441145fa0cf85854334b7f4e794"}]}