> This is a larger topic, and certainly there have been many Foo-over-UDP
> and generic-UDP-tunnel/encap proposals out there.
>
Yes, I'm aware of those. But I think that the fact that many
Foo-over-UDP seem to require more than just encapsulating the basic
format might be problematic and is requiring us to considering each
protocol individually. For instance, looking at RFC 3931 there's a
different L2TP header format for L2TP/UDP than L2TP/IP. L2TP-VP could
work in UDP case by setting a version number and converting reserved
field to type and using some other bits for header length as I
described. Unfortunately, this doesn't work in the non-UDP case so it
still wouldn't be L2TP...
> 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
