From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 1 11:40:53 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22908 for ; Tue, 1 Oct 2002 11:40:53 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 324463EC17; Tue, 1 Oct 2002 17:53:57 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 56B1A3EC11 for ; Tue, 1 Oct 2002 17:53:53 +0200 (CEST) Received: from smtp1.fteb.net (193.252.85.3) by hermes1.fth.net; 1 Oct 2002 17:42:11 +0200 Received: from siva (siva.adm.fth.net [193.252.64.152]) by smtp1.fteb.net (Postfix) with SMTP id 0660A109E06 for ; Tue, 1 Oct 2002 19:42:11 +0200 (CEST) Message-ID: <025a01c26961$87a5f620$9840fcc1@adsi.fth.net> From: "sivacoumar.djiva" To: Date: Tue, 1 Oct 2002 17:45:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0257_01C26972.4B259E60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 932 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0257_01C26972.4B259E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ceci est un test ------=_NextPart_000_0257_01C26972.4B259E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ceci est un test
------=_NextPart_000_0257_01C26972.4B259E60-- From ppvpn-owner@ppvpn.francetelecom.com Thu Oct 3 14:02:57 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28271 for ; Thu, 3 Oct 2002 14:02:57 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id DC1983EC16; Thu, 3 Oct 2002 20:16:00 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 3F5773EC11 for ; Thu, 3 Oct 2002 20:15:57 +0200 (CEST) Received: from almso2.proxy.att.com (192.128.166.71) by hermes1.fth.net; 3 Oct 2002 20:04:16 +0200 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g93HQlM7027008 for ; Thu, 3 Oct 2002 14:04:14 -0400 (EDT) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (6.5.019) id 3D8B560500410ABF; Thu, 3 Oct 2002 14:04:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Question on draft-ietf-ppvpn-mpls-vpn-mib-04.txt Date: Thu, 3 Oct 2002 14:04:13 -0400 Message-ID: <28F05913385EAC43AF019413F674A017019233CF@OCCLUST04EVS1.ugd.att.com> Thread-Topic: RE: Question on draft-ietf-ppvpn-mpls-vpn-mib-04.txt Thread-Index: AcJrByLPZhDroNDcEdai4QDAT2jDug== From: "Fang, Luyuan, ALCNS" To: "Wenjing Chu" , X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 933 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA28271 If a single physical interface is configured with multiple logical interfaces, then each logical interface can associate with a separate VRF. Luyuan Fang AT&T - IP Network Architecture and Routing Planning Middletown, NJ 07748 732-420-1921 luyuanfang@att.com -----Original Message----- From: Wenjing Chu [mailto:wchu@nexthop.com] Sent: Thursday, September 12, 2002 6:10 PM To: ppvpn@ppvpn.francetelecom.com Subject: Question on draft-ietf-ppvpn-mpls-vpn-mib-04.txt Tom et al, I have a separate question on the relationship among VRF, VPN, and interfaces. The document clearly says that: a) VRF is an instance of a VPN on a device, and the whole collection is the VPN b) A VRF can have multiple interfaces associated The question is then, can an interface have multiple associated VRFs, for its membership in multiple VPNs? Or, as some may say: An interface's VRF contains all the information from all the VPNs that the interface is a member of. (which would conflict with (a).) Can you clarify? Thanks. Regards Wenjing From ppvpn-owner@ppvpn.francetelecom.com Fri Oct 4 07:30:09 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29022 for ; Fri, 4 Oct 2002 07:30:09 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 38FC73EC16; Fri, 4 Oct 2002 13:43:20 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id EA62F3EC11 for ; Fri, 4 Oct 2002 13:43:16 +0200 (CEST) Received: from ietf.org (132.151.1.176) by hermes1.fth.net; 4 Oct 2002 13:31:36 +0200 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28958; Fri, 4 Oct 2002 07:29:33 -0400 (EDT) Message-Id: <200210041129.HAA28958@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@ppvpn.francetelecom.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Date: Fri, 04 Oct 2002 07:29:33 -0400 Sender: nsyracus@cnri.reston.va.us X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 934 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Scalable Connectionless Tunneling Architecture and Protocols for VPNs Author(s) : T. Kuwahara et al. Filename : draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Pages : 29 Date : 2002-10-3 This document defines a connectionless tunneling architecture that is applicable to layer 3 PE-based virtual private networks and specifies protocols for implementing it. This tunneling architecture is designed to facilitate scalability and reliability. A prominent feature of it is to provide VPN tunnels over a connectionless network. Since a connectionless network can provide full mesh connectivity without a connection establishment procedure, the architecture enables scalable operation of a VPN more efficiently than connection-oriented tunneling technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-cl-tunneling-vpn-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-cl-tunneling-vpn-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-ietf-ppvpn-cl-tunneling-vpn-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. --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: <2002-10-3150209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-cl-tunneling-vpn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-cl-tunneling-vpn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-3150209.I-D@ietf.org> --OtherAccess-- --NextPart-- From ppvpn-owner@ppvpn.francetelecom.com Fri Oct 4 10:52:26 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06612 for ; Fri, 4 Oct 2002 10:52:25 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 9C4423EC18; Fri, 4 Oct 2002 17:05:35 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 5B48E3EC11 for ; Fri, 4 Oct 2002 17:05:29 +0200 (CEST) Received: from mailgw2.technion.ac.il (132.68.238.35) by hermes1.fth.net; 4 Oct 2002 16:53:49 +0200 Received: by mailgw2.technion.ac.il (Postfix, from userid 60999) id CBC1A36E38; Fri, 4 Oct 2002 17:52:48 +0300 (IDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 9B91036E1A for ; Fri, 4 Oct 2002 17:52:46 +0300 (IDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA09056 for ietf-123-outbound.07@ietf.org; Fri, 4 Oct 2002 09:55:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA07483 for ; Fri, 4 Oct 2002 07:31:36 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28958; Fri, 4 Oct 2002 07:29:33 -0400 (EDT) Message-Id: <200210041129.HAA28958@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@ppvpn.francetelecom.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Date: Fri, 04 Oct 2002 07:29:33 -0400 Sender: nsyracus@cnri.reston.va.us X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 935 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Scalable Connectionless Tunneling Architecture and Protocols for VPNs Author(s) : T. Kuwahara et al. Filename : draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Pages : 29 Date : 2002-10-3 This document defines a connectionless tunneling architecture that is applicable to layer 3 PE-based virtual private networks and specifies protocols for implementing it. This tunneling architecture is designed to facilitate scalability and reliability. A prominent feature of it is to provide VPN tunnels over a connectionless network. Since a connectionless network can provide full mesh connectivity without a connection establishment procedure, the architecture enables scalable operation of a VPN more efficiently than connection-oriented tunneling technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-cl-tunneling-vpn-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-cl-tunneling-vpn-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-ietf-ppvpn-cl-tunneling-vpn-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. --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: <2002-10-3150209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-cl-tunneling-vpn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-cl-tunneling-vpn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-3150209.I-D@ietf.org> --OtherAccess-- --NextPart-- From ppvpn-owner@ppvpn.francetelecom.com Fri Oct 4 18:06:33 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23571 for ; Fri, 4 Oct 2002 18:06:32 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 1DF423EC18; Sat, 5 Oct 2002 00:19:43 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 221743EC11 for ; Sat, 5 Oct 2002 00:19:40 +0200 (CEST) Received: from father.pmc-sierra.bc.ca (216.241.224.13) by hermes1.fth.net; 5 Oct 2002 00:07:59 +0200 Received: (qmail 27108 invoked by uid 104); 4 Oct 2002 22:07:58 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4227. . Clean. Processed in 0.472838 secs); 04 Oct 2002 22:07:58 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 4 Oct 2002 22:07:57 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g94M7vQ14307; Fri, 4 Oct 2002 15:07:57 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Fri, 4 Oct 2002 15:08:51 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03994@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'pwe3@ietf.org'" Cc: ppvpn@ppvpn.francetelecom.com Subject: NSP signaling Date: Fri, 4 Oct 2002 15:07:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 936 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Hi, In the PW layering architecture a PE is divided in to PREP (pre-processor) and IW. The PREP is further divided to NSP and Forwarder. Draft-rosen and draft-martini define signaling methods for communication between IWs or forwarders. Many different services could use the same Forwarder and/or IW function. However, they may need their own signaling for configuration of their NSP. I was wondering in which WG should this type of signaling be defined? and has anybody defined such a signaling (independent of the Forwarder and IW function) yet? Thanks, -Shahram From ppvpn-owner@ppvpn.francetelecom.com Mon Oct 7 09:38:34 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18110 for ; Mon, 7 Oct 2002 09:38:34 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id B7FD33EC16; Mon, 7 Oct 2002 15:51:39 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id C15093EC11 for ; Mon, 7 Oct 2002 15:51:36 +0200 (CEST) Received: from sj-msg-core-1.cisco.com (171.71.163.11) by hermes1.fth.net; 7 Oct 2002 15:39:58 +0200 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g97DdoIm023751; Mon, 7 Oct 2002 06:39:50 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g97DdnqG009760; Mon, 7 Oct 2002 06:39:49 -0700 (PDT) Received: from CHMETZ-W2K2.cisco.com (sjc-vpn1-177.cisco.com [10.21.96.177]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA07380; Mon, 7 Oct 2002 06:39:48 -0700 (PDT) Message-Id: <4.3.2.7.2.20021007091858.045cbc68@mail1.cisco.com> X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Oct 2002 09:39:45 -0400 To: Shahram Davari From: Chris Metz Subject: Re: [PWE3] NSP signaling Cc: "'pwe3@ietf.org'" , ppvpn@ppvpn.francetelecom.com In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03994@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 937 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Shahram- At 03:07 PM 10/4/2002 -0700, Shahram Davari wrote: >Hi, > >In the PW layering architecture a PE is divided in to PREP (pre-processor) >and IW. >The PREP is further divided to NSP and Forwarder. > >Draft-rosen and draft-martini define signaling methods for communication >between IWs or forwarders. > >Many different services could use the same Forwarder and/or IW function. >However, they may need their own signaling for configuration of their NSP. Configuration in what sense? If it is specific to an AC terminating in the local PE (NSP) then it is a local matter outside the scope of any WG (PWE3 or PPVPN) as far as I can make out. IMO, if it involves manipulation of the forwarder and/or IW function then again it is a local matter as to how the NSP may want to interact with the PW protocol machinery. NSPs are also free to convey signaling messages amongst themselves in a transparent overlay fashion without any PW interaction. > > >I was wondering in which WG should this type of signaling be defined? and >has anybody defined >such a signaling (independent of the Forwarder and IW function) yet? This should be dependent on the type and nature of the NSP. Do you have an example in mind? Cheers ... >Thanks, >-Shahram >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From ppvpn-owner@ppvpn.francetelecom.com Mon Oct 7 10:06:00 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19688 for ; Mon, 7 Oct 2002 10:06:00 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 20A5F3EC16; Mon, 7 Oct 2002 16:19:12 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 321CB3EC11 for ; Mon, 7 Oct 2002 16:19:00 +0200 (CEST) Received: from father.pmc-sierra.bc.ca (216.241.224.13) by hermes1.fth.net; 7 Oct 2002 16:07:21 +0200 Received: (qmail 8595 invoked by uid 104); 7 Oct 2002 14:07:19 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4227. . Clean. Processed in 0.506958 secs); 07 Oct 2002 14:07:19 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 7 Oct 2002 14:07:18 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g97E7IQ11299; Mon, 7 Oct 2002 07:07:18 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Oct 2002 07:08:22 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03999@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Chris Metz'" Cc: "'pwe3@ietf.org'" , ppvpn@ppvpn.francetelecom.com Subject: RE: [PWE3] NSP signaling Date: Mon, 7 Oct 2002 07:07:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 938 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Chris, NSPs may need to coordinate certain parameters with each other. For example imagine that the service is TDM, and that we are using ATM CES over MPLS. In that case, the NSPs may need to inform each other of the type of the traffic (structured, unstructured, structured w/CAS, etc.). I would like to know in which WG should this be defined. Thanks, -Shahram > -----Original Message----- > From: Chris Metz [mailto:chmetz@cisco.com] > Sent: Monday, October 07, 2002 9:40 AM > To: Shahram Davari > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com > Subject: Re: [PWE3] NSP signaling > > > Shahram- > > At 03:07 PM 10/4/2002 -0700, Shahram Davari wrote: > >Hi, > > > >In the PW layering architecture a PE is divided in to PREP > (pre-processor) > >and IW. > >The PREP is further divided to NSP and Forwarder. > > > >Draft-rosen and draft-martini define signaling methods for > communication > >between IWs or forwarders. > > > >Many different services could use the same Forwarder and/or > IW function. > >However, they may need their own signaling for configuration > of their NSP. > > Configuration in what sense? If it is specific to an AC > terminating in the > local PE (NSP) then it is a local matter outside the scope of > any WG (PWE3 > or PPVPN) as far as I can make out. > > IMO, if it involves manipulation of the forwarder and/or IW > function then > again it is a local matter as to how the NSP may want to > interact with the > PW protocol machinery. NSPs are also free to convey > signaling messages > amongst themselves in a transparent overlay fashion without > any PW interaction. > > > > > > >I was wondering in which WG should this type of signaling be > defined? and > >has anybody defined > >such a signaling (independent of the Forwarder and IW function) yet? > > This should be dependent on the type and nature of the NSP. > Do you have an > example in mind? > > Cheers ... > > > > >Thanks, > >-Shahram > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > From ppvpn-owner@ppvpn.francetelecom.com Mon Oct 7 11:37:31 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23399 for ; Mon, 7 Oct 2002 11:37:31 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 38E513EC18; Mon, 7 Oct 2002 17:50:43 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 4A97B3EC14 for ; Mon, 7 Oct 2002 17:50:39 +0200 (CEST) Received: from sj-msg-core-4.cisco.com (171.71.163.54) by hermes1.fth.net; 7 Oct 2002 17:39:00 +0200 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g97Fctot006878; Mon, 7 Oct 2002 08:38:55 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g97FcrDx015551; Mon, 7 Oct 2002 08:38:54 -0700 (PDT) Received: from CHMETZ-W2K2.cisco.com (sjc-vpn1-177.cisco.com [10.21.96.177]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA06248; Mon, 7 Oct 2002 08:38:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20021007110128.045c2870@mail1.cisco.com> X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 Oct 2002 11:38:49 -0400 To: Shahram Davari From: Chris Metz Subject: RE: [PWE3] NSP signaling Cc: "'pwe3@ietf.org'" , ppvpn@ppvpn.francetelecom.com In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03999@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 939 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Sharam- At 07:07 AM 10/7/2002 -0700, Shahram Davari wrote: >Chris, > >NSPs may need to coordinate certain parameters with each other. For >example imagine that the service is TDM, and that we are using ATM CES >over MPLS. In that case, the NSPs may need >to inform each other of the type of the traffic (structured, unstructured, >structured w/CAS, etc.). I would think PWE3 since the dynamic programming of the NSPs is needed at each end to establish the PWE3 service. Aren't there LDP TLV placeholders for this kind via the VC FEC interface parameters? This should serve as a useful mechanism to opaquely carry this information from one NSP to another. In my previous response I was thinking more in the context of a broader VPWS-style environment where an NSP may behave as an autonomous signaling/routing node communicating with other like NSP's or native signaling/routing elements. PWE3 certainly should not care what signaling/routing messages may be exchanged between NSP's. Any interaction at all between NSP signaling/routing and PWE3 signaling should be a local matter, IMHO ... Cheers ... > > >I would like to know in which WG should this be defined. > >Thanks, >-Shahram > > > -----Original Message----- > > From: Chris Metz [mailto:chmetz@cisco.com] > > Sent: Monday, October 07, 2002 9:40 AM > > To: Shahram Davari > > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com > > Subject: Re: [PWE3] NSP signaling > > > > > > Shahram- > > > > At 03:07 PM 10/4/2002 -0700, Shahram Davari wrote: > > >Hi, > > > > > >In the PW layering architecture a PE is divided in to PREP > > (pre-processor) > > >and IW. > > >The PREP is further divided to NSP and Forwarder. > > > > > >Draft-rosen and draft-martini define signaling methods for > > communication > > >between IWs or forwarders. > > > > > >Many different services could use the same Forwarder and/or > > IW function. > > >However, they may need their own signaling for configuration > > of their NSP. > > > > Configuration in what sense? If it is specific to an AC > > terminating in the > > local PE (NSP) then it is a local matter outside the scope of > > any WG (PWE3 > > or PPVPN) as far as I can make out. > > > > IMO, if it involves manipulation of the forwarder and/or IW > > function then > > again it is a local matter as to how the NSP may want to > > interact with the > > PW protocol machinery. NSPs are also free to convey > > signaling messages > > amongst themselves in a transparent overlay fashion without > > any PW interaction. > > > > > > > > > > >I was wondering in which WG should this type of signaling be > > defined? and > > >has anybody defined > > >such a signaling (independent of the Forwarder and IW function) yet? > > > > This should be dependent on the type and nature of the NSP. > > Do you have an > > example in mind? > > > > Cheers ... > > > > > > > > >Thanks, > > >-Shahram > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 8 02:10:53 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01008 for ; Tue, 8 Oct 2002 02:10:52 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id C2B193EC19; Tue, 8 Oct 2002 08:24:04 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id B3F993EC11 for ; Tue, 8 Oct 2002 08:24:01 +0200 (CEST) Received: from orc.nn.com (62.90.60.130) by hermes1.fth.net; 8 Oct 2002 08:12:23 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Subject: RE: About PPVPN management X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 8 Oct 2002 08:16:05 +0200 Message-ID: Thread-Topic: About PPVPN management Thread-Index: AcJke26Z/tqLW/dCRg2U515PPTCwPQKFdUiw From: "Yoav Cohen" To: Cc: X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 940 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA01008 -----Original Message----- From: Arnaud Gonguet [mailto:arnaud.gonguet@alcatel.fr] Sent: Wednesday, September 25, 2002 11:04 To: ppvpn@ppvpn.francetelecom.com Subject: About PPVPN management Hi, A couple of months ago, a draft on PPVPN management was submitted to this WG (draft-yacine-ppvpn-mgt-frwk-00.txt). This draft is the very first version of a ppvpn management framework. It aims at describing the ppvpn management reference model and deals with functions, protocols, information models. It could be seen as a starting point to define further standardization efforts on PPVPN related protocols or info models. To improve the contents and relevance of this draft, all requests and comments are appreciated. Thanks, Arnaud Arnaud & Yacine, I'd like to raise some points to the draft's scope. The proposed draft concentrates on the architecture of the Network Management System (e.g. "A customer must have a means to view the topology, operational state, ..."). The reference model and management functions stated in the draft, really point to generic functions used to manage any type of technology. There are several bodies dealing with generic Network Management functionality e.g. ITU and organizations most notably the TeleManagement Forum (http://www.tmforum.org/). What differentiates technologies and services are the details of managing them, i.e. the management interfaces and how they map to these generic functions. Hence I believe that a more practical approach is to define the reference model and interfaces from the network management point of view. So the document should concentrate on: - Defining a PPVPN management reference model (i.e. a reference model that excludes the management function themselves). - Defining the PPVPN management interfaces by mapping according to the FCAPS functions. If needed, differentiate between PE based and CE based interfaces - Defining the management protocols e.g. SNMP, COPS, etc. - Defining the MIBs e.g. SNMP, and other models (if there's interest) I believe that this work can provide the ability for many existing network management platforms supporting various aspects of network management to tailor their models and applications to also support the PPVPN. Best regards, Yoav Cohen. From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 8 03:52:46 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02899 for ; Tue, 8 Oct 2002 03:52:46 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 6E84E3EC1D; Tue, 8 Oct 2002 10:05:57 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id EC79E3EC14 for ; Tue, 8 Oct 2002 10:05:54 +0200 (CEST) Received: from antivir1 (192.114.163.163) by hermes1.fth.net; 8 Oct 2002 09:54:16 +0200 Received: from 192.168.254.14 by antivir1 (InterScan E-Mail VirusWall NT); Tue, 08 Oct 2002 09:30:33 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Oct 2002 09:29:48 +0200 Message-ID: From: Sasha Vainshtein To: "'Chris Metz'" , Shahram Davari Cc: "'pwe3@ietf.org'" , ppvpn@ppvpn.francetelecom.com Subject: RE: [PWE3] NSP signaling Date: Tue, 8 Oct 2002 09:29:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 941 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Shahram, Chris and all, NSP is not a mystic box doing whatever the designer seems fit. It is a _native_ service processor that happens to be part of the PE instead of residing out of it. Hence it should not - and I think the layering draft explains it quite well - do things that are not natively part of the emulated service. Going to Shahram's example, the PWE3 should not care whether the ATM cell stream carried over the PW is generated by an NSP that resides within a PE or by an external device. In particular, the PW behavior should not be affected by the fact that one of its end points is connected to an NSP within the PE performing AAL1 adaptation of a TDM stream while the other is connected to a "native" ATM port with adaptation to TDM being performed by the CE. (The layering document expicitly mentions such use cases - e.g., see Fig. 3). The bottom line: NSP signaling should be out of scope of PWE3. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Chris Metz [mailto:chmetz@cisco.com] > Sent: Monday, October 07, 2002 5:39 PM > To: Shahram Davari > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com > Subject: RE: [PWE3] NSP signaling > > > Sharam- > > At 07:07 AM 10/7/2002 -0700, Shahram Davari wrote: > >Chris, > > > >NSPs may need to coordinate certain parameters with each other. For > >example imagine that the service is TDM, and that we are > using ATM CES > >over MPLS. In that case, the NSPs may need > >to inform each other of the type of the traffic (structured, > unstructured, > >structured w/CAS, etc.). > > I would think PWE3 since the dynamic programming of the NSPs > is needed at > each end to establish the PWE3 service. Aren't there LDP TLV > placeholders > for this kind via the VC FEC interface parameters? This > should serve as a > useful mechanism to opaquely carry this information from one > NSP to another. > > In my previous response I was thinking more in the context of > a broader > VPWS-style environment where an NSP may behave as an autonomous > signaling/routing node communicating with other like NSP's or native > signaling/routing elements. PWE3 certainly should not care what > signaling/routing messages may be exchanged between NSP's. > Any interaction > at all between NSP signaling/routing and PWE3 signaling > should be a local > matter, IMHO ... > > Cheers ... > > > > > > >I would like to know in which WG should this be defined. > > > >Thanks, > >-Shahram > > > > > -----Original Message----- > > > From: Chris Metz [mailto:chmetz@cisco.com] > > > Sent: Monday, October 07, 2002 9:40 AM > > > To: Shahram Davari > > > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com > > > Subject: Re: [PWE3] NSP signaling > > > > > > > > > Shahram- > > > > > > At 03:07 PM 10/4/2002 -0700, Shahram Davari wrote: > > > >Hi, > > > > > > > >In the PW layering architecture a PE is divided in to PREP > > > (pre-processor) > > > >and IW. > > > >The PREP is further divided to NSP and Forwarder. > > > > > > > >Draft-rosen and draft-martini define signaling methods for > > > communication > > > >between IWs or forwarders. > > > > > > > >Many different services could use the same Forwarder and/or > > > IW function. > > > >However, they may need their own signaling for configuration > > > of their NSP. > > > > > > Configuration in what sense? If it is specific to an AC > > > terminating in the > > > local PE (NSP) then it is a local matter outside the scope of > > > any WG (PWE3 > > > or PPVPN) as far as I can make out. > > > > > > IMO, if it involves manipulation of the forwarder and/or IW > > > function then > > > again it is a local matter as to how the NSP may want to > > > interact with the > > > PW protocol machinery. NSPs are also free to convey > > > signaling messages > > > amongst themselves in a transparent overlay fashion without > > > any PW interaction. > > > > > > > > > > > > > > >I was wondering in which WG should this type of signaling be > > > defined? and > > > >has anybody defined > > > >such a signaling (independent of the Forwarder and IW > function) yet? > > > > > > This should be dependent on the type and nature of the NSP. > > > Do you have an > > > example in mind? > > > > > > Cheers ... > > > > > > > > > > > > >Thanks, > > > >-Shahram > > > >_______________________________________________ > > > >pwe3 mailing list > > > >pwe3@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 8 05:39:41 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04592 for ; Tue, 8 Oct 2002 05:39:41 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 2577D3EC1E; Tue, 8 Oct 2002 11:52:53 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 3021A3EC14 for ; Tue, 8 Oct 2002 11:52:49 +0200 (CEST) Received: from smail3.alcatel.fr (213.223.66.5) by hermes1.fth.net; 8 Oct 2002 11:41:10 +0200 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id g989f99D013419 for ; Tue, 8 Oct 2002 11:41:09 +0200 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2002100811410724:3367 ; Tue, 8 Oct 2002 11:41:07 +0200 Message-ID: <3DA2A878.4040309@alcatel.fr> Date: Tue, 08 Oct 2002 11:42:16 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: "ppvpn@ppvpn.francetelecom.com" Subject: [Fwd: Re: About PPVPN management] X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/08/2002 11:41:07, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/08/2002 11:41:08, Serialize complete at 10/08/2002 11:41:08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1255; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 942 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 7bit hi yoav, I fully agree with your statements. the -00 version of the draft is still generic and we are now waiting for working group interest before further developing this work. thanks, yacine el mghazli Yoav Cohen wrote: > > -----Original Message----- > From: Arnaud Gonguet [mailto:arnaud.gonguet@alcatel.fr] > Sent: Wednesday, September 25, 2002 11:04 > To: ppvpn@ppvpn.francetelecom.com > Subject: About PPVPN management > > > Hi, > > A couple of months ago, a draft on PPVPN management was submitted to this WG (draft-yacine-ppvpn-mgt-frwk-00.txt). This draft is the very > first version of a ppvpn management framework. It aims at describing the ppvpn management reference model and deals with functions, > protocols, information models. It could be seen as a starting point to define further standardization efforts on PPVPN related protocols > or info models. > > To improve the contents and relevance of this draft, all requests and comments are appreciated. > > > Thanks, > > Arnaud > > > Arnaud & Yacine, > I'd like to raise some points to the draft's scope. > The proposed draft concentrates on the architecture of the Network Management System (e.g. "A customer must have a means to view the topology, operational state, ..."). > The reference model and management functions stated in the draft, really point to generic functions used to manage any type of technology. There are several bodies dealing with generic Network Management functionality e.g. ITU and organizations most notably the TeleManagement Forum (http://www.tmforum.org/). > What differentiates technologies and services are the details of managing them, i.e. the management interfaces and how they map to these generic functions. > Hence I believe that a more practical approach is to define the reference model and interfaces from the network management point of view. So the document should concentrate on: > > - Defining a PPVPN management reference model (i.e. a reference model that excludes the management function themselves). > - Defining the PPVPN management interfaces by mapping according to the FCAPS functions. If needed, differentiate between PE based and CE based interfaces > - Defining the management protocols e.g. SNMP, COPS, etc. > - Defining the MIBs e.g. SNMP, and other models (if there's interest) > > I believe that this work can provide the ability for many existing network management platforms supporting various aspects of network management to tailor their models and applications to also support the PPVPN. > > Best regards, > Yoav Cohen. > > > > > From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 8 07:14:42 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06375 for ; Tue, 8 Oct 2002 07:14:42 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 6FF1B3EC1E; Tue, 8 Oct 2002 13:27:54 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id ADF753EC11 for ; Tue, 8 Oct 2002 13:27:49 +0200 (CEST) Received: from ietf.org (132.151.1.176) by hermes1.fth.net; 8 Oct 2002 13:16:11 +0200 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06218; Tue, 8 Oct 2002 07:14:05 -0400 (EDT) Message-Id: <200210081114.HAA06218@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@ppvpn.francetelecom.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Tue, 08 Oct 2002 07:14:04 -0400 Sender: nsyracus@cnri.reston.va.us X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 943 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Virtual Hierarchical LAN Services Author(s) : A. Sodder Filename : draft-sodder-ppvpn-vhls-00.txt Pages : 12 Date : 2002-10-7 This draft describes an Ethernet [IEEE-802.3] L2VPN model that provides point-to-point and point-to-multipoint Layer 2 data communication services using a hierarchical LAN switching architecture. The model is based on a hierarchical MAC frame format. Scalability and manageability is achieved by simplifying the control plane at the cost of adding functionality to the forwarding plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sodder-ppvpn-vhls-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sodder-ppvpn-vhls-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-sodder-ppvpn-vhls-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. --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: <2002-10-7141234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sodder-ppvpn-vhls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sodder-ppvpn-vhls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-7141234.I-D@ietf.org> --OtherAccess-- --NextPart-- From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 8 09:59:45 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13725 for ; Tue, 8 Oct 2002 09:59:44 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id B80F33EC1D; Tue, 8 Oct 2002 16:12:55 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id BB3B83EC11 for ; Tue, 8 Oct 2002 16:12:45 +0200 (CEST) Received: from CIMA.coriolisnet.com (205.229.88.162) by hermes1.fth.net; 8 Oct 2002 16:01:07 +0200 Received: by CIMA.coriolisnet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Oct 2002 10:01:06 -0400 Message-ID: From: Joris wils To: "'asodder@tenornetworks.com'" Cc: ppvpn@ppvpn.francetelecom.com Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Tue, 8 Oct 2002 10:01:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 944 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Arnold: I like this draft, because it stays close to Ethernet and 802.1, thus having good multicast properties where topologies allow. However, you effectively propose to expand the VLAN ID of the encapsulated frame, your VHLS-ICW field, from 16 bits to 32 bits. Thus, the frames become non-IEEE 802.1 compliant. I assume you proposed that to get beyond the 4k VLAN bottleneck imposed by the 16 bit VLAN ID. However, the "wave" in the IEEE 802.1 committee and the Metro Ethernet Forum is to get beyond this bottleneck with VLAN tag stacking and tag translation instead, so that minimal or no changes will be required to existing equipment. Would you consider defining the VHLS-ICW field to be 16 bits and for the L2VPN identifier within to have local significance within the tree headed by a PE? Then the encapsulated frames will be 802.1 compliant. Signalling would be needed between the PEs, not the L2PEs, to exchange the local L2VPN-ids and the PEs would have to support tag translation. However, I think this is less objectionable than trying to change the format of an 802.1 frame. Joris -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, October 08, 2002 7:14 AM Cc: ppvpn@ppvpn.francetelecom.com Subject: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Virtual Hierarchical LAN Services Author(s) : A. Sodder Filename : draft-sodder-ppvpn-vhls-00.txt Pages : 12 Date : 2002-10-7 This draft describes an Ethernet [IEEE-802.3] L2VPN model that provides point-to-point and point-to-multipoint Layer 2 data communication services using a hierarchical LAN switching architecture. The model is based on a hierarchical MAC frame format. Scalability and manageability is achieved by simplifying the control plane at the cost of adding functionality to the forwarding plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sodder-ppvpn-vhls-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sodder-ppvpn-vhls-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-sodder-ppvpn-vhls-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. From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 8 11:49:59 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19105 for ; Tue, 8 Oct 2002 11:49:59 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 4119A3EC1D; Tue, 8 Oct 2002 18:03:11 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id BD8153EC11 for ; Tue, 8 Oct 2002 18:03:08 +0200 (CEST) Received: from sj-msg-core-4.cisco.com (171.71.163.54) by hermes1.fth.net; 8 Oct 2002 17:51:30 +0200 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g98FpEot012976; Tue, 8 Oct 2002 08:51:14 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g98FpCIJ022159; Tue, 8 Oct 2002 08:51:13 -0700 (PDT) Received: from CHMETZ-W2K2.cisco.com (sjc-vpn2-721.cisco.com [10.21.114.209]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA15751; Tue, 8 Oct 2002 08:51:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20021008113541.02874878@mail1.cisco.com> X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Oct 2002 11:51:05 -0400 To: Sasha Vainshtein From: Chris Metz Subject: RE: [PWE3] NSP signaling Cc: Shahram Davari , "'pwe3@ietf.org'" , ppvpn@ppvpn.francetelecom.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 945 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Sasha/all- Agree. But the question involved NSP signaling. I think it can be done in one of two ways without violating principles laid down in the PLD: 1. Transparently tunnel it ... this is the easiest 2. Interwork NSP with PW signaling. This is the hardest and should not involve any changes to PW signaling behavior. It is strictly an implementation matter left up to the designers. Cheers ... At 09:29 AM 10/8/2002 +0200, Sasha Vainshtein wrote: >Shahram, Chris and all, >NSP is not a mystic box doing whatever the designer >seems fit. >It is a _native_ service processor that happens to be >part of the PE instead of residing out of it. >Hence it should not - and I think the layering draft >explains it quite well - do things that are not natively >part of the emulated service. >Going to Shahram's example, the PWE3 should not care >whether the ATM cell stream carried over the PW is >generated by an NSP that resides within a PE or by an >external device. In particular, the PW behavior should >not be affected by the fact that one of its end points >is connected to an NSP within the PE performing AAL1 >adaptation of a TDM stream while the other >is connected to a "native" ATM port with adaptation >to TDM being performed by the CE. (The layering document >expicitly mentions such use cases - e.g., see Fig. 3). > >The bottom line: NSP signaling should be out of scope of >PWE3. >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Chris Metz [mailto:chmetz@cisco.com] > > Sent: Monday, October 07, 2002 5:39 PM > > To: Shahram Davari > > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com > > Subject: RE: [PWE3] NSP signaling > > > > > > Sharam- > > > > At 07:07 AM 10/7/2002 -0700, Shahram Davari wrote: > > >Chris, > > > > > >NSPs may need to coordinate certain parameters with each other. For > > >example imagine that the service is TDM, and that we are > > using ATM CES > > >over MPLS. In that case, the NSPs may need > > >to inform each other of the type of the traffic (structured, > > unstructured, > > >structured w/CAS, etc.). > > > > I would think PWE3 since the dynamic programming of the NSPs > > is needed at > > each end to establish the PWE3 service. Aren't there LDP TLV > > placeholders > > for this kind via the VC FEC interface parameters? This > > should serve as a > > useful mechanism to opaquely carry this information from one > > NSP to another. > > > > In my previous response I was thinking more in the context of > > a broader > > VPWS-style environment where an NSP may behave as an autonomous > > signaling/routing node communicating with other like NSP's or native > > signaling/routing elements. PWE3 certainly should not care what > > signaling/routing messages may be exchanged between NSP's. > > Any interaction > > at all between NSP signaling/routing and PWE3 signaling > > should be a local > > matter, IMHO ... > > > > Cheers ... > > > > > > > > > > >I would like to know in which WG should this be defined. > > > > > >Thanks, > > >-Shahram > > > > > > > -----Original Message----- > > > > From: Chris Metz [mailto:chmetz@cisco.com] > > > > Sent: Monday, October 07, 2002 9:40 AM > > > > To: Shahram Davari > > > > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com > > > > Subject: Re: [PWE3] NSP signaling > > > > > > > > > > > > Shahram- > > > > > > > > At 03:07 PM 10/4/2002 -0700, Shahram Davari wrote: > > > > >Hi, > > > > > > > > > >In the PW layering architecture a PE is divided in to PREP > > > > (pre-processor) > > > > >and IW. > > > > >The PREP is further divided to NSP and Forwarder. > > > > > > > > > >Draft-rosen and draft-martini define signaling methods for > > > > communication > > > > >between IWs or forwarders. > > > > > > > > > >Many different services could use the same Forwarder and/or > > > > IW function. > > > > >However, they may need their own signaling for configuration > > > > of their NSP. > > > > > > > > Configuration in what sense? If it is specific to an AC > > > > terminating in the > > > > local PE (NSP) then it is a local matter outside the scope of > > > > any WG (PWE3 > > > > or PPVPN) as far as I can make out. > > > > > > > > IMO, if it involves manipulation of the forwarder and/or IW > > > > function then > > > > again it is a local matter as to how the NSP may want to > > > > interact with the > > > > PW protocol machinery. NSPs are also free to convey > > > > signaling messages > > > > amongst themselves in a transparent overlay fashion without > > > > any PW interaction. > > > > > > > > > > > > > > > > > > >I was wondering in which WG should this type of signaling be > > > > defined? and > > > > >has anybody defined > > > > >such a signaling (independent of the Forwarder and IW > > function) yet? > > > > > > > > This should be dependent on the type and nature of the NSP. > > > > Do you have an > > > > example in mind? > > > > > > > > Cheers ... > > > > > > > > > > > > > > > > >Thanks, > > > > >-Shahram > > > > >_______________________________________________ > > > > >pwe3 mailing list > > > > >pwe3@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 8 12:23:03 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20456 for ; Tue, 8 Oct 2002 12:23:03 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 77A723EC1D; Tue, 8 Oct 2002 18:36:15 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id A71B23EC11 for ; Tue, 8 Oct 2002 18:36:08 +0200 (CEST) Received: from antivir1 (192.114.163.163) by hermes1.fth.net; 8 Oct 2002 18:24:30 +0200 Received: from 192.168.254.14 by antivir1 (InterScan E-Mail VirusWall NT); Tue, 08 Oct 2002 18:22:50 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Oct 2002 18:22:05 +0200 Message-ID: From: Sasha Vainshtein To: "'Chris Metz'" Cc: Shahram Davari , "'pwe3@ietf.org'" , ppvpn@ppvpn.francetelecom.com Subject: RE: [PWE3] NSP signaling Date: Tue, 8 Oct 2002 18:22:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 946 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Chris and all, Please see some comments inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Chris Metz [mailto:chmetz@cisco.com] > Sent: Tuesday, October 08, 2002 5:51 PM > To: Sasha Vainshtein > Cc: Shahram Davari; 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com > Subject: RE: [PWE3] NSP signaling > > > Sasha/all- > Agree. But the question involved NSP signaling. I think it > can be done in > one of two ways without violating principles laid down in the PLD: > > 1. Transparently tunnel it ... this is the easiest > If it exists natively. I assume that if it doesn't exist, you do not invent it for the PW use. > > 2. Interwork NSP with PW signaling. This is the hardest and > should not > involve any changes to PW signaling behavior. It is strictly an > implementation matter left up to the designers. > I do not see any problem with a transparent placeholder in the PW signaling (like Optional Interface Descriptor string in Section 5.1 of draft-ietf-pwe3-control-protocol-00.txt). Of course interpretation of any data sent in such a placeholder is purely a local matter. In particular, the PW setup MUST NOT be rejected based on inability to fill or interpret this information. I assume that this is what you mean by "not involving any changes in the PW signaling behavior". > > Cheers ... > > > > > At 09:29 AM 10/8/2002 +0200, Sasha Vainshtein wrote: > >Shahram, Chris and all, > >NSP is not a mystic box doing whatever the designer > >seems fit. > >It is a _native_ service processor that happens to be > >part of the PE instead of residing out of it. > >Hence it should not - and I think the layering draft > >explains it quite well - do things that are not natively > >part of the emulated service. > >Going to Shahram's example, the PWE3 should not care > >whether the ATM cell stream carried over the PW is > >generated by an NSP that resides within a PE or by an > >external device. In particular, the PW behavior should > >not be affected by the fact that one of its end points > >is connected to an NSP within the PE performing AAL1 > >adaptation of a TDM stream while the other > >is connected to a "native" ATM port with adaptation > >to TDM being performed by the CE. (The layering document > >expicitly mentions such use cases - e.g., see Fig. 3). > > > >The bottom line: NSP signaling should be out of scope of > >PWE3. > >With best regards, > > Sasha Vainshtein > >email: sasha@axerra.com > >tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > > > -----Original Message----- > > > From: Chris Metz [mailto:chmetz@cisco.com] > > > Sent: Monday, October 07, 2002 5:39 PM > > > To: Shahram Davari > > > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com > > > Subject: RE: [PWE3] NSP signaling > > > > > > > > > Sharam- > > > > > > At 07:07 AM 10/7/2002 -0700, Shahram Davari wrote: > > > >Chris, > > > > > > > >NSPs may need to coordinate certain parameters with each > other. For > > > >example imagine that the service is TDM, and that we are > > > using ATM CES > > > >over MPLS. In that case, the NSPs may need > > > >to inform each other of the type of the traffic (structured, > > > unstructured, > > > >structured w/CAS, etc.). > > > > > > I would think PWE3 since the dynamic programming of the NSPs > > > is needed at > > > each end to establish the PWE3 service. Aren't there LDP TLV > > > placeholders > > > for this kind via the VC FEC interface parameters? This > > > should serve as a > > > useful mechanism to opaquely carry this information from one > > > NSP to another. > > > > > > In my previous response I was thinking more in the context of > > > a broader > > > VPWS-style environment where an NSP may behave as an autonomous > > > signaling/routing node communicating with other like > NSP's or native > > > signaling/routing elements. PWE3 certainly should not care what > > > signaling/routing messages may be exchanged between NSP's. > > > Any interaction > > > at all between NSP signaling/routing and PWE3 signaling > > > should be a local > > > matter, IMHO ... > > > > > > Cheers ... > > > > > > > > > > > > > > >I would like to know in which WG should this be defined. > > > > > > > >Thanks, > > > >-Shahram > > > > > > > > > -----Original Message----- > > > > > From: Chris Metz [mailto:chmetz@cisco.com] > > > > > Sent: Monday, October 07, 2002 9:40 AM > > > > > To: Shahram Davari > > > > > Cc: 'pwe3@ietf.org'; ppvpn@ppvpn.francetelecom.com > > > > > Subject: Re: [PWE3] NSP signaling > > > > > > > > > > > > > > > Shahram- > > > > > > > > > > At 03:07 PM 10/4/2002 -0700, Shahram Davari wrote: > > > > > >Hi, > > > > > > > > > > > >In the PW layering architecture a PE is divided in to PREP > > > > > (pre-processor) > > > > > >and IW. > > > > > >The PREP is further divided to NSP and Forwarder. > > > > > > > > > > > >Draft-rosen and draft-martini define signaling methods for > > > > > communication > > > > > >between IWs or forwarders. > > > > > > > > > > > >Many different services could use the same Forwarder and/or > > > > > IW function. > > > > > >However, they may need their own signaling for configuration > > > > > of their NSP. > > > > > > > > > > Configuration in what sense? If it is specific to an AC > > > > > terminating in the > > > > > local PE (NSP) then it is a local matter outside the scope of > > > > > any WG (PWE3 > > > > > or PPVPN) as far as I can make out. > > > > > > > > > > IMO, if it involves manipulation of the forwarder and/or IW > > > > > function then > > > > > again it is a local matter as to how the NSP may want to > > > > > interact with the > > > > > PW protocol machinery. NSPs are also free to convey > > > > > signaling messages > > > > > amongst themselves in a transparent overlay fashion without > > > > > any PW interaction. > > > > > > > > > > > > > > > > > > > > > > >I was wondering in which WG should this type of signaling be > > > > > defined? and > > > > > >has anybody defined > > > > > >such a signaling (independent of the Forwarder and IW > > > function) yet? > > > > > > > > > > This should be dependent on the type and nature of the NSP. > > > > > Do you have an > > > > > example in mind? > > > > > > > > > > Cheers ... > > > > > > > > > > > > > > > > > > > > >Thanks, > > > > > >-Shahram > > > > > >_______________________________________________ > > > > > >pwe3 mailing list > > > > > >pwe3@ietf.org > > > > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > >_______________________________________________ > > > >pwe3 mailing list > > > >pwe3@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > From ppvpn-owner@ppvpn.francetelecom.com Thu Oct 10 08:34:57 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00820 for ; Thu, 10 Oct 2002 08:34:57 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id D93273EC1E; Thu, 10 Oct 2002 14:48:08 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id A9BF13EC12 for ; Thu, 10 Oct 2002 14:48:03 +0200 (CEST) Received: from ariadne.dt.fee.unicamp.br (143.106.8.45) by hermes1.fth.net; 10 Oct 2002 14:36:26 +0200 Received: from calipso.dt.fee.unicamp.br (calipso.dt.fee.unicamp.br [143.106.12.37]) by ariadne.dt.fee.unicamp.br (8.9.3/8.9.3) with ESMTP id JAA11373; Thu, 10 Oct 2002 09:32:01 -0300 (EST) Date: Thu, 10 Oct 2002 09:35:46 -0300 (EST) From: Marcel Cavalcanti De Castro To: ppvpn@ppvpn.francetelecom.com, mpls-ops@mplsrc.com Subject: VPN based VR or VPN based RFC2547bis ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 947 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8BIT HI I´m trying to do a comparison between VPN based VR and VPN based RFC2547bis, but I have two basic questions: - What was the motivation to create the VPN based VR instead of trying to work only with VPN based RFC2547bis?(Is it a commercial or scalability issue?) Because I read some documents and I supposed that the main difference between the two architectures resides in the model used to achieve VPN reachability and membership functions. Are there more differences? - Do we can choose one of this architecture when we talk about the scalability point of view? I'd appreciate any comments @> /()\ -^^--------------------------------------------------------- Marcel Cavalcanti de Castro Departamento de Telemática - DT Universidade Estadual de Campinas - UNICAMP www.dt.fee.unicamp.br/~castro ICQ: 131702293 ----------------------------------------------------------- From ppvpn-owner@ppvpn.francetelecom.com Thu Oct 10 08:55:50 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01654 for ; Thu, 10 Oct 2002 08:55:49 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id DC8EF3EC1E; Thu, 10 Oct 2002 15:09:02 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id B968E3EC12 for ; Thu, 10 Oct 2002 15:08:58 +0200 (CEST) Received: from smail3.alcatel.fr (213.223.66.5) by hermes1.fth.net; 10 Oct 2002 14:57:21 +0200 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id g9ACua9D024474; Thu, 10 Oct 2002 14:56:36 +0200 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2002101014563489:5195 ; Thu, 10 Oct 2002 14:56:34 +0200 Message-ID: <3DA57949.1080300@alcatel.fr> Date: Thu, 10 Oct 2002 14:57:45 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Marcel Cavalcanti De Castro Cc: ppvpn@ppvpn.francetelecom.com Subject: Re: VPN based VR or VPN based RFC2547bis ? References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/10/2002 14:56:34, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/10/2002 14:56:35 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 948 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA01654 Check the applicability statements (as) drafts on the ppvpn web page. yacine Marcel Cavalcanti De Castro wrote: > HI > I´m trying to do a comparison between VPN based VR and VPN based > RFC2547bis, but I have two basic questions: > > - What was the motivation to create the VPN based VR instead of > trying to work only with VPN based RFC2547bis?(Is it a > commercial or scalability issue?) > Because I read some documents and I supposed that the main > difference between the two architectures resides in the model used > to achieve VPN reachability and membership functions. Are there more > differences? > > - Do we can choose one of this architecture when we talk about the > scalability point of view? > > > I'd appreciate any comments > > @> > /()\ > -^^--------------------------------------------------------- > Marcel Cavalcanti de Castro > Departamento de Telemática - DT > Universidade Estadual de Campinas - UNICAMP > www.dt.fee.unicamp.br/~castro > ICQ: 131702293 > ----------------------------------------------------------- > > > > From ppvpn-owner@ppvpn.francetelecom.com Thu Oct 10 14:11:46 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18421 for ; Thu, 10 Oct 2002 14:11:46 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 140123EC1E; Thu, 10 Oct 2002 20:24:58 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 6E2C23EC12 for ; Thu, 10 Oct 2002 20:24:48 +0200 (CEST) Received: from hawk.CrescentNetworks.com (66.105.92.144) by hermes1.fth.net; 10 Oct 2002 20:13:11 +0200 Received: from CrescentNetworks.com (jcucchiara.in.crescentnets.com [192.168.29.132]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id OAA01944; Thu, 10 Oct 2002 14:13:09 -0400 (EDT) Message-ID: <3DA5C346.931EF361@CrescentNetworks.com> Date: Thu, 10 Oct 2002 14:13:26 -0400 From: Joan Cucchiara X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ppvpn@ppvpn.francetelecom.com, sam@coronanetworks.com, elwin@coronanetworks.com, benson.schliesser@savvis.net Subject: questions on draft-ietf-ppvpn-vr-mib-02.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 949 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 7bit Hello, A few questions and comments on the MIB. 1) Is the Internal Virtual Link used to connect to VRs in the same PE, or is it a link between VRs in a different PEs? 2) Is there a one to many relationship between the vrTunnelIpAddress and the Virtual Routers? 3) do you want any scalars to configure the number of VRs on the device? 4) regarding VPN-ID, have you considered adding some sort of mapping table to which is indexed by VPN-ID, VR? 5) Having a TC called VrIndexOrZero which is like the above but includes zero, where zero needs to be defined in the Description Clause of the objects * for VrConfigNextAvailableVrId have zero mean that no more VRs can be created. (for example, if the device is out of resources) * for vrId have zero mean that VR 0 is the NULL VR. 6) Limit the vrName to fewer characters (32 is probably good, but could be bigger. 255 seems quite large). This description should probably say these names need to be unique within the table. 7) vrAdminStatus: could testing be added here? 8) vrContextName - why is this a read-create and not a read-only? 9) vrType, not clear what this is, could more description be added? 10) (minor) please change the vrStat to be vrStatus 11) RouterId should this be 2 objects ( AddressType and Address ) (as in the INET-ADDRESS-MIB). 12) have you considered having the VrIfTable indexed by vrId and vrIfIndex ? (seems like a VR would want to quickly see all of its interfaces). 13) vrUp/vrDown traps need to contain a varbind. The vrId is an index. Thanks, Joan From ppvpn-owner@ppvpn.francetelecom.com Thu Oct 10 14:35:13 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19092 for ; Thu, 10 Oct 2002 14:35:13 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 4CBD23EC20; Thu, 10 Oct 2002 20:48:26 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 90BE23EC12 for ; Thu, 10 Oct 2002 20:48:22 +0200 (CEST) Received: from tenornetworks.com (63.77.213.2) by hermes1.fth.net; 10 Oct 2002 20:36:45 +0200 Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9AIag821908; Thu, 10 Oct 2002 14:36:43 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; THU, 10 Oct 2002 14:33:14 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Oct 2002 14:33:14 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E5601BCE9D7@newman.tenornet.com> From: "Sodder, Arnold" To: Joris wils , "'asodder@tenornetworks.com'" Cc: ppvpn@ppvpn.francetelecom.com Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Thu, 10 Oct 2002 14:33:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 950 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Joris: Thanks for your comments. My plan does not propose expanding the VLAN Tag to 32 bits. It proposes defining a new ethernet-type which describes how an ethernet frame is encapsulated in another ethernet frame with a control word that defines a VPN-id. The proposal is still 802.1 compliant and todays L2 switches will be able to switch the frame based on its outer MAC address. As with the stacked VLAN Tag approach, the L2 switch will need to handle the larger frame size. The biggest advantage of my plan is the simplicity at the control plane where it does not require signaling of a per VC label. For this the VPN identifier must be a global number within the network. Another benefit of this approach is that the MAC address tables on the L2PE and PE exhibit better scalability. Hopefully this clears up the need to a new ethernet type and the VHLS-ICW. Arnold -----Original Message----- From: Joris wils [mailto:jwils@coriolisnet.com] Sent: Tuesday, October 08, 2002 10:01 AM To: 'asodder@tenornetworks.com' Cc: ppvpn@ppvpn.francetelecom.com Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Arnold: I like this draft, because it stays close to Ethernet and 802.1, thus having good multicast properties where topologies allow. However, you effectively propose to expand the VLAN ID of the encapsulated frame, your VHLS-ICW field, from 16 bits to 32 bits. Thus, the frames become non-IEEE 802.1 compliant. I assume you proposed that to get beyond the 4k VLAN bottleneck imposed by the 16 bit VLAN ID. However, the "wave" in the IEEE 802.1 committee and the Metro Ethernet Forum is to get beyond this bottleneck with VLAN tag stacking and tag translation instead, so that minimal or no changes will be required to existing equipment. Would you consider defining the VHLS-ICW field to be 16 bits and for the L2VPN identifier within to have local significance within the tree headed by a PE? Then the encapsulated frames will be 802.1 compliant. Signalling would be needed between the PEs, not the L2PEs, to exchange the local L2VPN-ids and the PEs would have to support tag translation. However, I think this is less objectionable than trying to change the format of an 802.1 frame. Joris -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, October 08, 2002 7:14 AM Cc: ppvpn@ppvpn.francetelecom.com Subject: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Virtual Hierarchical LAN Services Author(s) : A. Sodder Filename : draft-sodder-ppvpn-vhls-00.txt Pages : 12 Date : 2002-10-7 This draft describes an Ethernet [IEEE-802.3] L2VPN model that provides point-to-point and point-to-multipoint Layer 2 data communication services using a hierarchical LAN switching architecture. The model is based on a hierarchical MAC frame format. Scalability and manageability is achieved by simplifying the control plane at the cost of adding functionality to the forwarding plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sodder-ppvpn-vhls-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sodder-ppvpn-vhls-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-sodder-ppvpn-vhls-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. From ppvpn-owner@ppvpn.francetelecom.com Thu Oct 10 15:54:54 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21648 for ; Thu, 10 Oct 2002 15:54:54 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 1B48F3EC20; Thu, 10 Oct 2002 22:08:07 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 2E9E53EC12 for ; Thu, 10 Oct 2002 22:08:04 +0200 (CEST) Received: from hotmail.com (216.33.241.86) by hermes1.fth.net; 10 Oct 2002 21:56:27 +0200 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 10 Oct 2002 12:56:26 -0700 Received: from 200.198.64.36 by lw8fd.law8.hotmail.msn.com with HTTP; Thu, 10 Oct 2002 19:56:25 GMT X-Originating-IP: [200.198.64.36] From: "Rubens Gomes" To: ppvpn@ppvpn.francetelecom.com Subject: MPLS-VPN-MIB Date: Thu, 10 Oct 2002 19:56:25 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Oct 2002 19:56:26.0458 (UTC) FILETIME=[1DF233A0:01C27097] X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 951 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com I am working with IP MPLS VPN for a telco company in Brazil, and I am planing to use the MPLS-VPN MIB as part of our VPN management strategy. I was wondering on the current status of the MPLS-VPN-MIB development? Any plans to release a new internet draft version soon? Or maybe expected date for RFC? Also, is it possible for me to download a copy of the latest MPLS-VPN-MIB, and compile it in my HP OpenView? Where is the MIB file available? Rubens S. Gomes http://www.rubens-gomes.com _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From ppvpn-owner@ppvpn.francetelecom.com Thu Oct 10 16:05:10 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22096 for ; Thu, 10 Oct 2002 16:05:10 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id A8D173EC22; Thu, 10 Oct 2002 22:18:23 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 9C1013EC12 for ; Thu, 10 Oct 2002 22:18:19 +0200 (CEST) Received: from rtp-msg-core-1.cisco.com (161.44.11.97) by hermes1.fth.net; 10 Oct 2002 22:06:42 +0200 Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9AK6lF2027786; Thu, 10 Oct 2002 16:06:47 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (ch2-dhcp134-166.cisco.com [161.44.134.166]) by bucket.cisco.com (Mirapoint) with ESMTP id ABX91880; Thu, 10 Oct 2002 16:06:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20021010160442.01e052d8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Oct 2002 16:06:39 -0400 To: "Rubens Gomes" From: "Thomas D. Nadeau" Subject: Re: MPLS-VPN-MIB Cc: ppvpn@ppvpn.francetelecom.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 952 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com >I am working with IP MPLS VPN for a telco company >in Brazil, and I am planing to use the MPLS-VPN MIB as >part of our VPN management strategy. Cool. >I was wondering on the current status of the MPLS-VPN-MIB >development? Any plans to release a new internet draft version >soon? Or maybe expected date for RFC? Yes, we have a few more changes to add to the MIB in a future update. However, the co-authors have been swamped since the last meeting, so we have not done the updates. I can say that the updates are not major, at least right now. Please look over the existing version and send comments to this list if you have any questions or comments. >Also, is it possible for me to download a copy of the >latest MPLS-VPN-MIB, and compile it in my HP OpenView? Where >is the MIB file available? http://www.ietf.org/html.charters/ppvpn-charter.html --Tom Success is relative; the more success, the more relatives. -Anonymous From ppvpn-owner@ppvpn.francetelecom.com Thu Oct 10 16:44:40 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23552 for ; Thu, 10 Oct 2002 16:44:40 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 8DE563EC22; Thu, 10 Oct 2002 22:57:53 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id E48043EC12 for ; Thu, 10 Oct 2002 22:57:50 +0200 (CEST) Received: from mtiwmhc11.worldnet.att.net (204.127.131.115) by hermes1.fth.net; 10 Oct 2002 22:46:14 +0200 Received: from 6640bbc3r131 ([12.81.6.90]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP id <20021010204611.JTZA20527.mtiwmhc11.worldnet.att.net@6640bbc3r131>; Thu, 10 Oct 2002 20:46:11 +0000 Message-ID: <001301c2709e$2f6e59e0$5a06510c@6640bbc3r131> From: "Brijesh Kumar" To: "Marcel Cavalcanti De Castro" , , References: Subject: Re: VPN based VR or VPN based RFC2547bis ? Date: Thu, 10 Oct 2002 13:46:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 953 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit ----- Original Message ----- From: "Marcel Cavalcanti De Castro" To: ; > I´m trying to do a comparison between VPN based VR and VPN based > RFC2547bis, but I have two basic questions: > > - What was the motivation to create the VPN based VR instead of > trying to work only with VPN based RFC2547bis?(Is it a > commercial or scalability issue?) > Because I read some documents and I supposed that the main > difference between the two architectures resides in the model used > to achieve VPN reachability and membership functions. Are there more > differences? Marcel, These are two different approaches to solve the problem - each with its own merits and demerits with regards to various features including scalability. And, that means that there is no clear cut winner here, and each vendor and the carrier has their own preference (including political alignments). The scalability of a VR model implementation is limited by the ability to run multiple logical instances of an intra-domain routing protocol such as ospf, is-is or RIP on the available control processor. Some vendors implement VRs by modifying one routing task and multiplexing routing contexts, while others may create as many routing task instances as VRs. No matter which approach you use for implementation, there is a limit on how much control traffic your control processor(s) can handle in the system. Maintaining huge number of IGP adjacencies requires quite lot of work and the available processor may not be able to keep the pace with the amount of work required (N VRs with M adjacencies lead to MN adjacencies). This will result in the system loosing adjacencies or unable to maiantain them for long time (hello time outs). That, alongwith available on-board memory, defines the limit of scalability for the VR model. If your processor(s) can keep pace with the control packets, then implementation is very clean and full VPN isolation is maintained between various VR instances. This model integrates very well with many other IPServices such as Firewall, NAT and providing Internet Access. And, of course you run secure IPSEC tunnels between VRs to create VPNs. BGP-MPLS model, on the other hand, extended BGP to multiplex routing and VPN membership information within its multi-protocol attribute. BGP doesn't scale without off-loading a lot of the filtering and processing to one or more Route Refelectors, and also requires many VPN specific extensions to BGP and route reflector processing. Since, too many things are being multiplexed over a BGP session (something for which it wasn't originally designed) the implementation of model is quite complex compared to VR model. In the case of BGP/MPLS VPNs, you may not have as many IGP control packets to maintain routing adjacencies as in the VR model, but you have to now process much more complex multiplexed routing and membership information over less number of BGP sessions. Given BGPs route computation and policy application requirements, this computation for large number of VRs requires quite a lot of computation in your system's control path. So, it also runs into the same problem as a VR model as the number of VRFs and the number of VPN sites increase. And, also it is somewhat less cleaner way to implement isolation between VRs (if you need to run IGP like ospf between multiple VPN sites - this model may be made to work, but you would require distribution and redistribution of routes between IGP and BGP at the VPN routers. And also some other restrictions how ospf areas can be configured etc.). Also, integration with other IP services such firewall etc. is somewhat less elegent (in addition to that you need mpls - yet another headache to develop or maintain for some). All said and done, the implementation works fine and many carriers find is as good and secure as the VR model. > - Do we can choose one of this architecture when we talk about the > scalability point of view? I don't think there is a definite answer to this. It depends on how smartly a particular vendor implemented and how much processing power a VPN router packs in it. Cheers, --brijesh From ppvpn-owner@ppvpn.francetelecom.com Fri Oct 11 03:01:47 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12972 for ; Fri, 11 Oct 2002 03:01:46 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id DA56D3EC1E; Fri, 11 Oct 2002 09:14:58 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 860813EC12 for ; Fri, 11 Oct 2002 09:14:47 +0200 (CEST) Received: from mta0 (61.144.161.10) by hermes1.fth.net; 11 Oct 2002 09:03:11 +0200 Received: from d07358 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H3T00505263QU@mta0.huawei.com> for ppvpn@ppvpn.francetelecom.com; Fri, 11 Oct 2002 15:01:16 +0800 (CST) Date: Fri, 11 Oct 2002 15:15:46 +0800 From: Du Wenhua Subject: Re: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt To: "Sodder, Arnold" Cc: "ppvpn@ppvpn.francetelecom.com" Reply-To: duwh@huawei.com Message-id: <0H3T00506263QU@mta0.huawei.com> Organization: Huawei Techlonogies, Co., Ltd MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: multipart/alternative; boundary="Boundary_(ID_7tzENZm6HUGPsSy3EeOIMg)" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 954 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com This is a multi-part message in MIME format. --Boundary_(ID_7tzENZm6HUGPsSy3EeOIMg) Content-type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,Sodder, Arnold=A3=A1 [VHLS] say: In the above frame formats the CE frame MUST -include- the original CRC32 to allow detection of bit errors introduced by devices in the service provider network or attached to the service provider network. If the L2PE device needs to modify the CE frame it MUST calculate and add a new CRC32 to the CE frame. draft-martini-l2circuit-encap-mpls-03.txt say: For simple Ethernet port to port transport, the entire Ethernet frame -without- the preamble or FCS is transported as a single packet. Would you consider change [VHLS] as later, just because many vendors su= rport it now. =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1Du Wenhua duwh@huawei.com =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 =A1=A1=A1=A1= =A1=A1=A1=A1=A1=A12002-10-11 --Boundary_(ID_7tzENZm6HUGPsSy3EeOIMg) Content-type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable --Boundary_(ID_7tzENZm6HUGPsSy3EeOIMg)-- From ppvpn-owner@ppvpn.francetelecom.com Fri Oct 11 08:39:25 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19121 for ; Fri, 11 Oct 2002 08:39:25 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id EE29C3EC18; Fri, 11 Oct 2002 14:52:36 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id A14A03EC11 for ; Fri, 11 Oct 2002 14:52:30 +0200 (CEST) Received: from zctfs063.nortelnetworks.com (47.164.128.120) by hermes1.fth.net; 11 Oct 2002 14:40:54 +0200 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9BCeqZ10843 for ; Fri, 11 Oct 2002 14:40:52 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Oct 2002 14:40:51 +0200 Message-ID: From: "Marco Carugi" To: "'ppvpn@ppvpn.francetelecom.com'" Cc: "Marco Carugi" , "John Pugh" Subject: Monday Oct 14th - 12H East Coast time : migration of the PPVPN WG mailing list, archive and home page Date: Fri, 11 Oct 2002 14:40:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27123.6F147180" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 955 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27123.6F147180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All,=20 this message to inform you that the PPVPN WG mailing list and archive will be moved to another location next Monday October 14th at 12H East Coast time.The informal PPVPN home page will be moved too. Please save this message for any new correspondance to the list after next Monday 12H. Current and new Webmasters worked together in order that the migration be as much transparent as possible for subscribers. Current subscribers will be moved automatically to the new list so you don't need to re-subscribe. I'll send this message a number of times to the list before the effective change. Thanks for your understanding, Marco=20 P.S. John Pugh (johnpugh@nortelnetworks.com), the new Webmaster, is available for support in case somebody will experience problems with the new list and site.=20 **************************************************************************** ******************************************************************** New mailing list : ppvpn@lyris.nortelnetworks.com To join the mailing list: send an e-mail to join-ppvpn@lyris.nortelnetworks.com No text is necessary in the body or the subject field.=20 To leave the mailing list: send an e-mail to leave-ppvpn@lyris.nortelnetworks.com No text is necessary in the body or the subject field.=20 New informal PPVPN WG home page : http://standards.nortelnetworks.com/ppvpn/index.htm List archive (messages to the new list): access via the "Mailing List" page of the Web site , at the "List archive" section. Please visit the Web site for additional information (meetings, old archive etc.). New Webmaster : John Pugh (johnpugh@nortelnetworks.com) **************************************************************************** **************** Marco CARUGI marco.carugi@nortelnetworks.com tel +33 1 6955 7027 fax +33 1 6955 3058=20 Nortel Networks S.A. Parc d'activit=E9s de Magny-Les Jeunes Bois CHATEAUFORT 78928 YVELINES Cedex 9 - FRANCE=20=20 ------_=_NextPart_001_01C27123.6F147180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Monday Oct 14th - 12H East Coast time : migration of the PPVPN WG ma= iling list, archive and home page

