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

["Anton Ivanov (antivano)" <[e-mail]>]

On 11/04/14 16:34, Tom Herbert wrote:
>> 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?
I agree - it is not a plan. It is a design direction.

I also agree - if there is a need to have a profile different from the 
current Ethernet one which has Ethertype we can put it in there. Note 
the "if".

In either case case we do not need to break the current standard to 
introduce this extension and we do not need to have a repeat of the MPLS 
& MPLS-TP Relationship. I mean Relationship with big R here (the whole 
soap opera including T-MPLS vs MPLS-TP).

A.

>
>> 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: [e-mail] [mailto:[e-mail]]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>>
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3