Re: MPLS over L2TPv3 encap for RFC 2547 VPNs

Yakov Rekhter <yakov@juniper.net> Wed, 04 February 2004 01:46 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16683 for <l3vpn-archive@odin.ietf.org>; Tue, 3 Feb 2004 20:46:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoC6u-0000a6-0Z for l3vpn-archive@odin.ietf.org; Tue, 03 Feb 2004 20:45:48 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i141jlTh002228 for l3vpn-archive@odin.ietf.org; Tue, 3 Feb 2004 20:45:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoC6t-0000Zr-QY for l3vpn-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 20:45:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16658 for <l3vpn-web-archive@ietf.org>; Tue, 3 Feb 2004 20:45:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoC6r-0004gt-00 for l3vpn-web-archive@ietf.org; Tue, 03 Feb 2004 20:45:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoC5v-0004bI-00 for l3vpn-web-archive@ietf.org; Tue, 03 Feb 2004 20:44:47 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoC5F-0004WJ-00 for l3vpn-web-archive@ietf.org; Tue, 03 Feb 2004 20:44:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoC5B-0000U2-EN; Tue, 03 Feb 2004 20:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoC55-0000To-70 for l3vpn@optimus.ietf.org; Tue, 03 Feb 2004 20:43:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16622 for <l3vpn@ietf.org>; Tue, 3 Feb 2004 20:43:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoC52-0004Vk-00 for l3vpn@ietf.org; Tue, 03 Feb 2004 20:43:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoC41-0004Ql-00 for l3vpn@ietf.org; Tue, 03 Feb 2004 20:42:49 -0500
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AoC3X-0004LS-00 for l3vpn@ietf.org; Tue, 03 Feb 2004 20:42:19 -0500
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i141fol56597; Tue, 3 Feb 2004 17:41:50 -0800 (PST) (envelope-from yakov@juniper.net)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i141fjh18617; Tue, 3 Feb 2004 17:41:45 -0800 (PST) (envelope-from yakov@juniper.net)
Message-Id: <200402040141.i141fjh18617@merlot.juniper.net>
To: "W. Mark Townsley" <townsley@cisco.com>
cc: mpls@uu.net, l3vpn@ietf.org
Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs
In-Reply-To: Your message of "Mon, 02 Feb 2004 21:26:15 +0100." <401EB267.5070908@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <88819.1075858905.1@juniper.net>
Date: Tue, 03 Feb 2004 17:41:45 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: l3vpn-admin@ietf.org
Errors-To: l3vpn-admin@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l3vpn.ietf.org>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

Mark,

> Based on comments received from the previous IETF meeting, I have split 
> the MPLS 
> over L2TPv3 draft into two documents.
> 
> draft-townsley-l2tpv3-mpls-01.txt targets mpls, and presents only the 
> MPLS over L2TPv3 encapsulation.
> 
> draft-townsley-l3vpn-l2tpv3-00.txt targets l3vpn, and discusses the use 
> of MPLS 
> over L2TPv3 within the context of RFC2547-Style VPNs.
> 
> Yakov also had three specific points raised during both meetings that 
> I promised to bring to the list. These follow:
> 
> > 1. Why extending BGP for multipoint-to-point L2TP signaling
> > is preferred to the existing L2TP signaling (or extending L2TP
> > to provide multipoint-to-point signaling) ?
> 
> Any sort of point to multipoint manual configuration or signaling may 
> in fact be used. 

My question was not whether BGP *may* be used, but *why* extend BGP
to support l2tp signaling when l2tp already has its own signaling
protocol. 

> However, BGP does seem prudent for what is effectively 
> an extension to RFC2547.

Please document in your draft what is exactly "prudent" about BGP.

> > 2. The applicability scope is by no means limited to 2547 - it is
> > applicable to any multipoint-to-point application.
> 
> Yes, though the scope does not extend beyond reachability information to 
> a given PE. The MPLS labels for the VPN routes themselves continue to 
> be distributed by the existing mechanisms of RFC2547.

I am glad you agree that that the distribution of l2tp signaling
information described in your draft  is completely orthogonal to
2547. Which is precisely the point I made.  That is, there is nothing
in your draft that is specific to just 2547. E.g., it is equally
applicable to VR based L3VPNs. Therefore, the draft has to be generalized
to cover any multipoint-to-point application of MPLS over l2tp.

> > 3. The security claims have to be reviewed by the Security ADs.
> 
> Yes, as with any potential RFC.

Since security considerations (and to be more precise, the part
about implications on packet spoofing) are presented in your draft
as one of the major justifications for using l2tp, in making a
decision on whether to accept your drafts as a WG document the WG
needs to know whether this justification is really accurate. That
is precisely why I asked the section on implications on packet
spoofing to be reviewed and evaluated for correctness and accuracy
by the Security ADs.

Yakov.