All,

this message to inform you that the PPVPN = WG mailing list and archive will be moved to another location next Monday O= ctober 14th at 12H East Coast time.The informal PPVPN home page will be mov= ed too.

Please save this message for any new corre= spondance to the list after next Monday 12H.

Current and new Webmasters worked together= in order that the migration be as much transparent as possible for subscri= bers. Current subscribers will be moved automatically to the new list so yo= u don't need to re-subscribe.

I'll send this message a number of times t= o the list before the effective change.

Thanks for your understanding, Marco

P.S. John Pugh (johnpugh@nortelnetworks.co= m), the new Webmaster, is available for support in case somebody will exper= ience problems with the new list and site.

******************************************= ***************************************************************************= ***************************

New mailing list : ppvpn@lyris.nortelnetworks.com
To join the mailing list: <= FONT SIZE=3D2 FACE=3D"Arial">send an e-mail to join-ppvpn@lyris.nortelnetwo= rks.com           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   No text is necessary in the body or the subject field.

To leave the mailing list: <= FONT SIZE=3D2 FACE=3D"Arial">send an e-mail to leave-ppvpn@lyris.nortelnetw= orks.com           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            No tex= t is necessary in the body or the subject field.

New informal PPVPN WG home page : http://standards.nortelnetworks.= com/ppvpn/index.htm
List archive (messages to the new list= ): access via the "Mailing Li= st" page of the Web site ,  at the "List archive" secti= on.

