From exim@www1.ietf.org Tue Jan 20 19:41:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03797 for ; Tue, 20 Jan 2004 19:41:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj6QB-0003Id-HQ for vpn-dir-archive@odin.ietf.org; Tue, 20 Jan 2004 19:40:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L0edQ2012680 for vpn-dir-archive@odin.ietf.org; Tue, 20 Jan 2004 19:40:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj6QB-0003IR-AT for vpn-dir-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 19:40: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 TAA03781 for ; Tue, 20 Jan 2004 19:40:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj6Q9-0001zx-00 for vpn-dir-web-archive@ietf.org; Tue, 20 Jan 2004 19:40:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj6PG-0001xs-00 for vpn-dir-web-archive@ietf.org; Tue, 20 Jan 2004 19:39:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj6Oa-0001vs-00 for vpn-dir-web-archive@ietf.org; Tue, 20 Jan 2004 19:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj6Ob-0003GX-AT; Tue, 20 Jan 2004 19:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj6OH-0003GL-2y for vpn-dir@optimus.ietf.org; Tue, 20 Jan 2004 19:38: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 TAA03728 for ; Tue, 20 Jan 2004 19:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj6OF-0001uZ-00 for vpn-dir@ietf.org; Tue, 20 Jan 2004 19:38:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj6NL-0001sj-00 for vpn-dir@ietf.org; Tue, 20 Jan 2004 19:37:44 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1Aj6MW-0001nd-00 for vpn-dir@ietf.org; Tue, 20 Jan 2004 19:36:52 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0L0Zp6t168428; Tue, 20 Jan 2004 19:36:01 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-143-47.mts.ibm.com [9.49.143.47]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0L0Zep1122584; Tue, 20 Jan 2004 17:35:40 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0L0ZVV07875; Tue, 20 Jan 2004 19:35:31 -0500 Message-Id: <200401210035.i0L0ZVV07875@cichlid.raleigh.ibm.com> To: Ross Callon cc: vpn-dir@ietf.org Subject: Re: draft-touch-ipsec-vpn-06.txt In-Reply-To: Message from rcallon@juniper.net of "Sun, 21 Sep 2003 23:40:33 EDT." <4.3.2.20030921233800.02bc4e90@zircon.juniper.net> Date: Tue, 20 Jan 2004 19:35:31 -0500 From: Thomas Narten Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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 autolearn=no version=2.60 Hi Ross. Digging through some old mail, I have this note. This document has come up to the IESG again for approval as an informational document and will be discussed Thursday. If there is a problem with publishing this, we need to be specific about why not. If this conflicts with existing WG work and it would be better to delay publication until after some RFCs are published, that is a possibility, but we will need to have cause Can one of you review (or get someone to review) this to see if you have any real issues? Thomas Ross Callon writes: > At 03:39 PM 9/19/2003 -0400, Thomas Narten wrote: > >Ron, Russ and Rick: > > > >Has this document been discussed in the VPN WGs at all? Is there any > >issue with publishing them as informational? (Joe has asked the RFC > >editor to publish them as info documents). > > > >Thomas > I have a problem with this being published as an RFC in any > form, prior to proper working group review. We have in the past > (in the IETF) had a number of cases of people publishing things > as informational in order to get around the need for IETF review. > While I understand why people want to avoid having their work > reviewed, I don't think that this is something that we should > encourage. In some cases in fact the document that was > published as informational was fine. In some other cases the > approach was fine, but the spec was incomplete. In a few > cases the approach had flaws. > Note that I don't actually know whether there is anything that > should be changed in the document (in a very quick look this > evening I didn't see any problems with the actual approach). > However, I don't think that it is correct to let them subvert the > process. There are numerous places in the ppvpn working group > minutes where the document has been referred to, in one case > as a reason to avoid progressing a different document. How can > someone say "we have an alternate document, which we are > not going to discuss, but this other document is the reason that > the working group shouldn't progress your document"? This > doesn't seem like a valid process to me. > Thus I think that both the L3VPN working group and the IPSec > working group should explicitly review the draft before it is > published as an RFC in any form. > While I am not aware of it being explicitly discussed, it has > apparently come up by reference in a number of discussions, > and appears to have been presented once during a different > presentation in spite of not appearing on the agenda. > This is what I was able to find looking through one minutes > (I only looked back as far as IETF 49): > From the minutes of IETF 56, during the discussion of > draft-declercq-ppvpn-ce-based-sol-00. > Joe Touch: We have running code that is similar to this draft, except > it is push-based, and not pull-based. Also it has not been cited as > reference. 90% is similar to this document, 10 % is different. We have > running code. > There was a brief reference in passing in IETF 55 during the > discussion of IPsec protected Virtual Links for PPVPNs > (Mark Duffy). (again this was along the line of "how can you > progress a document as a working group document when it > doesn't conform to this non-working-group document). > From the minutes of IETF 53, March 2002: > Joe Touch gave a background for dynamic routing for IPSec transport mode. > Didn't go to standards track to avoid confusion to already existing RFC 2401 > (and therefore informational). > This seemed to have occurred during or just after a presentation of > draft-knight-ppvpn-ipsec-dynroute-00.txt > The alleged reason for not going standards track doesn't make sense > to me. > During the 51st IETF (London, August 2001), in the discussion > of draft-declercq-ppvpn-ce-based-00.txt (renamed as > draft-ietf-ppvpn-ce-based-00.txt) there was a mention: > Can use IPSec in tunnel mode (ipsec does SA selection, encapsulation > and authentication/encryption) or transport mode (draft-touch-ipsec-..). > During the 50th IETF, during a discussion of "Use of IPSEC with PPVPN" (Bryan Gleeson, > draft-gleeson-IPSec-ppVPN-00.txt): > Comment - Joe Touch: This has been addressed in my draft. Read draft-touch-IPSec-VPN-01.txt > (used IP-in-IP encapsulation within IPSec transport mode). > Ross _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir From exim@www1.ietf.org Tue Jan 20 22:58:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09101 for ; Tue, 20 Jan 2004 22:58: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 1Aj9Ux-0005VY-0C for vpn-dir-archive@odin.ietf.org; Tue, 20 Jan 2004 22:57:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L3vkhE021171 for vpn-dir-archive@odin.ietf.org; Tue, 20 Jan 2004 22:57:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj9Uw-0005VO-SQ for vpn-dir-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 22:57: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 WAA09086 for ; Tue, 20 Jan 2004 22:57:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj9Ut-0003X9-00 for vpn-dir-web-archive@ietf.org; Tue, 20 Jan 2004 22:57:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj9U0-0003VM-00 for vpn-dir-web-archive@ietf.org; Tue, 20 Jan 2004 22:56:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj9TD-0003TN-00 for vpn-dir-web-archive@ietf.org; Tue, 20 Jan 2004 22:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj9TF-0005KA-C4; Tue, 20 Jan 2004 22:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj9T2-0005JZ-3a for vpn-dir@optimus.ietf.org; Tue, 20 Jan 2004 22:55: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 WAA09032 for ; Tue, 20 Jan 2004 22:55:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj9Sy-0003SA-00 for vpn-dir@ietf.org; Tue, 20 Jan 2004 22:55:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj9S3-0003Qc-00 for vpn-dir@ietf.org; Tue, 20 Jan 2004 22:54:48 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1Aj9RR-0003N2-00 for vpn-dir@ietf.org; Tue, 20 Jan 2004 22:54:09 -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 i0L3rdl70651; Tue, 20 Jan 2004 19:53:39 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp022.static.jnpr.net [172.24.253.22]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i0L3rXh37535; Tue, 20 Jan 2004 19:53:33 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040120214537.0304b048@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 20 Jan 2004 22:29:07 -0500 To: Thomas Narten From: Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt Cc: vpn-dir@ietf.org In-Reply-To: <200401210035.i0L0ZVV07875@cichlid.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 At 07:35 PM 1/20/2004 -0500, Thomas Narten wrote: >Hi Ross. > >Digging through some old mail, I have this note. This document has >come up to the IESG again for approval as an informational document >and will be discussed Thursday. If there is a problem with publishing >this, we need to be specific about why not. The reason is that it defines a protocol which is in the scope of the L3VPN working group, and is in conflict with other work being done by the working group, and yet it has not been reviewed by the l3vpn working group nor by any other working group. I think that the message to the authors of the document should be to take their document to the l3vpn working group, and progress it as a working group item. The fact that Joe Touch has on multiple occasions used the existence of his draft to try to block progression of other l3vpn (or ppvpn) working group items is pretty solid evidence that even he feels that it overlaps considerably with the scope of the l3vpn working group. >If this conflicts with existing WG work and it would be better to >delay publication until after some RFCs are published, that is a >possibility, but we will need to have cause Yes. It does. It specifically overlaps with the CE-based VPN work. See "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec" . >Can one of you review (or get someone to review) this to see if you >have any real issues? I will try to get people to review this. I doubt that other reviewers can get this done by Thursday (but I will ask tonight). I would prefer to send it to the l3vpn working group and ask for the group as a whole to review it (though it would also be a good idea to ask specific people in parallel). If there is any reasonable likelihood that the IESG will approve publication of this draft, I would like to send a message, or have our friendly IESG member send a message, to the l3vpn working group and ask whether people have any comments on the draft, and whether they think that the document should be reviewed by the l3vpn working group prior to publication. Feel free to forward this message to the IESG (I was tempted to CC the IESG on my own). thanks, Ross >Ross Callon writes: > > At 03:39 PM 9/19/2003 -0400, Thomas Narten wrote: > > > >Ron, Russ and Rick: > > > > > >Has this document been discussed in the VPN WGs at all? Is there any > > >issue with publishing them as informational? (Joe has asked the RFC > > >editor to publish them as info documents). > > > > > >Thomas > > > I have a problem with this being published as an RFC in any > > form, prior to proper working group review. We have in the past > > (in the IETF) had a number of cases of people publishing things > > as informational in order to get around the need for IETF review. > > While I understand why people want to avoid having their work > > reviewed, I don't think that this is something that we should > > encourage. In some cases in fact the document that was > > published as informational was fine. In some other cases the > > approach was fine, but the spec was incomplete. In a few > > cases the approach had flaws. > > > Note that I don't actually know whether there is anything that > > should be changed in the document (in a very quick look this > > evening I didn't see any problems with the actual approach). > > > However, I don't think that it is correct to let them subvert the > > process. There are numerous places in the ppvpn working group > > minutes where the document has been referred to, in one case > > as a reason to avoid progressing a different document. How can > > someone say "we have an alternate document, which we are > > not going to discuss, but this other document is the reason that > > the working group shouldn't progress your document"? This > > doesn't seem like a valid process to me. > > > Thus I think that both the L3VPN working group and the IPSec > > working group should explicitly review the draft before it is > > published as an RFC in any form. > > > > While I am not aware of it being explicitly discussed, it has > > apparently come up by reference in a number of discussions, > > and appears to have been presented once during a different > > presentation in spite of not appearing on the agenda. > > > This is what I was able to find looking through one minutes > > (I only looked back as far as IETF 49): > > > > From the minutes of IETF 56, during the discussion of > > draft-declercq-ppvpn-ce-based-sol-00. > > > Joe Touch: We have running code that is similar to this draft, except > > it is push-based, and not pull-based. Also it has not been cited as > > reference. 90% is similar to this document, 10 % is different. We have > > running code. > > > > There was a brief reference in passing in IETF 55 during the > > discussion of IPsec protected Virtual Links for PPVPNs > > (Mark Duffy). (again this was along the line of "how can you > > progress a document as a working group document when it > > doesn't conform to this non-working-group document). > > > > From the minutes of IETF 53, March 2002: > > > Joe Touch gave a background for dynamic routing for IPSec transport mode. > > Didn't go to standards track to avoid confusion to already existing RFC 2401 > > (and therefore informational). > > > This seemed to have occurred during or just after a presentation of > > draft-knight-ppvpn-ipsec-dynroute-00.txt > > > The alleged reason for not going standards track doesn't make sense > > to me. > > > > During the 51st IETF (London, August 2001), in the discussion > > of draft-declercq-ppvpn-ce-based-00.txt (renamed as > > draft-ietf-ppvpn-ce-based-00.txt) there was a mention: > > > Can use IPSec in tunnel mode (ipsec does SA selection, encapsulation > > and authentication/encryption) or transport mode (draft-touch-ipsec-..). > > > > During the 50th IETF, during a discussion of "Use of IPSEC with PPVPN" (Bryan Gleeson, > > draft-gleeson-IPSec-ppVPN-00.txt): > > > Comment - Joe Touch: This has been addressed in my draft. Read draft-touch-IPSec-VPN-01.txt > > (used IP-in-IP encapsulation within IPSec transport mode). > > > Ross > > >_______________________________________________ >Vpn-dir mailing list >Vpn-dir@ietf.org >https://www1.ietf.org/mailman/listinfo/vpn-dir _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir From exim@www1.ietf.org Wed Jan 21 01:04:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11710 for ; Wed, 21 Jan 2004 01:04: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 1AjBSw-0002tS-9G for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 01:03:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L63o4p011116 for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 01:03:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBSw-0002tD-2t for vpn-dir-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 01:03: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 BAA11706 for ; Wed, 21 Jan 2004 01:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjBSt-0000ch-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 01:03:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjBS2-0000bC-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 01:02:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjBR9-0000ZA-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 01:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjBRB-0002nL-9Z; Wed, 21 Jan 2004 01: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 1AjBR4-0002n6-VG for vpn-dir@optimus.ietf.org; Wed, 21 Jan 2004 01:01: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 BAA11671 for ; Wed, 21 Jan 2004 01:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjBR2-0000Xy-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 01:01:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjBQ4-0000Vd-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 01:00:53 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AjBPg-0000Tf-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 01:00:28 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjBPg-000PP7-E9; Wed, 21 Jan 2004 06:00:28 +0000 Date: Tue, 20 Jan 2004 17:54:50 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <104101484507.20040120175450@psg.com> To: Thomas Narten CC: Ross Callon , vpn-dir@ietf.org Subject: Re: draft-touch-ipsec-vpn-06.txt In-Reply-To: <200401210035.i0L0ZVV07875@cichlid.raleigh.ibm.com> References: <200401210035.i0L0ZVV07875@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thomas, et al- Rereading the e-mail from Ross, I think the main point is that the document should be brought before the WGs dealing with the related issues (Ross suggests L3VPN and IPSEC). I think this is a reasonable request--a 2-week Last Call with a careful explanation of the reasons should do it, I think. -- Alex http://www.psg.com/~zinin/ Tuesday, January 20, 2004, 4:35:31 PM, Thomas Narten wrote: > Hi Ross. > Digging through some old mail, I have this note. This document has > come up to the IESG again for approval as an informational document > and will be discussed Thursday. If there is a problem with publishing > this, we need to be specific about why not. > If this conflicts with existing WG work and it would be better to > delay publication until after some RFCs are published, that is a > possibility, but we will need to have cause > Can one of you review (or get someone to review) this to see if you > have any real issues? > Thomas > Ross Callon writes: >> At 03:39 PM 9/19/2003 -0400, Thomas Narten wrote: >> >Ron, Russ and Rick: >> > >> >Has this document been discussed in the VPN WGs at all? Is there any >> >issue with publishing them as informational? (Joe has asked the RFC >> >editor to publish them as info documents). >> > >> >Thomas >> I have a problem with this being published as an RFC in any >> form, prior to proper working group review. We have in the past >> (in the IETF) had a number of cases of people publishing things >> as informational in order to get around the need for IETF review. >> While I understand why people want to avoid having their work >> reviewed, I don't think that this is something that we should >> encourage. In some cases in fact the document that was >> published as informational was fine. In some other cases the >> approach was fine, but the spec was incomplete. In a few >> cases the approach had flaws. >> Note that I don't actually know whether there is anything that >> should be changed in the document (in a very quick look this >> evening I didn't see any problems with the actual approach). >> However, I don't think that it is correct to let them subvert the >> process. There are numerous places in the ppvpn working group >> minutes where the document has been referred to, in one case >> as a reason to avoid progressing a different document. How can >> someone say "we have an alternate document, which we are >> not going to discuss, but this other document is the reason that >> the working group shouldn't progress your document"? This >> doesn't seem like a valid process to me. >> Thus I think that both the L3VPN working group and the IPSec >> working group should explicitly review the draft before it is >> published as an RFC in any form. >> While I am not aware of it being explicitly discussed, it has >> apparently come up by reference in a number of discussions, >> and appears to have been presented once during a different >> presentation in spite of not appearing on the agenda. >> This is what I was able to find looking through one minutes >> (I only looked back as far as IETF 49): >> From the minutes of IETF 56, during the discussion of >> draft-declercq-ppvpn-ce-based-sol-00. >> Joe Touch: We have running code that is similar to this draft, except >> it is push-based, and not pull-based. Also it has not been cited as >> reference. 90% is similar to this document, 10 % is different. We have >> running code. >> There was a brief reference in passing in IETF 55 during the >> discussion of IPsec protected Virtual Links for PPVPNs >> (Mark Duffy). (again this was along the line of "how can you >> progress a document as a working group document when it >> doesn't conform to this non-working-group document). >> From the minutes of IETF 53, March 2002: >> Joe Touch gave a background for dynamic routing for IPSec transport mode. >> Didn't go to standards track to avoid confusion to already existing RFC 2401 >> (and therefore informational). >> This seemed to have occurred during or just after a presentation of >> draft-knight-ppvpn-ipsec-dynroute-00.txt >> The alleged reason for not going standards track doesn't make sense >> to me. >> During the 51st IETF (London, August 2001), in the discussion >> of draft-declercq-ppvpn-ce-based-00.txt (renamed as >> draft-ietf-ppvpn-ce-based-00.txt) there was a mention: >> Can use IPSec in tunnel mode (ipsec does SA selection, encapsulation >> and authentication/encryption) or transport mode (draft-touch-ipsec-..). >> During the 50th IETF, during a discussion of "Use of IPSEC with PPVPN" (Bryan Gleeson, >> draft-gleeson-IPSec-ppVPN-00.txt): >> Comment - Joe Touch: This has been addressed in my draft. Read draft-touch-IPSec-VPN-01.txt >> (used IP-in-IP encapsulation within IPSec transport mode). >> Ross > _______________________________________________ > Vpn-dir mailing list > Vpn-dir@ietf.org > https://www1.ietf.org/mailman/listinfo/vpn-dir _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir From exim@www1.ietf.org Wed Jan 21 13:43:47 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02960 for ; Wed, 21 Jan 2004 13:43:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjNJu-00035d-S4 for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 13:43:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LIhIPY011873 for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 13:43:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjNJu-00035Q-Ns for vpn-dir-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 13:43: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 NAA02951 for ; Wed, 21 Jan 2004 13:43:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjNJs-0003rU-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 13:43:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjNIy-0003pb-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 13:42:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjNIf-0003nP-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 13:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjNIg-0002qJ-I8; Wed, 21 Jan 2004 13:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjNHw-0002pT-T2 for vpn-dir@optimus.ietf.org; Wed, 21 Jan 2004 13:41: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 NAA02906 for ; Wed, 21 Jan 2004 13:41:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjNHu-0003mL-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 13:41:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjNH2-0003kQ-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 13:40:21 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1AjNGY-0003gm-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 13:39:50 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0LIcnFn081846; Wed, 21 Jan 2004 13:38:59 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-232-249.mts.ibm.com [9.65.232.249]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0LIccI1148544; Wed, 21 Jan 2004 11:38:38 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0LIcRW02964; Wed, 21 Jan 2004 13:38:28 -0500 Message-Id: <200401211838.i0LIcRW02964@cichlid.raleigh.ibm.com> To: Ross Callon cc: vpn-dir@ietf.org Subject: Re: draft-touch-ipsec-vpn-06.txt In-Reply-To: Message from rcallon@juniper.net of "Tue, 20 Jan 2004 22:29:07 EST." <4.3.2.20040120214537.0304b048@zircon.juniper.net> Date: Wed, 21 Jan 2004 13:38:27 -0500 From: Thomas Narten Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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 I went and reread the document this AM. I don't know that I'd call it a protocol. Looking through some IESG review comments, the one from Bellovin seems on the mark to me: > Here are my (belated) notes on draft-touch-ipsec-vpn-06.txt. They boil > down to the impression that Touch et al. have constructed a straw man > and then designed a mechanism to solve their "problems". I.e., I think the problem is real, but it's also mostly implementation and not protocol stuff, and anyone implementing this stuff would run into this and have to think about what to do. As long as its technically accurate (I saw no obvious bugs), I don't see much harm in letting it go. But I'm fine with getting the WG to look and decide if it has issues with it. Want to go ahead and do that? > The reason is that it defines a protocol which is in the scope of the > L3VPN working group, and is in conflict with other work being done by > the working group, and yet it has not been reviewed by the l3vpn working > group nor by any other working group. I think that the message to the > authors of the document should be to take their document to the l3vpn > working group, and progress it as a working group item. Not sure its really defining a protocol. More like advocating that one should use IPinIP tunneling (with IPSec as part of that) so that virtual links look like real interfaces. > The fact that Joe Touch has on multiple occasions used the existence > of his draft to try to block progression of other l3vpn (or ppvpn) working > group items is pretty solid evidence that even he feels that it overlaps > considerably with the scope of the l3vpn working group. > >If this conflicts with existing WG work and it would be better to > >delay publication until after some RFCs are published, that is a > >possibility, but we will need to have cause > Yes. It does. It specifically overlaps with the CE-based VPN work. > See "An Architecture for Provider Provisioned CE-based Virtual Private > Networks using IPsec" . Looks to me that it overlaps part of this document, but not that much. Specifically, Section 4.2 and 5. Not clear it overlaps much beyond that. > I will try to get people to review this. I doubt that other reviewers can > get this done by Thursday (but I will ask tonight). More time is OK, but we'll need closure within two weeks. > I would prefer to send it to the l3vpn working group and ask for the > group as a whole to review it (though it would also be a good idea to > ask specific people in parallel). Please do so. I will delay approval (if that is what the IESG decides is appropriate) until at least the following telechat. But if there is any chance of getting a review before then, that would help. Thomas _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir From exim@www1.ietf.org Wed Jan 21 16:00:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08274 for ; Wed, 21 Jan 2004 16:00: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 1AjPSW-0003ei-Pe for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 16:00:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LL0KIF014053 for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 16:00:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPSW-0003eO-DR for vpn-dir-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:00:20 -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 QAA08263 for ; Wed, 21 Jan 2004 16:00:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPSU-0001O2-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 16:00:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPRb-0001ML-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 15:59:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPRF-0001KJ-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 15:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPRF-0003SK-1N; Wed, 21 Jan 2004 15:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPQd-0003K9-Br for vpn-dir@optimus.ietf.org; Wed, 21 Jan 2004 15:58: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 PAA08205 for ; Wed, 21 Jan 2004 15:58:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPQb-0001J0-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 15:58:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPPj-0001Gx-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 15:57:27 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AjPPS-0001E9-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 15:57:10 -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 i0LKudBm038511; Wed, 21 Jan 2004 12:56:39 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (rcallon-lt.jnpr.net [10.10.132.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i0LKudh17133; Wed, 21 Jan 2004 12:56:39 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040121152826.030d8028@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 21 Jan 2004 15:39:13 -0500 To: Thomas Narten From: Ross Callon Subject: Fwd: RE: Review needed -- draft-touch-ipsec-vpn-06.txt Cc: vpn-dir@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 These comments came from an internal Juniper person who has worked with IPsec implementations. Since the document came from inside Juniper, it contained some internal stuff, so I am forwarding the pertinent parts. Ross >In a nutshell, the draft suggests that IPsec transport mode should >be used, instead of IPsec tunnel mode, to connect private networks >over a public infrastructure, when dynamic routing is required. > >The "fundamental problems" with the use of IPsec tunnel mode >with dynamic routing, as described by the author, if anything, >seem to be an implementation specific problem. > >Also, I think I recognize this draft. It appeared in the IPsec WG >years ago but people there did not care for it. _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir From exim@www1.ietf.org Wed Jan 21 16:00:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08276 for ; Wed, 21 Jan 2004 16:00: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 1AjPSX-0003f7-4s for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 16:00:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LL0Lok014071 for vpn-dir-archive@odin.ietf.org; Wed, 21 Jan 2004 16:00:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPSX-0003es-0I for vpn-dir-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:00: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 QAA08266 for ; Wed, 21 Jan 2004 16:00:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPSV-0001O7-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 16:00:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPRc-0001MT-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 15:59:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPRF-0001KK-00 for vpn-dir-web-archive@ietf.org; Wed, 21 Jan 2004 15:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPRF-0003Sj-Jn; Wed, 21 Jan 2004 15:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPQe-0003KJ-Jc for vpn-dir@optimus.ietf.org; Wed, 21 Jan 2004 15:58: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 PAA08211 for ; Wed, 21 Jan 2004 15:58:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPQd-0001JA-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 15:58:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPPk-0001HD-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 15:57:28 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AjPPV-0001EB-00 for vpn-dir@ietf.org; Wed, 21 Jan 2004 15:57:13 -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 i0LKuhl73872; Wed, 21 Jan 2004 12:56:43 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (rcallon-lt.jnpr.net [10.10.132.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i0LKubh17123; Wed, 21 Jan 2004 12:56:37 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040121152252.030c5580@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 21 Jan 2004 15:56:18 -0500 To: Thomas Narten From: Ross Callon Subject: Re: draft-touch-ipsec-vpn-06.txt Cc: vpn-dir@ietf.org In-Reply-To: <200401211838.i0LIcRW02964@cichlid.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 At 01:38 PM 1/21/2004 -0500, Thomas Narten wrote: >I went and reread the document this AM. I don't know that I'd call it >a protocol. It sort of depends what you mean by "protocol". I didn't see it as defining a new packet header. However, it does define how two different devices operate to talk to each other. It does imply implementation needed by boxes wanting to communicate, and implies the way that various other existing headers would be used. >...But I'm fine with getting the WG to look and decide if >it has issues with it. Want to go ahead and do that? Okay. I will put together a message for the l3vpn working group. >Not sure its really defining a protocol. More like advocating that >one should use IPinIP tunneling (with IPSec as part of that) so that >virtual links look like real interfaces. It is also proposing very specific ways to do this (which conflict with other work). > > I will try to get people to review this. I doubt that other reviewers can > > get this done by Thursday (but I will ask tonight). > >More time is OK, but we'll need closure within two weeks. I got one review already (less than 24 hours!). I will forward the pertinent parts. > > I would prefer to send it to the l3vpn working group and ask for the > > group as a whole to review it (though it would also be a good idea to > > ask specific people in parallel). > >Please do so. I will delay approval (if that is what the IESG decides >is appropriate) until at least the following telechat. Will do. By the way, who is on "vpn-dir"? Does this include anyone who is not on the l3vpn mailing list, and who would want to see the discussion (if any) over this document? thanks, Ross _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir From exim@www1.ietf.org Tue Jan 27 12:08:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13640 for ; Tue, 27 Jan 2004 12:08: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 1AlWgx-0002ky-Pa for vpn-dir-archive@odin.ietf.org; Tue, 27 Jan 2004 12:08:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RH7xgl010592 for vpn-dir-archive@odin.ietf.org; Tue, 27 Jan 2004 12:07:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWgx-0002kl-1I for vpn-dir-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 12:07: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 MAA13632 for ; Tue, 27 Jan 2004 12:07:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWgv-00077q-00 for vpn-dir-web-archive@ietf.org; Tue, 27 Jan 2004 12:07:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWfz-00074B-00 for vpn-dir-web-archive@ietf.org; Tue, 27 Jan 2004 12:07:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlWf6-00070R-00 for vpn-dir-web-archive@ietf.org; Tue, 27 Jan 2004 12:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWf3-0002QR-Vw; Tue, 27 Jan 2004 12:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWew-0002PS-3O for vpn-dir@optimus.ietf.org; Tue, 27 Jan 2004 12:05: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 MAA13557 for ; Tue, 27 Jan 2004 12:05:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWeu-0006zA-00 for vpn-dir@ietf.org; Tue, 27 Jan 2004 12:05:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWe4-0006w0-00 for vpn-dir@ietf.org; Tue, 27 Jan 2004 12:05:01 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AlWdh-0006rd-00 for vpn-dir@ietf.org; Tue, 27 Jan 2004 12:04:37 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0RH3D4E297512; Tue, 27 Jan 2004 12:03:23 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-226-191.mts.ibm.com [9.65.226.191]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0RH2nba154890; Tue, 27 Jan 2004 10:02:54 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0RH2AJ05563; Tue, 27 Jan 2004 12:02:17 -0500 Message-Id: <200401271702.i0RH2AJ05563@cichlid.raleigh.ibm.com> To: "Rick Wilder" , Ross Callon , Ron Bonica cc: vpn-dir@ietf.org Subject: 2447bis and related documents Date: Tue, 27 Jan 2004 12:02:09 -0500 From: Thomas Narten Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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 I've spent some time recently reviewing some related documents: draft-ietf-l3vpn-rfc2547bis-01.txt draft-ietf-l3vpn-as2547-03.txt draft-ietf-l3vpn-as-vr-00.txt draft-ietf-l3vpn-applicability-guidelines-00.txt I have some general questions that may develop into concerns, but for now may just stem from a lack of understanding and history. I started with draft-ietf-l3vpn-as2547-03.txt, and must say I didn't really find the document that illuminating. What I would have expected from an applicability statement is a "here is where you use this stuff, and here is where you don't" (perhaps with a "why and why not" to go along with the statements). Also, given that there are at least two competing solutions, I'd expect an attempt at making it clear where one would be used vs. the other, so an operator could easily understand why there are two approaches and what the percieved major differences are. What I found instead was more of a general overview of the protocol and mechanisms. A fair amount of the discussion in as2547 is in the 2547bis itself (which doesn't seem like what the goal should be). Also what, could have been more clear is just what the assumptions were for this technology. E.g.: From a customer perspective: - customer must run an IGP or BGP with SP (in order to inject/receive routes) - customer wants SP to handle the routing across backbone, and just wants to treat the backbone as an opaque cloud of sorts, where the details of how routing is done is handled by the SP. - customer doesn't want to deal with setting up tunnels between CEs and managing the logicahl interconnects - how the SP actually provides the service is something the customer doesn't care about (which is I think a true statement in general) Is there more to the this than the above? Am I missing something pretty basic? From an ISP perspective, I wasn't immediately sure why one would start with BGP, other than perhaps because they already are using it and understand it well, _and_ that they have MPLS. Indeed, I'm a bit confused about the way the documents try to say one doesn't have to run MPLS (citing draft-ietf-mpls-in-ip-or-gre-03.txt) as if it was NOT MPLS. How can this be? One absolutely must support the MPLS labeling scheme, or this stuff just doesn't work. That is, MPLS in IP is still MPLS. Right? (What am I missing here.) Looking further, I then see that the AS is modeled after: draft-ietf-l3vpn-as-vr-00.txt which contains a number of questions to answer about a proposed solutions. Both AS documents do this, but they tend to say hand-wavy things like "you can run IPsec here" or this or that, as a way to mitigate. Have others read the AS and are you happy with what it says? Thomas _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir From exim@www1.ietf.org Tue Jan 27 17:18:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26759 for ; Tue, 27 Jan 2004 17:18:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbX9-00082B-Fo for vpn-dir-archive@odin.ietf.org; Tue, 27 Jan 2004 17:18:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RMIB06030882 for vpn-dir-archive@odin.ietf.org; Tue, 27 Jan 2004 17:18:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbX9-000821-6A for vpn-dir-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 17:18: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 RAA26732 for ; Tue, 27 Jan 2004 17:18:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlbX6-0005Mj-00 for vpn-dir-web-archive@ietf.org; Tue, 27 Jan 2004 17:18:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlbVz-0005Ds-00 for vpn-dir-web-archive@ietf.org; Tue, 27 Jan 2004 17:17:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlbV1-0005Ag-00 for vpn-dir-web-archive@ietf.org; Tue, 27 Jan 2004 17:15:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbV3-0007z3-2d; Tue, 27 Jan 2004 17:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbU7-0007yW-EU for vpn-dir@optimus.ietf.org; Tue, 27 Jan 2004 17:15: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 RAA26644 for ; Tue, 27 Jan 2004 17:14:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlbU5-00056h-00 for vpn-dir@ietf.org; Tue, 27 Jan 2004 17:15:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlbT7-00052D-00 for vpn-dir@ietf.org; Tue, 27 Jan 2004 17:14:01 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AlbSQ-0004wJ-00 for vpn-dir@ietf.org; Tue, 27 Jan 2004 17:13:18 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0RMCDb9277252; Tue, 27 Jan 2004 17:12:23 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-219-63.mts.ibm.com [9.65.219.63]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0RMC1ba160826; Tue, 27 Jan 2004 15:12:02 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0RMBeV07390; Tue, 27 Jan 2004 17:11:40 -0500 Message-Id: <200401272211.i0RMBeV07390@cichlid.raleigh.ibm.com> To: Ross Callon cc: vpn-dir@ietf.org Subject: vpn-dir membership In-Reply-To: Message from rcallon@juniper.net of "Wed, 21 Jan 2004 15:56:18 EST." <4.3.2.20040121152252.030c5580@zircon.juniper.net> Date: Tue, 27 Jan 2004 17:11:40 -0500 From: Thomas Narten Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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 Ross Callon writes: > By the way, who is on "vpn-dir"? Does this include anyone who is not > on the l3vpn mailing list, and who would want to see the discussion (if > any) over this document? Alex has access to the definitive list, but my recollection is that it is the pwe3/l2vpn/l3vpn/l2tpext chairs, plus Russ (as technical advisor). And me/Alex/Margaret. Thomas _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir From exim@www1.ietf.org Sat Jan 31 21:55:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19648 for ; Sat, 31 Jan 2004 21:55:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7le-0000Dv-3X for vpn-dir-archive@odin.ietf.org; Sat, 31 Jan 2004 21:55:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i112tQp4000853 for vpn-dir-archive@odin.ietf.org; Sat, 31 Jan 2004 21:55:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7ld-0000Dg-UR for vpn-dir-web-archive@optimus.ietf.org; Sat, 31 Jan 2004 21:55: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 VAA19638 for ; Sat, 31 Jan 2004 21:55:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An7lb-0007cg-00 for vpn-dir-web-archive@ietf.org; Sat, 31 Jan 2004 21:55:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An7kd-0007XZ-00 for vpn-dir-web-archive@ietf.org; Sat, 31 Jan 2004 21:54:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1An7kF-0007Si-00 for vpn-dir-web-archive@ietf.org; Sat, 31 Jan 2004 21:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7kG-0000CB-S7; Sat, 31 Jan 2004 21:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7jg-0000Aj-MZ for vpn-dir@optimus.ietf.org; Sat, 31 Jan 2004 21:53: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 VAA19559 for ; Sat, 31 Jan 2004 21:53:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An7jd-0007Rl-00 for vpn-dir@ietf.org; Sat, 31 Jan 2004 21:53:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An7ij-0007Lf-00 for vpn-dir@ietf.org; Sat, 31 Jan 2004 21:52:25 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1An7iB-0007De-00 for vpn-dir@ietf.org; Sat, 31 Jan 2004 21:51:51 -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 i112pLBm093853; Sat, 31 Jan 2004 18:51:21 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp177.static.jnpr.net [172.24.253.177]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i112pKh16621; Sat, 31 Jan 2004 18:51:21 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040130142850.01383b48@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 31 Jan 2004 21:49:30 -0500 To: Thomas Narten From: Ross Callon Subject: 2547 over "not MPLS" (Re: 2447bis and related documents) Cc: vpn-dir@ietf.org In-Reply-To: <200401271702.i0RH2AJ05563@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 >Indeed, I'm a bit confused about the way the documents try to say one >doesn't have to run MPLS (citing draft-ietf-mpls-in-ip-or-gre-03.txt) >as if it was NOT MPLS. How can this be? One absolutely must support >the MPLS labeling scheme, or this stuff just doesn't work. That is, >MPLS in IP is still MPLS. Right? (What am I missing here.) The answer to this question is a bit less controversial and more straightforward than the answers to the rest of your message, so I figured I would start with this part. Basically the answer depends upon what you mean by "MPLS", and in which of your routers you are willing to run it. In terms of encapsulation, for each packet which is transmitted "in the VPN" (ie, each packet which is from a VPN site, to a VPN site, and is being transported across the service provider), the BGP/MPLS VPN solution requires that (i) the packet be encapsulated in an MPLS header; (ii) *some* additional encapsulation (MPLS or IPsec or MPLS-in-GRE-in-IP or MPLS-in-IP) be used to get the VPN packet, encapsulated in the MPLS header, to the appropriate PE router. Thus in the most basic form some use of MPLS is needed. However, strictly speaking this is only *required* in the PE routers, and only in those specific PE routers which are directly implementing BGP/MPLS VPNs. Also, all of the signalling regarding which labels to use for this particular "PE only" MPLS headers is done with BGP, so that no additional MPLS signaling protocol is required. If a second MPLS header is used for transmitting the packets across the provider backbone, then (i) The provider core routers need to also implement MPLS; and (ii) An additional MPLS signaling protocol (either LDP or RSVP, or both) needs to be run across the network, from PE router to P router to P router to PE router. This requires more configuration, and in many cases implies that routers from multiple companies interoperate (there are many multi-vendor deployments of MPLS, but this doesn't necessarily mean that every service provider feels comfortable with the interoperability of every combination of vendors that they might have deployed in their network). In the past I have talked to a small number of service providers (but not necessarily small service providers) who were reluctant to turn on MPLS signaling on all of their P and PE routers, and who were therefore at least pondering the possibility of running 2547 using the "private packet over MPLS over GRE over IP" encapsulation. I am under the impression that there are some deployments of this, including multi-vendor deployments, although I don't know how much. Ross _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir From exim@www1.ietf.org Sat Jan 31 21:55:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19651 for ; Sat, 31 Jan 2004 21:55:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7le-0000EG-L9 for vpn-dir-archive@odin.ietf.org; Sat, 31 Jan 2004 21:55:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i112tQ25000874 for vpn-dir-archive@odin.ietf.org; Sat, 31 Jan 2004 21:55:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7le-0000E0-Gv for vpn-dir-web-archive@optimus.ietf.org; Sat, 31 Jan 2004 21:55: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 VAA19641 for ; Sat, 31 Jan 2004 21:55:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An7lb-0007cl-00 for vpn-dir-web-archive@ietf.org; Sat, 31 Jan 2004 21:55:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An7ke-0007Xh-00 for vpn-dir-web-archive@ietf.org; Sat, 31 Jan 2004 21:54:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1An7kF-0007Sj-00 for vpn-dir-web-archive@ietf.org; Sat, 31 Jan 2004 21:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7kH-0000CP-0E; Sat, 31 Jan 2004 21:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1An7jh-0000Ak-9M for vpn-dir@optimus.ietf.org; Sat, 31 Jan 2004 21:53: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 VAA19562 for ; Sat, 31 Jan 2004 21:53:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1An7je-0007Rq-00 for vpn-dir@ietf.org; Sat, 31 Jan 2004 21:53:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1An7ij-0007Ln-00 for vpn-dir@ietf.org; Sat, 31 Jan 2004 21:52:26 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1An7iB-0007Ev-00 for vpn-dir@ietf.org; Sat, 31 Jan 2004 21:51:51 -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 i112pMBm093858; Sat, 31 Jan 2004 18:51:22 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp177.static.jnpr.net [172.24.253.177]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i112pLh16624; Sat, 31 Jan 2004 18:51:22 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040130150047.02ed1aa0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 31 Jan 2004 21:46:25 -0500 To: Thomas Narten From: Ross Callon Subject: Security Question (Re: 2447bis and related documents) Cc: vpn-dir@ietf.org In-Reply-To: <200401271702.i0RH2AJ05563@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: vpn-dir-admin@ietf.org Errors-To: vpn-dir-admin@ietf.org X-BeenThere: vpn-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: VPN Directorate 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.0 required=5.0 tests=AWL,FORGED_MUA_EUDORA autolearn=no version=2.60 >Looking further, I then see that the AS is modeled after: > draft-ietf-l3vpn-as-vr-00.txt > >which contains a number of questions to answer about a proposed >solutions. Both AS documents do this, but they tend to say hand-wavy >things like "you can run IPsec here" or this or that, as a way to >mitigate. > >Have others read the AS and are you happy with what it says? The questions are actually taken from the VPN security framework. The applicability statement for BGP/MPLS L3 VPNs was done before the AS for VRs. Thus it is natural that the authors of the VR AS may have taken a look at the other document before they wrote their AS. I think that the correct answer to a lot of these questions is that the way to secure VPNs in various ways involves use of other protocols or products or product features. Thus referring to other protocols which can be used in conjunction with BGP/MPLS VPNs seems straightforward to me. Ross _______________________________________________ Vpn-dir mailing list Vpn-dir@ietf.org https://www1.ietf.org/mailman/listinfo/vpn-dir