Hi, Tom, -----Original Message----- From: Tom Herbert <[email protected]> Date: Thursday, April 10, 2014 at 2:23 PM To: Carlos Pignataro <[email protected]> Cc: "[email protected]" <[email protected]>, Namgon Kim <[email protected]>, Fanduoliang <[email protected]>, "[email protected]" <[email protected]>, Zehn Cao <[email protected]> Subject: Re: [L2tpext] [nvo3] New Version Notification for draft-fan-l2tp-vp-01.txt
>> - To get hashing (for ECMP, RSS, etc.) in the network we'd almost >> certainly use L2TP over UDP, so L2TP-VP should probably have a format >> defined for use with UDP. >> >> >> There's also hashing for L2TPv3 directly over IP (e.g., RFC 5640) >> >Unfortunately to use that I'd need to replace all my hardware to >support it, and even if we did that the second we start putting L2TP >in IPsec we're right back to not having the hash. Same thinking >applies to GRE and it's use of key field for hash. I suppose it's not >by design, but UDP encap will likely be the de facto standard in the >data center-- it's not really that bad just a few bytes of overhead >buys us compatibility with a lot of devices. There's some pesky issues >to resolve, like whether UDP checksum is worthwhile and how to >interact with NAT, but if we do this right we should be a able to >provide a solution for all IP protocols (e.g. >http://tools.ietf.org/html/draft-herbert-gue-01 :-) ) This is a larger topic, and certainly there have been many Foo-over-UDP and generic-UDP-tunnel/encap proposals out there. Without rat-holing, my point was only that there¹s specs for ECMP for L2TPv3/GRE directly over IP, and also (agreeing with you here) you can run L2TPv3 over UDP. Thanks, ‹ Carlos. > >Tom > >> Thanks, >> >> Carlos. >> >> - Even with Type field, this still suffers from the same problem L2TP >> has that network devices won't be able to parse the packet beyond the >> L2TP header (the cookie field makes the header variable length). This >> eliminates the ability to implement the protocol with LRO for >> instance. I suggest you take four or five bits from reserved section >> for header length to resolve this (see example in GUE). >> - Cookie mechanism is an advantage over VXLAN and nvgre I believe, but >> why limit it to 32 bits? 64 bits is much stronger, and at some point >> we might even want 128 bits to do strong authentication. >> >> Some more general questions applicable to this and some other proposals. >> >> - "TNI field"-- this seems to use the same 24 bit left shifted format >> of nvgre and VXLAN. I still don't see the rationale for this! Why >> can't the full 32 bit field be allocated for vni? A large deployment >> will be using various levels of hierarchical allocation and possibly >> obfuscation of vni (TNI). The nvo3 requirements on this are vague >> ("100's of thousands of virtual networks"), but they clearly don't >> expect this the VNI to be a simple flat space either. >> - "Outer Ethernet Header"-- showing the outer Ethernet header in L3 >> encapsulations examples is not necessary, use of Ethernet is not a >> requirement, and this is potentially very misleading. For instance, >> the outer Ethernet FCS does *not* protect the packet end to end in an >> L3 routed network. Personally, I think it would be more illustrative >> to show the IP packet in the inner Ethernet frame instead to see how >> its alignment is affected. >> >> Thanks, >> Tom >> >> B.R. >> Frank >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Thursday, April 10, 2014 11:22 AM >> To: Xialiang (Frank); Zhen Cao; Fanduoliang; Zehn Cao; Namgon Kim; >>Namgon >> Kim; Fanduoliang; Xialiang (Frank) >> Subject: New Version Notification for draft-fan-l2tp-vp-01.txt >> >> >> A new version of I-D, draft-fan-l2tp-vp-01.txt has been successfully >> submitted >> by Liang Xia and posted to the IETF repository. >> >> Name: draft-fan-l2tp-vp >> Revision: 01 >> Title: L2TP-VP: Layer Two Tunneling Protocol - >>Virtualization >> Profile >> Document date: 2014-04-10 >> Group: Individual Submission >> Pages: 9 >> URL: >> http://www.ietf.org/internet-drafts/draft-fan-l2tp-vp-01.txt >> Status: https://datatracker.ietf.org/doc/draft-fan-l2tp-vp/ >> Htmlized: http://tools.ietf.org/html/draft-fan-l2tp-vp-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-fan-l2tp-vp-01 >> >> Abstract: >> This document describes Layer Two Tunneling Protocol (L2TP)'s >> virtualization profile (L2TP-VP), which reuses session header of L2TP >> data message to securely support overlay networks for multiple >> tenants, and simplifies tunnel setup by disabling all kinds of L2TP >> control messages. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >>submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> > >_______________________________________________ >L2tpext mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/l2tpext _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