Please visit the Web site for additional i= nformation (meetings, old archive etc.).
New Webmaster : John Pugh (johnpugh@no= rtelnetworks.com)
********************************************= ************************************************

Marco CARUGI
marco.carugi@nortelnetworks.com
tel +33 1 6955 7027
fax +33 1 6955 3058
Nortel Networks S.A.
Parc d'activit=E9s de Magny-Les Jeunes Bo= is  CHATEAUFORT
78928 YVELINES Cedex 9  - FRANCE&nbs= p;

------_=_NextPart_001_01C27123.6F147180-- From ppvpn-owner@ppvpn.francetelecom.com Fri Oct 11 10:41:30 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23783 for ; Fri, 11 Oct 2002 10:41:30 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id F3BB63EC18; Fri, 11 Oct 2002 16:54:37 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id BA7423EC11 for ; Fri, 11 Oct 2002 16:54:33 +0200 (CEST) Received: from tenornetworks.com (63.77.213.2) by hermes1.fth.net; 11 Oct 2002 16:42:57 +0200 Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9BEgb818423; Fri, 11 Oct 2002 10:42:37 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; FRI, 11 Oct 2002 10:39:15 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Oct 2002 10:39:15 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E5601BCE9E7@newman.tenornet.com> From: "Sodder, Arnold" To: duwh@huawei.com Cc: ppvpn@ppvpn.francetelecom.com Subject: Re: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Fri, 11 Oct 2002 10:39:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 956 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA23783 This requirement comes from an operations standpoint. Consider the case where a CE device is creating incorrect data in the frame body and creating a CRC based on the incorrect data. When the frame is received by the L2PE device the CRC will be checked and found to be good, even though the data in the frame is bad. When the total frame (including the CRC) is delivered by the service providers network there is a trace left as to where the error was created. In the case where the CRC is stripped, detecting the error becomes difficult. Thus when the original customers frame is not modified this error can be detected. In the case where the customers frame is modified the error cannot be detected. In general there should be no need for the L2PE device to modify the frame. For this reason I have choosen to carry the complete frame (including CRC) over the service providers network. Having an option is possible but being an implementor I'd like to keep the PE and L2PE devices as simple as possible and so choose to not support one. Hopefully this addresses your question. Arnold --------------------------- Hi,Sodder, Arnold, [VHLS] say: In the above frame formats the CE frame MUST -include- the original CRC32 to allow detection of bit errors introduced by devices in the service provider network or attached to the service provider network. If the L2PE device needs to modify the CE frame it MUST calculate and add a new CRC32 to the CE frame. draft-martini-l2circuit-encap-mpls-03.txt say: For simple Ethernet port to port transport, the entire Ethernet frame -without- the preamble or FCS is transported as a single packet. Would you consider change [VHLS] as later, just because many vendors surport it now. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ Du Wenhua duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ ¡¡¡¡¡¡¡¡¡¡2002-10-11 From ppvpn-owner@ppvpn.francetelecom.com Fri Oct 11 10:48:16 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24113 for ; Fri, 11 Oct 2002 10:48:16 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id A41C93EC1B; Fri, 11 Oct 2002 17:01:29 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id AE6603EC12 for ; Fri, 11 Oct 2002 17:01:23 +0200 (CEST) Received: from boreas.isi.edu (128.9.160.161) by hermes1.fth.net; 11 Oct 2002 16:49:47 +0200 Received: from isi.edu (ras31.isi.edu [128.9.176.131]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9BEneC07897; Fri, 11 Oct 2002 07:49:40 -0700 (PDT) Message-ID: <3DA6E4FE.1010307@isi.edu> Date: Fri, 11 Oct 2002 07:49:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Carugi Cc: "'ppvpn@ppvpn.francetelecom.com'" , John Pugh Subject: Re: Monday Oct 14th - 12H East Coast time : migration of the PPVPN WG mailing list, archive and home page References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 957 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 7bit Marco Carugi wrote: > All, > > this message to inform you that the PPVPN WG mailing list and archive > will be moved to another location next Monday October 14th at 12H East > Coast time.The informal PPVPN home page will be moved too. This is the second time this list is being moved in the past year. Is there any chance it could instead be moved to a place less suceptible to commercial and personal flux? E.g., the IETF site itself? Joe From ppvpn-owner@ppvpn.francetelecom.com Mon Oct 14 10:45:06 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22307 for ; Mon, 14 Oct 2002 10:45:06 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 0FACF3EC16; Mon, 14 Oct 2002 16:58:18 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id A4B543EC11 for ; Mon, 14 Oct 2002 16:58:14 +0200 (CEST) Received: from howler.tri.sbc.com (205.173.58.4) by hermes1.fth.net; 14 Oct 2002 16:46:40 +0200 Received: from sbctri.tri.sbc.com (mayhem-web-dmz.tri.sbc.com [144.60.9.137]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id g9EEpF8W006846; Mon, 14 Oct 2002 09:51:15 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g9EEiwW14099; Mon, 14 Oct 2002 09:44:58 -0500 (CDT) Received: by trimail2 with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 09:46:34 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D63226BE@trimail2> From: "Chen, Weijing" To: "'ipng@sunroof.eng.sun.com'" , ppvpn@ppvpn.francetelecom.com Subject: FW: I-D ACTION:draft-allen-lap-ipv6-00.txt Date: Mon, 14 Oct 2002 09:46:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C27390.7B87D6E0" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 958 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C27390.7B87D6E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, We would like to bring the attention to this ID announcement. This draft saw the same "connection-oriented" problem laid out by http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-cl-tunneling-vpn-00.txt . However, the proposal lay out by http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt dealt more than PPVPN. It dealt with broadband Internet access too. We would like to seek the interest of ipng group, ppvpn group, and other interesting party to advance this work. Thanks. -- Weijing Chen -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, October 14, 2002 6:25 AM Cc: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-allen-lap-ipv6-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 for Large Access Providers Author(s) : K. Allen, W. Chen Filename : draft-allen-lap-ipv6-00.txt Pages : 12 Date : 2002-10-11 =09 This document discusses how Large Access Providers (LAP) could use=20 IPv6 to solve current technical challenges. In particular, IPv6=C6s=20 large address space and optional header mechanism can be used to=20 provide scalable and manageable broadband Internet access and=20 Virtual Private Network (VPN) services. A new optional header to=20 support forwarding-plane based VPNs is proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-allen-lap-ipv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-allen-lap-ipv6-00.txt". =09 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. =09=09 =09=09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C27390.7B87D6E0 Content-Type: message/rfc822 To: Subject: Date: Mon, 14 Oct 2002 09:46:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C27390.7B87D6E0" ------_=_NextPart_002_01C27390.7B87D6E0 Content-Type: text/plain ------_=_NextPart_002_01C27390.7B87D6E0 Content-Type: application/octet-stream; name="ATT99779.txt" Content-Disposition: attachment; filename="ATT99779.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-11133732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allen-lap-ipv6-00.txt ------_=_NextPart_002_01C27390.7B87D6E0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-allen-lap-ipv6-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C27390.7B87D6E0-- ------_=_NextPart_000_01C27390.7B87D6E0-- From ppvpn-owner@ppvpn.francetelecom.com Mon Oct 14 11:11:27 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23314 for ; Mon, 14 Oct 2002 11:11:26 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id AA6243EC17; Mon, 14 Oct 2002 17:24:39 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id E6F9D3EC12 for ; Mon, 14 Oct 2002 17:24:30 +0200 (CEST) Received: from zctfs063.nortelnetworks.com (47.164.128.120) by hermes1.fth.net; 14 Oct 2002 17:12:56 +0200 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9EFCsg23911 for ; Mon, 14 Oct 2002 17:12:54 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 17:12:52 +0200 Message-ID: From: "Marco Carugi" To: "'ppvpn@ppvpn.francetelecom.com'" Cc: "John Pugh" , "Marco Carugi" Subject: RE: Monday Oct 14th - 12H East Coast time : migration of the PPVP N WG mailing list, archive and home page Date: Mon, 14 Oct 2002 17:12:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27394.29B3F00C" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 959 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27394.29B3F00C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Carugi, Marco [CTF:0000:EXCH]=20=20 > Sent: vendredi 11 octobre 2002 14:41 > To: 'ppvpn@ppvpn.francetelecom.com' > Cc: Carugi, Marco [CTF:0000:EXCH]; Pugh, John [NC1:6L24:EXCH] > Subject: Monday Oct 14th - 12H East Coast time : migration of the > PPVPN WG mailing list, archive and home page=20 >=20 > All,=20 >=20 > this message to inform you that the PPVPN WG mailing list and archive will > be moved to another location next Monday October 14th at 12H East Coast > time.The informal PPVPN home page will be moved too. > Please save this message for any new correspondance to the list after next > Monday 12H. >=20 > Current and new Webmasters worked together in order that the migration be > as much transparent as possible for subscribers. Current subscribers will > be moved automatically to the new list so you don't need to re-subscribe. >=20 > I'll send this message a number of times to the list before the effective > change. >=20 > Thanks for your understanding, Marco=20 >=20 > P.S. John Pugh (johnpugh@nortelnetworks.com), the new Webmaster, is > available for support in case somebody will experience problems with the > new list and site.=20 >=20 > ************************************************************************** > ********************************************************************** > New mailing list : ppvpn@lyris.nortelnetworks.com > To join the mailing list: send an e-mail to > join-ppvpn@lyris.nortelnetworks.com > No text is necessary in the body or the subject field.=20 > To leave the mailing list: send an e-mail to > leave-ppvpn@lyris.nortelnetworks.com > No text is necessary in the body or the subject field.=20 > New informal PPVPN WG home page : > http://standards.nortelnetworks.com/ppvpn/index.htm > List archive (messages to the new list): access via the "Mailing List" > page of the Web site , at the "List archive" section. > Please visit the Web site for additional information (meetings, old > archive etc.). > New Webmaster : John Pugh (johnpugh@nortelnetworks.com) > ************************************************************************** > ****************** >=20 > Marco CARUGI > marco.carugi@nortelnetworks.com > tel +33 1 6955 7027 > fax +33 1 6955 3058=20 > Nortel Networks S.A. > Parc d'activit=E9s de Magny-Les Jeunes Bois CHATEAUFORT > 78928 YVELINES Cedex 9 - FRANCE=20=20 >=20 ------_=_NextPart_001_01C27394.29B3F00C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Monday Oct 14th - 12H East Coast time : migration of the PPVPN W= G mailing list, archive and home page

     -----Or= iginal Message-----
    From:   Carugi, Marco [CTF:0000:EXCH] 
    Sent:   vendredi 11 octobre 2002 14:41
    To:     'ppvpn@ppvpn.francetelecom.com'
    Cc:     Carugi, Marco [CTF:0000:EXCH]; Pugh, John = [NC1:6L24:EXCH]
    Subject:     = ;   Monday Oct 14th - 1= 2H East Coast time : migration of the PPVPN WG mailing list, archive and ho= me page

    All,

    this message to inform you that the PPVPN = WG mailing list and archive will be moved to another location next Monday O= ctober 14th at 12H East Coast time.The informal PPVPN home page will be mov= ed too.

    Please save this message for any new corre= spondance to the list after next Monday 12H.

    Current and new Webmasters worked together= in order that the migration be as much transparent as possible for subscri= bers. Current subscribers will be moved automatically to the new list so yo= u don't need to re-subscribe.

    I'll send this message a number of times t= o the list before the effective change.

    Thanks for your understanding, Marco

    P.S. John Pugh (johnpugh@nortelnetworks.co= m), the new Webmaster, is available for support in case somebody will exper= ience problems with the new list and site.

    ******************************************= ***************************************************************************= ***************************

    New mailing list : ppvpn@lyris.nortelnetworks.com
    To join the mailing list: <= FONT SIZE=3D2 FACE=3D"Arial">send an e-mail to join-ppvpn@lyris.nortelnetwo= rks.com           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   No text is necessary in the body or the subject field.

    To leave the mailing list: <= FONT SIZE=3D2 FACE=3D"Arial">send an e-mail to leave-ppvpn@lyris.nortelnetw= orks.com           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            No tex= t is necessary in the body or the subject field.

    New informal PPVPN WG home page : http://standards.nortelnetworks.= com/ppvpn/index.htm
    List archive (messages to the new list= ): access via the "Mailing Li= st" page of the Web site ,  at the "List archive" secti= on.

    Please visit the Web site for additional i= nformation (meetings, old archive etc.).
    New Webmaster : John Pugh (johnpugh@no= rtelnetworks.com)
    ********************************************= ************************************************

Marco CARUGI
marco.carugi@nortelnetworks.com
tel +33 1 6955 7027
fax +33 1 6955 3058
Nortel Networks S.A.
Parc d'activit=E9s de Magny-Les Jeunes Bo= is  CHATEAUFORT
78928 YVELINES Cedex 9  - FRANCE&nbs= p;

------_=_NextPart_001_01C27394.29B3F00C-- From ppvpn-owner@ppvpn.francetelecom.com Mon Oct 14 12:40:10 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25394 for ; Mon, 14 Oct 2002 12:40:08 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id A02D13EC19; Mon, 14 Oct 2002 18:53:21 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 2D7163EC12 for ; Mon, 14 Oct 2002 18:53:13 +0200 (CEST) Received: from zctfs063.nortelnetworks.com (47.164.128.120) by hermes1.fth.net; 14 Oct 2002 18:41:38 +0200 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9EGfbg04130 for ; Mon, 14 Oct 2002 18:41:37 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 18:41:36 +0200 Message-ID: From: "Marco Carugi" To: "'ppvpn@lyris.nortelnetworks.com'" , "'ppvpn@ppvpn.francetelecom.com'" Cc: "John Pugh" , "Marco Carugi" Subject: TEST for migration of the PPVPN WG mailing list Date: Mon, 14 Oct 2002 18:41:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C273A0.8B0C4E1A" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 960 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C273A0.8B0C4E1A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry for this. Test for the new PPVPN WG mailing list.=20 You should receive this message twice (old list, new list). In case rerouting from old to new list is running as requested,=20 you should receive a third copy. Marco > -----Original Message----- > From: Carugi, Marco [CTF:0000:EXCH]=20=20 > Sent: lundi 14 octobre 2002 17:13 > To: 'ppvpn@ppvpn.francetelecom.com' > Cc: Pugh, John [NC1:6L24:EXCH]; Carugi, Marco [CTF:0000:EXCH] > Subject: RE: Monday Oct 14th - 12H East Coast time : migration of the > PPVPN WG mailing list, archive and home page=20 >=20 > -----Original Message----- > From: Carugi, Marco [CTF:0000:EXCH]=20=20 > Sent: vendredi 11 octobre 2002 14:41 > To: 'ppvpn@ppvpn.francetelecom.com' > Cc: Carugi, Marco [CTF:0000:EXCH]; Pugh, John [NC1:6L24:EXCH] > Subject: Monday Oct 14th - 12H East Coast time : migration of > the PPVPN WG mailing list, archive and home page=20 >=20 > All,=20 >=20 > this message to inform you that the PPVPN WG mailing list and > archive will be moved to another location next Monday October 14th at 12H > East Coast time.The informal PPVPN home page will be moved too. > Please save this message for any new correspondance to the list > after next Monday 12H. >=20 > Current and new Webmasters worked together in order that the > migration be as much transparent as possible for subscribers. Current > subscribers will be moved automatically to the new list so you don't need > to re-subscribe. >=20 > I'll send this message a number of times to the list before the > effective change. >=20 > Thanks for your understanding, Marco=20 >=20 > P.S. John Pugh (johnpugh@nortelnetworks.com), the new Webmaster, is > available for support in case somebody will experience problems with the > new list and site.=20 >=20 >=20=09 > ************************************************************************** > ********************************************************************** > New mailing list : ppvpn@lyris.nortelnetworks.com > To join the mailing list: send an e-mail to > join-ppvpn@lyris.nortelnetworks.com > No text is necessary in the body or the subject field.=20 > To leave the mailing list: send an e-mail to > leave-ppvpn@lyris.nortelnetworks.com > No text is necessary in the body or the subject field.=20 > New informal PPVPN WG home page : > http://standards.nortelnetworks.com/ppvpn/index.htm > List archive (messages to the new list): access via the "Mailing > List" page of the Web site , at the "List archive" section. > Please visit the Web site for additional information (meetings, old > archive etc.). > New Webmaster : John Pugh (johnpugh@nortelnetworks.com) >=20=09 > ************************************************************************** > ****************** >=20 > Marco CARUGI > marco.carugi@nortelnetworks.com > tel +33 1 6955 7027 > fax +33 1 6955 3058=20 > Nortel Networks S.A. > Parc d'activit=E9s de Magny-Les Jeunes Bois CHATEAUFORT > 78928 YVELINES Cedex 9 - FRANCE=20=20 >=20 ------_=_NextPart_001_01C273A0.8B0C4E1A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TEST for migration of the PPVPN WG mailing list

    Sorry for this.
    Test for the new PPVPN = WG mailing list.
    You should receive this= message twice (old list, new list). In case rerouting from old to new list= is running as requested,

    you should receive a thi= rd copy.
    Marco

     -----Or= iginal Message-----
    From:   Carugi, Marco [CTF:0000:EXCH] 
    Sent:   lundi 14 octobre 2002 17:13
    To:     'ppvpn@ppvpn.francetelecom.com'
    Cc:     Pugh, John [NC1:6L24:EXCH]; Carugi, Marco = [CTF:0000:EXCH]
    Subject:     = ;   RE: Monday Oct 14th= - 12H East Coast time : migration of the PPVPN WG mailing list, archive an= d home page

       -----Or= iginal Message-----
      From:   Carugi, Marco [CTF:0000:EXCH] 
      Sent:   vendredi 11 octobre 2002 14:41
      To:     'ppvpn@ppvpn.francetelecom.com'
      Cc:     Carugi, Marco [CTF:0000:EXCH]; Pugh, John = [NC1:6L24:EXCH]
      Subject:     = ;   Monday Oct 14th - 1= 2H East Coast time : migration of the PPVPN WG mailing list, archive and ho= me page

      All,

      this message to inform you that the PPVPN = WG mailing list and archive will be moved to another location next Monday O= ctober 14th at 12H East Coast time.The informal PPVPN home page will be mov= ed too.

      Please save this message for any new corre= spondance to the list after next Monday 12H.

      Current and new Webmasters worked together= in order that the migration be as much transparent as possible for subscri= bers. Current subscribers will be moved automatically to the new list so yo= u don't need to re-subscribe.

      I'll send this message a number of times t= o the list before the effective change.

      Thanks for your understanding, Marco

      P.S. John Pugh (johnpugh@nortelnetworks.co= m), the new Webmaster, is available for support in case somebody will exper= ience problems with the new list and site.

      ******************************************= ***************************************************************************= ***************************

      New mailing list : ppvpn@lyris.nortelnetworks.com
      To join the mailing list: <= FONT SIZE=3D2 FACE=3D"Arial">send an e-mail to join-ppvpn@lyris.nortelnetwo= rks.com           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   No text is necessary in the body or the subject field.

      To leave the mailing list: <= FONT SIZE=3D2 FACE=3D"Arial">send an e-mail to leave-ppvpn@lyris.nortelnetw= orks.com           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            No tex= t is necessary in the body or the subject field.

      New informal PPVPN WG home page : http://standards.nortelnetworks.= com/ppvpn/index.htm
      List archive (messages to the new list= ): access via the "Mailing Li= st" page of the Web site ,  at the "List archive" secti= on.

      Please visit the Web site for additional i= nformation (meetings, old archive etc.).
      New Webmaster : John Pugh (johnpugh@no= rtelnetworks.com)
      ********************************************= ************************************************

Marco CARUGI
marco.carugi@nortelnetworks.com
tel +33 1 6955 7027
fax +33 1 6955 3058
Nortel Networks S.A.
Parc d'activit=E9s de Magny-Les Jeunes Bo= is  CHATEAUFORT
78928 YVELINES Cedex 9  - FRANCE&nbs= p;

------_=_NextPart_001_01C273A0.8B0C4E1A-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Oct 14 12:40:43 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25445 for ; Mon, 14 Oct 2002 12:40:43 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9EGg6O23770 for ; Mon, 14 Oct 2002 12:42:07 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9EGg4q01685 for ; Mon, 14 Oct 2002 12:42:04 -0400 (EDT) Message-ID: From: "Marco Carugi" To: "PPVPN mail list" Cc: "John Pugh" , "Marco Carugi" Subject: TEST for migration of the PPVPN WG mailing list Date: Mon, 14 Oct 2002 18:41:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C273A0.8B0C4E1A" List-Unsubscribe: Reply-To: "PPVPN mail list" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C273A0.8B0C4E1A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry for this. Test for the new PPVPN WG mailing list.=20 You should receive this message twice (old list, new list). In case rerouting from old to new list is running as requested,=20 you should receive a third copy. Marco > -----Original Message----- > From: Carugi, Marco [CTF:0000:EXCH] =20 > Sent: lundi 14 octobre 2002 17:13 > To: 'ppvpn@ppvpn.francetelecom.com' > Cc: Pugh, John [NC1:6L24:EXCH]; Carugi, Marco [CTF:0000:EXCH] > Subject: RE: Monday Oct 14th - 12H East Coast time : migration of the > PPVPN WG mailing list, archive and home page=20 >=20 > -----Original Message----- > From: Carugi, Marco [CTF:0000:EXCH] =20 > Sent: vendredi 11 octobre 2002 14:41 > To: 'ppvpn@ppvpn.francetelecom.com' > Cc: Carugi, Marco [CTF:0000:EXCH]; Pugh, John [NC1:6L24:EXCH] > Subject: Monday Oct 14th - 12H East Coast time : migration of > the PPVPN WG mailing list, archive and home page=20 >=20 > All,=20 >=20 > this message to inform you that the PPVPN WG mailing list and > archive will be moved to another location next Monday October 14th at = 12H > East Coast time.The informal PPVPN home page will be moved too. > Please save this message for any new correspondance to the list > after next Monday 12H. >=20 > Current and new Webmasters worked together in order that the > migration be as much transparent as possible for subscribers. Current > subscribers will be moved automatically to the new list so you don't = need > to re-subscribe. >=20 > I'll send this message a number of times to the list before the > effective change. >=20 > Thanks for your understanding, Marco=20 >=20 > P.S. John Pugh (johnpugh@nortelnetworks.com), the new Webmaster, is > available for support in case somebody will experience problems with = the > new list and site.=20 >=20 > =09 > = ************************************************************************= ** > = ********************************************************************** > New mailing list : ppvpn@lyris.nortelnetworks.com > To join the mailing list: send an e-mail to > join-ppvpn@lyris.nortelnetworks.com > No text is necessary in the body or the subject field.=20 > To leave the mailing list: send an e-mail to > leave-ppvpn@lyris.nortelnetworks.com > No text is necessary in the body or the subject field.=20 > New informal PPVPN WG home page : > http://standards.nortelnetworks.com/ppvpn/index.htm > List archive (messages to the new list): access via the "Mailing > List" page of the Web site , at the "List archive" section. > Please visit the Web site for additional information (meetings, old > archive etc.). > New Webmaster : John Pugh (johnpugh@nortelnetworks.com) > =09 > = ************************************************************************= ** > ****************** >=20 > Marco CARUGI > marco.carugi@nortelnetworks.com > tel +33 1 6955 7027 > fax +33 1 6955 3058=20 > Nortel Networks S.A. > Parc d'activit=E9s de Magny-Les Jeunes Bois CHATEAUFORT > 78928 YVELINES Cedex 9 - FRANCE =20 >=20 --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com ------_=_NextPart_001_01C273A0.8B0C4E1A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TEST for migration of the PPVPN WG mailing list

    Sorry for = this.
    Test for the new = PPVPN WG mailing list.
    You should receive = this message twice (old list, new list). In case rerouting from old to = new list is running as requested,

    you should receive a = third copy.
    Marco

     -----Original Message-----
    From:   Carugi, Marco [CTF:0000:EXCH] 
    Sent:   = lundi 14 octobre 2002 17:13
    To:     'ppvpn@ppvpn.francetelecom.com'
    Cc:     Pugh, John [NC1:6L24:EXCH]; Carugi, Marco = [CTF:0000:EXCH]
    Subject:        RE: Monday Oct 14th - 12H East = Coast time : migration of the PPVPN WG mailing list, archive and home = page

       -----Original Message-----
      From:   Carugi, Marco [CTF:0000:EXCH] 
      Sent:   = vendredi 11 octobre 2002 14:41
      To:     'ppvpn@ppvpn.francetelecom.com'
      Cc:     Carugi, Marco [CTF:0000:EXCH]; Pugh, John = [NC1:6L24:EXCH]
      Subject:        Monday Oct 14th - 12H East Coast = time : migration of the PPVPN WG mailing list, archive and home page =

      All,

      this message to inform you that the = PPVPN WG mailing list and archive will be moved to another location = next Monday October 14th at 12H East Coast time.The informal PPVPN home = page will be moved too.

      Please save this message for any new = correspondance to the list after next Monday 12H.

      Current and new Webmasters worked = together in order that the migration be as much transparent as possible = for subscribers. Current subscribers will be moved automatically to the = new list so you don't need to re-subscribe.

      I'll send this message a number of = times to the list before the effective change.

      Thanks for your understanding, Marco =

      P.S. John Pugh = (johnpugh@nortelnetworks.com), the new Webmaster, is available for = support in case somebody will experience problems with the new list and = site.

      *********************************************************= ************************************************************************= ***************

      New mailing list : ppvpn@lyris.nortelnetworks.com
      To join the mailing = list: send an e-mail to = join-ppvpn@lyris.nortelnetworks.com      &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;          No text is = necessary in the body or the subject field.

      To leave the mailing = list: send an e-mail to = leave-ppvpn@lyris.nortelnetworks.com      =             =             =             =             =        No text is necessary in the body = or the subject field.

      New informal PPVPN WG home page = : http://standards.nortelnetworks.com/ppvpn/index.htm
      List archive (messages to the new = list): access via the = "Mailing List" page of the Web site ,  at the "List = archive" section.

      Please visit the Web site for = additional information (meetings, old archive etc.).
      New Webmaster : John Pugh = (johnpugh@nortelnetworks.com)
      *****************************************************************= ***************************

Marco CARUGI
marco.carugi@nortelnetworks.com
tel +33 1 6955 7027
fax +33 1 6955 3058
Nortel Networks S.A.
Parc d'activit=E9s de Magny-Les = Jeunes Bois  CHATEAUFORT
78928 YVELINES Cedex 9  - = FRANCE 

---
You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org
To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com ------_=_NextPart_001_01C273A0.8B0C4E1A-- From ppvpn-owner@ppvpn.francetelecom.com Mon Oct 14 19:55:26 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05910 for ; Mon, 14 Oct 2002 19:55:26 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 352DF3EC1C; Tue, 15 Oct 2002 02:08:39 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id E06563EC14 for ; Tue, 15 Oct 2002 02:08:32 +0200 (CEST) Received: from morpheus.lanterncom.com (64.161.157.68) by hermes1.fth.net; 15 Oct 2002 01:56:58 +0200 Received: by morpheus.lanterncom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 16:55:15 -0700 Message-ID: <58BE468BAC66D511AFE6000347251A2D01A16415@morpheus.lanterncom.com> From: Anoop Ghanwani To: "'ppvpn@ppvpn.francetelecom.com'" Subject: FW: Spanning tree PDUs and VPLS Date: Mon, 14 Oct 2002 16:55:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 961 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Is there a BCP for what a router should do when it receives a spanning tree PDU? Does it treat it like a multicast frame and forward it to all ports on the VPLS? Or does it just filter these frames? If the group hasn't discussed this issue, I'd be interested in hearing how vendors currently handle spanning tree PDUs. -Anoop -- Anoop Ghanwani - Lantern Communications - 408-521-6707 From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 15 09:39:05 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01242 for ; Tue, 15 Oct 2002 09:39:04 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id C486F3EC19; Tue, 15 Oct 2002 15:50:59 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id E48D33EC11 for ; Tue, 15 Oct 2002 15:50:53 +0200 (CEST) Received: from exchange.appiancom.com (65.202.180.166) by hermes1.fth.net; 15 Oct 2002 15:39:20 +0200 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Oct 2002 09:39:18 -0400 Message-ID: <4D043E1F07D3D5118E9900B0D083F9F6270044@EXCHANGE> From: Ashwin Moranganti To: "'Anoop Ghanwani'" , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Spanning tree PDUs and VPLS Date: Tue, 15 Oct 2002 09:39:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 962 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Anoop, VPLS will allow CEs to run STP. The STP frames will be tunneled, and will forwarded to all ports on the VPLS Ashwin -----Original Message----- From: Anoop Ghanwani [mailto:anoop@lanterncom.com] Sent: Monday, October 14, 2002 7:55 PM To: 'ppvpn@ppvpn.francetelecom.com' Subject: FW: Spanning tree PDUs and VPLS Is there a BCP for what a router should do when it receives a spanning tree PDU? Does it treat it like a multicast frame and forward it to all ports on the VPLS? Or does it just filter these frames? If the group hasn't discussed this issue, I'd be interested in hearing how vendors currently handle spanning tree PDUs. -Anoop -- Anoop Ghanwani - Lantern Communications - 408-521-6707 From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 15 09:51:51 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01790 for ; Tue, 15 Oct 2002 09:51:51 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9FDrFo17022 for ; Tue, 15 Oct 2002 09:53:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9FDrD123688 for ; Tue, 15 Oct 2002 09:53:13 -0400 (EDT) Message-ID: From: neil.2.harrison@bt.com To: "PPVPN mail list" Subject: Test message...please ignore and delete Date: Tue, 15 Oct 2002 14:52:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt08.hc.bt.com X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] List-Unsubscribe: Reply-To: "PPVPN mail list" Test message...please ignore and delete --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 15 12:31:17 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06761 for ; Tue, 15 Oct 2002 12:31:17 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9FGWbo02084 for ; Tue, 15 Oct 2002 12:32:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9FGWY126182 for ; Tue, 15 Oct 2002 12:32:35 -0400 (EDT) Message-ID: From: "John Pugh" To: "PPVPN mail list" Subject: New PPVPN web page and mail list Date: Tue, 15 Oct 2002 12:32:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27468.6403D9F0" List-Unsubscribe: Reply-To: "PPVPN mail list" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27468.6403D9F0 Content-Type: text/plain To the PPVPN mail exploder list: This is by way of introduction and will serve to verify that the list is operating correctly. If you have any suggestions regarding the web site (http://standards.nortelnetworks.com/ppvpn/index.htm )or the mail list ( ppvpn@lyris.nortelnetworks.com )please don't hesitate to send them to me. We will try to make improvements as quickly as possible. We will also try to respond to questions/concerns within 24 hours. We are looking at ways to present the PPVPN agendas and presentations so that duplication of information is minimized while still adding value for the PPVPN members so you may see some changes shortly in this area of the site. To avoid seeing the html tags in archived messages set your format to 'text only' in your email client before sending messages to the PPVPN list. There are 1065 members currently subscribed to the mail distribution list at ppvpn@lyris.nortelnetworks.com and if you receive this message you are one of them. Messages are archived as they are received and a link to the message archive ( http://zrchb175.us.nortel.com:8080/cgi-bin/lyris.pl?visit=ppvpn&id=192589112 ) is presented on the above web site. There are a number of viewing options using the web interface. Also, please note that the 'help' section of the PPVPN email page (Lyris server commands) contains many references including a page describing email commands that can be used. Regards, John Pugh Nortel Networks (USA - 919-997-3626) (http://standards.nortelnetworks.com/ppvpn/index.htm ) --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com ------_=_NextPart_001_01C27468.6403D9F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable New PPVPN web page and mail list

To the PPVPN mail exploder list:

