IETF Logo Mail Archive

Re: [Banana] Charter

"Zhangmingui (Martin)" <zhangmingui@huawei.com> Thu, 14 September 2017 03:08 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: banana@ietfa.amsl.com
Delivered-To: banana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54B1126C19 for <banana@ietfa.amsl.com>; Wed, 13 Sep 2017 20:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oarsTEd0H_Ts for <banana@ietfa.amsl.com>; Wed, 13 Sep 2017 20:08:04 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B2BD81321C4 for <banana@ietf.org>; Wed, 13 Sep 2017 20:08:03 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVK37393; Thu, 14 Sep 2017 03:07:01 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 14 Sep 2017 04:06:59 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 14 Sep 2017 11:06:55 +0800
From: "Zhangmingui (Martin)" <zhangmingui@huawei.com>
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "mrcullen42@gmail.com" <mrcullen42@gmail.com>
CC: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "banana@ietf.org" <banana@ietf.org>
Thread-Topic: [Banana] Charter
Thread-Index: AQHTLJQk7Lu8sWEKo0evWxTyU4qzAqKygcIAgAErmwI=
Date: Thu, 14 Sep 2017 03:07:19 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E7A65EC703@NKGEML515-MBX.china.huawei.com>
References: <96A7BC33-FB64-487A-A60D-7AB8504C9DDF@gmail.com> <a1df884a51f246a7969c0057ff78d807@BTWP000357.corp.ads> <C3A4BFB9-EAD7-4B32-90C1-248D6D74ECD1@gmail.com> <9A767D1D-C6CA-4C7D-A281-7150E259881D@gmail.com> <DB5PR07MB13998EE07C5B5D5DBACED79C9B1A0@DB5PR07MB1399.eurprd07.prod.outlook.com> <7ED94797-5E72-4191-B861-4CD2F410BBD5@gmail.com> <7i60gox0c8.wl-jch@irif.fr> <DB5PR07MB1399FEDB262E0205457EA8AB9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <87bmqgov69.wl-jch@irif.fr> <DB5PR07MB1399977AFFE9FA7D19A2D34D9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <0d8ce583860345b89020113f1239be5d@BTWP000357.corp.ads> <21BD0F20-9CE5-466B-992E-93F6D84DB7D4@gmail.com> <95788B92-E8C1-4FE6-9B0C-7F29361D9297@trammell.ch> <d3759d89-9f6e-bcf4-8c44-32f3f435d784@gmail.com> <01e83ac6-0bd0-e7c7-01e4-0ffb7af73034@gmail.com> <4B6D7CF5-E6BC-4ECA-9299-7458A624320B@nokia.com> <B31BA5EB-7369-4B49-B240-AA6C3E653231@gmail.com>, <2F216DBC-43EE-45AC-AAB8-68C81A14AD73@nokia.com>
In-Reply-To: <2F216DBC-43EE-45AC-AAB8-68C81A14AD73@nokia.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.41.10]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.59B9F255.005E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: bc32241e43be0e60699f62c70321883f
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/wnIEhIst3gxmJxSPk8n14eUnzU8>
Subject: Re: [Banana] Charter
X-BeenThere: banana@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Bandwidth Aggregation for interNet Access: Discussion of bandwidth aggregation solutions based on IETF technologies." <banana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/banana>, <mailto:banana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/banana/>
List-Post: <mailto:banana@ietf.org>
List-Help: <mailto:banana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/banana>, <mailto:banana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Sep 2017 03:08:06 -0000

Hi Alex,

If "GRE passthrough NAT" was proved to be really required, there are two options:
1. GRE in UDP while the UDP provides you the port number.
2. The GRE Key field to be used to carry the port number. 
For the second option, there are some existing implementations. But it is not an option if the Key field has already used for other purpose, e.g., security.

However, I would say the popular usage is that the NAT happens just before the GRE tunnel. Why do we have to insert a NAT device in between two GRE tunnel endpoints?

Thanks,
Mingui

________________________________________
From: Banana [banana-bounces@ietf.org] on behalf of Henderickx, Wim (Nokia - BE/Antwerp) [wim.henderickx@nokia.com]
Sent: Thursday, September 14, 2017 0:51
To: mrcullen42@gmail.com
Cc: Alexandre Petrescu; banana@ietf.org
Subject: Re: [Banana] Charter

How will you sent GRE through NAT. GRE has no port number

On 13/09/2017, 17:27, "mrcullen42@gmail.com" <mrcullen42@gmail.com> wrote:

    Hi Wim,

    Sent from my iPhone

    > If I hear GRE as a proposal it is very NAT unfriendly and the solution need to work across multiple providers, so this is an important consideration.

    Sorry, I somehow dropped this thread while I was in vacation...

    Why do you think that (all) GRE-based proposal(s) would be NAT unfriendly?

    Margaret


_______________________________________________
Banana mailing list
Banana@ietf.org
https://www.ietf.org/mailman/listinfo/banana

v2.23.0 | Report a Bug | By Email