Hi Jesse and Ben, Do you have some time to help us with our question how to cleanly model push and pop actions for NSH and outer Ethernet headers in OVS (see http://openvswitch.org/pipermail/dev/2016-August/077792.html for the original post).
We would really like to have this resolved before we submit the next version of the patch. As it affects the north-bound interface of OVS for NSH, we should have this agreed and frozen as soon as possible. Thanks, Jan > -----Original Message----- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jan Scheurich > Sent: Wednesday, 24 August, 2016 11:12 > > > From: Jesse Gross [mailto:je...@kernel.org] > > Sent: Wednesday, 24 August, 2016 04:48 > > > > >> I'm still not enthusiastic about having a combined push > > >> NSH/Ethernet action. I don't think that it even really supports the > > >> full NSH use case since at least some of the patches sent are not > > >> using VXLAN-GPE but directly insert the header over Ethernet. I > > >> wouldn't want to introduce an action that would immediately need to > > >> be replaced > > since we won't be able to change any of the public interface semantics once > > this goes in. > > > > > > I'm not enthusiastic either, but I think we should not block support > > > for NSH until the packet-type aware pipeline is finally > > implemented in OVS. One way of stressing the monolithic nature of > > these actions could be to call them "push/pop_nsh_eth". That would leave > > the names push/pop_nsh and push/pop_eth available for > a modular actions in the future. > > > > Ben mentioned that he had some comments on the "OVS philosophy" here > > vs. OpenFlow, so that might affect things. Hopefully it will end up > > simplifying things somewhat. > > It would be really good to get Ben's input here! > Perhaps I am looking at the problem too strictly from an OpenFlow perspective. > > > > > As I think you can tell, I really want to avoid situations where we > > don't do the right thing simply because of the time needed to > > implement it - this is particularly true where the change is user-visible > > and we'll have to live with the wart forever. I think there's > been an unfortunate amount of that with the NSH patchset in the past, so > let's see if we can find a clean way to handle this. > > I would love to see proposals for a clean way to model and implement this. > The patches that I have seen are clearly not good enough. > > Thanks, Jan > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
