From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 2 07:54: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 HAA12212 for ; Mon, 2 Dec 2002 07:54:00 -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 gB2Cu8m25977 for ; Mon, 2 Dec 2002 07:56:09 -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 gB2Cu5f21268 for ; Mon, 2 Dec 2002 07:56:05 -0500 (EST) Message-Id: <200212021252.HAA12046@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-01.txt Date: Mon, 02 Dec 2002 07:52:42 -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-01.txt Pages : 15 Date : 2002-11-27 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-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-sodder-ppvpn-vhls-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-sodder-ppvpn-vhls-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-11-27105903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sodder-ppvpn-vhls-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-sodder-ppvpn-vhls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-27105903.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 2 15:21: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 PAA08041 for ; Mon, 2 Dec 2002 15:21:14 -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 gB2KMmm25574 for ; Mon, 2 Dec 2002 15:22:48 -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 gB2KMjf23144 for ; Mon, 2 Dec 2002 15:22:46 -0500 (EST) Message-Id: <5.2.0.9.2.20021202151125.052b4698@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Dec 2002 15:11:35 -0500 To: From: "Thomas D. Nadeau" Subject: Re: draft-ietf-ppvpn-mpls-vpn-04.txt Cc: ppvpn@nortelnetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: rtp-msg-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-msg-core-1.cisco.com [161.44.11.97] X-LYRIS-Message-Id: >Hi, > >Had a few questions on this MIB. Thanks for the review. Sorry for the delay in responding. I started replying an forgot about it for some reason. >1) the name of the mib is 'MPLS/BGP Virtual >Private Network Management Information Base >using SMIv2' and the abstract says that >this MIB is based upon draft-ietf-ppvpn-rfc2547bis-02.txt >which has the title of: > >'BGP/MPLS VPNs' > >So my question is: could this MIB follow the draft >that is associated with it and be called >'BGP/MPLS ...' ? Need to make consistent. >(also section 6.0 refers to BGP/MPLS VPN and not MPLS/BGP VPN) Confusion on our part. We will make consistent. >2) The MplsVpnName which is a 32 Octet string, which >may or may not be the VPN ID. Could the description be >clarified to say if the VPN ID is not used as the value, >what the value is supposed to be? (If not in the TC then >maybe in the index itself). Good idea. Will update to be specific. >Also, I do not understand how this index could be >a NULL string for more than one VPN, otherwise, it >would be difficult to interpret which VPN an interface >belongs to. > >Is this possible? No. Just like it is impossible to have two VRFs with the same name on a PE, it is not possible to have two entries in the MIB with the same name. At least that is my understanding based on my implementation and the others I know of. >3) The following objects might work better >as Gauge32: > >mplsVpnVrfActiveInterfaces >mplsVpnVrfAssociatedInterfaces >mplsVpnVrfPefCurrNumRoutes Cool. >4) There are references to an MPLS-VPN Interface and >yet the MIB uses mpls(166) or mplsTunnel(150) >for the ifType. > >Was a new Mpls-VPN ifType considered? (The reason >a new ifType might want to be considered is because >if 2 (or more?) ifTypes are possible >to uniquely identify a BGP/MPLS interface, a new ifType >might be cleaner, especially if the MplsVpnName is allowed >to be NULL. We need to remove the references. We did not have enough time to clarify the text during the last edits. --Tom From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 2 20:58:48 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 UAA21717 for ; Mon, 2 Dec 2002 20:58:47 -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 gB3211m00395 for ; Mon, 2 Dec 2002 21:01:02 -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 gB320wf11319 for ; Mon, 2 Dec 2002 21:00:59 -0500 (EST) Message-ID: <3DEC0F63.7050206@cisco.com> Date: Tue, 03 Dec 2002 02:56:51 +0100 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: Joe Touch , Cheng-Yin.Lee@alcatel.com, erosen@cisco.com, ppvpn@lyris.nortelnetworks.com Subject: Re: L2TP and IPSec References: <3.0.5.32.20021126173921.008e3820@email.quarrytech.com> <3.0.5.32.20021128120250.007c7b20@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: townsley@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: europe.cisco.com [144.254.52.73] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark Duffy wrote: > At 09:42 AM 11/27/02 -0800, Joe Touch wrote: > >> >>Mark Duffy wrote: >> >>>I'm not familiar enough with the VPL work to be sure whether this is >>>relevant or not, but one possible reason to use L2TP+IPsec would be to get >>>the capability (based on L2TP sessions) to multiplex many separate VPN >>>contexts within one IPsec SA. Thus saving on number of SAs to create. Also, keeping the tunnneling mechanism above IP separate from the security mechanism of IP allows IPsec to focus on securing IP traffic between two points, and L2TP to focus on tunneling Layer 2. From a security perspective, I would be uncomfortable mucking around with IKE unnecessarily, or managing more SAs than necessary. >> >>Muxing several VPNs over a single IPsec is contradictory: >> >> - if the VPNs have sufficient security, they don't need IPsec >> underneath >> >> - if the VPNs lack security, they're not P anymore. > > > I disagree. The multiple VPNs share an SA only from PE to PE. The > "customers" (whose data is in the VPNs) do not have the keys. It's a > little like a bank where they lock your money and mine in the same vault. > But that doesn't mean I can withdraw your money nor you mine. Note that you can always have multiple SAs (one per VPN and PE pair) if you want, but you are not forced to. > > >>>Also, L2TP is readily extensible to allow binding each L2TP session to a >>>given VPN context. IPsec is not readily extensible to allow binding each >>>SA to a given VPN context. >> >>"extensible?" - this group isn't chartered to form new protocols to >>solve problems. > > > The extension I had in mind was merely allocating an AVP to convey a VPN > Identifier to bind to an l2tp session. L2tpv3 already has such an AVP, but > I don't think l2tpv2 does. The exact application was left somewhat out of scope in L2TPv2 as defined in RFC2661, but a number of AVPs are sometimes used for this today (i.e. the Calling Number AVP, or ATM VPI/VCI AVP). More often, session binding is performed via PPP-level authentication on top of the L2TP session (which, in turn, may also be carried in an L2TP AVP). The AVP format in L2TPv3 and L2TPv2 is identical, so you could quite easily use one AVP for the other. That said, if at all possible I would personally prefer to see folks move to L2TPv3 in full, rather than picking and choosing pieces into L2TPv2. > I, personally, am operating on the assumption > that allocating a new l2tp AVP is not outside the charter of this wg. > > I believe allocating such an AVP for l2tp is *much* more feasible than > allocating a corresponding IKE payload to do such a thing for IPsec. You may only have to go so far as to reference existing mechanisms of L2TPv3. I don't see this as protocol definition at all, merely application definition, which I believe is within the charter of this group. > > --Mark From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 3 10:19:23 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 KAA25309 for ; Tue, 3 Dec 2002 10:19: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 gB3FLTq18325 for ; Tue, 3 Dec 2002 10:21:29 -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 gB3FLQY22267 for ; Tue, 3 Dec 2002 10:21:26 -0500 (EST) Message-Id: <200212031520.gB3FKjK0007454@sj-msg-core-1.cisco.com> To: "W. Mark Townsley" cc: Mark Duffy , Joe Touch , Cheng-Yin.Lee@alcatel.com, ppvpn@lyris.nortelnetworks.com Subject: Re: L2TP and IPSec In-reply-to: Your message of Tue, 03 Dec 2002 02:56:51 +0100. <3DEC0F63.7050206@cisco.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: Tue, 03 Dec 2002 10:20:45 -0500 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: Mark> Also, keeping the tunnneling mechanism above IP separate from the Mark> security mechanism of IP allows IPsec to focus on securing IP traffic Mark> between two points, and L2TP to focus on tunneling Layer 2. Well, you should have made that argument some years ago when the IPsec WG was inventing their own tunneling protocol ;-) The problem now is that if one proposes to use L2TP-in-IPsec, someone will point out that this is one tunneling protocol inside another, and that it therefore violates some principle or other of network metaphysics. (Of course, if we use IPsec transport mode we can claim that we have not violated this principle of metaphysics, but of course there's always another principle of metaphysics that can be trottted out ...) I see two arguments in favor of passing PWE3 stuff transparently through IPsec: 1. This allows PWE3 signaling to pass through, and there is no temptation to try to add PWE3 stuff to IPsec signaling. 2. This allows a single SA to carry multiple ethernet links. (I think this is really what Mark Duffy was getting at. Whether the multiple links belong to different VPNs or not is an issue for a higher layer.) I think these are good arguments, but iff one gave no weight to them, then ethernet-in-IP-in-IPsec is what would make the most sense. From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 3 11:37: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 LAA01540 for ; Tue, 3 Dec 2002 11:37: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 gB3GdZq04788 for ; Tue, 3 Dec 2002 11:39: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 gB3GdWY25117 for ; Tue, 3 Dec 2002 11:39:33 -0500 (EST) Message-Id: <5.1.0.14.2.20021203173515.04c0de20@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Dec 2002 17:36:23 +0100 To: erosen@cisco.com From: Eric Vyncke Subject: Re: L2TP and IPSec Cc: "W. Mark Townsley" , Mark Duffy , Joe Touch , Cheng-Yin.Lee@alcatel.com, ppvpn@lyris.nortelnetworks.com In-Reply-To: <200212031520.gB3FKjK0007454@sj-msg-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: strange-brew.cisco.com X-SMTP-MAIL-FROM: evyncke@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: odd-brew.cisco.com [144.254.15.119] X-LYRIS-Message-Id: At 10:20 3/12/2002 -0500, Eric Rosen wrote: >Well, you should have made that argument some years ago when the IPsec WG >was inventing their own tunneling protocol ;-) The problem now is that if While I agree, please note that IPSec tunnel mode is identical to IPinIP protected by IPSec transport mode. So, the real question is rather: why IPSec WG complicated everything ;-) -eric From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 3 11:41:13 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 LAA01759 for ; Tue, 3 Dec 2002 11:41: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 gB3GhPq08111 for ; Tue, 3 Dec 2002 11:43:25 -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 gB3GhMY29829 for ; Tue, 3 Dec 2002 11:43:23 -0500 (EST) Message-ID: <00b201c29aec$39348da0$81c802c0@alok> From: "alok" To: , "Eric Vyncke" Cc: "W. Mark Townsley" , "Mark Duffy" , "Joe Touch" , , References: <5.1.0.14.2.20021203173515.04c0de20@brussels.cisco.com> Subject: Re: L2TP and IPSec Date: Tue, 3 Dec 2002 22:21:11 +0530 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: www.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit say that to GRE too? ----- Original Message ----- From: Eric Vyncke To: Cc: W. Mark Townsley ; Mark Duffy ; Joe Touch ; ; Sent: Tuesday, December 03, 2002 10:06 PM Subject: Re: L2TP and IPSec > At 10:20 3/12/2002 -0500, Eric Rosen wrote: > > >Well, you should have made that argument some years ago when the IPsec WG > >was inventing their own tunneling protocol ;-) The problem now is that if > > While I agree, please note that IPSec tunnel mode is identical to IPinIP protected by IPSec transport mode. So, the real question is rather: why IPSec WG complicated everything ;-) > > -eric > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 3 11:45:52 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 LAA02048 for ; Tue, 3 Dec 2002 11:45:51 -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 gB3Gm7q11515 for ; Tue, 3 Dec 2002 11:48:07 -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 gB3Gm4Y07993 for ; Tue, 3 Dec 2002 11:48:04 -0500 (EST) Message-ID: <3DECDF70.7010603@isi.edu> Date: Tue, 03 Dec 2002 08:44:32 -0800 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: ppvpn@lyris.nortelnetworks.com Subject: Re: L2TP and IPSec References: <5.1.0.14.2.20021203173515.04c0de20@brussels.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: boreas.isi.edu X-SMTP-MAIL-FROM: touch@ISI.EDU X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: boreas.isi.edu [128.9.160.161] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric Vyncke wrote: > At 10:20 3/12/2002 -0500, Eric Rosen wrote: > > >>Well, you should have made that argument some years ago when the IPsec WG >>was inventing their own tunneling protocol ;-) The problem now is that if > > > While I agree, please note that IPSec tunnel mode is identical to > IPinIP protected by IPSec transport mode. So, the real question > is rather: why IPSec WG complicated everything ;-) See draft-touch-ipsec-vpn Although the two generate the same packet on the wire, they differ dramatically in the order of processing of certain steps, and thus capabilities. Joe From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 3 12:27:43 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 MAA04645 for ; Tue, 3 Dec 2002 12:27:43 -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 gB3HTvq05277 for ; Tue, 3 Dec 2002 12:29: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 gB3HTsY16959 for ; Tue, 3 Dec 2002 12:29:54 -0500 (EST) Message-ID: <3DECE2C2.8000300@cisco.com> Date: Tue, 03 Dec 2002 17:58:42 +0100 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: erosen@cisco.com CC: Mark Duffy , Joe Touch , Cheng-Yin.Lee@alcatel.com, ppvpn@lyris.nortelnetworks.com Subject: Re: L2TP and IPSec References: <200212031520.gB3FKjK0007454@sj-msg-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: ams-msg-core-1.cisco.com X-SMTP-MAIL-FROM: townsley@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: ams-msg-core-1.cisco.com [144.254.74.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric Rosen wrote: > > Well, you should have made that argument some years ago when the IPsec WG > was inventing their own tunneling protocol ;-) I did, at the very least for the ipsra space. > I see two arguments in favor of passing PWE3 stuff transparently through > IPsec: > > 1. This allows PWE3 signaling to pass through, and there is no temptation to > try to add PWE3 stuff to IPsec signaling. > > 2. This allows a single SA to carry multiple ethernet links. (I think this > is really what Mark Duffy was getting at. Whether the multiple links > belong to different VPNs or not is an issue for a higher layer.) > > I think these are good arguments, but iff one gave no weight to them, then > ethernet-in-IP-in-IPsec is what would make the most sense. I consider both #1 and #2 significant. I would also consider the functional decomposition of the PWE3 service on top of IP from the securing of the IP connectivity itself as advantageous from a troubleshooting perspective, as well as from a service offering perspective in the case where no, or perhaps a selection of, tunnels need packet-level authentication, encryption, non-repudiation, etc. provided by IPsec. - Mark From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 3 12:59:05 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 MAA06520 for ; Tue, 3 Dec 2002 12:59:05 -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 gB3I1Kq21128 for ; Tue, 3 Dec 2002 13:01: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 gB3I1HY18070 for ; Tue, 3 Dec 2002 13:01:18 -0500 (EST) Message-Id: <200212031759.gB3HxjK0006138@sj-msg-core-1.cisco.com> To: Muneyoshi Suzuki cc: Cheng-Yin.Lee@alcatel.com, "IETF PPVPN list" , pwe3@ietf.org Subject: Re: [PWE3] Re: Bridge or In-reply-to: Your message of Mon, 25 Nov 2002 16:19:05 +0900. <200211250719.QAA27755@infer.nal.ecl.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.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, 03 Dec 2002 12:59:44 -0500 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: > It seems to me, draft-ietf-pwe3-ethernet-encap-01.txt specifies refence > model and protocol for Ethernet MAC frame transport over GRE/LSP tunnel. > It does not emulate anything. Well, I think that draft does a couple of things: 1. It specifies the pseudowire encapsulation for ethernet frames. 2. It specifies how one uses a pseudowire in order to emulate a LAN which has exactly two MACs on it. However, the PW is not itself an emulated LAN, as the emulation includes the NSP functionality, but the NSP is not part of the PW. Other documents, in the PPVPN WG, specify how to use pseudowires to emulate a LAN which has more than two MACs on it. In both cases, I think it is probably correct to say that the PEs are connected via an emulated LAN, while the CEs are connected via an emulated bridged LAN. (In the two-party case, I guess the PE has to be regarded as a vestigial bridge, since it does provide the MAC service, even though it doesn't do any address lookups.) But I'm still puzzled as to whether there is an actual issue here that needs resolution. From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 3 16:34:30 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 QAA19890 for ; Tue, 3 Dec 2002 16:34:29 -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 gB3Laeq21438 for ; Tue, 3 Dec 2002 16:36:41 -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 gB3LabY02031 for ; Tue, 3 Dec 2002 16:36:37 -0500 (EST) From: Message-Id: <-TExnxf.-jkx.-LK-yvACa.-23rWbm.-FYK.-GDxy1.-GHQp4AUY.-FKmJ46.-MNBq2e.-f5Fa4.-FHRJiw.-T3UWuk2VSkCz.-kWmydr1y80mYCr94ZJp3dVS0.-eomZuU.-F5mJo6sO.oY7rQb8JV.oe3spu8.otzUThAuO.o1wUqo@> Subject: Save up to 60% on Toner Cartridges!! [via LSMTP - see www.lsoft.com] Reply-To: dprint2000@aol.com Mime-Version: 1.0 Content-Type: text/plain, charset="iso-8859-1" Date: Tue, 3 Dec 2002 04:31:27 Comments: This message was delivered by an evaluation copy of LSMTP(TM) Comments: running on njcnt5.news-jrnl.com. L-Soft did not author, review Comments: nor edit the present message and therefore assumes no Comments: responsibility for its content. LSMTP evaluation kits are made Comments: available for testing purposes, on the assumption that they will Comments: only be used to deliver information requested by its recipients. X-SMTP-HELO: njcnt5.news-jrnl.com X-SMTP-MAIL-FROM: casa^^^^^@gick.com X-SMTP-RCPT-TO: mleech@nortelnetworks.com,dde@nortelnetworks.com,ksundell@nortelnetworks.com,nascif@nortelnetworks.com,gww@nortelnetworks.com,gsarno@nortelnetworks.com,abbieb@nortelnetworks.com,ppvpn@nortelnetworks.com,gimran@nortelnetworks.com,marco.carugi@nortelnetworks.com,travos@nortelnetworks.com,gparsons@nortelnetworks.com,skshirsa@nortelnetworks.com,taylor@nortelnetworks.com,lyris@nortelnetworks.com X-SMTP-PEER-INFO: [63.237.250.151] X-LYRIS-Message-Id: D & J PRINTING CORPORATION.....CALL US FOR YOUR CARTRIDGE NEEDS Phone 770-974-8228 Fax 770-974-7223 LOOK AT THESE SAVINGS!! UP TO 60% OFF RETAIL PRICES! Goverment,School and University purchase orders WELCOME. "No credit approval required" ***FREE SHIPPING WITH ORDERS OF $300 OR MORE!!*** DJ OEM MODEL APPLICATION UNIT PRICE PART# PART# HEWLETT PACKARD DJ1 C4092A HP Laserjet Series 1100,1100A,3200*****$45 DJ2 C4096A HP Laserjet Series 2100,2200*************$80 DJ3 92295A HP Laserjet Series II,IID,III,IIID*************$43 DJ4 92275A HP Laserjet Series IIP,IIP+,IIIP************$45 DJ5 92291A HP Laserjet Series IIIsi,IVsi****************$80 DJ6 92298A HP Laserjet Series 4,4M,4+,4M+,5,5M,5N*$64 DJ7 92274A HP Laserjet Series 4L,4ML,4P,4MP*******$49 DJ8 C4127X HP Laserjet Series 4000,T,N,TN,4050*****$85 DJ9 C3900A HP Laserjet Series 4V,4MV***************$85 DJ10 C4192X HP Laserjet Series 5000******************$95 DJ11 C3906A HP Laserjet Series 5L,5ML,6L***********$49 DJ12 C3903A HP Laserjet Series 5P,5MP,6P,6MP, 6M*$42 DJ13 C3909A HP Laserjet Series 5si,MX,MOPIER/8000*$85 DJ14 C4182X HP Laserjet Series 8100,N,DN***************$115 DJ15 C7115A HP Laserjet Series 1200*********************$59 APPLE DJ17 M2473G/A Laserwriter Pro 600,630, 16/1600PS********$50 DJ18 M2045G/A Personal Laser writer 300,320,4/600********$45 DJ19 M0089LL/A Personal Laser writer LS,SC,NT,NTR*******$44 DJ20 M6002 Laser Writer 2NT,2NTX,2SC,2F,2G************$44 DJ21 M4683G/A Laser Writer 12/640***************************$65 XEROX DJ22 6R900 Laser Toner LX Engine***********************$46 DJ23 6R903 Laser Toner EX Engine***********************$42 DJ24 6R902 Laser Toner SX Engine***********************$42 LEXMARK DJ25 1380520 Lexmark Optra 4019,4029 High Yield********$87 DJ26 1380950 Lexmark Optra R 4039,4049 High Yield*****$103 DJ27 1382140 Lexmark Optra N*******************************$100 DJ28 1382925 Lexmark Optra S*******************************$125 DJ29 12A5745 Lexmark Optra T*******************************$200 DJ30 12A0725 Lexmark SE************************************$150 DJ31 13T0101 Lexmark E310, E312**************************$73 EPSON DJ32 Epson Action Laser 7000,7500,8000,9000*******$110 DJ33 S051011 Epson Action Laser 1000,1500***************$100 CANON FAX DJ34 CANH116381 Canon Fax Laserclass 4000,4500,300 (FX3)*$47 DJ35 CANH116321220 Canon Fax 5000, 6000,7000(FX2)********$47 DJ36 CANH116401220 Canon Laserfax 8500,9000(FX4)**********$47 CANON COPIER DJ37 F414102710 PC 1,2,2L,2LX,3,3II,6,6RE,7,8,11,12,65**$69 DJ38 F418801750 PC 210 Thru 990(E40-E31)****************$90 DJ39 F418802750 PC 210 Thru 990(E20-E16)****************$90 DJ40 F419921700 PC50/F100**********************************$230 NEC DJ41 NEC NEC Series 2 Model 90, 95 ********************$97 BROTHER DJ42 TN200 FAX2800/2900/3800/MFC4800/6800/DCP1000**$25 DJ43 TN250 FAX2800/2900/3800/MFC4800/6800/DCP1000**$25 DJ44 TN5000PF FAX2800/2900/3800/MFC4800/6800/DCP1000*$25 DJ45 TN300 HL 1040/1050/1060/MFC-P2000 Toner Cartridge*$25 DJ46 TN200 HL 720/730/730DX Toner Cartridge***************$25 DJ47 TN5000PF Intellifax 3550ML/MFC4550/6550/7550MC****$25 ***FREE SHIPPING WITH ORDERS OF $300 OR MORE!!*** -PLACE YOUR ORDER AS FOLLOWS- To order by phone: 770-974-8228 To order by email: dprint2000@aol.com, subject: ORDER To order by mail: D & J Printing Corporation 2564 Cochise Drive Acworth, GA 30102 INCLUDE THE FOLLOWING INFORMATION WHEN YOU PLACE YOUR ORDER: 1) Your phone number 2) Company name/Contact name 3) Shipping address 4) Items and quantity needed 6) Method of payment (Pay by credit card, C.O.D., or purchase order) 7) Credit card number and exp. date when paying with credit card ** IF YOU ARE ORDERING BY PURCHASE ORDER, PLEASE INCLUDE A SEPARATE BILLING ADDRESS AND SHIPPING ADDRESS WHEN NEEDED PLEASE NOTE: * All of our prices are in US dollars. * Free STANDARD shipping with $300 orders. Rush and priority shipping also available for an additional cost. * Standard UPS shipping cost is $6.50 PER ORDER. Add $7.50 to C.O.D. orders. * We accept all major credit cards. * Our standard merchandise replacement policy is net 30 days. * All trade marks and brand names listed above are property of the respective holders and used for descriptive purposes only. ***send email removal request to dprint2000@aol.com subject: REMOVE (Please allow 24 hours for removal) From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 3 16:57:51 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 QAA21016 for ; Tue, 3 Dec 2002 16:57:51 -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 gB3Lxxq01354 for ; Tue, 3 Dec 2002 16:59:59 -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 gB3LxuY28218 for ; Tue, 3 Dec 2002 16:59:57 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "IETF PPVPN list" , pwe3@ietf.org From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [PWE3] Re: Bridge or Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Dec 2002 14:59:45 -0700 Sender: danny@tcb.net Message-Id: <20021203215950.465D155F67@nomad.tcb.net> X-SMTP-HELO: nomad.tcb.net X-SMTP-MAIL-FROM: danny@tcb.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177] X-LYRIS-Message-Id: > Eric Rosen: ... > But I'm still puzzled as to whether there is an actual issue here that needs > resolution. This would be my point as well. I think we're arguing more over semantics rather than any actual issue. -danny From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 3 23:42:32 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 XAA02858 for ; Tue, 3 Dec 2002 23:42:31 -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 gB44iOq07182 for ; Tue, 3 Dec 2002 23:44:25 -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 gB44iMY27753 for ; Tue, 3 Dec 2002 23:44:23 -0500 (EST) Message-Id: <200212040443.NAA00840@infer.nal.ecl.net> To: erosen@cisco.com cc: Muneyoshi Suzuki , Cheng-Yin.Lee@alcatel.com, "IETF PPVPN list" , pwe3@ietf.org Subject: Re: [PWE3] Re: Bridge or In-reply-to: Your message of "Tue, 03 Dec 2002 12:59:44 EST." <200212031759.gB3HxjK0006138@sj-msg-core-1.cisco.com> Date: Wed, 04 Dec 2002 13:43:30 +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: > Well, I think that draft does a couple of things: > 1. It specifies the pseudowire encapsulation for ethernet frames. Agreed. > 2. It specifies how one uses a pseudowire in order to emulate a LAN which > has exactly two MACs on it. However, the PW is not itself an emulated > LAN, as the emulation includes the NSP functionality, but the NSP is not > part of the PW. > Other documents, in the PPVPN WG, specify how to use pseudowires to emulate > a LAN which has more than two MACs on it. > In both cases, I think it is probably correct to say that the PEs are > connected via an emulated LAN, while the CEs are connected via an emulated > bridged LAN. Interesting. If the NSPs emulate a LAN: (1) It must explicitly addressed in section 3 of the draft. (2) Functions of the NSP must be decoupled into LAN and Bridge functions, because, it support VLAN tagging, but this is a part of MAC Relay Entity, especially the E-ISS sub-layer defined in section 7 of IEEE 802.1Q. (3) The NSP must not terminate PAUSE frame, so section 3.1.5 in the draft is incorrect. (4) The VC type in LDP signaling must have the following parameters to identify the LAN segment to be emulated by the NSPs. 1BASE5 10BROAD36 10BASE2 10BASE5 10BASE-F 10BASE-FB 10BASE-FL 10BASE-FP 10BASE-T 100BASE-FX 100BASE-T 100BASE-T2 100BASE-T4 100BASE-TX 100BASE-X 1000BASE-CX 1000BASE-LX 1000BASE-SX 1000BASE-T 1000BASE-X 10GBASE-SR 10GBASE-SW 10GBASE-LX4 10GBASE-LR 10GBASE-LW 10GBASE-ER 10GBASE-EW > (In the two-party case, I guess the PE has to be regarded as a > vestigial bridge, since it does provide the MAC service, even though it > doesn't do any address lookups.) Agreed. > But I'm still puzzled as to whether there is an actual issue here that needs > resolution. I hope this helps to further clarification. Thanks, Muneyoshi Suzuki From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Dec 4 00:06: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 AAA03661 for ; Wed, 4 Dec 2002 00:06: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 gB458m618080 for ; Wed, 4 Dec 2002 00:08:48 -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 gB458jr00248 for ; Wed, 4 Dec 2002 00:08:46 -0500 (EST) Message-Id: <200212040508.OAA00915@infer.nal.ecl.net> To: danny@tcb.net cc: "IETF PPVPN list" , pwe3@ietf.org Subject: Re: [PWE3] Re: Bridge or In-reply-to: Your message of "Tue, 03 Dec 2002 14:59:45 MST." <20021203215950.465D155F67@nomad.tcb.net> Date: Wed, 04 Dec 2002 14:08:09 +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: Danny, > This would be my point as well. I think we're arguing more over > semantics rather than any actual issue. LAN products support MAC frame forwarding as well as Bridge protocols such as STP/RSTP/MSTP and GARP/GMRP/GVRP and MAC control protocols such as PAUSE and LCAP. Handling rules for these protocols in a Bridge or LAN are completely different. Therefore, to verify conformity with existing LAN products, semantics must be clarified first. Otherwise, why can we claim that the PW conforms with existing LAN standards? Thanks, Muneyoshi Suzuki From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Dec 4 02:02:09 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 CAA08881 for ; Wed, 4 Dec 2002 02:02:09 -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 gB474M603147 for ; Wed, 4 Dec 2002 02:04:23 -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 gB474Jr13826 for ; Wed, 4 Dec 2002 02:04:20 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "IETF PPVPN list" , pwe3@ietf.org From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [PWE3] Re: Bridge or Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Dec 2002 00:04:19 -0700 Sender: danny@tcb.net Message-Id: <20021204070424.E089755F67@nomad.tcb.net> X-SMTP-HELO: nomad.tcb.net X-SMTP-MAIL-FROM: danny@tcb.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177] X-LYRIS-Message-Id: > LAN products support MAC frame forwarding as well as Bridge protocols > such as STP/RSTP/MSTP and GARP/GMRP/GVRP and MAC control protocols > such as PAUSE and LCAP. Handling rules for these protocols in a Bridge > or LAN are completely different. Therefore, to verify conformity with > existing LAN products, semantics must be clarified first. Semantics was probably a bad choice of words, though I do believe a large part of the issue here is a misalignment in *terminology*. > Otherwise, why can we claim that the PW conforms with existing LAN > standards? It's important to remember that it's not necessarily a goal for PWE3 to provide exact faithfulness to that of the native protocol (the FW document suggests PWE3 emulates "essential attributes" of a service). As such, with keeping the above in mind, Juergen is correct in stating that "PWE3 defines the transport of L1/L2 client signals over a PSN (paraphrased)". I believe the latter of your concern here was regarding the term used to define the "native protocol" (or "service") itself and do agree aligning terminology certainly makes sense. You folks were OK with "(Ethernet) LAN Emulation" or "Bridged (Ethernet) LAN Emulation", just not "Bridge Emulation", correct? I think we can work with this...? That being said, as Eric stated, while a PW does include NSP functionality for the service that's being emulated, the NSP is NOT part of the PW. Now, back to the first issue: I believe the initial concerns were triggered by Section 3.1.6 of the Ethernet encapsulation draft, where it states that the PAUSE frames MUST NOT be transmitted across a PW (paraphrased). If I'm not mistaken, that text was added quite a while ago in order to suggest [to naive implementers] that it doesn't make sense to forward IEEE802 flow-control frames across a PW/PSN. Being that the "MAC Entity", which resides within the NSP function, provides PAUSE frame termination, perhaps removing the current text and clarifying by employing additional NSP-specific terms will ease your concerns? If so, perhaps you could provide some text here? We should also clarify other NSP functions such as handling CRC errors, framing errors, runt conditions, etc.., and equally, PW functions that result in PW "generalized bit errors" (e.g., out-of-order packets, packet loss, etc..), as Akiva suggests. And we're certainly not providing the "medium connection", between "Medium Dependent Interfaces"! -danny From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Dec 4 06:28:09 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 GAA06311 for ; Wed, 4 Dec 2002 06:28:09 -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 gB4BUN608154 for ; Wed, 4 Dec 2002 06:30:23 -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 gB4BUKr12992 for ; Wed, 4 Dec 2002 06:30:20 -0500 (EST) Message-ID: <03f101c29b89$a3c4be40$81c802c0@alok> From: "alok" To: Subject: VPN End point identification Date: Wed, 4 Dec 2002 17:07:38 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: www.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit +AD4- Hi, +AD4- +AD4- is it possible to pass the end point of an LSP (maybe the IP address of the +AD4- PE in the local IGP topology) as a part of the BGP NLRIs? +AD4- +AD4- im specifically looking at the scenario of the NLRI associated with +AD4- IPv4+-label+-RD as has been seen in the inter-as scenario... +AD4- +AD4- -rgds +AD4- Alok +AD4- From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Dec 4 07:06:57 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 HAA07005 for ; Wed, 4 Dec 2002 07:06: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 gB4C95619742 for ; Wed, 4 Dec 2002 07:09:07 -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 gB4C93r14013 for ; Wed, 4 Dec 2002 07:09:03 -0500 (EST) Message-ID: From: "Marco Carugi" To: ppvpn@nortelnetworks.com Subject: Atlanta PPVPN minutes Date: Wed, 4 Dec 2002 13:08:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29B8D.DA742918" 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_01C29B8D.DA742918 Content-Type: text/plain; charset="iso-8859-1" All, Atlanta PPVPN WG minutes follow. Thanks to Ananth. Please comment on the minutes before Dec 13 so that we can make the required corrections and send them to IETF proceedings. These minutes and all meeting presentations (including my WG status and two presentations not given for lack of time), will be available within tomorrow on the informal PPVPN page http://standards.nortelnetworks.com/ppvpn/calendar.htm Marco **************************************************************************** ******************************************************* PPVPN WG meeting at 55th IETF, Atlanta, GA - Nov 20, 2002 Minutes recorded by Ananth Nagarajan (few additions/changes by Marco Carugi) Marco started with introducing the agenda. Meeting related documents will be posted on Nortel-maintained web site. 1. WG status ------------ Milestones have been recently updated. Layer 3 reqts and framework have been submitted to IESG. We are now at second round of comments, before they move towards Informational RFC. L3 approaches and applicability statements : submission to IESG for publication will be hopefully started in December. Marco also described the status of various documents (these updates have been sent to the mailing list). Last call on draft-ietf-ppvpn-cl-tunneling-vpn-00.txt not successful. Solicited input on whether this should be progressed in the WG. Little support, but most didn't care. Scott - Lack of strong opposition does not mean support. Under WG consideration - generic requirements, l2vpn requirements, vpn DNS-based discovery documents, terminology and metrics. Kireeti - Move to WG - does it mean that it is moved to WG status? If so, it needs call for consensus. Marco - yes, the normal process will be followed. Scott - CL tunneling: Is there support for publishing this as a informational RFC, as opposed to BCP? ASk for consensus on BCP RFC, Info RFC or is against publication? Yakov - BCP means best current practice. Since it is neither, there should be no such option. Scott - Disagreed. Consensus - support from authors for info RFC. None for BCP. About 10 people against publication. A lot of agnostics. Decision - need more discussion on mailing list. Scott - IESG has enough info to take this off the WG agenda. WG last call for draft-nagarajan-ppvpn-generic-reqts after it becomes a WG ID, to be done by end of 2002. Conditional to IESG approval of L3 reqts and framework, 2547bis and VR approaches to be advanced to Proposed standard. Protocol dependencies to be solved and submitted in parallel, together with applicability statements. Other 2547-based solution documents, VR extensions, L3 solution-specific MIBs etc will be advanced in reasonable timing. CE-based IPsec solution has not been updated since Yokohama, along with corresponding AS. Would like to progress this quickly. Design teams: Requirements team task on generic requirements and improvement of L3 and L2 requirements is being done. Some issues: Cooperation terms with IEEE 802.1 need to be figured out. Interaction with related WGs in IETF needs to be done for PPVPN, independently from whether sub-ip area survives or not. Layer 2 interworking for like-to-like is ok, while any-to-any is not currently ok (out of scope), apart from possible specific scenarios. Other work to be progressed includes QoS, management, security framework, multicast etc. for PPVPNs. Input from community is solicited. Liaison received from ITU-T on L1 VPNs was discussed. 2. Generic Requirements - Ananth Nagarajan ------------------------------------------- Ananth described the generic requirements draft and solicited input, especially for the scalability section. Loa talked about the terminology draft that is being simultaneously developed. There was a word of caution on the way this terminology draft would be progressed separately, as it would create problems for proposed solutions if they don't comply wih this. Request acceptance of generic requirements as WG draft. General consensus was for this acceptance. 3. CE-CE Authentication - Ron Bonica ----------------------------------- Ron made a short presentation on main issues related to this work. Process considerations - need BGP extended community type. Need UDP port number for new protocol. Vach expressed a procedural concern about whether PPVPN can do protocols. 4. CE autoconfiguration for CE-based PPVPN - Cheng Yin Lee ---------------------------------------------------------- Cheng Yin described the draft. Issues - is being able to push/update necessary? Is polling sufficient? Combining polling with receive-trigger-then-pull or push approach may be a good compromise (may then reduce polling interval)? 5. IPsec protected Virtual Links for PPVPNs - Mark Duffy -------------------------------------------------------- Virtual Link - point to point link across IP network implemented via tunneling. This is envisioned for CE-based and PE-based vR solutions. This can also be done between CE and PE. It is also useful for 2547, and hybrid networks for securing links between PEs running 2547 and VR. Requirements - multi-context support (multiple virtual links between a given pair of systems). Eric - Does it make sense to have one security association for all vpns, as opposed to separate associations for different vpns. Mark - Yes. Why this is needed? Current efforts don't address the multi context needs of network based VPNs. Issues : How does IPsec policy fit where forwarding decisions are made by best-matched prefix? How should VPN-ID like context be conveyed when a tunnel is established. Draft describes various approaches using combinations of either IPsec tunnel mode or IPsec transport mode with other tunneling schemes. Applicability to ppvpn - standards-based virtual links for adequate security for interoperability between approaches. Eric - There is already a draft on IPsec with 2547. Why is this different? Mark - this is not objecting to that draft, but that is specific to 2547 context. This is more generic. Marco - Is this mandatory before progressing VR? Or is it complementary? Mark - There is no mechanism defined today for securing VR tunnels. If you simply say "use IPsec tunneling between VRs", everyone will be doing it in a different way. Marco - Need further discussion on this. Mark - There is no alternative available in current drafts. Yu-cheng Ren (ISI) - This topic has been addressed by various drafts. Why do we need another (e.g. draft-touch, draft-knight). Mark - these drafts talk about using ipsec tunnels, but doesn't talk about securing multiple links. One of the authors of draft-touch - this is not the case. It talks about ip-in-ip draft. Yu-cheng - Nothing against this draft. Can this not be integrated into framework or requirements drafts? Mark - some part of this can be added. Need discussion on what needs to be included. 6. Use of multiple instance OSPF for PE-CE - Kunihiro Ishiguro -------------------------------------------------------------- Kunihiro presented this draft - "simple way to use ospf for ce-pe". Procedure - Assign OSPF instance to VRF. Benefit - much simpler, can coexist with ospf configurations, and can be applied to is-is. This draft complements Rosen draft (draft-rosen-vpns-ospf-bgp-mpls-05.txt) and overlaps a little bit. Eric - Don't need different procedures to do the same thing. Hoped this would eliminate complicated things in existing mechanisms. 7. L2 VPN design team report - Loa Andersson and others --------------------------------------------- Documents - metrics, terminology, framework (not much work done on these three). L2vpn requirements - significant progress. There was a design team debate on emulated LANs versus bridges. The design team has 22 members, plus several others who contributed that are not on the team. Recommend that design team structure be discontinued and work be continued separately. Requirements - Yetik Serbest ------------ Status - evolving towards common l2vpn requirements (as opposed to individual requirements for vpws, vpls etc.) Aligned with generic requirements draft, definitions moved to terminology draft, sections added on referencing generic reqts, addressing, network resource partitioning/sharing, access control, interoperability. Future work - clarify any issues with what a vpls is, and what it does, and clarify vlans in vpls. Also request feedback. Request moving it to WG status. Loa: The document has a "point-to-multipoint" VPWS, which is wrong and needs to be removed. A: Agreed. Cheng Yin: Is VPLS emulating a bridge or LAN? Yetik - wait for Eric's presentation. Architectural Model - Eric Rosen -------------------------------- Eric described the architectural model, and addressed points of disagreement between IETF and IEEE people, and inter-relationships between VPLS and IEEE bridge/LAN emulation. Other issues - Spanning tree, presumed LAN properties including packet order preservation, reliability, non-duplication, low latency. Loa - Nice powerpointing picture will be converted to ASCII art and used in requirements and framework drafts. Issues of VPLS - Muneyoshi Suzuki --------------------------------- Muneyoshi discussed issues related to customer views, provider views, vpls support etc, routing for LAN/bridge emulation. Norm Finn - IEEE 802.1 unofficial liaison ----------------------------------------- Project authorization request (amendment to 802.1q VLANs) - enable a SP to offer the equivalent of separate LAN segments, bridged or virtual bridged LANs (network of bridges doing l2vpn type services). Name of project - 802.1AD. MAC-in-MAC not possible with this amendment. Confident that IETF L2vpn and 802.1AD will be interoperable, compatible etc if mailing discussions are carried through. Q: how to solve MTU in 802.3 problem? A: Make it longer. This is possible. Cheng Yin - There should be minimum of overlap with vpls and IEEE work. But there will be overlap as IEEE defines Q-in-Q and IETF defines other encapsulation. A: Outer Q tag can be used as Pseudowire header. So there won't be a problem. This is exactly VPLS - just a different way of looking at it. Marco - intention from both sides to minimize overlap. Vach - there is no standard q-in-q way to identify customer packets. What the IEEE is doing in standardizing this may be a good thing. 8. CE-based Virtual PRivate LAN - Cheng Yin LEe ---------------------------------------------- Previous version described use of l2tpv3 for this application. l2tpv3 signaling and tunneling will be taken to l2tpext WG. This model describes the transport of Ethernet over IP tunnels (CE-based). Future work includes failure scenarios, monitoring of vpl connectivity and other l2tpv3 specifications to be done in l2tpext WG. Eric Rosen - Why not IPsec as it is CE-based? Why do use l2tpv3? Cheng Yin - No protocol number for use of ipsec. 9. Identify PW endpoints signaling - Eric Rosen ----------------------------------------------- It is possible that PWE3 owns the signaling portion. l2vpn can be built over pwe3 pseudowires. Problem statement: L2vpn has various autodiscovery. Martini signaling presupposed provisioning models. This solution identifies ways to use martini signaling and make it more applicable to l2vpn. Forwarders will be identified by vpn-id. Eric described various techniques (e.g. Distributed VPLS, VPWS full mesh, switched connection i.e., ATM SVCs to pseudowires). RAhul Aggarwal - Support this as it solves real issues with martini approaches. Marco - need clarification from ADs about this space, and where this needs to be done. Eric - Some of these also apply to l2tp signaling, in addition to martini Yakov - Can you use other forms of identification instead of VPN-ID Eric - yes. Hamid - suggested to use global unique identifiers instead of VPN-IDs Marco - Global ID issues need to be taken to list. 10. Scalability issues with VPLS - Andrew Sodder ------------------------------------------------ This draft has various parts, one part belonging to ieee (mac in mac), other parts to ietf. The draft also proposes vpn identifier and control word use. Many issues left to be addressed - vpls interoperabilty, oam ID work to be done in IEEE. Request continued discussion on list. Rahul Aggarwal - Don't understand motivation for the draft. There is no scaling issue with current mechanisms. This draft request changes to wire format, and requires changes to hardware. A: Depends on who you talk to. Rahul: Depends on which specific vendor box you are talking about. 11. GVPLS/LPE - Dinesh Mohan ----------------------------- Goal - support seamless integration of both distributed and non-distributed vpls models. Allow integration of different access topologies, in a hierarchical way. Other objectives - scalability and performance, optimizaton of replication and support for multicast applications, interoperability with other vpls solutions, integrated oam capability in data plane. The complementary draft-chen-ppvpn-dvpls-compare-01.txt describes comparisons of vpls approaches. Andersson's metrics draft was also mentioned. Future steps - convergence with solutions drafts, signaling, QoS/resiliency, enhance oam capabilities. Marco - comparison draft and metrics draft should be used by the design team. 12. VPLS based on IP multicast - Ali Sajassi ---------------------------------------------- Multicast, if supported on backbone, can be leveraged for vpls. mp2p PW for unicast and mp2mp PW for multicast is proposed. Encapsulation is GRE or l2tpv3. pw signaling is not needed. Issues - packet reordering may occur. Inter AS and IP address management. Sasha Vainshtein - PPVPN scalability parameters in requirements draft not enough for feasability of this draft. Also, all routers in provider core would need to learn routes to all these addresses. Text of the draft doesn't say how unicast addresses are treated by the device (pingable, or something else). A: RFC 1918 specifies private address space. This scheme can be used in hierarchical way (access, core etc.) and thus may tackle scaling issues. Regarding router issues, these can be taken to the list. Eric - VPLS depending on IP multicast sounds foolish. learning based on source address is also not a good idea (fragile). A: Discussion on list Juha - One of the requirements is operability in multi provider environment. Multicast may not be stable in this scenario. We need to take that requirement into account. 13. L2VPN Interworking - Ali Sajassi ------------------------------------- Local attachment circuit termination proposed for various attachment circuit types including ATM, ip, ppp, multiprotocol. Need two new PW types for IP and multiprotocol. Rahul - It may be useful to consider the idea of a "raw" pseudowire that can be used for multiprotocol case. Ali - wouldn't apply for multiprotocol, as it needs identification of protocol. Scott - Interworking out of scope of, when sub-ip was set up. Ali - purpose is not to reinvent the wheel. Just suggesting what pseudowire to use. Marco - Scott, should this continue to be discussed in the Working group. Scott - if it is restated as it was by Ali, it can be done. 14. Summary - Marco ------------------- In Yokohama, it was agreed to propose solutions based on functional structure proposed in L2 solutions design team. Next work steps on L2 were discussed. Functional decomposition of l2 is strongly recommended. No protocol development in ppvpn. Limited set of solutions, so it is not recommended to progress "all theoretically possible solutions". So we need to determine a pragmatic set of alternatives. Main functional blocks identified by DT (various options per block) - discovery, signaling, pw tunneling/data plane forwarding, informational model. Therefore, the functional documents should have a requirements section, option specification section(s), a section on interactions with other functions. Possible organization of deliverables : - N documents per each functional block, one per option - one doc per each functional block (N option-specific sections). A number of mono-option documents is almost done. Different solutions using same option for a specific function should rely on the same functional document. Aggressive plan for L2 DT is to have a DT meeting in January 2003 (1-2 days). Tasks to be completed were identified. It is possible to have another design team (in addition to this one) before the next IETF meeting. **************************************************************************** ********************************************** ------_=_NextPart_001_01C29B8D.DA742918 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Atlanta PPVPN minutes