This is by way of introduction and will serve to = verify that the list is operating correctly. If you have any = suggestions regarding the web site (http://standards.nortelnetworks.com/ppvpn/index.htm )or the mail list ( ppvpn@lyris.nortelnetworks.com )please don't = hesitate to send them to me. We will try to make improvements as = quickly as possible. We will also try to respond to questions/concerns = within 24 hours. We are looking at ways to present the PPVPN agendas = and presentations so that duplication of information is minimized while = still adding value for the PPVPN members so you may see some changes = shortly in this area of the site.

To avoid seeing the html tags in archived messages = set your format to 'text only' in your email client before sending = messages to the PPVPN list. There are 1065 members currently subscribed = to the mail distribution list at ppvpn@lyris.nortelnetworks.com and if = you receive this message you are one of them. Messages are archived as = they are received and a link to the message archive ( http://zrchb175.us.nortel.com:8080/cgi-bin/lyris.pl?vi= sit=3Dppvpn&id=3D192589112 ) is presented on the above web site. = There are a number of viewing options using the web = interface.

Also, please note that the 'help' section of the = PPVPN email page (Lyris server commands) contains many references = including a page describing email commands that can be used.

Regards,
John Pugh
Nortel Networks
(USA - 919-997-3626)
(http://standards.nortelnetworks.com/ppvpn/index.htm )

---
You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org
To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com ------_=_NextPart_001_01C27468.6403D9F0-- From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 15 13:24:16 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08245 for ; Tue, 15 Oct 2002 13:24:15 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 5AE823EC1C; Tue, 15 Oct 2002 19:37:23 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id DAFD93EC14 for ; Tue, 15 Oct 2002 19:37:18 +0200 (CEST) Received: from morpheus.lanterncom.com (64.161.157.68) by hermes1.fth.net; 15 Oct 2002 19:25:45 +0200 Received: by morpheus.lanterncom.com with Internet Mail Service (5.5.2653.19) id <496RRDNS>; Tue, 15 Oct 2002 10:24:02 -0700 Message-ID: <58BE468BAC66D511AFE6000347251A2D01A1641C@morpheus.lanterncom.com> From: Anoop Ghanwani To: "'Ashwin Moranganti'" , Anoop Ghanwani , "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Spanning tree PDUs and VPLS Date: Tue, 15 Oct 2002 10:24:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 963 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Ashwin, Thanks for the information. What happens in a point-to-multipoint topology? The leaves don't talk to each other directly so what happens when a spanning tree PDU is received from a leaf node? -Anoop > -----Original Message----- > From: Ashwin Moranganti [mailto:amoranganti@appiancom.com] > Sent: Tuesday, October 15, 2002 6:39 AM > To: 'Anoop Ghanwani'; 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Spanning tree PDUs and VPLS > > > Anoop, > > VPLS will allow CEs to run STP. The STP frames will be > tunneled, and will > forwarded to all ports on the VPLS > > Ashwin > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@lanterncom.com] > Sent: Monday, October 14, 2002 7:55 PM > To: 'ppvpn@ppvpn.francetelecom.com' > Subject: FW: Spanning tree PDUs and VPLS > > > > Is there a BCP for what a router should do when it receives > a spanning tree PDU? Does it treat it like a multicast > frame and forward it to all ports on the VPLS? Or does > it just filter these frames? > > If the group hasn't discussed this issue, I'd be interested > in hearing how vendors currently handle spanning tree PDUs. > > -Anoop > -- > Anoop Ghanwani - Lantern Communications - 408-521-6707 > From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 15 13:55:09 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09640 for ; Tue, 15 Oct 2002 13:55:08 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id AEA3C3EC22; Tue, 15 Oct 2002 20:08:22 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 228883EC17 for ; Tue, 15 Oct 2002 20:08:20 +0200 (CEST) Received: from exchange.appiancom.com (65.202.180.166) by hermes1.fth.net; 15 Oct 2002 19:56:46 +0200 Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Oct 2002 13:56:44 -0400 Message-ID: <4D043E1F07D3D5118E9900B0D083F9F6270046@EXCHANGE> From: Ashwin Moranganti To: "'Anoop Ghanwani'" Cc: "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Spanning tree PDUs and VPLS Date: Tue, 15 Oct 2002 13:56:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 964 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Anoop, I believe, the current IETF VPLS drafts, do not support point-to-multipoint topologies. In MEF, there is a concept of point-to-multipoint Ethernet virtual circuit. In which the broadcast, multicast and unicast packets from the leaf are forwarded only to the root and not to other leaves. But multicast, broadcast packets from the root are forwarded to all the leaves. Ashwin -----Original Message----- From: Anoop Ghanwani [mailto:anoop@lanterncom.com] Sent: Tuesday, October 15, 2002 1:24 PM To: 'Ashwin Moranganti'; Anoop Ghanwani; 'ppvpn@ppvpn.francetelecom.com' Subject: RE: Spanning tree PDUs and VPLS Ashwin, Thanks for the information. What happens in a point-to-multipoint topology? The leaves don't talk to each other directly so what happens when a spanning tree PDU is received from a leaf node? -Anoop > -----Original Message----- > From: Ashwin Moranganti [mailto:amoranganti@appiancom.com] > Sent: Tuesday, October 15, 2002 6:39 AM > To: 'Anoop Ghanwani'; 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Spanning tree PDUs and VPLS > > > Anoop, > > VPLS will allow CEs to run STP. The STP frames will be > tunneled, and will > forwarded to all ports on the VPLS > > Ashwin > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@lanterncom.com] > Sent: Monday, October 14, 2002 7:55 PM > To: 'ppvpn@ppvpn.francetelecom.com' > Subject: FW: Spanning tree PDUs and VPLS > > > > Is there a BCP for what a router should do when it receives > a spanning tree PDU? Does it treat it like a multicast > frame and forward it to all ports on the VPLS? Or does > it just filter these frames? > > If the group hasn't discussed this issue, I'd be interested > in hearing how vendors currently handle spanning tree PDUs. > > -Anoop > -- > Anoop Ghanwani - Lantern Communications - 408-521-6707 > From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 15 14:02:46 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09965 for ; Tue, 15 Oct 2002 14:02:45 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 393C23EC24; Tue, 15 Oct 2002 20:15:59 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 1AA813EC19 for ; Tue, 15 Oct 2002 20:15:54 +0200 (CEST) Received: from morpheus.lanterncom.com (64.161.157.68) by hermes1.fth.net; 15 Oct 2002 20:04:20 +0200 Received: by morpheus.lanterncom.com with Internet Mail Service (5.5.2653.19) id <496RRDP8>; Tue, 15 Oct 2002 11:02:37 -0700 Message-ID: <58BE468BAC66D511AFE6000347251A2D01A16420@morpheus.lanterncom.com> From: Anoop Ghanwani To: "'Ashwin Moranganti'" , Anoop Ghanwani Cc: "'ppvpn@ppvpn.francetelecom.com'" Subject: RE: Spanning tree PDUs and VPLS Date: Tue, 15 Oct 2002 11:02:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 965 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Ashwin, From a spanning tree standpoint, the VPLS acts like a hub. However, I think P2MP would mess things up for the spanning tree because it doesn't quite behave like a hub -- a leaf sees spanning tree PDUs from the root, but not from the other leaves. Anyway, since the VPLS drafts don't support P2MP, I guess we need not worry about this. -Anoop > -----Original Message----- > From: Ashwin Moranganti [mailto:amoranganti@appiancom.com] > Sent: Tuesday, October 15, 2002 10:57 AM > To: 'Anoop Ghanwani' > Cc: 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Spanning tree PDUs and VPLS > > > Anoop, > > I believe, the current IETF VPLS drafts, do not support > point-to-multipoint > topologies. > > In MEF, there is a concept of point-to-multipoint Ethernet > virtual circuit. > In which the broadcast, multicast and unicast packets from > the leaf are > forwarded only to the root and not to other leaves. > But multicast, broadcast packets from the root are forwarded > to all the > leaves. > > Ashwin > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@lanterncom.com] > Sent: Tuesday, October 15, 2002 1:24 PM > To: 'Ashwin Moranganti'; Anoop Ghanwani; > 'ppvpn@ppvpn.francetelecom.com' > Subject: RE: Spanning tree PDUs and VPLS > > > Ashwin, > > Thanks for the information. > > What happens in a point-to-multipoint topology? > The leaves don't talk to each other directly so what > happens when a spanning tree PDU is received from > a leaf node? > > -Anoop > > > -----Original Message----- > > From: Ashwin Moranganti [mailto:amoranganti@appiancom.com] > > Sent: Tuesday, October 15, 2002 6:39 AM > > To: 'Anoop Ghanwani'; 'ppvpn@ppvpn.francetelecom.com' > > Subject: RE: Spanning tree PDUs and VPLS > > > > > > Anoop, > > > > VPLS will allow CEs to run STP. The STP frames will be > > tunneled, and will > > forwarded to all ports on the VPLS > > > > Ashwin > > > > -----Original Message----- > > From: Anoop Ghanwani [mailto:anoop@lanterncom.com] > > Sent: Monday, October 14, 2002 7:55 PM > > To: 'ppvpn@ppvpn.francetelecom.com' > > Subject: FW: Spanning tree PDUs and VPLS > > > > > > > > Is there a BCP for what a router should do when it receives > > a spanning tree PDU? Does it treat it like a multicast > > frame and forward it to all ports on the VPLS? Or does > > it just filter these frames? > > > > If the group hasn't discussed this issue, I'd be interested > > in hearing how vendors currently handle spanning tree PDUs. > > > > -Anoop > > -- > > Anoop Ghanwani - Lantern Communications - 408-521-6707 > > > From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 15 14:21:04 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10630 for ; Tue, 15 Oct 2002 14:21:03 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id B70F33EC27; Tue, 15 Oct 2002 20:34:17 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 576A03EC1F for ; Tue, 15 Oct 2002 20:34:12 +0200 (CEST) Received: from sj-msg-core-3.cisco.com (171.70.157.152) by hermes1.fth.net; 15 Oct 2002 20:22:38 +0200 Received: from mira-sjcd-2.cisco.com (IDENT:mirapoint@mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9FIMLaW007156; Tue, 15 Oct 2002 11:22:21 -0700 (PDT) Received: from cisco.com (sjc-vpn1-632.cisco.com [10.21.98.120]) by mira-sjcd-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAK75952; Tue, 15 Oct 2002 11:08:35 -0700 (PDT) Message-ID: <3DAC5CD8.BA1BB34B@cisco.com> Date: Tue, 15 Oct 2002 11:22:16 -0700 From: Norman Finn X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: "Sodder, Arnold" Cc: duwh@huawei.com, ppvpn@ppvpn.francetelecom.com Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt References: <6B190B34070BD411ACA000B0D0214E5601BCE9E7@newman.tenornet.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 966 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit Arnold, Are we talking end-to-end (e.g. enter a box from an Ethernet, transmit on a tunnel, and out again on an Ethernet)? If so, this requirement is totally obsolete. Such a "don't touch the original CRC" rule was once used by bridges. But, bridges have been violating this rule since 802.1Q was introduced. Today, few 802.1Q-compatible bridges keep the CRC intact end-to-end, whether actually doing 802.1Q or not. Furthermore, for many kinds of service, especially those in which different Customer VLANs are used to tell the Service Provider which "tunnel" to which other site a frame should be sent on, it may be important to change part of the frame. For example, the 802.1Q tag may need to change. Not only that, but as currently implemented in many MAN Provider networks, a customer's BPDUs may have their MAC addresses altered in order to get them to pass transparently through a network of Provider bridges. There do exist algorithms that the very careful implementor may use so that, if a frame is altered, a delta to the CRC can be computed and XORed into the original CRC. This allows the frame to be changed without losing all of the benefit an end-to-end CRC. It would be much better to specify a SHOULD for this technique, rather than prohibiting a class of very useful operations based on a behavior that is obsolete. -- Norm "Sodder, Arnold" wrote: > > This requirement comes from an operations standpoint. > > Consider the case where a CE device is creating incorrect data in the frame > body and creating a CRC based on the incorrect data. When the frame is > received by the L2PE device the CRC will be checked and found to be good, > even though the data in the frame is bad. When the total frame (including > the CRC) is delivered by the service providers network there is a trace left > as to where the error was created. In the case where the CRC is stripped, > detecting the error becomes difficult. > > Thus when the original customers frame is not modified this error can be > detected. In the case where the customers frame is modified the error > cannot be detected. In general there should be no need for the L2PE device > to modify the frame. > > For this reason I have choosen to carry the complete frame (including CRC) > over the service providers network. Having an option is possible but being > an implementor I'd like to keep the PE and L2PE devices as simple as > possible and so choose to not support one. > > Hopefully this addresses your question. > > Arnold > > --------------------------- > > Hi,Sodder, Arnold, > > [VHLS] say: > > In the above frame formats the CE frame MUST -include- the original CRC32 to > allow detection of bit errors introduced by devices in the service provider > network or attached to the service provider network. If the L2PE device > needs to modify the CE frame it MUST calculate and add a new CRC32 to the CE > frame. > > draft-martini-l2circuit-encap-mpls-03.txt say: > > For simple Ethernet port to port transport, the entire Ethernet frame > -without- the preamble or FCS is transported as a single packet. > > Would you consider change [VHLS] as later, just because many vendors surport > it now. > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ > Du Wenhua duwh@huawei.com > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ ¡¡¡¡¡¡¡¡¡¡2002-10-11 From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 15 14:33:41 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11088 for ; Tue, 15 Oct 2002 14:33:40 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9FIZCo02136 for ; Tue, 15 Oct 2002 14:35:13 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9FIZ9119323 for ; Tue, 15 Oct 2002 14:35:10 -0400 (EDT) Message-Id: To: "PPVPN mail list" cc: ppvpn@lyris.nortelnetworks.com Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt In-reply-to: Your message of Tue, 15 Oct 2002 11:22:16 -0700. <3DAC5CD8.BA1BB34B@cisco.com> Reply-To: "PPVPN mail list" User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 15 Oct 2002 14:34:48 -0400 From: Eric Rosen X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] List-Unsubscribe: Norm> Such a "don't touch the original CRC" rule was once used by Norm> bridges. But, bridges have been violating this rule since 802.1Q was Norm> introduced. Today, few 802.1Q-compatible bridges keep the CRC intact Norm> end-to-end, whether actually doing 802.1Q or not. This is actually a PWE3 issue, as it has to do with the ethernet-over- IP/MPLS encapsulation and the service provided thereby, but has nothing really to do with VPNs. The discussion in PWE3 might have been easier if anyone there had known what you say above ;-) However, the "requirement" to keep the CRC intact was rejected there on the grounds that the PE devices offering the emulated ethernet service might be routers with standard NICs, and the standard NICs might insist on generating the CRC no matter what anyone says. --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 15 16:07:11 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13979 for ; Tue, 15 Oct 2002 16:03:45 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9FK4xo27779 for ; Tue, 15 Oct 2002 16:05:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9FK4s121862 for ; Tue, 15 Oct 2002 16:04:57 -0400 (EDT) Message-Id: To: "PPVPN mail list" cc: "PPVPN mail list" Subject: Re: New PPVPN web page and mail list In-reply-to: Your message of Tue, 15 Oct 2002 12:32:02 -0400. Reply-To: "PPVPN mail list" User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 15 Oct 2002 16:04:07 -0400 From: Eric Rosen X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] The new mailing list server does several objectionable things: 1. It rewrites the To: field, whose contents should really be determined by the composer of the message. 2. It changes the message-id, making it impossible to filter for duplicates. 3. It inserts a "Reply-to:" field specifying the mailing list. This is about the worst thing it could do; any time someone tries to respond to a message by "reply to sender" (assuming the reply will be private), the whole list will see the message. Can you fix this? If not, I would strongly recommend moving the mailing list to a different server which doesn't have these problems. --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 15 16:29:48 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14941 for ; Tue, 15 Oct 2002 16:29:47 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9FKVIo03680 for ; Tue, 15 Oct 2002 16:31:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9FKVF119615 for ; Tue, 15 Oct 2002 16:31:15 -0400 (EDT) Message-ID: Date: Tue, 15 Oct 2002 13:30:41 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: "PPVPN mail list" Subject: Re: New PPVPN web page and mail list Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050406080507020606090304" X-SMTP-HELO: boreas.isi.edu X-SMTP-MAIL-FROM: larse@ISI.EDU X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: boreas.isi.edu [128.9.160.161] Reply-To: "PPVPN mail list" This is a cryptographically signed message in MIME format. --------------ms050406080507020606090304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric Rosen wrote: > The new mailing list server does several objectionable things: ... It also doesn't add a "Sender:" field, which is useful to filter on. Lars -- Lars Eggert USC Information Sciences Institute --------------ms050406080507020606090304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMTAxNTIwMzA0MVowIwYJKoZIhvcNAQkEMRYEFOmwrLgIA48XOsSGQflx Qef6BcdjMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAJo6Ar1MOX1wwhvvMOlaUF/5dOJGN8Jhgu1KM5s7EdgaCnsy9nwC2 JfTF2L//nTKxIoC0a6KQWhnvdQhQbAjmcwi8kH8JagD9EJkkYwG0kzlLW/TzxRFPqiVEPx65 gvLaJ5G3ZCQrYj/B+ztE0mO6Bje+yqQd69Jd/BWOXdYfdG/5QEUjfa3dm3FrmypRteyhUdYP V+3B36zirkPVrVwR0P8sCq3eCNZ1ZJSk46K+Beq91hpIORpKH8owqwKwpkDb/pzFSaKcCmZn QkUhIgA2ZbtKokND1K08GxLa4EfTneOsBk4dLiresknCROuDJLFP10N2rnXcpXmkvcs3sW6z rgAAAAAAAA== --------------ms050406080507020606090304 Content-Type: text/plain; charset="us-ascii" Content-description: footer --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com --------------ms050406080507020606090304-- From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 15 18:28:41 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17640 for ; Tue, 15 Oct 2002 18:28:41 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 56C8B3EC2B; Wed, 16 Oct 2002 00:41:53 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id D57A23EC22 for ; Wed, 16 Oct 2002 00:41:43 +0200 (CEST) Received: from exch-srv.CoronaNetworks.com (205.219.34.104) by hermes1.fth.net; 16 Oct 2002 00:30:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt Date: Tue, 15 Oct 2002 15:28:13 -0700 Message-ID: Thread-Topic: questions on draft-ietf-ppvpn-vr-mib-02.txt Thread-Index: AcJwiKL42Zoom9sKEda5xQCw0H7wnwEDjrXg From: "Elwin Eliazer" To: "Joan Cucchiara" , , , , X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 967 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA17640 Hi Joan, Thanks for your very valid comments. Excuse us for the delay in responding. My responses are in-lined below. Cheers, Elwin. -----Original Message----- From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com] Sent: Thursday, October 10, 2002 11:13 AM To: ppvpn@ppvpn.francetelecom.com; sam@coronanetworks.com; elwin@coronanetworks.com; benson.schliesser@savvis.net Subject: questions on draft-ietf-ppvpn-vr-mib-02.txt Hello, A few questions and comments on the MIB. 1) Is the Internal Virtual Link used to connect to VRs in the same PE, or is it a link between VRs in a different PEs? Elwin> It is for VRs in the same PE. 2) Is there a one to many relationship between the vrTunnelIpAddress and the Virtual Routers? Elwin> One to many is possible for the cases of tunnels having a Elwin> demultiplexing field. 3) do you want any scalars to configure the number of VRs on the device? Elwin> That will be nice to add. 4) regarding VPN-ID, have you considered adding some sort of mapping table to which is indexed by VPN-ID, VR? Elwin> This could be for quick searching. Inverse VPN/VR table?? Elwin> Sure...That sounds okay. 5) Having a TC called VrIndexOrZero which is like the above but includes zero, where zero needs to be defined in the Description Clause of the objects * for VrConfigNextAvailableVrId have zero mean that no more VRs can be created. (for example, if the device is out of resources) * for vrId have zero mean that VR 0 is the NULL VR. Elwin> Good suggestion. 6) Limit the vrName to fewer characters (32 is probably good, but could be bigger. 255 seems quite large). This description should probably say these names need to be unique within the table. Elwin> agreed. 7) vrAdminStatus: could testing be added here? Elwin> Sure. 8) vrContextName - why is this a read-create and not a read-only? Elwin> This allows the user to specify the VR context, or community, Elwin> for the particular VR being created. If it were read-only, this Elwin> would mean the device is creating the context for the VR. 9) vrType, not clear what this is, could more description be added? Elwin> This has to be removed. 10) (minor) please change the vrStat to be vrStatus Elwin> will do. 11) RouterId should this be 2 objects ( AddressType and Address ) (as in the INET-ADDRESS-MIB). Elwin> good point. 12) have you considered having the VrIfTable indexed by vrId and vrIfIndex ? (seems like a VR would want to quickly see all of its interfaces). Elwin> No, a VR is identified by the community string itself. Elwin> We are suggesting managing multiple instances of the Elwin> "VrIfTable" using a model similar to that described in RFC2571. 13) vrUp/vrDown traps need to contain a varbind. The vrId is an index. Elwin> No, the vrId MAX-ACCESS is defined as accessible-for-notify. Thanks, Joan From ppvpn-owner@ppvpn.francetelecom.com Tue Oct 15 18:51:14 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18519 for ; Tue, 15 Oct 2002 18:51:13 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id E5D203EC30; Wed, 16 Oct 2002 01:04:26 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 64D3E3EC21 for ; Wed, 16 Oct 2002 01:04:20 +0200 (CEST) Received: from exch-srv.CoronaNetworks.com (205.219.34.104) by hermes1.fth.net; 16 Oct 2002 00:52:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt Date: Tue, 15 Oct 2002 15:50:49 -0700 Message-ID: Thread-Topic: questions on draft-ietf-ppvpn-vr-mib-02.txt Thread-Index: AcJwiKL42Zoom9sKEda5xQCw0H7wnwEDjrXgAAGSGhA= From: "Elwin Eliazer" To: "Joan Cucchiara" , , , Cc: X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 968 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA18519 Resending it, to include the new mailing-list. Those who received it already can ignore this. Cheers, Elwin. -----Original Message----- From: Elwin Eliazer Sent: Tuesday, October 15, 2002 3:29 PM To: 'Joan Cucchiara'; ppvpn@ppvpn.francetelecom.com; sam@coronanetworks.com; elwin@coronanetworks.com; benson.schliesser@savvis.net Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt Hi Joan, Thanks for your very valid comments. Excuse us for the delay in responding. My responses are in-lined below. Cheers, Elwin. -----Original Message----- From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com] Sent: Thursday, October 10, 2002 11:13 AM To: ppvpn@ppvpn.francetelecom.com; sam@coronanetworks.com; elwin@coronanetworks.com; benson.schliesser@savvis.net Subject: questions on draft-ietf-ppvpn-vr-mib-02.txt Hello, A few questions and comments on the MIB. 1) Is the Internal Virtual Link used to connect to VRs in the same PE, or is it a link between VRs in a different PEs? Elwin> It is for VRs in the same PE. 2) Is there a one to many relationship between the vrTunnelIpAddress and the Virtual Routers? Elwin> One to many is possible for the cases of tunnels having a Elwin> demultiplexing field. 3) do you want any scalars to configure the number of VRs on the device? Elwin> That will be nice to add. 4) regarding VPN-ID, have you considered adding some sort of mapping table to which is indexed by VPN-ID, VR? Elwin> This could be for quick searching. Inverse VPN/VR table?? Elwin> Sure...That sounds okay. 5) Having a TC called VrIndexOrZero which is like the above but includes zero, where zero needs to be defined in the Description Clause of the objects * for VrConfigNextAvailableVrId have zero mean that no more VRs can be created. (for example, if the device is out of resources) * for vrId have zero mean that VR 0 is the NULL VR. Elwin> Good suggestion. 6) Limit the vrName to fewer characters (32 is probably good, but could be bigger. 255 seems quite large). This description should probably say these names need to be unique within the table. Elwin> agreed. 7) vrAdminStatus: could testing be added here? Elwin> Sure. 8) vrContextName - why is this a read-create and not a read-only? Elwin> This allows the user to specify the VR context, or community, Elwin> for the particular VR being created. If it were read-only, this Elwin> would mean the device is creating the context for the VR. 9) vrType, not clear what this is, could more description be added? Elwin> This has to be removed. 10) (minor) please change the vrStat to be vrStatus Elwin> will do. 11) RouterId should this be 2 objects ( AddressType and Address ) (as in the INET-ADDRESS-MIB). Elwin> good point. 12) have you considered having the VrIfTable indexed by vrId and vrIfIndex ? (seems like a VR would want to quickly see all of its interfaces). Elwin> No, a VR is identified by the community string itself. Elwin> We are suggesting managing multiple instances of the Elwin> "VrIfTable" using a model similar to that described in RFC2571. 13) vrUp/vrDown traps need to contain a varbind. The vrId is an index. Elwin> No, the vrId MAX-ACCESS is defined as accessible-for-notify. Thanks, Joan From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 15 18:51:50 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18548 for ; Tue, 15 Oct 2002 18:51:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9FMrNo07072 for ; Tue, 15 Oct 2002 18:53:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9FMrK129696 for ; Tue, 15 Oct 2002 18:53:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt Date: Tue, 15 Oct 2002 15:50:49 -0700 Message-ID: Thread-Topic: questions on draft-ietf-ppvpn-vr-mib-02.txt Thread-Index: AcJwiKL42Zoom9sKEda5xQCw0H7wnwEDjrXgAAGSGhA= From: "Elwin Eliazer" To: "Joan Cucchiara" , , , Cc: X-SMTP-HELO: exch-srv.CoronaNetworks.com X-SMTP-MAIL-FROM: elwin@coronanetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [205.219.34.104] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA18548 Resending it, to include the new mailing-list. Those who received it already can ignore this. Cheers, Elwin. -----Original Message----- From: Elwin Eliazer Sent: Tuesday, October 15, 2002 3:29 PM To: 'Joan Cucchiara'; ppvpn@ppvpn.francetelecom.com; sam@coronanetworks.com; elwin@coronanetworks.com; benson.schliesser@savvis.net Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt Hi Joan, Thanks for your very valid comments. Excuse us for the delay in responding. My responses are in-lined below. Cheers, Elwin. -----Original Message----- From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com] Sent: Thursday, October 10, 2002 11:13 AM To: ppvpn@ppvpn.francetelecom.com; sam@coronanetworks.com; elwin@coronanetworks.com; benson.schliesser@savvis.net Subject: questions on draft-ietf-ppvpn-vr-mib-02.txt Hello, A few questions and comments on the MIB. 1) Is the Internal Virtual Link used to connect to VRs in the same PE, or is it a link between VRs in a different PEs? Elwin> It is for VRs in the same PE. 2) Is there a one to many relationship between the vrTunnelIpAddress and the Virtual Routers? Elwin> One to many is possible for the cases of tunnels having a Elwin> demultiplexing field. 3) do you want any scalars to configure the number of VRs on the device? Elwin> That will be nice to add. 4) regarding VPN-ID, have you considered adding some sort of mapping table to which is indexed by VPN-ID, VR? Elwin> This could be for quick searching. Inverse VPN/VR table?? Elwin> Sure...That sounds okay. 5) Having a TC called VrIndexOrZero which is like the above but includes zero, where zero needs to be defined in the Description Clause of the objects * for VrConfigNextAvailableVrId have zero mean that no more VRs can be created. (for example, if the device is out of resources) * for vrId have zero mean that VR 0 is the NULL VR. Elwin> Good suggestion. 6) Limit the vrName to fewer characters (32 is probably good, but could be bigger. 255 seems quite large). This description should probably say these names need to be unique within the table. Elwin> agreed. 7) vrAdminStatus: could testing be added here? Elwin> Sure. 8) vrContextName - why is this a read-create and not a read-only? Elwin> This allows the user to specify the VR context, or community, Elwin> for the particular VR being created. If it were read-only, this Elwin> would mean the device is creating the context for the VR. 9) vrType, not clear what this is, could more description be added? Elwin> This has to be removed. 10) (minor) please change the vrStat to be vrStatus Elwin> will do. 11) RouterId should this be 2 objects ( AddressType and Address ) (as in the INET-ADDRESS-MIB). Elwin> good point. 12) have you considered having the VrIfTable indexed by vrId and vrIfIndex ? (seems like a VR would want to quickly see all of its interfaces). Elwin> No, a VR is identified by the community string itself. Elwin> We are suggesting managing multiple instances of the Elwin> "VrIfTable" using a model similar to that described in RFC2571. 13) vrUp/vrDown traps need to contain a varbind. The vrId is an index. Elwin> No, the vrId MAX-ACCESS is defined as accessible-for-notify. Thanks, Joan --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 15 23:55:56 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23164 for ; Tue, 15 Oct 2002 23:55:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9G3vUo17173 for ; Tue, 15 Oct 2002 23:57:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9G3vS111493 for ; Tue, 15 Oct 2002 23:57:28 -0400 (EDT) Date: Wed, 16 Oct 2002 12:09:25 +0800 From: Du Wenhua Subject: Re: RE: Spanning tree PDUs and VPLS To: Ashwin Moranganti Cc: "ppvpn@lyris.nortelnetworks.com" Reply-to: duwh@huawei.com Message-id: <0H4200B2P2VEGU@mta1.huawei.com> Organization: Huawei Techlonogies, Co., Ltd MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta1 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.15] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23164 Ashwin Moranganti, One qustion about run STP on VPLS. In the following diagram, surpose the AC between CE1 and PE1 is VLAN 100, the AC between CE2 and PE1 is VLAN 200, the AC between CE3 and PE2 is VLAN 300. If CE1 and CE2 and CE3 have back door, CEs must run STP. Because many STP protocols(PVST¡¢MST) are associates VLANS with STP instances and carry this information in the BPDU. So how could Acess Networks and PEs deal with the BPDU which is received from CE1 and will be forward to CE2 and CE3, while the VLAN ID must be changed from 100 to 200 or 300? Maybe one solution is, both the Access networks and PEs must tunnel and forward the BPUD. +-----+ + CE1 +\ +-----+ \ ................... VPLS A \ - /\-_ +----+ +----+ - /\-_ \/ \ / \ |VPLS| |VPLS| / \ / \ +-----+ \ Access \--| PE1|--Service--| PE2+---\ Access \----| CE3 | /| Network | +----+ Provider +----+ | Network | +-----+ / \ / . Backbone . \ / VPLS A +-----+ / ------- . | . ------- + CE2 +/ . | . +-----+ . +----+ . VPLS A .....|VPLS|........ | PE3| +----+ Du Wenhua >Anoop, > >VPLS will allow CEs to run STP. The STP frames will be tunneled, and will >forwarded to all ports on the VPLS > >Ashwin > >-----Original Message----- >From: Anoop Ghanwani [mailto:anoop@lanterncom.com] >Sent: Monday, October 14, 2002 7:55 PM >To: 'ppvpn@ppvpn.francetelecom.com' >Subject: FW: Spanning tree PDUs and VPLS > > > >Is there a BCP for what a router should do when it receives >a spanning tree PDU? Does it treat it like a multicast >frame and forward it to all ports on the VPLS? Or does >it just filter these frames? > >If the group hasn't discussed this issue, I'd be interested >in hearing how vendors currently handle spanning tree PDUs. > >-Anoop >-- >Anoop Ghanwani - Lantern Communications - 408-521-6707 = = = = = = = = = = = = = = = = = = = = ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-10-16 --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 16 09:17:52 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28417 for ; Wed, 16 Oct 2002 09:17:36 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9GDIZp02371 for ; Wed, 16 Oct 2002 09:18:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9GDIW824620 for ; Wed, 16 Oct 2002 09:18:33 -0400 (EDT) Message-ID: From: Joris wils To: "'duwh@huawei.com'" , Ashwin Moranganti Cc: ppvpn@lyris.nortelnetworks.com Subject: RE: RE: Spanning tree PDUs and VPLS Date: Wed, 16 Oct 2002 09:17:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" X-SMTP-HELO: CIMA.coriolisnet.com X-SMTP-MAIL-FROM: jwils@coriolisnet.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [205.229.88.162] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA28417 Wenhua: If I understand you correctly, the VPLS is performing tag translation. Are you describing one VLAN, which uses the tag 100 at CE1/PE1, tag 200 at CE2/PE2 and tag 300 at CE3/PE3. If yes, do the backdoor connections also perform tag translation? If the backdoor links do not perform tag translation, then you have an invalid network, because the tags are not consistent. If the backdoor links DO perform tag translation, then there is no problem, because the tags in the PVST and MST BPDUs will be translated regardless if they use the backdoor or VPLS connection. -----Original Message----- From: Du Wenhua [mailto:duwh@huawei.com] Sent: Wednesday, October 16, 2002 12:09 AM To: Ashwin Moranganti Cc: ppvpn@lyris.nortelnetworks.com Subject: Re: RE: Spanning tree PDUs and VPLS Ashwin Moranganti, One qustion about run STP on VPLS. In the following diagram, surpose the AC between CE1 and PE1 is VLAN 100, the AC between CE2 and PE1 is VLAN 200, the AC between CE3 and PE2 is VLAN 300. If CE1 and CE2 and CE3 have back door, CEs must run STP. Because many STP protocols(PVST¡¢MST) are associates VLANS with STP instances and carry this information in the BPDU. So how could Acess Networks and PEs deal with the BPDU which is received from CE1 and will be forward to CE2 and CE3, while the VLAN ID must be changed from 100 to 200 or 300? Maybe one solution is, both the Access networks and PEs must tunnel and forward the BPUD. +-----+ + CE1 +\ +-----+ \ ................... VPLS A \ - /\-_ +----+ +----+ - /\-_ \/ \ / \ |VPLS| |VPLS| / \ / \ +-----+ \ Access \--| PE1|--Service--| PE2+---\ Access \----| CE3 | /| Network | +----+ Provider +----+ | Network | +-----+ / \ / . Backbone . \ / VPLS A +-----+ / ------- . | . ------- + CE2 +/ . | . +-----+ . +----+ . VPLS A .....|VPLS|........ | PE3| +----+ Du Wenhua >Anoop, > >VPLS will allow CEs to run STP. The STP frames will be tunneled, and will >forwarded to all ports on the VPLS > >Ashwin > >-----Original Message----- >From: Anoop Ghanwani [mailto:anoop@lanterncom.com] >Sent: Monday, October 14, 2002 7:55 PM >To: 'ppvpn@ppvpn.francetelecom.com' >Subject: FW: Spanning tree PDUs and VPLS > > > >Is there a BCP for what a router should do when it receives >a spanning tree PDU? Does it treat it like a multicast >frame and forward it to all ports on the VPLS? Or does >it just filter these frames? > >If the group hasn't discussed this issue, I'd be interested >in hearing how vendors currently handle spanning tree PDUs. > >-Anoop >-- >Anoop Ghanwani - Lantern Communications - 408-521-6707 = = = = = = = = = = = = = = = = = = = = ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-10-16 --- You are currently subscribed to ppvpn as: jwils@coriolisnet.com To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 16 12:24:50 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04829 for ; Wed, 16 Oct 2002 12:24:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9GGQIb18694 for ; Wed, 16 Oct 2002 12:26:19 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9GGQD827922 for ; Wed, 16 Oct 2002 12:26:16 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Joris wils" , , "Ashwin Moranganti" Cc: Subject: RE: RE: Spanning tree PDUs and VPLS Date: Wed, 16 Oct 2002 09:25:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit 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 V5.50.4133.2400 In-Reply-To: X-OriginalArrivalTime: 16 Oct 2002 16:24:29.0313 (UTC) FILETIME=[806A5F10:01C27530] X-SMTP-HELO: mail.timetranetworks.com X-SMTP-MAIL-FROM: vkompella@timetranetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: mail.timetra.com [63.104.212.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit The tags 100, 200, and 300, respectively, are used only on the access to provider link. They get stripped. Any per customer VLAN tags on the BPDUs remain (if you are using multiple per-VLAN STP instances, i.e., 802.1s, over a single VPLS, but there are additional complications). So these tags 100, 200, or 300 do not show up in the inter-CE connectivity, as I envision it. -Vach > -----Original Message----- > From: Joris wils [mailto:jwils@coriolisnet.com] > Sent: Wednesday, October 16, 2002 6:18 AM > To: 'duwh@huawei.com'; Ashwin Moranganti > Cc: ppvpn@lyris.nortelnetworks.com > Subject: RE: RE: Spanning tree PDUs and VPLS > > > Wenhua: > > If I understand you correctly, the VPLS is performing tag translation. Are > you describing one VLAN, which uses the tag 100 at CE1/PE1, tag 200 at > CE2/PE2 and tag 300 at CE3/PE3. > > If yes, do the backdoor connections also perform tag translation? If the > backdoor links do not perform tag translation, then you have an invalid > network, because the tags are not consistent. If the backdoor links DO > perform tag translation, then there is no problem, because the tags in the > PVST and MST BPDUs will be translated regardless if they use the backdoor or > VPLS connection. > > -----Original Message----- > From: Du Wenhua [mailto:duwh@huawei.com] > Sent: Wednesday, October 16, 2002 12:09 AM > To: Ashwin Moranganti > Cc: ppvpn@lyris.nortelnetworks.com > Subject: Re: RE: Spanning tree PDUs and VPLS > > > Ashwin Moranganti, > One qustion about run STP on VPLS. > In the following diagram, surpose the AC between CE1 and PE1 is VLAN > 100, the AC between CE2 and PE1 is VLAN 200, the AC between CE3 and PE2 is > VLAN 300. > If CE1 and CE2 and CE3 have back door, CEs must run STP. > Because many STP protocols(PVST¡¢MST) are associates VLANS with STP > instances and carry this information in the BPDU. So how could Acess > Networks and PEs deal with the BPDU which is received from CE1 and will be > forward to CE2 and CE3, while the VLAN ID must be changed from 100 to 200 > or 300? Maybe one solution is, both the Access networks and PEs must > tunnel and forward the BPUD. > > +-----+ > + CE1 +\ > +-----+ \ ................... > VPLS A \ - /\-_ +----+ +----+ - /\-_ > \/ \ / \ |VPLS| |VPLS| / \ / \ +-----+ > \ Access \--| PE1|--Service--| PE2+---\ Access \----| CE3 | > /| Network | +----+ Provider +----+ | Network | +-----+ > / \ / . Backbone . \ / VPLS A > +-----+ / ------- . | . ------- > + CE2 +/ . | . > +-----+ . +----+ . > VPLS A .....|VPLS|........ > | PE3| > +----+ > > > Du Wenhua > > > >Anoop, > > > >VPLS will allow CEs to run STP. The STP frames will be tunneled, and will > >forwarded to all ports on the VPLS > > > >Ashwin > > > >-----Original Message----- > >From: Anoop Ghanwani [mailto:anoop@lanterncom.com] > >Sent: Monday, October 14, 2002 7:55 PM > >To: 'ppvpn@ppvpn.francetelecom.com' > >Subject: FW: Spanning tree PDUs and VPLS > > > > > > > >Is there a BCP for what a router should do when it receives > >a spanning tree PDU? Does it treat it like a multicast > >frame and forward it to all ports on the VPLS? Or does > >it just filter these frames? > > > >If the group hasn't discussed this issue, I'd be interested > >in hearing how vendors currently handle spanning tree PDUs. > > > >-Anoop > >-- > >Anoop Ghanwani - Lantern Communications - 408-521-6707 > > = = = = = = = = = = = = = = = = = = = = > > > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-10-16 > > > > > > --- > You are currently subscribed to ppvpn as: jwils@coriolisnet.com > To unsubscribe send a blank email to > leave-ppvpn-121951I@lyris.nortelnetworks.com > > > --- > You are currently subscribed to ppvpn as: vkompella@timetra.com > To unsubscribe send a blank email to > leave-ppvpn-121951I@lyris.nortelnetworks.com --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 16 14:07:19 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07701 for ; Wed, 16 Oct 2002 14:07:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9GI8oK11411 for ; Wed, 16 Oct 2002 14:08:51 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9GI8lt09576 for ; Wed, 16 Oct 2002 14:08:47 -0400 (EDT) Reply-To: From: "asodder" To: "'PPVPN mail list'" Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Wed, 16 Oct 2002 14:03:57 -0400 Message-ID: <002901c2753e$66edd540$d903a8c0@tenornet.com> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: X-SMTP-HELO: tenornetworks.com X-SMTP-MAIL-FROM: asodder@tenornetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtu.tenornetworks.com [63.77.213.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit >This is actually a PWE3 issue, as it has to do with the ethernet-over- >IP/MPLS encapsulation and the service provided thereby, but has nothing >really to do with VPNs. Eric, You mentioned that this is a PWE3 issue, however I was under the (maybe incorrect) assumption that the outer mac frame follows the rules as specified in the PWE3 draft for ethernet-over-IP/MPLS. If this is incorrect do let me know. The inner mac frame is different but should be transported as data in the outer mac frame. Arnold --- You are currently subscribed to ppvpn as: asodder@tenornetworks.com To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 16 14:18:48 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08158 for ; Wed, 16 Oct 2002 14:18:47 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9GIKIK16146 for ; Wed, 16 Oct 2002 14:20:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9GIKFt02629 for ; Wed, 16 Oct 2002 14:20:15 -0400 (EDT) Reply-To: From: "asodder" To: Subject: FW: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Wed, 16 Oct 2002 14:15:27 -0400 Message-ID: <002a01c27540$016a0fc0$d903a8c0@tenornet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-MIME-Autoconverted: from 8bit to quoted-printable by tenornetworks.com id g9GIJR804724 X-SMTP-HELO: tenornetworks.com X-SMTP-MAIL-FROM: asodder@tenornetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtu.tenornetworks.com [63.77.213.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA08158 -----Original Message----- From: asodder [mailto:asodder@tenornetworks.com] Sent: Wednesday, October 16, 2002 1:59 PM To: 'Norman Finn' Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Norm, I agree that this requirement should be changed to a should. In doing that I'll also need to add a bit in the VHLS-ICW that indicates if the inner CRC is present or not. Arnold -----Original Message----- From: Norman Finn [mailto:nfinn@cisco.com] Sent: Tuesday, October 15, 2002 2:22 PM To: Sodder, Arnold Cc: duwh@huawei.com; ppvpn@ppvpn.francetelecom.com Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Arnold, Are we talking end-to-end (e.g. enter a box from an Ethernet, transmit on a tunnel, and out again on an Ethernet)? If so, this requirement is totally obsolete. Such a "don't touch the original CRC" rule was once used by bridges. But, bridges have been violating this rule since 802.1Q was introduced. Today, few 802.1Q-compatible bridges keep the CRC intact end-to-end, whether actually doing 802.1Q or not. Furthermore, for many kinds of service, especially those in which different Customer VLANs are used to tell the Service Provider which "tunnel" to which other site a frame should be sent on, it may be important to change part of the frame. For example, the 802.1Q tag may need to change. Not only that, but as currently implemented in many MAN Provider networks, a customer's BPDUs may have their MAC addresses altered in order to get them to pass transparently through a network of Provider bridges. There do exist algorithms that the very careful implementor may use so that, if a frame is altered, a delta to the CRC can be computed and XORed into the original CRC. This allows the frame to be changed without losing all of the benefit an end-to-end CRC. It would be much better to specify a SHOULD for this technique, rather than prohibiting a class of very useful operations based on a behavior that is obsolete. -- Norm "Sodder, Arnold" wrote: > > This requirement comes from an operations standpoint. > > Consider the case where a CE device is creating incorrect data in the frame > body and creating a CRC based on the incorrect data. When the frame is > received by the L2PE device the CRC will be checked and found to be good, > even though the data in the frame is bad. When the total frame (including > the CRC) is delivered by the service providers network there is a trace left > as to where the error was created. In the case where the CRC is stripped, > detecting the error becomes difficult. > > Thus when the original customers frame is not modified this error can be > detected. In the case where the customers frame is modified the error > cannot be detected. In general there should be no need for the L2PE device > to modify the frame. > > For this reason I have choosen to carry the complete frame (including CRC) > over the service providers network. Having an option is possible but being > an implementor I'd like to keep the PE and L2PE devices as simple as > possible and so choose to not support one. > > Hopefully this addresses your question. > > Arnold > > --------------------------- > > Hi,Sodder, Arnold, > > [VHLS] say: > > In the above frame formats the CE frame MUST -include- the original CRC32 to > allow detection of bit errors introduced by devices in the service provider > network or attached to the service provider network. If the L2PE device > needs to modify the CE frame it MUST calculate and add a new CRC32 to the CE > frame. > > draft-martini-l2circuit-encap-mpls-03.txt say: > > For simple Ethernet port to port transport, the entire Ethernet frame > -without- the preamble or FCS is transported as a single packet. > > Would you consider change [VHLS] as later, just because many vendors surport > it now. > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ > Du Wenhua duwh@huawei.com > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ ¡¡¡¡¡¡¡¡¡¡2002-10-11 --- You are currently subscribed to ppvpn as: ppvpn-archive@lists.ietf.org To unsubscribe send a blank email to leave-ppvpn-121951I@lyris.nortelnetworks.com From ppvpn-owner@ppvpn.francetelecom.com Wed Oct 16 15:37:38 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10259 for ; Wed, 16 Oct 2002 15:37:38 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id B792F3EC17; Wed, 16 Oct 2002 21:50:50 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 681193EC11 for ; Wed, 16 Oct 2002 21:50:45 +0200 (CEST) Received: from hotmail.com (216.33.241.213) by hermes1.fth.net; 16 Oct 2002 21:39:12 +0200 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 16 Oct 2002 12:39:11 -0700 Received: from 200.198.64.36 by lw8fd.law8.hotmail.msn.com with HTTP; Wed, 16 Oct 2002 19:39:10 GMT X-Originating-IP: [200.198.64.36] From: "Rubens Gomes" To: ppvpn@ppvpn.francetelecom.com Subject: Route Distinguisher Id Date: Wed, 16 Oct 2002 19:39:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Oct 2002 19:39:11.0405 (UTC) FILETIME=[B37C25D0:01C2754B] X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 969 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its IP backbone. Right now, we are in the process of establishing conventions and strategies to name and identify things like RDs, vrfNames, and such in the VPN VRFs. A question has been raised regarding the strategy to be used for the RDs. Should the RD be unique per VPN? That is, within the same VPN, use the same RD in the different VRFs? Or should we use a distinct RDs for each VRF in the network? From the perspective of network management it appears to make sense to use the same RD in a VPN because that would facilitate the correlation of VPNs with RDs. However, someone else here raised the possiblity of NOT having unique routes when the same RD is used, and is aiming at unique RDs in the network. Here is basically what this person has raised: aim: make routes unique, distinguish between VRF on same PE set: on the VRF and attached to all routes when redistributed into MP-BGP rule 1: no 2 VRFs on the same PE may have the same RD rule 2: the combination of : (=VPNV4-address) needs to be unique in the provider network as BGP (MP-BGP) only forwards the best route (otherwise load-balance won’t happen on redundant links) The bottonline: Should RDs be unique or not? Rubens S. Gomes http://www.rubens-gomes.com _________________________________________________________________ Unlimited Internet access -- and 2 months free!  Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp From ppvpn-owner@ppvpn.francetelecom.com Wed Oct 16 16:07:12 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10691 for ; Wed, 16 Oct 2002 16:07:11 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 200B93EC1A; Wed, 16 Oct 2002 22:20:26 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 184163EC11 for ; Wed, 16 Oct 2002 22:20:21 +0200 (CEST) Received: from sj-msg-core-3.cisco.com (171.70.157.152) by hermes1.fth.net; 16 Oct 2002 22:08:47 +0200 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9GK8jxF010195; Wed, 16 Oct 2002 13:08:45 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjcm-3.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAS40728; Wed, 16 Oct 2002 13:06:21 -0700 (PDT) Message-ID: <3DADC74A.853498A0@cisco.com> Date: Wed, 16 Oct 2002 22:08:42 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rubens Gomes Cc: ppvpn@ppvpn.francetelecom.com Subject: Re: Route Distinguisher Id References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 970 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit > The bottonline: Should RDs be unique or not? My recommendation would be to make them unique. If you want to discuss pros & cons of both approaches fell free to send me mail offline as some of them are simply vendor specific :). Rgs, R. > Rubens Gomes wrote: > > My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its > IP backbone. Right > now, we are in the process of establishing conventions and strategies to > name and identify things like > RDs, vrfNames, and such in the VPN VRFs. > > A question has been raised regarding the strategy to be used for the RDs. > Should the RD be unique > per VPN? That is, within the same VPN, use the same RD in the different > VRFs? Or should we use a > distinct RDs for each VRF in the network? From the perspective of network > management it appears > to make sense to use the same RD in a VPN because that would facilitate the > correlation of VPNs > with RDs. However, someone else here raised the possiblity of NOT having > unique routes when the > same RD is used, and is aiming at unique RDs in the network. Here is > basically what this person has > raised: > > aim: make routes unique, distinguish between VRF on same PE > set: on the VRF and attached to all routes when redistributed into MP-BGP > rule 1: no 2 VRFs on the same PE may have the same RD > rule 2: the combination of : (=VPNV4-address) needs to be > unique in the provider network as BGP (MP-BGP) only forwards the best route > (otherwise load-balance > won’t happen on redundant links) > > The bottonline: Should RDs be unique or not? > > Rubens S. Gomes > http://www.rubens-gomes.com > > _________________________________________________________________ > Unlimited Internet access -- and 2 months free! Try MSN. > http://resourcecenter.msn.com/access/plans/2monthsfree.asp From ppvpn-owner@ppvpn.francetelecom.com Wed Oct 16 19:43:41 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15281 for ; Wed, 16 Oct 2002 19:43:40 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 6A8E23EC17; Thu, 17 Oct 2002 01:56:53 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id C2FFB3EC11 for ; Thu, 17 Oct 2002 01:56:48 +0200 (CEST) Received: from merlot.juniper.net (207.17.136.129) by hermes1.fth.net; 17 Oct 2002 01:45:14 +0200 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9GNjCm60743; Wed, 16 Oct 2002 16:45:12 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200210162345.g9GNjCm60743@merlot.juniper.net> To: "Rubens Gomes" Cc: ppvpn@ppvpn.francetelecom.com Subject: Re: Route Distinguisher Id In-Reply-To: Your message of "Wed, 16 Oct 2002 19:39:10 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <90767.1034811912.1@juniper.net> Date: Wed, 16 Oct 2002 16:45:12 -0700 From: Yakov Rekhter X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 971 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA15281 Rubens, > My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its > IP backbone. Right > now, we are in the process of establishing conventions and strategies to > name and identify things like > RDs, vrfNames, and such in the VPN VRFs. > > A question has been raised regarding the strategy to be used for the RDs. > Should the RD be unique > per VPN? That is, within the same VPN, use the same RD in the different > VRFs? Or should we use a > distinct RDs for each VRF in the network? From the perspective of network > management it appears > to make sense to use the same RD in a VPN because that would facilitate the > correlation of VPNs > with RDs. However, someone else here raised the possiblity of NOT having > unique routes when the > same RD is used, and is aiming at unique RDs in the network. Here is > basically what this person has > raised: > > aim: make routes unique, distinguish between VRF on same PE > set: on the VRF and attached to all routes when redistributed into MP-BGP > rule 1: no 2 VRFs on the same PE may have the same RD > rule 2: the combination of : (=VPNV4-address) needs to be > unique in the provider network as BGP (MP-BGP) only forwards the best route > (otherwise load-balance > won’t happen on redundant links) > > > The bottonline: Should RDs be unique or not? If you use a distinct RD for each VRF, then it is possible to autoconfigure such RDs (thus avoiding efforts in managing allocation/assignment and configuration of RDs). Also, if you use a distinct RD for each VRF, then it enables pretty straightforward support for load sharing among multiple links of a multihomed site (where the site is multihomed to different PEs). Yakov. From ppvpn-owner@ppvpn.francetelecom.com Wed Oct 16 20:00:37 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15683 for ; Wed, 16 Oct 2002 20:00:37 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 266873EC17; Thu, 17 Oct 2002 02:13:51 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id A29943EC11 for ; Thu, 17 Oct 2002 02:13:46 +0200 (CEST) Received: from exch-srv.CoronaNetworks.com (205.219.34.104) by hermes1.fth.net; 17 Oct 2002 02:02:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Route Distinguisher Id Date: Wed, 16 Oct 2002 17:00:12 -0700 Message-ID: Thread-Topic: Route Distinguisher Id Thread-Index: AcJ1S3nS05sMsQFeR8aiTXtaCc6qoAAJMclA From: "Shiv Agarwal" To: "Rubens Gomes" , X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 972 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA15683 Rubens, Can you ensure that the address space of VRFs participating in a VPN does not overlap? If yes, then all VRFs in a VPN can be assigned the same RD. Also your point of correlating RDs with VPNs may not hold good for VRFs participating in multiple VPNs. Try to correlate VPNs using both RD and RTs. Shiv. -----Original Message----- From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] Sent: Wednesday, October 16, 2002 12:39 PM To: ppvpn@ppvpn.francetelecom.com Subject: Route Distinguisher Id My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its IP backbone. Right now, we are in the process of establishing conventions and strategies to name and identify things like RDs, vrfNames, and such in the VPN VRFs. A question has been raised regarding the strategy to be used for the RDs. Should the RD be unique per VPN? That is, within the same VPN, use the same RD in the different VRFs? Or should we use a distinct RDs for each VRF in the network? From the perspective of network management it appears to make sense to use the same RD in a VPN because that would facilitate the correlation of VPNs with RDs. However, someone else here raised the possiblity of NOT having unique routes when the same RD is used, and is aiming at unique RDs in the network. Here is basically what this person has raised: aim: make routes unique, distinguish between VRF on same PE set: on the VRF and attached to all routes when redistributed into MP-BGP rule 1: no 2 VRFs on the same PE may have the same RD rule 2: the combination of : (=VPNV4-address) needs to be unique in the provider network as BGP (MP-BGP) only forwards the best route (otherwise load-balance won't happen on redundant links) The bottonline: Should RDs be unique or not? Rubens S. Gomes http://www.rubens-gomes.com _________________________________________________________________ Unlimited Internet access -- and 2 months free!  Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp From ppvpn-owner@ppvpn.francetelecom.com Wed Oct 16 21:39:10 2002 Received: from smtp-out.fteb.net (cerbere.minitel.net [193.252.91.94]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17978 for ; Wed, 16 Oct 2002 21:39:10 -0400 (EDT) Received: by smtp-out.fteb.net (Postfix, from userid 0) id 05B0B3EC17; Thu, 17 Oct 2002 03:52:23 +0200 (CEST) Received: from hermes1.fth.net (hermes1.pl.fth.net [193.252.69.31]) by smtp-out.fteb.net (Postfix) with ESMTP id 2CC353EC11 for ; Thu, 17 Oct 2002 03:52:17 +0200 (CEST) Received: from ns1.oware.net (64.50.112.33) by hermes1.fth.net; 17 Oct 2002 03:40:42 +0200 Received: from kojak ([64.50.112.68]) by ns1.oware.net (8.10.2+Sun/8.10.2) with ESMTP id g9H1biJ21088; Wed, 16 Oct 2002 18:37:44 -0700 (PDT) From: "Joe Lin" To: "'Shiv Agarwal'" , "'Rubens Gomes'" , Subject: RE: Route Distinguisher Id Date: Wed, 16 Oct 2002 18:42:01 -0700 Message-ID: <016b01c2757e$637bebf0$9800a8c0@kojak> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Loop: ppvpn@ppvpn.francetelecom.com X-Sequence: 973 Precedence: list List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: Sender: ppvpn-owner@ppvpn.francetelecom.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA17978 In the operational sense: If you have unique RDs per VRF, it makes troubleshooting a lot easier because you can make correlations easier. But unique RDs will suck up more memory on the PE, at least that’s what I gathered on cisco's website. I don’t have that particular URL anymore. but do a search on cisco's site and you should find it -joe -----Original Message----- From: ppvpn-owner@ppvpn.francetelecom.com [mailto:ppvpn-owner@ppvpn.francetelecom.com] On Behalf Of Shiv Agarwal Sent: Wednesday, October 16, 2002 5:00 PM To: Rubens Gomes; ppvpn@ppvpn.francetelecom.com Subject: RE: Route Distinguisher Id Rubens, Can you ensure that the address space of VRFs participating in a VPN does not overlap? If yes, then all VRFs in a VPN can be assigned the same RD. Also your point of correlating RDs with VPNs may not hold good for VRFs participating in multiple VPNs. Try to correlate VPNs using both RD and RTs. Shiv. -----Original Message----- From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] Sent: Wednesday, October 16, 2002 12:39 PM To: ppvpn@ppvpn.francetelecom.com Subject: Route Distinguisher Id My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its IP backbone. Right now, we are in the process of establishing conventions and strategies to name and identify things like RDs, vrfNames, and such in the VPN VRFs. A question has been raised regarding the strategy to be used for the RDs. Should the RD be unique per VPN? That is, within the same VPN, use the same RD in the different VRFs? Or should we use a distinct RDs for each VRF in the network? From the perspective of network management it appears to make sense to use the same RD in a VPN because that would facilitate the correlation of VPNs with RDs. However, someone else here raised the possiblity of NOT having unique routes when the same RD is used, and is aiming at unique RDs in the network. Here is basically what this person has raised: aim: make routes unique, distinguish between VRF on same PE set: on the VRF and attached to all routes when redistributed into MP-BGP rule 1: no 2 VRFs on the same PE may have the same RD rule 2: the combination of : (=VPNV4-address) needs to be unique in the provider network as BGP (MP-BGP) only forwards the best route (otherwise load-balance won't happen on redundant links) The bottonline: Should RDs be unique or not? Rubens S. Gomes http://www.rubens-gomes.com _________________________________________________________________ Unlimited Internet access -- and 2 months free!  Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 16 22:41:18 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19228 for ; Wed, 16 Oct 2002 22:41:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9H2gno15693 for ; Wed, 16 Oct 2002 22:42:49 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9H2gku06236 for ; Wed, 16 Oct 2002 22:42:47 -0400 (EDT) Date: Thu, 17 Oct 2002 10:54:50 +0800 From: Du Wenhua Subject: Re: RE: RE: Spanning tree PDUs and VPLS To: "vkompella@timetranetworks.com" , Joris wils , Ashwin Moranganti Cc: "ppvpn@lyris.nortelnetworks.com" Reply-to: duwh@huawei.com Message-id: <0H4300JSSU2ZWZ@mta0.huawei.com> Organization: Huawei Techlonogies, Co., Ltd MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA19228 Vach Kompella, Thanks. Your reply has sovle the problem. But in practice, maybe ,there will exist two puzzles: (1)The access network , that is made up of some tradional ethernet switch, must tunnel the CE's BPDU(such as change the DMAC). Some of today's product don't surport this fearture; (2)In my following diagram, if these attachmetn circiurt tags are 100,200,100, and the two access network have backdoor ( this is found in carrier's reality network), how to run STP? --Du Wenhua >The tags 100, 200, and 300, respectively, are used only on the access to >provider link. They get stripped. Any per customer VLAN tags on the BPDUs >remain (if you are using multiple per-VLAN STP instances, i.e., 802.1s, over a >single VPLS, but there are additional complications). So these tags 100, 200, >or 300 do not show up in the inter-CE connectivity, as I envision it. > >-Vach > >> -----Original Message----- >> From: Joris wils [mailto:jwils@coriolisnet.com] >> Sent: Wednesday, October 16, 2002 6:18 AM >> To: 'duwh@huawei.com'; Ashwin Moranganti >> Cc: ppvpn@lyris.nortelnetworks.com >> Subject: RE: RE: Spanning tree PDUs and VPLS >> >> >> Wenhua: >> >> If I understand you correctly, the VPLS is performing tag translation. Are >> you describing one VLAN, which uses the tag 100 at CE1/PE1, tag 200 at >> CE2/PE2 and tag 300 at CE3/PE3. >> >> If yes, do the backdoor connections also perform tag translation? If the >> backdoor links do not perform tag translation, then you have an invalid >> network, because the tags are not consistent. If the backdoor links DO >> perform tag translation, then there is no problem, because the tags in the >> PVST and MST BPDUs will be translated regardless if they use the backdoor or >> VPLS connection. >> >> -----Original Message----- >> From: Du Wenhua [mailto:duwh@huawei.com] >> Sent: Wednesday, October 16, 2002 12:09 AM >> To: Ashwin Moranganti >> Cc: ppvpn@lyris.nortelnetworks.com >> Subject: Re: RE: Spanning tree PDUs and VPLS >> >> >> Ashwin Moranganti, >> One qustion about run STP on VPLS. >> In the following diagram, surpose the AC between CE1 and PE1 is VLAN >> 100, the AC between CE2 and PE1 is VLAN 200, the AC between CE3 and PE2 is >> VLAN 300. >> If CE1 and CE2 and CE3 have back door, CEs must run STP. >> Because many STP protocols(PVST¡¢MST) are associates VLANS with STP >> instances and carry this information in the BPDU. So how could Acess >> Networks and PEs deal with the BPDU which is received from CE1 and will be >> forward to CE2 and CE3, while the VLAN ID must be changed from 100 to 200 >> or 300? Maybe one solution is, both the Access networks and PEs must >> tunnel and forward the BPUD. >> >> +-----+ >> + CE1 +\ >> +-----+ \ ................... >> VPLS A \ - /\-_ +----+ +----+ - /\-_ >> \/ \ / \ |VPLS| |VPLS| / \ / \ +-----+ >> \ Access \--| PE1|--Service--| PE2+---\ Access \----| CE3 | >> /| Network | +----+ Provider +----+ | Network | +-----+ >> / \ / . Backbone . \ / VPLS A >> +-----+ / ------- . | . ------- >> + CE2 +/ . | . >> +-----+ . +----+ . >> VPLS A .....|VPLS|........ >> | PE3| >> +----+ >> >> >> Du Wenhua >> >> >> >Anoop, >> > >> >VPLS will allow CEs to run STP. The STP frames will be tunneled, and will >> >forwarded to all ports on the VPLS >> > >> >Ashwin >> > >> >-----Original Message----- >> >From: Anoop Ghanwani [mailto:anoop@lanterncom.com] >> >Sent: Monday, October 14, 2002 7:55 PM >> >To: 'ppvpn@ppvpn.francetelecom.com' >> >Subject: FW: Spanning tree PDUs and VPLS >> > >> > >> > >> >Is there a BCP for what a router should do when it receives >> >a spanning tree PDU? Does it treat it like a multicast >> >frame and forward it to all ports on the VPLS? Or does >> >it just filter these frames? >> > >> >If the group hasn't discussed this issue, I'd be interested >> >in hearing how vendors currently handle spanning tree PDUs. >> > >> >-Anoop >> >-- >> >Anoop Ghanwani - Lantern Communications - 408-521-6707 >> >> = = = = = = = = = = = = = = = = = = = = >> >> >> >> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua >> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com >> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-10-16 >> >> >> >> >> >> --- >> You are currently subscribed to ppvpn as: jwils@coriolisnet.com >> To unsubscribe send a blank email to >> leave-ppvpn-121951I@lyris.nortelnetworks.com >> >> >> --- >> You are currently subscribed to ppvpn as: vkompella@timetra.com >> To unsubscribe send a blank email to >> leave-ppvpn-121951I@lyris.nortelnetworks.com = = = = = = = = = = = = = = = = = = = = ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Ö Àñ£¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-10-17 From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 08:46:56 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08475 for ; Thu, 17 Oct 2002 08:46:55 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HCmSu00770 for ; Thu, 17 Oct 2002 08:48:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HCmP219867 for ; Thu, 17 Oct 2002 08:48:26 -0400 (EDT) Message-Id: <200210171245.g9HCjUm97476@merlot.juniper.net> To: "Joe Lin" cc: "'Shiv Agarwal'" , "'Rubens Gomes'" , ppvpn@ppvpn.francetelecom.com Subject: Re: Route Distinguisher Id In-Reply-To: Your message of "Wed, 16 Oct 2002 18:42:01 PDT." <016b01c2757e$637bebf0$9800a8c0@kojak> MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <29767.1034858730.1@juniper.net> Date: Thu, 17 Oct 2002 05:45:30 -0700 From: Yakov Rekhter X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA08475 Joe, > In the operational sense: > > If you have unique RDs per VRF, it makes troubleshooting a lot easier > because you can make correlations easier. > > But unique RDs will suck up more memory on the PE, at least that's what > I gathered on cisco's website. While this may be correct for a particular vendor, do *not* assume that it is correct for other vendors. Yakov. > I don't have that particular URL anymore. but do a search on cisco's > site and you should find it > > -joe > > -----Original Message----- > From: ppvpn-owner@ppvpn.francetelecom.com > [mailto:ppvpn-owner@ppvpn.francetelecom.com] On Behalf Of Shiv Agarwal > Sent: Wednesday, October 16, 2002 5:00 PM > To: Rubens Gomes; ppvpn@ppvpn.francetelecom.com > Subject: RE: Route Distinguisher Id > > Rubens, > > Can you ensure that the address space of VRFs participating in a VPN > does not overlap? > If yes, then all VRFs in a VPN can be assigned the same RD. Also your > point of correlating RDs with VPNs may not hold good for VRFs > participating in multiple VPNs. Try to correlate VPNs using both RD and > RTs. > > Shiv. > > -----Original Message----- > From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] > Sent: Wednesday, October 16, 2002 12:39 PM > To: ppvpn@ppvpn.francetelecom.com > Subject: Route Distinguisher Id > > > My company (www.diveo.net.br) is getting ready to implement MPLS VPN in > its > IP backbone. Right > now, we are in the process of establishing conventions and strategies > to > name and identify things like > RDs, vrfNames, and such in the VPN VRFs. > > A question has been raised regarding the strategy to be used for the > RDs. > Should the RD be unique > per VPN? That is, within the same VPN, use the same RD in the different > > VRFs? Or should we use a > distinct RDs for each VRF in the network? From the perspective of > network > management it appears > to make sense to use the same RD in a VPN because that would facilitate > the > correlation of VPNs > with RDs. However, someone else here raised the possiblity of NOT > having > unique routes when the > same RD is used, and is aiming at unique RDs in the network. Here is > basically what this person has > raised: > > aim: make routes unique, distinguish between VRF on same PE > set: on the VRF and attached to all routes when redistributed into > MP-BGP > rule 1: no 2 VRFs on the same PE may have the same RD > rule 2: the combination of : (=VPNV4-address) needs to > be > unique in the provider network as BGP (MP-BGP) only forwards the best > route > (otherwise load-balance > won't happen on redundant links) > > > The bottonline: Should RDs be unique or not? > > Rubens S. Gomes > http://www.rubens-gomes.com > > > > > _________________________________________________________________ > Unlimited Internet access -- and 2 months free!  Try MSN. > http://resourcecenter.msn.com/access/plans/2monthsfree.asp > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 09:19:48 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09869 for ; Thu, 17 Oct 2002 09:19:47 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HDLIu10195 for ; Thu, 17 Oct 2002 09:21:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HDLG213415 for ; Thu, 17 Oct 2002 09:21:16 -0400 (EDT) Message-Id: <200210171320.g9HDKjIm009191@sj-msg-core-1.cisco.com> To: asodder@tenornetworks.com Cc: ppvpn@lyris.nortelnetworks.com Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt In-reply-to: Your message of Wed, 16 Oct 2002 14:03:57 -0400. <002901c2753e$66edd540$d903a8c0@tenornet.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 17 Oct 2002 09:20:44 -0400 From: Eric Rosen X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: Arnold> You mentioned that this is a PWE3 issue, however I was under the Arnold> (maybe incorrect) assumption that the outer mac frame follows the Arnold> rules as specified in the PWE3 draft for ethernet-over-IP/MPLS. If Arnold> this is incorrect do let me know. The inner mac frame is different Arnold> but should be transported as data in the outer mac frame. If you want to argue that the ethernet-over-IP/MPLS service begins after the MAC-in-MAC encaps has been done, and ends before the corresponding decaps has been done, then you could argue that the rules for the MAC-in-MAC encaps are outside PWE3's scope. The rules for MAC-in-MAC encapsulation would then be totally outside the scope of the IETF, I believe, as there is no IP or MPLS involved. The proposal would have to be taken to IEEE. This might be a good way to approach it, as the hierarchy would then be done in the layer 2 network using layer 2 techniques, and in the MPLS/IP layer one can just do "ordinary" VPLS without need for further hierarchy. If on the other hand you want to argue that the ethernet-over-IP/MPLS service begins before the MAC-in-MAC encaps is done, and ends after the decaps is done, then it would have to be considered part of the IP/MPLS encapsulation and would fall under PWE3. From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 09:54:09 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11248 for ; Thu, 17 Oct 2002 09:54:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HDthu16756 for ; Thu, 17 Oct 2002 09:55:45 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HDte212895 for ; Thu, 17 Oct 2002 09:55:41 -0400 (EDT) Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EBE1@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'erosen@cisco.com'" , asodder@tenornetworks.com Cc: ppvpn@lyris.nortelnetworks.com Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Thu, 17 Oct 2002 09:54:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: celox-ma1-ems1.celoxnetworks.com X-SMTP-MAIL-FROM: egray@celoxnetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: celox-ma1-imap1.celoxnetworks.com [12.40.60.233] X-LYRIS-Message-Id: Eric, See below... > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, October 17, 2002 9:21 AM > To: asodder@tenornetworks.com > Cc: ppvpn@lyris.nortelnetworks.com > Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt > > > Arnold> You mentioned that this is a PWE3 issue, however I was > Arnold> under the (maybe incorrect) assumption that the outer > Arnold> mac frame follows the rules as specified in the PWE3 > Arnold> draft for ethernet-over-IP/MPLS. If this is incorrect > Arnold> do let me know. The inner mac frame is different but > Arnold> should be transported as data in the outer mac frame. > > If you want to argue that the ethernet-over-IP/MPLS service begins > after the MAC-in-MAC encaps has been done, and ends before the > corresponding decaps has been done, then you could argue that the > rules for the MAC-in-MAC encaps are outside PWE3's scope. > > The rules for MAC-in-MAC encapsulation would then be totally outside > the scope of the IETF, I believe, as there is no IP or MPLS involved. > The proposal would have to be taken to IEEE. > > This might be a good way to approach it, as the hierarchy would then be > done in the layer 2 network using layer 2 techniques, and in the > MPLS/IP layer one can just do "ordinary" VPLS without need for further > hierarchy. > This seems very reasonable. In fact, I can't see how making L2 (MAC) re-encapsulation part of something the IETF cares about could make sense... > ... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 10:11:05 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12027 for ; Thu, 17 Oct 2002 10:11:04 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HECgu02385 for ; Thu, 17 Oct 2002 10:12:42 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HECd218150 for ; Thu, 17 Oct 2002 10:12:39 -0400 (EDT) Message-Id: <200210171412.g9HEC6d09521@zcars0ms.ca.nortel.com> Date: Thu, 17 Oct 2002 09:11:58 -0500 From: Joe Creel To: Subject: testing non member postings X-Mailer: USANET web-mailer (CM.0402.4.07) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-SMTP-HELO: cmsoutbound.mx.net X-SMTP-MAIL-FROM: tallship@usa.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: cmsrelay01.mx.net [165.212.11.110] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12027 hello; Trying to verify that non list members can post to this list. thanks Joe Creel NORTEL/CSC Thanks Joe Creel tallship@usa.net From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 10:31:07 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12786 for ; Thu, 17 Oct 2002 10:31:07 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HEWUu07615 for ; Thu, 17 Oct 2002 10:32:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HEWR206187 for ; Thu, 17 Oct 2002 10:32:27 -0400 (EDT) Date: Thu, 17 Oct 2002 10:35:28 -0400 Message-ID: <3DAB0A1300003CBF@mta08.san.yahoo.com> From: "Kavita Khanna" Subject: MPLS 2002 (www.mpls2002.com) Program Details To: mpls@uu.net, ppvpn@ppvpn.francetelecom.com, pwe3@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: kkhanna@isocore.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12786 The program for the MPLS 2002 International Conference (http://www.mpls2002.com) is detailed below. The conference website has been updated with abstract and bio details (http://www.mpls2002.com/sessions.htm) Tutorials - Sunday, October 27, 2002 - Introduction To MPLS: S. Poretsky, Avici Systems - Label Distribution Protocol: E. Chen & R. Aggarwal, Redback Networks - Traffic Engineering: J. Boyle, PDNets - Optical Networks: D. Awduche, Isocore Corp. - MPLS Restoration: A. Sayeed & Dr. A. Charny, Cisco Systems - GMPLS Recovery: D. Papadimitriou, Alcatel Technical Sessions - Monday, October 28, 2002 - Building a Native Data Network for Corporate VPNs: L. Andersson, Utfors - MPLS Traffic Engineering and MPLS Fast Reroute within Equant's Network: Z. Ahmad, Equant - Multi-QoS Reliable MPLS Networks: H. Komura, NTT - MPLS Interoperability: Milestones and Progress: B. Jabbari, Isocore - Providing Fast convergence and Bandwidth protection with MPLS Traffic Engineering Fast Reroute: J. P. Vasseur, Cisco Systems - Dynamics of Restoration and Convergence in MPLS/TE: C. Villamizar & R. Khanna, Avici Systems - Multi-Layer Restoration: G. Grammel, Alcatel - MPLS Resiliency and Graceful Recovery: R. Aggarwal, Redback Networks - From Pseudowires to Layer 2 VPNs: B. Davie, Cisco Systems - BGP-based Layer 2 VPNs: K. Kompella, Juniper Networks - MPLS: The missing link for delivering Metro Ethernet and ATM Services: G. Leonard, Riverstone Networks - Architectural Considerations for Delivering Scalable Transparent LAN Services (VPLS) over MPLS: S. Khandekar, TiMetra Networks - Layer 2 Interworking between Ethernet, Frame Relay, and ATM: A. Malis, Vivace Networks - A New Paradigm for Layer 3 VPNs: R. Chandra, Redback Networks - Improving the Scability of MPLS based VPNs by Extending MPLS to an Aggregation Router between PE and CE: A. Kankkunen, Tellabs - Speed, Scale, and Services at the Network Edge Using MPLS Based VPNs: E. Gray, Celox Networks - MPLS based VPNs with Voice Applications: B. Goode, ATT Technical Sessions - Tuesday, October 29, 2002 - MPLS Architecture Considerations for Operations and Management: G. Swallow, Cisco Systems - MPLS OAM: Challenges and Opportunities: D. Allan, Nortel Networks - Next Generation Network Management for MPLS-based Services: G. Dixon, Laurel Networks - Integrating NAT and Stateful Firewalls with RFC 2547-based PEs: V. Srinivasan, Cosine Communications - Warning: MPLS is not Secure: M. Barsoum, Quarry Technologies - Security and Protection of PE-CE Interface: C. Chase, ATT Technologies - Characterization and Representation of Impairements for Routing in All-Optical Networks: D.O. Awduche, Isocore - GMPLS-based Photonic Backbone Network: N. Yamanaka, NTT - Routing and Wavelength Assignment Using GMPLS: J. Lang, Calient Networks - Interoperability of O-UNI and GMPLS Protocols: Z. Ali and K. Sage, Cisco Systems - GMPLS for Hierarchical and Hybrid Optical networks: S. Araki, NEC - Packet Optical Integration: D. Fedyk, Nortel Networks - Diff-Serv-Aware MPLS Traffic Engineering and its Applications: F. Le Faucheur, Cisco Systems - Online Traffic Engineering with Design-Based Routing: I. Widjaja, I. Saniee, A. Elwalid, and D. Mitra, Lucent Technologies - MPLS QoS Performance Evaluation: K. Owens, Erlang Technologies - Characterizing MPLS based VPNs: Capabilites and Role of Core Routers: R. Papneja, Avici Systems and V. Sharma, Metanoia, Inc. - Traffic Engineering Considerations in GMPLS Networks: Y. Xue - Emerging New GMPLS-based Optical VPNs: H. Ould-Brahim, Nortel Networks - The Emergence of a Multiprotocol Core: A. Missing, Alcatel From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 11:17:10 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14393 for ; Thu, 17 Oct 2002 11:17:10 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HFIbu01112 for ; Thu, 17 Oct 2002 11:18:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HFIZ211145 for ; Thu, 17 Oct 2002 11:18:35 -0400 (EDT) Message-ID: <1117F7D44159934FB116E36F4ABF221B020B0EF6@celox-ma1-ems1.celoxnetworks.com> From: "Suryanarayana, Ananth" To: "'Rubens Gomes'" , ppvpn@ppvpn.francetelecom.com Subject: RE: Route Distinguisher Id Date: Thu, 17 Oct 2002 11:18:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: ananth@celoxnetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: It seems, if RD is unique per VPN, then it logically correct as RD's purpose is after all to distinguish routes with same prefixes amogst different vpns. But, I am not sure how it can be implemented? for eg: consider the case in which three are three CE routers CE1(belonging to VPN1). CE2 (belonging to VPN2) and CE3 (belonging to both VPN1 and VPN2) attached to a single PE. A sample configuration for this would be having three VRFs as CE1---attached to VRF1 (Import RT 1:1 and 1:3, Export RT 1:1) RD 1:1 (Belongs to VPN1) CE2---attached to VRF2 (Import RT 1:2 and 1:3, Export RT 1:2) RD 1:2 (Belongs to VPN2) CE3---attached to VRF3 (Import RT 1:1 and 2:2, Export RT 1:3) RD 1:3 (?) (Belongs to both VPN1 and VPN2) Suppose, if both CE1 and CE3 send a VPN1 route 5.5.5.0/24 to the edge router PE with itself as the next-hops, then PE is suppose to select the best route among these routes. But since route from CE1 (attached ro VRF1) will have RD 1:1 which is different from that of route advertised from CE3 (Attached to VRF3, which will be 1:3), they will not be comparable. Now, in this case, if configurable RDs supported are only one per VRF, how can we ensure that route selection process is corectly made by making RD unique per VRF. If we want to make it unique per VPN, does it mean, multiple (default) RDs per VRF support is required? Thanks, Ananth -----Original Message----- From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] Sent: Wednesday, October 16, 2002 3:39 PM To: ppvpn@ppvpn.francetelecom.com Subject: Route Distinguisher Id My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its IP backbone. Right now, we are in the process of establishing conventions and strategies to name and identify things like RDs, vrfNames, and such in the VPN VRFs. A question has been raised regarding the strategy to be used for the RDs. Should the RD be unique per VPN? That is, within the same VPN, use the same RD in the different VRFs? Or should we use a distinct RDs for each VRF in the network? From the perspective of network management it appears to make sense to use the same RD in a VPN because that would facilitate the correlation of VPNs with RDs. However, someone else here raised the possiblity of NOT having unique routes when the same RD is used, and is aiming at unique RDs in the network. Here is basically what this person has raised: aim: make routes unique, distinguish between VRF on same PE set: on the VRF and attached to all routes when redistributed into MP-BGP rule 1: no 2 VRFs on the same PE may have the same RD rule 2: the combination of : (=VPNV4-address) needs to be unique in the provider network as BGP (MP-BGP) only forwards the best route (otherwise load-balance won't happen on redundant links) The bottonline: Should RDs be unique or not? Rubens S. Gomes http://www.rubens-gomes.com _________________________________________________________________ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 12:32:39 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16769 for ; Thu, 17 Oct 2002 12:32:38 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HGY9u21382 for ; Thu, 17 Oct 2002 12:34:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HGY5218990 for ; Thu, 17 Oct 2002 12:34:06 -0400 (EDT) From: "Joe Lin" To: "'Yakov Rekhter'" Cc: "'Shiv Agarwal'" , "'Rubens Gomes'" , Subject: RE: Route Distinguisher Id Date: Thu, 17 Oct 2002 09:34:45 -0700 Message-ID: <018601c275fb$1a612390$9800a8c0@kojak> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200210171245.g9HCjUm97476@merlot.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: jlin@doradosoftware.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16769 I apologize for my implication in my email.. I meant on cisco's website, they say it sucks up more memory on PE in their implementation. Other vendors does not claim this is an issue -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Thursday, October 17, 2002 5:46 AM To: Joe Lin Cc: 'Shiv Agarwal'; 'Rubens Gomes'; ppvpn@ppvpn.francetelecom.com Subject: Re: Route Distinguisher Id Joe, > In the operational sense: > > If you have unique RDs per VRF, it makes troubleshooting a lot easier > because you can make correlations easier. > > But unique RDs will suck up more memory on the PE, at least that's what > I gathered on cisco's website. While this may be correct for a particular vendor, do *not* assume that it is correct for other vendors. Yakov. > I don't have that particular URL anymore. but do a search on cisco's > site and you should find it > > -joe > > -----Original Message----- > From: ppvpn-owner@ppvpn.francetelecom.com > [mailto:ppvpn-owner@ppvpn.francetelecom.com] On Behalf Of Shiv Agarwal > Sent: Wednesday, October 16, 2002 5:00 PM > To: Rubens Gomes; ppvpn@ppvpn.francetelecom.com > Subject: RE: Route Distinguisher Id > > Rubens, > > Can you ensure that the address space of VRFs participating in a VPN > does not overlap? > If yes, then all VRFs in a VPN can be assigned the same RD. Also your > point of correlating RDs with VPNs may not hold good for VRFs > participating in multiple VPNs. Try to correlate VPNs using both RD and > RTs. > > Shiv. > > -----Original Message----- > From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] > Sent: Wednesday, October 16, 2002 12:39 PM > To: ppvpn@ppvpn.francetelecom.com > Subject: Route Distinguisher Id > > > My company (www.diveo.net.br) is getting ready to implement MPLS VPN in > its > IP backbone. Right > now, we are in the process of establishing conventions and strategies > to > name and identify things like > RDs, vrfNames, and such in the VPN VRFs. > > A question has been raised regarding the strategy to be used for the > RDs. > Should the RD be unique > per VPN? That is, within the same VPN, use the same RD in the different > > VRFs? Or should we use a > distinct RDs for each VRF in the network? From the perspective of > network > management it appears > to make sense to use the same RD in a VPN because that would facilitate > the > correlation of VPNs > with RDs. However, someone else here raised the possiblity of NOT > having > unique routes when the > same RD is used, and is aiming at unique RDs in the network. Here is > basically what this person has > raised: > > aim: make routes unique, distinguish between VRF on same PE > set: on the VRF and attached to all routes when redistributed into > MP-BGP > rule 1: no 2 VRFs on the same PE may have the same RD > rule 2: the combination of : (=VPNV4-address) needs to > be > unique in the provider network as BGP (MP-BGP) only forwards the best > route > (otherwise load-balance > won't happen on redundant links) > > > The bottonline: Should RDs be unique or not? > > Rubens S. Gomes > http://www.rubens-gomes.com > > > > > _________________________________________________________________ > Unlimited Internet access -- and 2 months free!  Try MSN. > http://resourcecenter.msn.com/access/plans/2monthsfree.asp > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 13:25:39 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18718 for ; Thu, 17 Oct 2002 13:25:38 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HHRCu07418 for ; Thu, 17 Oct 2002 13:27:12 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HHR9204004 for ; Thu, 17 Oct 2002 13:27:09 -0400 (EDT) Date: Thu, 17 Oct 2002 13:25:48 -0400 From: Ajay Simha To: Joe Lin Cc: "'Yakov Rekhter'" , "'Shiv Agarwal'" , "'Rubens Gomes'" , ppvpn@ppvpn.francetelecom.com Subject: Re: Route Distinguisher Id Message-ID: <20021017172548.GA450@cisco.com> References: <200210171245.g9HCjUm97476@merlot.juniper.net> <018601c275fb$1a612390$9800a8c0@kojak> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline In-Reply-To: <018601c275fb$1a612390$9800a8c0@kojak> User-Agent: Mutt/1.4i X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: asimha@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA18718 On Thu Oct 17 09:34:45 2002, Joe Lin wrote: > I apologize for my implication in my email.. > > I meant on cisco's website, they say it sucks up more memory on PE in > their implementation. > > Other vendors does not claim this is an issue If I'm not mistaken, Cisco's docs recommend not using unique RD per site(of the same VPN). Unique RD per VRF is still recommended and fine. -ajay > > > > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Thursday, October 17, 2002 5:46 AM > To: Joe Lin > Cc: 'Shiv Agarwal'; 'Rubens Gomes'; ppvpn@ppvpn.francetelecom.com > Subject: Re: Route Distinguisher Id > > Joe, > > > In the operational sense: > > > > If you have unique RDs per VRF, it makes troubleshooting a lot easier > > because you can make correlations easier. > > > > But unique RDs will suck up more memory on the PE, at least that's > what > > I gathered on cisco's website. > > While this may be correct for a particular vendor, do *not* assume that > it is correct for other vendors. > > Yakov. > > > I don't have that particular URL anymore. but do a search on cisco's > > site and you should find it > > > > > -joe > > > > -----Original Message----- > > From: ppvpn-owner@ppvpn.francetelecom.com > > [mailto:ppvpn-owner@ppvpn.francetelecom.com] On Behalf Of Shiv Agarwal > > Sent: Wednesday, October 16, 2002 5:00 PM > > To: Rubens Gomes; ppvpn@ppvpn.francetelecom.com > > Subject: RE: Route Distinguisher Id > > > > Rubens, > > > > Can you ensure that the address space of VRFs participating in a VPN > > does not overlap? > > If yes, then all VRFs in a VPN can be assigned the same RD. Also your > > point of correlating RDs with VPNs may not hold good for VRFs > > participating in multiple VPNs. Try to correlate VPNs using both RD > and > > RTs. > > > > Shiv. > > > > -----Original Message----- > > From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] > > Sent: Wednesday, October 16, 2002 12:39 PM > > To: ppvpn@ppvpn.francetelecom.com > > Subject: Route Distinguisher Id > > > > > > My company (www.diveo.net.br) is getting ready to implement MPLS VPN > in > > its > > IP backbone. Right > > now, we are in the process of establishing conventions and strategies > > to > > name and identify things like > > RDs, vrfNames, and such in the VPN VRFs. > > > > A question has been raised regarding the strategy to be used for the > > RDs. > > Should the RD be unique > > per VPN? That is, within the same VPN, use the same RD in the > different > > > > VRFs? Or should we use a > > distinct RDs for each VRF in the network? From the perspective of > > network > > management it appears > > to make sense to use the same RD in a VPN because that would > facilitate > > the > > correlation of VPNs > > with RDs. However, someone else here raised the possiblity of NOT > > having > > unique routes when the > > same RD is used, and is aiming at unique RDs in the network. Here is > > basically what this person has > > raised: > > > > aim: make routes unique, distinguish between VRF on same PE > > set: on the VRF and attached to all routes when redistributed into > > MP-BGP > > rule 1: no 2 VRFs on the same PE may have the same RD > > rule 2: the combination of : (=VPNV4-address) needs > to > > be > > unique in the provider network as BGP (MP-BGP) only forwards the best > > route > > (otherwise load-balance > > won't happen on redundant links) > > > > > > The bottonline: Should RDs be unique or not? > > > > Rubens S. Gomes > > http://www.rubens-gomes.com > > > > > > > > > > _________________________________________________________________ > > Unlimited Internet access -- and 2 months free!  Try MSN. > > http://resourcecenter.msn.com/access/plans/2monthsfree.asp > > > > > > > > > > > > > > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 13:35:29 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19100 for ; Thu, 17 Oct 2002 13:35:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HHb6u11789 for ; Thu, 17 Oct 2002 13:37:06 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HHb3213015 for ; Thu, 17 Oct 2002 13:37:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Route Distinguisher Id Date: Thu, 17 Oct 2002 10:34:29 -0700 Message-ID: Thread-Topic: Route Distinguisher Id Thread-Index: AcJ18NJjj0DlFv5zQE6Xg2ZyrBjC9gAEiaZQ From: "Shiv Agarwal" To: "Suryanarayana, Ananth" , X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: Shiv@coronanetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA19100 Ananth, 2547 says that ............. <----------------> 1.3. VPNs with Overlapping Address Spaces We assume that any two non-intersecting VPNs (i.e., VPNs with no sites in common) may have overlapping address spaces; the same address may be reused, for different systems, in different VPNs. As long as a given endsystem has an address which is unique within the scope of the VPNs that it belongs to, the endsystem itself does not need to know anything about VPNs. <----------------> In your case VPN1 and VPN2 are intersecting because the site CE3 is common to both VPNs. So your case is not valid. If you want to support this kind of scenario then you could define two VRFs at CE3, one participating in VPN1 and another in VPN2. Each of the 2 VRFs should have a different RD. For access side(CE), you may use 2 separate sub interfaces and map them to the 2 VRFs, one to each. Shiv. -----Original Message----- From: Suryanarayana, Ananth [mailto:ananth@celoxnetworks.com] Sent: Thursday, October 17, 2002 8:18 AM To: 'Rubens Gomes'; ppvpn@ppvpn.francetelecom.com Subject: RE: Route Distinguisher Id It seems, if RD is unique per VPN, then it logically correct as RD's purpose is after all to distinguish routes with same prefixes amogst different vpns. But, I am not sure how it can be implemented? for eg: consider the case in which three are three CE routers CE1(belonging to VPN1). CE2 (belonging to VPN2) and CE3 (belonging to both VPN1 and VPN2) attached to a single PE. A sample configuration for this would be having three VRFs as CE1---attached to VRF1 (Import RT 1:1 and 1:3, Export RT 1:1) RD 1:1 (Belongs to VPN1) CE2---attached to VRF2 (Import RT 1:2 and 1:3, Export RT 1:2) RD 1:2 (Belongs to VPN2) CE3---attached to VRF3 (Import RT 1:1 and 2:2, Export RT 1:3) RD 1:3 (?) (Belongs to both VPN1 and VPN2) Suppose, if both CE1 and CE3 send a VPN1 route 5.5.5.0/24 to the edge router PE with itself as the next-hops, then PE is suppose to select the best route among these routes. But since route from CE1 (attached ro VRF1) will have RD 1:1 which is different from that of route advertised from CE3 (Attached to VRF3, which will be 1:3), they will not be comparable. Now, in this case, if configurable RDs supported are only one per VRF, how can we ensure that route selection process is corectly made by making RD unique per VRF. If we want to make it unique per VPN, does it mean, multiple (default) RDs per VRF support is required? Thanks, Ananth -----Original Message----- From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] Sent: Wednesday, October 16, 2002 3:39 PM To: ppvpn@ppvpn.francetelecom.com Subject: Route Distinguisher Id My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its IP backbone. Right now, we are in the process of establishing conventions and strategies to name and identify things like RDs, vrfNames, and such in the VPN VRFs. A question has been raised regarding the strategy to be used for the RDs. Should the RD be unique per VPN? That is, within the same VPN, use the same RD in the different VRFs? Or should we use a distinct RDs for each VRF in the network? From the perspective of network management it appears to make sense to use the same RD in a VPN because that would facilitate the correlation of VPNs with RDs. However, someone else here raised the possiblity of NOT having unique routes when the same RD is used, and is aiming at unique RDs in the network. Here is basically what this person has raised: aim: make routes unique, distinguish between VRF on same PE set: on the VRF and attached to all routes when redistributed into MP-BGP rule 1: no 2 VRFs on the same PE may have the same RD rule 2: the combination of : (=VPNV4-address) needs to be unique in the provider network as BGP (MP-BGP) only forwards the best route (otherwise load-balance won't happen on redundant links) The bottonline: Should RDs be unique or not? Rubens S. Gomes http://www.rubens-gomes.com _________________________________________________________________ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 14:35:13 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21120 for ; Thu, 17 Oct 2002 14:35:12 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HIaou00806 for ; Thu, 17 Oct 2002 14:36:50 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HIal208757 for ; Thu, 17 Oct 2002 14:36:47 -0400 (EDT) Message-Id: <200210171836.g9HIa2G23534@ns2.elwaves.net.in> To: From: "PAULENE" Subject: Lowest rates in 32 years28128 Date: Thu, 17 Oct 2002 13:35:13 -0500 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Reply-To: aaronmood@ips.ras.ru X-Priority: 1 X-MSMail-Priority: High X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Sensitivity: Confidential X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 References: {]GqOOWMhYsg_^:S\[ccB{m`SdJ2RgTl`kn`DTRVRGX^RCEGreX=BLDE@QU9D Content-Transfer-Encoding: 7bit Note Dare to Compare! Do you have the LOWEST Mortgage rate available? * Compare our rates. * No obligation. * Search hundreds of lenders instantly. * Free qoutes. * ALL Credit Accepted. A,B and subprime! One thing we all know, rates won't stay this low forever. Search now: http://25555@aol.trodg.com Unlist; http://25846@aol.trodg.com/remove From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 14:38:38 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21863 for ; Thu, 17 Oct 2002 14:38:38 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HIeBu02836 for ; Thu, 17 Oct 2002 14:40:11 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HIe9214861 for ; Thu, 17 Oct 2002 14:40:09 -0400 (EDT) Message-ID: <1117F7D44159934FB116E36F4ABF221B020B0EF8@celox-ma1-ems1.celoxnetworks.com> From: "Suryanarayana, Ananth" To: "'Shiv Agarwal'" , "Suryanarayana, Ananth" , ppvpn@ppvpn.francetelecom.com Subject: RE: Route Distinguisher Id Date: Thu, 17 Oct 2002 14:39:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: ananth@celoxnetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Does it mean, in this case, if the CE is running BGP for exchanging routes at CE, then there must be one BGP session per vpn that it belongs to ? Also, it requires one connection per vpn between CE and PE? I was thinking that, all the configurations are managed within the PE by using VRFs, RDs and Route targets where as, a CE routes is associated with just one vrf over one interface and they just have to "mention" the vpns they wish to belong to. From the cisco book "MPLS and VPN Architectures: Page 154, Note), I read "All sites that share the same routing information (usually it means that they belong to the same set of vpns) that are allowed to communicate directly with each other, and that are connected to the same PE router can be placed in a common VRF. If I apply to this example, there is only one site C3, that belongs to the set of VPNS VPN1 and VPN2 and hence C3 can be placed in a common single VRF. Isn;t it? thanks Ananth -----Original Message----- From: Shiv Agarwal [mailto:Shiv@coronanetworks.com] Sent: Thursday, October 17, 2002 1:34 PM To: Suryanarayana, Ananth; ppvpn@ppvpn.francetelecom.com Subject: RE: Route Distinguisher Id Ananth, 2547 says that ............. <----------------> 1.3. VPNs with Overlapping Address Spaces We assume that any two non-intersecting VPNs (i.e., VPNs with no sites in common) may have overlapping address spaces; the same address may be reused, for different systems, in different VPNs. As long as a given endsystem has an address which is unique within the scope of the VPNs that it belongs to, the endsystem itself does not need to know anything about VPNs. <----------------> In your case VPN1 and VPN2 are intersecting because the site CE3 is common to both VPNs. So your case is not valid. If you want to support this kind of scenario then you could define two VRFs at CE3, one participating in VPN1 and another in VPN2. Each of the 2 VRFs should have a different RD. For access side(CE), you may use 2 separate sub interfaces and map them to the 2 VRFs, one to each. Shiv. -----Original Message----- From: Suryanarayana, Ananth [mailto:ananth@celoxnetworks.com] Sent: Thursday, October 17, 2002 8:18 AM To: 'Rubens Gomes'; ppvpn@ppvpn.francetelecom.com Subject: RE: Route Distinguisher Id It seems, if RD is unique per VPN, then it logically correct as RD's purpose is after all to distinguish routes with same prefixes amogst different vpns. But, I am not sure how it can be implemented? for eg: consider the case in which three are three CE routers CE1(belonging to VPN1). CE2 (belonging to VPN2) and CE3 (belonging to both VPN1 and VPN2) attached to a single PE. A sample configuration for this would be having three VRFs as CE1---attached to VRF1 (Import RT 1:1 and 1:3, Export RT 1:1) RD 1:1 (Belongs to VPN1) CE2---attached to VRF2 (Import RT 1:2 and 1:3, Export RT 1:2) RD 1:2 (Belongs to VPN2) CE3---attached to VRF3 (Import RT 1:1 and 2:2, Export RT 1:3) RD 1:3 (?) (Belongs to both VPN1 and VPN2) Suppose, if both CE1 and CE3 send a VPN1 route 5.5.5.0/24 to the edge router PE with itself as the next-hops, then PE is suppose to select the best route among these routes. But since route from CE1 (attached ro VRF1) will have RD 1:1 which is different from that of route advertised from CE3 (Attached to VRF3, which will be 1:3), they will not be comparable. Now, in this case, if configurable RDs supported are only one per VRF, how can we ensure that route selection process is corectly made by making RD unique per VRF. If we want to make it unique per VPN, does it mean, multiple (default) RDs per VRF support is required? Thanks, Ananth -----Original Message----- From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] Sent: Wednesday, October 16, 2002 3:39 PM To: ppvpn@ppvpn.francetelecom.com Subject: Route Distinguisher Id My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its IP backbone. Right now, we are in the process of establishing conventions and strategies to name and identify things like RDs, vrfNames, and such in the VPN VRFs. A question has been raised regarding the strategy to be used for the RDs. Should the RD be unique per VPN? That is, within the same VPN, use the same RD in the different VRFs? Or should we use a distinct RDs for each VRF in the network? From the perspective of network management it appears to make sense to use the same RD in a VPN because that would facilitate the correlation of VPNs with RDs. However, someone else here raised the possiblity of NOT having unique routes when the same RD is used, and is aiming at unique RDs in the network. Here is basically what this person has raised: aim: make routes unique, distinguish between VRF on same PE set: on the VRF and attached to all routes when redistributed into MP-BGP rule 1: no 2 VRFs on the same PE may have the same RD rule 2: the combination of : (=VPNV4-address) needs to be unique in the provider network as BGP (MP-BGP) only forwards the best route (otherwise load-balance won't happen on redundant links) The bottonline: Should RDs be unique or not? Rubens S. Gomes http://www.rubens-gomes.com _________________________________________________________________ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 17 14:54:42 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22542 for ; Thu, 17 Oct 2002 14:54:42 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HIuJu11212 for ; Thu, 17 Oct 2002 14:56:19 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9HIuG205363 for ; Thu, 17 Oct 2002 14:56:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Route Distinguisher Id Date: Thu, 17 Oct 2002 11:53:26 -0700 Message-ID: Thread-Topic: Route Distinguisher Id Thread-Index: AcJ2DEXD8vgreJjeQeWkTa43zIrZMwAAPtNQ From: "Shiv Agarwal" To: "Suryanarayana, Ananth" , X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: Shiv@coronanetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA22542 Ananth, inline>>>> Shiv. -----Original Message----- From: Suryanarayana, Ananth [mailto:ananth@celoxnetworks.com] Sent: Thursday, October 17, 2002 11:40 AM To: Shiv Agarwal; Suryanarayana, Ananth; ppvpn@ppvpn.francetelecom.com Subject: RE: Route Distinguisher Id Does it mean, in this case, if the CE is running BGP for exchanging routes at CE, then there must be one BGP session per vpn that it belongs to ? Shiv>>> that depends on the implementation. Also, it requires one connection per vpn between CE and PE? I was thinking that, all the configurations are managed within the PE by using VRFs, RDs and Route targets where as, a CE routes is associated with just one vrf over one interface and they just have to "mention" the vpns they wish to belong to. From the cisco book "MPLS and VPN Architectures: Page 154, Note), I read "All sites that share the same routing information (usually it means that they belong to the same set of vpns) that are allowed to communicate directly with each other, and that are connected to the same PE router can be placed in a common VRF. Shiv>>> where does it say that these common sites can have overlapping IP Addresses?? If I apply to this example, there is only one site C3, that belongs to the set of VPNS VPN1 and VPN2 and hence C3 can be placed in a common single VRF. Isn;t it? Shiv>>> only if the VPNs have non overlapping ip address space. thanks Ananth -----Original Message----- From: Shiv Agarwal [mailto:Shiv@coronanetworks.com] Sent: Thursday, October 17, 2002 1:34 PM To: Suryanarayana, Ananth; ppvpn@ppvpn.francetelecom.com Subject: RE: Route Distinguisher Id Ananth, 2547 says that ............. <----------------> 1.3. VPNs with Overlapping Address Spaces We assume that any two non-intersecting VPNs (i.e., VPNs with no sites in common) may have overlapping address spaces; the same address may be reused, for different systems, in different VPNs. As long as a given endsystem has an address which is unique within the scope of the VPNs that it belongs to, the endsystem itself does not need to know anything about VPNs. <----------------> In your case VPN1 and VPN2 are intersecting because the site CE3 is common to both VPNs. So your case is not valid. If you want to support this kind of scenario then you could define two VRFs at CE3, one participating in VPN1 and another in VPN2. Each of the 2 VRFs should have a different RD. For access side(CE), you may use 2 separate sub interfaces and map them to the 2 VRFs, one to each. Shiv. -----Original Message----- From: Suryanarayana, Ananth [mailto:ananth@celoxnetworks.com] Sent: Thursday, October 17, 2002 8:18 AM To: 'Rubens Gomes'; ppvpn@ppvpn.francetelecom.com Subject: RE: Route Distinguisher Id It seems, if RD is unique per VPN, then it logically correct as RD's purpose is after all to distinguish routes with same prefixes amogst different vpns. But, I am not sure how it can be implemented? for eg: consider the case in which three are three CE routers CE1(belonging to VPN1). CE2 (belonging to VPN2) and CE3 (belonging to both VPN1 and VPN2) attached to a single PE. A sample configuration for this would be having three VRFs as CE1---attached to VRF1 (Import RT 1:1 and 1:3, Export RT 1:1) RD 1:1 (Belongs to VPN1) CE2---attached to VRF2 (Import RT 1:2 and 1:3, Export RT 1:2) RD 1:2 (Belongs to VPN2) CE3---attached to VRF3 (Import RT 1:1 and 2:2, Export RT 1:3) RD 1:3 (?) (Belongs to both VPN1 and VPN2) Suppose, if both CE1 and CE3 send a VPN1 route 5.5.5.0/24 to the edge router PE with itself as the next-hops, then PE is suppose to select the best route among these routes. But since route from CE1 (attached ro VRF1) will have RD 1:1 which is different from that of route advertised from CE3 (Attached to VRF3, which will be 1:3), they will not be comparable. Now, in this case, if configurable RDs supported are only one per VRF, how can we ensure that route selection process is corectly made by making RD unique per VRF. If we want to make it unique per VPN, does it mean, multiple (default) RDs per VRF support is required? Thanks, Ananth -----Original Message----- From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] Sent: Wednesday, October 16, 2002 3:39 PM To: ppvpn@ppvpn.francetelecom.com Subject: Route Distinguisher Id My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its IP backbone. Right now, we are in the process of establishing conventions and strategies to name and identify things like RDs, vrfNames, and such in the VPN VRFs. A question has been raised regarding the strategy to be used for the RDs. Should the RD be unique per VPN? That is, within the same VPN, use the same RD in the different VRFs? Or should we use a distinct RDs for each VRF in the network? From the perspective of network management it appears to make sense to use the same RD in a VPN because that would facilitate the correlation of VPNs with RDs. However, someone else here raised the possiblity of NOT having unique routes when the same RD is used, and is aiming at unique RDs in the network. Here is basically what this person has raised: aim: make routes unique, distinguish between VRF on same PE set: on the VRF and attached to all routes when redistributed into MP-BGP rule 1: no 2 VRFs on the same PE may have the same RD rule 2: the combination of : (=VPNV4-address) needs to be unique in the provider network as BGP (MP-BGP) only forwards the best route (otherwise load-balance won't happen on redundant links) The bottonline: Should RDs be unique or not? Rubens S. Gomes http://www.rubens-gomes.com _________________________________________________________________ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Oct 18 09:41:26 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25934 for ; Fri, 18 Oct 2002 09:41:26 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9IDgtB18890 for ; Fri, 18 Oct 2002 09:42:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9IDgqT24557 for ; Fri, 18 Oct 2002 09:42:52 -0400 (EDT) Message-ID: <3DB00F9B.6050104@research.att.com> Date: Fri, 18 Oct 2002 09:41:47 -0400 From: Chris Chase User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Suryanarayana, Ananth" Cc: "'Shiv Agarwal'" , ppvpn@ppvpn.francetelecom.com Subject: Re: Route Distinguisher Id References: <1117F7D44159934FB116E36F4ABF221B020B0EF8@celox-ma1-ems1.celoxnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: chase@research.att.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Forget vrfs, RDs, RTs for a moment. (1) You apparently want CE1 and CE3 to present the same prefix, 5.5.5.0/24, to other sites (i.e., CE2), even though prefixes represent different networks (different end systems)? Then you as a customer/user have a very ill-defined network and violate a fundamental principle of IP routing that you must be able to disambiguiate end system addresses that share a common reachability space. There is no VPN or toplological magic solution here. You have to use address translation (NAT). It is the standard solution for extranets and private intranets which merge networks with incompatible addresses. (2) If, on the other hand, what you are suggesting is that only CE1 be able to present 5.5.5.0/24 to CE2 then you need to remove the CE3 prefix. The solution mentioned below would put it in a separate vrf or you could filter it out. (3) The 5.5.5.0/24 prefix from CE1 and CE3 represents the same end systems. Perhaps CE1 and CE3 have backdoor connectivity. We have customers who distribute their data centers geographically and then have a high speed interconnect, e.g., a metro fiber ring. They will advertise the same prefix from both sites. If eqaul cost then we load balance. Or they can advertise them in a preferred way so one operates as primary and the other as backup. The concept of overlapping VPNs is ill-defined. Mainly because the definition of a VPN is ill-defined and the definition of a "site" in the draft is ill-defined (should have stuck to just defining interfaces on vrfs). Chris Chase AT&T Labs Research Suryanarayana, Ananth wrote: >Does it mean, in this case, if the CE is running BGP for exchanging routes >at CE, then there must be one BGP session per vpn that it belongs to ? >Also, it requires one connection per vpn between CE and PE? I was thinking >that, all the configurations are managed within the PE by using VRFs, RDs >and Route targets where as, a CE routes is associated with just one vrf over >one interface and they just have to "mention" the vpns they wish to belong >to. > >From the cisco book "MPLS and VPN Architectures: Page 154, Note), I read >"All sites that share the same routing information (usually it means that >they belong to the same set of vpns) that are allowed to communicate >directly with each other, and that are connected to the same PE router can >be placed in a common VRF. > >If I apply to this example, there is only one site C3, that belongs to the >set of VPNS VPN1 and VPN2 and hence C3 can be placed in a common single VRF. >Isn;t it? > > >thanks > >Ananth > >-----Original Message----- >From: Shiv Agarwal [mailto:Shiv@coronanetworks.com] >Sent: Thursday, October 17, 2002 1:34 PM >To: Suryanarayana, Ananth; ppvpn@ppvpn.francetelecom.com >Subject: RE: Route Distinguisher Id > > >Ananth, > >2547 says that ............. ><----------------> >1.3. VPNs with Overlapping Address Spaces > > We assume that any two non-intersecting VPNs (i.e., VPNs with no > sites in common) may have overlapping address spaces; the same > address may be reused, for different systems, in different VPNs. As > long as a given endsystem has an address which is unique within the > scope of the VPNs that it belongs to, the endsystem itself does not > need to know anything about VPNs. ><----------------> >In your case VPN1 and VPN2 are intersecting because the site CE3 is common >to both VPNs. So your case is not valid. If you want to support this kind of >scenario then you could define two VRFs at CE3, one participating in VPN1 >and another in VPN2. Each of the 2 VRFs should have a different RD. For >access side(CE), you may use 2 separate sub interfaces and map them to the 2 >VRFs, one to each. > >Shiv. > >-----Original Message----- >From: Suryanarayana, Ananth [mailto:ananth@celoxnetworks.com] >Sent: Thursday, October 17, 2002 8:18 AM >To: 'Rubens Gomes'; ppvpn@ppvpn.francetelecom.com >Subject: RE: Route Distinguisher Id > > >It seems, if RD is unique per VPN, then it logically correct as RD's purpose >is after all to distinguish routes with same prefixes amogst different vpns. >But, I am not sure how it can be implemented? > >for eg: consider the case in which three are three CE routers CE1(belonging >to VPN1). CE2 (belonging to VPN2) and CE3 (belonging to both VPN1 and VPN2) >attached to a single PE. > >A sample configuration for this would be having three VRFs as > >CE1---attached to VRF1 (Import RT 1:1 and 1:3, Export RT 1:1) RD 1:1 >(Belongs to VPN1) >CE2---attached to VRF2 (Import RT 1:2 and 1:3, Export RT 1:2) RD 1:2 >(Belongs to VPN2) >CE3---attached to VRF3 (Import RT 1:1 and 2:2, Export RT 1:3) RD 1:3 (?) >(Belongs to both VPN1 and VPN2) > >Suppose, if both CE1 and CE3 send a VPN1 route 5.5.5.0/24 to the edge router >PE with itself as the next-hops, then PE is suppose to select the best route >among these routes. But since route from CE1 (attached ro VRF1) will have RD >1:1 which is different from that of route advertised from CE3 (Attached to >VRF3, which will be 1:3), they will not be comparable. > >Now, in this case, if configurable RDs supported are only one per VRF, how >can we ensure that route selection process is corectly made by making RD >unique per VRF. If we want to make it unique per VPN, does it mean, multiple >(default) RDs per VRF support is required? > > >Thanks, > >Ananth > >-----Original Message----- >From: Rubens Gomes [mailto:rubens_gomes@hotmail.com] >Sent: Wednesday, October 16, 2002 3:39 PM >To: ppvpn@ppvpn.francetelecom.com >Subject: Route Distinguisher Id > > >My company (www.diveo.net.br) is getting ready to implement MPLS VPN in its >IP backbone. Right >now, we are in the process of establishing conventions and strategies to >name and identify things like >RDs, vrfNames, and such in the VPN VRFs. > >A question has been raised regarding the strategy to be used for the RDs. >Should the RD be unique >per VPN? That is, within the same VPN, use the same RD in the different >VRFs? Or should we use a >distinct RDs for each VRF in the network? From the perspective of network >management it appears >to make sense to use the same RD in a VPN because that would facilitate the > >correlation of VPNs >with RDs. However, someone else here raised the possiblity of NOT having >unique routes when the >same RD is used, and is aiming at unique RDs in the network. Here is >basically what this person has >raised: > >aim: make routes unique, distinguish between VRF on same PE >set: on the VRF and attached to all routes when redistributed into MP-BGP >rule 1: no 2 VRFs on the same PE may have the same RD >rule 2: the combination of : (=VPNV4-address) needs to be >unique in the provider network as BGP (MP-BGP) only forwards the best route >(otherwise load-balance >won't happen on redundant links) > > >The bottonline: Should RDs be unique or not? > >Rubens S. Gomes >http://www.rubens-gomes.com > > > > >_________________________________________________________________ >Unlimited Internet access -- and 2 months free! Try MSN. >http://resourcecenter.msn.com/access/plans/2monthsfree.asp > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Oct 18 11:33:40 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00743 for ; Fri, 18 Oct 2002 11:33:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9IFZHB11206 for ; Fri, 18 Oct 2002 11:35:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9IFZDT14429 for ; Fri, 18 Oct 2002 11:35:14 -0400 (EDT) Date: Fri, 18 Oct 2002 11:34:01 -0400 (EDT) From: Westcoastchamber Westcoastchambers To: westcoastchamber.wes@lycos.co.uk Message-ID: <1034955235031063@lycos.co.uk> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [216.139.169.150] Mime-Version: 1.0 Subject: Soliciting Your Attention Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0310631034955235_ID" X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: westcoastchamber.wes@lycos.co.uk X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0310631034955235_ID Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit West Coast Chamber 21st Avenue Abidjan Cote'd' Iviore alternative email:barrister.yahere@law.com Attention, We the above named law firm would like to solicit your assistance in a highly confidential business proposal involving a very well known Senegalese family whose name will be made known to you at the commencement of this business. Our client is in dire need of a foreign partner whose task is to assist in receiving forex, which runs into several millions of dollars. This quest stemmed from the fact that the head of the family is presently incapacitated politically. Several attempts by this notable family to move the said funds outside the shores of the country for safe custody failed hence their resolve to engage our services. However, being the attorney to this embattled family, we are presently saddled with the responsibility of securing and negotiating a safe passage for these funds via Europe with a willing and trustworthy foreign partner. Modalities on how the said funds will be moved have been worked out and will be made known to you as soon as we receive an affirmative acknowledgement of this fax. We count on your maturity and sincerity with the hope and belief that once these funds are placed in your custody, there should be nothing to worry about. Please be informed that this family is ready to release 10% of the fund to you on successful completion of this business. Yours Faithfully, Barrister Yemego Conde(SAS.Llb.hons.BA Admin.) Principal counsel ______________________________________________________ Check out all the latest outrageous email attachments on the Outrageous Email Chart! - http://viral.lycos.co.uk --=_NextPart_Caramail_0310631034955235_ID-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Oct 18 14:28:21 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05991 for ; Fri, 18 Oct 2002 14:28:20 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9IITuB07181 for ; Fri, 18 Oct 2002 14:29:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9IITrT19374 for ; Fri, 18 Oct 2002 14:29:53 -0400 (EDT) Date: Fri, 18 Oct 2002 14:29:20 -0400 (EDT) Reply-To: Message-ID: <000d66e21eca$4338d5c8$1cb54ad4@lnblnf> From: To: mia4@jubiipost.dk Subject: FORTUNE 500 COMPANY HELPS YOU WORK FROM HOME! MiME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Internet Mail Service (5.5.2650.21) Importance: Normal X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: bizman23@raakim.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Fortune 500 company is recruiting thousands in work at home program! No experience required! For free information: http://www.rollingwebs.com/wealthathome This is the program you have heard about! Nothing like it anywhere! http://www.rollingwebs.com/wealthathome To be removed go to: http://www.rollingwebs.com/wealthathome/remove.html 4945l4 From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Oct 20 18:49:11 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04134 for ; Sun, 20 Oct 2002 18:49:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9KMoaB25617 for ; Sun, 20 Oct 2002 18:50:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9KMoYT11232 for ; Sun, 20 Oct 2002 18:50:34 -0400 (EDT) Message-ID: <3db333193db32874@hermes1.fth.net> (added by hermes1.fth.net) From: "JACKSON MOYO" Date: Mon, 21 Oct 2002 00:49:49 To: ppvpn@ppvpn.francetelecom.com Subject: IT IS IMPORTANT I GET YOUR RESPONSE. MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: moyo@loadmail.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit FROM: JACKSON MOYO. FAX: +31-619-104-918. TEL: +31-629-238-054. Please reply to:E-mail:jmoyo@37.com Complements of the day.Grace, Peace and love to you. I hope my letter does not cause you too much embarrassment as I write to you in good faith. Please excuse my intrusion into you business life. My name is Jackson Moyo, the elder son of Mr.Dennnis Moyo from the Republic of Zimbabwe. During the current war against the farmers in Zimbabwe from the supporters of President Robert Mugabe,in his effort to chase all the white farmers out of the country, he ordered all the white farmers to surrender their farms to his party members and his Followers. My father was one of the most successful farmer in my country, but he did not support the idea of dispossessing the white farmers of their land. Because of this, his farm was invaded and burnt by government supporters. In the course of the attack, my father was killed, and the invaders made away with a lot of items from my Father?s farm. And our family house was utterly destroyed. My mother died too out of heart attack. Before the death of my father, he drew my attention to the sum of US$10MILLION, Which he deposited with a Security Company in Amsterdam when the crisis was coming up. My sister and I decided to move out of Zimbabwe for our own security, because our lives were in danger. We decided to move to the Amsterdam, The Netherlands where my father deposited this money. Till date, the security company is not aware of the content of the consignment because my father used his diplomatic immunity as at that time to deposit the consignment as important personal valuables.I decided to have contact with overseas person/firm who will assist me to move the money out of Amsterdam. This becomes necessary because as political asylum seekers, we are not allowed to own or operate a bank account. If you accept this proposal, you shall receive 20% of the entire amount for assisting us to move this money out, 75% of this amount shall be for us, and the remaining 5% shall be mapped out for expenses incurred in the course of the transaction. I want you to immediately confirm your interest in the project via my fax number, as soon as I get your response, I will give you more details on how we can proceed. Thanks for your anticipated cooperation. I await your Urgent response Best regards, JACKSON MOYO From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Oct 21 00:52:50 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08911 for ; Mon, 21 Oct 2002 00:52:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9L4sUi27048 for ; Mon, 21 Oct 2002 00:54:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9L4sRl28463 for ; Mon, 21 Oct 2002 00:54:27 -0400 (EDT) Date: Mon, 21 Oct 2002 10:26:40 +0530 Date: Mon, 21 Oct 2002 10:29:38 +0530 X-Originating-IP: 10.3.0.2 X-Auth-User: pjoshi@mahindrabt.com Message-ID: <008101c278be$a8b8d500$ad08030a@mahindrabt.com> From: "Priya Joshi" To: Subject: Request to Join the PPVPN Mailing list. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: chandgate2.mahindrabt.com X-SMTP-MAIL-FROM: pjoshi@mahindrabt.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [203.124.156.99] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Oct 21 04:34:16 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21537 for ; Mon, 21 Oct 2002 04:34:15 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9L8Zvi19729 for ; Mon, 21 Oct 2002 04:35:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9L8Zsl04189 for ; Mon, 21 Oct 2002 04:35:54 -0400 (EDT) Date: Mon, 21 Oct 2002 16:35:44 +0800 From: lidefeng Subject: About draft-martini-ethernet-encap-mpls-01.txt To: luca@level3.net, nna@level3.net, giles@packetexchange.net, tappan@cisco.com, erosen@cisco.com, sjv@laurelnetworks.com, Andy.Malis@vivacenetworks.com, sirkay@technologist.com, "Vasile Radoaca" , chris@cw.net, kireeti@juniper.net, xipeng@redback.com, chris_flores@hotmail.com, davidz@corrigent.com, raj@luminous.com, nick@timetra.com, sunil@timetra.com, loa.andersson@utfors.se Cc: ppvpn@ppvpn.francetelecom.com Message-id: <002a01c278dc$d9cb1ae0$22436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,all, I have studied "draft-martini-ethernet-encap-mpls-01.txt",and in "Figure 4 : Configuration Options" of section "Appendix A - Interoperability Guidelines",there is an item "Encap on C " which specifies an reference point in "Figure 3: PW reference diagram",while in Figure 3: PW reference diagram,there is no any reference point C,there are only reference point A and reference point B. I think it is ommited without intent.Could you please tell me where is the reference point C in Figure 3: PW reference diagram.it will be appreciable if you can send me the whole revised draft in your responding e-mail. Best Wishes! Defeng Li From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Oct 21 14:05:58 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08728 for ; Mon, 21 Oct 2002 14:05:58 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9LI7bC01325 for ; Mon, 21 Oct 2002 14:07:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9LI7Yl02104 for ; Mon, 21 Oct 2002 14:07:35 -0400 (EDT) Message-ID: <3db4422a3db41b5c@hermes1.fth.net> (added by hermes1.fth.net) From: "WALL STREET BULLETIN..47611" To: Subscriber.Acct.#99240@zcars0jk.ca.nortel.com Subject: New Stock Pick: NNCO UP 112%.................................................. hnhbs Sender: "WALL STREET BULLETIN..47611" Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 21 Oct 2002 13:09:03 -0500 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Priority: 1 X-SMTP-HELO: hermes1.fth.net X-SMTP-MAIL-FROM: Subscriber_Services78056@cac.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: hermes1.pl.fth.net [193.252.69.31] X-LYRIS-Message-Id:

NEW ISSUE - Volume 6, Issue 37 - October 2002

CLICK HERE

 

 

I no longer wish to receive your newsletter click here

uukpifddfqbiaqacqw From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 22 07:40:50 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12239 for ; Tue, 22 Oct 2002 07:40:50 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9MBgR415603 for ; Tue, 22 Oct 2002 07:42:27 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9MBgO018260 for ; Tue, 22 Oct 2002 07:42:25 -0400 (EDT) Message-Id: <200210221139.HAA11877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ppvpn@lyris.nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-duffy-ppvpn-ipsec-vlink-00.txt Date: Tue, 22 Oct 2002 07:39:25 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework for IPsec Protected Virtual Links for PPVPNs Author(s) : M. Duffy Filename : draft-duffy-ppvpn-ipsec-vlink-00.txt Pages : 15 Date : 2002-10-21 This memo explores some choices that arise when IPsec is to be used to implement secure 'virtual links' interconnecting customer premises VPN devices and/or network based virtual routers. The main focus is on the network based cases. Requirements are proposed and some relevant aspects of the IPsec protocol suite are discussed. A number of different protocol architectures for virtual links are then evaluated. This memo is informational in nature; it is intended that it will focus discussion toward a standard in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-duffy-ppvpn-ipsec-vlink-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-duffy-ppvpn-ipsec-vlink-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-duffy-ppvpn-ipsec-vlink-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. --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: <2002-10-21143059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-duffy-ppvpn-ipsec-vlink-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-duffy-ppvpn-ipsec-vlink-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-21143059.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 22 12:02:02 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23883 for ; Tue, 22 Oct 2002 12:02:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9MG3W428100 for ; Tue, 22 Oct 2002 12:03:32 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9MG3T019545 for ; Tue, 22 Oct 2002 12:03:29 -0400 (EDT) Message-ID: From: "Hu, Cheng-Hong" To: ppvpn@lyris.nortelnetworks.com Subject: L2 over GRE Date: Tue, 22 Oct 2002 09:02:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: chu@tri.sbc.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: Hi, All: Do you have information on standard work for L2VPN over GRE? Are there any IDs specifically talking about L2 over GRE? Thanks! Cheng-hong Hu Architecture SBC Technology Resources 4698 Willow Road Pleasanton, CA 94588 Phone: 925-598-1228 From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 22 12:10:09 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24193 for ; Tue, 22 Oct 2002 12:10:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9MGBa403045 for ; Tue, 22 Oct 2002 12:11:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9MGBX023773 for ; Tue, 22 Oct 2002 12:11:33 -0400 (EDT) Message-ID: From: "Hu, Cheng-Hong" To: "'Priya Joshi'" , ppvpn@lyris.nortelnetworks.com Subject: RE: Request to Join the PPVPN Mailing list. Date: Tue, 22 Oct 2002 09:10:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: chu@tri.sbc.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: Dear Sir: I'd like to join PPVPN working group. My email address is chu@tri.sbc.com Thanks! Cheng-hong Hu Architecture SBC Technology Resources 4698 Willow Road Pleasanton, CA 94588 Phone: 925-598-1228 -----Original Message----- From: Priya Joshi [mailto:pjoshi@mahindrabt.com] Sent: Sunday, October 20, 2002 10:00 PM To: ppvpn@lyris.nortelnetworks.com Subject: Request to Join the PPVPN Mailing list. ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 22 21:07:15 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09981 for ; Tue, 22 Oct 2002 21:07:15 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9N18r408010 for ; Tue, 22 Oct 2002 21:08:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9N18n027590 for ; Tue, 22 Oct 2002 21:08:50 -0400 (EDT) Reply-To: From: "asodder" To: Cc: Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Tue, 22 Oct 2002 21:00:54 -0400 Message-ID: <00fb01c27a2f$a65e3a80$d303a8c0@tenornet.com> 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 CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200210171320.g9HDKjIm009191@sj-msg-core-1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: tenornetworks.com X-SMTP-MAIL-FROM: asodder@tenornetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtu.tenornetworks.com [63.77.213.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, I agree that initially I have been assuming that the ethernet-over-IP/MPLS service begins after the MAC-in-MAC encaps has been done, and ends before the corresponding decaps has been done. I think I may need to explain the control plane much more. VHLS does not need a per LAN segment VC label to be signaled, since the VC is only used to demux VHLS data from other PWE3 point-to-point traffic. Thus a single VC is signaled and the VHLS VPN identifier is used to demux the data at the receiving PE. This is not the same as VPLS which requires multiple VC labels to be signaled since the VC label is used to determine which VPN the frame belongs to and also which PE device the frame was received from. I'm very interested in your last statement which implies that if the service begins before the MAC-in-MAC encaps is done then the standardization effort belongs in the PWE3 working group. Could you please elaborate. Thanks, Arnold -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Thursday, October 17, 2002 9:21 AM To: asodder@tenornetworks.com Cc: ppvpn@lyris.nortelnetworks.com Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Arnold> You mentioned that this is a PWE3 issue, however I was under the Arnold> (maybe incorrect) assumption that the outer mac frame follows the Arnold> rules as specified in the PWE3 draft for ethernet-over-IP/MPLS. If Arnold> this is incorrect do let me know. The inner mac frame is different Arnold> but should be transported as data in the outer mac frame. If you want to argue that the ethernet-over-IP/MPLS service begins after the MAC-in-MAC encaps has been done, and ends before the corresponding decaps has been done, then you could argue that the rules for the MAC-in-MAC encaps are outside PWE3's scope. The rules for MAC-in-MAC encapsulation would then be totally outside the scope of the IETF, I believe, as there is no IP or MPLS involved. The proposal would have to be taken to IEEE. This might be a good way to approach it, as the hierarchy would then be done in the layer 2 network using layer 2 techniques, and in the MPLS/IP layer one can just do "ordinary" VPLS without need for further hierarchy. If on the other hand you want to argue that the ethernet-over-IP/MPLS service begins before the MAC-in-MAC encaps is done, and ends after the decaps is done, then it would have to be considered part of the IP/MPLS encapsulation and would fall under PWE3. From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 23 02:03:21 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18301 for ; Wed, 23 Oct 2002 02:03:20 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9N651r06190 for ; Wed, 23 Oct 2002 02:05:01 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9N64wK07965 for ; Wed, 23 Oct 2002 02:04:59 -0400 (EDT) Date: Wed, 23 Oct 2002 15:02:16 +0900 From: Masato Ando To: ppvpn@lyris.nortelnetworks.com Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Message-Id: <20021023145907.B355.MASATY@tec.poweredcom.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.08 X-SMTP-HELO: mx0.sd.ttnet.ad.jp X-SMTP-MAIL-FROM: masaty@tec.poweredcom.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [210.224.142.130] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Sodder (1)VHLS Draft say >L2PE devices are assigned a single MAC address. When an L2PE device >has two uplinks to different PE devices the same MAC address is used In my opinion, L2PE devices can be assigned one or more configurable addresses. This allows you to assign different MAC addresses on each downlink port on L2PE devices. You can use this type of assignment to control traffic by MAC address filtering. For example, it is supposed that you build a nationwide IX by L2 network and the IX supports two services, regional exchange and nationwide exchange. You can provide this service by L2PE MAC address filtering with MAC addresses on downlink port. Tier1 Tier1 ISP(A)--+ .......... ........ .......... +--ISP(C) L2PE---.Regional.---MAC---.nation. ---MAC---.Regional.--L2PE Tier2 | . bb(X) . Filter . bb . Filter . bb(Y) . | Tier2 ISP(B)--+ .......... ........ .......... +--ISP(D) *Tier1 ISPs MAC frame can pass MAC Filter. *Tier2 ISPs MAC frame cannot pass MAC Filter. PSTN(iSCSI, etc)-GW service is other example. This requires location base access control and MAC address filtering is also useful for this. (2) About hierachical MAC assignment. I support your idea about L2PE MAC. The other advantage on L2PE MAC is capability of hierarchical MAC assignment. West coast switchs L2PE MAC address=(aa:aa:**:**:**) San Francisco area switches L2PE MAC address=(aa:aa:aa:**:**) area 1 switches L2PE MAC address=(aa:aa:aa:aa:**) area 2 switches L2PE MAC address=(aa:aa:aa:bb:**) Los Angeles ara switches L2PE MAC address=(aa:aa:bb:**:**) East coast switches L2PE MAC address=(bb:bb:**:**:**) New York area switches L2PE MAC address=(bb:bb:aa:**:**) You can use MAC address filtering with a mask for avoiding loop traffic. You can use aggregate MAC bridging also. (3)I have same idea as VHLS. I call this technology "Ethernet over Ethernet(EoE)" or "Mac on mac". I made a similar presentation to the JANOG10 in Tokyo on this July 2002. You can get the presentation form http://www.janog.gr.jp/meeting/janog10/pdf/janog10-l2-ando.pdf It is written in Japanese, but you can understand page 16,17 figure. I have another detail documentation written in Japanese. If you want I will transrate the document to English and send it to you. I want to contribute your draft. (4) I belong to one of the largest nation wide ethernet VPN provider in Japan. In our company, we are using QinQ(VMAN) technology. Im looking for new solution for next generation network to solve some problems. I like VPLS.But I dont want to use VPLS. Because it has full mesh LSP broadcast problem which wastes backbone capacity. ("H"VPLS is not perfect solution, core needs full mesh LSP anyway) The point of broadcast capability, I think your idea is superior to VPLS. -- Masato Ando 03-4431-6630 From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 23 10:06:31 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00304 for ; Wed, 23 Oct 2002 10:06:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9NE89r02891 for ; Wed, 23 Oct 2002 10:08:10 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9NE86K26782 for ; Wed, 23 Oct 2002 10:08:07 -0400 (EDT) Message-Id: <200210231406.g9NE6qIm003753@sj-msg-core-1.cisco.com> To: asodder@tenornetworks.com cc: ppvpn@lyris.nortelnetworks.com Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt In-reply-to: Your message of Tue, 22 Oct 2002 21:00:54 -0400. <00fb01c27a2f$a65e3a80$d303a8c0@tenornet.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Oct 2002 10:06:51 -0400 From: Eric Rosen X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: Arnold> I agree that initially I have been assuming that the Arnold> ethernet-over-IP/MPLS service begins after the MAC-in-MAC encaps has Arnold> been done, and ends before the corresponding decaps has been done. In this case, we need only consider how to provide the emulated LAN service for the packets which have already been MAC-in-MAC encapsulated, and we need to do that considering only the outer MAC header. So this reduces to exactly the same problem that VPLS is intended to solve. The only relevant difference then between your proposal and VPLS is the following. In VPLS, signaling is used to assign a locally significant label value that represents a particular L2VPN instance in a particular PE. You appear to be proposing to replace the locally significant label value with globally significant values, so as to eliminate the signaling. It's not completely clear how you intend this to work, as your draft says nothing about how a packet is associated with its source PE. I think you might be intending to have each PE signal a single label (representing the "emulated LAN application") to each other PE. Then you seem to be intending to have each packet carry a VPN-id in its encapsulation. My comments on this would be: - It significantly increases the per-packet overhead. I see that you're trying to squeeze the VPN-id into some existing MAC header field, but this won't work. The VPN-id has to be a globally unique value which can feasibly be administered in a multi-provider space, and this means it is going to be about 8 bytes long. (See, e.g., RFC 2685.) - With a significant increase in the per-packet overhead, you need to make the assumption that the packets will not have to pass through any legacy ethernet equipment (you know, the kind that just barely supports an ethernet frame with a couple of MPLS labels). This is not a realistic assumption. - For the increase in packet size, I don't see that you gain any significant reduction in signaling, as you still seem to need per-PE control connections. (To eliminate that, I think you'd need to require that the MAC-in-MAC encaps be further encapsulated inside IP, so you could learn the source PE's address on a per-packet basis; but I think that has problems as well.) You also need to consider the impact of interoperating with other hierarchical VPLS or distributed VPLS schemes, as well as interoperating with the PWE3 p2p ethernet service, all of which seem to be made more complex. (You're not assuming that emulated LAN service will only be offered with new L2PE equipment that does the MAC-in-MAC processing, are you?) - By carrying the VPN-id in each packet, you impose the requirement to look up the VPN-id for each received packet, so we have yet another kind of thing to be looked up. I can see that VHLS keeps the MAC address tables in the PE smaller than HVPLS does, but the distributed (sometimes called "decoupled") VPLS models eliminate those tables in the PE altogether, though at the cost of requiring MPLS in the L2PEs. One alternative to consider might be the following. In the distributed VPLS model, allow MAC-in-MAC to be an alternative to MPLS for the local L2PE-to-PE signaling, but don't carry the MAC-in-MAC across the network. This would allow the various schemes to interoperate (e.g., MAC-in-MAC at one end, MPLS at the other). Arnold> I'm very interested in your last statement which implies that if the Arnold> service begins before the MAC-in-MAC encaps is done then the Arnold> standardization effort belongs in the PWE3 working group. Could you Arnold> please elaborate. There's not really anything to elaborate. The specification of the encapsulation needed to provide an ethernet service over an IP or MPLS network is in the domain of PWE3. From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 23 11:15:08 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13189 for ; Wed, 23 Oct 2002 11:15:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9NFGbr18579 for ; Wed, 23 Oct 2002 11:16:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9NFGZK00055 for ; Wed, 23 Oct 2002 11:16:35 -0400 (EDT) Message-ID: <6B190B34070BD411ACA000B0D0214E56015915A9@newman.tenornet.com> From: "Mancour, Tim" To: "'Masato Ando'" , ppvpn@lyris.nortelnetworks.com Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Wed, 23 Oct 2002 11:11:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: tenornetworks.com X-SMTP-MAIL-FROM: timm@tenornetworks.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: rtu.tenornetworks.com [63.77.213.2] X-LYRIS-Message-Id: Masato, In reference to 1 below - I believe that we can use the VPN identifier, instead of a MAC address, to provide the filtering capability that you are requesting. The service provider could partition the VPN space into a nation space (e.g. 1..N) and separate set of regional spaces (e.g. N+1..16777215). The filtering function would then pass traffic that contains a VPN identifier that is a member of the national space and block all other traffic. Regards, Tim Mancour -----Original Message----- From: Masato Ando [mailto:masaty@tec.poweredcom.net] Sent: Wednesday, October 23, 2002 2:02 AM To: ppvpn@lyris.nortelnetworks.com Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Sodder (1)VHLS Draft say >L2PE devices are assigned a single MAC address. When an L2PE device >has two uplinks to different PE devices the same MAC address is used In my opinion, L2PE devices can be assigned one or more configurable addresses. This allows you to assign different MAC addresses on each downlink port on L2PE devices. You can use this type of assignment to control traffic by MAC address filtering. For example, it is supposed that you build a nationwide IX by L2 network and the IX supports two services, regional exchange and nationwide exchange. You can provide this service by L2PE MAC address filtering with MAC addresses on downlink port. Tier1 Tier1 ISP(A)--+ .......... ........ .......... +--ISP(C) L2PE---.Regional.---MAC---.nation. ---MAC---.Regional.--L2PE Tier2 | . bb(X) . Filter . bb . Filter . bb(Y) . | Tier2 ISP(B)--+ .......... ........ .......... +--ISP(D) *Tier1 ISPs MAC frame can pass MAC Filter. *Tier2 ISPs MAC frame cannot pass MAC Filter. PSTN(iSCSI, etc)-GW service is other example. This requires location base access control and MAC address filtering is also useful for this. (2) About hierachical MAC assignment. I support your idea about L2PE MAC. The other advantage on L2PE MAC is capability of hierarchical MAC assignment. West coast switchs L2PE MAC address=(aa:aa:**:**:**) San Francisco area switches L2PE MAC address=(aa:aa:aa:**:**) area 1 switches L2PE MAC address=(aa:aa:aa:aa:**) area 2 switches L2PE MAC address=(aa:aa:aa:bb:**) Los Angeles ara switches L2PE MAC address=(aa:aa:bb:**:**) East coast switches L2PE MAC address=(bb:bb:**:**:**) New York area switches L2PE MAC address=(bb:bb:aa:**:**) You can use MAC address filtering with a mask for avoiding loop traffic. You can use aggregate MAC bridging also. (3)I have same idea as VHLS. I call this technology "Ethernet over Ethernet(EoE)" or "Mac on mac". I made a similar presentation to the JANOG10 in Tokyo on this July 2002. You can get the presentation form http://www.janog.gr.jp/meeting/janog10/pdf/janog10-l2-ando.pdf It is written in Japanese, but you can understand page 16,17 figure. I have another detail documentation written in Japanese. If you want I will transrate the document to English and send it to you. I want to contribute your draft. (4) I belong to one of the largest nation wide ethernet VPN provider in Japan. In our company, we are using QinQ(VMAN) technology. Im looking for new solution for next generation network to solve some problems. I like VPLS.But I dont want to use VPLS. Because it has full mesh LSP broadcast problem which wastes backbone capacity. ("H"VPLS is not perfect solution, core needs full mesh LSP anyway) The point of broadcast capability, I think your idea is superior to VPLS. -- Masato Ando 03-4431-6630 From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 23 23:21:51 2002 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15279 for ; Wed, 23 Oct 2002 23:21:51 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9O3NIr06332 for ; Wed, 23 Oct 2002 23:23:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9O3NFK04493 for ; Wed, 23 Oct 2002 23:23:15 -0400 (EDT) Message-ID: <9DF00DDFB54ED511A9AE00508BF9380A0559F191@zrtpd0j9.us.nortel.com> From: "John Pugh" To: "PPVPN (ppvpn@lyris.nortelnetworks.com)" Subject: This is my test message Date: Wed, 23 Oct 2002 23:22:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27B0C.A33BE270" X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27B0C.A33BE270 Content-Type: text/plain Hopefully the web archive will kick in ------_=_NextPart_001_01C27B0C.A33BE270 Content-Type: text/html This is my test message

