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

[Lucy yong <[e-mail]>]

Hi Tom,

Please see inline below.

-----Original Message-----
From: Tom Herbert [mailto:[e-mail]] 
Sent: Tuesday, April 15, 2014 6:15 PM
To: Lucy yong
Cc: [e-mail]
Subject: Re: [Tofoo] use of UDP in tunneling foo over IP

Hi Lucy,

Response in line...

On Tue, Apr 15, 2014 at 12:00 PM, Lucy yong <[e-mail]> 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. 
[Lucy] This is a good way to put. A bit change is: "data center" -> "data centers and service provider networks".
 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".
[Lucy] Agree. Need the right terms here.
 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?
[Lucy] you raise a lot of good questions that need to be considered and addressed in NVO technology. Each solution has pros and cons. The matter is which has the better optimization for current reality and potential capability to evolve. 

Thanks,
Lucy

Thanks,
Tom

> 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:[e-mail]] On Behalf 
> Of IETF Secretariat
> Sent: Thursday, April 10, 2014 12:04 PM
> To: IETF Announcement List
> Cc: [e-mail]; [e-mail]
> 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: [e-mail]
> 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.
>
> _______________________________________________
> Tofoo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tofoo