All, 
Atlanta PPVPN WG minutes follow. = Thanks to Ananth.
Please comment on the minutes before = Dec 13 so that we can make the required corrections and send them to = IETF proceedings.

These  minutes and all meeting = presentations (including my WG status and two presentations not given = for lack of  time),   will be available within tomorrow = on the informal PPVPN page http://standards.nortelnetworks.com/ppvpn/calendar.htm=

Marco

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

PPVPN WG meeting at 55th IETF, = Atlanta, GA - Nov 20, 2002

Minutes recorded by Ananth = Nagarajan  (few additions/changes by  Marco Carugi)

Marco started with introducing the = agenda. Meeting related documents will be
posted on Nortel-maintained web = site.

1. WG status
------------

Milestones have been recently updated. = Layer 3 reqts and framework have been
submitted to IESG. We are now at = second round of comments, before they move
towards Informational RFC.

L3 approaches and applicability = statements : submission to IESG for
publication will be hopefully started = in December.

Marco also described the status of = various documents (these updates have
been sent to the mailing = list).

Last call on = draft-ietf-ppvpn-cl-tunneling-vpn-00.txt not successful.
Solicited input on whether this = should be progressed in the WG. Little
support, but most didn't care.

Scott - Lack of strong opposition does = not mean support.

Under WG consideration - generic = requirements, l2vpn requirements, vpn DNS-based
discovery documents, terminology and = metrics.

Kireeti - Move to WG - does it mean = that it is moved to WG status? If so, it
needs call for consensus.
Marco - yes, the normal process will = be followed.

Scott - CL tunneling:  Is there = support for publishing this as a
informational RFC, as opposed to BCP? = ASk for consensus on BCP RFC, Info RFC
or is against publication?
Yakov - BCP means best current = practice. Since it is neither, there should
be no such option.
Scott - Disagreed.

Consensus - support from authors for = info RFC. None for BCP. About 10 people
against publication. A lot of = agnostics.
Decision - need more discussion on = mailing list.

Scott - IESG has enough info to take = this off the WG agenda.

WG last call for = draft-nagarajan-ppvpn-generic-reqts after it becomes a WG
ID, to be done by end of 2002.

Conditional to IESG approval of L3 = reqts and framework, 2547bis and VR
approaches to be advanced to Proposed = standard.  Protocol dependencies to be
solved and submitted in parallel, = together with applicability statements.

Other 2547-based solution documents, = VR extensions, L3 solution-specific
MIBs etc will be advanced in = reasonable timing.

CE-based IPsec solution has not been = updated since Yokohama, along with
corresponding AS.  Would like to = progress this quickly.

Design teams:
Requirements team task on generic = requirements and improvement of L3 and L2
requirements is being done.

Some issues: Cooperation terms with = IEEE 802.1 need to be figured out.
Interaction with related WGs in IETF = needs to be done for PPVPN, independently
from whether sub-ip area survives or = not.  Layer 2 interworking for
like-to-like is ok, while any-to-any = is not currently ok (out of scope),
apart from possible specific = scenarios.

Other work to be progressed includes = QoS, management, security framework,
multicast etc. for PPVPNs. Input from = community is solicited.

Liaison received from ITU-T on L1 VPNs = was discussed.


2. Generic Requirements - Ananth = Nagarajan
-------------------------------------------

Ananth described the generic = requirements draft and solicited input,
especially for the scalability = section.  Loa talked about the terminology
draft that is being simultaneously = developed.  There was a word of caution
on the way this terminology draft = would be progressed separately, as it
would create problems for proposed = solutions if they don't comply wih this.

Request acceptance of generic = requirements as WG draft.
General consensus was for this = acceptance.

3. CE-CE Authentication - Ron = Bonica
-----------------------------------

Ron made a short presentation on main = issues related to this work.

Process considerations - need BGP = extended community type. Need UDP port
number for new protocol.
Vach expressed a procedural concern = about whether PPVPN can do protocols.


4. CE autoconfiguration for CE-based = PPVPN - Cheng Yin Lee
---------------------------------------------------------= -

Cheng Yin described the draft.

Issues - is being able to push/update = necessary? Is polling sufficient?
Combining polling with = receive-trigger-then-pull or push approach may be a
good compromise (may then reduce = polling interval)?

5. IPsec protected Virtual Links for = PPVPNs - Mark Duffy
--------------------------------------------------------<= /FONT>

Virtual Link - point to point link = across IP network implemented via
tunneling. This is envisioned for = CE-based and PE-based vR solutions. This
can also be done between CE and = PE.  It is also useful for 2547, and hybrid
networks for securing links between = PEs running 2547 and VR.

Requirements - multi-context support = (multiple virtual links between a given
pair of systems).

Eric - Does it make sense to have one = security association for all vpns, as
opposed to separate associations for = different vpns.
Mark - Yes.

Why this is needed? Current efforts = don't address the multi context needs of
network based VPNs.
Issues : How does IPsec policy fit = where forwarding decisions are made by
best-matched prefix?  How should = VPN-ID like context be conveyed when a
tunnel is established.

Draft describes various approaches = using combinations of either IPsec tunnel
mode or IPsec transport mode with = other tunneling schemes.

Applicability to ppvpn - = standards-based virtual links for adequate security
for interoperability between = approaches.

Eric - There is already a draft on = IPsec with 2547. Why is this different?
Mark - this is not objecting to that = draft, but that is specific to 2547
context. This is more generic.

Marco - Is this mandatory before = progressing VR? Or is it complementary?
Mark - There is no mechanism defined = today for securing VR tunnels. If you
simply say "use IPsec tunneling = between VRs", everyone will be doing it in a
different way.

Marco - Need further discussion on = this.
Mark - There is no alternative = available in current drafts.

Yu-cheng Ren (ISI) - This topic has = been addressed by various drafts.  Why
do we need another (e.g. draft-touch, = draft-knight).
Mark - these drafts talk about using = ipsec tunnels, but doesn't talk about
securing multiple links.
One of the authors of draft-touch - = this is not the case. It talks about
ip-in-ip draft.
Yu-cheng - Nothing against this = draft. Can this not be integrated into
framework or requirements = drafts?
Mark - some part of this can be = added. Need discussion on what needs to be
included.

6. Use of multiple instance OSPF for = PE-CE - Kunihiro Ishiguro
---------------------------------------------------------= -----

Kunihiro presented this draft - = "simple way to use ospf for ce-pe".
Procedure - Assign OSPF instance to = VRF.

Benefit - much simpler, can coexist = with ospf configurations, and can be
applied to is-is.

This draft complements Rosen draft = (draft-rosen-vpns-ospf-bgp-mpls-05.txt)
and overlaps a little bit.

Eric - Don't need different procedures = to do the same thing. Hoped this
would eliminate complicated things in = existing mechanisms.

7. L2 VPN design team report - Loa = Andersson and others
---------------------------------------------

Documents - metrics, terminology, = framework (not much work done on these
three). L2vpn requirements - = significant progress. There was a design team
debate on emulated LANs versus = bridges.

The design team has 22 members, plus = several others who contributed that are
not on the team.  Recommend that = design team structure be discontinued and
work be continued separately.

Requirements - Yetik Serbest
------------

Status - evolving towards common l2vpn = requirements (as opposed to
individual requirements for vpws, = vpls etc.)
Aligned with generic requirements = draft, definitions moved to terminology
draft, sections added on referencing = generic reqts, addressing, network
resource partitioning/sharing, access = control, interoperability.

Future work - clarify any issues with = what a vpls is, and what it does, and
clarify vlans in vpls.  Also = request feedback.

Request moving it to WG status.

Loa: The document has a = "point-to-multipoint" VPWS, which is wrong and needs
to be removed.
A: Agreed.

Cheng Yin: Is VPLS emulating a bridge = or LAN?
Yetik - wait for Eric's = presentation.

Architectural Model - Eric = Rosen
--------------------------------

Eric described the architectural = model, and addressed points of disagreement
between IETF and IEEE people, and = inter-relationships between VPLS and IEEE
bridge/LAN emulation.

Other issues - Spanning tree, presumed = LAN properties including packet order
preservation, reliability, = non-duplication, low latency.

Loa - Nice powerpointing picture will = be converted to ASCII art and used in
requirements and framework = drafts.

Issues of VPLS - Muneyoshi = Suzuki
---------------------------------
Muneyoshi discussed issues related to = customer views, provider views, vpls
support etc, routing for LAN/bridge = emulation.

Norm Finn - IEEE 802.1 unofficial = liaison
-----------------------------------------

Project authorization request = (amendment to 802.1q VLANs) - enable a SP to
offer the equivalent of separate LAN = segments, bridged or virtual bridged
LANs (network of bridges doing l2vpn = type services).

Name of project - 802.1AD.
MAC-in-MAC not possible with this = amendment.

Confident that IETF L2vpn and 802.1AD = will be interoperable, compatible etc
if mailing discussions are carried = through.

Q: how to solve MTU in 802.3 = problem?
A: Make it longer. This is = possible.

Cheng Yin - There should be minimum of = overlap with vpls and IEEE work.  But
there will be overlap as IEEE defines = Q-in-Q and IETF defines other
encapsulation.
A: Outer Q tag can be used as = Pseudowire header. So there won't be a
problem.
This is exactly VPLS - just a = different way of looking at it.

Marco - intention from both sides to = minimize overlap.

Vach - there is no standard q-in-q way = to identify customer packets.  What
the IEEE is doing in standardizing = this may be a good thing.


8. CE-based Virtual PRivate LAN - = Cheng Yin LEe
----------------------------------------------

Previous version described use of = l2tpv3 for this application. l2tpv3
signaling and tunneling will be taken = to l2tpext WG.

This model describes the transport of = Ethernet over IP tunnels (CE-based).

Future work includes failure = scenarios, monitoring of vpl connectivity and
other l2tpv3 specifications to be = done in l2tpext WG.

Eric Rosen - Why not IPsec as it is = CE-based?  Why do use l2tpv3?
Cheng Yin - No protocol number for = use of ipsec.

9. Identify PW endpoints signaling - = Eric Rosen
-----------------------------------------------

It is possible that PWE3 owns the = signaling portion. l2vpn can be built over
pwe3 pseudowires.

Problem statement: L2vpn has various = autodiscovery. Martini signaling
presupposed provisioning models. This = solution identifies ways to use
martini signaling and make it more = applicable to l2vpn.

Forwarders will be identified by = vpn-id.

Eric described various techniques = (e.g. Distributed VPLS, VPWS full mesh,
switched connection i.e., ATM SVCs to = pseudowires).

RAhul Aggarwal - Support this as it = solves real issues with martini
approaches.
Marco - need clarification from ADs = about this space, and where this needs
to be done.
Eric - Some of these also apply to = l2tp signaling, in addition to martini

Yakov - Can you use other forms of = identification instead of VPN-ID
Eric - yes.
Hamid - suggested to use global = unique identifiers instead of VPN-IDs
Marco - Global ID issues need to be = taken to list.


10. Scalability issues with VPLS - = Andrew Sodder
------------------------------------------------
This draft has various parts, one = part belonging to ieee (mac in mac), other
parts to ietf.
The draft also proposes vpn = identifier and control word use.

Many issues left to be addressed - = vpls interoperabilty, oam ID work to be
done in IEEE.

Request continued discussion on = list.

Rahul Aggarwal - Don't understand = motivation for the draft. There is no
scaling issue with current = mechanisms. This draft request changes to wire
format, and requires changes to = hardware.
A: Depends on who you talk to.
Rahul: Depends on which specific = vendor box you are talking about.

11. GVPLS/LPE - Dinesh Mohan
-----------------------------
Goal - support seamless integration = of both distributed and non-distributed
vpls models. Allow integration of = different access topologies, in a
hierarchical way.
Other objectives - scalability and = performance, optimizaton of replication
and support for multicast = applications, interoperability with other vpls
solutions, integrated oam capability = in data plane.

The complementary = draft-chen-ppvpn-dvpls-compare-01.txt describes comparisons of vpls =
approaches. Andersson's metrics draft = was also mentioned.

Future steps - convergence with = solutions drafts, signaling, QoS/resiliency,
enhance oam capabilities.

Marco - comparison draft and metrics = draft should be used by the design
team.

12. VPLS based on IP multicast - Ali = Sajassi
----------------------------------------------

Multicast, if supported on backbone, = can be leveraged for vpls.
mp2p PW for unicast and mp2mp PW for = multicast is proposed.

Encapsulation is GRE or l2tpv3. pw = signaling is not needed.
Issues - packet reordering may = occur.  Inter AS and IP address management.

Sasha Vainshtein - PPVPN scalability = parameters in requirements draft not
enough for feasability of this draft. = Also, all routers in provider core
would need to learn routes to all = these addresses.  Text of the draft
doesn't say how unicast addresses are = treated by the device (pingable, or
something else).
A: RFC 1918 specifies private address = space. This scheme can be used in
hierarchical way (access, core etc.) = and thus may tackle scaling issues.
Regarding router issues, these can be = taken to the list.

Eric - VPLS depending on IP multicast = sounds foolish.  learning based on
source address is also not a good = idea (fragile).
A: Discussion on list

Juha - One of the requirements is = operability in multi provider environment.
  Multicast may not be stable in = this scenario.  We need to take that
requirement into account.

13. L2VPN Interworking - Ali = Sajassi
-------------------------------------

Local attachment circuit termination = proposed for various attachment circuit
types including ATM, ip, ppp, = multiprotocol. Need two new PW types for IP
and multiprotocol.

Rahul - It may be useful to consider = the idea of a "raw" pseudowire that can
be used for multiprotocol = case.
Ali - wouldn't apply for = multiprotocol, as it needs identification of
protocol.

Scott - Interworking out of scope of, = when sub-ip was set up.
Ali - purpose is not to reinvent the = wheel. Just suggesting what pseudowire
to use.
Marco - Scott, should this continue = to be discussed in the Working group.
Scott - if it is restated as it was = by Ali, it can be done.

14. Summary - Marco
-------------------

In Yokohama, it was agreed to propose = solutions based on functional structure
proposed in L2 solutions design = team.  Next work steps on L2 were discussed.
Functional decomposition of l2 is = strongly recommended. No protocol development in
ppvpn.  Limited set of = solutions, so it is not recommended to progress "all
theoretically possible = solutions". So we need to determine a pragmatic set
of alternatives.

Main functional blocks identified by = DT (various options per block)
- discovery, signaling, pw = tunneling/data plane forwarding, informational model. 
Therefore, the functional documents = should have a requirements section,
option specification section(s), a = section on interactions with other functions.

Possible organization of deliverables = :
- N documents per each functional = block, one per option
- one doc per each functional block = (N option-specific sections).

A number of mono-option documents is = almost done.

Different solutions using same option = for a specific function should rely on
the same functional document.

Aggressive plan for L2 DT is to have a = DT meeting in January 2003 (1-2
days). Tasks to be completed were = identified.

It is possible to have another design = team (in addition to this one) before
the next IETF meeting.

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




