> You do not need to specify anything here. You can just offset yourself and
> stick the extra fields between a _STANDARD_ L2TPv3 header and the payload.
> Due to L2TPv3 not specifying an Ethertype in the header you can offset the
> data by as much as you wish and stick in there whatever you wish. It will
> still be fully compatible and will be supported at some backward
> compatibility level by any implementation which has an offset parameter.
> That is pretty much all of them nowdays.
>
"stick in there whatever you wish" is not a plan to produce an
interoperable and robust protocol. It seems like L2TP would generally
benefit from including an EtherType, why not propose that as a new
optional L2TP field?
> In any case, as we already have a reference implementation for use of L2TPv3
> as a virtualization protocol enqueued for inclusion in kvm-qemu 2.1,
> containers in Linux above 3.3 and UML (TBA, current versions are 3.3+)
> please specify how you interoperate versus existing code which in the
> process of being deployed.
>
> Hint - you do not.
>
>
> A.
>
>
>
> 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).
>
> [Frank] : good comments. Will consider it~~
>
>
> - 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.
>
> [Frank] : It’s an issue existing a long time. I have no personal preference
> on it. It totally depends on real requirement.
>
>
>
>
>
>
> - "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.
>
> [Frank] : Actually, It’s only a encapsulation example. But your comment is
> right. We will correct in the next version. Thanks!
>
>
>
> 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
>
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
>
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