Hopefully the web archive will kick in

------_=_NextPart_001_01C27B0C.A33BE270-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Oct 28 11:02:14 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15851 for ; Mon, 28 Oct 2002 11:02:13 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9SG3wV09472 for ; Mon, 28 Oct 2002 11:03:58 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9SG3uK23707 for ; Mon, 28 Oct 2002 11:03:56 -0500 (EST) Message-ID: <9DF00DDFB54ED511A9AE00508BF9380A0561A212@zrtpd0j9.us.nortel.com> From: "John Pugh" To: "PPVPN (ppvpn@lyris.nortelnetworks.com)" Subject: Archive Page Update Date: Mon, 28 Oct 2002 10:58:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27E9A.DE827470" X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27E9A.DE827470 Content-Type: text/plain The 2002 archives (January - September) have been updated at the following web page for your convenience. October will be archived at the end of this month. Archives previous to 2002 are contained in the zip file. http://standards.nortelnetworks.com/ppvpn/archiveddocs.html > John Pugh Nortel Networks Tel: 919-997-3626 (Office) Tel: 919-471-1217 (Telecommute) http://standards.nortelnetworks.com ------_=_NextPart_001_01C27E9A.DE827470 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Archive Page Update

The 2002 archives (January - = September) have been updated at the following web page for your = convenience. October will be archived at the end of this month. = Archives previous to 2002 are contained in the zip file.

