Re: [Tofoo] use of UDP in tunneling foo over IP

Tom Herbert <> Tue, 15 April 2014 23:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DF7D01A0076 for <>; Tue, 15 Apr 2014 16:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p08Y2O2iCGsS for <>; Tue, 15 Apr 2014 16:15:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::229]) by (Postfix) with ESMTP id 3BEEC1A0073 for <>; Tue, 15 Apr 2014 16:15:32 -0700 (PDT)
Received: by with SMTP id to1so9919179ieb.0 for <>; Tue, 15 Apr 2014 16:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DTA0nvK8mfhpcIhLOhQbgBSv49WjcUvoOx/5vJsjakE=; b=DhllkJO15szrIzyqn+6ajxTamloeKCUq/g2EsRhG+yHMIwIBtCYQesLtKHgxE5uPhb TUwNf/wtFJDDPQW0rHlbp5qCUZkx/ikU9hp9OPxQgCw8bNupWtHrqvQLJQRwQRe5BYgJ KEczCC6PjQs7i91Ukwdi6wLWgtJ6YkPA3168cVArYk3p9L9LZAT7cC/9MYAa2ALO+SjK SNcn+xohneFuTlCc0Dgo8N/KUTK+bwAtGj3lyCUPZARXQyReue07h9F1Vyv/2odgMBmU LPmkm0EvmSuGrD+j4gheufbZ9lqQ/490K81QGPPofN+s61qLg7OPS0JnruAPQVE9veDg DwzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DTA0nvK8mfhpcIhLOhQbgBSv49WjcUvoOx/5vJsjakE=; b=l6ZqkipY9856TpZ7lgTan5d89jrKOUkGwWtkGFd0dcNCzuLWAWbCBe8NfpY2YL95RS aoeVqSJBrCaOimB11RBRIOzQQEaqnM2HosmqTI5UlkEesPQFX5Jn501DRcB0g+nhDdfa 34/suYK+J1gK54I3mp86KPSfA2Ds/5i2Ml9X2AMk/mlxLoPI8FzeKfgovpd9XHVXQTxy j1if8BD8kbB8QaGcxsJXRxbJ/pRsWa0EnOrxOxojtMZSjWFtx8xSTYNSS7pztROOdz6Y xZFSWoT2SdWp1prrVRQYA7Hq8hAWv5ptRNOxUeItSiqFenD0bpQiXzx8QtU7W8PAbQRN bkuQ==
X-Gm-Message-State: ALoCoQkiSeJwzz+8yLuh7xYQ9G6HzjrZ8wjnjdGiF3FvK0tfUQituMk/pCIO6ijIHk+XG+1JUuxzbtBSaViAeWBFo6S1rMBIdNcLrdvlpzib8txLc2OSAXl8zIHNAZym4o9hs2ieUYlLT8ykmu/QFYeGL/Agfwd/YZVyYRlE7Jrq3Dp85CZjLx3DfIX0u8i/VE3WQyFYgCYK
MIME-Version: 1.0
X-Received: by with SMTP id a3mr6523668igg.28.1397603729103; Tue, 15 Apr 2014 16:15:29 -0700 (PDT)
Received: by with HTTP; Tue, 15 Apr 2014 16:15:29 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 15 Apr 2014 16:15:29 -0700
Message-ID: <>
From: Tom Herbert <>
To: Lucy yong <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Tofoo] use of UDP in tunneling foo over IP
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Apr 2014 23:15:35 -0000

Hi Lucy,

Response in line...

On Tue, Apr 15, 2014 at 12:00 PM, Lucy yong <> wrote:
> 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.
I think the relevant question is can we define standard "data center"
protocols which have different properties and optimizations than
"Internet" protocols.  There might be some justification for latitude
here (in my opinion the requirement that all encapsulation protocols
need to inter-operate with NAT is awfully restrictive), but as a
prerequisite I think you would need a clear definition of "use within
a data center" or a "data center protocol". For instance, if packets
are going over private links between two sites can they still be
considered to be within a data center? Also, would this imply that
data center networks must meet certain requirements to be candidates
for using a data center protocol? Would a low error rate be required
such that things to make UDP checksum unnecessary as a standard? To
what extent can we assume security of the protocol provided by the DC
network? Is in order delivery guaranteed so we don't have to worry
about OOO? Can the upper protocol layers be trusted to do congestion
control correctly (in case of NV answer is clearly no to that)?
Requirements to use L2 or L3?


> 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.
> Regards,
> Lucy
> -----Original Message-----
> From: IETF-Announce [] On Behalf Of IETF Secretariat
> Sent: Thursday, April 10, 2014 12:04 PM
> To: IETF Announcement List
> Cc:;
> 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:
> Archive:
> To subscribe:
> Purpose:
> 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.
> _______________________________________________
> Tofoo mailing list