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

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 10 Apr 2014 03:37:15 +0000

Hi folks,
We have updated the L2TP-VP version -01 draft. 
In the new version draft, we add the motivation of this draft and modification to the format of L2TP-VP header.
Welcome your comments and suggestions!

B.R.
Frank

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Apr 2014 08:46:55 -0700

> Welcome your comments and suggestions!
Hi Frank,

Thanks for posting. A few comments:

- This is so dramatically different from L2TP I wonder if it can still
honestly be called L2TP. Have you implemented this? How much of L2TP
stack can be leveraged?
- "Session ID is changed to a 31-bit field"-- doesn't this break L2TP then?
- "Type field"-- I suspect this is meant to be an EtherType value.
Please be explicit about this.
- 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.
- 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

> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 10 Apr 2014 17:08:35 +0000

Frank, Tom,

Please find some additional comments inline, L2TPExt chair hat off.

On Apr 10, 2014, at 11:46 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

<[email-masked]<mailto:[email-masked]>> wrote:

Hi Frank,

These two bullet points are critical. A "profile" of protocol is a constrained subset of it, within an applicability context. What this document shows is not a profile.

The most-significant bit of the Session ID being used for something else ("Modified bit") has two implications:

  1.  This is not a profile, it's an attempt to redefine L2TPv3.
  2.  This non-profile draft describes a non-backwards compatible protocol. Meaning, L2TPv3's Session ID allows for Session IDs with the MSB set. Consequently, a packet cannot be differentiated between L2TPv3 and this other protocol (which is not a profile).
  3.  It breaks L2TPv3.

OK, I lied, three (or possibly more) implications :-)

The remaining points are subordinate to this high-order bit (no pun intended).

There's also hashing for L2TPv3 directly over IP (e.g., RFC 5640)

Thanks,

Carlos.

Thanks,
Tom

B.R.
Frank

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, April 10, 2014 11:22 AM
To: Xialiang (Frank); Zhen Cao; Fanduoliang; Zehn Cao; Namgon Kim; Namgon

Name:         draft-fan-l2tp-vp
Revision:     01

Abstract:

The IETF Secretariat

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Apr 2014 11:23:20 -0700

> 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 :-) )

Tom

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 10 Apr 2014 18:34:37 +0000

Hi, Tom,

-----Original Message-----
From: Tom Herbert <[email-masked]>
Date: Thursday, April 10, 2014 at 2:23 PM
To: Carlos Pignataro <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Namgon Kim <[email-masked]>,
Fanduoliang <[email-masked]>, "[email-masked]" <[email-masked]>,
Zehn Cao <[email-masked]>
Subject: Re: [L2tpext] [nvo3] New Version Notification
for	draft-fan-l2tp-vp-01.txt

>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.

>> Title:                L2TP-VP: Layer Two Tunneling Protocol -
>>Virtualization
>> Profile
>L2tpext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/l2tpext

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 Apr 2014 11:53:27 -0700

> 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...

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Fri, 11 Apr 2014 09:31:57 +0000

Hi Tom, Carlos,
Thanks for your comments, please see my response inline:

From: nvo3 [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, April 11, 2014 1:09 AM
To: Tom Herbert
Cc: [email-masked]; Namgon Kim; Fanduoliang; [email-masked]; Xialiang (Frank); Zehn Cao
Subject: Re: [nvo3] New Version Notification for draft-fan-l2tp-vp-01.txt

Frank, Tom,

Hi folks,

There's also hashing for L2TPv3 directly over IP (e.g., RFC 5640)
[Frank] : Agree with all your comments. In current draft, we only specifies L2TP-VP over IP. We indeed have considered L2TP-VP over UDP and can add this part of content in next version if necessary.

Thanks,

Carlos.

Thanks,
Tom

B.R.
Frank

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, April 10, 2014 11:22 AM
To: Xialiang (Frank); Zhen Cao; Fanduoliang; Zehn Cao; Namgon Kim; Namgon

Name:         draft-fan-l2tp-vp
Revision:     01

Abstract:

The IETF Secretariat

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Fri, 11 Apr 2014 10:01:45 +0000

Hi Tom, Carlos,

B.R.
Frank

Frank, Tom,

Hi folks,

- This is so dramatically different from L2TP I wonder if it can still
honestly be called L2TP. Have you implemented this? How much of L2TP
stack can be leveraged?
- "Session ID is changed to a 31-bit field"-- doesn't this break L2TP then?
[Frank] : The main differences we've made are:

1.       Session ID is changed to 31-bit: that's because we need the most significant bit for differentiating  L2TPv3 packets with L2TP-VP packets in data plane. The only disadvantage is to limit the session ID scope for existing L2TPv3 protocol to < 2 ^ 31, but that scope is large enough to be used for L2TPv3 session in practice;

2.       We reuse first 32 bit of cookie field to the TNI, the left 32 bit is still used for cookie field. This indeed limit the cookie mechanism's capability. In next version of the draft, we will solve this problem.
Except the above, we do not change anything of L2TPv3. What we currently do is to reuse L2TPv3 for multi-tenant network scenarios, but keep its implementation separating from existed L2TPv3 implementation in data plane clearly.

The remaining points are subordinate to this high-order bit (no pun intended).
[Frank] : I think we can consider the relationship between L2TP-VP and L2TPv3 as the same thing of relationship between MPLS-TP and MPLS.

Thanks,

Carlos.

[Frank] : good comments. Will consider it~~

[Frank] : It's an issue existing a long time. I have no personal preference on it. It totally depends on real requirement.

[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-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, April 10, 2014 11:22 AM
To: Xialiang (Frank); Zhen Cao; Fanduoliang; Zehn Cao; Namgon Kim; Namgon

Name:         draft-fan-l2tp-vp
Revision:     01

Abstract:

The IETF Secretariat

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 11 Apr 2014 12:29:38 +0000

Frank,

Please see inline.

On Apr 11, 2014, at 6:01 AM, Xialiang (Frank) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tom, Carlos,

B.R.
Frank

From: nvo3 [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, April 11, 2014 1:09 AM
To: Tom Herbert
Cc: [email-masked]<mailto:[email-masked]>; Namgon Kim; Fanduoliang; [email-masked]<mailto:[email-masked]>; Xialiang (Frank); Zehn Cao
Subject: Re: [nvo3] New Version Notification for draft-fan-l2tp-vp-01.txt

Frank, Tom,

Hi folks,

- This is so dramatically different from L2TP I wonder if it can still
honestly be called L2TP. Have you implemented this? How much of L2TP
stack can be leveraged?
- "Session ID is changed to a 31-bit field"-- doesn't this break L2TP then?
[Frank] : The main differences we’ve made are:
1.       Session ID is changed to 31-bit: that’s because we need the most significant bit for differentiating  L2TPv3 packets with L2TP-VP packets in data plane. The only disadvantage is to limit the session ID scope for existing L2TPv3 protocol to < 2 ^ 31, but that scope is large enough to be used for L2TPv3 session in practice;
2.       We reuse first 32 bit of cookie field to the TNI, the left 32 bit is still used for cookie field. This indeed limit the cookie mechanism’s capability. In next version of the draft, we will solve this problem.
Except the above, we do not change anything of L2TPv3.

I will say that both things are a non-starter. You can appreciate it's not only 31 vs 32 bits. As it was already pointed out, you cannot differentiate an L2TPv3 packet with the MSB set. Regarding the cookie, please read RFC 3931 on the discussion of 32 vs. 64 bits.

Best,

Carlos.

What we currently do is to reuse L2TPv3 for multi-tenant network scenarios, but keep its implementation separating from existed L2TPv3 implementation in data plane clearly.

Thanks,

Carlos.

[Frank] : It’s an issue existing a long time. I have no personal preference on it. It totally depends on real requirement.

[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-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, April 10, 2014 11:22 AM
To: Xialiang (Frank); Zhen Cao; Fanduoliang; Zehn Cao; Namgon Kim; Namgon

Name:         draft-fan-l2tp-vp
Revision:     01

Abstract:

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<http://tools.ietf.org/>.

The IETF Secretariat

_______________________________________________
L2tpext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/l2tpext