From exim@www1.ietf.org Mon Feb 2 15:31:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07475 for ; Mon, 2 Feb 2004 15:31:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkiW-0003pp-LY for l3vpn-archive@odin.ietf.org; Mon, 02 Feb 2004 15:30:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12KUmdA014738 for l3vpn-archive@odin.ietf.org; Mon, 2 Feb 2004 15:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkiW-0003pd-EO for l3vpn-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 15:30:48 -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 PAA07420 for ; Mon, 2 Feb 2004 15:30:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkiV-0005dt-00 for l3vpn-web-archive@ietf.org; Mon, 02 Feb 2004 15:30:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkhY-0005ZO-00 for l3vpn-web-archive@ietf.org; Mon, 02 Feb 2004 15:29:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ankgz-0005Uu-00 for l3vpn-web-archive@ietf.org; Mon, 02 Feb 2004 15:29:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ankgn-0003ew-2T; Mon, 02 Feb 2004 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkgZ-0003eE-OI for l3vpn@optimus.ietf.org; Mon, 02 Feb 2004 15:28:48 -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 PAA07345 for ; Mon, 2 Feb 2004 15:28:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkgY-0005UH-00 for l3vpn@ietf.org; Mon, 02 Feb 2004 15:28:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ankfa-0005PT-00 for l3vpn@ietf.org; Mon, 02 Feb 2004 15:27:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ankei-0005H2-00 for l3vpn@ietf.org; Mon, 02 Feb 2004 15:26:52 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2004 12:27:06 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i12KQJHQ001723; Mon, 2 Feb 2004 15:26:20 -0500 (EST) Received: from cisco.com ([10.25.65.252]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AWR84011; Mon, 2 Feb 2004 12:26:17 -0800 (PST) Message-ID: <401EB267.5070908@cisco.com> Date: Mon, 02 Feb 2004 21:26:15 +0100 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@uu.net, l3vpn@ietf.org Subject: MPLS over L2TPv3 encap for RFC 2547 VPNs References: <200311121950.hACJoYi63281@merlot.juniper.net> In-Reply-To: <200311121950.hACJoYi63281@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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. However, BGP does seem prudent for what is effectively an extension to RFC2547. > 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. > 3. The security claims have to be reviewed by the Security ADs. Yes, as with any potential RFC. Thanks, - Mark From exim@www1.ietf.org Tue Feb 3 20:46:16 2004 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 ; 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 ; 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 ; 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" 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 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: , List-Id: List-Post: List-Help: List-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. From exim@www1.ietf.org Wed Feb 4 03:50:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26336 for ; Wed, 4 Feb 2004 03:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIjU-0002vg-IA for l3vpn-archive@odin.ietf.org; Wed, 04 Feb 2004 03:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i148o46o011255 for l3vpn-archive@odin.ietf.org; Wed, 4 Feb 2004 03:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIjU-0002vP-6E for l3vpn-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 03:50:04 -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 DAA26304 for ; Wed, 4 Feb 2004 03:50:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoIjR-0007Tv-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 03:50:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoIiS-0007Ns-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 03:49:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoIhW-0007I3-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 03:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIhW-0002oG-P6; Wed, 04 Feb 2004 03:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoIgg-0002lz-T3 for l3vpn@optimus.ietf.org; Wed, 04 Feb 2004 03:47:11 -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 DAA26195 for ; Wed, 4 Feb 2004 03:47:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoIge-0007BA-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 03:47:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoIfv-00073l-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 03:46:23 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AoIf7-0006rf-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 03:45:33 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 04 Feb 2004 00:45:06 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i148j1Xi012765; Wed, 4 Feb 2004 03:45:01 -0500 (EST) Received: from cisco.com ([10.25.65.252]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AWT02839; Wed, 4 Feb 2004 00:44:59 -0800 (PST) Message-ID: <4020B10A.70805@cisco.com> Date: Wed, 04 Feb 2004 09:44:58 +0100 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs References: <200402040141.i141fjh18617@merlot.juniper.net> In-Reply-To: <200402040141.i141fjh18617@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > Please document in your draft what is exactly "prudent" about BGP. Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide: "RFC2547 already provides an egress-to-ingress signaling capability via BGP, and we specify below how to extend this to the signalling of security policy." I will add this text to the l3vpn-l2tpv3 document: "RFC2547 already provides an egress-to-ingress signaling capability via BGP, [NALAWADE] or [RAGGARWA] specifies how to extend this to the signaling of L2TPv3 reachability information for a PE." > 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. No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label for a VPN-IPv4 address distributed via RFC2547 extensions to BGP between PEs. I should not extend this draft to cover other L3VPN models any more than draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt should. Shall I rename it to something with "2547" in the title to be more clear? >>>3. The security claims have to be reviewed by the Security ADs. I am more than happy to have discussions with Security ADs on this topic. - Mark From exim@www1.ietf.org Wed Feb 4 04:31:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27634 for ; Wed, 4 Feb 2004 04:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJNB-0006Tm-LD for l3vpn-archive@odin.ietf.org; Wed, 04 Feb 2004 04:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i149V5tn024906 for l3vpn-archive@odin.ietf.org; Wed, 4 Feb 2004 04:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJNB-0006Td-A0 for l3vpn-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 04:31:05 -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 EAA27585 for ; Wed, 4 Feb 2004 04:31:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJN8-0003PZ-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 04:31:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJMB-0003K9-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 04:30:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoJLG-0003Et-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 04:29:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJLE-0006CG-7P; Wed, 04 Feb 2004 04:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJKK-00069h-Fd for l3vpn@optimus.ietf.org; Wed, 04 Feb 2004 04:28:08 -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 EAA27453 for ; Wed, 4 Feb 2004 04:28:05 -0500 (EST) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJKH-00038E-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 04:28:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJJP-000330-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 04:27:12 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138] helo=i2kc03-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AoJJ4-0002wl-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 04:26:50 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 09:26:20 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 09:26:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: MPLS over L2TPv3 encap for RFC 2547 VPNs Date: Wed, 4 Feb 2004 09:26:19 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF3171@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: MPLS over L2TPv3 encap for RFC 2547 VPNs Thread-Index: AcPqwHEGtzaajeQNS7eaAobdD7hEDAANuLLg To: , Cc: , , , X-OriginalArrivalTime: 04 Feb 2004 09:26:20.0210 (UTC) FILETIME=[F2C61120:01C3EB00] Content-Transfer-Encoding: quoted-printable 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yakov/Mark, This discussion seems to have 2 major themes: - the appropriate functional use (or misuse) of protocols - security implications of functional protocol use (or misuse). I would much prefer we split the VPN problem into its 3 major components = (see below) and folks can use whichever protocol is considered the most = appropriate to that component. Further, and speaking as an operator, = I'd like to see as much *appropriate* re-use of components across the 3 = networking modes of co-cs, co-ps and cl-p as possible when creating VPNs = so that I can get my capex/opex costs down....and this has impact = through to the NMS/OSS supporting these. Now when I look at the VPN problem I see 3 major component areas: 1 Discovery/authentication: One needs a method of knowing which = addressable access points of a given server layer technology belong to a = given VPN. A query/response behaviour seems most appropriate here, not = a broadcast approach that one gets with BGP4. So an approach based on = Radius say seems a good solution here. 2 Server layer topology creation: One needs a method of creating = forwarding paths between the identified (from above) addressable access = points of the server layer technology belonging to the VPN. This needs = a proper signalling protocol IMO and not a broadcast behaviour like = BGP4. Several signalling protocols could be used, and the selection is = dependent upon which networking mode is being used for the server layer = technology. For example, if the server layer is IP (cl-ps mode) one can = use L2TP (but I could also 'signal' the set-up of GRE tunnels say). If = the server layer is MPLS (co-ps mode) one can use RSVP-TE.....and in = theory I could also use PNNI. If the server layer is SDH (co-cs mode) = one can again use RSVP-TE....or I could also use PNNI. There are three important observations at this point: - within a given mode there can be more than 1 choice of signalling = protocol....some signalling protocols have better functional = specification/behaviour than others; - the use of an out-of-band (OOB), logical and/or physical, date-plane = network for the important *internal* control/management traffic should = be very high on any operator's requirements list for obvious security = reasons. So where this is possible this should be done (this should be = a no-brainer requirement IMO for both the co-ps and co-cs modes); - if we stop the VPN creation process at steps 1 and 2 above we have the = essence of automating the creation of a simple managed BW VPN is some = technology.....some folk call these 'L2 VPNs', not a good term IMO but = it is in general usage. 3 Client layer reachability information: This is a component that can = be added to the above 'L2 VPN' base-case to create a so-called 'L3 VPN'. = The type of client should not be prescriptive....and this is why it is = architecturally wrong to assume 'L3 VPN'=3D> IP VPN, and why I think the = term 'L3 VPN' is misleading. Indeed, I recall seeing a draft from Chris = Metz (draft-metz-switched-atm-l2vpn-00.txt) a while ago that was using a = rfc2547 approach with BGP4 distributing ATM NSAP address reachability = over MPLS as the server layer technology, ie ATM was the client in this = 'L3 VPN' Now here a limited broadcast functional behaviour is what is required to = distribute information regarding which *client* layer access point = addresses lie above/behind which *server* layer access point = addresses....noting these are 2 disjoint layer networks. It is my opinion that if folks started to regard VPNs in the above terms = then much of the squabbling (eg 'my protocol is better than yours') = could be avoided. And we may also be able to provide operator's with = better solutions in the future (esp noting my points on functional = re-use to get capex/opex down and the use of an OOB control/management = plane where this is appropriate to improve security). regards, Neil=20 > -----Original Message----- > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > Yakov Rekhter > Sent: 04 February 2004 01:42 > To: W. Mark Townsley > Cc: mpls@uu.net; l3vpn@ietf.org > Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs=20 >=20 >=20 > Mark, >=20 > > Based on comments received from the previous IETF meeting,=20 > I have split=20 > > the MPLS=20 > > over L2TPv3 draft into two documents. > >=20 > > draft-townsley-l2tpv3-mpls-01.txt targets mpls, and=20 > presents only the=20 > > MPLS over L2TPv3 encapsulation. > >=20 > > draft-townsley-l3vpn-l2tpv3-00.txt targets l3vpn, and=20 > discusses the use=20 > > of MPLS=20 > > over L2TPv3 within the context of RFC2547-Style VPNs. > >=20 > > Yakov also had three specific points raised during both=20 > meetings that=20 > > I promised to bring to the list. These follow: > >=20 > > > 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) ? > >=20 > > Any sort of point to multipoint manual configuration or=20 > signaling may=20 > > in fact be used.=20 >=20 > 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.=20 >=20 > > However, BGP does seem prudent for what is effectively=20 > > an extension to RFC2547. >=20 > Please document in your draft what is exactly "prudent" about BGP. >=20 > > > 2. The applicability scope is by no means limited to 2547 - it is > > > applicable to any multipoint-to-point application. > >=20 > > Yes, though the scope does not extend beyond reachability=20 > information to=20 > > a given PE. The MPLS labels for the VPN routes themselves=20 > continue to=20 > > be distributed by the existing mechanisms of RFC2547. >=20 > 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=20 > generalized > to cover any multipoint-to-point application of MPLS over l2tp. >=20 > > > 3. The security claims have to be reviewed by the Security ADs. > >=20 > > Yes, as with any potential RFC. >=20 > 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. >=20 > Yakov. >=20 >=20 From exim@www1.ietf.org Wed Feb 4 14:59:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22625 for ; Wed, 4 Feb 2004 14:59:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTBJ-0008Kq-3y for l3vpn-archive@odin.ietf.org; Wed, 04 Feb 2004 14:59:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14JxTBc032034 for l3vpn-archive@odin.ietf.org; Wed, 4 Feb 2004 14:59:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTBI-0008K1-Mo for l3vpn-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 14:59:28 -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 OAA22580 for ; Wed, 4 Feb 2004 14:59:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTBF-0005bp-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 14:59:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTAI-0005We-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 14:58:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoT9w-0005Rc-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 14:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoT9s-00083r-NH; Wed, 04 Feb 2004 14:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoT9L-0007z8-PN for l3vpn@optimus.ietf.org; Wed, 04 Feb 2004 14:57:27 -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 OAA22475 for ; Wed, 4 Feb 2004 14:57:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoT9I-0005PN-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 14:57:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoT8O-0005IA-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 14:56:29 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AoT7h-00057C-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 14:55:45 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i14Jt8Bm008590; Wed, 4 Feb 2004 11:55:08 -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 i14Jt8h00257; Wed, 4 Feb 2004 11:55:08 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402041955.i14Jt8h00257@merlot.juniper.net> To: "W. Mark Townsley" cc: mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs In-Reply-To: Your message of "Wed, 04 Feb 2004 09:44:58 +0100." <4020B10A.70805@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62067.1075924507.1@juniper.net> Date: Wed, 04 Feb 2004 11:55:08 -0800 From: Yakov Rekhter 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: , List-Id: List-Post: List-Help: List-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, > Yakov Rekhter wrote: > > > Please document in your draft what is exactly "prudent" about BGP. > > Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide: > > "RFC2547 already provides an egress-to-ingress signaling capability via BGP, > and we specify below how to extend this to the signalling of security policy." > > I will add this text to the l3vpn-l2tpv3 document: > > "RFC2547 already provides an egress-to-ingress signaling capability via BGP, > [NALAWADE] or [RAGGARWA] specifies how to extend this to the signaling of > L2TPv3 reachability information for a PE." Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does *not* replace IPSec signaling with BGP. All it does is specifying how to use BGP to indicate whether a particular VPN on a PE should use IPSec to get traffic to that PE. In contrast your draft uses BGP not just to specify whether a particular VPN on a PE should use l2tp to get traffic to that PE, but also uses BGP to carry the l2tp session and cookie (l2tp signaling information). That is, in contrast to draft-ietf-l3vpn-ipsec-2547-01.txt your draft does replace the l2tp signaling protocol with BGP, thus eliminating the need for l2tp signaling with the l2tp signaling protocol. Just tell us why BGP signaling is any better than l2tp signaling. > > 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. > > No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label for a VPN-IPv4 > address distributed via RFC2547 extensions to BGP between PEs. I should not > extend this draft to cover other L3VPN models any more than > draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt > should. Shall I rename it to something with "2547" in the title to be > more clear? First of all I'd like to thank you for pointing that both draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt took a fairly narrow point of view. This is a bug, not a feature, and therefore it should be fixed. Second, the restriction on the applicability of your draft to 2547 is quite arbitrary. That is, there are *no* technical justifications for this restriction. And the fact that some other drafts took a fairly narrow view of the problem is no justification for continuing this. > >>>3. The security claims have to be reviewed by the Security ADs. > > I am more than happy to have discussions with Security ADs on this topic. Thanks. Please post the outcome of this discussion to the list. Yakov. From exim@www1.ietf.org Wed Feb 4 15:06:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23063 for ; Wed, 4 Feb 2004 15:06:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTI0-0005rk-Kp for l3vpn-archive@odin.ietf.org; Wed, 04 Feb 2004 15:06:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14K6OQ8022542 for l3vpn-archive@odin.ietf.org; Wed, 4 Feb 2004 15:06:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTI0-0005rV-F9 for l3vpn-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 15:06:24 -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 PAA23020 for ; Wed, 4 Feb 2004 15:06:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTHx-0006At-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 15:06:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTH1-00066P-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 15:05:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTGj-00061t-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 15:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTGh-00056D-DN; Wed, 04 Feb 2004 15:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTG2-0004pL-7R for l3vpn@optimus.ietf.org; Wed, 04 Feb 2004 15:04:22 -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 PAA22839 for ; Wed, 4 Feb 2004 15:04:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTFz-00061M-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 15:04:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTF3-0005xF-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 15:03:22 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AoTEX-0005rf-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 15:02:49 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i14K2JBm008620 for ; Wed, 4 Feb 2004 12:02:19 -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 i14K2Jh01112 for ; Wed, 4 Feb 2004 12:02:19 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402042002.i14K2Jh01112@merlot.juniper.net> To: l3vpn@ietf.org Subject: draft-ietf-l3vpn-gre-ip-2547-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64613.1075924939.1@juniper.net> Date: Wed, 04 Feb 2004 12:02:19 -0800 From: Yakov Rekhter 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: , List-Id: List-Post: List-Help: List-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 Folks, draft-ietf-l3vpn-gre-ip-2547-01.txt talks about using GRE or IP tunnels instead of the outer label for 2547 VPNs. However, the same approach could be used for other MPLS VPN applications (e.g., VR-based VPNs with BGP-based autodiscovery). With this in mind I'd like to propose to generalize the document. Comments ??? Yakov. From exim@www1.ietf.org Wed Feb 4 15:46:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25912 for ; Wed, 4 Feb 2004 15:46:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTtz-0005MN-8b for l3vpn-archive@odin.ietf.org; Wed, 04 Feb 2004 15:45:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14KjdYD020599 for l3vpn-archive@odin.ietf.org; Wed, 4 Feb 2004 15:45:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTtz-0005MA-4r for l3vpn-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 15:45:39 -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 PAA25871 for ; Wed, 4 Feb 2004 15:45:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTtx-0001u8-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 15:45:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTsx-0001n7-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 15:44:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTsR-0001gd-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 15:44:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTsQ-0004oc-Pd; Wed, 04 Feb 2004 15:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTrk-0004lQ-Uo for l3vpn@optimus.ietf.org; Wed, 04 Feb 2004 15:43:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25683; Wed, 4 Feb 2004 15:43:18 -0500 (EST) Message-Id: <200402042043.PAA25683@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-tc-mib-01.txt Date: Wed, 04 Feb 2004 15:43:18 -0500 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Definition of Textual Conventions for Layer 3 Virtual Private Network (L3VPN) Management Author(s) : B. Schliesser, T. Nadeau Filename : draft-ietf-l3vpn-tc-mib-01.txt Pages : 7 Date : 2004-2-4 This document describes Textual Conventions used for managing PPVPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-tc-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-tc-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-tc-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-4160230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-tc-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-tc-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-4160230.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Wed Feb 4 18:00:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05931 for ; Wed, 4 Feb 2004 18:00: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 1AoVzq-0007FC-AZ for l3vpn-archive@odin.ietf.org; Wed, 04 Feb 2004 17:59:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Mxobe027840 for l3vpn-archive@odin.ietf.org; Wed, 4 Feb 2004 17:59:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVzq-0007Ex-4i for l3vpn-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 17:59:50 -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 RAA05876 for ; Wed, 4 Feb 2004 17:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVzn-0004K2-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 17:59:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVyx-0004Cl-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 17:58:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoVy9-00044Y-00 for l3vpn-web-archive@ietf.org; Wed, 04 Feb 2004 17:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVy7-00074r-DP; Wed, 04 Feb 2004 17:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVxz-00073m-1L for l3vpn@optimus.ietf.org; Wed, 04 Feb 2004 17:57: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 RAA05729 for ; Wed, 4 Feb 2004 17:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVxw-00043a-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 17:57:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVwp-0003vw-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 17:56:43 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AoVwH-0003oJ-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 17:56:09 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i14MtWH27654; Wed, 4 Feb 2004 17:55:32 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1FNHYZGX>; Wed, 4 Feb 2004 17:55:33 -0500 Message-ID: From: "Hamid Ould-Brahim" To: Yakov Rekhter , l3vpn@ietf.org Subject: RE: draft-ietf-l3vpn-gre-ip-2547-01.txt Date: Wed, 4 Feb 2004 17:55:31 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , List-Id: List-Post: List-Help: List-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 Yakov, > > draft-ietf-l3vpn-gre-ip-2547-01.txt talks about using GRE or > IP tunnels instead of the outer label for 2547 VPNs. > However, the same approach could be used for other MPLS VPN > applications (e.g., VR-based VPNs with BGP-based autodiscovery). > > With this in mind I'd like to propose to generalize the document. > Sounds good to me. Hamid. From exim@www1.ietf.org Thu Feb 5 01:51:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21161 for ; Thu, 5 Feb 2004 01:51:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AodLY-0004BY-Td for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 01:50:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i156oitR016084 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 01:50:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AodLY-0004BL-N1 for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 01:50:44 -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 BAA21157 for ; Thu, 5 Feb 2004 01:50:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AodLV-0001Jz-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 01:50:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AodKY-0001Fl-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 01:49:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AodJz-0001BI-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 01:49:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AodJt-00044I-SK; Thu, 05 Feb 2004 01:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AodJd-00043q-AD for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 01:48:45 -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 BAA21142 for ; Thu, 5 Feb 2004 01:48:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AodJa-0001As-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 01:48:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AodIf-00016d-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 01:47:45 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=alpha.jnpr.net) by ietf-mx with esmtp (Exim 4.12) id 1AodI2-0000x3-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 01:47:06 -0500 Received: from antiquark.jnpr.net ([172.24.18.153]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Feb 2004 22:46:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-l3vpn-gre-ip-2547-01.txt Date: Thu, 5 Feb 2004 14:46:34 +0800 Message-ID: <633FD71566107A418601A4B7A56AFF6704A1B995@antiquark.jnpr.net> Thread-Topic: draft-ietf-l3vpn-gre-ip-2547-01.txt Thread-Index: AcPrWmz9vIjPMGoSQ1yiODHyv3dP4gAWUN2g From: "Ananth Nagarajan" To: "Yakov Rekhter" , X-OriginalArrivalTime: 05 Feb 2004 06:46:37.0203 (UTC) FILETIME=[CD44FE30:01C3EBB3] Content-Transfer-Encoding: quoted-printable 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Yakov, I think generalizing is a logical step forward. I support the idea. Thanks, Ananth=20 > -----Original Message----- > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On=20 > Behalf Of Yakov Rekhter > Sent: Thursday, February 05, 2004 1:32 AM > To: l3vpn@ietf.org > Subject: draft-ietf-l3vpn-gre-ip-2547-01.txt >=20 > Folks, >=20 > draft-ietf-l3vpn-gre-ip-2547-01.txt talks about using GRE or=20 > IP tunnels instead of the outer label for 2547 VPNs. =20 > However, the same approach could be used for other MPLS VPN=20 > applications (e.g., VR-based VPNs with BGP-based autodiscovery). >=20 > With this in mind I'd like to propose to generalize the document. >=20 > Comments ??? >=20 > Yakov. >=20 >=20 >=20 From exim@www1.ietf.org Thu Feb 5 02:45:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05577 for ; Thu, 5 Feb 2004 02:45:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeBt-0007E8-Jg for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 02:44:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i157in8v027774 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 02:44:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeBt-0007Dt-6L for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 02:44:49 -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 CAA05556 for ; Thu, 5 Feb 2004 02:44:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoeBp-00067r-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 02:44:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoeB1-00061z-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 02:43:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoeA9-0005ui-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 02:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeA9-000768-1W; Thu, 05 Feb 2004 02:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeA1-00075m-T6 for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 02:42:54 -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 CAA05449 for ; Thu, 5 Feb 2004 02:42:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoe9y-0005t6-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 02:42:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoe8w-0005nC-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 02:41:47 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoe8R-0005h9-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 02:41:15 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Feb 2004 23:47:45 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i157ehDI015618; Wed, 4 Feb 2004 23:40:43 -0800 (PST) Received: from cisco.com (sj-rraszuk-vpn1.cisco.com [10.25.32.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APZ68183; Wed, 4 Feb 2004 23:40:41 -0800 (PST) Message-ID: <4021F375.9040403@cisco.com> Date: Wed, 04 Feb 2004 23:40:37 -0800 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard.spencer@bt.com CC: yakov@juniper.net, townsley@cisco.com, mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Richard, > in which case the same security > risks apply to MPLS 2547 networks and IP 2547 networks anyway. It would be interesting to see how did you achieved the above conclusion. If any PSN carries internet natively it seems much harder to inject MPLS labeled packets into them then IP packets. Of course one could protect such a network on all ingress points to accept any IP packet destined to a group of PE loopbacks used as next hops for IP 2547 and that is main protection scheme which should be applied in all IP 2547 networks. It is my understanding that Mark's proposal just attempts to deliver an extra protection layer for operator's mistakes where such an ingress ACL could be by mistake omitted or for whatever reason disabled on any external interface. Now signaling wise my personal opinion is that for operator's benefit both ways should be allowed. For those who use L2TPv3 for L2 transport and PE-PE L2TPv3 signaling is already in place it seems much more natural to extend it to carry extra information. For those who do not intend to use L2TP for L2 services using BGP which is already in place seems equally fine. The overhead incurred to distribute required information by BGP is pretty much negligible. Also looking at the extra signaling need when L2TP encapsulation is used in Inter-AS cases for IP 2547 BGP seems a bit better suited as well. In a lot scenarios ingress ACL protection of such a remote islands may not be always at all possible :-). Rgs, R. > richard.spencer@bt.com wrote: > Mark, > > The justification for using L2TP as opposed to IP or GRE > encapsulation over an IP PSN seems to be that security is improved. > However, from what I understand security in an IP/GRE encapsulated > PSN using 2547 is exactly the same as a PSN using MPLS, i.e. security > is not an issue and is comparable to FR/ATM. That is unless the same > PSN is to be used for carrying Internet traffic (natively, not inside > a VPN) and customer VPN traffic, in which case the same security > risks apply to MPLS 2547 networks and IP 2547 networks anyway. The > inherent problem being that IP the control traffic shares the same > data plane as the public Internet traffic, unlike ATM which uses an > out-of-band control plane (and is the only sensible solution to the > problem, i.e. use reserved labels for control/management traffic in > MPLS). > >> From an L2 perspective I can see that L2TP could be useful as it is >> well suited for encapsulating and signalling L2 tunnels. However, I >> do not see why L2TP is useful for L3 VPNs, why not just use GRE or >> IP encapsulations, which don't require any signalling? I could >> maybe understand if a provider was using L2TP for L2 services and >> wanted to reuse L2Tp for L3 services, but if so, why use BGP >> signalling why not use L2TP signalling? > > Also, I do not agree with the use of the phrase "RFC 2547 Style > VPNs", which is used several times within this draft. I would not > consider RFC2547 to be a 'style' of VPNs, I would consider RFC2547 to > be a specific VPN implementation, just like FR or ATM are specific > VPN implantations. Why is the word 'style' used? Why not just say RFC > 2547 VPNs? > > Richard > > >> -----Original Message----- From: owner-mpls@UU.NET >> [mailto:owner-mpls@UU.NET]On Behalf Of Yakov Rekhter Sent: 04 >> February 2004 20:55 To: W. Mark Townsley Cc: mpls@UU.NET; >> l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 >> VPNs >> >> >> Mark, >> >> >>> Yakov Rekhter wrote: >>> >>> >>>> Please document in your draft what is exactly "prudent" about >>>> BGP. >>> >>> Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide: >>> >>> "RFC2547 already provides an egress-to-ingress signaling >> >> capability via BGP, >> >>> and we specify below how to extend this to the signalling >> >> of security policy." >> >>> I will add this text to the l3vpn-l2tpv3 document: >>> >>> "RFC2547 already provides an egress-to-ingress signaling >> >> capability via BGP, >> >>> [NALAWADE] or [RAGGARWA] specifies how to extend this to >> >> the signaling of >> >>> L2TPv3 reachability information for a PE." >> >> Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does >> not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does >> *not* replace IPSec signaling with BGP. All it does is specifying >> how to use BGP to indicate whether a particular VPN on a PE should >> use IPSec to get traffic to that PE. >> >> In contrast your draft uses BGP not just to specify whether a >> particular VPN on a PE should use l2tp to get traffic to that PE, >> but also uses BGP to carry the l2tp session and cookie (l2tp >> signaling information). That is, in contrast to >> draft-ietf-l3vpn-ipsec-2547-01.txt your draft does replace the l2tp >> signaling protocol with BGP, thus eliminating the need for l2tp >> signaling with the l2tp signaling protocol. >> >> Just tell us why BGP signaling is any better than l2tp signaling. >> >> >>>> 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. >>> >>> No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label >> >> for a VPN-IPv4 >> >>> address distributed via RFC2547 extensions to BGP between >> >> PEs. I should not >> >>> extend this draft to cover other L3VPN models any more than >>> draft-ietf-l3vpn-ipsec-2547-01.txt or >> >> draft-ietf-l3vpn-gre-ip-2547-00.txt >> >>> should. Shall I rename it to something with "2547" in the >> >> title to be >> >>> more clear? >> >> First of all I'd like to thank you for pointing that both >> draft-ietf-l3vpn-ipsec-2547-01.txt or >> draft-ietf-l3vpn-gre-ip-2547-00.txt took a fairly narrow point of >> view. This is a bug, not a feature, and therefore it should be >> fixed. >> >> Second, the restriction on the applicability of your draft to 2547 >> is quite arbitrary. That is, there are *no* technical >> justifications for this restriction. And the fact that some other >> drafts took a fairly narrow view of the problem is no justification >> for continuing this. >> >> >>>>>> 3. The security claims have to be reviewed by the Security >>>>>> ADs. >>> >>> I am more than happy to have discussions with Security ADs >> >> on this topic. >> >> Thanks. Please post the outcome of this discussion to the list. >> >> Yakov. >> > > From exim@www1.ietf.org Thu Feb 5 07:35:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13426 for ; Thu, 5 Feb 2004 07:35:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoiic-0007LW-WB for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 07:34:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15CYsXS028237 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 07:34:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoiic-0007LM-Nb for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 07:34:54 -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 HAA13403 for ; Thu, 5 Feb 2004 07:34:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoiic-0001jF-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 07:34:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoihf-0001e1-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 07:33:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoigs-0001Ye-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 07:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoign-0007AE-7p; Thu, 05 Feb 2004 07:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoigf-00079s-TW for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 07:32:54 -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 HAA13333 for ; Thu, 5 Feb 2004 07:32:53 -0500 (EST) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoigf-0001Wq-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 07:32:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoifg-0001PO-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 07:31:53 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150] helo=i2kc02-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1Aoiel-0001EU-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 07:30:56 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by i2kc02-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 12:30:24 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 12:30:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: MPLS over L2TPv3 encap for RFC 2547 VPNs Date: Thu, 5 Feb 2004 12:30:23 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF318A@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: MPLS over L2TPv3 encap for RFC 2547 VPNs Thread-Index: AcPru2C8M9+o57meQ22woWrs6ruyRQAFUqEuAASJ33A= To: , Cc: , X-OriginalArrivalTime: 05 Feb 2004 12:30:23.0708 (UTC) FILETIME=[D39FE1C0:01C3EBE3] Content-Transfer-Encoding: base64 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpKdXN0IHRvIGFkZCB0byBSaWNoYXJkJ3MgKGNsb3NpbmcpIHJlbWFya3MgKGFu ZCBJIGhvcGUgeW91IGFsc28gc2F3IG15IG1vcmUgZ2VuZXJhbCBvbmVzIHdydCBnZW5lcmljIFZQ TnMgdGhlIG90aGVyIGRheSkuLi4uLi5oYXZpbmcgYW4gT09CIGNvbnRyb2wvbWFuYWdlbWVudC1w bGFuZSB3aGVyZSB0aGlzIGlzIHBvc3NpYmxlIGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBiZSBh bG1vc3QgYmUgYSBuby1icmFpbmVyIHJlcXVpcmVtZW50IGZvciBhbiBvcGVyYXRvci4gIEl0cyBz b21ldGhpbmcgSSB3b3VsZCB1cmdlIGFsbCBzdXBwbGllcnMgdG8gY2FyZWZ1bGx5IGNvbnNpZGVy Lg0KDQpyZWdhZHMsIE5laWwgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogb3duZXItbXBsc0BVVS5ORVQgW21haWx0bzpvd25lci1tcGxzQFVVLk5FVF1PbiBCZWhhbGYg T2YNCj4gcmljaGFyZC5zcGVuY2VyQGJ0LmNvbQ0KPiBTZW50OiAwNSBGZWJydWFyeSAyMDA0IDEx OjAxDQo+IFRvOiByYXN6dWtAY2lzY28uY29tDQo+IENjOiB5YWtvdkBqdW5pcGVyLm5ldDsgdG93 bnNsZXlAY2lzY28uY29tOyBtcGxzQFVVLk5FVDsgbDN2cG5AaWV0Zi5vcmcNCj4gU3ViamVjdDog UkU6IE1QTFMgb3ZlciBMMlRQdjMgZW5jYXAgZm9yIFJGQyAyNTQ3IFZQTnMNCj4gDQo+IA0KPiBS b2JlcnQsDQo+IA0KPiA+ID4gaW4gd2hpY2ggY2FzZSB0aGUgc2FtZSBzZWN1cml0eQ0KPiA+ID4g cmlza3MgYXBwbHkgdG8gTVBMUyAyNTQ3IG5ldHdvcmtzIGFuZCBJUCAyNTQ3IG5ldHdvcmtzIGFu eXdheS4NCj4gDQo+ID4gSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gc2VlIGhvdyBkaWQgeW91 IGFjaGlldmVkIHRoZSANCj4gYWJvdmUgY29uY2x1c2lvbi4gDQo+IA0KPiAgDQo+IA0KPiA+IElm IGFueSBQU04gY2FycmllcyBpbnRlcm5ldCBuYXRpdmVseSBpdCBzZWVtcyBtdWNoIGhhcmRlciAN Cj4gdG8gaW5qZWN0IE1QTFMNCj4gPiBsYWJlbGVkIHBhY2tldHMgaW50byB0aGVtIHRoZW4gSVAg cGFja2V0cy4NCj4gDQo+ICANCj4gDQo+IElmIHlvdSBkbyBub3QgYWdyZWUgd2l0aCBteSBjb25j bHVzaW9uIHRoZW4gSSB3b3VsZCBiZSANCj4gaW50ZXJlc3RlZCB0byBrbm93IGlmIHRoaXMganVz dCB5b3VyIG93biBwZXJzb25hbCB2aWV3PyBJIGFzayANCj4gYmVjYXVzZSBhdCBhIHNlbWluYXIg YSBmZXcgbW9udGhzIGFnbyBhdHRlbmRlZXMgd2VyZSBhc3N1cmVkIA0KPiBieSBDaXNjbyByZXBy ZXNlbnRhdGl2ZXMgdGhhdCB0aGUgZm9yd2FyZGluZyBvZiBWUE4gcGFja2V0cyANCj4gdXNpbmcg SVAvR1JFIHdhcyBqdXN0IGFzIHNlY3VyZSBhcyB1c2luZyBNUExTIGhlYWRlcnMuIFRoaXMgDQo+ IHdhcyByZWdhcmRpbmcgdGhlIHVzZSBvZiBHUkUgZm9yIG11bHRpY2FzdCB3aXRoIFJGQzI1NDcg VlBOcy4gDQo+IElmIHlvdSBkbyBub3QgYWdyZWUgd2l0aCB0aGlzIHRoZW4gYW0gSSB0byBhc3N1 bWUgdGhhdCBpbiANCj4geW91ciB2aWV3IFJGQzI1NDcgbmV0d29ya3MgYmVsb25naW5nIHRvIHBy b3ZpZGVycyB0aGF0IG9mZmVyIA0KPiBtdWx0aWNhc3Qgc2VydmljZXMgYXJlIG5vdCBhcyBzZWN1 cmUgYXMgcHJvdmlkZXIgbmV0d29ya3MgDQo+IHRoYXQgZG8gbm90IG9mZmVyIG11bHRpY2FzdCBz ZXJ2aWNlcz8NCj4gDQo+ICANCj4gDQo+IElNTyB0aGUgcHJpbWFyeSBzZWN1cml0eSBjb25jZXJu IGlzIHRoYXQgdGhlIGNvbnRyb2wgcGxhbmUgDQo+IHdpbGwgYmUgY29tcHJvbWlzZWQuIElmIElu dGVybmV0IHRyYWZmaWMgaXMgY2FycmllZCBuYXRpdmVseSANCj4gdGhlbiB0aGVyZSBpcyBhIHJp c2sgdGhhdCBhbiBpbnRydWRlciBtYXkgYXR0ZW1wdCB0byBhY2Nlc3MgDQo+IHRoZSBwcm92aWRl cnMgY29udHJvbCBwbGFuZSB2aWEgdGhlIEludGVybmV0IGJ5IHNwb29maW5nIA0KPiBjb250cm9s IHBhY2tldHMuIFRoaXMgc2VjdXJpdHkgY29uY2VybiBleGlzdHMgb24gaW5ncmVzcyB0byANCj4g dGhlIHByb3ZpZGVyIG5ldHdvcmsgc28gdGhlIFBTTiBlbmNhcHN1bGF0aW9uIHVzZWQgaXMgDQo+ IGlycmVsZXZhbnQuIEFzIHlvdSBzdWdnZXN0LCB1c2luZyBBQ0xzIGlzIG9uZSBzb2x1dGlvbiB0 byB0aGUgDQo+IHByb2JsZW0sIHVzaW5nIG91dC1vZi1iYW5kIHNpZ25hbGxpbmcgaXMgYW5vdGhl ciBzb2x1dGlvbi4NCj4gDQo+ICANCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiAgDQo+IA0KPiBSaWNo YXJkDQo+IA0K From exim@www1.ietf.org Thu Feb 5 07:57:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13952 for ; Thu, 5 Feb 2004 07:57:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj3w-0000CV-Ed for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 07:56:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15CuuUM000770 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 07:56:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj3w-0000CL-5h for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 07:56:56 -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 HAA13933 for ; Thu, 5 Feb 2004 07:56:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoj3v-0003br-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 07:56:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoj2y-0003Vl-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 07:55:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoj28-0003Qv-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 07:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj25-0008RA-VA; Thu, 05 Feb 2004 07:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj1z-0008PK-Ch for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 07:54: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 HAA13881 for ; Thu, 5 Feb 2004 07:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoj1x-0003QA-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 07:54:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoj13-0003LS-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 07:53:58 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Aoj0U-0003Fm-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 07:53:22 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2004 04:52:20 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i15CqnxH009150; Thu, 5 Feb 2004 07:52:50 -0500 (EST) Received: from cisco.com (rtp-vpn1-190.cisco.com [10.82.224.190]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWT91038; Thu, 5 Feb 2004 04:52:47 -0800 (PST) Message-ID: <40223C9E.7000209@cisco.com> Date: Thu, 05 Feb 2004 13:52:46 +0100 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard.spencer@bt.com CC: yakov@juniper.net, mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit richard.spencer@bt.com wrote: > Mark, > > The justification for using L2TP as opposed to IP or GRE encapsulation over > an IP PSN seems to be that security is improved. However, from what I Actually, the justification is 3-fold. As detailed in Section 5 "Applicability" of draft-townsley-l3vpn-l2tpv3-00.txt, the first two reasons have more to do with whether or not you are using L2TPv3 for other services on your network and wish to maintain a homogeneous type of tunneling encapsulation for MPLS as well as FR, ATM, etc. Incidentally, these two are precisely the same two reasons given for why one might choose a GRE encap vs. an IP encap. Security against blind spoofing attacks via the Cookie is identified as an additional reason for L2TPv3 over and above the other two reasons. > understand security in an IP/GRE encapsulated PSN using 2547 is exactly the > same as a PSN using MPLS, i.e. security is not an issue and is comparable to > FR/ATM. That is unless the same PSN is to be used for carrying Internet > traffic (natively, not inside a VPN) and customer VPN traffic, in which case > the same security risks apply to MPLS 2547 networks and IP 2547 networks > anyway. There are a number of references to the security concerns with respect to packet spoofing when running MPLS over IP or GRE. These stem from the comparative ability between MPLS and IP to block exterior traffic from penetrating the core network where the VPN is operating, and thus disallowing spoofed packets into the customer VPN. As I understand the argument, it is purported to be far easier to isolate an MPLS core by dropping labeled traffic from any non-core-facing interface than it would be to configure and maintain similarly-purposed L3ACLs on all non-core-facing interfaces of an IP core. This argument is mentioned in more detail in a number of places, including: draft-ietf-l3vpn-gre-ip-2547-00.txt, Section 7 draft-ietf-l3vpn-ipsec-2547-01.txt, Section 1.1, paragraph 3 "MPLS Technology and Applications," Davie, Rekhter, pg 217 > The inherent problem being that IP the control traffic shares the > same data plane as the public Internet traffic, unlike ATM which uses an > out-of-band control plane (and is the only sensible solution to the problem, > i.e. use reserved labels for control/management traffic in MPLS). Interesting, but how does carrying the control channel out of band help in a blind spoofing attack on the data plane (where one is merely guessing labels in attempt to break into a VPN)? > >> From an L2 perspective I can see that L2TP could be useful as it is well >> suited for encapsulating and signalling L2 tunnels. However, I do not see >> why L2TP is useful for L3 VPNs, why not just use GRE or IP encapsulations, >> which don't require any signalling? I could maybe understand if a provider >> was using L2TP for L2 services and wanted to reuse L2Tp for L3 services, >> but if so, why use BGP signalling why not use L2TP signalling? We are only advertising a single Session/Cookie per PE (not per PE pair, per VPN, etc). So, for the 2547 L3VPN case, we can include this Session/Cookie in the BGP Next Hop Update allowing it to become part of the single adjacency that gets built for sending all 2547 traffic over L2TPv3/IP to that PE. If we were performing any sort of p2p signaling, advertising any customer-facing interface parameters or IDs, signaling interface status, utilizing keepalives, etc. I would be more inclined to use the L2TP signaling, establishing individual sessions between PEs. > > Also, I do not agree with the use of the phrase "RFC 2547 Style VPNs", which > is used several times within this draft. I would not consider RFC2547 to be a > 'style' of VPNs, I would consider RFC2547 to be a specific VPN > implementation, just like FR or ATM are specific VPN implantations. Why is > the word 'style' used? Why not just say RFC 2547 VPNs? "RFC 2547 Style" - it's not my word. In fact, I was stumped as to what term to use myself, so I referred to draft-andersson-ppvpn-terminology-04.txt which uses "RFC 2547 Style" and "Virtual Router (VR) style" (Page 8-9 and in some figures) to differentiate between the two VPN methods. I'm happy to use any other accepted term. Hope this clarifies things, and thanks for the feedback, - Mark > > Richard > > >> -----Original Message----- From: owner-mpls@UU.NET >> [mailto:owner-mpls@UU.NET]On Behalf Of Yakov Rekhter Sent: 04 February 2004 >> 20:55 To: W. Mark Townsley Cc: mpls@UU.NET; l3vpn@ietf.org Subject: Re: >> MPLS over L2TPv3 encap for RFC 2547 VPNs >> >> >> Mark, >> >> >>> Yakov Rekhter wrote: >>> >>> >>>> Please document in your draft what is exactly "prudent" about BGP. >>> >>> Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide: >>> >>> "RFC2547 already provides an egress-to-ingress signaling >> >> capability via BGP, >> >>> and we specify below how to extend this to the signalling >> >> of security policy." >> >>> I will add this text to the l3vpn-l2tpv3 document: >>> >>> "RFC2547 already provides an egress-to-ingress signaling >> >> capability via BGP, >> >>> [NALAWADE] or [RAGGARWA] specifies how to extend this to >> >> the signaling of >> >>> L2TPv3 reachability information for a PE." >> >> Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does not >> work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does *not* replace >> IPSec signaling with BGP. All it does is specifying how to use BGP to >> indicate whether a particular VPN on a PE should use IPSec to get traffic >> to that PE. >> >> In contrast your draft uses BGP not just to specify whether a particular >> VPN on a PE should use l2tp to get traffic to that PE, but also uses BGP to >> carry the l2tp session and cookie (l2tp signaling information). That is, in >> contrast to draft-ietf-l3vpn-ipsec-2547-01.txt your draft does replace the >> l2tp signaling protocol with BGP, thus eliminating the need for l2tp >> signaling with the l2tp signaling protocol. >> >> Just tell us why BGP signaling is any better than l2tp signaling. >> >> >>>> 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. >>> >>> No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label >> >> for a VPN-IPv4 >> >>> address distributed via RFC2547 extensions to BGP between >> >> PEs. I should not >> >>> extend this draft to cover other L3VPN models any more than >>> draft-ietf-l3vpn-ipsec-2547-01.txt or >> >> draft-ietf-l3vpn-gre-ip-2547-00.txt >> >>> should. Shall I rename it to something with "2547" in the >> >> title to be >> >>> more clear? >> >> First of all I'd like to thank you for pointing that both >> draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt >> took a fairly narrow point of view. This is a bug, not a feature, and >> therefore it should be fixed. >> >> Second, the restriction on the applicability of your draft to 2547 is quite >> arbitrary. That is, there are *no* technical justifications for this >> restriction. And the fact that some other drafts took a fairly narrow view >> of the problem is no justification for continuing this. >> >> >>>>>> 3. The security claims have to be reviewed by the Security ADs. >>> >>> I am more than happy to have discussions with Security ADs >> >> on this topic. >> >> Thanks. Please post the outcome of this discussion to the list. >> >> Yakov. >> > > From exim@www1.ietf.org Thu Feb 5 07:57:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13957 for ; Thu, 5 Feb 2004 07:57:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj3x-0000Cs-CG for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 07:56:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15CuvJi000788 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 07:56:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj3x-0000Cd-7E for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 07:56:57 -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 HAA13936 for ; Thu, 5 Feb 2004 07:56:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoj3v-0003bw-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 07:56:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoj30-0003Vt-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 07:55:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoj28-0003Qw-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 07:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj27-0008Rg-I0; Thu, 05 Feb 2004 07:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoj20-0008PU-8d for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 07:54:56 -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 HAA13887 for ; Thu, 5 Feb 2004 07:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoj1y-0003QK-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 07:54:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoj16-0003Li-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 07:54:01 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Aoj0f-0003Gb-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 07:53:33 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Feb 2004 04:59:25 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i15Cr05j014198; Thu, 5 Feb 2004 04:53:00 -0800 (PST) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APZ80375; Thu, 5 Feb 2004 04:52:57 -0800 (PST) Message-ID: <40223CA5.9090802@cisco.com> Date: Thu, 05 Feb 2004 04:52:53 -0800 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: richard.spencer@bt.com, mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs References: <0536FC9B908BEC4597EE721BE6A3538904EF318A@i2km07-ukbr.domain1.systemhost.net> In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF318A@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Neil, I fully support and agree that control plane separation from forwarding and OOB control plane is the future which should happen as soon as possible. In fact some of this is already here in a lot of production networks in one form or the other. I am convinced that we will see more of those coming. But this thread is not about securing control plane but data plane so I think we should keep those quite orthogonal issues separate ;) Thx, R. PS, Regarding Richard's comment about seminar he attended I have not seen the material and therefore can't comment on it. > neil.2.harrison@bt.com wrote: > > Robert, > > Just to add to Richard's (closing) remarks (and I hope you also saw > my more general ones wrt generic VPNs the other day)......having an > OOB control/management-plane where this is possible is something that > should be almost be a no-brainer requirement for an operator. Its > something I would urge all suppliers to carefully consider. > > regads, Neil > > >> -----Original Message----- From: owner-mpls@UU.NET >> [mailto:owner-mpls@UU.NET]On Behalf Of richard.spencer@bt.com Sent: >> 05 February 2004 11:01 To: raszuk@cisco.com Cc: yakov@juniper.net; >> townsley@cisco.com; mpls@UU.NET; l3vpn@ietf.org Subject: RE: MPLS >> over L2TPv3 encap for RFC 2547 VPNs >> >> >> Robert, >> >> >>>> in which case the same security risks apply to MPLS 2547 >>>> networks and IP 2547 networks anyway. >> >>> It would be interesting to see how did you achieved the >> >> above conclusion. >> >> >> >> >>> If any PSN carries internet natively it seems much harder >> >> to inject MPLS >> >>> labeled packets into them then IP packets. >> >> >> >> If you do not agree with my conclusion then I would be interested >> to know if this just your own personal view? I ask because at a >> seminar a few months ago attendees were assured by Cisco >> representatives that the forwarding of VPN packets using IP/GRE was >> just as secure as using MPLS headers. This was regarding the use of >> GRE for multicast with RFC2547 VPNs. If you do not agree with this >> then am I to assume that in your view RFC2547 networks belonging to >> providers that offer multicast services are not as secure as >> provider networks that do not offer multicast services? >> >> >> >> IMO the primary security concern is that the control plane will be >> compromised. If Internet traffic is carried natively then there is >> a risk that an intruder may attempt to access the providers control >> plane via the Internet by spoofing control packets. This security >> concern exists on ingress to the provider network so the PSN >> encapsulation used is irrelevant. As you suggest, using ACLs is one >> solution to the problem, using out-of-band signalling is another >> solution. >> >> >> >> Regards, >> >> >> >> Richard >> From exim@www1.ietf.org Thu Feb 5 10:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18574 for ; Thu, 5 Feb 2004 10:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolAg-00085R-HZ for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 10:12:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15FC2Fs031079 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 10:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolAg-00085B-AQ for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:12:02 -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 KAA18493 for ; Thu, 5 Feb 2004 10:11:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolAe-0000yQ-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 10:12:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aol9i-0000sG-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 10:11:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aol8m-0000lB-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 10:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol8l-0007KR-3p; Thu, 05 Feb 2004 10:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aol7w-00076r-24 for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 10:09:12 -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 KAA18166 for ; Thu, 5 Feb 2004 10:09:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aol7t-0000dV-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 10:09:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aol70-0000XH-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 10:08:14 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Aol6f-0000Qc-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 10:07:53 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2004 07:06:46 -0800 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i15F7LxH007717; Thu, 5 Feb 2004 10:07:21 -0500 (EST) Message-Id: <200402051507.i15F7LxH007717@rtp-core-1.cisco.com> To: Yakov Rekhter cc: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-01.txt In-reply-to: Your message of Wed, 04 Feb 2004 12:02:19 -0800. <200402042002.i14K2Jh01112@merlot.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Feb 2004 10:07:21 -0500 From: Eric Rosen 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: , List-Id: List-Post: List-Help: List-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=AWL autolearn=no version=2.60 > However, the same approach could be used for other MPLS VPN applications > (e.g., VR-based VPNs with BGP-based autodiscovery). This document has been around a long time, and none of the folks who believe in VR-based VPNS (if there are even any still around) has bothered to contribute any text. If one of those folks wants to contribute some text, we could take a look at it, otherwise this seems like a non-issue. From exim@www1.ietf.org Thu Feb 5 10:49:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20285 for ; Thu, 5 Feb 2004 10:49:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolkT-0004Rn-CX for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 10:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Fn1uh017089 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 10:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolkT-0004RY-4V for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:49:01 -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 KAA20260 for ; Thu, 5 Feb 2004 10:48:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolkQ-0004Xr-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 10:48:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoljS-0004Rq-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 10:47:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoliX-0004NT-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 10:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoliX-0004L3-AK; Thu, 05 Feb 2004 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolhY-0004Hn-U8 for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 10:46:00 -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 KAA20191 for ; Thu, 5 Feb 2004 10:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolhW-0004Ig-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 10:45:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aolga-0004E8-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 10:45:01 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1Aolfn-00044g-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 10:44:11 -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 i15Fhel63752; Thu, 5 Feb 2004 07:43:40 -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 i15FhZh91447; Thu, 5 Feb 2004 07:43:35 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402051543.i15FhZh91447@merlot.juniper.net> To: erosen@cisco.com cc: Yakov Rekhter , l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-01.txt In-Reply-To: Your message of "Thu, 05 Feb 2004 10:07:21 EST." <200402051507.i15F7LxH007717@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98894.1075995815.1@juniper.net> Date: Thu, 05 Feb 2004 07:43:35 -0800 From: Yakov Rekhter 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: , List-Id: List-Post: List-Help: List-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 Eric, > > However, the same approach could be used for other MPLS VPN applications > > (e.g., VR-based VPNs with BGP-based autodiscovery). > > This document has been around a long time, and none of the folks who believe > in VR-based VPNS (if there are even any still around) has bothered to > contribute any text. If one of those folks wants to contribute some text, > we could take a look at it, otherwise this seems like a non-issue. I'll be glad to contribute the text. Yakov. From exim@www1.ietf.org Thu Feb 5 11:00:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20891 for ; Thu, 5 Feb 2004 11:00:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolvF-00061r-3g for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 11:00:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15G08Q4023169 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 11:00:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolvE-00061c-IU for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:00:08 -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 LAA20858 for ; Thu, 5 Feb 2004 11:00:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolvC-0005jf-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 11:00:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aolu9-0005d0-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 10:59:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoltF-0005W8-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 10:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoltB-0005S4-7W; Thu, 05 Feb 2004 10:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolsL-0005PJ-7q for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 10:57:09 -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 KAA20652 for ; Thu, 5 Feb 2004 10:57:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolsI-0005Oc-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 10:57:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolrM-0005Ga-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 10:56:09 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AolqS-00053b-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 10:55:12 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2004 07:54:06 -0800 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i15FsdYO026125; Thu, 5 Feb 2004 10:54:40 -0500 (EST) Message-Id: <200402051554.i15FsdYO026125@rtp-core-2.cisco.com> To: richard.spencer@bt.com cc: raszuk@cisco.com, yakov@juniper.net, townsley@cisco.com, mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs In-reply-to: Your message of Thu, 05 Feb 2004 11:00:35 +0000. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Feb 2004 10:54:39 -0500 From: Eric Rosen 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: , List-Id: List-Post: List-Help: List-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=AWL autolearn=no version=2.60 > If you do not agree with my conclusion then I would be interested to know > if this just your own personal view? I ask because at a seminar a few > months ago attendees were assured by Cisco representatives Really, should know better than to assume that any statement made on this list is a statement of corporate position. I would never assume that statements made by BT employees here reflect a corporate position. > the forwarding of VPN packets using IP/GRE was just as secure as using > MPLS headers. When comparing two security schemes, you need to look at the particular threat models of interest, the likelihood making mistakes in deploying the scheme, the limits of applicability of the scheme, etc. Without this context, it is meaningless to say that A is as secure as B. From exim@www1.ietf.org Thu Feb 5 11:17:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21786 for ; Thu, 5 Feb 2004 11:17:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomBZ-0008R3-3r for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 11:17:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GH1lZ032419 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 11:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomBY-0008Qo-Ur for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:17:01 -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 LAA21684 for ; Thu, 5 Feb 2004 11:16:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomBY-0007QS-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 11:17:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomAa-0007Ka-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 11:16:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aom9w-0007Ee-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 11:15:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom9f-0008Iz-Pb; Thu, 05 Feb 2004 11:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aom8n-0008BC-2c for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 11:14:09 -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 LAA21559 for ; Thu, 5 Feb 2004 11:14:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aom8m-00078r-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 11:14:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aom7l-00071e-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 11:13:06 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1Aom6t-0006pM-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 11:12:12 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id i15GBX3K026500; Thu, 5 Feb 2004 08:11:33 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.10/Submit) id i15GBXT2026499; Thu, 5 Feb 2004 08:11:33 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 5 Feb 2004 08:11:33 -0800 From: David Meyer To: richard.spencer@bt.com Cc: yakov@juniper.net, townsley@cisco.com, mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs Message-ID: <20040205161133.GA26422@1-4-5.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon 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: , List-Id: List-Post: List-Help: List-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=AWL autolearn=no version=2.60 Richard, >> Also, I do not agree with the use of the phrase "RFC 2547 Style >> VPNs", which is used several times within this draft. I would >> not consider RFC2547 to be a 'style' of VPNs, I would consider >> RFC2547 to be a specific VPN implementation, just like FR or ATM >> are specific VPN implantations. Why is the word 'style' used? >> Why not just say RFC 2547 VPNs? Well taken. FWIW, my recollection is that the term "style" crept in when we were thinking that there might be multiple kinds of L3 VPNs (the two notable instantiations were 2547 and VR). So we talked about 2547 style v. VR style L3VPNs. In any event, as you suggest, maybe its time to update our terminology. Dave [I must also admit that I use "2547 Style VPN" in the RIFT document, but will change that -- dmm] From exim@www1.ietf.org Thu Feb 5 11:30:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22439 for ; Thu, 5 Feb 2004 11:30:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomO9-0001bu-H2 for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 11:30:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GU1UC006173 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 11:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomO8-0001bB-Td for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:30:00 -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 LAA22392 for ; Thu, 5 Feb 2004 11:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomO8-0000xS-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 11:30:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomNA-0000r2-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 11:29:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AomMF-0000mI-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 11:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomMD-00011L-DS; Thu, 05 Feb 2004 11:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomLH-00010J-Iy for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 11:27:03 -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 LAA22296 for ; Thu, 5 Feb 2004 11:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomLG-0000gn-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 11:27:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomKP-0000ba-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 11:26:10 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AomJa-0000OE-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 11:25:18 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 05 Feb 2004 08:24:10 -0800 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i15GOgYO004002; Thu, 5 Feb 2004 11:24:46 -0500 (EST) Message-Id: <200402051624.i15GOgYO004002@rtp-core-2.cisco.com> To: Yakov Rekhter cc: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-01.txt In-reply-to: Your message of Thu, 05 Feb 2004 07:43:35 -0800. <200402051543.i15FhZh91447@merlot.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Feb 2004 11:24:42 -0500 From: Eric Rosen 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: , List-Id: List-Post: List-Help: List-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=AWL autolearn=no version=2.60 Eric> This document has been around a long time, and none of the folks who Eric> believe in VR-based VPNS (if there are even any still around) has Eric> bothered to contribute any text. If one of those folks wants to Eric> contribute some text, we could take a look at it, otherwise this seems Eric> like a non-issue. Yakov> I'll be glad to contribute the text. In your new role as chief advocate for VR-based VPNs? Or in your new role as ensurer of architectural and theoretical completeness? Wouldn't it be nice if we could keep a focus on practical problems and avoid debates about things that no one really cares about? After all, as someone once said, the proof of the pudding is in the eating, not in the debate about the pudding. :-) From exim@www1.ietf.org Thu Feb 5 13:08:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26710 for ; Thu, 5 Feb 2004 13:08:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AonvK-0003LY-Ci for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 13:08:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15I8MfU012852 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 13:08:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AonvJ-0003Ko-Dq for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 13:08:21 -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 NAA26658 for ; Thu, 5 Feb 2004 13:08:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AonvH-0003bk-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 13:08:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aonu9-0003JR-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 13:07:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aons8-0002wk-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 13:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aons7-0002gr-9C; Thu, 05 Feb 2004 13:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aonro-0002g9-AX for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 13:04:44 -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 NAA26252 for ; Thu, 5 Feb 2004 13:04:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aonrm-0002te-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 13:04:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AonqM-0002jU-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 13:03:14 -0500 Received: from mailgate1b.savvis.net ([216.91.182.6]) by ietf-mx with esmtp (Exim 4.12) id 1Aonpf-0002dD-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 13:02:31 -0500 Received: from sl6exch3.savvis.ad.savvis.net (sl6exch3.it.savvis.net [10.12.134.21]) by mailgate1b.savvis.net (8.12.9/8.12.1) with ESMTP id i15I0OaW020420; Thu, 5 Feb 2004 12:00:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-l3vpn-gre-ip-2547-01.txt Date: Thu, 5 Feb 2004 11:49:16 -0600 Message-ID: <51909D9AC2941E4F9D35B264D12CD7C2060990D9@sl6exch3> Thread-Topic: draft-ietf-l3vpn-gre-ip-2547-01.txt Thread-Index: AcPsBQ9RJdTR2SUETk6l2ohigOL6DgABgakw From: "Schliesser, Benson" To: , "Yakov Rekhter" Cc: X-ECS-MailScanner: No virus is found Content-Transfer-Encoding: quoted-printable 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Being employed by a service provider that provides (a fair number of) VR-based VPNs, I'd say it's unfair to suggest "no one really cares about" them. If you'd like to argue that there are fewer VR-based VPNs than BGP/MPLS-based VPNs deployed in the world, then I won't oppose. (although my curiosity would like to see some evidence of this) But even that doesn't obviate the need for addressing the 'practical problems' of the VR model. I'd be thankful if Yakov would generalize the draft. And just because I can't help myself, I have to add (...not intended to reflect upon the BGP/MPLS versus VR models, nor start any religious wars therein, just to make the point that your analogy isn't entirely fair): You can't assume a steakhouse is unworthy of attention simply because vastly more people eat fast-food hamburgers. -Benson -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On Behalf Of Eric Rosen Sent: Thursday, February 05, 2004 10:25 AM To: Yakov Rekhter Cc: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-01.txt=20 Eric> This document has been around a long time, and none of the folks Eric> who believe in VR-based VPNS (if there are even any still around) has Eric> bothered to contribute any text. If one of those folks wants to Eric> contribute some text, we could take a look at it, otherwise this=20 Eric> seems like a non-issue. Yakov> I'll be glad to contribute the text. In your new role as chief advocate for VR-based VPNs? Or in your new role as ensurer of architectural and theoretical completeness? Wouldn't it be nice if we could keep a focus on practical problems and avoid debates about things that no one really cares about? After all, as someone once said, the proof of the pudding is in the eating, not in the debate about the pudding. :-) From exim@www1.ietf.org Thu Feb 5 14:33:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00820 for ; Thu, 5 Feb 2004 14:33:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopFe-0000as-O7 for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 14:33:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15JXQAL002276 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 14:33:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopFe-0000ad-IC for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 14:33:26 -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 OAA00813 for ; Thu, 5 Feb 2004 14:33:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AopFc-0004yY-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 14:33:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AopEj-0004rm-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 14:32:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AopEG-0004k5-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 14:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopEG-0000UV-49; Thu, 05 Feb 2004 14:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopDa-0000Sz-86 for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 14:31:18 -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 OAA00597 for ; Thu, 5 Feb 2004 14:31:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AopDX-0004gz-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 14:31:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AopCh-0004ZF-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 14:30:24 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AopBo-0004Kk-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 14:29:28 -0500 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15JSud06085; Thu, 5 Feb 2004 11:28:56 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3VZ7ZB>; Thu, 5 Feb 2004 11:28:57 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93036C8B3C@zsc3c026.us.nortel.com> From: "Shashi Kiran" To: "'Yakov Rekhter'" , l3vpn@ietf.org Subject: RE: draft-ietf-l3vpn-gre-ip-2547-01.txt Date: Thu, 5 Feb 2004 11:28:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EC1D.E08BA722" 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: , List-Id: List-Post: List-Help: List-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.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EC1D.E08BA722 Content-Type: text/plain Yakov, We support this initiative. It fits in logically with the evolution of both our product/s as well as some of our customer networks. Rgds Shashi Kiran -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On Behalf Of Yakov Rekhter Sent: Wednesday, February 04, 2004 12:02 PM To: l3vpn@ietf.org Subject: draft-ietf-l3vpn-gre-ip-2547-01.txt Folks, draft-ietf-l3vpn-gre-ip-2547-01.txt talks about using GRE or IP tunnels instead of the outer label for 2547 VPNs. However, the same approach could be used for other MPLS VPN applications (e.g., VR-based VPNs with BGP-based autodiscovery). With this in mind I'd like to propose to generalize the document. Comments ??? Yakov. ------_=_NextPart_001_01C3EC1D.E08BA722 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-ietf-l3vpn-gre-ip-2547-01.txt

Yakov,

We support this initiative. It fits in logically with = the evolution of both our product/s as well as some of our customer = networks.

Rgds
Shashi Kiran


-----Original Message-----
From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] = On Behalf Of Yakov Rekhter
Sent: Wednesday, February 04, 2004 12:02 PM
To: l3vpn@ietf.org
Subject: draft-ietf-l3vpn-gre-ip-2547-01.txt


Folks,

draft-ietf-l3vpn-gre-ip-2547-01.txt talks about using = GRE or IP tunnels instead of the outer label for 2547 VPNs.  = However, the same approach could be used for other MPLS VPN = applications (e.g., VR-based VPNs with BGP-based = autodiscovery).

With this in mind I'd like to propose to generalize = the document.

Comments ???

Yakov.

------_=_NextPart_001_01C3EC1D.E08BA722-- From exim@www1.ietf.org Thu Feb 5 15:22:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04215 for ; Thu, 5 Feb 2004 15:22:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoq10-00056l-Fi for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 15:22:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15KMMYh019634 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 15:22:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoq10-00056b-9G for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 15:22:22 -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 PAA04159 for ; Thu, 5 Feb 2004 15:22:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoq0y-0002B5-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 15:22:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoq09-000257-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 15:21:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aopzj-0001xw-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 15:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopzi-0004TZ-DX; Thu, 05 Feb 2004 15:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopyu-0004HJ-Iu for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 15:20:12 -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 PAA03859 for ; Thu, 5 Feb 2004 15:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopyt-0001ve-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 15:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aopxy-0001qk-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 15:19:15 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1Aopxl-0001lM-00 for l3vpn@ietf.org; Thu, 05 Feb 2004 15:19:01 -0500 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i15KIJh16309; Thu, 5 Feb 2004 12:18:19 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1F3VZ98R>; Thu, 5 Feb 2004 12:18:20 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93036C8B3D@zsc3c026.us.nortel.com> From: "Shashi Kiran" To: "'Schliesser, Benson'" , erosen@cisco.com, Yakov Rekhter Cc: l3vpn@ietf.org Subject: RE: draft-ietf-l3vpn-gre-ip-2547-01.txt Date: Thu, 5 Feb 2004 12:18:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EC25.31E43D94" 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: , List-Id: List-Post: List-Help: List-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.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EC25.31E43D94 Content-Type: text/plain Right-on. We have fairly mature VR-based VPNs in our service provider customer networks. They still have among the fastest uptake with Enterprises willing to pay a premium for them in certain cases. The comments are in poor-taste, and not a realistic assessment of profitable service provider offerings. Rgds Shashi Kiran -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On Behalf Of Schliesser, Benson Sent: Thursday, February 05, 2004 9:49 AM To: erosen@cisco.com; Yakov Rekhter Cc: l3vpn@ietf.org Subject: RE: draft-ietf-l3vpn-gre-ip-2547-01.txt Being employed by a service provider that provides (a fair number of) VR-based VPNs, I'd say it's unfair to suggest "no one really cares about" them. If you'd like to argue that there are fewer VR-based VPNs than BGP/MPLS-based VPNs deployed in the world, then I won't oppose. (although my curiosity would like to see some evidence of this) But even that doesn't obviate the need for addressing the 'practical problems' of the VR model. I'd be thankful if Yakov would generalize the draft. And just because I can't help myself, I have to add (...not intended to reflect upon the BGP/MPLS versus VR models, nor start any religious wars therein, just to make the point that your analogy isn't entirely fair): You can't assume a steakhouse is unworthy of attention simply because vastly more people eat fast-food hamburgers. -Benson -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On Behalf Of Eric Rosen Sent: Thursday, February 05, 2004 10:25 AM To: Yakov Rekhter Cc: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-gre-ip-2547-01.txt Eric> This document has been around a long time, and none of the folks Eric> who believe in VR-based VPNS (if there are even any still around) has Eric> bothered to contribute any text. If one of those folks wants to Eric> contribute some text, we could take a look at it, otherwise this Eric> seems like a non-issue. Yakov> I'll be glad to contribute the text. In your new role as chief advocate for VR-based VPNs? Or in your new role as ensurer of architectural and theoretical completeness? Wouldn't it be nice if we could keep a focus on practical problems and avoid debates about things that no one really cares about? After all, as someone once said, the proof of the pudding is in the eating, not in the debate about the pudding. :-) ------_=_NextPart_001_01C3EC25.31E43D94 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-ietf-l3vpn-gre-ip-2547-01.txt

Right-on.

We have fairly mature VR-based VPNs in our service = provider customer networks. They still have among the fastest = uptake  with Enterprises willing to pay a premium for them in = certain cases. The comments are in poor-taste, and not a realistic = assessment of profitable service provider offerings.


Rgds
Shashi Kiran


-----Original Message-----
From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] = On Behalf Of Schliesser, Benson
Sent: Thursday, February 05, 2004 9:49 AM
To: erosen@cisco.com; Yakov Rekhter
Cc: l3vpn@ietf.org
Subject: RE: draft-ietf-l3vpn-gre-ip-2547-01.txt =



Being employed by a service provider that provides (a = fair number of) VR-based VPNs, I'd say it's unfair to suggest "no = one really cares about" them. If you'd like to argue that there = are fewer VR-based VPNs than BGP/MPLS-based VPNs deployed in the world, = then I won't oppose. (although my curiosity would like to see some = evidence of this) But even that doesn't obviate the need for addressing = the 'practical problems' of the VR model. I'd be thankful if Yakov = would generalize the draft.

And just because I can't help myself, I have to add = (...not intended to reflect upon the BGP/MPLS versus VR models, nor = start any religious wars therein, just to make the point that your = analogy isn't entirely fair): You can't assume a steakhouse is unworthy = of attention simply because vastly more people eat fast-food = hamburgers.

-Benson


-----Original Message-----
From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] = On Behalf Of Eric Rosen
Sent: Thursday, February 05, 2004 10:25 AM
To: Yakov Rekhter
Cc: l3vpn@ietf.org
Subject: Re: draft-ietf-l3vpn-gre-ip-2547-01.txt =



Eric> This document has  been around a long = time, and none  of the folks

Eric> who believe  in VR-based VPNS  (if = there  are even  any still
around) has
Eric> bothered  to contribute  any = text.   If one  of those  folks
wants to
Eric> contribute some text, we could take a look = at it, otherwise this
Eric> seems like a non-issue.

Yakov> I'll be glad to contribute the text.

In your new role  as chief advocate for VR-based = VPNs?  Or  in your new role as ensurer  of architectural = and  theoretical completeness? Wouldn't  it be nice if we = could keep a  focus on practical problems and avoid debates about = things that no one really cares about?  After all, as someone once = said, the proof of the pudding is in the eating, not in the debate = about the pudding.

:-)




------_=_NextPart_001_01C3EC25.31E43D94-- From exim@www1.ietf.org Thu Feb 5 15:46:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05594 for ; Thu, 5 Feb 2004 15:46:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqOH-0006xt-FJ for l3vpn-archive@odin.ietf.org; Thu, 05 Feb 2004 15:46:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15KkPdh026767 for l3vpn-archive@odin.ietf.org; Thu, 5 Feb 2004 15:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqOH-0006xe-B6 for l3vpn-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 15:46:25 -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 PAA05534 for ; Thu, 5 Feb 2004 15:46:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqOF-0004O2-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 15:46:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqNE-0004HB-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 15:45:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoqMy-0004BB-00 for l3vpn-web-archive@ietf.org; Thu, 05 Feb 2004 15:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqMx-0006ZV-Kl; Thu, 05 Feb 2004 15:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqMM-0006YO-9F for l3vpn@optimus.ietf.org; Thu, 05 Feb 2004 15:44:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05348; Thu, 5 Feb 2004 15:44:24 -0500 (EST) Message-Id: <200402052044.PAA05348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-ospf-2547-01.txt Date: Thu, 05 Feb 2004 15:44:23 -0500 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : OSPF as the PE/CE Protocol in BGP/MPLS VPNs Author(s) : E. Rosen Filename : draft-ietf-l3vpn-ospf-2547-01.txt Pages : 19 Date : 2004-2-5 This document specifies procedures to be used when a Service Provider (SP) provides 'BGP/MPLS IP VPN' service to a customer, and the customer uses OSPF to advertise its routes to the SP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ospf-2547-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-ospf-2547-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-ospf-2547-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-5155312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-ospf-2547-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-ospf-2547-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-5155312.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Fri Feb 6 11:14:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02839 for ; Fri, 6 Feb 2004 11:14:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8c3-0006Kt-P5 for l3vpn-archive@odin.ietf.org; Fri, 06 Feb 2004 11:13:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16GDp4B024349 for l3vpn-archive@odin.ietf.org; Fri, 6 Feb 2004 11:13:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8c3-0006Ke-JC for l3vpn-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 11:13:51 -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 LAA02800 for ; Fri, 6 Feb 2004 11:13:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8c2-0007KU-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 11:13:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8b8-0007GR-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 11:12:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8aI-0007Cq-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 11:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8aF-00063K-Ke; Fri, 06 Feb 2004 11:11:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap8a6-00061o-NU for l3vpn@optimus.ietf.org; Fri, 06 Feb 2004 11:11:50 -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 LAA02680 for ; Fri, 6 Feb 2004 11:11:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8a4-0007B9-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 11:11:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap8ZB-00078C-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 11:10:53 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Ap8YU-00072D-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 11:10:10 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Feb 2004 08:09:30 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i16G9cYO011792; Fri, 6 Feb 2004 11:09:38 -0500 (EST) Received: from cisco.com (ams-clip-vpn-dhcp177.cisco.com [10.61.64.177]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWU82813; Fri, 6 Feb 2004 08:09:36 -0800 (PST) Message-ID: <4023BC3F.5040101@cisco.com> Date: Fri, 06 Feb 2004 17:09:35 +0100 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs References: <200402041955.i14Jt8h00257@merlot.juniper.net> In-Reply-To: <200402041955.i14Jt8h00257@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > Mark, > > >>Yakov Rekhter wrote: >> >> >>>Please document in your draft what is exactly "prudent" about BGP. >> >>Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide: >> >>"RFC2547 already provides an egress-to-ingress signaling capability via BGP, >>and we specify below how to extend this to the signalling of security policy." >> >>I will add this text to the l3vpn-l2tpv3 document: >> >>"RFC2547 already provides an egress-to-ingress signaling capability via BGP, >>[NALAWADE] or [RAGGARWA] specifies how to extend this to the signaling of >>L2TPv3 reachability information for a PE." > > > Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does > not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does > *not* replace IPSec signaling with BGP. All it does is specifying > how to use BGP to indicate whether a particular VPN on a PE should > use IPSec to get traffic to that PE. Read again. The ipsec-2547 draft refers to encoding more than just whether or not to reach a PE via IPsec vs. MPLS (as if this is somehow OK, when advertising other bits of reachability information for the PE isn't). Specifically, the draft refers to encoding of the BGP "IPsec Extended Community" or "Tunnel Type Extended Community" to: - accept, deny, or direct traffic with different IPsec policies (e.g., how to process a packet based on the SPI received within the IPsec header). - determine if a PE may be reached via GRE or IP (e.g., which IP protocol type and header format to use). The l3vpn-l2tpv3 draft is encoding somewhat similar information. e.g., Accept an MPLS-labeled payload on the IP Protocol Type for L2TPv3, and process or drop it based on the Session/Cookie received in the L2TPv3 header. Bottom line, if you throw out one, you are really going to have to throw out the other. Niether of which I think is a good idea. > > In contrast your draft uses BGP not just to specify whether a > particular VPN on a PE should use l2tp to get traffic to that PE, > but also uses BGP to carry the l2tp session and cookie (l2tp signaling > information). That is, in contrast to draft-ietf-l3vpn-ipsec-2547-01.txt > your draft does replace the l2tp signaling protocol with BGP, thus > eliminating the need for l2tp signaling with the l2tp signaling > protocol. > > Just tell us why BGP signaling is any better than l2tp signaling. I will say it again. (1) This is an application of 2547 which is already using BGP, and (2) L2TP needs to distribute a *single* PE Session/Cookie to be used by every participating 2547-PE for VPN traffic destined to that PE (much like a single IP address is distributed to every participating PE for VPN traffic destined to that PE). > > >>>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. >> >>No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label for a VPN-IPv4 >>address distributed via RFC2547 extensions to BGP between PEs. I should not >>extend this draft to cover other L3VPN models any more than >>draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt >>should. Shall I rename it to something with "2547" in the title to be >>more clear? > > > First of all I'd like to thank you for pointing that both > draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt > took a fairly narrow point of view. This is a bug, not a feature, > and therefore it should be fixed. I have no problem with someone documenting how a VR-based VPN should work, but why do this in the same draft? Would you consider adding VR VPNs to 2547bis? > > Second, the restriction on the applicability of your draft to 2547 is > quite arbitrary. Hardly arbitrary. > That is, there are *no* technical justifications for this restriction. VRs and 2547 are different technical approaches, what technical justification is there for putting them in the *same* document? > And the fact that some other drafts took a fairly > narrow view of the problem is no justification for continuing this. And adding my document to the mix is justification for taking the other documents off course? Write some VR text. I have absolutely no problem with that. But procedurally or technically I don't see why 2547 and VR must be a part of the same document. - Mark > > >>>>>3. The security claims have to be reviewed by the Security ADs. >> >>I am more than happy to have discussions with Security ADs on this topic. > > > Thanks. Please post the outcome of this discussion to the list. > > Yakov. > From exim@www1.ietf.org Fri Feb 6 14:38:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11564 for ; Fri, 6 Feb 2004 14:38:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBna-0006DQ-DB for l3vpn-archive@odin.ietf.org; Fri, 06 Feb 2004 14:37:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Jbwgd023869 for l3vpn-archive@odin.ietf.org; Fri, 6 Feb 2004 14:37:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBnZ-0006Cm-9K for l3vpn-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 14:37:57 -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 OAA11537 for ; Fri, 6 Feb 2004 14:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBnW-00065j-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 14:37:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApBme-00061t-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 14:37:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApBli-0005xv-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 14:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBli-0005pn-KQ; Fri, 06 Feb 2004 14:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBld-0005oR-DP for l3vpn@optimus.ietf.org; Fri, 06 Feb 2004 14:35:57 -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 OAA11420 for ; Fri, 6 Feb 2004 14:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBla-0005wE-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 14:35:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApBkk-0005tE-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 14:35:03 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1ApBkS-0005pf-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 14:34:44 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i16JY5Bm015860; Fri, 6 Feb 2004 11:34:05 -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 i16JY5h26081; Fri, 6 Feb 2004 11:34:05 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402061934.i16JY5h26081@merlot.juniper.net> To: "W. Mark Townsley" cc: richard.spencer@bt.com, mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs In-Reply-To: Your message of "Thu, 05 Feb 2004 13:52:46 +0100." <40223C9E.7000209@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1033.1076096045.1@juniper.net> Date: Fri, 06 Feb 2004 11:34:05 -0800 From: Yakov Rekhter 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: , List-Id: List-Post: List-Help: List-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, richard.spencer@bt.com wrote: > > > Mark, > > > > The justification for using L2TP as opposed to IP or GRE encapsulation over > > an IP PSN seems to be that security is improved. However, from what I > > Actually, the justification is 3-fold. As detailed in Section 5 > "Applicability" of draft-townsley-l3vpn-l2tpv3-00.txt, the first > two reasons have more to do with whether or not you are using L2TPv3 > for other services on your network a nd wish to maintain a homogeneous > type of tunneling encapsulation for MPLS as we ll as FR, ATM, etc. If you already using l2tpv3 for other services, that means that you already using l2tpv3 signaling as well. So, why for 2547 you would use BGP as a signaling protocol ? > Incidentally, these two are precisely the same two reasons given > for why one might choose a GRE encap vs. an IP encap. The analogy does not work, as there is one significant difference between GRE and l2tpv3 - GRE encaps does not require any signaling, l2tpv3 does. [clipped...[ > >> From an L2 perspective I can see that L2TP could be useful as it is well > >> suited for encapsulating and signalling L2 tunnels. However, I do not see > >> why L2TP is useful for L3 VPNs, why not just use GRE or IP encapsulations, > >> which don't require any signalling? I could maybe understand if a provider > >> was using L2TP for L2 services and wanted to reuse L2Tp for L3 services, > >> but if so, why use BGP signalling why not use L2TP signalling? > > We are only advertising a single Session/Cookie per PE (not per PE pair, per > VPN, etc). So, for the 2547 L3VPN case, we can include this Session/Cookie in > the BGP Next Hop Update allowing it to become part of the single adjacency > that gets built for sending all 2547 traffic over L2TPv3/IP to that PE. Two points: 1. Could you please elaborate on the benefits of doing this relative to the use of l2tpv3 signaling. 2. In the VR case, we would only advertise a single Session/Cookie per PE (not per PE pair, per VPN, etc). So, for the VR L3VPN case, we can include this Session/Cookie in the BGP Next Hop Update allowing it to become part of the single adjacency that gets built for sending all VR VPN traffic over L2TPv3/IP to that PE. Which is exactly my point - from the BGP-based l2tp signaling exactly the same procedures are used for both VR and 2547. Yakov. From exim@www1.ietf.org Fri Feb 6 14:50:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11894 for ; Fri, 6 Feb 2004 14:50:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBzA-0007b4-PM for l3vpn-archive@odin.ietf.org; Fri, 06 Feb 2004 14:49:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16JnuTr029195 for l3vpn-archive@odin.ietf.org; Fri, 6 Feb 2004 14:49:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBzA-0007ao-J9 for l3vpn-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 14:49:56 -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 OAA11879 for ; Fri, 6 Feb 2004 14:49:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBz7-0006rn-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 14:49:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApByC-0006oP-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 14:48:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApBxJ-0006lK-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 14:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBxJ-0007UC-Jb; Fri, 06 Feb 2004 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBxG-0007Tk-Ng for l3vpn@optimus.ietf.org; Fri, 06 Feb 2004 14:47:58 -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 OAA11817 for ; Fri, 6 Feb 2004 14:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBxD-0006kU-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 14:47:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApBwL-0006hZ-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 14:47:01 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1ApBvz-0006dv-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 14:46:39 -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 i16Jk9l69086; Fri, 6 Feb 2004 11:46:09 -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 i16Jk3h27311; Fri, 6 Feb 2004 11:46:03 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200402061946.i16Jk3h27311@merlot.juniper.net> To: "W. Mark Townsley" cc: mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs In-Reply-To: Your message of "Fri, 06 Feb 2004 17:09:35 +0100." <4023BC3F.5040101@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5445.1076096763.1@juniper.net> Date: Fri, 06 Feb 2004 11:46:03 -0800 From: Yakov Rekhter 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: , List-Id: List-Post: List-Help: List-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, > > In contrast your draft uses BGP not just to specify whether a > > particular VPN on a PE should use l2tp to get traffic to that PE, > > but also uses BGP to carry the l2tp session and cookie (l2tp signaling > information). That is, in contrast to draft-ietf-l3vpn-ipsec-2547-01.txt > > your draft does replace the l2tp signaling protocol with BGP, thus > > eliminating the need for l2tp signaling with the l2tp signaling > > protocol. > > > > Just tell us why BGP signaling is any better than l2tp signaling. > > I will say it again. (1) This is an application of 2547 which is already usin g > BGP, and (2) L2TP needs to distribute a *single* PE Session/Cookie to be used by > every participating 2547-PE for VPN traffic destined to that PE (much like a > single IP address is distributed to every participating PE for VPN traffic > destined to that PE). Are you saying that just because an application uses BGP, the application should use BGP, instead of l2tp for l2tp signaling ? Or you saying that only when both (1) *and* (2) hold, then the application should use BGP, instead of l2tp for l2tp signaling ? > >>>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. > >> > >>No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label for a VPN-IPv4 > >>address distributed via RFC2547 extensions to BGP between PEs. I should not > >>extend this draft to cover other L3VPN models any more than > >>draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt > >>should. Shall I rename it to something with "2547" in the title to be > >>more clear? > > > > > > First of all I'd like to thank you for pointing that both > > draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt > > took a fairly narrow point of view. This is a bug, not a feature, > > and therefore it should be fixed. > > I have no problem with someone documenting how a VR-based VPN should work, bu t > why do this in the same draft? Would you consider adding VR VPNs to 2547bis? Based on the feedback received so far on the mailing list, I do plan to generalize draft-ietf-l3vpn-gre-ip-2547-00.txt. > > Second, the restriction on the applicability of your draft to 2547 is > > quite arbitrary. > > Hardly arbitrary. > > > That is, there are *no* technical justifications for this restriction. > > VRs and 2547 are different technical approaches, what technical justification > is there for putting them in the *same* document? Because from the l2tp point of view the procedures are exactly the same, whether it is 2547 or MPLS-based VR. Yakov. From exim@www1.ietf.org Fri Feb 6 17:29:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26262 for ; Fri, 6 Feb 2004 17:29:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApETD-0005Ln-0U for l3vpn-archive@odin.ietf.org; Fri, 06 Feb 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16MT6Ro020561 for l3vpn-archive@odin.ietf.org; Fri, 6 Feb 2004 17:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApETC-0005LY-PT for l3vpn-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 17:29:06 -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 RAA26205 for ; Fri, 6 Feb 2004 17:29:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApETA-00005J-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:29:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApES8-0007mK-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:28:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApERD-0007iZ-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApERB-0005CW-Lq; Fri, 06 Feb 2004 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApERA-0005Bt-AP for l3vpn@optimus.ietf.org; Fri, 06 Feb 2004 17:27:00 -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 RAA26120 for ; Fri, 6 Feb 2004 17:26:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApER7-0007hb-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 17:26:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEQB-0007eI-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 17:25:59 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ApEPE-0007YY-00 for l3vpn@ietf.org; Fri, 06 Feb 2004 17:25:00 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2004 14:31:09 +0000 Received: from cisco.com ([128.107.177.23]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i16MOS9T026959; Fri, 6 Feb 2004 14:24:28 -0800 (PST) Message-ID: <4024141A.8060105@cisco.com> Date: Fri, 06 Feb 2004 14:24:26 -0800 From: Gargi Reply-To: gargi@cisco.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: "W. Mark Townsley" , mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs References: <200402061946.i16Jk3h27311@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.1.1.86173 Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Yakov, >>every participating 2547-PE for VPN traffic destined to that PE (much like a >>single IP address is distributed to every participating PE for VPN traffic >>destined to that PE). > > > Are you saying that just because an application uses BGP, the application > should use BGP, instead of l2tp for l2tp signaling ? > > Or you saying that only when both (1) *and* (2) hold, then the application > should use BGP, instead of l2tp for l2tp signaling ? The l3vpn-l2tpv3 draft is no different from ppvpn-mpls-ip-gre-sig-00.txt Both describe how the same information about L2TPv3/GRE tunnel endpoints can be exchanged via BGP as one of the mechanisms. Neither draft mandates the use of BGP. One could use static configuration, LDP/l2tp signalling or BGP for the relevant tunnel endpoints to know this information. The use of the mechanism is upto the respective operator who chooses the machanism that suits their particular network. Also, the information carried in BGP (when BGP is chosen as the mechanism) is no different than the inner label that is exchanged via BGP. The inner label may be per-prefix, per VRF or whatever granularity depending on the implementation's choice and it is exchanged via BGP. It identifies to the rcvg router of the data packet how the packet is to be switched. In case of the tunnel endpoints for l2tp or gre tunnels, the tunnel information sent through BGP, also identifies to the receiver of the BGP update (and sender of the data packet) how the packet is to be switched. For the IP-VPN application, if there is no label-switching enabled in the core, and the tunnel endpoint becomes unreachable from the sender (of the data pkt) PE, the prefix loses reachability. In that sense, this is reachability information. Yes, the tunnel endpoint information - in case of generic l2tp & gre tunnels, could be exchanged through different signalling protocols. The application that justifies carrying the endpoint information in BGP is that in case of some applications such as IP-VPNs, this is indeed reachability information. And it is very analogous to the IGP reachability which sometimes gets injected into BGP. >>>>extend this draft to cover other L3VPN models any more than >>>>draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt >>>>should. Shall I rename it to something with "2547" in the title to be >>>>more clear? If it is ok to carry either of the above information in BGP, the l3vpn-l2tp draft just specifies on emore such class of information that could be exchanged via BGP. I see no difference. > Based on the feedback received so far on the mailing list, I do > plan to generalize draft-ietf-l3vpn-gre-ip-2547-00.txt. Excellent! I would vote for generalizing it such that doesnt matter whether the information is gre, l2tp or ipsec related - it could use the same BGP mechanism whenever BGP is the protocol to exchange any part of the information. Thanks, Gargi From exim@www1.ietf.org Fri Feb 6 17:34:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26499 for ; Fri, 6 Feb 2004 17:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEY0-0005eQ-Ch for l3vpn-archive@odin.ietf.org; Fri, 06 Feb 2004 17:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16MY4P2021716 for l3vpn-archive@odin.ietf.org; Fri, 6 Feb 2004 17:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEY0-0005dw-3v for l3vpn-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 17:34:04 -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 RAA26474 for ; Fri, 6 Feb 2004 17:34:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEXx-0000Tx-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:34:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEXA-0000Q0-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:33:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApEW1-0000Lv-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEW2-0005Rw-6O; Fri, 06 Feb 2004 17:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZ3Q-0000bX-KL for l3vpn@optimus.ietf.org; Wed, 04 Feb 2004 21:15:44 -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 VAA13622 for ; Wed, 4 Feb 2004 21:15:41 -0500 (EST) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoZ3O-000009-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 21:15:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoZ2T-0007i2-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 21:14:46 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138] helo=i2kc03-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AoZ1a-0007Vi-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 21:13:50 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 02:13:20 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 02:13:19 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: MPLS over L2TPv3 encap for RFC 2547 VPNs Date: Thu, 5 Feb 2004 02:13:18 -0000 Message-ID: Thread-Topic: MPLS over L2TPv3 encap for RFC 2547 VPNs Thread-Index: AcPrWgvYNwpeEMcQSj67xeC4f+CSnwAKuQ8g To: , Cc: , X-OriginalArrivalTime: 05 Feb 2004 02:13:19.0321 (UTC) FILETIME=[9F5EC490:01C3EB8D] Content-Transfer-Encoding: quoted-printable 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: , List-Id: List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mark, The justification for using L2TP as opposed to IP or GRE encapsulation = over an IP PSN seems to be that security is improved. However, from what = I understand security in an IP/GRE encapsulated PSN using 2547 is = exactly the same as a PSN using MPLS, i.e. security is not an issue and = is comparable to FR/ATM. That is unless the same PSN is to be used for = carrying Internet traffic (natively, not inside a VPN) and customer VPN = traffic, in which case the same security risks apply to MPLS 2547 = networks and IP 2547 networks anyway. The inherent problem being that IP = the control traffic shares the same data plane as the public Internet = traffic, unlike ATM which uses an out-of-band control plane (and is the = only sensible solution to the problem, i.e. use reserved labels for = control/management traffic in MPLS). >From an L2 perspective I can see that L2TP could be useful as it is well = suited for encapsulating and signalling L2 tunnels. However, I do not = see why L2TP is useful for L3 VPNs, why not just use GRE or IP = encapsulations, which don't require any signalling? I could maybe = understand if a provider was using L2TP for L2 services and wanted to = reuse L2Tp for L3 services, but if so, why use BGP signalling why not = use L2TP signalling? Also, I do not agree with the use of the phrase "RFC 2547 Style VPNs", = which is used several times within this draft. I would not consider = RFC2547 to be a 'style' of VPNs, I would consider RFC2547 to be a = specific VPN implementation, just like FR or ATM are specific VPN = implantations. Why is the word 'style' used? Why not just say RFC 2547 = VPNs? Richard=20 > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yakov > Rekhter > Sent: 04 February 2004 20:55 > To: W. Mark Townsley > Cc: mpls@UU.NET; l3vpn@ietf.org > Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs=20 >=20 >=20 > Mark, >=20 > > Yakov Rekhter wrote: > >=20 > > > Please document in your draft what is exactly "prudent" about BGP. > >=20 > > Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide: > >=20 > > "RFC2547 already provides an egress-to-ingress signaling=20 > capability via BGP,=20 > > and we specify below how to extend this to the signalling=20 > of security policy." > >=20 > > I will add this text to the l3vpn-l2tpv3 document: > >=20 > > "RFC2547 already provides an egress-to-ingress signaling=20 > capability via BGP,=20 > > [NALAWADE] or [RAGGARWA] specifies how to extend this to=20 > the signaling of=20 > > L2TPv3 reachability information for a PE." >=20 > Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does > not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does > *not* replace IPSec signaling with BGP. All it does is specifying > how to use BGP to indicate whether a particular VPN on a PE should > use IPSec to get traffic to that PE. >=20 > In contrast your draft uses BGP not just to specify whether a > particular VPN on a PE should use l2tp to get traffic to that PE, > but also uses BGP to carry the l2tp session and cookie (l2tp signaling > information). That is, in contrast to=20 > draft-ietf-l3vpn-ipsec-2547-01.txt > your draft does replace the l2tp signaling protocol with BGP, thus > eliminating the need for l2tp signaling with the l2tp signaling > protocol. >=20 > Just tell us why BGP signaling is any better than l2tp signaling. >=20 > > > That is, there is nothing in your draft that is specific to just=20 > > > 2547. E.g., it is equally applicable to VR based L3VPNs.=20 > Therefore, > > > the draft has to be generalized to cover any multipoint-to-point > > > application of MPLS over l2tp. > >=20 > > No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label=20 > for a VPN-IPv4=20 > > address distributed via RFC2547 extensions to BGP between=20 > PEs. I should not=20 > > extend this draft to cover other L3VPN models any more than=20 > > draft-ietf-l3vpn-ipsec-2547-01.txt or=20 > draft-ietf-l3vpn-gre-ip-2547-00.txt=20 > > should. Shall I rename it to something with "2547" in the=20 > title to be=20 > > more clear? >=20 > First of all I'd like to thank you for pointing that both > draft-ietf-l3vpn-ipsec-2547-01.txt or=20 > draft-ietf-l3vpn-gre-ip-2547-00.txt > took a fairly narrow point of view. This is a bug, not a feature, > and therefore it should be fixed. >=20 > Second, the restriction on the applicability of your draft to 2547 is > quite arbitrary. That is, there are *no* technical justifications > for this restriction. And the fact that some other drafts=20 > took a fairly=20 > narrow view of the problem is no justification for continuing this. >=20 > > >>>3. The security claims have to be reviewed by the Security ADs. > >=20 > > I am more than happy to have discussions with Security ADs=20 > on this topic. >=20 > Thanks. Please post the outcome of this discussion to the list. > =20 > Yakov.=20 >=20 From exim@www1.ietf.org Fri Feb 6 17:34:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26513 for ; Fri, 6 Feb 2004 17:34:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEY0-0005eB-9h for l3vpn-archive@odin.ietf.org; Fri, 06 Feb 2004 17:34:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16MY4CU021701 for l3vpn-archive@odin.ietf.org; Fri, 6 Feb 2004 17:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEXz-0005dn-Fu for l3vpn-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 17:34:04 -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 RAA26471 for ; Fri, 6 Feb 2004 17:33:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEXx-0000Ts-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:34:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEX6-0000Ps-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:33:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApEW1-0000Lu-00 for l3vpn-web-archive@ietf.org; Fri, 06 Feb 2004 17:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEW1-0005Rg-MF; Fri, 06 Feb 2004 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoNs8-00083n-SO for l3vpn@optimus.ietf.org; Wed, 04 Feb 2004 09:19:21 -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 JAA06823 for ; Wed, 4 Feb 2004 09:19:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoNs7-00015O-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 09:19:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoNrF-0000z1-00 for l3vpn@ietf.org; Wed, 04 Feb 2004 09:18:29 -0500 Received: from [213.163.128.164] (helo=shyguy.smb.utfors.se) by ietf-mx with esmtp (Exim 4.12) id 1AoNqC-0000nM-00; Wed, 04 Feb 2004 09:17:20 -0500 Received: from pi.se (md46909b9.utfors.se [212.105.9.185]) by shyguy.smb.utfors.se (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HSK00K6NCC7ZS@shyguy.smb.utfors.se>; Wed, 04 Feb 2004 15:02:46 +0100 (MET) Date: Wed, 04 Feb 2004 15:02:27 +0100 From: Loa Andersson Subject: Re: last call on terminology draft In-reply-to: <017a01c3eb03$e25c39b0$1702010a@Puppy> To: Adrian Farrel , l2vpn@ietf.org Cc: Tove Madsen , Rick Wilder , l3vpn@ietf.org Message-id: <4020FB73.9070503@pi.se> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 References: <20040120215626.64812.qmail@web109.biz.mail.yahoo.com> <017a01c3eb03$e25c39b0$1702010a@Puppy> Content-Transfer-Encoding: QUOTED-PRINTABLE 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Adrian, inline Adrian Farrel wrote: >Useful draft, thanks. > :) > >Mainly typos, attached. > >I find it odd that the list of drafts that depend on this terminolog= y draft are normative >references. This will delay the publication of this document as an R= FC and doesn't seem >necessary. > good point, we'll look into how will handle it > >Not sure if references such as draft-ppvpn-metrics.00.txt in section= 3.7 should actually >be handled as other references. Perhaps add a third references secti= on "Expired >References"? > this gives some idea of the "patina" of the draft, the metrics were important when we first wrote the terminology. I guess that the appro= priate thing to do is to mention the therer are drafts that has expired, som= etimes because they've been incorported in others, sometime because they ser= ved their purpose > >I wonder whether the sections are in the right order. The building b= lock terms from >section 5 get used throughout section 3. The early subsections in se= ction 3 refer to the >later subsections. But this is hardly important. > believe me, there are circular dependencies in the draft, which ever way you do you will have forward looking references We will look in to the typos /Loa > >You seem to be missing copyright and IPR statements. > >Cheers, >Adrian > > =20 > >--------------------------------------------------------------------= ---- > >L3VPN Working Group Loa Andersso= n >Internet-Draft Tove Madse= n >< TLA=A1gr= oup > =20 > >> TLA-group >> =20 >> >Expiration Date: March 2004 > > 25 September, 200= 3 > > PPVPN terminology > > > >Status of this Memo > > This document is an Internet-Draft and is in full conformance w= ith > all provisions of Section 10 of RFC2026 [RFC2026]. > > Internet-Drafts are working documents of the Internet Engineeri= ng > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet-Draf= ts > as reference material or to cite them other than as "work in > progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed a= t > http://www.ietf.org/shadow.html. > > For potential updates to the above required-text see: > http://www.ietf.org/ietf/1id-guidelines.txt > > >Abstract > >< The provider provisioned VPN solutions has attracted a great de= al >< of interest. Memos proposing different and overlapping solution > =20 > >> The provider provisioned VPN solutions have attracted a great de= al >> of interest. Memos proposing different and overlapping solutions >> =20 >> > have been discussed on the PPVPN mailing list and in the Workin= g >< Group meetings. This has lead to a development of a partly new > =20 > >> Group meetings. This has lead to the development of a partly new >> =20 >> > set of concepts used to describe the set of VPN services. To a >< certain extent there are more than one term covering the same >< concept and sometimes the same term covers more than on concept= . > =20 > >> certain extent there is more than one term covering the same >> concept and sometimes the same term covers more than one concept= . >> =20 >> > The terminology needs to be made clearer and more intuitive. Th= is > document seeks to fill at least part of that need. > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25= .09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 2] > >Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIO= NAL" > in this document are to be interpreted as described in RFC-211= 9 > [RFC2119]. > >Table of contents > >1. Introduction ....................................................= . 3 > >2. PPVPN Terminology ...............................................= . 4 > >3. Provider Provisioned Virtual Private Network services ...........= . 5 > 3.1 IP-only LAN-like Service (IPLS)..............................= . 5 > 3.2 Layer 2 VPN (L2VPN) .........................................= . 5 > 3.3 Layer 3 VPN (L3VPN) .........................................= . 5 > 3.4 Pseudo Wire (PW) ............................................= . 5 > 3.5 Transparent LAN Service (TLS)................................= . 6 > 3.6 Virtual LAN (VLAN) ..........................................= . 6 > 3.7 Virtual Leased Line Service (VLLS)...........................= . 6 > 3.8 Virtual Private LAN Service (VPLS)...........................= . 6 > 3.9 Virtual Private Network (VPN)................................= . 6 > 3.10 Virtual Private Switched Network (VPSN).....................= . 7 > 3.11 Virtual Private Wire Service (VPWS).........................= . 7 > >4. Classification of VPNs ..........................................= . 7 > >5. Building blocks .................................................= . 9 > 5.1 Customer Edge device (CE) ...................................= . 9 > 5.1.1 Device based CE naming.................................= . 9 > 5.1.2 Service based CE naming................................= 10 > 5.2 Provider Edge (PE) ..........................................= 10 > 5.2.1 Device based PE naming.................................= 11 > 5.2.2 Service based PE naming................................= 11 > 5.2.3 Distribution based PE naming...........................= 12 > 5.3 Core ........................................................= 12 > 5.3.1 Provider router (P) ...................................= 12 > 5.4 Naming in specific Internet drafts...........................= 12 > 5.4.1 Layer 2 PE (L2PE) .....................................= 12 > 5.4.2 Logical PE (LPE) ......................................= 13 > 5.4.3 PE-CLE ................................................= 13 > 5.4.4 PE-Core ...............................................= 13 > 5.4.5 PE-Edge ...............................................= 13 > 5.4.6 PE-POP ................................................= 13 > 5.4.7 VPLS Edge (VE) ........................................= 13 > >6. Functions .......................................................= 13 > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.= 09.03 > >=0C > >Andersson / Madsen Expires March 2004 [= Page 3] > > 6.1 Attachment Circuit (AC) ..................................= . 14 > 6.2 Backdoor Links ...........................................= . 14 > 6.3 Endpoint discovery .......................................= . 14 > 6.4 Flooding .................................................= . 14 > 6.5 MAC address learning .....................................= . 14 > 6.5.1 Qualified learning ..................................= . 14 > 6.5.2 Unqualified learning ................................= . 15 > 6.6 Signalling ...............................................= . 15 > >7. 'Boxes' .........................................................= . 15 > 7.1 Aggregation box ..........................................= . 15 > 7.2 Customer Premises Equipment (CPE).........................= . 15 > 7.3 Multi Tenant Unit (MTU) ..................................= . 16 > >8. Packet Switched Network (PSN) ...................................= . 16 > 8.1 Route Distinguisher (RD) .................................= . 16 > 8.2 Route Reflector ..........................................= . 16 > 8.3 Route Target (RT) ........................................= . 16 > 8.4 Tunnel ...................................................= . 17 > 8.5 Tunnel multiplexor .......................................= . 17 > 8.6 Virtual Channel (VC) .....................................= . 17 > 8.7 VC label .................................................= . 17 > 8.8 Inner label ..............................................= . 17 > 8.9 VPN Routing and Forwarding (VRF)..........................= . 17 > 8.10 VPN Forwarding Instance (VFI)............................= . 18 > 8.11 Virtual Switch Instance (VSI)............................= . 18 > 8.12 Virtual Router (VR) .....................................= . 18 > >9. Acknowledgements ................................................= . 18 > >10. Authors' Contact ...............................................= . 18 > >11. Normative References ...........................................= . 19 > >12. Non-Normative References .......................................= . 19 > > > >1. Introduction > >< There are a comparatively large number of memos being submit= ted to > =20 > >> There is a comparatively large number of memos being submitte= d to >> =20 >> > the former PPVPN, and L2VPN, L3VPN and PWE3 working groups t= hat >< all addresses the same problem space, provider provisioned v= irtual > =20 > >> all address the same problem space, provider provisioned virt= ual >> =20 >> > private networking for end customers. The memos address a wi= de > range of services, but there is also a great deal of commona= lity > among the proposed solutions. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [= Page 4] > >< This has lead to a development of a partly new set of concepts > =20 > >> This has lead to the development of a partly new set of concept= s >> =20 >> > used to describe this set of VPN services. To a certain extent >< there are more than one term covering the same concept and > =20 > >> there is more than one term covering the same concept and >> =20 >> > sometimes the same term covers more than one concept. The > terminology needs to be made clearer and more intuitive. > > This document seeks to fill at least part of the need and prop= oses > a foundation for a unified terminology for the L2VPN, L3VPN > working groups; in some cases the parallel concepts within the >< PWE3 working group is used as references. > =20 > >> PWE3 working group are used as references. >> =20 >> > > >2. PPVPN Terminology > > The concepts and terms in this list are gathered from Internet > Drafts sent to the L2VPN and L3VPN mailing lists (earlier PPVP= N > mailing list) and RFCs relevant to the L2VPN and L3VPN working > groups. The focus is on terminology and concepts that are spec= ific > to the PPVPN area, but this is not strictly enforced, e.g. the= re > are concepts and terms within the PWE3 and (Generalized) MPLS > areas that are closely related. We've tried to find the earlie= st > use of terms and concepts. > > This document intends to fully cover the concepts within five = core > documents from the L2VPN and L3VPN working groups the "Generic > Requirements for Provider Provisioned VPN" [GENERIC], the "A > Framework for Layer 3 Provider Provisioned Virtual Private > Networks" [L3VPN-frmwrk], the "Service requirements for Layer = 3 > Provider Provisioned Virtual Private Networks" [PPVPN-req], th= e > "L2VPN Framework [L2VPN-frmwrk] and "Service Requirements for > Layer 2 Provider Provisioned Virtual Private Networks" [L2VPN- > req]. The intention is to create a comprehensive and unified s= et > of concepts for these documents, and by extension for the enti= re >< PPVPNarea.Todosoitisalsonecessarytogivesomeofthe > =20 > >> PPVPN area. To do so it is also necessary to give some of the >> =20 >> >##huh?## development the concepts of the area have been through. > > The document is structured in four major sections. Section 4 l= ists >< the different services that has been/will be specified, Sectio= n 5 >< lists the building blocks that is used to specify those servic= es, > =20 > >> the different services that have been/will be specified, Sectio= n 5 >> lists the building blocks that are used to specify those servic= es, >> =20 >> > section 6 lists the functions needed in those services and sec= tion > 7 list some typical devices used in customer and provider > networks. > > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 = [Page 5] > >3. Provider Provisioned Virtual Private Network services > > In this section we define the terminology that relates the set= of > services to solutions specified by the L2VPN and L3VPN working > groups. The concept "pseudo wire" that belongs to the PWE3 wor= king > group is included for reference purposes. For requirements in > provider provisioned VPNs see [PPVPN-req]. > > In this section all abbreviations are listed in alphabetic ord= er. > >3.1 IP-only LAN-like Service (IPLS) > > An IPLS is very like a VPLS (see 3.8), except that: > > - it is assumed that the CE devices (see 5.1) are hosts or > routers, not switches > > - it is assumed that the service will only need to carry IP > packets, and supporting packets such as ICMP and ARP; > otherwise layer 2 packets which do not contain IP are not > supported. > > While this service is a functional subset of the VPLS service,= it > is considered separately because it may be possible to provide= it > using different mechanisms, which may allow it to run on certa= in > hardware platforms that cannot support the full VPLS functiona= lity > [PPVPN-L2-frmwrk]. > >3.2 Layer 2 VPN (L2VPN) > > Three types of L2VPNs are described in this document, Virtual >< Private Wire Service (VPWS) (section 3.11), VPLS Virtual Priva= te >< LAN Service (VPLS)(section 3.8), and IP-only LAN-like Service >< (IPLS). > =20 > >> Private Wire Service (VPWS) (section 3.11), Virtual Private >> LAN Service (VPLS) (section 3.8), and IP-only LAN-like Service >> (IPLS) (section 3.1). >> =20 >> > >3.3 Layer 3 VPN (L3VPN) > > An L3VPN is a solution that interconnects several sets of host= s > and routers and allows them to communicate based on L3 address= es, > see [L3VPN-frmwrk]. > >3.4 Pseudo Wire (PW) > >< The PWE3 working group within IETF specifies the pseudo wire > =20 > >> The PWE3 working group within the IETF specifies the pseudo wir= e >> =20 >> > technology. A pseudo wire is an emulated point-to-point >< connectivity over a packet switched network that gives the > =20 > >> connection over a packet switched network that gives the >> =20 >> > possibility to interconnect two nodes with any L2 technology. = The > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Page= 6] > > PW shares some of the building blocks and architecture construc= ts > with the point to multipoint solutions, e.g. PE (see 5.2) and C= E > (see 5.1). An early solution for PWs is described in [martini- > tran]. Encapsulation formats readily used in VPWS, VPLS and PWs > are described in [martini-encap]. Requirements for PWs are foun= d >< in [PWE3-req] and [PWE3-frmwrk] present an architectural framew= ork > =20 > >> in [PWE3-req] and [PWE3-frmwrk] presents an architectural framew= ork >> =20 >> > for PWs. > >3.5 Transparent LAN Service (TLS) > > TLS was an early name used to describe the VPLS service, it was > used e.g. in the now dated draft-lasserre-tls-mpls-00.txt. It h= as > been replaced by VPLS, which is the current term. > >3.6 Virtual LAN (VLAN) > > A VLAN is a way of separating traffic on a LAN, e.g. between > different departments within a company. This acronym is not > defined by former PPVPN working group, but is defined by IEEE > 802.1Q. The VLANID is used to mark an Ethernet frame with a tag= to > create user groups on a LAN. > >3.7 Virtual Leased Line Service (VLLS) > > The VLLS has been replaced by VPWS. It was used in now dated > draft-ppvpn-metrics.00.txt. > >3.8 Virtual Private LAN Service (VPLS) > > A VPLS is a provider service that emulates the full functionali= ty > of a traditional Local Area Network. A VPLS makes it possible t= o > interconnect several LAN segments over a packet switched networ= k > (PSN) and makes the remote LAN segments behave as one single LA= N. > For an early work on defining a solution and protocol for a VPL= S > see [L2VPN-req], [Lasserre-vkompella], and [Kompella-VPLS]. > > In a VPLS the provider network emulates a learning bridge and > forwarding decisions are taken based on MAC addresses or MAC > addresses and VLAN tag. > >3.9 Virtual Private Network (VPN) > > VPN is a generic term that covers the use of public or private > networks to create groups of users that are separated from othe= r > network users and may communicate among them as if they were on= a >< private network. The level of separation is possible to enhance > =20 > >> private network. It is possible to enhance the level of separati= on >> =20 >> > e.g. by end-to-end encryption, this is however outside the scop= e > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.09= .03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 7] > > of IETF VPN working group charters. This VPN definition is fro= m > [RFC2764]. > > In the [L3VPN-frmwrk] the term VPN is used to refer to a speci= fic > set of sites as either an intranet or an extranet that have be= en > configured to allow communication. Note that a site is a membe= r of > at least one VPN, and may be a member of many VPNs. > > In this document "VPN" is also used as a generic name for all > services listed in section 3. > >3.10 Virtual Private Switched Network (VPSN) > > A VPSN is replaced by VPLS. The VPSN abbreviation was used e.g= . in > the now dated draft-vkompella-ppvpn-vpsn.reqmts-00.txt. > >3.11 Virtual Private Wire Service (VPWS) > > A Virtual Private Wire Service (VPWS) is a point-to-point circ= uit > (link) connecting two Customer Edge devices. The CE in the > customer network is connected to a PE in the provider network = via > an Attachment Circuit (see 6.1); the Attachment Circuit is eit= her > a physical or a logical circuit. > >< The PE's in the core network is connected via a PW. > =20 > >> The PE's in the core network are connected via a PW. >> =20 >> > > The CE devices can be routers, bridges, switches or hosts. In = some > implementations a set of VPWSs is used to create a multi-site > L2VPN network. An example of a VPWS solution is described in > [L2VPN]. > >< A VPWS differs from a VPLS (section 4.8) in that the VPLS is p= oint > =20 > >> A VPWS differs from a VPLS (section 3.8) in that the VPLS is po= int >> =20 >> > to multipoint, while the VPWS is point to point. See [L2VPN- > frmwrk]. > > >4. Classification of VPNs > > The terminology used in [GENERIC] is defined based on the figu= re > below. > > > > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.= 09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 8] > > PPVPN > ________________|__________________ > | | > Layer 2 Layer 3 > ______|_____ ______|______ > | | | | > P2P P2M PE-based CE-based > (VPWS) _____|____ ______|____ | > | | | | | > VPLS IPLS RFC2547 Virtual IPsec > Style Router > > > The figure above presents a taxonomy of PPVPN technologies. Som= e > of the definitions are given below: > > CE-based VPN: A VPN approach in which the shared service provid= er > network does not have any knowledge of the customer VPN. This > information is limited to CE equipment. All the VPN-specific > procedures are performed in the CE devices, and the PE devices = are > not aware in any way that some of the traffic they are processi= ng > is VPN traffic (see also [L3VPN-frmwrk]). > > PE-Based VPNs: A Layer 3 VPN approach in which a service provid= er > network is used to interconnect customer sites using shared > resources. Specifically the PE device maintains VPN state, > isolating users of one VPN from users of another VPN. Because t= he > PE device maintains all required VPN state, the CE device may > behave as if it were connected to a private network. Specifical= ly, > the CE in a PE-based VPN must not require any changes or > additional functionality to be connected to a PPVPN instead of = a > private network. > > The PE devices know that certain traffic is VPN traffic. They > forward the traffic (through tunnels) based on the destination = IP >< address of the packet, and optionally on based on other > =20 > >> address of the packet, and optionally based on other >> =20 >> > information in the IP header of the packet. The PE devices are > themselves the tunnel endpoints. The tunnels may make use of > various encapsulations to send traffic over the SP network (suc= h > as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS >< tunnels)[L3VPN-frmwrk]. > =20 > >> tunnels) [L3VPN-frmwrk]. >> =20 >> > > > Virtual Router (VR) style: A PE-based VPN approach in which the= PE > router maintains a complete logical router for each VPN that it > supports. Each logical router maintains a unique forwarding tab= le > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [= Page 9] > > and executes a unique instance of the routing protocols. These > VPNs are described in [PPVPN-VR]. > > RFC 2547 Style: A PE-based VPN approach in which the PE router > maintains separate forwarding environment for each VPN and a > separate forwarding table for each VPN. In order to maintain > multiple forwarding table instances while running only a singl= e > routing protocol instance, RFC 2547 style VPNs mark route > advertisements with attributes that identify their VPN context= . > These VPNs are based on the approach described in [RFC2547bis]= . > > >5. Building blocks > > Starting with specifications of L3VPNs, e.g. the 2547 > specification [RFC2547] and [RFC2547bis] and Virtual Routers > [PPVPN-VR], a way of describing the building blocks and alloca= tion > of functions in VPN solutions was developed. The building bloc= ks >< are often in day-to-day talk treated as if it were physical bo= xes, >< common for all services. > =20 > >> are often used in day-to-day talk as if they were physical boxe= s, >> common to all services. >> =20 >> > >< However, for different reasons this is to over-simplify. Any o= f > =20 > >> However, for different reasons this is an over-simplification. = Any of >> =20 >> > the building blocks could be implemented across more than one > physical box. How common the use of such implementations will = be > is beyond the scope of this document. > >5.1 Customer Edge device (CE) > > A CE is the name of the device with the functionality needed o= n > the customer premises to access the services specified by the > former PPVPN working group. > > There are two different aspects that need to be considered in > naming CE devices. One could start with the type of device tha= t is > used to implement the CE (see section 5.1.1). It is also possi= ble > to use the service the CE provides and with the result it will= be > a set of "prefixed CEs", (see section 5.1.2). > > It is common practice to use "CE" to indicate any of these box= es, > since it is very often unambiguous in the specific context. > >5.1.1 Device based CE naming > > >5.1.1.1 Customer Edge Router (CE-R) > > A CE-R is a router in the customer network interfacing the > provider network. There are many reasons to use a router in th= e > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 10] > > customer network, e.g. in an L3VPN using private IP addressin= g > this is the router that is able to do forwarding based on the > private addresses. Another reason to require the use of a CE-= R on > the customer side is that one want to limit the number on MAC= - > addresses that needs to be learnt in the provider network. > > A CE-R could be used to access both L2 and L3 services. > > >5.1.1.2 Customer Edge Switch (CE-S) > > A CE-S is a service aware L2 switch in the customer network > interfacing the provider network. In a VPWS or a VPLS it is n= ot > strictly necessary to use a router in the customer network, a > layer 2 switch might very well do the job. > >5.1.2 Service based CE naming > > The list below is just examples and it will be extended as th= e > number of services increases. > > >5.1.2.1 L3VPN-CE > > An L3VPN-CE is the device or set of devices on the customer > premises that attaches to a provider provisioned L3VPN, e.g. = a > 2547bis implementation. > > >5.1.2.2 VPLS-CE > > A VPLS-CE is the device or set of devices on the customer pre= mises > that attaches to a provider provisioned VPLS. > > >5.1.2.3 VPWS-CE > > A VPWS-CE is the device or set of devices on the customer pre= mises > that attaches to a provider provisioned VPWS. > >5.2 Provider Edge (PE) > > A PE is the name of the device or set of devices at the edge = of > the provider network with the functionality that is needed to > interface the customer. PE, without further qualifications, i= s > very often used for naming the devices since it is made > unambiguous by the context. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25= .09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 11] > > In naming PEs there are three aspects that we need to conside= r, > the service they support, whether the functionality needed fo= r > service is distributed across more than one device and the ty= pe of > device they are build on. > >5.2.1 Device based PE naming > > Both routers and switches may be used to implement PEs, howev= er > the scaling properties will be radically different depending = which >< type of equipment that is chosen. > =20 > >> type of equipment is chosen. >> =20 >> > > >5.2.1.1 Provider Edge Router (PE-R) > > A PE-R is a L3 device that participates in the PSN (see secti= on 8) > routing and forwards packets based on the routing information= . > > >5.2.1.2 Provider Edge Switch (PE-S) > >< APE-SisaL2devicethatparticipatesine.g.aswitched > =20 > >> A PE-S is a L2 device that participates in e.g. a switched >> =20 >> > Ethernet taking forwarding decision packets based on L2 addre= ss > information. > >5.2.2 Service based PE naming > > >5.2.2.1 L3VPN-PE > > An L3VPN-PE is a device or set of devices at the edge of the > provider network interfacing the customer network, with the > functionality needed for an L3VPN. > > >5.2.2.2 VPWS-PE > > A VPWS-PE is a device or set of devices at the edge of the > provider network interfacing the customer network, with the > functionality needed for a VPWS. > > >5.2.2.3 VPLS-PE > > A VPLS-PE is a device or set of devices at the edge of the > provider network interfacing the customer network, with the > functionality needed for a VPLS. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 12] > >5.2.3 Distribution based PE naming > > For scaling reasons it is in the VPLS/VPWS cases sometimes de= sired > to distribute the functions in the VPLS/VPWS-PE across more t= han > one device, e.g. is it feasible to allocate MAC address learn= ing > on a comparatively small and in-expensive device close to the > customer site, while participation in the PSN signalling and = set > up of PE to PE tunnels are done by routers closer to the netw= ork > core. > > When distributing functionality across devices a protocol is > needed to exchange information between the Network facing PE = (N- > PE) see section 5.2.3.1 and the User facing PE (U-PE) see sec= tion > 5.2.3.2. > > >5.2.3.1 Network facing PE (N-PE) > > The N-PE is the device to which the signalling and control > functions are allocated when a VPLS-PE is distributed across = more > than one box. > > >5.2.3.2 User facing PE (U-PE) > > The U-PE is the device to which the functions needed to take > forwarding or switching decision at the ingress of the provid= er > network. > >5.3 Core > >5.3.1 Provider router (P) > >< ThePisdefinedasarouterinthecorenetworkthatdoesnot > =20 > >> The P is defined as a router in the core network that does not >> =20 >> > have interfaces directly towards a customer. Hence a P router= does > not need to keep VPN state and is VPN un-aware. > >5.4 Naming in specific Internet drafts > >5.4.1 Layer 2 PE (L2PE) > > L2PE is the joint name of the devices in the provider network= that > implement L2 functions needed for a VPLS or a VPWS. > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.= 09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 13] > >5.4.2 Logical PE (LPE) > > The term Logical PE (LPE) originates from a dated Internet Dr= aft > "VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical = PE > Architecture" and was used to describe a set of devices used = in a > provider network to implement a VPLS. In a LPE, VPLS function= s are > distributed across small devices (PE-Edges/U-PE) and devices > attached to a network core (PE-Core/N-PE). In an LPE solution= the > PE-edge and PE-Core can be interconnected by a switched Ether= net > transport network(s) or uplinks. The LPE will appear to the c= ore > network as a single PE. In this document the devices that > constitutes the LPE is called N-PE and U-PE. > >5.4.3 PE-CLE > > An alternative name for the U-PE suggested in now dated Inter= net > Draft "VPLS architectures". > >5.4.4 PE-Core > > See the origins and use of this concept in section 5.4.2. > >5.4.5 PE-Edge > > See the origins and use of this concept in section 5.4.2. > >5.4.6 PE-POP > > An alternative name for the U-PE suggested in now dated Inter= net > Draft "VPLS architectures". > >5.4.7 VPLS Edge (VE) > > The term VE originates from a dated Internet Draft on a > distributed transparent LAN service and was used to describe = the >< deviceusedbyaprovidernetworktohandoffaVPLStoa > =20 > >> device used by a provider network to hand off a VPLS to a >> =20 >> > customer. In this document the VE is called a VPLS-PE. > > This name has dated. > > >6. Functions > > In this section we have grouped a number of concepts and term= s >< that has to be performed to make the VPN services work. > =20 > >> that have to be performed to make the VPN services work. >> =20 >> > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [P= age 14] > >6.1 Attachment Circuit (AC) > > In a Layer 2 VPN the CE is attached to PE via an Attachment > Circuit (AC). The AC may be a physical or logical link. > > >6.2 Backdoor Links > > Backdoor Links are links between CE devices that are provided= by > the end customer rather than the SP; may be used to interconn= ect > CE devices in multiple-homing arrangements [L3VPN-frmwrk]. > >6.3 Endpoint discovery > > Endpoint discovery is the process by which the devices that a= re > aware of a specific VPN service will find all customer facing > ports that belong to the same service. > > The requirements on endpoint discovery and signalling are > discussed in [PPVPN-req]. It was also the topic in a now date= d > Internet Draft reporting from a design team activity on VPN > discovery. > >6.4 Flooding > > Flooding is a function related to L2 and L3 services; when a = PE > receives a frame with an unknown destination MAC-address, tha= t > frame is send out over (flooded) every other interface. > >6.5 MAC address learning > > MAC address learning is a function related to L2 services; wh= en PE > receives a frame with an unknown source MAC-address the > relationship between that MAC-address and interface is learnt= for > future forwarding purposes. In a layer 2 VPN solution from th= e > L2VPN WG, this function is allocated to the VPLS-PE. > >6.5.1 Qualified learning > > In qualified learning, the learning decisions at the U-PE are > based on the customer Ethernet frame's MAC address and VLAN t= ag, > if a VLAN tag exists. If no VLAN tag exists, the default VLAN= is > assumed. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 15] > >6.5.2 Unqualified learning > > In unqualified learning, learning is based on a customer Ethe= rnet > frame's MAC address only. > >6.6 Signalling > > Signalling is the process by which the PEs that have VPNs beh= ind > them exchange information to set up PWs, PSN tunnels and tunn= el > multiplexers. This process might be automated through a proto= col > or done by manual configuration. Different protocols may be u= sed > to establish the PSN tunnels and exchange the tunnel multiple= xers. > > > > >7. 'Boxes' > > We list a set of boxes that will typically be used in an > environment that supports different kinds of VPN services. We= have > chosen to include some names of boxes that originate outside = the > protocol specifying organisations. > >7.1 Aggregation box > > The aggregation box is typically an L2 switch that is service > unaware and is used only to aggregate traffic to more functio= n > rich points in the network. > >7.2 Customer Premises Equipment (CPE) > > The CPE equipment is the box that a provider places with the > customer. It serves two purposes, giving the customer ports t= o > plug in to and making it possible for a provider to monitor t= he > connectivity to the customer site. The CPE is typically a low= cost > box with limited functionality and in most cases not aware of= the > VPN services offered by the provider network. > > The CPE equipment is not necessarily the equipment to which t= he CE > functions are allocated, but is part of the provider network = and > used for monitoring purposes. > > The CPE name is used primarily in network operation and deplo= yment > contexts, and should not be used in protocol specifications. > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 16] > >7.3 Multi Tenant Unit (MTU) > > An MTU [DTLS] is typically an L2 switch placed by a service > provider in a building where customers of that service provid= er > are located. > > The MTU device name is used primarily in network operation an= d > deployment contexts, and should not be used in protocol > specifications, as it is also a used abbreviation for Maximum > Transmit Units. > > >8. Packet Switched Network (PSN) > > A PSN is the network through which the tunnels supporting the= VPN > services are set up. > >8.1 Route Distinguisher (RD) > > A Route Distinguisher [RFC2547bis] is an 8-byte value that > togetherwitha4byteIPv4addressidentifiesaVPN-IPv4address > family. If two VPNs use the same IPv4 address prefix, the PEs > translates these into unique VPN-IPv4 address prefixes. This > ensures that if the same address is used in two different VPN= s, it > is possible to install two completely different routes to tha= t > address, one for each VPN. > >8.2 Route Reflector > > A route reflector is a network element owned by a Service Pro= vider > (SP) that is used to distribute BGP routes to the SP's BGP-en= abled > routers [L3VPN-frmwrk]. > >8.3 Route Target (RT) > > A Route Target attribute [RFC2547bis] can be thought of as > identifying a set of sites, or more precisely a set of VRFs (= see > section 8.8). > > Associating a particular Route Target with a route, allows th= at > route to be placed in all VRFs that are used for routing traf= fic > received from the corresponding sites. > > A Route Target attribute is also a BGP extended community use= d in > [RFC2547], and [BGPVPN-auto]. A Route Target community is use= d to > constrain VPN information distribution to the set of VRFs. A = route > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25= .09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 17] > > target can be perceived as identifying a set of sites, or mor= e > precisely a set of VRFs. > >8.4 Tunnel > > A tunnel is connectivity through a PSN that is used to send > traffic across the network from one PE to another. The tunnel > provides a mechanism to transport packets from one PE to anot= her, > separation of one customer's traffic from another customer's > traffic is done based on tunnel multiplexers (see section 8.4= ). > How the tunnel is established depends on the tunnelling mecha= nisms > provided by the PSN, i.e. the tunnel could be based on e.g. t= he > IP-header, an MPLS label, the L2TP Session ID, or on the GRE = Key > field. > >8.5 Tunnel multiplexor > > A tunnel multiplexor is an entity that is sent with the packe= ts > traversing the tunnel to make possible to decide to which ins= tance > of a service a packet belongs and from which sender it was > received. In [L2VPN] the tunnel multiplexor is formatted as a= n > MPLS label. > >8.6 Virtual Channel (VC) > > A VC is transported within a tunnel and identified by its tun= nel > multiplexer. A virtual channel is identified by a VCI (Virtua= l > Channel Identifier). In the PPVPN context a VCI is a VC label= or > tunnel multiplexer and in the Martini case it is equal to the > VCID. > >8.7 VC label > > In an MPLS enabled IP network a VC label is an MPLS label, us= ed to > identify traffic within a tunnel that belongs to a particular= VPN, > i.e. the VC label is the tunnel multiplexer in networks that = uses > MPLS labels. > >8.8 Inner label > > "Inner label" is another name for VC label (see section 8.6). > >8.9 VPN Routing and Forwarding (VRF) > > In networks running 2547 VPN's [RFC2547], PE routers maintain > VRF's. A VRF is a per-site forwarding table. Every site to wh= ich > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt = 25.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Page = 18] > > the PE router is attached is associated with one of these tab= les. > A particular packet's IP destination address is looked up in = a > particular VRF only if that packet has arrived directly from = a > site, which is associated with that table. > >8.10 VPN Forwarding Instance (VFI) > > VPN Forwarding Instance (VFI) is a logical entity that reside= s in > a PE that includes the router information base and forwarding > information base for a VPN instance [L3VPN-frmwrk]. > >8.11 Virtual Switch Instance (VSI) > > In a layer 2 context a VSI is a virtual switching instance th= at > serves one single VPLS [L2VPN-frmwrk]. A VSI performs standar= d LAN > (i.e., Ethernet) bridging functions. Forwarding done by a VSI= is > based on MAC addresses and VLAN tags, and possibly other rele= vant > information on a per VPLS basis. The VSI is allocated to VPLS= -PE > or in the distributed case to the U-PE. > >8.12 Virtual Router (VR) > > A Virtual Router (VR) is software and hardware based emulatio= n of > a physical router. Virtual routers have independent IP routin= g and > forwarding tables and they are isolated from each other, see > [PPVPN-VR]. > > >9. Acknowledgements > > Much of the content in this document is based on discussion i= n the > PPVPN design teams for "auto discovery" and "l2vpn". > > >10. Authors' Contact > > Loa Andersson > TLA-group > loa@pi.se > > Tove Madsen > TLA-group > tove@niebelungen.net > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 25.= 09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pag= e 19] >11. Normative References > >[GENERIC] Nagarajan, A (ed), "Generic Requirements for Provider >Provisioned VPN", draft-ietf-l3vpn-generic-reqts-01.txt, Work in >Progress, Internet Draft, Aug 2003 > >[L2VPN-frmwrk] Andersson, L. and Rosen, E., "L2VPN Framework", draft= - >ietf-l2vpn-l2-framework-01.txt, Work in Progress, Internet Draft, >Sept 2003 > >[L3VPN-frmwrk] Callon, R. and Suzuki, M.," A Framework for Layer 3 >Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn- >framework-00.txt, Work in Progress, Internet Draft, March 2003 > >[PPVPN-req] Carugi, M. and McDysan, D., "Service requirements for >Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf- >l3vpn-requirements-00.txt, Work in Progress, Internet Draft, Oct 200= 3 > >[L2VPN-req] Augustyn, W., and Serbest, Y., "Service Requirements for >Layer 2 Provider Provisioned Virtual Private Networks", draft-ietf- >l2vpn-requirements-00.txt, Work in Progress, Internet Draft, May 200= 3 > > >12. Non-Normative References > > >[BGPVPN-auto] Ould-Brahim, H., Rosen, E. and Rekhter, Y. "Using BGP >as an auto-discovery mechanism for network-based VPNs", draft-ietf- >l3vpn-bgpvpn-auto-00.txt, Work in progress, Internet Draft, July 200= 3 > >[kompella-VPLS] Kompella, K. "Virtual Private LAN Service", draft- >ietf-l2vpn-vpls-bgp-00.txt, Work in Progress, Internet Draft, May >2003 > >[L2VPN] Kompella, K., et.al. "Layer 2 VPNs Over Tunnels", draft- >kompella-ppvpn-l2vpn-03.txt, Work in Progress, June 2002 > >[lasserre-vkompella] Kompella, V. and Lasserre, M., "Virtual Private >LAN Services over MPLS" draft-ietf-l2vpn-vpls-ldp-00.txt, Work in >progress, Mar 2002 > >[martini-encap] Martini, L., et.al. "Encapsulation Methods for >Transport of Layer 2 Frames Over IP and MPLSNetworks", draft-martini= - >l2circuit-encap-mpls-05.txt, Work in Progress, Internet Draft, April >2003 > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > >Andersson / Madsen Expires March 2004 [Pa= ge 20] > >[martini-tran] Martini, L., et.al. "Transport of Layer 2 Frames Over >MPLS", draft-martini-l2circuit-trans-mpls-11.txt, Work in progress, >Internet Draft, April 2003 > >[PPVPN-VR] Ould-Brahim, H., et.al. "Network-based IP VPN using >Virtual Routers", draft-ietf-l3vpn-vpn-vr-00.txt, Work in Progress, >Internet Draft, July 2002 > >[PWE3-arch] Prayson, P. and Bryant, S., "PWE3 Architecture", draft- >ietf-pwe3-arch-05.txt, Work in Progress, Internet Draft, August 2003 > >[PWE3-req] Xiao, X., "Requirements for Pseudo-Wire Emulation Edge-to= - >Edge (PWE3)", draft-ietf-pwe3-requirements-06.txt, Work in progress, >Internet Draft, July 2003 > >[RFC2547] Rosen, E., et.al. "BGP/MPLS VPNs", rfc2547, March 1999 > >[RFC2547bis] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn- >rfc2547bis-01.txt, Work in Progress, Internet Draft, September 2003 > >[RFC2764] Gleeson, B., et.al. "A Framework for IP Based Virtual >Private Networks", rfc2764, February 2000 > > > > > > > > > > > > > > > > > > > > > > > > > > >INTERNET-DRAFT draft-ietf-l3vpn-ppvpn-terminology-00.txt 2= 5.09.03 > >=0C > > =20 > From exim@www1.ietf.org Sat Feb 7 04:59:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28780 for ; Sat, 7 Feb 2004 04:59:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApPFD-0007nX-N7 for l3vpn-archive@odin.ietf.org; Sat, 07 Feb 2004 04:59:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i179xNTi029974 for l3vpn-archive@odin.ietf.org; Sat, 7 Feb 2004 04:59:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApPFC-0007nN-OD for l3vpn-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 04:59:22 -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 EAA28776 for ; Sat, 7 Feb 2004 04:59:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApPF9-0005sN-00 for l3vpn-web-archive@ietf.org; Sat, 07 Feb 2004 04:59:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApPED-0005pc-00 for l3vpn-web-archive@ietf.org; Sat, 07 Feb 2004 04:58:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApPDw-0005mk-00 for l3vpn-web-archive@ietf.org; Sat, 07 Feb 2004 04:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApPDu-0007iR-K2; Sat, 07 Feb 2004 04:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApPDG-0007fb-Jh for l3vpn@optimus.ietf.org; Sat, 07 Feb 2004 04:57:22 -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 EAA28745 for ; Sat, 7 Feb 2004 04:57:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApPDD-0005ly-00 for l3vpn@ietf.org; Sat, 07 Feb 2004 04:57:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApPCG-0005j3-00 for l3vpn@ietf.org; Sat, 07 Feb 2004 04:56:20 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1ApPBQ-0005ct-00 for l3vpn@ietf.org; Sat, 07 Feb 2004 04:55:28 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2004 01:54:28 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i179svYO008221; Sat, 7 Feb 2004 04:54:58 -0500 (EST) Received: from cisco.com (rtp-vpn2-107.cisco.com [10.82.240.107]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AWV38048; Sat, 7 Feb 2004 01:54:56 -0800 (PST) Message-ID: <4024B5EF.2020505@cisco.com> Date: Sat, 07 Feb 2004 10:54:55 +0100 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs References: <200402061946.i16Jk3h27311@merlot.juniper.net> In-Reply-To: <200402061946.i16Jk3h27311@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dropping double-post to mpls@uu.net. Please see inline. Yakov Rekhter wrote: > Mark, > > >>>In contrast your draft uses BGP not just to specify whether a >>>particular VPN on a PE should use l2tp to get traffic to that PE, >>>but also uses BGP to carry the l2tp session and cookie (l2tp signaling >> >>information). That is, in contrast to draft-ietf-l3vpn-ipsec-2547-01.txt >> >>>your draft does replace the l2tp signaling protocol with BGP, thus >>>eliminating the need for l2tp signaling with the l2tp signaling >>>protocol. >>> >>>Just tell us why BGP signaling is any better than l2tp signaling. >> >>I will say it again. (1) This is an application of 2547 which is already usin > > g > >>BGP, and (2) L2TP needs to distribute a *single* PE Session/Cookie to be used > > by > >>every participating 2547-PE for VPN traffic destined to that PE (much like a >>single IP address is distributed to every participating PE for VPN traffic >>destined to that PE). > > > Are you saying that just because an application uses BGP, the application > should use BGP, instead of l2tp for l2tp signaling ? > > Or you saying that only when both (1) *and* (2) hold, then the application > should use BGP, instead of l2tp for l2tp signaling ? The two reasons I gave above were motivations for the design of 2547 VPNs with an L2TPv3 encapsulation, no more. I have no desire to extend this to a generalized theorem (or continued rathole discussion) for when to use BGP or L2TP signaling for all other possible applications, as I must say you seem to be intent on doing with this thread. > > >>>>>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. >>>> >>>>No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label for a VPN-IPv4 >>>>address distributed via RFC2547 extensions to BGP between PEs. I should not > > > >>>>extend this draft to cover other L3VPN models any more than >>>>draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt >>>>should. Shall I rename it to something with "2547" in the title to be >>>>more clear? >>> >>> >>>First of all I'd like to thank you for pointing that both >>>draft-ietf-l3vpn-ipsec-2547-01.txt or draft-ietf-l3vpn-gre-ip-2547-00.txt >>>took a fairly narrow point of view. This is a bug, not a feature, >>>and therefore it should be fixed. >> >>I have no problem with someone documenting how a VR-based VPN should work, bu > > t > >>why do this in the same draft? Would you consider adding VR VPNs to 2547bis? > > > Based on the feedback received so far on the mailing list, I do > plan to generalize draft-ietf-l3vpn-gre-ip-2547-00.txt. > > >>>Second, the restriction on the applicability of your draft to 2547 is >>>quite arbitrary. >> >>Hardly arbitrary. >> >> >>>That is, there are *no* technical justifications for this restriction. >> >>VRs and 2547 are different technical approaches, what technical justification >>is there for putting them in the *same* document? > > > Because from the l2tp point of view the procedures are exactly > the same, whether it is 2547 or MPLS-based VR. I am happy to work with you or anyone else interested in discussing the technical details of this to determine whether it is indeed a good fit for the same draft, or could exist separately without undue repetition. - Mark > > Yakov. > From exim@www1.ietf.org Sat Feb 7 13:13:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10761 for ; Sat, 7 Feb 2004 13:13:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApWwc-0007gB-0V for l3vpn-archive@odin.ietf.org; Sat, 07 Feb 2004 13:12:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17ICfpm029515 for l3vpn-archive@odin.ietf.org; Sat, 7 Feb 2004 13:12:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApWwb-0007fy-O1 for l3vpn-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 13:12:41 -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 NAA10752 for ; Sat, 7 Feb 2004 13:12:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApWwZ-0001fY-00 for l3vpn-web-archive@ietf.org; Sat, 07 Feb 2004 13:12:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApWvf-0001bh-00 for l3vpn-web-archive@ietf.org; Sat, 07 Feb 2004 13:11:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApWv1-0001XO-00 for l3vpn-web-archive@ietf.org; Sat, 07 Feb 2004 13:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApWv0-0007a5-7g; Sat, 07 Feb 2004 13:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApWuc-0007ZE-Cs for l3vpn@optimus.ietf.org; Sat, 07 Feb 2004 13:10:38 -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 NAA10640 for ; Sat, 7 Feb 2004 13:10:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApWua-0001W8-00 for l3vpn@ietf.org; Sat, 07 Feb 2004 13:10:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApWtb-0001RY-00 for l3vpn@ietf.org; Sat, 07 Feb 2004 13:09:36 -0500 Received: from web21410.mail.yahoo.com ([216.136.232.85]) by ietf-mx with smtp (Exim 4.12) id 1ApWsd-0001Mr-00 for l3vpn@ietf.org; Sat, 07 Feb 2004 13:08:35 -0500 Message-ID: <20040207180835.75947.qmail@web21410.mail.yahoo.com> Received: from [66.31.70.41] by web21410.mail.yahoo.com via HTTP; Sat, 07 Feb 2004 10:08:35 PST Date: Sat, 7 Feb 2004 10:08:35 -0800 (PST) From: Roger Pottier Subject: Multi-AS Backbones To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1211845799-1076177315=:73758" 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: , List-Id: List-Post: List-Help: List-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.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --0-1211845799-1076177315=:73758 Content-Type: text/plain; charset=us-ascii Hi, draft-ietf-l3vpn-rfc2547bis-01.txt specifies the multi-AS Backbone scenario. 10. c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between source and destination ASes, with EBGP redistribution of labeled IPv4 routes from AS to neighboring AS. The ASBR maintains labeled IPv4 /32 routes to the PE routers within its AS and uses EBGP to distribute the labeled routes to other ASes. Between, two ASs, it uses BGP to distribute the labels, but in that case, how is the labeled path within the AS Maintained. Is it using BGP itself. Or is LDP/RSVP used to distribute the labels within the same AS? Thanks, Roger --------------------------------- Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online --0-1211845799-1076177315=:73758 Content-Type: text/html; charset=us-ascii
Hi,
 
 draft-ietf-l3vpn-rfc2547bis-01.txt specifies the multi-AS Backbone scenario.
 
10. c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between
         source and destination ASes, with EBGP redistribution of
         labeled IPv4 routes from AS to neighboring AS.
 
The ASBR  maintains labeled IPv4  /32 routes to the PE routers within its AS and uses EBGP to  distribute the labeled routes to other ASes. 
Between, two ASs, it uses BGP to distribute the labels, but in that case, how is the labeled path within the AS Maintained.
Is it using BGP itself. Or is  LDP/RSVP used to
distribute the labels within the same AS?
 
Thanks,
Roger
 

Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online --0-1211845799-1076177315=:73758-- From exim@www1.ietf.org Sat Feb 7 16:07:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14213 for ; Sat, 7 Feb 2004 16:07:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApZfB-0001OJ-73 for l3vpn-archive@odin.ietf.org; Sat, 07 Feb 2004 16:06:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17L6rsh005346 for l3vpn-archive@odin.ietf.org; Sat, 7 Feb 2004 16:06:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApZfB-0001O9-2T for l3vpn-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 16:06:53 -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 QAA14186 for ; Sat, 7 Feb 2004 16:06:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApZf9-0005NO-00 for l3vpn-web-archive@ietf.org; Sat, 07 Feb 2004 16:06:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApZeP-0005HX-00 for l3vpn-web-archive@ietf.org; Sat, 07 Feb 2004 16:06:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApZdP-00059x-00 for l3vpn-web-archive@ietf.org; Sat, 07 Feb 2004 16:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApZdN-00019H-IH; Sat, 07 Feb 2004 16:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApZca-00011u-Tn for l3vpn@optimus.ietf.org; Sat, 07 Feb 2004 16:04:13 -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 QAA14047 for ; Sat, 7 Feb 2004 16:04:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApZcZ-00051m-00 for l3vpn@ietf.org; Sat, 07 Feb 2004 16:04:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApZbt-0004t1-00 for l3vpn@ietf.org; Sat, 07 Feb 2004 16:03:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ApZaL-0004ip-02 for l3vpn@ietf.org; Sat, 07 Feb 2004 16:01:53 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ApYww-0005KK-8x for l3vpn@ietf.org; Sat, 07 Feb 2004 15:21:10 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 07 Feb 2004 12:20:05 -0800 Received: from chrlewis-w2k02.cisco.com (sjc-vpn2-347.cisco.com [10.21.113.91]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i17KIlqC021578; Sat, 7 Feb 2004 12:19:16 -0800 (PST) Message-Id: <4.3.2.7.2.20040206211306.02a94da0@fargo.cisco.com> X-Sender: chrlewis@fargo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Feb 2004 21:23:21 -0600 To: yakov@juniper.net From: Chris Lewis Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs Cc: mpls@UU.NET, l3vpn@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=DATE_IN_PAST_12_24 autolearn=no version=2.60 Hello Yakov, I saw your exchange with Mark below and want to offer an opinion. I agree that your question as to why BGP is better than L2TP signaling in this case is one worth asking. I believe that the answer is quite simple, however I would appreciate any further input on where this logic falls down. In this draft, Mark is not signaling pseudowire state. Rather a single piece of information that tells any other PE wanting to communicate with a given PE, what it's capabilities are, needs to be communicated throughout the domain. In this instance the same set of information needs to go to many peers and there is no exchange of pseudowire state involved. Essentially a point to multipoint conversation. To me it seems logical that using the BGP default behavior of broadcast is more efficient than using the behavior of L2TP, which is point to point in nature and forcing a replication of many L2TP point to point sessions, when a single BGP entry would do. Does this make sense, or am I missing something? Cheers Chris To: "W. Mark Townsley" cc: mpls@UU.NET, l3vpn@ietf.org Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs Date: Wed, 04 Feb 2004 11:55:08 -0800 From: Yakov Rekhter Mark, > Yakov Rekhter wrote: > > > Please document in your draft what is exactly "prudent" about BGP. > > Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide: > > "RFC2547 already provides an egress-to-ingress signaling capability via BGP, > and we specify below how to extend this to the signalling of security policy." > > I will add this text to the l3vpn-l2tpv3 document: > > "RFC2547 already provides an egress-to-ingress signaling capability via BGP, > [NALAWADE] or [RAGGARWA] specifies how to extend this to the signaling of > L2TPv3 reachability information for a PE." Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does *not* replace IPSec signaling with BGP. All it does is specifying how to use BGP to indicate whether a particular VPN on a PE should use IPSec to get traffic to that PE. In contrast your draft uses BGP not just to specify whether a particular VPN on a PE should use l2tp to get traffic to that PE, but also uses BGP to carry the l2tp session and cookie (l2tp signaling information). That is, in contrast to draft-ietf-l3vpn-ipsec-2547-01.txt your draft does replace the l2tp signaling protocol with BGP, thus eliminating the need for l2tp signaling with the l2tp signaling protocol. Just tell us why BGP signaling is any better than l2tp signaling. From exim@www1.ietf.org Mon Feb 9 05:58:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11855 for ; Mon, 9 Feb 2004 05:58:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq96z-0000zK-Ja for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 05:57:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Avvea003792 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 05:57:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq96z-0000z5-EK for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 05:57:57 -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 FAA11843 for ; Mon, 9 Feb 2004 05:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq96v-00061P-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 05:57:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq95z-0005wC-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 05:56:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq959-0005qt-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 05:56:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq959-0000r0-BM; Mon, 09 Feb 2004 05:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq955-0000qI-1G for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 05:55:59 -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 FAA11640 for ; Mon, 9 Feb 2004 05:55:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq951-0005pp-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 05:55:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq94B-0005jT-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 05:55:03 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1Aq93C-0005ZL-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 05:54:02 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i19ArQBm026459; Mon, 9 Feb 2004 02:53:26 -0800 (PST) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i19ArQh37086; Mon, 9 Feb 2004 02:53:26 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i19ArPv05836; Mon, 9 Feb 2004 02:53:25 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs Date: Mon, 9 Feb 2004 02:53:25 -0800 (PST) From: Rahul Aggarwal To: Chris Lewis cc: yakov@juniper.net, "" , "" Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs In-Reply-To: <4.3.2.7.2.20040206211306.02a94da0@fargo.cisco.com> Message-ID: <20040209024159.E85898@sapphire.juniper.net> References: <4.3.2.7.2.20040206211306.02a94da0@fargo.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: List-Post: List-Help: List-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 Hi Chris, On Fri, 6 Feb 2004, Chris Lewis wrote: > Hello Yakov, > > I saw your exchange with Mark below and want to offer an opinion. > > I agree that your question as to why BGP is better than L2TP signaling in > this case is one worth asking. > > I believe that the answer is quite simple, however I would appreciate any > further input on where this logic falls down. > > In this draft, Mark is not signaling pseudowire state. Rather a single > piece of information that tells any other PE wanting to communicate with a > given PE, what it's capabilities are, needs to be communicated throughout > the domain. In this instance the same set of information needs to go to Not just capabilities. This information includes L2TPv3 signaling information: session-id and cookie. > many peers and there is no exchange of pseudowire state involved. > Essentially a point to multipoint conversation. > Hence, shouldn't it be fine to generalize this draft to cover any point-to-multipoint application of MPLS over L2TPv3 ? rahul > To me it seems logical that using the BGP default behavior of broadcast is > more efficient than using the behavior of L2TP, which is point to point in > nature and forcing a replication of many L2TP point to point sessions, when > a single BGP entry would do. > > Does this make sense, or am I missing something? > > Cheers > > Chris > > To: "W. Mark Townsley" > cc: mpls@UU.NET, l3vpn@ietf.org > Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs > Date: Wed, 04 Feb 2004 11:55:08 -0800 > From: Yakov Rekhter > Mark, > > Yakov Rekhter wrote: > > > > > Please document in your draft what is exactly "prudent" about BGP. > > > > Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide: > > > > "RFC2547 already provides an egress-to-ingress signaling capability via > BGP, > > and we specify below how to extend this to the signalling of security > policy." > > > > I will add this text to the l3vpn-l2tpv3 document: > > > > "RFC2547 already provides an egress-to-ingress signaling capability via > BGP, > > [NALAWADE] or [RAGGARWA] specifies how to extend this to the signaling of > > L2TPv3 reachability information for a PE." > Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does > not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does > *not* replace IPSec signaling with BGP. All it does is specifying > how to use BGP to indicate whether a particular VPN on a PE should > use IPSec to get traffic to that PE. > In contrast your draft uses BGP not just to specify whether a > particular VPN on a PE should use l2tp to get traffic to that PE, > but also uses BGP to carry the l2tp session and cookie (l2tp signaling > information). That is, in contrast to draft-ietf-l3vpn-ipsec-2547-01.txt > your draft does replace the l2tp signaling protocol with BGP, thus > eliminating the need for l2tp signaling with the l2tp signaling > protocol. > Just tell us why BGP signaling is any better than l2tp signaling. > > From exim@www1.ietf.org Mon Feb 9 09:15:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20125 for ; Mon, 9 Feb 2004 09:15:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCBo-0004K8-Oa for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 09:15:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19EF8MJ016616 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 09:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCBo-0004Jv-HU for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 09:15:08 -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 JAA20058 for ; Mon, 9 Feb 2004 09:15:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCBm-00021Y-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 09:15:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCAm-0001tC-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 09:14:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqC9n-0001nQ-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 09:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqC9l-000480-Fx; Mon, 09 Feb 2004 09:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqC8p-000478-67 for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 09:12:03 -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 JAA19962 for ; Mon, 9 Feb 2004 09:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqC8n-0001hm-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 09:12:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqC7r-0001cl-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 09:11:04 -0500 Received: from door.sniff.de ([82.212.219.2]) by ietf-mx with esmtp (Exim 4.12) id 1AqC6x-0001Xk-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 09:10:07 -0500 Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E8DDC2AA0B; Mon, 9 Feb 2004 14:11:16 +0000 (GMT) In-Reply-To: <20040206225217.43302.qmail@web21404.mail.yahoo.com> References: <20040206225217.43302.qmail@web21404.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43B1D890-5B0A-11D8-AC99-0003934A79C2@sniff.de> Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org, mpls@UU.NET From: Marc Binderberger Subject: Re: Multi-As Backbones Date: Mon, 9 Feb 2004 15:14:25 +0100 To: Roger Pottier X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Roger, > draft-ietf-l3vpn-rfc2547bis-01.txt specifies the multi-AS Backbone > scenario. > > 10. c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between > source and destination ASes, with EBGP redistribution of > labeled IPv4 routes from AS to neighboring AS. > > The ASBR maintains labeled IPv4 /32 routes to the PE routers within > its AS and uses EBGP to distribute the labeled routes to other ASes. > > Between, two ASs, it uses BGP to distribute the labels, but in that > case, how is the labeled path within the AS Maintained. Is it using > BGP itself. Or is LDP/RSVP used to > distribute the labels within the same AS? Redistributing the eBGP-learned /32 into your IGP (thus using LDP/RSVP) works. A colleague of mine has tested this. Obviously this has some limitations with scalability. Using iBGP IPv4+label - haven't tested yet as no IOS for 7600 (our PE plattform) was available supporting this. As I understand the theory this results in a packet with 3 labels minimum: the MP-BGP VPN label at the bottom, then the IPv4 next hop label and topmost the LDP label to the ASBR. Regards, Marc -- Marc Binderberger Powered by *BSD ;-) From exim@www1.ietf.org Mon Feb 9 10:18:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23548 for ; Mon, 9 Feb 2004 10:18:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDAk-0005H8-8b for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 10:18:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19FI6cq020267 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 10:18:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDAk-0005Gn-1l for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 10:18:06 -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 KAA23489 for ; Mon, 9 Feb 2004 10:18:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDAh-0007FE-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 10:18:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqD9k-0007B8-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 10:17:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqD8n-00077E-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 10:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqD8k-0004lF-Qs; Mon, 09 Feb 2004 10:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqD7s-0004Z8-Be for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 10:15:08 -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 KAA23254 for ; Mon, 9 Feb 2004 10:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqD7q-00073A-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 10:15:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqD6r-0006zZ-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 10:14:06 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AqD6b-0006vk-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 10:13:49 -0500 Received: from chrlewis-w2k02.cisco.com (sjc-vpn3-658.cisco.com [10.21.66.146]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i19FD9pq012043; Mon, 9 Feb 2004 07:13:09 -0800 (PST) Message-Id: <4.3.2.7.2.20040209090017.02c3c2d0@fargo.cisco.com> X-Sender: chrlewis@fargo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Feb 2004 09:10:55 -0600 To: Rahul Aggarwal From: Chris Lewis Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs Cc: yakov@juniper.net, "" , "" In-Reply-To: <20040209024159.E85898@sapphire.juniper.net> References: <4.3.2.7.2.20040206211306.02a94da0@fargo.cisco.com> <4.3.2.7.2.20040206211306.02a94da0@fargo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi Rahul, At 04:53 AM 2/9/2004, Rahul Aggarwal wrote: >Hi Chris, > >On Fri, 6 Feb 2004, Chris Lewis wrote: > > > Hello Yakov, > > > > I saw your exchange with Mark below and want to offer an opinion. > > > > I agree that your question as to why BGP is better than L2TP signaling in > > this case is one worth asking. > > > > I believe that the answer is quite simple, however I would appreciate any > > further input on where this logic falls down. > > > > In this draft, Mark is not signaling pseudowire state. Rather a single > > piece of information that tells any other PE wanting to communicate with a > > given PE, what it's capabilities are, needs to be communicated throughout > > the domain. In this instance the same set of information needs to go to > >Not just capabilities. This information includes L2TPv3 signaling >information: session-id and cookie. If it's the same value that has to go to multiple peers, it seems to me that to broadcast it by BGP is a more efficient option. > > many peers and there is no exchange of pseudowire state involved. > > Essentially a point to multipoint conversation. > > > >Hence, shouldn't it be fine to generalize this draft to cover any >point-to-multipoint application of MPLS over L2TPv3 ? If you're referring to virtual routers in this definition of generalization, I don't have an opinion. Chris >rahul > > > To me it seems logical that using the BGP default behavior of broadcast is > > more efficient than using the behavior of L2TP, which is point to point in > > nature and forcing a replication of many L2TP point to point sessions, when > > a single BGP entry would do. > > > > > > > Does this make sense, or am I missing something? > > > > Cheers > > > > Chris > > > > To: "W. Mark Townsley" > > cc: mpls@UU.NET, l3vpn@ietf.org > > Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs > > Date: Wed, 04 Feb 2004 11:55:08 -0800 > > From: Yakov Rekhter > > Mark, > > > Yakov Rekhter wrote: > > > > > > > Please document in your draft what is exactly "prudent" about BGP. > > > > > > Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide: > > > > > > "RFC2547 already provides an egress-to-ingress signaling capability via > > BGP, > > > and we specify below how to extend this to the signalling of security > > policy." > > > > > > I will add this text to the l3vpn-l2tpv3 document: > > > > > > "RFC2547 already provides an egress-to-ingress signaling capability via > > BGP, > > > [NALAWADE] or [RAGGARWA] specifies how to extend this to the > signaling of > > > L2TPv3 reachability information for a PE." > > Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does > > not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does > > *not* replace IPSec signaling with BGP. All it does is specifying > > how to use BGP to indicate whether a particular VPN on a PE should > > use IPSec to get traffic to that PE. > > In contrast your draft uses BGP not just to specify whether a > > particular VPN on a PE should use l2tp to get traffic to that PE, > > but also uses BGP to carry the l2tp session and cookie (l2tp signaling > > information). That is, in contrast to draft-ietf-l3vpn-ipsec-2547-01.txt > > your draft does replace the l2tp signaling protocol with BGP, thus > > eliminating the need for l2tp signaling with the l2tp signaling > > protocol. > > Just tell us why BGP signaling is any better than l2tp signaling. > > > > From exim@www1.ietf.org Mon Feb 9 10:47:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24663 for ; Mon, 9 Feb 2004 10:47:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDco-00082R-Fy for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 10:47:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Fl6Lj030893 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 10:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDco-00082C-B5 for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 10:47:06 -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 KAA24647 for ; Mon, 9 Feb 2004 10:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDcl-0001fe-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 10:47:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDbn-0001bL-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 10:46:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqDap-0001WD-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 10:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDap-0007vM-Aj; Mon, 09 Feb 2004 10:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDa9-0007qj-L1 for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 10:44:21 -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 KAA24587 for ; Mon, 9 Feb 2004 10:44:17 -0500 (EST) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDa7-0001T3-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 10:44:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDZH-0001NT-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 10:43:27 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AqDYi-0001Gk-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 10:42:53 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 15:42:21 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 15:42:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: MPLS over L2TPv3 encap for RFC 2547 VPNs Date: Mon, 9 Feb 2004 15:42:19 -0000 Message-ID: Thread-Topic: MPLS over L2TPv3 encap for RFC 2547 VPNs Thread-Index: AcPr5v4OXGBiOWTFRKiSEfTAKqcFOwDOtUYj To: Cc: , X-OriginalArrivalTime: 09 Feb 2004 15:42:20.0501 (UTC) FILETIME=[4DD20850:01C3EF23] Content-Transfer-Encoding: base64 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: , List-Id: List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TWFyaywNCg0KID4gVGhlIGluaGVyZW50IHByb2JsZW0gYmVpbmcgdGhhdCBJUCB0aGUgY29udHJv bCB0cmFmZmljIHNoYXJlcyB0aGUNCj4gc2FtZSBkYXRhIHBsYW5lIGFzIHRoZSBwdWJsaWMgSW50 ZXJuZXQgdHJhZmZpYywgdW5saWtlIEFUTSB3aGljaCB1c2VzIGFuDQo+IG91dC1vZi1iYW5kIGNv bnRyb2wgcGxhbmUgKGFuZCBpcyB0aGUgb25seSBzZW5zaWJsZSBzb2x1dGlvbiB0byB0aGUgcHJv YmxlbSwNCj4gaS5lLiB1c2UgcmVzZXJ2ZWQgbGFiZWxzIGZvciBjb250cm9sL21hbmFnZW1lbnQg dHJhZmZpYyBpbiBNUExTKS4NCg0KSW50ZXJlc3RpbmcsIGJ1dCBob3cgZG9lcyBjYXJyeWluZyB0 aGUgY29udHJvbCBjaGFubmVsIG91dCBvZiBiYW5kIGhlbHAgaW4gYQ0KYmxpbmQgc3Bvb2Zpbmcg YXR0YWNrIG9uIHRoZSBkYXRhIHBsYW5lICh3aGVyZSBvbmUgaXMgbWVyZWx5IGd1ZXNzaW5nIGxh YmVscyBpbg0KYXR0ZW1wdCB0byBicmVhayBpbnRvIGEgVlBOKT8NCiANClJTPiBCZWNhdXNlIGlm IHRoZSBjb250cm9sIGNoYW5uZWwgaXMgb3V0IG9mIGJhbmQgdGhlbiBhbnlvbmUgd2l0aCBhY2Nl c3MgdG8gdGhlIGNvbnRyb2wgY2hhbm5lbCBjYW4gb25seSBlZmZlY3Qgd2hhdCBnb2VzIGluIHRo ZSBjb250cm9sIGNoYW5uZWwsIHRoZXkgY2Fubm90IGF0dGVtcHQgVlBOIHNwb29maW5nIGF0dGFj a3MgaW4gdGhlIGRhdGEgcGxhbmUuIEFzIHRoaW5ncyBjdXJyZW50bHkgc3RhbmQgaW4gSVAvTVBM UywgYW55b25lIHdpdGggYWNjZXNzIHRvIHRoZSBjb250cm9sIGNoYW5uZWwgaXMgZnJlZSB0byBp bml0aWF0ZSBhIFZQTiBzcG9vZiBhdHRhY2sgb24gdGhlIGRhdGEgcGxhbmUgYmVjYXVzZSB0aGV5 IHNoYXJlIHRoZSBzYW1lIGFkZHJlc3Mgc3BhY2UuIA0KIA0KUmljaGFyZCANCg== From exim@www1.ietf.org Mon Feb 9 11:35:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26603 for ; Mon, 9 Feb 2004 11:35:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqENF-0003Dv-M2 for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 11:35:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19GZ51U012377 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 11:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqENF-0003DN-1z for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 11:35:05 -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 LAA26469 for ; Mon, 9 Feb 2004 11:35:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqENE-0006NQ-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 11:35:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEL4-0005zO-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 11:32:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqEJO-0005jn-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 11:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEJJ-0002yU-TR; Mon, 09 Feb 2004 11:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEIS-0002wb-Qa for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 11:30:08 -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 LAA26138 for ; Mon, 9 Feb 2004 11:30:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEIR-0005dh-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 11:30:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEHe-0005Za-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 11:29:18 -0500 Received: from web21403.mail.yahoo.com ([216.136.232.73]) by ietf-mx with smtp (Exim 4.12) id 1AqEGr-0005UR-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 11:28:29 -0500 Message-ID: <20040209162828.56766.qmail@web21403.mail.yahoo.com> Received: from [47.234.0.52] by web21403.mail.yahoo.com via HTTP; Mon, 09 Feb 2004 08:28:28 PST Date: Mon, 9 Feb 2004 08:28:28 -0800 (PST) From: Roger Pottier Subject: Re: Multi-As Backbones To: Marc Binderberger Cc: l3vpn@ietf.org, mpls@UU.NET In-Reply-To: <43B1D890-5B0A-11D8-AC99-0003934A79C2@sniff.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1766934781-1076344108=:56562" 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: , List-Id: List-Post: List-Help: List-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.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1766934781-1076344108=:56562 Content-Type: text/plain; charset=us-ascii Hi Marc, Thank you for the response. Marc Binderberger wrote: Hi Roger, > draft-ietf-l3vpn-rfc2547bis-01.txt specifies the multi-AS Backbone > scenario. > > 10. c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between > source and destination ASes, with EBGP redistribution of > labeled IPv4 routes from AS to neighboring AS. > > The ASBR maintains labeled IPv4 /32 routes to the PE routers within > its AS and uses EBGP to distribute the labeled routes to other ASes. > > Between, two ASs, it uses BGP to distribute the labels, but in that > case, how is the labeled path within the AS Maintained. Is it using > BGP itself. Or is LDP/RSVP used to > distribute the labels within the same AS? Redistributing the eBGP-learned /32 into your IGP (thus using LDP/RSVP) works. A colleague of mine has tested this. Obviously this has some limitations with scalability. As you said, this could have some scaling limitations. Does LDP assign a label to each route learnt by the IGP. I think, LDP does not assign labels for BGP Learnt routes. Can cisco be configured to send labels for some BGP Learnt routes? Using iBGP IPv4+label - haven't tested yet as no IOS for 7600 (our PE plattform) was available supporting this. As I understand the theory this results in a packet with 3 labels minimum: the MP-BGP VPN label at the bottom, then the IPv4 next hop label and topmost the LDP label to the ASBR. The IPv4 Nexthop Label (Middle one) would be assigned by the ASBR? Regards, Roger Regards, Marc -- Marc Binderberger Powered by *BSD ;-) --------------------------------- Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online --0-1766934781-1076344108=:56562 Content-Type: text/html; charset=us-ascii
Hi Marc,
 
 Thank you for the response. 

Marc Binderberger <marc@sniff.de> wrote:

Hi Roger,

> draft-ietf-l3vpn-rfc2547bis-01.txt specifies the multi-AS Backbone
> scenario.
>
> 10. c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between
> source and destination ASes, with EBGP redistribution of
> labeled IPv4 routes from AS to neighboring AS.
>
> The ASBR maintains labeled IPv4 /32 routes to the PE routers within
> its AS and uses EBGP to distribute the labeled routes to other ASes.
>


> Between, two ASs, it uses BGP to distribute the labels, but in that
> case, how is the labeled path within the AS Maintained. Is it using
> BGP itself. Or is LDP/RSVP used to
> distribute the labels within the same AS?

Redistributing the eBGP-learned /32 into your IGP (thus using LDP/RSVP)
works. A colleague of mine has tested this. Obviously this has some
limitations with scalability.

As you said, this could have some scaling limitations. Does LDP assign a label to each route learnt by the IGP. I think, LDP does not assign labels for BGP Learnt routes. Can cisco be configured to send labels for some BGP Learnt routes?



Using iBGP IPv4+label - haven't tested yet as no IOS for 7600 (our PE
plattform) was available supporting this. As I understand the theory
this results in a packet with 3 labels minimum: the MP-BGP VPN label at
the bottom, then the IPv4 next hop label and topmost the LDP label to
the ASBR.

The IPv4 Nexthop Label (Middle one) would be assigned by the ASBR?

 

Regards,

Roger

Regards, Marc
--
Marc Binderberger Powered by *BSD ;-)

Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online --0-1766934781-1076344108=:56562-- From exim@www1.ietf.org Mon Feb 9 13:52:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04169 for ; Mon, 9 Feb 2004 13:52:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGWC-000777-Dl for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 13:52:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19IqSle027341 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 13:52:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGWC-00076r-7c for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 13:52:28 -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 NAA04162 for ; Mon, 9 Feb 2004 13:52:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGWA-0005OK-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 13:52:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGVB-0005IN-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 13:51:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGUo-0005Cg-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 13:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGUo-0006t3-6Y; Mon, 09 Feb 2004 13:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGU4-0006ru-86 for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 13:50:16 -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 NAA04117 for ; Mon, 9 Feb 2004 13:50:13 -0500 (EST) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGU2-0005BG-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 13:50:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGT9-000573-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 13:49:20 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150] helo=i2kc02-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AqGSg-00051a-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 13:48:50 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc02-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 18:48:18 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 9 Feb 2004 18:48:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: MPLS vs IP encap in RFC2547 Date: Mon, 9 Feb 2004 18:48:18 -0000 Message-ID: Thread-Topic: MPLS over L2TPv3 encap for RFC 2547 VPNs Thread-Index: AcPr5v4OXGBiOWTFRKiSEfTAKqcFOwDTu0PZ To: , X-OriginalArrivalTime: 09 Feb 2004 18:48:18.0548 (UTC) FILETIME=[4888E340:01C3EF3D] Content-Transfer-Encoding: base64 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: , List-Id: List-Post: List-Help: List-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.8 required=5.0 tests=AWL,BLANK_LINES_70_80, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SXQgaGFzIGJlZW4gYXNzZXJ0ZWQgb24gdGhpcyBtYWlsaW5nIGxpc3QgYW5kIGluIGEgY291cGxl IG9mIElFVEYgZHJhZnRzLCB0aGF0IHVzaW5nIElQIGVuY2Fwc3VsYXRpb24gdGVjaG5pcXVlcyBh Y3Jvc3MgYSBQU04gaW5zdGVhZCBvZiBNUExTIGZvciBSRkMyNTQ3IG1ha2UgaXQgbW9yZSBkaWZm aWN1bHQgdG8gcHJvdGVjdCBWUE5zIGFnYWluc3Qgc3Bvb2ZlZCBhdHRhY2tzLg0KDQogDQoNCkkg d291bGQgbGlrZSB0byBjaGFsbGVuZ2UgdGhpcyBhc3NlcnRpb24sIGFzIEkgYmVsaWV2ZSB0aGF0 IHVzaW5nIElQIGVuY2Fwc3VsYXRpb24gaW4gdGhlIFBTTiBpbnN0ZWFkIG9mIE1QTFMgYWN0dWFs bHkgbWFrZXMgaXQgZWFzaWVyIHRvIHByb3RlY3QgYWdhaW5zdCBzcG9vZmVkIFZQTiBhdHRhY2tz LiBJIGFtIG5vdCBhIHNlY3VyaXR5IGV4cGVydCBzbyBJIHdlbGNvbWUgYW55IGNvbW1lbnRzIHRo YXQgZXhwbGFpbiB3aGVyZSBteSBhcmd1bWVudCBmYWxscyBkb3duLiANCg0KIA0KDQpNeSBhcmd1 bWVudCBpcyBiYXNlZCBvbiB0aGUgZmFjdCB0aGF0IHRoYXQgTVBMUyBuZXR3b3JrcyBjYW4gZm9y d2FyZCBWUE4gcGFja2V0cyBiYXNlZCBvbiBJUCBvciBNUExTIChQSFAgaXMgYSBnb29kIGV4YW1w bGUgb2YgdGhpcyksIGFuZCBoZW5jZSAnSVAvTVBMUycgbmV0d29ya3MgaW5oZXJpdCB0aGUgc2Vj dXJpdHkgcmlza3MgYXNzb2NpYXRlZCB3aXRoIGJvdGggSVAgYW5kIE1QTFMgZm9yd2FyZGluZy4g DQoNCiANCg0KRnVuZGFtZW50YWxseSwgdGhpcyBhcmd1bWVudCBjb21lcyBiYWNrIHRvIHRoZSBm YWN0IHRoYXQgSVAvTVBMUyBuZXR3b3JrcyB0b2RheSB1c2UgdGhlIHNhbWUgYWRkcmVzcyBzcGFj ZSBmb3IgY29udHJvbCBwbGFuZSB0cmFmZmljIHRoYXQgdGhleSB1c2UgZm9yIGZvcndhcmRpbmcg VlBOIHBhY2tldHMgaW4gdGhlIGRhdGEgcGxhbmUsIGkuZS4gLzMyIGxvb3BiYWNrIGFkZHJlc3Nl cyB0aGF0IGFyZSB1c2VkIGZvciBMRFAvQkdQIHNlc3Npb25zIGFyZSBhbHNvIHVzZWQgYXMgUEUg bmV4dCBob3BzIGZvciBWUE4gcGFja2V0cy4gQXMgc3RhdGVkIHByZXZpb3VzbHksIG9uZSBzb2x1 dGlvbiB0byB0aGUgcHJvYmxlbSBpcyB0byB1c2UgZmlsdGVyaW5nOyBhbm90aGVyIGlzIHRvIHVz ZSBhbiBPT0IgY29udHJvbCBwbGFuZS4NCg0KIA0KDQpJZiBhbiBhdHRhY2tlciBpcyBhYmxlIHRv IGluaXRpYXRlIGFuIGF0dGFjayBmcm9tIHdpdGhpbiB0aGUgc2VydmljZSBwcm92aWRlciBuZXR3 b3JrIHRoZW4gdGhlIHNlY3VyaXR5IHJpc2tzIGFzc29jaWF0ZWQgd2l0aCBJUC9NUExTIG5ldHdv cmtzIGFyZSBjb21wYXJhYmxlIHRvIG90aGVyIFZQTiB0ZWNobm9sb2dpZXMgc3VjaCBhcyBBVE0v RlIuIElmIGhvd2V2ZXIgYW4gYXR0YWNrZXIgYXR0ZW1wdHMgdG8gaW5pdGlhdGUgYW4gYXR0YWNr IGZyb20gb3V0c2lkZSB0aGUgcHJvdmlkZXIgbmV0d29yaywgdGhlbiB0aGUgc2VjdXJpdHkgcmlz a3MgaW4gYW4gSVAvTVBMUyBuZXR3b3JrIGFyZSBkZXBlbmRhbnQgb24gd2hpY2ggcm91dGluZyBp bnN0YW5jZSB0aGUgaW50ZXJmYWNlIGNvbm5lY3RzIHRvLCBpLmUuIGEgY3VzdG9tZXIgVlJGIG9y IHRoZSBnbG9iYWwgcm91dGluZyB0YWJsZS4NCg0KIA0KDQpUbyBwcm92aWRlIGp1c3RpZmljYXRp b24gZm9yIHRoaXMgYXJndW1lbnQsIEkgd2lsbCBleGFtaW5lIDMgcG9pbnRzIG9mIGVudHJ5IGlu dG8gdGhlIG5ldHdvcmsgd2hlcmUgYSBzcG9vZmluZyBhdHRlbXB0IG1pZ2h0IHRha2UgcGxhY2Uu DQoNCiANCg0KMS4gVmlhIGEgbGVnaXRpbWF0ZSBub24tY29yZSBmYWNpbmcgbWFuYWdlZCBpbnRl cmZhY2UgYXQgdGhlIGVkZ2Ugb2YgdGhlIHByb3ZpZGVyIG5ldHdvcmsuDQoNCiANCg0KYSkgSWYg dGhlIGludGVyZmFjZSBiZWxvbmdzIHRvIGEgVlBOLCB0aGVuIHRoZSBWUkYgaXQgYmVsb25ncyB0 byB3aWxsIG9ubHkgY29udGFpbiByb3V0ZXMgYmVsb25naW5nIHRvIHRoYXQgcGFydGljdWxhciBW UE4uIFRoaXMgd291bGQgbW9zdCBsaWtlbHkgYmUgYSBjdXN0b21lci1mYWNpbmcgaW50ZXJmYWNl Lg0KDQogDQoNCklmIGEgcGFja2V0IGlzIHJlY2VpdmVkIHdpdGggYW4gYWRkcmVzcy9sYWJlbCB0 aGF0IGJlbG9uZ3MgdG8gYSBkaWZmZXJlbnQgVlBOIG9yIHRvIHRoZSBwcm92aWRlciBuZXR3b3Jr LCB0aGVuIHRoZSBwYWNrZXQgd2lsbCBiZSBkcm9wcGVkIGJlY2F1c2UgYSByb3V0ZSB0byB0aGUg ZGVzdGluYXRpb24gd2lsbCBub3QgZXhpc3QgKGkuZS4gcm91dGUgaXNvbGF0aW9uIGlzIGVuZm9y Y2VkKS4gVGhpcyBpcyBpbmRlcGVuZGVudCBvZiB3aGF0ZXZlciBlbmNhcHN1bGF0aW9uIG1ldGhv ZCAoSVAvR1JFLCBNUExTKSBpcyB1c2VkIHdpdGhpbiB0aGUgUFNOLg0KDQogDQoNCmIpIElmIHRo ZSBpbnRlcmZhY2UgYmVsb25ncyB0byB0aGUgc2VydmljZSBwcm92aWRlciBnbG9iYWwgcm91dGlu ZyB0YWJsZSwgdGhlbiB0aGUgcm91dGluZyB0YWJsZSB3aWxsIGNvbnRhaW4gSUdQIHJvdXRlcywg YW5kIG1heSBjb250YWluIEludGVybmV0IHJvdXRlcy4gVGhpcyB3b3VsZCBtb3N0IGxpa2VseSBi ZSBhbiBpbnRlcmZhY2UgZmFjaW5nIHRoZSBJbnRlcm5ldCBvciBhbm90aGVyIEFTL3Byb3ZpZGVy IHRvIHN1cHBvcnQgaW50ZXItQVMvcHJvdmlkZXIgVlBOcy4NCg0KIA0KDQpJbiBvcmRlciB0byBw cm90ZWN0IGFnYWluc3QgSVAgcGFja2V0IHNwb29maW5nLCBpbmdyZXNzIGZpbHRlcmluZyBtdXN0 IGJlIGFwcGxpZWQgb24gdGhlIGludGVyZmFjZS4gVGhpcyBpcyBpbmRlcGVuZGVudCBvZiB3aGF0 ZXZlciBlbmNhcHN1bGF0aW9uIG1ldGhvZCBpcyB1c2VkIHdpdGhpbiB0aGUgUFNOLiBUaGlzIGlz IGEga2V5IHBvaW50LCBhIG5ldHdvcmsgcnVubmluZyBNUExTIGluIHRoZSBjb3JlIGNhbiBzdGls bCBmb3J3YXJkIHBhY2tldHMgYmFzZWQgb24gSVAgYWRkcmVzc2VzIGl0IHJlY2VpdmVzIGF0IHRo ZSBlZGdlIChhc3N1bWluZyBJUCBpcyBydW5uaW5nIG9uIGludGVyZmFjZXMgYXQgdGhlIGVkZ2Up Lg0KDQogDQoNCklmIE1QTFMgbGFiZWxsZWQgcGFja2V0cyBhcmUgcmVjZWl2ZWQgb24gYW4gaW50 ZXJmYWNlIGJ1dCBNUExTIGlzIG5vdCBlbmFibGVkLCB0aGVuIHRoZXkgc2hvdWxkIGJlIGRyb3Bw ZWQuIFRoaXMgaXMgaW5kZXBlbmRlbnQgb2Ygd2hhdGV2ZXIgZW5jYXBzdWxhdGlvbiBpcyB1c2Vk IGFjcm9zcyB0aGUgUFNOLg0KDQogDQoNCklmIHRoZSBQU04gaXMgdXNpbmcgTVBMUyBpbiB0aGUg Y29yZSwgYW5kIE1QTFMgaXMgZW5hYmxlZCBvbiB0aGUgaW50ZXJmYWNlIHRoZW4gZmlsdGVyaW5n IG5lZWRzIGJlIHVzZWQgdG8gZHJvcCBzcG9vZmVkIE1QTFMgcGFja2V0cy4gVGhpcyBpcyBpbiBh ZGRpdGlvbiB0byB0aGUgZmlsdGVyaW5nIHJlcXVpcmVkIHRvIHByb3RlY3QgYWdhaW5zdCBzcG9v ZmVkIElQIHBhY2tldHMuDQoNCiANCg0KMi4gVmlhIGFuIGlsbGVnYWwgYXR0YWNrIGZyb20gYSBy b3V0ZXIgaW50ZXJmYWNlIHdpdGhpbiB0aGUgcHJvdmlkZXIgbmV0d29yayBieSBhbiBpbnRydWRl cg0KDQogDQoNCmkpIElmIGFuIGludHJ1ZGVyIGhhcyBnYWluZWQgYWNjZXNzIHRvIGEgcm91dGVy IGludGVyZmFjZSB3aXRoaW4gdGhlIHByb3ZpZGVyIG5ldHdvcmsgKGVkZ2Ugb3IgY29yZSksIHRo ZSBpbnRydWRlciBtYXkgYWxzbyBiZSBhYmxlIHRvIGxvb2t1cCByb3V0aW5nL2xhYmVsIGluZm9y bWF0aW9uLiBJZiBzbywgdGhlbiB0aGUgaW50cnVkZXIgY2FuIHVzZSB0aGlzIGluZm9ybWF0aW9u IHRvIGNhcnJ5IG91dCBhIFZQTiBwYWNrZXQgc3Bvb2ZpbmcgYXR0YWNrLiBUaGlzIGlzIGluZGVw ZW5kZW50IG9mIHdoYXRldmVyIGVuY2Fwc3VsYXRpb24gaXMgdXNlZCBhY3Jvc3MgdGhlIFBTTi4N Cg0KIA0KDQppaSkgSWYgYW4gaW50cnVkZXIgZ2FpbnMgYWNjZXNzIHRvIGEgcm91dGVyIGludGVy ZmFjZSB3aXRoaW4gdGhlIHByb3ZpZGVyIG5ldHdvcmsgYnV0IGNhbm5vdCBhY3F1aXJlIHJvdXRp bmcvbGFiZWwgaW5mb3JtYXRpb24sIHRoZW4gYnJ1dGUgZm9yY2UgdGVjaG5pcXVlcyBtdXN0IGJl IHVzZWQgdG8gc3Bvb2YgcGFja2V0cy4gSW4gb3JkZXIgdG8gc3Bvb2YgYSBWUE4gcGFja2V0LCBh biBhdHRhY2tlciBtdXN0IGRldGVybWluZSB0aGUgY29ycmVjdCBQU04gbGFiZWwvSVAgZGVzdGlu YXRpb24gYWRkcmVzc2VzIEFORCB0aGUgY29ycmVjdCBWUE4gbGFiZWwuIElmIHRoZSBQU04gbGFi ZWwvYWRkcmVzcyBpcyBub3QgdmFsaWQsIHRoZSBmaXJzdCBQRS9QIHJvdXRlciB0aGF0IHJlY2Vp dmVzIHRoZSBwYWNrZXQgd2lsbCBkcm9wIGl0LiBJZiB0aGUgUFNOIGxhYmVsL2FkZHJlc3MgaXMg Y29ycmVjdCBidXQgdGhlIFZQTiBsYWJlbCBpcyBpbmNvcnJlY3QsIHRoZW4gdGhlIHBhY2tldCB3 aWxsIGJlIGRyb3BwZWQgYnkgdGhlIGVncmVzcyBQRS4NCg0KIA0KDQpJZiB0aGUgUFNOIHN1cHBv cnRzIElQIG9ubHksIHRoZW4gdGhlIHByb2JhYmlsaXR5IG9mIHNwb29maW5nIHN1Y2Nlc3MgaXMg YmFzZWQgb246DQoNCiANCg0KUChQU04gZGVzdGluYXRpb24gSVAgYWRkcmVzcykgeCBQKFZQTiBs YWJlbCkNCg0KIA0KDQpJZiB0aGUgUFNOIHN1cHBvcnRzIElQL01QTFMgZm9yd2FyZGluZyB0aGVu IHRoZSBwcm9iYWJpbGl0eSBpcyBiYXNlZCBvbjoNCg0KIA0KDQpQKFBTTiBkZXN0aW5hdGlvbiBJ UCBhZGRyZXNzKSB4IFAoVlBOIGxhYmVsKSBPUg0KDQpQKFBTTiBsYWJlbCkgeCBQKFZQTiBsYWJl bCkNCg0KIA0KDQpSZWdhcmRsZXNzIG9mIHdoYXQgdGhlIGFjdHVhbCBwcm9iYWJpbGl0aWVzIGFy ZSwgdGhlIHByb2JhYmlsaXR5IG9mIGEgc3VjY2Vzc2Z1bCBWUE4gcGFja2V0IHNwb29mIGF0dGFj ayB3aWxsIGFsd2F5cyBncmVhdGVyIHRoYW4gYW4gSVAgb25seSBuZXR3b3JrLiBUaGlzIGlzIGJl Y2F1c2UgcGFja2V0cyBjYW4gYmUgZm9yd2FyZGVkIHVzaW5nIElQIGRlc3RpbmF0aW9uIGFkZHJl c3NlcyBPUiBNUExTIGxhYmVscy4NCg0KIA0KDQozLiBWaWEgYW4gaWxsZWdhbCBhdHRhY2sgZnJv bSBhbiBpbnRydWRlciB0aGF0IGhhcyB0YXBwZWQgaW50byBhIHBoeXNpY2FsIGxpbmsgd2l0aGlu IHRoZSBwcm92aWRlciBuZXR3b3JrDQoNCiANCg0KaSkgSWYgYW4gaW50cnVkZXIgaGFzIHRhcHBl ZCBpbnRvIGEgcGh5c2ljYWwgbGluayB0aGVuIGl0IGlzIGxpa2VseSB0aGF0IHRoZXkgYXJlIGFi bGUgdG8gc25vb3AgTVBMUy9JUCBwYWNrZXRzIHRvIGRldGVybWluZSB3aGF0IGxhYmVscyBvciBJ UCBhZGRyZXNzZXMgYXJlIGJlaW5nIHVzZWQuIElmIHNvLCB0aGVuIHRoZSBpbnRydWRlciBjYW4g dXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gY2Fycnkgb3V0IGEgVlBOIHBhY2tldCBzcG9vZmluZyBh dHRhY2suIFRoaXMgaXMgaW5kZXBlbmRlbnQgb2Ygd2hhdGV2ZXIgZW5jYXBzdWxhdGlvbiBpcyB1 c2VkIGFjcm9zcyB0aGUgUFNOLg0KDQogDQoNCmlpKSBJZiBhbiBpbnRydWRlciBoYXMgZ2FpbmVk IGFjY2VzcyB0byBhIHBoeXNpY2FsIGxpbmsgYW5kIGZvciB3aGF0ZXZlciByZWFzb24gY2FuIG9u bHkgdHJhbnNtaXQgcGFja2V0cywgdGhlbiBicnV0ZSBmb3JjZSB0ZWNobmlxdWVzIG11c3QgYmUg YXBwbGllZCBhcyBkZXNjcmliZWQgaW4gMiBpaSkuDQoNCiANCg0KSW4gYm90aCAyIGFuZCAzLCB0 aGUgb25seSB3YXkgdG8gcHJvdGVjdCBhZ2FpbnN0IHRoaXMgdHlwZSBvZiBhdHRhY2sgaXMgdG8g dXNlIGVuc3VyZSBwaHlzaWNhbCBuZXR3b3JrIHByb3RlY3Rpb24gYW5kIHRvIHVzZSBlbmNyeXB0 aW9uL2F1dGhlbnRpY2F0aW9uLiBUaGUgcG9pbnQgYmVpbmcgdGhhdCB0byBwcm90ZWN0IGFnYWlu c3QgdGhlc2UgdHlwZXMgb2YgYXR0YWNrLCB0aGVzZSBzZWN1cml0eSBtZWFzdXJlcyBtdXN0IGJl IHRha2VuIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgUFNOIGlzIElQIG9yIElQL01QTFMuDQoN CiANCg0KQXMgSSBzYXksIGFkbWl0dGVkbHkgSSdtIG5vdCBhIHNlY3VyaXR5IGV4cGVydCBzbyBJ IHdlbGNvbWUgYW55IGNvbW1lbnRzIHRoYXQgZXhwbGFpbiB3aHkgbXkgYXJndW1lbnRzIGFyZSBp bmNvcnJlY3QuDQoNCiANCg0KUmljaGFyZA0KDQo= From exim@www1.ietf.org Mon Feb 9 14:13:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05078 for ; Mon, 9 Feb 2004 14:13:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGqV-0000WV-E4 for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 14:13:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JDRVF002005 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 14:13:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGqV-0000WG-7d for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:13:27 -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 OAA05069 for ; Mon, 9 Feb 2004 14:13:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGqS-0007Jw-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 14:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGpa-0007EA-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 14:12:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGp6-00077z-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 14:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGp6-0000Nn-PF; Mon, 09 Feb 2004 14:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGoP-0000Av-4f for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 14:11:17 -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 OAA04957 for ; Mon, 9 Feb 2004 14:11:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGoM-000757-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 14:11:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGnU-0006zA-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 14:10:21 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AqGml-0006oE-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 14:09:35 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2004 20:09:42 +0100 Received: from cisco.com (amsterdam.cisco.com [144.254.74.238]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i19J8eL1025754; Mon, 9 Feb 2004 20:08:40 +0100 (MET) Received: from JGUICHARW2K (dhcp-10-86-162-232.cisco.com [10.86.162.232]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id UAA16616; Mon, 9 Feb 2004 20:09:01 +0100 (MET) From: "Jim Guichard" To: , , Subject: RE: MPLS vs IP encap in RFC2547 Date: Mon, 9 Feb 2004 14:01:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Content-Transfer-Encoding: quoted-printable 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Richard, if the intruder is sat on an IP network, even if they gain access to a = provider router and assertain the relevant label information for a given = destination, how can they get the labelled packet into the provider = core, assuming that an interface that is NOT enabled for MPLS switching = receives the incoming packets ? Jim > >-----Original Message----- > >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > >richard.spencer@bt.com > >Sent: Monday, February 09, 2004 1:48 PM > >To: l3vpn@ietf.org; mpls@UU.NET > >Subject: MPLS vs IP encap in RFC2547 > > > > > >It has been asserted on this mailing list and in a couple of=20 > >IETF drafts, that using IP encapsulation techniques across a PSN=20 > >instead of MPLS for RFC2547 make it more difficult to protect=20 > >VPNs against spoofed attacks. > > > >=20 > > > >I would like to challenge this assertion, as I believe that=20 > >using IP encapsulation in the PSN instead of MPLS actually makes=20 > >it easier to protect against spoofed VPN attacks. I am not a=20 > >security expert so I welcome any comments that explain where my=20 > >argument falls down.=20 > > > >=20 > > > >My argument is based on the fact that that MPLS networks can=20 > >forward VPN packets based on IP or MPLS (PHP is a good example=20 > >of this), and hence 'IP/MPLS' networks inherit the security=20 > >risks associated with both IP and MPLS forwarding.=20 > > > >=20 > > > >Fundamentally, this argument comes back to the fact that IP/MPLS=20 > >networks today use the same address space for control plane=20 > >traffic that they use for forwarding VPN packets in the data=20 > >plane, i.e. /32 loopback addresses that are used for LDP/BGP=20 > >sessions are also used as PE next hops for VPN packets. As=20 > >stated previously, one solution to the problem is to use=20 > >filtering; another is to use an OOB control plane. > > > >=20 > > > >If an attacker is able to initiate an attack from within the=20 > >service provider network then the security risks associated with=20 > >IP/MPLS networks are comparable to other VPN technologies such=20 > >as ATM/FR. If however an attacker attempts to initiate an attack=20 > >from outside the provider network, then the security risks in an=20 > >IP/MPLS network are dependant on which routing instance the=20 > >interface connects to, i.e. a customer VRF or the global routing = table. > > > >=20 > > > >To provide justification for this argument, I will examine 3=20 > >points of entry into the network where a spoofing attempt might=20 > >take place. > > > >=20 > > > >1. Via a legitimate non-core facing managed interface at the=20 > >edge of the provider network. > > > >=20 > > > >a) If the interface belongs to a VPN, then the VRF it belongs to=20 > >will only contain routes belonging to that particular VPN. This=20 > >would most likely be a customer-facing interface. > > > >=20 > > > >If a packet is received with an address/label that belongs to a=20 > >different VPN or to the provider network, then the packet will=20 > >be dropped because a route to the destination will not exist=20 > >(i.e. route isolation is enforced). This is independent of=20 > >whatever encapsulation method (IP/GRE, MPLS) is used within the PSN. > > > >=20 > > > >b) If the interface belongs to the service provider global=20 > >routing table, then the routing table will contain IGP routes,=20 > >and may contain Internet routes. This would most likely be an=20 > >interface facing the Internet or another AS/provider to support=20 > >inter-AS/provider VPNs. > > > >=20 > > > >In order to protect against IP packet spoofing, ingress=20 > >filtering must be applied on the interface. This is independent=20 > >of whatever encapsulation method is used within the PSN. This is=20 > >a key point, a network running MPLS in the core can still=20 > >forward packets based on IP addresses it receives at the edge=20 > >(assuming IP is running on interfaces at the edge). > > > >=20 > > > >If MPLS labelled packets are received on an interface but MPLS=20 > >is not enabled, then they should be dropped. This is independent=20 > >of whatever encapsulation is used across the PSN. > > > >=20 > > > >If the PSN is using MPLS in the core, and MPLS is enabled on the=20 > >interface then filtering needs be used to drop spoofed MPLS=20 > >packets. This is in addition to the filtering required to=20 > >protect against spoofed IP packets. > > > >=20 > > > >2. Via an illegal attack from a router interface within the=20 > >provider network by an intruder > > > >=20 > > > >i) If an intruder has gained access to a router interface within=20 > >the provider network (edge or core), the intruder may also be=20 > >able to lookup routing/label information. If so, then the=20 > >intruder can use this information to carry out a VPN packet=20 > >spoofing attack. This is independent of whatever encapsulation=20 > >is used across the PSN. > > > >=20 > > > >ii) If an intruder gains access to a router interface within the=20 > >provider network but cannot acquire routing/label information,=20 > >then brute force techniques must be used to spoof packets. In=20 > >order to spoof a VPN packet, an attacker must determine the=20 > >correct PSN label/IP destination addresses AND the correct VPN=20 > >label. If the PSN label/address is not valid, the first PE/P=20 > >router that receives the packet will drop it. If the PSN=20 > >label/address is correct but the VPN label is incorrect, then=20 > >the packet will be dropped by the egress PE. > > > >=20 > > > >If the PSN supports IP only, then the probability of spoofing=20 > >success is based on: > > > >=20 > > > >P(PSN destination IP address) x P(VPN label) > > > >=20 > > > >If the PSN supports IP/MPLS forwarding then the probability is based = on: > > > >=20 > > > >P(PSN destination IP address) x P(VPN label) OR > > > >P(PSN label) x P(VPN label) > > > >=20 > > > >Regardless of what the actual probabilities are, the probability=20 > >of a successful VPN packet spoof attack will always greater than=20 > >an IP only network. This is because packets can be forwarded=20 > >using IP destination addresses OR MPLS labels. > > > >=20 > > > >3. Via an illegal attack from an intruder that has tapped into a=20 > >physical link within the provider network > > > >=20 > > > >i) If an intruder has tapped into a physical link then it is=20 > >likely that they are able to snoop MPLS/IP packets to determine=20 > >what labels or IP addresses are being used. If so, then the=20 > >intruder can use this information to carry out a VPN packet=20 > >spoofing attack. This is independent of whatever encapsulation=20 > >is used across the PSN. > > > >=20 > > > >ii) If an intruder has gained access to a physical link and for=20 > >whatever reason can only transmit packets, then brute force=20 > >techniques must be applied as described in 2 ii). > > > >=20 > > > >In both 2 and 3, the only way to protect against this type of=20 > >attack is to use ensure physical network protection and to use=20 > >encryption/authentication. The point being that to protect=20 > >against these types of attack, these security measures must be=20 > >taken regardless of whether the PSN is IP or IP/MPLS. > > > >=20 > > > >As I say, admittedly I'm not a security expert so I welcome any=20 > >comments that explain why my arguments are incorrect. > > > >=20 > > > >Richard > > From exim@www1.ietf.org Mon Feb 9 14:24:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05654 for ; Mon, 9 Feb 2004 14:24:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH1C-0001S4-8s for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 14:24:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JOUM1005574 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 14:24:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH1C-0001Rp-2O for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:24:30 -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 OAA05644 for ; Mon, 9 Feb 2004 14:24:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH19-0000aa-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 14:24:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqH0F-0000Uw-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 14:23:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGzk-0000ON-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 14:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGzk-0001Km-UV; Mon, 09 Feb 2004 14:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGz7-0001GH-Qi for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 14:22:21 -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 OAA05531 for ; Mon, 9 Feb 2004 14:22:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGz5-0000Mb-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 14:22:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGyI-0000Hy-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 14:21:32 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AqGxr-0000Bh-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 14:21:03 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i19JKJg01465; Mon, 9 Feb 2004 14:20:20 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1F334V3R; Mon, 9 Feb 2004 14:20:19 -0500 Received: from nortelnetworks.com (potti.engeast.baynetworks.com [47.17.140.52]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D8262A6T; Mon, 9 Feb 2004 14:20:18 -0500 Message-ID: <4027DD6C.C06C7A3B@nortelnetworks.com> Date: Mon, 09 Feb 2004 14:20:12 -0500 From: Rajesh Potti Organization: Nortel Networks X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jim Guichard CC: richard.spencer@bt.com, l3vpn@ietf.org, mpls@UU.NET Subject: Re: MPLS vs IP encap in RFC2547 References: Content-Type: multipart/alternative; boundary="------------563BAF143E33D9180974F665" 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: , List-Id: List-Post: List-Help: List-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=HTML_MESSAGE autolearn=no version=2.60 --------------563BAF143E33D9180974F665 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Richard, When a PE receives a packet from the CE, PEalso checks to make sure, it comes with a label, that it has announced to the CE. If PE did not announce that label to the CE, the packet is dropped. Rajesh Jim Guichard wrote: > Hi Richard, > > if the intruder is sat on an IP network, even if they gain access to a provider router and assertain the relevant label information for a given destination, how can they get the labelled packet into the provider core, assuming that an interface that is NOT enabled for MPLS switching receives the incoming packets ? Jim > > > >-----Original Message----- > > >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > > >richard.spencer@bt.com > > >Sent: Monday, February 09, 2004 1:48 PM > > >To: l3vpn@ietf.org; mpls@UU.NET > > >Subject: MPLS vs IP encap in RFC2547 > > > > > > > > >It has been asserted on this mailing list and in a couple of > > >IETF drafts, that using IP encapsulation techniques across a PSN > > >instead of MPLS for RFC2547 make it more difficult to protect > > >VPNs against spoofed attacks. > > > > > > > > > > > >I would like to challenge this assertion, as I believe that > > >using IP encapsulation in the PSN instead of MPLS actually makes > > >it easier to protect against spoofed VPN attacks. I am not a > > >security expert so I welcome any comments that explain where my > > >argument falls down. > > > > > > > > > > > >My argument is based on the fact that that MPLS networks can > > >forward VPN packets based on IP or MPLS (PHP is a good example > > >of this), and hence 'IP/MPLS' networks inherit the security > > >risks associated with both IP and MPLS forwarding. > > > > > > > > > > > >Fundamentally, this argument comes back to the fact that IP/MPLS > > >networks today use the same address space for control plane > > >traffic that they use for forwarding VPN packets in the data > > >plane, i.e. /32 loopback addresses that are used for LDP/BGP > > >sessions are also used as PE next hops for VPN packets. As > > >stated previously, one solution to the problem is to use > > >filtering; another is to use an OOB control plane. > > > > > > > > > > > >If an attacker is able to initiate an attack from within the > > >service provider network then the security risks associated with > > >IP/MPLS networks are comparable to other VPN technologies such > > >as ATM/FR. If however an attacker attempts to initiate an attack > > >from outside the provider network, then the security risks in an > > >IP/MPLS network are dependant on which routing instance the > > >interface connects to, i.e. a customer VRF or the global routing table. > > > > > > > > > > > >To provide justification for this argument, I will examine 3 > > >points of entry into the network where a spoofing attempt might > > >take place. > > > > > > > > > > > >1. Via a legitimate non-core facing managed interface at the > > >edge of the provider network. > > > > > > > > > > > >a) If the interface belongs to a VPN, then the VRF it belongs to > > >will only contain routes belonging to that particular VPN. This > > >would most likely be a customer-facing interface. > > > > > > > > > > > >If a packet is received with an address/label that belongs to a > > >different VPN or to the provider network, then the packet will > > >be dropped because a route to the destination will not exist > > >(i.e. route isolation is enforced). This is independent of > > >whatever encapsulation method (IP/GRE, MPLS) is used within the PSN. > > > > > > > > > > > >b) If the interface belongs to the service provider global > > >routing table, then the routing table will contain IGP routes, > > >and may contain Internet routes. This would most likely be an > > >interface facing the Internet or another AS/provider to support > > >inter-AS/provider VPNs. > > > > > > > > > > > >In order to protect against IP packet spoofing, ingress > > >filtering must be applied on the interface. This is independent > > >of whatever encapsulation method is used within the PSN. This is > > >a key point, a network running MPLS in the core can still > > >forward packets based on IP addresses it receives at the edge > > >(assuming IP is running on interfaces at the edge). > > > > > > > > > > > >If MPLS labelled packets are received on an interface but MPLS > > >is not enabled, then they should be dropped. This is independent > > >of whatever encapsulation is used across the PSN. > > > > > > > > > > > >If the PSN is using MPLS in the core, and MPLS is enabled on the > > >interface then filtering needs be used to drop spoofed MPLS > > >packets. This is in addition to the filtering required to > > >protect against spoofed IP packets. > > > > > > > > > > > >2. Via an illegal attack from a router interface within the > > >provider network by an intruder > > > > > > > > > > > >i) If an intruder has gained access to a router interface within > > >the provider network (edge or core), the intruder may also be > > >able to lookup routing/label information. If so, then the > > >intruder can use this information to carry out a VPN packet > > >spoofing attack. This is independent of whatever encapsulation > > >is used across the PSN. > > > > > > > > > > > >ii) If an intruder gains access to a router interface within the > > >provider network but cannot acquire routing/label information, > > >then brute force techniques must be used to spoof packets. In > > >order to spoof a VPN packet, an attacker must determine the > > >correct PSN label/IP destination addresses AND the correct VPN > > >label. If the PSN label/address is not valid, the first PE/P > > >router that receives the packet will drop it. If the PSN > > >label/address is correct but the VPN label is incorrect, then > > >the packet will be dropped by the egress PE. > > > > > > > > > > > >If the PSN supports IP only, then the probability of spoofing > > >success is based on: > > > > > > > > > > > >P(PSN destination IP address) x P(VPN label) > > > > > > > > > > > >If the PSN supports IP/MPLS forwarding then the probability is based on: > > > > > > > > > > > >P(PSN destination IP address) x P(VPN label) OR > > > > > >P(PSN label) x P(VPN label) > > > > > > > > > > > >Regardless of what the actual probabilities are, the probability > > >of a successful VPN packet spoof attack will always greater than > > >an IP only network. This is because packets can be forwarded > > >using IP destination addresses OR MPLS labels. > > > > > > > > > > > >3. Via an illegal attack from an intruder that has tapped into a > > >physical link within the provider network > > > > > > > > > > > >i) If an intruder has tapped into a physical link then it is > > >likely that they are able to snoop MPLS/IP packets to determine > > >what labels or IP addresses are being used. If so, then the > > >intruder can use this information to carry out a VPN packet > > >spoofing attack. This is independent of whatever encapsulation > > >is used across the PSN. > > > > > > > > > > > >ii) If an intruder has gained access to a physical link and for > > >whatever reason can only transmit packets, then brute force > > >techniques must be applied as described in 2 ii). > > > > > > > > > > > >In both 2 and 3, the only way to protect against this type of > > >attack is to use ensure physical network protection and to use > > >encryption/authentication. The point being that to protect > > >against these types of attack, these security measures must be > > >taken regardless of whether the PSN is IP or IP/MPLS. > > > > > > > > > > > >As I say, admittedly I'm not a security expert so I welcome any > > >comments that explain why my arguments are incorrect. > > > > > > > > > > > >Richard > > > -- Rajesh Potti. --------------563BAF143E33D9180974F665 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Richard,

 When a PE receives a packet from the CE, PEalso checks to make sure, it comes with a label, that it has announced to the CE.
 If PE did not announce that label to the CE, the packet is dropped.

Rajesh

Jim Guichard wrote:

Hi Richard,

if the intruder is sat on an IP network, even if they gain access to a provider router and assertain the relevant label information for a given destination, how can they get the labelled packet into the provider core, assuming that an interface that is NOT enabled for MPLS switching receives the incoming packets ? Jim

> >-----Original Message-----
> >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of
> >richard.spencer@bt.com
> >Sent: Monday, February 09, 2004 1:48 PM
> >To: l3vpn@ietf.org; mpls@UU.NET
> >Subject: MPLS vs IP encap in RFC2547
> >
> >
> >It has been asserted on this mailing list and in a couple of
> >IETF drafts, that using IP encapsulation techniques across a PSN
> >instead of MPLS for RFC2547 make it more difficult to protect
> >VPNs against spoofed attacks.
> >
> >
> >
> >I would like to challenge this assertion, as I believe that
> >using IP encapsulation in the PSN instead of MPLS actually makes
> >it easier to protect against spoofed VPN attacks. I am not a
> >security expert so I welcome any comments that explain where my
> >argument falls down.
> >
> >
> >
> >My argument is based on the fact that that MPLS networks can
> >forward VPN packets based on IP or MPLS (PHP is a good example
> >of this), and hence 'IP/MPLS' networks inherit the security
> >risks associated with both IP and MPLS forwarding.
> >
> >
> >
> >Fundamentally, this argument comes back to the fact that IP/MPLS
> >networks today use the same address space for control plane
> >traffic that they use for forwarding VPN packets in the data
> >plane, i.e. /32 loopback addresses that are used for LDP/BGP
> >sessions are also used as PE next hops for VPN packets. As
> >stated previously, one solution to the problem is to use
> >filtering; another is to use an OOB control plane.
> >
> >
> >
> >If an attacker is able to initiate an attack from within the
> >service provider network then the security risks associated with
> >IP/MPLS networks are comparable to other VPN technologies such
> >as ATM/FR. If however an attacker attempts to initiate an attack
> >from outside the provider network, then the security risks in an
> >IP/MPLS network are dependant on which routing instance the
> >interface connects to, i.e. a customer VRF or the global routing table.
> >
> >
> >
> >To provide justification for this argument, I will examine 3
> >points of entry into the network where a spoofing attempt might
> >take place.
> >
> >
> >
> >1. Via a legitimate non-core facing managed interface at the
> >edge of the provider network.
> >
> >
> >
> >a) If the interface belongs to a VPN, then the VRF it belongs to
> >will only contain routes belonging to that particular VPN. This
> >would most likely be a customer-facing interface.
> >
> >
> >
> >If a packet is received with an address/label that belongs to a
> >different VPN or to the provider network, then the packet will
> >be dropped because a route to the destination will not exist
> >(i.e. route isolation is enforced). This is independent of
> >whatever encapsulation method (IP/GRE, MPLS) is used within the PSN.
> >
> >
> >
> >b) If the interface belongs to the service provider global
> >routing table, then the routing table will contain IGP routes,
> >and may contain Internet routes. This would most likely be an
> >interface facing the Internet or another AS/provider to support
> >inter-AS/provider VPNs.
> >
> >
> >
> >In order to protect against IP packet spoofing, ingress
> >filtering must be applied on the interface. This is independent
> >of whatever encapsulation method is used within the PSN. This is
> >a key point, a network running MPLS in the core can still
> >forward packets based on IP addresses it receives at the edge
> >(assuming IP is running on interfaces at the edge).
> >
> >
> >
> >If MPLS labelled packets are received on an interface but MPLS
> >is not enabled, then they should be dropped. This is independent
> >of whatever encapsulation is used across the PSN.
> >
> >
> >
> >If the PSN is using MPLS in the core, and MPLS is enabled on the
> >interface then filtering needs be used to drop spoofed MPLS
> >packets. This is in addition to the filtering required to
> >protect against spoofed IP packets.
> >
> >
> >
> >2. Via an illegal attack from a router interface within the
> >provider network by an intruder
> >
> >
> >
> >i) If an intruder has gained access to a router interface within
> >the provider network (edge or core), the intruder may also be
> >able to lookup routing/label information. If so, then the
> >intruder can use this information to carry out a VPN packet
> >spoofing attack. This is independent of whatever encapsulation
> >is used across the PSN.
> >
> >
> >
> >ii) If an intruder gains access to a router interface within the
> >provider network but cannot acquire routing/label information,
> >then brute force techniques must be used to spoof packets. In
> >order to spoof a VPN packet, an attacker must determine the
> >correct PSN label/IP destination addresses AND the correct VPN
> >label. If the PSN label/address is not valid, the first PE/P
> >router that receives the packet will drop it. If the PSN
> >label/address is correct but the VPN label is incorrect, then
> >the packet will be dropped by the egress PE.
> >
> >
> >
> >If the PSN supports IP only, then the probability of spoofing
> >success is based on:
> >
> >
> >
> >P(PSN destination IP address) x P(VPN label)
> >
> >
> >
> >If the PSN supports IP/MPLS forwarding then the probability is based on:
> >
> >
> >
> >P(PSN destination IP address) x P(VPN label) OR
> >
> >P(PSN label) x P(VPN label)
> >
> >
> >
> >Regardless of what the actual probabilities are, the probability
> >of a successful VPN packet spoof attack will always greater than
> >an IP only network. This is because packets can be forwarded
> >using IP destination addresses OR MPLS labels.
> >
> >
> >
> >3. Via an illegal attack from an intruder that has tapped into a
> >physical link within the provider network
> >
> >
> >
> >i) If an intruder has tapped into a physical link then it is
> >likely that they are able to snoop MPLS/IP packets to determine
> >what labels or IP addresses are being used. If so, then the
> >intruder can use this information to carry out a VPN packet
> >spoofing attack. This is independent of whatever encapsulation
> >is used across the PSN.
> >
> >
> >
> >ii) If an intruder has gained access to a physical link and for
> >whatever reason can only transmit packets, then brute force
> >techniques must be applied as described in 2 ii).
> >
> >
> >
> >In both 2 and 3, the only way to protect against this type of
> >attack is to use ensure physical network protection and to use
> >encryption/authentication. The point being that to protect
> >against these types of attack, these security measures must be
> >taken regardless of whether the PSN is IP or IP/MPLS.
> >
> >
> >
> >As I say, admittedly I'm not a security expert so I welcome any
> >comments that explain why my arguments are incorrect.
> >
> >
> >
> >Richard
> >

-- 
Rajesh Potti.
  --------------563BAF143E33D9180974F665-- From exim@www1.ietf.org Mon Feb 9 14:27:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05785 for ; Mon, 9 Feb 2004 14:27:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH3t-0001gd-JD for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 14:27:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JRHNE006476 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 14:27:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH3t-0001gN-Dh for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:27:17 -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 OAA05770 for ; Mon, 9 Feb 2004 14:27:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH3q-0000pU-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 14:27:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqH2w-0000lB-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 14:26:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqH2f-0000gj-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 14:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH2g-0001ah-EQ; Mon, 09 Feb 2004 14:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH1w-0001WN-OV for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 14:25:16 -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 OAA05687 for ; Mon, 9 Feb 2004 14:25:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH1u-0000fN-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 14:25:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqH16-0000aO-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 14:24:26 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AqH0E-0000OM-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 14:23:30 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2004 20:23:36 +0100 Received: from cisco.com (amsterdam.cisco.com [144.254.74.238]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i19JMZL1028758; Mon, 9 Feb 2004 20:22:35 +0100 (MET) Received: from JGUICHARW2K (dhcp-10-86-162-232.cisco.com [10.86.162.232]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id UAA18155; Mon, 9 Feb 2004 20:22:55 +0100 (MET) From: "Jim Guichard" To: Cc: , , Subject: RE: MPLS vs IP encap in RFC2547 Date: Mon, 9 Feb 2004 14:15:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01C3EF17.2E5BF2D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4027DD6C.C06C7A3B@nortelnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal 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: , List-Id: List-Post: List-Help: List-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.1 required=5.0 tests=AWL,HTML_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0074_01C3EF17.2E5BF2D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit if the interface is an IP interface (e.g. MPLS forwarding is not enabled) then the router should drop ALL labelled packets - Jim -----Original Message----- From: rpotti@nortelnetworks.com [mailto:rpotti@nortelnetworks.com] Sent: Monday, February 09, 2004 2:20 PM To: Jim Guichard Cc: richard.spencer@bt.com; l3vpn@ietf.org; mpls@UU.NET Subject: Re: MPLS vs IP encap in RFC2547 Hi Richard, When a PE receives a packet from the CE, PEalso checks to make sure, it comes with a label, that it has announced to the CE. If PE did not announce that label to the CE, the packet is dropped. Rajesh Jim Guichard wrote: Hi Richard, if the intruder is sat on an IP network, even if they gain access to a provider router and assertain the relevant label information for a given destination, how can they get the labelled packet into the provider core, assuming that an interface that is NOT enabled for MPLS switching receives the incoming packets ? Jim > >-----Original Message----- > >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > >richard.spencer@bt.com > >Sent: Monday, February 09, 2004 1:48 PM > >To: l3vpn@ietf.org; mpls@UU.NET > >Subject: MPLS vs IP encap in RFC2547 > > > > > >It has been asserted on this mailing list and in a couple of > >IETF drafts, that using IP encapsulation techniques across a PSN > >instead of MPLS for RFC2547 make it more difficult to protect > >VPNs against spoofed attacks. > > > > > > > >I would like to challenge this assertion, as I believe that > >using IP encapsulation in the PSN instead of MPLS actually makes > >it easier to protect against spoofed VPN attacks. I am not a > >security expert so I welcome any comments that explain where my > >argument falls down. > > > > > > > >My argument is based on the fact that that MPLS networks can > >forward VPN packets based on IP or MPLS (PHP is a good example > >of this), and hence 'IP/MPLS' networks inherit the security > >risks associated with both IP and MPLS forwarding. > > > > > > > >Fundamentally, this argument comes back to the fact that IP/MPLS > >networks today use the same address space for control plane > >traffic that they use for forwarding VPN packets in the data > >plane, i.e. /32 loopback addresses that are used for LDP/BGP > >sessions are also used as PE next hops for VPN packets. As > >stated previously, one solution to the problem is to use > >filtering; another is to use an OOB control plane. > > > > > > > >If an attacker is able to initiate an attack from within the > >service provider network then the security risks associated with > >IP/MPLS networks are comparable to other VPN technologies such > >as ATM/FR. If however an attacker attempts to initiate an attack > >from outside the provider network, then the security risks in an > >IP/MPLS network are dependant on which routing instance the > >interface connects to, i.e. a customer VRF or the global routing table. > > > > > > > >To provide justification for this argument, I will examine 3 > >points of entry into the network where a spoofing attempt might > >take place. > > > > > > > >1. Via a legitimate non-core facing managed interface at the > >edge of the provider network. > > > > > > > >a) If the interface belongs to a VPN, then the VRF it belongs to > >will only contain routes belonging to that particular VPN. This > >would most likely be a customer-facing interface. > > > > > > > >If a packet is received with an address/label that belongs to a > >different VPN or to the provider network, then the packet will > >be dropped because a route to the destination will not exist > >(i.e. route isolation is enforced). This is independent of > >whatever encapsulation method (IP/GRE, MPLS) is used within the PSN. > > > > > > > >b) If the interface belongs to the service provider global > >routing table, then the routing table will contain IGP routes, > >and may contain Internet routes. This would most likely be an > >interface facing the Internet or another AS/provider to support > >inter-AS/provider VPNs. > > > > > > > >In order to protect against IP packet spoofing, ingress > >filtering must be applied on the interface. This is independent > >of whatever encapsulation method is used within the PSN. This is > >a key point, a network running MPLS in the core can still > >forward packets based on IP addresses it receives at the edge > >(assuming IP is running on interfaces at the edge). > > > > > > > >If MPLS labelled packets are received on an interface but MPLS > >is not enabled, then they should be dropped. This is independent > >of whatever encapsulation is used across the PSN. > > > > > > > >If the PSN is using MPLS in the core, and MPLS is enabled on the > >interface then filtering needs be used to drop spoofed MPLS > >packets. This is in addition to the filtering required to > >protect against spoofed IP packets. > > > > > > > >2. Via an illegal attack from a router interface within the > >provider network by an intruder > > > > > > > >i) If an intruder has gained access to a router interface within > >the provider network (edge or core), the intruder may also be > >able to lookup routing/label information. If so, then the > >intruder can use this information to carry out a VPN packet > >spoofing attack. This is independent of whatever encapsulation > >is used across the PSN. > > > > > > > >ii) If an intruder gains access to a router interface within the > >provider network but cannot acquire routing/label information, > >then brute force techniques must be used to spoof packets. In > >order to spoof a VPN packet, an attacker must determine the > >correct PSN label/IP destination addresses AND the correct VPN > >label. If the PSN label/address is not valid, the first PE/P > >router that receives the packet will drop it. If the PSN > >label/address is correct but the VPN label is incorrect, then > >the packet will be dropped by the egress PE. > > > > > > > >If the PSN supports IP only, then the probability of spoofing > >success is based on: > > > > > > > >P(PSN destination IP address) x P(VPN label) > > > > > > > >If the PSN supports IP/MPLS forwarding then the probability is based on: > > > > > > > >P(PSN destination IP address) x P(VPN label) OR > > > >P(PSN label) x P(VPN label) > > > > > > > >Regardless of what the actual probabilities are, the probability > >of a successful VPN packet spoof attack will always greater than > >an IP only network. This is because packets can be forwarded > >using IP destination addresses OR MPLS labels. > > > > > > > >3. Via an illegal attack from an intruder that has tapped into a > >physical link within the provider network > > > > > > > >i) If an intruder has tapped into a physical link then it is > >likely that they are able to snoop MPLS/IP packets to determine > >what labels or IP addresses are being used. If so, then the > >intruder can use this information to carry out a VPN packet > >spoofing attack. This is independent of whatever encapsulation > >is used across the PSN. > > > > > > > >ii) If an intruder has gained access to a physical link and for > >whatever reason can only transmit packets, then brute force > >techniques must be applied as described in 2 ii). > > > > > > > >In both 2 and 3, the only way to protect against this type of > >attack is to use ensure physical network protection and to use > >encryption/authentication. The point being that to protect > >against these types of attack, these security measures must be > >taken regardless of whether the PSN is IP or IP/MPLS. > > > > > > > >As I say, admittedly I'm not a security expert so I welcome any > >comments that explain why my arguments are incorrect. > > > > > > > >Richard > > -- Rajesh Potti. ------=_NextPart_000_0074_01C3EF17.2E5BF2D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
if the=20 interface is an IP interface (e.g. MPLS forwarding is not enabled) then = the=20 router should drop ALL labelled packets - Jim
-----Original Message-----
From: = rpotti@nortelnetworks.com=20 [mailto:rpotti@nortelnetworks.com]
Sent: Monday, February = 09, 2004=20 2:20 PM
To: Jim Guichard
Cc: = richard.spencer@bt.com;=20 l3vpn@ietf.org; mpls@UU.NET
Subject: Re: MPLS vs IP encap in = RFC2547

Hi Richard,=20

 When a PE receives a packet from the CE, PEalso checks = to make=20 sure, it comes with a label, that it has announced to the CE. =
 If=20 PE did not announce that label to the CE, the packet is dropped.=20

Rajesh=20

Jim Guichard wrote:=20

Hi Richard,=20

if the intruder is sat on an IP network, even if they gain access = to a=20 provider router and assertain the relevant label information for a = given=20 destination, how can they get the labelled packet into the provider = core,=20 assuming that an interface that is NOT enabled for MPLS switching = receives=20 the incoming packets ? Jim=20

> >-----Original Message-----
> >From:=20 l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On = Behalf=20 Of
> >richard.spencer@bt.com
> >Sent: Monday, = February=20 09, 2004 1:48 PM
> >To: l3vpn@ietf.org; mpls@UU.NET =
>=20 >Subject: MPLS vs IP encap in RFC2547
> >
> > =
> >It has been asserted on this mailing list and in a = couple of=20
> >IETF drafts, that using IP encapsulation techniques = across a=20 PSN
> >instead of MPLS for RFC2547 make it more difficult = to=20 protect
> >VPNs against spoofed attacks.
> > =
>=20 >
> >
> >I would like to challenge this = assertion, as=20 I believe that
> >using IP encapsulation in the PSN = instead of=20 MPLS actually makes
> >it easier to protect against = spoofed VPN=20 attacks. I am not a
> >security expert so I welcome any = comments=20 that explain where my
> >argument falls down.
> = >=20
> >
> >
> >My argument is based on the = fact=20 that that MPLS networks can
> >forward VPN packets based = on IP or=20 MPLS (PHP is a good example
> >of this), and hence = 'IP/MPLS'=20 networks inherit the security
> >risks associated with = both IP and=20 MPLS forwarding.
> >
> >
> >
>=20 >Fundamentally, this argument comes back to the fact that IP/MPLS =
> >networks today use the same address space for control = plane=20
> >traffic that they use for forwarding VPN packets in the = data=20
> >plane, i.e. /32 loopback addresses that are used for = LDP/BGP=20
> >sessions are also used as PE next hops for VPN packets. = As=20
> >stated previously, one solution to the problem is to = use=20
> >filtering; another is to use an OOB control plane. =
>=20 >
> >
> >
> >If an attacker is able = to=20 initiate an attack from within the
> >service provider = network=20 then the security risks associated with
> >IP/MPLS = networks are=20 comparable to other VPN technologies such
> >as ATM/FR. If = however=20 an attacker attempts to initiate an attack
> >from outside = the=20 provider network, then the security risks in an
> >IP/MPLS = network=20 are dependant on which routing instance the
> >interface = connects=20 to, i.e. a customer VRF or the global routing table.
> > =
>=20 >
> >
> >To provide justification for this = argument,=20 I will examine 3
> >points of entry into the network where = a=20 spoofing attempt might
> >take place.
> > =
> >=20
> >
> >1. Via a legitimate non-core facing = managed=20 interface at the
> >edge of the provider network.
> = >=20
> >
> >
> >a) If the interface belongs = to a=20 VPN, then the VRF it belongs to
> >will only contain = routes=20 belonging to that particular VPN. This
> >would most = likely be a=20 customer-facing interface.
> >
> >
> > =
> >If a packet is received with an address/label that = belongs to a=20
> >different VPN or to the provider network, then the = packet will=20
> >be dropped because a route to the destination will not = exist=20
> >(i.e. route isolation is enforced). This is independent = of=20
> >whatever encapsulation method (IP/GRE, MPLS) is used = within the=20 PSN.
> >
> >
> >
> >b) If = the=20 interface belongs to the service provider global
> = >routing table,=20 then the routing table will contain IGP routes,
> >and may = contain=20 Internet routes. This would most likely be an
> >interface = facing=20 the Internet or another AS/provider to support
>=20 >inter-AS/provider VPNs.
> >
> >
> = >=20
> >In order to protect against IP packet spoofing, ingress =
> >filtering must be applied on the interface. This is = independent=20
> >of whatever encapsulation method is used within the = PSN. This=20 is
> >a key point, a network running MPLS in the core can = still=20
> >forward packets based on IP addresses it receives at = the edge=20
> >(assuming IP is running on interfaces at the edge). =
>=20 >
> >
> >
> >If MPLS labelled = packets are=20 received on an interface but MPLS
> >is not enabled, then = they=20 should be dropped. This is independent
> >of whatever=20 encapsulation is used across the PSN.
> >
> > =
>=20 >
> >If the PSN is using MPLS in the core, and MPLS is = enabled=20 on the
> >interface then filtering needs be used to drop = spoofed=20 MPLS
> >packets. This is in addition to the filtering = required to=20
> >protect against spoofed IP packets.
> > =
> >=20
> >
> >2. Via an illegal attack from a router = interface=20 within the
> >provider network by an intruder
> = >=20
> >
> >
> >i) If an intruder has = gained access=20 to a router interface within
> >the provider network (edge = or=20 core), the intruder may also be
> >able to lookup = routing/label=20 information. If so, then the
> >intruder can use this = information=20 to carry out a VPN packet
> >spoofing attack. This is = independent=20 of whatever encapsulation
> >is used across the PSN. =
> >=20
> >
> >
> >ii) If an intruder gains = access to=20 a router interface within the
> >provider network but = cannot=20 acquire routing/label information,
> >then brute force = techniques=20 must be used to spoof packets. In
> >order to spoof a VPN = packet,=20 an attacker must determine the
> >correct PSN label/IP = destination=20 addresses AND the correct VPN
> >label. If the PSN = label/address=20 is not valid, the first PE/P
> >router that receives the = packet=20 will drop it. If the PSN
> >label/address is correct but = the VPN=20 label is incorrect, then
> >the packet will be dropped by = the=20 egress PE.
> >
> >
> >
> >If = the PSN=20 supports IP only, then the probability of spoofing
> = >success is=20 based on:
> >
> >
> >
> = >P(PSN=20 destination IP address) x P(VPN label)
> >
> > =
>=20 >
> >If the PSN supports IP/MPLS forwarding then the=20 probability is based on:
> >
> >
> > =
>=20 >P(PSN destination IP address) x P(VPN label) OR
> > =
>=20 >P(PSN label) x P(VPN label)
> >
> >
> = >=20
> >Regardless of what the actual probabilities are, the=20 probability
> >of a successful VPN packet spoof attack = will always=20 greater than
> >an IP only network. This is because = packets can be=20 forwarded
> >using IP destination addresses OR MPLS = labels.=20
> >
> >
> >
> >3. Via an = illegal=20 attack from an intruder that has tapped into a
> >physical = link=20 within the provider network
> >
> >
> = >=20
> >i) If an intruder has tapped into a physical link then = it is=20
> >likely that they are able to snoop MPLS/IP packets to = determine=20
> >what labels or IP addresses are being used. If so, then = the=20
> >intruder can use this information to carry out a VPN = packet=20
> >spoofing attack. This is independent of whatever = encapsulation=20
> >is used across the PSN.
> >
> > =
>=20 >
> >ii) If an intruder has gained access to a physical = link=20 and for
> >whatever reason can only transmit packets, then = brute=20 force
> >techniques must be applied as described in 2 ii). =
> >
> >
> >
> >In both 2 and = 3, the=20 only way to protect against this type of
> >attack is to = use=20 ensure physical network protection and to use
>=20 >encryption/authentication. The point being that to protect =
>=20 >against these types of attack, these security measures must be =
>=20 >taken regardless of whether the PSN is IP or IP/MPLS.
> = >=20
> >
> >
> >As I say, admittedly I'm = not a=20 security expert so I welcome any
> >comments that explain = why my=20 arguments are incorrect.
> >
> >
> > =
>=20 >Richard
> >

-- 
Rajesh Potti.
  ------=_NextPart_000_0074_01C3EF17.2E5BF2D0-- From exim@www1.ietf.org Mon Feb 9 16:26:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14639 for ; Mon, 9 Feb 2004 16:26:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIvG-0003fS-ER for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 16:26:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LQU9X014098 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 16:26:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIvG-0003fJ-B1 for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 16:26:30 -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 QAA14530 for ; Mon, 9 Feb 2004 16:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIvE-0004PH-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 16:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIss-0003t3-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 16:24:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIr1-0003S4-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 16:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIqx-0002pU-Hi; Mon, 09 Feb 2004 16:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIqp-0002of-Ut for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 16:21:55 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13826; Mon, 9 Feb 2004 16:21:52 -0500 (EST) Message-Id: <200402092121.QAA13826@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-01.txt Date: Mon, 09 Feb 2004 16:21:52 -0500 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Using BGP as an Auto-Discovery Mechanism for Provider-provisioned VPNs Author(s) : H. Ould-Brahim Filename : draft-ietf-l3vpn-bgpvpn-auto-01.txt Pages : 12 Date : 2004-2-9 In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The purpose of this draft is to define a BGP based auto-discovery mechanism for both layer-2 VPN architectures and layer-3 VPNs ([VPN-VR]). This mechanism is based on the approach used by [RFC2547-bis] for distributing VPN routing information within the service provider(s). Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-bgpvpn-auto-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-9162152.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgpvpn-auto-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9162152.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Mon Feb 9 17:12:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14642 for ; Mon, 9 Feb 2004 16:26:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIvG-0003fq-It for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 16:26:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LQU24014116 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 16:26:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIvG-0003fU-F2 for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 16:26:30 -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 QAA14532 for ; Mon, 9 Feb 2004 16:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIvE-0004P9-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 16:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIsr-0003sr-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 16:24:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIr1-0003S3-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 16:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIqx-0002pG-36; Mon, 09 Feb 2004 16:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIqd-0002nu-Ro for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 16:21:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13794; Mon, 9 Feb 2004 16:21:40 -0500 (EST) Message-Id: <200402092121.QAA13794@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-02.txt Date: Mon, 09 Feb 2004 16:21:40 -0500 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : MPLS/BGP Layer 3 Virtual Private Network Management Information Base Using Author(s) : T. Nadeau Filename : draft-ietf-l3vpn-mpls-vpn-mib-02.txt Pages : 36 Date : 2004-2-9 This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multi-protocol Label Switching Layer-3 Virtual Private Networks on a Multi-Protocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-mpls-vpn-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-9162139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-mpls-vpn-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-mpls-vpn-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-9162139.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Mon Feb 9 18:35:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00761 for ; Mon, 9 Feb 2004 18:35:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKvk-0003oy-Sx for l3vpn-archive@odin.ietf.org; Mon, 09 Feb 2004 18:35:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19NZ8cJ014682 for l3vpn-archive@odin.ietf.org; Mon, 9 Feb 2004 18:35:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKvk-0003oj-Mi for l3vpn-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 18:35:08 -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 SAA00675 for ; Mon, 9 Feb 2004 18:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKvh-0001N0-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 18:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKuq-0001CD-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 18:34:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqKtk-000102-00 for l3vpn-web-archive@ietf.org; Mon, 09 Feb 2004 18:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKth-0003bo-RW; Mon, 09 Feb 2004 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKtU-0003bQ-5f for l3vpn@optimus.ietf.org; Mon, 09 Feb 2004 18:32:48 -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 SAA00408 for ; Mon, 9 Feb 2004 18:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKtR-0000wu-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 18:32:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKsS-0000p9-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 18:31:44 -0500 Received: from door.sniff.de ([82.212.219.2]) by ietf-mx with esmtp (Exim 4.12) id 1AqKru-0000iB-00 for l3vpn@ietf.org; Mon, 09 Feb 2004 18:31:10 -0500 Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 243682AA0B; Mon, 9 Feb 2004 23:32:15 +0000 (GMT) In-Reply-To: <20040209162828.56766.qmail@web21403.mail.yahoo.com> References: <20040209162828.56766.qmail@web21403.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org, mpls@UU.NET From: Marc Binderberger Subject: Re: Multi-As Backbones Date: Tue, 10 Feb 2004 00:35:22 +0100 To: Roger Pottier X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Roger, > As you said, this could have some scaling limitations. Does LDP assign > a label to each route learnt by the IGP. I think, LDP does not assign > labels for BGP Learnt routes. Can cisco be configured to send labels > for some BGP Learnt routes? From a test setup. The box is a 7507 w/ 12.0(25)S1: router bgp 65017 bgp router-id 192.168.249.250 bgp cluster-id 3239121353 bgp log-neighbor-changes bgp deterministic-med bgp bestpath compare-routerid neighbor 192.168.249.17 remote-as 65018 neighbor 192.168.249.17 password 7 070D2D4D460B151015100E1E4A6465 ! address-family ipv4 redistribute isis TEST level-2 route-map ISIS-TO-BGP neighbor 192.168.249.17 activate neighbor 192.168.249.17 send-label no auto-summary no synchronization exit-address-family R1-7507#show ip bgp BGP table version is 4, local router ID is 192.168.249.250 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 192.168.249.251/32 192.168.249.46 10 32768 ? *> 192.168.17.206/32 192.168.249.17 10 0 65018 ? R1-7507#show ip bgp 192.168.17.206/32 BGP routing table entry for 192.168.17.206/32, version 4 Paths: (1 available, best #1) Not advertised to any peer 65018 192.168.249.17 from 192.168.249.17 (192.168.249.241) Origin incomplete, metric 10, localpref 100, valid, external, best, mpls labels in/out 106/18 So R1 receives label "18" via eBGP, the LDP binds local label "106". This happens even without a redistribution into the IGP. On router "R3" (belonging to AS65017): R3-7204#show mpls ldp bindings 192.168.17.206 32 detail tib entry: 192.168.17.206/32, rev 37 local binding: tag: 203 Advertised to: 192.168.249.250:0 remote binding: tsr: 192.168.249.250:0, tag: 106 BTW, with 12.2(18)S it did not work. >> Using iBGP IPv4+label - haven't tested yet as no IOS for 7600 (our PE >> plattform) was available supporting this. As I understand the theory >> this results in a packet with 3 labels minimum: the MP-BGP VPN label >> at >> the bottom, then the IPv4 next hop label and topmost the LDP label to >> the ASBR. > > The IPv4 Nexthop Label (Middle one) would be assigned by the ASBR? Yes. But let me try to get 1-2 more test boxes in the setup. Seeing is believing :-) Regards, Marc -- Marc Binderberger Powered by *BSD ;-) From exim@www1.ietf.org Tue Feb 10 02:17:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02850 for ; Tue, 10 Feb 2004 02:17:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS8N-00071m-Qv for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 02:16:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A7GdW1027011 for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 02:16:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS8N-00071V-2M for l3vpn-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 02:16:39 -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 CAA02805 for ; Tue, 10 Feb 2004 02:16:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS8J-0001nS-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 02:16:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS7N-0001j8-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 02:15:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqS6p-0001f4-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 02:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS6n-0006Vk-1D; Tue, 10 Feb 2004 02:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS6T-0006PN-CA for l3vpn@optimus.ietf.org; Tue, 10 Feb 2004 02:14:41 -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 CAA02674 for ; Tue, 10 Feb 2004 02:14:38 -0500 (EST) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS6P-0001ej-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 02:14:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS5h-0001aN-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 02:13:55 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139] helo=i2kc05-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AqS5F-0001TK-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 02:13:25 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 07:12:56 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 07:12:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: MPLS vs IP encap in RFC2547 Date: Tue, 10 Feb 2004 07:12:55 -0000 Message-ID: Thread-Topic: MPLS vs IP encap in RFC2547 Thread-Index: AcPvQDBq5SSlKnaPQQyQPDZRlynXagAGpCrj To: , , X-OriginalArrivalTime: 10 Feb 2004 07:12:55.0884 (UTC) FILETIME=[4E4D58C0:01C3EFA5] Content-Transfer-Encoding: base64 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: , List-Id: List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgSmltLA0KDQogDQoNClRoYW5rcyBmb3IgeW91IGNvbW1lbnQsIEkgYW0gbm90IHN1cmUgd2hp Y2ggc3BlY2lmaWMgc2NlbmFyaW8geW91IGFyZSByZWZlcnJpbmcgdG8sIGNhbiB5b3UgZWxhYm9y YXRlIGFzIHRvIHdoaWNoIHBvaW50KHMpIG9mIGVudHJ5IHlvdSBhcmUgcmVmZXJyaW5nIHRvLCB3 aGF0IHRoZSBQU04gdHlwZSBpcyBhbmQgd2hhdCB0eXBlIG9mIHBhY2tldHMgKElQIG9yIE1QTFMp IGFyZSBiZWluZyByZWNlaXZlZCBieSB0aGUgaW50ZXJmYWNlPw0KDQogDQoNCkFyZSB5b3UgYXNr aW5nIGV2ZW4gaWYgYW4gaW50cnVkZXIgbGVhcm5zIGxhYmVsIGluZm9ybWF0aW9uIGZvciBhIGdp dmVuIGRlc3RpbmF0aW9uLCBob3cgY2FuIHBhY2tldHMgYmUgc2VudCB0byBhbiBpbnRlcmZhY2Ug dGhhdCBkb2VzIG5vdCBoYXZlIE1QTFMgZW5hYmxlZD8gSWYgdGhpcyBpcyB3aGF0IHlvdSBhcmUg YXNraW5nIHRoZW4gSSBhZ3JlZSB0aGF0IHRoZXkgY2FuJ3QuIEFzIEkgc3RhdGVkIGluIG15IG9y aWdpbmFsIG1lc3NhZ2UgIklmIE1QTFMgbGFiZWxsZWQgcGFja2V0cyBhcmUgcmVjZWl2ZWQgb24g YW4gaW50ZXJmYWNlIGJ1dCBNUExTIGlzIG5vdCBlbmFibGVkLCB0aGVuIHRoZXkgc2hvdWxkIGJl IGRyb3BwZWQuIFRoaXMgaXMgaW5kZXBlbmRlbnQgb2Ygd2hhdGV2ZXIgZW5jYXBzdWxhdGlvbiBp cyB1c2VkIGFjcm9zcyB0aGUgUFNOLiINCg0KIA0KDQpIb3dldmVyLCBJIG1heSBiZSBtaXNpbnRl cnByZXRpbmcgd2hhdCB5b3UgYXJlIHNheWluZy4NCg0KIA0KDQpSaWNoYXJkIA0KDQoJLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogSmltIEd1aWNoYXJkIFttYWlsdG86amd1aWNo YXJAY2lzY28uY29tXSANCglTZW50OiBNb24gMDkvMDIvMjAwNCAxNDowMSANCglUbzogU3BlbmNl cixSLFJpY2hhcmQsWEdINSBSOyBsM3ZwbkBpZXRmLm9yZzsgbXBsc0BVVS5ORVQgDQoJQ2M6IA0K CVN1YmplY3Q6IFJFOiBNUExTIHZzIElQIGVuY2FwIGluIFJGQzI1NDcNCgkNCgkNCg0KCUhpIFJp Y2hhcmQsDQoJDQoJaWYgdGhlIGludHJ1ZGVyIGlzIHNhdCBvbiBhbiBJUCBuZXR3b3JrLCBldmVu IGlmIHRoZXkgZ2FpbiBhY2Nlc3MgdG8gYSBwcm92aWRlciByb3V0ZXIgYW5kIGFzc2VydGFpbiB0 aGUgcmVsZXZhbnQgbGFiZWwgaW5mb3JtYXRpb24gZm9yIGEgZ2l2ZW4gZGVzdGluYXRpb24sIGhv dyBjYW4gdGhleSBnZXQgdGhlIGxhYmVsbGVkIHBhY2tldCBpbnRvIHRoZSBwcm92aWRlciBjb3Jl LCBhc3N1bWluZyB0aGF0IGFuIGludGVyZmFjZSB0aGF0IGlzIE5PVCBlbmFibGVkIGZvciBNUExT IHN3aXRjaGluZyByZWNlaXZlcyB0aGUgaW5jb21pbmcgcGFja2V0cyA/IEppbQ0KCQ0KCT4gPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiA+RnJvbTogbDN2cG4tYWRtaW5AaWV0Zi5vcmcg W21haWx0bzpsM3Zwbi1hZG1pbkBpZXRmLm9yZ11PbiBCZWhhbGYgT2YNCgk+ID5yaWNoYXJkLnNw ZW5jZXJAYnQuY29tDQoJPiA+U2VudDogTW9uZGF5LCBGZWJydWFyeSAwOSwgMjAwNCAxOjQ4IFBN DQoJPiA+VG86IGwzdnBuQGlldGYub3JnOyBtcGxzQFVVLk5FVA0KCT4gPlN1YmplY3Q6IE1QTFMg dnMgSVAgZW5jYXAgaW4gUkZDMjU0Nw0KCT4gPg0KCT4gPg0KCT4gPkl0IGhhcyBiZWVuIGFzc2Vy dGVkIG9uIHRoaXMgbWFpbGluZyBsaXN0IGFuZCBpbiBhIGNvdXBsZSBvZg0KCT4gPklFVEYgZHJh ZnRzLCB0aGF0IHVzaW5nIElQIGVuY2Fwc3VsYXRpb24gdGVjaG5pcXVlcyBhY3Jvc3MgYSBQU04N Cgk+ID5pbnN0ZWFkIG9mIE1QTFMgZm9yIFJGQzI1NDcgbWFrZSBpdCBtb3JlIGRpZmZpY3VsdCB0 byBwcm90ZWN0DQoJPiA+VlBOcyBhZ2FpbnN0IHNwb29mZWQgYXR0YWNrcy4NCgk+ID4NCgk+ID4N Cgk+ID4NCgk+ID5JIHdvdWxkIGxpa2UgdG8gY2hhbGxlbmdlIHRoaXMgYXNzZXJ0aW9uLCBhcyBJ IGJlbGlldmUgdGhhdA0KCT4gPnVzaW5nIElQIGVuY2Fwc3VsYXRpb24gaW4gdGhlIFBTTiBpbnN0 ZWFkIG9mIE1QTFMgYWN0dWFsbHkgbWFrZXMNCgk+ID5pdCBlYXNpZXIgdG8gcHJvdGVjdCBhZ2Fp bnN0IHNwb29mZWQgVlBOIGF0dGFja3MuIEkgYW0gbm90IGENCgk+ID5zZWN1cml0eSBleHBlcnQg c28gSSB3ZWxjb21lIGFueSBjb21tZW50cyB0aGF0IGV4cGxhaW4gd2hlcmUgbXkNCgk+ID5hcmd1 bWVudCBmYWxscyBkb3duLg0KCT4gPg0KCT4gPg0KCT4gPg0KCT4gPk15IGFyZ3VtZW50IGlzIGJh c2VkIG9uIHRoZSBmYWN0IHRoYXQgdGhhdCBNUExTIG5ldHdvcmtzIGNhbg0KCT4gPmZvcndhcmQg VlBOIHBhY2tldHMgYmFzZWQgb24gSVAgb3IgTVBMUyAoUEhQIGlzIGEgZ29vZCBleGFtcGxlDQoJ PiA+b2YgdGhpcyksIGFuZCBoZW5jZSAnSVAvTVBMUycgbmV0d29ya3MgaW5oZXJpdCB0aGUgc2Vj dXJpdHkNCgk+ID5yaXNrcyBhc3NvY2lhdGVkIHdpdGggYm90aCBJUCBhbmQgTVBMUyBmb3J3YXJk aW5nLg0KCT4gPg0KCT4gPg0KCT4gPg0KCT4gPkZ1bmRhbWVudGFsbHksIHRoaXMgYXJndW1lbnQg Y29tZXMgYmFjayB0byB0aGUgZmFjdCB0aGF0IElQL01QTFMNCgk+ID5uZXR3b3JrcyB0b2RheSB1 c2UgdGhlIHNhbWUgYWRkcmVzcyBzcGFjZSBmb3IgY29udHJvbCBwbGFuZQ0KCT4gPnRyYWZmaWMg dGhhdCB0aGV5IHVzZSBmb3IgZm9yd2FyZGluZyBWUE4gcGFja2V0cyBpbiB0aGUgZGF0YQ0KCT4g PnBsYW5lLCBpLmUuIC8zMiBsb29wYmFjayBhZGRyZXNzZXMgdGhhdCBhcmUgdXNlZCBmb3IgTERQ L0JHUA0KCT4gPnNlc3Npb25zIGFyZSBhbHNvIHVzZWQgYXMgUEUgbmV4dCBob3BzIGZvciBWUE4g cGFja2V0cy4gQXMNCgk+ID5zdGF0ZWQgcHJldmlvdXNseSwgb25lIHNvbHV0aW9uIHRvIHRoZSBw cm9ibGVtIGlzIHRvIHVzZQ0KCT4gPmZpbHRlcmluZzsgYW5vdGhlciBpcyB0byB1c2UgYW4gT09C IGNvbnRyb2wgcGxhbmUuDQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+SWYgYW4gYXR0YWNrZXIgaXMg YWJsZSB0byBpbml0aWF0ZSBhbiBhdHRhY2sgZnJvbSB3aXRoaW4gdGhlDQoJPiA+c2VydmljZSBw cm92aWRlciBuZXR3b3JrIHRoZW4gdGhlIHNlY3VyaXR5IHJpc2tzIGFzc29jaWF0ZWQgd2l0aA0K CT4gPklQL01QTFMgbmV0d29ya3MgYXJlIGNvbXBhcmFibGUgdG8gb3RoZXIgVlBOIHRlY2hub2xv Z2llcyBzdWNoDQoJPiA+YXMgQVRNL0ZSLiBJZiBob3dldmVyIGFuIGF0dGFja2VyIGF0dGVtcHRz IHRvIGluaXRpYXRlIGFuIGF0dGFjaw0KCT4gPmZyb20gb3V0c2lkZSB0aGUgcHJvdmlkZXIgbmV0 d29yaywgdGhlbiB0aGUgc2VjdXJpdHkgcmlza3MgaW4gYW4NCgk+ID5JUC9NUExTIG5ldHdvcmsg YXJlIGRlcGVuZGFudCBvbiB3aGljaCByb3V0aW5nIGluc3RhbmNlIHRoZQ0KCT4gPmludGVyZmFj ZSBjb25uZWN0cyB0bywgaS5lLiBhIGN1c3RvbWVyIFZSRiBvciB0aGUgZ2xvYmFsIHJvdXRpbmcg dGFibGUuDQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+VG8gcHJvdmlkZSBqdXN0aWZpY2F0aW9uIGZv ciB0aGlzIGFyZ3VtZW50LCBJIHdpbGwgZXhhbWluZSAzDQoJPiA+cG9pbnRzIG9mIGVudHJ5IGlu dG8gdGhlIG5ldHdvcmsgd2hlcmUgYSBzcG9vZmluZyBhdHRlbXB0IG1pZ2h0DQoJPiA+dGFrZSBw bGFjZS4NCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID4xLiBWaWEgYSBsZWdpdGltYXRlIG5vbi1jb3Jl IGZhY2luZyBtYW5hZ2VkIGludGVyZmFjZSBhdCB0aGUNCgk+ID5lZGdlIG9mIHRoZSBwcm92aWRl ciBuZXR3b3JrLg0KCT4gPg0KCT4gPg0KCT4gPg0KCT4gPmEpIElmIHRoZSBpbnRlcmZhY2UgYmVs b25ncyB0byBhIFZQTiwgdGhlbiB0aGUgVlJGIGl0IGJlbG9uZ3MgdG8NCgk+ID53aWxsIG9ubHkg Y29udGFpbiByb3V0ZXMgYmVsb25naW5nIHRvIHRoYXQgcGFydGljdWxhciBWUE4uIFRoaXMNCgk+ ID53b3VsZCBtb3N0IGxpa2VseSBiZSBhIGN1c3RvbWVyLWZhY2luZyBpbnRlcmZhY2UuDQoJPiA+ DQoJPiA+DQoJPiA+DQoJPiA+SWYgYSBwYWNrZXQgaXMgcmVjZWl2ZWQgd2l0aCBhbiBhZGRyZXNz L2xhYmVsIHRoYXQgYmVsb25ncyB0byBhDQoJPiA+ZGlmZmVyZW50IFZQTiBvciB0byB0aGUgcHJv dmlkZXIgbmV0d29yaywgdGhlbiB0aGUgcGFja2V0IHdpbGwNCgk+ID5iZSBkcm9wcGVkIGJlY2F1 c2UgYSByb3V0ZSB0byB0aGUgZGVzdGluYXRpb24gd2lsbCBub3QgZXhpc3QNCgk+ID4oaS5lLiBy b3V0ZSBpc29sYXRpb24gaXMgZW5mb3JjZWQpLiBUaGlzIGlzIGluZGVwZW5kZW50IG9mDQoJPiA+ d2hhdGV2ZXIgZW5jYXBzdWxhdGlvbiBtZXRob2QgKElQL0dSRSwgTVBMUykgaXMgdXNlZCB3aXRo aW4gdGhlIFBTTi4NCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID5iKSBJZiB0aGUgaW50ZXJmYWNlIGJl bG9uZ3MgdG8gdGhlIHNlcnZpY2UgcHJvdmlkZXIgZ2xvYmFsDQoJPiA+cm91dGluZyB0YWJsZSwg dGhlbiB0aGUgcm91dGluZyB0YWJsZSB3aWxsIGNvbnRhaW4gSUdQIHJvdXRlcywNCgk+ID5hbmQg bWF5IGNvbnRhaW4gSW50ZXJuZXQgcm91dGVzLiBUaGlzIHdvdWxkIG1vc3QgbGlrZWx5IGJlIGFu DQoJPiA+aW50ZXJmYWNlIGZhY2luZyB0aGUgSW50ZXJuZXQgb3IgYW5vdGhlciBBUy9wcm92aWRl ciB0byBzdXBwb3J0DQoJPiA+aW50ZXItQVMvcHJvdmlkZXIgVlBOcy4NCgk+ID4NCgk+ID4NCgk+ ID4NCgk+ID5JbiBvcmRlciB0byBwcm90ZWN0IGFnYWluc3QgSVAgcGFja2V0IHNwb29maW5nLCBp bmdyZXNzDQoJPiA+ZmlsdGVyaW5nIG11c3QgYmUgYXBwbGllZCBvbiB0aGUgaW50ZXJmYWNlLiBU aGlzIGlzIGluZGVwZW5kZW50DQoJPiA+b2Ygd2hhdGV2ZXIgZW5jYXBzdWxhdGlvbiBtZXRob2Qg aXMgdXNlZCB3aXRoaW4gdGhlIFBTTi4gVGhpcyBpcw0KCT4gPmEga2V5IHBvaW50LCBhIG5ldHdv cmsgcnVubmluZyBNUExTIGluIHRoZSBjb3JlIGNhbiBzdGlsbA0KCT4gPmZvcndhcmQgcGFja2V0 cyBiYXNlZCBvbiBJUCBhZGRyZXNzZXMgaXQgcmVjZWl2ZXMgYXQgdGhlIGVkZ2UNCgk+ID4oYXNz dW1pbmcgSVAgaXMgcnVubmluZyBvbiBpbnRlcmZhY2VzIGF0IHRoZSBlZGdlKS4NCgk+ID4NCgk+ ID4NCgk+ID4NCgk+ID5JZiBNUExTIGxhYmVsbGVkIHBhY2tldHMgYXJlIHJlY2VpdmVkIG9uIGFu IGludGVyZmFjZSBidXQgTVBMUw0KCT4gPmlzIG5vdCBlbmFibGVkLCB0aGVuIHRoZXkgc2hvdWxk IGJlIGRyb3BwZWQuIFRoaXMgaXMgaW5kZXBlbmRlbnQNCgk+ID5vZiB3aGF0ZXZlciBlbmNhcHN1 bGF0aW9uIGlzIHVzZWQgYWNyb3NzIHRoZSBQU04uDQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+SWYg dGhlIFBTTiBpcyB1c2luZyBNUExTIGluIHRoZSBjb3JlLCBhbmQgTVBMUyBpcyBlbmFibGVkIG9u IHRoZQ0KCT4gPmludGVyZmFjZSB0aGVuIGZpbHRlcmluZyBuZWVkcyBiZSB1c2VkIHRvIGRyb3Ag c3Bvb2ZlZCBNUExTDQoJPiA+cGFja2V0cy4gVGhpcyBpcyBpbiBhZGRpdGlvbiB0byB0aGUgZmls dGVyaW5nIHJlcXVpcmVkIHRvDQoJPiA+cHJvdGVjdCBhZ2FpbnN0IHNwb29mZWQgSVAgcGFja2V0 cy4NCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID4yLiBWaWEgYW4gaWxsZWdhbCBhdHRhY2sgZnJvbSBh IHJvdXRlciBpbnRlcmZhY2Ugd2l0aGluIHRoZQ0KCT4gPnByb3ZpZGVyIG5ldHdvcmsgYnkgYW4g aW50cnVkZXINCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID5pKSBJZiBhbiBpbnRydWRlciBoYXMgZ2Fp bmVkIGFjY2VzcyB0byBhIHJvdXRlciBpbnRlcmZhY2Ugd2l0aGluDQoJPiA+dGhlIHByb3ZpZGVy IG5ldHdvcmsgKGVkZ2Ugb3IgY29yZSksIHRoZSBpbnRydWRlciBtYXkgYWxzbyBiZQ0KCT4gPmFi bGUgdG8gbG9va3VwIHJvdXRpbmcvbGFiZWwgaW5mb3JtYXRpb24uIElmIHNvLCB0aGVuIHRoZQ0K CT4gPmludHJ1ZGVyIGNhbiB1c2UgdGhpcyBpbmZvcm1hdGlvbiB0byBjYXJyeSBvdXQgYSBWUE4g cGFja2V0DQoJPiA+c3Bvb2ZpbmcgYXR0YWNrLiBUaGlzIGlzIGluZGVwZW5kZW50IG9mIHdoYXRl dmVyIGVuY2Fwc3VsYXRpb24NCgk+ID5pcyB1c2VkIGFjcm9zcyB0aGUgUFNOLg0KCT4gPg0KCT4g Pg0KCT4gPg0KCT4gPmlpKSBJZiBhbiBpbnRydWRlciBnYWlucyBhY2Nlc3MgdG8gYSByb3V0ZXIg aW50ZXJmYWNlIHdpdGhpbiB0aGUNCgk+ID5wcm92aWRlciBuZXR3b3JrIGJ1dCBjYW5ub3QgYWNx dWlyZSByb3V0aW5nL2xhYmVsIGluZm9ybWF0aW9uLA0KCT4gPnRoZW4gYnJ1dGUgZm9yY2UgdGVj aG5pcXVlcyBtdXN0IGJlIHVzZWQgdG8gc3Bvb2YgcGFja2V0cy4gSW4NCgk+ID5vcmRlciB0byBz cG9vZiBhIFZQTiBwYWNrZXQsIGFuIGF0dGFja2VyIG11c3QgZGV0ZXJtaW5lIHRoZQ0KCT4gPmNv cnJlY3QgUFNOIGxhYmVsL0lQIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBBTkQgdGhlIGNvcnJlY3Qg VlBODQoJPiA+bGFiZWwuIElmIHRoZSBQU04gbGFiZWwvYWRkcmVzcyBpcyBub3QgdmFsaWQsIHRo ZSBmaXJzdCBQRS9QDQoJPiA+cm91dGVyIHRoYXQgcmVjZWl2ZXMgdGhlIHBhY2tldCB3aWxsIGRy b3AgaXQuIElmIHRoZSBQU04NCgk+ID5sYWJlbC9hZGRyZXNzIGlzIGNvcnJlY3QgYnV0IHRoZSBW UE4gbGFiZWwgaXMgaW5jb3JyZWN0LCB0aGVuDQoJPiA+dGhlIHBhY2tldCB3aWxsIGJlIGRyb3Bw ZWQgYnkgdGhlIGVncmVzcyBQRS4NCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID5JZiB0aGUgUFNOIHN1 cHBvcnRzIElQIG9ubHksIHRoZW4gdGhlIHByb2JhYmlsaXR5IG9mIHNwb29maW5nDQoJPiA+c3Vj Y2VzcyBpcyBiYXNlZCBvbjoNCgk+ID4NCgk+ID4NCgk+ID4NCgk+ID5QKFBTTiBkZXN0aW5hdGlv biBJUCBhZGRyZXNzKSB4IFAoVlBOIGxhYmVsKQ0KCT4gPg0KCT4gPg0KCT4gPg0KCT4gPklmIHRo ZSBQU04gc3VwcG9ydHMgSVAvTVBMUyBmb3J3YXJkaW5nIHRoZW4gdGhlIHByb2JhYmlsaXR5IGlz IGJhc2VkIG9uOg0KCT4gPg0KCT4gPg0KCT4gPg0KCT4gPlAoUFNOIGRlc3RpbmF0aW9uIElQIGFk ZHJlc3MpIHggUChWUE4gbGFiZWwpIE9SDQoJPiA+DQoJPiA+UChQU04gbGFiZWwpIHggUChWUE4g bGFiZWwpDQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+UmVnYXJkbGVzcyBvZiB3aGF0IHRoZSBhY3R1 YWwgcHJvYmFiaWxpdGllcyBhcmUsIHRoZSBwcm9iYWJpbGl0eQ0KCT4gPm9mIGEgc3VjY2Vzc2Z1 bCBWUE4gcGFja2V0IHNwb29mIGF0dGFjayB3aWxsIGFsd2F5cyBncmVhdGVyIHRoYW4NCgk+ID5h biBJUCBvbmx5IG5ldHdvcmsuIFRoaXMgaXMgYmVjYXVzZSBwYWNrZXRzIGNhbiBiZSBmb3J3YXJk ZWQNCgk+ID51c2luZyBJUCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgT1IgTVBMUyBsYWJlbHMuDQoJ PiA+DQoJPiA+DQoJPiA+DQoJPiA+My4gVmlhIGFuIGlsbGVnYWwgYXR0YWNrIGZyb20gYW4gaW50 cnVkZXIgdGhhdCBoYXMgdGFwcGVkIGludG8gYQ0KCT4gPnBoeXNpY2FsIGxpbmsgd2l0aGluIHRo ZSBwcm92aWRlciBuZXR3b3JrDQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+aSkgSWYgYW4gaW50cnVk ZXIgaGFzIHRhcHBlZCBpbnRvIGEgcGh5c2ljYWwgbGluayB0aGVuIGl0IGlzDQoJPiA+bGlrZWx5 IHRoYXQgdGhleSBhcmUgYWJsZSB0byBzbm9vcCBNUExTL0lQIHBhY2tldHMgdG8gZGV0ZXJtaW5l DQoJPiA+d2hhdCBsYWJlbHMgb3IgSVAgYWRkcmVzc2VzIGFyZSBiZWluZyB1c2VkLiBJZiBzbywg dGhlbiB0aGUNCgk+ID5pbnRydWRlciBjYW4gdXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gY2Fycnkg b3V0IGEgVlBOIHBhY2tldA0KCT4gPnNwb29maW5nIGF0dGFjay4gVGhpcyBpcyBpbmRlcGVuZGVu dCBvZiB3aGF0ZXZlciBlbmNhcHN1bGF0aW9uDQoJPiA+aXMgdXNlZCBhY3Jvc3MgdGhlIFBTTi4N Cgk+ID4NCgk+ID4NCgk+ID4NCgk+ID5paSkgSWYgYW4gaW50cnVkZXIgaGFzIGdhaW5lZCBhY2Nl c3MgdG8gYSBwaHlzaWNhbCBsaW5rIGFuZCBmb3INCgk+ID53aGF0ZXZlciByZWFzb24gY2FuIG9u bHkgdHJhbnNtaXQgcGFja2V0cywgdGhlbiBicnV0ZSBmb3JjZQ0KCT4gPnRlY2huaXF1ZXMgbXVz dCBiZSBhcHBsaWVkIGFzIGRlc2NyaWJlZCBpbiAyIGlpKS4NCgk+ID4NCgk+ID4NCgk+ID4NCgk+ ID5JbiBib3RoIDIgYW5kIDMsIHRoZSBvbmx5IHdheSB0byBwcm90ZWN0IGFnYWluc3QgdGhpcyB0 eXBlIG9mDQoJPiA+YXR0YWNrIGlzIHRvIHVzZSBlbnN1cmUgcGh5c2ljYWwgbmV0d29yayBwcm90 ZWN0aW9uIGFuZCB0byB1c2UNCgk+ID5lbmNyeXB0aW9uL2F1dGhlbnRpY2F0aW9uLiBUaGUgcG9p bnQgYmVpbmcgdGhhdCB0byBwcm90ZWN0DQoJPiA+YWdhaW5zdCB0aGVzZSB0eXBlcyBvZiBhdHRh Y2ssIHRoZXNlIHNlY3VyaXR5IG1lYXN1cmVzIG11c3QgYmUNCgk+ID50YWtlbiByZWdhcmRsZXNz IG9mIHdoZXRoZXIgdGhlIFBTTiBpcyBJUCBvciBJUC9NUExTLg0KCT4gPg0KCT4gPg0KCT4gPg0K CT4gPkFzIEkgc2F5LCBhZG1pdHRlZGx5IEknbSBub3QgYSBzZWN1cml0eSBleHBlcnQgc28gSSB3 ZWxjb21lIGFueQ0KCT4gPmNvbW1lbnRzIHRoYXQgZXhwbGFpbiB3aHkgbXkgYXJndW1lbnRzIGFy ZSBpbmNvcnJlY3QuDQoJPiA+DQoJPiA+DQoJPiA+DQoJPiA+UmljaGFyZA0KCT4gPg0KCQ0KCQ0K DQo= From exim@www1.ietf.org Tue Feb 10 02:31:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03801 for ; Tue, 10 Feb 2004 02:31:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSLx-0002IZ-79 for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 02:30:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A7UfRT008829 for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 02:30:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSLw-0002IF-Au for l3vpn-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 02:30:40 -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 CAA03766 for ; Tue, 10 Feb 2004 02:30:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSLs-0002y0-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 02:30:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSKy-0002lc-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 02:29:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqSKK-0002gy-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 02:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSKL-00029f-GO; Tue, 10 Feb 2004 02:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSJy-00022d-Dl for l3vpn@optimus.ietf.org; Tue, 10 Feb 2004 02:28:38 -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 CAA03654 for ; Tue, 10 Feb 2004 02:28:35 -0500 (EST) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSJu-0002fu-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 02:28:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSIx-0002bj-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 02:27:36 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150] helo=i2kc02-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AqSIJ-0002TL-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 02:26:56 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by i2kc02-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 07:26:26 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 07:26:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: MPLS vs IP encap in RFC2547 Date: Tue, 10 Feb 2004 07:26:25 -0000 Message-ID: Thread-Topic: MPLS vs IP encap in RFC2547 Thread-Index: AcPvQcpwLGanWqIPQsmrxKisBXat/gAZVOZ4 To: , Cc: , X-OriginalArrivalTime: 10 Feb 2004 07:26:25.0879 (UTC) FILETIME=[3118C670:01C3EFA7] Content-Transfer-Encoding: base64 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: , List-Id: List-Post: List-Help: List-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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgUmFqZXNoLA0KDQogDQoNCkFncmVlZCwgaG93ZXZlciBJIGRvIG5vdCBiZWxpZXZlIEkgc3Rh dGUgYW55d2hlcmUgaW4gbXkgb3JpZ2luYWwgcG9zdCBhbnl0aGluZyBjb250cmFyeSB0byB5b3Vy IGNvbW1lbnQuIA0KDQogDQoNCkluIG15IG9yaWdpbmFsIHBvc3QgSSBzdGF0ZSAiSWYgdGhlIFBT TiBpcyB1c2luZyBNUExTIGluIHRoZSBjb3JlLCBhbmQgTVBMUyBpcyBlbmFibGVkIG9uIHRoZSBp bnRlcmZhY2UgdGhlbiBmaWx0ZXJpbmcgbmVlZHMgYmUgdXNlZCB0byBkcm9wIHNwb29mZWQgTVBM UyBwYWNrZXRzLiIgSSB1c2UgdGhlIHRlcm0gZmlsdGVyaW5nIGxvb3NlbHkgdG8gcmVmZXIgdG8g YW55IG1lY2hhbmlzbXMgdGhhdCBjaGVja3MgTVBMUyBsYWJlbHMgZm9yIHJlY2VpdmVkIHBhY2tl dHMgYW5kIGRyb3BzL2ZvcndhcmRzIHRoZSBwYWNrZXRzIGFjY29yZGluZ2x5LiBBcyB5b3Ugc2F5 LCB0aGlzIG1heSBiZSBhIGNoZWNrIHRvIGVuc3VyZSB0aGF0IHRoZSByZWNlaXZlZCBwYWNrZXQg Y29udGFpbnMgYSBsYWJlbCB0aGF0IGhhcyBiZWVuIGFubm91bmNlZCB0byB0aGUgQ0UuDQoNCiAN Cg0KUmVnYXJkcywNCg0KIA0KDQpSaWNoYXJkDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LSANCglGcm9tOiBSYWplc2ggUG90dGkgW21haWx0bzpycG90dGlAbm9ydGVsbmV0d29ya3MuY29t XSANCglTZW50OiBNb24gMDkvMDIvMjAwNCAxNDoyMCANCglUbzogSmltIEd1aWNoYXJkIA0KCUNj OiBTcGVuY2VyLFIsUmljaGFyZCxYR0g1IFI7IGwzdnBuQGlldGYub3JnOyBtcGxzQFVVLk5FVCAN CglTdWJqZWN0OiBSZTogTVBMUyB2cyBJUCBlbmNhcCBpbiBSRkMyNTQ3DQoJDQoJDQoJSGkgUmlj aGFyZCwgDQoNCgkgV2hlbiBhIFBFIHJlY2VpdmVzIGEgcGFja2V0IGZyb20gdGhlIENFLCBQRWFs c28gY2hlY2tzIHRvIG1ha2Ugc3VyZSwgaXQgY29tZXMgd2l0aCBhIGxhYmVsLCB0aGF0IGl0IGhh cyBhbm5vdW5jZWQgdG8gdGhlIENFLiANCgkgSWYgUEUgZGlkIG5vdCBhbm5vdW5jZSB0aGF0IGxh YmVsIHRvIHRoZSBDRSwgdGhlIHBhY2tldCBpcyBkcm9wcGVkLiANCg0KCVJhamVzaCANCg0KCUpp bSBHdWljaGFyZCB3cm90ZTogDQoNCgkJSGkgUmljaGFyZCwgDQoNCgkJaWYgdGhlIGludHJ1ZGVy IGlzIHNhdCBvbiBhbiBJUCBuZXR3b3JrLCBldmVuIGlmIHRoZXkgZ2FpbiBhY2Nlc3MgdG8gYSBw cm92aWRlciByb3V0ZXIgYW5kIGFzc2VydGFpbiB0aGUgcmVsZXZhbnQgbGFiZWwgaW5mb3JtYXRp b24gZm9yIGEgZ2l2ZW4gZGVzdGluYXRpb24sIGhvdyBjYW4gdGhleSBnZXQgdGhlIGxhYmVsbGVk IHBhY2tldCBpbnRvIHRoZSBwcm92aWRlciBjb3JlLCBhc3N1bWluZyB0aGF0IGFuIGludGVyZmFj ZSB0aGF0IGlzIE5PVCBlbmFibGVkIGZvciBNUExTIHN3aXRjaGluZyByZWNlaXZlcyB0aGUgaW5j b21pbmcgcGFja2V0cyA/IEppbSANCg0KCQk+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSAN CgkJPiA+RnJvbTogbDN2cG4tYWRtaW5AaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1hZG1pbkBpZXRm Lm9yZ11PbiBCZWhhbGYgT2YgDQoJCT4gPnJpY2hhcmQuc3BlbmNlckBidC5jb20gDQoJCT4gPlNl bnQ6IE1vbmRheSwgRmVicnVhcnkgMDksIDIwMDQgMTo0OCBQTSANCgkJPiA+VG86IGwzdnBuQGll dGYub3JnOyBtcGxzQFVVLk5FVCANCgkJPiA+U3ViamVjdDogTVBMUyB2cyBJUCBlbmNhcCBpbiBS RkMyNTQ3IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+SXQgaGFzIGJlZW4gYXNzZXJ0ZWQgb24gdGhp cyBtYWlsaW5nIGxpc3QgYW5kIGluIGEgY291cGxlIG9mIA0KCQk+ID5JRVRGIGRyYWZ0cywgdGhh dCB1c2luZyBJUCBlbmNhcHN1bGF0aW9uIHRlY2huaXF1ZXMgYWNyb3NzIGEgUFNOIA0KCQk+ID5p bnN0ZWFkIG9mIE1QTFMgZm9yIFJGQzI1NDcgbWFrZSBpdCBtb3JlIGRpZmZpY3VsdCB0byBwcm90 ZWN0IA0KCQk+ID5WUE5zIGFnYWluc3Qgc3Bvb2ZlZCBhdHRhY2tzLiANCgkJPiA+IA0KCQk+ID4g DQoJCT4gPiANCgkJPiA+SSB3b3VsZCBsaWtlIHRvIGNoYWxsZW5nZSB0aGlzIGFzc2VydGlvbiwg YXMgSSBiZWxpZXZlIHRoYXQgDQoJCT4gPnVzaW5nIElQIGVuY2Fwc3VsYXRpb24gaW4gdGhlIFBT TiBpbnN0ZWFkIG9mIE1QTFMgYWN0dWFsbHkgbWFrZXMgDQoJCT4gPml0IGVhc2llciB0byBwcm90 ZWN0IGFnYWluc3Qgc3Bvb2ZlZCBWUE4gYXR0YWNrcy4gSSBhbSBub3QgYSANCgkJPiA+c2VjdXJp dHkgZXhwZXJ0IHNvIEkgd2VsY29tZSBhbnkgY29tbWVudHMgdGhhdCBleHBsYWluIHdoZXJlIG15 IA0KCQk+ID5hcmd1bWVudCBmYWxscyBkb3duLiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPiANCgkJ PiA+TXkgYXJndW1lbnQgaXMgYmFzZWQgb24gdGhlIGZhY3QgdGhhdCB0aGF0IE1QTFMgbmV0d29y a3MgY2FuIA0KCQk+ID5mb3J3YXJkIFZQTiBwYWNrZXRzIGJhc2VkIG9uIElQIG9yIE1QTFMgKFBI UCBpcyBhIGdvb2QgZXhhbXBsZSANCgkJPiA+b2YgdGhpcyksIGFuZCBoZW5jZSAnSVAvTVBMUycg bmV0d29ya3MgaW5oZXJpdCB0aGUgc2VjdXJpdHkgDQoJCT4gPnJpc2tzIGFzc29jaWF0ZWQgd2l0 aCBib3RoIElQIGFuZCBNUExTIGZvcndhcmRpbmcuIA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+IA0K CQk+ID5GdW5kYW1lbnRhbGx5LCB0aGlzIGFyZ3VtZW50IGNvbWVzIGJhY2sgdG8gdGhlIGZhY3Qg dGhhdCBJUC9NUExTIA0KCQk+ID5uZXR3b3JrcyB0b2RheSB1c2UgdGhlIHNhbWUgYWRkcmVzcyBz cGFjZSBmb3IgY29udHJvbCBwbGFuZSANCgkJPiA+dHJhZmZpYyB0aGF0IHRoZXkgdXNlIGZvciBm b3J3YXJkaW5nIFZQTiBwYWNrZXRzIGluIHRoZSBkYXRhIA0KCQk+ID5wbGFuZSwgaS5lLiAvMzIg bG9vcGJhY2sgYWRkcmVzc2VzIHRoYXQgYXJlIHVzZWQgZm9yIExEUC9CR1AgDQoJCT4gPnNlc3Np b25zIGFyZSBhbHNvIHVzZWQgYXMgUEUgbmV4dCBob3BzIGZvciBWUE4gcGFja2V0cy4gQXMgDQoJ CT4gPnN0YXRlZCBwcmV2aW91c2x5LCBvbmUgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gaXMgdG8g dXNlIA0KCQk+ID5maWx0ZXJpbmc7IGFub3RoZXIgaXMgdG8gdXNlIGFuIE9PQiBjb250cm9sIHBs YW5lLiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+SWYgYW4gYXR0YWNrZXIgaXMgYWJs ZSB0byBpbml0aWF0ZSBhbiBhdHRhY2sgZnJvbSB3aXRoaW4gdGhlIA0KCQk+ID5zZXJ2aWNlIHBy b3ZpZGVyIG5ldHdvcmsgdGhlbiB0aGUgc2VjdXJpdHkgcmlza3MgYXNzb2NpYXRlZCB3aXRoIA0K CQk+ID5JUC9NUExTIG5ldHdvcmtzIGFyZSBjb21wYXJhYmxlIHRvIG90aGVyIFZQTiB0ZWNobm9s b2dpZXMgc3VjaCANCgkJPiA+YXMgQVRNL0ZSLiBJZiBob3dldmVyIGFuIGF0dGFja2VyIGF0dGVt cHRzIHRvIGluaXRpYXRlIGFuIGF0dGFjayANCgkJPiA+ZnJvbSBvdXRzaWRlIHRoZSBwcm92aWRl ciBuZXR3b3JrLCB0aGVuIHRoZSBzZWN1cml0eSByaXNrcyBpbiBhbiANCgkJPiA+SVAvTVBMUyBu ZXR3b3JrIGFyZSBkZXBlbmRhbnQgb24gd2hpY2ggcm91dGluZyBpbnN0YW5jZSB0aGUgDQoJCT4g PmludGVyZmFjZSBjb25uZWN0cyB0bywgaS5lLiBhIGN1c3RvbWVyIFZSRiBvciB0aGUgZ2xvYmFs IHJvdXRpbmcgdGFibGUuIA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+IA0KCQk+ID5UbyBwcm92aWRl IGp1c3RpZmljYXRpb24gZm9yIHRoaXMgYXJndW1lbnQsIEkgd2lsbCBleGFtaW5lIDMgDQoJCT4g PnBvaW50cyBvZiBlbnRyeSBpbnRvIHRoZSBuZXR3b3JrIHdoZXJlIGEgc3Bvb2ZpbmcgYXR0ZW1w dCBtaWdodCANCgkJPiA+dGFrZSBwbGFjZS4gDQoJCT4gPiANCgkJPiA+IA0KCQk+ID4gDQoJCT4g PjEuIFZpYSBhIGxlZ2l0aW1hdGUgbm9uLWNvcmUgZmFjaW5nIG1hbmFnZWQgaW50ZXJmYWNlIGF0 IHRoZSANCgkJPiA+ZWRnZSBvZiB0aGUgcHJvdmlkZXIgbmV0d29yay4gDQoJCT4gPiANCgkJPiA+ IA0KCQk+ID4gDQoJCT4gPmEpIElmIHRoZSBpbnRlcmZhY2UgYmVsb25ncyB0byBhIFZQTiwgdGhl biB0aGUgVlJGIGl0IGJlbG9uZ3MgdG8gDQoJCT4gPndpbGwgb25seSBjb250YWluIHJvdXRlcyBi ZWxvbmdpbmcgdG8gdGhhdCBwYXJ0aWN1bGFyIFZQTi4gVGhpcyANCgkJPiA+d291bGQgbW9zdCBs aWtlbHkgYmUgYSBjdXN0b21lci1mYWNpbmcgaW50ZXJmYWNlLiANCgkJPiA+IA0KCQk+ID4gDQoJ CT4gPiANCgkJPiA+SWYgYSBwYWNrZXQgaXMgcmVjZWl2ZWQgd2l0aCBhbiBhZGRyZXNzL2xhYmVs IHRoYXQgYmVsb25ncyB0byBhIA0KCQk+ID5kaWZmZXJlbnQgVlBOIG9yIHRvIHRoZSBwcm92aWRl ciBuZXR3b3JrLCB0aGVuIHRoZSBwYWNrZXQgd2lsbCANCgkJPiA+YmUgZHJvcHBlZCBiZWNhdXNl IGEgcm91dGUgdG8gdGhlIGRlc3RpbmF0aW9uIHdpbGwgbm90IGV4aXN0IA0KCQk+ID4oaS5lLiBy b3V0ZSBpc29sYXRpb24gaXMgZW5mb3JjZWQpLiBUaGlzIGlzIGluZGVwZW5kZW50IG9mIA0KCQk+ ID53aGF0ZXZlciBlbmNhcHN1bGF0aW9uIG1ldGhvZCAoSVAvR1JFLCBNUExTKSBpcyB1c2VkIHdp dGhpbiB0aGUgUFNOLiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+YikgSWYgdGhlIGlu dGVyZmFjZSBiZWxvbmdzIHRvIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGdsb2JhbCANCgkJPiA+cm91 dGluZyB0YWJsZSwgdGhlbiB0aGUgcm91dGluZyB0YWJsZSB3aWxsIGNvbnRhaW4gSUdQIHJvdXRl cywgDQoJCT4gPmFuZCBtYXkgY29udGFpbiBJbnRlcm5ldCByb3V0ZXMuIFRoaXMgd291bGQgbW9z dCBsaWtlbHkgYmUgYW4gDQoJCT4gPmludGVyZmFjZSBmYWNpbmcgdGhlIEludGVybmV0IG9yIGFu b3RoZXIgQVMvcHJvdmlkZXIgdG8gc3VwcG9ydCANCgkJPiA+aW50ZXItQVMvcHJvdmlkZXIgVlBO cy4gDQoJCT4gPiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPkluIG9yZGVyIHRvIHByb3RlY3QgYWdh aW5zdCBJUCBwYWNrZXQgc3Bvb2ZpbmcsIGluZ3Jlc3MgDQoJCT4gPmZpbHRlcmluZyBtdXN0IGJl IGFwcGxpZWQgb24gdGhlIGludGVyZmFjZS4gVGhpcyBpcyBpbmRlcGVuZGVudCANCgkJPiA+b2Yg d2hhdGV2ZXIgZW5jYXBzdWxhdGlvbiBtZXRob2QgaXMgdXNlZCB3aXRoaW4gdGhlIFBTTi4gVGhp cyBpcyANCgkJPiA+YSBrZXkgcG9pbnQsIGEgbmV0d29yayBydW5uaW5nIE1QTFMgaW4gdGhlIGNv cmUgY2FuIHN0aWxsIA0KCQk+ID5mb3J3YXJkIHBhY2tldHMgYmFzZWQgb24gSVAgYWRkcmVzc2Vz IGl0IHJlY2VpdmVzIGF0IHRoZSBlZGdlIA0KCQk+ID4oYXNzdW1pbmcgSVAgaXMgcnVubmluZyBv biBpbnRlcmZhY2VzIGF0IHRoZSBlZGdlKS4gDQoJCT4gPiANCgkJPiA+IA0KCQk+ID4gDQoJCT4g PklmIE1QTFMgbGFiZWxsZWQgcGFja2V0cyBhcmUgcmVjZWl2ZWQgb24gYW4gaW50ZXJmYWNlIGJ1 dCBNUExTIA0KCQk+ID5pcyBub3QgZW5hYmxlZCwgdGhlbiB0aGV5IHNob3VsZCBiZSBkcm9wcGVk LiBUaGlzIGlzIGluZGVwZW5kZW50IA0KCQk+ID5vZiB3aGF0ZXZlciBlbmNhcHN1bGF0aW9uIGlz IHVzZWQgYWNyb3NzIHRoZSBQU04uIA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+IA0KCQk+ID5JZiB0 aGUgUFNOIGlzIHVzaW5nIE1QTFMgaW4gdGhlIGNvcmUsIGFuZCBNUExTIGlzIGVuYWJsZWQgb24g dGhlIA0KCQk+ID5pbnRlcmZhY2UgdGhlbiBmaWx0ZXJpbmcgbmVlZHMgYmUgdXNlZCB0byBkcm9w IHNwb29mZWQgTVBMUyANCgkJPiA+cGFja2V0cy4gVGhpcyBpcyBpbiBhZGRpdGlvbiB0byB0aGUg ZmlsdGVyaW5nIHJlcXVpcmVkIHRvIA0KCQk+ID5wcm90ZWN0IGFnYWluc3Qgc3Bvb2ZlZCBJUCBw YWNrZXRzLiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+Mi4gVmlhIGFuIGlsbGVnYWwg YXR0YWNrIGZyb20gYSByb3V0ZXIgaW50ZXJmYWNlIHdpdGhpbiB0aGUgDQoJCT4gPnByb3ZpZGVy IG5ldHdvcmsgYnkgYW4gaW50cnVkZXIgDQoJCT4gPiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPmkp IElmIGFuIGludHJ1ZGVyIGhhcyBnYWluZWQgYWNjZXNzIHRvIGEgcm91dGVyIGludGVyZmFjZSB3 aXRoaW4gDQoJCT4gPnRoZSBwcm92aWRlciBuZXR3b3JrIChlZGdlIG9yIGNvcmUpLCB0aGUgaW50 cnVkZXIgbWF5IGFsc28gYmUgDQoJCT4gPmFibGUgdG8gbG9va3VwIHJvdXRpbmcvbGFiZWwgaW5m b3JtYXRpb24uIElmIHNvLCB0aGVuIHRoZSANCgkJPiA+aW50cnVkZXIgY2FuIHVzZSB0aGlzIGlu Zm9ybWF0aW9uIHRvIGNhcnJ5IG91dCBhIFZQTiBwYWNrZXQgDQoJCT4gPnNwb29maW5nIGF0dGFj ay4gVGhpcyBpcyBpbmRlcGVuZGVudCBvZiB3aGF0ZXZlciBlbmNhcHN1bGF0aW9uIA0KCQk+ID5p cyB1c2VkIGFjcm9zcyB0aGUgUFNOLiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+aWkp IElmIGFuIGludHJ1ZGVyIGdhaW5zIGFjY2VzcyB0byBhIHJvdXRlciBpbnRlcmZhY2Ugd2l0aGlu IHRoZSANCgkJPiA+cHJvdmlkZXIgbmV0d29yayBidXQgY2Fubm90IGFjcXVpcmUgcm91dGluZy9s YWJlbCBpbmZvcm1hdGlvbiwgDQoJCT4gPnRoZW4gYnJ1dGUgZm9yY2UgdGVjaG5pcXVlcyBtdXN0 IGJlIHVzZWQgdG8gc3Bvb2YgcGFja2V0cy4gSW4gDQoJCT4gPm9yZGVyIHRvIHNwb29mIGEgVlBO IHBhY2tldCwgYW4gYXR0YWNrZXIgbXVzdCBkZXRlcm1pbmUgdGhlIA0KCQk+ID5jb3JyZWN0IFBT TiBsYWJlbC9JUCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgQU5EIHRoZSBjb3JyZWN0IFZQTiANCgkJ PiA+bGFiZWwuIElmIHRoZSBQU04gbGFiZWwvYWRkcmVzcyBpcyBub3QgdmFsaWQsIHRoZSBmaXJz dCBQRS9QIA0KCQk+ID5yb3V0ZXIgdGhhdCByZWNlaXZlcyB0aGUgcGFja2V0IHdpbGwgZHJvcCBp dC4gSWYgdGhlIFBTTiANCgkJPiA+bGFiZWwvYWRkcmVzcyBpcyBjb3JyZWN0IGJ1dCB0aGUgVlBO IGxhYmVsIGlzIGluY29ycmVjdCwgdGhlbiANCgkJPiA+dGhlIHBhY2tldCB3aWxsIGJlIGRyb3Bw ZWQgYnkgdGhlIGVncmVzcyBQRS4gDQoJCT4gPiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPklmIHRo ZSBQU04gc3VwcG9ydHMgSVAgb25seSwgdGhlbiB0aGUgcHJvYmFiaWxpdHkgb2Ygc3Bvb2Zpbmcg DQoJCT4gPnN1Y2Nlc3MgaXMgYmFzZWQgb246IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+IA0KCQk+ ID5QKFBTTiBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzKSB4IFAoVlBOIGxhYmVsKSANCgkJPiA+IA0K CQk+ID4gDQoJCT4gPiANCgkJPiA+SWYgdGhlIFBTTiBzdXBwb3J0cyBJUC9NUExTIGZvcndhcmRp bmcgdGhlbiB0aGUgcHJvYmFiaWxpdHkgaXMgYmFzZWQgb246IA0KCQk+ID4gDQoJCT4gPiANCgkJ PiA+IA0KCQk+ID5QKFBTTiBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzKSB4IFAoVlBOIGxhYmVsKSBP UiANCgkJPiA+IA0KCQk+ID5QKFBTTiBsYWJlbCkgeCBQKFZQTiBsYWJlbCkgDQoJCT4gPiANCgkJ PiA+IA0KCQk+ID4gDQoJCT4gPlJlZ2FyZGxlc3Mgb2Ygd2hhdCB0aGUgYWN0dWFsIHByb2JhYmls aXRpZXMgYXJlLCB0aGUgcHJvYmFiaWxpdHkgDQoJCT4gPm9mIGEgc3VjY2Vzc2Z1bCBWUE4gcGFj a2V0IHNwb29mIGF0dGFjayB3aWxsIGFsd2F5cyBncmVhdGVyIHRoYW4gDQoJCT4gPmFuIElQIG9u bHkgbmV0d29yay4gVGhpcyBpcyBiZWNhdXNlIHBhY2tldHMgY2FuIGJlIGZvcndhcmRlZCANCgkJ PiA+dXNpbmcgSVAgZGVzdGluYXRpb24gYWRkcmVzc2VzIE9SIE1QTFMgbGFiZWxzLiANCgkJPiA+ IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+My4gVmlhIGFuIGlsbGVnYWwgYXR0YWNrIGZyb20gYW4g aW50cnVkZXIgdGhhdCBoYXMgdGFwcGVkIGludG8gYSANCgkJPiA+cGh5c2ljYWwgbGluayB3aXRo aW4gdGhlIHByb3ZpZGVyIG5ldHdvcmsgDQoJCT4gPiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPmkp IElmIGFuIGludHJ1ZGVyIGhhcyB0YXBwZWQgaW50byBhIHBoeXNpY2FsIGxpbmsgdGhlbiBpdCBp cyANCgkJPiA+bGlrZWx5IHRoYXQgdGhleSBhcmUgYWJsZSB0byBzbm9vcCBNUExTL0lQIHBhY2tl dHMgdG8gZGV0ZXJtaW5lIA0KCQk+ID53aGF0IGxhYmVscyBvciBJUCBhZGRyZXNzZXMgYXJlIGJl aW5nIHVzZWQuIElmIHNvLCB0aGVuIHRoZSANCgkJPiA+aW50cnVkZXIgY2FuIHVzZSB0aGlzIGlu Zm9ybWF0aW9uIHRvIGNhcnJ5IG91dCBhIFZQTiBwYWNrZXQgDQoJCT4gPnNwb29maW5nIGF0dGFj ay4gVGhpcyBpcyBpbmRlcGVuZGVudCBvZiB3aGF0ZXZlciBlbmNhcHN1bGF0aW9uIA0KCQk+ID5p cyB1c2VkIGFjcm9zcyB0aGUgUFNOLiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+aWkp IElmIGFuIGludHJ1ZGVyIGhhcyBnYWluZWQgYWNjZXNzIHRvIGEgcGh5c2ljYWwgbGluayBhbmQg Zm9yIA0KCQk+ID53aGF0ZXZlciByZWFzb24gY2FuIG9ubHkgdHJhbnNtaXQgcGFja2V0cywgdGhl biBicnV0ZSBmb3JjZSANCgkJPiA+dGVjaG5pcXVlcyBtdXN0IGJlIGFwcGxpZWQgYXMgZGVzY3Jp YmVkIGluIDIgaWkpLiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+SW4gYm90aCAyIGFu ZCAzLCB0aGUgb25seSB3YXkgdG8gcHJvdGVjdCBhZ2FpbnN0IHRoaXMgdHlwZSBvZiANCgkJPiA+ YXR0YWNrIGlzIHRvIHVzZSBlbnN1cmUgcGh5c2ljYWwgbmV0d29yayBwcm90ZWN0aW9uIGFuZCB0 byB1c2UgDQoJCT4gPmVuY3J5cHRpb24vYXV0aGVudGljYXRpb24uIFRoZSBwb2ludCBiZWluZyB0 aGF0IHRvIHByb3RlY3QgDQoJCT4gPmFnYWluc3QgdGhlc2UgdHlwZXMgb2YgYXR0YWNrLCB0aGVz ZSBzZWN1cml0eSBtZWFzdXJlcyBtdXN0IGJlIA0KCQk+ID50YWtlbiByZWdhcmRsZXNzIG9mIHdo ZXRoZXIgdGhlIFBTTiBpcyBJUCBvciBJUC9NUExTLiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPiAN CgkJPiA+QXMgSSBzYXksIGFkbWl0dGVkbHkgSSdtIG5vdCBhIHNlY3VyaXR5IGV4cGVydCBzbyBJ IHdlbGNvbWUgYW55IA0KCQk+ID5jb21tZW50cyB0aGF0IGV4cGxhaW4gd2h5IG15IGFyZ3VtZW50 cyBhcmUgaW5jb3JyZWN0LiANCgkJPiA+IA0KCQk+ID4gDQoJCT4gPiANCgkJPiA+UmljaGFyZCAN CgkJPiA+DQoNCgktLSANCglSYWplc2ggUG90dGkuDQoJICANCg0K From exim@www1.ietf.org Tue Feb 10 05:35:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10666 for ; Tue, 10 Feb 2004 05:35:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVEA-0007m7-W7 for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 05:34:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AAYoDi029886 for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 05:34:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVEA-0007lx-Eg for l3vpn-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 05:34:50 -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 FAA10660 for ; Tue, 10 Feb 2004 05:34:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqVE7-0006E3-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 05:34:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqVDA-00068u-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 05:33:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqVCP-00063Y-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 05:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVCP-0007eW-Mt; Tue, 10 Feb 2004 05:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVCG-0007eG-AN for l3vpn@optimus.ietf.org; Tue, 10 Feb 2004 05:32:52 -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 FAA10618 for ; Tue, 10 Feb 2004 05:32:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqVCC-00062g-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 05:32:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqVBM-0005xf-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 05:31:57 -0500 Received: from door.sniff.de ([82.212.219.2]) by ietf-mx with esmtp (Exim 4.12) id 1AqVAr-0005rV-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 05:31:25 -0500 Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 2B9872AA0B; Tue, 10 Feb 2004 10:32:36 +0000 (GMT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: , From: Marc Binderberger Subject: Re: MPLS vs IP encap in RFC2547 Date: Tue, 10 Feb 2004 11:35:41 +0100 To: richard.spencer@bt.com X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Richard, maybe I'm missing something but from what you say I can't see the "spoof probability is higher for MPLS than for IP encapsulation". Looks more like a "not much difference" for me. The overall complexity of the MPLS control plane is larger than for native IP due to additional protocols like LDP and RSVP. The challenge to protect these protocols is similar to a native IP network and the protection mechanism are identical, e.g. MD5 hashing, infrastructure ACL and so on. With more protocols in place it is probably easier to disturb the MPLS service. On the forwarding plane I would rate MPLS as safer than IP encapsulation. In an ideal world it should be the same but the situation is more complex for IP-encapsulation. VPN ports (unless for CsC) and "Internet" ports are native IP ports and a router can simply drop labeled packets. And for CsC customers only advertised labels (in the particular VRF context) are accepted. One may compare this to uRPF for IP - but this feature is not always available or the performance makes it impractical to use. As a result address spoofing is likely to be possible - and any scheme like GRE is at risk. Stated less technically: for VPNs based on IP encapsulation the customer is closer to the VPN implementation as s/he talks IP too. It's mainly the global Internet ports causing the problem. There is one scenario in the MPLS world which is similar: InterAS "type b" and "type c" interconnects where a port in global routing accepts labeled traffic. I disagree with your statement that in an IP/MPLS network both option are available, forwarding based on IP and on MPLS and thus the overall risk is the sum of both. To spoof into a MPLS VPN from the forwarding plane you need labeled traffic - try to send some data to 10.1.2.3 while on a core router ;-) Regards, Marc On Feb 9, 2004, at 7:48 PM, richard.spencer@bt.com wrote: > It has been asserted on this mailing list and in a couple of IETF > drafts, that using IP encapsulation techniques across a PSN instead of > MPLS for RFC2547 make it more difficult to protect VPNs against > spoofed attacks. > > > > I would like to challenge this assertion, as I believe that using IP > encapsulation in the PSN instead of MPLS actually makes it easier to > protect against spoofed VPN attacks. I am not a security expert so I > welcome any comments that explain where my argument falls down. > > > > My argument is based on the fact that that MPLS networks can forward > VPN packets based on IP or MPLS (PHP is a good example of this), and > hence 'IP/MPLS' networks inherit the security risks associated with > both IP and MPLS forwarding. > > > > Fundamentally, this argument comes back to the fact that IP/MPLS > networks today use the same address space for control plane traffic > that they use for forwarding VPN packets in the data plane, i.e. /32 > loopback addresses that are used for LDP/BGP sessions are also used as > PE next hops for VPN packets. As stated previously, one solution to > the problem is to use filtering; another is to use an OOB control > plane. > > > > If an attacker is able to initiate an attack from within the service > provider network then the security risks associated with IP/MPLS > networks are comparable to other VPN technologies such as ATM/FR. If > however an attacker attempts to initiate an attack from outside the > provider network, then the security risks in an IP/MPLS network are > dependant on which routing instance the interface connects to, i.e. a > customer VRF or the global routing table. > > > > To provide justification for this argument, I will examine 3 points of > entry into the network where a spoofing attempt might take place. > > > > 1. Via a legitimate non-core facing managed interface at the edge of > the provider network. > > > > a) If the interface belongs to a VPN, then the VRF it belongs to will > only contain routes belonging to that particular VPN. This would most > likely be a customer-facing interface. > > > > If a packet is received with an address/label that belongs to a > different VPN or to the provider network, then the packet will be > dropped because a route to the destination will not exist (i.e. route > isolation is enforced). This is independent of whatever encapsulation > method (IP/GRE, MPLS) is used within the PSN. > > > > b) If the interface belongs to the service provider global routing > table, then the routing table will contain IGP routes, and may contain > Internet routes. This would most likely be an interface facing the > Internet or another AS/provider to support inter-AS/provider VPNs. > > > > In order to protect against IP packet spoofing, ingress filtering must > be applied on the interface. This is independent of whatever > encapsulation method is used within the PSN. This is a key point, a > network running MPLS in the core can still forward packets based on IP > addresses it receives at the edge (assuming IP is running on > interfaces at the edge). > > > > If MPLS labelled packets are received on an interface but MPLS is not > enabled, then they should be dropped. This is independent of whatever > encapsulation is used across the PSN. > > > > If the PSN is using MPLS in the core, and MPLS is enabled on the > interface then filtering needs be used to drop spoofed MPLS packets. > This is in addition to the filtering required to protect against > spoofed IP packets. > > > > 2. Via an illegal attack from a router interface within the provider > network by an intruder > > > > i) If an intruder has gained access to a router interface within the > provider network (edge or core), the intruder may also be able to > lookup routing/label information. If so, then the intruder can use > this information to carry out a VPN packet spoofing attack. This is > independent of whatever encapsulation is used across the PSN. > > > > ii) If an intruder gains access to a router interface within the > provider network but cannot acquire routing/label information, then > brute force techniques must be used to spoof packets. In order to > spoof a VPN packet, an attacker must determine the correct PSN > label/IP destination addresses AND the correct VPN label. If the PSN > label/address is not valid, the first PE/P router that receives the > packet will drop it. If the PSN label/address is correct but the VPN > label is incorrect, then the packet will be dropped by the egress PE. > > > > If the PSN supports IP only, then the probability of spoofing success > is based on: > > > > P(PSN destination IP address) x P(VPN label) > > > > If the PSN supports IP/MPLS forwarding then the probability is based > on: > > > > P(PSN destination IP address) x P(VPN label) OR > > P(PSN label) x P(VPN label) > > > > Regardless of what the actual probabilities are, the probability of a > successful VPN packet spoof attack will always greater than an IP only > network. This is because packets can be forwarded using IP destination > addresses OR MPLS labels. > > > > 3. Via an illegal attack from an intruder that has tapped into a > physical link within the provider network > > > > i) If an intruder has tapped into a physical link then it is likely > that they are able to snoop MPLS/IP packets to determine what labels > or IP addresses are being used. If so, then the intruder can use this > information to carry out a VPN packet spoofing attack. This is > independent of whatever encapsulation is used across the PSN. > > > > ii) If an intruder has gained access to a physical link and for > whatever reason can only transmit packets, then brute force techniques > must be applied as described in 2 ii). > > > > In both 2 and 3, the only way to protect against this type of attack > is to use ensure physical network protection and to use > encryption/authentication. The point being that to protect against > these types of attack, these security measures must be taken > regardless of whether the PSN is IP or IP/MPLS. > > > > As I say, admittedly I'm not a security expert so I welcome any > comments that explain why my arguments are incorrect. > > > > Richard > > -- Marc Binderberger Powered by *BSD ;-) From exim@www1.ietf.org Tue Feb 10 06:08:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11715 for ; Tue, 10 Feb 2004 06:08:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVk4-0001Ht-Kw for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 06:07:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AB7mht004948 for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 06:07:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVk4-0001Hd-0V for l3vpn-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 06:07:48 -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 GAA11706 for ; Tue, 10 Feb 2004 06:07:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqVk0-0001UK-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 06:07:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqVj5-0001Pt-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 06:06:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqViP-0001LN-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 06:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqViM-00010T-Rz; Tue, 10 Feb 2004 06:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqVi8-0000zu-Ho for l3vpn@optimus.ietf.org; Tue, 10 Feb 2004 06:05:48 -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 GAA11671 for ; Tue, 10 Feb 2004 06:05:44 -0500 (EST) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqVi4-0001Kr-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 06:05:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqVhA-0001GR-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 06:04:49 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139] helo=i2kc05-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AqVgk-0001BR-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 06:04:22 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 11:03:53 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 11:03:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: MPLS vs IP encap in RFC2547 Date: Tue, 10 Feb 2004 11:03:51 -0000 Message-ID: Thread-Topic: MPLS over L2TPv3 encap for RFC 2547 VPNs Thread-Index: AcPr5v4OXGBiOWTFRKiSEfTAKqcFOwDTu0PZACMJhHk= To: , X-OriginalArrivalTime: 10 Feb 2004 11:03:52.0802 (UTC) FILETIME=[91AB3C20:01C3EFC5] Content-Transfer-Encoding: base64 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: , List-Id: List-Post: List-Help: List-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.8 required=5.0 tests=AWL,BLANK_LINES_70_80, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGF2aW5nIHRob3VnaHQgYWJvdXQgaXQgZnVydGhlciwgSSBoYXZlIGRpc2NvdmVyZWQgYSBmbGF3 IGluIG15IGFyZ3VtZW50LiBGb3IgYW4gZWdyZXNzIFBFIHRvIGNvcnJlY3RseSBwcm9jZXNzIGEg VlBOIHBhY2tldCByZWNlaXZlZCB2aWEgSVAgb3IgSVAvR1JFIGVuY2Fwc3VsYXRpb24gYWNyb3Nz IGFuIElQL01QTFMgUFNOLCB0aGUgZW5jYXBzdWxhdGlvbiBtZXRob2QgbXVzdCBpZGVudGlmeSB0 aGUgcGF5bG9hZCBhcyBiZWluZyBhbiBNUExTIHBhY2tldC4gSW4gdGhlIElQIGVuY2Fwc3VsYXRp b24gY2FzZSB0aGlzIGlzIGRvbmUgdXNpbmcgYSBwcm90b2NvbCBudW1iZXIgZmllbGQgKFRCQSku IEluIHRoZSBJUC9HUkUgY2FzZSwgdGhlIElQIHByb3RvY29sIGZpZWxkIGlzIHVzZWQgdG8gaW5k aWNhdGUgdGhhdCB0aGUgSVAgcGFja2V0IGNvbnRhaW5zIGEgR1JFIHBhY2tldCwgYW5kIHRoZSBw cm90b2NvbCB0eXBlIGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyIGlzIHVzZWQgdG8gaW5kaWNhdGUg dGhhdCB0aGUgcGFja2V0IGlzIGFuIE1QTFMgcGFja2V0LiANCg0KIA0KDQpUaGUgYWJvdmUgYXNz dW1lcyB0aGF0IHRoZSBzcG9vZmVkIFZQTiBwYWNrZXQgaXMgc2VudCB2aWEgYW4gaW50ZXJmYWNl IGRpcmVjdGx5IGNvbm5lY3RlZCB0byB0aGUgUEUuIFRoZSByZWFzb24gYmVpbmcgdGhhdCBpZiB0 aGUgUFNOIGlzIHJ1bm5pbmcgTVBMUywgdGhlbiBieSBkZWZhdWx0IGlmIGEgUCByb3V0ZXIgcmVj ZWl2ZXMgYSBwYWNrZXQgd2l0aCBhbiBJUCBkZXN0aW5hdGlvbiBhZGRyZXNzIGl0IGhhcyBhIEZF QyBmb3IgdGhlbiBpdCB3aWxsIGZvcndhcmQgdGhlIHBhY2tldCB1c2luZyBhbiBNUExTIGxhYmVs LiBUbyBwcm90ZWN0IGFuIElQL01QTFMgbmV0d29yayBmcm9tIFZQTiBzcG9vZmluZyB1c2luZyBJ UCBpbnN0ZWFkIG9mIE1QTFMsIHRoZW4gdGhlIHByb3ZpZGVyIGNvdWxkIHNpbXBseSBmaWx0ZXIg b3V0IGFuZCBkcm9wIGFueSBwYWNrZXRzIHRoYXQgY29udGFpbiBNUExTLWluLUlQIG9yIEdSRSBl bmNhcHN1bGF0ZWQgcGFja2V0cyBiYXNlZCBvbiB0aGUgSVAgcHJvdG9jb2wgbnVtYmVyLg0KDQog DQoNClVzaW5nIGJydXRlIGZvcmNlIGFuIGF0dGFja2VyIGNvdWxkIHBvdGVudGlhbGx5IGluamVj dCBzcG9vZmVkIFZQTiBwYWNrZXRzIHVzaW5nIElQIGVuY2Fwc3VsYXRpb24gd2l0aCB0aGUgcHJv dG9jb2wgbnVtYmVyIHNldCB0byBhIG51bWJlciBmb3IgYSB2YWxpZCBwcm90b2NvbCB0eXBlIHRv IGJlIHJlY2VpdmVkIG92ZXIgdGhhdCBpbnRlcmZhY2UgKGUuZy4gU05NUCkuIEluIHdoaWNoIGNh c2UsIHRoZSBJUCBoZWFkZXIgd291bGQgYmUgcmVwbGFjZWQgd2l0aCBhIGxhYmVsIGFuZCB0aGUg cGFja2V0IHdvdWxkIGJlIHN3aXRjaGVkIGFjcm9zcyB0aGUgTFNQIHRvIHRoZSBkZXN0aW5hdGlv biBQRS4gSG93ZXZlciwgd2hlbiBQSFAgcG9wcyB0aGUgbGFiZWwgZnJvbSB0aGUgc3RhY2ssIGJl Y2F1c2UgdGhlIHJvdXRlciB0aGF0IHJlY2VpdmVkIHRoZSBvcmlnaW5hbCBJUCBlbmNhcHN1bGF0 ZWQgcGFja2V0IHdpbGwgaGF2ZSBpbXBvc2VkIGEgbGFiZWwgd2l0aCB0aGUgYm90dG9tIG9mIHRo ZSBzdGFjayBiaXQgc2V0LCB0aGUgcmVtYWluaW5nIHBhY2tldCB3aWxsIGJlIGZvcndhcmRlZCBh cyBhbiBJUCBwYWNrZXQuIFdoZW4gdGhlIGVncmVzcyBQRSByZWNlaXZlcyB0aGUgcGFja2V0IGl0 IHdpbGwgYmUgZXhwZWN0aW5nIGFuIElQIHBhY2tldCAoZHVlIHRvIHRoZSBMMiBwcm90b2NvbCBJ RCksIGFuZCB3aWxsIGRyb3AgaXQgYmVjYXVzZSBpdCB3aWxsIGFjdHVhbGx5IHJlY2VpdmUgYW4g TVBMUyBwYWNrZXQsIG5vdCBhbiBJUCBwYWNrZXQuDQoNCiANCg0KVGhlIG9wdGlvbiB0byBmaWx0 ZXIgb3V0IHBvdGVudGlhbCBzcG9vZmVkIFZQTiBwYWNrZXRzIHVzaW5nIHRoZSBJUCBwcm90b2Nv bCBudW1iZXIgZmllbGQgbWFrZXMgaXQgZWFzaWVyIHRvIHByb3RlY3QgYW4gSVAvTVBMUyBSRkMy NTQ3IG5ldHdvcmsgYWdhaW5zdCBhdHRhY2sgZnJvbSBzcG9vZmVkIFZQTiBJUCBlbmNhcHN1bGF0 ZWQgcGFja2V0cy4gVGhpcyBpcyBub3QgYW4gb3B0aW9uIGluIGFuIElQIG9ubHkgUkZDMjU0NyBu ZXR3b3JrIGFzIElQIGVuY2Fwc3VsYXRlZCBwYWNrZXRzIG11c3QgYmUgZm9yd2FyZGVkLg0KDQog DQoNClJlZ2FyZHMsDQoNCiANCg0KUmljaGFyZA0KDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIA0KRnJvbTogbDN2cG4tYWRtaW5AaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJpY2hhcmQu c3BlbmNlckBidC5jb20gDQpTZW50OiBNb24gMDkvMDIvMjAwNCAxMzo0OCANClRvOiBsM3ZwbkBp ZXRmLm9yZzsgbXBsc0BVVS5ORVQgDQpDYzogDQpTdWJqZWN0OiBNUExTIHZzIElQIGVuY2FwIGlu IFJGQzI1NDcNCg0KDQoNCglJdCBoYXMgYmVlbiBhc3NlcnRlZCBvbiB0aGlzIG1haWxpbmcgbGlz dCBhbmQgaW4gYSBjb3VwbGUgb2YgSUVURiBkcmFmdHMsIHRoYXQgdXNpbmcgSVAgZW5jYXBzdWxh dGlvbiB0ZWNobmlxdWVzIGFjcm9zcyBhIFBTTiBpbnN0ZWFkIG9mIE1QTFMgZm9yIFJGQzI1NDcg bWFrZSBpdCBtb3JlIGRpZmZpY3VsdCB0byBwcm90ZWN0IFZQTnMgYWdhaW5zdCBzcG9vZmVkIGF0 dGFja3MuDQoJDQoJDQoJDQoJSSB3b3VsZCBsaWtlIHRvIGNoYWxsZW5nZSB0aGlzIGFzc2VydGlv biwgYXMgSSBiZWxpZXZlIHRoYXQgdXNpbmcgSVAgZW5jYXBzdWxhdGlvbiBpbiB0aGUgUFNOIGlu c3RlYWQgb2YgTVBMUyBhY3R1YWxseSBtYWtlcyBpdCBlYXNpZXIgdG8gcHJvdGVjdCBhZ2FpbnN0 IHNwb29mZWQgVlBOIGF0dGFja3MuIEkgYW0gbm90IGEgc2VjdXJpdHkgZXhwZXJ0IHNvIEkgd2Vs Y29tZSBhbnkgY29tbWVudHMgdGhhdCBleHBsYWluIHdoZXJlIG15IGFyZ3VtZW50IGZhbGxzIGRv d24uDQoJDQoJDQoJDQoJTXkgYXJndW1lbnQgaXMgYmFzZWQgb24gdGhlIGZhY3QgdGhhdCB0aGF0 IE1QTFMgbmV0d29ya3MgY2FuIGZvcndhcmQgVlBOIHBhY2tldHMgYmFzZWQgb24gSVAgb3IgTVBM UyAoUEhQIGlzIGEgZ29vZCBleGFtcGxlIG9mIHRoaXMpLCBhbmQgaGVuY2UgJ0lQL01QTFMnIG5l dHdvcmtzIGluaGVyaXQgdGhlIHNlY3VyaXR5IHJpc2tzIGFzc29jaWF0ZWQgd2l0aCBib3RoIElQ IGFuZCBNUExTIGZvcndhcmRpbmcuDQoJDQoJDQoJDQoJRnVuZGFtZW50YWxseSwgdGhpcyBhcmd1 bWVudCBjb21lcyBiYWNrIHRvIHRoZSBmYWN0IHRoYXQgSVAvTVBMUyBuZXR3b3JrcyB0b2RheSB1 c2UgdGhlIHNhbWUgYWRkcmVzcyBzcGFjZSBmb3IgY29udHJvbCBwbGFuZSB0cmFmZmljIHRoYXQg dGhleSB1c2UgZm9yIGZvcndhcmRpbmcgVlBOIHBhY2tldHMgaW4gdGhlIGRhdGEgcGxhbmUsIGku ZS4gLzMyIGxvb3BiYWNrIGFkZHJlc3NlcyB0aGF0IGFyZSB1c2VkIGZvciBMRFAvQkdQIHNlc3Np b25zIGFyZSBhbHNvIHVzZWQgYXMgUEUgbmV4dCBob3BzIGZvciBWUE4gcGFja2V0cy4gQXMgc3Rh dGVkIHByZXZpb3VzbHksIG9uZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbSBpcyB0byB1c2UgZmls dGVyaW5nOyBhbm90aGVyIGlzIHRvIHVzZSBhbiBPT0IgY29udHJvbCBwbGFuZS4NCgkNCgkNCgkN CglJZiBhbiBhdHRhY2tlciBpcyBhYmxlIHRvIGluaXRpYXRlIGFuIGF0dGFjayBmcm9tIHdpdGhp biB0aGUgc2VydmljZSBwcm92aWRlciBuZXR3b3JrIHRoZW4gdGhlIHNlY3VyaXR5IHJpc2tzIGFz c29jaWF0ZWQgd2l0aCBJUC9NUExTIG5ldHdvcmtzIGFyZSBjb21wYXJhYmxlIHRvIG90aGVyIFZQ TiB0ZWNobm9sb2dpZXMgc3VjaCBhcyBBVE0vRlIuIElmIGhvd2V2ZXIgYW4gYXR0YWNrZXIgYXR0 ZW1wdHMgdG8gaW5pdGlhdGUgYW4gYXR0YWNrIGZyb20gb3V0c2lkZSB0aGUgcHJvdmlkZXIgbmV0 d29yaywgdGhlbiB0aGUgc2VjdXJpdHkgcmlza3MgaW4gYW4gSVAvTVBMUyBuZXR3b3JrIGFyZSBk ZXBlbmRhbnQgb24gd2hpY2ggcm91dGluZyBpbnN0YW5jZSB0aGUgaW50ZXJmYWNlIGNvbm5lY3Rz IHRvLCBpLmUuIGEgY3VzdG9tZXIgVlJGIG9yIHRoZSBnbG9iYWwgcm91dGluZyB0YWJsZS4NCgkN CgkNCgkNCglUbyBwcm92aWRlIGp1c3RpZmljYXRpb24gZm9yIHRoaXMgYXJndW1lbnQsIEkgd2ls bCBleGFtaW5lIDMgcG9pbnRzIG9mIGVudHJ5IGludG8gdGhlIG5ldHdvcmsgd2hlcmUgYSBzcG9v ZmluZyBhdHRlbXB0IG1pZ2h0IHRha2UgcGxhY2UuDQoJDQoJDQoJDQoJMS4gVmlhIGEgbGVnaXRp bWF0ZSBub24tY29yZSBmYWNpbmcgbWFuYWdlZCBpbnRlcmZhY2UgYXQgdGhlIGVkZ2Ugb2YgdGhl IHByb3ZpZGVyIG5ldHdvcmsuDQoJDQoJDQoJDQoJYSkgSWYgdGhlIGludGVyZmFjZSBiZWxvbmdz IHRvIGEgVlBOLCB0aGVuIHRoZSBWUkYgaXQgYmVsb25ncyB0byB3aWxsIG9ubHkgY29udGFpbiBy b3V0ZXMgYmVsb25naW5nIHRvIHRoYXQgcGFydGljdWxhciBWUE4uIFRoaXMgd291bGQgbW9zdCBs aWtlbHkgYmUgYSBjdXN0b21lci1mYWNpbmcgaW50ZXJmYWNlLg0KCQ0KCQ0KCQ0KCUlmIGEgcGFj a2V0IGlzIHJlY2VpdmVkIHdpdGggYW4gYWRkcmVzcy9sYWJlbCB0aGF0IGJlbG9uZ3MgdG8gYSBk aWZmZXJlbnQgVlBOIG9yIHRvIHRoZSBwcm92aWRlciBuZXR3b3JrLCB0aGVuIHRoZSBwYWNrZXQg d2lsbCBiZSBkcm9wcGVkIGJlY2F1c2UgYSByb3V0ZSB0byB0aGUgZGVzdGluYXRpb24gd2lsbCBu b3QgZXhpc3QgKGkuZS4gcm91dGUgaXNvbGF0aW9uIGlzIGVuZm9yY2VkKS4gVGhpcyBpcyBpbmRl cGVuZGVudCBvZiB3aGF0ZXZlciBlbmNhcHN1bGF0aW9uIG1ldGhvZCAoSVAvR1JFLCBNUExTKSBp cyB1c2VkIHdpdGhpbiB0aGUgUFNOLg0KCQ0KCQ0KCQ0KCWIpIElmIHRoZSBpbnRlcmZhY2UgYmVs b25ncyB0byB0aGUgc2VydmljZSBwcm92aWRlciBnbG9iYWwgcm91dGluZyB0YWJsZSwgdGhlbiB0 aGUgcm91dGluZyB0YWJsZSB3aWxsIGNvbnRhaW4gSUdQIHJvdXRlcywgYW5kIG1heSBjb250YWlu IEludGVybmV0IHJvdXRlcy4gVGhpcyB3b3VsZCBtb3N0IGxpa2VseSBiZSBhbiBpbnRlcmZhY2Ug ZmFjaW5nIHRoZSBJbnRlcm5ldCBvciBhbm90aGVyIEFTL3Byb3ZpZGVyIHRvIHN1cHBvcnQgaW50 ZXItQVMvcHJvdmlkZXIgVlBOcy4NCgkNCgkNCgkNCglJbiBvcmRlciB0byBwcm90ZWN0IGFnYWlu c3QgSVAgcGFja2V0IHNwb29maW5nLCBpbmdyZXNzIGZpbHRlcmluZyBtdXN0IGJlIGFwcGxpZWQg b24gdGhlIGludGVyZmFjZS4gVGhpcyBpcyBpbmRlcGVuZGVudCBvZiB3aGF0ZXZlciBlbmNhcHN1 bGF0aW9uIG1ldGhvZCBpcyB1c2VkIHdpdGhpbiB0aGUgUFNOLiBUaGlzIGlzIGEga2V5IHBvaW50 LCBhIG5ldHdvcmsgcnVubmluZyBNUExTIGluIHRoZSBjb3JlIGNhbiBzdGlsbCBmb3J3YXJkIHBh Y2tldHMgYmFzZWQgb24gSVAgYWRkcmVzc2VzIGl0IHJlY2VpdmVzIGF0IHRoZSBlZGdlIChhc3N1 bWluZyBJUCBpcyBydW5uaW5nIG9uIGludGVyZmFjZXMgYXQgdGhlIGVkZ2UpLg0KCQ0KCQ0KCQ0K CUlmIE1QTFMgbGFiZWxsZWQgcGFja2V0cyBhcmUgcmVjZWl2ZWQgb24gYW4gaW50ZXJmYWNlIGJ1 dCBNUExTIGlzIG5vdCBlbmFibGVkLCB0aGVuIHRoZXkgc2hvdWxkIGJlIGRyb3BwZWQuIFRoaXMg aXMgaW5kZXBlbmRlbnQgb2Ygd2hhdGV2ZXIgZW5jYXBzdWxhdGlvbiBpcyB1c2VkIGFjcm9zcyB0 aGUgUFNOLg0KCQ0KCQ0KCQ0KCUlmIHRoZSBQU04gaXMgdXNpbmcgTVBMUyBpbiB0aGUgY29yZSwg YW5kIE1QTFMgaXMgZW5hYmxlZCBvbiB0aGUgaW50ZXJmYWNlIHRoZW4gZmlsdGVyaW5nIG5lZWRz IGJlIHVzZWQgdG8gZHJvcCBzcG9vZmVkIE1QTFMgcGFja2V0cy4gVGhpcyBpcyBpbiBhZGRpdGlv biB0byB0aGUgZmlsdGVyaW5nIHJlcXVpcmVkIHRvIHByb3RlY3QgYWdhaW5zdCBzcG9vZmVkIElQ IHBhY2tldHMuDQoJDQoJDQoJDQoJMi4gVmlhIGFuIGlsbGVnYWwgYXR0YWNrIGZyb20gYSByb3V0 ZXIgaW50ZXJmYWNlIHdpdGhpbiB0aGUgcHJvdmlkZXIgbmV0d29yayBieSBhbiBpbnRydWRlcg0K CQ0KCQ0KCQ0KCWkpIElmIGFuIGludHJ1ZGVyIGhhcyBnYWluZWQgYWNjZXNzIHRvIGEgcm91dGVy IGludGVyZmFjZSB3aXRoaW4gdGhlIHByb3ZpZGVyIG5ldHdvcmsgKGVkZ2Ugb3IgY29yZSksIHRo ZSBpbnRydWRlciBtYXkgYWxzbyBiZSBhYmxlIHRvIGxvb2t1cCByb3V0aW5nL2xhYmVsIGluZm9y bWF0aW9uLiBJZiBzbywgdGhlbiB0aGUgaW50cnVkZXIgY2FuIHVzZSB0aGlzIGluZm9ybWF0aW9u IHRvIGNhcnJ5IG91dCBhIFZQTiBwYWNrZXQgc3Bvb2ZpbmcgYXR0YWNrLiBUaGlzIGlzIGluZGVw ZW5kZW50IG9mIHdoYXRldmVyIGVuY2Fwc3VsYXRpb24gaXMgdXNlZCBhY3Jvc3MgdGhlIFBTTi4N CgkNCgkNCgkNCglpaSkgSWYgYW4gaW50cnVkZXIgZ2FpbnMgYWNjZXNzIHRvIGEgcm91dGVyIGlu dGVyZmFjZSB3aXRoaW4gdGhlIHByb3ZpZGVyIG5ldHdvcmsgYnV0IGNhbm5vdCBhY3F1aXJlIHJv dXRpbmcvbGFiZWwgaW5mb3JtYXRpb24sIHRoZW4gYnJ1dGUgZm9yY2UgdGVjaG5pcXVlcyBtdXN0 IGJlIHVzZWQgdG8gc3Bvb2YgcGFja2V0cy4gSW4gb3JkZXIgdG8gc3Bvb2YgYSBWUE4gcGFja2V0 LCBhbiBhdHRhY2tlciBtdXN0IGRldGVybWluZSB0aGUgY29ycmVjdCBQU04gbGFiZWwvSVAgZGVz dGluYXRpb24gYWRkcmVzc2VzIEFORCB0aGUgY29ycmVjdCBWUE4gbGFiZWwuIElmIHRoZSBQU04g bGFiZWwvYWRkcmVzcyBpcyBub3QgdmFsaWQsIHRoZSBmaXJzdCBQRS9QIHJvdXRlciB0aGF0IHJl Y2VpdmVzIHRoZSBwYWNrZXQgd2lsbCBkcm9wIGl0LiBJZiB0aGUgUFNOIGxhYmVsL2FkZHJlc3Mg aXMgY29ycmVjdCBidXQgdGhlIFZQTiBsYWJlbCBpcyBpbmNvcnJlY3QsIHRoZW4gdGhlIHBhY2tl dCB3aWxsIGJlIGRyb3BwZWQgYnkgdGhlIGVncmVzcyBQRS4NCgkNCgkNCgkNCglJZiB0aGUgUFNO IHN1cHBvcnRzIElQIG9ubHksIHRoZW4gdGhlIHByb2JhYmlsaXR5IG9mIHNwb29maW5nIHN1Y2Nl c3MgaXMgYmFzZWQgb246DQoJDQoJDQoJDQoJUChQU04gZGVzdGluYXRpb24gSVAgYWRkcmVzcykg eCBQKFZQTiBsYWJlbCkNCgkNCgkNCgkNCglJZiB0aGUgUFNOIHN1cHBvcnRzIElQL01QTFMgZm9y d2FyZGluZyB0aGVuIHRoZSBwcm9iYWJpbGl0eSBpcyBiYXNlZCBvbjoNCgkNCgkNCgkNCglQKFBT TiBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzKSB4IFAoVlBOIGxhYmVsKSBPUg0KCQ0KCVAoUFNOIGxh YmVsKSB4IFAoVlBOIGxhYmVsKQ0KCQ0KCQ0KCQ0KCVJlZ2FyZGxlc3Mgb2Ygd2hhdCB0aGUgYWN0 dWFsIHByb2JhYmlsaXRpZXMgYXJlLCB0aGUgcHJvYmFiaWxpdHkgb2YgYSBzdWNjZXNzZnVsIFZQ TiBwYWNrZXQgc3Bvb2YgYXR0YWNrIHdpbGwgYWx3YXlzIGdyZWF0ZXIgdGhhbiBhbiBJUCBvbmx5 IG5ldHdvcmsuIFRoaXMgaXMgYmVjYXVzZSBwYWNrZXRzIGNhbiBiZSBmb3J3YXJkZWQgdXNpbmcg SVAgZGVzdGluYXRpb24gYWRkcmVzc2VzIE9SIE1QTFMgbGFiZWxzLg0KCQ0KCQ0KCQ0KCTMuIFZp YSBhbiBpbGxlZ2FsIGF0dGFjayBmcm9tIGFuIGludHJ1ZGVyIHRoYXQgaGFzIHRhcHBlZCBpbnRv IGEgcGh5c2ljYWwgbGluayB3aXRoaW4gdGhlIHByb3ZpZGVyIG5ldHdvcmsNCgkNCgkNCgkNCglp KSBJZiBhbiBpbnRydWRlciBoYXMgdGFwcGVkIGludG8gYSBwaHlzaWNhbCBsaW5rIHRoZW4gaXQg aXMgbGlrZWx5IHRoYXQgdGhleSBhcmUgYWJsZSB0byBzbm9vcCBNUExTL0lQIHBhY2tldHMgdG8g ZGV0ZXJtaW5lIHdoYXQgbGFiZWxzIG9yIElQIGFkZHJlc3NlcyBhcmUgYmVpbmcgdXNlZC4gSWYg c28sIHRoZW4gdGhlIGludHJ1ZGVyIGNhbiB1c2UgdGhpcyBpbmZvcm1hdGlvbiB0byBjYXJyeSBv dXQgYSBWUE4gcGFja2V0IHNwb29maW5nIGF0dGFjay4gVGhpcyBpcyBpbmRlcGVuZGVudCBvZiB3 aGF0ZXZlciBlbmNhcHN1bGF0aW9uIGlzIHVzZWQgYWNyb3NzIHRoZSBQU04uDQoJDQoJDQoJDQoJ aWkpIElmIGFuIGludHJ1ZGVyIGhhcyBnYWluZWQgYWNjZXNzIHRvIGEgcGh5c2ljYWwgbGluayBh bmQgZm9yIHdoYXRldmVyIHJlYXNvbiBjYW4gb25seSB0cmFuc21pdCBwYWNrZXRzLCB0aGVuIGJy dXRlIGZvcmNlIHRlY2huaXF1ZXMgbXVzdCBiZSBhcHBsaWVkIGFzIGRlc2NyaWJlZCBpbiAyIGlp KS4NCgkNCgkNCgkNCglJbiBib3RoIDIgYW5kIDMsIHRoZSBvbmx5IHdheSB0byBwcm90ZWN0IGFn YWluc3QgdGhpcyB0eXBlIG9mIGF0dGFjayBpcyB0byB1c2UgZW5zdXJlIHBoeXNpY2FsIG5ldHdv cmsgcHJvdGVjdGlvbiBhbmQgdG8gdXNlIGVuY3J5cHRpb24vYXV0aGVudGljYXRpb24uIFRoZSBw b2ludCBiZWluZyB0aGF0IHRvIHByb3RlY3QgYWdhaW5zdCB0aGVzZSB0eXBlcyBvZiBhdHRhY2ss IHRoZXNlIHNlY3VyaXR5IG1lYXN1cmVzIG11c3QgYmUgdGFrZW4gcmVnYXJkbGVzcyBvZiB3aGV0 aGVyIHRoZSBQU04gaXMgSVAgb3IgSVAvTVBMUy4NCgkNCgkNCgkNCglBcyBJIHNheSwgYWRtaXR0 ZWRseSBJJ20gbm90IGEgc2VjdXJpdHkgZXhwZXJ0IHNvIEkgd2VsY29tZSBhbnkgY29tbWVudHMg dGhhdCBleHBsYWluIHdoeSBteSBhcmd1bWVudHMgYXJlIGluY29ycmVjdC4NCgkNCgkNCgkNCglS aWNoYXJkDQoJDQoJDQoNCg== From exim@www1.ietf.org Tue Feb 10 10:12:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21733 for ; Tue, 10 Feb 2004 10:12:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZYN-00053C-6Q for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 10:11:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AFBxQf019410 for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 10:11:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZYN-00052z-1G for l3vpn-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:11:59 -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 KAA21696 for ; Tue, 10 Feb 2004 10:11:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZYK-0001GZ-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 10:11:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZXO-0001Bn-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 10:11:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZWa-00016i-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 10:10:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZWU-0004J3-Te; Tue, 10 Feb 2004 10:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZWP-0004Hg-QC for l3vpn@optimus.ietf.org; Tue, 10 Feb 2004 10:09:58 -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 KAA21503 for ; Tue, 10 Feb 2004 10:09:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZWN-00016L-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 10:09:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZVh-00011e-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 10:09:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AqZUv-0000uu-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 10:08:26 -0500 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2004 16:08:31 +0100 Received: from cisco.com (amsterdam.cisco.com [144.254.74.238]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1AF7TL1005393; Tue, 10 Feb 2004 16:07:29 +0100 (MET) Received: from JGUICHARW2K (dhcp-10-86-162-232.cisco.com [10.86.162.232]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA05072; Tue, 10 Feb 2004 16:07:51 +0100 (MET) From: "Jim Guichard" To: , , Subject: RE: MPLS vs IP encap in RFC2547 Date: Tue, 10 Feb 2004 10:00:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 In-Reply-To: Importance: Normal Content-Transfer-Encoding: quoted-printable 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: , List-Id: List-Post: List-Help: List-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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Richard - my basic point is that labelled packets cannot be sent into = a PSN that is either IP or MPLS enabled. So, if an attacker knows all = the relevant label information then how can it get its packets from an = IP network onto an MPLS network ? if the answer is that it can't then I = would argue that the MPLS infrastructure is more secure, not less. If = you contrast that with an IP network then if an attacker can obtain all = the relevant IP information then all they need to do is put the right = encapsulation onto the packet and they may attack the VPN - Jim=20 > >-----Original Message----- > >From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > >Sent: Tuesday, February 10, 2004 2:13 AM > >To: jguichar@cisco.com; l3vpn@ietf.org; mpls@UU.NET > >Subject: RE: MPLS vs IP encap in RFC2547 > > > > > >Hi Jim, > > > >=20 > > > >Thanks for you comment, I am not sure which specific scenario=20 > >you are referring to, can you elaborate as to which point(s) of=20 > >entry you are referring to, what the PSN type is and what type=20 > >of packets (IP or MPLS) are being received by the interface? > > > >=20 > > > >Are you asking even if an intruder learns label information for=20 > >a given destination, how can packets be sent to an interface=20 > >that does not have MPLS enabled? If this is what you are asking=20 > >then I agree that they can't. As I stated in my original message=20 > >"If MPLS labelled packets are received on an interface but MPLS=20 > >is not enabled, then they should be dropped. This is independent=20 > >of whatever encapsulation is used across the PSN." > > > >=20 > > > >However, I may be misinterpreting what you are saying. > > > >=20 > > > >Richard=20 > > > > -----Original Message-----=20 > > From: Jim Guichard [mailto:jguichar@cisco.com]=20 > > Sent: Mon 09/02/2004 14:01=20 > > To: Spencer,R,Richard,XGH5 R; l3vpn@ietf.org; mpls@UU.NET=20 > > Cc:=20 > > Subject: RE: MPLS vs IP encap in RFC2547 > >=09 > >=09 > > > > Hi Richard, > >=09 > > if the intruder is sat on an IP network, even if they gain=20 > >access to a provider router and assertain the relevant label=20 > >information for a given destination, how can they get the=20 > >labelled packet into the provider core, assuming that an=20 > >interface that is NOT enabled for MPLS switching receives the=20 > >incoming packets ? Jim > >=09 > > > >-----Original Message----- > > > >From: l3vpn-admin@ietf.org=20 > >[mailto:l3vpn-admin@ietf.org]On Behalf Of > > > >richard.spencer@bt.com > > > >Sent: Monday, February 09, 2004 1:48 PM > > > >To: l3vpn@ietf.org; mpls@UU.NET > > > >Subject: MPLS vs IP encap in RFC2547 > > > > > > > > > > > >It has been asserted on this mailing list and in a couple of > > > >IETF drafts, that using IP encapsulation techniques across a PSN > > > >instead of MPLS for RFC2547 make it more difficult to protect > > > >VPNs against spoofed attacks. > > > > > > > > > > > > > > > >I would like to challenge this assertion, as I believe that > > > >using IP encapsulation in the PSN instead of MPLS actually makes > > > >it easier to protect against spoofed VPN attacks. I am not a > > > >security expert so I welcome any comments that explain where my > > > >argument falls down. > > > > > > > > > > > > > > > >My argument is based on the fact that that MPLS networks can > > > >forward VPN packets based on IP or MPLS (PHP is a good example > > > >of this), and hence 'IP/MPLS' networks inherit the security > > > >risks associated with both IP and MPLS forwarding. > > > > > > > > > > > > > > > >Fundamentally, this argument comes back to the fact that IP/MPLS > > > >networks today use the same address space for control plane > > > >traffic that they use for forwarding VPN packets in the data > > > >plane, i.e. /32 loopback addresses that are used for LDP/BGP > > > >sessions are also used as PE next hops for VPN packets. As > > > >stated previously, one solution to the problem is to use > > > >filtering; another is to use an OOB control plane. > > > > > > > > > > > > > > > >If an attacker is able to initiate an attack from within the > > > >service provider network then the security risks associated with > > > >IP/MPLS networks are comparable to other VPN technologies such > > > >as ATM/FR. If however an attacker attempts to initiate an attack > > > >from outside the provider network, then the security risks in an > > > >IP/MPLS network are dependant on which routing instance the > > > >interface connects to, i.e. a customer VRF or the global=20 > >routing table. > > > > > > > > > > > > > > > >To provide justification for this argument, I will examine 3 > > > >points of entry into the network where a spoofing attempt might > > > >take place. > > > > > > > > > > > > > > > >1. Via a legitimate non-core facing managed interface at the > > > >edge of the provider network. > > > > > > > > > > > > > > > >a) If the interface belongs to a VPN, then the VRF it belongs to > > > >will only contain routes belonging to that particular VPN. This > > > >would most likely be a customer-facing interface. > > > > > > > > > > > > > > > >If a packet is received with an address/label that belongs to a > > > >different VPN or to the provider network, then the packet will > > > >be dropped because a route to the destination will not exist > > > >(i.e. route isolation is enforced). This is independent of > > > >whatever encapsulation method (IP/GRE, MPLS) is used=20 > >within the PSN. > > > > > > > > > > > > > > > >b) If the interface belongs to the service provider global > > > >routing table, then the routing table will contain IGP routes, > > > >and may contain Internet routes. This would most likely be an > > > >interface facing the Internet or another AS/provider to support > > > >inter-AS/provider VPNs. > > > > > > > > > > > > > > > >In order to protect against IP packet spoofing, ingress > > > >filtering must be applied on the interface. This is independent > > > >of whatever encapsulation method is used within the PSN. This is > > > >a key point, a network running MPLS in the core can still > > > >forward packets based on IP addresses it receives at the edge > > > >(assuming IP is running on interfaces at the edge). > > > > > > > > > > > > > > > >If MPLS labelled packets are received on an interface but MPLS > > > >is not enabled, then they should be dropped. This is independent > > > >of whatever encapsulation is used across the PSN. > > > > > > > > > > > > > > > >If the PSN is using MPLS in the core, and MPLS is enabled on the > > > >interface then filtering needs be used to drop spoofed MPLS > > > >packets. This is in addition to the filtering required to > > > >protect against spoofed IP packets. > > > > > > > > > > > > > > > >2. Via an illegal attack from a router interface within the > > > >provider network by an intruder > > > > > > > > > > > > > > > >i) If an intruder has gained access to a router interface within > > > >the provider network (edge or core), the intruder may also be > > > >able to lookup routing/label information. If so, then the > > > >intruder can use this information to carry out a VPN packet > > > >spoofing attack. This is independent of whatever encapsulation > > > >is used across the PSN. > > > > > > > > > > > > > > > >ii) If an intruder gains access to a router interface within the > > > >provider network but cannot acquire routing/label information, > > > >then brute force techniques must be used to spoof packets. In > > > >order to spoof a VPN packet, an attacker must determine the > > > >correct PSN label/IP destination addresses AND the correct VPN > > > >label. If the PSN label/address is not valid, the first PE/P > > > >router that receives the packet will drop it. If the PSN > > > >label/address is correct but the VPN label is incorrect, then > > > >the packet will be dropped by the egress PE. > > > > > > > > > > > > > > > >If the PSN supports IP only, then the probability of spoofing > > > >success is based on: > > > > > > > > > > > > > > > >P(PSN destination IP address) x P(VPN label) > > > > > > > > > > > > > > > >If the PSN supports IP/MPLS forwarding then the=20 > >probability is based on: > > > > > > > > > > > > > > > >P(PSN destination IP address) x P(VPN label) OR > > > > > > > >P(PSN label) x P(VPN label) > > > > > > > > > > > > > > > >Regardless of what the actual probabilities are, the probability > > > >of a successful VPN packet spoof attack will always greater than > > > >an IP only network. This is because packets can be forwarded > > > >using IP destination addresses OR MPLS labels. > > > > > > > > > > > > > > > >3. Via an illegal attack from an intruder that has tapped into a > > > >physical link within the provider network > > > > > > > > > > > > > > > >i) If an intruder has tapped into a physical link then it is > > > >likely that they are able to snoop MPLS/IP packets to determine > > > >what labels or IP addresses are being used. If so, then the > > > >intruder can use this information to carry out a VPN packet > > > >spoofing attack. This is independent of whatever encapsulation > > > >is used across the PSN. > > > > > > > > > > > > > > > >ii) If an intruder has gained access to a physical link and for > > > >whatever reason can only transmit packets, then brute force > > > >techniques must be applied as described in 2 ii). > > > > > > > > > > > > > > > >In both 2 and 3, the only way to protect against this type of > > > >attack is to use ensure physical network protection and to use > > > >encryption/authentication. The point being that to protect > > > >against these types of attack, these security measures must be > > > >taken regardless of whether the PSN is IP or IP/MPLS. > > > > > > > > > > > > > > > >As I say, admittedly I'm not a security expert so I welcome any > > > >comments that explain why my arguments are incorrect. > > > > > > > > > > > > > > > >Richard > > > > > >=09 > >=09 > > From exim@www1.ietf.org Tue Feb 10 14:20:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03875 for ; Tue, 10 Feb 2004 14:20:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdQV-0001vQ-Ld for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 14:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AJK7wE007394 for l3vpn-archive@odin.ietf.org; Tue, 10 Feb 2004 14:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdQU-0001v3-SJ for l3vpn-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 14:20:07 -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 OAA03845 for ; Tue, 10 Feb 2004 14:20:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqdQS-0004lD-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 14:20:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqdPf-0004eu-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 14:19:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqdOW-0004Wn-00 for l3vpn-web-archive@ietf.org; Tue, 10 Feb 2004 14:18:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdOT-0001lS-MF; Tue, 10 Feb 2004 14:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdNa-0001i1-2K for l3vpn@optimus.ietf.org; Tue, 10 Feb 2004 14:17:06 -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 OAA03632 for ; Tue, 10 Feb 2004 14:17:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqdNX-0004Ni-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 14:17:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqdMY-0004ER-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 14:16:03 -0500 Received: from web21403.mail.yahoo.com ([216.136.232.73]) by ietf-mx with smtp (Exim 4.12) id 1AqdLc-00045j-00 for l3vpn@ietf.org; Tue, 10 Feb 2004 14:15:04 -0500 Message-ID: <20040210191502.64423.qmail@web21403.mail.yahoo.com> Received: from [47.234.0.52] by web21403.mail.yahoo.com via HTTP; Tue, 10 Feb 2004 11:15:02 PST Date: Tue, 10 Feb 2004 11:15:02 -0800 (PST) From: Roger Pottier Subject: Re: Multi-As Backbones To: Marc Binderberger Cc: l3vpn@ietf.org, mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1233346633-1076440502=:64197" 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: , List-Id: List-Post: List-Help: List-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=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1233346633-1076440502=:64197 Content-Type: text/plain; charset=us-ascii Hi Marc, Between the ASBRs at the two ASes, i think you have send-label configured for ipv4 address family. Does that result in the ASBR sending out labels for each PE, within its own AS. Or does it send labels only for its own router ID? For 10(b) with no multihop MP-EBGP, how are the labels exchanged between the ASBRs, to each other - is it using EBGP ipv4+ Label connection. Regards, Roger Marc Binderberger wrote: Hi Roger, > As you said, this could have some scaling limitations. Does LDP assign > a label to each route learnt by the IGP. I think, LDP does not assign > labels for BGP Learnt routes. Can cisco be configured to send labels > for some BGP Learnt routes? >From a test setup. The box is a 7507 w/ 12.0(25)S1: router bgp 65017 bgp router-id 192.168.249.250 bgp cluster-id 3239121353 bgp log-neighbor-changes bgp deterministic-med bgp bestpath compare-routerid neighbor 192.168.249.17 remote-as 65018 neighbor 192.168.249.17 password 7 070D2D4D460B151015100E1E4A6465 ! address-family ipv4 redistribute isis TEST level-2 route-map ISIS-TO-BGP neighbor 192.168.249.17 activate neighbor 192.168.249.17 send-label no auto-summary no synchronization exit-address-family R1-7507#show ip bgp BGP table version is 4, local router ID is 192.168.249.250 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 192.168.249.251/32 192.168.249.46 10 32768 ? *> 192.168.17.206/32 192.168.249.17 10 0 65018 ? R1-7507#show ip bgp 192.168.17.206/32 BGP routing table entry for 192.168.17.206/32, version 4 Paths: (1 available, best #1) Not advertised to any peer 65018 192.168.249.17 from 192.168.249.17 (192.168.249.241) Origin incomplete, metric 10, localpref 100, valid, external, best, mpls labels in/out 106/18 So R1 receives label "18" via eBGP, the LDP binds local label "106". This happens even without a redistribution into the IGP. On router "R3" (belonging to AS65017): R3-7204#show mpls ldp bindings 192.168.17.206 32 detail tib entry: 192.168.17.206/32, rev 37 local binding: tag: 203 Advertised to: 192.168.249.250:0 remote binding: tsr: 192.168.249.250:0, tag: 106 BTW, with 12.2(18)S it did not work. >> Using iBGP IPv4+label - haven't tested yet as no IOS for 7600 (our PE >> plattform) was available supporting this. As I understand the theory >> this results in a packet with 3 labels minimum: the MP-BGP VPN label >> at >> the bottom, then the IPv4 next hop label and topmost the LDP label to >> the ASBR. > > The IPv4 Nexthop Label (Middle one) would be assigned by the ASBR? Yes. But let me try to get 1-2 more test boxes in the setup. Seeing is believing :-) Regards, Marc -- Marc Binderberger Powered by *BSD ;-) --------------------------------- Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online --0-1233346633-1076440502=:64197 Content-Type: text/html; charset=us-ascii
Hi Marc,
 
 Between the ASBRs at the two ASes, i think you have send-label configured for ipv4
address family. Does that result in the ASBR sending out labels for each PE, within
 its own AS. Or does it send labels only for its own router ID?
 
 For 10(b) with no multihop MP-EBGP, how are the labels exchanged between the
 ASBRs, to each other - is it using EBGP ipv4+ Label connection.
 
Regards,
Roger
 

Marc Binderberger <marc@sniff.de> wrote:
Hi Roger,

> As you said, this could have some scaling limitations. Does LDP assign
> a label to each route learnt by the IGP. I think, LDP does not assign
> labels for BGP Learnt routes. Can cisco be configured to send labels
> for some BGP Learnt routes?


From a test setup. The box is a 7507 w/ 12.0(25)S1:

router bgp 65017
bgp router-id 192.168.249.250
bgp cluster-id 3239121353
bgp log-neighbor-changes
bgp deterministic-med
bgp bestpath compare-routerid
neighbor 192.168.249.17 remote-as 65018
neighbor 192.168.249.17 password 7 070D2D4D460B151015100E1E4A6465
!
address-family ipv4
redistribute isis TEST level-2 route-map ISIS-TO-BGP
neighbor 192.168.249.17 activate
neighbor 192.168.249.17 send-label
no auto-summary
no synchronization
exit-address-family


R1-7507#show ip bgpBGP table version is 4, local router ID is 192.168.249.250
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 192.168.249.251/32
192.168.249.46 10 32768 ?
*> 192.168.17.206/32
192.168.249.17 10 0 65018 ?

R1-7507#show ip bgp 192.168.17.206/32
BGP routing table entry for 192.168.17.206/32, version 4
Paths: (1 available, best #1)
Not advertised to any peer
65018
192.168.249.17 from 192.168.249.17 (192.168.249.241)
Origin incomplete, metric 10, localpref 100, valid, external,
best,
mpls labels in/out 106/18


So R1 receives label "18" via eBGP, the LDP binds local label "106".
This happens even without a redistribution into the IGP.

On router "R3" (belonging to AS65017):

R3-7204#show mpls ldp bindings 192.168.17.206 32 detail
tib entry: 192.168.17.206/3! 2, rev 37
local binding: tag: 203
Advertised to:
192.168.249.250:0
remote binding: tsr: 192.168.249.250:0, tag: 106


BTW, with 12.2(18)S it did not work.



>> Using iBGP IPv4+label - haven't tested yet as no IOS for 7600 (our PE
>> plattform) was available supporting this. As I understand the theory
>> this results in a packet with 3 labels minimum: the MP-BGP VPN label
>> at
>> the bottom, then the IPv4 next hop label and topmost the LDP label to
>> the ASBR.
>
> The IPv4 Nexthop Label (Middle one) would be assigned by the ASBR?

Yes. But let me try to get 1-2 more test boxes in the setup. Seeing is
believing :-)


Regards, Marc
--
Marc Binderberger Powered by *BSD ;-)

Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online --0-1233346633-1076440502=:64197-- From exim@www1.ietf.org Wed Feb 11 14:29:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16133 for ; Wed, 11 Feb 2004 14:29:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar02X-00054q-EW for l3vpn-archive@odin.ietf.org; Wed, 11 Feb 2004 14:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJSrAX019514 for l3vpn-archive@odin.ietf.org; Wed, 11 Feb 2004 14:28:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar02X-00054f-A7 for l3vpn-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:28:53 -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 OAA16104 for ; Wed, 11 Feb 2004 14:28:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar02U-0002Zj-00 for l3vpn-web-archive@ietf.org; Wed, 11 Feb 2004 14:28:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar01c-0002UJ-00 for l3vpn-web-archive@ietf.org; Wed, 11 Feb 2004 14:27:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar00y-0002OW-00 for l3vpn-web-archive@ietf.org; Wed, 11 Feb 2004 14:27:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar00i-0004mG-Of; Wed, 11 Feb 2004 14:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar00f-0004lq-LT for l3vpn@optimus.ietf.org; Wed, 11 Feb 2004 14:26:58 -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 OAA16018 for ; Wed, 11 Feb 2004 14:26:55 -0500 (EST) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar00d-0002NY-00 for l3vpn@ietf.org; Wed, 11 Feb 2004 14:26:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqzzi-0002I2-00 for l3vpn@ietf.org; Wed, 11 Feb 2004 14:25:59 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139] helo=i2kc05-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AqzzS-0002Bz-00 for l3vpn@ietf.org; Wed, 11 Feb 2004 14:25:42 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Feb 2004 19:25:11 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Feb 2004 19:25:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: MPLS vs IP encap in RFC2547 Date: Wed, 11 Feb 2004 19:25:10 -0000 Message-ID: Thread-Topic: MPLS vs IP encap in RFC2547 Thread-Index: AcPvwQyzGzGL89jhT9Shd5aX8scmegBE0c0P To: Cc: , X-OriginalArrivalTime: 11 Feb 2004 19:25:11.0162 (UTC) FILETIME=[C42E7DA0:01C3F0D4] Content-Transfer-Encoding: base64 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgTWFyYywNCg0KIA0KDQo+IG1heWJlIEknbSBtaXNzaW5nIHNvbWV0aGluZyBidXQgZnJvbSB3 aGF0IHlvdSBzYXkgSSBjYW4ndCBzZWUgdGhlDQo+ICJzcG9vZiBwcm9iYWJpbGl0eSBpcyBoaWdo ZXIgZm9yIE1QTFMgdGhhbiBmb3IgSVAgZW5jYXBzdWxhdGlvbiIuIExvb2tzDQo+IG1vcmUgbGlr ZSBhICJub3QgbXVjaCBkaWZmZXJlbmNlIiBmb3IgbWUuDQoNCk15IGFyZ3VtZW50IHdhcyBiYXNl ZCBvbiB0aGUgZmFjdCB0aGF0IGluIGFuIElQL01QTFMgbmV0d29yaywgVlBOIHBhY2tldHMgY291 bGQgcG90ZW50aWFsbHkgYmUgZm9yd2FyZGVkIHVzaW5nIE1QTFMtaW4tSVAvR1JFIG9yIE1QTFMg bGFiZWwgc3RhY2tpbmcuIFRoZXJlZm9yZSBhdCBmaXJzdCBwYXNzIEkgYXNzdW1lZCB0aGUgc3Bv b2ZpbmcgcHJvYmFiaWxpdHkgd2FzIFAoTVBMUy1pbi1JUC9HUkUgc3Bvb2YgYXR0YWNrKSArIFAo TVBMUyBsYWJlbCBzdGFja2VkIHNwb29mIGF0dGFjaykuIEhvd2V2ZXIsIGhhdmluZyB0aG91Z2h0 IGFib3V0IGl0IGZ1cnRoZXIsIGV2ZW4gaWYgTVBMUy1pbi1JUC9HUkUgd2FzIHN1cHBvcnRlZCBi eSBkZWZhdWx0IGFjcm9zcyBhbiBJUC9NUExTIG5ldHdvcmssIGl0IHdvdWxkIGJlIGVhc3kgdG8g c3RvcCBNUExTLWluLUlQIHNwb29maW5nIGF0dGFja3MgYnkgdXNpbmcgSVAgcHJvdG9jb2wgbnVt YmVyIGZpbHRlcmluZy4NCg0KIA0KDQpJIG5vdyBhZ3JlZSB3aXRoIGV4aXN0aW5nIElFVEYgZHJh ZnRzIHRoYXQgc2F5IFZQTiBwYWNrZXQgc3Bvb2ZpbmcgaXMgZWFzaWVyIHRvIHByb3RlY3QgYWdh aW5zdCBpbiBhbiBNUExTIFBTTiB0aGFuIGl0IGlzIGluIGFuIElQIFBTTi4gSG93ZXZlciwgdGhp cyBpcyBiYXNlZCBvbiB0aGUgZmFjdCB0aGF0IDEpIE1QTFMgcGFja2V0cyByZWNlaXZlZCBhdCB0 aGUgZWRnZSBjYW4gYmUgZHJvcHBlZCAob3IgdGhlaXIgbGFiZWxzIGNoZWNrZWQgYWdhaW5zdCBk aXN0cmlidXRlZCBsYWJlbHMgaWYgdGhlIGludGVyZmFjZSBzdXBwb3J0cyBNUExTKSwgYW5kIDIp IE1QTFMtaW4tSVAvR1JFIHBhY2tldHMgKGlmIHN1cHBvcnRlZCkgY2FuIGJlIGRyb3BwZWQgYnkg c2ltcGx5IGZpbHRlcmluZyBvbiB0aGUgSVAgcHJvdG9jb2wgbnVtYmVyLiBBcyBmYXIgYXMgSSBr bm93LCB0aGUgY3VycmVudCBJRVRGIGRyYWZ0cyBvbmx5IG1lbnRpb24gMSwgYW5kIG5vdCAyLiBJ IGd1ZXNzIGhvdyBpbXBvcnRhbnQgMiBpcyBkZXBlbmRzIG9uIHdoZXRoZXIgcm91dGVyIGltcGxl bWVudGF0aW9ucyBzdXBwb3J0IE1QTFMtaW4tSVAvR1JFIGJ5IGRlZmF1bHQgYW5kIHRoZXJlZm9y ZSBJUCBwcm90b2NvbCBudW1iZXIgZmlsdGVyaW5nIGlzIHJlcXVpcmVkLCBvciBpZiBNUExTLWlu LUlQL0dSRSBzdXBwb3J0IGlzIGEgZmVhdHVyZSB0aGF0IHByb3ZpZGVycyBjYW4gc2ltcGx5IHR1 cm4gb24gb3Igb2ZmLiANCg0KDQo+IFRoZSBvdmVyYWxsIGNvbXBsZXhpdHkgb2YgdGhlIE1QTFMg Y29udHJvbCBwbGFuZSBpcyBsYXJnZXIgdGhhbiBmb3INCj4gbmF0aXZlIElQIGR1ZSB0byBhZGRp dGlvbmFsIHByb3RvY29scyBsaWtlIExEUCBhbmQgUlNWUC4gVGhlIGNoYWxsZW5nZQ0KPiB0byBw cm90ZWN0IHRoZXNlIHByb3RvY29scyBpcyBzaW1pbGFyIHRvIGEgbmF0aXZlIElQIG5ldHdvcmsg YW5kIHRoZQ0KPiBwcm90ZWN0aW9uIG1lY2hhbmlzbSBhcmUgaWRlbnRpY2FsLCBlLmcuIE1ENSBo YXNoaW5nLCBpbmZyYXN0cnVjdHVyZQ0KPiBBQ0wgIGFuZCBzbyBvbi4gV2l0aCBtb3JlIHByb3Rv Y29scyBpbiBwbGFjZSBpdCBpcyBwcm9iYWJseSBlYXNpZXIgdG8NCj4gZGlzdHVyYiB0aGUgTVBM UyBzZXJ2aWNlLg0KDQogDQoNCkFncmVlZCwgSVAgb25seSBuZWVkcyByb3V0aW5nIHByb3RvY29s cyB3aGVyZWFzIE1QTFMgcmVxdWlyZXMgcm91dGluZyBhbmQgc2lnbmFsbGluZyBwcm90b2NvbHMs IHdoaWNoIGFkZHMgZXh0cmEgY29tcGxleGl0eS4gSG93ZXZlciwgdXNpbmcgcHJvdG9jb2xzIGxp a2UgTDJUUCBpbiBhbiBJUCBuZXR3b3JrIGFsc28gaW5jcmVhc2VzIGNvbXBsZXhpdHkuICANCg0K PiBJIGRpc2FncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQgdGhhdCBpbiBhbiBJUC9NUExTIG5ldHdv cmsgYm90aCBvcHRpb24NCj4gYXJlIGF2YWlsYWJsZSwgZm9yd2FyZGluZyBiYXNlZCBvbiBJUCBh bmQgb24gTVBMUyBhbmQgdGh1cyB0aGUgb3ZlcmFsbA0KPiByaXNrIGlzIHRoZSBzdW0gb2YgYm90 aC4NCg0KIA0KDQpZZXMgSSBhZ3JlZSB0aGF0IG15IG9yaWdpbmFsIHN0YXRlbWVudCB3YXMgaW5j b3JyZWN0LCBhcyBJIGhhZCBub3QgdGFrZW4gaW50byBhY2NvdW50IGhvdyBlYXN5IGl0IHdvdWxk IGJlIHRvIGJsb2NrIE1QTFMtaW4tSVAgcGFja2V0cyBpbiBhbiBJUC9NUExTIG5ldHdvcmsuIA0K DQogDQoNCj4gVG8gc3Bvb2YgaW50byBhIE1QTFMgVlBOIGZyb20gdGhlIGZvcndhcmRpbmcgcGxh bmUgeW91IG5lZWQgbGFiZWxsZWQgdHJhZmZpYw0KDQogDQoNCuKApiBvciBzdXBwb3J0IGZvciBN UExTLWluLUlQL0dSRSB0cmFmZmljLg0KDQogDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cywN Cg0KIA0KDQpSaWNoYXJkDQoNCg== From exim@www1.ietf.org Thu Feb 12 00:42:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25827 for ; Thu, 12 Feb 2004 00:42:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cF-0006El-Hq for l3vpn-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5gNnO023969 for l3vpn-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9cF-0006EW-D5 for l3vpn-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:42:23 -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 AAA25720 for ; Thu, 12 Feb 2004 00:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9cC-0005t9-00 for l3vpn-web-archive@ietf.org; Thu, 12 Feb 2004 00:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9bM-0005j4-00 for l3vpn-web-archive@ietf.org; Thu, 12 Feb 2004 00:41:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar9a1-0005YR-00 for l3vpn-web-archive@ietf.org; Thu, 12 Feb 2004 00:40:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar9L5-0005hR-C4 for l3vpn-web-archive@ietf.org; Thu, 12 Feb 2004 00:24:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9Ko-0003WI-Jh; Thu, 12 Feb 2004 00:24:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar99k-0002wW-A2 for l3vpn@optimus.ietf.org; Thu, 12 Feb 2004 00:12:56 -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 AAA24584 for ; Thu, 12 Feb 2004 00:12:53 -0500 (EST) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar99h-0002vn-00 for l3vpn@ietf.org; Thu, 12 Feb 2004 00:12:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar98j-0002r2-00 for l3vpn@ietf.org; Thu, 12 Feb 2004 00:11:54 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150] helo=i2kc02-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1Ar98O-0002mO-00 for l3vpn@ietf.org; Thu, 12 Feb 2004 00:11:33 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by i2kc02-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 05:11:01 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 05:11:01 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: MPLS vs IP encap in RFC2547 Date: Thu, 12 Feb 2004 05:11:00 -0000 Message-ID: Thread-Topic: MPLS vs IP encap in RFC2547 Thread-Index: AcPv56oWv2JtzZC4S7WlnEzss3/XaABOVq7f To: , , X-OriginalArrivalTime: 12 Feb 2004 05:11:01.0632 (UTC) FILETIME=[9B7E9000:01C3F126] Content-Transfer-Encoding: base64 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgSmltLA0KIA0KPiBIaSBSaWNoYXJkIC0gbXkgYmFzaWMgcG9pbnQgaXMgdGhhdCBsYWJlbGxl ZCBwYWNrZXRzIGNhbm5vdCBiZSBzZW50IA0KPiBpbnRvIGEgUFNOIHRoYXQgaXMgZWl0aGVyIElQ IG9yIE1QTFMgZW5hYmxlZC4gU28sIGlmIGFuIGF0dGFja2VyIGtub3dzIA0KPiBhbGwgdGhlIHJl bGV2YW50IGxhYmVsIGluZm9ybWF0aW9uIHRoZW4gaG93IGNhbiBpdCBnZXQgaXRzIHBhY2tldHMg ZnJvbSANCj4gYW4gSVAgbmV0d29yayBvbnRvIGFuIE1QTFMgbmV0d29yayA/DQogDQpSZWdhcmRp bmcgdGhlIHNlbmRpbmcgb2YgbGFiZWxsZWQgcGFja2V0cyBpbnRvIGFuIE1QTFMgUFNOLCBJIHdh cyB0aGlua2luZyBvZiB0aGUgaW50ZXItcHJvdmlkZXIgY2FzZSB3aGVyZSBhIFBTTiBtYXkgcmVj ZWl2ZSBsYWJlbGxlZCBwYWNrZXRzIGZyb20gYW5vdGhlciBwcm92aWRlci4gSSBhZ3JlZSB0aGF0 IGxhYmVsbGVkIHBhY2tldHMgY2Fubm90IG5vcm1hbGx5IGJlIHNlbnQgaW50byBhIFBTTiwgaS5l LiBieSBhIENFLg0KIA0KPiBpZiB0aGUgYW5zd2VyIGlzIHRoYXQgaXQgY2FuJ3QgdGhlbiBJIHdv dWxkIGFyZ3VlIHRoYXQgdGhlIE1QTFMgDQo+IGluZnJhc3RydWN0dXJlIGlzIG1vcmUgc2VjdXJl LCBub3QgbGVzcy4gSWYgeW91IGNvbnRyYXN0IHRoYXQgd2l0aCBhbiANCj4gSVAgbmV0d29yayB0 aGVuIGlmIGFuIGF0dGFja2VyIGNhbiBvYnRhaW4gYWxsIHRoZSByZWxldmFudCBJUCANCj4gaW5m b3JtYXRpb24gdGhlbiBhbGwgdGhleSBuZWVkIHRvIGRvIGlzIHB1dCB0aGUgcmlnaHQgZW5jYXBz dWxhdGlvbiANCj4gb250byB0aGUgcGFja2V0IGFuZCB0aGV5IG1heSBhdHRhY2sgdGhlIFZQTiAt IEppbQ0KIA0KSSBub3cgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgVlBOIGRhdGEgcGxhbmUgaXMg bW9yZSBzZWN1cmUgaW4gYSBNUExTIFBTTiB0aGFuIGl0IGlzIGluIGFuIElQIFBTTi4gVGhlIHJl YXNvbnMgYmVpbmcgdGhhdCAxKSBhbnkgbGFiZWxsZWQgcGFja2V0cyByZWNlaXZlZCBmcm9tIGEg Q0UgY2FuIHNpbXBseSBiZSBkcm9wcGVkLCAyKSBhbnkgbGFiZWxsZWQgcGFja2V0cyByZWNlaXZl ZCBmcm9tIGFub3RoZXIgcHJvdmlkZXIgY2FuIGhhdmUgdGhlaXIgbGFiZWxzIGNoZWNrZWQgYWdh aW5zdCBhIGxpc3Qgb2YgdmFsaWQgbGFiZWxzIGRpc3RyaWJ1dGVkIGJ5IHRoZSBQRSB0byB0aGF0 IHByb3ZpZGVyLCBhbmQgMykgTVBMUy1pbi1JUC9HUkUgcGFja2V0cyAoaWYgc3VwcG9ydGVkKSBj YW4gYmUgZHJvcHBlZCBieSB0dXJuaW5nIHRoZSBmZWF0dXJlIG9mZiBvciBieSBmaWx0ZXJpbmcg YmFzZWQgb24gSVAgcHJvdG9jb2wgbnVtYmVycy4NCg0KUmljaGFyZA0K From exim@www1.ietf.org Mon Feb 16 12:32:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07442 for ; Mon, 16 Feb 2004 12:32:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asmbf-0008Nn-Q3 for l3vpn-archive@odin.ietf.org; Mon, 16 Feb 2004 12:32:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GHWVr1032215 for l3vpn-archive@odin.ietf.org; Mon, 16 Feb 2004 12:32:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asmbf-0008NW-KP for l3vpn-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 12:32:31 -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 MAA07434 for ; Mon, 16 Feb 2004 12:32:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asmbe-0003ba-00 for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 12:32:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asmao-0003YN-00 for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 12:31:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsmaG-0003TM-00 for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 12:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmaE-0008J2-JX; Mon, 16 Feb 2004 12:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmZI-0008Gh-JT for l3vpn@optimus.ietf.org; Mon, 16 Feb 2004 12:30:04 -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 MAA07136 for ; Mon, 16 Feb 2004 12:30:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsmZG-0003JY-00 for l3vpn@ietf.org; Mon, 16 Feb 2004 12:30:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsmXz-00036g-00 for l3vpn@ietf.org; Mon, 16 Feb 2004 12:28:43 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AsmWs-0002re-00 for l3vpn@ietf.org; Mon, 16 Feb 2004 12:27:34 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1GHR3Bm059533 for ; Mon, 16 Feb 2004 09:27:04 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp005.static.jnpr.net [172.24.253.5]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1GHR3o56942 for ; Mon, 16 Feb 2004 09:27:03 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040216121254.040f9080@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 16 Feb 2004 12:26:24 -0500 To: l3vpn@ietf.org From: Ross Callon Subject: Last Call on Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 This message begins working group last call on . Note that this document already passed working group last call a while ago. However, the document has since been updated based on IESG comments. The last call will therefore be limited to the changes which have been made, and is abbreviated in time frame. The last call will end on Wednesday, February 25. The changes which have been made include: - Explanation of 3 scenarios for the deployment of VPNs. (see section 1.2). In those cases where requirements vary between scenarios, stating how. - Substantial increase in the scaling requirements presented in section 5.1.2. - Editorial changes (typos corrected, extra spaces removed, "VPN" in the title expanded to "Virtual Private Networks"). - Some text clarification. - Capitalization of keywords such as "MUST" and "SHOULD". - Adding reference to Security Framework document and general cleaning up of references, along with mentioning draft names in addition to titles. Ross From exim@www1.ietf.org Mon Feb 16 15:42:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20378 for ; Mon, 16 Feb 2004 15:42:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspYs-0002zm-4b for l3vpn-archive@odin.ietf.org; Mon, 16 Feb 2004 15:41:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKfosA011508 for l3vpn-archive@odin.ietf.org; Mon, 16 Feb 2004 15:41:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspYr-0002zX-VN for l3vpn-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:41:49 -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 PAA20277 for ; Mon, 16 Feb 2004 15:41:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspYq-0002XN-00 for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspXy-0002RX-00 for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:40:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AspXR-0002Li-00 for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:40:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspXE-00026P-Ia; Mon, 16 Feb 2004 15:40:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspWk-00021N-MT for l3vpn@optimus.ietf.org; Mon, 16 Feb 2004 15:39:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19823; Mon, 16 Feb 2004 15:39:36 -0500 (EST) Message-Id: <200402162039.PAA19823@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l3vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-as-vr-01.txt Date: Mon, 16 Feb 2004 15:39:36 -0500 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: , List-Id: List-Post: List-Help: List-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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches Author(s) : A. Nagarajan Filename : draft-ietf-l3vpn-as-vr-01.txt Pages : 28 Date : 2004-2-16 This document is an applicability statement for Layer 3 Provider Provisioned VPNs (L3 PPVPNs) that is based on Virtual Router (VR) approaches. This document describes how VR-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as-vr-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l3vpn-as-vr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l3vpn-as-vr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-16122930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-as-vr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-as-vr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16122930.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Mon Feb 16 15:53:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22172 for ; Mon, 16 Feb 2004 15:53:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspjL-0004i8-AA for l3vpn-archive@odin.ietf.org; Mon, 16 Feb 2004 15:52:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKqdLc018102 for l3vpn-archive@odin.ietf.org; Mon, 16 Feb 2004 15:52:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspjL-0004ho-2G for l3vpn-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:52:39 -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 PAA22023 for ; Mon, 16 Feb 2004 15:52:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspjJ-0004TK-00 for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:52:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsphH-00042A-00 for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:50:32 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aspf2-0003b2-00 for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:48:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aspf1-0003Pp-9b for l3vpn-web-archive@ietf.org; Mon, 16 Feb 2004 15:48:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aspeq-0004B5-QX; Mon, 16 Feb 2004 15:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspeM-00048D-87 for l3vpn@optimus.ietf.org; Mon, 16 Feb 2004 15:47:30 -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 PAA21365 for ; Mon, 16 Feb 2004 15:47:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspeK-0003T2-00 for l3vpn@ietf.org; Mon, 16 Feb 2004 15:47:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aspd6-0003Er-00 for l3vpn@ietf.org; Mon, 16 Feb 2004 15:46:13 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1Aspc2-0002z8-00; Mon, 16 Feb 2004 15:45:06 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1GKiZBm059896; Mon, 16 Feb 2004 12:44:35 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp161.static.jnpr.net [172.24.253.161]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1GKiYo70123; Mon, 16 Feb 2004 12:44:35 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040216154230.040f9080@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 16 Feb 2004 15:44:15 -0500 To: l3vpn@ietf.org, l2vpn@ietf.org From: Ross Callon Subject: End of Last Call (Re: last call on terminology draft) In-Reply-To: <20040120215626.64812.qmail@web109.biz.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 At 01:56 PM 1/20/2004 -0800, Rick Wilder wrote: >This begins a 2-week last-call period for . > >Please let the list hear any remaining comments on this document. > >Rick The VPN Terminology Draft, , has now successfully completed last call. Ross From exim@www1.ietf.org Wed Feb 18 13:01:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04620 for ; Wed, 18 Feb 2004 13:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW0M-0002QQ-I1 for l3vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 13:01:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1II12NL009314 for l3vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 13:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW0L-0002Pz-VZ for l3vpn-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 13:01:02 -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 NAA04599 for ; Wed, 18 Feb 2004 13:00:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtW0K-0003Oi-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 13:01:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVyf-00039L-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 12:59:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtVxp-00032n-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 12:58:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVxR-0002JC-IN; Wed, 18 Feb 2004 12:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVwt-0002Id-0v for l3vpn@optimus.ietf.org; Wed, 18 Feb 2004 12:57:27 -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 MAA04283 for ; Wed, 18 Feb 2004 12:57:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVwr-0002uU-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 12:57:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVw9-0002ns-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 12:56:42 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AtVvH-0002al-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 12:55:47 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1IHtHBm071222 for ; Wed, 18 Feb 2004 09:55:17 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (rcallon-lt.jnpr.net [10.10.132.117]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1IHtFo98141 for ; Wed, 18 Feb 2004 09:55:16 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040218111818.032b8278@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 18 Feb 2004 12:55:09 -0500 To: l3vpn@ietf.org From: Ross Callon Subject: Re: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 With my "individual participant" hat on, I have a few comments, mostly editorial, on this draft. - First of all, the -02 version has been published, and thus I will comment based on draft-ietf-l3vpn-mpls-vpn-mib-02.txt. - The title has a dangling "Using" in it. Also, it seems that the term "BGP/MPLS" is used more commonly than "MPLS/BGP". Thus I believe that the title should be changed to: BGP/MPLS Layer 3 Virtual Private Network Management Information Base - Second paragraph of the status section: Change "In ternet" to "Internet". - My understanding is that this document is the MIB for "BGP/MPLS IP VPNs" as specified in . The abstract seems to be not quite as precise as it could be in stating this. How about changing the abstract to be: Abstract This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor BGP/MPLS IP Layer 3 Virtual Private Networks [reference] on a Multi- Protocol Label Switching (MPLS) enabled Label Switching Router (LSR) supporting this feature. This same change will also effect the first paragraph of section 2.0 (Introduction). - In a similar vein, there are many places where the document refers to "MPLS L3 VPNs". I would be inclined to change this to "BGP/MPLS L3 VPNs". I think that this is a bit more precise, and might avoid confusion with any other sort of L3 VPN which makes use of MPLS (eg, in principle one could use MPLS LSPs between VRs, which is not in the scope of this MIB as I understand it). - The reference also needs to be updated in a couple of ways. On the one hand, the reference to the "BGP/MPLS IP VPNs" document is quite out of date (it should be to draft-ietf-l3vpn-rfc2547bis-01.txt). Also, I would expect that at some point the "BGP/MPLS IP VPNs" document will probably be published as an RFC, and that people will stop referring to the approach as "2547" since there will be a different RFC number for the approach. Thus I would think that a reference with a pointer such as [BGP/MPLS VPNs] would be better than [RFC2547bis]. Actually, elsewhere in the document the reference is listed as [MPLSBGPVPN], while in the reference section it is listed as [RFC2547bis]. - I found the second paragraph of the terminology section confusing. It currently states: Throughout this document, the use of the terms "Provider Edge (PE) and Customer Edge (CE) or PE/CE" will be replaced by PE in all cases except when a network device is a CE when used in the carrier of carriers model. To me this seems to imply that where you want to say "Provider Edge" you will say PE, and where you want to say "Provider Edge or Customer Edge" you will say "PE". Is this right? It seems to me that (i) The terms "PE" and "CE" are very standard VPN terms; and (ii) If you want to say "provider edge or customer edge" you should say "PE or CE". Thus, I would be inclined to delete this paragraph. Also, I think that it would be useful to add a reference to the terminology draft to the first paragraph of the terminology section (see ). - Section 5, last bullet item, this currently states: - LDP paths or traffic engineered tunnels should be configured between PEs and CEs. With layer 3 VPNs (whether based on BGP/MPLS VPNs or on VRs) the LSPs are not normally set up to the CE devices. Also, the LSPs don't need to be manually configured, they could be set up via signaling. Also, this sentence seems to assume that if the LSPs are set up using RSVP, then this must be for the purpose of traffic engineering. In fact, this sentence seems to be getting to the requirement that LSPs are set up between PE devices. So why not say so by changing this bullet item to: - LSPs should be set up between PEs. - Section 6.2, mplsL3vpnIfConfTable This currently reads: This table represents the MPLS L3VPN-enabled interfaces that are associated with a specific VRF as represented in the aforementioned mplsL3VpnVrfTable. Each entry in this table corresponds to an entry in the Interfaces MIB... There is a nit here: For the interfaces between any particular PE and any particular CE: In general this interface will be associated with a particular VRF. However, in general you won't be actually running MPLS over this interface and don't need to be running BGP over this interface. Thus in a sense you aren't actually operating the BGP/MPLS L3 VPN protocols over this interface, but are instead running "ordinary" routing stuff over this interface, which then gets associated with the appropriate VRF. Thus, perhaps this paragraph should start out as: This table represents the interfaces that are associated with a specific VRF (and therefore are part of a particular VPN being supported using BGP/MPLS L3 VPNs) as represented in the aforementioned mplsL3VpnVrfTable. Each entry in this table corresponds to an entry in the Interfaces MIB... Another question on the same paragraph: In general a PE device will have one or more interfaces to P devices. Any one interface from PE to P device may support multiple LSPs to other PEs, and any one PE to PE LSP may support multiple VPNs. Thus the interface from PE to P may in some sense be used to support multiple VPNs. Are the PE to P interfaces included in the mplsL3VpnIfConfTable? My understanding (which might be wrong) is that they are not. - A very minor nit on page 6, (part of section 8), in the description of MplsL3VpnName. Here you refer to the BGP/MPLS L3 VPN approach as "MPLS/BGP VPN". In fact I have seen this written as both "BGP/MPLS VPNs", and "MPLS/BGP VPNs". It seems to me that it is a bit cleaner to pick one way of writing the terminology and stick with it, and it seems more common to put the BGP first. I agree that this is a pretty silly nit, but it seems that it might be slightly less confusing to be consistent (both within any one document and between documents). - I think that the reference to [VPNTCMIB] also should be updated, although you should know better than me. thanks, Ross At 01:42 PM 1/30/2004 -0500, Ronald Bonica wrote: >Folks, > >This message initiates a WG last call on draft-ietf-l3vpn-mpls-vpn-mib-01. >The last call will end on February 13. > > Ron > > >-----Original Message----- >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of >Internet-Drafts@ietf.org >Sent: Friday, January 30, 2004 11:50 AM >To: IETF-Announce: >Cc: l3vpn@ietf.org >Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Layer 3 Virtual Private Networks Working >Group of the IETF. > > Title : MPLS/BGP Layer 3 Virtual Private Network Management Information >Base Using > Author(s) : T. Nadeau > Filename : draft-ietf-l3vpn-mpls-vpn-mib-01.txt > Pages : 35 > Date : 2004-1-29 From exim@www1.ietf.org Wed Feb 18 15:06:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15325 for ; Wed, 18 Feb 2004 15:06:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXxN-0001UY-78 for l3vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 15:06:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IK65Y7005733 for l3vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 15:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXxM-0001UO-W5 for l3vpn-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 15:06:05 -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 PAA15261 for ; Wed, 18 Feb 2004 15:06:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtXxK-00025j-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 15:06:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXwM-00021b-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 15:05:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtXvP-0001yw-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 15:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXvN-0008PY-Li; Wed, 18 Feb 2004 15:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXuU-0007Ne-Oy for l3vpn@optimus.ietf.org; Wed, 18 Feb 2004 15:03:06 -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 PAA15075 for ; Wed, 18 Feb 2004 15:03:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtXuR-0001wK-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 15:03:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXtS-0001tv-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 15:02:03 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AtXsj-0001qA-00; Wed, 18 Feb 2004 15:01:17 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2004 12:00:46 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1IK0h0K026461; Wed, 18 Feb 2004 15:00:44 -0500 (EST) Received: from cisco.com (rtp-vpn3-316.cisco.com [10.82.217.62]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AXB71847; Wed, 18 Feb 2004 12:00:41 -0800 (PST) Message-ID: <4033C468.8090803@cisco.com> Date: Wed, 18 Feb 2004 21:00:40 +0100 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ross Callon CC: l3vpn@ietf.org, l2vpn@ietf.org Subject: Re: End of Last Call (Re: last call on terminology draft) References: <4.3.2.20040216154230.040f9080@zircon.juniper.net> In-Reply-To: <4.3.2.20040216154230.040f9080@zircon.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Did we ever decide on the best single term for: RFC 2547-Style VPNs, or BGP/MPLS VPNs, or MPLS/BGP VPNs, or ...some other term? Thanks, - Mark Ross Callon wrote: > At 01:56 PM 1/20/2004 -0800, Rick Wilder wrote: > > >>This begins a 2-week last-call period for . >> >>Please let the list hear any remaining comments on this document. >> >>Rick > > > The VPN Terminology Draft, , > has now successfully completed last call. > > Ross > > > From exim@www1.ietf.org Wed Feb 18 20:05:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05103 for ; Wed, 18 Feb 2004 20:05:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtccQ-0000mP-I7 for l3vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 20:04:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J14k4b002991 for l3vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 20:04:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtccQ-0000mA-Dh for l3vpn-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 20:04:46 -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 UAA05078 for ; Wed, 18 Feb 2004 20:04:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtccO-0006PB-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 20:04:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtcbV-0006N1-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 20:03:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atcao-0006L9-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 20:03:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atcaj-0000cl-AS; Wed, 18 Feb 2004 20:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtcaP-0000cO-Cq for l3vpn@optimus.ietf.org; Wed, 18 Feb 2004 20:02:41 -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 UAA05029 for ; Wed, 18 Feb 2004 20:02:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtcaN-0006JZ-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 20:02:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtcZP-0006H1-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 20:01:39 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AtcYV-0006EN-00; Wed, 18 Feb 2004 20:00:43 -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 i1J10Dl38565; Wed, 18 Feb 2004 17:00:13 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp045.static.jnpr.net [172.24.253.45]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1J107o50002; Wed, 18 Feb 2004 17:00:07 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040218195003.0328f160@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 18 Feb 2004 19:59:06 -0500 To: "W. Mark Townsley" From: Ross Callon Subject: Re: End of Last Call (Re: last call on terminology draft) Cc: l3vpn@ietf.org, l2vpn@ietf.org In-Reply-To: <4033C468.8090803@cisco.com> References: <4.3.2.20040216154230.040f9080@zircon.juniper.net> <4.3.2.20040216154230.040f9080@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 At 09:00 PM 2/18/2004 +0100, W. Mark Townsley wrote: >Did we ever decide on the best single term for: > >RFC 2547-Style VPNs, or >BGP/MPLS VPNs, or >MPLS/BGP VPNs, or Good question. I agree that we should have one term. with my "participant only" hat on: As I pointed out in my earlier email today (to L3vpn only regarding the MIB for BGP/MPLS VPNs) I don't like the term "RFC2547-style VPNs" because I expect that eventually a derivative of the current documents for this approach will be published as RFCs, and the number will be something other than 2547. Between the other two terms, I don't care. However, doing a quick survey (which I did a while ago), it looked to me that the term "BGP/MPLS VPNs" is used more often than "MPLS/BGP VPNs". Thus it would be easier to put the BGP first (fewer places to fix). Finally, if we are talking about layer 3 VPNs, it might be the most precise to put this as: BGP/MPLS L3 VPNs Just my opinion. thanks, Ross From exim@www1.ietf.org Wed Feb 18 21:12:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07803 for ; Wed, 18 Feb 2004 21:12:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdfJ-0006JO-Hn for l3vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 21:11:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J2BnA3024256 for l3vpn-archive@odin.ietf.org; Wed, 18 Feb 2004 21:11:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtdfJ-0006J9-DW for l3vpn-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 21:11:49 -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 VAA07798 for ; Wed, 18 Feb 2004 21:11:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtdfG-0001pd-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 21:11:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtdeL-0001o1-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 21:10:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atddc-0001mI-00 for l3vpn-web-archive@ietf.org; Wed, 18 Feb 2004 21:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atddb-0005xq-4d; Wed, 18 Feb 2004 21:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtddP-0005x6-9G for l3vpn@optimus.ietf.org; Wed, 18 Feb 2004 21:09:51 -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 VAA07745 for ; Wed, 18 Feb 2004 21:09:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtddM-0001lH-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 21:09:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtdcU-0001jK-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 21:08:55 -0500 Received: from noya.bupt.edu.cn ([202.112.96.2]) by ietf-mx with esmtp (Exim 4.12) id 1AtdcC-0001gh-00 for l3vpn@ietf.org; Wed, 18 Feb 2004 21:08:36 -0500 Received: from RavProxy ([202.112.101.93]) (authenticated bits=0) by noya.bupt.edu.cn (8.12.10/8.12.10) with ESMTP id i1J28KXS008889 for ; Thu, 19 Feb 2004 10:08:30 +0800 (CST) Message-ID: <029a01c3f68d$39bfab30$b302a8c0@xjli> From: "Li Xiangjun" To: Subject: End to end QoS guarantee for users in VPN Date: Thu, 19 Feb 2004 10:08:06 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0297_01C3F6D0.44CB4AF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, FROM_ENDS_IN_NUMS,MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0297_01C3F6D0.44CB4AF0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGk7DQogICAgVHJhZGl0aW9uYWxseSB3ZSBvbmx5IG1hbmFnZXMgdGhlIHRvYWwgUW9TIG9mIFZQ Ti4gSW4gZmFjdCxtYW55IHVzZXJzIGluIHRoZSBlbnRlcnByaXNlIHVzZSB0aGUgVlBOLHRoYXQg bWVhbnMgdGhlIFZQTiBjYXJyaWVzIGRpZmZlcmVudCBraW5kcyBvZiBzZXJ2aWNlcyhWb0lQLkhU VFAuVm9EIGV0IGFjLikgb2YgZGlmZmVyZW50IHVzZXJzIGluIHRoZSBlbnRlcnByaXNlLiBIb3cg dG8gYXNzdXJlIGV2ZXJ5IHVzZXIncyBRb1MsIHRoYXQgaXMgdG8gc2F5IGV2ZXJ5IGZsb3cncyBR b1MgPw0KICAgIElzIHRoZXJlIGFueSBzdWdnZXN0aW9uIGFib3V0IGl0Pw0K ------=_NextPart_000_0297_01C3F6D0.44CB4AF0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjEyNjQiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5oaTs8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgVHJhZGl0aW9uYWxseSB3ZSBv bmx5IG1hbmFnZXMgdGhlIHRvYWwgUW9TIA0Kb2YgVlBOLiBJbiBmYWN0LG1hbnkgdXNlcnMgaW4g dGhlIGVudGVycHJpc2UgdXNlIHRoZSBWUE4sdGhhdCBtZWFucyB0aGUgVlBOIA0KY2FycmllcyZu YnNwO2RpZmZlcmVudCBraW5kcyBvZiBzZXJ2aWNlcyhWb0lQLkhUVFAuVm9EIGV0IGFjLikgb2Yg ZGlmZmVyZW50IA0KdXNlcnMgaW4gdGhlIGVudGVycHJpc2UuIEhvdyB0byBhc3N1cmUgZXZlcnkg dXNlcidzIFFvUywgdGhhdCBpcyB0byBzYXkgZXZlcnkgDQpmbG93J3MgUW9TID88L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgSXMgdGhlcmUgYW55IHN1 Z2dlc3Rpb24gYWJvdXQgDQppdD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0297_01C3F6D0.44CB4AF0-- From exim@www1.ietf.org Thu Feb 19 09:33:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19944 for ; Thu, 19 Feb 2004 09:33:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpEx-0002Kd-9N for l3vpn-archive@odin.ietf.org; Thu, 19 Feb 2004 09:33:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JEXNKM008953 for l3vpn-archive@odin.ietf.org; Thu, 19 Feb 2004 09:33:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpEw-0002KK-Si for l3vpn-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 09:33:22 -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 JAA19941 for ; Thu, 19 Feb 2004 09:33:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtpEv-0007Qc-00 for l3vpn-web-archive@ietf.org; Thu, 19 Feb 2004 09:33:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtpDy-0007ND-00 for l3vpn-web-archive@ietf.org; Thu, 19 Feb 2004 09:32:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtpDe-0007Jr-00 for l3vpn-web-archive@ietf.org; Thu, 19 Feb 2004 09:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpDe-0001xd-0s; Thu, 19 Feb 2004 09:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtpCr-0001wS-VA for l3vpn@optimus.ietf.org; Thu, 19 Feb 2004 09:31:13 -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 JAA19869 for ; Thu, 19 Feb 2004 09:31:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtpCq-0007Hb-00 for l3vpn@ietf.org; Thu, 19 Feb 2004 09:31:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtpBs-0007Ek-00 for l3vpn@ietf.org; Thu, 19 Feb 2004 09:30:13 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtpB2-00078i-00 for l3vpn@ietf.org; Thu, 19 Feb 2004 09:29:20 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Feb 2004 06:37:57 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1JESk1m018607; Thu, 19 Feb 2004 06:28:47 -0800 (PST) Received: from tnadeauw2k02 (che-vpn-cluster-2-122.cisco.com [10.86.242.122]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGD94557; Thu, 19 Feb 2004 09:28:45 -0500 (EST) Reply-To: From: "Thomas D. Nadeau" To: "'Ross Callon'" , Subject: RE: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01 Date: Thu, 19 Feb 2004 09:28:25 -0500 Organization: Cisco Systems, inc. Message-ID: <001001c3f6f4$a6ef7570$6b01a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <4.3.2.20040218111818.032b8278@zircon.juniper.net> Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On > Behalf Of Ross Callon > Sent: Wednesday, February 18, 2004 12:55 PM > To: l3vpn@ietf.org > Subject: Re: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01 > > > With my "individual participant" hat on, I have a few comments, > mostly editorial, on this draft. > > - First of all, the -02 version has been published, and thus I will > comment based on draft-ietf-l3vpn-mpls-vpn-mib-02.txt. > > - The title has a dangling "Using" in it. Also, it seems that the > term "BGP/MPLS" is used more commonly than "MPLS/BGP". > Thus I believe that the title should be changed to: > > BGP/MPLS Layer 3 Virtual Private Network Management > Information Base Yup, typo. > - Second paragraph of the status section: Change "In ternet" > to "Internet". OK. > - My understanding is that this document is the MIB for "BGP/MPLS > IP VPNs" as specified in . Yes. > The abstract > seems to be not quite as precise as it could be in stating > this. How about changing the abstract to be: > > Abstract > > This memo defines an portion of the Management > Information Base (MIB) > for use with network management protocols in the > Internet community. In > particular, it describes managed objects to > configure and/or monitor > BGP/MPLS IP Layer 3 Virtual Private Networks > [reference] on a Multi- > Protocol Label Switching (MPLS) enabled Label > Switching Router (LSR) supporting this feature. OK. > This same change will also effect the first paragraph of section 2.0 > (Introduction). OK. > - In a similar vein, there are many places where the document > refers to "MPLS L3 VPNs". I would be inclined to change this to > "BGP/MPLS L3 VPNs". Hmm, I just went through and changed everything from "BGP/MPLS L3 VPNs" to "MPSL L3 VPNs" because I thought it was clearer. :( > I think that this is a bit more precise, and might > avoid confusion with any other sort of L3 VPN which makes use of MPLS > (eg, in principle one could use MPLS LSPs between VRs, which is not > in the scope of this MIB as I understand it). OK. > - The reference also needs to be updated in a couple of ways. > On the one > hand, the reference to the "BGP/MPLS IP VPNs" document is > quite out of > date (it should be to draft-ietf-l3vpn-rfc2547bis-01.txt). OK. > Also, I would expect > that at some point the "BGP/MPLS IP VPNs" document will probably be > published as an RFC, and that people will stop referring to > the approach as "2547" since there will be a different RFC number for the > approach. Thus I > would think that a reference with a pointer such as [BGP/MPLS VPNs] > would be better than [RFC2547bis]. Actually, elsewhere in the document > the reference is listed as [MPLSBGPVPN], while in the > reference section it is listed as [RFC2547bis]. OK. > - I found the second paragraph of the terminology section > confusing. It currently states: > > Throughout this document, the use of the terms > "Provider Edge (PE) and Customer Edge (CE) or PE/CE" will be replaced by > PE in all cases except when a network device is a CE when used in the > carrier of carriers model. > > To me this seems to imply that where you want to say "Provider Edge" > you will say PE, and where you want to say "Provider Edge or Customer > Edge" you will say "PE". Is this right? It seems to me that > (i) The terms > "PE" and "CE" are very standard VPN terms; and (ii) If you want to say > "provider edge or customer edge" you should say "PE or CE". Thus, I > would be inclined to delete this paragraph. Done. Less is more! *) > Also, I think that it would be > useful to add a reference to the terminology draft to the > first paragraph of the terminology section (see > ). Good point. I hadn't thought of that. > - Section 5, last bullet item, this currently states: > > - LDP paths or traffic engineered tunnels should be > configured between PEs and CEs. > > With layer 3 VPNs (whether based on BGP/MPLS VPNs or on VRs) > the LSPs are not normally set up to the CE devices. True, we should state something like: LDP paths or traffic engineered tunnels should be established between PEs, and in some cases (Carrier's carrier/inter-AS), possibly betweeen PEs and CEs. > Also, the LSPs > don't need to be manually configured, they could be set up via > signaling. We were trying to state that the LSPs (however setup) are an a priori assumption. Does the above look ok? > Also, this sentence seems to assume that if the LSPs are > set up using RSVP, then this must be for the purpose of traffic > engineering. In fact, this sentence seems to be getting to the > requirement that LSPs are set up between PE devices. So why not > say so by changing this bullet item to: > > - LSPs should be set up between PEs. Yup. See above. > - Section 6.2, mplsL3vpnIfConfTable > > This currently reads: > > This table represents the MPLS L3VPN-enabled interfaces > that are associated with a specific VRF as represented in > the aforementioned mplsL3VpnVrfTable. Each entry in this > table corresponds to an entry in the Interfaces MIB... > > There is a nit here: For the interfaces between any particular PE > and any particular CE: In general this interface will be associated > with a particular VRF. However, in general you won't be actually > running MPLS over this interface and don't need to be running > BGP over this interface. > > Thus in a sense you aren't actually > operating the BGP/MPLS L3 VPN protocols over this interface, > but are instead running "ordinary" routing stuff over this interface, > which then gets associated with the appropriate VRF. > > Thus, perhaps this paragraph should start out as: > > This table represents the interfaces that are associated > with a specific VRF (and therefore are part of a > particular VPN > being supported using BGP/MPLS L3 VPNs) as represented in > the aforementioned mplsL3VpnVrfTable. Each entry in this > table corresponds to an entry in the Interfaces MIB... I can live with that. 8) > Another question on the same paragraph: In general a PE device will > have one or more interfaces to P devices. Any one interface from PE > to P device may support multiple LSPs to other PEs, and any one > PE to PE LSP may support multiple VPNs. Thus the interface from > PE to P may in some sense be used to support multiple VPNs. Are > the PE to P interfaces included in the mplsL3VpnIfConfTable? My > understanding (which might be wrong) is that they are not. The core-facing interfaces are not included, only the CE interfaces (or ASBR ifs in the CsC case). > - A very minor nit on page 6, (part of section 8), in the > description of > MplsL3VpnName. Here you refer to the BGP/MPLS L3 VPN approach > as "MPLS/BGP VPN". In fact I have seen this written as both > "BGP/MPLS VPNs", and "MPLS/BGP VPNs". It seems to me that > it is a bit cleaner to pick one way of writing the > terminology and stick > with it, and it seems more common to put the BGP first. I agree that > this is a pretty silly nit, but it seems that it might be > slightly less confusing to be consistent (both within any one document and > between documents). I will go through and make sure things are consistent. > - I think that the reference to [VPNTCMIB] also should be updated, > although you should know better than me. Yes, I think we will straighten that out during this editing phase. There was some confusion about the naming of the MIB and so on, which I think is okay now. Thanks for the comments. --Tom > thanks, Ross > > At 01:42 PM 1/30/2004 -0500, Ronald Bonica wrote: > > >Folks, > > > >This message initiates a WG last call on > draft-ietf-l3vpn-mpls-vpn-mib-01. > >The last call will end on February 13. > > > > Ron > > > > > >-----Original Message----- > >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > >Internet-Drafts@ietf.org > >Sent: Friday, January 30, 2004 11:50 AM > >To: IETF-Announce: > >Cc: l3vpn@ietf.org > >Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-01.txt > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > >This draft is a work item of the Layer 3 Virtual Private > Networks Working > >Group of the IETF. > > > > Title : MPLS/BGP Layer 3 Virtual Private > Network Management Information > >Base Using > > Author(s) : T. Nadeau > > Filename : draft-ietf-l3vpn-mpls-vpn-mib-01.txt > > Pages : 35 > > Date : 2004-1-29 > > > From exim@www1.ietf.org Fri Feb 20 08:09:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20185 for ; Fri, 20 Feb 2004 08:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuAOp-0000B8-JA for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 08:09:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KD8xT4000665 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 08:08:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuAOp-0000A5-6k for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 08:08:59 -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 IAA20122 for ; Fri, 20 Feb 2004 08:08:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuAOn-0005hI-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 08:08:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuANn-0005ZJ-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 08:07:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuAMz-0005Vz-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 08:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuAMv-0007x6-OI; Fri, 20 Feb 2004 08:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuAMr-0007wY-2l for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 08:06:57 -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 IAA20097 for ; Fri, 20 Feb 2004 08:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuAMq-0005VN-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 08:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuALu-0005Sb-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 08:06:00 -0500 Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AuAL2-0005Lq-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 08:05:04 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i1KCxqd1015884 for ; Fri, 20 Feb 2004 08:04:24 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 402FA6F600246A4C; Fri, 20 Feb 2004 08:02:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3F7B1.EB613DDE" Subject: RE: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01 Date: Fri, 20 Feb 2004 07:03:22 -0600 Message-ID: <7AFE40EF30EE754DA967D1B5968457CA02165F85@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: yes Thread-Topic: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01 Thread-Index: AcP29TejbuRbxt+eQV+Gl13iVaIeLAAuJTag From: "Lai, Wai S (Waisum), ALABS" To: , "Ross Callon" , Cc: "Ash, Gerald R (Jerry), ALABS" , "Chung, Li-Jin W, ALABS" 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: , List-Id: List-Post: List-Help: List-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F7B1.EB613DDE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Further comments on the -02 version. As discussed in attachment 1, a new counter is proposed to provide a rough estimate of the number of dropped routes when the operator-defined VRF maximum route threshold is exceeded. The practical use of such a dropped-route counter is presented in attachment 2. It does not appear that this counter is included in the -02 version. Please clarify. Thanks, Wai Sum -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thursday, February 19, 2004 9:28 AM To: 'Ross Callon'; l3vpn@ietf.org Subject: RE: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01 > -----Original Message----- > From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org] On=20 > Behalf Of Ross Callon > Sent: Wednesday, February 18, 2004 12:55 PM > To: l3vpn@ietf.org > Subject: Re: WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01 >=20 >=20 > With my "individual participant" hat on, I have a few comments,=20 > mostly editorial, on this draft. >=20 > - First of all, the -02 version has been published, and thus I will > comment based on draft-ietf-l3vpn-mpls-vpn-mib-02.txt. >=20 > - The title has a dangling "Using" in it. Also, it seems that the > term "BGP/MPLS" is used more commonly than "MPLS/BGP". > Thus I believe that the title should be changed to: >=20 > BGP/MPLS Layer 3 Virtual Private Network Management=20 > Information Base Yup, typo. > - Second paragraph of the status section: Change "In ternet"=20 > to "Internet".=20 OK. > - My understanding is that this document is the MIB for "BGP/MPLS=20 > IP VPNs" as specified in .=20 Yes. > The abstract > seems to be not quite as precise as it could be in stating=20 > this. How about changing the abstract to be:=20 >=20 > Abstract=20 >=20 > This memo defines an portion of the Management=20 > Information Base (MIB)=20 > for use with network management protocols in the=20 > Internet community. In=20 > particular, it describes managed objects to=20 > configure and/or monitor=20 > BGP/MPLS IP Layer 3 Virtual Private Networks=20 > [reference] on a Multi- > Protocol Label Switching (MPLS) enabled Label=20 > Switching Router (LSR) supporting this feature. OK. > This same change will also effect the first paragraph of section 2.0=20 > (Introduction).=20 OK. > - In a similar vein, there are many places where the document=20 > refers to "MPLS L3 VPNs". I would be inclined to change this to=20 > "BGP/MPLS L3 VPNs".=20 Hmm, I just went through and changed everything=20 from "BGP/MPLS L3 VPNs" to "MPSL L3 VPNs" because I thought it was clearer. :( =20 > I think that this is a bit more precise, and might > avoid confusion with any other sort of L3 VPN which makes use of MPLS > (eg, in principle one could use MPLS LSPs between VRs, which is not=20 > in the scope of this MIB as I understand it).=20 OK.=09 > - The reference also needs to be updated in a couple of ways.=20 > On the one=20 > hand, the reference to the "BGP/MPLS IP VPNs" document is=20 > quite out of=20 > date (it should be to draft-ietf-l3vpn-rfc2547bis-01.txt).=20 OK. > Also, I would expect=20 > that at some point the "BGP/MPLS IP VPNs" document will probably be=20 > published as an RFC, and that people will stop referring to=20 > the approach as "2547" since there will be a different RFC number for the=20 > approach. Thus I=20 > would think that a reference with a pointer such as [BGP/MPLS VPNs]=20 > would be better than [RFC2547bis]. Actually, elsewhere in the document > the reference is listed as [MPLSBGPVPN], while in the=20 > reference section it is listed as [RFC2547bis]. OK. > - I found the second paragraph of the terminology section=20 > confusing. It currently states: >=20 > Throughout this document, the use of the terms=20 > "Provider Edge (PE) and Customer Edge (CE) or PE/CE" will be replaced by=20 > PE in all cases except when a network device is a CE when used in the=20 > carrier of carriers model. >=20 > To me this seems to imply that where you want to say "Provider Edge" > you will say PE, and where you want to say "Provider Edge or Customer > Edge" you will say "PE". Is this right? It seems to me that=20 > (i) The terms > "PE" and "CE" are very standard VPN terms; and (ii) If you want to say > "provider edge or customer edge" you should say "PE or CE". Thus, I > would be inclined to delete this paragraph.=20 Done. Less is more! *) > Also, I think that it would be > useful to add a reference to the terminology draft to the=20 > first paragraph of the terminology section (see=20 > ). Good point. I hadn't thought of that. > - Section 5, last bullet item, this currently states: >=20 > - LDP paths or traffic engineered tunnels should be=20 > configured between PEs and CEs.=20 >=20 > With layer 3 VPNs (whether based on BGP/MPLS VPNs or on VRs) > the LSPs are not normally set up to the CE devices.=20 True, we should state something like: LDP paths or traffic engineered tunnels should be=20 established between PEs, and in some cases (Carrier's=20 carrier/inter-AS), possibly betweeen PEs and CEs. > Also, the LSPs > don't need to be manually configured, they could be set up via=20 > signaling.=20 We were trying to state that the LSPs (however setup) are=20 an a priori assumption. Does the above look ok? > Also, this sentence seems to assume that if the LSPs are > set up using RSVP, then this must be for the purpose of traffic > engineering. In fact, this sentence seems to be getting to the > requirement that LSPs are set up between PE devices. So why not > say so by changing this bullet item to: >=20 > - LSPs should be set up between PEs.=20 Yup. See above. > - Section 6.2, mplsL3vpnIfConfTable >=20 > This currently reads:=20 >=20 > This table represents the MPLS L3VPN-enabled interfaces=20 > that are associated with a specific VRF as represented in=20 > the aforementioned mplsL3VpnVrfTable. Each entry in this=20 > table corresponds to an entry in the Interfaces MIB...=20 >=20 > There is a nit here: For the interfaces between any particular PE=20 > and any particular CE: In general this interface will be associated > with a particular VRF. However, in general you won't be actually > running MPLS over this interface and don't need to be running=20 > BGP over this interface.=20 >=20 > Thus in a sense you aren't actually=20 > operating the BGP/MPLS L3 VPN protocols over this interface, > but are instead running "ordinary" routing stuff over this interface, > which then gets associated with the appropriate VRF.=20 >=20 > Thus, perhaps this paragraph should start out as: >=20 > This table represents the interfaces that are associated=20 > with a specific VRF (and therefore are part of a=20 > particular VPN > being supported using BGP/MPLS L3 VPNs) as represented in=20 > the aforementioned mplsL3VpnVrfTable. Each entry in this=20 > table corresponds to an entry in the Interfaces MIB... I can live with that. 8) > Another question on the same paragraph: In general a PE device will > have one or more interfaces to P devices. Any one interface from PE > to P device may support multiple LSPs to other PEs, and any one > PE to PE LSP may support multiple VPNs. Thus the interface from=20 > PE to P may in some sense be used to support multiple VPNs. Are > the PE to P interfaces included in the mplsL3VpnIfConfTable? My=20 > understanding (which might be wrong) is that they are not.=20 The core-facing interfaces are not included, only the CE=20 interfaces (or ASBR ifs in the CsC case).=20 > - A very minor nit on page 6, (part of section 8), in the=20 > description of=20 > MplsL3VpnName. Here you refer to the BGP/MPLS L3 VPN approach > as "MPLS/BGP VPN". In fact I have seen this written as both=20 > "BGP/MPLS VPNs", and "MPLS/BGP VPNs". It seems to me that=20 > it is a bit cleaner to pick one way of writing the=20 > terminology and stick > with it, and it seems more common to put the BGP first. I agree that > this is a pretty silly nit, but it seems that it might be=20 > slightly less confusing to be consistent (both within any one document and=20 > between documents).=20 I will go through and make sure things are consistent. > - I think that the reference to [VPNTCMIB] also should be updated, > although you should know better than me.=20 Yes, I think we will straighten that out during this=20 editing phase. There was some confusion about the naming of the MIB and so on, which I think is okay now. Thanks for the comments. --Tom =20 > thanks, Ross >=20 > At 01:42 PM 1/30/2004 -0500, Ronald Bonica wrote: >=20 > >Folks, > > > >This message initiates a WG last call on=20 > draft-ietf-l3vpn-mpls-vpn-mib-01. > >The last call will end on February 13. > > > > Ron > > > > > >-----Original Message----- > >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of > >Internet-Drafts@ietf.org > >Sent: Friday, January 30, 2004 11:50 AM > >To: IETF-Announce: > >Cc: l3vpn@ietf.org > >Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-01.txt > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > >This draft is a work item of the Layer 3 Virtual Private=20 > Networks Working > >Group of the IETF. > > > > Title : MPLS/BGP Layer 3 Virtual Private=20 > Network Management Information > >Base Using > > Author(s) : T. Nadeau > > Filename : draft-ietf-l3vpn-mpls-vpn-mib-01.txt > > Pages : 35 > > Date : 2004-1-29 >=20 >=20 >=20 ------_=_NextPart_001_01C3F7B1.EB613DDE Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Received: from OCCLUST02EVS1.ugd.att.com ([135.38.164.9]) by KCCLUST06EVS1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 20 Aug 2003 09:33:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Received: from ocfe02.ugd.att.com ([135.38.164.17]) by OCCLUST02EVS1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Aug 2003 09:33:46 -0500 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by ocfe02.ugd.att.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Aug 2003 09:33:52 -0500 Received: from ckpmx2.proxy.att.com (192.168.15.105) by attrh3i.attrh.att.com (6.5.032) id 3F23F8510080D8A5; Wed, 20 Aug 2003 10:33:00 -0400 content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Date: Wed, 20 Aug 2003 06:00:00 -0600 Message-ID: <7AFE40EF30EE754DA967D1B5968457CA02165D46@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Thread-Index: AcMP2C62Vf/xmb2vROSwc7V+gBejzgACZAHAFXh+EKA= List-Help: List-Subscribe: , List-Unsubscribe: , From: "Lai, Wai S (Waisum), ALABS" To: Cc: "Ross Callon" , "Loa Andersson" , "Ron Bonica" , , "Ash, Gerald R (Jerry), ALABS" , "Chung, Li-Jin W, ALABS" Content-Transfer-Encoding: quoted-printable At the initiation of Ross Callon, a meeting was held during the IETF'57 in Vienna to discuss the VPN-MIB requirements described in the following draft http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt=20 Participants were Ross Callon, Ron Bonica, Loa Andersson, Tom Nadeau, Jerry Ash, Li-Jin Chung, and Wai Sum Lai. As a result, it was agreed that a new counter is to be added to the VPN-MIB to provide a rough estimate of the number of dropped routes when the operator-defined VRF maximum route threshold is exceeded. (see Section 3.1 of the draft). Such count is needed for capacity planning and threshold tuning purposes. It was also agreed that the RT/RD linkage in VPN-MIB (Section 3.2) is to be handled by the NMS. Comments on this are welcome. Thanks, Wai Sum -----Original Message----- From: Lai, Wai S (Waisum), ALABS=20 Sent: Thursday, May 01, 2003 9:02 AM To: ppvpn@nortelnetworks.com Subject: RE: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt Based on our testing of the VPN MIB, we have identified some requirements as described in the following draft. Your comments are welcome. Thanks, Wai Sum -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, May 01, 2003 7:48 AM Cc: mpls@uu.net; ppvpn@nortelnetworks.com Subject: I-D ACTION:draft-lai-mpls-mib-rqmts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Management Requirements for MPLS MIBs Author(s) : W. Lai, L. Chung Filename : draft-lai-mpls-mib-rqmts-00.txt Pages : 6 Date : 2003-4-30 =09 In this document, requirements for three MPLS-related MIBs (LDP-MIB,=20 VPN-MIB, and BGP4-MIB) are presented for the support of specific=20 network management needs for fault and performance management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt ------_=_NextPart_001_01C3F7B1.EB613DDE Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Received: from OCCLUST03EVS1.ugd.att.com ([135.71.164.10]) by occlust04evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 13 Nov 2002 18:53:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Received: from ocfe01.ugd.att.com ([135.71.164.16]) by OCCLUST03EVS1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 13 Nov 2002 18:53:47 -0500 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by ocfe01.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 13 Nov 2002 18:53:45 -0500 Received: from cyrus2.wsscan.att.com (135.38.12.5) by attrh0i.attrh.att.com (6.5.019) id 3DD290ED0004E20D for wlai@ems.att.com; Wed, 13 Nov 2002 18:53:46 -0500 content-class: urn:content-classes:message Subject: RE: Proposal for MPLS-VPN-MIB enhancements Date: Wed, 13 Nov 2002 17:51:30 -0600 Message-ID: <28F05913385EAC43AF019413F674A017044A33A1@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for MPLS-VPN-MIB enhancements Thread-Index: AcJJOWHMYqmE064iQgOW1cclj4ekVwA0vL+QEFjKIeA= From: "Lai, Wai S (Waisum), ALASO" To: "Thomas D. Nadeau" Cc: , "Ash, Gerald R (Jerry), ALABS" , "Chung, Li-Jin W, ALABS" , "Van der Linde, Harmen, ALABS" , "Zhang, Leah, ALABS" Content-Transfer-Encoding: quoted-printable Tom, Regarding (1) about the practical use of the dropped-route count, here are some examples: 1. Engineering of the routing table - to properly tune its size via the max threshold. 2. Understanding of customer demand for prefix routes - increase in demand could be due to growth of the business, or re-homing. Re-engineering effort might be needed if this is the case. 3. Trouble shooting and understanding the customer service impact - customer might inject too many routes due to provisioning errors.=20 4. Router resource management to optimize router performance - the overflow counts can be summerized at the per router level for forcasting and capacity planning. Regarding (2) about VRF/RD/RT association, the proposal is to associate RT with the RD index and not the VRF name index. Currently, the mplsVpnVrfRouteTargetTable table is key on the VRF name, but one VRF name could have two or more RD number assigned to it. Also, while the mplsVpnRouteTarget uses the same format as the mplsVpnRouteDistinguisher, it does not provide the RD index. An explicit association between RT and RD is needed. In this connection, I believe that some clarification of the example in "Defining the VPN," page 8, is needed. Clearly, the first "100:1" in mplsVpnVrfTable is the RD number. However, the second "100:1" in mplsVpnVrfRouteTargetTable should be the RT number and not RD number, am I correct? If this is the case, then giving the same number to RD and RT may cause ambiguity in the example. Thanks, Wai Sum. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, August 21, 2002 1:36 PM To: Lai, Wai S (Waisum), ALASO Cc: ppvpn@ppvpn.francetelecom.com Subject: Re: Proposal for MPLS-VPN-MIB enhancements >I would like to propose the following enhancements for consideration in >draft-ietf-ppvpn-mpls-vpn-mib-04: > >(1) Currently, there is the mplsNumVrfRouteMaxThreshExceeded >notification >when the VRF maximum route threshold is exceeded. It is suggested to >add >a counter for the number of routes dropped due to such threshold being >exceeded. The reporting of such a count is useful for capacity planning >and for threshold tunning purposes. What practical purpose do you see in counting routes that are not added beyond knowing that you have exceed that operator-defined threshold? >(2) In the mplsVpnVrfRouteTargetTable table, it appears that there is no >explicit mapping between the route targets (RT) and their associated >Route Distinguisher (RD). It is suggested to add such association between >VRF, RD, and RT in this table. What do you mean by an explicit mapping -- an index? The current RouteTarget table contains the associated RD for each RT entry: MplsVpnVrfRouteTargetEntry ::=3D SEQUENCE { mplsVpnVrfRouteTargetIndex Unsigned32, mplsVpnVrfRouteTargetType INTEGER, mplsVpnVrfRouteTarget MplsVpnRouteDistinguisher, mplsVpnVrfRouteTargetDescr DisplayString, mplsVpnVrfRouteTargetRowStatus RowStatus } --Tom >Comments are welcome. >Thanks, Wai Sum. ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time.=20 ------_=_NextPart_001_01C3F7B1.EB613DDE-- From exim@www1.ietf.org Fri Feb 20 11:12:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00200 for ; Fri, 20 Feb 2004 11:12:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDG0-0005Ma-76 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 11:12:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KGC4BA020610 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 11:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDG0-0005MJ-00 for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 11:12:04 -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 LAA00173 for ; Fri, 20 Feb 2004 11:12:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuDFz-0004o3-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 11:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuDF0-0004jz-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 11:11:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuDE8-0004gZ-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 11:10:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDE1-00052n-Lr; Fri, 20 Feb 2004 11:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDDF-0004ys-95 for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 11:09:13 -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 LAA00070 for ; Fri, 20 Feb 2004 11:09:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuDDC-0004c1-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 11:09:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuDCK-0004YE-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 11:08:17 -0500 Received: from av1-2-sn3.vrr.skanova.net ([81.228.9.106]) by ietf-mx with esmtp (Exim 4.12) id 1AuDBj-0004Sm-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 11:07:39 -0500 Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 3F36F37E5E; Fri, 20 Feb 2004 17:07:08 +0100 (CET) Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 242F537E5B; Fri, 20 Feb 2004 17:07:08 +0100 (CET) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with ESMTP id i1KG749n023880; Fri, 20 Feb 2004 17:07:07 +0100 (CET) Message-ID: <4036309B.1020007@pi.se> Date: Fri, 20 Feb 2004 17:06:51 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "W. Mark Townsley" Cc: Ross Callon , l3vpn@ietf.org, l2vpn@ietf.org Subject: Re: End of Last Call (Re: last call on terminology draft) References: <4.3.2.20040216154230.040f9080@zircon.juniper.net> <4033C468.8090803@cisco.com> In-Reply-To: <4033C468.8090803@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, the current 2547bis draft says "BGP/MPLS IP VPNs", I suggest that we use that term, will work it into the terminology draft. /Loa W. Mark Townsley wrote: > > Did we ever decide on the best single term for: > > RFC 2547-Style VPNs, or > BGP/MPLS VPNs, or > MPLS/BGP VPNs, or > > ...some other term? > > Thanks, > > - Mark > > Ross Callon wrote: > >> At 01:56 PM 1/20/2004 -0800, Rick Wilder wrote: >> >> >>> This begins a 2-week last-call period for >>> . >>> >>> Please let the list hear any remaining comments on this document. >>> >>> Rick >> >> >> >> The VPN Terminology Draft, , >> has now successfully completed last call. >> Ross >> >> >> > > > > -- Loa Andersson mobile +46 739 81 21 64 From exim@www1.ietf.org Fri Feb 20 13:52:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06549 for ; Fri, 20 Feb 2004 13:52:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFkp-00040I-Vp for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 13:52:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KIq3tB015386 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 13:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFkp-000405-N4 for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 13:52:03 -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 NAA06509 for ; Fri, 20 Feb 2004 13:52:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFkn-0007Vn-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 13:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFjr-0007Rh-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 13:51:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuFiw-0007Oq-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 13:50:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFis-0003QY-9m; Fri, 20 Feb 2004 13:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFhw-0003JP-Nd for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 13:49:05 -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 NAA06411 for ; Fri, 20 Feb 2004 13:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFhu-0007Ki-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 13:49:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFgx-0007Go-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 13:48:04 -0500 Received: from web21409.mail.yahoo.com ([216.136.232.79]) by ietf-mx with smtp (Exim 4.12) id 1AuFg0-0007Cn-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 13:47:04 -0500 Message-ID: <20040220184700.50690.qmail@web21409.mail.yahoo.com> Received: from [47.234.0.52] by web21409.mail.yahoo.com via HTTP; Fri, 20 Feb 2004 10:47:00 PST Date: Fri, 20 Feb 2004 10:47:00 -0800 (PST) From: Roger Pottier Subject: Re: Multi-As Backbones To: Marc Binderberger Cc: l3vpn@ietf.org, mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1916917587-1077302820=:50549" 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: , List-Id: List-Post: List-Help: List-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.1 required=5.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_A autolearn=no version=2.60 --0-1916917587-1077302820=:50549 Content-Type: text/plain; charset=us-ascii Hi, If i have "send label" configured for a BGP peer, do the peers need to be on directly connected interfaces? If it is not, how would the MPLS switches in between know about the labels? And if it is on directly connected interfaces, does it allocate a label from the interface label spaceof that interface? I guess, for carrier's Carrier case, the CEs need to be on directly connected interfaces with the PE. Thanks, Roger. Marc Binderberger wrote: Hi Roger, > As you said, this could have some scaling limitations. Does LDP assign > a label to each route learnt by the IGP. I think, LDP does not assign > labels for BGP Learnt routes. Can cisco be configured to send labels > for some BGP Learnt routes? >From a test setup. The box is a 7507 w/ 12.0(25)S1: router bgp 65017 bgp router-id 192.168.249.250 bgp cluster-id 3239121353 bgp log-neighbor-changes bgp deterministic-med bgp bestpath compare-routerid neighbor 192.168.249.17 remote-as 65018 neighbor 192.168.249.17 password 7 070D2D4D460B151015100E1E4A6465 ! address-family ipv4 redistribute isis TEST level-2 route-map ISIS-TO-BGP neighbor 192.168.249.17 activate neighbor 192.168.249.17 send-label no auto-summary no synchronization exit-address-family R1-7507#show ip bgp BGP table version is 4, local router ID is 192.168.249.250 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 192.168.249.251/32 192.168.249.46 10 32768 ? *> 192.168.17.206/32 192.168.249.17 10 0 65018 ? R1-7507#show ip bgp 192.168.17.206/32 BGP routing table entry for 192.168.17.206/32, version 4 Paths: (1 available, best #1) Not advertised to any peer 65018 192.168.249.17 from 192.168.249.17 (192.168.249.241) Origin incomplete, metric 10, localpref 100, valid, external, best, mpls labels in/out 106/18 So R1 receives label "18" via eBGP, the LDP binds local label "106". This happens even without a redistribution into the IGP. On router "R3" (belonging to AS65017): R3-7204#show mpls ldp bindings 192.168.17.206 32 detail tib entry: 192.168.17.206/32, rev 37 local binding: tag: 203 Advertised to: 192.168.249.250:0 remote binding: tsr: 192.168.249.250:0, tag: 106 BTW, with 12.2(18)S it did not work. >> Using iBGP IPv4+label - haven't tested yet as no IOS for 7600 (our PE >> plattform) was available supporting this. As I understand the theory >> this results in a packet with 3 labels minimum: the MP-BGP VPN label >> at >> the bottom, then the IPv4 next hop label and topmost the LDP label to >> the ASBR. > > The IPv4 Nexthop Label (Middle one) would be assigned by the ASBR? Yes. But let me try to get 1-2 more test boxes in the setup. Seeing is believing :-) Regards, Marc -- Marc Binderberger Powered by *BSD ;-) --------------------------------- Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. --0-1916917587-1077302820=:50549 Content-Type: text/html; charset=us-ascii
Hi,
 
 If i have "send label" configured for a BGP peer, do the peers need to be on directly
connected interfaces? If it is not, how would the MPLS switches in between know
about the labels?
And if it is on directly connected interfaces, does it allocate a label from  the interface label spaceof that interface?
 
 I guess, for carrier's Carrier case, the CEs need to be on directly connected interfaces with the PE.
 
Thanks,
Roger.

Marc Binderberger <marc@sniff.de> wrote:
Hi Roger,

> As you said, this could have some scaling limitations. Does LDP assign
> a label to each route learnt by the IGP. I think, LDP does not assign
> labels for BGP Learnt routes. Can cisco be configured to send labels
> for some BGP Learnt routes?


From a test setup. The box is a 7507 w/ 12.0(25)S1:

router bgp 65017
bgp router-id 192.168.249.250
bgp cluster-id 3239121353
bgp log-neighbor-changes
bgp deterministic-med
bgp bestpath compare-routerid
neighbor 192.168.249.17 remote-as 65018
neighbor 192.168.249.17 password 7 070D2D4D460B151015100E1E4A6465
!
address-family ipv4
redistribute isis TEST level-2 route-map ISIS-TO-BGP
neighbor 192.168.249.17 activate
neighbor 192.168.249.17 send-label
no auto-summary
no synchronization
exit-address-family


R1-7507#show ip bgpBGP table version is 4, local router ID is 192.168.249.250
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 192.168.249.251/32
192.168.249.46 10 32768 ?
*> 192.168.17.206/32
192.168.249.17 10 0 65018 ?

R1-7507#show ip bgp 192.168.17.206/32
BGP routing table entry for 192.168.17.206/32, version 4
Paths: (1 available, best #1)
Not advertised to any peer
65018
192.168.249.17 from 192.168.249.17 (192.168.249.241)
Origin incomplete, metric 10, localpref 100, valid, external,
best,
mpls labels in/out 106/18


So R1 receives label "18" via eBGP, the LDP binds local label "106".
This happens even without a redistribution into the IGP.

On router "R3" (belonging to AS65017):

R3-7204#show mpls ldp bindings 192.168.17.206 32 detail
tib entry: 192.168.17.206/3! 2, rev 37
local binding: tag: 203
Advertised to:
192.168.249.250:0
remote binding: tsr: 192.168.249.250:0, tag: 106


BTW, with 12.2(18)S it did not work.



>> Using iBGP IPv4+label - haven't tested yet as no IOS for 7600 (our PE
>> plattform) was available supporting this. As I understand the theory
>> this results in a packet with 3 labels minimum: the MP-BGP VPN label
>> at
>> the bottom, then the IPv4 next hop label and topmost the LDP label to
>> the ASBR.
>
> The IPv4 Nexthop Label (Middle one) would be assigned by the ASBR?

Yes. But let me try to get 1-2 more test boxes in the setup. Seeing is
believing :-)


Regards, Marc
--
Marc Binderberger Powered by *BSD ;-)

Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want. --0-1916917587-1077302820=:50549-- From exim@www1.ietf.org Fri Feb 20 14:15:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07461 for ; Fri, 20 Feb 2004 14:15:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG78-0006De-7t for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 14:15:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KJF6i6023900 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 14:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG78-0006DP-32 for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 14:15:06 -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 OAA07445 for ; Fri, 20 Feb 2004 14:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuG75-0001C5-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 14:15:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuG65-00017j-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 14:14:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuG57-00011g-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 14:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG57-0005oe-MI; Fri, 20 Feb 2004 14:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuG4R-0005ml-Ja for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 14:12:19 -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 OAA07188 for ; Fri, 20 Feb 2004 14:12:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuG4P-0000zh-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 14:12:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuG3P-0000vi-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 14:11:16 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AuG2s-0000rX-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 14:10:42 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i1KJAC1K021528; Fri, 20 Feb 2004 11:10:12 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i1KJACQC021525; Fri, 20 Feb 2004 11:10:12 -0800 (PST) Date: Fri, 20 Feb 2004 11:10:12 -0800 (PST) Message-Id: <200402201910.i1KJACQC021525@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Roger Pottier Cc: Marc Binderberger , l3vpn@ietf.org, mpls@UU.NET Subject: Re: Multi-As Backbones In-Reply-To: <20040220184700.50690.qmail@web21409.mail.yahoo.com> References: <20040220184700.50690.qmail@web21409.mail.yahoo.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Roger Pottier writes: > Hi, If i have "send label" configured for a BGP peer, do the peers > need to be on directly connected interfaces? While details may differ between implementations, BGP SAFI=4, which is what i assume you are refering to, does not require a directly connected interface. It can be used over a directly connected interface, in case in which it is the top label, or over a non-directly connected session, case in which the intra-area signaling protocol manages the top. > If it is not, how would > the MPLS switches in between know about the labels? link [AS1] [AS2 ] ASBR1 ---- ASBR2 --- P1 --- P2 --- PE1 ===> direction of routing advertisements asbr1 advertises 10.0.1.1/32 label 10000 via directly connected ebgp session to asbr2 asbr2 advertises 10.0.1.1/32 label 20000 via ibgp safi=4 session to PE1 PE1 needs LDP/RSVP path to asbr2, w/ hop-by-hop labels. assume P2 advertises label 30000 for the ASBR2 FEC. PE1 forwarding state: 10.1.1.1/32 push (20000, 30000).... > And if it is on > directly connected interfaces, does it allocate a label from the > interface label spaceof that interface? implementation dependent. I'm not sure that this is the question that you want to ask also... Some implementations use only a platform space but restrict allocated labels so that they can be used only in a subset of interfaces (where they are announced). You can consider this to be 'interface label space' or not. The important property is that a CoC customer interface cannot use labels which have not been assigned to him. > I guess, for carrier's Carrier case, the CEs need to be on directly > connected interfaces with the PE. That is the most common model. However the statement "need to be" is not acurate. One could configure it as a multihop session... i'm sure somebody will find a good reason why one of this days. Lots of creative people out there ;-) Pedro. From exim@www1.ietf.org Fri Feb 20 15:19:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11972 for ; Fri, 20 Feb 2004 15:19:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuH77-00058G-MY for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 15:19:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KKJ982019724 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 15:19:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuH77-000583-Ho for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 15:19:09 -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 PAA11864 for ; Fri, 20 Feb 2004 15:19:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuH76-00065b-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 15:19:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuH6C-00061W-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 15:18:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuH5L-0005xv-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 15:17:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuH54-0004XH-Ag; Fri, 20 Feb 2004 15:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuH4J-0004Jg-8u for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 15:16:15 -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 PAA11442 for ; Fri, 20 Feb 2004 15:16:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuH4I-0005sZ-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 15:16:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuH3M-0005oO-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 15:15:16 -0500 Received: from door.sniff.de ([82.212.219.2]) by ietf-mx with esmtp (Exim 4.12) id 1AuH2h-0005kq-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 15:14:36 -0500 Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id CB20F2AA0B; Fri, 20 Feb 2004 20:15:53 +0000 (GMT) In-Reply-To: <20040220184700.50690.qmail@web21409.mail.yahoo.com> References: <20040220184700.50690.qmail@web21409.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: l3vpn@ietf.org, mpls@UU.NET From: Marc Binderberger Subject: Re: Multi-As Backbones Date: Fri, 20 Feb 2004 21:18:47 +0100 To: Roger Pottier X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: quoted-printable 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Roger, > =A0If i have "send label" configured for a BGP peer, do the peers need=20= > to be on directly > connected interfaces? No other MPLS hop(s) in between, right. That's at least the "usual"=20 scenario. > If it is not, how would the=A0MPLS switches=A0in between know > about the labels? They don't know unless you configure them, e.g. by means of static=20 labels. > And if it is on directly connected interfaces, does it=A0allocate a=20 > label from =A0the interface label space of that interface? The routers I have seen use a global label pool, not per-interface. Well ... what (should) exist is an information that relates the label=20 to the interface, maybe something similar to Carrier's Carrier where=20 the label is related to the VRF the interface is part of. If this=20 information doesn't exist you cannot prevent label spoofing > =A0=A0I guess, for carrier's Carrier case, the CEs need to be on = directly=20 > connected interfaces with the PE. Same as above, when there is a label-switch device in between how does=20= it know about the labels in/out? Again for routers (the one I know) it's a global pool together with=20 information about the VRF the labels have been advertised in. Regards, Marc -- Marc Binderberger Powered by *BSD ;-) From exim@www1.ietf.org Fri Feb 20 15:37:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12838 for ; Fri, 20 Feb 2004 15:37:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHOV-0007SY-Qz for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 15:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KKb7cD028668 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 15:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHOT-0007SF-Tf for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 15:37:05 -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 PAA12820 for ; Fri, 20 Feb 2004 15:37:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHOS-0007SE-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 15:37:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHNU-0007Ol-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 15:36:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuHMW-0007L1-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 15:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHMV-00079s-OS; Fri, 20 Feb 2004 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHLc-00075g-53 for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 15:34:08 -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 PAA12696 for ; Fri, 20 Feb 2004 15:34:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHLa-0007Gg-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 15:34:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHKj-0007CI-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 15:33:13 -0500 Received: from web21406.mail.yahoo.com ([216.136.232.76]) by ietf-mx with smtp (Exim 4.12) id 1AuHJp-00078o-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 15:32:17 -0500 Message-ID: <20040220203217.37346.qmail@web21406.mail.yahoo.com> Received: from [64.221.212.137] by web21406.mail.yahoo.com via HTTP; Fri, 20 Feb 2004 12:32:17 PST Date: Fri, 20 Feb 2004 12:32:17 -0800 (PST) From: Jeff Helmer Subject: Question on nexthop/label in CsC/Multi-AS scenarios To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-990906201-1077309137=:36915" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,FROM_HAS_ULINE_NUMS, HTML_20_30,HTML_MESSAGE,HTML_TAG_BALANCE_A autolearn=no version=2.60 --0-990906201-1077309137=:36915 Content-Type: text/plain; charset=us-ascii I have a question related to setting of the nexthop/label in Carrier's Carrier or Multi-AS scenario. Consider scenario below: CsC-PE | -------------------------- | | CE1 CE2 | | --------------------------- | PE CsC-PE is in AS 100 and CE1, CE2 and PE are in AS 200. If CE1 advertised route X to CsC-PE with label L1 and CsC-PE selected the route in the VRF, when it advertises the route to CE2, does it follow the regular nexthop rules and advertise CE1 as the nexthop? If so, does it use the same label L1? Or, will CsC-PE allocate its own label and advertise itself as the nexthop to CE2? The same question arises when CE1 gets a route Y with label L2 from CsC-PE and has to advertise it to PE. Would CE1 allocate its own label and advertise itself as the nexthop to PE or would it advertise the EBGP peer (CsC-PE) as the nexthop and expect PE to have a label-switched path to CsC-PE? Is the above implementation dependent? - Jeff --------------------------------- Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. --0-990906201-1077309137=:36915 Content-Type: text/html; charset=us-ascii
I have a question related to setting of the nexthop/label in Carrier's Carrier or Multi-AS scenario. Consider scenario below:
 
        CsC-PE
            |
--------------------------
     |           |
   CE1      CE2
     |           |
---------------------------
           |
          PE
 
CsC-PE is in AS 100 and CE1, CE2 and PE are in AS 200.
 
If CE1 advertised route X to CsC-PE with label L1 and CsC-PE selected the route in the VRF, when it advertises the route to CE2, does it follow the regular nexthop rules and advertise CE1 as the nexthop? If so, does it use the same label L1? Or, will CsC-PE allocate its own label and advertise itself as the nexthop to CE2?
 
The same question arises when CE1 gets a route Y with label L2 from CsC-PE and has to advertise it to PE. Would CE1 allocate its own label and advertise itself as the nexthop to PE or would it advertise the EBGP peer (CsC-PE) as the nexthop and expect PE to have a label-switched path to CsC-PE?
 
Is the above implementation dependent?
 
- Jeff
 

Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want. --0-990906201-1077309137=:36915-- From exim@www1.ietf.org Fri Feb 20 16:49:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16707 for ; Fri, 20 Feb 2004 16:49:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuIWD-00073k-LL for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 16:49:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KLn9SW027130 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 16:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuIWD-00073V-GQ for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 16:49:09 -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 QAA16672 for ; Fri, 20 Feb 2004 16:49:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuIWB-0005tw-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 16:49:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuIVC-0005qn-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 16:48:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuIUE-0005nQ-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 16:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuIU9-0006Ym-Cl; Fri, 20 Feb 2004 16:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuITK-0006Y8-Ol for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 16:46:10 -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 QAA16593 for ; Fri, 20 Feb 2004 16:46:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuITI-0005kS-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 16:46:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuISO-0005hd-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 16:45:13 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AuIRg-0005bw-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 16:44:29 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i1KLhx1K021760; Fri, 20 Feb 2004 13:43:59 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i1KLhxPU021757; Fri, 20 Feb 2004 13:43:59 -0800 (PST) Date: Fri, 20 Feb 2004 13:43:59 -0800 (PST) Message-Id: <200402202143.i1KLhxPU021757@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jeff Helmer Cc: l3vpn@ietf.org Subject: Question on nexthop/label in CsC/Multi-AS scenarios In-Reply-To: <20040220203217.37346.qmail@web21406.mail.yahoo.com> References: <20040220203217.37346.qmail@web21406.mail.yahoo.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I have a question related to setting of the nexthop/label in Carrier's Carrier or Multi-AS scenario. Consider scenario below: > CsC-PE > | > -------------------------- > | | > CE1 CE2 > | | > --------------------------- > | > PE > > CsC-PE is in AS 100 and CE1, CE2 and PE are in AS 200. > > If CE1 advertised route X to CsC-PE with label L1 and CsC-PE > selected the route in the VRF, when it advertises the route to CE2, > does it follow the regular nexthop rules and advertise CE1 as the > nexthop? In a multi-access link (e.g. shared ether segment), it should, imho... If these are two different links it cannot. > If so, does it use the same label L1? assuming shared link scenario, yes. Labels are next-hop specific. Whenever the nexthop is changed the label must change (and stiching state is created). A router cannot change the label and not the next-hop... i.e. it can't assign a label in behalf of somebody else. > Or, will CsC-PE allocate its own label and advertise itself as the nexthop to CE2? If the 3rd party next-hop check fails (!= links) or nexthop self is configured, that would be the case. As with unlabeled BGP. > > The same question arises when CE1 gets a route Y with label L2 from > CsC-PE and has to advertise it to PE. Would CE1 allocate its own label > and advertise itself as the nexthop CE1 is most likely doing next-hop self given that there is typically the assumption that label signaling doesn't extend to the inter-provider link... > to PE or would it advertise the EBGP peer (CsC-PE) as the nexthop > and expect PE to have a label-switched path to CsC-PE? That typically doesn't happen... you could however configure a system that way. > Is the above implementation dependent? The defaults in terms of next-hop self config are implementation dependent. The behaviour of allocating labels when next-hop changes is a property of mpls. Whether you have label FECs for the address of the peer is a network design decision. Pedro. From exim@www1.ietf.org Fri Feb 20 17:32:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18347 for ; Fri, 20 Feb 2004 17:32:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJC3-0002SL-4t for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 17:32:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KMWNG1009440 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 17:32:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJC2-0002SB-RK for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 17:32:22 -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 RAA18344 for ; Fri, 20 Feb 2004 17:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuJC0-00010y-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 17:32:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuJBB-0000xM-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 17:31:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuJAl-0000sU-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 17:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJAl-0002BN-AL; Fri, 20 Feb 2004 17:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJAE-0002A8-UL for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 17:30:30 -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 RAA18228 for ; Fri, 20 Feb 2004 17:30:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuJAC-0000rT-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 17:30:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuJ9C-0000m6-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 17:29:27 -0500 Received: from web21411.mail.yahoo.com ([216.136.232.80]) by ietf-mx with smtp (Exim 4.12) id 1AuJ8d-0000hG-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 17:28:52 -0500 Message-ID: <20040220222851.57303.qmail@web21411.mail.yahoo.com> Received: from [64.221.212.137] by web21411.mail.yahoo.com via HTTP; Fri, 20 Feb 2004 14:28:51 PST Date: Fri, 20 Feb 2004 14:28:51 -0800 (PST) From: Jeff Helmer Subject: Re: Question on nexthop/label in CsC/Multi-AS scenarios To: Pedro Roque Marques Cc: l3vpn@ietf.org In-Reply-To: <200402202143.i1KLhxPU021757@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-945910521-1077316131=:56811" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,FROM_HAS_ULINE_NUMS, HTML_MESSAGE autolearn=no version=2.60 --0-945910521-1077316131=:56811 Content-Type: text/plain; charset=us-ascii Pedro, Thanks for your response. The summary I understood is that the rules for setting the nexthop are roughly the same for both unlabeled IPv4 and labeled IPv4 route exchange. The possible exception is when advertising route learnt from EBGP to IBGP peers - if sending labels with the route, it appears best to set the nexthop to self (with appropriate label allocation and stitching). I have a similar question related to Multi-AS 10(c) scenario. Consider the diagram below where the multihop EBGP VPN peering is between PEx and PEy. If PEx learns of route Rd1:X from PEy, should it set the nexthop to self or not before advertising to PE1? If it set nexthop to self, the PE1 may be unnecessarily sending the packet to PEx instead of directly sending towards PEy in the adjacent AS. -- PE1 -- P --- ASBR1 ---- ASBR2 -- P -- PE2 | | | | PEx PEy If PEx were to pass the VPN route with nexthop unchanged, how will Multi-AS scenario 10(b) work? It appears PEx needs a default behavior (e.g., next-hop-self) and user configuration is needed for one of the two scenarios. Am I totally off the mark? - Jeff Pedro Roque Marques wrote: > I have a question related to setting of the nexthop/label in Carrier's Carrier or Multi-AS scenario. Consider scenario below: > CsC-PE > | > -------------------------- > | | > CE1 CE2 > | | > --------------------------- > | > PE > > CsC-PE is in AS 100 and CE1, CE2 and PE are in AS 200. > > If CE1 advertised route X to CsC-PE with label L1 and CsC-PE > selected the route in the VRF, when it advertises the route to CE2, > does it follow the regular nexthop rules and advertise CE1 as the > nexthop? In a multi-access link (e.g. shared ether segment), it should, imho... If these are two different links it cannot. > If so, does it use the same label L1? assuming shared link scenario, yes. Labels are next-hop specific. Whenever the nexthop is changed the label must change (and stiching state is created). A router cannot change the label and not the next-hop... i.e. it can't assign a label in behalf of somebody else. > Or, will CsC-PE allocate its own label and advertise itself as the nexthop to CE2? If the 3rd party next-hop check fails (!= links) or nexthop self is configured, that would be the case. As with unlabeled BGP. > > The same question arises when CE1 gets a route Y with label L2 from > CsC-PE and has to advertise it to PE. Would CE1 allocate its own label > and advertise itself as the nexthop CE1 is most likely doing next-hop self given that there is typically the assumption that label signaling doesn't extend to the inter-provider link... > to PE or would it advertise the EBGP peer (CsC-PE) as the nexthop > and expect PE to have a label-switched path to CsC-PE? That typically doesn't happen... you could however configure a system that way. > Is the above implementation dependent? The defaults in terms of next-hop self config are implementation dependent. The behaviour of allocating labels when next-hop changes is a property of mpls. Whether you have label FECs for the address of the peer is a network design decision. Pedro. --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! --0-945910521-1077316131=:56811 Content-Type: text/html; charset=us-ascii
Pedro,
 
Thanks for your response. The summary I understood is that the rules for setting the nexthop are roughly the same for both unlabeled IPv4 and labeled IPv4 route exchange. The possible exception is when advertising route learnt from EBGP to IBGP peers - if sending labels with the route, it appears best to set the nexthop to self (with appropriate label allocation and stitching).
 
I have a similar question related to Multi-AS 10(c) scenario.
 
Consider the diagram below where the multihop EBGP VPN peering is between PEx and PEy. If PEx learns of route Rd1:X from PEy, should it set the nexthop to self or not before advertising to PE1? If it set nexthop to self, the PE1 may be unnecessarily sending the packet to PEx instead of directly sending towards PEy in the adjacent AS.
 
 
-- PE1 -- P --- ASBR1 ---- ASBR2 -- P -- PE2
          |                         |
          |                         |
         PEx                        PEy
 
If PEx were to pass the VPN route with nexthop unchanged, how will Multi-AS scenario 10(b) work? It appears PEx needs a default behavior (e.g., next-hop-self) and user configuration is needed for one of the two scenarios. Am I totally off the mark?
 
- Jeff

Pedro Roque Marques <roque@juniper.net> wrote:

> I have a question related to setting of the nexthop/label in Carrier's Carrier or Multi-AS scenario. Consider scenario below:
> CsC-PE
> |
> --------------------------
> | |
> CE1 CE2
> | |
> ---------------------------
> |
> PE
>
> CsC-PE is in AS 100 and CE1, CE2 and PE are in AS 200.
>
> If CE1 advertised route X to CsC-PE with label L1 and CsC-PE
> selected the route in the VRF, when it advertises the route to CE2,
> does it follow the regular nexthop rules and advertise CE1 as the
> nexthop?

In a multi-access link (e.g. shared ether segment), it should, imho...
If these are two different links it cannot.

> If so, does it use the same label L1?
assuming shared link scenario, yes.

Labels are next-hop specific.

Whenever the nexthop! is changed the label must change (and stiching
state is created). A router cannot change the label and not the
next-hop... i.e. it can't assign a label in behalf of somebody else.

> Or, will CsC-PE allocate its own label and advertise itself as the nexthop to CE2?

If the 3rd party next-hop check fails (!= links) or nexthop self is
configured, that would be the case. As with unlabeled BGP.

>
> The same question arises when CE1 gets a route Y with label L2 from
> CsC-PE and has to advertise it to PE. Would CE1 allocate its own label
> and advertise itself as the nexthop

CE1 is most likely doing next-hop self given that there is typically
the assumption that label signaling doesn't extend to the
inter-provider link...

> to PE or would it advertise the EBGP peer (CsC-PE) as the nexthop
> and expect PE to have a label-switched path to CsC-PE?

That typically doesn't happen... you could however configure a system
that way.

> Is the above implementation dependent?

The defaults in terms of next-hop self config are implementation
dependent.

The behaviour of allocating labels when next-hop changes is a property
of mpls.

Whether you have label FECs for the address of the peer is a network
design decision.

Pedro.

Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it! --0-945910521-1077316131=:56811-- From exim@www1.ietf.org Fri Feb 20 17:57:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19001 for ; Fri, 20 Feb 2004 17:57:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJa8-000426-2o for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 17:57:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KMvGmx015488 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 17:57:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJa7-00041X-Su for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 17:57:15 -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 RAA18994 for ; Fri, 20 Feb 2004 17:57:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuJa5-0002SK-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 17:57:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuJZI-0002PV-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 17:56:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuJYv-0002Ld-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 17:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJYu-0003oh-UG; Fri, 20 Feb 2004 17:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJY9-0003ns-GC for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 17:55:13 -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 RAA18860 for ; Fri, 20 Feb 2004 17:55:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuJY6-0002JM-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 17:55:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuJXI-0002Gp-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 17:54:21 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AuJWj-0002Am-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 17:53:45 -0500 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i1KMrF1K021979; Fri, 20 Feb 2004 14:53:15 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i1KMrFXT021976; Fri, 20 Feb 2004 14:53:15 -0800 (PST) Date: Fri, 20 Feb 2004 14:53:15 -0800 (PST) Message-Id: <200402202253.i1KMrFXT021976@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jeff Helmer Cc: l3vpn@ietf.org Subject: Re: Question on nexthop/label in CsC/Multi-AS scenarios In-Reply-To: <20040220222851.57303.qmail@web21411.mail.yahoo.com> References: <200402202143.i1KLhxPU021757@roque-bsd.juniper.net> <20040220222851.57303.qmail@web21411.mail.yahoo.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit 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: , List-Id: List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > I have a similar question related to Multi-AS 10(c) scenario. > > Consider the diagram below where the multihop EBGP VPN peering is > between PEx and PEy. If PEx learns of route Rd1:X from PEy, should it > set the nexthop to self or not before advertising to PE1? Both options are availiable from a standards point of view. Its a design decision... Typically that decision would depend on wether PE1 has a FEC for PE2/32. If you are doing option 10 c) then one would by default configure PEx and PEy to not modify the next-hop. i.e. this would be the equivalent of iBGP RRs. > If it set > nexthop to self, the PE1 may be unnecessarily sending the packet to > PEx instead of directly sending towards PEy in the adjacent AS. > > > -- PE1 -- P --- ASBR1 ---- ASBR2 -- P -- PE2 > | | > | | > PEx PEy > > If PEx were to pass the VPN route with nexthop unchanged, how will > Multi-AS scenario 10(b) work? 10(b) assumes that the exchange of routes and traffic is being performed by the ASBRs, not PEx & y. > It appears PEx needs a default behavior > (e.g., next-hop-self) and user configuration is needed for one of the > two scenarios. Am I totally off the mark? It would be reasonable to default to next-hop for EBGP if the session is directly connected (common 10b scenario) and default not to for multihop (common 10c scenario). Implementations may not get all the nuances right ;-) Pedro. From exim@www1.ietf.org Fri Feb 20 18:53:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23323 for ; Fri, 20 Feb 2004 18:53:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKSQ-0007i6-N8 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 18:53:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KNrMVZ029632 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 18:53:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKSQ-0007hr-IA for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 18:53:22 -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 SAA23315 for ; Fri, 20 Feb 2004 18:53:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKSN-0007Pc-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 18:53:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKRT-0007MV-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 18:52:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuKR9-0007If-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 18:52:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKR7-0007V0-5z; Fri, 20 Feb 2004 18:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKQT-0007Sz-NH for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 18:51:21 -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 SAA23245 for ; Fri, 20 Feb 2004 18:51:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKQQ-0007Gt-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 18:51:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKPk-0007Dj-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 18:50:37 -0500 Received: from web21401.mail.yahoo.com ([216.136.232.71]) by ietf-mx with smtp (Exim 4.12) id 1AuKOs-00078Q-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 18:49:42 -0500 Message-ID: <20040220234938.33708.qmail@web21401.mail.yahoo.com> Received: from [64.221.212.137] by web21401.mail.yahoo.com via HTTP; Fri, 20 Feb 2004 15:49:38 PST Date: Fri, 20 Feb 2004 15:49:38 -0800 (PST) From: Jeff Helmer Subject: Re: FW: End to end QoS guarantee for users in VPN To: neil.2.harrison@bt.com Cc: l3vpn@ietf.org In-Reply-To: <20040220233646.3218.qmail@web21408.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-652043719-1077320978=:33227" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.7 required=5.0 tests=AWL,FROM_HAS_ULINE_NUMS, HTML_20_30,HTML_FONTCOLOR_RED,HTML_MESSAGE,HTML_TAG_BALANCE_A autolearn=no version=2.60 --0-652043719-1077320978=:33227 Content-Type: text/plain; charset=us-ascii Neil, I wanted to understand the phrase "traffic isolation on a per VPN basis" that you used. Do you mean per-VPN LSPs (without any merging) between the PE routers (assuming a MPLS core)? This would ensure each VPN has a guaranteed end-to-end bandwidth which may not be possible if all VPNs between a pair of PE routers used the same tunnel LSP. The DS codepoint would then signify the relative importance of different kinds of traffic in the same VPN. - Jeff Jeff Helmer wrote: -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Li Xiangjun Sent: 19 February 2004 02:08 To: l3vpn@ietf.org Subject: End to end QoS guarantee for users in VPN hi; Traditionally we only manages the toal QoS of VPN. In fact,many users in the enterprise use the VPN,that means the VPN carries different kinds of services(VoIP.HTTP.VoD et ac.) of different users in the enterprise. How to assure every user's QoS, that is to say every flow's QoS ? Is there any suggestion about it? Excellent question. And I agree with you. As a general observation it is not possible to differentiate 'urgency' (ie how fast?) from 'importance' (ie how critical is this pkt vs others?) from just a DS codepoint at the pkt level. One can imagine cases in 1 VPN where a given voice call is mission critical and others where it is not....same applies to data applications. Further, there is a difference between the treatment of public traffic and private traffic.....and in fact some public traffic that belongs to the same 'urgency' class can also have different 'importance'. One can use the LSP as a survivavbility differentiator, ie to isolate different VPN instances......however, this requires p2p LSPs because if the traffic gets merged on lower mp2p LSPs then per VPN QoS/perf/failure-handling behaviour is not simple to provide. The usual response to such uncertainty in these quantities is to significanly overprovide.......which is not a good solution. There are deeper issues here of pricing for 'fair/meaningful' services that, in addition to the urgency vs importance angle, is affected by BW borrowing between DS classes.....and these can't be easily sorted IMO if the network arch is unable to deliver traffic isolation on a per VPN basis. regards, Neil --------------------------------- Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. --------------------------------- Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. --0-652043719-1077320978=:33227 Content-Type: text/html; charset=us-ascii
Neil,
 
I wanted to understand the phrase "traffic isolation on a per VPN basis" that you used. Do you mean per-VPN LSPs (without any merging) between the PE routers (assuming a MPLS core)? This would ensure each VPN has a guaranteed end-to-end bandwidth which may not be possible if all VPNs between a pair of PE routers used the same tunnel LSP. The DS codepoint would then signify the relative importance of different kinds of traffic in the same VPN.
 
- Jeff

Jeff Helmer <jeff_helmer_1@yahoo.com> wrote:
-----Original Message-----
From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Li Xiangjun
Sent: 19 February 2004 02:08
To: l3vpn@ietf.org
Subject: End to end QoS guarantee for users in VPN

hi;
    Traditionally we only manages the toal QoS of VPN. In fact,many users in the enterprise use the VPN,that means the VPN carries different kinds of services(VoIP.HTTP.VoD et ac.) of different users in the enterprise. How to assure every user's QoS, that is to say every flow's QoS ?
    Is there any suggestion about it? 
Excellent question.  And I agree with you.  As a general observation it is not possible to differentiate 'urgency' (ie how fast?) from 'importance' (ie how critical is this pkt vs others?) from just a DS codepoint at the pkt level.  One can imagine cases in 1 VPN where a given voice call is mission critical and others where it is not....same applies to data applications.  Further, there is a difference between the treatment of public traffic and private traffic.....and in fact some public traffic that belongs to the same 'urgency' class can also have different 'importance'.  One can use the LSP as a survivavbility differentiator, ie to isolate different VPN instances......however, this requires p2p LSPs because if the traffic gets merged on lower mp2p LSPs then per VPN QoS/perf/failure-handling behaviour is not simple to provide. The usual response to such uncert! ainty in these quantities is to significanly overprovide.......which is not a good solution.
 
There are deeper issues here of pricing for 'fair/meaningful' services that, in addition to the urgency vs importance angle, is affected by BW borrowing between DS classes.....and these can't be easily sorted IMO if the network arch is unable to deliver traffic isolation on a per VPN basis.
 
regards, Neil
 
 

Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.

Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want. --0-652043719-1077320978=:33227-- From exim@www1.ietf.org Fri Feb 20 19:09:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24032 for ; Fri, 20 Feb 2004 19:09:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKhv-0000nD-Us for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 19:09:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L09Nud003041 for l3vpn-archive@odin.ietf.org; Fri, 20 Feb 2004 19:09:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKhv-0000my-Qb for l3vpn-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 19:09:23 -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 TAA24029 for ; Fri, 20 Feb 2004 19:09:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKhs-0000oX-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 19:09:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKh5-0000j4-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 19:08:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuKgc-0000ec-00 for l3vpn-web-archive@ietf.org; Fri, 20 Feb 2004 19:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKgc-0000en-9x; Fri, 20 Feb 2004 19:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKfu-0000Mo-Fn for l3vpn@optimus.ietf.org; Fri, 20 Feb 2004 19:07:18 -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 TAA23799 for ; Fri, 20 Feb 2004 19:07:13 -0500 (EST) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKfr-0000c3-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 19:07:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKew-0000Yj-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 19:06:19 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139] helo=i2kc05-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AuKeA-0000S9-00 for l3vpn@ietf.org; Fri, 20 Feb 2004 19:05:30 -0500 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Sat, 21 Feb 2004 00:05:01 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Sat, 21 Feb 2004 00:05:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F80E.58E1D450" Subject: RE: FW: End to end QoS guarantee for users in VPN Date: Sat, 21 Feb 2004 00:05:00 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF328D@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: FW: End to end QoS guarantee for users in VPN Thread-Index: AcP4DDimgruk/5uoThq+dZLgZIeUhAAASoeQ To: Cc: X-OriginalArrivalTime: 21 Feb 2004 00:05:00.0638 (UTC) FILETIME=[5934F7E0:01C3F80E] 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: , List-Id: List-Post: List-Help: List-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.8 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_RED,HTML_MESSAGE,HTML_TAG_BALANCE_A,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F80E.58E1D450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This needs a longish response .....so I'll get back to you off-list. =20 regards, Neil -----Original Message----- From: Jeff Helmer [mailto:jeff_helmer_1@yahoo.com] Sent: 20 February 2004 23:50 To: Harrison,N,Neil,IKR2 R Cc: l3vpn@ietf.org Subject: Re: FW: End to end QoS guarantee for users in VPN Neil, =20 I wanted to understand the phrase "traffic isolation on a per VPN basis" = that you used. Do you mean per-VPN LSPs (without any merging) between = the PE routers (assuming a MPLS core)? This would ensure each VPN has a = guaranteed end-to-end bandwidth which may not be possible if all VPNs = between a pair of PE routers used the same tunnel LSP. The DS codepoint = would then signify the relative importance of different kinds of traffic = in the same VPN. =20 - Jeff Jeff Helmer wrote: -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Li = Xiangjun Sent: 19 February 2004 02:08 To: l3vpn@ietf.org Subject: End to end QoS guarantee for users in VPN hi; Traditionally we only manages the toal QoS of VPN. In fact,many = users in the enterprise use the VPN,that means the VPN carries different = kinds of services(VoIP.HTTP.VoD et ac.) of different users in the = enterprise. How to assure every user's QoS, that is to say every flow's = QoS ? Is there any suggestion about it?=20 Excellent question. And I agree with you. As a general observation it = is not possible to differentiate 'urgency' (ie how fast?) from = 'importance' (ie how critical is this pkt vs others?) from just a DS = codepoint at the pkt level. One can imagine cases in 1 VPN where a = given voice call is mission critical and others where it is not....same = applies to data applications. Further, there is a difference between = the treatment of public traffic and private traffic.....and in fact some = public traffic that belongs to the same 'urgency' class can also have = different 'importance'. One can use the LSP as a survivavbility = differentiator, ie to isolate different VPN instances......however, this = requires p2p LSPs because if the traffic gets merged on lower mp2p LSPs = then per VPN QoS/perf/failure-handling behaviour is not simple to = provide. The usual response to such uncertainty in these quantities is = to significanly overprovide.......which is not a good solution. =20 There are deeper issues here of pricing for 'fair/meaningful' services = that, in addition to the urgency vs importance angle, is affected by BW = borrowing between DS classes.....and these can't be easily sorted IMO if = the network arch is unable to deliver traffic isolation on a per VPN = basis. =20 regards, Neil =20 =20 _____ =20 Do you Yahoo!? Yahoo! = Mail SpamGuard - Read only the mail you want. _____ =20 Do you Yahoo!? Yahoo! = Mail SpamGuard - Read only the mail you want. ------_=_NextPart_001_01C3F80E.58E1D450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This needs a longish response .....so I'll = get back to=20 you off-list.
 
regards, Neil
-----Original Message-----
From: Jeff Helmer=20 [mailto:jeff_helmer_1@yahoo.com]
Sent: 20 February 2004=20 23:50
To: Harrison,N,Neil,IKR2 R
Cc:=20 l3vpn@ietf.org
Subject: Re: FW: End to end QoS guarantee for = users=20 in VPN

Neil,
 
I wanted to understand the phrase "traffic isolation on a per VPN = basis"=20 that you used. Do you mean per-VPN LSPs (without any merging) between = the PE=20 routers (assuming a MPLS core)? This would ensure each VPN has a = guaranteed=20 end-to-end bandwidth which may not be possible if all VPNs between a = pair of=20 PE routers used the same tunnel LSP. The DS codepoint would then = signify the=20 relative importance of different kinds of traffic in the same = VPN.
 
- Jeff

Jeff Helmer = <jeff_helmer_1@yahoo.com>=20 wrote:
-----Original Message-----
From: = l3vpn-admin@ietf.org=20 [mailto:l3vpn-admin@ietf.org]On Behalf Of Li=20 Xiangjun
Sent: 19 February 2004 02:08
To:=20 l3vpn@ietf.org
Subject: End to end QoS guarantee for = users in=20 VPN

hi;
    Traditionally we only = manages the=20 toal QoS of VPN. In fact,many users in the enterprise use the = VPN,that=20 means the VPN carries different kinds of = services(VoIP.HTTP.VoD et=20 ac.) of different users in the enterprise. How to assure every = user's QoS,=20 that is to say every flow's QoS ?
    Is there any suggestion = about=20 it? 
Excellent question.  And I agree = with=20 you.  As a general observation it is not possible to = differentiate=20 'urgency' (ie how fast?) from 'importance' (ie how critical is = this pkt vs=20 others?) from just a DS codepoint at the pkt level.  One can = imagine=20 cases in 1 VPN where a given voice call is mission critical and = others=20 where it is not....same applies to data applications.  = Further, there=20 is a difference between the treatment of public traffic and = private=20 traffic.....and in fact some public traffic that belongs to the = same=20 'urgency' class can also have different 'importance'.  One = can use=20 the LSP as a survivavbility differentiator, ie to isolate = different VPN=20 instances......however, this requires p2p LSPs because if the = traffic gets=20 merged on lower mp2p LSPs then per VPN = QoS/perf/failure-handling=20 behaviour is not simple to provide. The usual response to such = uncertainty=20 in these quantities is to significanly overprovide.......which is = not a=20 good solution.
 
There are deeper issues here of pricing = for=20 'fair/meaningful' services that, in addition to the urgency vs = importance=20 angle, is affected by BW borrowing between DS classes.....and = these=20 can't be easily sorted IMO if the network arch is unable to = deliver=20 traffic isolation on a per VPN basis.
 
regards,=20 Neil
 
 

Do you Yahoo!?
Yahoo!=20 Mail SpamGuard - Read only the mail you want.

Do you Yahoo!?
Yahoo!=20 Mail SpamGuard - Read only the mail you = want. ------_=_NextPart_001_01C3F80E.58E1D450-- From exim@www1.ietf.org Sun Feb 22 22:12:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21118 for ; Sun, 22 Feb 2004 22:12:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6Vf-0007hD-8n for l3vpn-archive@odin.ietf.org; Sun, 22 Feb 2004 22:11:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N3Bt2A029579 for l3vpn-archive@odin.ietf.org; Sun, 22 Feb 2004 22:11:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6Vf-0007h0-0j for l3vpn-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 22:11: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 WAA21072 for ; Sun, 22 Feb 2004 22:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av6Vb-0001Sf-00 for l3vpn-web-archive@ietf.org; Sun, 22 Feb 2004 22:11:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av6Ug-0001Pg-00 for l3vpn-web-archive@ietf.org; Sun, 22 Feb 2004 22:10:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Av6Ts-0001Mk-00 for l3vpn-web-archive@ietf.org; Sun, 22 Feb 2004 22:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6Tr-0007bc-1s; Sun, 22 Feb 2004 22:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av6Tm-0007al-0W for l3vpn@optimus.ietf.org; Sun, 22 Feb 2004 22:09:58 -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 WAA20963 for ; Sun, 22 Feb 2004 22:09:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av6Ti-0001Lx-00 for l3vpn@ietf.org; Sun, 22 Feb 2004 22:09:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av6Sp-0001JK-00 for l3vpn@ietf.org; Sun, 22 Feb 2004 22:09:00 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1Av6SU-0001Fd-00 for l3vpn@ietf.org; Sun, 22 Feb 2004 22:08:38 -0500 Received: from chrlewis-w2k02.cisco.com (sjc-vpn4-450.cisco.com [10.21.81.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i1N385cx014618; Sun, 22 Feb 2004 19:08:05 -0800 (PST) Message-Id: <4.3.2.7.2.20040222204934.02b7c400@fargo.cisco.com> X-Sender: chrlewis@fargo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 22 Feb 2004 21:08:04 -0600 To: neil.2.harrison@bt.com From: Chris Lewis Subject: End to end QoS guarantee for users in VPN Cc: l3vpn@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3041603==_.ALT" 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: , List-Id: List-Post: List-Help: List-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.1 required=5.0 tests=AWL,HTML_FONTCOLOR_RED, HTML_MESSAGE autolearn=no version=2.60 --=====================_3041603==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Neil, I understand that this may be a longish discussion, but would you be prepared to engage on a couple of points from this topic on the alias? The couple of points I'm interested in hearing more from you on are; 1. The need for over-provisioning to ensure end to end QoS, which you (correctly IMHO) identify as not a good solution 2. The need for per VPN QoS On the first one, Steven Casner in NANAOG 22 presented a nice study of a tier 1 backbone that showed that for pretty much all of the time, if there was twice the bandwidth available than offered load, there was never congestion/delay/jitter, even under failures. This does of course trade off the cost of bandwidth with a simple network planning model. The downsides however do include cost, unexpected shifts in traffic, provisioning failures, internet traffic affecting VoIP and so forth. One proposal is to over provision (or under provision) on a per class basis, so that say the controlled latency class has 2 times the bandwidth available when compared to the offered load, however the best effort class may be under provisioned and not get all it needs in times of congestion. The obvious benefit here is that the cost of over-provisioning is lowered and is only done for the classes that really need it. This leads on to point 2, while it is true to say it is impossible to come up with a portable definition of what is mission critical and what is not for an enterprise, it is possible to identify different levels of service within a provider VPN that the enterprise can match its traffic to, such as voice requiring 150 ms end to end delay, or a transaction program requiring X hundred msecs of delay, or a file transfer requiring Y Mbps. So is it not feasible to suggest that a provider can offer these different service types, then knowing what has been subscribed to, engineer a network for the aggregate, meaning that it is known that X hundred Mbps of voice transport has been sold, and therefore 2X is provisioned in the network? If this then meant that all voice traffic was treated properly, there would be no need for per VPN QoS to support voice. The same could then be true of other traffic classes (even though those other classes would have different under or over provisioning ratios). Cheers Chris This needs a longish response .....so I'll get back to you off-list. regards, Neil -----Original Message----- From: Jeff Helmer [mailto:jeff_helmer_1@yahoo.com] Sent: 20 February 2004 23:50 To: Harrison,N,Neil,IKR2 R Cc: l3vpn@ietf.org Subject: Re: FW: End to end QoS guarantee for users in VPN Neil, I wanted to understand the phrase "traffic isolation on a per VPN basis" that you used. Do you mean per-VPN LSPs (without any merging) between the PE routers (assuming a MPLS core)? This would ensure each VPN has a guaranteed end-to-end bandwidth which may not be possible if all VPNs between a pair of PE routers used the same tunnel LSP. The DS codepoint would then signify the relative importance of different kinds of traffic in the same VPN. - Jeff Jeff Helmer wrote: -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Li Xiangjun Sent: 19 February 2004 02:08 To: l3vpn@ietf.org Subject: End to end QoS guarantee for users in VPN hi; Traditionally we only manages the toal QoS of VPN. In fact,many users in the enterprise use the VPN,that means the VPN carries different kinds of services(VoIP.HTTP.VoD et ac.) of different users in the enterprise. How to assure every user's QoS, that is to say every flow's QoS ? Is there any suggestion about it? Excellent question. And I agree with you. As a general observation it is not possible to differentiate 'urgency' (ie how fast?) from 'importance' (ie how critical is this pkt vs others?) from just a DS codepoint at the pkt level. One can imagine cases in 1 VPN where a given voice call is mission critical and others where it is not....same applies to data applications. Further, there is a difference between the treatment of public traffic and private traffic.....and in fact some public traffic that belongs to the same 'urgency' class can also have different 'importance'. One can use the LSP as a survivavbility differentiator, ie to isolate different VPN instances......however, this requires p2p LSPs because if the traffic gets merged on lower mp2p LSPs then per VPN QoS/perf/failure-handling behaviour is not simple to provide. The usual response to such uncertainty in these quantities is to significanly overprovide.......which is not a good solution. There are deeper issues here of pricing for 'fair/meaningful' services that, in addition to the urgency vs importance angle, is affected by BW borrowing between DS classes.....and these can't be easily sorted IMO if the network arch is unable to deliver traffic isolation on a per VPN basis. regards, Neil --=====================_3041603==_.ALT Content-Type: text/html; charset="us-ascii" Neil,

I understand that this may be a longish discussion, but would you be prepared to engage on a couple of points from this topic on the alias?

The couple of points I'm interested in hearing more from you on are;

1. The need for over-provisioning to ensure end to end QoS, which you (correctly IMHO) identify as not a good solution
2. The need for per VPN QoS

On the first one, Steven Casner in NANAOG 22 presented a nice study of a tier 1 backbone that showed that for pretty much all of the time, if there was twice the bandwidth available than offered load, there was never congestion/delay/jitter, even under failures. This does of course trade off the cost of bandwidth with a simple network planning model. The downsides however do include cost, unexpected shifts in traffic, provisioning failures, internet traffic affecting VoIP and so forth. One proposal is to over provision (or under provision) on a per class basis, so that say the controlled latency class has 2 times the bandwidth available when compared to the offered load, however the best effort class may be under provisioned and not get all it needs in times of congestion. The obvious benefit here is that the cost of over-provisioning is lowered and is only done for the classes that really need it.

This leads on to point 2, while it is true to say it is impossible to come up with a portable definition of what is mission critical and what is not for an enterprise, it is possible to identify different levels of service within a provider VPN that the enterprise can match its traffic to, such as voice requiring 150 ms end to end delay, or a transaction program requiring X hundred msecs of delay, or a file transfer requiring Y Mbps.

So is it not feasible to suggest that a provider can offer these different service types, then knowing what has been subscribed to, engineer a network for the aggregate, meaning that it is known that X hundred Mbps of voice transport has been sold, and therefore 2X is provisioned in the network? If this then meant that all voice traffic was treated properly, there would be no need for per VPN QoS to support voice. The same could then be true of other traffic classes (even though those other classes would have different under or over provisioning ratios).

Cheers

Chris

This needs a longish response .....so I'll get back to you off-list.
regards, Neil
-----Original Message-----
From: Jeff Helmer [mailto:jeff_helmer_1@yahoo.com]
Sent: 20 February 2004 23:50
To: Harrison,N,Neil,IKR2 R
Cc: l3vpn@ietf.org
Subject: Re: FW: End to end QoS guarantee for users in VPN

Neil,
I wanted to understand the phrase "traffic isolation on a per VPN basis" that you used. Do you mean per-VPN LSPs (without any merging) between the PE routers (assuming a MPLS core)? This would ensure each VPN has a guaranteed end-to-end bandwidth which may not be possible if all VPNs between a pair of PE routers used the same tunnel LSP. The DS codepoint would then signify the relative importance of different kinds of traffic in the same VPN.
- Jeff

Jeff Helmer <jeff_helmer_1@yahoo.com> wrote:
-----Original Message-----
From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Li Xiangjun
Sent: 19 February 2004 02:08
To: l3vpn@ietf.org
Subject: End to end QoS guarantee for users in VPN

hi;
Traditionally we only manages the toal QoS of VPN. In fact,many users in the enterprise use the VPN,that means the VPN carries different kinds of services(VoIP.HTTP.VoD et ac.) of different users in the enterprise. How to assure every user's QoS, that is to say every flow's QoS ?
Is there any suggestion about it?
Excellent question. And I agree with you. As a general observation it is not possible to differentiate 'urgency' (ie how fast?) from 'importance' (ie how critical is this pkt vs others?) from just a DS codepoint at the pkt level. One can imagine cases in 1 VPN where a given voice call is mission critical and others where it is not....same applies to data applications. Further, there is a difference between the treatment of public traffic and private traffic.....and in fact some public traffic that belongs to the same 'urgency' class can also have different 'importance'. One can use the LSP as a survivavbility differentiator, ie to isolate different VPN instances......however, this requires p2p LSPs because if the traffic gets merged on lower mp2p LSPs then per VPN QoS/perf/failure-handling behaviour is not simple to provide. The usual response to such uncertainty in these quantities is to significanly overprovide.......which is not a good solution.
There are deeper issues here of pricing for 'fair/meaningful' services that, in addition to the urgency vs importance angle, is affected by BW borrowing between DS classes.....and these can't be easily sorted IMO if the network arch is unable to deliver traffic isolation on a per VPN basis.
regards, Neil
 --=====================_3041603==_.ALT-- From exim@www1.ietf.org Tue Feb 24 22:26:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24252 for ; Tue, 24 Feb 2004 22:26:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avpgp-0004uI-Fm for l3vpn-archive@odin.ietf.org; Tue, 24 Feb 2004 22:26:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P3QRlo018858 for l3vpn-archive@odin.ietf.org; Tue, 24 Feb 2004 22:26:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avpgp-0004u5-9v for l3vpn-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 22:26:27 -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 WAA24237 for ; Tue, 24 Feb 2004 22:26:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avpgm-0002Fr-00 for l3vpn-web-archive@ietf.org; Tue, 24 Feb 2004 22:26:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avpfo-0002B1-00 for l3vpn-web-archive@ietf.org; Tue, 24 Feb 2004 22:25:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avper-00026x-00 for l3vpn-web-archive@ietf.org; Tue, 24 Feb 2004 22:24:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvpeS-0004o2-Tk; Tue, 24 Feb 2004 22:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avpdw-0004nW-J2 for l3vpn@optimus.ietf.org; Tue, 24 Feb 2004 22:23:28 -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 WAA24185 for ; Tue, 24 Feb 2004 22:23:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avpdt-000224-00 for l3vpn@ietf.org; Tue, 24 Feb 2004 22:23:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avpcy-0001yJ-00 for l3vpn@ietf.org; Tue, 24 Feb 2004 22:22:29 -0500 Received: from noya.bupt.edu.cn ([202.112.96.2]) by ietf-mx with esmtp (Exim 4.12) id 1Avpcl-0001uO-00 for l3vpn@ietf.org; Tue, 24 Feb 2004 22:22:15 -0500 Received: from RavProxy ([202.112.101.118]) (authenticated bits=0) by noya.bupt.edu.cn (8.12.10/8.12.10) with ESMTP id i1P3LuXS026230 for ; Wed, 25 Feb 2004 11:22:07 +0800 (CST) Message-ID: <00d201c3fb4e$74b90810$b302a8c0@xjli> From: "Li Xiangjun" To: Subject: Fw: End to end QoS guarantee for users in VPN Date: Wed, 25 Feb 2004 11:21:22 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01C3FB91.7FC4A7D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, FROM_ENDS_IN_NUMS,MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01C3FB91.7FC4A7D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 ICAgIFNlcnZpY2UgTGV2ZWwgQWdyZWVtZW50IGFib3V0IFZQTiBiZXR3ZWVuIGVudGVycHJpc2Ug YW5kIFNlcnZpY2UgUHJvdmlkZXIgbWF5YmUgaXMgYXMgZm9sbG93aW5nKEkgdGhpbmsgZW50ZXJw cmlzZSBjdXN0b21lciBkbyBuZWVkIHRoZXNlIHJlcXVpcmVtZW50cyk6IA0KICAgIFZQTiBTZXJ2 aWNlIFNMQShhbiBFeGFtcGxlKToNCnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHBlcmZvcm1hbmNlIHBhcmFtZXRlcnMgJiB0YXJnZXQgdmFsdWUNCnwgICAgICAgICAgICBB cHBsaWNhdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBEYXRhIFJhdGVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQp8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIERlbGF5ICAgICAgIEppdHRlciAgICAgUGFja2V0IExvc3MgUmF0aW8NCnwtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCnwgICAgICAgICAgICBUb3RhbCBRb1MgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMiBNDQp8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWluIFNlc3Npb24gTnVtICBNYXggU2Vz c2lvbiBOdW0gICBQZXJTZXNzaW9uIFJlcXVpcmVtZW50DQp8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQp8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWb0lQICAgICAgICAgICAgICAgIDEwICAgICAg ICAgICAgICAgICAgICAgICAgNTAgICAgICAgICAgICAgICAgICAgICAgICAgMTAgS2JpdC9zICAg ICAgICAgICAgICAgIDwgMTUwbXMgICAgICAgICAgPCAxbXMgICAgICAgIDwgMyUNCnwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KfCAgUmVzdHJpY3Rpb24gICAgICAgICAgICAgIFZvRCAgICAg ICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgICAgICAgIDUgICAgICAgICAgICAgICAg ICAgICAgICAgIDIwMEtiaXQvcyAgICAgICAgICAgICAgICA8MTBtcyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPDElDQp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVzdCBFZmZvcnQgICBNaW4gVG90YWwgIDUw MEsNCnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpCZXN0IEVmZm9ydCdzIHByaW9yaXR5IGlzIHRoZSBsb3dl c3QgYW5kIG90aGVycyBjYW4gcHJlZW1wdCBpdCdzIGJhbmR3aWR0aC4NCg0KICAgIFRoZSBxdWVz dGlvbiBpcyBob3cgdG8gZ3VhcmFudGVlIGVhY2ggc2Vzc2lvbidzIFFvUywgbm90IGVhY2ggY2xh c3MuIEV2ZW4gdGhvdWdoIGVhY2ggY2xhc3MnIFFvcyBjYW4gYmUgZ3VhcmFudGVlZCwgZm9yIGVh Y2ggc2Vzc2lvbiAsbWF5YmUgaXQncyBiYWQgb25lLg0KICAgIEZvciBleGFtcGxlLCAxIE0gYmFu ZHdpZHRoIGlzIGFsbG9jYXRlZCB0byBWb0QgY2xhc3Mgc2VydmljZSBhYnNvbHV0ZWx5LCB0aGF0 IGlzIG1lYW4sIDUgc2Vzc2lvbnMnIFFvUyBjYW4gYmUgZ3VhcmFudGVlZC4gSWYgMTAgcGVyc29u cyhtYXliZSBtb3JlKSBpbiB0aGUgZW50ZXJwcmlzZSByZXF1ZXN0IFZvRCBzZXJ2aWNlIGNvbmN1 cnJlbnRseSwgaWYgbm8gcmVzb3VyY2UgY29udHJvbCBlbnRpdHkgZXhpc3RzIGFuZCBhbGwgdGhl IHJlcXVlc3QgYXJlIHRyZWF0ZWQgZmFpcmx5LCB0aGVuIDEwIFZvRCBzZXNzaW9uIG1heWJlIGV4 aXN0IGFuZCBlYWNoIGhhcyBiYWQgUW9TLiBUaGUgcG9pbnQgaXMgdGhhdCA1IFZvRCBzZXNzaW9u cycgUW9TIGNhbiBiZSBndWFyYW50ZWVkIGlmIG90aGVycyA1IHJlcXVlc3QgYXJlIG5vdCBhbGxv d2VkLiANCiAgICBJZiBhIGNhbGwgYWRtaXNzaW9uIGNvbnRyb2wgZW50aXR5IGV4aXN0cywgYnV0 IGZvciByZWFsLXRpbWUgc2VydmljZSxsaWtlIFZvSVAsIGhvdyB0byBndWFyYW50ZWUgaXQncyBy ZWFsIHRpbWUgcmVxdWlyZW1lbnQ/DQoNClJlZ2FyZCwNCiAgICANCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gDQpGcm9tOiBsM3Zwbi1yZXF1ZXN0QGlldGYub3JnIA0KVG86IGwzdnBuQGll dGYub3JnIA0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjQsIDIwMDQgMTowMCBBTQ0KU3ViamVj dDogTDN2cG4gZGlnZXN0LCBWb2wgMSAjMTM3IC0gMSBtc2cNCg0KVG9kYXkncyBUb3BpY3M6DQoN CiAgIDEuIEVuZCB0byBlbmQgUW9TIGd1YXJhbnRlZSBmb3IgdXNlcnMgaW4gVlBOIChDaHJpcyBM ZXdpcykNCg0KDQpOZWlsLA0KDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIG1heSBiZSBhIGxvbmdp c2ggZGlzY3Vzc2lvbiwgYnV0IHdvdWxkIHlvdSBiZSANCnByZXBhcmVkIHRvIGVuZ2FnZSBvbiBh IGNvdXBsZSBvZiBwb2ludHMgZnJvbSB0aGlzIHRvcGljIG9uIHRoZSBhbGlhcz8NCg0KVGhlIGNv dXBsZSBvZiBwb2ludHMgSSdtIGludGVyZXN0ZWQgaW4gaGVhcmluZyBtb3JlIGZyb20geW91IG9u IGFyZTsNCg0KMS4gVGhlIG5lZWQgZm9yIG92ZXItcHJvdmlzaW9uaW5nIHRvIGVuc3VyZSBlbmQg dG8gZW5kIFFvUywgd2hpY2ggeW91IA0KKGNvcnJlY3RseSBJTUhPKSBpZGVudGlmeSBhcyBub3Qg YSBnb29kIHNvbHV0aW9uDQoyLiBUaGUgbmVlZCBmb3IgcGVyIFZQTiBRb1MNCg0KT24gdGhlIGZp cnN0IG9uZSwgU3RldmVuIENhc25lciBpbiBOQU5BT0cgMjIgcHJlc2VudGVkIGEgbmljZSBzdHVk eSBvZiBhIA0KdGllciAxIGJhY2tib25lIHRoYXQgc2hvd2VkIHRoYXQgZm9yIHByZXR0eSBtdWNo IGFsbCBvZiB0aGUgdGltZSwgaWYgdGhlcmUgDQp3YXMgdHdpY2UgdGhlIGJhbmR3aWR0aCBhdmFp bGFibGUgdGhhbiBvZmZlcmVkIGxvYWQsIHRoZXJlIHdhcyBuZXZlciANCmNvbmdlc3Rpb24vZGVs YXkvaml0dGVyLCBldmVuIHVuZGVyIGZhaWx1cmVzLiBUaGlzIGRvZXMgb2YgY291cnNlIHRyYWRl IG9mZiANCnRoZSBjb3N0IG9mIGJhbmR3aWR0aCB3aXRoIGEgc2ltcGxlIG5ldHdvcmsgcGxhbm5p bmcgbW9kZWwuIFRoZSBkb3duc2lkZXMgDQpob3dldmVyIGRvIGluY2x1ZGUgY29zdCwgdW5leHBl Y3RlZCBzaGlmdHMgaW4gdHJhZmZpYywgcHJvdmlzaW9uaW5nIA0KZmFpbHVyZXMsIGludGVybmV0 IHRyYWZmaWMgYWZmZWN0aW5nIFZvSVAgYW5kIHNvIGZvcnRoLiBPbmUgcHJvcG9zYWwgaXMgdG8g DQpvdmVyIHByb3Zpc2lvbiAob3IgdW5kZXIgcHJvdmlzaW9uKSBvbiBhIHBlciBjbGFzcyBiYXNp cywgc28gdGhhdCBzYXkgdGhlIA0KY29udHJvbGxlZCBsYXRlbmN5IGNsYXNzIGhhcyAyIHRpbWVz IHRoZSBiYW5kd2lkdGggYXZhaWxhYmxlIHdoZW4gY29tcGFyZWQgDQp0byB0aGUgb2ZmZXJlZCBs b2FkLCBob3dldmVyIHRoZSBiZXN0IGVmZm9ydCBjbGFzcyBtYXkgYmUgdW5kZXIgcHJvdmlzaW9u ZWQgDQphbmQgbm90IGdldCBhbGwgaXQgbmVlZHMgaW4gdGltZXMgb2YgY29uZ2VzdGlvbi4gVGhl IG9idmlvdXMgYmVuZWZpdCBoZXJlIA0KaXMgdGhhdCB0aGUgY29zdCBvZiBvdmVyLXByb3Zpc2lv bmluZyBpcyBsb3dlcmVkIGFuZCBpcyBvbmx5IGRvbmUgZm9yIHRoZSANCmNsYXNzZXMgdGhhdCBy ZWFsbHkgbmVlZCBpdC4NCg0KVGhpcyBsZWFkcyBvbiB0byBwb2ludCAyLCB3aGlsZSBpdCBpcyB0 cnVlIHRvIHNheSBpdCBpcyBpbXBvc3NpYmxlIHRvIGNvbWUgDQp1cCB3aXRoIGEgcG9ydGFibGUg ZGVmaW5pdGlvbiBvZiB3aGF0IGlzIG1pc3Npb24gY3JpdGljYWwgYW5kIHdoYXQgaXMgbm90IA0K Zm9yIGFuIGVudGVycHJpc2UsIGl0IGlzIHBvc3NpYmxlIHRvIGlkZW50aWZ5IGRpZmZlcmVudCBs ZXZlbHMgb2Ygc2VydmljZSANCndpdGhpbiBhIHByb3ZpZGVyIFZQTiB0aGF0IHRoZSBlbnRlcnBy aXNlIGNhbiBtYXRjaCBpdHMgdHJhZmZpYyB0bywgc3VjaCBhcyANCnZvaWNlIHJlcXVpcmluZyAx NTAgbXMgZW5kIHRvIGVuZCBkZWxheSwgb3IgYSB0cmFuc2FjdGlvbiBwcm9ncmFtIHJlcXVpcmlu ZyANClggaHVuZHJlZCBtc2VjcyBvZiBkZWxheSwgb3IgYSBmaWxlIHRyYW5zZmVyIHJlcXVpcmlu ZyBZIE1icHMuDQoNClNvIGlzIGl0IG5vdCBmZWFzaWJsZSB0byBzdWdnZXN0IHRoYXQgYSBwcm92 aWRlciBjYW4gb2ZmZXIgdGhlc2UgZGlmZmVyZW50IA0Kc2VydmljZSB0eXBlcywgdGhlbiBrbm93 aW5nIHdoYXQgaGFzIGJlZW4gc3Vic2NyaWJlZCB0bywgZW5naW5lZXIgYSBuZXR3b3JrIA0KZm9y IHRoZSBhZ2dyZWdhdGUsIG1lYW5pbmcgdGhhdCBpdCBpcyBrbm93biB0aGF0IFggaHVuZHJlZCBN YnBzIG9mIHZvaWNlIA0KdHJhbnNwb3J0IGhhcyBiZWVuIHNvbGQsIGFuZCB0aGVyZWZvcmUgMlgg aXMgcHJvdmlzaW9uZWQgaW4gdGhlIG5ldHdvcms/IElmIA0KdGhpcyB0aGVuIG1lYW50IHRoYXQg YWxsIHZvaWNlIHRyYWZmaWMgd2FzIHRyZWF0ZWQgcHJvcGVybHksIHRoZXJlIHdvdWxkIGJlIA0K bm8gbmVlZCBmb3IgcGVyIFZQTiBRb1MgdG8gc3VwcG9ydCB2b2ljZS4gVGhlIHNhbWUgY291bGQg dGhlbiBiZSB0cnVlIG9mIA0Kb3RoZXIgdHJhZmZpYyBjbGFzc2VzIChldmVuIHRob3VnaCB0aG9z ZSBvdGhlciBjbGFzc2VzIHdvdWxkIGhhdmUgZGlmZmVyZW50IA0KdW5kZXIgb3Igb3ZlciBwcm92 aXNpb25pbmcgcmF0aW9zKS4NCg0KQ2hlZXJzDQoNCkNocmlzDQo= ------=_NextPart_000_00CF_01C3FB91.7FC4A7D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1nYjIzMTIiPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjgw MC4xMjY0IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg YmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPlNlcnZpY2UgDQpMZXZlbCBBZ3JlZW1l bnQgYWJvdXQgVlBOIGJldHdlZW4gZW50ZXJwcmlzZSBhbmQgU2VydmljZSBQcm92aWRlciBtYXli ZSANCmlzJm5ic3A7YXMgZm9sbG93aW5nKEkgdGhpbmsgZW50ZXJwcmlzZSBjdXN0b21lciBkbyBu ZWVkIHRoZXNlIA0KcmVxdWlyZW1lbnRzKTo8L0ZPTlQ+IDwvRElWPg0KPERJVj4NCjxESVY+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZQTiBT ZXJ2aWNlIFNMQShhbiANCkV4YW1wbGUpOjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiANCnNpemU9Mz58LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIA0Kc2l6ZT0zPnwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwZXJmb3Jt YW5jZSANCnBhcmFtZXRlcnMgJmFtcDsgdGFyZ2V0IHZhbHVlPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIA0Kc2l6ZT0zPnwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDtBcHBsaWNh dGlvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO0RhdGEgDQpSYXRlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg DQpzaXplPTM+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0RlbGF5Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Sml0dGVyJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KUGFja2V0IExvc3MgUmF0aW88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+fCZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsgVG90YWwgUW9T Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyANCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IDIgTTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiANCnNpemU9Mz58LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO01pbiANClNlc3Npb24gTnVtJm5ic3A7IE1heCBTZXNzaW9uIE51 bSZuYnNwOyZuYnNwOyZuYnNwO1BlclNlc3Npb24gDQpSZXF1aXJlbWVudDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCnNpemU9Mz58LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIA0Kc2l6 ZT0zPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpWb0lQJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KMTAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7IDUwJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwIA0KS2JpdC9zJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KJmx0OyAxNTBtcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsgDQoxbXMmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7ICZsdDsgMyU8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgDQpzaXplPTM+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+fCZuYnNwOyZuYnNwO1Jlc3RyaWN0 aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KVm9EJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzUmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAwS2JpdC9zJm5ic3A7Jm5ic3A7Jm5ic3A7IA0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KJmx0OzEwbXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7MSU8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIA0K ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PEZPTlQgDQpzaXplPTM+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjxGT05UIA0Kc2l6ZT0zPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxGT05UIA0Kc2l6ZT0zPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvRk9OVD48Rk9OVCBzaXpl PTM+QmVzdCBFZmZvcnQmbmJzcDsmbmJzcDsgTWluIFRvdGFsJm5ic3A7IA0KNTAwSzwvRk9OVD48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQpzaXplPTM+ fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgc2l6ZT0zPkJlc3QgRWZmb3J0J3MgcHJpb3JpdHkgaXMgdGhlIGxvd2VzdCANCmFu ZCBvdGhlcnMgY2FuIHByZWVtcHQgaXQncyBiYW5kd2lkdGguPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPiZuYnNwOyZuYnNwOyZuYnNw OyBUaGUgcXVlc3Rpb24gaXMgaG93IA0KdG8gZ3VhcmFudGVlIGVhY2ggc2Vzc2lvbidzIFFvUywg bm90IGVhY2ggY2xhc3MuIEV2ZW4gdGhvdWdoIGVhY2ggY2xhc3MnIFFvcyBjYW4gDQpiZSBndWFy YW50ZWVkLCBmb3IgZWFjaCBzZXNzaW9uICxtYXliZSBpdCdzIGJhZCBvbmUuPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz4mbmJzcDsmbmJzcDsm bmJzcDsgRm9yIGV4YW1wbGUsIDEgTSANCmJhbmR3aWR0aCBpcyBhbGxvY2F0ZWQgdG8gVm9EIGNs YXNzIHNlcnZpY2UgYWJzb2x1dGVseSwgdGhhdCBpcyBtZWFuLCA1IA0Kc2Vzc2lvbnMnIFFvUyBj YW4gYmUgZ3VhcmFudGVlZC4gSWYgMTAgcGVyc29ucyhtYXliZSBtb3JlKSBpbiB0aGUgZW50ZXJw cmlzZSANCjwvRk9OVD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz5yZXF1ZXN0 IFZvRCBzZXJ2aWNlIGNvbmN1cnJlbnRseSwgaWYgDQpubyByZXNvdXJjZSBjb250cm9sIGVudGl0 eSBleGlzdHMgYW5kIGFsbCB0aGUgcmVxdWVzdCBhcmUgdHJlYXRlZCBmYWlybHksIA0KdGhlbiZu YnNwOzEwIFZvRCBzZXNzaW9uIG1heWJlIGV4aXN0IGFuZCBlYWNoIGhhcyBiYWQgUW9TLiBUaGUg cG9pbnQgaXMgdGhhdCA1IA0KVm9EIHNlc3Npb25zJyBRb1MgY2FuIGJlIGd1YXJhbnRlZWQgaWYg b3RoZXJzIDUgcmVxdWVzdCBhcmUgbm90IGFsbG93ZWQuIA0KPC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDsmbmJzcDsmbmJzcDsgSWYgYSBjYWxsIGFkbWlzc2lvbiBjb250cm9sIGVudGl0eSBleGlz dHMsIGJ1dCBmb3IgDQpyZWFsLXRpbWUgc2VydmljZSxsaWtlIFZvSVAsIGhvdyB0byBndWFyYW50 ZWUgaXQncyByZWFsIHRpbWUgcmVxdWlyZW1lbnQ/PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0zPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+UmVnYXJkLDwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvRElWPjwvRk9OVD48L0RJVj4NCjxESVYgc3R5bGU9IkZPTlQ6IDlw dCDLzszlIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPERJViBzdHlsZT0iQkFDS0dS T1VORDogI2U0ZTRlNDsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiA8QSANCnRpdGxl PWwzdnBuLXJlcXVlc3RAaWV0Zi5vcmcgDQpocmVmPSJtYWlsdG86bDN2cG4tcmVxdWVzdEBpZXRm Lm9yZyI+bDN2cG4tcmVxdWVzdEBpZXRmLm9yZzwvQT4gPC9ESVY+DQo8RElWPjxCPlRvOjwvQj4g PEEgdGl0bGU9bDN2cG5AaWV0Zi5vcmcgDQpocmVmPSJtYWlsdG86bDN2cG5AaWV0Zi5vcmciPmwz dnBuQGlldGYub3JnPC9BPiA8L0RJVj4NCjxESVY+PEI+U2VudDo8L0I+IFR1ZXNkYXksIEZlYnJ1 YXJ5IDI0LCAyMDA0IDE6MDAgQU08L0RJVj4NCjxESVY+PEI+U3ViamVjdDo8L0I+IEwzdnBuIGRp Z2VzdCwgVm9sIDEgIzEzNyAtIDEgbXNnPC9ESVY+PC9ESVY+PEJSPlRvZGF5J3MgDQpUb3BpY3M6 PEJSPjxCUj4mbmJzcDsmbmJzcDsgMS4gRW5kIHRvIGVuZCBRb1MgZ3VhcmFudGVlIGZvciB1c2Vy cyBpbiBWUE4gKENocmlzIA0KTGV3aXMpPEJSPjxCUj48QlI+TmVpbCw8QlI+PEJSPkkgdW5kZXJz dGFuZCB0aGF0IHRoaXMgbWF5IGJlIGEgbG9uZ2lzaCANCmRpc2N1c3Npb24sIGJ1dCB3b3VsZCB5 b3UgYmUgPEJSPnByZXBhcmVkIHRvIGVuZ2FnZSBvbiBhIGNvdXBsZSBvZiBwb2ludHMgZnJvbSAN CnRoaXMgdG9waWMgb24gdGhlIGFsaWFzPzxCUj48QlI+VGhlIGNvdXBsZSBvZiBwb2ludHMgSSdt IGludGVyZXN0ZWQgaW4gaGVhcmluZyANCm1vcmUgZnJvbSB5b3Ugb24gYXJlOzxCUj48QlI+MS4g VGhlIG5lZWQgZm9yIG92ZXItcHJvdmlzaW9uaW5nIHRvIGVuc3VyZSBlbmQgdG8gDQplbmQgUW9T LCB3aGljaCB5b3UgPEJSPihjb3JyZWN0bHkgSU1ITykgaWRlbnRpZnkgYXMgbm90IGEgZ29vZCBz b2x1dGlvbjxCUj4yLiANClRoZSBuZWVkIGZvciBwZXIgVlBOIFFvUzxCUj48QlI+T24gdGhlIGZp cnN0IG9uZSwgU3RldmVuIENhc25lciBpbiBOQU5BT0cgMjIgDQpwcmVzZW50ZWQgYSBuaWNlIHN0 dWR5IG9mIGEgPEJSPnRpZXIgMSBiYWNrYm9uZSB0aGF0IHNob3dlZCB0aGF0IGZvciBwcmV0dHkg bXVjaCANCmFsbCBvZiB0aGUgdGltZSwgaWYgdGhlcmUgPEJSPndhcyB0d2ljZSB0aGUgYmFuZHdp ZHRoIGF2YWlsYWJsZSB0aGFuIG9mZmVyZWQgDQpsb2FkLCB0aGVyZSB3YXMgbmV2ZXIgPEJSPmNv bmdlc3Rpb24vZGVsYXkvaml0dGVyLCBldmVuIHVuZGVyIGZhaWx1cmVzLiBUaGlzIA0KZG9lcyBv ZiBjb3Vyc2UgdHJhZGUgb2ZmIDxCUj50aGUgY29zdCBvZiBiYW5kd2lkdGggd2l0aCBhIHNpbXBs ZSBuZXR3b3JrIA0KcGxhbm5pbmcgbW9kZWwuIFRoZSBkb3duc2lkZXMgPEJSPmhvd2V2ZXIgZG8g aW5jbHVkZSBjb3N0LCB1bmV4cGVjdGVkIHNoaWZ0cyBpbiANCnRyYWZmaWMsIHByb3Zpc2lvbmlu ZyA8QlI+ZmFpbHVyZXMsIGludGVybmV0IHRyYWZmaWMgYWZmZWN0aW5nIFZvSVAgYW5kIHNvIA0K Zm9ydGguIE9uZSBwcm9wb3NhbCBpcyB0byA8QlI+b3ZlciBwcm92aXNpb24gKG9yIHVuZGVyIHBy b3Zpc2lvbikgb24gYSBwZXIgY2xhc3MgDQpiYXNpcywgc28gdGhhdCBzYXkgdGhlIDxCUj5jb250 cm9sbGVkIGxhdGVuY3kgY2xhc3MgaGFzIDIgdGltZXMgdGhlIGJhbmR3aWR0aCANCmF2YWlsYWJs ZSB3aGVuIGNvbXBhcmVkIDxCUj50byB0aGUgb2ZmZXJlZCBsb2FkLCBob3dldmVyIHRoZSBiZXN0 IGVmZm9ydCBjbGFzcyANCm1heSBiZSB1bmRlciBwcm92aXNpb25lZCA8QlI+YW5kIG5vdCBnZXQg YWxsIGl0IG5lZWRzIGluIHRpbWVzIG9mIGNvbmdlc3Rpb24uIA0KVGhlIG9idmlvdXMgYmVuZWZp dCBoZXJlIDxCUj5pcyB0aGF0IHRoZSBjb3N0IG9mIG92ZXItcHJvdmlzaW9uaW5nIGlzIGxvd2Vy ZWQgDQphbmQgaXMgb25seSBkb25lIGZvciB0aGUgPEJSPmNsYXNzZXMgdGhhdCByZWFsbHkgbmVl ZCBpdC48QlI+PEJSPlRoaXMgbGVhZHMgb24gDQp0byBwb2ludCAyLCB3aGlsZSBpdCBpcyB0cnVl IHRvIHNheSBpdCBpcyBpbXBvc3NpYmxlIHRvIGNvbWUgPEJSPnVwIHdpdGggYSANCnBvcnRhYmxl IGRlZmluaXRpb24gb2Ygd2hhdCBpcyBtaXNzaW9uIGNyaXRpY2FsIGFuZCB3aGF0IGlzIG5vdCA8 QlI+Zm9yIGFuIA0KZW50ZXJwcmlzZSwgaXQgaXMgcG9zc2libGUgdG8gaWRlbnRpZnkgZGlmZmVy ZW50IGxldmVscyBvZiBzZXJ2aWNlIDxCUj53aXRoaW4gYSANCnByb3ZpZGVyIFZQTiB0aGF0IHRo ZSBlbnRlcnByaXNlIGNhbiBtYXRjaCBpdHMgdHJhZmZpYyB0bywgc3VjaCBhcyA8QlI+dm9pY2Ug DQpyZXF1aXJpbmcgMTUwIG1zIGVuZCB0byBlbmQgZGVsYXksIG9yIGEgdHJhbnNhY3Rpb24gcHJv Z3JhbSByZXF1aXJpbmcgPEJSPlggDQpodW5kcmVkIG1zZWNzIG9mIGRlbGF5LCBvciBhIGZpbGUg dHJhbnNmZXIgcmVxdWlyaW5nIFkgTWJwcy48QlI+PEJSPlNvIGlzIGl0IG5vdCANCmZlYXNpYmxl IHRvIHN1Z2dlc3QgdGhhdCBhIHByb3ZpZGVyIGNhbiBvZmZlciB0aGVzZSBkaWZmZXJlbnQgPEJS PnNlcnZpY2UgdHlwZXMsIA0KdGhlbiBrbm93aW5nIHdoYXQgaGFzIGJlZW4gc3Vic2NyaWJlZCB0 bywgZW5naW5lZXIgYSBuZXR3b3JrIDxCUj5mb3IgdGhlIA0KYWdncmVnYXRlLCBtZWFuaW5nIHRo YXQgaXQgaXMga25vd24gdGhhdCBYIGh1bmRyZWQgTWJwcyBvZiB2b2ljZSA8QlI+dHJhbnNwb3J0 IA0KaGFzIGJlZW4gc29sZCwgYW5kIHRoZXJlZm9yZSAyWCBpcyBwcm92aXNpb25lZCBpbiB0aGUg bmV0d29yaz8gSWYgPEJSPnRoaXMgdGhlbiANCm1lYW50IHRoYXQgYWxsIHZvaWNlIHRyYWZmaWMg d2FzIHRyZWF0ZWQgcHJvcGVybHksIHRoZXJlIHdvdWxkIGJlIDxCUj5ubyBuZWVkIA0KZm9yIHBl ciBWUE4gUW9TIHRvIHN1cHBvcnQgdm9pY2UuIFRoZSBzYW1lIGNvdWxkIHRoZW4gYmUgdHJ1ZSBv ZiA8QlI+b3RoZXIgDQp0cmFmZmljIGNsYXNzZXMgKGV2ZW4gdGhvdWdoIHRob3NlIG90aGVyIGNs YXNzZXMgd291bGQgaGF2ZSBkaWZmZXJlbnQgPEJSPnVuZGVyIA0Kb3Igb3ZlciBwcm92aXNpb25p bmcgcmF0aW9zKS48QlI+PEJSPkNoZWVyczxCUj48QlI+Q2hyaXM8QlI+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_00CF_01C3FB91.7FC4A7D0-- From exim@www1.ietf.org Wed Feb 25 02:34:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00837 for ; Wed, 25 Feb 2004 02:34:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtYc-0004Ua-BS for l3vpn-archive@odin.ietf.org; Wed, 25 Feb 2004 02:34:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P7YEsW017266 for l3vpn-archive@odin.ietf.org; Wed, 25 Feb 2004 02:34:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtYb-0004UP-W0 for l3vpn-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 02:34:14 -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 CAA00758 for ; Wed, 25 Feb 2004 02:34:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtYY-0001zR-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 02:34:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvtXo-0001pq-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 02:33:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvtWW-0001aJ-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 02:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtWT-0003su-Il; Wed, 25 Feb 2004 02:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtVb-0003ju-KW for l3vpn@optimus.ietf.org; Wed, 25 Feb 2004 02:31:07 -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 CAA29392 for ; Wed, 25 Feb 2004 02:31:03 -0500 (EST) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtVX-0001NN-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 02:31:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvtUF-00014u-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 02:29:45 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139] helo=i2kc05-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AvtTe-0000yA-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 02:29:07 -0500 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 Feb 2004 07:28:37 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 Feb 2004 07:28:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: End to end QoS guarantee for users in VPN Date: Wed, 25 Feb 2004 07:28:35 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF32BC@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: RE: End to end QoS guarantee for users in VPN Thread-Index: AcP6Y6xAfB7hfGXUEdifKgAGWzDmww== To: Cc: X-OriginalArrivalTime: 25 Feb 2004 07:28:36.0705 (UTC) FILETIME=[FB457D10:01C3FB70] Content-Transfer-Encoding: quoted-printable 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: , List-Id: List-Post: List-Help: List-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.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable *re-posting in plain text converted from original HTML format of = original posting* Hi Chris....I can't really do justice to this on this list..........and = where to start! However, let me have a go (though I really don't want to = open up any protracted discussion here). =20 Its not as simple as homing-in on a single topic like QoS support in = VPNs (whatever that truly means...see later).........we really have to = go right back to the fundamental principles of the 3 networking modes = (ie co-cs, co-ps and cl-ps) and look across the whole arch vista to = understand how QoS fits in the big picture. This means we need to start with respecting the func arch principles of = G.805/809 for the mode considered, because everything flows from these. = >From this we can then define a network and NMS/OSS architecture that:=20 - delivers a minimised opex/capex solution across all public and private = services (this is multi-faceted)=20 - is secure for both customer traffic and internal operator = control/management traffic......so, for example, an OOB network is = required for internal/sensitive operator control and management traffic=20 - allows the creation of service models (which include appropriate = differential pricing models) that are both meaningful and fair (to all = parties) across all networking loading points and across all public and = private services........if we don't get this right we will probably = damage the industry for all parties (ie end-users/customers, vendors and = operators).=20 - allows a network design that is proofed against all future (unknown) = traffic types/vectors. =20 Now in our view IETF have created some networking problems that won't = allow us to easily (if at all) achieve the above objectives. I have been = posting mails on these problems for a long time now, esp on what is = wrong with MPLS as-is and some of its consequences like PWE3. However, = and for whatever reasons, we have not been able to get IETF to take our = requirements into account. I suspect one of the problems for IETF these = days is an unclear target audience:=20 - is it the Internet?=20 - is it the ISP/alt-nets?=20 - is it the trad operators like BT?=20 There are conflicting requirements here. We are no longer operating in = the old Arpanet days when the Internet was a big experiment......so the = IETF modus operandi that worked fine then looks highly suspect to us now = (and we can't fix that here anyway). The bubble on misreported BW demand = has burst and so trad operators are being courted again by = vendors.......but our commercial requirements are not the same as the = others above. =20 I can do no better than to advise anyone who really wants to understand = our thinking on networking (eg why we must start with G.805/809 func = arch models) to please read chapters 3 and 4 (at least) of a colleague's = book (Andy Reid, co-authored with Mike Sexton) on 'broadband = networking'. I know this stuff is anathema to some folks, but for us = operators it is crucial since this is the basis for developing the = management information models.....and NMS/OSS are key areas to get right = for any major operator ........but these can only be as good as the = underpinning network arch models allow. Break the arch rules and it will = all slowly start to go pear-shaped.=20 I could provide you with a long list of stuff that is broken in our = view. However, that would take pages. =20 Some further remarks in-line below.=20 regards, Neil=20 : Chris Lewis [mailto:chrlewis@cisco.com] Sent: 23 February 2004 03:08 To: Harrison,N,Neil,IKR2 R Cc: l3vpn@ietf.org Subject: End to end QoS guarantee for users in VPN Neil, =09 I understand that this may be a longish discussion, but would you be = prepared to engage on a couple of points from this topic on the alias? =09 The couple of points I'm interested in hearing more from you on are; =09 1. The need for over-provisioning to ensure end to end QoS, which you = (correctly IMHO) identify as not a good solution=20 2. The need for per VPN QoS=20 NH=3D> I think QoS is much abused term Chris. Few networks (not just = comms) can create a viable commercial model from multiple 'QoS = levels'....look at successful transport networks say, eg we have a very = successful airline in the UK called Easyjet, and its based on a 1-class = service model....just '1st come 1st served'. ATM tried lots of = QoS/traffic classes. They were not a success..........simple ATM = services are a success however......and one of the key strengths of ATM = is that we have a trail that can be managed quite separately from the = traffic flowing on that trail (this is related to the 'urgency' vs = 'importance' issue that I will return to shortly). In fact all the = networks that have been successful to date have not really 'done QoS' as = a conscious act, eg PSTN, Sonet/SDH, Internet as-is, FR. QoS is also intrinsically related to a notion of BW squeezing, ie trying = to get more traffic on a given resource. It is, however, an efficiency = illusion. BW is not a scarce resource any longer and the costs are = falling each day......complexity is a major problem however, and its = costs are rising each day. Multiple traffic/QoS classes create = complexity/capex costs in both the data-plane (buffers, schedulers, etc) = and the control-plane protocols to support this, and there are = associated complexity/opex costs with the design/operation/maintenance = of such networks. Real networks, as you also note below, don't run = heavily loaded. Why? Well, there are lots of reasons such as: - the topology of a given layer network is created from trails in a = lower server layer network, eg optics, SDH VC4s........ so = planning-cycle growth comes in large BW quanta ; - layer networks require ~ 30% redundancy for protection/restoration=20 - there is a varying demand over usage cycles, eg daily, so capacity has = be related to some peak usage demand=20 - if there is uncertainty (or a lack of control) of routing this = encourages over-dimensioning - similarly, uncertainties in traffic forecast can lead to = over-dimensioning (and possibly under-dimensioning in some cases).=20 Now given all service requirements have to be met at the peak time and = at the *end* of the current planning-cycle, then over the life of real = networks it is not surprising they seem to be under-utilised. This creates a serious commercial challenge for operators in that QoS = has to be seen to be 'fair and meaningful' over a large range of = loads.......and the really big challenge is ensuring the right behaviour = for: - Normal Operation...load <~50% for maybe >99% of time? - Abnormal Operation...load -> 100% for maybe <1% of time? The network behaviour required is different in each of these operating = regions......in the former (ie nearly all of the time) its providing = fair/meaningful service (ie 'you get what you pay for not what someone = else has paid for'), whilst in the latter its about protecting the = network (and this is a one reason the control/management protocols have = to go OOB, another reason is security) from overload (ie must remain = stable) and ensuring that the right serivices survive......this is the = 'urgency' vs 'importance' problem. Now any technology that allows BW sharing across different QoS classes = will not allow a solution to the commercial problems. Indeed, over = provisioning simply makes these commercial problems worse!=20 There is also the problem of 'urgency' vs 'importance'. Under failures = its not QoS considerations that should determine which traffic survives, = but some 'importance' semantic........which IMO is something one has to = associate with the trail entity, esp in the case of private vs public = traffic say. This survivability issue also implies a required 'ordering = behaviour'....because fault-handling and survivability/availability = (which are related) are far more important metrics than QoS, and must be = considered before QoS has any meaningful basis. That is:=20 - the arch of the network mode considered must be right 1st=20 - which then allows the appropriate defects to be identified=20 - which then allows the appropriate OAM to be defined ......such that = defects have the appropriate entry/exit criteria and consequent actions = specified=20 - which then allows the (un)available states to be defined=20 - which then, and only then, provides the temporal basis (ie the = available state) where QoS has any meaning.=20 These aspects are not the same for the cl-ps, co-ps and co-cs modes, ie = a different approach is required for each mode.....and this is assuming = one has (i) respected the func arch of the mode considered, and (ii) = that the technology used is correctly and adequately functionally = specified.=20 And remember what I said earlier about the importance of management = information models? Well, once one starts to define the fault-handling = and availability/QoS registers in network elements, and how these = interface to the NMS/OSS and stuff like billing/SLAs/etc, then it is = rather important that the above thinking has flowed through from a = proper understanding of the underpinning network architecture of the = mode being considered.=20 You can use a co-ps mode like MPLS to provide the missing = survivability/availability control (at the trail level rather than the = pkt level) for VPNs. This is fine providing it respects the allowed arch = of that mode (ie p2p or p2mp only) but fails if there is merging, ie LDP = mp2p....and PHP is also a merging device. The mp2p/PHP violations of the = co-ps mode also create significant fault management problems too ....and = these get compounded if we add a proprietary ECMP behaviour to the brew. = And noting what I said earlier, if we can't get the defects/OAM sorted = first then we don't even have a basis for addressing the traffic/QoS = aspects anyway. I therefore find it hard to take seriously anyone who = tells me LSP-Ping is 'simple/efficient' (as the draft currently = says)....esp compared to Y.1711. Though I have to own up to = self-interest here as I penned to original version of Y.1711. But please = note this was not specifically written for MPLS, this is how IMO we = should do the basic defect detection/handling in any co-ps mode = technology that is architecturally compliant. CL=3D> On the first one, Steven Casner in NANAOG 22 presented a nice = study of a tier 1 backbone that showed that for pretty much all of the = time, if there was twice the bandwidth available than offered load, = there was never congestion/delay/jitter, even under failures. This does = of course trade off the cost of bandwidth with a simple network planning = model.=20 NH=3D> So if there is BW sharing between classes and if the network is = lightly loaded over much of its life (which it has to be) then just how = can one make a good commercial model for 'service differentiation'? CL=3D> The downsides however do include cost, unexpected shifts in = traffic, provisioning failures, internet traffic affecting VoIP and so = forth. One proposal is to over provision (or under provision) on a per = class basis, so that say the controlled latency class has 2 times the = bandwidth available when compared to the offered load, however the best = effort class may be under provisioned and not get all it needs in times = of congestion. The obvious benefit here is that the cost of = over-provisioning is lowered and is only done for the classes that = really need it.=20 NH=3D> I think there are alternative ways of looking at the overall = service problem we operators have, but this requires one to have an = open-mind wrt to the solutions and the real value of QoS in relation to = the network mode.....see my next comment.=20 =09 CL=3D> This leads on to point 2, while it is true to say it is = impossible to come up with a portable definition of what is mission = critical and what is not for an enterprise, it is possible to identify = different levels of service within a provider VPN that the enterprise = can match its traffic to, such as voice requiring 150 ms end to end = delay, or a transaction program requiring X hundred msecs of delay, or a = file transfer requiring Y Mbps. =20 NH=3D> It's not just private traffic we have to address, but also public = traffic. Let's assume we are addressing an operator's commercial service = requirements and not just those of the Internet. Suppose we had 2 simple = modes of (1 class in each) cl-ps and co-ps (emulating co-cs, ie CBR) = working in harmony, and where the co-ps core can offer both on-demand = SVC-like services for public traffic (but only as/when required and = charged for accordingly, else use the cl-ps mode) and S-PVC-like based = services for private traffic when strong SLAs and strong traffic = isolation are required (one can still do VPNs using a proper cl-ps = server layer, but the SLAs and traffic isolation available now are much = weaker). Further, for VPNs we could have more generic models......where a = (so-called) L3 VPN is nothing more than adding a client layer = reachability component to a base-case simple managed BW (so-called) L2 = VPN. In the public service case we let the application/user choose the mode = (we obviously need different pricing models here). You then don't need a = load of complex QoS classes in each mode that won't work anyway, just = simple peak rate models work fine....the biggest 'QoS bang per buck' = comes from mode selection and we can thus enforce fair/meaningful = services over all load points.....users now only get what they pay for, = not what someone else has paid for. One could argue that this is using = BW wisely to solve both technical and commercial problems that are = otherwise hard or intractable. Add an OOB control/management-plane and the top-level objectives I = mentioned earlier can now really start to be addressed.=20 CL=3D> So is it not feasible to suggest that a provider can offer these = different service types, then knowing what has been subscribed to, = engineer a network for the aggregate, meaning that it is known that X = hundred Mbps of voice transport has been sold, and therefore 2X is = provisioned in the network? If this then meant that all voice traffic = was treated properly, there would be no need for per VPN QoS to support = voice. The same could then be true of other traffic classes (even though = those other classes would have different under or over provisioning = ratios).=20 NH=3D> As I noted earlier, QoS is an illusion if seen solely as a means = to an end in a single network mode. The successful networks to date have = never done 'QoS' and I don't see any reason why this should suddenly = change......QoS should be a non-issue IMO if you get the right network = arch in place for the 3 modes, and you use them wisely working in = harmony. We have various internal papers that go into some of the stuff I have = briefly touched on above, ie what precisely is wrong/missing with MPLS = as-is and the stuff its spawned, like in PWE3, and also the development = of an alternative network service architecture based on the 3 modes = working together.=20 regards, Neil Cheers =09 Chris =09 This needs a longish response .....so I'll get back to you off-list.=20 regards, Neil=20 -----Original Message----- From: Jeff Helmer [] Sent: 20 February 2004 23:50 To: Harrison,N,Neil,IKR2 R Cc: l3vpn@ietf.org Subject: Re: FW: End to end QoS guarantee for users in VPN =09 Neil,=20 I wanted to understand the phrase "traffic isolation on a per VPN = basis" that you used. Do you mean per-VPN LSPs (without any merging) = between the PE routers (assuming a MPLS core)? This would ensure each = VPN has a guaranteed end-to-end bandwidth which may not be possible if = all VPNs between a pair of PE routers used the same tunnel LSP. The DS = codepoint would then signify the relative importance of different kinds = of traffic in the same VPN.=20 - Jeff =09 Jeff Helmer wrote:=20 -----Original Message----- From: l3vpn-admin@ietf.org [On = Behalf Of Li Xiangjun Sent: 19 February 2004 02:08 To: l3vpn@ietf.org Subject: End to end QoS guarantee for users in VPN =09 hi;=20 Traditionally we only manages the toal QoS of VPN. In fact,many users = in the enterprise use the VPN,that means the VPN carries different kinds = of services(VoIP.HTTP.VoD et ac.) of different users in the enterprise. = How to assure every user's QoS, that is to say every flow's QoS ?=20 Is there any suggestion about it?=20 Excellent question. And I agree with you. As a general observation it = is not possible to differentiate 'urgency' (ie how fast?) from = 'importance' (ie how critical is this pkt vs others?) from just a DS = codepoint at the pkt level. One can imagine cases in 1 VPN where a given = voice call is mission critical and others where it is not....same = applies to data applications. Further, there is a difference between the = treatment of public traffic and private traffic.....and in fact some = public traffic that belongs to the same 'urgency' class can also have = different 'importance'. One can use the LSP as a survivavbility = differentiator, ie to isolate different VPN instances......however, this = requires p2p LSPs because if the traffic gets merged on lower mp2p LSPs = then per VPN QoS/perf/failure-handling behaviour is not simple to = provide. The usual response to such uncertainty in these quantities is = to significanly overprovide.......which is not a good solution.=20 There are deeper issues here of pricing for 'fair/meaningful' services = that, in addition to the urgency vs importance angle, is affected by BW = borrowing between DS classes.....and these can't be easily sorted IMO if = the network arch is unable to deliver traffic isolation on a per VPN = basis.=20 regards, Neil From exim@www1.ietf.org Wed Feb 25 02:35:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00897 for ; Wed, 25 Feb 2004 02:35:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtYv-0004Ya-E3 for l3vpn-archive@odin.ietf.org; Wed, 25 Feb 2004 02:34:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P7YXcq017506 for l3vpn-archive@odin.ietf.org; Wed, 25 Feb 2004 02:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtYu-0004YH-Tm for l3vpn-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 02:34:32 -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 CAA00792 for ; Wed, 25 Feb 2004 02:34:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtYr-00022g-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 02:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvtXq-0001py-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 02:33:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvtWW-0001aK-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 02:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtWU-0003t7-Dl; Wed, 25 Feb 2004 02:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvtVv-0003mv-RX for l3vpn@optimus.ietf.org; Wed, 25 Feb 2004 02:31:27 -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 CAA29663 for ; Wed, 25 Feb 2004 02:31:24 -0500 (EST) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvtVr-0001QI-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 02:31:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvtUJ-00015N-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 02:29:49 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AvtTl-0000zD-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 02:29:13 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 Feb 2004 07:28:43 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 25 Feb 2004 07:28:43 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FB70.FEE4998F" Subject: RE: End to end QoS guarantee for users in VPN Date: Wed, 25 Feb 2004 07:28:42 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF32BD@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: End to end QoS guarantee for users in VPN Thread-Index: AcP7TwFYJ8NTv7fHRVe5sPqHuT9qTAAHEURQ To: , X-OriginalArrivalTime: 25 Feb 2004 07:28:43.0440 (UTC) FILETIME=[FF492B00:01C3FB70] 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: , List-Id: List-Post: List-Help: List-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.9 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FB70.FEE4998F Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Can you please use plain text for mails in future.......I tried = responding to an orginal mail from yourself that Chris Lewis had tagged = with some supplementary questions (I note you have attached some of this = below) and found it ended up too large (the list moderator culled it). =20 The basic answer to your question is this......'there is no such thing = as a free lunch'. Has it ever crossed your mind that the reason this = stuff is not easily solveable is that perhaps the underpinning approach = and network arch is all wrong? I'll re-post my response to Chris I = noted above in plain text where I discuss this aspect for both public = and private services (you can't just consider these in = isolation).......not that I expect many dyed-in-the-wool IETF folks will = like it because, as I say, it questions the fundamantal approach being = used so far. =20 thanks...regards, Neil -----Original Message----- From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of Li = Xiangjun Sent: 25 February 2004 03:21 To: l3vpn@ietf.org Subject: Fw: End to end QoS guarantee for users in VPN=20 Service Level Agreement about VPN between enterprise and Service = Provider maybe is as following(I think enterprise customer do need these = requirements):=20 VPN Service SLA(an Example): |------------------------------------------------------------------------= --------------------------------------------------------- | = = performance parameters & target value | Application = Data Rates = ---------------------------------------- | = Delay = Jitter Packet Loss Ratio |------------------------------------------------------------------------= --------------------------------------------------------- | Total QoS = 2 M |------------------------------------------------------------------------= -------------------------------------------------------- | Min Session Num Max Session = Num PerSession Requirement |------------------------------------------------------------------------= --------------------------------------------------------- | VoIP 10 = 50 10 Kbit/s < 150ms = < 1ms < 3% | = -------------------------------------------------------------------------= ------------------------------------ | Restriction VoD 2 = 5 200Kbit/s <10ms = <1% | = -------------------------------------------------------------------------= ------------------------------------ | Best Effort Min Total 500K |------------------------------------------------------------------------= ---------------------------------------------------------- Best Effort's priority is the lowest and others can preempt it's = bandwidth. =20 The question is how to guarantee each session's QoS, not each class. = Even though each class' Qos can be guaranteed, for each session ,maybe = it's bad one. For example, 1 M bandwidth is allocated to VoD class service = absolutely, that is mean, 5 sessions' QoS can be guaranteed. If 10 = persons(maybe more) in the enterprise request VoD service concurrently, = if no resource control entity exists and all the request are treated = fairly, then 10 VoD session maybe exist and each has bad QoS. The point = is that 5 VoD sessions' QoS can be guaranteed if others 5 request are = not allowed.=20 If a call admission control entity exists, but for real-time = service,like VoIP, how to guarantee it's real time requirement? =20 Regard, =20 ----- Original Message -----=20 From: l3vpn-request@ietf.org=20 To: l3vpn@ietf.org=20 Sent: Tuesday, February 24, 2004 1:00 AM Subject: L3vpn digest, Vol 1 #137 - 1 msg Today's Topics: 1. End to end QoS guarantee for users in VPN (Chris Lewis) Neil, I understand that this may be a longish discussion, but would you be=20 prepared to engage on a couple of points from this topic on the alias? The couple of points I'm interested in hearing more from you on are; 1. The need for over-provisioning to ensure end to end QoS, which you=20 (correctly IMHO) identify as not a good solution 2. The need for per VPN QoS On the first one, Steven Casner in NANAOG 22 presented a nice study of a = tier 1 backbone that showed that for pretty much all of the time, if = there=20 was twice the bandwidth available than offered load, there was never=20 congestion/delay/jitter, even under failures. This does of course trade = off=20 the cost of bandwidth with a simple network planning model. The = downsides=20 however do include cost, unexpected shifts in traffic, provisioning=20 failures, internet traffic affecting VoIP and so forth. One proposal is = to=20 over provision (or under provision) on a per class basis, so that say = the=20 controlled latency class has 2 times the bandwidth available when = compared=20 to the offered load, however the best effort class may be under = provisioned=20 and not get all it needs in times of congestion. The obvious benefit = here=20 is that the cost of over-provisioning is lowered and is only done for = the=20 classes that really need it. This leads on to point 2, while it is true to say it is impossible to = come=20 up with a portable definition of what is mission critical and what is = not=20 for an enterprise, it is possible to identify different levels of = service=20 within a provider VPN that the enterprise can match its traffic to, such = as=20 voice requiring 150 ms end to end delay, or a transaction program = requiring=20 X hundred msecs of delay, or a file transfer requiring Y Mbps. So is it not feasible to suggest that a provider can offer these = different=20 service types, then knowing what has been subscribed to, engineer a = network=20 for the aggregate, meaning that it is known that X hundred Mbps of voice = transport has been sold, and therefore 2X is provisioned in the network? = If=20 this then meant that all voice traffic was treated properly, there would = be=20 no need for per VPN QoS to support voice. The same could then be true of = other traffic classes (even though those other classes would have = different=20 under or over provisioning ratios). Cheers Chris ------_=_NextPart_001_01C3FB70.FEE4998F Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Can you please use plain text for mails in=20 future.......I tried responding to an orginal mail from yourself that = Chris=20 Lewis had tagged with some supplementary questions (I note you have = attached=20 some of this below) and found it ended up too large (the list moderator = culled=20 it).
 
The basic answer to your question is = this......'there=20 is no such thing as a free lunch'.  Has it ever crossed your mind = that the=20 reason this stuff is not easily solveable is that perhaps the = underpinning=20 approach and network arch is all wrong?  I'll re-post my response = to Chris=20 I noted above in plain text where I discuss this aspect for both public = and=20 private services (you can't just consider these in isolation).......not = that I=20 expect many dyed-in-the-wool IETF folks will like it because, as I say, = it=20 questions the fundamantal approach being used so = far.
 
thanks...regards, Neil
-----Original Message-----
From: = l3vpn-admin@ietf.org=20 [mailto:l3vpn-admin@ietf.org]On Behalf Of Li = Xiangjun
Sent:=20 25 February 2004 03:21
To: l3vpn@ietf.org
Subject: = Fw: End=20 to end QoS guarantee for users in VPN

    Service Level Agreement about VPN between enterprise and = Service=20 Provider maybe is as following(I think enterprise customer do = need these=20 requirements):
    VPN = Service SLA(an=20 Example):
|---------------------------------------------------------------= ------------------------------------------------------------------=
|          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp; performance=20 parameters & target value
|           = =  Application         &n= bsp;           &nb= sp;           &nbs= p;            = ;   Data=20 = Rates           &n= bsp;           &nb= sp;           &nbs= p;  ----------------------------------------
|          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;      Delay    &nb= sp;  Jitter    =20 Packet Loss Ratio
|---------------------------------------------------------------= ------------------------------------------------------------------=
|   =20         Total QoS   =20             =    =20             =    =20             =     2=20 M
|---------------------------------------------------------------= -----------------------------------------------------------------<= /DIV>
|          &nb= sp;           &nbs= p;            = ;        Min=20 Session Num  Max Session Num   PerSession=20 Requirement
|---------------------------------------------------------------= ------------------------------------------------------------------=
|          &nb= sp;           &nbs= p;        =20 = VoIP           &nb= sp;   =20 10            =    =20         50    =    =20            =20      10=20 = Kbit/s           &= nbsp;   =20 < = 150ms          <=20 1ms        < 3%
|          &nb= sp;           &nbs= p;        -----------------------= -------------------------------------------------------------------------= -------------
|  Restriction      &nbs= p;      =20 = VoD           &nbs= p;      2     &nbs= p;            = ;        5   =20             =    =20       200Kbit/s   =20            =20 = <10ms           = ;            =       <1%
|           = ;                 &nbs= p;       ----------------------------------------------------------------= ---------------------------------------------
|           = ;                 &nbs= p;     =20 Best Effort   Min Total =20 500K
|---------------------------------------------------------------= -------------------------------------------------------------------
Best Effort's priority is = the lowest=20 and others can preempt it's bandwidth.
 
    The = question is=20 how to guarantee each session's QoS, not each class. Even though each = class'=20 Qos can be guaranteed, for each session ,maybe it's bad = one.
    For = example, 1 M=20 bandwidth is allocated to VoD class service absolutely, that is mean, = 5=20 sessions' QoS can be guaranteed. If 10 persons(maybe more) in the = enterprise=20 request VoD service = concurrently,=20 if no resource control entity exists and all the request are treated = fairly,=20 then 10 VoD session maybe exist and each has bad QoS. The point = is that 5=20 VoD sessions' QoS can be guaranteed if others 5 request are not = allowed.=20
    If a call admission control entity exists, but = for=20 real-time service,like VoIP, how to guarantee it's real time=20 requirement?
 
Regard,
   
----- = Original Message -----=20
From: l3vpn-request@ietf.org
Sent: Tuesday, February 24, 2004 1:00 AM
Subject: L3vpn digest, Vol 1 #137 - 1 = msg

Today's=20 Topics:

   1. End to end QoS guarantee for users in = VPN=20 (Chris Lewis)


Neil,

I understand that this may be a = longish=20 discussion, but would you be
prepared to engage on a couple of = points from=20 this topic on the alias?

The couple of points I'm interested in = hearing=20 more from you on are;

1. The need for over-provisioning to = ensure end=20 to end QoS, which you
(correctly IMHO) identify as not a good=20 solution
2. The need for per VPN QoS

On the first one, = Steven Casner=20 in NANAOG 22 presented a nice study of a
tier 1 backbone that = showed that=20 for pretty much all of the time, if there
was twice the bandwidth=20 available than offered load, there was never =
congestion/delay/jitter, even=20 under failures. This does of course trade off
the cost of = bandwidth with a=20 simple network planning model. The downsides
however do include = cost,=20 unexpected shifts in traffic, provisioning
failures, internet = traffic=20 affecting VoIP and so forth. One proposal is to
over provision (or = under=20 provision) on a per class basis, so that say the
controlled = latency class=20 has 2 times the bandwidth available when compared
to the offered = load,=20 however the best effort class may be under provisioned
and not get = all it=20 needs in times of congestion. The obvious benefit here
is that the = cost of=20 over-provisioning is lowered and is only done for the
classes that = really=20 need it.

This leads on to point 2, while it is true to say it = is=20 impossible to come
up with a portable definition of what is = mission=20 critical and what is not
for an enterprise, it is possible to = identify=20 different levels of service
within a provider VPN that the = enterprise can=20 match its traffic to, such as
voice requiring 150 ms end to end = delay, or=20 a transaction program requiring
X hundred msecs of delay, or a = file=20 transfer requiring Y Mbps.

So is it not feasible to suggest = that a=20 provider can offer these different
service types, then knowing = what has=20 been subscribed to, engineer a network
for the aggregate, meaning = that it=20 is known that X hundred Mbps of voice
transport has been sold, and = therefore 2X is provisioned in the network? If
this then meant = that all=20 voice traffic was treated properly, there would be
no need for per = VPN QoS=20 to support voice. The same could then be true of
other traffic = classes=20 (even though those other classes would have different
under or = over=20 provisioning = ratios).

Cheers

Chris
------_=_NextPart_001_01C3FB70.FEE4998F-- From exim@www1.ietf.org Wed Feb 25 14:04:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05537 for ; Wed, 25 Feb 2004 14:04:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4K5-00041v-JR for l3vpn-archive@odin.ietf.org; Wed, 25 Feb 2004 14:03:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJ3vRH015482 for l3vpn-archive@odin.ietf.org; Wed, 25 Feb 2004 14:03:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4K5-00041Y-43 for l3vpn-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:03:57 -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 OAA05493 for ; Wed, 25 Feb 2004 14:03:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4K2-0005mw-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 14:03:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4J6-0005gY-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 14:02:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4IH-0005bu-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 14:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4ID-0003IU-MX; Wed, 25 Feb 2004 14:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4HH-0003CO-Ec for l3vpn@optimus.ietf.org; Wed, 25 Feb 2004 14:01:03 -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 OAA05333 for ; Wed, 25 Feb 2004 14:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4HF-0005V0-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 14:01:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4GH-0005Ph-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 14:00:01 -0500 Received: from web106.biz.mail.yahoo.com ([216.136.174.208]) by ietf-mx with smtp (Exim 4.12) id 1Aw4FL-0005Ku-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 13:59:03 -0500 Message-ID: <20040225185903.84024.qmail@web106.biz.mail.yahoo.com> Received: from [128.251.97.179] by web106.biz.mail.yahoo.com via HTTP; Wed, 25 Feb 2004 10:59:03 PST Date: Wed, 25 Feb 2004 10:59:03 -0800 (PST) From: Rick Wilder Subject: reminder: QoS not currently in L3VPN charter To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: , List-Id: List-Post: List-Help: List-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 This is not to say the discussions of QoS here are not interesting, but currently out of charter. Any proposal to expand the WG charter to include QoS would require a clear statement of requirements for VPN-specific QoS work. Rick From exim@www1.ietf.org Wed Feb 25 17:30:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19631 for ; Wed, 25 Feb 2004 17:30:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7XX-0001zl-Ph for l3vpn-archive@odin.ietf.org; Wed, 25 Feb 2004 17:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PMU3XX007663 for l3vpn-archive@odin.ietf.org; Wed, 25 Feb 2004 17:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7XX-0001zE-1L for l3vpn-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 17:30:03 -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 RAA19611 for ; Wed, 25 Feb 2004 17:29:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7XU-000684-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 17:30:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7WX-00062Y-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 17:29:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7VZ-0005wk-00 for l3vpn-web-archive@ietf.org; Wed, 25 Feb 2004 17:28:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7VZ-0001tm-Cd; Wed, 25 Feb 2004 17:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7Un-0001rE-6S for l3vpn@optimus.ietf.org; Wed, 25 Feb 2004 17:27:13 -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 RAA19513 for ; Wed, 25 Feb 2004 17:27:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7Uk-0005sP-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 17:27:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7Tw-0005ml-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 17:26:20 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7TM-0005dU-00 for l3vpn@ietf.org; Wed, 25 Feb 2004 17:25:44 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1PMPEBm098189; Wed, 25 Feb 2004 14:25:14 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp078.static.jnpr.net [172.24.253.78]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1PMPDo65986; Wed, 25 Feb 2004 14:25:13 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040225162856.02f09980@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 25 Feb 2004 17:22:32 -0500 To: Rick Wilder , l3vpn@ietf.org From: Ross Callon Subject: Re: reminder: QoS not currently in L3VPN charter In-Reply-To: <20040225185903.84024.qmail@web106.biz.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 At 10:59 AM 2/25/2004 -0800, Rick Wilder wrote: >This is not to say the discussions of QoS here are not interesting, but currently out of >charter. > >Any proposal to expand the WG charter to include QoS would require a clear statement of >requirements for VPN-specific QoS work. > >Rick To expand a bit on Rick's comments. There has been other work in the IETF over many years on QoS. In my reading of the recent discussion on the l3vpn working group mailing list, I noticed an interesting discussion. However, I didn't notice anything that would suggest a solution specific to VPNs -- the same issues could be raised for other types of traffic going through an IP/MPLS Network. If there are VPN-specific aspects of QoS we could try to understand what these are, and then have discussions regarding whether to extent the working group charter. If the QoS issues are applicable to IP networks in general, then to me it would appear to be difficult to argue why these should be in this working group rather than elsewhere in the IETF. Ross From exim@www1.ietf.org Thu Feb 26 04:18:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00096 for ; Thu, 26 Feb 2004 04:18:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHeh-00036Y-D8 for l3vpn-archive@odin.ietf.org; Thu, 26 Feb 2004 04:18:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q9I7xp011907 for l3vpn-archive@odin.ietf.org; Thu, 26 Feb 2004 04:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHef-00035x-5Y for l3vpn-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 04:18:05 -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 EAA29974 for ; Thu, 26 Feb 2004 04:18:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwHec-0005K7-00 for l3vpn-web-archive@ietf.org; Thu, 26 Feb 2004 04:18:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwHdA-00052l-00 for l3vpn-web-archive@ietf.org; Thu, 26 Feb 2004 04:16:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AwHc7-0004x2-00 for l3vpn-web-archive@ietf.org; Thu, 26 Feb 2004 04:15:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AwHY3-00020i-Pv for l3vpn-web-archive@ietf.org; Thu, 26 Feb 2004 04:11:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHXr-0002dd-HA; Thu, 26 Feb 2004 04:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwHXC-0002YC-9P for l3vpn@optimus.ietf.org; Thu, 26 Feb 2004 04:10:22 -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 EAA29815 for ; Thu, 26 Feb 2004 04:10:19 -0500 (EST) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwHX9-0004fZ-00 for l3vpn@ietf.org; Thu, 26 Feb 2004 04:10:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwHWB-0004bv-00 for l3vpn@ietf.org; Thu, 26 Feb 2004 04:09:20 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AwHVb-0004Uj-00; Thu, 26 Feb 2004 04:08:43 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Feb 2004 09:08:13 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Feb 2004 09:08:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: reminder: QoS not currently in L3VPN charter Date: Thu, 26 Feb 2004 09:08:12 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF32CD@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: reminder: QoS not currently in L3VPN charter Thread-Index: AcP77rQJBkIjdpMOR0KQVk7a402fVQAUxhaw To: , , Cc: X-OriginalArrivalTime: 26 Feb 2004 09:08:13.0315 (UTC) FILETIME=[10058D30:01C3FC48] Content-Transfer-Encoding: quoted-printable 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: , List-Id: List-Post: List-Help: List-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.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ross Callon wrote 25 February 2004 22:23 =20 > At 10:59 AM 2/25/2004 -0800, Rick Wilder wrote: >=20 > >This is not to say the discussions of QoS here are not=20 > interesting, but currently out of > >charter.=20 > > > >Any proposal to expand the WG charter to include QoS would=20 > require a clear statement of > >requirements for VPN-specific QoS work. > > > >Rick >=20 > To expand a bit on Rick's comments. There has been other work in the > IETF over many years on QoS. In my reading of the recent=20 > discussion on=20 > the l3vpn working group mailing list, I noticed an=20 > interesting discussion. > However, I didn't notice anything that would suggest a=20 > solution specific to=20 > VPNs -- the same issues could be raised for other types of=20 > traffic going=20 > through an IP/MPLS Network.=20 >=20 > If there are VPN-specific aspects of QoS we could try to=20 > understand what=20 > these are, and then have discussions regarding whether to extent the=20 > working group charter. If the QoS issues are applicable to IP=20 > networks in > general, then to me it would appear to be difficult to argue=20 > why these=20 > should be in this working group rather than elsewhere in the IETF.=20 >=20 > Ross Hi Ross, Not sure if you are referring above to my recent posting = (responding to questions from Chris Lewis) on the thread 'RE: End to end = QoS guarantee for users in VPN'? But yes, I agree with you that QoS = (whatever that really means....since I think different people have = different interpretations of QoS) is not specific to VPNs. But in = general the solutions required for private network services are not the = same as those for public network services, as I attempted to explain in = my recent posting, eg the difference between an 'urgency' and = 'importance' semantic (which is not absolute), and is not just a 'pkt = attribute' in any case, and the implications of BW sharing between QoS = classes on an operator's ability to create fair/meaningful and = appropriately priced services. We (in BT) are having a real dilemma at present in trying to work out = just 'who' the target audience is for certain work items in IETF.....esp = in PWE3; please see the PWE3 thread 'RE: [PWE3] New PWE3 Charter Items: = SPVC Interworking'. I have taken the liberty of copying-in the PWE3 WG = on this mail for their information. In our view the requirements for the Internet as-is are very different = from those of an operator like BT. Not sure how to sort this out.....but we for sure need a more = rigorous/complete and more service-oriented approach to dealing with = certain topics (this being one of them) than has been done to date in = IETF......it seems (to us at least) that the IETF, given its current = modus operandi and assuming this does not change, may not be the right = place to do this sort of work. regards, Neil BT/GS/CTO From exim@www1.ietf.org Thu Feb 26 14:32:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04407 for ; Thu, 26 Feb 2004 14:32:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwREZ-0003gV-S8 for l3vpn-archive@odin.ietf.org; Thu, 26 Feb 2004 14:31:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QJVl83014163 for l3vpn-archive@odin.ietf.org; Thu, 26 Feb 2004 14:31:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwREZ-0003gM-Nf for l3vpn-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 14:31: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 OAA04398 for ; Thu, 26 Feb 2004 14:31:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwREX-000333-00 for l3vpn-web-archive@ietf.org; Thu, 26 Feb 2004 14:31:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRDc-0002yH-00 for l3vpn-web-archive@ietf.org; Thu, 26 Feb 2004 14:30:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwRD0-0002tL-00 for l3vpn-web-archive@ietf.org; Thu, 26 Feb 2004 14:30:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRCt-0003TB-OC; Thu, 26 Feb 2004 14:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRCm-0003Rq-E9 for l3vpn@optimus.ietf.org; Thu, 26 Feb 2004 14:29:56 -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 OAA04301 for ; Thu, 26 Feb 2004 14:29:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRCj-0002sq-00 for l3vpn@ietf.org; Thu, 26 Feb 2004 14:29:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRC1-0002n7-00 for l3vpn@ietf.org; Thu, 26 Feb 2004 14:29:10 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AwRB9-0002Zt-00 for l3vpn@ietf.org; Thu, 26 Feb 2004 14:28:15 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1QJRjBm001524 for ; Thu, 26 Feb 2004 11:27:45 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp083.static.jnpr.net [172.24.253.83]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1QJRio78826 for ; Thu, 26 Feb 2004 11:27:44 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040226142551.02f354f8@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 26 Feb 2004 14:27:25 -0500 To: l3vpn@ietf.org From: Ross Callon Subject: End of WG Last Call: draft-ietf-l3vpn-mpls-vpn-mib-01 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 This ends the working group last call on draft-ietf-l3vpn-mpls-vpn-mib-01. Thanks, Ross At 01:42 PM 1/30/2004 -0500, Ronald Bonica wrote: >Folks, > >This message initiates a WG last call on draft-ietf-l3vpn-mpls-vpn-mib-01. >The last call will end on February 13. > > Ron > > >-----Original Message----- >From: l3vpn-admin@ietf.org [mailto:l3vpn-admin@ietf.org]On Behalf Of >Internet-Drafts@ietf.org >Sent: Friday, January 30, 2004 11:50 AM >To: IETF-Announce: >Cc: l3vpn@ietf.org >Subject: I-D ACTION:draft-ietf-l3vpn-mpls-vpn-mib-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Layer 3 Virtual Private Networks Working >Group of the IETF. > > Title : MPLS/BGP Layer 3 Virtual Private Network Management Information >Base Using > Author(s) : T. Nadeau > Filename : draft-ietf-l3vpn-mpls-vpn-mib-01.txt > Pages : 35 > Date : 2004-1-29 > >