------_=_NextPart_001_01C29B8D.DA742918-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Dec 4 09:24:41 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 JAA12634 for ; Wed, 4 Dec 2002 09:24: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 gB4EQu607806 for ; Wed, 4 Dec 2002 09:26: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 gB4EQrr19161 for ; Wed, 4 Dec 2002 09:26:54 -0500 (EST) Message-Id: <200212041426.gB4EQKS36480@merlot.juniper.net> To: "Marco Carugi" cc: ppvpn@nortelnetworks.com Subject: Re: Atlanta PPVPN minutes In-Reply-To: Your message of "Wed, 04 Dec 2002 13:08:28 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31305.1039011980.1@juniper.net> Date: Wed, 04 Dec 2002 06:26:20 -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, > Atlanta PPVPN WG minutes follow. Thanks to Ananth. > Please comment on the minutes before Dec 13 so that we can make the required > corrections and send them to IETF proceedings. > These minutes and all meeting presentations (including my WG status and two > presentations not given for lack of time), will be available within > tomorrow on the informal PPVPN page > http://standards.nortelnetworks.com/ppvpn/calendar.htm [clipped...] > 9. Identify PW endpoints signaling - Eric Rosen > ----------------------------------------------- > > It is possible that PWE3 owns the signaling portion. l2vpn can be built over > > pwe3 pseudowires. > > Problem statement: L2vpn has various autodiscovery. Martini signaling > presupposed provisioning models. This solution identifies ways to use > martini signaling and make it more applicable to l2vpn. > > Forwarders will be identified by vpn-id. > > Eric described various techniques (e.g. Distributed VPLS, VPWS full mesh, > switched connection i.e., ATM SVCs to pseudowires). > > RAhul Aggarwal - Support this as it solves real issues with martini > approaches. > Marco - need clarification from ADs about this space, and where this needs > to be done. > Eric - Some of these also apply to l2tp signaling, in addition to martini > > Yakov - Can you use other forms of identification instead of VPN-ID Please reflect in the minutes that I asked specifically whether one could use the form used by the Route Target BGP Extended Community. Yakov. From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Dec 4 14:14:48 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 OAA29108 for ; Wed, 4 Dec 2002 14:14:47 -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 gB4JGa621040 for ; Wed, 4 Dec 2002 14:16: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 gB4JGYr16733 for ; Wed, 4 Dec 2002 14:16:34 -0500 (EST) Date: Wed, 4 Dec 2002 14:13:54 -0500 (EST) From: Scott Bradner Message-Id: <200212041913.gB4JDshs001997@newdev.harvard.edu> To: ppvpn@nortelnetworks.com Subject: in case you have not seen this: IETF Sub-IP area: request for input X-SMTP-HELO: newdev.harvard.edu X-SMTP-MAIL-FROM: sob@newdev.harvard.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: newdev.eecs.harvard.edu [140.247.60.212] X-LYRIS-Message-Id: IETF SUB-IP area The IESG announced in November of 2000 that a new SUB-IP temporary pseudo-area would be formed as a part of an effort to develop a "systematic approach to dealing with what we used to describe as "sub-IP" technologies." At the time the IESG said: "Over the years the boundary between 'wires' and IP protocols has become harder to define and the interaction has become more intertwined. For example, what appear as 'wires' or 'circuits' in a virtual network may in fact be routed datagrams in an underlying IP network. The topology of dynamic underlying networks such as ATM and soon switched optical networks can interact with IP-level traffic engineering and routing. Additionally, with IETF technologies such as MPLS we are defining a whole new class of 'wires'." (http://www.ietf.org/IESG/STATEMENTS/new-area.txt) After the December 2000 IETF meeting and taking into account the discussion at that meeting the IESG formed a "temporary" SUB-IP Area. IN the announcement of this action the IESG said: "It is temporary because the IESG believes that this concentrated sub-IP effort will likely be of short duration, on the order of a year or two. We feel that much of the work will be done by then, and the working groups closed. Any working groups that have not finished when the IESG determines that the area should be closed will be moved into existing the IETF areas where they seem to have the best fit." and "The IESG expects to review the development process and charters, however; if we conclude that this expectation is incorrect, we will need to make this area more formal. At that point, the nominating committee will be asked to supply dedicated area directors." (http://www.ietf.org/IESG/STATEMENTS/sub_area.txt) Although the SUB-IP working groups have made considerable progress (with 7 RFCs published, another 12 IDs approved for publication, 9 IDs under IESG consideration and an additional 11 IDs having been passed to the ADs for their evaluation) their work is not yet done (with 53 working group IDs currently in progress). It does appear that some of the working groups could finish the work in their charters over the next 6 months but it could be a lot longer for others. Because the end is in sight for some of the working groups and since the IESG had generally assumed that the area would be a temporary one and the second anniversary of the creation of the SUB-IP area is next spring, analysis was started in the IESG to figure out which areas would be the best ones for the SUB-IP working groups to move to so that they could continue their work. As part of that analysis a SUB-IP area session was held during the IETF meeting in Atlanta where this topic was discussed. There was a spirited discussion during the session on the best path forward. The opinions ranged from following the distribution of working groups, to doing so with some specific changes to keeping the working groups in a separate SUB-IP area. A sense of the room was taken at the end of the discussion and that sense was very strongly that the SUB-IP Area should become a "long-term" (the description that was used during the consensus call) one and that the nomcom be asked to nominate a person (or persons) to become director(s) of the SUB-IP area. To help provide more information as input for the IESG discussion we would like to continue the discussion started in Atlanta on the mailing list. It is our intention to keep the discussion on the future of the SUB-IP area open, but short-lived, because it would be a very good idea to let the nomcom know ASAP what the future holds as they need to know what expertise is needed in the ADs for the existing areas and if they need to search for additional people. The IESG aim is to be able to let the nomcom know what the future of the SUB-IP work is by the end of the day of Thursday Dec 12th. That date was chosen because it is the date of the next IESG teleconference yet it provides some time for a public discussion. The options seem to be: 1/ move WGs (back) to permanent areas: migrate the SUB-IP working groups to other IETF areas sometime soon, likely before next summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or other) directorates to ensure the continued coordination between the remaining WGs. 2/ establish a long-term area: decide that the SUB-IP area will be a long-term one, clearly define its charter, and ask the nomcom to select one or two people to be Area Directors 3/ status quo: continue the SUB-IP Area as a temporary, ad-hoc effort, much as it has been, with the IESG selecting two sitting ADs to continue the effort that Bert & Scott have been doing. But maybe give more responsibility to the working group's technical advisors, normally the AD from the area where the working group might otherwise live. Data points for the discussion: DP1. It does look like a number of the SUB-IP working groups will be finishing up their main work in the next year and be ready to be closed until it is time to revise the RFCs based on experience or to advance them on the standards track. The groups that should be finishing up include ipo, gsmp and tewg. That would leave mpls, ppvpn and ccamp. DP2. WGs in SUB-IP or the work pursued in them came from existing well-established areas, i.e., tewg came from OPS, gsmp, mpls (with ccamp and ppvpn as its derivatives) came from RTG. DP3. There's still a need for technical oversight from permanent areas, so some WGs have a technical advisor--normally the AD from the area where the working group might otherwise live (e.g. CCAMP, and PPVPN with a RTG AD as the TA). DP4. SUB-IP directorate was very useful when the area was just created. It is currently passive and WGs continue operating just fine. DP5. The sense of the SUB-IP session in Atlanta was that the SUB-IP Area was working and there is no compelling reason to break it up. There is a need to clarify the charters of some of the working groups so that the different groups understand what the division of tasks are but it is hard to identify what problem would be solved by breaking up the area. DP6. Extensions to specific IETF technologies should be done in the working groups responsible for those technologies based on requirements provided by other working groups. For example, extensions to OSPF should be done by the OSPF working group based on input from other working groups or individuals rather than being done someplace else. Discussions about the options: 1/ Move WGs (back) to permanent areas and close the area For: Each WG within SUB-IP definitely has a strong feature that maps it to a given permanent area [1]. The property that logically holds them together in SUB-IP now is the need for coordination wrt the technologies that are normally considered below the IP layer. While this was indeed necessary right after SUB-IP creation, DP4 suggests that the goal has been achieved and the focus is shifting back to coordination with permanent areas (e.g., DP3, as well as the fact that RTG WGs are already dealing with SUB-IP related extensions). DP1 suggests that there will be about three active WGs within a year; at least two of them can be argued to belong in RTG area (where they originally came from, see DP2), so it wouldn't make a lot of sense to have two separate areas overlapping so considerably. PPVPN does not map strongly to any area, however it doesn't map strongly to SUB-IP either (MPLS is just one possible encapsulation method) Against: DP5 suggests that the feeling in the room was against closing the area, though there was also some support for the idea that moving MPLS and CCAMP to RTG would be a fine idea if the area were to be closed. The feeling was that the area has been working and that there is no strong argument that there is a need to change things at this time. 2/ Establish a long-term area For: DP5 suggests that the community believes this is a good idea. See also the "Against" for option 1. In addition the opinion was expressed that having a specific area with specifically assigned management, knowledgeable in the field, would be an advantage. In addition, new SUP-IP work may develop in the future and it would be good to have a home for it. Against: See "For" arguments for option 1 above. Also, there was an assumption when the area was formed that it would be temporary and the size of the IESG is near max effective size. It is also expected that if the nomcom needs to find an AD(s) for SUB-IP, the set of required skills would be extremely similar to those needed for the RTG area, which again brings up the question of whether it makes sense to have two areas with so similar expertise scopes. 3/ Status quo For: DP5 suggests that the way the area operates is fine and does not need fixing at this time. As DP1 predicts, there may not be many active SUB-IP working groups within a year and it may be best to wait until a few of the working groups finish their work and close before deciding on the long term direction for this work. The IESG would decide which ADs would be asked to manage the area in March. Against: A decision has to be made sooner or later, delaying the decision will not make it any easier to make. The IESG would like to hear from the community on this topic - please direct your comments to the ietf@ietf.org list. The IESG will discuss the matter in its next telechat on December 12. -------------------------------------------------- [1] possible WG to area mappings: - IPO has the IP-over-foo property, which is usually addressed in INT, - GSMP came from RTG - MPLS (aside from the fact that it came from RTG) deals with a technology that is arguably another IP forwarding paradigm and relies heavily on regular routing functionality and/or protocols. - CCAMP works on a generalized version of MPLS, which could map it to RTG as well - TEWG came from O&M - PPVPN: suggestions have been made of INT, because its tunneling which is closest to INT, RTG because some of the suggested discovery and VPN routing mechanisms, and TSV, because its related to PWE3 (in TSV because of congestion control worries) From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Dec 5 13:58:57 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 NAA23754 for ; Thu, 5 Dec 2002 13:58:57 -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 gB5J0dx19132 for ; Thu, 5 Dec 2002 14:00:40 -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 gB5J0ar25264 for ; Thu, 5 Dec 2002 14:00:36 -0500 (EST) Message-ID: <3DEFA22F.E796D724@cisco.com> Date: Thu, 05 Dec 2002 10:59:59 -0800 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Cheng-Yin.Lee@alcatel.com CC: IETF PPVPN list , pwe3@ietf.org Subject: Re: Bridge or References: <3DDBE6D9.157B6E1D@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: nfinn@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: Content-Transfer-Encoding: 7bit This is an old thread (Nov. 20), but let me take a crack at your questions. These questions will be examined very carefully by IEEE P802.1, and I'm sure, will be answered at some point. Cheng-Yin Lee wrote: > > May I know if these two questions have been clarified yet: > 1) Is VPLS emulating LAN or bridges? > 2) what's the difference between emulating Ethernet and LAN? > 1) Is VPLS emulating LAN or bridges? Neither. Also, both. The problem is that the differences between a LAN and a bridge (other than timing, of course) are really a collection of differences in how certain L2 protocols are handled. A customer may want to make a choice on a per-protocol basis, instead of an all-or-nothing "bridge or LAN" choice. Furthermore, there are some new possibilities which are not applicable to either a bridge or a LAN, at present. Physical LAN Provider protocol segment Bridge Service 802.3x pause frames xparent engage or (a) suppress .3 Link Aggregation xparent engage or (b) suppress 802.1X Port Access xparent engage or (b) suppress 802.1D/W/S BPDUs xparent engage (c) 802.1D GMRP xparent engage or (d) xparent 802.1Q GVRP xparent engage or (d) xparent L3 data xparent xparent xparent (a) The provider must not pass 802.3x pause frames through the service. The timing assumed by 802.3x cannot be met by an L2-over-L3 service. (b) The customer may wish to run these protocols, especially 802.1X, either 1) between the customer and the provider; 2) end-to-end; or 3) both! (This requires extensions to 802.1X.) Furthermore, the 802.1X authentication may be desirable on what is, otherwise, a transparent "LAN"-like service. (c) A provider "LAN-like" service may transport a customer's BPDUs end-to-end. However, it is unlikely that the provider will handshake with a customer's BPDUs, and thus concatenate the Provider's spanning tree with all of the customers' spanning trees. So, the "bridge" option is not available. (d) Similar to (c), but some use may well be found for these protocols in controlling the delivery of a customer's multicast MAC addresses and/or VLANs. Easier to suppress them, however, in a "bridge-like" service. There are many more protocols to consider, of course, but the answers are similar. > 2) what's the difference between emulating Ethernet and LAN? Not clear to me what you mean. In general, "LAN" includes 802.5 Token Ring, FDDI, 802.11 wireless, etc. etc. Nobody cares much about anything except Ethernet, any more. If you meant the difference between emulating an Ethernet and emulating a VLAN, the difference is in the eyes of the beholder. To a router, they're the same thing. To a bridge, a VLAN has no independent existence; it is just an extra filter applied to frames that are bridged from Ethernet to Ethernet. Therefore, some number of emulated VLANs are grouped together and treated as a single emulated Ethernet, which has no existence outside the bridge. I hope this rather long-winded explanation helps. -- Norm From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Dec 5 15:05:55 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 PAA26050 for ; Thu, 5 Dec 2002 15:05:55 -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 gB5K86x02424 for ; Thu, 5 Dec 2002 15:08:06 -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 gB5K83r14135 for ; Thu, 5 Dec 2002 15:08:03 -0500 (EST) Message-ID: <3DEFB1FF.5EEAA427@cisco.com> Date: Thu, 05 Dec 2002 12:07:27 -0800 From: Norman Finn X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,ja,ru,de,zh MIME-Version: 1.0 To: Cheng-Yin.Lee@alcatel.com CC: IETF PPVPN list Subject: Re: IEEE 802.1 actions on Provider Bridges References: <3DDB2276.23F1A4C8@cisco.com> <3DE64157.6573B6F@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-msg-core-4.cisco.com X-SMTP-MAIL-FROM: nfinn@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-4.cisco.com [171.71.163.54] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Cheng-Yin Lee wrote: > > 4. There is every expectation that 802.1AD and VPLS will be perfectly > > compatible, interoperable, and have a minimum of overlap, with the > > L2-VPNs defined by PPVPN, > > > > I believe there is function overlap in IEEE Q in Q work and VPLS. To me, minimum overlap would imply using IEEE functions where applicable rather than specifying something in parallel. I certainly wouldn't argue with you, there. :) > > partitioning of the functions of an > > NPE or a PE-rs into a "provider bridge" and some number of > > "Emulated LAN Segments" are carried through. > > > Could you kindly elaborate on the above partitioning of functions pls? This is explained much more thoroughly in the slides at: http://p8021:~go_wildcats@www.ieee802.org/1/mirror/8021/docs2002/bridge-based-ether-prov-2.pdf -- Norm > Norman Finn wrote: > > > To summarize, unofficially (I have no official liaison position), what > > happened with regard to L2 service providers at the IEEE P802.1 meeting > > last week: > > > > 1. P802.1 forwarded a Project Authorization Request to start 802.1AD, > > an amendment to IEEE Std. 802.1Q-1998 (the VLAN standard) to cover > > Provider Bridges. (Relevant portions of PAR follow my signature.) > > > > 2. We can expect 802.1AD to specify the operation of a provider's > > Bridged LAN offering Layer 2 services. The primary foci are > > expected to be the Provider/Customer interface, and Q-over-Q tag > > operations. We can expect it to use an outer 802.1Q tag, where > > needed, to differentiate among different customers' services. > > > > 3. Given that this project will be an amendment to 802.1Q, MAC-in-MAC > > techniques will not be a possibility. That does not rule out some > > type of MAC-in-MAC technique, for either this or for other > > purposes, in the future. > > > > 4. There is every expectation that 802.1AD and VPLS will be perfectly > > compatible, interoperable, and have a minimum of overlap, with the > > L2-VPNs defined by PPVPN, assuming that the recent dt-l2vpn mailing > > list discussions regarding the partitioning of the functions of an > > NPE or a PE-rs into a "provider bridge" and some number of > > "Emulated LAN Segments" are carried through. > > > > -- Norm > > > > RELEVANT PARTS OF 802.1AD PAR: > > > > TITLE OF DOCUMENT: Standard for Local and Metropolitan Area Networks. > > Virtual Bridged Local Area Networks. Amendment 4: Provider Bridges. > > > > SCOPE: To develop an architecture and bridge (-1-) protocols, compatible > > and interoperable with existing Bridged Local Area Network protocols and > > equipment, to provide separate instances of the MAC service (-3-) to > > multiple independent users of a Bridged Local Area Network (-1-, -2-) in a > > manner that does not require cooperation among the users, and requires a > > minimum of cooperation between the users and the provider of the MAC > > service. To define basic management of users' MAC services. > > > > References: -1- IEEE Std. 802.1D, -2- IEEE Std. 802.1Q, -3- IEEE Std. 802, > > -4- IEEE P802.1S. > > > > PURPOSE: This standard will enable a Service Provider to offer the > > equivalent of separate LAN Segments, Bridged or Virtual Bridged LANs, > > to a number of users, over the Provider's bridged network. This Standard > > will enable the use of the architecture and protocols of IEEE Std 802.1Q, > > and provide for interoperability and consistent management. From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Dec 5 16:39:48 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 QAA01292 for ; Thu, 5 Dec 2002 16:39:48 -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 gB5Lfxx20178 for ; Thu, 5 Dec 2002 16:41:59 -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 gB5Lfvr22577 for ; Thu, 5 Dec 2002 16:41:57 -0500 (EST) Message-Id: <200212052140.gB5LewX08026@zcars0mt.ca.nortel.com> From: "Haja" To: Subject: From Brunei Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 5 Dec 2002 22:40:52 X-SMTP-HELO: your-tx4s5p2lf6 X-SMTP-MAIL-FROM: h2laila@email.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: a71032.upc-a.chello.nl [62.163.71.32] X-LYRIS-Message-Id: Dear Sir, My name is Haja I am a 23 years old and a British citizen who was taken to Brunei by my father at the young age of 12. He deceived me that I was going there on vacation and later married me off to a wealthy Prince in Brunei who is 30 years older than me. I was thus forced into marriage and when I objected I was beaten and raped by this Prince. I was locked up in a house for two years after which I submitted and decided to accept my faith, knowing that was the only way out. After I got my freedom back I have been allowed by my husband to have access to his businesses. Over the years I am been able to acquire some money $16,000,000.00 ( Sixteen million dollars),which I diverted into a private finance house in Darussalam without his knowledge. Right now I have mapped out a plan of escape out of Brunei, first of all I want to move the fund out of the Brunei. This is where I need your assistance, I will move the fund out of Brunei on your name through a Cargo courier company to Europe to avoid been detected by my husband. After which you will help me secure the fund before I get out of Brunei. If you know you are capable of handling such a huge amount of money respond to me and I will compensate you by giving you 10% of the total fund. Note also that you must keep this transaction secret as my life is at stake if my husband or any of his relatives hear of this transaction they will stone me to death or hang me. I await your quick response. ( dot24@mail.com or 800y2k@mail.com ) Yours faithfully, Haja From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Dec 5 23:39:44 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 XAA13744 for ; Thu, 5 Dec 2002 23:39:44 -0500 (EST) 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 gB64fwF17380 for ; Thu, 5 Dec 2002 23:41: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 gB64ftr20942 for ; Thu, 5 Dec 2002 23:41:55 -0500 (EST) Date: 5 Dec 2002 23:36:23 -0500 Message-ID: <3DF02947.531EC382@alcatel.com> From: "Cheng-Yin Lee" To: "Muneyoshi Suzuki" Cc: erosen@cisco.com, " IETF PPVPN list" , pwe3@ietf.org X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [PWE3] Re: Bridge or References: <200212040443.NAA00840@infer.nal.ecl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: m115-138.on.tac.net [209.202.115.138] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I think we have come a long way on this thread from http://www1.ietf.org/mail-archive/working-groups/pwe3/current/msg03154.html [Note: LAN refers to an Ethernet/802.3 LAN below.] We are talking about LAN (or bridged LAN - see clarification later) emulation instead of Ethernet "wire" emulation. Eric, Danny, thanks for taking into consideration the concerns raised earlier on emulating Ethernet "wire". There are only a couple more issues. Eric Rosen wrote: > > > But I'm still puzzled as to whether there is an actual issue here that needs > > > resolution. I thought Juergen articulated this quite clearly in a previous email. Here's another attempt : (a) If PWE3 WG is defining Ethernet emulation (i.e. taking into account the client/Ethernet MAC layer requirements), then the NSPs functions required should be defined in this WG, (b) if PWE3 WG is simply encapsulating and transporting Ethernet frames over the PSN (without taking into account the essential client layer requirements), then NSP functions required are out of scope. In this case, the required NSPs functions including PAUSE frames should not be specified in draft-ietf-pwe3-ethernet-encap-01.txt, and all PWE3 documents should not state that PWE3 is working on Ethernet emulation. [I believe we have agreed to rule out the option of emulating Ethernet "wire"]. To the PWE3 WG, are we doing (a) or (b)? ==================================================================================== Further comments to Eric & Muneyoshi below: Paraphrasing from 802.1d to discuss LAN and bridged LAN emulation: The Ethernet/802.3 service emulation allows the interconnection of stations or stations attached to separate LANs in different remote sites, as if there were attached to a single LAN. The stations are unaware of their attachment to a single LAN or a Bridged LAN when using the MAC Service. [Hence, as far as _data_ traffic is concerned, there is no difference between emulating a LAN or a Bridged LAN]. The presence of the emulation devices and the tunnels used to provide this feature can lead to differences in Quality of Service provided by the MAC sublayer; it is only because of such differences that this service emulation is not fully transparent to (_data_) traffic from stations. Control traffic is an artifact and can be handled as appropriate, e.g. if a device participates in STP, then it processes the STP BPDUs, if a device does not participate in STP, then it doesn't process the STP BPDUs. As for PAUSE frames, since it is specified to be terminated by another station connected to a station on a full-duplex/2 station network, it should be terminated accordingly. > > > Well, I think that draft does a couple of things: > > > 1. It specifies the pseudowire encapsulation for ethernet frames. > > > > Agreed. It specifies the encapsulation for ethernet frames over PSN (I think it is not necessary to use the term pseudowire here, the term seems to be a moving target) Eric Rosen wrote: > > > 2. It specifies how one uses a pseudowire in order to emulate a LAN which > > > has exactly two MACs on it. However, the PW is not itself an emulated > > > LAN, as the emulation includes the NSP functionality, but the NSP is not > > > part of the PW. The PW as defined above simply encapsulates the Ethernet frame and transport it over the PSN. > > > Other documents, in the PPVPN WG, specify how to use pseudowires to emulate > > > a LAN which has more than two MACs on it. > > > In both cases, I think it is probably correct to say that the PEs are > > > connected via an emulated LAN, This sounds to me inconsistent with the above PW definition, which says the PW btwn the PEs is not an emulated LAN. > > > while the CEs are connected via an emulated bridged LAN. As far as data traffic is concerned, there should be no difference between emulating a LAN or a bridged LAN. Muneyoshi Suzuki wrote: > > Interesting. If the NSPs emulate a LAN: > > > > (1) It must explicitly addressed in section 3 of the draft. Agree. So it sounds like NSP functions are going to be defined in this draft and in PWE3 WG. > > (2) Functions of the NSP must be decoupled into LAN and Bridge functions, > > because, it support VLAN tagging, but this is a part of MAC Relay Entity, > > especially the E-ISS sub-layer defined in section 7 of IEEE 802.1Q. My personal opinion is if we let 802.1d/q do the job (especially for multipoint) instead of having another parallel function for 802.1q/QinQ functions in IP/MPLS, we would not need to parallel IEEE specs in the IETF. > > > (In the two-party case, I guess the PE has to be regarded as a > > > vestigial bridge, since it does provide the MAC service, even though it > > > doesn't do any address lookups.) > > > > Agreed. Eric, I am glad we are agreeing on this (as well as not emulating Ethernet "wire"). Yes, the learning bridge function is not present in this case. thanks cheng-yin From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Dec 5 23:48:47 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 XAA14153 for ; Thu, 5 Dec 2002 23:48:46 -0500 (EST) 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 gB64p1F21542 for ; Thu, 5 Dec 2002 23:51:01 -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 gB64owr26802 for ; Thu, 5 Dec 2002 23:50:59 -0500 (EST) Date: 5 Dec 2002 23:45:29 -0500 Message-ID: <3DF02B69.6F4E82C3@alcatel.com> From: "Cheng-Yin Lee" To: "Norman Finn" Cc: "IETF PPVPN list" , pwe3@ietf.org X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Bridge or References: <3DDBE6D9.157B6E1D@alcatel.com> <3DEFA22F.E796D724@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: m115-138.on.tac.net [209.202.115.138] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Norm, Thanks for your clarification. Norman Finn wrote: > > This is an old thread (Nov. 20), but let me take a crack at > your questions. These questions will be examined very carefully > by IEEE P802.1, and I'm sure, will be answered at some point. [deleted] > The problem is that the differences > between a LAN and a bridge (other than timing, of course) are > really a collection of differences in how certain L2 protocols > are handled. I agree with you on this. > > > 2) what's the difference between emulating Ethernet and LAN? > > Not clear to me what you mean. In general, "LAN" includes > 802.5 Token Ring, FDDI, 802.11 wireless, etc. etc. Nobody > cares much about anything except Ethernet, any more. I meant emulating Ethernet and (Ethernet) LAN, there seems to be some disagreement earlier on this issue, but I think there is agreement now it is the same thing. thanks cheng-yin From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 6 00:18:24 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 AAA14807 for ; Fri, 6 Dec 2002 00:18:24 -0500 (EST) 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 gB65KhF09083 for ; Fri, 6 Dec 2002 00:20:43 -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 gB65Kdr13392 for ; Fri, 6 Dec 2002 00:20:39 -0500 (EST) Message-ID: <3DF03318.2BF95806@verio.net> Date: Fri, 06 Dec 2002 00:18:16 -0500 From: Jorge Amodio Organization: NTT/VERIO X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF PPVPN list Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: dfw-smtpout3.email.verio.net X-SMTP-MAIL-FROM: jamodio@verio.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: dfw-smtpout3.email.verio.net [129.250.36.43] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit unsubscribe From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 6 00:21:25 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 AAA14862 for ; Fri, 6 Dec 2002 00:21:25 -0500 (EST) 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 gB65NiF12912 for ; Fri, 6 Dec 2002 00:23:44 -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 gB65Nfr18141 for ; Fri, 6 Dec 2002 00:23:41 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: " IETF PPVPN list" , pwe3@ietf.org From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [PWE3] Re: Bridge or Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Dec 2002 22:14:46 -0700 Sender: danny@tcb.net Message-Id: <20021206051451.E5FB155F67@nomad.tcb.net> X-SMTP-HELO: nomad.tcb.net X-SMTP-MAIL-FROM: danny@tcb.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177] X-LYRIS-Message-Id: b (more/less), and feel free to point out terminology clashes or potential boundary issues that may be of concern. -danny > To the PWE3 WG, are we doing (a) or (b)? > I thought Juergen articulated this quite clearly in a previous email. > Here's another attempt : > (a) If PWE3 WG is defining Ethernet emulation (i.e. taking into > account the client/Ethernet MAC layer requirements), then the NSPs > functions required should be defined in this WG, > (b) if PWE3 WG is simply encapsulating and transporting Ethernet frames > over the PSN (without taking into account the essential client layer > requirements), then NSP functions required are out of scope. In this > case, the required NSPs functions including PAUSE frames should not be > specified in draft-ietf-pwe3-ethernet-encap-01.txt, and all PWE3 From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 6 02:01: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 CAA18142 for ; Fri, 6 Dec 2002 02:01:17 -0500 (EST) 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 gB673LF29637 for ; Fri, 6 Dec 2002 02:03: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 gB673Ir02050 for ; Fri, 6 Dec 2002 02:03:18 -0500 (EST) Message-Id: <200212060658.PAA03501@img.m.ecl.ntt.co.jp> To: "Cheng-Yin Lee" cc: "Muneyoshi Suzuki" , erosen@cisco.com, " IETF PPVPN list" , pwe3@ietf.org Subject: Re: [PWE3] Re: Bridge or In-reply-to: Your message of "05 Dec 2002 23:36:23 EST." <3DF02947.531EC382@alcatel.com> Date: Fri, 06 Dec 2002 15:58:12 +0900 From: Muneyoshi Suzuki X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Cheng-Yin, > I thought Juergen articulated this quite clearly in a previous email. > Here's another attempt : > (a) If PWE3 WG is defining Ethernet emulation (i.e. taking into > account the client/Ethernet MAC layer requirements), then the NSPs > functions required should be defined in this WG, > (b) if PWE3 WG is simply encapsulating and transporting Ethernet frames > over the PSN (without taking into account the essential client layer > requirements), then NSP functions required are out of scope. In this > case, > the required NSPs functions including PAUSE frames should not be > specified in > draft-ietf-pwe3-ethernet-encap-01.txt, and all PWE3 documents should not > state that PWE3 is working > on Ethernet emulation. [I believe we have agreed to rule out the option > of emulating Ethernet "wire"]. I fully agree with this. > > > > Well, I think that draft does a couple of things: > > > > 1. It specifies the pseudowire encapsulation for ethernet frames. > > > Agreed. > It specifies the encapsulation for ethernet frames over PSN (I think it > is not necessary to use the term pseudowire here, the term seems to be a > moving target) Exactly. > > > (2) Functions of the NSP must be decoupled into LAN and Bridge functions, > > > because, it support VLAN tagging, but this is a part of MAC Relay Entity, > > > especially the E-ISS sub-layer defined in section 7 of IEEE 802.1Q. > My personal opinion is if we let 802.1d/q do the job (especially for > multipoint) instead > of having another parallel function for 802.1q/QinQ functions in > IP/MPLS, we would not need to parallel IEEE specs in the IETF. Needless to say, the IETF should not develop new LAN/Bridge protocol, but the IETF should refer the IEEE work if it is needed. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 6 03:20: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 DAA28649 for ; Fri, 6 Dec 2002 03:20:43 -0500 (EST) 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 gB68MQF12972 for ; Fri, 6 Dec 2002 03:22:27 -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 gB68MNr16828 for ; Fri, 6 Dec 2002 03:22:24 -0500 (EST) Message-Id: <200212060821.RAA08329@img.m.ecl.ntt.co.jp> To: danny@tcb.net cc: "IETF PPVPN list" , pwe3@ietf.org, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: [PWE3] Re: Bridge or In-reply-to: Your message of "Wed, 04 Dec 2002 00:04:19 MST." <20021204070424.E089755F67@nomad.tcb.net> Date: Fri, 06 Dec 2002 17:21:24 +0900 From: Muneyoshi Suzuki X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Danny, > It's important to remember that it's not necessarily a goal for PWE3 > to provide exact faithfulness to that of the native protocol (the FW > document suggests PWE3 emulates "essential attributes" of a service). Yes, but limitation must be addressed in the applicability statement, so semantics must be clarified. > As such, with keeping the above in mind, Juergen is correct in stating > that "PWE3 defines the transport of L1/L2 client signals over a PSN > (paraphrased)". Agreed. > I believe the latter of your concern here was regarding the term used > to define the "native protocol" (or "service") itself and do agree > aligning terminology certainly makes sense. Exactly. > You folks were OK with > "(Ethernet) LAN Emulation" or "Bridged (Ethernet) LAN Emulation", just > not "Bridge Emulation", correct? I think we can work with this...? I think the PW Ethernet reference configuration defined in section 2 can be termed Bridged (Ethernet) LAN Emulation, from viewpoint service customers. > That being said, as Eric stated, while a PW does include NSP functionality > for the service that's being emulated, the NSP is NOT part of the PW. As Cheng-Yin pointed out, the scope of draft-ietf-pwe3-ethernet-encap-01.txt is one of issues. According to the abstract, this draft discuss encapsulation of Ethernet/802.3 PDUs within a pseudo-wire. >Abstract > existing PSN to offer ethernet services. This document addresses the > encapsulation of Ethernet/802.3 PDUs within a pseudowire, and issues > associated with the point-to-point emulation of ethernet within a PW. But, the draft mainly consists of section 3 that is titled "Requirements for Ethernet Pseudo-Wire Emulation". It seems to me, this section does not discuss requirements, but if it is really requirements, this section should be entirely moved to the PWE3 requirements document. I think requirements mean description of conditions that should be satisfied by a solution. However, it seems to me section 3 addresses implementation model and technical specification. So, if the draft specifies PW protocol, it should focus PW protocol only, NSP and CE-to-CE service are out scope of the draft. If the draft specifies PW protocol and CE-to-CE service scenario using the PW, these must be described separately. And it seems to me, NSP does not emulate anything; for me it consists of MAC entity that terminates CE-PE link and MAC relay entity, but if it emulates something, emulated entity that is specified in existing standard or recommendation must be clarified. > Now, back to the first issue: > I believe the initial concerns were triggered by Section 3.1.6 > of the Ethernet encapsulation draft, where it states that the PAUSE > frames MUST NOT be transmitted across a PW (paraphrased). If I'm > not mistaken, that text was added quite a while ago in order to > suggest [to naive implementers] that it doesn't make sense to forward > IEEE802 flow-control frames across a PW/PSN. I don't think "forwarding PAUSE frame across PW does not make sense", because, a PW is not Ethernet, so PAUSE frame is undefined in that section. > Being that the "MAC Entity", which resides within the NSP function, > provides PAUSE frame termination, perhaps removing the current text > and clarifying by employing additional NSP-specific terms will ease > your concerns? If so, perhaps you could provide some text here? I think it depends on the scope of the draft. But if needed a small note is sufficient, e.g., Note that PAUSE frame is undefined on the PW, because it is not Ethernet. > We should also clarify other NSP functions such as handling CRC errors, > framing errors, runt conditions, etc.., and equally, PW functions that > result in PW "generalized bit errors" (e.g., out-of-order packets, packet > loss, etc..), as Akiva suggests. I'm very confused now. The above functions are indispensable for Ethernet frame transport over GRE/LSP tunnel. Nevertheless, you claim that the NSP is not the part of the PW....... I would like to suggest to carefully sort our functionalities of PW model from viewpoint of protocol architecture. > And we're certainly not providing the "medium connection", between > "Medium Dependent Interfaces"! I fully agree with this. Therefore, the PW Ethernet reference configuration, defined in section 2, does NOT provide LAN emulation or emulated LAN service to customers. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 6 13:19: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 NAA17634 for ; Fri, 6 Dec 2002 13:19:36 -0500 (EST) 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 gB6ILs817186 for ; Fri, 6 Dec 2002 13:21:55 -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 gB6ILpT29907 for ; Fri, 6 Dec 2002 13:21:52 -0500 (EST) Message-ID: <3DF0D8F5.6000009@cisco.com> Date: Fri, 06 Dec 2002 17:05:57 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muneyoshi Suzuki CC: Cheng-Yin Lee , Muneyoshi Suzuki , erosen@cisco.com, IETF PPVPN list , pwe3@ietf.org Subject: Re: [PWE3] Re: Bridge or References: <200212060658.PAA03501@img.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-msg-core-4.cisco.com X-SMTP-MAIL-FROM: stbryant@cisco.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-4.cisco.com [171.71.163.54] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi Suzuki wrote: > Cheng-Yin, > > >>I thought Juergen articulated this quite clearly in a previous email. >>Here's another attempt : >>(a) If PWE3 WG is defining Ethernet emulation (i.e. taking into >>account the client/Ethernet MAC layer requirements), then the NSPs >>functions required should be defined in this WG, >>(b) if PWE3 WG is simply encapsulating and transporting Ethernet frames >>over the PSN (without taking into account the essential client layer >>requirements), then NSP functions required are out of scope. In this >>case, >>the required NSPs functions including PAUSE frames should not be >>specified in >>draft-ietf-pwe3-ethernet-encap-01.txt, and all PWE3 documents should not >>state that PWE3 is working >>on Ethernet emulation. [I believe we have agreed to rule out the option >>of emulating Ethernet "wire"]. > > > I fully agree with this. > > >>>>>Well, I think that draft does a couple of things: >>>>>1. It specifies the pseudowire encapsulation for ethernet frames. >>>> >>>>Agreed. >>> >>It specifies the encapsulation for ethernet frames over PSN (I think it >>is not necessary to use the term pseudowire here, the term seems to be a >>moving target) > > > Exactly. > > >>>>(2) Functions of the NSP must be decoupled into LAN and Bridge functions, >>>>because, it support VLAN tagging, but this is a part of MAC Relay Entity, >>>>especially the E-ISS sub-layer defined in section 7 of IEEE 802.1Q. >>> >>My personal opinion is if we let 802.1d/q do the job (especially for >>multipoint) instead >>of having another parallel function for 802.1q/QinQ functions in >>IP/MPLS, we would not need to parallel IEEE specs in the IETF. > > > Needless to say, the IETF should not develop new LAN/Bridge protocol, > but the IETF should refer the IEEE work if it is needed. > That is why we partitioned the system into a pseudo wire defined by PWE3 (which just transports things that it is given), and an NSP + Forwarder which is defined by an expert in the media technolgy (in this case IEEE + IETF PPVPN) and which performs more complex functions. Stewart > Thanks, > > > Muneyoshi Suzuki > Nippon Telegraph and Telephone Corp. > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 6 16:47:54 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 QAA26155 for ; Fri, 6 Dec 2002 16:47:54 -0500 (EST) 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 gB6Lo4815317 for ; Fri, 6 Dec 2002 16:50:04 -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 gB6Lo0e26226 for ; Fri, 6 Dec 2002 16:50:01 -0500 (EST) Date: 6 Dec 2002 16:48:59 -0500 Message-ID: <3DF11B4A.48E84FE2@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "Muneyoshi Suzuki" Cc: danny@tcb.net, "IETF PPVPN list" , pwe3@ietf.org X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [PWE3] Re: Bridge or References: <200212060821.RAA08329@img.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: m115-138.on.tac.net [209.202.115.138] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Danny, > > We should also clarify other NSP functions such as handling CRC errors, > > framing errors, runt conditions, etc.., and equally, PW functions that > > result in PW "generalized bit errors" (e.g., out-of-order packets, packet > > loss, etc..), as Akiva suggests. > > I'm very confused now. The above functions are indispensable for Ethernet > frame transport over GRE/LSP tunnel. Nevertheless, you claim that the NSP > is not the part of the PW....... > > I would like to suggest to carefully sort our functionalities of PW model > from viewpoint of protocol architecture. > I am puzzled too. Where will the above so-called NSPs functions be specified? BTW, if you agree with Juergen, it's option (a), not (b). In Option (a), which I believe is the technically correct thing to do in PWE3, we can use IEEE specs in some of the emulation blocks as well, it doesn't mean PWE3 need to specify them. thanks cheng-yin Muneyoshi Suzuki wrote: > Danny, > > > It's important to remember that it's not necessarily a goal for PWE3 > > to provide exact faithfulness to that of the native protocol (the FW > > document suggests PWE3 emulates "essential attributes" of a service). > > Yes, but limitation must be addressed in the applicability statement, > so semantics must be clarified. > > > As such, with keeping the above in mind, Juergen is correct in stating > > that "PWE3 defines the transport of L1/L2 client signals over a PSN > > (paraphrased)". > > Agreed. > > > I believe the latter of your concern here was regarding the term used > > to define the "native protocol" (or "service") itself and do agree > > aligning terminology certainly makes sense. > > Exactly. > > > You folks were OK with > > "(Ethernet) LAN Emulation" or "Bridged (Ethernet) LAN Emulation", just > > not "Bridge Emulation", correct? I think we can work with this...? > > I think the PW Ethernet reference configuration defined in section 2 > can be termed Bridged (Ethernet) LAN Emulation, from viewpoint service > customers. > > > That being said, as Eric stated, while a PW does include NSP functionality > > for the service that's being emulated, the NSP is NOT part of the PW. > > As Cheng-Yin pointed out, the scope of draft-ietf-pwe3-ethernet-encap-01.txt > is one of issues. > > According to the abstract, this draft discuss encapsulation of > Ethernet/802.3 PDUs within a pseudo-wire. > > >Abstract > > existing PSN to offer ethernet services. This document addresses the > > encapsulation of Ethernet/802.3 PDUs within a pseudowire, and issues > > associated with the point-to-point emulation of ethernet within a PW. > > But, the draft mainly consists of section 3 that is titled "Requirements > for Ethernet Pseudo-Wire Emulation". It seems to me, this section does > not discuss requirements, but if it is really requirements, this section > should be entirely moved to the PWE3 requirements document. > > I think requirements mean description of conditions that should be > satisfied by a solution. However, it seems to me section 3 addresses > implementation model and technical specification. So, if the draft > specifies PW protocol, it should focus PW protocol only, NSP and > CE-to-CE service are out scope of the draft. > > If the draft specifies PW protocol and CE-to-CE service scenario using the > PW, these must be described separately. And it seems to me, NSP does not > emulate anything; for me it consists of MAC entity that terminates CE-PE link > and MAC relay entity, but if it emulates something, emulated entity that > is specified in existing standard or recommendation must be clarified. > > > Now, back to the first issue: > > I believe the initial concerns were triggered by Section 3.1.6 > > of the Ethernet encapsulation draft, where it states that the PAUSE > > frames MUST NOT be transmitted across a PW (paraphrased). If I'm > > not mistaken, that text was added quite a while ago in order to > > suggest [to naive implementers] that it doesn't make sense to forward > > IEEE802 flow-control frames across a PW/PSN. > > I don't think "forwarding PAUSE frame across PW does not make sense", > because, a PW is not Ethernet, so PAUSE frame is undefined in that section. > > > Being that the "MAC Entity", which resides within the NSP function, > > provides PAUSE frame termination, perhaps removing the current text > > and clarifying by employing additional NSP-specific terms will ease > > your concerns? If so, perhaps you could provide some text here? > > I think it depends on the scope of the draft. But if needed a small note > is sufficient, e.g., > > Note that PAUSE frame is undefined on the PW, because it is not Ethernet. > > > We should also clarify other NSP functions such as handling CRC errors, > > framing errors, runt conditions, etc.., and equally, PW functions that > > result in PW "generalized bit errors" (e.g., out-of-order packets, packet > > loss, etc..), as Akiva suggests. > > I'm very confused now. The above functions are indispensable for Ethernet > frame transport over GRE/LSP tunnel. Nevertheless, you claim that the NSP > is not the part of the PW....... > > I would like to suggest to carefully sort our functionalities of PW model > from viewpoint of protocol architecture. > > > And we're certainly not providing the "medium connection", between > > "Medium Dependent Interfaces"! > > I fully agree with this. Therefore, the PW Ethernet reference configuration, > defined in section 2, does NOT provide LAN emulation or emulated LAN > service to customers. > > Thanks, > > Muneyoshi Suzuki > Nippon Telegraph and Telephone Corp. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 6 19:10:45 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 TAA02070 for ; Fri, 6 Dec 2002 19:10:45 -0500 (EST) 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 gB70D4805517 for ; Fri, 6 Dec 2002 19:13:05 -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 gB70D1e00319 for ; Fri, 6 Dec 2002 19:13:02 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "IETF PPVPN list" , pwe3@ietf.org From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [PWE3] Re: Bridge or Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Dec 2002 17:13:31 -0700 Sender: danny@tcb.net Message-Id: <20021207001336.8765055F67@nomad.tcb.net> X-SMTP-HELO: nomad.tcb.net X-SMTP-MAIL-FROM: danny@tcb.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177] X-LYRIS-Message-Id: Cheng-yin, For the benefit of myself and the rest of the WG, before we continue this discussion could provide us with a pointer to some (publicly accessible) specification or set of specifications that define the terms you're employing? I had thought we were in synch but this is apparently not the case. I think part of the problem here is that some of us tend to employ words and phrases much more loosely than others (or are not as attached, depending on how one looks at it), and this is introducing some confusion. If you'll provide a pointer I'll work with Stewart, Eric & others to ensure we're aligned (where we need to be). We'll also provide a bit more description on the forwarder and NSP functions we keep referring to. And one other note... This'll be my last cross-posting (i.e., PWE3 & PPVPN), I'll move this discussion to the pwe3 list. Thanks... -danny > I am puzzled too. Where will the above so-called NSPs functions be specified? > > BTW, if you agree with Juergen, it's option (a), not (b). In Option (a), which > I believe is the technically correct thing to do in PWE3, we can use IEEE specs > in some of the emulation blocks as well, it doesn't mean PWE3 need to specify > them. From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 9 00:37:57 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 AAA18536 for ; Mon, 9 Dec 2002 00:37:56 -0500 (EST) 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 gB95dq222409 for ; Mon, 9 Dec 2002 00:39:52 -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 gB95dn512960 for ; Mon, 9 Dec 2002 00:39:49 -0500 (EST) Message-Id: <200212090539.OAA06243@img.m.ecl.ntt.co.jp> To: stbryant@cisco.com cc: Muneyoshi Suzuki , Cheng-Yin Lee , erosen@cisco.com, IETF PPVPN list , pwe3@ietf.org Subject: Re: [PWE3] Re: Bridge or In-reply-to: Your message of "Fri, 06 Dec 2002 17:05:57 GMT." <3DF0D8F5.6000009@cisco.com> Date: Mon, 09 Dec 2002 14:39:07 +0900 From: Muneyoshi Suzuki X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Stewart, > > Needless to say, the IETF should not develop new LAN/Bridge protocol, > > but the IETF should refer the IEEE work if it is needed. > That is why we partitioned the system into a pseudo wire defined by PWE3 > (which just transports things that it is given), and an NSP + Forwarder > which is defined by an expert in the media technolgy (in this case IEEE > + IETF PPVPN) and which performs more complex functions. Agreed. It seems to me, "NSP function" described in draft-ietf-pwe3- ethernet-encap-01.txt consists of the following two functions (precisely, protocol entities in IEEE/ITU-T terminology) (1)MAC function (entity) that terminates Ethernet LAN between CE and PE, and is defined in IEEE 802.3-2002. (2)MAC Relay function (entity) that forwards Ethernet MAC flames, and is defined in IEEE 802.1D-1998, .1t-2001, and .1w-2001. If VLAN tagging is performed, it also must conforms with IEEE 802.1Q-1998, .1u-2001, and 802.1v-2001. Then these protocols specifications for these functions (entities) are out of scope of PWE3 protocol specification, it may define "PSN tunnel" and "PW termination" functions. The following text is extracted from the draft, and comments in-line. > The "NSP" function includes packet processing needed to translate the > Ethernet packets that arrive at the CE-PE interface to/from the > Ethernet packets that are applied to the PW termination point. Such I think "Ethernet packets" may be "Ethernet MAC frames." > functions may include stripping, overwriting or adding VLAN tags, In my understanding, 802.1Q specifies VLAN tag stripping and adding, but I think, overwriting is not defined. > physical port multiplexing and demultiplexing, PW-PW bridging, I don't understand "physical port" in the above. Is it an Ethernet port to CE or PW port to PE? If it is an Ethernet port, what is "multiplexing and demultiplexing" of Ethernet? If it is a PW port, multiplexing and demultiplexing function should be reside in "PW termination" function. > L2 encapsulation, shaping, policing, etc. I also don't understand "L2 encapsulation" Does it encapsulate to Ethernet frame or PSN tunnel packet? If it is PSN tunnel encapsulation, it should be reside in "PW termination" function. > The points to the left of A, including the physical layer between the > CE and PE, and any adaptation (NSP) functions between it and the PW > terminations, are outside of the scope of PWE3 and are not defined > here. Right. And the following is extracted from Danny's mail. > We should also clarify other NSP functions such as handling CRC errors, > framing errors, runt conditions, etc.., and equally, PW functions that > result in PW "generalized bit errors" (e.g., out-of-order packets, packet > loss, etc..), as Akiva suggests. I think the above functions are belongs to the "PW termination", if CRC and framing errors in the above mean errors in PSN tunnel. Thanks, Muneyoshi Suzuki Nippon Telegraph and Telephone Corp. From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 9 07:39:20 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 HAA06233 for ; Mon, 9 Dec 2002 07:39:20 -0500 (EST) 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 gB9CfX204344 for ; Mon, 9 Dec 2002 07:41:34 -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 gB9CfU507366 for ; Mon, 9 Dec 2002 07:41:31 -0500 (EST) Message-ID: <045001c29f81$6b1f34c0$81c802c0@alok> From: "alok" To: , Subject: Labels per link... Date: Mon, 9 Dec 2002 18:19:11 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" 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: www.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi All i need to know what is the standard implementation practice on labels for multipoint interfaces. If i have an ethernet network between routers, P routers connected to multiple P via ethernet... is a label unique +ACI-per neighbour+ACI- or +ACI-per interface+ACI- in this case for example, P-a, P-b and P-c are on the same ethernet LAN can u have label 111 between P-a and P-b for egress trafficbetween a and b, and 111 between P-a and P-c for egress traffic between a and c? -rgds Alok From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 9 13:39: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 NAA23912 for ; Mon, 9 Dec 2002 13:39:10 -0500 (EST) 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 gB9IfI220759 for ; Mon, 9 Dec 2002 13:41:20 -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 gB9IfG526807 for ; Mon, 9 Dec 2002 13:41:16 -0500 (EST) Date: Mon, 9 Dec 2002 13:39:27 -0500 (EST) From: Scott Bradner Message-Id: <200212091839.gB9IdRXV023556@newdev.harvard.edu> To: ppvpn@nortelnetworks.com Subject: Re: a personal opinion on what to do about the sub-ip area X-SMTP-HELO: newdev.harvard.edu X-SMTP-MAIL-FROM: sob@newdev.harvard.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: newdev.eecs.harvard.edu [140.247.60.212] X-LYRIS-Message-Id: if you have an opinion on the future of the sub-ip area and want to express it - please send that opinion to the ietf@ietf.org &/or the iesg@ietf.org lists for my current opinion (whatever that is worth) please see http://www.ietf.org//mail-archive/ietf/Current/msg18465.html thanks Scott From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 9 19:24:54 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 TAA10182 for ; Mon, 9 Dec 2002 19:24:53 -0500 (EST) 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 gBA0R6n10344 for ; Mon, 9 Dec 2002 19:27:07 -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 gBA0R4507157 for ; Mon, 9 Dec 2002 19:27:04 -0500 (EST) Message-ID: <20021210002631.22158.qmail@web20514.mail.yahoo.com> Date: Mon, 9 Dec 2002 16:26:31 -0800 (PST) From: "Gopal@Yahoo" Subject: Re: [MPLS-OPS]: Labels per link... To: alok , mpls-ops@mplsrc.com, ppvpn@lyris.nortelnetworks.com In-Reply-To: <045001c29f81$6b1f34c0$81c802c0@alok> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web20514.mail.yahoo.com X-SMTP-MAIL-FROM: gnaganab@yahoo.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: web20514.mail.yahoo.com [216.136.173.246] X-LYRIS-Message-Id: --- alok wrote: > Hi All > > i need to know what is the standard implementation > practice on labels for > multipoint interfaces. > > If i have an ethernet network between routers, P > routers connected to > multiple P via ethernet... > > is a label unique +ACI-per neighbour+ACI- or > +ACI-per interface+ACI- in this case What is ACI? In frame-mode, (local)Label is unique to a router(LSR). > > for example, P-a, P-b and P-c are on the same > ethernet LAN > > can u have label 111 between P-a and P-b for egress > trafficbetween a and b, > and 111 between P-a and P-c for egress traffic > between a and c? Yes. If router-A is the Egress for a prefix, net-A and if local label for Net-A is 111. Then rtr-A adv 111 to both rtr-b and rtr-c. Then, both rtr-b and rtr-c will have 111 as the out-label for the prefix, net-A. > > -rgds > Alok > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: > http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 9 20:08: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 UAA12071 for ; Mon, 9 Dec 2002 20:08:12 -0500 (EST) 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 gBA1AOn21698 for ; Mon, 9 Dec 2002 20:10: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 gBA1AL524771 for ; Mon, 9 Dec 2002 20:10:21 -0500 (EST) Message-ID: <20021210010951.95093.qmail@web14503.mail.yahoo.com> Date: Mon, 9 Dec 2002 17:09:51 -0800 (PST) From: nitin p Subject: Re: [MPLS-OPS]: Labels per link... To: "Gopal@Yahoo" , alok , mpls-ops@mplsrc.com, ppvpn@lyris.nortelnetworks.com In-Reply-To: <20021210002631.22158.qmail@web20514.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web14503.mail.yahoo.com X-SMTP-MAIL-FROM: nitin_panj@yahoo.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: web14503.mail.yahoo.com [216.136.224.66] X-LYRIS-Message-Id: Gopal, Adding to this discussion.. Don't we have the concept of having global and local labels. Global when there is one label pool in a router and all the interfaces are assigned labels from this pool so label values at two interafces on the same router will never be same. Local, is the one in which each interface has it pool of labels and two interface on the same box maight have same label values. Please correct me on this. Thanks, Nitin --- "Gopal@Yahoo" wrote: > > --- alok wrote: > > Hi All > > > > i need to know what is the standard implementation > > practice on labels for > > multipoint interfaces. > > > > If i have an ethernet network between routers, P > > routers connected to > > multiple P via ethernet... > > > > is a label unique +ACI-per neighbour+ACI- or > > +ACI-per interface+ACI- in this case > > What is ACI? > In frame-mode, (local)Label is unique to a > router(LSR). > > > > > for example, P-a, P-b and P-c are on the same > > ethernet LAN > > > > can u have label 111 between P-a and P-b for > egress > > trafficbetween a and b, > > and 111 between P-a and P-c for egress traffic > > between a and c? > > Yes. > > If router-A is the Egress for a prefix, net-A and if > local label for Net-A is 111. Then rtr-A adv 111 to > both rtr-b and rtr-c. > > Then, both rtr-b and rtr-c will have 111 as the > out-label for the prefix, net-A. > > > > > > -rgds > > Alok > > > > ------- > > The MPLS-OPS Mailing List > > Subscribe/Unsubscribe: > > http://www.mplsrc.com/mplsops.shtml > > Archive: > http://www.mplsrc.com/mpls-ops_archive.shtml > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up > now. > http://mailplus.yahoo.com > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: > http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 9 23:25: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 XAA16757 for ; Mon, 9 Dec 2002 23:25:26 -0500 (EST) 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 gBA4Rhn14714 for ; Mon, 9 Dec 2002 23:27:44 -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 gBA4Re505741 for ; Mon, 9 Dec 2002 23:27:41 -0500 (EST) Date: 9 Dec 2002 23:21:53 -0500 Message-ID: <3DF56BE1.76C9152B@alcatel.com> From: "Cheng-Yin Lee" To: "Muneyoshi Suzuki" Cc: stbryant@cisco.com, erosen@cisco.com, " IETF PPVPN list" , pwe3@ietf.org X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [PWE3] Re: Bridge or References: <200212090539.OAA06243@img.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: m115-138.on.tac.net [209.202.115.138] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Stewart, Muneyoshi, Muneyoshi Suzuki wrote: > > Stewart, > > > > Needless to say, the IETF should not develop new LAN/Bridge protocol, > > > but the IETF should refer the IEEE work if it is needed. > > That is why we partitioned the system into a pseudo wire defined by PWE3 > > (which just transports things that it is given), and an NSP + Forwarder > > which is defined by an expert in the media technolgy (in this case IEEE > > + IETF PPVPN) and which performs more complex functions. I think IEEE is the expert in the (Ethernet) media technology and PPVPN would have more to do with Virtual Private LAN site discovery than media technology. > Agreed. It seems to me, "NSP function" described in draft-ietf-pwe3- > ethernet-encap-01.txt consists of the following two functions (precisely, > protocol entities in IEEE/ITU-T terminology) > > (1)MAC function (entity) that terminates Ethernet LAN between CE and PE, > and is defined in IEEE 802.3-2002. > > (2)MAC Relay function (entity) that forwards Ethernet MAC flames, > and is defined in IEEE 802.1D-1998, .1t-2001, and .1w-2001. > If VLAN tagging is performed, it also must conforms with IEEE 802.1Q-1998, > .1u-2001, and 802.1v-2001. > > Then these protocols specifications for these functions (entities) are > out of scope of PWE3 protocol specification, it may define "PSN tunnel" > and "PW termination" functions. The question then is in which WG should some of these "NSP functions" (e.g. what to do with MAC control frames) be clarified, if these "NSP functions" are out of scope of PWE3 WG. > And the following is extracted from Danny's mail. > > > We should also clarify other NSP functions such as handling CRC errors, > > framing errors, runt conditions, etc.., and equally, PW functions that > > result in PW "generalized bit errors" (e.g., out-of-order packets, packet > > loss, etc..), as Akiva suggests. > > I think the above functions are belongs to the "PW termination", if CRC > and framing errors in the above mean errors in PSN tunnel. Agree these functions belong to PW termination (as I understand, this is in agreement with G.805/G.809 as well), and should be clarified in PWE3. thanks cheng-yin From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 10 00:55:33 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 AAA19523 for ; Tue, 10 Dec 2002 00:55:32 -0500 (EST) 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 gBA5vhm00684 for ; Tue, 10 Dec 2002 00:57:44 -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 gBA5veP20473 for ; Tue, 10 Dec 2002 00:57:41 -0500 (EST) Message-ID: <20021210055713.64111.qmail@web20514.mail.yahoo.com> Date: Mon, 9 Dec 2002 21:57:13 -0800 (PST) From: "Gopal@Yahoo" Subject: Re: [MPLS-OPS]: Labels per link... To: nitin p , alok , mpls-ops@mplsrc.com, ppvpn@lyris.nortelnetworks.com In-Reply-To: <20021210010951.95093.qmail@web14503.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web20514.mail.yahoo.com X-SMTP-MAIL-FROM: gnaganab@yahoo.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: web20514.mail.yahoo.com [216.136.173.246] X-LYRIS-Message-Id: Nitin, That is incorrect. Pls forward me if there is a doc that supports your data. In frame mode labels are unique to the router. There is one big label space per router. Router assigns labels to the prefixes in the routing table from this space. If a prefix P is learned from neighbors on 2 different interfaces(or we advertise to 2 neighbors on 2 differnt interfaces), router assigns one unique label to that prefix(it is often refered as local label). In label or local label = Label that router assigns to a prefix. This label is one unique to the router, no matter how many sources we learn from or, to how many neighbors we advertise. Out label or remote label(s) = label this router received from the neighbors. there can be more than one remote/out label for a prefix(advertised by different neighbors). You can play with your boxes to see this behaviour indeed. rgds, gopal --- nitin p wrote: > Gopal, > > Adding to this discussion.. > Don't we have the concept of having global and local > labels. Global when there is one label pool in a > router and all the interfaces are assigned labels > from > this pool so label values at two interafces on the > same router will never be same. > Local, is the one in which each interface has it > pool > of labels and two interface on the same box maight > have same label values. > Please correct me on this. > > Thanks, > Nitin > > --- "Gopal@Yahoo" wrote: > > > > --- alok wrote: > > > Hi All > > > > > > i need to know what is the standard > implementation > > > practice on labels for > > > multipoint interfaces. > > > > > > If i have an ethernet network between routers, > P > > > routers connected to > > > multiple P via ethernet... > > > > > > is a label unique +ACI-per neighbour+ACI- or > > > +ACI-per interface+ACI- in this case > > > > What is ACI? > > In frame-mode, (local)Label is unique to a > > router(LSR). > > > > > > > > for example, P-a, P-b and P-c are on the same > > > ethernet LAN > > > > > > can u have label 111 between P-a and P-b for > > egress > > > trafficbetween a and b, > > > and 111 between P-a and P-c for egress traffic > > > between a and c? > > > > Yes. > > > > If router-A is the Egress for a prefix, net-A and > if > > local label for Net-A is 111. Then rtr-A adv 111 > to > > both rtr-b and rtr-c. > > > > Then, both rtr-b and rtr-c will have 111 as the > > out-label for the prefix, net-A. > > > > > > > > > > -rgds > > > Alok > > > > > > ------- > > > The MPLS-OPS Mailing List > > > Subscribe/Unsubscribe: > > > http://www.mplsrc.com/mplsops.shtml > > > Archive: > > http://www.mplsrc.com/mpls-ops_archive.shtml > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up > > now. > > http://mailplus.yahoo.com > > > > ------- > > The MPLS-OPS Mailing List > > Subscribe/Unsubscribe: > > http://www.mplsrc.com/mplsops.shtml > > Archive: > http://www.mplsrc.com/mpls-ops_archive.shtml > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up > now. > http://mailplus.yahoo.com > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: > http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Dec 12 04:04:32 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 EAA17196 for ; Thu, 12 Dec 2002 04:04:32 -0500 (EST) 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 gBC96mf01186 for ; Thu, 12 Dec 2002 04:06:48 -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 gBC96jT05042 for ; Thu, 12 Dec 2002 04:06:46 -0500 (EST) Message-ID: <4162-22002124129610814@directvinternet.com> From: "Charly Calder Faux Furs" To: ppvpn@nortelnetworks.com Subject: Christmas Greetings! Date: Thu, 12 Dec 2002 01:06:11 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_94915C5ABAF209EF376268C8" X-SMTP-HELO: directvinternet.com X-SMTP-MAIL-FROM: ccalder@directvinternet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dsl-65-191-41-34.telocity.com [65.191.41.34] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable =09 =09=09 =09=20 =20 Faux Chinchilla Faux Fox=20 Manhattan Mink=09=09=09=09=09 =09=09=09=09 =09=09=09=09 =20 =09=09=09=09 =20 Midnight Mink Faux Fur Throw:=20 Faux Fur Throws are ideal choice to make your living space more cozy, eleg= ant or plain cool=2E Charly Calder throws come in a variety of best qualit= y TISSAVEL Faux Furs (Black & Brown Mink, Sable, Red & Purple Fox, Wolf an= d more)=20 Our exclusive offer only available at: www=2Echarlycalder=2Ecom=20 Forward this e-mail to a friend, and automatically enter to WIN!=20 Happy Holidays!=20 =20 If you wish no longer to receive e-mail offers from us, send e-mail to cca= lder@directvinternet=2Ecom, with subject line Remove=2E We apologize for t= he inconvenience=2E=20 ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable =09 =09=09Charly Calder Holiday Gift Ideas =09
=09=09=09=09 =09=09=09=09


