[{"id":1771992,"web_url":"http://patchwork.ozlabs.org/comment/1771992/","msgid":"","list_archive_url":null,"date":"2017-09-20T15:27:52","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":66668,"url":"http://patchwork.ozlabs.org/api/people/66668/","name":"Andreas Schultz","email":"aschultz@tpip.net"},"content":"On 19/09/17 02:38, Tom Herbert wrote:\n> Add new configuration of GTP interfaces that allow specifying a port to\n> listen on (as opposed to having to get sockets from a userspace control\n> plane). This allows GTP interfaces to be configured and the data path\n> tested without requiring a GTP-C daemon.\n\nThis would imply that you can have multiple independent GTP sockets on \nthe same IP address.That is not permitted by the GTP specifications. \n3GPP TS 29.281, section 4.3 states clearly that there is \"only\" one GTP \nentity per IP address.A PDP context is defined by the destination IP and \nthe TEID. The destination port is not part of the identity of a PDP context.\n\nEven the source IP and source port are not part of the tunnel identity. \nThis makes is possible to send traffic from a new SGSN/SGW during \nhandover before the control protocol has announced the handover.\n\nAt this point the usual response is: THAT IS NOT SAFE. Yes, GTP has been \ndesigned for cooperative networks only and should not be used on \nhostile/unsecured networks.\n\nOn the sending side, using multiple ports is permitted as long as the \ndefault GTP port is always able to receive incoming messages.\n\nAndreas\n\n[...]","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xy3lF6QLcz9s8J\n\tfor ;\n\tThu, 21 Sep 2017 01:37:13 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751900AbdITPhK (ORCPT );\n\tWed, 20 Sep 2017 11:37:10 -0400","from mail.tpip.net ([92.43.49.48]:59151 \"EHLO mail.tpip.net\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751697AbdITPhK (ORCPT );\n\tWed, 20 Sep 2017 11:37:10 -0400","from office.tpip.net (unknown [153.92.65.89])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mail.tpip.net (Postfix) with ESMTPS id 15EDA4F406;\n\tWed, 20 Sep 2017 15:27:54 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby office.tpip.net (Postfix) with ESMTP id B6C1FA318D;\n\tWed, 20 Sep 2017 17:27:53 +0200 (CEST)","from office.tpip.net ([127.0.0.1])\n\tby localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10032)\n\twith ESMTP id 0KObQsC3vLXt; Wed, 20 Sep 2017 17:27:53 +0200 (CEST)","from localhost (localhost [127.0.0.1])\n\tby office.tpip.net (Postfix) with ESMTP id 65E8FA318E;\n\tWed, 20 Sep 2017 17:27:53 +0200 (CEST)","from office.tpip.net ([127.0.0.1])\n\tby localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10026)\n\twith ESMTP id RU6JxlPwv5tj; Wed, 20 Sep 2017 17:27:53 +0200 (CEST)","from [192.168.13.82] (pd95c9392.dip0.t-ipconnect.de\n\t[217.92.147.146])\n\tby office.tpip.net (Postfix) with ESMTPSA id 095EFA318D;\n\tWed, 20 Sep 2017 17:27:52 +0200 (CEST)"],"X-Virus-Scanned":"amavisd-new at tpip.net","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","To":"Tom Herbert , davem@davemloft.net","Cc":"netdev@vger.kernel.org, pablo@netfilter.org, laforge@gnumonks.org,\n\trohit@quantonium.net","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>","From":"Andreas Schultz ","Message-ID":"","Date":"Wed, 20 Sep 2017 17:27:52 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170919003904.5124-10-tom@quantonium.net>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772017,"web_url":"http://patchwork.ozlabs.org/comment/1772017/","msgid":"","list_archive_url":null,"date":"2017-09-20T15:57:26","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":65986,"url":"http://patchwork.ozlabs.org/api/people/65986/","name":"Tom Herbert","email":"tom@herbertland.com"},"content":"On Wed, Sep 20, 2017 at 8:27 AM, Andreas Schultz wrote:\n> On 19/09/17 02:38, Tom Herbert wrote:\n>>\n>> Add new configuration of GTP interfaces that allow specifying a port to\n>> listen on (as opposed to having to get sockets from a userspace control\n>> plane). This allows GTP interfaces to be configured and the data path\n>> tested without requiring a GTP-C daemon.\n>\n>\n> This would imply that you can have multiple independent GTP sockets on the\n> same IP address.That is not permitted by the GTP specifications. 3GPP TS\n> 29.281, section 4.3 states clearly that there is \"only\" one GTP entity per\n> IP address.A PDP context is defined by the destination IP and the TEID. The\n> destination port is not part of the identity of a PDP context.\n>\nWe are in no way trying change GTP, if someone runs this in a real GTP\nnetwork then they need to abide by the specification. However, there\nis nothing inconsistent and it breaks nothing if someone wishes to use\ndifferent port numbers in their own private network for testing or\ndevelopment purposes. Every other UDP application that has assigned\nport number allows configurable ports, I don't see that GTP is so\nspecial that it should be an exception.\n\nTom","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=herbertland-com.20150623.gappssmtp.com\n\theader.i=@herbertland-com.20150623.gappssmtp.com\n\theader.b=\"k7FkduR0\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xy4Bf5KlHz9s7c\n\tfor ;\n\tThu, 21 Sep 2017 01:57:30 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751646AbdITP52 (ORCPT );\n\tWed, 20 Sep 2017 11:57:28 -0400","from mail-qk0-f179.google.com ([209.85.220.179]:55752 \"EHLO\n\tmail-qk0-f179.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751581AbdITP51 (ORCPT\n\t); Wed, 20 Sep 2017 11:57:27 -0400","by mail-qk0-f179.google.com with SMTP id q8so1295985qkl.12\n\tfor ; Wed, 20 Sep 2017 08:57:27 -0700 (PDT)","by 10.237.61.196 with HTTP; Wed, 20 Sep 2017 08:57:26 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=herbertland-com.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=TVGoFxHiXTYaR9g6nHLSbs1rvCCp+8IDU23HdwPYRRY=;\n\tb=k7FkduR0u3pVBjIcnNvCfz3/n6Nc277BmI/6LImyvLU/XXPCNuM1iJvcKwMa8T5Uq4\n\tuCvtYEb3b0AbC/Qzp4dVXWnUD/3MPcIoTuYuNUGHKodUInwSYvppkm7dfOovQdYOfIEg\n\tZEQ/YFZysc+8YqZIg/lLx5gBQRnB/eWWV5sfOYVcXqFbt8tgNw98TCaYjrTZ9L326Ji6\n\tAJ52I9KIB25rv0hc6+s6admI+jz+IVP7GL9tQZKfp49yJ/JuikVoDPwahjGcAhpUvRD5\n\tATGOBA4iT0M1hS0hPMLa7qKub9/9qO5pXe1k3FX9oeXCR7BreX2tXy4TS7uSRu/UqCj/\n\tLjyw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=TVGoFxHiXTYaR9g6nHLSbs1rvCCp+8IDU23HdwPYRRY=;\n\tb=AZ1ucYdboQtRTxGJWY0Yx/dAG6kFQVGsETiXtsiBUYmTOV3ls6MwOrus5NY/wwjgNO\n\tacu/K9XO3Np6tR1kTZiLweSpOskFWKNEk/pfljUBipRh3Olf9KoF3ZE9Fr+NyQyxUYQT\n\tzA6KP5Tx+msbQAO0ogCKw5AJsmFSmjLdnmBe+Zo0c58T94Ky4435N1oS1ylltJMiTRkH\n\t3ejASXaBfJ4WdHPDpNChDUjNRUZQy2tz/elqmJ0VMyx+8K7Nucd6XAI+15cDgyR/xPIS\n\tbVcuPkvrWuK3AYhyUHot/wQbln9yCz0Gq89rbkcs87mNg5MOH//zwgOqP8CFYTSecSLh\n\tp5tQ==","X-Gm-Message-State":"AHPjjUgG4ge+FwqWfnSKoXhWvgNGZWaCuwp09owsiDa2ym3qyXG8Suep\n\t4xWf0KQ+t6PTqJzB+kNy0gooJ9npD1/2px8IKVq2zQ==","X-Google-Smtp-Source":"AOwi7QCKXvgV8dgxLmgYMzo6y1gwXEY2Id9Rp6A05eBI9xur2lusT/Eovs7SaFm2K98cmfLBi2/DROI1WxPFrMdZAQo=","X-Received":"by 10.55.109.131 with SMTP id i125mr7501451qkc.17.1505923046688; \n\tWed, 20 Sep 2017 08:57:26 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>\n\t","From":"Tom Herbert ","Date":"Wed, 20 Sep 2017 08:57:26 -0700","Message-ID":"","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","To":"Andreas Schultz ","Cc":"Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tHarald Welte , Rohit Seth ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772025,"web_url":"http://patchwork.ozlabs.org/comment/1772025/","msgid":"<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>","list_archive_url":null,"date":"2017-09-20T16:07:49","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":66668,"url":"http://patchwork.ozlabs.org/api/people/66668/","name":"Andreas Schultz","email":"aschultz@tpip.net"},"content":"On 20/09/17 17:57, Tom Herbert wrote:\n> On Wed, Sep 20, 2017 at 8:27 AM, Andreas Schultz wrote:\n>> On 19/09/17 02:38, Tom Herbert wrote:\n>>>\n>>> Add new configuration of GTP interfaces that allow specifying a port to\n>>> listen on (as opposed to having to get sockets from a userspace control\n>>> plane). This allows GTP interfaces to be configured and the data path\n>>> tested without requiring a GTP-C daemon.\n>>\n>>\n>> This would imply that you can have multiple independent GTP sockets on the\n>> same IP address.That is not permitted by the GTP specifications. 3GPP TS\n>> 29.281, section 4.3 states clearly that there is \"only\" one GTP entity per\n>> IP address.A PDP context is defined by the destination IP and the TEID. The\n>> destination port is not part of the identity of a PDP context.\n>>\n> We are in no way trying change GTP, if someone runs this in a real GTP\n> network then they need to abide by the specification. However, there\n> is nothing inconsistent and it breaks nothing if someone wishes to use\n> different port numbers in their own private network for testing or\n> development purposes. Every other UDP application that has assigned\n> port number allows configurable ports, I don't see that GTP is so\n> special that it should be an exception.\n\nGTP isn't special, I just don't like to have testing only features in \nthere when the same goal can be reached without having to add extra \nstuff. Adding code that is not going to be useful in real production \nsetups (or in this case would even break production setups when enabled \naccidentally) makes the implementation more complex than it needs to be.\n\nYou can always add multiple IP's to your test system and have the same \neffect without having to change the ports.\n\nRegards\nAndreas\n\n> \n> Tom\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xy4Qg2yVsz9s7c\n\tfor ;\n\tThu, 21 Sep 2017 02:07:55 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751499AbdITQHx (ORCPT );\n\tWed, 20 Sep 2017 12:07:53 -0400","from mail.tpip.net ([92.43.49.48]:37948 \"EHLO mail.tpip.net\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751581AbdITQHv (ORCPT );\n\tWed, 20 Sep 2017 12:07:51 -0400","from office.tpip.net (unknown [153.92.65.89])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mail.tpip.net (Postfix) with ESMTPS id 9A8564F406;\n\tWed, 20 Sep 2017 16:07:50 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n\tby office.tpip.net (Postfix) with ESMTP id 6DA93A318D;\n\tWed, 20 Sep 2017 18:07:50 +0200 (CEST)","from office.tpip.net ([127.0.0.1])\n\tby localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10032)\n\twith ESMTP id W4RTL2mTPUPJ; Wed, 20 Sep 2017 18:07:50 +0200 (CEST)","from localhost (localhost [127.0.0.1])\n\tby office.tpip.net (Postfix) with ESMTP id F2DC8A318E;\n\tWed, 20 Sep 2017 18:07:49 +0200 (CEST)","from office.tpip.net ([127.0.0.1])\n\tby localhost (office.tpip.net [127.0.0.1]) (amavisd-new, port 10026)\n\twith ESMTP id 6kJ4SHnGiB2M; Wed, 20 Sep 2017 18:07:49 +0200 (CEST)","from [192.168.13.82] (pd95c9392.dip0.t-ipconnect.de\n\t[217.92.147.146])\n\tby office.tpip.net (Postfix) with ESMTPSA id 92FF3A318D;\n\tWed, 20 Sep 2017 18:07:49 +0200 (CEST)"],"X-Virus-Scanned":"amavisd-new at tpip.net","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","To":"Tom Herbert ","Cc":"Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tHarald Welte , Rohit Seth ","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>\n\t\n\t","From":"Andreas Schultz ","Message-ID":"<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>","Date":"Wed, 20 Sep 2017 18:07:49 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772042,"web_url":"http://patchwork.ozlabs.org/comment/1772042/","msgid":"","list_archive_url":null,"date":"2017-09-20T16:24:07","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":72064,"url":"http://patchwork.ozlabs.org/api/people/72064/","name":"Tom Herbert","email":"tom@quantonium.net"},"content":"On Wed, Sep 20, 2017 at 9:07 AM, Andreas Schultz wrote:\n>\n>\n> On 20/09/17 17:57, Tom Herbert wrote:\n>>\n>> On Wed, Sep 20, 2017 at 8:27 AM, Andreas Schultz \n>> wrote:\n>>>\n>>> On 19/09/17 02:38, Tom Herbert wrote:\n>>>>\n>>>>\n>>>> Add new configuration of GTP interfaces that allow specifying a port to\n>>>> listen on (as opposed to having to get sockets from a userspace control\n>>>> plane). This allows GTP interfaces to be configured and the data path\n>>>> tested without requiring a GTP-C daemon.\n>>>\n>>>\n>>>\n>>> This would imply that you can have multiple independent GTP sockets on\n>>> the\n>>> same IP address.That is not permitted by the GTP specifications. 3GPP TS\n>>> 29.281, section 4.3 states clearly that there is \"only\" one GTP entity\n>>> per\n>>> IP address.A PDP context is defined by the destination IP and the TEID.\n>>> The\n>>> destination port is not part of the identity of a PDP context.\n>>>\n>> We are in no way trying change GTP, if someone runs this in a real GTP\n>> network then they need to abide by the specification. However, there\n>> is nothing inconsistent and it breaks nothing if someone wishes to use\n>> different port numbers in their own private network for testing or\n>> development purposes. Every other UDP application that has assigned\n>> port number allows configurable ports, I don't see that GTP is so\n>> special that it should be an exception.\n>\n>\n> GTP isn't special, I just don't like to have testing only features in there\n> when the same goal can be reached without having to add extra stuff. Adding\n> code that is not going to be useful in real production setups (or in this\n> case would even break production setups when enabled accidentally) makes the\n> implementation more complex than it needs to be.\n\nWell, you could make the same argument that allowing GTP to configured\nas standalone interface is a problem since GTP is only allowed to be\nwith used with GTP-C. But, then we have something in the kernel that\nthe community is expected to support, but requires jumping through a\nwhole bunch of hoops just to run a simple netperf. The more that\npatches and features look like other things in the kernel that are\nalready well established, the better the chances we can accept them\nand support them. It's probably a natural consequence of any large\nopen source project, so sometimes it's worth the effort to add a few\nlines of complexity to get the benefits of community contribution and\nsupport.\n\nTom","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=quantonium-net.20150623.gappssmtp.com\n\theader.i=@quantonium-net.20150623.gappssmtp.com\n\theader.b=\"AiMhA2B1\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xy4nS1d6pz9sPt\n\tfor ;\n\tThu, 21 Sep 2017 02:24:12 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751709AbdITQYK (ORCPT );\n\tWed, 20 Sep 2017 12:24:10 -0400","from mail-wm0-f54.google.com ([74.125.82.54]:46974 \"EHLO\n\tmail-wm0-f54.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751499AbdITQYJ (ORCPT\n\t); Wed, 20 Sep 2017 12:24:09 -0400","by mail-wm0-f54.google.com with SMTP id i189so8786497wmf.1\n\tfor ; Wed, 20 Sep 2017 09:24:08 -0700 (PDT)","by 10.223.158.197 with HTTP; Wed, 20 Sep 2017 09:24:07 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=quantonium-net.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=D8QTqvN2LjlRb1ikBjmOms8Q/389yezKGw47bvb9nDg=;\n\tb=AiMhA2B1bQD+ijgLoyiJr0DecyRopjetnhlJs506Zos11wp0SK0k2f5uX6vqnDMGQv\n\t7HTE3GFUu0PKnTM7tloHT1sC1ODqxHtJCaUBCumCeRt9xTKe8E5ozmNLwwFJbkO5EwcK\n\tMD2ezNVSKhw9DapIuWEIU5XcSoLKIROzy6neTqBHwhdH28sxSgTa2lGdoWuGqoY9usI5\n\tr5T8vhHqYojRX3mQOVxGWDcldjMogDAlS0h4V/TXK0+IW5ckNOS4zov0eH8yWv71XST2\n\tGLPs2FVXjJOcZbU3s98iWRUR1tfD/43Bxg3DSYVaYUr5sWQg2Wj9rqolNsLQBR6tW6fu\n\tSEJw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=D8QTqvN2LjlRb1ikBjmOms8Q/389yezKGw47bvb9nDg=;\n\tb=CC1KY/CN/qCj62ZgFmo05zLIqBTIyw5xQGU2ZUZ08N77UU4cbyyEE3jw0XsRMmvPrh\n\tz0bBFZvhJBSHBnLj6GBvw3hcz+48XEIDuws5O2heipqpZb2QRGO0zDGIr6GN7hvFAR2R\n\tj9oQRYtL8+8yzxAUM+uBQ7xTYP4tEwxdZ9c5dgJCOb47h4P+JRBYqHvOsvScjeZeZsEK\n\tUHY2DqZLHGuj4hhZu8xU5pLe0RTkwM55OqYDSFBr796agPiXXvnMSap0fQnhV46VVZqW\n\tyofZnLxMZU83nsrWR40ym1IpsaJM4I6n6AFyGndTiU7Qz1oeg9LTOnjSPPSNBaiFthr2\n\tun0w==","X-Gm-Message-State":"AHPjjUiW8s6QIwW84TDlcAvc8mNnqXR59/7Gqa12bKSgWtuqeqQLWTR+\n\tgaU2KL8MqN62VVsvmDC+tq5B4twO3+SrkrcX9i1gFA==","X-Google-Smtp-Source":"AOwi7QBZTyIYarUmocNqHRSycl4swJkkeApWXikTXKzpQanMwvib5usIYkMEiBwNBgMmLyfX4eXRW33r1XYgpQVCSuY=","X-Received":"by 10.28.52.132 with SMTP id b126mr4531273wma.144.1505924647638; \n\tWed, 20 Sep 2017 09:24:07 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>\n\t\n\t\n\t<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>","From":"Tom Herbert ","Date":"Wed, 20 Sep 2017 09:24:07 -0700","Message-ID":"","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","To":"Andreas Schultz ","Cc":"Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tHarald Welte , Rohit Seth ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772324,"web_url":"http://patchwork.ozlabs.org/comment/1772324/","msgid":"<20170921001313.n2uo56oxmphcvd5g@nataraja>","list_archive_url":null,"date":"2017-09-21T00:13:13","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":931,"url":"http://patchwork.ozlabs.org/api/people/931/","name":"Harald Welte","email":"laforge@gnumonks.org"},"content":"Hi Tom,\n\nOn Wed, Sep 20, 2017 at 09:24:07AM -0700, Tom Herbert wrote:\n> On Wed, Sep 20, 2017 at 9:07 AM, Andreas Schultz wrote:\n> > GTP isn't special, I just don't like to have testing only features in there\n> > when the same goal can be reached without having to add extra stuff. Adding\n> > code that is not going to be useful in real production setups (or in this\n> > case would even break production setups when enabled accidentally) makes the\n> > implementation more complex than it needs to be.\n> \n> Well, you could make the same argument that allowing GTP to configured\n> as standalone interface is a problem since GTP is only allowed to be\n> with used with GTP-C. But, then we have something in the kernel that\n> the community is expected to support, but requires jumping through a\n> whole bunch of hoops just to run a simple netperf. \n\n\"A whole bunch of hoops\" without your new interface would consist of\nrunning a single command-line program that is supplied with libgtpnl.\nThis is not a complete 3GPP network, but a simple libmnl-based helper\nlibrary with no other depenencies.\n\nI'm not neccessarily against introducing features like the 'standalone\ninterface configuration'. However, we must make sure that any\nsignificant new feature contributions like IPv6 are tested in a\n\"realistic setup\" and not just using those 'interfaces added for easy\ndevelopment'. Also, I would argue those 'interfaces added for easy\ndeveopment/benchmarking' should probably be clearly marked as such to\navoid raising the impression that this is what leads to a\nstandard-conforming / production-type setup.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyHC66zg2z9sNr\n\tfor ;\n\tThu, 21 Sep 2017 10:13:38 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751858AbdIUANc (ORCPT );\n\tWed, 20 Sep 2017 20:13:32 -0400","from ganesha.gnumonks.org ([213.95.27.120]:32772 \"EHLO\n\tganesha.gnumonks.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751663AbdIUANa (ORCPT\n\t); Wed, 20 Sep 2017 20:13:30 -0400","from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dup7O-00022P-KY; Thu, 21 Sep 2017 02:13:26 +0200","from laforge by localhost.localdomain with local (Exim 4.89)\n\t(envelope-from )\n\tid 1dup7B-0003Ed-Df; Thu, 21 Sep 2017 08:13:13 +0800"],"Date":"Thu, 21 Sep 2017 08:13:13 +0800","From":"Harald Welte ","To":"Tom Herbert ","Cc":"Andreas Schultz , Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tRohit Seth ","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","Message-ID":"<20170921001313.n2uo56oxmphcvd5g@nataraja>","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>\n\t\n\t\n\t<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772340,"web_url":"http://patchwork.ozlabs.org/comment/1772340/","msgid":"","list_archive_url":null,"date":"2017-09-21T00:55:01","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":72064,"url":"http://patchwork.ozlabs.org/api/people/72064/","name":"Tom Herbert","email":"tom@quantonium.net"},"content":"On Wed, Sep 20, 2017 at 5:13 PM, Harald Welte wrote:\n> Hi Tom,\n>\n> On Wed, Sep 20, 2017 at 09:24:07AM -0700, Tom Herbert wrote:\n>> On Wed, Sep 20, 2017 at 9:07 AM, Andreas Schultz wrote:\n>> > GTP isn't special, I just don't like to have testing only features in there\n>> > when the same goal can be reached without having to add extra stuff. Adding\n>> > code that is not going to be useful in real production setups (or in this\n>> > case would even break production setups when enabled accidentally) makes the\n>> > implementation more complex than it needs to be.\n>>\n>> Well, you could make the same argument that allowing GTP to configured\n>> as standalone interface is a problem since GTP is only allowed to be\n>> with used with GTP-C. But, then we have something in the kernel that\n>> the community is expected to support, but requires jumping through a\n>> whole bunch of hoops just to run a simple netperf.\n>\n> \"A whole bunch of hoops\" without your new interface would consist of\n> running a single command-line program that is supplied with libgtpnl.\n> This is not a complete 3GPP network, but a simple libmnl-based helper\n> library with no other depenencies.\n>\nYou have the point of view of someone who has a lot of experience\ndealing with this protocol. Try to imagine if you were some random\nkernel network programmer with no experience in the area. If they\nhappen to find a one-off bug and want to do the right thing by running\na test, you want to make that as easy as possible. From that\nperspective, building protocol specific libraries and finding the\nright cmd line to run is significant hoops (I can attest to this).\nThere are other examples in the kernel of systems bigger than GTP that\nrequire a whole lot of effort just to run a simple test; you'll notice\nfor those it's rare that best developers ever bother to look at them\nunless they're making a global change that affects the code. We don't\nwant GTP to take be like that!\n\n> I'm not neccessarily against introducing features like the 'standalone\n> interface configuration'. However, we must make sure that any\n> significant new feature contributions like IPv6 are tested in a\n> \"realistic setup\" and not just using those 'interfaces added for easy\n> development'. Also, I would argue those 'interfaces added for easy\n> deveopment/benchmarking' should probably be clearly marked as such to\n> avoid raising the impression that this is what leads to a\n> standard-conforming / production-type setup.\n>\nGiven the obvious complexity of running a real GTP stack, I don't\nthink we have to worry about this. In order to test a \"realistic\nsetup\" a whole bunch of other support is needed. So the forward\nlooking question now is how to get to be able to run a \"realistic\nsetup\"?\n\nTom","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=quantonium-net.20150623.gappssmtp.com\n\theader.i=@quantonium-net.20150623.gappssmtp.com\n\theader.b=\"s0twlsEP\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyJ6y26Bwz9s0Z\n\tfor ;\n\tThu, 21 Sep 2017 10:55:06 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751879AbdIUAzE (ORCPT );\n\tWed, 20 Sep 2017 20:55:04 -0400","from mail-wr0-f179.google.com ([209.85.128.179]:49103 \"EHLO\n\tmail-wr0-f179.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751636AbdIUAzD (ORCPT\n\t); Wed, 20 Sep 2017 20:55:03 -0400","by mail-wr0-f179.google.com with SMTP id 108so3395031wra.5\n\tfor ; Wed, 20 Sep 2017 17:55:02 -0700 (PDT)","by 10.223.158.197 with HTTP; Wed, 20 Sep 2017 17:55:01 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=quantonium-net.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=1zmucwPz7pMj2i6B5Oj9oQxCvQNpKzsb74OMFtnZ7fc=;\n\tb=s0twlsEPz/CTI1IfvaZIQDX7Za+XipWrIvsoDIKMWvRsJUrH7sm6ec1AGTvs3p3Arp\n\tP6wWyIytFv6sEUcvyeogz9kuB6ffh0ND0FKMFdl0nPIL8v/IWXS4BdeJ182U9QB6NLyF\n\tckAt5Zlf01sBicjBRcMvqFYUV9/fn0evfOySetvGRjXShlXkNafqoXZ91Qn0jdvnwPIE\n\ttTF2uC7QIALz+zsLiiQwbm/flccU5SV1psmwMxSMHsBKpKAtLjAyq0c+DO7edpQP2Z7v\n\tsgF5I5lSM712N39jg/BO+1mNaw+UuHHfWlum6wvAOulH/QeJCo+WYhWcTWGGo5oYnEsT\n\tCG9w==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=1zmucwPz7pMj2i6B5Oj9oQxCvQNpKzsb74OMFtnZ7fc=;\n\tb=q+9OcudrMBc3vphp4Hz10KkXTnwJBWHvHzy8YpAzqd1WxFSkKXyfuOnwBgl3ChWht1\n\thl5/YSo4kjcGTBjQTjKnXtJ3LDWigOTE5Wqo5InV2glxuont3e48CHskkcWH8xYP5vGE\n\tbgmnvKXkG35gzTA/QEoaX/Z1ZdzOXUWO7t4TqtCa9tvWfRHgozA7bJbxgRQbeKfBHsOL\n\t//qvjnznnMzNPZLeZ/9OAyY0is2vKF7QlGfOwvaGioTzt4ys1WqoLL6rjYTNLFNervPr\n\tZYRbuAFVpPqNlIVfJm172NOkp6kwwdq2ATFcnxY+emShe0prwiOB3HH6RbQ9Xwy30sY2\n\tLbrg==","X-Gm-Message-State":"AHPjjUhuru3LP5cW32a6QfOd96YMli1FPbQrcLE8GR03wDO8fcsFIDwW\n\tWppl2veNCsstbL07FNX+kEDQf1yPsKnHjFzivUZVRw==","X-Google-Smtp-Source":"AOwi7QAWzqBHKf5Y25XcNi6S7kXdccUd3G+qwOQZVX+/Ae+JJDFr7zQhh97Gn7Phrp6B5nqPYFds9Q3pHKGSp6NY8Xc=","X-Received":"by 10.223.196.238 with SMTP id o43mr360892wrf.276.1505955302091; \n\tWed, 20 Sep 2017 17:55:02 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170921001313.n2uo56oxmphcvd5g@nataraja>","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>\n\t\n\t\n\t<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>\n\t\n\t<20170921001313.n2uo56oxmphcvd5g@nataraja>","From":"Tom Herbert ","Date":"Wed, 20 Sep 2017 17:55:01 -0700","Message-ID":"","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","To":"Harald Welte ","Cc":"Andreas Schultz , Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tRohit Seth ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772941,"web_url":"http://patchwork.ozlabs.org/comment/1772941/","msgid":"<20170921151253.4udm54dcq7x3ed4q@nataraja>","list_archive_url":null,"date":"2017-09-21T15:12:53","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":2169,"url":"http://patchwork.ozlabs.org/api/people/2169/","name":"Harald Welte","email":"laforge@netfilter.org"},"content":"Hi Tom,\n\nOn Wed, Sep 20, 2017 at 05:55:01PM -0700, Tom Herbert wrote:\n> You have the point of view of someone who has a lot of experience\n> dealing with this protocol. Try to imagine if you were some random\n> kernel network programmer with no experience in the area. If they\n> happen to find a one-off bug and want to do the right thing by running\n> a test, you want to make that as easy as possible. \n\nAgreed. But we're not talking abut fixing a random bug in your patch\nseries, but we're talking about adding significant new features - and\nthose features need to be tested in real use caes, not just in an\nartificial test setup that holds assumptions that are not true.\n\nTo improve performance, or to fix simple bugs that only affect the\nprocessing of the GTP-U G-PDU, a much more limited and hence\n\"unrealistic\" test scenario is probably sufficient/acceptable.\n\n> From that perspective, building protocol specific libraries and\n> finding the right cmd line to run is significant hoops (I can attest\n> to this).\n\nI understand your argument. But then, there is actually quite some\ntools to help you (see further below), as well as the wiki page at\nhttp://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing\n\nOf course, existing tools and existing wiki pages also only document\nexisting features of the kernel code :)\n\nYes, the documentation could be better. But then, how much more can you\nexpect from somebody who's doing this mostly for fun and who - despite\nworking in his dayjob on FOSS cellular projects - has no single\ncommercial project/context that uses the kernel GTP code.\n\nIn any case, working on a specific protocol or technology will require\nthat you understand that technology to some extent, including the\navailable tools. There's always a learning curve involved.\n\n> There are other examples in the kernel of systems bigger than GTP that\n> require a whole lot of effort just to run a simple test; you'll notice\n> for those it's rare that best developers ever bother to look at them\n> unless they're making a global change that affects the code. We don't\n> want GTP to take be like that!\n\nI'm all for following your argument. My point is simply: You cannot\ndevelop code solely based on mock-ups without any 'realistic' test\nscenarios. Otherwise you will end up with something that works only in\nyour artificial lab setup, and follows all the best practises of the way\nhow the Linux kernel traditionally approaches tunneling implementations,\nbut it will never work/interop in the real world.\n\nAnd I'm very strongly opposed to merging code where we have not been\nable to show that it will inter-operate in at least one realistic\nscenario. This would raise wrong expectations with users and all sorts\nof downstream problems.\n\nSo let's say we merge your IPv6 support as-is, and kernels get released\n+ shipped with it. Later on, we find that in order to turn it into a\nstandards-compliant implementation together with all the required bits\nin userspace and on the control plane, we need to change some parts of\nit, particularly those parts that affect the netlink or any other\nexposed userspace interface. At that point, we cannot change the\ninterface as the kernel has a strict rule of never breaking userspace\nABI. But we must change it in order to make it work in the real world.\nSo what do we do? Add lots of cruft in order to emulate backwards\ncompatibility?\n\n> So the forward looking question now is how to get to be able to run a\n> \"realistic setup\"?\n\nYou can run this realistic setup entirely using Osmocom components.\n\nFor running a 2G network: OsmoBTS+OsmoNITB+OsmoSGSN\nFor running a 3G network: OsmoHNBGW+OsmoMSC+OsmoHLR+OsmoSGSN\n\nBoth above stacks/combinations will provide you with GTP-C and GTP-U\nagainst a GGSN. As GGSN, you can then use either OpenGGSN, or OsmoGGSN,\nor ergw. For OpenGGSN and ergw, this will work with kernel GTP today,\nfor those features present in kernel GTP (i.e. IPv4-only).\n\nIn both cases you need some RF hardware. I'm happy to contribute\nrelated hardware (and support getting it set up) free of charge from my\ncompany sysmocom to anyone who has a realistic prospect of either\n* integrating your IPv6 support or other significant feature patches with\n libgtpnl + OsmoGGSN (at which point you can run a complete setup with\n real phones to verify it works end-to-end)\n* building and documenting or operating a continuous integration setup\n that would run tests on each new kernel version (or net-next, or\n whatever tree makes sense) to help us catch any regressions as the\n code proceeds\n\nIn order to have a smaller, but still realistic test scenario, I\nimplemented a series of GTP tests in\nhttp://git.osmocom.org/osmo-ttcn3-hacks/tree/ggsn_tests/GGSN_Tests.ttcn\n\nThis code basically emulates the combination of everything from Phone to\nSGSN, so that you have only two entities:\n* the implementation under test = IUT (a GGSN implementing GTP-C + GTP-U)\n* the test itself (GGSN_Test) executing against the IUT\n\nThe code so far implements PDP context activation + address allocation\nfor IPv4-only and IPv6-only cases and can be run against a GGSN\nimplementing those. The IPv6-only PDP context unit tests include the\nconvoluted two-phase address assignment including sending the router\nsolicitation from the simulated phone as well as verifying the router\nadvertisement sent in response from the GGSN.\n\nYes, I know they're written in an unknown niche programming language\ncalled TTCN-3, but this was the best tool at hand for the job I could\nfind, and the tests are open source as is the Eclipse Titan toolchain\nfor compiling it.\n\nWe even have a Dockerfile that will build you a docker container\ncontaining the compiled GGSN_test at\nhttp://git.osmocom.org/docker-playground/tree/ggsn-test\n\nThat docker container is used by a jenkins build test job to test\ncurrent OsmoGGSN master every night against the test suite.\n\nI was stupid enough to break the testsuite with an accidential commit,\nso tests between August 27th and today failed. I've just reverted that\naccident - don't let that mistake of mine mislead you.\n\nI'm happy to contribute further to this by adding actual user-IP GTP-U\nfunctional testing beyond the router soliciatation/advertisement to it.\n\nSo my suggestion in terms of a \"realistic testbed without having to\nconfigure + run dozens of programs and using real RF + phones\" is to use\nthat testsuite.\n\nWhat one cannot get around is having to implement support for new\nfeatures added on the kernel side such as IPv6 in libgtpnl and at least\none of the GGSN's using it, sorry. Without that, there is no way to\nknow if that code would do anything useful. You simply cannot\nrealistically test GTP-U alone without GTP-C.\n\nI'd love to offer help on this, but it's really impossible right now.\nI'm on holidays on a motorbike tour through rural Taiwan's mountains,\nhad to deal with a flat tire today, have limited connectivity and am\nalready cutting down hard on sleep every night to be able to respond to\nthe absolute minimally required work e-mails. And review/follow-up to\nyour much appreciated patch series the last couple of days has also used\na lot of (unexpected not scheduled for) time. I'm not complaining, I'm\njust saying I am really not able to contribute more to this effort right\nnow beyond my review, the offer of free hardware for a real cellular\nnetwork, and the extension of the test cases for GTP-U beyond the\nalready implemented very important IPv6 address allocation/assignment\nwhich I believe your current code would not pass.\n\nRegards,\n\tHarald","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xygl15YVxz9s7f\n\tfor ;\n\tFri, 22 Sep 2017 01:39:09 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751859AbdIUPjD (ORCPT );\n\tThu, 21 Sep 2017 11:39:03 -0400","from ganesha.gnumonks.org ([213.95.27.120]:39191 \"EHLO\n\tganesha.gnumonks.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751726AbdIUPjB (ORCPT\n\t); Thu, 21 Sep 2017 11:39:01 -0400","from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dv3Z1-0000Rk-Tc; Thu, 21 Sep 2017 17:38:56 +0200","from laforge by localhost.localdomain with local (Exim 4.89)\n\t(envelope-from )\n\tid 1dv39p-0005vW-KL; Thu, 21 Sep 2017 23:12:53 +0800"],"Date":"Thu, 21 Sep 2017 23:12:53 +0800","From":"Harald Welte ","To":"Tom Herbert ","Cc":"Andreas Schultz , Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tRohit Seth ","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","Message-ID":"<20170921151253.4udm54dcq7x3ed4q@nataraja>","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>\n\t\n\t\n\t<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>\n\t\n\t<20170921001313.n2uo56oxmphcvd5g@nataraja>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772984,"web_url":"http://patchwork.ozlabs.org/comment/1772984/","msgid":"","list_archive_url":null,"date":"2017-09-21T16:43:02","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":72064,"url":"http://patchwork.ozlabs.org/api/people/72064/","name":"Tom Herbert","email":"tom@quantonium.net"},"content":"On Thu, Sep 21, 2017 at 8:12 AM, Harald Welte wrote:\n> Hi Tom,\n>\n> On Wed, Sep 20, 2017 at 05:55:01PM -0700, Tom Herbert wrote:\n>> You have the point of view of someone who has a lot of experience\n>> dealing with this protocol. Try to imagine if you were some random\n>> kernel network programmer with no experience in the area. If they\n>> happen to find a one-off bug and want to do the right thing by running\n>> a test, you want to make that as easy as possible.\n>\n> Agreed. But we're not talking abut fixing a random bug in your patch\n> series, but we're talking about adding significant new features - and\n> those features need to be tested in real use caes, not just in an\n> artificial test setup that holds assumptions that are not true.\n>\n> To improve performance, or to fix simple bugs that only affect the\n> processing of the GTP-U G-PDU, a much more limited and hence\n> \"unrealistic\" test scenario is probably sufficient/acceptable.\n>\n>> From that perspective, building protocol specific libraries and\n>> finding the right cmd line to run is significant hoops (I can attest\n>> to this).\n>\n> I understand your argument. But then, there is actually quite some\n> tools to help you (see further below), as well as the wiki page at\n> http://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing\n>\n> Of course, existing tools and existing wiki pages also only document\n> existing features of the kernel code :)\n>\n> Yes, the documentation could be better. But then, how much more can you\n> expect from somebody who's doing this mostly for fun and who - despite\n> working in his dayjob on FOSS cellular projects - has no single\n> commercial project/context that uses the kernel GTP code.\n>\n> In any case, working on a specific protocol or technology will require\n> that you understand that technology to some extent, including the\n> available tools. There's always a learning curve involved.\n>\n>> There are other examples in the kernel of systems bigger than GTP that\n>> require a whole lot of effort just to run a simple test; you'll notice\n>> for those it's rare that best developers ever bother to look at them\n>> unless they're making a global change that affects the code. We don't\n>> want GTP to take be like that!\n>\n> I'm all for following your argument. My point is simply: You cannot\n> develop code solely based on mock-ups without any 'realistic' test\n> scenarios. Otherwise you will end up with something that works only in\n> your artificial lab setup, and follows all the best practises of the way\n> how the Linux kernel traditionally approaches tunneling implementations,\n> but it will never work/interop in the real world.\n>\n\n> And I'm very strongly opposed to merging code where we have not been\n> able to show that it will inter-operate in at least one realistic\n> scenario. This would raise wrong expectations with users and all sorts\n> of downstream problems.\n>\nHarald,\n\nPlease see the cover letter for the original GTP kernel patches dated\nMay 10, 2016. My first question on those was \"Is there a timeline for\nadding IPv6 support?\". To which Pablo replied that there was a\npreliminary patch for it that has not been released. That was almost a\nyear and half ago and we have not heard anything since. If you don't\nlike my patches or don't think that can be adapted to fully support\nthe GTP specification, that's fine. But then you need to provide a\nviable alternative. We are at the point where a kernel networking\nfeature that only supports IPv4 when it could support IPv6 must be\nconsidered incomplete.\n\nThanks,\nTom","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=quantonium-net.20150623.gappssmtp.com\n\theader.i=@quantonium-net.20150623.gappssmtp.com\n\theader.b=\"ZTS0sUsU\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyj920rJLz9s2G\n\tfor ;\n\tFri, 22 Sep 2017 02:43:18 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751780AbdIUQnQ (ORCPT );\n\tThu, 21 Sep 2017 12:43:16 -0400","from mail-wm0-f41.google.com ([74.125.82.41]:44531 \"EHLO\n\tmail-wm0-f41.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751602AbdIUQnF (ORCPT\n\t); Thu, 21 Sep 2017 12:43:05 -0400","by mail-wm0-f41.google.com with SMTP id m127so1632395wmm.1\n\tfor ; Thu, 21 Sep 2017 09:43:04 -0700 (PDT)","by 10.223.158.197 with HTTP; Thu, 21 Sep 2017 09:43:02 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=quantonium-net.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=tvoQfDmDQ3I8QNmzQtbe1usIasj3uaELOC2GZKCVW2A=;\n\tb=ZTS0sUsUCX9EVWJREqpQvQ3IXutAGE8iQiPiUETRpUK8cOkhUG1T3RTR0GgnIRAYc8\n\tdY/JV8tm5KNgqrCLO0XCjgyRnfNXH88AxUIUft+e5ulJNej+CAs6jxdGnYrASavvRSnZ\n\t0qKoz9lvSpCU7+IfcJctA0enYODip+1KlAwamRSQ1tjnFVHcelegkyItEicLKHDViyJn\n\t0ccWzX32ZIaanXtXm+EVF3PXcq2UwfyqMtwqZ/nO+3v/OWa+F6rKFIIE8r/zni/ioy2/\n\t7qLccLPG8vJrs2dkPJcQq0KLWrHxuW7PEdvH/Vt0XmXpVYYTQQQQbuclnSitv6U5aFYY\n\t5Xpg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=tvoQfDmDQ3I8QNmzQtbe1usIasj3uaELOC2GZKCVW2A=;\n\tb=PViMEqL8u6QsSYqB7tGFRGYpGgv1f2GaQxJrubH4iymgXkNXevU3HlLLJwyxRL2h0D\n\tGFM8H9YKEqN+Y13MeQyFuvIpJAtU9wE7Wi9tMAlvaotMIIlLVEmQsnZk1F9okhI9yI1q\n\tW1VPbiJ70d4RLxQFCDSOvjQF/PFcd0xyNB0SbYgIuB98Gi+vJdgO6w9+H4GhQZ4uAu8E\n\tA70bxxRITMG5N8ToCJt0zZSszGOjPvmAEynMz9Snh9cAyTu8bieY6y0I3X8XrRkVUK3+\n\tIQNcPddLERPSBTbpIdEpO21vAzmRHAS4ivlRHMdmXKYYB5Hna69JmSeBzmu/KujxExr+\n\tLUqg==","X-Gm-Message-State":"AHPjjUjPvov/kktWwKjHg7Vg5bNwyOB4ARymgYuaL8+4siWj2UcdJc0Y\n\tdspjsUVDeLxJA8B05Ja8tL4+vqGLRELOZPf2en+7uQ==","X-Google-Smtp-Source":"AOwi7QCdMTpTQhdBmChgfOBnZC0eAy6VUTPI8iZfPUnLj4COddykVOmbCiZrzP5uPOFO1MuSY+vbt7OZGNEsh5CTvr0=","X-Received":"by 10.28.31.140 with SMTP id f134mr1414285wmf.81.1506012183485; \n\tThu, 21 Sep 2017 09:43:03 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170921151253.4udm54dcq7x3ed4q@nataraja>","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>\n\t\n\t\n\t<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>\n\t\n\t<20170921001313.n2uo56oxmphcvd5g@nataraja>\n\t\n\t<20170921151253.4udm54dcq7x3ed4q@nataraja>","From":"Tom Herbert ","Date":"Thu, 21 Sep 2017 09:43:02 -0700","Message-ID":"","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","To":"Harald Welte ","Cc":"Andreas Schultz , Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tRohit Seth ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1774100,"web_url":"http://patchwork.ozlabs.org/comment/1774100/","msgid":"<20170924021626.b37zlwsomlibtnfs@nataraja>","list_archive_url":null,"date":"2017-09-24T02:16:26","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":931,"url":"http://patchwork.ozlabs.org/api/people/931/","name":"Harald Welte","email":"laforge@gnumonks.org"},"content":"Hi Tom,\n\nOn Thu, Sep 21, 2017 at 09:43:02AM -0700, Tom Herbert wrote:\n> Please see the cover letter for the original GTP kernel patches dated\n> May 10, 2016. My first question on those was \"Is there a timeline for\n> adding IPv6 support?\". To which Pablo replied that there was a\n> preliminary patch for it that has not been released. \n\nI'll suggest Pablo to comment on that. I don't recall the details at\nthat time, I was only involved in the earliest development of the module\nand then handed over.\n\n> If you don't like my patches or don't think that can be adapted to\n> fully support the GTP specification, that's fine. \n\nIt's not about \"not liking\". I'm very happy about contributions,\nincluding (of course) yours. It's about making sure that code we merge\ninto the kernel GTP driver will actually be usable to create a\nstandards-compliant GTP application or not.\n\nThere's no use in merging an IPv6 support patch if already by code\nreview it can be shown that it's impossible to create a spec-compliant\nimplementation using that patch. To me, that would be \"merging IPv6\nsupport so we can check off a box on a management form or marketing\nsheet\", but not for any practical value.\n\n> But then you need to provide a viable alternative.\n\nWhy do *I* have to provide a viable alternative? Who says that *I* have\nan obligation to do so? A (co-)maintainer of a given driver doesn't\nhave the obligation of implementing any feature as requested.\n\nCommunity based collaborative development only gets those things done\nthat people contribute. I have already contributed almost a decade of\nmy life to creating Free Software implementations of cellular protocol\nstacks, and it continues to be the center of my work and spare time.\nGTP is only one protocol layer on one of those stacks.\n\nPablo, Andreas and I have contributed a Linux kernel implementation that\ncurrently only implements IPv4. This implementation can by anyone\nextended to support IPv6, and as you see from this e-mail thread, there\nis interest in helping this along by\n* providing code review (even at times when it's personally difficult\n for me)\n* providing free hardware for setting up a \"private cellular network\"\n to test interoperability\n* providing testing tools for validation in absence of such a cellular\n network\n\n> We are at the point where a kernel networking feature that only\n> supports IPv4 when it could support IPv6 must be considered\n> incomplete.\n\nI agree it is incomplete. There's no doubt about that. But then,\neven the current \"incomplete\" implementation is working and can be used\nto operate an interoperable, spec-compatible IPv4 GGSN. So it serves a\npractical purpose. All I'm asking is that any IPv6 support patches are\ndeveloped with that same practical purpose in mind.\n\nGoing through the cover letter of your series again:\n\n> - IPv6 support\n\nCannot be merged as-is, see lengthy review discussion\n\n> - Configurable networking interfaces so that GTP kernel can be\n> used and tested without needing GSN network emulation (i.e. no user\n> space daemon needed).\n> - Port numbers are configurable\n\nAs I indicated, I'm not fundamentally opposed to it, but I'm wondering\nhow much value they bring in reality. Andreas has raised the valid\nconcern that we're adding code that is not used in production setups or\nby any of the userspace implementations using this tunneling module.\nThe code gets more complex and gets code paths that will not be\nexercised/tested.\n\nNevertheless, if it helps you to work on GTP, we can merge them from my\npoint of view - unless Pablo and/or Andreas object more strongly.\n\n> - GSO,GRO\n> - A facility that allows application specific GSO callbacks\n\nFine with me, but I think you need to convince other folks about the\n\"application specific GSO\" and the usage of the upper bits of\nshinfo(skb)->gso_type.\n\n> - Control of zero UDP checksums\n\nSame as above, Dave was raising some question about it, not sure if\nhis concern remains.\n\n> - Addition of a dst_cache in the GTP structure\n\nFine with me.\n\n\nAs for the patches touching gtp.c:\n\n* 04/14 udp recv clean up:\n\tfine with me, but kbuild robot complaint?\n\tOn a minor note, I think you're mixing two unrelated topics:\n\tSeparating the UDP receive functions and conversion to gro_cells,\n\twhich violates the \"one patch per feature\" rule. I'd still\n\tmerge it, but would prefer two separate patches\n\n* 05/14 Remove special mtu handling\n\tPending your rework\n\n* 06/14 Eliminate pktinfo and add port configuration\n\tI don't like the combination of a non-functional \"cosmetic\"\n\trefactoring of removing a data structure with the introduction\n\tof a new feature. Makes it harder to review, impossible to\n\tmerge only one of the two. For the rationale of introducing the\n\tgtp_pktinfo struct, see\n\thttp://git.osmocom.org/osmo-gtp-kernel/commit/?id=3bc7019c7afd06b5c7d94e5621728d092b82bb85\n\tit was actually intended to make IPv6 support easier, but the\n\tpartial IPv6 support was removed before mainline submission.\n\n* 07/14 Support encapsulation of IPv6 packets\n\tNot acceptable in its current form, see extensive review\n\n* 08/14 Support encpasulating over IPv6\n\tNo concerns in principle. Pending you making it dependent on AF\n\tof socket\n\n* 09/14 Allow configuring GTP interface as standalone\n\tCan be merged unless strong objection from Pablo/Andreas (see above)\n\n* 10/14 Add support for devnet\n\tNo concerns from my side\n\n* 12/14 Configuration for zero UDP checksum\n\tUp to Dave, he raised a question on it\n\n* 13/14 Support for GRO\n\tNo concerns from my side\n\n* 14/14 GSO support\n\tNo concerns from my side\n\nBTW: Where have the iproute2/ip patches been posted, which you mention\nin your cover page of the patch series?","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y0B0V0CfWz9t2M\n\tfor ;\n\tSun, 24 Sep 2017 12:26:01 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751521AbdIXCUP (ORCPT );\n\tSat, 23 Sep 2017 22:20:15 -0400","from ganesha.gnumonks.org ([213.95.27.120]:60458 \"EHLO\n\tganesha.gnumonks.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751355AbdIXCUO (ORCPT\n\t); Sat, 23 Sep 2017 22:20:14 -0400","from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dvwWf-0008Q3-UV; Sun, 24 Sep 2017 04:20:10 +0200","from laforge by localhost.localdomain with local (Exim 4.89)\n\t(envelope-from )\n\tid 1dvwT4-0000sv-Jp; Sun, 24 Sep 2017 10:16:26 +0800"],"Date":"Sun, 24 Sep 2017 10:16:26 +0800","From":"Harald Welte ","To":"Tom Herbert ","Cc":"Andreas Schultz , Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tRohit Seth ","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","Message-ID":"<20170924021626.b37zlwsomlibtnfs@nataraja>","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>\n\t\n\t\n\t<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>\n\t\n\t<20170921001313.n2uo56oxmphcvd5g@nataraja>\n\t\n\t<20170921151253.4udm54dcq7x3ed4q@nataraja>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170609 (1.8.3)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1774248,"web_url":"http://patchwork.ozlabs.org/comment/1774248/","msgid":"","list_archive_url":null,"date":"2017-09-24T15:55:49","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":72064,"url":"http://patchwork.ozlabs.org/api/people/72064/","name":"Tom Herbert","email":"tom@quantonium.net"},"content":"> It's not about \"not liking\". I'm very happy about contributions,\n> including (of course) yours. It's about making sure that code we merge\n> into the kernel GTP driver will actually be usable to create a\n> standards-compliant GTP application or not.\n>\nHarald,\n\nDo you believe that these patches are not at all on the right track,\nthat they can't be built upon to get to a standards-compliant\nimplementation, and that we are going to have to throw all of this and\nstart from scratch to provide IPv6 support?\n\n> There's no use in merging an IPv6 support patch if already by code\n> review it can be shown that it's impossible to create a spec-compliant\n> implementation using that patch. To me, that would be \"merging IPv6\n> support so we can check off a box on a management form or marketing\n> sheet\", but not for any practical value.\n>\n\nTo be clear, these patches are not done because to be a bullet point\non a marketing sheet. IPv6 is becoming _the_ Internet protocol. It\ncontinues to exhibit exponential growth (~20% of Internet, per Google\nstats), I believe least two of the largest datacenter operators are\nrunning everything over IPv6, and there are already proposals to start\nofficial deprecation of IPv4. In the mobile space IPv6 is going to be\na critical enabler of IoT and security in technologies like 5G. If we\nwant Linux to be at the forefront of the next technology wave then we\nneed to focus on IPv6 now! We should be far past the days of vendors\nonly providing IPv4 in the kernel support because \"that's what our\ncustomers use\" and they'll get to IPv6 support at their leisure. IMO,\ndavem has every right to unilaterally NAK patches that only support\nIPv4 or only test IPv4 with not even a path or timeline for IPv6\nsupport.\n\nThanks,\nTom","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=quantonium-net.20150623.gappssmtp.com\n\theader.i=@quantonium-net.20150623.gappssmtp.com\n\theader.b=\"YJ9O0qiC\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y0Wz038glz9sPs\n\tfor ;\n\tMon, 25 Sep 2017 01:55:56 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752626AbdIXPzx (ORCPT );\n\tSun, 24 Sep 2017 11:55:53 -0400","from mail-wm0-f53.google.com ([74.125.82.53]:43058 \"EHLO\n\tmail-wm0-f53.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752590AbdIXPzw (ORCPT\n\t); Sun, 24 Sep 2017 11:55:52 -0400","by mail-wm0-f53.google.com with SMTP id m72so7647563wmc.0\n\tfor ; Sun, 24 Sep 2017 08:55:51 -0700 (PDT)","by 10.223.158.197 with HTTP; Sun, 24 Sep 2017 08:55:49 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=quantonium-net.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=ECsmxtZlVrTIQfc4wBhUmLE1NP9WEMuMrBzc1RoRDYk=;\n\tb=YJ9O0qiCGQ8WZlaW+MBqiuj75VvTVmG7E1ILJzaXB3CawbUu0s2VaJejrviX4TdC3E\n\tRH5B6vhhKp/2atb6rC5Ziuo88SxYTe5opChvIZ9DTlJ3fnZO3WmRFwTSZ/VqVn1QvLZ8\n\tDaGdRydB3Xjwu5iU7AKddQezsDIcnnh5rwvw9sV4AASeVOz6cu4vvFDySOZMMmEZnII7\n\tr6TsX3cUZxGcTy8y32jlPJWEHtzObTS50QoESFX5MZ2bntP4epMMre42JIwxD1q6VQK4\n\t/57PqXBR+XcKFL2F4uu0fQKPOrNH47lSjgsYpaZFoOU83MTomYe4fNbqL8w610PTD3xu\n\tkuNw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=ECsmxtZlVrTIQfc4wBhUmLE1NP9WEMuMrBzc1RoRDYk=;\n\tb=pRDOI7tPShmQZNXVHy6WZNCd6/KNMgl/P+jVqDtEfn67TCXN2SazUjiGwc81KhpnPW\n\tgtbbdA2Z74A9I96x48/4BppoS06WLlvdInHCRnI/tgQoWS+IorH9zOnrX2gBUq5+pw1L\n\t9T0+2tSKB33d2GdmRMSUKlmioKGdRATXvMQW6DEE6a72+70Mf3Xi+Ik4xqB1cUuPtsab\n\t6OSyW+V8La0yCa33xFpumMX5eH+MwhdEpiLFlaGwOklr+SseTv7e6ObmdtugGbClpH3S\n\tPIyXgico8b1nKq19FVWerRZbiFvH+1scCP/sq4Cps74yok26y3sgFbaqKqtn/uRSjNze\n\tcgrQ==","X-Gm-Message-State":"AHPjjUh7s3rQiqc4+DYgYqbXfLV6RjAtlhVqf6Aqz6TXRvrZU0NSLhUl\n\t2pRQWs09gnV/QvU2AWgUsuKvcLg/swo7ZJmsys/2pQ==","X-Google-Smtp-Source":"AOwi7QB+BZwEWPUS4/HboSp9p4yCxrvkqruSicuk1vDXgozyYJs44JRiJFPaIe8HSpLyo4BzVz22Apa9CF+s1RNY8BE=","X-Received":"by 10.28.31.140 with SMTP id f134mr7240342wmf.81.1506268550743; \n\tSun, 24 Sep 2017 08:55:50 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170924021626.b37zlwsomlibtnfs@nataraja>","References":"<20170919003904.5124-1-tom@quantonium.net>\n\t<20170919003904.5124-10-tom@quantonium.net>\n\t\n\t\n\t<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>\n\t\n\t<20170921001313.n2uo56oxmphcvd5g@nataraja>\n\t\n\t<20170921151253.4udm54dcq7x3ed4q@nataraja>\n\t\n\t<20170924021626.b37zlwsomlibtnfs@nataraja>","From":"Tom Herbert ","Date":"Sun, 24 Sep 2017 08:55:49 -0700","Message-ID":"","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","To":"Harald Welte ","Cc":"Andreas Schultz , Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tRohit Seth ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1774252,"web_url":"http://patchwork.ozlabs.org/comment/1774252/","msgid":"<20170924162543.d7syskutxzgvbw23@nataraja>","list_archive_url":null,"date":"2017-09-24T16:25:43","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":2169,"url":"http://patchwork.ozlabs.org/api/people/2169/","name":"Harald Welte","email":"laforge@netfilter.org"},"content":"Hi Tom,\n\nOn Sun, Sep 24, 2017 at 08:55:49AM -0700, Tom Herbert wrote:\n> Do you believe that these patches are not at all on the right track,\n> that they can't be built upon to get to a standards-compliant\n> implementation, and that we are going to have to throw all of this and\n> start from scratch to provide IPv6 support?\n\nI believe I have pointed out where the problem areas are, several times\nby now. I see no reason why things would have to be started from\nscratch. However, the issues pointed out in the IPv6 support patch[es]\nhave to be resolved *before* any merge to mainline.\n\nI don't mind merging \"incomplete\" code that doesn't cover all parts of a\nspec but provides basic interoperability. I also am not arguing that\ncode must be bug-free at the time it is merged (which is impossible\nanyway). But I am arguing that we cannot merge something that is\na wrong implementation as per the spec, and hence it must be brought\nin-line with the spec before it can be merged.\n\n> > There's no use in merging an IPv6 support patch if already by code\n> > review it can be shown that it's impossible to create a spec-compliant\n> > implementation using that patch. To me, that would be \"merging IPv6\n> > support so we can check off a box on a management form or marketing\n> > sheet\", but not for any practical value.\n> \n> To be clear, these patches are not done because to be a bullet point\n> on a marketing sheet. \n\nGreat.\n\n> IPv6 is becoming _the_ Internet protocol.\n\nI'm all aware of that, and I've been a very early adopter, since the\n1990ies with 6bone.\n\nMy argument is not against IPv6 support. My argument is against merging\nsomething that introdues IPv6 in a way that's not in-line with the GTP\nprotocol specifications, as such a way is of no use to anyone (except\nmarketing sheets).\n\n> We should be far past the days of vendors only providing IPv4 in the\n> kernel support because \"that's what our customers use\" and they'll get\n> to IPv6 support at their leisure. \n\nI'm not sure where a \"vendor\" is involved with the GTP patches so far. I\nthink we have to draw a distinction between what you expect from\nprofessional, corporate \"vendors\" with a commercial interest in mind\n(such as supporting their hardware) and what you can expect from people\ndoing things in their spare time, out of enthusiasm to finally bring\nsome Free Software into the closed world of telecommunications.\n\nThe Telecom world should have implemented something like a GTP kernel\nmodule a decade to 15 years ago. They could have saved significant\ninvestments in proprietary hardware by running open source GGSNs with an\naccelerated user plane in the kernel. Nobody seemed to have an interest\nin that, until today - as you can see from Pablo and me working on this\nin our spare time, whenever we have a couple of spare cycles next to\nmany other projects. You can see from the osmo-gtp-kernel commit log it\ntook years of being a ultra-low-priority on-and-off project to ever get\nto a point where we thought it was worth submitting it mainline.\nAndreas deserves the praise for finally pushing it ahead.\n\nI'm looking forward to reviewing the next version of the patch series.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y0Xdz16ynz9sRW\n\tfor ;\n\tMon, 25 Sep 2017 02:26:14 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752624AbdIXQ0K (ORCPT );\n\tSun, 24 Sep 2017 12:26:10 -0400","from ganesha.gnumonks.org ([213.95.27.120]:36851 \"EHLO\n\tganesha.gnumonks.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752416AbdIXQ0K (ORCPT\n\t); Sun, 24 Sep 2017 12:26:10 -0400","from uucp by ganesha.gnumonks.org with local-bsmtp (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dw9jI-0007tX-Vh; Sun, 24 Sep 2017 18:26:05 +0200","from laforge by localhost.localdomain with local (Exim 4.89)\n\t(envelope-from )\n\tid 1dw9ix-0008ND-Cx; Mon, 25 Sep 2017 00:25:43 +0800"],"Date":"Mon, 25 Sep 2017 00:25:43 +0800","From":"Harald Welte ","To":"Tom Herbert ","Cc":"Andreas Schultz , Tom Herbert ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tRohit Seth ","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","Message-ID":"<20170924162543.d7syskutxzgvbw23@nataraja>","References":"\n\t\n\t<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>\n\t\n\t<20170921001313.n2uo56oxmphcvd5g@nataraja>\n\t\n\t<20170921151253.4udm54dcq7x3ed4q@nataraja>\n\t\n\t<20170924021626.b37zlwsomlibtnfs@nataraja>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1774264,"web_url":"http://patchwork.ozlabs.org/comment/1774264/","msgid":"","list_archive_url":null,"date":"2017-09-24T17:18:53","subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","submitter":{"id":65986,"url":"http://patchwork.ozlabs.org/api/people/65986/","name":"Tom Herbert","email":"tom@herbertland.com"},"content":"> I'm not sure where a \"vendor\" is involved with the GTP patches so far. I\n> think we have to draw a distinction between what you expect from\n> professional, corporate \"vendors\" with a commercial interest in mind\n> (such as supporting their hardware) and what you can expect from people\n> doing things in their spare time, out of enthusiasm to finally bring\n> some Free Software into the closed world of telecommunications.\n>\nIf it makes you feel any better I am not getting paid for this work either :-)\n\n> The Telecom world should have implemented something like a GTP kernel\n> module a decade to 15 years ago. They could have saved significant\n> investments in proprietary hardware by running open source GGSNs with an\n> accelerated user plane in the kernel. Nobody seemed to have an interest\n> in that, until today - as you can see from Pablo and me working on this\n> in our spare time, whenever we have a couple of spare cycles next to\n> many other projects. You can see from the osmo-gtp-kernel commit log it\n> took years of being a ultra-low-priority on-and-off project to ever get\n> to a point where we thought it was worth submitting it mainline.\n> Andreas deserves the praise for finally pushing it ahead.\n>\nI completely agree, and your work is well appreciated! But I don't\nbelieve it is to late to steer the ship away from proprietary\nsolutions. In fact, given the direction of the rest of the industry\ndirection, now is our best opportunity to try. That is a major reason\nfor these patches. We need to bring GTP into the limelight and get a\nlot more people thinking about. This might even be the world's most\nimportant tunneling protocol. If nothing else, a discussion like this\nis good if it inspires others in the community to start to look at it.\n\nTom","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=herbertland-com.20150623.gappssmtp.com\n\theader.i=@herbertland-com.20150623.gappssmtp.com\n\theader.b=\"adgNutWX\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y0Ypx419Fz9sRm\n\tfor ;\n\tMon, 25 Sep 2017 03:19:05 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752699AbdIXRS4 (ORCPT );\n\tSun, 24 Sep 2017 13:18:56 -0400","from mail-qt0-f179.google.com ([209.85.216.179]:50743 \"EHLO\n\tmail-qt0-f179.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752550AbdIXRSz (ORCPT\n\t); Sun, 24 Sep 2017 13:18:55 -0400","by mail-qt0-f179.google.com with SMTP id f15so4960433qtf.7\n\tfor ; Sun, 24 Sep 2017 10:18:54 -0700 (PDT)","by 10.237.61.196 with HTTP; Sun, 24 Sep 2017 10:18:53 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=herbertland-com.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=44JZGlCsghtGW6HmhHXmtyvMb9HppIomRaScjktKTSk=;\n\tb=adgNutWXuF0A9sXWpVpKl4ZMKRHS4pkifOQCsZo7eLRskF+YnKWrk4Ly7OFRz/UCEZ\n\tDCcSJakKxR18So03luoQnUNnmp9mQ+rrTBCdu31u6toUfPoIHZyQEcDoOkW3wyQmuPzT\n\tMO2iPfGX4Y15hlXKrYijfK0OzkCCp7YLQc86ZM+38FPem7dRNFFqh6EK4/mRk3wfFCeq\n\tRQeZ0p0fbh4ZiD16RWpYF92wxbYPwc2rD0VkkaDsQj5dv2BzkkHQspl8cJFdyWR4RPlq\n\t2reibUAFxsLdZJvaFddkv1QDMVA6Ih/EecqpvrVKfUBf3lZJTye17tACs1Y/RgtvINS3\n\twwAg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=44JZGlCsghtGW6HmhHXmtyvMb9HppIomRaScjktKTSk=;\n\tb=e2pqaG24n7F8B+AXLSBJPXCega/U/b+ddxS7HG9Uu3hy6rG+eEZNJ/Omhg1N2JrbZL\n\t/gY17DzUJJnOPaUx7E4pOHY5Fwa/TjKySKFIDE2mB31oNyFxOWDJPeDckrJWlWh7WfT1\n\t0tyzKVOH0JRrn9a69AfrHf9NHT8bxviWlsuCvfyn6RC7w5y87nAQU35YUSioUKhJZt1m\n\tMzFfJ1vWij+pO419LewK94cDXfSKJce+PDNjmPIBgzssPWSK47CFpjqOUtsp1hW05mf2\n\tVHCIXw85+KtT2QymDNPNN5z2wTQ3SCTF1GrkAWeih2sBiFROdMe7SSbYVOi6KPkWmwY5\n\t76Aw==","X-Gm-Message-State":"AHPjjUiwUPfeUBztzpLmp0tByg823rqg/QWgIc/Mq+6ux9lLvqNKUqcj\n\tHG7PDTWPrn7/+ZVBhre/jqGb/QtY1alTmkYwb8pPdw==","X-Google-Smtp-Source":"AOwi7QALmxfEntV/gUHBiSEgbdqR9qoIoGauVVdTJqZ5kThutkJpxEbKjhF8iH+qwWiwMUE3ssu/by/9Y+ve5jnlUfQ=","X-Received":"by 10.237.62.206 with SMTP id o14mr7989462qtf.286.1506273534289; \n\tSun, 24 Sep 2017 10:18:54 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170924162543.d7syskutxzgvbw23@nataraja>","References":"\n\t\n\t<56e339a8-fa2d-6f8d-a89c-c0f3f242763a@tpip.net>\n\t\n\t<20170921001313.n2uo56oxmphcvd5g@nataraja>\n\t\n\t<20170921151253.4udm54dcq7x3ed4q@nataraja>\n\t\n\t<20170924021626.b37zlwsomlibtnfs@nataraja>\n\t\n\t<20170924162543.d7syskutxzgvbw23@nataraja>","From":"Tom Herbert ","Date":"Sun, 24 Sep 2017 10:18:53 -0700","Message-ID":"","Subject":"Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as\n\tstandalone","To":"Harald Welte ","Cc":"Tom Herbert , Andreas Schultz ,\n\t\"David S. Miller\" ,\n\tLinux Kernel Network Developers ,\n\tPablo Neira Ayuso ,\n\tRohit Seth ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]