[Tofoo] use of UDP in tunneling foo over IP

Lucy yong <lucy.yong@huawei.com> Tue, 15 April 2014 19:00 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: tofoo@ietfa.amsl.com
Delivered-To: tofoo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id DDF311A06A1 for <tofoo@ietfa.amsl.com>; Tue, 15 Apr 2014 12:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.473
X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fIAeWblGmu6H for <tofoo@ietfa.amsl.com>; Tue, 15 Apr 2014 12:00:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) by ietfa.amsl.com (Postfix) with ESMTP id 499E91A0642 for <tofoo@ietf.org>; Tue, 15 Apr 2014 12:00:19 -0700 (PDT)
Received: from (EHLO lhreml204-edg.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFR15899; Tue, 15 Apr 2014 19:00:14 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com ( by lhreml204-edg.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Tue, 15 Apr 2014 19:58:54 +0100
Received: from DFWEML703-CHM.china.huawei.com ( by lhreml402-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Tue, 15 Apr 2014 20:00:13 +0100
Received: from DFWEML701-CHM.china.huawei.com ([]) by dfweml703-chm.china.huawei.com ([]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 12:00:02 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: "tofoo@ietf.org" <tofoo@ietf.org>
Thread-Topic: use of UDP in tunneling foo over IP
Thread-Index: AQHPWNznn0+ZMVBexkCjCPZIfOowrw==
Date: Tue, 15 Apr 2014 19:00:02 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4536FDE0@dfweml701-chm.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/kAkgP-ml10Nolo3p_8j2lQVHysY
Subject: [Tofoo] use of UDP in tunneling foo over IP
X-BeenThere: tofoo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." <tofoo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tofoo>, <mailto:tofoo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tofoo/>
List-Post: <mailto:tofoo@ietf.org>
List-Help: <mailto:tofoo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tofoo>, <mailto:tofoo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Apr 2014 19:00:23 -0000

Hope to stimulate some discussions.

The demand for using tunnels in data centers and across the Internet is increasing due to network virtualization. UDP based tunnel mechanism is desirable for such network virtualization applications because UDP has the demultiplex capability (need at egress) and potential flow entropy capability (used by underlay network). So the approach brings least common denominator between NV overlay and underlay networks, which meets the key requirement of NVO, i.e. decouple overlay networking and underlay network.

The consequence of this approach is that NVO traffic will be treated as UDP traffic in underlay IP networks. In other words, these NVO applications will be treated as UDP applications in underlay IP network. RFC5054 has specified the rules for a UDP application to follow in order to make Internet work well. Now the question is if these new UDP tunnel methods for NV should follow the exact same rule or not.

Yes, if the UDP tunnel over Internet, it needs to follow the rules specified in RFC5054; but if the UDP tunnel is used within data centers or service provider networks, the rules specified in RFC5054 may be overkill. Thus, it is necessary to differentiate the two environments and have a proper set of rules for the latter case. 

Since RFC5054 only specifies the rules, people want a solution example in the tunnel mechanism when a rule applies. For example, congestion control solution example when it is necessary.

One key feature in NVO is the ability to express overlay traffic flow entropy to underlay networks. UDP tunnel achieves this without a change in underlay networks, which is great beneficial. However IPv6 header has a flow label field for host to express flow entropy and RFC6438 specifies how to use it in IPv6 networks; some foo over IP could use the flow label if underlay network is IPv6 instead of foo-in-udp over IP, which will be simpler the rules because IPv6 has some different semantics and mechanism that result in different rules from IPv4 such as checksum. Gre-in-udp and mpls-in-udp are under this category. However, if an NVO application is a new overlay application such as LISP and VXLAN and needs to distinguish from host applications, it still needs UDP tunnel in IPv6 underlay network. Thus, transport area people like to see a solution example to meet the rules in both IPv4 and IPv6 underlay network.


-----Original Message-----
From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Secretariat
Sent: Thursday, April 10, 2014 12:04 PM
To: IETF Announcement List
Cc: mls.ietf@gmail.com; tofoo@ietf.org
Subject: New Non-WG Mailing List: Tofoo -- Discussion list for Tunneling over Foo (with)in IP networks (TOFOO)

A new IETF non-working group email list has been created.

List address: tofoo@ietf.org
Archive: http://www.ietf.org/mail-archive/web/tofoo/
To subscribe: https://www.ietf.org/mailman/listinfo/tofoo


Tunneling data across IP-based networks can use a variety of existing encapsulation schemes, such as, GRE [RFC2784], IP-in-IP [RFC2003] and IPsec tunnels [RFC4301] or proposed encapsulation schemes that are based on carrying traffic over UDP. 
The demand for using tunnels in data centers and across the Internet is increasing also due to network virtualization. 
A number of known issues have been raised around using tunnels, discussions about applicability of these issues are ongoing and a number of solutions to cope with, for instance, congestion control or congestion control sensitivity, are being discussed. 
The intention of this list is to bring together tunnel protocol designers/implementers, network operators, and the different areas in the IETF to discuss the ways forward.

For additional information, please contact the list administrators.