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

From: Lucy yong <[email-masked]>
Date: Tue, 15 Apr 2014 21:56:54 +0000

One correction on previous mail. It should be RFC5405 (not 5054)

-----Original Message-----
From: Lucy yong 
Sent: Tuesday, April 15, 2014 2:04 PM
To: [email-masked]'
Subject: use of UDP in tunneling foo over IP

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.

Regards,
Lucy     

-----Original Message-----
From: IETF-Announce [mailto:[email-masked]] On Behalf Of IETF Secretariat
Sent: Thursday, April 10, 2014 12:04 PM
To: IETF Announcement List
Cc: [email-masked]; [email-masked]
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: [email-masked]
Archive: http://www.ietf.org/mail-archive/web/tofoo/
To subscribe: https://www.ietf.org/mailman/listinfo/tofoo

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.