:24 PM
> To: Amar Padmanabhan ; Joe Stringer
> ; Wieger IJntema
> Cc: ovs dev ; Pablo Neira Ayuso
> ; Harald Welte
> 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
&g
han ; Joe Stringer ;
> Wieger IJntema
> Cc: ovs dev ; Pablo Neira Ayuso ;
> Harald Welte
> 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 b
switch.org
> [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Amar Padmanabhan
> Sent: Friday, 14 July, 2017 19:23
> To: Joe Stringer ; Wieger IJntema
>
> Cc: ovs dev ; Harald Welte
> ; Pablo Neira Ayuso
> Subject: Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream
> d
switch.org] On Behalf Of Amar Padmanabhan
> Sent: Friday, 14 July, 2017 19:23
> To: Joe Stringer ; Wieger IJntema
> Cc: ovs dev ; Harald Welte ;
> Pablo Neira Ayuso
> Subject: Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath
>
> Yeah, we are looking at t
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 7/14/1
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, \
>> actions=set_field:02:0
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 mentioned on the
>
> 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, \
> set_field:ff:ff:ff:ff
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
> rtnet
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 GTP net_device. Thi
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 GTP net_device. This
allows us to program GTP tunnels via ovs-vsctl.
Example
11 matches
Mail list logo
