)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e4173c70da44053666a2554210b9a5f7e6f5381","unresolved":false,"context_lines":[{"line_number":14,"context_line":"    vlan_tci\u003d0x0000/0x1fff"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"in rule match and this"},{"line_number":17,"context_line":"works fine for frames without a dot1q tag."},{"line_number":18,"context_line":"According to openvswitch manual [1], we should set vlan_tci with"},{"line_number":19,"context_line":"mask that will wildcard TCI bit to allow match also for dot1q"},{"line_number":20,"context_line":"tagged frames on VLAN 0, e.g. it COP is modified, and VLAN ID is 0."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"3f79a3b5_330fc938","line":17,"range":{"start_line":17,"start_character":0,"end_line":17,"end_character":42},"updated":"2018-10-30 10:26:13.000000000","message":"this is correct.\nml2/ovs does not support vlan\ntransparnacy. \n\nit is not valid for a dot1q tagged\npacket to be recived from a tor on a neutron flat network implemented with ovs. in fact this is stated several time in our docs not just for ovs.\n\nhttps://github.com/openstack/neutron/search?q\u003duntagged+%28flat%29\u0026unscoped_q\u003duntagged+%28flat%29\n\nthe most important one however is this \n\nhttps://github.com/openstack/neutron/blob/a388701ddfe628e9a5bd16a78422164799b11ef8/doc/source/admin/archives/adv-features.rst#terminology\n\n\"A virtual network implemented as packets on a specific physical network containing no IEEE 802.1Q header. Each physical network can realize at most one flat network.\"\n\nfrom reading the reporducer comments again in deatil in the down stream bug in particalar comments 9 and 10\nhttps://bugzilla.redhat.com/show_bug.cgi?id\u003d1635909#c9\nhttps://bugzilla.redhat.com/show_bug.cgi?id\u003d1635909#c10\n\ni am more or less convinced that the TOR switch was not correctly striping the vlan tag before transmitting the packet to the compute node. that is the only why ovs could be failing on this rule as for that rule to fail it would require a 802.1Q  header to be present on the packet.\n\nif a customer want to apply vlan based qos to a neutron flat network the should be configuring the switch prot either as a acess port to a singel vlan or as a trunk if the port is used for neutron vlan networks.\n\nin both acess and trunk configurtion the tor chould be set to encapulate the unttaged traffic onto a private vlan outside of the neutorn controled range and the qos policy should be applied to that vlan. \n\nthis will cause the switch tag and untagged traffic coming form the compute node corresponding to the flat network and will cause the switch to strip the vlan tag before sending it to a compute node therefore complying with our flat network requirement that no 802.1q header be present.\nwithing the core network the manually assigend vlan prioity can be used by the operator for qos.","commit_id":"e58e480f2a12bab524109f432d1afc6459eb4e4c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e4173c70da44053666a2554210b9a5f7e6f5381","unresolved":false,"context_lines":[{"line_number":22,"context_line":"To fix that, this patch changes openflow rule created for such"},{"line_number":23,"context_line":"networks in br-int to use:"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"    vlan_tci \u003d 0x0000/0x0fff"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"which means that DCI bit is wildcarde in rule match."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"3f79a3b5_6ea0faa4","line":25,"range":{"start_line":25,"start_character":4,"end_line":25,"end_character":28},"updated":"2018-10-30 10:26:13.000000000","message":"the current behavior is not an oversight it is the correct behavior. this would allow packets to be recived that are out of contract to be transmitted on a neutron flat network.\n\nAllowing such traffic to work with ovs nodes may result in connectivity issue instances connected to linux bridge or sriov interfaces as they may be less tollerant of processing traffic that is ment to have no vlan header but actully has a vlan hearder with a vid of 0 as these are phyically different on the wire and should not be assuemd to be the same.\n\nit is true that the 802.1q spec reserves vlan 0 as having a special meaning of a header that carries only priority infomation but unless we change the definition of a flat network to allow that it is currently invalid to use priority tags with flat networks.\n\ni would assume such a change would not be valid to do in a bug as it changes the semantic meaning of an api value and places additional implementation burden on all other flat network implementations.","commit_id":"e58e480f2a12bab524109f432d1afc6459eb4e4c"}]}