Re: [nvo3] New Version Notification for draft-fan-l2tp-vp-01.txt
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Thu, 10 April 2014 17:08 UTC
Return-Path: <cpignata@cisco.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7751A01FF; Thu, 10 Apr 2014 10:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.772
X-Spam-Level:
X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2mrb4JYoKP4; Thu, 10 Apr 2014 10:08:38 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6809B1A01DD; Thu, 10 Apr 2014 10:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14364; q=dns/txt; s=iport; t=1397149717; x=1398359317; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SHg+aigfhgEXofSf/S+USB7RkxUI0hdJV7VGrp/GmkM=; b=aw4mK62M7N0fWwxHPD9cnPcQBCCADABHb6XpDHB8M9J1ZmMLVm+gWLa2 0c/ZQE5iiFVe7iANSW0h2kKijSj3ENgxkibkMSe5cELimx1kH99uJ4bLd dwU2hRWGsZwfw4Llc0pbHtv+6MRLgyx1ZzKyP8ELwwpfC52hJPptMkOfy 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkYFAM7ORlOtJA2K/2dsb2JhbABagkJEO1EGvHGHNYEjFnSCJQEBAQQBAQFrCQIMBAIBCA4DBAEBKAcnCxQJCAIEDgUJh3MIBc08F44VUwQHBgODG4EUBJRxg22BNZENgzCBakE
X-IronPort-AV: E=Sophos; i="4.97,835,1389744000"; d="scan'208,217"; a="34720988"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP; 10 Apr 2014 17:08:36 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3AH8aWB008806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Apr 2014 17:08:36 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 12:08:35 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Tom Herbert <therbert@google.com>
Thread-Topic: [nvo3] New Version Notification for draft-fan-l2tp-vp-01.txt
Thread-Index: AQHPVGwUioKZm7B370uoJbPkmsBi+JsKMc1AgAEhXoCAABbWgA==
Date: Thu, 10 Apr 2014 17:08:35 +0000
Message-ID: <1045434E-F6BE-444E-8E28-B2DCCE1B0A35@cisco.com>
References: <20140410032205.30725.83163.idtracker@ietfa.amsl.com> <C02846B1344F344EB4FAA6FA7AF481F10F3E29D0@SZXEMA502-MBS.china.huawei.com> <CA+mtBx9r75d3bkk4FeHWXjPMwfetr97rBuxWoubDsx=_Y_RZ0g@mail.gmail.com>
In-Reply-To: <CA+mtBx9r75d3bkk4FeHWXjPMwfetr97rBuxWoubDsx=_Y_RZ0g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.229.74]
Content-Type: multipart/alternative; boundary="_000_1045434EF6BE444E8E28B2DCCE1B0A35ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/QIJtDi43WcUGdEQsD7JKuNge_pQ
Cc: "l2tpext@ietf.org" <l2tpext@ietf.org>, Namgon Kim <ng.kim@kt.com>, Fanduoliang <fanduoliang@huawei.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "Xialiang (Frank)" <frank.xialiang@huawei.com>, Zehn Cao <zehn.cao@gmail.com>
Subject: Re: [nvo3] New Version Notification for draft-fan-l2tp-vp-01.txt
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2014 17:08:43 -0000
Frank, Tom, Please find some additional comments inline, L2TPExt chair hat off. On Apr 10, 2014, at 11:46 AM, Tom Herbert <therbert@google.com<mailto:therbert@google.com>> wrote: On Wed, Apr 9, 2014 at 8:37 PM, Xialiang (Frank) <frank.xialiang@huawei.com<mailto:frank.xialiang@huawei.com>> wrote: 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! 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? 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). - "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. There's also hashing for L2TPv3 directly over IP (e.g., RFC 5640) 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> [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<mailto:nvo3@ietf.org> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org<mailto:nvo3@ietf.org> https://www.ietf.org/mailman/listinfo/nvo3
- Re: [nvo3] New Version Notification for draft-fan… Xialiang (Frank)
- Re: [nvo3] New Version Notification for draft-fan… Tom Herbert
- Re: [nvo3] New Version Notification for draft-fan… Carlos Pignataro (cpignata)
- Re: [nvo3] New Version Notification for draft-fan… Tom Herbert
- Re: [nvo3] [L2tpext] New Version Notification for… Carlos Pignataro (cpignata)
- Re: [nvo3] [L2tpext] New Version Notification for… Tom Herbert
- Re: [nvo3] New Version Notification for draft-fan… Xialiang (Frank)
- Re: [nvo3] New Version Notification for draft-fan… Xialiang (Frank)
- Re: [nvo3] New Version Notification for draft-fan… Anton Ivanov (antivano)
- Re: [nvo3] [L2tpext] New Version Notification for… Carlos Pignataro (cpignata)
- Re: [nvo3] New Version Notification for draft-fan… Tom Herbert
- Re: [nvo3] New Version Notification for draft-fan… Anton Ivanov (antivano)