Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-17 Thread Yang, Yi Y
l.com> Cc: ovs dev <d...@openvswitch.org>; Pablo Neira Ayuso <pa...@netfilter.org>; Harald Welte <lafo...@gnumonks.org> Subject: RE: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath Yi, so what you are saying is that for the third use case (GTP-u processing w/o terminat

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-17 Thread Jan Scheurich
er.ijntema@gmail.com> > Cc: ovs dev <d...@openvswitch.org>; Pablo Neira Ayuso <pa...@netfilter.org>; > Harald Welte <lafo...@gnumonks.org> > Subject: RE: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath > > Jan, for the use case you mentioned

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-17 Thread Yang, Yi Y
witch.org>; Pablo Neira Ayuso <pa...@netfilter.org>; Harald Welte <lafo...@gnumonks.org> Subject: Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath These are indeed two different use case. The pure termination of the GTP-u tunnel can be done by adding su

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-17 Thread Jan Scheurich
witch.org] On Behalf Of Amar Padmanabhan > Sent: Friday, 14 July, 2017 19:23 > To: Joe Stringer <j...@ovn.org>; Wieger IJntema <wieger.ijntema@gmail.com> > Cc: ovs dev <d...@openvswitch.org>; Harald Welte <lafo...@gnumonks.org>; > Pablo Neira Ayuso <pa...@netfi

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-14 Thread Amar Padmanabhan
Yeah, we are looking at tunnel termination in OVS, i.e. GGSN or PGW. I think what you mention Weiger is about an on-path device that also does some classification like some of the 5G proposals. I think Yi is also looking at it but that is not directly related to this patch set. - Amar On

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-14 Thread Joe Stringer
On 14 July 2017 at 04:53, Wieger IJntema wrote: >> ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \ >> ofport_request=2 type=gtp option:remote_ip=flow options:key=flow >> >> ovs-ofctl add-flow br0 >> "in_port=2,tun_src=192.168.60.141,tun_id=123,

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-14 Thread Joe Stringer
On 13 July 2017 at 18:38, Jiannan Ouyang wrote: > Hi Joe, > >> It's neat to see new tunnel implementations being introduced, and also >> quite cool that it doesn't require significant code changes to OVS to >> make this happen. Thanks for looking into this :-) > > Thanks :) > >> I

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-14 Thread Wieger IJntema
> > ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \ > ofport_request=2 type=gtp option:remote_ip=flow options:key=flow > > ovs-ofctl add-flow br0 > "in_port=2,tun_src=192.168.60.141,tun_id=123, \ > actions=set_field:02:00:00:00:00:00->eth_src, \ >

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-13 Thread Jiannan Ouyang
Hi Joe, > It's neat to see new tunnel implementations being introduced, and also > quite cool that it doesn't require significant code changes to OVS to > make this happen. Thanks for looking into this :-) Thanks :) > I mentioned on the netdev thread that we should work towards using the >

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

2017-07-13 Thread Joe Stringer
On 12 July 2017 at 17:45, Jiannan Ouyang wrote: > This patch series depends on the Linux net-next patch set > [PATCH net-next] Flow Based GTP Tunneling > > With flow based GTP tunneling supported in the upstream datapath, we can > create a gtp vport associated with a flow based