3D"Click
Faux Chinchilla

Faux Fox
3D"Click
Manhattan Mink=09=09=09=09=09

=09=09=09=09

=20
Midnight Mink Faux Fur Throw:

Faux Fur Throws are ideal choice to make your living space more cozy, eleg= ant or plain cool=2E Charly Calder throws come in a variety of best qualit= y TISSAVEL Faux Furs (Black & Brown Mink, Sable, Red= & Purple Fox, Wolf and more)
Our exclusive offer only available at: www=2Echarlycalder=2Ecom


Forward this e-mail to a friend, and automatically enter to WIN!

Happy Holidays!




If you wish no longer to receive e-mail offers from us, send e-mail to cca= lder@directvinternet=2Ecom, with subject line Remove=2E We apologize for the inconvenience=2E=20 ------=_NextPart_84815C5ABAF209EF376268C8-- ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: image/gif; name="rektop.gif" Content-Transfer-Encoding: base64 Content-Description: rektop.gif Content-Id: <2377715-2200212412931741089@directvinternet.com> Content-Transfer-Encoding: base64 R0lGODlhpQFHANUAAHR1cF1niB0dHWp3oVRde2l2niwsLCkpKXB+qzc4OigoKIKTykpSaXyMvzxB UiQkJCIiIiYmJkdMW2Nuk3aFtCAgIEVMYxkZGSotNRUVFTk+TH+QxIaY0VdgfTI1QXF/rTU6SU5W cCQlKjM4RVFac0BGWjs9RS4xOyEiJhscIB4gIygpL42h4PLz58LDumBgXYea1pGRi+fn3EFEUHiH uJ2el0dIRoWFgFRUUqmqotrb0c7Pxba2ri4uLo2g3C8vLyH5BAAAAAAALAAAAAClAUcAAAb/wJ9w +Ov1DEjD4aBQRB7Q6ANCpUqjkeYyaTQSv+CweEwuf41JJbP5vE6r7kdWsUV6zfgufg9GJ5drTnFQ VVZuc3QHaXd8jXxdaUtNgoNvhodailyMjp2eZn5qbFFUFaanqKmXmYt6n2NdsZyOoUqjhBCpuqir dJthsrF9wbOvQrWSClKFu80VcFBzmgauxq+hyW24uc67l9LTxdbje9hNuKYCAiIaJQTv8PEaHuqm EFCsrT3kRbW/neaUvUmnToOGeAgJzKv3DF+4YUfSULsDSeJEfgFJcaugToDBEAnjhVjI0JCWf/we RZTUphRBAR7ahZSnQUTJe3J82dmXsies/5VMCKU7+IGDj6NIkyr1QSNACRENH2SaRg1jRIsXG/mR JJQj0Q1LwyKlMcGCgoY6eQ7xJzEWVpTGtgrkVjBEgKJi8/rYMCAEPXsOufjMs1IQXQEY3H0Aqzcs hw8ESggALLWOuMFWkTB5kktAiQGNQx+dgCEquJ3jtkoChLpcYc6mSkwwKlrvgBH3fHG6mqzOxD+r H6bWrKyzBwIfatfeMMED4LRqMQMjzhmxhQK0lTceYAHqvQiWpQ+WK7QD47w0PqhXjyB72BLPcEpN O9yWIGl2XFOfUoHBebHprfdBe3oxAAF9axHnRARZUKUggydldc0RQR1onl4IrBfPXerR0P/YBhag pUl04hFR2BQMIKDXBusFEM8A6zXGQQAYfDdiiT2dOIUG/x3Fl0L0dCTABUNeYOQFKowwAgMEqOjD B5NV4MAEJ+R0Y1zEPRCABNHoRqIYrz1QwQgeKvUjSUIWeWQGSjLp5AYQgJffMdT1MAEIgf0hiAQT MNDgnNdkOYJ7PlAwAQEjnHAkkWk26pE7BfToAwcGVlYVjmcgocwKySW1AQIkWACCCkc62mhMBEzQ qVIB5HYlpnGtxFkHSXFQFgYdNdPRohn0msEFKzzWEa0+4IngJydCcBQNrgL6k2acMVArd7gypMuu a/qK5AbMynlpEdA+4MBRrVoqirhHdSD/x6vIZskYAoj6+mup1uqaJgoOEFDmpBWY+6V4aARFbFMO iCAvvVE60+gFGjAwQHYGevsvrFplCUEASE0gWcKXLPPSmkaC4OHGAhBw1ADNTtwPMbLYsiNS5XpZ RrLSjrbxKR1rxJE6vF4gsg/qSlxRhcT6UIKVXF2cbsosNy0MuC4nF4ADKhxsZK7xFcLMKR2lcKQK FhylQW47OQ2M09WYSKEyJDBlwQpWXx2l1lqjIuSiICTXAdNnoO23yu1WWMKkHdhkj3yITNLSzjyD EIKHHIQgpMlP9iux2my9pcQTFWiA1AeWj9h0P7Y8MS7QuB6OxSSKC3W342Xuba5EFVZQ/7TsrPPX Ke4Oav6WWy6v0MG+CCDg4jsdaODACvJptDXji6pwlAXN+l52y9ZP5MpWTzg8FgKHIl+CA7jFUTfX PBuZgYqgr3t9Rdn7nrYxFnNbrWmTAKL/OSBI0IGq5/lACGwyuaNAqXrYAw5raGcYj3xOANXDCvAq 9AEaBAl/U9mfMk7gPwB+LgSlcRVVWCKmkiGFAA3JAhQ4MoGjhMByOgEOVvTXFt4UhyMxkQkBGKA8 B1SCbnZTUwZO90KkqYGG8Uui9shTQgwYRAMh6MBIHLC8QQARfUXqlVEOOLsk6u+LvZMQ/Tb3gBJs gIBRmcoMFaCBGVDRAU8kYJQK6AMCTP/GSm9JBuv2OAoIqOMED4RgZcJokQM8YVBoxEmDfBMJBXjA jVSMY65wksE1rFAdYTuKHftFCnVQTgNoSUQg+EhK36hmLhuJDxYYpI0q2CuLGSiTBgSZuFIuUDNf tKUpJ4hKXkCDlctIZRCFSLkA3HGQkQDjKEnJultephGamkIHOjBJfCQij5tBh70uQDk73vFPjaRE JVw3pAzAjEihFOUt//CEDhizHpS85gyzORBVKJJ1rdyZz5DigMm4kmefPCYwx3mFRZYNl7co6B5b chhTqS8DGDsKCgRJ0C5lAp/aKOhplqgncUqhlgLhz0sWpj5AalId8UwERjNa0S4JZ4z/xfnABKo5 n3UilBKu3AVAp8coTqrzHPX0ZU551qsTXi0qcoBQhKgDgQ5ACZ7WtKkocOoSnDVPZ/q8AJuQAgJG 3e0CbSuWP3FS1axtzSThwIYem7m/H0yAAgKKa1wJNb2xllWoP6RbIaIQIeDddI+5VEAH4CrXwu4r KQWA51WDeUVnoLU1r4gmBJJjAZomToPizKlOh0S5EVzNOd+5RWegCA+SIYZnGojUBganyV85EbRw gIAHehDDJbTTB+/0J1/zB4jWbUMX0BgIYtzxju5s9ShdJdIFMJAvAjjASSCoV0EI0IHudEQEBBTB BDw0AH/5FZdIPKIT/KOdpCDAqx05/wg8oquOEjDgLMxYQRSDxI4QgDBXIAABeG4EPwUykiUzWFV5 fbCCeljAQHUTXgeqddr2FmW1HcEASEJQvmN9Ilw1G8D9VFlQN5RVSKcQQWW5eZQRZEAFBfDBBDjM HxEQgK4IWAEIjsIBC2TyKKz1AQNOnDGsYcwB4HRZzT4wy7ktlqVBZRzHSrCCoQiYxgzwAFJOMK+I LqWrQgIBaDyFAhSUqQAY2NcHwKmW72oumxBggIAf8wEXhSC/KhBBUrCsDhEEAMZgo3GQOtLCOl7A y0kJwAVCsIENjMBfa+nvmYMirtkkJT0DeIcDQEDlfRGAURGlgRzVUaZLh8BH7pizz/+chBQ4ScVZ nrDYqj5g3YSZ9XlKFpIHQgCaEVOuV5Z29ToOyxzs1HEFNZsUUjhgzhL3ysoWuFomfVjb4vSZKfd1 tV5TaapZg2bFnqwV+MDCASkfxVc3XgoJjoSCTtGABCNIcbFU8DNhI4UBiO6b0/QEmxPUxFHqe/Z5 eYaB/xjKSQyYMY1RoNwVGDVfzy115L7JrkQ3raNCQVPX1DeCYaugI59e1pCGlONLnyDj7qFBBiww IxMPMQDUsxTg8qCpJ6zg2ctC+Z5NlaYVQPEuSWHATn2QAZj7YOYCULcPCoCCXmHAKCZ/tgVG4Nxi +8DkKmDMBrR6AdpowH3snIKVY27/AaDTXB0o0IAFkJOdDgxl2CXwVYoR4G2e94oCNvNAsAPwq54f pQApKIGTEFB3g98diriDrH72s42hGsnvyGXUBVY1gaJnAAPGtvJ5jWTlCcgrlvwkkgdW8ICGE0ZB zhtqkUg9AfSuStBGEjoB6v4mKhKgqwgoAAkKAHe39Us31tBR5yTlI/UcDx4CoqsBR8A4ykmLApTb y0SVS+O0P97RPrBAr07nA6oX1di9uvGOqT+2zjeSMxp4cql9j5Dgi2UDoEwH5RCQggzkvQFHoUDb fXUUEvTKA7Xfi6/6TBsOFED683IBjMFeCOQJapVQHjMkpLZvHUFjDmB0VmZiKmBp/79yHnznKxOI FAXAMKamAKj2eTeFZPwxJBl3FKlzCkeHFMkmPTDTKxdQM5N3JCJGAgRAAhOAABvAAbenCCsHCjqS CyUgfgNmQKDkEia0LKTybDSwAoPmdxxQPISyehdgUjSwKBcwZYviJJSSHYLkIGjWOVs2hErxAQyQ NRxBOTSAAPmHFBU3Ke3ndGJRACBgAWHFAR1wAimwJBOAeosnNt/kgR84eOC1TLBRgtFXD+rgI8Wz FFJoUsjFADSQSRxAKhlwAjkodEaxN5cDEGq1VoZRASk4GrpVCjnGAScQAH3iI6SyT0+iXNnSKyIQ AjiYMqkRJtwgYYelHBzQFyEkH/9AqGdHkosbsAKSsgE1c2lGYkBp0imPoShTmBR9RgMQJDT7cYuP I4YC1IukUAGGCDNOogK08SkXIHRHgQCnCI2ItxSCNiQR5Rx58kwgOE/nAAHnIY32YAp0ZYwudCQ3 xgE0QCq0sYEg4I9MqIScZ2G0kDkIpXVJURpXkAvP5o8ogHjI6HcDkCaSwgElECeeZ4CFMRfpIALu ACPn9wGR1nVWFQ0MQggkAGFCEoRPMkAwUSYb8H9GwgEbwGCgYXaooAB9NgE2YSQOkInFFgDP4CWn hA7rcBAwInwscpLOoTpJFQUVYGVtxoQmc2krADmXxiNMMTVGggJbNGJmNC1FZgr/nsMBlCQ65GBm uHRInYIbvuiVe2GTV5iTQpJJjcdxRiE5AwCU6UUDIRBagueRCsloESU78/GJGMMBdkQkYcMBRSYA yUEC8WEKDJAdbYYB75gZoNcVsWYqKZkTKpVZjYVFaSJUOfMGuIE+WkVlxeaOuEc6D6JNX4c1HIYI liRSt8lgNJcKosliq8OWPhEMb4kLq6SUIHY4sNYNWuNSgRgrvIQJ+6NNwLVXHkYQz0GcbXkVU8VY VUU3qyNPfzVQefWchwBSLNUZKAAC9HdAm7gywAFUhbcR4mlRC5QMoTdt/HmewZVUrJQP8JgSQLEg SpUN9dlSCmpEYjQeH3mgI0Sf/wSlVLlDCtAZnbGSTIEggh+lm4ykoYG1UKw0oiClTiEKkiZjKy0E SipHIsigRxy6SrxFSBtKojZ6oyXKBiupkjMaXgNKoEDBBEjUWwZKoaLETEg6o3CBGZ0oVeKVpJVE pAuSDw0KpN55RJ4YpTWkaPOkTF5KSLRDQhBgiEaJdROjaCfaox+aQFj6pW76psokPz2YI1e6aF5a SHAKpj/anXL6ol9qPWDUCjjilkqkPZhTp4WaqOH0AC9HOD7Fg4BDqEr0NPKpqJYaP/MDK5kjqZfa p3NqFXWqB5zaqYWJKWwqQbJABn+zqqw6n8iJR9/ig1y6pZnqcKx6q/3lNxRzNv+42quruqvylqrB 6qtmA6xgwjLGyon09gQGVaUqQQzJGq3SOq3UWq3Weq2qyhtrsEvY2q3e+q3gGq7iOqiIuqTjeq7o mq7quq7UyqW1KgQJIAEmAAYmIAH2Ggb2Kq/0KgEJMATxyq9DIAEzMAQzMLD/CrBCUK/2Oq8Ji7A/ cK9CMAMIq7D+mq/9GrESAAb56rA/ILEbO68bOwb/erEEa68ky7BEgLLsurIsa63ISgYmwAIIIAT6 +gPwhwAskLE/0AE0ywIDwAIN0LBCgLMDu7MwwAJIiwD9ygIUMAQU0LQSgLQsEABDEABSC7QM8ANW q7M2m7M/kAAwAAMmkAA4K7X/PBu1SEu1QkABLAAGV8u0Rcu2V0u1VwsDBUCyQtABR5u0/ToDDSC1 MEACa8u1P1AAatuyiJu46fq38xp7HSuzM8ACBfADMTuvBZCzlzuwb/W1QJu3STsBRzu5TOu0TWsC AbAALLAAVSu5AVAAYau1XhuxqVu4LMCzOGu3ZcsApou6MOC0bfsFqYuKRyu2P8C2AXC8W/IDwRsA fyu4Q9ABnxu6YJu6b4W0WUsBMFC0EzC1itu93vutJFC7MQsDCbC9Gfu35Su5YKu6UXu3R2sC0Ou8 R5u1lMuzytu0a4u/48sC9Lu1QrC9DOC/Q7C9OBu0kUu+NEu/CcACR+u8bOu2//jrVpJbvL9LBKPL uRH8A/ObsDwLvREcvqrLttkbvtz7vSZ8wtG6vlZbuwuguj8QvnrLwNBrvwsQuEg7AQ2AwJHrwhb8 thdsteGLv/7rtyxgurELr6jLAgNrtZMLBlbrwWtbwUNwwZTLtHIrtTo7ugkAvU38uDzsu84rBEdL wWGbuiWMwmicxiVyuTBAAUlsvwt8wwyMwDuLtAuAAKGbsLP7BSL8tNiLvzCgujhrxG87AbCrsyRA tQwwwXXcxUTQwrQ7sA8sBAEguFQcs4ZytH48sD68AEVbxV8cxWGswW3LtjMAAw2wyIerxqzcyuMQ ufwLvSxAsperuqjbxXHcAf+LXMRD0MBD4LxU/LQv/LYFIAFsWwDb68IC/MBRq7awfLEmkLUkLLWT O8n3e81CcLnVLMWwuwDMywKjTMphLLjQG7SeG8JtO7bN7Mrs3M6e0ACqu8COHLU8a7Wf/AN43K8L 0LQdMLAkTAHfLLoRLMyoi7w1nAD+i7OGzMTHi7oPe8Zla7gN/LcGTb7Ge7yjG7yuy8DzetHHm7Gj e8D92s/DzLQBnQC8W738S8EBe8bu/NIwHQaJnM2E+wML0K8mYM5DwABNPAGWPLMvvLfqi83FSwHt u7qJ7LXTKwErfLUPfbjpK7UkELVADbuD9bZNi9Vx+7Z0i78ErLxATQJCfbf/lHvFgRvFLb3KMb3W MJ0A0AwGJIu38DrXHYu3EJus9XrPwDoDdl3THXvXbB3Ygj3YhF3Yhn3YiJ3Yir3YjN3Yjv3YkB3Z kj3ZlF3Zln3ZmJ3Zmr3ZnN3Znv3ZoB3aoj3apF3apn3aqJ3aqr3arI3GCXADLvAC7GoDMeACONDa uN3KCdACvC3b6ooDvN0Ccp3bxO29ANACNWADQvACMRADN3CxNvACNnADt00Er30DNmACAPDcRIAD za3cQhDdNrDd4O0INdACAHCxANDcADAEOPACCRAD5f0Cvu3e8P0D0/3dREDb6Y0DN9DeRLDe6W3f 0w3gxX3gZBADLeDbORDc/y0gA7et4DKA3t094S2gAzsQ3L593sHtAv0q4cF9A53gAi0AryQe3Dug 3CQ+4eXNAxReA/064QkAABbO2yL+AzcQ3Dxg4TIArxnO2zJQA0Kw4kBe3Qh+5EMAADrQAjtQA8cd 5ABA4jrwAwruAgYuBOddAwreAjmg4DnwA08OAC9A4i5A5Q9+A+c95Y1QAxPuAlp+4TEAABle5iTO A1d+3Dmw2wCA5yYw4XaeAxMu20sO2zZO4u3d4LFN4xRO4jtwAy4u5Ege6UrO5DVA4jf+A4Gu4Fc+ 5CWO6cL9AzrQ4y7uAs3d4MKt4Dfu4kaOB2zeAm6+5ABuA7xtAyRe30MgA/8yoOA60OB7zuRD0OA5 ANxl/gKu/gPEzgM/wNtdXtvFTuLKvds9HumRruCyTeJG7uLMveBgQOKc3u0n7uALTu1CIO6NwO3J /ulCkOFjru1fwOETLgNTruCQDuauTuzDXuz2fu7gTued/gPmLu1HLu6PDq+87d3sTgTmnvAlDuzw CuDkTu58YO4ZDuDALdy1DgYVfwMTLuTHreY/8Oj5HvLFHuhC8N7dfvIAj+DiTuyu3uplDvFDoPDd zvI50Opf/vAHvwfmnuMtwAOAjtz+nvNDsAPx3gK3bQJLrgM1kOEyEN34/vQvf+E1YOrt/e//nvLF Te6Kztsebua2fvIyD+Z4Nf7lXj/uQm8G/77lvM0D/XrxYHADMYDfO+DeP/7g7S3y917mP8Dhdo/y V4/1uQ3xCUDfq/4Kg3/fKXH1h1/eZODWdG3fX28G0R35gC/tMJ+uf1/5mm+tzM346bremx/6oj/6 pF/6pn/6qJ/6qr/6rN/6rv/66xoEADs= ------=_NextPart_94915C5ABAF209EF376268C8 Content-Type: image/gif; name="holidaygift.gif" Content-Transfer-Encoding: base64 Content-Description: holidaygift.gif Content-Id: <1476716-2200212412931741090@directvinternet.com> Content-Transfer-Encoding: base64 R0lGODlhYgGAANUAADExMS4QEC0tLSUlJTEaGrNKaSkpKSEgIDIrKxoZGSskJDAVFSoODmkzQh0d HY+DsyMbGxoWFjEiIisbG1UnMiUQEM4zVo1slB0WFo59q42f3SISEno6TY2d2h0ZGY5xm42g35CR xo+JuyAUFDAoKI2Z1Y52oY56po1liicgIBgXFyYWFh4TE4+Gt5lGYJCOw4yX0tUtUcE/YEAcIY+M v+IhSNsnTJCXz4xfgY+UzBsUFOgcQ42h4I2b2I+Ar4pAVyH5BAAAAAAALAAAAABiAYAAAAb/QAAA MUQYjyQEabmUkCTQqJQgoRKu2Kx2y+16v+CwmFutjs/otHrN9patbbK1LK07nUzlcT/sC/+AgYJE e3tMTU92UHNYb3GPkG6Mb5RZlZdwkZqba5iYlpOhnqFXdFSKUE+HeoWEQkSCsYGErUmHd6iLjpy8 vWBmvsHCwru8wJSoqqutfbCyz7SFtky4doxxC1fZBNvd2t/c4N7h5NvD51vj6uLs5e3r7uTo842l p8l4S6yFfs7Ps0UMKaGWSFGmg1zgKXzHMN5Ch/TOPFSXbUHFi9wwWswIsePEdhEhXVKkLA8zV/9i RUMysAkqUl68aZzJcaNNmjdr4tToEZyw/4k7dQrNSTRo0aE8P8o7Zw4NHZL59vHxl3KWtJaqciHU IjOjxa9gw4odS7as2bBIhfZc283o2bdw48o1m5ZoQ6V4f02yU1LfST9V/7TSc8tgMa7h5ipezFhs XbePvTaeTLny2MhHM0Me9+Up36hJ+KEM/OrqrYJ1wty0zLp1WcwzXcuePRu2TrlqJXlOlc/vX9Kl pVEzvPXbRdrIkytfzrw57cRbzOyOUlKqEcDAhRMknjCx8+/gWQewOH5B+fPk05tXj369+/blw4df Gv0eddB/qabUjsjaYeNwwcfegO8RKGCBCLYn31wHNmjggwlC6CCCC1IGXRf45BHaEc0AF/+QEadx 191bE5Yo4YkRphifcyYWGMB4L5oH44wy1hjjjTTiaGOOKE5Y4Vv0iVLHIRuK5qEhIab2n3dknZfj kztGqeOUUFIpZYtY9shelVxe6aWVYHYZ5npZqqglhWcF2QhU+hR5nX77IbGdf10cFxZ6VL6o5558 9unnn4Dy+SWUZhYq4Jg4Bqrooow2quegURp6ZouvNWXPdMpY9+aRcg6n5FZmOSmjo6SWaiqkiIrJ pamstuqqn6iqGquU7pGl5hyfmTTVK6Qh2Z8iEyQ0lqivFmssoLOmOuqxzDZbbLKyCqpjrWhZWg9J y3A4WlWd/hpFcZLdSaaz5JZr7rnopqv/7qMwVqrFdLxlqy2nWGU1hQTBptPkAg1w4O8Mf/rrb7EC N7DnDC4UQIGjMwi88LqmzvBDARRTbDCgFBTgwp8ZV/zDixS4wEGjAo/saL8cXAwxqQs07LBjcgzZ m5vbxllvNUuG+1W7Fuzgs8l9+uxzsUJbsGcBPhtNstAFrOwoBTIILfUONmzspw0+F8AAn1FLbXQM WTcqNak976C0045yIHUBK6D1rn33EflbYN2i9i2++ooLY9k7AM3n2K8WvSffaTONtqIMID314hYA vGcDPtdw9ouKSz2y4YwC3mjZkx+uqNpCc1BtzFL0RTN2Nid5txYT2LkzmXz7vafmrQqu/6cLSRce tud/dr344jE4rmfZH+tJgdQ1xBDDi5gvSvuinPPOKOShO2ZthrrykV29dkcRbL6t69zui7H/+byp thuvMqOg79C09HsmPrUFIvsrQw1e98nBwy/Kn7TwAWieos4XqOjBb4DVgxkZ+CKvedGNSPbyXha+ 57r0DC905hOan6AGNp/ZQAayY17ublcxP/3AAvjbQQ1kQIH2vW9PHCzaxxKmMeNVjH964kAJFXW8 tW3tYB2MwcK2trWKcYCIAajcEAOQsKJRbIlIRCIBoYa1pH3MgHzigAyqaDar/WkGBejgDmLQNB1S jE8z2KLQyIjDACbQbViYALz6MhjUQf8Dgt2T4/ey0Da9XfBnGRxaFCvHuBlEUXBEJBwSZ8A35FXu hQHw3+JkgMX2hbByi/Jd3yLJSSLOIAYyiGIkDUdETCbyd0fspCoZILUoSnJqBcDiixj5O6qtL4cp nJoMfPe4XOpSeFKbgfVIV7oGOnA/EMSZHCdIgPDpbVTl81MrGUBNBmjydzYwZDWLVk0G8K2bn6wl LLt5zVpaoJqW7CY1K6fOds7Ah+3sZiTbyTQkspOTjQydKA8pNHWW83fnrGY4xVmDBqgTd+LUHAV8 uTitidBn1LJI+OKIqd7UEU4qSaYEFOC9Kuyxda1r2wrG07YcckCMBShZyaa5TqnZoGL/jYxBN7lZ zW/W1GsUu984qfkDl8qAYmJMGjr1qU52xrOaPRWaNtGpUpVuM2vUTBjfbkhJodnAAhYw6FGpyVIG JNWDPw3j/LrJtxqkVIe5rMFSFyq0FeZ0cUT0nQVGpkOfhVJPYlzRV7iRr2vFzZib4haRNloHPXq0 mQtoHVhGSqaEirOaPbSrOn+QSxc81Wxk7WdUpWZZagZgoFBlwAxyKYOlvjKgDEhnUTW71cqh9rK1 vKzWvFnLI7IytFuFrUBJa1pCohahYzQtaENJTb4JsZsc8OVNVWhI45V2cEKLaNuaeYV8sSl7x0Qm ExRAAo5yFArL/GhiFyBS8oz0oY6d/1o1K0fcya7xsq+1KQNQ6k4uzha4Mm2na4f6M/2y9qiPpGdC ZVvc2nIVt7m9rc+qCdzXrpem8yVqNyO7A0NGVq3tbN8OllvQVfKpbDXQa0XiWN3d0PGiD1QdePEm 3pBahLEBGGl6f7fcHVDgqGLUJoRpu+ADU+2owJ2t734Qz9EKlZqq7aZRWyu09sKWxj6ebT6JWs8E +3jD1PSdbdVpZMxeuWJgLgAXjxjgeMpXkxaQgQsM9sM/WsA85Z0u+JpZUcDaURbJ7C4UOKrHPRJg BX/+CmNLmkQxNznMFWNpCm3A5P4qOL6abZ+TJ1xl+baTc/ztm3973GgvKznMmiTwg/85LWors9TS 6sQ0A6g3Y/dJcsur5TRbF7fC9XFuLCClLnXxVbqZualDVcmzdyWQAhZPgIIu7uNIKwBdRwuY0zuO taYfndkeu3Crlf5vqo+cWgmPGstb1fCNc1s5RkdZydpW8GxNzVpUVzugGk6v1ioHa3STugFTxiDl chdniSZW11SQYzHltiuMBgKCChh2R6l7bMSSl7wxHg+zmR27o7JUjFv1nVZ3bFNWTzrTUlYqjrmd 5G8n+J1Nzm2Xd9DeKreU1Oe2soLBzTfTdrODAUU51RCNaDILjcjtrIDv2pkxGQSVapxU3Jtf/JVc f4/XAt+zr41kcEBghbuE5Wixj83/9WZOYAVgfziMX0Rxb8+Utb7rLJdzCd9qgzuX4/ZnlX23buRC uH1qr+bQE6zJvMtdaHF3uSSf7WBso13wmUZtCmsgc69Gm5orV7kL4L5v98WY6YD+9/eWKQWOQvA3 VX9FErjb3WHzGV9cP/Z4xU7eCiw7ABWoeDxZCtyCttN37a15jfW+RpsD19UVYPUOtCpQMaJW5w6m sJVnjWDIa9LJgl9yNRdtc4trtgLtsz04jc/75os2BhaI+8r9bs2uusDvQscgs9n18Bd/lM5RJ2x3 7Rx6wRwC697dOupTH9Kvg33QsAd7sVMBs/dfYlQDascBjRR3vnNcPAZuFBYDtgVG/zv1gGalTT/A RZ4WYXalTSfVVVv1ezvnLz+gU71HgDH3cuDWfcHFbqRWVgUwAwSYgV4DWbxVTQ2AUihISCxEgPim XpvFcksVebOUMDMAdpfXNiD1UbwmdU5Aer6xK4FBJNyVcN9FbCnAf1zHehA3UitQdj9DgCjIAAQo NSgYfAylgVlzhsyHgA9ITQRISB70O+vGfHPION30VXcIhFYmggRFfCk4eOqkYW54VGUoNGfYAGkI UHDIACKIVUGlfRUAWpHDUD2mh2NUVU0WgF1jAeUldgzHdU0ofzODYlN4f6WXcCmwdVr4df4nUmDn esy2AgNIho04c7ZIhoqYUAVQAf9iGFW51DTfdIb/5DP0hYK7+Ds1UEUOVoxc1HiOaIlTEzxjGIjS x2CcBXu3eIatlIjSqELMmIsV4IdSEwMN4ItwSInT2E+TKIfTKIMxJjVxBnZ/5nXBwmvF5l2m0woC UDN4tl2p+F1bl4VaGGj/h4ReGHv69Iti2I1iWAFQ8zsSiI4UCZE9w2gKuWAVSYNTIzJM85AWCTy0 ZDYM+UpZw04lmZJkCDXSWDVn2IhVFofsuI0/KFMvKY4zx5AhOT8jeU4VqYC01ou++JCi5Y420AAo iWT59lwMMFKdGGPlFT6tGAWm93miIQAptgQJV3opoADFRpBaGHZiGYtfKItDOXH/Z5mWaumLElMx a7aWaekvcHmWZGhGGjNuRFmRDBAyFXOOKvmLfHmX6aeRZJiXhlmXYOYCFKCXjEmUlXOYvpgyjVmY lFmRZxmYBeCXczmUmPkDm0mAbUkxngmXtoiZiomWMTaOLnCE5BV2rsh/o5h1VnkE/XhnsXAIBhCQ hJWFYJl6K/B1rdmFXhiAaPmZxlmYxpmcyrmcFGmLYsgBluWNSQOZ1FmZQ2md2EmRj0mdhsmc3vmd 4JmcsDecB6mE5GWPXJeFxGaFGwWFUYgAtQmfp7hdVqiKA9mKr1ieX/iFG2CW4fmfABqgZ5lGdsUB vjh5QuMCAhqe27mgDvqgy0mc/6kpiwgpdoAGaFrIa97lee65If3oCvUHAFRYn1pHbBPQm8d2ofp5 kLLYnxD6ojA6lO44jTGqnA1aozgKo2W5n66nn/2Hn6u4oVVoTPEJAFiZEqhIol25iifaimCXnyzK o2bpojlapcs5khIpg1YKlze6pV76nTtKoSuaWL+pheqZj+05f9nzof0QbEuQmwG5pFiIoikKnPq5 ASuAp67Xn3xaAX36pcZJpQ+6AQXAUBcIqGppl4i6qGvpovzpizyKkLBIXq9ppnKUj/U5m/C5qUY6 hXBqACRqn7zZpBMAAa74mysKdni6Aayqp37qp60qqIxqpdBJMRwwA7I6q8qZq/+6+p99+qsUKqb6 2ZqVmnpnup6Z6p5G8KG1iZX1RwK5mZtK6pVY2KSmWqqnmqqrSpatCqux+q2x2qtqyavfSa7iGp7g mq7qGq6Duq7f+qp8qqd5Oq+pWqzpealCOqRMIAAeyqlHiqTROn9KuopMSpDXCgGomqqqmqfu2rAO +7AQ+67nOrFzGbEWe7EYu677ua0Ka6/HdqaYaoV41I8kSwQC8K8pEbAKAKoDW7CkaqqmugIIq7Dz uqoZe7M4m7ELmrPs6qA8+7NA67AMy6r0Wq+oyn+8uYrImqkaUrIka5uCAK3QWoX1uaQEy5swW6oy u7UKu61eG7Rg+7DeGrZkW7b/Znu2F1uzRduxv3mt96q0XRmqUrsETtusJxsYKsuyVmi1V2utEPC3 Wzuz+jkCC0u4GzACaJu4iru4jNu4Oau2eEqz//d1B/uxTXq1JKqm+7qpJOusKPsMAcuyeuuVV0uw f4utf4uwqruihNu6eIq4K4C4jju7tFu7tpuxsJu7r0uvhKuwM5u1x2aqBDsB1Cq3cPqm8Nm5Jtup ADu1o+uVpHu1EJCFMJu6gMu1sZu9rRu7I9C93vu94Hu74ju+5Au04Hu+3pun29u7vaufq4u6YFm6 0EuiAUsC/Jq8nHu3nxsLobuy01q602u91iuzgvt/64u+CJzACny4CtzADrwB/ywAwRIcwRQ8wRFb wRhswRmcwePrwB78wSD8wdqbvSv6uwSctcKbtEsqt1JrAAjgwieLv526v1FrADbsv6FauqsYwAI8 wBgAAR6wAhgwwq0bwkZ8xEj8vSywxEyswU68wU6cxAgMxRksxVZ8xVhMxCT8u6qLuieawvKbrHOb m/h7svrLvP9gw2qccKPLt6abAj2cugS8AkE8xHY8AhhAuHn8vXuMxX7cvUwcyII8yIRcyIZ8yIgs yH+8yIzMyFpcwKtrvaV6ujq8wvUJqi2cBPxqxmY8w2jMv9F6wwk3AAn3Ai9AAzQgAiLQAi3wAA8A x3Gsuqr7wxhQy3SMx7jcx//eewEXkMS8/MvADMKJnMg4UMzGbMzDnMwosMzLnMzDPAI4gAKK3MgO zMvoC8zY3MvW3MBDjMexa8dCTMfiHMk9TL2VPL+XnMmbnLyc7MlpvMY3TMoKMACmfMqpvMqtzMOx DMQIG8QQMAIekMcCncu4PALbbMQYkM2/XMsMzdDO/NAoEM0SHdHS/NCFzMwY3cyHDMLLTM1GfNDf q9C/bNC9DL4DLdC2nNLg3M+Au88BXMlxm842LLWbzMmdjJU0DAhqfMMsS8qknAIDkAKofAA7TNQu zc/+XMfh3NBMjQEf8AFNHdVR/dRS7dAWbdEafdWI/MuBzNVaPcgXUNGIXNX/ZF3WDU3VZI3WeOzU UG3WDC3E4BzE/izL5VyqcCy/lozDoWu/9mvTN10VOw2qoOrT8wzUKXDKq3gA+JzPf+sDPpABGZC6 HgABJ2ACHmACmG3ZdlzLmW0CGGACbf3ZoV3LH+DZU20CLFDVpU3VpZ3abM3UT80CH3ABH8DEXi3I Ya0DhIwCFyDIvL3E2EzIvAzWuA3MYM3Vww3cxs0C2IwBgnzWTw3VaO3UqL3ao03aoC3dpq3a243d 1D3d313aAC3ame3PmJ26JpC6kJ26PuDKD9ACYUy/K0vTfe3XZ5yyO+2/hB3UQR0CL5ACRH3PLXAA EODeD+DYj/23HgDZJ9Dg/w7e0CZQ2Z293ZjN1BUe1ReO4ROe4RmuAzrw1B4e3TqQ0B/g4SZu4rx8 4iee4it+AR4OzCoe4iW+xE3NxE9N27Nd27Y927R92zlO27Id3dEd1Syw4Rxu5BCO5GSd4Zyt5J+d 2bV82Z1d2fzc4H97An+73nDs3qzcAiKwikEdqoLdwvxqAPbdyYAd2Po9z/ydAiEQAgAu1DRA4CnQ 5dZ74AoO2RngAXzO4Hz+4LUM6BjQ4ExN6E3t4Ih+Agwt6A2+3ZVt4RRuAh8u6TH+4T3+4yhe2yc+ 2xjw4SVe6ZMO6ia+2qMO4p7+6ae+6ahe2h7+5Bru6BG+6IY+6IbO6LMu1f+3TuuKHui1fgJ8/ucN /usODsTrDQGRDQGO/bcp8N5xrspBGtNs7L+hW9N+HaIAoOYG4NM+bdg5AOdEjdgErsqL3cqu3Ng+ MNnoDtl9vud8XsuQzdDv3tDxztR6Xu8ZAO/3Lu/3rgMR0OAq7u8mntmiLuRCXuoqbuqgfeKQXtZM 7uoOz9ClneQMDeVknesZsOsYMO/unu8an/H5XtUdH/Icf++/ru6TTezHnuyO/QAFzvLTy8oiQNTy K8/RDq0zbcMCYOZnntOBgO37PQD8nQM5EOf+fQAEjsriPu5/68roDsSOzedP39COzdBTL/U+INVV 39RZv/ER4OGQreIX3/X/Hu7goq4DmA3qCX/iZ2/2lF7pAC/qbz/2pv3oEr/o3Z3oGK/v9P7xGXD1 Vl/LW48Bga/1fk/1hQ/45+4BT8/nxn7u/IzsPpC67l3grAwBdJ4CqozKNPDfPz3PVijYN8/XZ768 ac7T2c7mbA7UN5ADRH0Ab07gB4DKlh/LlY/uHsD0t/8Av87nuJ/7TO3KUg38US38hm/4Jx4BX2/i el72EY72be/hza8DcR/jyX/iGaD812/i/X4CY8/9J/722w/qyz/ixf/3tUz85/8A6f/76k/W6I8B vc/7up/7u4/nTV/uf2vnXW7UrQ8EKeHrFUopBgqkwmBgNqFNwZRaBVyx/9lstJkcfL+p7+2WOqRy ocM6RIQcIA4aLQ4RiSAevafV0vf9/vowCAEJMQwPFQcVDx8eI3R0Hh8kJx8tH30sfTYzMixDJTNO RC1PUE9JR0FNLTN8MiIlO2V1YFtvP1lzP3N1X30OO4UbKR0fkRsZExFbHhqjkxWT9zwe9bDzIB76 IPIAvyH68Ozwzg7mzFJC2gfElpieoEgE6quoEAAEtPqxuLogAROGzLocOdawaUNkDh0HEGjg0ZPn zp47gABZw4gxWqEWhyKEFLkRkMgIGzFJSvmgkytgLn3FlBQBlstMlHBWUkmMWCiePEX19JFTZ6iQ JBk5W/bRI8mOGPb0sf/GJ1DUQFI1Yrwj7ts5iG/QEWnXLsc7L0ucAJSCzwo/f1rUDpRLBh3dhG/G hnhTZ46HPH77WrwjwkNFa4NFYLjz9I5JxxEQQxbheOPIPiIpzfK5yebPUClnPo6UU7NKnKZOg870 uaToo4Mli2xscjYhxIoTP7VN+DBvwXoM+wWOuA7fvTTgoDNDNocYeGfTRrlngO2Ufdff/uMywIBc MM7RJRRfB85D83nMT1W/noa1hlNdx5c/n/5jm/Xx59e/nz/99f8BDHCPv+o4j7xvxFtHOSHAWIK7 eaIQgLrqrnMruysA4s47sw4YIDzx7iqvwDj8ckDA9YhIMcU9+mtRNJv/RHFRxhlprFGkE3FUL70R HyovuQQXNOsLgZBoAkIpJmSrwgu1i0JDucR4p0MzQAxRxPTSy3GqvELQI4EvbQyzNBgtEdPMM2XU EseHPDjPzb1+BNI5IYl8UC0Jq6MCOyYz7G5DMc7wsMofeXTA0EPbTFTNPb5s1NFG0YxU0klrfNTS SxtddD0Td3wzThAVNCvKBrmLLsIkleTHwuz63PCLKQcd7wA3DY2D00RNVBNTRyl9TIWQYuxV2GEj 2BVTTfW49dBlC1wDrCoVHFWu7o48NU9VmcRwO1fB6DBWEB2YdVZbDcVVU2PRBTMCFdht18Z2VdAh 3vp+JdZe19LNN1M1/5Vt0zxPPwXSQyGnLfVOVPFZks8MuX1V0G/FDXfZicvtN1f19N0V3o057rje +eQN+eN7h+0445PRBdBicylu9tlBzRhY2oHUivBahS+Mq2FvH45V4lkpnpjl/1B+1OOjkebYsXiZ DpnGpDsWE2qoiy5aZZaDPjRiiNcANMqZNawZ4VT3ZLXVDTsUtOcqf8562aHXqzqBqemum12R6bVb 7735rlvulP+z2O22uUZnYG7FvlZPbBfezk/v0l5j7W/bztrcuKvuu+51RRYZXnnX1Vz00Uk/+u9L A8fa7a25dhhxg61VHGezowABhMcH0ED3wyUvPCGJB0fU4tMv5Tv0X/9hgEHedmHIofmm2+0c+uNL r97j5E0mPuMSuC/B0aGD5p7ircNdg/tBB+6gg4YTVxzbVd8CyPYnQdjdYW99Jz/4is3V3tHSsce8 5ClvY8s7mvQ8Z73Scc9j/ktXDyDYg0etjGIQHF/5QARBEKltAOp73cHcN7v4cQEEPNCQ7UCANvxx rXL7G54Dq8dAASYtgQq04dFkaDoHXgqCqBPcxCy4LNaJR33iUVuHPOgqsY2NbPDzh/xSaAAUekd3 ulvhGqqoAfE4QH1cVF8HBtfFRCVAfY76YhkbhcY0dmBuZ+wAu9y4sQj2YGM5VIEdOTbAALarezns Y/fYhUc8wquPdyz/AR8PWcg6lgCCKmjk0dz4qEia8YtfOqMk2UjJL97KjV7cpKHOeIAirqGIoRzY AeonlyzWDE8hZFzOSGjCKQ4EhSi0ooeymMU1OCCXuuti0MTIKTW6cZiZXGMbvwhHYipzmex6pDMP 6bE/+nGazpwjHa0pR2xy7JoRbFc3n+nIa6oPksRc4yQtScxLHvOcZ/TXGUEJT0+6MSG9rOLA7Jc7 DdTSdgBppexeSbsm8ICgPJgfLQ/6hX16yHZarKdDD1BFoPFSd0GraMU6oIEvVbFRHE2A7h4FUhXo Dl4kVaYKktkucp7Umt7U5ja96VJxbpOlKH0jvFa6sZTaFKbPTOlO/3eq05xy1KMfBalRO3pUpBqV qBVtU0Y1YKiLHmqqVSyfRLFoRcndU59fmGJ3pHg7LvzzZgEdIRQKmlaE8tN2PEAlW1GY1d9JNaoU mypdHfBRECQgrxvV6FKTOjeTsquKG8tlHG2q0jNyk6Y4valiHRtZyQqVsjVlaU4tW1INbCywjjqq UpVq1Lxmca93pShel3XRiEJUrlgEgeQGdlDZwrWfsXNltgAAEIJ2p6BgMChtc0fb1751iw6wXdCO m1qNUpSvzf3sXzs7WMLmcqT2NKkGHpvYjmF2spbNbnUNu1mOcTen5L0pd6WrWc76NaR/BS10kZrX +jW3fhO7qGkr2v/ahNhuv6/lnUG9msIBCFesUCBrnkT4RC7slrcm/AJB0TZg/8aKv1tM7sQubKjj JmDDfbXdlz7sqBDb7mi2FK/HpJteyG73u4NN74tPrF4Zg1fGMEYxCOAl4r3qGMQ75rCPOcwD+oIg r8Yl8rKSm2Ej9xdEJWSy62brVROClZVMTJhZz4pWHnShtwPo8oNNeICC4q/Cbx3uGpR8KBSqOckf zutve+xjFPYYXiRmF1vrfOIUx1izehZvYaf7Zz5X18+DJnS7AE1jRAvazzjuGArZ9eM4N2rOku6x owzaXIOy+chGPrKSyxxXNFc4uClM2ywP2lstj9XKbSlbdiQUBQb/N9jBaVVrh2w95jXkesxZoy2n a6ljflLa0XfGswpoW+f6Tfdo1g10Fhe9TzsjG64eM3GibWzsYz8arnEO9qVBLGT6Clm+nfZ0Ldks RDOPmq3e4jWEfQvhd7Pafe/DbaxX3QUDfFmt3ZIyQUEE8LQWl2JpdQBBl2Xr5jZK4QwXN7wKWmxt S7xddp52x6hb0lpWfNvUJvHFN7bxaYP84iKneI7bStBHNfxLKm85ufmqckMhPOEGPxTNAy6egQPc QxAuIbzlAmFab5ne9U6wP/Bdsyc1zN9HTAjAITYxHtR86hNrbpFRZj2Q37Diyj451xu4w6uPfeZV d6Gh8pcQDqaN/+lghZ0/W724V8N6iW7H3c5etUKos/DgvHYb2bNOuq1zPdlg16HYAV/km5t9f2nv XeSYTrO3w73e9r43deq+9Mjzzt1uzV/ZCxo8wAdec4MHu60Nv17ENwrrrZc641fn+CO6ru1hW+KB KYRluic9Lm7fPOQf7/izL2v0pE/98fu2+ny1/urDn5jj1Q5btm+eyrePu9ydCGs8Zd73v7/fFT/v fOb3tWjIN3+OlV+18Tdf/GiH/uwPR33bJ+761tG99rfPfc0zHfjg9137i6/8zk+B0k971k/x2g/6 og/y4q/2qq/KcK+JcAsLpgDzeK/39o//vm9yCgcAme90BtBuCv9Q7A6Qr9rP/WSvd3hn877A7urO Ao3u/vAv//Tv7iKv/ziQ75wv8bTH/EbwB3nQ9U5QAfFnBVmwBeeP/iJQAifwCqrAAl/Q7o7QdYqQ CD1w7IAwC7Vw+YKQ/YZQAeFv+uTvAa2v8iyvCfcBHzAvCqVwCoHP6dLu9RaPYjQN5sjPWFyuaPIw Dy+FD7dQbkoQAcWP5jAo7cJwCsHABetu+ypvSbLvQtgCCtkwbBBxBYMvDstuDoMmAWQOC3fFDzNm D8UNU0DxD3clEBPvBMsODFWQAadQEV9wCXNv7u6tOtZwEtvwCN/wEjuQEAkxa7rQUkoxX4axD0cx C1ExGb1QFRf/LwV5xgiPEBYXEQZj8OiY5FokERcz0PtOyf++xdb6ru9+cRzTavRUrhxXDh1fzuHS 8RyPkRMLCh7ZEdOmDvAUDuvKkfnKsRPF8Rf7kfEQzuaezvNapxVp7xWTMAplcRYfMVsUJxujkBJt 8AbvBw5jBRzfTRP/kR/rMNfokeVE8SNZDh498s3sUB71sSTf7eoyEvRsbiPN7t10jiBj5RArUSLZ EEkW8sqs0SHdByIjsvsQEQe5Zu9CD/QyMSnD8VA6siNNEuZCDyWlMh6fsimr0iTHjiOx0iTFseYW LyZ9ESyRcixDb9eMkiaNyCAbkAWlMCcNrP54siFr8SdpMCcl/7ISd9Ebz3KXkjIsYa/g6rHIZI4j BxMqDTMrDxMfE1Mjqe71WtIf/RIw5bDvAo4g924BobESpVEhqdEMHRENtcAMGdEtoYASb5IoK3Mg K1MpNzJoILPqXlMpw3Iyl1IjY9M1MfLdYBP2yNHmXtMsUxM4MdMVEXIzY7EzRbMnJ1A0K7Au7TIX dbEig1PM0BLq/PErJdMra7MvxZI1a/M2tzM8cfMoswY8HTMcZ1I4VRM4bfImjfM4dxLBzhA0KZA5 R/MCX/Au8XIDqXM91xPqvvM6b5M8j3I2x7IrD5RAIzM7W9M2FzRA3UrXqNPzLrM/h/MgoxEnSZMR 7RP76PMtOv+0OW+RNPVzKL9vzCrUOi0z13CTNv0OO3sTHL9SRl3yJanON1+0Ro9yQgfOLG3NP9mT OjMzQ8kwJ++zQz/zQ/tBVUL0PkmzNIWSBRkQlXquOinUSi9TOxmTRufwNQOSN0PPS6fuOmfUMRlv IAUOS9WUJveuSiUHwsSQLTV0Q5GTOZNUSZc0DZt0NJ9U30zTDaXTG4kQXJixUMtTayR0UBX1/dQy TuX0PaeRQ5v0TvE0NCtkT520T6EzOk/JIhf1U0G1SmQyVEm1SpyOCt1zTuk0PqtRBvHU3jBVRJ3z Of+UUyOnCks1Vwf1R3V1UU/1GYmTSBPSSKEwVmG1UmHtM43/NVM1tVZtlT8FtVeldVqJ8Fd5Zkpv EgkhNVLrdFLnE1lB1BGXVVY11U+jVEpRFVdzkFrZVVetdfawdS0RsS379EiNVVnB1SHxdVyLtVw3 FVCNUF0fb13blRUF9mDfdWDjNVizlV6f1F7v9VjztQmPdVypAChJ9F9NNGChNWERVmE/NmQ9dmQX FlU5Nls3xGFXtVu9FV8nFjQrVk+XtV+ftERRVi5K9mQXVmB11mRz9md9Nmjl9WZTVlWJVVIj1mVf Vklj1mLJFT/zU2OJdiCAtmettmqxFkOndmvvslwhNlb3lRaXFg2bVmZnlk9rVmq5dm3Ztm3dtmBU dmVZ1U5jyXZsl7ZpnZZZM9Zm37Zv/fZv2adrvbZYLTZs5dJuK7Vs85Zm+7RrAfdxIZdr23JYH5Zl MTVsETdz87RiF3dW09ZxIzd0RVdbHddfrcVyQ9RwNXd1kc5wLZZxy7V0nXV0aTfyJvd2KVdTv/Zy y5Z1fRcS97VzR9R0cbd4a7c4Zdd4lXfyiPctkRZse/d3pfcaXfdsMbZ5lzd7k3d7tbd7uTd3sfd0 59Yz63Z6zXc5q9dYYTd8xeZ7vfd9k5d95ZfyUNc+Vfd8KzUIAAA7 ------=_NextPart_94915C5ABAF209EF376268C8-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 13 18:54: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 SAA10481 for ; Fri, 13 Dec 2002 18:54:20 -0500 (EST) 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 gBDNuO324536 for ; Fri, 13 Dec 2002 18:56:25 -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 gBDNuM512421 for ; Fri, 13 Dec 2002 18:56:22 -0500 (EST) Message-Id: <200212132355.gBDNtsO07376@zcars0mt.ca.nortel.com> From: GS Union Subject: Õî÷ó ïîäåëèòüñÿ ñ âàìè èíôî î çàðàáîòêå â èíòåðíåòå. Organization: Home Reply-To: alexunion121@hotmail.com X-Mailer: The Bat! (v1.52f) Business Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="= Multipart Boundary 1214020155" Date: Sat, 14 Dec 2002 01:55:39 +0200 X-SMTP-HELO: Localhost X-SMTP-MAIL-FROM: alexunion121@hotmail.com X-SMTP-RCPT-TO: gparsons@nortelnetworks.com,gww@nortelnetworks.com,ksundell@nortelnetworks.com,lyris@nortelnetworks.com,marco.carugi@nortelnetworks.com,mleech@nortelnetworks.com,ppvpn@nortelnetworks.com,taylor@nortelnetworks.com,travos@nortelnetworks.com X-SMTP-PEER-INFO: 80-235-101-162-dsl.plus.estpak.ee [80.235.101.162] X-LYRIS-Message-Id: This is a multipart MIME message. --= Multipart Boundary 1214020155 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit Çäðàâñòâóéòå. Åñëè Âû ðàáîòàåòå èëè òîëüêî íà÷èíàåòå çàðàáàòûâàòü â èíòåðíåòå, åñëè Âàì åù¸ íå ïîâåçëî èëè äàæå ïîâåçëî â ôèíàíñîâîì ïëàíå, òî õî÷ó Âàì ïðåäëîæèòü âåñüìà õîðîøèé çàðàáîòîê, ïðè ïîìîùè èíòåðíåòà, ïðî÷èòàéòå âëîæåíèå è Âàì âñ¸ ñòàíåò ïîíÿòíî, îáåùàþ áóäåò èíòåðåñíî. Ýòî íå ïèðàìèäà è íè÷åãî ïîäîáíîãî, íèêîãî íå ïðèä¸òñÿ ïîäêëþ÷àòü ê ýòîìó, çàõëàìëÿòü ÿùèêè ñïàìîì è òåððîðèçèðîâàòü æèòåëåé èíòåðíåòà, õîòÿ åñëè Âàì íðàâèòüñÿ ýòî áîëüøå, òî è òàêàÿ âîçìîæíîñòü â ýòîì ïðîåêòå íå èñêëþ÷àåòñÿ... Åñëè äóìàåòå ÷òî ýòî îáìàí, òî Âû âñåãäà ìîæåòå ïåðåïðîäàòü ýòîò ïðåêò. _ _ Ñ óâàæåíèåì Rusmon mail to: òîò êîòîðûé â àðõèâå. --= Multipart Boundary 1214020155 Content-Type: application/octet-stream; name="Åùå â XIX âåêå çíàìåíèòûé àíãëèéñêèé ôèëîñîô è ìûñëèòåëü Ãåðáåðò Ñïåíñåð ñêàçàë ïî ïîâîäó ïðåäëàãàåìîãî ìíîé ïðîåêòà.ra" Content-Disposition: attachment; filename="Åùå â XIX âåêå çíàìåíèòûé àíãëèéñêèé ôèëîñîô è ìûñëèòåëü Ãåðáåðò Ñïåíñåð ñêàçàë ïî ïîâîäó ïðåäëàãàåìîãî ìíîé ïðîåêò" Content-Transfer-Encoding: base64 UmFyIRoHAM+QcwAADQAAAAAAAACtjnQggvoA31UAAACOAQACMuh5C4ydhy0d M9oAIAAAAIXppSCiIFhJWCCipaqlIKetoKylraji66kgoK2jq6ip4aqoqSDk qKuu4a7kIKggrOvhq6jipavsIIOl4KGl4OIgka+lreGl4CDhqqCnoKsgr64g r66irqTjIK/gpaSroKOgpayuo64grK2uqSCv4K6lquKgLmRvYwAEVBVJNSB8 MgOCkCD0hZCAYDkg3ISQQYGQIHVEgZBBPkREIDggfTyAYICQQtOAkEwggJB8 QICQgGAg1YKQQTVAHCBBg5AgzYCQIIOQQxcgP0CJkDEggpAgP3VAgZBCMMAC HCGVEQzI0VgYAi0lYxjZ8GMbBjH8EkMY3I0jFiWJYksXwzMaabaQkBCQnZCE AgEckGBCEkA2bNIdnZp6bN3pN02aGwk1ybPgbCSdJ8Oz4a52SE02abNhId2E PTSGzps+BDSA+nwekYDGve3V4m2Nsrlc5VVyqu8xJufDs/emN4sWZl3V1XK5 XOcrlc5yuWv8hnmeZ5nmczzPM8/f39yqq6uruqpVlq8X7Fl9197ifA+H83Q/ 7QPeL+Cwg3GRwkGYN8denz9lfsziDt6jXVHeH3Jkx9jJe2iyKnn0f6PE+N20 E7B42GCDbZ367L3o1N/82vDV0HDwc77Hcv3psUFTnvK8XBa6feD+X6mBXnoO ngyc+9t4jKv3qbdZHLuK6BnrHZHiz2Tv78vn03F1MnuEOyiuDcbpOPQeMn9/ AyXpIuU4xE8n1vr2Y4MdtGwI1dMh5vkEHLJ5+fO5GMvI382S4UEnx3Fc700f LKau/NZr46XCZ+lr9/pEgcATzxelqTf9cmOasJNDyeVSD+MnaP1n6NUjOR79 On10kX91kg0EpafAvj9GSn67u0gfXCxuc/m6XD0HwvsspqxbfM0KDaJAv8Ke XmYMnd6VNd9fFgpCuYQvo4/IXD8TkUT7JNj1zxe/OG66pssb3f5YwTfsPPFS z+F8PIT9+qlBPHvsf1ynxlIxqmx7G02agUF/VJL8aURhv23BwqzVa79Uvh6P vESPAbKCxgzcj88Mr1X78/DroZ0O7c1Pn1MGuijjzxvFfLdQ30MyGhUd1z4a UOJDd1HJIy3hvY3d2jDeZMsk1cb5538NFPnVp98+N3mcSo3quZOT64qfj4pP 64MNsr80k++yhwFU6ir4agFI3sO95mRu7uBko/manzcQ08mWCniXCfv3g7eo 7t0Mlt1cduzfZLdlwqgFjqSeDu/eQB5tINSr/VCzTbm9rpQ4pcSenntYn85J qk/bRVyt7njpA6eyjTk9FumYyo5xVOAGaKeJeF1gUTVw36ftoVEKVOT89qml 58qzHqBsnHUAYW1eJ9d379gALBoKlms5e66SuZu75940Nsy3JkbuzTK6wV9q oBuHfp9+6b5V6QBS5T+tJnw7v2yrDw1AJhq6kA2D4ZxusvlBGPz3ygsGgB8N ybjgtO0hs4dIh0u54dBDo4dOn86Uvfn4eMjlo0/HyUVQ1MbuvPK5FQ8/ePh5 Fn32cAcreq8nDST+d97TVZT4gcZQnwVhhxyGtwDaoGCO+VYfnndJoWGoZWKQ ETnBViCAc2crpQou8jckMcNRrvC3oQogUDWs5gAO9BOka82KoSYA3PUJXfd3 Cq0viqDzxukIVnZJ5likB3HRWcOhhziqnAElmAKw6NXz2kHnzvYdFDolfHp1 AwHD1kGPByyUlnqYNPYjjuD/cGhroOGL21DOq6YRECBgYqCQLoFChqQFWUiI GmKH9bKsTEhmuW3MIMcSpK4UAW79uGFMFrBaqI8rlVC6SNsmVNbK4T/XhHDv cwu3UijDavcvSquOtlEbroxGo2TNILwEjpygtnKxSw1U2bk0DofUkT9awVnA OaQJ6xVpgIACBg+8KimG69gqv3NIpzChEisPlDEZo1b8xEuEogkCBl11Shq/ QhYeolCNgx4H7wJ0D4QqIQOHgTyJGnFWe9b1irUpMIyDyFXUiqWiwnYOmnEC 2uYYxMhXd12pMdQyKrWMxWA1JVvgrgAFt1coQ3BwNaRqIdbQhx2VgOEUwq6t kgheKGSe/g/mizC7eXxJYnK8YVHvR8RQc48NqWCI9LRK71+q8wkELKefs6k4 G5dQDTg42uYKgS0h+8Lyr4VywewYTsdwdIiJHl77cDAsMgjE5dRYPMCgacOM ajYpGN3DDSdEq/tEjsZzAtDjCagcfk5VeXareEaggLNZy9aoLwlPgutTYY5R I0ymwp09Aob8VGKE8F/hsHNmIF4yrEpD1NSYE9a5XtvIsBPAxiI7CtOKsQqg BGgdOWgvW6q5DqLIrzAGYjwOXNJJhFBRkwJAwmBntnfU0FUPUQUlWiIkMVXx 3BX6pprO+VxwCjt1AcNXhDMKhDHJpLFNy+2pgCijx295uYbhg+gDIbp0SBDH Tzd5nHhnMrU5eUwsUHTIBrismLjmFhUl8WNmIQhMepW4VZS7iUY24YQUBAVv CN3wWJgqta9IXV0rlBgemKDUOspqBS7YianmSNaUkTE9SJ0SY9GV12GnoqZY aCWjNI3C/V9IDlmqJQC4FFlYWyuoWiTDpMFhixxHrQhfUFfGJCwdLfqrELyT mEPOhqAMS6Fq7I5neTwCTkWyrFPcu/JCW6kIDowCUCbFojrciygFIKGi4Vf4 K71UDSg8MjDrpVVTFUIb3XBEuCaoKDGgq7GOo6KaQy+TUBlNR8MxVrhrjJik oJBp64IvlaMyazFqbWBkiRHekapJQtiUmJCIGA3pYeWyrepKHxRhxS6KyVUA 3Ul8bFmdUCHxrSv878IpZb8riTyr5fMHA2i4UnfMSMUlXG0qj0xF9gb5dKKH ZPFEaNP2jdIQ8Gty8cAqQBS5WM2iq0k4zMIXUlAZiqEIAl16olDENc9RKwKZ jeQDdriHeONHEqg0DhsNvl3KnEEA28ODVBVZYBW2OI64L7w6UE6Cx2UVV22w xKLpEXZgqx+ErYbnsQjR0xXwigOAd2LKWiOFCcDDF5zHCxROQuXD1b+QNcIK YVWNefM0mPGGJveeHWNfrRVtBnvgxkpGLFCnXCuuuUK84CiVGEjHGVkoWZZr U2FtwbkxLFpBSVwJ5F/gIjXkCnGhxyiyQwwdT7t5+eSH4Tj0/LRUGOwSUk2G 6VRqJEEUWInl5bNAiRJ6qMN4RSALJjXgtdmRVH+MKgClCQewlEhrCCTyKCN4 WE/n1BdGaWBN4pDbnE5e7SQ8XDnizkc/ktpBaKzFvPeyhs2e8c7Pji+XVZNe Ph0qaFno3QkbpMYhQuCSsdoWI4K9uCA3Hh2cDUZTpJQYGP4tioeUiNcsSvJd kQbfKK/AAoe+lk0tFYKYKlUAcn9blRz98pjmTNjoloFdBPI0teOo4VLSmheP WkR7yajNj25jMLIAmTDVh8FnXDDEwsAKFOey8J5FQP5cmObKgHNAEn5KaKQH XFWMm4Y5HgfHs4LU2briMLlERo8HGcVJaKq2uWDMEIRx3X7Mv9SNnZhwL5SG 8FgXxgs45RLccxIQXg5PUiAnkfQFBEFr4yU8AIhb53G6Yw2YVO58CNVA2xMB VpTSWMzpip5KgNKFt+sJgwBv2vNtmEOcKRMc8F9QYCzREBfKsxpX7k2KftGG aytsNiJ0LNDoEjdcKxEiW+KnUiN/YZB7eq6IKjvCtk4IjckKHgsUIgE4PNk2 cH5dOZfK1EUCS5mZ8uOoZDt4D1CKOdLkJYKgcXcds4BJZSYEy2xue1qgPUYR u2FNarDHu0KbS/VyXUF1EiwJjEdFBlyWn5iWxhkixDhO++iSZS+JZUz1aqUV p2eSZMFq6TVesVTBEKtaIC5IY/lkLCfAFPCmAEoIAwWtfUnllcITDXwfXeki 9HJOsyOrwnEFAkQLvVGb5nEJOzRJKcvLfSUJeApR7mGOUmmxwaBoCvNL3U1V avN/P5wcufIIpGmO0WfGFzZikNl3VFdrKylgSgB77xhTGgcw95MySNZPwquu AxEqdS5XcGiwsMUFOMQhwAAtFqnq2ZE4CyqCjKB6SmoCcOFa35NUCuEWcY1H mICiOm6IYArhOqgd+e4VlY2+VLrwda0iG/lFaXElKgw1ca0LqD4flp7V6FGg q+4TU20JqPga7AazS5X0+YBgPKoKEyKO7Ee6QORhuZLDcKFo+sAryX5IE04v PLBOIony8lCj3aQaORddPYh6nmPoElLEYYnjuHfgG8sH1BmgSpqBc22hFXTN SmoxVgJOIZ0moF5ceIRmm+7s1XzpqUWZhVJcKAWaqwXRpTCOCvjXub+pyA58 jIek5KI8QcNZX6RN6oMPpaOMAcvWHUTzW1MqhnUqlPWLFC81Es+g0GrWqnMx mh7vzXfUGIVcuqay0t6krrR004TL0wy7jUMJQATHBAzGGsCWyNQgA4+oJvcm Q4LsFi6cNzwURam03Cc/XVAtMuuldEsj0TPA+UcjJYSBUgBldp+G0UHtOK7c xknmqyiWkSmkhR5ODFT53m8BPKwSzlrgkNggUNWjxbxV3Bt8dG1hsXmu0LQf assgkS7NkzV1O4xyuMQikPg8kFnNOss2wCIRqYOMdQ0WMdgsPoblnT2J6R1r QWg1HjilkXhuVgFrL2E8YZPJW2G5NwWIwdatUevlcpucLReXhgFg3GEUU4c3 IEArSzbxRDGeI9nkzEYzlCkmEgYdGpem0UwVmdX3XrNZUOp1uDEW0lBSFvhM dpqEmP3gGdNzVB27iA9ZKUFtmq+Ijs10NN4n7f9UjHPNGgDkLnfe7k4NV/Lx 9gWUJbM1msX1l5RokVu5mlVTQLJklUMvDODyWl7xVDkl0G6gpTU0r1kXauRL 2VW0dV/DfVpHD6Et1Des1jU95MtaPJnV5YN8woQ+d6dbcEwo63Se9Fk+xdzS BpqgfaQyqkHQ3csW0fl2RJfGnCisa0mY4Prmr4v0roexrs5pgo07dhnN01gy YrDUQqBI/zyxhcKzibkxMVI2jqvWGDSqpQfqg+OhJY1woa+0Vy8FVBbo5Rt0 M+vCULPZkGYYg4bM3UcldOksVHEksYQAyeYu6mwqOe5kg3RrLwSWzymSIJQy 9NeArN00dMLTx6MisZirKu2sHdHFAWRcu/6YYn0ekELlqOuIwv64Zr5wWEJ2 Qm3AAlaZMT6khNJUmFdqUw2sVQQ0DHgCEdAsmpYHXrF2FS0NB0STlehg9gn1 59NE0JkBB1FaaxLXOIu9bvaf8BWd6w2zLaJOVVXZ9USK3haToc01jEvWUAY5 5yFqgi4xPLtweF+Wl8wS4kvhCFIvZCCHRGxpEeeCQKrygbpQCDmCukHpUBWh uquGKQ1cr3EMdABlwFE25tB3gszCr5mN5Yy8AhetVw50suzhxLHin01glt8d va4eJSuKck9nE4rxYQhnriyRyckNihhJxEnI54ijij1ou8WGWCt0Q/hx9OVr gkowUCzDp5iTVpnmkLhT1nry9UI8OFy1CiaqqBVkbwhIjXQ6v6/lCzZps7tu kYaX1MZk+HNtxyOVJpZRmoSGujSvrDUU8WhwNaSburUNA+Fa3ujnRUS7QLVs 2JWI6rJB1bUAzqnhSYuLsNhBOIwaN0w9Wc4toiVHfMKpbk+vlegI9TQ3jM9E PvpmF4+g4EmkDNw4U6exbpPj62ECLF4oP6ULVQHzdy8wMUIIlLp7CzRMlmvF mPnOzHAWGjjqAT+a47oGMcy9xHFIxs2TZaPJOV3Fakyj2D439NpspYm7kjay 5YxrsruBSAsbHUKa9yomgRYtQ8rSMCgZEZAWphKxpca8V+1gaTWJpskS1vRU DhTnHV4aLFeNueqFbZfND0a2BBfM/VapBLNS4asPnhNI3DkdiZTOMVscEbKp LEVe9OimKxHXJg5Uz8WMJG/YiXPpwRGQPDTk8VpbVdy7biEUC7HZpWRDC3jl bQrwKE/7EIol3Qc1sQr+dubU7LOgd1EE4W40u4r+UEvMHLQ/lpdmkqiBFEyb 5eUSOi0HVdyjBsPjE3R6q0hDM/EfvY2AdaVgYrLiBxhxfBZTqYF0xzErByTV nkUy6eYzNjBgdypQ4w2octx9aSmKzSB0C6aZLHRhkirUyc8AwqrUiHazglfC znL8sDRSw62OrVTykWCuWaUfOqWQw6UuPrLBEVNc00C9SNOZedOK1wcaqNnw UXEnpx9Oeu5QlJ3TpigyuSQohT0qoCyuu6GyndSwOJbUaywRkphm6b9fyW6I TZmuCyH2Eoldwzxi6s3KE0y3I+4AudAxjVMU0516VfOobZrxSwj2zsPpYdBD xW7KfXdvOAwYxAW2VgoBPAigWVW1G+mSxZ5aMw+HLGPNn2EeSSaF3fYzyjsv CYzbwD1xyV1yyvWMtNeFk8xEl8wg25cLgHoV029I7ISL2BBZMyqRpknVJCTF LgxdEhTWBbzQZE8SVCtaLICLCanDaFNI1BeOxmqROSjfVdTXW8Fq9leBTTMu 9TWz3A68A/FEnSXATOFsMgjiFWOkpZsIlDIPtlU3NNbPWXgoA6L1CphJLQSH 0EoAi0skmCuafaIVaYXDtomJXJzXGBiS1S3yrEEk9jquOC29IQV0lLdU14gG /OyV08xDYVFQN1rcycTB2EQa9ZdfEe2BjNNmtmvSyq7uG8lXHM3Cg6ilTIh5 JobrDsmMIPJLJeSszXqQuhUWtpaWYdZMX6YRjkwWWgckomEFdyCTEr9EjK+5 U2apRVgeHS4TpCxFnYcSWU+BvxQhWaCOlfGdJd8wdy11CkQJjzAFCshCk4iA qTwCSY0iG3vs714nI4sb0spDWEDTjGwHD8x2VDyqb2eNRJSSpvaCXXEEknrc AWDYTqdvFsQHElLYavonUjLkgFmwCO39TAgeItAtdsy2j1s3mtLwmsR+DYgA EARilCpuYPl31FYJk3DXo+wA9gvVhcvAObVbUAuWQk029jVmHL1RdJrxBJzk k5mnGymJTWORgbQOAa1bDM+MuhYtEhSXGM01TQkp7W0iq9Q47rsAtWIdbwE3 Jq/bQJHj+t6hY4FWNYo9+hMCeYlQ8y2g5IidM7+vAKdqtenAaPYPlfrMcKdQ VValWGS81EPjuIF63VupTqt5Vr/gcNxkaBmgTizeKTENFFilG1JkHy0WZ87Q KF+DkcrLYXuKsRrKfATK4J3+YjOSvg7nuWYEE5QlM4lOXG5w5iQCuH2zGTLK oQu66wQ3cBjwfvE/h4TAfNxCBHUev2LIAqsC/G1ul2n/apPnkKojJpreT1yr DMOnSUWBybyzeZKKoSPBVFzTLwG3YEghoTix0lzUMIe28rAZTFWIH+C0lNhw mMmvOjJpSCpcifafSJACa01Aq6QHFXLKnAY5aGwwwpCiTjkiqty0ToYRjgBJ R7mqDb6LReReXr8LQ2Lw/TPLCM58UxXBw2IhbpEgqJq5BbsCFThqvHBTl5zr RSjl6NU2MpJBC0DOXwPvafAGfeHJfT3kRs5Ih1tA6cUACCSX6VDue4Qz4gxi 3Tbq+O5guFfDNV9OSTqjqYDOh8tb7MyNy9OlNkW6e3JzrQKHNqnK6WTW58hS yeyYQFoddNATBnpsu7l+Y9dcreWaw+lz9xxSkw0MRi7YKpqKcBaqQtQZxFCG MxCAXpt8Pyq3baHXB7wWAhxLWtTCRIN9LQ7p6WuLDkkaxiqBrYcWsaD6XxrO LAdIhVHjaK4xhGs0Ll1UodhszNzjrgwFu4aeZaOEaQnILFbu7PT77eC6i1BF lAg5SClUL6C550RU5zJvdSnVtdLB0aRwSG3Ssl22VooiaG6iZDkszWmZJCtY uDH8lVBMTkCrkfNnT4cJ1rkijfHyscIwvASKWps8csG7lmcBLjUkMQ18X2/q It3m5bRrPogBu8OfCv4z3Tni6G6qjmu2CHLRPgNGAhS3L8/sOyuBUfOqgaj6 XXjqP8Ffbv3Mbue7QvjI0chehNBWU7KBSLxfU4WlotxuklpN0sJn4+FQi1pa iFuUwHqck4KrY/LT58rVEQejdVOhvxMUqnsd9kpt+OQ44Rvax50XS2l8Oh40 SjGydQALkd6LGtsyMDJojHW6BRCyeeG4DHR8Znrj6WMKU7b1NiDMbTlIOVZB RVOF8mTK7/Ui1N5q3CJLFFmtxJ9Qh+oEt5Tdcx8pCopis0zVurylLCrnPEuL riSKUTeSb3rG9lMOxNdVA2gBh+f5wW2KNBjauWmJxpCcRjlaE84cUrYW5Zgs HWv7ybGuJIQd50WMJbNa/bjZOarxnVYw9uoyW3UTNsn2cukqp6Yn/VcuCVVA pJNeVqo1iDxpk5Gg0xdR1nqMNbGknFRV6NS7LL7vCQM24rLbX1jVQQmo56V5 IuxSVWKuCQ63MR2v5Ecknl0WLVKhq8wsBG4sh9+OYTVSY2uFDMPEBcAonaZ5 dgL00eWQzfs20yq9gUXkatc0dZhHyt0Y3boW6Odm1spNySZVWaXa7O5YuFaH fEs47h3NwS1DKWTkYptd9qx0tuuPlRhQ7dFL6BtKFIlpXKANy7SB1YeftGaH mBahRMhdTyZbC64L32kGyVVM+JfPP8WcjiGXDWeNco4py9Y890jinMLjzz5F TTcosC7RxHM0rPITdKO0cx9HMPhnwh+aWS3ENqwNeGcGzYyFzNxmYmfp6+az QnV9l3IQAjFTFN5U2p51yjTqypYSdKsJtR0azSMqrmbCk7HVKiV7dsVQbJcD GL1TGAoizCcUznUbDurj4qxeaDw6mlZSWnsX9G5ZA0feJhz8OeS/vAf4GhhS 0j3Ioc/DZlwAIEs8l0Sgu5EYeA0aeDooRz9c6r99Ar5VQ7wl/hcfDZrh5doh f9Kn+qnmF9IdRZp+fQq5dkqmccrg8SEOIB8O+D1KeBxqvv0qGyT54moh+ahx SaDqVw9UlrRWUBOZ3UOWxoFJvzSuLotRzcGRJmgI0oWNY+3m6yAbov6n5ojA 1TY6Q0aZJu6KW5UHhGgdYRStHMxvOKduV4th1MY5Km2DSMuXlMkJkRABp6dm w8V0uRuWdhLg7I+oGfSOyReX7C4hVOJpl4CSjSZAg6hIo6gLSlM0NrlbOBJk EiidJyHDmRO5MEwuBu/yafbcKN4U6716uCN14q2Tq6imds3PWmDD3mGtpYrq p3J5Gp1OOVNmS3fG0kCmWJiHeTTutjUziwvHRlPtdzCxqImqG+Bkqqgh11yM Apj1s+Xalosj8SKUDvWg0HUXLDoxPEXaDVyUKc84vBwVd1pL+SqZs4NtYoS0 dFivKefFbpFsrxp/Cw1Y+G5rX2NQkDeYwBprMCmOwpuBcyRgeOV8szRyFOa1 FQUqpCnzBwjqdz9l54oesrmiVtQzCpTRR3JU8FmeP48YDEvAnJWp3HAsPao4 4VkAXZhvifCJ+Ix5lRxK4gDeCThVMeUppkK0Li8/uVw1HlcVYtSaCmG0K4QG xFWUTmgJiWuMoF0fS9LXSYQLgnhNTAlMp46Uo9SDq+H+tXjVhG6mazAI+iBl 1pyOAp7QM0OgqGFsSIQPvy3pfh0ztsLQFXkFSHAsUPBBerAYQ+auslAR4Ai9 RBroOUSfKqMnF5IjjHwkMw10iBeaMJMpyZzQsmQWUlgij0iz+15epRCtduHn tVBL1YTTWVC35dXAMK4hWN8KosyMqpRoMnUmzP/Wc8YgOtaXfkVeS8GH1zIV hCqXRLl8tjUYZAY5euVXdG/JMjrTFLHwoEaI125AC5kD50HEOFMsAhJsFWRk 0l27Gqgy7j4ZyHTVKBtwWjMf0QYkJDj3owYWzHkUTf3TqtjLTFsfjmy1OE5w 5nQCy6Zx2Y2fIaGwzNl8FTnmp1OrcCDpRok3EFrWYZ0ox1Acz5wJoHGxxcZF ZUOyh68FiVpwAirxzC1Ca0tq9GGsmCm1sSXcouBOqUq7nXjNSIUR9E7yDMmK Q++R1uA3bcfj7gBsJrOtvyOCTmDVRCHjsIqdPMTqbZVxjtApcKxC4gKsYmIt LPXC32+ZEfSoOycceY5NK1Opd/XIPvHrHHMg+x2a/26dgQunDIg19J4MpBV6 izK3Y9Vf6jkTejVN+LYHYb8dMHO7ZA67GYPEEcmMWocC7TkTdjYE4si3BW8T TOrK5W37g6XVqDkTCLgyf9dC22sEl/VuPNWizjVQGixwospyqLEnbyykYIvp qdEXPLudhlht2jD6tmQ0LdQzBwtehwqUZDlqxcdDjmqdt8XRPkFmjBWWcNDc 4y+UWCc5gKr1owPOHU/pi2u4JdywXEwfgDQdT6IuMRhEl7CZ/oil9snBSB9t ODVpQt8tvOwcmBWq3ioJ/gDDHOCWiJZF8CydwDctILckHGAy9xQOemt2JM6Z kAN6tsPvsFw5IcTO0gtmaLVZq4LeuVFQzRcZzkZtZQ6kXnI7OZpfCcytGGll bg8U2zEqMku4PgqN5wNh85oKcWocPR1cJdq191jsaai3BZ5yL0F5AQGc4hjj bwi3zTIsAWdVvgda11LqZV8IpFmmE3Dr0YQUG3KpD4LjbF3f5iDn4OdSKzow fvXUQLOfAhd00BNXYUSumgWDAH5DQ19C25eKonUmDKsSYFfphh5jgINXljcS R0ay5q32kdKFlnF40HIshRS9YIMRAjiGTP4T1jhfghHbLf9sxr4bmPXVJtXp oMFoB64iqFhqxRHNCVBzF8YYt0t8rhxXNtMAQvINStn0HwDKK9aMgFxneaJj hn0APDHSzU1ulBTl2priusLRbjgN63y9iiOIAfG2AZRZeUlOxSSoDXVRQST0 OM/rp5qNMcXLn0f4dcpSIuDCKzhynTOz9vw9pADPiiqc5FMC0gs5b48OeQtZ L09i6ghYy0i0hasGaymdnQNVecB+NVHeJnoZksqflhNZOxrssGVmfl5YZN35 uJjbPPPJt6N+VrvdUeyq0DZPOi0W67ihQsnm841wHmgNgErh68IQsviRTLBI cr8TowefbZ0lt64J8JY4LXGcaRtpS3zAcPjctBStOOWnstR2FQfoaLF7C+W+ RApLcDhX1ApuAvaheK9nnrhWY5MIroSmFkeLECdVeuyvlfFk0NPOyh8ByVRt xjxMd4ZQEHKOf60Mo0KYulky4rkK4N5uMuHOQAcsQ5OY1vzsUW1aw2nmcaOc NllBq3QKtKKD61kW4Kk5xtoODfw0bLP2nqDcXUkj+KKk6xsQISY16gBuTgdG YaO63miIT4qHKvSjYKmmVpbJ3YLSxsXb2CwiWjg9aPiU4qxaR1ok6a9XPw+e nFprg+8boXKg4HrD6ZZuW686/XnS4sSVurCVjaLM/cWMRdeEDeO2OgcYrxGf JS1yQV+BjG45NlW37BrLLGnC1jJpZwb6WRuoakryVXQLqCiE70YIEnMvGBD1 FloSIHMWoqjopRSYmbDolptW1HoXNvTZ7l2dpLruRVQ9cukLBE0YFvrVpmYj p7F/Rg0lwmaIQqgLO8Ja5Y9SF/XfSDoW6q4R/qBGVYTFjsRmK2jnTZmThBC7 lNW6HvJvDOPZZaT8tS6Arc6XQBwAAOtltN4+MOEoNcdV2rI8EfLQzj9LbMXD pzM6GkMBfbMr1gYOatghRLZmIC0uxMnE6nOor2rHVGhsFeSGhxMq+ytu0l4b 7Ajk9uU422Yb2037ZwLIZyh/a8SnXwcYG2/rJQR6Otw6E+V5Qcua7eVZky0k 4SpxoFZHVN8iy6S1xVxwhCalgKvD2hrd1y4nyqQOdpTZm0P52VbNpwBZNgn1 rRvrJ2GasmFr7i9GitHCbZt5jTVoFjJdDsXyktiot1ps+GW2b2TrEtFLSLuV rMdiLEQqvC+FjAC0K3YBSddGj+knYDi9+C33IPBuWqGOksOQ7BPdZsLdLGJE LQIyraet+1gVSNhMDYRovOJ/3qbmq6psrHCKjmrXT6/CZiarzMqbsHA1XAR9 Nezxq/MdUIkEZfpQjAv1HCFF9NKHEesm8PFBmFVl41fTmR+GOZ2T6xZEH7Cy 0stCHMkhY44lRV9aG0tV3IWMR07z5PMho4AnytFKW51QZfRsLtR0q4+sSwDa ABYrGOcgTFJ7WHjgFy572QBLN+K/OwiF3xvBel6YMUKYLdtVahifIcZx00Wp gPp2JSOdHUDTjkZZClNJbdhODs+UB5Zjpxzci4kxE6dbEq4zZClYxnnigmZ7 c8TIkOY6jDp2CbtOFCNeCGdsoN12WTE1QnE1WD8GyfbDopPb0wrPR94RrZjc 1nmdz5rhYuFQ52LPRcXFoItDFoouui6+L38XYRf0xdnF38XhojOINsh2+fTR OLjPhaCL5SHvONQbXv9r2+1+p/Ztfffv7XY7r2vp9rrB/z9T7o8/sP0Z7/zB xavzS9JXU9fx0HOJ89JsA+3kkWTsz7ouPGPr6+DlajzPnjzWvrzcbSWHsc7X bqepPp8zXD90HIyaM9RKx1fEIucQjd7aBGXPIs3pOeTz9z0r0XBoJiLkxDkZ Gfl+NVAFjM5vjnqmKp+0AX+0CFd+dCV8z3x8w9168c/s+RVvpjyesjx79+Nf Gey575ib4cXpq7jNza7oK6pHL7pzPeaGBP7/lseqr4JHjhO8r/AgzveZqNyM jscmM95Vf1/E5+5rtD3kIfJxw+mii0cVv3mY3qXEWG7Nwv9Oc8pP46Q9D63l 64apggR0LGuRSM7GPs45xxwiqlGp99fzwX/+CFn65kpF5+dB6PvCPGwwwVyA MbvAT577UoK/0sV4hwbxB8qhFtUPT36DqsBPx8tBBrY3novY+mQe8Q5n06DU Idh6hB3nMJoMb/7b08fuD7PBRZ3iO77dFlTsOJQcV8XnoM8hViv4EJ+r3Y5n cw4r7iVDOZRx5Xjur0Vf5Fcjj5+gedp9DknC6SLQp86fj0Fwh2mnQbdD3mpE Rn443yPSCJHhY25i1cU3kqjG524QWKHmZ6DmkNC8EUevjfF/F98f99f5H3/5 v3h/foOV+/Tbb/cdINlzCTYEmvk/XqUcbkPuzYG78njz6zcxH8djVOOrkc+A EEnA6BTMVc8qWpeYRzDhy57tbRLcejBkreDBoAudc3uSdlQHHn6KHxk+dxF0 ycfOrjftRd3F7hJAfWxvX0kHxEPQYSeDG/b1iDvUP8uuQbJD4GIg2iHpcZB1 SHNJIZ4eNoERDzZER83GgRJ0WS9WRFO45cSK9BUdMRF3iqE+/FLf7333/3vv 7AvxkxyEoBOPr7BIXzYGAz0qMC+PjgI+lk3RluJkfsgVf6zv9mEW5CI1ABdz XqBLh6dPnq4v5Iuwi7KL50X1Yu4i+5F+WLw4ttFt4s8kvnRRuoi1UWrixYvV Rc1F7aL3EXvYuui+PF2sX+ZGLd/G+DFP/5INYh03qk0ONnxdr6tB9ZDw/NIM 6h0UX+/4v8v+/+W6I8XyfxfA/F/0+BGxnTOFX/ZSxBgkF5RfOFDCjhWw/S6f DfkUeWxxS4it+R2bxi7g0Eh5axYPPoNknz2XRoPc9JF8lD7z4CDYdlF8r4MX quzi+Oh63/sg0naxdT9KL5Zw3z4J/Z1tW+mP5rikFhpq6qHP5zmmrstnWJJ3 j2XPaavMeSk+ecXcxsgf8xxiMMFein3NyRz+VwyPX5s9Hk+QYPwxx6AgYU9h 63c8znxv5r0RG/Ji7f16D8qHnfYJ5+xvYdGIi/ixuvjegjehi6KIBKdZG+H+ Huvq/F7r8P834UHdfwev5O39fu9ks14ZN/6SuI+GXKP3sarya2dP/7GO+sUW KqfHsf5/cov9l9EHBxQXZ+Onz9CL7fs0HeoeZ9qg9wh/l9ug2SH6fUIPBQ6b 99BNQ7X+BBX9UniRsHv0HxP6Iu1Q/WTd++r+AJC38lR5bshIb7P4IkOfn7/u dy/UyX40UZ/XG/yd/1PO9/jd/BLeP/uousvhHYJU7/09WGs6d/Mtw5RGftbv jLiL39GFBoaroTnVy81cqHUCuMSqizWGY62bJfDE0U/KFvZm3lKQueoVvtyL wSgJBm4dg0LL21jXHmCltyj1xbXbJmSaA71LkbVWoi1CcNb4cY82qrq3ACMV 5AF03jhbSq9GsTd4ZFF5TZdXQe0c1flY3CytfPGYlxMrhUQkXUrHnLGhtPhp Ps1tyTQM5nIsZbVlOb5ebqTB0G2CWhZe3eeLY4S9A+U1nZrAwPqerI+xvJDs CXaDIjwZDuV/C9Ibdis1Ki9E8vpdWLakc3X9iNhBO/YLSUhrpzcLlBlVmaHR MBJTaQXpYLgtesTpMXrNXohxc3bGT40WIKRsHcaH+V6eIOivBZ75L5lz8OcC AC9GD/40ktroXtsWrxpy7qbnej9LDn39u25ekKmUoQFiiYzU3GXssDT6vVuL y78rJKwGaU2Obb7DqX0hl03EN/lAnzIgnPbIkX9LuoTUz2uGO02lSl6pixQj QdE4z6jSh3M2PArfU4mWG5tjVjpkY3zH9WWxn+0WagdMg5CBm7ilMspT4hOQ diOai2Wa+4ttkiVg7g0/WRRJ+ElUBVMk32UBnlNt4t5zJYBZSZdDAFTs1SZe expADxQbaBMWsa2eqxvZK8YSIzfrlGE5JciCNZRj7MYkTHX4TSJxpbX42TgQ y2wWhNbtlwFqsDVNBWmL2FxlWEFVMiqGawihpWrtXXsM+WqsDX1ieBFwGuSz dYJ5kS2xtjSTAY+ib9hZBOFQmz1cn2SbOa2iyYNo1cGEdBQeFtwzGLWYvmUl u4LALqlQz1VeivhgQlZaE8YxJlpKQSJKLLGOZsRa+hvV7yke2s041S5R9FXQ 7SkD2yddy0kpjQ8JtPsBsiZpDSZlb8txeXrumO0lTsDJgSTVxDGsnljpLnQr OJslIchN+GxblrBCC3s5CUShMaghOfU0AIEycm4wa9e4vHIhcEoItx12R9ng 0ISeFFjAyH1yxBKcm08WIGI4XJFLUFx/g080SPWPk1UIYNw3CJgmkF2hugJn B3hsASZRuCVhLF8Upg2NNlLwYvB2zRZNZjaxLMdRGJCp45XDh8RneXklmMNm hcGzKqZPUtErIjDs26GHNkfFJFrOBCI6zHZ8Q05x6BTpTp2IxPbvK7pDBrVQ SeFMliWDNFCqhjjmEBLRZ4zbCTkekMgjBaMicuVBAhstN3PZg85tOBUIfTS4 qmbXrFCcmVjAuWeGwC7zrD1NSy3HGjKqEt2IxEZVJUW2Lw0yhH0ELlBiNy/X u/diEgZv1737nGrhm7lJTcJGlMSatILTkEwrMfNSQOMzc03PAco1wVzl0Uo/ jciGRpJT0gdJNIDhtozJFzm47qUM6WMMJw8Ce9dq6YbrPbHAmC2qtOq9QYhm dhS7unwcnovvSOLNB544/xpNCSICTaQHRHdejN3CN45zfubJGsBg9W80tUgZ MqkcMmmtfQrcg6nV5atPbpDkkNyJOJLzML5sHUagIfHTnCPhzaZbfQnaSd9C 7MY88EXk6tYfE6ai2jc5uTt07ZT5quhbLxOOJj03CmFvCSEs3HSAAsiSYCFC izC1bJ9KrO+xUZ9cixIEKea8PBubHGAaP7MV7KOsm7QbJwDMcLjIcanN3GAb Yvk1ss05VSSCi50gnOSp4AGwGKyIAQq9qING+/jxb5BNuF3XHfZMjdKQjzVE 460ZzCfRVW3wOu4ZEwZT412oui0cpppzanhsaRDN0xJdQW9ScchfqA7EcESK yt2obspIUlzzgvObo3ObJbFYrAZVUl+AUJUrVu5xITqBstKeRm6/IHGORV8B FPtFkgMz1Ljy7iktGGoSG0jWSF0pLMyQ5+ZUK3JSfpaQD6bJhk8Nu2e/Flry yZSXVOqgeeiDJf8Cj+u1wpMZwElFsQkq2uWdvXNCFasRJqjGhfOfLGbdFwic Cd0yigP3WtlOHhEQmx+6NXJ1uq4d6WMdUlxRMhNDLh7kP3smyYgmOCUvfxjj TDoLJmai2q6ZYpcqRTapSl1cGJEhmjQQWx6xNCIRPN6gTM18xkG4FJ14239p 8ou6jyzSsKPnULEg7g9VN6FSRzjPEGrSq9AiApXp0lXFZGq4QmkSGIZAw4fe ySmko8YjSWEyrePVNSqlNGCTxboocjgGSXoW4T2V5Q5dttOxcmAAv4Vqi2PJ lRzOf3GlzkGpkXUJ65ilwomCcaFcGkTmSm0vxkxxbHlpSOVq3NWWpaNVnhFJ lh8x6hgjxQt2cSpbDFaSq2ryo4RZMC6cZOkUIpXzd5pORYyAcalbzSpC5NVp S3oCHLC3nUNQ0kgI5+/wHm5mrN2wrRUFKvEflciYShV5l0gISnB1EHOhsyvl IOhSIXplJUOUT+vUJ+vdPtINgr4XoKiWkwf0Je/NkjX1EguKYQS0jWCuCm16 P00tsDSFeNIH4TCHoIbVtRcraF61SajajvRO/JCiPLLfF4ODgIlVb6yt9PXI lnjysdah/CgqKHQo4AvE0LDSIhnCsSCswSz9HZdqznkSs2LSmCWAbc9ygYir o3ZGJubN3CE7EMp8LTgZJ0EHQkJnU7+A7z6NGWeIF5A88Ip0jTC6KHj0fnTJ DnqCPOCnMiFEcGH8Q5zhQZPQzLEmRTqyL0HG5f00LzqqZuG8tBGrbeN4Lzmb m2YbXmuldK9aVbTDL6pZqGsLgTpV5yzXlEKc8nnCI6Wkv09NBkUB4LAelN6P IekNIzf0dweWf5abIcpZUsf1V5p9TZlkdJzrFpKTRswvWJr1ArS4qchZALbD KzWJSIKh+etqcFGFmxt2MeXZUyXYA6U2xcUga8c2m7NACwr6mOebmimAs/pk 3mAgHMCjoygpCuZt87EhvmxLAUsWLxhMDqTnUJUI1QiheMTnObTzlpHlyJC3 L1WrNvjDwnaayKIGTEjxn4M+LYGJmKOpjGh5aF4L3rQr7JYtAVLaKUHWR29Q KpFMIsC2Qr64ZrQ2S0YZF569YPtkUXj4YtylQDt/qLZg2jTKRHBNaeLVQO9Q tIEOUBbsUqmQ60l8ZKmNC5McBU16cRsP4GYrQ6fO2dY8y1zCcYAxKHLyFrki cigFgoVewQj3kSomqGLU3r44R1BZ+sM+tGTKGAiZunLKczofvKjmk4Hiku+w CxQuGIUWRhby0HtUnY7FR6bNhxSquhpITkW2jWRnaO7ICPnGMh8bLzDHP5Fb HvGJ0p1UNUXrOpVwjofSZXkDUchQOk+vrFEAq9Lx6oYxPXEFvBPHb2G5Zp9v eyj49k0dyyV9G6jbZX5D97od3/tlAu9B1uXtDZEuGxPqGlDpjBdbI+2Ffp9C PYpRLewSiatIFSzVANpdNZRbJrNjBb7RXXSJTvSuvdOtZNxUHMRe3bXMZhYK nY6rlWgx8xcOLFbcp82xEjYT17Wwf8k5FOEkKMWDXQY0GICUVludMm+3oF9S n29KnzzsaHw+ySGs6DBg51P62qfp9rBZp5VdBnsscdn17TO7QWKINw22DJC4 0Wuu6dcJLu/IarvA9Ds5vXL1qt+xC6qbXVE2aGPUNXn0yRimJEa73Z0lRk6Y MmmjYwMl9EtGWlWjrci51qWQ1PGU7uESYUSHuWSHntU3e59NwumT+S2wxNLA 1W5as8vZft45oXwoy1b0eD6ZSOYmTV1EubGXMHESBz29JD6XUt1DXqJLyc5S JpBo4V28W3inaI+f+ZB0VrLFd55cti14RXhFIu55tZwN2Cgq6ROB7kk/726J b2326ikNiiuTPklYGZ6QU9y6sE92/aJyz3PxufgcmMKsly6ZlYkzcBU4TMWN eh4c2P+1xaJjSGpTQNsZMuPxQOTgq+e+bM+K7lWa3RIQF2S2mK4EdXr1UDRw u40iWMZinSTuG06WgnISA1qTMiMBtnA/nuMgkidLyIOKPJRSJmhZN7YIOIbT +X7KhpFasiLgSlxkqakgI9NaEOkSU8zVdcu/6ROtx/U2HRxlG6jjOyGqmNob 9dju375KTAjYiceMiRFbzbqR+r1Z66Do0++1T0vOb/Vi7zM+op8vTt8SSfQE JxSB137rh/pd3eoq1YS/Ez8pmzAlEZPJnBcTirRSCQecg1EVI89JvqWZvDG2 NROxtbYk0siJWiYVgpSjSrHMmZOOhJSjF3+v4CsJz0HTsFZ0agZ59DLhTlPK z9Zi5q6RJW37cZSa4AGx5Ggo0EIk7S2/AlNNMS7SkaVrYTm7ZVOtLL6qIKmZ +xpekuSNB/daXoXo9lDEj4coq+Oh4uSpZpM65dVbClaUydDlB4jGpuvH4cBG gtJ0afo9Mbw0MhLH0zsEAyPRKRKZEhvah1EtG0LSAl4LZQ2jWQ1e7Q8cLKl/ w9D6DeaIyC3vhavE7mdgBxmQErbY6Y1vmDZebZwXVHxW6iM3ljMIXQS3U892 BHLqQ3YJDWKLCoq/PKwS6fcxinmbT0pmJhfWrWQ6UtYyBRjlIxhNsHLlXY2u WqrOrUa14ZjOVckZqAUlHwWAxUrmOLLImFiSlyossUpzPlnmjoGJDLm0ZtWC 3WDBlzll2XjdzWiRQOixvXdzDLSiiXulJEDS07tpDHay1tDHZQSkpMX9Z5Oh 5U7XMlIwmPms3eUw+2sol6OHmrgtnBrSRblRJEATa0W2kxgMJYj5dXWZ4/YZ H6cnrbMd2BFKiDlSDFU3kZE+1aSgPGiik0qYxQKO0cIsSYyanHYFYasYrZpE bLZwS+hDXd2ezWFzyJcKanOK1iaipTNG4JTL04/p55z6AYoJyBxAFs7vRGLV M0xWbnXK2nE0yWUlRXIkGkZlJFLLqnV5Khyzo2dFbqqq5/paSIvJO9hh14bQ 7LzKm3pU4IybYA48tANW1OClZCNAmNd9FW3PQWxUmrizzq/CEi8Rrxs4Sb/L wVluS20lZa1GbkZtlPlRt5jv7wkOKZTWfL0gl6rE1uitKJp0iZv4nd21O1jr 3dbcuu/0BZObZPN0ZLaxGyATSOSqPS6vU5HIh1QjBI2FtAkNcM0h7XVw9VpE EP5JxtvLr8d/9qZcuDDTd3O2+r4FGJAEAvbr0FRbWZ3LSdKtGFOjhwfHwSPX 18FmwbGS+4v1tF8dV6nti8QpzDgsi6IwiafY0p8nE6DCyhen3HQrCI1ZBpSM LtiyPwmG4JJog4it43FK3Nt70yEKHyEOEz/WsHDS7z0S54s6G+fLyQieejKb ZQOOGBWwdy9SY9K9Ck2Pty9CoFuie2/hE1VSNvxZuCRtytubrMzrZfUVVMmU ydJjESbjSVxCIukbxRaT26LF0woBxr+s5VTcmjDezNZRuLYxtRtnVWGcVr3Z ZtyTCeM8RTirbyVrIvLnZWUNiozKLeM44YZabYhme4TbIFfCx2F578NtHLaP WrT5hanbfR+OoDCd1cx3e5Bdjo13IOigsmuAFUgAFdm3dLvX4bVfZuvOQ8lL WeM4IL4kAeDVWsdhKFrPJFcK55dyu3OilKQAlzm0FxbN2Vvo1aOajCztHWKd 82+S7sLXuqauJNYmLZBAbpiQ8heAQIpqo0wJKnOkTmYG+y1gv9Ybnl0SidNI MhAJer2qgOrXSUoLqFw+gILsws+tTE6iHtr1mnac3XhEybHfvqk0LVNM4u01 a0Y6qNUsmygcGGPrYnujL6LZuDZ1jB59B50j5zm8PqtN0JTCtdKQfyA1OHUz M9HO/S6joT5Qs3sGxytx8GgJ1k6Pgp7Qn1Nr21O1MRJm7zDb4vL0ocyrslM+ V+PdJZwwV6AbLsCeZEQFhag8H4NuemC+1yzgxEi/dHNuGDnpWcZRtcKrrmsu uXDg3Ibm7VOvepTGmqzQJuCHk0Td8rmkyZQ6Qn4Ux43l/a9u8jSyB3CAWG7M BS3SkwuGLPBTm+cby5W9cRWrwVjVVturhOPmDrpxOQafdzcmyc1j+XK2iwZ6 flNDBTAUWhCWMKXt6/qmr7lJrJt12TvzrDkBSNRyMgDLHfhFFasOOrLuYTre 5escA8KxxwbdFgCMuqlSnIuuDWI7jpeO774pyLoHKEegRhTAjagQckN+HR4W TM8FUEzLyVXbKef1BPidyBZujJCBkyrQ0RJbw91UEtsU83DpjFNlNxphZTj0 TkrRDjr+k5obm5Ilh5LqvCnhMFh2a2eraQOpcBKDsnjA2SlcNuykKQ1BnVJA Mqeji0Jl9K7N2aMo+QoW2tnVe8zbBD0M5LVOHturpG3IC24o5A85dqLxnLzj H04bdIlfPERtVM5bb3A6aU24RRW03UPanyJbDtJzFML2/GD/mjoFUaHDq+MY AKn46CtkMGe0HrqshIJ2+b0qPjqgsuVA5B+DqqSW9xbuQX40DgHE5AB6Ue74 pNe3br/okS4nWzu5jtKvfdeGuQ0d9J3mZlmvzaZlNbCgamQu5c5TZowSTNt0 Bc4h96mDfm03N0DihSVZslM7XIZv228hspVjTryXb3TdOoyezLJ3dzGLo1NW JTc+F1KGKfu3YnbY5oA+djUclJwWzGD8AYBMfiXxeltoE0iW4J1X7XHap+Uy JpsqE7fnmTo7TJDYPM3c4NgHw2kbUD1rD9nSeAoQ/XlrbErNrrjduW3H6Exo 6FCSb04xnV76qbomE7mUf5z+BDkNXTn2aiBxx0xLeIUIPSkHUNypB0FcyFnZ ZdU2k5+gqOLkTaL+Om8oOPb3wkNJUc/k6jSPXs6WSA5thc+pI3zrzBlO3yMp PuQnbnLMBCe+4KT1eZPNN5ifMhQGsgZVJN3Gh4QBvG7JhX7h6I69spFpghVO VnOImpyZUD0jpjRJs3EnOnm0gyDSXV4JkOsvTCxsmHDLUtqAu6uiZIcTBwvS cy2+dGDp184V8W9fxQs3eMMZFZcACjSjeuCRNXpfuyCVBJKZIOBYJaqBxukM gUBT3evSNDnkUZjvwdk1KJI7YrpSA6F4TU358Qs39ncS7xJHMQlyY2P/ImwB rTvCM5qa+HK6Xopn5yJZyty6nttpFOAbDGILpenFAGMqnKdL41VbhuHQGPUc frq8iYTpJzrkIYwE2r251eQyhinpERyrPwkQE+TovKrAmsp2VtrEPvpE5unQ YNFN400zHH68dDUp20YCqQyZpz9KPnXTjwrVdw2WUw9KItP1CHqAvrlqF1c6 jTk0aPa0l4WploXRk0MpTnpEL5XaKLIiFXm/+xClT0GUZVCllmi7Zo6OdR7M Uh1ahS06xK7kEy6Lia726BkTMXS3ciEa9t3ZYYy6xw4/cmm/T3e0y6qmDVTu n6Irc4+4TDgmKbpk7Im/fLmXGkxDJRVjRHn2LPy/P47SPv6YUYDdWTOMckvM ApkiRHjE/MQNMnGFqztGZjrldgpuUTTFuqYA6ewWr0AcLqqUlnVhOvvocNJs q/WHpYpZ2rLqo4Z5R3R1KQzCzDyyuC7O4uriYm2qmqIUYvMnd+Awl1ZLKVLw lagbTeEf1pZYdKt83EyCGmOiJ1yUJgUqXyS7N123WaizZaN6ZdBqyFMKQtvc rtowyREs+qZfkqkaFF+WF5nYnTL2wOWqR5kJTOb2LclKs47JB6cIaPjJXflk XmguljdjWkQoXdJXPP9mCh54/FAqx08IerlVA1eV2UV1rXCG5zmhLls7PAqY Ic88FUG7jfsN9qHMYuc42Qa5vWici+yTDRNX1vFy3d8sgVxkYFv049FKUKLn bFSUZQzO2b4fvdHrPQsmkC7pS6uYOH75bfR4VSYoTPL1Uq0869LURGYcTtDv 4byTCA2qMiKHVLm40HIIk2aPAcjSu7bEOy8FLhn6yU0Jti11IslXt1sJpO6M 2HTJzLD5oeMdsPj6RMTiFnRNIwkQ2ufA1kg+mMdGqqdj3bRVehKqt9cRWhJl bpLE3VIbjXnLqtsUCYLHVFFbKd4fJRgFfrEvodHe2RXr1Ln+ORQfSqRzKOyl puGdgrpErfFQZEUIftVBKQVZjOx7EzsZeVAHNnLI/3/z2HwJQ/oIAAIiOl4D NIMB2E6QXhLs26fUgrayidAuucLZIpicfu4AArYW3querUIayzyGn5fhOLVQ St6pELtSIXZrOsEvCEBPa5VLxhThbNsate2u+vUGmoO99b9+EBBu81Q7EStu 9keTzaOcvra1F9hRT9w2W4U+KQXiuyyOCuVR5kuIqeUx9ZVpfAzZZCdgH2BO egyxuHdyWGB8/sbvqa5R+jhQphjjl+zlEJSIT7q9hCNLQEOFZUOsYUOV3HTo ysJd5ZT7l5n1JmKQ3ErJO6qk5vOyJ3RNP5MT6GiSWtLoyskuobY2kcPmwGkX Qx6Iqlv+e7MUr++so4gRt2iOIUzUyxMTTFzblGiD0cGGSdamvsusmpeY+6V3 6wHYl/LotlKtOgRkmguKWknkIhwriZoJNlVkw3a4MpkGy3ex0cOtWQ1DSiCE HXIy5Z21ILtrRVUIQmB0iXeRQNW6kOt8LZmVD7zO3H5qlEzu769NEKkZfyle elR3mSSFatmMlJ+J37UFyXsN2f6dWXmr95k6BsU2Tebqm8AlakmG7PbLvwBa qgsMOFZOuvayb2C3DjYJqyth4JhEbDP2oBnw611jPriT2ZQWLcbtHUqGXp6i g03bg6ODoYOeB86emg6aDpU/rzkGxNCiqTNNzlsO3PK5UiZzzzP7cgb0mGYq LQF/a93UgKCg1qJ2UdzQTNEhknjF5Up9BW1LA5Jx8NVgGOoP2waFUmwnNKi5 D7QDhXjQyFoZxsggRzrYXVRcGUhWr1ks1UatI9hnYpigY5xZuS9U6/qq5fPW efDB9bbKRr+aNDAMHZOkczcI6R2chnsEQbtlyzuT0Z7fYLOIaNIBOCalMN3Z LkQM0Ta+ZL7RanC1FCKoBxwwx+WtwGmp+sVy14xTc2ctnfSVUlKS8/2AAoGV ccMiv1Mx1rplrkSFih3DqahwrEsQ3dfMATZ3aAaiCeaubqkm2qF6sYpq6N08 kiZ4ZpeM0maVlvwvrehSatqthu5lxts2L6g4DH1iIq81mVlCR0UmpLOB8z5U NzMj7oRoXBaKxaNKXHyztrOkd/Kn13Rj7qv2EYMZXcwxBtN64I+1uirU+3qa taniDtns3czKqNd0cyhjf8biCUECiqcMejjcCp5iRr1mixZ31iUy/KLu0Ul6 r7CIgAegAjWMA7URJX7EgS0jOWx7l4bjS88PiOC5tqxHYsoNtvG7usWyk7l4 4uqSj5YlylWiJNL+m2UP5xs/sLL/fB5ugnGluybaqZu9FJRCk3Wvm81ZI51C +D5ZW8y0NJdvWGha5/ARj5Lk1wxdgkg3CprpRqY2hlf1abAU9w6PNqcJ1Z+c 7OONyHWTQdE24oGvGlvmyPnTbI1Uz6KUN/Ka/RT95apTl1Fmy/1YgHaREeOp dgFJ6AXeGbvLBW8y/oJ8+RF8X4qDs0Or7NW+8+ejfiDvvbeIjM9Ueq+ZBB7v /sg94h6+LQ9qrfgenjdRFqovH/28fvNy/Z+T3nwP4fge0+B3kXP8xhQZV4kS BWr0W29vkSZEJ8IiUZ2Mp9dcikvvLnhkW9jVuHJ3nDWt5mftrfAmkla5zY2/ vQSsirDfZngutfp88z81B06H3EXvIuti1/z0HPIdhF0sXtovBig+gghQ8PFn Yusi+JF8eLtYvoRcz9JPGjfdxYP04IMaLv9mg8JD5EW3izH1UGgQ6SLpYvbR dVF4nffa2fy/gSfx73cvfVD5ffdL32z554T/VoR6qb8naZFzTZbvhwGNRoxp e87LAvfuZckXey3vjLTdT9IbiAHnTdsg1/2oz6H+EXfp8/CT0vxI34sXyovC i8SLQ9z+1pJzx8ZFnZRe+q3s/5osqaiSj6sNNXrkGu5zdtckuoM02Qc8s+WR JqoJN+e1sEdCRIPfo/2skHdlMk/uGDDbuE+fxxeFF5kWe/8INIh00U2LVxay LmovF+/9T7/9XW9J6jrZ+kDCv3PQ/nQh+crkHV1SG8355Ox1vCQjy/aJ/WX6 atb/30OT4uw4VCH5j1dTJ6Oqc+P2pIWvJv1sy+pQhLhEcU1LmwvTzqfPWfWQ dah97F86L7cX3Yu7i72Lvou/i2sW2i3EUH10EKH2KSG+ljfI8D7uz+V/T7v+ n5Xstn6zE9Zs/u+BgwZV4lyh1mg7P2P1UOw9V3UEzX8QFfFX/AIlQhdDV+DB bV+6LD2PyU4bZjM1x+GsHFFr/6fMrLI2kHpM+r75ThF1I8e1des6zxB4cGir X28hvnAte8oqnLJeeWb5aFY5i4JuPGd6XthL79ynz18XZxfJi2sXlRcX9lBo EOc7dBpEPWRdbF3cXeRQ/3oMwh00Wni6eLqYu1i+dF3kXexaFJleijaUWri1 kQGacvG2MbZxvRRdJFsoviRfFiA0Twfw/b2fyNy9hUPwl6n/P4et6cv0gyx4 yyFNZPfaI/1tu/ZXr06JvDpjpl2Q9mVSM1l8GrZ6+dXJbZhPWoALvrJ897F4 MXXvH8gZPvdVHwYtpFAk/yGNzEWaizkWei0EWhi0UVnFpop8V5FQi5eLyv80 H6Pv9x9TuPmdx78P9++hT6/Mjdj3Hp+4grfiWTVa1FzWsleHtoUZbZmHtWlc 4OP+J/jm2ON+pXc1STAf7QkXXl3Iog46VuyF1venD/fcH9h/44Hy0jxpEvbi I91cP7kyuKj/PpQr+v0WEvJd/9ZAn6fI4fmuIl68y78abI6zikS4Uav8fPHO +7RRaOKrWxpDcKU/UACg4IL6c0nz9j8CDWd5Fy6Hp4tZ3qDlvxxf5+FFw+2i 5vbxdkh8OLTecg6/cRfbTQudrkHD8NGfiQ/ji2sXkmtB32foRYeVZnkx/y// qOjV63zwY8f7D8cRGZrTwZvWVzBv84NlmHEHBqyZmZM9pU/8l+RngLJ1n3xv 3zKHoE+dhF1MWD3oiD5T8SfvqOs/9IOWQ4yRF8vG9DF0kX3fCESfleGgzCb7 ztvEQbeo9X4qaIk4r4XkRnxKj4O1QcP/xFPQ9PFmPKQeN+bufn9z+b4Yf7+P 4bfX96o+vqMG/fiWzeuEx9fwUHK5KR89dVKymMc49ZFVoknj3Hdk9fHAKd7f 0vnfhUNahn/ShcHRJ85rbDjnzO3HHTsCx28EsebFCGPfXIQx8tUPbp8/aiAg P8sbpklz9QjfUxfMi+tFzVdXKIR6mN6uLccEgz2Yi1nBxa9D9DNoO3Q91wqD u0Oa4YSJuujevi7uLw+97n6PcoC/3xI33ve9TG7r6CNH4Y44Cuxcot9Yjb0l UokmTi95eF1aSknJj0n1mVSv5yyLWWrzNo5gcJqO7ItzwEPkEW9tfy7XwIPR 94R/kzA3yBLr1/BIyy4pYE6CK267YV2l7Xq7Wx7X7VGy7X42Ys+15aw4/rui h0yfPIJXD3Gdr29foI3heuQQej7wj67pnE59WXtoK7YV07vOC3VYflsePT7d 03nqM3WE4nGJMcg1XeWG8SPPtNCdSnxmpVN72Ubq4Fr89cO5VHhWG1rv4tNQ gynxxEEPjcon1zsGa8bMxVwJ/k9HbwZvxvPOM91XfB+D8OD69dnEp9MhNX3m U/TZ+OiP57DSZL7+w3sqVWed89qE/7eD8aEaffVfsGrK9HY1yHL11ZeZOMfp MmTV7t/KBP1+ZjjERumOkvLF9Hpnli/Ehdk/yVcv9U8d1/j4fUeX/b93ife9 XB8mDE/szYWTxirr5UMqjw/ozwHudNQ7+bZP/fjD+pIS7/XntoTx/PHdsEbe Rw6fWur7D0Bo3dVh7ziQqfPPXdPnp551CvT8IVfS81hlTzYIlYIw5YzQf/85 IFgjsa9HtYUa/X2FcysI+Fghg9H3iKKKKKKKJH0meg4lKREEw3EAjuyaUozB 8fIr0+vCx14Nv8LsJbliv5tt0CdTfm5/W62uh5xPrsdbxsPtI3pooJHjem0c HyMj4YUpf8zns+f+MOlNpdrQbGurW6XFbr7mKpHqYPYYPk5Hz4PUmoPEGq8p 7ks7cajy9FBxnlNyB/6Ef04JemX30B83G2qcteNrkdsn1gZT2aGYIRNvpUQI ByB8T4PT838SDx4J6gTUrj4micUMmysEG8JiQ3pcrhA18/CwF2NBzXN72avr sY3PcM8GCpFQJ37LqQ/nM+849o4eEMrz5UhP85fegvBp96vCH87gl/NQ/ZpN b+Gbu4ZPnXxYsXJxcvF0kXi5xB7riYvgobHjUHqNDF1KGhxyD7CGx5BBpkM2 L/vF/dF7vToOvQ3HIpr2N8WLaRfC1CDjMl2SQnvuqj923QYFxF6dDyWAn542 lgoOxwovrobbXIP3kOp5NB7HHi+Qh0/LIPfcvFrPTxeqQ7PmEH/hD9aL7MXg Rfji8uLzIvOi3EWZ9Sm1I3josXmUH/VD7+Lsw/f1iD+fnYz8HPxe02Kpox/2 xv+0W4i+j0iDlfZxaPpYvJ9vF6tISesjdhFyfUV0xYY10dB8dVXK+vOIsX9u yruxTacC+e6pXH9WnRqFi5y6+LquBPrrfTf2QR3R/nEe4/Po7OvR9TYowcKj F6Ob9x+H/cgiGxg7GO9wEM7KB81NCu4DwUrdg9hU5wM9kd/lMmcf8/qUZYEe x6RGXm+BOXsI9KusavSY+54FtyPN06NAPHo+SIo7HHRvr0W/k4OpKWRsxlfH EdMmdSquXXwIwZMs4jLHhq/TbKOUMeWGZU8+jBYoyuXRr6mWp8zYowSRSRse /MZOWp5+JHc2PAZOmZgRkzNYxbzMFTLnOA8FM1wJYMuol/KydCYjq/t3po/K 8mjG6qAx36zy4I8GZglPHjFx9zCuy8aewiiewCyZ8M9Z0ioAcS/HkvSFLwjS 7JEuiZLcpS2K+7FqTUYFf0zAnsv/GGh1yuybsH8I/03mmfiX8UCnJz/Gh64X vfH8o9mTk9jUUz9TS+VNCLlOCl0hZBGtQ//kX8kX/Vv9OuU435vKIP9E+f0R J7Gw9BG+3i7X0ybJjc743efl8X8Xie+/0/Pu7uK6uV/89O2n93ifZ2n4dp9L aeR5P/r9OJ5ffbT+Lx/F8j/Dx9ntPW+Pxnka/b8R5Xi7Xydt2f6frePr9t7/ x+28raeP9Hbdx+n1v/Fv5XGeN6vbbfyfqeb03j/FyP7fH+Rkdr+nceXuNt7f I+fkeH5fh+b4WR97xur8PjfKtvM7HbW22+b3PKeZ5v6fO3GRuO38rotvm/K7 /y/aeZyG19f5P9e07Tyfk+T+Paf57X5flfW2mj8zw+cg/Wfjg4Ef5OBHFPnF +HBHi0O11308jwua/JtPFnfg+x+TzvL871xfR8tbJPj/Wx733XyPufxp/+R5 sG4T8HmCyV+24fhXw5MeUr992PP3y1e/zsgeyz+5GQrgj+fLWycj+o/sHACg 7zIerGULUje1/pT+fNjkngK+WCt/1Fffo+8I08jI/1g+6n0/3SGEEsFPiVxE Dxn4I/jPywI7PRbTXfT21puOpyOq2+Z83vvx/J83kPI2PIe5yMjy+E6rwvvb Hsv9/FyPN9b5ux8ncf6/1+R93y+J8v7vmdt5fYeX4nmfB2/2PO0Xm8PtvUeb +nuf8PN7vOe48n9/b/a2+v8zrPM1uR3O26zzur/i/8+d8fzOayP5dvg8tmdv 23nV1z8zprbb/A87+//j/Dw/9/E+n/xvR/jbbZbfkPPHb+82/s/M/B5u1831 fnnkYu36Tb/46zI/o/N0G+A+jttV5v49x6zzON2+n8363neLzkH6/8SCf9Ti vFg72d5rhx93N72Cp9sBG8ARfMc8giR9T+VfoknfAJPnID5/OMS/nnETfgk7 +JO+bhXzq+XcDRwfQHD87cDQN6bty57JmJR+FT5V8e4Hp+gyHP9+3yd/2nMI NrzAqcfBwQp875WvqNglBb7CDYxV0H08/sPUeV9TnedyOIf/woo5T+pf+4jQ J8+77qv4n3fYbjP/a4LeH3azHNJ9/NxJfA/4+v3meVT56PUJo8/S8ZVHvqoE YdlwSK7tRu6I92YQ5hE+jgR+HSZlFahG1CPdwaHg0T+RlFS4ObjrkkbkkfTz nDorUI2oR9PwM4itQjahH0+14pFahG1CPp9VxaK1CNqEfT5TjUVqEbUI8oDP +OxX9Z39XF+4+u6fj672TO139V1enM37goBzJczG/mD5S9/I9BvXkwUwl/IJ YJ/e56H88hcX1a4vOm5Bq3fuWVsedgWO8B1Nemr9+FXN9cyH7ppPv69Xx16G vRtX17v1+/Q5GDwydE/Xj8xArz4HC4tcGc/wfuHhfrXrgkfK8jBKCDoaCmEx zY1OD14VFOLi6qL37Qnvec9PB0UHsk+ejg9vB0SvlPlOND+g6fsjIf/cOJh8 X11d9xNj7mLDgoeCr7CH+HqYAz/eqXQyo8wcuoj3n4PaJ+7GT6+3GW0mxCWa m5JyaGm888Fuiu4PMV/BLNxOoKqsD00HUJ5POhF26oW+nV1ubzENeHiPHRg6 VPXc4rk09YiLDiOD31thHJ12Dv6kUpqq3eV9cmnz6YZaUJjJj01RumdWm37h VQbFFtSnqAlqBzyubzgVGIKwptDeYsKjVOspIck9kmN4E890yai9mErmdyYE 5VA4Ow4TfdcFvSKtbAV77VVtBUCw5jL3MKDOB7xHz5gJVx+vg54vX0O9yWac J/9nmes0EHjJdzuwV077VDofteInzUiwgTol4g23E1DougDFeb5WI8WGc76R 8vfF0+/471Lxj9fvo+8I9P42Y6KH6EG5fde6m3AXnnjQcWfGodT04+cn9TRn 7XW//PiQunmYKz41sctT42RxCSX7TpevyQqLf3+Cq+QLH3IyM6zpbFmE8rQq L9ZXxnBUj9JT7UTvwI/0CSJ4gf8BwfA/6f1eR5ePsM52nvvQF9LyPz/9JiHm a6CDiS+/ritjsFdduT4pGP92uShgr9Uum7giv67sifgyZuEJUv/Olnbxmqjo C1v/6auCGz4gmJ9eHioRcRFq4gsHFjeKVBECuuAGtIVQ2NiP7qtGOgVTq/Yb Fvz1LoVdjdH0ux5zoZPJDobeDJnnkPJ+w9d0vR+06PoOmseY3keesbaZazIF GYc9t8YLbyZcL7bw878L7NdF0nS3egQ2BdTYFjZYQDjcxpd+j7xFFFFFFFFF FFFEj+Kq5/1fUj8Hc/g7K147Ofzf0Ruq8v5mri4J747iuHPj4Us2zYQDnqdI SgD1UXWQCoN9cC7ySgzm0OyJRL7OAc+ntYBWv/+nAKgD9gqZ96B3P0jjW9Hs efTBb92BKxoet8imp6dE6OazSujT4qY9JnBrwlB7hc4PT7pCUV77nwPz/j8D xfC/NAvPe+VXtz2bEvjnlV2CXvryrv1vKa7V+t1uLrsbE9MyvqKHnq9MPLDQ 9EkD1gQNrpYevBIdKSqbv5NRuAuZXGo28/65XrwtU6PPIuy01+ZNMuILzJlw keHRQQcBzZ4k9JfQdHkyzEeHQI9EQbq/Q2CPc6aDjnKZK373+hC/o+Ho+8RR RRRRRRRf/HYAgEUgMAAiAIokXshHyH8/sMmfwecyI+fzeTjn9TCi7aCP5Cuy HfWs/X+6OWvfoqr7zkinoPP90buE+tTb0S+OWBnNdMhwkS6VKixU9Li0rDq6 IpTJ4QViT7ER/4DxznndbhpYwf95M5+I3Vh2kk4Gb/85qCvrj2NBk6PXtZ7t tBy6lKZPYk3J6XDp66uJVEj1uyQ7fkUT5iNS0ddWn19dURV3emgy740Keury VGY9apFrp8me8v6ZXVbFSpe6iDXJ63oFVSHwpaUQKsdX8ajgAPu1Rv4KRb7f upp9RhMbHBHo/TN11cLVZ6SDHSIL2MG/vjOg172/dvVI9jAjuOAeuj2riJ7j 8+jytcm/thmhFC+W5oEPb7Tw/J8T83i+RYuNH+gaa3J+mD9tX0frlYT8H72q fZ7XY8/0XTWs+Da3fzvZwej7wj57/+TEPXsAQAcA --= Multipart Boundary 1214020155-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 16 08:47: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 IAA04762 for ; Mon, 16 Dec 2002 08:47:29 -0500 (EST) 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 gBGDnjb00258 for ; Mon, 16 Dec 2002 08:49:46 -0500 (EST) Received: from lyris.nortelnetworks.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 gBGDngZ10901 for ; Mon, 16 Dec 2002 08:49:43 -0500 (EST) From: Shiv From: Shiv_Santosh_GURUNATHAN/BE/ALCATEL@ALCATEL Message-ID: <3DFDD721.D61C9731@alcatel.be> Date: Mon, 16 Dec 2002 13:37:37 +0000 Reply-To: shiv_santosh.gurunathan@alcatel.be Organization: alcatel X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ppvpn@nortelnetworks.com Subject: Question Regarding draft-rosen-vpns-ospf-bgp-mpls-05.txt X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 12/16/2002 14:48:34, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 12/16/2002 14:48:36, Serialize complete at 12/16/2002 14:48:36 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: mail.alcatel.be X-SMTP-MAIL-FROM: Shiv_Santosh.GURUNATHAN@alcatel.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: alc250.alcatel.be [195.207.101.250] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi, I have a doubt regarding draft-rosen-vpns-ospf-bgp-mpls-05.txt. Please Consider the following topology. / CE1---------------PE1--------------PE2---------CE3-----Site 2 Site1 I I \ I I CE2---------------- Site 1 and Site2 both belong to the same set of VPNs. Site 1 has two CEs namely CE1 and CE2. Both the CEs are connected to PE1.Site 1 and Site 2 both are running OSPF and belong to different areas but same domain.OSPF is enabled on link CE1-PE1 and PE2-CE3. Note: OSPF is not enabled in link CE2-PE1.Interface CE1-PE1 and CE2-PE1 are both mapped to the same VRF say VRF1. In VRF1 redistribution of ospf routes into bgp is enabled. Suppose Site 1 network say 10/8 is advertised to both CE1 and CE2. CE1 propagates OSPF route 10/8 to PE1 with next-hop CE1. In PE1 a static route is configured in VRF1 for 10/8 with next-hop as CE2.So VRF A will have two routes to reach 10/8 namely 1)ROUTE_1 :Destination - 10/8, Next-hop = CE1, Source Protocol - ospf 2)ROUTE_2: Destination - 10/8, Next-hop = CE2, Source Protocol - static In VRF1, ROUTE_2 is the best route. I have the following questions: 1) Which route ROUTE_1 or ROUTE_2 should be given to PE2. ROUTE_1 , ROUTE_2 or both.To be more precise, when ROUTE_1 and ROUTE_2 are sent to PE2, their NEXT_HOP will be set to PE1(BGP Next-Hop). The main difference between ROUTE_1 and ROUTE_2 will be "OSPF Route Type Extended Communities Attribute". It would be interesting to observe the following points. If we assume that PE1-PE2 link is not present(i.e. PE1 and PE2 will together constitute a router say PE).Site 1 and Site 2 constitiute a single domain inter-AS OSPF network. : 1) Then ROUTE_1 will be propgated as type-3 LSA. 2)If redistribution from static to ospf is enabled. ROUTE_2 will be sent as type-5 LSA. OSPF protocol will then take it's own course of action and type-3 will be preferred. Now If remove this assumption, PE1-PE2 will have IBGP peering. If ROUTE_2 is sent after ROUTE_1, then IBGP in PE2 will consider ROUTE_2 as a replacement route to ROUTE_1 and vice-versa. This will affect the OSPF protocol functionality in the sense either ROUTE_1 or ROUTE_2 will be considered as valid routes, but not both. Thanks and Regards, Shiv From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 16 11:39:27 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 LAA10306 for ; Mon, 16 Dec 2002 11:39:27 -0500 (EST) 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 gBGGfqb08690 for ; Mon, 16 Dec 2002 11:41:52 -0500 (EST) Received: from lyris.nortelnetworks.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 gBGGfnx01304 for ; Mon, 16 Dec 2002 11:41:49 -0500 (EST) From: ananth.nagarajan@mail.sprint.com X-OpenMail-Hops: 1 Date: Mon, 16 Dec 2002 10:38:58 -0600 Message-Id: Subject: draft-ietf-ppvpn-generic-reqts-00 MIME-Version: 1.0 TO: ppvpn@nortelnetworks.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 16 Dec 2002 10:38:58 -0600" Content-Transfer-Encoding: 7bit X-SMTP-HELO: damgwp01.corp.sprint.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: parker2.sprint.com [199.14.91.106] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit All, Since there has been no response to my email on Nov 26, and since we have an aggressive time line for completion of this draft, I would like to solicit comments once again. If nothing comes up, I would go ahead and update the draft after minor editorial changes this Friday (December 20), and it would then be ready for last call. So I request you to make any comments ASAP. To make it easier, here are some areas where we would like suggestions/agreement/disagreement: Section 5.1.1: Service Provider Capacity Sizing Projections 1. "The estimate is that a large service provider will require support for on the order of 10,000 VPNs within four years." 2. "The number of site interfaces should range from a few site interfaces to over 50,000 site interfaces per VPN." 3. "The number of routes per VPN may range from just a few to the number of routes exchanged between ISPs (on the order of 100,000)." Section 5.1.2 4. Section 5.1.2.1 (Users per VPN): "L3 VPNs must scale from 2 users per VPN to O(10^5) users per VPN. L2 VPNs must scale from 2 users to a few hundred." 5. Section 5.1.2.2 (Users per site): "L3 VPNs must scale from 1 user per site to thousands of users per site. L2 VPNs must scale from 1 user to a few hundred per site." 6. Note that the above makes the assumption that the number of sites in an L2VPN is of the same order as teh number of users. this is also mentioned in Section 5.1.2.3. Does this make sense? 7. Section 5.1.2.4 (Number of PEs and CEs): There are no numbers given. Do you agree with the text? Any suggestions for numbers? 8. Section 5.1.2.5 (Number of sites per PE): "The scaling point here is that the PE must be able to support a few or even a single site on the low end and O(10^4) sites on the high end." Is this a reasonable criterion by which PPVPN solutions are evaluated? 9. Section 5.1.2.6 (Number of VPNs in the network): "As mentioned in Section 5.1.1, the number of VPNs in the network should be O(10^4)." 10. Section 5.1.2.7 (Number of VPNs per PE): "It is estimated that the number of VPNs needs to be at least an order of magnitude higher than the number of sites per PE." 11. Section 5.1.2.8 (Number of VPNs per site): "It is possible that one customer will run up to O(100) VPNs." Is this even a reasonable metric? 12. Section 5.1.2.9 (Number of addresses per VPN): No numbers mentioned. Is the text ok? Any suggestions for numbers? 13. Section 5.1.2.10 (Number of addresses per PE): "This is a function of the number of VPNs per site and the number of addresses per site and the number of sites per PE." 14. Any other metrics that you would like to see? 15. Other comments on the rest of the document are welcome. Thanks, Ananth > -----Original Message----- > From: ananth.nagarajan [mailto:ananth.nagarajan@mail.sprint.com] > Sent: Tuesday, November 26, 2002 2:23 PM > To: ppvpn > Cc: ananth.nagarajan > Subject: Soliciting comments/input on > draft-ietf-ppvpn-generic-reqts-00.txt > > > All, > As discussed during the PPVPN meeting in Atlanta last week, I have > re-submitted draft-nagarajan-ppvpn-generic-reqts-01.txt as a WG > document (draft-ietf-ppvpn-generic-reqts-00.txt). This version has a > few minor changes from draft-nagarajan-...-01. > > These include: > - The taxonomy picture and the wording in that section have > been fixed > so that the context is generic (without specifying specific > solutions). > - Typos have been fixed > - Wording changes have been made in accordance with feedback > received > prior to the meeting. > > As mentioned during the PPVPN meeting, the authors would like to > finalize this document by the end of the year and therefore, > we request > input on the draft. Specifically, input is sought on the contents of > the scalability section (section 5.1.1 and 5.1.2). It should > be noted > that the scalability parameters and numbers used in this draft are > merely to provoke discussion, and are based on the operational > experiences of a few representatives of the co-authors list. These > numbers are not carved in stone by any means, and I therefore request > some discussion on this topic on the list. > > I would also like to request comments on Section 4.2 (Stability), in > terms of a good working description of stability and the generic > requirements associated with it. > > The authors hope to consolidate the comments received and > have another > revision of this draft in the second week of December (targetting > December 10), which we hope would be close to final. > > Thanks, > Ananth > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 16 20:11: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 UAA23009 for ; Mon, 16 Dec 2002 20:11:49 -0500 (EST) 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 gBH1EBb23221 for ; Mon, 16 Dec 2002 20:14:12 -0500 (EST) Received: from lyris.nortelnetworks.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 gBH1E9x12115 for ; Mon, 16 Dec 2002 20:14:09 -0500 (EST) From: Subject: LASER PRINTER, COPIER, & FAX SUPPLIES. Date: lun, 16 dic 2002 08:15:22 Message-Id: <557.718086.849317@unknown> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-SMTP-HELO: unknown X-SMTP-MAIL-FROM: onlinesaleonprintsupplies@terra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,scotfor@nortelnetworks.com,nnupdate@nortelnetworks.com,moodyjam@nortelnetworks.com,nortelr@nortelnetworks.com,rycroft@nortelnetworks.com,muirj@nortelnetworks.com X-SMTP-PEER-INFO: [200.71.70.105] X-LYRIS-Message-Id: GTTS | December 2002 Newsletter
GT Toner Supplies
Laser Printer, Copier, and Fax Supplies
1-888-662-2256
1-866-237-7397

