From l3vpn-bounces@ietf.org Fri Oct 1 13:45:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00109 for ; Fri, 1 Oct 2004 13:45:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRbr-0005Ph-0P for l3vpn-web-archive@ietf.org; Fri, 01 Oct 2004 13:54:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDR5i-0005FA-T1; Fri, 01 Oct 2004 13:21:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQcr-0007BP-3H for l3vpn@megatron.ietf.org; Fri, 01 Oct 2004 12:51:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23751 for ; Fri, 1 Oct 2004 12:51:18 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQlK-0003A9-Jo for l3vpn@ietf.org; Fri, 01 Oct 2004 13:00:07 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i91GoEJ26907; Fri, 1 Oct 2004 09:50:14 -0700 (PDT) Message-ID: <415D8B35.8020702@isi.edu> Date: Fri, 01 Oct 2004 09:52:05 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org References: <200409301953.PAA24365@ietf.org> In-Reply-To: <200409301953.PAA24365@ietf.org> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig41B370B36AF0CCA4C49BE640" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: Re: I-D ACTION:draft-ietf-l3vpn-ipsec-2547-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig41B370B36AF0CCA4C49BE640 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > 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 : Use of PE-PE IPsec in RFC2547 VPNs > Author(s) : E. Rosen, et al. > Filename : draft-ietf-l3vpn-ipsec-2547-03.txt > Pages : 17 > Date : 2004-9-30 Regarding use of transport mode IPsec to secure tunnels, FYI, our ID has (finally) been issued as an RFC: RFC3884: Use of IPsec Transport Mode for Dynamic Routing Joe --------------enig41B370B36AF0CCA4C49BE640 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBXYs6E5f5cImnZrsRAknIAKCqW60JS5Q7ipoRjD4Q1+IjQa47GACgoO5F xOv2Ar9IVDpwsj8NKnaCynY= =deFp -----END PGP SIGNATURE----- --------------enig41B370B36AF0CCA4C49BE640-- From l3vpn-bounces@ietf.org Fri Oct 1 14:44:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05872 for ; Fri, 1 Oct 2004 14:44:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDSX7-0007KB-Ps for l3vpn-web-archive@ietf.org; Fri, 01 Oct 2004 14:53:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDS5A-0006br-L2; Fri, 01 Oct 2004 14:24:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRpb-00061b-Qk for l3vpn@megatron.ietf.org; Fri, 01 Oct 2004 14:08:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02618 for ; Fri, 1 Oct 2004 14:08:32 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRy5-0006Ew-R7 for l3vpn@ietf.org; Fri, 01 Oct 2004 14:17:23 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i91I6uJ18548; Fri, 1 Oct 2004 11:06:56 -0700 (PDT) Message-ID: <415D9D35.4040303@isi.edu> Date: Fri, 01 Oct 2004 11:08:53 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org, ppvpn@nortelnetworks.com References: In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8EFEFBCAFBC0D70BF6D6C205" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: Re: WG mailing list X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8EFEFBCAFBC0D70BF6D6C205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI - the following RFC has (finally) been published; it would be useful to update pending docs that refer to our earlier ID. 3884 Use of IPsec Transport Mode for Dynamic Routing. J. Touch, L. Eggert, Y. Wang. September 2004. (Format: TXT=59437 bytes) (Status: INFORMATIONAL) Joe --------------enig8EFEFBCAFBC0D70BF6D6C205 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBXZ01E5f5cImnZrsRAnNEAJ9c+64jd5vldzB1uoyIoTNvTHyQ7wCgsKhd HzjX8bzDX7WcDpDtNtO5zos= =tLWS -----END PGP SIGNATURE----- --------------enig8EFEFBCAFBC0D70BF6D6C205-- From l3vpn-bounces@ietf.org Tue Oct 5 16:04:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03937 for ; Tue, 5 Oct 2004 16:04:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEvhR-0004A6-V1 for l3vpn-web-archive@ietf.org; Tue, 05 Oct 2004 16:14:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvGR-0007DS-QX; Tue, 05 Oct 2004 15:46:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvA5-0004bt-IV; Tue, 05 Oct 2004 15:39:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00917; Tue, 5 Oct 2004 15:39:47 -0400 (EDT) Message-Id: <200410051939.PAA00917@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 05 Oct 2004 15:39:47 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-as2547-07.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --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 BGP/MPLS IP VPNs Author(s) : E. Rosen Filename : draft-ietf-l3vpn-as2547-07.txt Pages : 32 Date : 2004-10-5 This document provides an Applicability Statement for the VPN solution described in [BGP-MPLS-IP-VPN] and other documents listed in the References section. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-as2547-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-as2547-07.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-as2547-07.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-10-5160454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-as2547-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-as2547-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-5160454.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Tue Oct 5 16:08:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04517 for ; Tue, 5 Oct 2004 16:08:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEvl3-0004l7-13 for l3vpn-web-archive@ietf.org; Tue, 05 Oct 2004 16:18:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvGU-0007EL-Ox; Tue, 05 Oct 2004 15:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvA9-0004dC-Ic; Tue, 05 Oct 2004 15:39:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00924; Tue, 5 Oct 2004 15:39:51 -0400 (EDT) Message-Id: <200410051939.PAA00924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 05 Oct 2004 15:39:51 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-rfc2547bis-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --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 : BGP/MPLS IP VPNs Author(s) : E. Rosen, Y. Rekhter Filename : draft-ietf-l3vpn-rfc2547bis-03.txt Pages : 49 Date : 2004-10-5 This document describes a method by which a Service Provider may use an IP backbone to provide IP VPNs (Virtual Private Networks) for its customers. This method uses a "peer model", in which the customers' edge routers ("CE routers") send their routes to the Service Provider's edge routers ("PE routers"); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. This document obsoletes RFC 2547. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rfc2547bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2547bis-03.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-rfc2547bis-03.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-10-5160500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-rfc2547bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-rfc2547bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-5160500.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Wed Oct 6 00:11:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15417 for ; Wed, 6 Oct 2004 00:11:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF3IZ-0003lF-Dl for l3vpn-web-archive@ietf.org; Wed, 06 Oct 2004 00:21:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF37n-0005Pi-9v; Wed, 06 Oct 2004 00:09:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF36Q-00055n-Ix for l3vpn@megatron.ietf.org; Wed, 06 Oct 2004 00:08:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15248 for ; Wed, 6 Oct 2004 00:08:31 -0400 (EDT) Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF3Fn-0003fg-Kj for l3vpn@ietf.org; Wed, 06 Oct 2004 00:18:19 -0400 Received: from MDUFFY1.quarrytech.com (rocket.quarrytech.com [10.1.1.127]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N87X5C0L; Wed, 6 Oct 2004 00:07:59 -0400 Message-Id: <6.1.2.0.2.20041005225652.02f8fcf8@localhost> X-Sender: mduffy@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 06 Oct 2004 00:04:11 -0400 To: Ronald Bonica , l3vpn@ietf.org From: Mark Duffy In-Reply-To: <00cc01c4a0ba$fcefed40$da932799@mcilink.com> References: <00cc01c4a0ba$fcefed40$da932799@mcilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: Re: Last call: draft-ietf-l3vpn-ipsec-2547-02 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 At 11:44 AM 9/22/2004, Ronald Bonica wrote: >Folks, > >This email begins a WG Last Call on draft-ietf-l3vpn-ipsec-2547-02. The >authors have recommended that this draft be published as an Experimental >RFC. Last call will end on October 5, 2004. It's great to see this document move forward! I have several comments, below. (They are relative to the -03 draft, which appeared shortly after the last call was issued.) --------------- In sect. 2.2, 2nd paragraph, it says "In an RFC2547 VPN environment, it makes most sense to place control of the policies with the egress PE router." I don't necessarily disagree with this but I believe the document should offer some arguments in support of this statement, since it is the basis for much of what follows. Just because this is convenient to implement doesn't necessarily mean it is the most desirable. In 2.2, 3rd paragraph, I don't understand what the last sentence means: (However, in this sort of application the ingress PE and the egress PE are NOT really independent entities which might conceivably have different security policies.) Perhaps it can be reworded. The document calls (sect. 2.3) for using an Extended Community to signal the requirement to use IPsec for certain VPN routes. But it is vague on exactly what the semantics should be and there is no allocation of a community type. As such this does not do much to encourage interoperable implementations. I don't know, maybe this is par for the course for Experimental RFC status? Or should it be specified further now? Besides using the (rather blunt, IMO) technique of not accepting labeled packets from outside the SP's network, it is difficult (impossible?) to create a mixed environment where some traffic is protected by IPsec and some is not. This is because there is no way of knowing which PE the unprotected traffic came from, and hence no way of making sure traffic that was supposed to be protected isn't slipped in with the unprotected. If the draft could address this problem in some way (perhaps a lowered expectation of supporting such a mixed environment) it would be more credible. In sect 2.6 para 3, discussing whether IPsec SAs should be per-PE-pair or per-VPN it says "Since the SA is PE-to-PE, NOT CE-to-CE, having a different SA for each VPN does not provide any additional security." While I agree that per-PE-pair seems to be the right granularity for other reasons, I disagree with the statement about not providing additional security. Sharing an SA across multiple VPNs allows an adversary who can send traffic within one VPN and also sniff the PE-PE link to mount a known-plaintext attack against the encryption. In sect 2.6 para 6 it says that the PE router should deliver the MPLS-in-IP (or GRE) packet to the IPsec module, along with the corresponding IPsec Extended Community value. What is reason for passing the extended community? What information does it convey that the IPsec module would need? Re sect 2.6: Assuming a given PE device implements IPsec for other applications, how is the IKE Responder to determine the purpose of a given SA (so that it knows how to process packets received from the SA, and so it knows that it can send VPN packets on the SA)? If the negotiated traffic selectors are for protocol MPLS-in-IP, it could *perhaps* deduce this. But that's an even bigger stretch if the SA is negotiated for protocol GRE. There are other possible solutions, perhaps deducing the SA is for BGP/MPLS VPN use if the signalling is directed to the IP address that is advertised as the BGP next hop address. Another possibility might be to define an IKE payload to convey this. In any event, calling out one specific mechanism would encourage interoperable implementations. In sect. 2.7, item b.iii, it describes case iii relative to item b.ii ("... but case ii does not apply"). I suspect that not every reader ;-) would reach the same conclusion as to what case this actually covers. Can the case be spelled out more specifically? I think replacing "but case ii does not apply" with "indicating that IPsec is to be used in all cases" would do the trick. The last 2 paragraphs of sect. 2.7 are very implementation-oriented. I don't see that they really add much to the document; I'd consider removing them. Nits: Many of the references to RFC2547 VPNs have been replaced by references to BGP/MPLS IP VPNs. It would be nice to fix the rest. In the 6th paragraph of sect. 1, where it is discussing ingress and egress PEs directly adjacent and says "... even in the case where a backbone route label would not be used" it seems to assume that PHP must always be used. "... even in the case where a backbone route label *might* not be used" would be more appropriate. In sect 1.4 para 2, s/is the one way/is one way/ s/to connecting a/to connect a/ Thanks, Mark From l3vpn-bounces@ietf.org Wed Oct 6 05:24:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05505 for ; Wed, 6 Oct 2004 05:24:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF8C7-0003a5-So for l3vpn-web-archive@ietf.org; Wed, 06 Oct 2004 05:34:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF82C-000502-Ad; Wed, 06 Oct 2004 05:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF80p-0004sa-O5 for l3vpn@megatron.ietf.org; Wed, 06 Oct 2004 05:23:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05482 for ; Wed, 6 Oct 2004 05:23:05 -0400 (EDT) Received: from web60901.mail.yahoo.com ([216.155.196.77]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CF8AH-0003Pz-DS for l3vpn@ietf.org; Wed, 06 Oct 2004 05:32:55 -0400 Message-ID: <20041006092235.58729.qmail@web60901.mail.yahoo.com> Received: from [61.16.170.194] by web60901.mail.yahoo.com via HTTP; Wed, 06 Oct 2004 10:22:35 BST Date: Wed, 6 Oct 2004 10:22:35 +0100 (BST) From: Spice Sylvia To: l3vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit Subject: draft-ietf-l3vpn-rt-constrain-01.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 8bit Hello folks in the draft, given that AS#RT# froms a NLRI, a. Is it possible to have only the AS#RT#s avaliable on a node and based on the fact that someone does an import of that RT#, the prefixes should be fetched? (that is we only send AS#RT# to peers via BGP and when group membership/VPN membership is signaled, the prefixes are imported) b. If (a) is not feasable for whatever reasons (like time to fetch prefixes etc), and assuming that AS#RT#prefix# are all present on the peer, can we assume that only when a peer of the node imports a particular AS#RT#, will the corresponding forwarding element/label be inserted in the FIB? In other words, other than the benefits of TE from RSVP-TE, can a or b be used to setup signaled LSPs? -brgds Sylvia ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Wed Oct 6 05:44:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06783 for ; Wed, 6 Oct 2004 05:44:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF8Uy-0004jn-5O for l3vpn-web-archive@ietf.org; Wed, 06 Oct 2004 05:54:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8I6-00078B-2m; Wed, 06 Oct 2004 05:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8FP-0006n3-SH for l3vpn@megatron.ietf.org; Wed, 06 Oct 2004 05:38:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06440 for ; Wed, 6 Oct 2004 05:38:09 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF8Os-0004Lc-2J for l3vpn@ietf.org; Wed, 06 Oct 2004 05:47:59 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 06 Oct 2004 02:42:36 -0700 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.10/8.12.6) with ESMTP id i969bZdX007144; Wed, 6 Oct 2004 02:37:37 -0700 (PDT) Received: from [10.10.10.78] (sjc-rraszuk-vpn1.cisco.com [10.25.90.226]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AXT44873; Wed, 6 Oct 2004 02:39:53 -0700 (PDT) Message-ID: <4163BCD9.6090908@cisco.com> Date: Wed, 06 Oct 2004 02:37:29 -0700 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Spice Sylvia References: <20041006092235.58729.qmail@web60901.mail.yahoo.com> In-Reply-To: <20041006092235.58729.qmail@web60901.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-rt-constrain-01.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Hi Sylvia, If I am interpreting your quiestion right - yes A is possible. In fact stay tuned for more details on A alone. I have work in progress trying to document A a bit in more detail. Thx, R. > Spice Sylvia wrote: > > Hello folks > > in the draft, given that AS#RT# froms a NLRI, > > a. Is it possible to have only the AS#RT#s avaliable > on a node and based on the fact that someone does an > import of that RT#, the prefixes should be fetched? > (that is we only send AS#RT# to peers via BGP and when > group membership/VPN membership is signaled, the > prefixes are imported) > > b. If (a) is not feasable for whatever reasons (like > time to fetch prefixes etc), and assuming that > AS#RT#prefix# are all present on the peer, can we > assume that only when a peer of the node imports a > particular AS#RT#, will the corresponding forwarding > element/label be inserted in the FIB? > > In other words, other than the benefits of TE from > RSVP-TE, can a or b be used to setup signaled LSPs? > > -brgds > Sylvia > > > > > > ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com > > From l3vpn-bounces@ietf.org Wed Oct 6 05:58:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07595 for ; Wed, 6 Oct 2004 05:58:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF8ix-0005ct-QH for l3vpn-web-archive@ietf.org; Wed, 06 Oct 2004 06:08:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8XW-00015K-LY; Wed, 06 Oct 2004 05:56:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF8Uk-0000bs-8U for l3vpn@megatron.ietf.org; Wed, 06 Oct 2004 05:54:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07298 for ; Wed, 6 Oct 2004 05:53:59 -0400 (EDT) Received: from web60907.mail.yahoo.com ([216.155.196.83]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CF8eD-0005NK-Jk for l3vpn@ietf.org; Wed, 06 Oct 2004 06:03:49 -0400 Message-ID: <20041006095331.721.qmail@web60907.mail.yahoo.com> Received: from [61.16.170.194] by web60907.mail.yahoo.com via HTTP; Wed, 06 Oct 2004 10:53:31 BST Date: Wed, 6 Oct 2004 10:53:31 +0100 (BST) From: Spice Sylvia To: raszuk@cisco.com In-Reply-To: <4163BCD9.6090908@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 8bit Cc: l3vpn@ietf.org Subject: Re: draft-ietf-l3vpn-rt-constrain-01.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 8bit Thanks a lot Robert, Just happy to know I wasn't a raving lunatic when I asked for something like RT :)) for TE, I guess we will have to wait for the link bandwidth community to happen or the metric to change into bandwidth from hops. looking forward to it.. -brgds Sylvia --- Robert Raszuk wrote: > Hi Sylvia, > > If I am interpreting your quiestion right - yes A is > possible. In fact > stay tuned for more details on A alone. I have work > in progress trying > to document A a bit in more detail. > > Thx, > R. > > > Spice Sylvia wrote: > > > > Hello folks > > > > in the draft, given that AS#RT# froms a NLRI, > > > > a. Is it possible to have only the AS#RT#s > avaliable > > on a node and based on the fact that someone does > an > > import of that RT#, the prefixes should be > fetched? > > (that is we only send AS#RT# to peers via BGP and > when > > group membership/VPN membership is signaled, the > > prefixes are imported) > > > > b. If (a) is not feasable for whatever reasons > (like > > time to fetch prefixes etc), and assuming that > > AS#RT#prefix# are all present on the peer, can we > > assume that only when a peer of the node imports a > > particular AS#RT#, will the corresponding > forwarding > > element/label be inserted in the FIB? > > > > In other words, other than the benefits of TE from > > RSVP-TE, can a or b be used to setup signaled > LSPs? > > > > -brgds > > Sylvia > > ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com From l3vpn-bounces@ietf.org Fri Oct 8 02:52:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28684 for ; Fri, 8 Oct 2004 02:52:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFomF-0007u6-NA for l3vpn-web-archive@ietf.org; Fri, 08 Oct 2004 03:02:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFoaX-00030q-SG; Fri, 08 Oct 2004 02:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFoZ0-0002kF-2Z for l3vpn@megatron.ietf.org; Fri, 08 Oct 2004 02:49:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28459 for ; Fri, 8 Oct 2004 02:49:11 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFoih-0007na-9z for l3vpn@ietf.org; Fri, 08 Oct 2004 02:59:24 -0400 Received: from l04955 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I590067Z5B11Y@mta0.huawei.com> for l3vpn@ietf.org; Fri, 08 Oct 2004 14:13:50 +0800 (CST) Date: Fri, 08 Oct 2004 14:16:00 +0800 From: lidefeng <77cronux.leed0621@huawei.com> To: Jonathan Harrison , l3vpn@ietf.org Message-id: <01d001c4acfe$48cf91d0$07436e0a@l04955> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com References: <37701240971DD31193970000F6CCB9F705042627@duke.datcon.co.uk> X-Spam-Score: 1.0 (+) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7BIT Subject: Re: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834 bytes) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: "Jonathan Harrison" To: "'lidefeng'" <77cronux.leed0621@huawei.com>; Sent: Thursday, September 23, 2004 11:00 PM Subject: RE: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834 bytes) > Defeng Li, > > We've looked through your draft in some detail, and have a few comments. > > 1) Overall, we think that the draft is useful, and that it goes some way to > solving the problem. > > 2) The main issue with the draft is that it does not go into any detail with > regards to the possible topologies used in the customer IS-IS network. The > result is that the topological restrictions imposed by the proposed solution > are not obvious, and it is not clear whether the solution needs to be > extended to cope with additional cases. > > For example, the CE devices could be > > - all at level 1, all in the same area > - all at level 1, some CE devices are in the same area, some CE devices are > in different areas > - all at level 2 > - some at level 1, some at level 2. > > The draft should clearly explain whether it applies to such topologies, and > how it applies to these topologies. I've noted some particular cases below > that do not appear to be handled by the draft. A: Agree > > 3) As mentioned in section 4.3, redistributed addresses must be less > preferable in the routing calculation (at least on the PE routers) to > internal IS-IS routes to prevent loops. Hence it makes sense to advertise > the VPN routes from BGP as level 1 routes with the "up/down" bit set. Note > though that this has some interesting consequences. A: Maybe the description of the third paragraph of 4.3 is not very clear. 4.3 mainly focus on the issue of loop prevention using up/down bit. At last, Redistribute addresses will be converted to some type of LSP(level-1/level-2, internal/external reachability...) as per the attribute that bgp extended community carry. Besides, when we configure the command "redistribute bgp... " in isis, we also can specify the level/metric-type of converted lsp by the command parameters, which i think should be prefered to "choose" to BGP ext-com carry. So, it is not "redistributed addresses must be less preferable in the routing calculation ". We can consider to remove the specification or give a more clear description in the next version of the draft. I wonder if i have clarify the confusion. > > - Such routes are less preferable to internal IS-IS routes, and so the > backdoor link is always preferred. The result is that nothing is gained by > allowing different metric types/levels to be advertised in BGP extended > communities. A: As per the last explanation, "backdoor link is always preferred" will not happen. > > - This also imposes topology restrictions. If the customer site containing > a CE device contains multiple areas, then the routes from BGP will only be > advertised in the level 1 area containing the CE device. These routes > cannot be advertised via level 2 to other areas, because the route has the > up/down bit set. Similar problems arise if the CE devices are in a level 2 > only topology. > > These examples show that there are a number of types of topology for which > the solution currently doesn't work. We should either look at the best way > to enhance the draft to apply to any topology, or (as mentioned above) the > draft should describe any topological restrictions. A: Yes, we should add one more restriction that CE sites must belong to level-1. PE-CE can work in both level-1 and level-2 domain. > > 4) The document needs to describe the sham link processing in much more > detail. In particular, it should explain the following points. > > a) Why are sham links required? They are needed because routing > information passed through the VPN must be less preferable than the internal > IS-IS routes learnt via the back-door link. In order for the VPN to be used > for routing traffic, it must appear as an IS-IS link with lower cost than > the back-door link. A: Agree. > > b) When can a sham link can be set up? An IS will only route over the > sham link if it has the LSPs describing both ends of the link. Hence the CE > devices at both ends of a sham link must either both act at level 2, or both > be in the same area at level 1. A: This is a really big problem for us. Sham link is only required when back door exists. But it is more difficult for isis to exchange hello or LSP packet via backbone between PEs because we can't forward the hello/LSP through multi-hop as what OSPF vitual link could do. In my opnion, it is difficult to maintain "up/down" relationship between PEs. I think we can simply add the sham link(NBR TLV) into the PE's LSP if the route of the address that sham link configuration designate is active . what is your good option? > > c) How is the sham link configured? This should differentiate between > information that is manually configured, and information that can be > auto-configured (for comparison, see draft-rosen-vpns-ospf-bgp-mpls-06, > which describes how sham links may be manually configured and/or > automatically configured). In particular, the document should describe how > the metric used for each link is chosen - it could either be manually > configured, or a default value used for each link, or it could be based in > some way on the cost of the path between the PE devices. A: I think we only need to support the maually configured manner, which is more simple and also prcatical. > > d) Is it the customer or the service provider that is responsible for the > metric chosen for a sham link? The metric will have a significant effect on > the whether the customer IS-IS network uses the sham link or the back-door > link for traffic. Hence the choice of metric must come from the customer. > However, it is the (service provider configured) PE devices that actually > sets up the sham link. A: In my opnion, the draft only need to specify a method to configure the metric of the sham link. Who is responsible to decide the metric value is beyond the scope of the draft. > > 5) The draft assumes that narrow metrics are used. Wide metrics are > commonly used in IS-IS networks (and may even be required to give sufficient > differentiation between the cost of a sham link and the cost of a back-door > link), so the draft should consider the wide metrics case. > A: Yes, we forget to add the wide-metric part into the initial draft, we will update it in the draft of the next version. > 6) I have a number of minor editorial comments that I will mail to you > privately. A: Thanks for your very helpful work. In fact, the initial draft need to be elaborated really. From l3vpn-bounces@ietf.org Fri Oct 8 10:47:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00865 for ; Fri, 8 Oct 2004 10:47:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwBN-0008RB-0b for l3vpn-web-archive@ietf.org; Fri, 08 Oct 2004 10:57:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvik-00033j-M1; Fri, 08 Oct 2004 10:27:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFvdu-0001P6-FK; Fri, 08 Oct 2004 10:22:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28029; Fri, 8 Oct 2004 10:22:45 -0400 (EDT) Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFvno-0007lE-B6; Fri, 08 Oct 2004 10:33:03 -0400 Received: from wushan (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I5900AHNQA1AB@mta1.huawei.com>; Fri, 08 Oct 2004 21:48:21 +0800 (CST) Date: Fri, 08 Oct 2004 22:13:52 +0800 From: lidefeng <77cronux.leed0621@huawei.com> To: Ronald Bonica Message-id: <0I5900AL6QCEAB@mta1.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 beta1 [cn] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 2.1 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: base64 Cc: shengc , l3vpn , chenyunqing , isis-wg Subject: Re: RE: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834 bytes) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: base64 SSByZWFkIHRoZSBMM3ZwbiB3ZyBjaGFydGVyLCBJIGRpZG4ndCBmaW5kIGFueSBzdGF0ZW1lbnQg dGhhdCBJU0lTIGFzIGEgcGUtY2Ugcm91dGluZyBwcm90b2NvbCBmb3IgQkdQL01QTFMgVlBOLCBq dXN0IGxpa2UgaXQgZGlkbid0IGV4cGxpY3RseSBzdGF0ZSB0aGF0IE9TUEYgYXMgYSBwZS1jZSBy b3V0aW5nIHByb3RvY29sIGZvciBCR1AvTVBMUyBWUE4sIGFuZCBkcmFmdC1pZXRmLWwzdnBuLW9z cGYtMjU0Ny0wMS50eHQNCmlzIGEgV0cgZHJhZnQsIGFuZCB0aGVyZSBpcyBubyBleHBsaWN0IHN0 YXRlbWVudCBvZiBpbmNsdWRpbmcgUEUtUEUgR1JFIG9yIElQIGluIEJHUC9NUExTIElQIFZQTnMg aW4gTDNWUE4gd2cgY2hhcnRlciwgYW5kIGRyYWZ0LWlldGYtbDN2cG4tZ3JlLWlwLTI1NDctMDIu dHh0IGlzIGEgd2cgZHJhZnQgdG9vLCB3aGF0J3MgbW9yZSwgbm93IHRoYXQgdGhpcyB0b3BpYyBp cyBvdXQgb2Ygc2NvcGUgb2YgbDN2cG4gd2cgY2hhcnRlciwgaG93IGNvbWUgdGhpcyBkcmFmdCB3 YXMgYXJyYW5nZWQgZm9yIHByZXNlbnRhdGlvbj8gDQoNCkFuZCBJUy1JUyBpcyBkZXBsb3llZCBp biBzb21lIHNjZW5hcmlvcywgc3VjaCBhcyBzb21lIGVudGVycHJpc2UgbmV0d29yaywgYW5kIHdo ZW4gdHdvIHN1Y2ggZW50ZXJwcmlzZSBuZXR3b3JrcyB3b3VsZCBsaWtlIHRvIGFjY2VzcyBzZXJ2 aWNlIHByb3ZpZGVyIHRvIGFwcGx5IEJHUC9NUExTIFZQTiBzZXJ2aWNlIGJldHdlZW4gdGhpcyB0 d28gc2l0ZXMsIGlmIHVzZSBJUy1JUyBhcyBQRS1DRSByb3V0aW5nIHByb3RvY29sLCBpdCB3aWxs IGJlIG11Y2ggZWFzaWVyIGZvciB0aGVzZSBlbnRlcnByaXNlIG5ldHdvcmtzIGN1c3RvbWVyIHRv IHRyYW5zaXRpb24gZnJvbSB0aGUgcHJldmlvdXMgbmV0d29yayB3aXRob3V0IGNoYW5naW5nIHRo ZSByb3V0aW5nIHByb3RvY29sIGluIHRoZSBvcmlnaW5hbCBuZXR3b3JrLg0KDQpJbiBzb21lIHNl cnZpY2UgcHJvdmlkZXJzLCB0aGUgSVMtSVMgaXMgcHJlZmVyZWQgZm9yIGl0cyBhZHZhbnRhZ2Ug aW4gaXRzIGNvbXBhdGliaWxpdHkgYmV0d2VlbiBJUHY0IGFuZCBJUHY2IHNvIGFzIHRvIHRyYW5z aXQgdGhlaXIgVlBOIGVhc2lseSwgYXMgSSBtZW50aW9uZWQgaW4gbXkgbGFzdCBlLW1haWwsIElT LUlTdjYgY2FuIGJlIHN1cHBvcnRlZCBlYXNpbHkgYnkgYWRkaW5nIHR3byBUTFZzIHRvIElTLUlT djQsIGhvd2V2ZXIsIGlmIE9TUEZ2MiBpcyBkZXBsb3llZCBhcyBDRS1QRSByb3V0aW5nLCB3aGVu IFZQTiBjdXN0b21lciBob3BlIHRvIHRyYW5zaXQgY3VzdG9tZXIgbmV0d29yayBmcm9tIElQdjQg dG8gSVB2NiwgdGhlbiBoZSB3b3VsZCBkZXBsb3kgT1NQRnYzIGluIHRoZWlyIG5ldHdvcmssIGFz IE9TUEZ2MyBpcyBub3QgY29tcGF0aWJsZSB3aXRoIE9TUEZ2MiwgaW4gZmFjdCwgdGhleSBtYXkg YmUgbG9va2VkIHVwb24gYXMgdHdvIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29sLCBzbyB0aGlz IHRyYW5zaXRpb24gd2lsbCBicmluZyBzb21lIGltcGFjdCB0byBjdXRvbWVyJ3MgbmV0d29yay4g SW4gdGhpcyByZWdhcmQsIHNvbWUgc2VydmljZSBwcm92aWRlciB3b3VsZCBwcmVmZXIgSVMtSVMg YXMgQ0UtUEUgcm91dGluZyBwcm90b2NvbCBpbiBCR1AvTVBMUyBWUE4uDQoNCkluIG90aGVyIHdv cmRzLCBJUy1JUyBhcyB0aGUgUEUtQ0Ugcm91dGluZyBwcm90b2NvbCBnaXZlIHRoZSBzZXJ2aWNl IHByb3ZpZGVyIGFuIGFsdGVybmF0aXZlIHRvIGNob29zZSB0aGUgUEUtQ0Ugcm91dGluZyBwcm90 b2NvbCwgdGhvdWdoIGlzIG5vdCBhbiBpbmRpc3BlbnNhYmxlIGNob2ljZSwgaXQganVzdCBwcm92 aWRlIGd1aWRlIGxpbmUgZm9yIHNlcnZpY2UgcHJvdmlkZXIgd2hlbiBoZSBjaG9vc2UgSVMtSVMg YXMgUEUtQ0Ugcm91dGluZyBwcm90b2NvbCwgYW5kIGl0cyBnb2FsIGlzIHRvIGJlIHByb2dyZXNz ZWQgaW50byBhbiBpbmZvcm1hdGlvbmFsIFJGQywgbm90IGEgc3RhbmRhcmQgdHJhY2sgUkZDIHdo aWNoIGRlbWFuZCB0aGUgY29tcGxldGUgYWJzZXJ2YXRpb24uIFNvIHdoeSBub3QgYWNjZXB0IHRo aXMgc3ViamVjdCBpbiBMM1ZQTiBXRyBjaGFydGVyPw0KDQpBcyBkcmFmdC1zaGVuZyB3aWxsIGFk ZHJlc3MgdGhlIHByb2JsZW0gd2hlbiBJUy1JUyBpcyB1c2VkIGFzIFBFLUNFIHJvdXRpbmcgcHJv dG9jb2wsIGFuZCB0aGVyZSBhcmUgc29tZSByZXF1aXJlbWVudHMgZnJvbSBzb21lIHNlcnZpY2Ug cHJvdmlkZXJzIGluIHNvbWUgc2NlbmFyaW9zLiBzbyBJIGhvcGUgY2hhaXJzIGNhbiByZWNvbnNp ZGVyIHRvIG1ha2UgdGhlIHByb2dyZXNzIHRvIHRoaXMgZHJhZnQuDQoNCg0KIA0KDQoNCg0KDQoN CgkNCg0KDQogDQoNCg0KDQoNCj5EZWZlbmcsDQo+DQo+Q3VycmVudGx5LCB0aGUgTDNWUE4gV0cg Y2hhcnRlciBkb2VzIG5vdCBpbmNsdWRlIElTSVMgYXMgYSBQRS1DRSByb3V0aW5nDQo+cHJvdG9j b2wuIEhvd2V2ZXIsIEkgd291bGQgbGlrZSB0byBvcGVuIHRoZSBtYWlsaW5nIGxpc3QgdG8gZGlz Y3Vzc2lvbi4NCj4NCj5JcyB0aGVyZSBhIGNvbXBlbGxpbmcgcmVhc29uIHRvIGRlcGxveSBJU0lT IGFzIGEgUEUtQ0Ugcm91dGluZyBwcm90b2NvbCwgYXMNCj5vcHBvc2VkIHRvIEJHUCBvciBPU1BG PyBBbHNvLCBJIHdvdWxkIGxpa2UgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlcmUgaXMNCj5icm9h ZCBXRyBpbnRlcmVzdCBpbiB0aGlzIHdvcmsuDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJvbg0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3Vu Y2VzQGlldGYub3JnXSANCj4+IE9uIEJlaGFsZiBPZiBsaWRlZmVuZw0KPj4gU2VudDogVGh1cnNk YXksIFNlcHRlbWJlciAwMiwgMjAwNCA1OjEzIEFNDQo+PiBUbzogcmlja0ByaHdpbGRlci5uZXQ7 IFJvbmFsZCBCb25pY2E7IFJvc3MgQ2FsbG9uDQo+PiBDYzogbDN2cG5AaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IEFib3V0IElTLUlTIGFzIHRoZSBQRS9DRSBQcm90b2NvbCBpbiBCR1AvTVBMUyBWUE5z IA0KPj4gKDQzODM0IGJ5dGVzKQ0KPj4gDQo+PiANCj4+IERlYXIgQ2hhaXJtZW4sDQo+PiANCj4+ IEF0IDU3dGggSUVURiBtZWV0aW5nLCBJIG1hZGUgdGhlIHByZXNlbnRhdGlvbiBmb3IgDQo+PiBk cmFmdC1zaGVuZy1wcHZwbi1pc2lzLWJncC1tcGxzLTAwLnR4dCBhdCBQUFZQTiB3ZyBtZWV0aW5n IA0KPj4gYW5kIHByb3Bvc2VkIHRoZSBkcmFmdCBhYm91dCAiSVMtSVMgYXMgdGhlIFBFL0NFIFBy b3RvY29sIGluIA0KPj4gQkdQL01QTFMgVlBOcyIgYXMgd29yayBncm91cCBkcmFmdCwgbm93IFBQ VlBOIHdnIGlzIGRpdmlkZWQgDQo+PiBpbnRvIEwzVlBOIGFuZCBMMlZQTiwgYXQgdGhlIHNhbWUg dGltZSwgZHJhZnQgIk9TUEYgYXMgdGhlIA0KPj4gUEUvQ0UgUHJvdG9jb2wgaW4gQkdQL01QTFMg VlBOcyAiIGlzIHByb2dyZXNzZWQgYXMgTDNWUE4gd2csIA0KPj4gYW5kIElTLUlTIGFzIGFuIGFs dGVybmF0ZSBJR1AgaW4gU1AncyBuZXR3b3JrIGFuZCANCj4+IGVudGVycHJpc2UncyBuZXR3b3Jr IGhhcyBpdHMgYWR2YW50YWdlcyBvdmVyIE9TUEYsIGVzcGVjaWFsbHkgDQo+PiBpbiBJUHY2IGFu ZCBUcmFmZmljIEVuZ2luZWVyaW5nIHNjZW5hcmlvcyhPU1BGdjMgY2FuJ3QgYmUgDQo+PiBjb21w YXRpYmlsaXR5IHdpdGggT1NQRnYyo6x3aGlsZSBJUy1JU3Y2IGNhbiBiZSB1cGRhdGVkIGZyb20g DQo+PiBJUy1JU3Y0IGJ5IFRMViBleHRlbnNpb25hKSwgYW5kIElTLUlTIGdhaW5lZCBpdHMgd2lk ZSANCj4+IGRlcGxveW1lbnQgZ3JhZHVhbGx5Lg0KPj4gDQo+PiBTbyBJIGhvcGUgTDNWUE4gd2cg Y29uc2lkZXIgdG8gcHJvZ3Jlc3MgDQo+PiBkcmFmdC1zaGVuZy1wcHZwbi1pc2lzLWJncC1tcGxz LTAwLnR4dCBhcyBXRyBkcmFmdCwgYW5kIGl0J3MgDQo+PiBnb2FsIGlzIHRvIGJlY29tZSBhbiBp bmZvcm1hdGlvbmFsIFJGQy4NCj4+IA0KPj4gQXMgdG8gdGhlIHRlY2huaWNhbCBwcm9ibGVtIG1p Z2h0IGV4aXN0IGluIGl0LCBjb21tZW50cyBhcmUgd2VsY29tZWQuDQo+PiANCj4+IFJlZ2FyZHMN Cj4+IA0KPj4gRGVmZW5nIExpDQo+PiBIdWF3ZWkgVGVjaG5vbG9naWVzDQo+PiANCj4+IA0KPj4g DQo+DQo+Lg0KDQo= From l3vpn-bounces@ietf.org Fri Oct 8 17:31:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19237 for ; Fri, 8 Oct 2004 17:31:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2V6-0005N8-QO for l3vpn-web-archive@ietf.org; Fri, 08 Oct 2004 17:42:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG1yQ-0000zw-Ew; Fri, 08 Oct 2004 17:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG1a7-00044k-Ax for l3vpn@megatron.ietf.org; Fri, 08 Oct 2004 16:43:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09515 for ; Fri, 8 Oct 2004 16:43:13 -0400 (EDT) Received: from westford-nat.juniper.net ([65.194.140.2] helo=proton.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG1k5-0002BT-3P for l3vpn@ietf.org; Fri, 08 Oct 2004 16:53:34 -0400 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 Date: Fri, 8 Oct 2004 16:42:41 -0400 Message-ID: <1E8ACF422ADD1A458AAFFAD2E6FF70C856B552@proton.jnpr.net> Thread-Topic: Last call: draft-ietf-l3vpn-mgt-fwk Thread-Index: AcStd1sSHhwsvnGfTF+9PhEUzVgkzg== From: "Ronald Bonica" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: quoted-printable Subject: Last call: draft-ietf-l3vpn-mgt-fwk X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Folks, The email begins a WG last call on draft-ietf-l3vpn-mgt-fwk. Last call will end 2 weeks from today, on 10/22/2004. Ron From l3vpn-bounces@ietf.org Mon Oct 11 16:51:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24421 for ; Mon, 11 Oct 2004 16:51:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH7J9-0003dS-9W for l3vpn-web-archive@ietf.org; Mon, 11 Oct 2004 17:02:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH675-0007UW-48; Mon, 11 Oct 2004 15:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH61g-0005Aw-LE; Mon, 11 Oct 2004 15:40:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09081; Mon, 11 Oct 2004 15:40:06 -0400 (EDT) Message-Id: <200410111940.PAA09081@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 11 Oct 2004 15:40:06 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-gre-ip-2547-03.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --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 : Use of PE-PE GRE or IP in BGP/MPLS IP VPNs Author(s) : Y. Rekhter, E. Rosen Filename : draft-ietf-l3vpn-gre-ip-2547-03.txt Pages : 7 Date : 2004-10-11 This draft describes a variation of BGP/MPLS IP VPNs ([BGP-MPLS-VPN]) in which the outermost MPLS label of a VPN packet (the tunnel label) is replaced with either IP or a GRE encapsulation. This enables the VPN packets to be carried over non-MPLS networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-gre-ip-2547-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-gre-ip-2547-03.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-gre-ip-2547-03.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-10-11155357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-gre-ip-2547-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-gre-ip-2547-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-11155357.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Tue Oct 12 18:31:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23480 for ; Tue, 12 Oct 2004 18:31:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHVLQ-0005TW-Qe for l3vpn-web-archive@ietf.org; Tue, 12 Oct 2004 18:42:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHV6n-0006iz-Ko; Tue, 12 Oct 2004 18:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHV2y-0005Q2-EO for l3vpn@megatron.ietf.org; Tue, 12 Oct 2004 18:23:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22949 for ; Tue, 12 Oct 2004 18:23:06 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHVDm-0005Jx-QP for l3vpn@ietf.org; Tue, 12 Oct 2004 18:34:20 -0400 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 i9CMMZ979874 for ; Tue, 12 Oct 2004 15:22:35 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.24.236.4]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9CMMUe48777 for ; Tue, 12 Oct 2004 15:22:30 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20041012182034.0347a638@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 12 Oct 2004 18:22:27 -0400 To: l3vpn@ietf.org From: Ross Callon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: draft-ietf-l3vpn-rt-constrain-01.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 This begins the working group last call on "Constrained VPN route distribution" draft-ietf-l3vpn-rt-constrain-01.txt. This draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-01.txt The last call will end in on October 27th. Thanks, Ross From l3vpn-bounces@ietf.org Wed Oct 13 10:35:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02995 for ; Wed, 13 Oct 2004 10:35:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHkPA-0006NJ-NX for l3vpn-web-archive@ietf.org; Wed, 13 Oct 2004 10:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHkCq-0006vM-C4; Wed, 13 Oct 2004 10:34:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHk1a-0002iM-DO for l3vpn@megatron.ietf.org; Wed, 13 Oct 2004 10:22:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00794 for ; Wed, 13 Oct 2004 10:22:36 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8] helo=smtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHkCP-00064X-Gi for l3vpn@ietf.org; Wed, 13 Oct 2004 10:33:56 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <45CQS8CD>; Wed, 13 Oct 2004 15:21:35 +0100 Message-ID: <37701240971DD31193970000F6CCB9F7050426C4@duke.datcon.co.uk> From: Jonathan Harrison To: "'lidefeng'" <77cronux.leed0621@huawei.com>, l3vpn@ietf.org Date: Wed, 13 Oct 2004 15:21:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Subject: RE: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Defeng Li, Thanks for the response to my comments. We understand your explanation, however we still think that the text describing the effect of using the up/down bit in relation to sham links could be expanded. Consider the case where there are two PE devices (A and B), connected by an MPLS/BGP VPN, and also connected through IS-IS with a back-door link. The requirement for preventing the redistribution of redistributed addresses is as follows. - PE device A learns of a destination address in an IS-IS LSP from a router at the local customer site. - PE device A advertises the address via BGP to remote PE device B. - PE device B redistributes the address into the IS-IS network. - PE device A learns of the destination address in the IS-IS LSP of PE device B. - PE device A has now learnt the address from both a local router, and from PE device B. - It is a requirement that the preferred route of PE device A is the route to the local router. (Otherwise, A will install the redistributed route to the address in the forwarding table, and then redistribute this redistributed route via BGP to PE device B, and so on.) The method you suggest uses the up/down bit to ensure that this requirement is met. This works due to the rules of route preference defined in RFC 2966 - for example, a level 1 route with internal metric is always preferred to a level 1 route with the up/down bit set (regardless of the actual metric value). So the redistributed routes are less preferable. Note that the VPN will still be used for traffic - consider the following cases. 1) If there is no back-door link the routes learnt from BGP are used to route traffic over the VPN link (regardless of whether a sham link is used). 2) If there is a back-door link, but no sham link, then the routes over the back-door link are always preferred (because of the setting of the up/down bit). In other words, the VPN link is acting as a back-up link - it is only used if the back-door link goes down. 3) If there is a back-door link and a sham link, then the routes learnt over the VPN are not used. However, the internal IS-IS routes may take the inter-site traffic over the VPN (sham) link and/or the back-door link, depending on the network topology. To answer your question on sham links - I think that manual configuration of the sham links probably makes the most sense. BGP can still be used to pass the end-point addresses between the VPN sites - the presence of these addresses indicates whether the sham link is usable (and should be added to the IS-IS LSP), rather than for auto-configuration. Jon ------------------------------------------- Jon Harrison Network Protocols Group Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: jrh@dataconnection.com Web: http://www.dataconnection.com -----Original Message----- From: lidefeng [mailto:77cronux.leed0621@huawei.com] Sent: 08 October 2004 07:16 To: Jonathan Harrison; l3vpn@ietf.org Subject: Re: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834 bytes) ----- Original Message ----- From: "Jonathan Harrison" To: "'lidefeng'" <77cronux.leed0621@huawei.com>; Sent: Thursday, September 23, 2004 11:00 PM Subject: RE: About IS-IS as the PE/CE Protocol in BGP/MPLS VPNs (43834 bytes) > Defeng Li, > > We've looked through your draft in some detail, and have a few comments. > > 1) Overall, we think that the draft is useful, and that it goes some way to > solving the problem. > > 2) The main issue with the draft is that it does not go into any detail with > regards to the possible topologies used in the customer IS-IS network. The > result is that the topological restrictions imposed by the proposed solution > are not obvious, and it is not clear whether the solution needs to be > extended to cope with additional cases. > > For example, the CE devices could be > > - all at level 1, all in the same area > - all at level 1, some CE devices are in the same area, some CE devices are > in different areas > - all at level 2 > - some at level 1, some at level 2. > > The draft should clearly explain whether it applies to such topologies, and > how it applies to these topologies. I've noted some particular cases below > that do not appear to be handled by the draft. A: Agree > > 3) As mentioned in section 4.3, redistributed addresses must be less > preferable in the routing calculation (at least on the PE routers) to > internal IS-IS routes to prevent loops. Hence it makes sense to advertise > the VPN routes from BGP as level 1 routes with the "up/down" bit set. Note > though that this has some interesting consequences. A: Maybe the description of the third paragraph of 4.3 is not very clear. 4.3 mainly focus on the issue of loop prevention using up/down bit. At last, Redistribute addresses will be converted to some type of LSP(level-1/level-2, internal/external reachability...) as per the attribute that bgp extended community carry. Besides, when we configure the command "redistribute bgp... " in isis, we also can specify the level/metric-type of converted lsp by the command parameters, which i think should be prefered to "choose" to BGP ext-com carry. So, it is not "redistributed addresses must be less preferable in the routing calculation ". We can consider to remove the specification or give a more clear description in the next version of the draft. I wonder if i have clarify the confusion. > > - Such routes are less preferable to internal IS-IS routes, and so the > backdoor link is always preferred. The result is that nothing is gained by > allowing different metric types/levels to be advertised in BGP extended > communities. A: As per the last explanation, "backdoor link is always preferred" will not happen. > > - This also imposes topology restrictions. If the customer site containing > a CE device contains multiple areas, then the routes from BGP will only be > advertised in the level 1 area containing the CE device. These routes > cannot be advertised via level 2 to other areas, because the route has the > up/down bit set. Similar problems arise if the CE devices are in a level 2 > only topology. > > These examples show that there are a number of types of topology for which > the solution currently doesn't work. We should either look at the best way > to enhance the draft to apply to any topology, or (as mentioned above) the > draft should describe any topological restrictions. A: Yes, we should add one more restriction that CE sites must belong to level-1. PE-CE can work in both level-1 and level-2 domain. > > 4) The document needs to describe the sham link processing in much more > detail. In particular, it should explain the following points. > > a) Why are sham links required? They are needed because routing > information passed through the VPN must be less preferable than the internal > IS-IS routes learnt via the back-door link. In order for the VPN to be used > for routing traffic, it must appear as an IS-IS link with lower cost than > the back-door link. A: Agree. > > b) When can a sham link can be set up? An IS will only route over the > sham link if it has the LSPs describing both ends of the link. Hence the CE > devices at both ends of a sham link must either both act at level 2, or both > be in the same area at level 1. A: This is a really big problem for us. Sham link is only required when back door exists. But it is more difficult for isis to exchange hello or LSP packet via backbone between PEs because we can't forward the hello/LSP through multi-hop as what OSPF vitual link could do. In my opnion, it is difficult to maintain "up/down" relationship between PEs. I think we can simply add the sham link(NBR TLV) into the PE's LSP if the route of the address that sham link configuration designate is active . what is your good option? > > c) How is the sham link configured? This should differentiate between > information that is manually configured, and information that can be > auto-configured (for comparison, see draft-rosen-vpns-ospf-bgp-mpls-06, > which describes how sham links may be manually configured and/or > automatically configured). In particular, the document should describe how > the metric used for each link is chosen - it could either be manually > configured, or a default value used for each link, or it could be based in > some way on the cost of the path between the PE devices. A: I think we only need to support the maually configured manner, which is more simple and also prcatical. > > d) Is it the customer or the service provider that is responsible for the > metric chosen for a sham link? The metric will have a significant effect on > the whether the customer IS-IS network uses the sham link or the back-door > link for traffic. Hence the choice of metric must come from the customer. > However, it is the (service provider configured) PE devices that actually > sets up the sham link. A: In my opnion, the draft only need to specify a method to configure the metric of the sham link. Who is responsible to decide the metric value is beyond the scope of the draft. > > 5) The draft assumes that narrow metrics are used. Wide metrics are > commonly used in IS-IS networks (and may even be required to give sufficient > differentiation between the cost of a sham link and the cost of a back-door > link), so the draft should consider the wide metrics case. > A: Yes, we forget to add the wide-metric part into the initial draft, we will update it in the draft of the next version. > 6) I have a number of minor editorial comments that I will mail to you > privately. A: Thanks for your very helpful work. In fact, the initial draft need to be elaborated really. From l3vpn-bounces@ietf.org Mon Oct 18 13:16:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03219 for ; Mon, 18 Oct 2004 13:16:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbJj-0004ph-8K for l3vpn-web-archive@ietf.org; Mon, 18 Oct 2004 13:29:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaYx-00061q-Gw; Mon, 18 Oct 2004 12:40:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaQa-0004Lq-7I for l3vpn@megatron.ietf.org; Mon, 18 Oct 2004 12:32:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29749 for ; Mon, 18 Oct 2004 12:32:01 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJacV-0003rx-Ru for l3vpn@ietf.org; Mon, 18 Oct 2004 12:44:29 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Oct 2004 18:31:07 +0200 Received: from l-dhcp-3259-4.rd.francetelecom.fr ([10.193.15.132]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Oct 2004 18:31:09 +0200 From: Thomas Morin To: L3VPN Content-Type: multipart/alternative; boundary="=-krGFsZSSWh7FaEZOmI3u" Organization: France Telecom R&D CORE/CPN Date: Mon, 18 Oct 2004 18:31:07 +0200 Message-Id: <1098117067.4446.14.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 X-OriginalArrivalTime: 18 Oct 2004 16:31:09.0412 (UTC) FILETIME=[DFAF6240:01C4B52F] X-Spam-Score: 0.7 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Jean-Louis LE ROUX , Elodie HEMON , Renaud MOIGNARD Subject: Multicast VPN requirements draft X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --=-krGFsZSSWh7FaEZOmI3u Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, We just submitted a requirements draft for the support of multicast in provider provided IP VPNs. http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg02443.html Abstract: This document presents a set of functional requirements for network solutions that allow the support of IP multicast within IP provider provided VPNs. It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions, that specify the support of IP multicast within VPNs, use these requirements as a guideline. It is not the intent of this document to propose technical solutions, nor to detail solution specific issues. This draft currently reflects the position of FT R&D and FT group operators, but we already received interesting feedback from other operators which should contribute to next revision of draft. The main goal of this first submission is to trigger discussion about the requirements for this service, so all issues are very opened and your comments on this draft are very welcome. Regards, -Thomas Morin -- == Thomas MORIN - France Telecom R&D/CORE/CPN == Tel.: +33(0) 2 96 05 37 34 - www.francetelecom.com/rd -- --=-krGFsZSSWh7FaEZOmI3u Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hello,

We just submitted a requirements draft for the support of multicast in provider provided  IP VPNs.

http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg02443.html
Abstract:
   This document presents a set of functional requirements for network
   solutions that allow the support of IP multicast within IP provider
   provided VPNs. It specifies requirements both from the end user
   and service provider standpoints. It is intended that potential
   solutions, that specify the support of IP multicast within VPNs,
   use these requirements as a guideline. It is not the intent of this
   document to propose technical solutions, nor to detail solution
   specific issues.

This draft currently reflects the position of FT R&D and FT group operators, but we already received interesting feedback from other operators which should contribute to next revision of draft. 

The main goal of this first submission is to trigger discussion about the requirements for this service, so all issues are very opened and your comments on this draft are very welcome.

Regards,

-Thomas Morin

--
== Thomas MORIN - France Telecom R&D/CORE/CPN
== Tel.: +33(0) 2 96 05 37 34 - www.francetelecom.com/rd
--
--=-krGFsZSSWh7FaEZOmI3u-- From l3vpn-bounces@ietf.org Thu Oct 21 11:35:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13885 for ; Thu, 21 Oct 2004 11:35:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfB2-00069u-4m for l3vpn-web-archive@ietf.org; Thu, 21 Oct 2004 11:48:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeqj-0005wC-IE; Thu, 21 Oct 2004 11:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKegz-0002Cv-KZ for l3vpn@megatron.ietf.org; Thu, 21 Oct 2004 11:17:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12148 for ; Thu, 21 Oct 2004 11:17:27 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKetc-0005k9-E5 for l3vpn@ietf.org; Thu, 21 Oct 2004 11:30:33 -0400 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 i9LFGt965713; Thu, 21 Oct 2004 08:16:55 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.28.5.73]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9LFGne40433; Thu, 21 Oct 2004 08:16:49 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20041021111352.0336cca8@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Oct 2004 11:15:15 -0400 To: l3vpn@ietf.org From: Ross Callon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: rcallon@juniper.net, rick@rhwilder.net Subject: Call for L3VPN Presentations X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed If anyone has an item that they would like on the L3VPN agenda for IETF61 in Washington, then please send email to all three working group chairs. Thanks, Ross From l3vpn-bounces@ietf.org Thu Oct 21 19:59:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05870 for ; Thu, 21 Oct 2004 19:59:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKn2U-0003yZ-5l for l3vpn-web-archive@ietf.org; Thu, 21 Oct 2004 20:12:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl6H-00058r-Vw; Thu, 21 Oct 2004 18:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKj50-0001Ae-1h; Thu, 21 Oct 2004 15:58:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13886; Thu, 21 Oct 2004 15:58:31 -0400 (EDT) Message-Id: <200410211958.PAA13886@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 21 Oct 2004 15:58:31 -0400 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-ospf-2547-02.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --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 Provider/Customer Edge Protocol for BGP/MPLS IP VPNs Author(s) : E. Rosen, et al. Filename : draft-ietf-l3vpn-ospf-2547-02.txt Pages : 20 Date : 2004-10-21 Many Service Providers offer Virtual Private Network ("VPN") services to their customers, using a technique in which customer edge routers ("CE routers") are routing peers of provider edge routers ("PE routers"). The Border Gateway Protocol ("BGP") is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching ("MPLS") is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First ("OSPF") protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ospf-2547-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-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-ospf-2547-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-10-21154710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-ospf-2547-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-ospf-2547-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154710.I-D@ietf.org> --OtherAccess-- --NextPart-- From l3vpn-bounces@ietf.org Mon Oct 25 09:36:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25454 for ; Mon, 25 Oct 2004 09:36:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM5Eo-0006rG-KM for l3vpn-web-archive@ietf.org; Mon, 25 Oct 2004 09:50:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM4zg-0005xB-LZ; Mon, 25 Oct 2004 09:34:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM4xr-0005qP-3W for l3vpn@megatron.ietf.org; Mon, 25 Oct 2004 09:32:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25355 for ; Mon, 25 Oct 2004 09:32:45 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM5BJ-0006oc-1j for l3vpn@ietf.org; Mon, 25 Oct 2004 09:46:41 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PDWhIn018261; Mon, 25 Oct 2004 22:32:43 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PDWhE7018297; Mon, 25 Oct 2004 22:32:43 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PDWgbN018290; Mon, 25 Oct 2004 22:32:42 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PDWgP7003583; Mon, 25 Oct 2004 22:32:42 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PDWg5c003578; Mon, 25 Oct 2004 22:32:42 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PDWfUr023080; Mon, 25 Oct 2004 22:32:41 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PDWfuc013453; Mon, 25 Oct 2004 22:32:41 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i9PDWftD013450; Mon, 25 Oct 2004 22:32:41 +0900 (JST) Received: from win-yasukawa.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA16801; Mon, 25 Oct 2004 22:32:40 +0900 (JST) Message-Id: <5.0.2.5.2.20041025203033.0632adc8@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Mon, 25 Oct 2004 22:45:32 +0900 To: l3vpn@ietf.org From: Seisho Yasukawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: rcallon@juniper.net, adrian@olddog.co.uk, kshankar@motorola.com, yasukawa.seisho@lab.ntt.co.jp, rick@rhwilder.net Subject: Fwd: I-D ACTION:draft-yasukawa-l3vpn-p2mp-mcast-00.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hi, We submitted a following new MVPN draft recently which we would like to discuss at next upcoming IETF meeting. The draft describes a new IP Multicast VPN architecture which, we beleive, provides flexible service operation for SPs and enhances the scalability performance of the network. Your comments and feedbacks on this draft are very welcome. Regards, Seisho >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : BGP/MPLS IP Multicast VPNs > Author(s) : S. Yasukawa, et al. > Filename : draft-yasukawa-l3vpn-p2mp-mcast-00.txt > Pages : 20 > Date : 2004-10-19 > >This document describes a solution framework for IP Multicast > VPNs. It describes procedures for establishing optimal virtual > private IP multicast networks over a provider network. The simple > multicast tunnel operation mechanism within a core network provides > easy and flexible IP multicast VPN service operation for the > service provider. And because the solution can minimize PIM > neighbor maintenance over remote PEs, the solution enhances the > scalability performance of the multicast VPN service network. This > document also describes a P2MP TE LSP based multicast tunnel > mechanism which could enhance TE capability and reliability of IP > multicast VPNs. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-yasukawa-l3vpn-p2mp-mcast-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the >message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >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-yasukawa-l3vpn-p2mp-mcast-00.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-yasukawa-l3vpn-p2mp-mcast-00.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. >Content-Type: text/plain >Content-ID: <2004-10-20104813.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-yasukawa-l3vpn-p2mp-mcast-00.txt > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce From l3vpn-bounces@ietf.org Mon Oct 25 11:43:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05821 for ; Mon, 25 Oct 2004 11:43:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7EG-0000fW-Vk for l3vpn-web-archive@ietf.org; Mon, 25 Oct 2004 11:57:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6vz-0003if-N7; Mon, 25 Oct 2004 11:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6uG-0003bL-VT; Mon, 25 Oct 2004 11:37:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05053; Mon, 25 Oct 2004 11:37:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM77k-0000Xi-MF; Mon, 25 Oct 2004 11:51:08 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CM6p5-0003Eq-7g; Mon, 25 Oct 2004 11:31:51 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 25 Oct 2004 11:31:51 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: l3vpn@ietf.org Subject: Last Call: 'OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs' to Proposed Standard X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 The IESG has received a request from the Layer 3 Virtual Private Networks WG to consider the following document: - 'OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-11-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ospf-2547-02.txt From l3vpn-bounces@ietf.org Tue Oct 26 10:49:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10807 for ; Tue, 26 Oct 2004 10:49:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSqt-0004V7-GO for l3vpn-web-archive@ietf.org; Tue, 26 Oct 2004 11:03:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSXH-0003dU-Ko; Tue, 26 Oct 2004 10:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSSH-0002To-22 for l3vpn@megatron.ietf.org; Tue, 26 Oct 2004 10:37:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10159 for ; Tue, 26 Oct 2004 10:37:42 -0400 (EDT) Received: from smtp102.mail.sc5.yahoo.com ([216.136.174.140]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMSfs-0004IK-7q for l3vpn@ietf.org; Tue, 26 Oct 2004 10:51:53 -0400 Received: from unknown (HELO RLAPTOP) (vsharma87@202.63.185.44 with login) by smtp102.mail.sc5.yahoo.com with SMTP; 26 Oct 2004 14:37:37 -0000 From: "Vishal Sharma" To: "MPLS" , "CCAMP" , "L2PPVPN" , "L3PPVPN" , "PWE3" Date: Tue, 26 Oct 2004 07:37:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit Cc: Loa Andersson , Thomas Nadeau , "Monique J. Morrow" Subject: Deadline extended: "Inter-Provider Service Quality..." IEEE Comm. Mag. CFP X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: v.sharma@ieee.org List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 3.4 (+++) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Folks, Due to responses from several quarters for this CFP, and the authors requesting for more time to submit, we are happy to let you know that the deadline for submission for this Feature Topic issue has been extended up to: **26 November 2004**. So, we invite those working in this area who are considering sending in their contributions, but were held back by the deadline to rush to do so! If you intend to submit a paper for this special issue, please do drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your continued participation! Thanks, -Vishal ========================================================================= CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "Challenges in Enabling Inter-Provider Service Quality on the Internet" ************************************************************************* ** Submission deadline extended to 26 November 2004.** As carriers and service providers build multi-services networks based on IP/MPLS- enabled infrastructures that are able to meet evermore stringent service level agreements (SLAs) and quality-of-service (QoS) requirements, it becomes a key issue to extend the ability to deliver these services across carrier and service provider domain boundaries, while at the same time preserving the same SLAs and QoS assurances as those provided within a given provider's network. The advent of new end-user applications, as well as new services based on MPLS technology, such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs), also means the emergence of added service quality requirements from operators deploying and interoperating these networks and the end-users themselves. As a result, providers and vendors require efficient means to enable inter-provider service quality, which comprises of several key elements including quality of service, class of service, security, OAM, and restoration and repair. This will is lead to the emergence of improved or novel tools and techniques to address these aspects, with the goal of guaranteeing service quality end-to-end, improving security and billing/accounting, and reducing operating costs. Standards organizations such as the IETF and the ITU are taking on significant work in this area, and various aspects of this subject are also being investigated by bodies such as the OIF, the MSF, the MPLS/Frame Relay Alliance, the IEEE, and the Metro Ethernet Forum, and are the themes for numerous upcoming conferences. This feature topic issue of the IEEE Communications Magazine has a multi-pronged focus on the delivery of inter-provider service quality: * Highlight operator and end-user concerns and requirements. * Feature current and/or planned deployment experiences. * Survey modern research and engineering developments. * Spotlight contemporary standards activity. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but certainly not limited to) the following topics: * Carrier requirements for efficient inter-provider service quality: Current operational needs, bottlenecks, future demands * Deployment experience with inter-provider service quality on IP/MPLS- based networks: comparative analysis, case studies * QoS management in an inter-provider environment: interconnection architectures using MPLS, Diffserv, QoS performance, path characterization, routing policies * Service assurance in inter-provider infrastructures: End-to-end SLA management, service billing/reporting, admission control * Failure and restoration requirements/challenges in inter-provider contexts * Interoperability and inter-working of diverse equipment types and technologies (ATM, FR, Ethernet) * Current engineering and research developments: E.g. Passive and active performance measurement and monitoring, TE, modelling and simulation * Standards activities and initiatives: new services and network architectures On-line CFP with submission instructions can be found at: http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided there is consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at http://www.comsoc.org/pubs/commag/sub_guidelines.html. ** Please submit no later than 26 November 2004.** Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due: **26 November 2004** Acceptance Notification: 15 January 2004 Final Manuscript Due: 28 February 2005 Publication Date: June 2005 (Deadline extended from 30th October 2004 to 26th November 2004.) Guest Editors Monique J. Morrow, Cisco Systems, (mmorrow@cisco.com) Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Thomas D.Nadeau, Cisco Systems (tnadeau@cisco.com) Loa Andersson, Acreo (loa@pi.se) **************************************************************** Vishal Sharma, Ph.D. Metanoia, Inc. (Critical Systems Thinking) 888 Villa Street, Suite 200, Mountain View, CA 94041-1261 Phone: +1 650-641-0082. Fax: +1 650-641-0086 Email: v.sharma@ieee.org. http://www.metanoia-inc.com **************************************************************** From l3vpn-bounces@ietf.org Tue Oct 26 11:25:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14074 for ; Tue, 26 Oct 2004 11:25:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTQ0-0005Hg-2A for l3vpn-web-archive@ietf.org; Tue, 26 Oct 2004 11:39:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTB3-0000ec-3S; Tue, 26 Oct 2004 11:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMT9r-0000SC-5C; Tue, 26 Oct 2004 11:22:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13799; Tue, 26 Oct 2004 11:22:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTNX-0005Ds-Pi; Tue, 26 Oct 2004 11:36:55 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CMT6G-0008Ca-82; Tue, 26 Oct 2004 11:19:04 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 26 Oct 2004 11:19:04 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: l3vpn, Internet Architecture Board , l3vpn mailing list , chair , l3vpn chair , RFC Editor Subject: Protocol Action: 'BGP/MPLS IP VPNs' to Proposed Standard X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l3vpn-bounces@ietf.org Errors-To: l3vpn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 The IESG has approved the following documents: - 'BGP/MPLS IP VPNs ' as a Proposed Standard - 'Applicability Statement for BGP/MPLS IP VPNs ' as an Informational RFC These documents are products of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary This document describes a method by which a Service Provider may use an IP backbone to provide IP VPNs (Virtual Private Networks) for its customers. This method uses a "peer model", in which the customers' edge routers ("CE routers") send their routes to the Service Provider's edge routers ("PE routers"). BGP is then used by the Service Provider to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This bis done in a way which ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. The PE routers distribute, to the CE routers in a particular VPN, the routes from other the CE routers in that VPN. The CE routers do not peer with each other, hence there is no "overlay" visible to the VPN's routing algorithm. The term "IP" in "IP VPN" is used to indicate that the PE receives IP datagrams from the CE, examines their IP headers, and routes them accordingly. Working Group Summary There has long been consent in the WG to move this document forward. Indeed, the original charter called from revising RFC 2547 (informational) to reflect experience with it, and put it on the standards track. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. There are numerous implementations in use.