= http://standards.nortelnetworks.com/ppvpn/archiveddocs.ht= ml

John = Pugh
Nortel = Networks
Tel: 919-997-3626 = (Office)
Tel: 919-471-1217 = (Telecommute)
http://standards.nortelnetworks.com

------_=_NextPart_001_01C27E9A.DE827470-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Oct 28 20:41:21 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06498 for ; Mon, 28 Oct 2002 20:41:20 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9T1gqV03663 for ; Mon, 28 Oct 2002 20:42:58 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9T1goK20123 for ; Mon, 28 Oct 2002 20:42:50 -0500 (EST) Message-Id: <200210290142.KAA47296@infer.nal.ecl.net> To: ppvpn@lyris.nortelnetworks.com Subject: I-D ACTION:draft-ietf-ppvpn-framework-06.txt Date: Tue, 29 Oct 2002 10:42:21 +0900 From: Muneyoshi Suzuki X-SMTP-HELO: infer.nal.ecl.net X-SMTP-MAIL-FROM: suzuki@nal.ecl.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: infer.nal.ecl.net [163.138.70.32] X-LYRIS-Message-Id: It seems ID announcement is not posted to the new mailing list, so I forward it to the correct address. The L3 PPVPN framework design team updated the document based on the IESG comments. Many nits are fixed and mainly sections 3.3.1.3, 4.1, 4.2.1.1, 4.2.1.4, 4.2.2, 4.3.3, 4.3.4, 4.4, 4.4.2 are updated. I don't think we need to present the update in the upcoming meeting, so please post your questions or comments to this mailing list or get in touch with the authors, if you have. Thanks, Muneyoshi Suzuki ---- Message-Id: <200210281128.GAA03464@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: ppvpn@ppvpn.francetelecom.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-framework-06.txt Date: Mon, 28 Oct 2002 06:28:47 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : A Framework for Layer 3 Provider Provisioned Virtual Private Networks Author(s) : R. Callon et al. Filename : draft-ietf-ppvpn-framework-06.txt Pages : 71 Date : 2002-10-25 This document provides a framework for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues which are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-framework-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-framework-06.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-ppvpn-framework-06.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: <2002-10-25112739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-framework-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-25112739.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Oct 29 15:47:00 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24264 for ; Tue, 29 Oct 2002 15:46:59 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9TKmLg28783 for ; Tue, 29 Oct 2002 15:48:22 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9TKmHN05547 for ; Tue, 29 Oct 2002 15:48:17 -0500 (EST) Message-ID: <9DF00DDFB54ED511A9AE00508BF9380A056BB8EB@zrtpd0j9.us.nortel.com> From: "John Pugh" To: ppvpn@nortelnetworks.com Subject: PPVPN web site/mail server Date: Tue, 29 Oct 2002 15:47:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27F8C.698A5E60" X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27F8C.698A5E60 Content-Type: text/plain The informal PPVPN web site hosted by Nortel Networks has been updated to include all information that was on the France Telecom web site. The new URL is: http://www.nortelnetworks.com/ppvpn - The site contains the following updated pages: ' Mailing List' link Mailing List information can be found here as follows: The mailing list address for distribution to the over 1000 subscribers is ppvpn@nortelnetworks.com The address to be used for subscribing/unsubscribing is: lyris@nortelnetworks.com 'Calendar of Events' link Documents relating to IETF PPVPN meetings can be found here. They are organized by meeting date. 'Archived Documents' link Archived messages can be found here. Archives are divided into three areas as follows: - messages received from today onwards are stored on the new mail archive server. Click on the PPVPN link and the archive displays by month. Click on October and notice that you can select author/date/topic chronologically or 'most recent first'. You may also display a 'table of contents' if desirable. - Year 2002 messages as per the France Telecom web site are listed on the archive page directly. - Messages received from years 2000 - 2002 are contained in a zip file in html format. Instructions are provided I apologize for the inconvenience caused while we re-configured the site in accordance with the various requirements that came in. We will endeavor to be responsive to any needs that may arise in the future and hope you find the slightly new format to your liking. > John Pugh Nortel Networks Tel: 919-997-3626 (Office) http://www.nortelnetworks.com/ppvpn ------_=_NextPart_001_01C27F8C.698A5E60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable PPVPN web site/mail server