Hp-Hp color - Lexmark - Epson - Panasonic - Apple - Cannon - Xerox
 
Please forward to the person responsible for purchasing your laser printer supplies.
If you received this email on error, please reply to gtts002@cable.net.co with subject: REMOVE... sorry for the inconvenience.
University and/or School purchase orders WELCOME. (no credit approval required)
Pay by check, c.o.d, or purchase order (net 30 days).

WE ACCEPT ALL MAJOR CREDIT CARDS!

New! HP 4500/4550 series color cartridges in stock!

 
 
Order by phone: Toll free 1-866-237-7397 Toll free 1-888-662-2256

Order by email: gtts002@cable.net.co subject: ORDER
Our cartridge prices are as follows:
(please order by item number)
Item

HP

Price
1 92274A Toner Cartridge for LaserJet 4L, 4ML, 4P, 4MP $47.50
2 C4092A Black Toner Cartridge for LaserJet 1100A, ASE, 3200SE $45.50
2A C7115A Toner Cartridge For HP LaserJet 1000, 1200, 3330 $55.50
2B C7115X High Capacity Toner Cartridge for HP LaserJet 1000, 1200, 3330 $65.50
3 92295A Toner Cartridge for LaserJet II, IID, III, IIID $49.50
4 92275A Toner Cartridge for LaserJet IIP, IIP+, IIIP $55.50
5 C3903A Toner Cartridge for LaserJet 5P, 5MP, 6P, 6Pse, 6MP, 6Pxi $46.50
6 C3909A Toner Cartridge for LaserJet 5Si, 5SiMX, 5Si Copier, 8000 $92.50
7 C4096A Toner Cartridge for LaserJet 2100, 2200DSE, 2200DTN $72.50
8 C4182X UltraPrecise High Capacity Toner Cartridge for LaserJet 8100 Series $125.50
9 C3906A Toner Cartridge for LaserJet 5L, 5L Xtra, 6Lse, 6L, 6Lxi, 3100se $42.50
9A C3906A Toner Cartridge for LaserJet 3100, 3150 $42.50
10 C3900A Black Toner Cartridge for HP LaserJet 4MV, 4V $89.50
11 C4127A Black Toner Cartridge for LaserJet 4000SE, 4000N, 4000T, 4000TN $76.50
11A C8061A Black Laser Toner for HP LaserJet 4100, 4100N $76.50
11B C8061X High Capacity Toner Cartridge for LJ4100, 4100N $85.50
11C C4127X High Capacity Black Cartridge for LaserJet 4000SE,4000N,4000T,4000TN $84.50
12 92291A Toner Cartridge for LaserJet IIISi, 4Si, 4SiMX $57.50
13 92298A Toner Cartridge for LaserJet 4, 4 Plus, 4M, 4M Plus, 5, 5se, 5M, 5N $46.50
14 C4129X High Capacity Black Toner Cartridge for LaserJet 5000N $97.50
15 LASERFAX 500, 700 (FX1) $49.00
16 LASERFAX 5000, 7000 (FX2) $54.00
17 LASERFAX (FX3) $49.00
18 LASERFAX (FX4) $49.00
Item

