Re: [nvo3] [L2tpext] New Version Notification for draft-fan-l2tp-vp-01.txt

Hi, Tom,

-----Original Message-----
From: Tom Herbert <therbert@google.com>
Date: Thursday, April 10, 2014 at 2:23 PM
To: Carlos Pignataro <cpignata@cisco.com>
Cc: "l2tpext@ietf.org" <l2tpext@ietf.org>, Namgon Kim <ng.kim@kt.com>,
Fanduoliang <fanduoliang@huawei.com>, "nvo3@ietf.org" <nvo3@ietf.org>,
Zehn Cao <zehn.cao@gmail.com>
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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> 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
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>
>_______________________________________________
>L2tpext mailing list
>L2tpext@ietf.org
>https://www.ietf.org/mailman/listinfo/l2tpext