The informal PPVPN web site hosted by = Nortel Networks has been updated to include all information that was on = the France Telecom web site. The new URL is:

http://www.nortelnetworks.com/ppvpn - The site contains the following updated = pages:

' Mailing List' link
Mailing List information can be found = here as follows:
The mailing list address for = distribution to the over 1000 subscribers is = ppvpn@nortelnetworks.com
The address to be used for = subscribing/unsubscribing is: lyris@nortelnetworks.com

'Calendar of Events' link
Documents relating to IETF PPVPN = meetings can be found here. They are organized by meeting date.

'Archived Documents' link
Archived messages can be found here. = Archives are divided into three areas as follows:

- messages received from today onwards = are stored on the new mail archive server. Click on the PPVPN link and = the archive displays by month. Click on October and notice that you can = select author/date/topic chronologically or 'most recent first'. You = may also display a 'table of contents' if desirable.

- Year 2002 messages as per the France = Telecom web site are listed on the archive page directly.
- Messages received from years 2000 - = 2002 are contained in a zip file in html format. Instructions are = provided

I apologize for the inconvenience = caused while we re-configured the site in accordance with the various = requirements that came in. We will endeavor to be responsive to any = needs that may arise in the future and hope you find the slightly new = format to your liking.

John = Pugh
Nortel = Networks
Tel: 919-997-3626 = (Office)