HP COLOR

Price
C1 C4194a Toner Cartridge, Yellow (color lj 4500/4550 series) $89.50
C2 C4193a Toner Cartridge, Magenta (color lj 4500/4550 series) $89.50
C3 C4192a toner cartridge, cyan (color lj 4500/4550 series) $89.50
C4 c4191a toner cartridge, black (color lj 4500/4550 series) $74.50
Item

LEXMARK

Price
19 1380520 High Yield Black Laser Toner for 4019, 4019E, 4028, 4029, 6, 10, 10L $109.50
20 1382150 High Yield Toner for 3112, 3116, 4039-10+, 4049- Model 12L,16R, Optra $109.50
21 69G8256 Laser Cartridge for Optra E, E+, EP, ES, 4026, 4026 (6A,6B,6D,6E) $49.00
22 13T0101 High Yield Toner Cartridge for Lexmark Optra E310, E312, E312L $89.00
23 1382625 High-Yield Laser Toner Cartridge for Lexmark Optra S (4059) $129.50
24 12A5745 High Yield Laser Toner for Lexmark Optra T610, 612, 614 (4069) $165.00
Item

EPSON

Price
25 S051009 Toner Cartridge for Epson EPL7000, 7500, 8000+ $115.50
25A S051009 LP-3000 PS 7000 $115.50
26 AS051011 Imaging Cartridge for ActionLaser-1000, 1500 $99.50
26A AS051011 EPL-5000, EPL-5100, EPL-5200 $99.50
Item

