Re: [L2tpext] [nvo3] New Version Notification for draft-fan-l2tp-vp-01.txt
Tom Herbert <therbert@google.com> Thu, 10 April 2014 18:53 UTC
Return-Path: <therbert@google.com>
X-Original-To: l2tpext@ietfa.amsl.com
Delivered-To: l2tpext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80B41A029C for <l2tpext@ietfa.amsl.com>; Thu, 10 Apr 2014 11:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no
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 Bos80n39bEcX for <l2tpext@ietfa.amsl.com>; Thu, 10 Apr 2014 11:53:28 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0971A0303 for <l2tpext@ietf.org>; Thu, 10 Apr 2014 11:53:28 -0700 (PDT)
Received: by mail-ig0-f171.google.com with SMTP id c1so8203962igq.10 for <l2tpext@ietf.org>; Thu, 10 Apr 2014 11:53:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6lj5cSaAfwTnLAlSeeefQ4k6jiIBkh9DmIFcfuRO5b8=; b=JqRWFcTQ/XcVjaGSxim9OYL3Z9uEFEFijccjg/MLZtgsay5dDovB/DwlFFcMfKdb63 07f5F8MS2T9h23XdhKOdCN+h31Oc11cxurAJE5KNm0xjyAPZ+UiBDw2oYOI28yDl2UcI TzUEmDkBAFpx+h3DMg9WowzVDBk2uecAX3lcNrRwrU6lepxdcytO3J0WSZDn2i07qFA5 u5eul7nQ1pv/ssOlRRVy69FeIjkbyhAND5+u/sRwNhgu0P5Qpwgk9OWlUk1iXar1lwkr G+M3glCxs2OxuxKjEPqqKrfZWGMIt2dOQ3cQv3k17yLcwn2eVudhQ8jP0GeiIfjSMVfI Km5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6lj5cSaAfwTnLAlSeeefQ4k6jiIBkh9DmIFcfuRO5b8=; b=ZGxhPxlzvFL5hzO6pS44eHEvgj1Im0luLsMHOEhc0C67Cj0/28x52vXcRH8YKxNOLs /L1/5CvwpgbJfTVDpqPwC+8tbh+bMRTyPNRccb3/DgdCt4qpX9EjxQZPWncysr7+WjgM NsLWKTuJDtD23ULeCX4PsREd3Mw3MbO0bO+/dM5sJ79ARBVJpOG+XVTyFOYlZMR59/xo ilVV3G62FXn1aNTrnxi0rzecjOy8wUC2T8RvSxqWJUUjiRG6PuHmBsxA/5MI2r9kkIYU tOLl8eVSDreeeoWHD51vnl6T24nwL8d0+U5wh6gWDyzi+tGE7os0Crg9aJFFtw6wf42L mrKg==
X-Gm-Message-State: ALoCoQmuQFygqGA9v49zXV6HE4HPCTPGKSDCZK4OlMNHxrbN1CyN6/ZMKYoCZfHIHFkeyDeHSWPbM0B+na4rN9LH+4Cb7YwuCHi9zOCp3N7Ns9IQTHgP+TrsgqBxVG8unNHryXx+vDHfZSJGlaz10psYRm1gPUN80JbyORhtiROckzhq7+K/DDZczFBbHfPQaHAmT2Ioyl7c
MIME-Version: 1.0
X-Received: by 10.50.43.225 with SMTP id z1mr12468352igl.29.1397156007254; Thu, 10 Apr 2014 11:53:27 -0700 (PDT)
Received: by 10.64.148.98 with HTTP; Thu, 10 Apr 2014 11:53:27 -0700 (PDT)
In-Reply-To: <CF6C5B3D.52433%cpignata@cisco.com>
References: <20140410032205.30725.83163.idtracker@ietfa.amsl.com> <C02846B1344F344EB4FAA6FA7AF481F10F3E29D0@SZXEMA502-MBS.china.huawei.com> <CA+mtBx9r75d3bkk4FeHWXjPMwfetr97rBuxWoubDsx=_Y_RZ0g@mail.gmail.com> <1045434E-F6BE-444E-8E28-B2DCCE1B0A35@cisco.com> <CA+mtBx9480QZV-+FByVi2yF9dnGQDAFau8-Xak-vD+wuZjmTOQ@mail.gmail.com> <CF6C5B3D.52433%cpignata@cisco.com>
Date: Thu, 10 Apr 2014 11:53:27 -0700
Message-ID: <CA+mtBx98h3tA7aErjdQwnDhhcjpV6=ELXr-0DpOaaMvxpySbwg@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/l2tpext/x9dV8PoC-dGMHCghhTDuA0u47xE
Cc: Fanduoliang <fanduoliang@huawei.com>, Zehn Cao <zehn.cao@gmail.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "l2tpext@ietf.org" <l2tpext@ietf.org>, Namgon Kim <ng.kim@kt.com>
Subject: Re: [L2tpext] [nvo3] New Version Notification for draft-fan-l2tp-vp-01.txt
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2tpext/>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2014 18:53:29 -0000
> 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: 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 >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> >> >>_______________________________________________ >>L2tpext mailing list >>L2tpext@ietf.org >>https://www.ietf.org/mailman/listinfo/l2tpext >
- Re: [L2tpext] New Version Notification for draft-… Xialiang (Frank)
- Re: [L2tpext] [nvo3] New Version Notification for… Tom Herbert
- Re: [L2tpext] [nvo3] New Version Notification for… Carlos Pignataro (cpignata)
- Re: [L2tpext] [nvo3] New Version Notification for… Tom Herbert
- Re: [L2tpext] [nvo3] New Version Notification for… Carlos Pignataro (cpignata)
- Re: [L2tpext] [nvo3] New Version Notification for… Tom Herbert
- Re: [L2tpext] [nvo3] New Version Notification for… Xialiang (Frank)
- Re: [L2tpext] [nvo3] New Version Notification for… Xialiang (Frank)
- Re: [L2tpext] [nvo3] New Version Notification for… Carlos Pignataro (cpignata)