http://www.nortelnetworks.com/ppvpn

------_=_NextPart_001_01C27F8C.698A5E60-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Oct 30 22:26:20 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24166 for ; Wed, 30 Oct 2002 22:26:20 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9V3S0l01385 for ; Wed, 30 Oct 2002 22:28:00 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9V3RvJ21797 for ; Wed, 30 Oct 2002 22:27:57 -0500 (EST) Message-ID: From: "Marco Carugi" To: ppvpn@nortelnetworks.com Cc: "Marco Carugi" , "'Muneyoshi Suzuki'" , "'kuwahara.takeshi@lab.ntt.co.jp'" Subject: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Date: Thu, 31 Oct 2002 04:27:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2808D.7084997C" X-LYRIS-Message-Id: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2808D.7084997C Content-Type: text/plain; charset="iso-8859-1" All, This is a request for WG Last Call. Authors believe the work is done after the last ID update and solicit the call. There were issues with this draft in past mailing list exchanges (technical issues, positioning of this ID in the context of PPVPN work/objectives), it was then decided to review the situation after some updates planned by authors. Let's see how you feel now. Marco > Dear Marco, > > As you have known, we submitted the updated version of our draft as > draft-ietf-ppvpn-cl-tuneling-vpn-00.txt. Section 3.2.3 is newly added > and sections 1., 2. and 3.1 are mainly updated. > > We believe the work is done. Therefore, we would like to solicit WG > last call. > > Thanks in advance, > > Takeshi Kuwahara. > > >A New Internet-Draft is available from the on-line Internet-Drafts directories > . > >This draft is a work item of the Provider Provisioned Virtual Private > >Networks Working Group of the IETF. > > > > Title : Scalable Connectionless Tunneling Architecture and > > Protocols for VPNs > > Author(s) : T. Kuwahara et al. > > Filename : draft-ietf-ppvpn-cl-tunneling-vpn-00.txt > > Pages : 29 > > Date : 2002-10-3 > > > >This document defines a connectionless tunneling architecture that is > >applicable to layer 3 PE-based virtual private networks and specifies > >protocols for implementing it. This tunneling architecture is > >designed to facilitate scalability and reliability. A prominent > >feature of it is to provide VPN tunnels over a connectionless > >network. Since a connectionless network can provide full mesh > >connectivity without a connection establishment procedure, the > >architecture enables scalable operation of a VPN more efficiently > >than connection-oriented tunneling technologies. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-cl-tunneling-vpn-00.tx t > > ------_=_NextPart_001_01C2808D.7084997C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt =

All,

This is a request for WG Last Call.
Authors believe the work is done after the last ID = update and solicit the call.
There were issues with this draft in past mailing = list exchanges (technical issues, positioning of this ID in the context = of PPVPN work/objectives), it was then decided to review the situation = after some updates planned by authors.

Let's see how you feel now.
 
Marco
 
> Dear Marco,
>
> As you have known, we submitted the updated = version of our draft as
> draft-ietf-ppvpn-cl-tuneling-vpn-00.txt. = Section 3.2.3 is newly added
> and sections 1., 2. and 3.1 are mainly = updated.
>
> We believe the work is done.  Therefore, = we would like to solicit WG
> last call.
>
> Thanks in advance,
>
> Takeshi Kuwahara.
>
> >A New Internet-Draft is available from the = on-line Internet-Drafts directories
> .
> >This draft is a work item of the Provider = Provisioned Virtual Private
> >Networks Working Group of the IETF.
> >
> = >         = Title           : = Scalable Connectionless Tunneling Architecture and
> = >           &n= bsp;           &n= bsp;   Protocols for VPNs
> = >         = Author(s)       : T. Kuwahara et = al.
> = >         = Filename        : = draft-ietf-ppvpn-cl-tunneling-vpn-00.txt
> = >         = Pages           : = 29
> = >         = Date            = : 2002-10-3
> >
> >This document defines a connectionless = tunneling architecture that is
> >applicable to layer 3 PE-based virtual = private networks and specifies
> >protocols for implementing it.  This = tunneling architecture is
> >designed to facilitate scalability and = reliability.  A prominent
> >feature of it is to provide VPN tunnels = over a connectionless
> >network.  Since a connectionless = network can provide full mesh
> >connectivity without a connection = establishment procedure, the
> >architecture enables scalable operation of = a VPN more efficiently
> >than connection-oriented tunneling = technologies.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-c= l-tunneling-vpn-00.txt
>
>

------_=_NextPart_001_01C2808D.7084997C-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 07:05:42 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14876 for ; Thu, 31 Oct 2002 07:05:41 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VC7JO23393 for ; Thu, 31 Oct 2002 07:07:21 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VC7GH10257 for ; Thu, 31 Oct 2002 07:07:16 -0500 (EST) Message-Id: <200210311204.HAA14687@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-duffy-ppvpn-ipsec-vlink-00.txt Date: Thu, 31 Oct 2002 07:04:35 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework for IPsec Protected Virtual Links for PPVPNs Author(s) : M. Duffy Filename : draft-duffy-ppvpn-ipsec-vlink-00.txt Pages : 15 Date : 2002-10-21 This memo explores some choices that arise when IPsec is to be used to implement secure 'virtual links' interconnecting customer premises VPN devices and/or network based virtual routers. The main focus is on the network based cases. Requirements are proposed and some relevant aspects of the IPsec protocol suite are discussed. A number of different protocol architectures for virtual links are then evaluated. This memo is informational in nature; it is intended that it will focus discussion toward a standard in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-duffy-ppvpn-ipsec-vlink-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-duffy-ppvpn-ipsec-vlink-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-duffy-ppvpn-ipsec-vlink-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. --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: <2002-10-31070712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-duffy-ppvpn-ipsec-vlink-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-duffy-ppvpn-ipsec-vlink-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31070712.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 07:05:54 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14889 for ; Thu, 31 Oct 2002 07:05:53 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VC7aO23796 for ; Thu, 31 Oct 2002 07:07:37 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VC7YH10773 for ; Thu, 31 Oct 2002 07:07:34 -0500 (EST) Message-Id: <200210311204.HAA14739@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-knight-ppvpn-vr-protocol-00.txt Date: Thu, 31 Oct 2002 07:04:48 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol Actions for Virtual Router VPNs Author(s) : P. Knight Filename : draft-knight-ppvpn-vr-protocol-00.txt Pages : 5 Date : 2002-10-29 This document identifies elements of the protocols used by the 'Virtual Router' Provider Provisioned VPN architecture which may need to be coordinated with IETF Working Groups other than the PPVPN WG. The primary focus of coordination identified in this document is with the IPSEC WG. This document is for temporary administrative purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-knight-ppvpn-vr-protocol-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-knight-ppvpn-vr-protocol-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-knight-ppvpn-vr-protocol-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. --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: <2002-10-31070847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-knight-ppvpn-vr-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-knight-ppvpn-vr-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31070847.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 07:05:58 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14902 for ; Thu, 31 Oct 2002 07:05:58 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VC7VO23690 for ; Thu, 31 Oct 2002 07:07:33 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VC7SH10619 for ; Thu, 31 Oct 2002 07:07:28 -0500 (EST) Message-Id: <200210311204.HAA14669@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shah-ppvpn-arp-mediation-01.txt Date: Thu, 31 Oct 2002 07:04:30 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ARP Mediation for IP interworking of Layer 2 VPN Author(s) : H. Shah et al. Filename : draft-shah-ppvpn-arp-mediation-01.txt Pages : 16 Date : 2002-10-21 This draft addresses an issue in a particular kind of Layer 2 VPN, which provides point-to-point connectivity for IP traffic only. In this kind of VPN it is possible to form heterogeneous point-to-point links, where the two ends of the link use different technologies, e.g., one end is Ethernet and the other is Frame Relay or ATM. If two IP systems are connected via a heterogeneous point-to-point link, each may be using different address learning techniques, for instance, one using ARP on Ethernet and the other using Inverse ARP on Frame Relay. It is up to the Provider Edge routers to make these different techniques inter-work. This draft specifies the procedures which the Provider Edge (PE) routers should perform in order to allow correct operation across heterogeneous point-to-point links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shah-ppvpn-arp-mediation-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shah-ppvpn-arp-mediation-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shah-ppvpn-arp-mediation-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-31070628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shah-ppvpn-arp-mediation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-shah-ppvpn-arp-mediation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31070628.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 07:09:22 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15163 for ; Thu, 31 Oct 2002 07:09:22 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VCAbO27644 for ; Thu, 31 Oct 2002 07:10:37 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VCAUH15904 for ; Thu, 31 Oct 2002 07:10:30 -0500 (EST) Message-Id: <200210311204.HAA14722@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shah-ppvpn-ipls-00.txt Date: Thu, 31 Oct 2002 07:04:44 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP over LAN Service (IPLS) Author(s) : H. Shah et al. Filename : draft-shah-ppvpn-ipls-00.txt Pages : 16 Date : 2002-10-21 A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear to those systems as if they are interconnected on a private LAN. The systems which are interconnected in this way may themselves be LAN switches. If, however, the interconnected systems are NOT LAN switches, but rather are IP hosts or IP routers, certain simplifications are possible. We call this simplified type of virtual private LAN service an 'IP over LAN Service' (IPLS). In IPLS, as in VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their MAC Destination Addresses. However, the maintenance of the MAC forwarded tables is done via signaling, rather than via the 'MAC Address Learning' procedures of IEEE 802.1D. Further, Address Resolution Protocol (ARP) messages are proxied, rather than being carried transparently. This draft specifies the protocols and procedures for support of the IPLS service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shah-ppvpn-ipls-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shah-ppvpn-ipls-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-shah-ppvpn-ipls-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. --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: <2002-10-31070809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shah-ppvpn-ipls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shah-ppvpn-ipls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31070809.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 07:13:00 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15298 for ; Thu, 31 Oct 2002 07:12:59 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VCDZO01442 for ; Thu, 31 Oct 2002 07:13:36 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VCDTH21001 for ; Thu, 31 Oct 2002 07:13:29 -0500 (EST) Message-Id: <200210311205.HAA14793@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-framework-06.txt Date: Thu, 31 Oct 2002 07:05:02 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : A Framework for Layer 3 Provider Provisioned Virtual Private Networks Author(s) : R. Callon et al. Filename : draft-ietf-ppvpn-framework-06.txt Pages : 71 Date : 2002-10-25 This document provides a framework for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues which are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-framework-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-framework-06.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-ppvpn-framework-06.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: <2002-10-31071004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-framework-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31071004.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 07:15:25 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15454 for ; Thu, 31 Oct 2002 07:15:25 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VCGcO05251 for ; Thu, 31 Oct 2002 07:16:38 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VCGYH26010 for ; Thu, 31 Oct 2002 07:16:35 -0500 (EST) Message-Id: <200210311204.HAA14706@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-radoaca-ppvpn-gvpls-00.txt Date: Thu, 31 Oct 2002 07:04:39 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GVPLS/LPE - Generic VPLS Solution based on LPE Framework Author(s) : V. Radoaca et al. Filename : draft-radoaca-ppvpn-gvpls-00.txt Pages : 31 Date : 2002-10-29 This document describes virtual private LAN service (VPLS) solution over MPLS, called Generic VPLS/LPE (GVPLS) that emulates a partial bridging functionality [802.1D] to connect customers LANs/VLANs across the Metro and WAN Service Provider networks. This functionality includes the MAC learning and forwarding to emulate connectivity between the customer LANs/VLANs. This is a partial bridging functionality since it is transparent to customer topology and STP protocol. For VPLS solutions, the VPLS Reference Model [VPLS-L2-FRW] introduces two types of models: distributed and non-distributed. While [LPE] framework, and [DTLS] solution present a distributed model and [HVPLS] solution presents a non-distributed model, it is recognized that both models may need to co-exist in the same in the same SP network. This implies a need of a unified provisioning model with signalling mechanisms to support these new classes of solutions. The MAC learning process and the scalability in terms of number of VPLSs and number of customer ports can be increased significantly if some optimisations are provided in the Control and Data plane. The current draft presents the GVPLS solution that addresses such issues. The term 'Generic' in this document is used to reflect the unified aspect of the two models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-radoaca-ppvpn-gvpls-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-radoaca-ppvpn-gvpls-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-radoaca-ppvpn-gvpls-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. --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: <2002-10-31070744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-radoaca-ppvpn-gvpls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-radoaca-ppvpn-gvpls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31070744.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 07:21:39 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15757 for ; Thu, 31 Oct 2002 07:21:39 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VCMdO13104 for ; Thu, 31 Oct 2002 07:22:39 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VCMXH05586 for ; Thu, 31 Oct 2002 07:22:34 -0500 (EST) Message-Id: <200210311204.HAA14756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ishiguro-ppvpn-pe-ce-ospf-01.txt Date: Thu, 31 Oct 2002 07:04:53 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of Multiple Instance of OSPF for the PE/CE protocol in BGP/MPLS VPNs Author(s) : K. Ishiguro, V. Hallivuori Filename : draft-ishiguro-ppvpn-pe-ce-ospf-01.txt Pages : 5 Date : 2002-10-16 This document describes a simple way to use OSPF for Provider Edge (PE) router and Customer Edge (CE) router communication in BGP/MPLS VPNs [RFC2547BIS]. [VPN-BGP-OSPF] proposes a complicated way to achieve VPN route propagation as Type-3 LSAs. This document describes the use of multiple instances of OSPF in conjunction with standard BGP/OSPF route redistribution mechanisms to maintain reachability information throughout VPNs. With this mechanism, VPN routes are propagated as Type-5 LSAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ishiguro-ppvpn-pe-ce-ospf-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ishiguro-ppvpn-pe-ce-ospf-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ishiguro-ppvpn-pe-ce-ospf-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-31070916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ishiguro-ppvpn-pe-ce-ospf-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ishiguro-ppvpn-pe-ce-ospf-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31070916.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 07:21:56 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15774 for ; Thu, 31 Oct 2002 07:21:56 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VCNNO14111 for ; Thu, 31 Oct 2002 07:23:24 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VCJWH00781 for ; Thu, 31 Oct 2002 07:19:33 -0500 (EST) Message-Id: <200210311204.HAA14775@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Date: Thu, 31 Oct 2002 07:04:57 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Virtual Hierarchical LAN Services Author(s) : A. Sodder Filename : draft-sodder-ppvpn-vhls-00.txt Pages : 12 Date : 2002-10-7 This draft describes an Ethernet [IEEE-802.3] L2VPN model that provides point-to-point and point-to-multipoint Layer 2 data communication services using a hierarchical LAN switching architecture. The model is based on a hierarchical MAC frame format. Scalability and manageability is achieved by simplifying the control plane at the cost of adding functionality to the forwarding plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sodder-ppvpn-vhls-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sodder-ppvpn-vhls-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-sodder-ppvpn-vhls-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. --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: <2002-10-31070934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sodder-ppvpn-vhls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sodder-ppvpn-vhls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31070934.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 07:29:12 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16277 for ; Thu, 31 Oct 2002 07:29:11 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VCV0O23558 for ; Thu, 31 Oct 2002 07:31:00 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VCUvH19337 for ; Thu, 31 Oct 2002 07:30:57 -0500 (EST) Message-Id: <200210311205.HAA14815@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-rfc2547bis-03.txt Date: Thu, 31 Oct 2002 07:05:07 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : BGP/MPLS VPNs Author(s) : E. Rosen et al. Filename : draft-ietf-ppvpn-rfc2547bis-03.txt Pages : 47 Date : 2002-10-25 This document describes a method by which a Service Provider may use an IP backbone to provide 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 is 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. Each route within a VPN is assigned an MPLS label; when BGP distributes a VPN route, it also distributes an MPLS label for that route. Before a customer data packet travels across the Service Provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route that is the best match to the packet's destination address. This MPLS packet is further encapsulated (e.g., with another MPLS label, or with an IP or GRE tunnel header) so that it gets tunneled across the backbone to the proper PE router. Thus the backbone core routers do not need to know the VPN routes. The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises which need an extranet, an Internet Service Provider, an application service provider, another VPN Service Provider which uses this same method to offer VPNs to clients of its own, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value. This document obsoletes RFC 2547. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-rfc2547bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-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-ppvpn-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: <2002-10-31071038.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-rfc2547bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-rfc2547bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31071038.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Oct 31 10:49:21 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26454 for ; Thu, 31 Oct 2002 10:49:21 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9VFotO24842 for ; Thu, 31 Oct 2002 10:50:57 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g9VForH13550 for ; Thu, 31 Oct 2002 10:50:53 -0500 (EST) Message-Id: <200210311549.g9VFnlm58723@merlot.juniper.net> To: "Marco Carugi" cc: ppvpn@nortelnetworks.com, "'Muneyoshi Suzuki'" , "'kuwahara.takeshi@lab.ntt.co.jp'" Subject: Re: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt In-Reply-To: Your message of "Thu, 31 Oct 2002 04:27:30 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89163.1036079387.1@juniper.net> Date: Thu, 31 Oct 2002 07:49:47 -0800 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Marco, > All, > > This is a request for WG Last Call. > Authors believe the work is done after the last ID update and solicit the > call. > There were issues with this draft in past mailing list exchanges (technical > issues, positioning of this ID in the context of PPVPN work/objectives), it > was then decided to review the situation after some updates planned by > authors. > Let's see how you feel now. From the PPVPN Charter: Note that it is not a goal of this WG to develop new protocols or extend existing ones. Rather, the purpose is to document and identify gaps and shortcomings in individual approaches with regards to the requirements. In the case that specific work items are identified, such work will be done in an appropriate WG. Taking on specific protocol work items in this WG will require rechartering. From the draft: This document defines a connectionless (CL) tunneling architecture that is applicable to layer 3 PE-based virtual private networks [L3- PPVPN-FR]. It also specifies protocols for implementing the CL tunneling architecture. Therefore, in order for the PPVPN WG to even accept this as a WG document either (a) the protocol described in this document (see Section 3) has to be taken out, or (b) the WG has to be rechartered. With this in mind I would suggest that first either (a) or (b) should happen, and after that we would revisit the issue of WG Last Call. Moreover, as the charter said that "Standardization of specific approaches will be gauged on (I)SP support.", the WG needs to have information on the support of (I)SPs for the approach specified in draft-ietf-ppvpn-cl-tunneling-vpn-00.txt. Yakov.
 

Hi,Sodder, Arnold=A3=A1 

[VHLS] say:

   In the above frame formats the CE frame MUST -include- the original
   CRC32 to allow detection of bit errors introdu= ced by devices in the
   service provider network or attached to the service provider network. 
  = ; If the L2PE device needs to modify the CE frame it MUST calculate and 
 &n= bsp; add a new CRC32 to the CE frame.

draft-martini-l2circuit-e= ncap-mpls-03.txt say:

  For simple Etherne= t port to port transport, the entire Ethernet frame
  -without- the preamble or FCS is transported as a single packet.

   Would you consider change [VHLS]  as later, just beca= use many vendors surport it now.

  =A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Du Wenhua

         =             &nb= sp;   duwh@huawei.com
=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A12002-10-11