PANASONIC

Price
27 Nec series 2 models 90 and 95
 $109.50
Item

APPLE

Price
28 2473G/A Laser Toner for LaserWriter Pro 600, 630, LaserWriter 16/600 PS
 $57.50
29 1960G/A Laser Toner for Apple LaserWriter Select, 300, 310, 360 $ 71.50
30 M0089LL/A Toner Cartridge for Laserwriter 300, 320 (74A) $ 52.50
31 M6002 Toner Cartridge for Laserwriter IINT, IINTX, IISC, IIF, IIG (95A) $ 47.50
31A M0089LL/A Toner Cartridge for Laserwriter LS, NT, NTR, SC (75A) $ 55.50
32 M4683G/A Laser Toner for LaserWriter 12, 640PS $85.50
Item

CANON

Price
33 Fax CFX-L3500, CFX-4000 CFX-L4500, CFX-L4500IE & IF FX3 $49.50
33A L-250, L-260i, L-300 FX3 $49.50
33B LASER CLASS 2060, 2060P, 4000 FX3 $49.50
34 LASER CLASS 5000, 5500, 7000, 7100, 7500, 6000 FX2 $49.50
35 FAX 5000 FX2 $49.50
36 LASER CLASS 8500, 9000, 9000L, 9000MS, 9500, 9500 MS, 9500 S FX4  $49.50
36A Fax L700,720,760,770,775,777,780,785,790, & L3300 FX1 $49.50
36B L-800, L-900 FX4 $49.50
37 A30R Toner Cartridge for PC-6, 6RE, 7, 11, 12 $59.50
38 E-40 Toner Cartridge for PC-720, 740, 770, 790,795, 920, 950, 980 $85.50
38A E-20 Toner Cartridge for PC-310, 325, 330, 330L, 400, 420, 430 $85.50
Item

XEROX

Price
39 6R900 75A $ 55.50
40 6R903 98A $ 46.50
41 6R902 95A $ 49.50
42 6R901 91A $ 65.50
43 6R908 06A $ 42.50
44 6R899 74A $ 47.50
45 6R928 96A $ 72.50
46 6R926 27X $ 84.50
47 6R906 09A $ 92.50
48 6R907 4MV $ 89.50
49 6R905 03A $46.50

call toll free 1-866-237-7397
30 Day unlimited warranty included on all products
GT Toner Supplies guarantees these cartridges to be free from defects in workmanship and material.

We look forward in doing business with you.

We Guarantee your satisfaction!!!
If you are ordering by purchase order please fill out an order form
with the following information: 

purchase order number
phone number
company or school name
shipping address and billing address
city, state zip code Order Now 

call toll free

1-866-237-7397
If you are ordering by e-mail or c.o.d. please fill out an order
form with the following information: 

phone number
company name
first and last name
street address
city, state zip code 

call toll free

1-866-237-7397
All trade marks and brand names listed above are property of the respective
holders and used for descriptive purposes only.
 
PLEASE DO NOT REPLY TO THIS EMAIL
From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Dec 18 09:21:14 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 JAA08670 for ; Wed, 18 Dec 2002 09:21:13 -0500 (EST) 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 gBIENRQ16491 for ; Wed, 18 Dec 2002 09:23:28 -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 gBIENNN23031 for ; Wed, 18 Dec 2002 09:23:24 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15872.33980.521014.792919@harjus.eng.song.fi> Date: Wed, 18 Dec 2002 16:22:52 +0200 To: ppvpn@nortelnetworks.com Subject: radius based pe discovery X-Mailer: VM 7.03 under Emacs 21.2.1 From: jh@lohi.eng.song.fi X-SMTP-HELO: lohi.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: lohi.eng.song.fi [195.10.149.18] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit i just submitted the following internet draft: Using Radius for PE-Based VPN Discovery Abstract This document describes how in PE-based VPNs a PE of a VPN can use Radius to authenticate its CEs and discover the other PEs of the VPN. it is available also as ftp://lohi.eng.song.fi/tmp/draft-heinanen-radius-pe-discovery-00.txt the memo describes the basic ideas behind radius based discovery, but not all protocol details (packet formats). in order for me to make sense to spend more time on this, the working group should measure if there is enough support for radius based discovery so that this memo or (based on the comments) its successor could become a working group document. -- juha From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 20 11:38: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 LAA01182 for ; Fri, 20 Dec 2002 11:38:52 -0500 (EST) 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 gBKGfD113252 for ; Fri, 20 Dec 2002 11:41:13 -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 gBKGfAp06022 for ; Fri, 20 Dec 2002 11:41:11 -0500 (EST) From: ananth.nagarajan@mail.sprint.com X-OpenMail-Hops: 1 Date: Fri, 20 Dec 2002 10:39:46 -0600 Message-Id: Subject: ID submitted: draft-ietf-ppvpn-generic-reqts-01.txt MIME-Version: 1.0 TO: ppvpn@nortelnetworks.com Content-Type: multipart/mixed; boundary="openmail-part-78b60330-00000001" X-SMTP-HELO: damgwp01.corp.sprint.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: parker2.sprint.com [199.14.91.106] X-LYRIS-Message-Id: --openmail-part-78b60330-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 20 Dec 2002 10:39:46 -0600" Content-Transfer-Encoding: 7bit All, The attached revised generic requirements document was submitted yesterday. It may take a while for it to get posted because of the holiday season. Please see and comment. This call for comments may be treated as a WG last call (Marco will follow up with that announcement). Major changes include fixing typos, and modifying Section 5.1 on scalability. Thanks and happy holidays. Ananth --openmail-part-78b60330-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="draft-ietf-ppvpn-generic-reqts-01.txt" ;Creation-Date="Fri, 20 Dec 2002 10:39:46 -0600" Content-Transfer-Encoding: 7bit Internet Draft Ananth Nagarajan Expiration Date: June 2003 Sprint Category: Informational (Editor) December 2002 Generic Requirements for Provider Provisioned VPN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC-2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that othergroups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in [Page 1] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 this document are to be interpreted as described in [RFC-2119]. 1. Introduction This document is an output of the design team formed to develop requirements for PPVPNs in the PPVPN working group. As such this work fits within the scope of the PPVPN working group. This document discusses generic PPVPN requirements categorized as service, provider and engineering requirements. These are independent of any particular type of PPVPN technology. In other words, all PPPVP technologies are expected to meet the umbrella set of requirements described in this document. Specific requirements related to Layer 3 PPVPNs are described in [L3REQTS]. Similarly, requirements that are specific to layer 2 PPVPNs are described in [L2REQTS]. 1.1. Problem Statement Corporations and other organizations have become increasingly dependent on their networks for tele- and datacommunication. The data communication networks were originally built as Local Area Networks (LAN). Over time the possibility to interconnect the networks on different sites has become more and more important. The connectivity for corporate networks has been supplied by service providers, mainly as Frame Relay (FR) or Asynchronous Transfer Mode (ATM) connections, and more recently as Ethernet and IP-based tunnels. This type of network, interconnecting a number of sites over a shared network infrastructure is called Virtual Private Network (VPN). If the sites belong to the same organization, the VPN is called an Intranet. If the sites belong to different organizations that share a common interest, the VPN is called an Extranet. Customers are looking for service providers to deliver data and telecom connectivity over one or more shared networks, with service level assurances in the form of security, QoS and other parameters. In order to provide isolation between the traffic belonging to different customers, mechanisms such as Layer 2 connections or Layer 2/3 tunnels are necessary. When the shared infrastructure is an IP network, the tunneling technologies that are typically used are IPsec, MPLS, L2TP, GRE, IP-in-IP etc. Traditional Internet VPNs have been based on IPsec to provide [Page 2] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 security over the Internet. Service providers are now beginning to deploy enhanced VPN services that provide features such as service differentiation, traffic management, Layer 2 and Layer 3 connectivity, etc. in addition to security. Newer tunneling mechanisms have certain features that allow the service providers to provide these enhanced VPN services. The VPN solutions we define now must be able to accommodate the traditional types of VPNs as well as the enhanced services now being deployed. They need to be able to run in a single service provider's network, as well as between a set of service providers and across the Internet. In doing so the VPNs should not be allowed to violate basic Internet design principles or overload the Internet core routers or accelarate the growths of the Internet routing tables. Specifically, Internet core routers shall not be required to maintain VPN-related information, regardless of whether the Internet routing protocols are used to distribute this information or not. In order to achieve this, the mechanisms used to develop various PPVPN solutions shall be as common as possible with generic Internet infrastructure mechanisms like discovery, signaling, routing and management. At the same time, existing Internet infrastructure mechanisms shall not be overloaded. Another generic requirement from a standardization perspective is to limit the number of different solution approaches to provide a specific type of VPN to as small a number as possible. 1.2. Outline of this document This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The document contains several sections, with each set representing a significant aspect of PPVPN requirements. Section 2 lists authors who contributed to this document. Section 3 defines terminology and presents a taxonomy of PPVPN technologies. The taxonomy contains two broad classes, representing Layer 2 and Layer 3 VPNs. Each top level VPN class contains subordinate classes. For example, the Layer 3 VPN class contains a subordinate class of PE-based Layer 3 VPNs. Sections 4, 5, 6 describe generic PPVPN requirements. The requirements are broadly classified under the following categories: 1) Service requirements - Service attributes that the customer can observe or measure. For example, does the service forward frames or route datagrams? What security guarantees does the service provide? Availability and stability are key requirements in this category. [Page 3] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 2) Provider requirements - Characteristics that Service Providers use to determine the cost-effectiveness of a PPVPN service. Scaling and management are examples of Provider requirements. 3) Engineering requirements - Implementation characteristics that make service and provider requirements achievable. These can be further classified as: 3a) Forwarding plane requirements - e.g., requirements related to router forwarding behavior. 3b) Control plane requirements - e.g., requirements related to reachability and distribution of reachability information. 3c) Requirements related to the commonality of PPVPN mechanisms with each other and with generic Internet mechanisms. 2. Contributing Authors This document was the combined effort of several individuals that were part of the Service Provider focus group whose intentions were to present Service Provider view on the general requirements for PPVPN. A significant set of requirements were directly taken from previous work by the PPVPN WG to develop requirements for Layer 3 PPVPN [L3REQTS]. The existing work in the L2 requirements area has also influenced the contents of this document [L2REQTS]. Besides the editor, the following are the authors that contributed to this document: Loa Andersson Ron Bonica Dave McDysan Junichi Sumimoto Muneyoshi Suzuki David Meyer Marco Carugi Yetik Serbest Luyuan Fang Javier Achirica [Page 4] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 3. Definitions and Taxonomy The terminology used in this document is defined in [TERMINOLOGY]. In addition the following terminology is used: Site: a geographical location with one or more users or one or more servers or a combination of servers and users. User: the end user equipment (hosts), e.g., a workstation. PPVPN ________________|__________________ | | Layer 2 (L2) Layer 3 (L3) ______|_____ ______|________ | | | | PE-based CE-based PE-based CE-based | |___________ | | P2P P2MP The figure above presents a taxonomy of PPVPN technologies. Although the above figure shows the classification for PE-based Layer 2 VPNs, it should be noted that CE-based Layer 2 PPVPNs may also be further classified as point-to-point (P2P) or point-to-multipoint (P2MP). However, there are not many solutions in the CE-based Layer 2 PPVPN space being proposed. It is also the intention of the working group to have a limited number of solutions, and this goal must be kept in mind when proposing solutions that meet the requirements specified in this document. Definitions for CE-based and PE-based PPVPNs can be obtained from [L3FRAMEWORK]. Layer 2 specific definitions can be obtained from [L2FRAMEWORK]. [Page 5] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 4. Service requirements These are the requirements that a customer can observe or measure, in order to verify if the PPVPN service that the Service Provider (SP) provides is satisfactory. 4.1. Availability VPN services must have high availability. VPNs that are distributed over several sites require connectivity to be maintained even in the event of network failures or degraded service. This can be achieved via various redundancy techniques such as: 1. Physical Diversity A single site connected to multiple CEs (for CE-based PPVPN) or PEs (for PE-based PPVPNs), or different POPs, or even different service providers or 2. via tunnel redundancy. 4.2. Stability In addition to availability, VPN services must also be stable. Stability is a function of several components such as VPN routing, signaling and discovery mechanisms, in addition to tunnel stability. For example, in the case of routing, route flapping or routing loops must be avoided in order to ensure stability. Stability of the VPN service is directly related to the stability of the mechanisms and protocols used to establish the service. It should also be possible to allow network upgrades and maintenance procedures without impacting the VPN service. 4.3. Traffic types VPN services must support unicast (or point to point) traffic and should support any-to-any or point-to-multipoint traffic including multicast and broadcast traffic. In the broadcast model, the network delivers a stream to all members of a subnetwork, regardless of their [Page 6] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 interest in that stream. In the multicast model, the network delivers a stream to a set of destinations that have registered interest in the stream. All destinations need not belong to the same subnetwork. Multicast is more applicable to L3 VPNs while broadcast is more applicable to L2VPNs. It is desirable to support multicast limited in scope to an intranet or extranet. The solution should be able to support a large number of such intranet or extranet specific multicast groups in a scalable manner. All PPVPN approaches shall support both IPv4 and IPv6 traffic. Specific L2 traffic types (e.g., ATM, Frame Relay and Ethernet) shall be supported via encapsulation in IP or MPLS tunnels in the case of L2VPNs. 4.4. Data isolation The PPVPN must support forwarding plane isolation. The network must never deliver user data accross VPN boundaries unless the two VPNs participate in an intranet or extranet. Furthermore, if the provider network receives signaling or routing information from one VPN, it must not reveal that information to another VPN unless the two VPNs participate in an intranet or extranet. 4.5. Security A range of security features should be supported by the suite of PPVPN solutions in the form of securing customer flows, providing authentication services for temporary, remote or mobile users, and the need to protect service provider resources involved in supporting a PPVPN [VPN SEC]. Each PPVPN solution should state which security features it supports and how such features can be configured on a per customer basis. Protection against Denial of Service (DoS) attacks is a key component of security mechanisms. Examples of DoS attacks include mail spamming, access connection congestion, TCP SYN attacks, ping attacks and intrusion attempts such as Trojan horse attack. [Page 7] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 4.5.1. User data security PPVPN solutions that support user data security should use standard methods (e.g., IPsec) to achieve confidentiality, integrity, authentication and replay attack prevention. Such security methods must be configurable between different end points, such as CE-CE, PE- PE, and CE-PE. It is also desirable to configure security on a per- route or per-VPN basis. 4.5.2. Access control A PPVPN solution may also have the ability to activate the appropriate filtering capabilities upon request of a customer. A filter provides a mechanism so that access control can be invoked at the point(s) of communication between different organizations involved in an extranet. Access control can be implemented by a firewall, access control lists on routers or similar mechanisms to apply policy-based access control. Access control must also be applicable between CE-CE, PE-PE and CE-PE. 4.5.3. Site authentication and authorization A PPVPN solution requires authentication and authorization of the following: - temporary and permanent access for users connecting to sites (authentication and authorization BY the site) - the site itself (authentication and authorization FOR the site) 4.5.4. Inter domain security The VPN solution must have appropriate security mechanisms to prevent the different kinds of Distributed Denial of Service (DDoS) attacks mentioned earlier, misconfiguration or unauthorized accesses in inter domain PPVPN connections. [Page 8] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 4.6. Topology A VPN should support arbitrary, customer-defined inter-site connectivity, ranging, for example, from hub-and-spoke, partial mesh to full mesh topology. These can actually be different from the topology used by the service provider. To the extent possible, a PPVPN service should be independent of the geographic extent of the deployment. Multiple VPNs per customer site should be supported without requiring additional hardware resources per VPN. This should also include a free mix of L2 and L3 VPNs. To the extent possible, the PPVPN services should be independent of access network technology. 4.7. Addressing Each customer resource must be identified by an address that is unique within its VPN. It need not be identified by a globally unique address. Support for private addresses as described in RFC 1918, as well as overlapping customer addresses shall be supported. A VPN service shall be capable of supporting non-IP customer addresses via encapsulation techniques, if it is a Layer 2 VPN (e.g., Frame Relay, ATM, Ethernet). Support for non-IP Layer 3 addresses may be desirable in some cases, but is beyond the scope of VPN solutions developed in the IETF, and therefore, this document. 4.8. Quality of Service A PPVPN shall be able to support QoS via IETF standardized mechanisms such as Diffserv. Support for best-effort traffic shall be mandatory for all PPVPN types. Note that all cases involving QoS may require that the CE and/or PE perform shaping and/or policing. The need to provide QoS will occur primarily in the access network, since that will often be the bottleneck. This is likely to occur since the backbone effectively statistically multiplexes many users, and is traffic engineered or includes capacity for restoration and growth. Hence PE-PE QoS is not a major issue. As far as access QoS is [Page 9] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 concerned, there are two directions of QoS management that should be considered in any PPVPN service regarding QoS: - From the CE across the access network to the PE - From the PE across the access network to CE PPVPN CE and PE devices should be capable of supporting QoS across at least the following subset of access networks, as applicable to the specific type of PPVPN (L2 or L3). However, to the extent possible, the QoS capability of a PPVPN should be independent of the access network technology: - ATM Virtual Connections (VCs) - Frame Relay Data Link Connection Identifiers (DLCIs) - 802.1d Prioritized Ethernet - MPLS-based access - Multilink Multiclass PPP - QoS-enabled wireless (e.g., LMDS, MMDS) - Cable modem - QoS-enabled Digital Subscriber Line (DSL) Different service models for QoS may be supported. Examples of PPVPN QoS service models are: - Managed access service : Provides QoS on the access connection between CE and the customer facing ports of the PE. No QoS support is required in the provider core network in this case. - Edge-to-edge QoS : Provides QoS across the provider core, either between CE pairs or PE pairs, depending on the tunnel demarcation points. This scenario requires QoS support in the provider core network. 4.9. Service Level Agreement and Service Level Specification Monitoring and Reporting A Service Level Specification (SLS) may be defined per access network connection, per VPN, per VPN site, and/or per VPN route. The service provider may define objectives and the measurement interval for at least the SLS using the following Service Level Objective (SLO) parameters: - QoS and traffic parameters for the Intserv flow or Diffserv class [Y.1541] - Availability for the site, VPN, or access connection [Page 10] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 - Duration of outage intervals per site, route or VPN - Service activation interval (e.g., time to turn up a new site) - Trouble report response time interval - Time to repair interval - Total traffic offered to the site, route or VPN - Measure of non-conforming traffic for the site, route or VPN - Delay and delay variation (jitter) bounds - Packet ordering, at least when transporting L2 services sensitive to reordering (e.g., ATM). The above list contains items from [Y.1241], as well as other items typically part of SLAs for currently deployed VPN services [FRF.13]. See [RFC3198] for generic definitions of SLS, SLA, and SLO. The provider network management system shall measure, and report as necessary, whether measured performance meets or fails to meet the above SLS objectives. The service provider and the customer may negotiate a contractual arrangement that includes a Service Level Agreement (SLA) regarding compensation if the provider does not meet an SLS performance objective. Details of such compensation are outside the scope of this document. 4.10. Network Resource Partitioning and Sharing between VPNs Network resources such as memory space, FIB table, bandwidth and CPU processing shall be shared between VPNs. Mechanisms should be provided to prevent any specific VPN from taking up available network resources and causing others to fail. [Page 11] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 5. Provider requirements This section describes operational requirements for a cost-effective, profitable VPN service offering. 5.1. Scalability The scalability for VPN solutions has many aspects. The list below is intended to comprise of the aspects that PPVPN solutions should address. Clearly these aspects in absolute figures are very different for different types of VPNs - i.e., a point to point service has only two sites, while a VPLS or L3VPN may have a larger number of sites. It is also important to verify that PPVPN solutions not only scales on the high end, but also on the low end - i.e., a VPN with three sites and three users should be as viable as a VPN with hundreds of sites and thousands of users. 5.1.1. Service Provider Capacity Sizing Projections A PPVPN solution should be scalable to support a very large number of VPNs per Service Provider network. The estimate is that a large service provider will require support for O(10^4) VPNs within four years. A PPVPN solution should be scalable to support a wide range of number of site interfaces per VPN, depending on the size and/or structure of the customer organization. The number of site interfaces should range from a few site interfaces to over 50,000 site interfaces per VPN. A PPVPN solution should be scalable to support of a wide range of number of routes per VPN. The number of routes per VPN may range from just a few to the number of routes exchanged between ISPs (O(10^5)). The high end number is especially true considering the fact that many large ISPs may provide VPN services to smaller ISPs or large corporations. Typically, the number of routes per VPN are twice the number of site interfaces or larger. A PPVPN solution should support high values of the frequency of configuration setup and change, e.g., for real-time provisioning of an on-demand videoconferencing VPN or addition/deletion of sites. Approaches should articulate scaling and performance limits for more complex deployment scenarios, such as inter-AS(S) VPNs and carriers' [Page 12] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 carrier. Approaches should also describe other dimensions of interest, such as capacity requirements or limits, number of interworking instances supported as well as any scalability implications on management systems. A PPVPN solution should support a large number of customer interfaces on a single PE (for PE-based PPVPN) or CE (for CE-based PPVPN) with current Internet protocols. 5.1.2. VPN Scalability aspects This section describes the metrics for scaling PPVPN solutions, points out some of the scaling differences between L2 and L3 VPNs. Further discussion on service provider sizing projections are in Section 5.1.1. 5.1.2.1. Number of users per site The number of users per site follows the same logic as for users per VPN. Further, it must be possible to have single user sites connected to the same VPN as very large sites are connected to. L3 VPNs must scale from 1 user per site to O(10^3) per site. L2 VPNs must scale from 1 user to a O(10^2) per site. 5.1.2.2. Number of sites per VPN The number of sites per VPN clearly depends on the number of users per site. VPNs must scale from 2 to O(10^2) sites per VPN. These numbers are usually limited by device memory. 5.1.2.3. Number of PEs and CEs The number of PEs that supports the same set of VPNs, i.e., the number of PEs that needs to directly exchange information on VPN de- multiplexing information is clearly a scaling factor in a PE-based VPN. Similarly, in a CE-based VPN, the number of cEs is a scaling factor. This number is driven by the type of VPN service, and also by whether the service is within a single AS/domain or involves a multi- SP or multi-AS network. Typically, this number should be as low as possible in order to make the VPN cost effective and manageable. [Page 13] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 5.1.2.4. Number of sites per PE The number of sites per PE needs to be discussed based on several different scenarios. On the one hand there is a limitation to the number of customer facing interfaces that the PE can support. On the other hand the access network may aggregate several sites connected on comparatively low bandwidth on to one single high bandwidth interface on the PE. The scaling point here is that the PE must be able to support a few or even a single site on the low end and O(10^4) sites on the high end. This number is also limited by device memory. Implementations of PPVPN solutions may be evaluated based on this requirement, because it directly impacts cost and manageability of a VPN. 5.1.2.5. Number of VPNs in the network The number of VPNs should scale linearly with the size of the access network and with the number of PEs. As mentioned in Section 5.1.1, the number of VPNs in the network should be O(10^4). This requirement also effectively places a requirement on the number of tunnels that must be supported in the network. For a PE-based VPN, the number of tunnels is of the same order as the number of VPNs. For a CE-based VPN, the number of tunnels in the core network may be fewer, because of the possibility of tunnel aggregation or multiplexing across the core. 5.1.2.6. Number of VPNs per customer For a large it is fully conceivable that the number of VPNs could be fairly large, both service diversification and separation of different work groups contributes to this. It is possible that one customer will run up to O(100) VPNs. 5.1.2.7. Number of addresses per VPN Since any VPN solution shall support private customer addresses, the number of addresses supported for a L3 VPN needs to scale from very few (for smaller customers) to very large numbers seen in typical Service Provider backbones. The high end is especially true considering that many Tier 1 SPs may provide VPN services to Tier 2 SPs or to large corporations. For a L2 VPN this number would be on the order of addresses supported in typical native Layer 2 backbones. [Page 14] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 5.1.3. Solution-Specific Metrics Each PPVPN solution shall document its scalability characteristics in quantitative terms. Some examples are provided below as an illustration. The following example applies to the number of tunnels necessary in various devices in the network. In a PE-based VPN, edge-to-edge tunnels (PE-to-PE) need to be established, while in a CE-based VPN, end-to-end tunnels between pairs of CEs are necessary. Therefore,in general, PE-based VPNs scale better than CE-based VPNs, although the scalability of CE-based VPNs may be improved by tunnel aggregation between PEs. A scalable PE-based solution should quantify the amount of state that a PE and P device must support. This should be stated in terms of the total number of VPNs and site interfaces supported by the service provider. Ideally, all VPN-specific state should be contained in the PE device for a PE-based VPN. Similarly, all VPN-specific state should be contained in the CE device for a CE-based VPN. In all cases, the backbone routers (P devices) shall not maintain VPN- specific state as far as possible. Another metric is that of complexity. In a PE-based solution the PE is more complex in that it must maintain tunnel-specific information for each VPN, but the CE is simpler since it does not need to support tunnels. On the other hand, in a CE-based solution, the CE is more complex since it must implement routing across a number of tunnels to other CEs in the VPN, but the PE is simpler since it has only one routing and forwarding instance. A CE-based solution should quantify the state and scaling limits. This should be stated in terms of the number of tunnels supported, how these tunnels are provisioned and maintained (e.g., key exchange), how routing occurs across these tunnels, and what the impact of changes in the network topology do to the convergence performance of such a solution. 5.2. Management A service provider must have a means to view the topology, operational state, service order status, and other parameters associated with each customer's VPN. Furthermore, the service provider must have a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the VPN service(s) [Page 15] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 to its customers. VPN devices should provide standards-based management interfaces wherever feasible. 5.2.1. Customer Management of a VPN A customer must have a means to view the topology, operational state, service order status, and other parameters associated with his or her VPN. All aspects of management information about CE devices and customer attributes of a PPVPN manageable by an SP should be capable of being configured and maintained by the customer after being authenticated and authorized. A customer should be able to make dynamic requests for changes to traffic parameters. A customer should be able to receive real-time response from the SP network in response to these requests. One example of such as service is a "Dynamic Bandwidth management" capability, that enables real-time response to customer requests for changes of allocated bandwidth allocated to their VPN(s). 6. Engineering requirements These requirements are driven by implementation characteristics that make service and provider requirements achievable. 6.1. Forwarding plane requirements VPN solutions should not pre-suppose or preclude the use of IETF developed tunneling techniques such as IP-in-IP, L2TP, GRE, MPLS or IPsec. The separation of VPN solution and tunnels will facilitate adaptability with extensions to current tunneling techniques or development of new tunneling techniques. It should be noted that the choice of the tunneling techniques may impact the service capabilities of the VPN solution. For Layer 2 VPNs, solutions should utilize the encapsulation techniques defined by PWE3, and should not impose any new requirements on these techniques. PPVPN solutions must not impose any restrictions on the backbone traffic engineering and management techniques. Conversely, backbone [Page 16] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 engineering and management techniques must not affect the basic operation of a PPVPN, apart from influencing the SLA/SLS guarantees associated with the service. The SP should, however, be required to provide per-VPN management, tunnel maintenance and other maintenance required in order to meet the SLA/SLS. By definition, VPN traffic should be segregated from each other, and from non-VPN traffic in the network. After all, VPNs are a means of dividing a physical network into several logical (virtual) networks. VPN traffic separation should be done in a scalable fashion. However, safeguards should be made available against misbehaving VPNs to not affect the network and other VPNs. A VPN solution should not impose any hard limit on the number of VPNs provided in the network. 6.2. Control plane requirements The plug and play feature of a VPN solution with minimum configuration requirements is an important consideration. The VPN solutions should have mechanisms for protection against customer interface and/or routing instabilities so that they do not impact other customers' services. A VPN should be provisioned with minimum number of steps. For instance,a VPN need not be configured in every PE. For this to be accomplished, an auto-configuration and an auto-discovery protocol, which should be as common as possible to all VPN solutions, should be defined. However, these mechanisms should not adversely affect the cost, scalability or stability of a service by being overly complex, or by increasing layers in the protocol stack. Mechanisms to protect the SP network from effects of misconfiguration of VPNs should be provided. 6.3. Control Plane Containment The PPVPN control plane must include a mechanism through which the service provider can filter PPVPN related control plane information as it passes between Autonomous Systems. For example, if a service provider supports a PPVPN offering, but the service provider's neighbors do not participate in that offering, the service provider should not leak PPVPN control information into neighboring networks. Neighboring networks must be equipped with mechanisms that filter this information should the service provider leak it. [Page 17] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 6.4. Requirements related to commonality of PPVPN mechanisms with each other and with generic Internet mechanisms As far as possible, the mechanisms used to establish a VPN service should re-use well-known IETF protocols, limiting the need to define new protocols from scratch. It should, however, be noted that the use of Internet mechanisms for the establishment and running of an Internet-based VPN service, shall not affect the stability, robustness, and scalability of the Internet or Internet services. In other words, these mechanisms should not conflict with the architectural principles of the Internet, nor should it put at risk the existing Internet systems. For example, IETF-developed routing protocols should be used for routing of L3 PPVPN traffic, without adding VPN-specific state to the Internet core routers. Similarly, well-known L2 technologies should be used in VPNs offering L2 services, without imposing risks to the Internet routers. A solution must be implementable without requiring to add additional funcionality to the P devices in a network, and minimal functionality to the PE in a PE-based VPN and CE in a CE-based VPN. In addition to commonality with generic Internet mechanisms, infrastructure mechanisms used in different PPVPN solutions (both L2 and L3), e.g., discovery, signaling, routing and management, should be as common as possible. 6.5. Interoperability Each technical solution is expected to be based on interoperable Internet standards. Multi-vendor interoperability at network element, network and service levels among different implementations of the same technical solution should be ensured (that will likely rely on the completeness of the corresponding standard). This is a central requirement for SPs and customers. The technical solution must be multi-vendor interoperable not only within the SP network infrastructure, but also with the customer's network equipment and services making usage of the PPVPN service. Customer access connections to a PPVPN solution may be different at different sites (e.g., Frame Relay on one site and Ethernet on another). Interconnection of a L2VPN over an L3VPN as if it were a customer [Page 18] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 site shall be supported. However, interworking of Layer 2 technologies is not required, and is outside the scope of the working group, and therefore, of this document. Inter-domain interoperability - It should be possible to deploy a PPVPN solution across domains, Autonomous Systems, or the Internet. 7. Security Considerations This document does not have any security considerations other than the security requirements described in Section 4.5. 8. References 8.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider Provisioned Virtual Private Networks", work in progress [L3FRAMEWORK] Callon, R., Suzuki, M., et al. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", work in progress [L2FRAMEWORK] Andersson, L., et al. "A Framework for Layer 2 Provider Provisioned Virtual Private Networks", work in progress 8.2. Informative References [L3REQTS] Carugi, M., McDysan, D. et al., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks", work in progress [L2REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks", work in progress [Y.1241] "IP Transfer Capability for the support of IP based Services", Y.1241 ITU-T Draft Recommendation, March 2000 [Y.1311] Knightson, K. (editor), "Network based IP VPN Service [Page 19] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 - Generic Framework and Service Requirements ", Y.1311 ITU-T Recommendation, May 2001 [RFC 3198] A. Westerinen et al, "Terminology for Policy-Based Management," November, 2001. [VPN SEC] J. De Clercq et al, "Considerations about possible security extensions to BGP/MPLS VPN," work in progress. [FRF.13] Frame Relay Forum, "Service Level Definitions Implementation Agreement," August, 1998. [Y.1541] "Network Performance Objectives for IP-based Services," Y.1541, ITU-T Recommendation. 9. Acknowledgements This work was done in consultation with the entire design team for PPVPN requirements. A lot of the text was adapted from the Layer 3 requirements document produced by Layer 3 requirements design team. The authors would also like to acknowledge the constructive feedback from Alex Zinin. 10. Editor's Address Ananth Nagarajan Sprint 6220 Sprint Parkway Overland Park, KS 66251 USA E-mail: ananth.nagarajan@mail.sprint.com [Page 20] Internet Draft draft-ietf-ppvpn-generic-reqts-01.txt Dec 2002 11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. [Page 21] --openmail-part-78b60330-00000001-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 20 11:47: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 LAA01860 for ; Fri, 20 Dec 2002 11:47:08 -0500 (EST) 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 gBKGnP118759 for ; Fri, 20 Dec 2002 11:49:25 -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 gBKGnMp20118 for ; Fri, 20 Dec 2002 11:49:23 -0500 (EST) Message-ID: From: "Marco Carugi" To: ppvpn@nortelnetworks.com Cc: "'ananth.nagarajan@mail.sprint.com'" , "Marco Carugi" Subject: WG Last Call on draft-ietf-ppvpn-generic-reqts-01.txt Date: Fri, 20 Dec 2002 17:48:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A847.501951FA" 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_01C2A847.501951FA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As anticipated by Ananth,=20 I'd like to start now a WG last call on this ID (to Info RFC) ending = Jan 10th. Happy holidays, Marco > -----Original Message----- > From: ananth.nagarajan@mail.sprint.com > [mailto:ananth.nagarajan@mail.sprint.com] > Sent: vendredi 20 d=E9cembre 2002 17:40 > To: ppvpn@nortelnetworks.com > Subject: ID submitted: draft-ietf-ppvpn-generic-reqts-01.txt >=20 >=20 > All, > The attached revised generic requirements document was submitted=20 > yesterday. It may take a while for it to get posted because of the=20 > holiday season. Please see and comment. This call for=20 > comments may be=20 > treated as a WG last call (Marco will follow up with that=20 > announcement). Major changes include fixing typos, and modifying=20 > Section 5.1 on scalability. >=20 > Thanks and happy holidays. > Ananth > =20 >=20 ------_=_NextPart_001_01C2A847.501951FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG Last Call on draft-ietf-ppvpn-generic-reqts-01.txt

As anticipated by Ananth,
I'd like to start now a WG last call on this ID (to = Info RFC) ending Jan 10th.

Happy holidays, Marco


> -----Original Message-----
> From: ananth.nagarajan@mail.sprint.com
> [mailto:ananth.nagarajan= @mail.sprint.com]
> Sent: vendredi 20 d=E9cembre 2002 17:40
> To: ppvpn@nortelnetworks.com
> Subject: ID submitted: = draft-ietf-ppvpn-generic-reqts-01.txt
>
>
> All,
> The attached revised generic requirements = document was submitted
> yesterday. It may take a while for it to get = posted because of the
> holiday season. Please see and comment.  = This call for
> comments may be
> treated as a WG last call (Marco will follow up = with that
> announcement).  Major changes include = fixing typos, and modifying
> Section 5.1 on scalability.
>
> Thanks and happy holidays.
> Ananth
> 
>

------_=_NextPart_001_01C2A847.501951FA-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Dec 20 12:08:54 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 MAA02283 for ; Fri, 20 Dec 2002 12:08:53 -0500 (EST) 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 gBKHBA116502 for ; Fri, 20 Dec 2002 12:11:11 -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 gBKHB8p22993 for ; Fri, 20 Dec 2002 12:11:08 -0500 (EST) Message-ID: From: "Marco Carugi" To: "'ppvpn@nortelnetworks.com'" Subject: ID-nits Date: Fri, 20 Dec 2002 18:10:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A84A.48BCED24" 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_01C2A84A.48BCED24 Content-Type: text/plain; charset="iso-8859-1" All, FYI (reminder from ADs to WG chairs and ID authors). **************************************************************************** ***** Remember that you need to read and understand http://www.ietf.org/ID-nits.html You also need to get your document authors to read and understand it. The editors should use this as a checklist *before* finishing their documents. You should use this as a checklist *before* sending us a ID for publication! thanks Scott & Bert ------_=_NextPart_001_01C2A84A.48BCED24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ID-nits

All,
FYI (reminder from ADs to WG chairs and ID = authors).

***************************************************************= ******************
Remember that you need to read and understand http://www.ietf.org/ID-nits.html

You also need to get your document authors to read = and understand it.

The editors should  use this as a checklist = *before* finishing their documents.

You should use this as a checklist *before* sending = us a ID for publication!

thanks

Scott & Bert
 

------_=_NextPart_001_01C2A84A.48BCED24-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Dec 22 06:47:20 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 GAA00403 for ; Sun, 22 Dec 2002 06:47:20 -0500 (EST) 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 gBMBnGN12757 for ; Sun, 22 Dec 2002 06:49:17 -0500 (EST) Received: from lyris.nortelnetworks.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 gBMBnE324091 for ; Sun, 22 Dec 2002 06:49:14 -0500 (EST) Message-Id: <200212221148.gBMBms709248@zcars0jk.ca.nortel.com> From: "Robert " Date: Sun, 22 Dec 2002 07:02:41 To: ppvpn@nortelnetworks.com Subject: New Information MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-SMTP-HELO: ecarsggg.nortelnetworks.com X-SMTP-MAIL-FROM: r@everythingwomenknowaboutmen.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: 48.17.171.66.subscriber.vzavenue.net [66.171.17.48] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit *** You are receiving this message based on an OPT-IN list. If you think this is an error, please reply with REMOVE in the subject line.*** Welcome to the most exciting discovery ever! Everything that women know about men is about to be released. Nobody has ever release this breakthrough information. If you are interested in finding out what women really know about men please copy and paste the link below in your browser in order to be taken to the new informational site. www.everythingwomenknowaboutmen.com Best wishes, Rob From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 23 01:42: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 BAA12897 for ; Mon, 23 Dec 2002 01:42:18 -0500 (EST) 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 gBN6iWP20197 for ; Mon, 23 Dec 2002 01:44:33 -0500 (EST) Received: from lyris.nortelnetworks.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 gBN6iTR17377 for ; Mon, 23 Dec 2002 01:44:29 -0500 (EST) X-OpenMail-Hops: 1 Date: Mon, 23 Dec 2002 08:43:33 +0200 Message-Id: Subject: Management VPNs MIME-Version: 1.0 From: marko.kulmala@tellabs.com TO: ppvpn@nortelnetworks.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 23 Dec 2002 08:43:33 +0200" X-Mirapoint-Sig: mx2.tellabs.fi X-SMTP-HELO: mx2.tellabs.fi X-SMTP-MAIL-FROM: marko.kulmala@tellabs.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mx2.tellabs.fi [193.65.253.35] X-LYRIS-Message-Id: Hello, Draft-ietf-ppvpn-rfc2547bis-03.txt describes how management VPNs are created. IP connectivity is such that Network management system can communicate with all CEs but CEs can not communicate with each other. My interpretation is that, in fact, the set of overlapping VPNs are created. In each VPN there is one CE router and Network management sytem. Is that correct way to think this or would it be better to think that there is only one VPN, where some members of VPN are not able to communicate at all ? Best Regards, Marko Kulmala ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 23 07:57:33 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 HAA28153 for ; Mon, 23 Dec 2002 07:57:33 -0500 (EST) 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 gBNCxUP19290 for ; Mon, 23 Dec 2002 07:59:30 -0500 (EST) Received: from lyris.nortelnetworks.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 gBNCxRR12339 for ; Mon, 23 Dec 2002 07:59:28 -0500 (EST) Message-Id: <200212231255.HAA27745@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-generic-reqts-01.txt Date: Mon, 23 Dec 2002 07:55:54 -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 : Generic Requirements for Provider Provisioned VPN Author(s) : A. Nagarajan Filename : draft-ietf-ppvpn-generic-reqts-01.txt Pages : 21 Date : 2002-12-20 This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-generic-reqts-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-generic-reqts-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ppvpn-generic-reqts-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-12-20130116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-generic-reqts-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-generic-reqts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130116.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Dec 23 09:26:53 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 JAA03474 for ; Mon, 23 Dec 2002 09:26:52 -0500 (EST) 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 gBNETHP27819 for ; Mon, 23 Dec 2002 09:29:17 -0500 (EST) Received: from lyris.nortelnetworks.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 gBNETFR00382 for ; Mon, 23 Dec 2002 09:29:15 -0500 (EST) From: ananth.nagarajan@mail.sprint.com X-OpenMail-Hops: 1 Date: Mon, 23 Dec 2002 08:28:38 -0600 Message-Id: Subject: FW: I-D ACTION:draft-ietf-ppvpn-generic-reqts-01.txt MIME-Version: 1.0 TO: ppvpn@nortelnetworks.com Content-Type: multipart/mixed; boundary="openmail-part-78d1f435-00000001" X-SMTP-HELO: kcmgwp01.corp.sprint.com X-SMTP-MAIL-FROM: ananth.nagarajan@mail.sprint.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: parker1.sprint.com [208.18.122.165] X-LYRIS-Message-Id: --openmail-part-78d1f435-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 23 Dec 2002 08:28:37 -0600" Content-Transfer-Encoding: 7bit fyi - the Generic Requirements draft is now available on the on-line repository. Ananth -----Original Message----- From: Internet-Drafts [mailto:Internet-Drafts@ietf.org] Sent: Monday, December 23, 2002 6:56 AM To: IETF-Announce: . Cc: ppvpn; Internet-Drafts Subject: I-D ACTION:draft-ietf-ppvpn-generic-reqts-01.txt 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 : Generic Requirements for Provider Provisioned VPN Author(s) : A. Nagarajan Filename : draft-ietf-ppvpn-generic-reqts-01.txt Pages : 21 Date : 2002-12-20 This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-generic-reqts-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-generic-reqts-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ppvpn-generic-reqts-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. --openmail-part-78d1f435-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="draft-ietf-ppvpn-generic-reqts-01.txt" ;Creation-Date="Mon, 23 Dec 2002 08:28:37 -0600" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-12-20130116.I-D@ietf.org> --openmail-part-78d1f435-00000001-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 24 08:34: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 IAA07216 for ; Tue, 24 Dec 2002 08:34:38 -0500 (EST) 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 gBODb2323886 for ; Tue, 24 Dec 2002 08:37:03 -0500 (EST) Received: from lyris.nortelnetworks.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 gBODaxs21145 for ; Tue, 24 Dec 2002 08:37:00 -0500 (EST) Date: Tue, 24 Dec 2002 08:36:30 -0500 (EST) Message-ID: From: ·P®¦¯¬ºÖ@zcars0jk.ca.nortel.com To: Ä@±æ¹ê²{ Cc: 1223-3N@zcars0jk.ca.nortel.com, 1223-4N@zcars0jk.ca.nortel.com Subject: =?big5?Q?=C4@=B1=E6=B9=EA=B2{?= MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_dF6dBoweI1yZQ8C" X-Mailer: 6euF7ja0IRXYhoyAWmED711 X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: wong X-SMTP-MAIL-FROM: chejen0329@sinamail.com X-SMTP-RCPT-TO: lyris@nortelnetworks.com,ppvpn@nortelnetworks.com,dfonarev@nortelnetworks.com X-SMTP-PEER-INFO: NK218-187-40-47.3-24.pl.apol.com.tw [218.187.40.47] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_dF6dBoweI1yZQ8C Content-Type: multipart/alternative; boundary="----=_NextPart_dF6dBoweI1yZQ8CAA" ------=_NextPart_dF6dBoweI1yZQ8CAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4wIj4NCjxtZXRhIG5hbWU9IlByb2dJZCIgY29udGVu dD0iRnJvbnRQYWdlLkVkaXRvci5Eb2N1bWVudCI+DQo8dGl0bGU+vdDFpafau6EmbmJzcDsmbmJz cDsgs1ynQabbpHakQK3Tpbyo0zwvdGl0bGU+DQo8L2hlYWQ+DQoNCjxib2R5Pg0KDQo8cD48Yj48 Zm9udCBjb2xvcj0iIzAwODAwMCIgZmFjZT0itdixZMTXstO2wiwgtdixZMTXssq26iIgc2l6ZT0i NiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KvdDFpafau6E8L2ZvbnQ+PGZvbnQgY29s b3I9IiM2NjMzY2MiPiZuYnNwOyA8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRjAwMDAiPiA8Zm9udCBm YWNlPSK12LFkxNey07bCIiBzaXplPSI1Ij6zXKdBptukdqRArdOlvKjTPC9mb250PjwvZm9udD48 L2I+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iNCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0Kt+2n2q3MqrqlQKzJpb+lSKSjpWmr5MSzqrqzdKvXp+/F3K7JoUa37afa rcyorcPkqrqoxqqrrPC1TaSjpkG89LF4PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjQiPq7J oUa37afarcytsbnvpbyo06FBpXWz0a/ttU2qurVMqr6uyaFGqK2ssLT5pHC1TKdVqrqlq6SrpHCl wa3MoUG406ZwpvM8L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iNCI+vdW+46bbpHahQa2rt3O+ QcCztN27xbVMsaGqurdzqsC3fKFIPC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCqr4tMGpfrCqpKOkVaq6paK3frJ2oUHF /TwvZm9udD48YSBocmVmPSJodHRwOi8vd3d3LmVhZ2xlLWZseS5pZHYudHcvbW9ycmlzLnBocCIg dGFyZ2V0PSJfYmxhbmsiPjxmb250IHNpemU9IjUiIGNvbG9yPSIjMDAwMEZGIj48Yj6hdbW5p9qk QKX3pHWnQKFJoXY8L2I+PC9mb250PjwvYT48Zm9udCBzaXplPSI0Ij6mqKyws1ymaKWit36qzKq6 pkCmUKTfwW48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iNCI+oUGm/ahzs7q91qazr+CkT7Sj qNGnQaR1p0C+97d8qU+hSKxPrEapsqFIrE+l+Ld+oUjB2axPp0Gm26R2oUg8L2ZvbnQ+PC9wPg0K PHA+PGZvbnQgc2l6ZT0iNCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K rbG577xAxdykpKq6pUCsyaFBpKO9VKl3qrqlvKjToUGkV69asdqtzLCjpEapVKZ1reyms6q6sU23 frvisOyhQa5JPC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjQiPq26ttS+xLt7r3WmYaR1p0Cl fqFBrE+nX6RduNO+Qa7JpmGp77BfwFmo06FBrN2s3aV+rMmqusXcpMahQbdRt1GkraZ+oUI8L2Zv bnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iNCI+pFGmfqzGqc6kR6RRoUKkVKRRpn6r4aq6p0GhQbjT uUy126Swu/K8y6q6pc2soaFIPC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9IjQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCqdBqrqlvKjToUGldaazp0Gm26R2r+Cz0LN5 oUGldaazptukdrPMqfql1aFBpl2muaFBu1Co5LWlq92nT6RIrEmxyzwvZm9udD48L3A+DQo8cD48 Zm9udCBzaXplPSI0Ij6kQKX3pHWnQKFBpKOmcKbbpHazXaprp+ym7a7JpU6qurzprHmhQbFqpMan Qaq6pHWnQKfer+ChQbPQs3mlWMTdqfM8L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgY29sb3I9IiMwMDAw RkYiPjxiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZWFnbGUtZmx5Lmlkdi50dy9tb3JyaXMucGhwIiB0 YXJnZXQ9Il9ibGFuayI+PGZvbnQgc2l6ZT0iNSI+ptukdqq6pbyo0zwvZm9udD48Zm9udCBzaXpl PSI0Ij6hQzwvZm9udD48L2E+PC9iPjwvZm9udD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+ PGJyPg0KPGZvbnQgc2l6ZT0iNCI+pnCqR7F6qrqqQqTNpF2ms6ZQvMuqurdRqmsspF2nxrHmsXqx Tqa5sFSup8LgsUinaaq+Li7BwsHCISE8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwPqFAPC9wPg0KPHA+ oUA8L3A+DQoNCjwvYm9keT4NCg0KPC9odG1sPg== ------=_NextPart_dF6dBoweI1yZQ8CAA-- ------=_NextPart_dF6dBoweI1yZQ8C-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Dec 31 13:52: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 NAA27431 for ; Tue, 31 Dec 2002 13:52:39 -0500 (EST) 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 gBVIt1a09818 for ; Tue, 31 Dec 2002 13:55:02 -0500 (EST) Received: from lyris.nortelnetworks.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 gBVIsxQ00215 for ; Tue, 31 Dec 2002 13:54:59 -0500 (EST) From: To: "ppvpn" Subject: =?iso-8859-1?Q?call_china_6.2=A2_www.callez.com?= Date: Tue, 31 Dec 2002 13:50:17 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_46DCC_01C2B0D3.8D621A80" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 31 Dec 2002 18:50:18.0015 (UTC) FILETIME=[76715AF0:01C2B0FD] X-SMTP-HELO: webserver X-SMTP-MAIL-FROM: promotion@callez.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: 216-211-196-130.noviant.com [216.211.196.130] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_46DCC_01C2B0D3.8D621A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ------=_NextPart_000_46DCC_01C2B0D3.8D621A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
------=_NextPart_000_46DCC_01C2B0D3.8D621A80--