From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 1 11:13:47 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 LAA19803 for ; Fri, 1 Nov 2002 11:13:46 -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 gA1GFaX26444 for ; Fri, 1 Nov 2002 11:15: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 gA1GFXU19127 for ; Fri, 1 Nov 2002 11:15:33 -0500 (EST) Message-Id: <200211011610.gA1GAlPP012211@sj-msg-core-1.cisco.com> To: "Marco Carugi" cc: ppvpn@nortelnetworks.com, "'Muneyoshi Suzuki'" , "'kuwahara.takeshi@lab.ntt.co.jp'" Subject: Re: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt In-reply-to: Your message of Thu, 31 Oct 2002 04:27:30 +0100. 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: Fri, 01 Nov 2002 11:10:47 -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@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: I don't remember the discussion which concluded that this should be a WG document. But anyway ... The draft really contains two separate and unrelated ideas. The first idea is a proposal for tunneling L3VPN packets through a backbone. The second idea is a proposal for creating and purging "cut-through" routes (i.e., routes between spokes) in a hub-and-spoke VPN. Let's look at these separately. The tunneling proposal is the following: - Each VFI has its own, unique IPv6 address, different from the address of its PE, and different from the address of any other VFI in the same or in a different VPN. - At an ingress PE, a VFI must map a VPN packet's IP destination address to the IPv6 address of an egress VFI. - The VPN packet is then tunneled across the backbone by being encapsulated in IPv6, according to RFC 2473 ("Generic Packet Tunneling in IPv6"), which is basically just an "anything inside IPv6" encapsulation. The meat of the proposal is that the IPv6 destination address field must be set to the address of the egress VFI. Thus, no other demux field is needed. Is this a useful technique in the context of L3VPN? I have a few comments: - The proposal seems to be restricted to backbones that support IPv6. This limits its utility rather severely. (Well, one could use a 6-in-4 encapsulation around the RFC 2473 encapsulation, but that seems kind of silly.) - The proposal requires that the ingress VFI map a VPN IP destination address to an IPv6 address which uniquely identifies a VFI. It then assumes that somehow each PE belonging to a particular VPN knows the IPv6 addresses of all the remote VFIs in that VPN. It's not worth considering the case in which every VFI in every PE is provisioned with the v6 addresses of every remote VFI in the same VPN; that would subvert the manageability/scalability claims that are being made. So we must suppose that there is some sort of discovery scheme which passes around the v6 addresses dynamically. Given this sort of discovery scheme, my observation is that it could just as easily pass, for each VFI, the IP address of a PE, along with a 32-bit (or 20-bit) label value that selects a particular VFI in that PE. This could then be carried as part of a GRE encaps (or as part of an MPLS-in- IP-or-GRE encaps). Then we would have an encapsulation which works equally well on v4 and v6 backbones, is much more efficient on v4 backbones (if somewhat less efficient on v6 backbones), and is more scalable from the manageability perspective, as it doesn't require the provisioning of v6 addresses for the VFIs. I think the authors need to make a case as to why using a v6 address to identify a VFI is better than any of the existing schemes. - The proposed encaps doesn't seem applicable to the 2547 style of VPN, as that distributes PE IP addresses and MPLS labels, rather than VRF addresses. Of course, one could imagine extending 2547 to pass the v6 addresses, but it's hard to see the advantage of doing so. I don't know whether the proposed encaps has any particular advantages for the VR style of VPN, it might be nice to hear from the proponents of VR. So I just don't see why the proposed encapsulation is a good idea. Unless it gets integrated into one of the L3VPN schemes, I don't see how it could advance to proposed standard. I don't see much point in advancing it to informational either, unless it already has significant deployment. There's an unlimited number of possible encapsulations, and I don't think we want an RFC to describe each one. Now let's look at the "cut-through" proposal. This is apparently meant to apply only in a "hub and spoke" topology. At the spokes, the VFI has three kinds of routes: - a default route pointing to the hub VFI, - routes to the locally attached site, - "cut-through routes", i.e., routes pointing to other spokes. The cut-through routes are installed and removed dynamically by means of the "Connectionless Tunneling Control Protocol" (CTCP). The hub VFI does not contain cut-through routes, but it must contain routes to all the sites attached via all the spokes. The CTCP procedures are the following: - If a hub H receives a packet with destination address D, from ingress PE S, and if H's route for D goes through another PE, R, then: * H forwards the packet to R, and * If S is a spoke, H sends a CTCP message (redirect) to S, telling it "your route to D is via R". H then forgets all about it. * When S receives such a CTCP message, it installs the new route to R. Thereafter, S sends packets to D via R instead of via H - If a spoke R receives a packet with destination address D, from ingress PE S, and if R's route for D goes through another PE, then: * R drops the packet, and * If S is a spoke, R sends a CTCP message (purge) to S, telling it "your route to D is not via R". (This is black hole prevention.) * When S receives such a CTCP message, is removes the route to D via R. The draft doesn't really discuss what happens if there are multiple hubs, though I assume that the hubs don't want to send CTCP messages to each other. The draft seems to assume that each PE knows (for each VFI) whether it is a hub or a spoke; presumably this is a matter of configuration. But to avoid situations in which hubs send CTCP to each other, each hub must know of all the other hubs. The spokes also have to know of the hubs, so as not to send purge messages to hubs. (At least, I assume that the spokes don't want to be bombarding the hubs with useless purge messages.) I imagine that hubs are supposed to ignore any received purge or redirect messages, though the draft doesn't seem to mention that explicitly. It's very difficult to know what topologies are supposed to be ruled out, how those rules are to be enforced, and what happens if through misconfiguration an "unsupported topology" is created. The strict hub and spoke hierarchy seems to be the only thing that protects against long-standing loops, so it's important to understand whether this is restriction is acceptable and enforceable. For example, requiring that there only be a single hub is obviously not acceptable, due to the single point of failure issues. Even ignoring these issues, there are some problems. One problem is that the hub doesn't seem to remember that it has sent a redirect to a spoke. So suppose that S1 and S2 are spokes attached to the same site, but S1's route is, at some time, the preferable one. The hub may now redirect some third spoke S3, so that packets from S3 for the site in question go directly via S1. Then let us suppose that routing changes so that S2's route to the site is now the preferable one. S3's packets will continue going via S1, as long as S1 has a direct route to the site. There doesn't seem to be any way to get S3 back on the optimal route, ever. (I am assuming here that one does not want to relegate multiply homed sites to the case of an unsupported topology.) I think there needs to be a rule that cut-through routes must not be distributed into the site via the site's IGP, i.e., that the CE routers must only default-route to the spokes. Otherwise I think loops may be possible. Another problem: any procedure in which control messages are sent as a response to the reception of data messages is somewhat suspect; throttling of the control messages becomes a necessity, though this isn't mentioned in the draft. (Perhaps this is regarded as an implementation matter.) Another problem is that the redirect and purge messages are unreliable and unsequenced. Purge messages may fail to get through in any sort of timely manner, and the result may be black holes that last for quite awhile. Purge messages which arrive late may already be obsolete, undoing the effect of redirect messages which were sent later but arrived earlier. Redirect messages which arrive late may already be obsolete, undoing the effect of purge messages which were sent later but arrived earlier. If a spoke loses a route, there will be a lag time during which the hub hasn't recomputed routes yet; during this time, there may be a "war" during which the hub constantly emits redirects for the lost route, and the spoke constantly emits purges. With no sequencing, some of these messages may get processed after the hub recomputes the routes, and this may greatly increase the effective routing convergence time. The use of a connectionless control plane is also suspect from a security perspective. There needs to at least be some optional method for authenticating and ensuring the integrity of the CTCP messages. When the control plane sets up connections, one can talk about using IPsec, TLS, etc., but when each control packet is a datagram, I'm not sure I understand how the security would be done. The "security considerations" section is only one sentence long; no one has ever let me get away with writing such a short security considerations section ;-) It would be interesting to hear from proponents of the VR model as to whether they see any need for cut-through routes. If they do, then perhaps there might be some merit in having the WG look into these issues more closely. Right now I think there's no question of CTCP going forward as a proposed standard. I don't see how that could happen unless CTCP were integrated into the VR model in some way. With regard to its going forward as an informational RFC, I don't really see why it should. Setting up cut-through routes is not exactly a new idea (cf. NHRP, especially the infamous router-to-router NHRP), and this particular solution seems to have a number of unresolved issues. Unless there is already widespread deployment of CTCP, I don't see what the interest is. From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 1 12:25:56 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23965 for ; Fri, 1 Nov 2002 12:25: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 gA1HRQX12507 for ; Fri, 1 Nov 2002 12:27: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 gA1HRNU14374 for ; Fri, 1 Nov 2002 12:27:23 -0500 (EST) Message-ID: From: "Schliesser, Benson" To: "'erosen@cisco.com'" , "Marco Carugi" Cc: ppvpn@nortelnetworks.com, "'Muneyoshi Suzuki'" , "'kuwahara.takeshi@lab.ntt.co.jp'" Subject: RE: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Date: Fri, 1 Nov 2002 11:25:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-ECS-MailScanner: No virus is found X-SMTP-HELO: mailgate1a.savvis.net X-SMTP-MAIL-FROM: Benson.Schliesser@savvis.net X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailgate1a.savvis.net [216.91.182.5] X-LYRIS-Message-Id: > I don't remember the discussion which concluded that this > should be a WG document. But anyway ... I'm glad you said that, Eric, because I was thinking the same thing. > Right now I think there's no question of CTCP going forward > as a proposed standard. I don't see how that could happen > unless CTCP were integrated into the VR model in some way. While 4-in-6 tunneling is a concept that could be applied to the VR model, I'd suggest that the CTCP model is naturally exclusive of the VR model just as it is the BGP/MPLS model. It supplants the route distribution mechanism of both models with a new one. > With regard to its going forward as an informational RFC, > I don't really see why it should. [...] and this particular > solution seems to have a number of unresolved issues. Unless > there is already widespread deployment of CTCP, I don't see > what the interest is. I have to agree with Eric's comments (including those not quoted here) on this draft. While it's possible that this model will actually work, I don't see how it's a better alternative to any of the existing models. In fact, as Eric points out, there are a great many concerns with the model. If it had some hope of becoming a stronger solution than what exists today I would suggest that we work through these concerns and help it mature. But I tend towards thinking that would be wasted energy. This draft is interesting for discussion, but not useful for standardization. And if it's not employed by more than a single provider then I see no reason to bother documenting it in a public forum. -Benson From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 1 14:43:31 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 OAA00811 for ; Fri, 1 Nov 2002 14:43: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 gA1JikX04125 for ; Fri, 1 Nov 2002 14:44:47 -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 gA1JihU02479 for ; Fri, 1 Nov 2002 14:44:44 -0500 (EST) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D63226E2@trimail2> From: "Chen, Weijing" To: "'erosen@cisco.com'" , "Marco Carugi" Cc: ppvpn@nortelnetworks.com, "'Muneyoshi Suzuki'" , "'kuwahara.takeshi@lab.ntt.co.jp'" Subject: RE: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Date: Fri, 1 Nov 2002 13:35:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: wchen@tri.sbc.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: The other problem with this draft is that it is unknown how the proposal handles the Internet access from VPN and inter-VPN access. Nonetheless, the scaleable and manageable operation issues of current VPN brought by this draft are still a valid and major concern among service providers. Witness the draft http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt, it raises the same concern. The solution proposed by the late draft may have some same disadvantages layout by Eric's email, such as rely on IPv6 as core network, encapsulation in IPv6, etc. Although IPv6 was chosen for the solution, it doesn't prevent the solution from expansion into IPv4. But from the ongoing industry and market trend, it seems too late to do anything other than MPLS VPN in IPv4 space. Once again, we operation group in service provider has very serious concern about scaleable manageability of MPLS/VPN. We may have to swallow the pill now. But we still hope that the manageability is not side stepped. Regards, -- Weijing Chen From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 2 05:41:49 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 FAA01719 for ; Sat, 2 Nov 2002 05:41:49 -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 gA2AhTP27376 for ; Sat, 2 Nov 2002 05:43:30 -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 gA2AhRK03508 for ; Sat, 2 Nov 2002 05:43:27 -0500 (EST) Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03A3C@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Eric Rosen '" , "Marco Carugi" Cc: "'ppvpn@nortelnetworks.com '" , "''Muneyoshi Suzuki' '" , "''kuwahara.takeshi@lab.ntt.co.jp' '" Subject: RE: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Date: Sat, 2 Nov 2002 02:42:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: mother.pmc-sierra.bc.ca X-SMTP-MAIL-FROM: Shahram_Davari@pmc-sierra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mother.pmc-sierra.bc.ca [216.241.224.12] X-LYRIS-Message-Id: - The proposal seems to be restricted to backbones that support IPv6. This limits its utility rather severely. (Well, one could use a 6-in-4 encapsulation around the RFC 2473 encapsulation, but that seems kind of silly.) SD => Any proposal has a scope. The scope of this proposal is IPV6 networks. Having a scope should not prevent a draft from being advanced in IETF. - The proposal requires that the ingress VFI map a VPN IP destination address to an IPv6 address which uniquely identifies a VFI. It then assumes that somehow each PE belonging to a particular VPN knows the IPv6 addresses of all the remote VFIs in that VPN. It's not worth considering the case in which every VFI in every PE is provisioned with the v6 addresses of every remote VFI in the same VPN; that would subvert the manageability/scalability claims that are being made. SD=> The scalability is no worst than 2547, which requires that every every PE belonging to a VPN should know the IPV4 address of all other PEs connected to the same VPN and the MPLS label for each of the VFIs. So we must suppose that there is some sort of discovery scheme which passes around the v6 addresses dynamically. Given this sort of discovery scheme, my observation is that it could just as easily pass, for each VFI, the IP address of a PE, along with a 32-bit (or 20-bit) label value that selects a particular VFI in that PE. This could then be carried as part of a GRE encaps (or as part of an MPLS-in- IP-or-GRE encaps). SD=> I am glad that you brought this up. But my recall is that last time(when I proposed to use IP tunneling for PPVPN) you said it is stupid to tunnel MPLS through IP, because MPLS networks push/pop labels and having IP in some of the tunneling levels makes it very complicated. I think the authors need to make a case as to why using a v6 address to identify a VFI is better than any of the existing schemes. SD=> Because it is much simpler and more efficient in IPV6 networks. Why should you use an extra MPLS label and do an extra lookup in IPV6 networks, when it is not necessary. Besides it wont have the problems that you have mentioned before regarding mixing up IP and MPLS tunnels. -Shahram From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 2 17:59:25 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14186 for ; Sat, 2 Nov 2002 17:59:25 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA2N19P12629 for ; Sat, 2 Nov 2002 18:01: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 gA2N16K09978 for ; Sat, 2 Nov 2002 18:01:06 -0500 (EST) Message-Id: <200211022300.gA2N0Cm40826@merlot.juniper.net> To: "Chen, Weijing" cc: "'erosen@cisco.com'" , "Marco Carugi" , ppvpn@nortelnetworks.com, "'Muneyoshi Suzuki'" , "'kuwahara.takeshi@lab.ntt.co.jp'" Subject: Re: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt In-Reply-To: Your message of "Fri, 01 Nov 2002 13:35:46 CST." <905A1C4ABF353F4C8CC16FA9F53DD0D63226E2@trimail2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16204.1036278012.1@juniper.net> Date: Sat, 02 Nov 2002 15:00:12 -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: Weijing, > The other problem with this draft is that it is unknown how the proposal > handles the Internet access from VPN and inter-VPN access. > > Nonetheless, the scaleable and manageable operation issues of current VPN > brought by this draft are still a valid and major concern among service > providers. Witness the draft > http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt, it raises > the same concern. The solution proposed by the late draft may have some > same disadvantages layout by Eric's email, such as rely on IPv6 as core > network, encapsulation in IPv6, etc. Although IPv6 was chosen for the > solution, it doesn't prevent the solution from expansion into IPv4. But > from the ongoing industry and market trend, it seems too late to do anything > other than MPLS VPN in IPv4 space. > > Once again, we operation group in service provider has very serious concern > about scaleable manageability of MPLS/VPN. Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN". Also, when you said "we operation group in service provider", do you mean a specific service provider ? Yakov. From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 4 11:09: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 LAA19894 for ; Mon, 4 Nov 2002 11:09:50 -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 gA4GBge03873 for ; Mon, 4 Nov 2002 11:11:42 -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 gA4GBch21028 for ; Mon, 4 Nov 2002 11:11:39 -0500 (EST) Message-Id: <200211041606.gA4G6LPP029749@sj-msg-core-1.cisco.com> To: Shahram Davari cc: "Marco Carugi" , "'ppvpn@nortelnetworks.com '" , "''Muneyoshi Suzuki' '" , "''kuwahara.takeshi@lab.ntt.co.jp' '" Subject: Re: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt In-reply-to: Your message of Sat, 02 Nov 2002 02:42:37 -0800. <4B6D09F3B826D411A67300D0B706EFDEB03A3C@nt-exch-yow.pmc-sierra.bc.ca> 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: Mon, 04 Nov 2002 11:06:21 -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@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: Shahram> Any proposal has a scope. The scope of this proposal is IPV6 Shahram> networks. Having a scope should not prevent a draft from being Shahram> advanced in IETF. Well, I don't think I said that the draft should be rejected because it has a scope. However, a proposal with a small scope would generally be considered to be at a disadvantage when compared to a proposal with larger scope, other things being equal of course. Eric> Given this sort of discovery scheme, my observation is that it could Eric> just as easily pass, for each VFI, the IP address of a PE, along with Eric> a 32-bit (or 20-bit) label value that selects a particular VFI in that Eric> PE. This could then be carried as part of a GRE encaps (or as part of Eric> an MPLS-in-IP-or-GRE encaps). Shahram> But my recall is that last time(when I proposed to use IP tunneling Shahram> for PPVPN) you said it is stupid to tunnel MPLS through IP, because Shahram> MPLS networks push/pop labels and having IP in some of the Shahram> tunneling levels makes it very complicated. Yes, I do think it gets very complicated if you have IP tunnels nested in MPLS tunnels nested in IP tunnels, nested in MPLS tunnels, etc. I definitely think it is best to use MPLS tunnels if it is at all feasible. However, in the context of the draft being discussed, only IP tunnels are being used, so that point is irrelevant. The issue at hand is how best to determine what to do with a particular IP packet once it reaches the tunnel endpoint. This is most commonly done with a demux field rather than by inferring it from the IP destination address. I simply pointed out that by using a dynamically assigned demux field, you could increase the scope of the proposal, as well as reduce the management burden (and hence improve the scalability). And if you are trying to integrate with a VPN scheme which already distributes MPLS labels as the demux field, then it is advantageous to be able to continue to use them. Your point to the contrary is that if you use a unique IP destination address for each tunnel, there is no need at the egress to look up a separate demux field. In effect, the high order portion of the address identifies the egress PE uniquely, and the low order portion identifies a VFI relative to a PE. This suggests to me that the low order portion should be dynamically assigned rather than provisioned. Then, if a particular PE was the endpoint of some IPv4 tunnels and some IPv6 tunnels, it could even use the same demux value for both kinds of tunnels, though the IPv4 and the IPv6 encaps would carry the demux value in different places. A proposal of that sort might be worth considering. However, if one assumes that a given PE might have to terminate both v4 and v6 tunnels, I'm not sure whether having different encapsulation procedures for each kind of tunnel (label-after-IP-header for v4, label-in-IP-address for v6) works out to be more or less efficient than having a single kind of encapsulation (label-after-IP-header) for both IP protocols. Certainly it makes the control procedures more complicated. From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 4 19:17:02 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 TAA15864 for ; Mon, 4 Nov 2002 19:17:02 -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 gA50Ipe00261 for ; Mon, 4 Nov 2002 19:18: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 gA50Inh20455 for ; Mon, 4 Nov 2002 19:18:49 -0500 (EST) Message-Id: <200211050018.JAA66735@infer.nal.ecl.net> To: ppvpn@nortelnetworks.com Subject: Bridging network or networked bridges Date: Tue, 05 Nov 2002 09:18:18 +0900 From: Muneyoshi Suzuki X-SMTP-HELO: infer.nal.ecl.net X-SMTP-MAIL-FROM: suzuki@nal.ecl.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: infer.nal.ecl.net [163.138.70.32] X-LYRIS-Message-Id: Since beginning of the last month, several discussions about VPLS were held on the PPVPN WG generic requirements, L2VPN, and discovery design teams mailing lists as well as personal communications. The teams understand that there are many issues to be solved, and feel that the issues should be discussed in the public. So, the teams don't reach any consensus and don't decide anything yet. For further discussion, this memo summarize and sort out issues rose on the lists. Note that some of issues addressed in this mail may be beyond the scope of the IETF, but may belong to the IEEE 802 committee. So, discussions from technical as well as administrative viewpoint for possible directions are expected. Thanks, Muneyoshi Suzuki --- 1. Reference Bridge is defined in IEEE 802.1D-1998, 802.1t-2001 (amendment to 802.1D), and 802.1w-2001 (RSTP extension). 802.1D and 802.1t specify Bridge architecture, MAC frame relay operation, Bridge protocols (such as STP, GARP, and GMRP), and management protocol. And 802.1w specifies RSTP. Note that the 802.1 WG is now discussing 802.1y (corrections to 802.1D, 802.1t and 802.1w). In this process, STP may be officially obsoleted and replaced by RSTP. Note that Bridge implementation of many products in the market is still based on 802.1D-1993 or earlier specification. Also note that there are many cheap Bridge products that only support MAC frame relay operation and don't implement Bridge and management protocols. If a user install this type product, loop free deployment is the user responsibility. VLAN is defined in IEEE 802.1Q-1998, 802.1u-2001 (corrections to 802.1Q), 802.1v-2001 (protocol/port-based VLAN extension). 802.1Q, 802.1u, and 802.1v define extension of Bridge defined in 802.1D-1998. It specify extended Bridge architecture, VLAN tagging and MAC frame relay operation based on VLAN tag, and GVRP. Note that the VLAN defined in the IEEE 802.1 is NOT the technology that emulates multiple logical LANs over a single physical LAN. Note that the 802.1 WG is now discussing 802.1s (MSTP extension), and some VLAN-aware Bridge products support per-VLAN based STP, which is proprietary protocol. Also note that some VLAN-aware Bridge products in the market support the stacked VLAN mechanism which is intended used by SPs, enables transparent forwarding of customer VLAN tag in the SP network, but is not yet standardized. 2. Terminology used in this memo 1982-style Bridge: A Bridge that supports only MAC frame relay operation, and the operation is based current or earlier 802.1D specification. 1998-style Bridge: A Bridge that conforms to IEEE 802.1D-1998 and 802.1t- 2001. It may support RSTP defined IEEE 802.1w-2001, but does not support VLAN capability defined in IEEE 802.1Q-1998. VLAN-aware Bridge: A Bridge that conforms to IEEE 802.1D-1998, 802.1t-2001, 802.1Q-1998, 802.1u-2001, and 802.1v-2001. It may support RSTP defined IEEE 802.1w-2001 or MSTP may be defined as IEEE 802.1s. Bridge: 1982-style, 1998-style, or VLAN-aware Bridge. Bridged LAN: A concatenation of individual LANs interconnected by Bridges. LAN: LAN technology that provides the MAC service and is defined in a series of IEEE 802 LAN standards such as IEEE 802.3 Ethernet LAN. Note that "LAN segment" means the medium connection, e.g., 1000BASE-T, between Medium Dependent Interfaces in a LAN. The use of this terminology may be inappropriate in the VPLS context, because it is not intended to provide medium dependent service. 3. Customer View VPLS service is enabled by a logical Bridged LAN, which consists of physical or emulated LANs and Bridges. This Bridged LAN provides independent VPLS service instances per customer. From the viewpoint of VPLS service customers, a service instance emulated by VSIs in PEs for a customer is equivalent to: o A LAN o A single Bridge, that is: - A 1982-style Bridge - A 1998-style Bridge - A VLAN-aware Bridge o A Bridged LAN composed by: - 1982-style Bridges (loop free topology must be ensured) - 1998-style Bridges - VLAN-aware Bridges - Bridges Question: Expected scenario from customer's perspective. Note that if a customer interconnects customer's VLAN-aware Bridges through a VPLS service instance, it may have to be equivalent to a LAN, a VLAN-aware Bridge, or a Bridged LAN composed by VLAN-aware Bridges. One of issues at here is what should be emulated by a VSI in a PE or VSIs for a VPLS customer. A single LAN or a single Bridge may be emulated by VSIs in PEs belonging to an SP network. Also, a single VSI in a PE may emulate a single Bridge (remote-Bridge) and emulated Bridges may be interconnected by Ethernet pseudo wires. The other issue is how the service instance handles the Bridge protocols such as STP/RSTP/MSTP and GARP/GMRP/GVRP transfered through BPDUs, as well as, LCAP and MAC control protocol for PAUSE operation received from/sent to the customer site. MAC frames used by these protocols are sent to multicast addresses. Emulated 1998-style and VLAN-aware Bridges must terminate most of these frames, then appropriate action based on the standard must be executed. On the other hand, emulated LAN and 1982-style Bridge must transparently forward most of these frames. This may decrease load in PEs. Note that emulated LAN, that learns customer's MAC addresses, and 1982-style Bridge must transparently forward customer STP/RSTP/MSTP BPDU frame, because these don't join the spanning tree. However, when a customer network topology is changed, the MAC address cache in VSIs for the customer should be flushed to reduce the time for topology change. So, a STP/RSTP/MSTP snooping mechanism may be required for these implementation. 4. SPs Requirements VPLS service providers must identify order of the maximum number of the customers (e.g., # of service instances, CEs, etc) to be supported. SPs may restrict maximum number of the MAC addresses supported by a single VPLS service (or a single customer site). Question: Order of the maximum number of the customers assumed by SPs. Thousands, tens of thousands, hundreds of thousands, or millions..... And, the maximum number of the MAC addresses supported by a single VPLS service. Tens, hundreds, thousands, or tens of thousands...... Note that theses values may strongly impact on MAC forwarding table size in the VPLS. 5. Implementation Model VPLS service is enabled by a logical Bridged LAN, which consists of physical or emulated LANs and Bridges. This Bridged LAN provides independent VPLS service instances per customer. A portion of the Bridged LAN is emulated by VSIs interconnected by Ethernet pseudo wires. 5.1 Support of VPLS Service Port-based VLAN (defined in Annex D of IEEE 802.1D, 802.1u and 802.1v) enables per-customer based VLAN support, if a port corresponds to a single customer. Thus, VLAN-aware Bridges can be used for the support of VPLS service in the Bridged LAN. However, the current VLAN standard support only 4094 VLANs in the Bridged LAN. Also it does not emulate a VLAN-aware Bridge for a customer, so the customer network cannot use the VLAN. These may be unacceptable restrictions for VPLS service providers and customers. Therefore, development of new layer 2 technology that supports SP class VLAN service is indispensable. Note that the technology to be developed may be independent from layer 3 technology such as IP and MPLS. Stacked-VLAN aware Bridge, described in section 1, is one of candidates for solution. Encapsulation Bridge which support MAC-in-MAC encapsulation is the other candidate. Stacked-VLAN aware Bridge may have to learn customer MAC addresses, while MAC-in-MAC may not have to learn these, so the latter may be able to reduce MAC address table size. Note that there is a possibility that the same MAC addresses are assigned to different Ethernet interfaces. VRRP assigns the same virtual MAC addresses to different interfaces. Per-VLAN based STP, described in section 1, also use a similar scheme. Thus, if a customer uses VLANs in the customer network, and if the same MAC addresses appear in different customer VLANs, current Stacked-VLAN aware Bridge implementation may not distinguish these MAC addresses, because it does not care customer VLAN identifiers. 5.2 LAN/Bridge Emulation PWE3 WG is discussing point-to-point Ethernet pseudo wire, which is described in the following drafts. draft-ietf-pwe3-control-protocol-00.txt draft-ietf-pwe3-ethernet-encap-00.txt PPVPN WG will use this pseudo wire as an emulation technology in the logical Bridged LAN that provide VPLS service. A part of the Bridged LAN is emulated by VSIs interconnected by Ethernet pseudo wires. That is equivalent to: o A LAN o A single Bridge o A Bridged LAN (or something like these) The emulated part must ensure loop free MAC frame forwarding, however the use of STP may be inappropriate in WAN environment. Therefore, the WG is discussing topology restriction of pseudo wires that interconnect VSIs. One of solutions is tree structure topology, here a VSI is a node and a pseudo wire is a link, however details of this approach are not proposed yet. Another solution is full mesh topology with split-horizon forwarding scheme proposed in draft-lasserre-vkompella-ppvpn-vpls-02.txt. The split-horizon forwarding scheme enables loop free MAC frame forwarding. A VSI forwards a MAC frame received from a customer to others VSIs, but it never forward a frame received from a VSI to another VSI. It also learns MAC addresses received from the customer network. Obviously, in this scheme, a VSI doesn't emulate a remote-Bridge defined in IEEE 802.1G. Thus, one of issues at here is what is emulated by full mesh topology with split-horizon forwarding scheme. o It is an emulated LAN, because it transparently forwards MAC frames. o It is an emulated Bridge, because it terminates MAC layer, then forwards MAC frames to another interface, so it can interconnect different Ethernet mediums, furthermore, it learns MAC addresses for forwarding. Note that if it is an emulated Bridge, at least, it may have to be a VLAN- aware Bridge for support of VPLS service in the Bridged LAN. The other issue is scalability. Obviously, full mesh topology is not scale, if number of VSIs is increased. Support of broadcast and multicast is also problematic, because it wastes bandwidth in the SP network and increases jitter of MAC frame forwarding. 5.3 Routing for LAN/Bridge Emulation Topology restriction described in the previous section may not be acceptable for SPs, because SPs can not deploy PEs freely and full mesh topology may not scale. However, if a VSI emulates a remote Bridge, currently only STP/RSTP can be used for routing. RSTP much improved recovery time, however, we need more experiments of the use of RSTP in WAN environments. The final issue is, if RSTP works in WAN environments, it only blocks links and constructs a tree or hierarchical tree topologies. It may not efficiently use link bandwidth. So, minimum OSPF or BGP-4 extension for MAC routing support may be required. From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 5 03:48: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 DAA07884 for ; Tue, 5 Nov 2002 03:48: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 gA58ngi05170 for ; Tue, 5 Nov 2002 03:49: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 gA58ned14221 for ; Tue, 5 Nov 2002 03:49:40 -0500 (EST) Message-ID: <3DC785EE.5000706@cisco.com> Date: Tue, 05 Nov 2002 00:48:46 -0800 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cheng-Yin.Lee@alcatel.com CC: stbryant@cisco.com, danny@tcb.net, pwe3@ietf.org, ppvpn@nortelnetworks.com Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00 References: <200211011519.gA1FJY601724@tcb.net> <3DC2D23D.FFF906F4@alcatel.com> <3DC2DC33.5000807@cisco.com> <3DC2DF8C.5F0033E@alcatel.com> <3DC2EBA8.9020006@cisco.com> <3DC2F00E.AA52A419@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: townsley@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit cc'ing ppvpn Cheng-Yin Lee wrote: > Stewart, > Just some quick points: > As I see it, a bridge emulates an Ethernet wire, a PPVPL would then be an application of this > ethernet pseudo wire service, and would have additional requirements e.g. VPL/endpoints > discovery, among others. Mark Townsley may have articulated the latter point before? I will re-iterate and expound based on the current discussion. Auto-discovery for L2VPNs are clearly within the rhelm of PPVPN. Wire properties are defined within PWE3 (and any L2TP-specific support for such within l2tpext). P2MP wire properties fall within the "could" rhelm of PWE3 (as chartered), and the discussion on this thread has been more about whether they "should" or not. Most of the current mindshare on this topic is within PPVPN, particularly on the subject of a "bridged network or network of bridges" debate. Cheng-yin, if I understand your problem with defining your work within ppvpn, it is that the application of the lee-l2tpext draft you cited on this thread are ce-based vpns defined in draft-lee-ce-based-vpl-00.txt, which quite specifically leaves the first "p" in ppvpn out of the equation. That said, ppvpn has already tackled some ce-based VPNs via IPsec, though this is a L3 approach and certainly does not include VPLS. It is not clear to me whether your ce-based solution is provider or customer provisioned. If provider-provisioned, than from ppvpn's perspective, there is a pretty decent argument for your work under a L2VPN CE-based architecture heading, similar in spirit to that for L3VPNs defined in draft-ietf-ppvpn-framework-06.txt. If customer-provisioned, the topology doesn't change too terribly much, but the language in the document certainly would. I can certainly understand some level of frustration with the l2vpn work in ppvpn to date, and the desire to bypass it on grounds that your work is not provider-equipment based. However, there has been some very recent work by the l2vpn design team, which yielded a posting to the ppvpn list within the past 24 hours. There is some very good discussion behind this, and it would be a shame for application not to fit within this framework. So, to the WGs I would ask, where do CE-based L2VPNs lie? I would prefer within the same group working on the larger issue of ppvpns. This would require at least a section detailing how it looks when the PE and the CE are collapsed into a single box, and perhaps any associated provider-specific requirements are adjusted to "customer"-specific requirements. Would the ppvpn WG be willing to cover this (with Cheng-yin's help, of course!)? Thanks, - Mark > > Sorry, I have to go now, but will catch up with this later. > > thanks > cheng-yin > > Stewart Bryant wrote: > > >>As I read this draft you are setting up individual PWs using >>L2TP and then bridging across them. The bridging function >>belongs in the FWRD component. I was working on the assumption >>that FWRD was outside the scope of PWE3 (I had assumed that it >>belonged to PPVPN). I am not sure why we would move it back in >>scope, and if we did how we would set the demarcation with >>PPVPN. >> >>The present (implicit) restriction of PW to pt-pt Ethernet >>provides a clean functional divide between transmission >>and forwarding. >> >>Stewart >> >>Cheng-Yin Lee wrote: >> >>>Stewart, >>> >>>Stewart Bryant wrote: >>> >>> >>> >>>>Cheng-Yin >>>> >>>>To clarify: the sort of thing that you have in mind is to >>>>explicitly cover the multicasting of Ethernet over the WAN >>>>using something like IP or MPLS multicast? >>> >>> >>>No, No, No ! :-). I agree with you that "I am not sure the saving in packet >>>replication justifies the complexity ..." >>> >>>I meant something like in draft-lee-l2tpext-pwe3-vpl-00.txt, encapsulating Ethernet in >>>L2TPv3 and bridging at an LCCE. >>>A side note is that a PPVPN/PPVPL may have additional requirements besides the >>>emulation of an Ethernet wire. >>> >>>regards, >>>cheng-yin. >>> >>> >>> >>>>Although this is not explicitly called out, you can do this >>>>with the specs as they exist today, by for example, using >>>>L2TPv3 in manual configuration mode and using an IP multicast >>>>address as the IP DA. >>>> >>>>Is there anyone who has an application for this mode? >>>> >>>>The only use that I can see for this is to avoid replication >>>>of broadcast packets when building a L2VPN, but I am not sure >>>>the saving in packet replication justifies the complexity of >>>>effectively running two parallel PW networks (ie the broadcast >>>>network plus the point to point mesh). However that is a call >>>>that the PPVPN WG need to make. >>>> >>>>Regards >>>> >>>>Stewart >>>> >>>>Cheng-Yin Lee wrote: >>>> >>>> >>>>>Danny, >>>>>I was referring to Ethernet specifically in my previous email >>>>>http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03096.html >>>>>The Ethernet 'wire' inherently allows broadcasting. In my view, a bridge emulates >>>>>an Ethernet 'wire'. OTOH, whether bridging is done at PE/L2PE/CE, I believe, is >>>>>out of the scope of PWE3. >>>>> >>>>>For services where multipoint transmission is not a property of the "wire", I >>>>>agree multipoint discussion is out of scope. >>>>> >>>>>thanks >>>>>cheng-yin >>>>> >>>>>Danny McPherson wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>>Creating a multi-point system out of p2p wires is definitely a PPVPN >>>>>>>function rather than a PWE3 function. But that doesn't rule out the >>>>>>>possibility of PWE3 defining a p2mp wire of some sort. Whether such a thing >>>>>>>is actually needed is an open question. >>>>>> >>>>>>I tend to agree with Eric here and would like to see some >>>>>>discussion of drivers for the work. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I think this should just be punted for now, left "for further study". >>>>>> >>>>>>My first inclination is to agree. However, begin that there is >>>>>>apparent interest and it's technically chartered (at least in the >>>>>>case of Ethernet), we should at least give it some opportunity for >>>>>>consideration. >>>>>> >>>>>>I'd be interested in what others think... >>>>>> >>>>>>-danny >>>>>> >>>>>>_______________________________________________ >>>>>>pwe3 mailing list >>>>>>pwe3@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> >>>>> >>>>>_______________________________________________ >>>>>pwe3 mailing list >>>>>pwe3@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>>> >>>>> >>>> >>> >>> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 5 06:06: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 GAA10398 for ; Tue, 5 Nov 2002 06:06: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 gA5B8hi01870 for ; Tue, 5 Nov 2002 06:08: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 gA5B8ed14976 for ; Tue, 5 Nov 2002 06:08:40 -0500 (EST) Message-Id: <200211051105.GAA10213@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-nagarajan-ppvpn-generic-reqts-01.txt Date: Tue, 05 Nov 2002 06:05:55 -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 : Generic Requirements for Provider Provisioned VPN Author(s) : A. Nagarajan Filename : draft-nagarajan-ppvpn-generic-reqts-01.txt Pages : 21 Date : 2002-11-4 This document described 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nagarajan-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-nagarajan-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-nagarajan-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-11-4171503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nagarajan-ppvpn-generic-reqts-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-nagarajan-ppvpn-generic-reqts-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171503.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 5 06:11:44 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 GAA11424 for ; Tue, 5 Nov 2002 06:11:44 -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 gA5BDai06027 for ; Tue, 5 Nov 2002 06:13: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 gA5BDXd21010 for ; Tue, 5 Nov 2002 06:13:34 -0500 (EST) Message-Id: <200211051110.GAA11216@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-vpls-requirements-01.txt Date: Tue, 05 Nov 2002 06:10:40 -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 : Requirements for Virtual Private LAN Services (VPLS) Author(s) : W. Augustyn et al. Filename : draft-ietf-ppvpn-vpls-requirements-01.txt Pages : 16 Date : 2002-11-4 This draft describes service requirements related to emulating a virtual private LAN over an IP or MPLS network infrastructure. The service is called VPLS. It is a class of Provider Provisioned Virtual Private Network [2]. The general requirements can be found in [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-requirements-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-vpls-requirements-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-vpls-requirements-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-4172452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-vpls-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-vpls-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4172452.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 5 10:18: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 KAA22938 for ; Tue, 5 Nov 2002 10:18:32 -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 gA5FKMi08229 for ; Tue, 5 Nov 2002 10:20: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 gA5FKJd07040 for ; Tue, 5 Nov 2002 10:20:20 -0500 (EST) Message-Id: <4.3.2.7.2.20021105160904.02a05e38@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Nov 2002 16:17:54 +0100 To: Rick Wilder , "Marco Carugi" From: "Michael H. Behringer" Subject: Request for Speaking Slot, draft-behringer-mpls-vpn-auth-00.txt Cc: ppvpn@nortelnetworks.com, Jim Guichard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: mbehring@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: amsterdam.cisco.com [144.254.74.238] X-LYRIS-Message-Id: Marco, Rick, We have published a draft about an authentication scheme for MPLS/VPN, which is similar to draft-ietf-ppvpn-l3vpn-auth-00.txt, but does not require changes to the CE. If you consider this work of interest for this WG, it would be nice to get a speaking slot in Atlanta. Thanks, Michael A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS VPN Authentication Author(s) : M. Behringer, J. Guichard Filename : draft-behringer-mpls-vpn-auth-00.txt Pages : 6 Date : 2002-10-31 Authentication in current MPLS/VPN networks [RFC2547] is based on routing authentication between CE-PE, PE-PE and again PE-CE, which authenticates the routing peer and verifies the integrity of routing updates from that peer. This does not provide CE-CE authentication. Here we propose a CE-CE authentication scheme that combines the three separate steps above and protects against misconfiguration of the PE routers by the Service Provider on the MPLS network. The proposed changes affect only the PE routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-behringer-mpls-vpn-auth-00.txt From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 5 11:07: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 LAA26458 for ; Tue, 5 Nov 2002 11:07: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 gA5G9ii22269 for ; Tue, 5 Nov 2002 11:09: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 gA5G9fd29306 for ; Tue, 5 Nov 2002 11:09:41 -0500 (EST) Reply-To: From: "asodder" To: Cc: Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-01.txt Date: Tue, 5 Nov 2002 11:02:48 -0500 Message-ID: <00a001c284e4$cd210b60$da03a8c0@tenornet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200210231406.g9NE6qIm003753@sj-msg-core-1.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-SMTP-HELO: tenornetworks.com X-SMTP-MAIL-FROM: asodder@tenornetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtu.tenornetworks.com [63.77.213.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Eric, I've added a description to the draft that illustrates how the PWE3-CTRL draft can be extended to support VHLS. Hopefully this will illustrate the reduction in signalling when compared with VPLS. The updated draft can be found at: ftp://63.77.213.10/pub/draft-sodder-ppvpn-vhls-01.txt. [Sorry I missed the deadline]. I have not addressed all the issues you have raised in your earlier email. The issue of per-packet overhead is the trade-off that this approach makes with respect to other approaches. Your proposal for inter-operability with VPLS is good and I'll try and detail it (hopefully with your help) and include it in the next version of the draft. Arnold -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Wednesday, October 23, 2002 10:07 AM To: asodder@tenornetworks.com Cc: ppvpn@lyris.nortelnetworks.com Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt Arnold> I agree that initially I have been assuming that the Arnold> ethernet-over-IP/MPLS service begins after the MAC-in-MAC encaps has Arnold> been done, and ends before the corresponding decaps has been done. In this case, we need only consider how to provide the emulated LAN service for the packets which have already been MAC-in-MAC encapsulated, and we need to do that considering only the outer MAC header. So this reduces to exactly the same problem that VPLS is intended to solve. The only relevant difference then between your proposal and VPLS is the following. In VPLS, signaling is used to assign a locally significant label value that represents a particular L2VPN instance in a particular PE. You appear to be proposing to replace the locally significant label value with globally significant values, so as to eliminate the signaling. It's not completely clear how you intend this to work, as your draft says nothing about how a packet is associated with its source PE. I think you might be intending to have each PE signal a single label (representing the "emulated LAN application") to each other PE. Then you seem to be intending to have each packet carry a VPN-id in its encapsulation. My comments on this would be: - It significantly increases the per-packet overhead. I see that you're trying to squeeze the VPN-id into some existing MAC header field, but this won't work. The VPN-id has to be a globally unique value which can feasibly be administered in a multi-provider space, and this means it is going to be about 8 bytes long. (See, e.g., RFC 2685.) - With a significant increase in the per-packet overhead, you need to make the assumption that the packets will not have to pass through any legacy ethernet equipment (you know, the kind that just barely supports an ethernet frame with a couple of MPLS labels). This is not a realistic assumption. - For the increase in packet size, I don't see that you gain any significant reduction in signaling, as you still seem to need per-PE control connections. (To eliminate that, I think you'd need to require that the MAC-in-MAC encaps be further encapsulated inside IP, so you could learn the source PE's address on a per-packet basis; but I think that has problems as well.) You also need to consider the impact of interoperating with other hierarchical VPLS or distributed VPLS schemes, as well as interoperating with the PWE3 p2p ethernet service, all of which seem to be made more complex. (You're not assuming that emulated LAN service will only be offered with new L2PE equipment that does the MAC-in-MAC processing, are you?) - By carrying the VPN-id in each packet, you impose the requirement to look up the VPN-id for each received packet, so we have yet another kind of thing to be looked up. I can see that VHLS keeps the MAC address tables in the PE smaller than HVPLS does, but the distributed (sometimes called "decoupled") VPLS models eliminate those tables in the PE altogether, though at the cost of requiring MPLS in the L2PEs. One alternative to consider might be the following. In the distributed VPLS model, allow MAC-in-MAC to be an alternative to MPLS for the local L2PE-to-PE signaling, but don't carry the MAC-in-MAC across the network. This would allow the various schemes to interoperate (e.g., MAC-in-MAC at one end, MPLS at the other). From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 5 20: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 UAA02415 for ; Tue, 5 Nov 2002 20: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 gA620qi25563 for ; Tue, 5 Nov 2002 21:00: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 gA620nd10599 for ; Tue, 5 Nov 2002 21:00:49 -0500 (EST) Date: 5 Nov 2002 20:57:12 -0500 Message-ID: <3DC876F8.1F284D41@alcatel.com> From: "Cheng-Yin Lee" To: "W. Mark Townsley" Cc: stbryant@cisco.com, danny@tcb.net, pwe3@ietf.org, ppvpn@nortelnetworks.com X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00 References: <200211011519.gA1FJY601724@tcb.net> <3DC2D23D.FFF906F4@alcatel.com> <3DC2DC33.5000807@cisco.com> <3DC2DF8C.5F0033E@alcatel.com> <3DC2EBA8.9020006@cisco.com> <3DC2F00E.AA52A419@alcatel.com> <3DC785EE.5000706@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@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark et al, "W. Mark Townsley" wrote: > cc'ing ppvpn > > Cheng-Yin Lee wrote: > > Stewart, > > Just some quick points: > > As I see it, a bridge emulates an Ethernet wire, a PPVPL would then be an application of this > > ethernet pseudo wire service, and would have additional requirements e.g. VPL/endpoints > > discovery, among others. Mark Townsley may have articulated the latter point before? > > I will re-iterate and expound based on the current discussion. > > Auto-discovery for L2VPNs are clearly within the rhelm of PPVPN. > > Wire properties are defined within PWE3 (and any L2TP-specific support for such > within l2tpext). I think the first and most fundamental question then is what is an Ethernet pseudo-wire. The PWE3 WG charter alluded this: "Ethernet transmission to a "multicast" IEEE-48 address is in scope" We may choose to ignore this inherent aspect of Ethernet transmission, and do the work in PPVPN, but, > P2MP wire properties fall within the "could" rhelm of PWE3 (as chartered), and > the discussion on this thread has been more about whether they "should" or not. > Most of the current mindshare on this topic is within PPVPN, the next point that I should reiterate then is an Ethernet pseudo-wire may not necessarily be a PPVPL. In addition, I think there are advantages in partitioning the Ethernet pseudo-wire aspects from PPVPL (which has many additional requirements). An Ethernet pseudo-wire may also be used in different applications. > particularly on the > subject of a "bridged network or network of bridges" debate. As I see it, many of the issues raised in "Bridging network or networked bridges" email are related to bridging customers' traffic in the provider's network, a smaller number of issues are independent of whether the VPL is customer or provider provisioned, some are in IEEE realm, while others are implementation details. Hence it looks like it is even more important to partition these different issues and problems - it is easier to focus on a scoped problem. > Cheng-yin, if I understand your problem with defining your work within ppvpn, it > is that the application of the lee-l2tpext draft you cited on this thread are > ce-based vpns defined in draft-lee-ce-based-vpl-00.txt, which quite specifically > leaves the first "p" in ppvpn out of the equation. That said, ppvpn has already > tackled some ce-based VPNs via IPsec, though this is a L3 approach and certainly > does not include VPLS. It is not clear to me whether your ce-based solution is > provider or customer provisioned. If provider-provisioned, than from ppvpn's > perspective, there is a pretty decent argument for your work under a L2VPN > CE-based architecture heading, similar in spirit to that for L3VPNs defined in > draft-ietf-ppvpn-framework-06.txt. If customer-provisioned, the topology doesn't > change too terribly much, but the language in the document certainly would. > > I can certainly understand some level of frustration with the l2vpn work in > ppvpn to date, and the desire to bypass it on grounds that your work is not > provider-equipment based. However, there has been some very recent work by the > l2vpn design team, which yielded a posting to the ppvpn list within the past 24 > hours. There is some very good discussion behind this, and it would be a shame > for application not to fit within this framework. > > So, to the WGs I would ask, where do CE-based L2VPNs lie? I would prefer within > the same group working on the larger issue of ppvpns. > This would require at > least a section detailing how it looks when the PE and the CE are collapsed into > a single box, and perhaps any associated provider-specific requirements are > adjusted to "customer"-specific requirements. Strictly speaking, PPVPN is only for provider provisioned VPN, but I think what you suggest is good way to reuse some of the work in PPVPN. On work partitioning, I still think it's better to partition Ethernet pseudo-wire from the applications because of the reasons I gave above and in previous email. thanks cheng-yin > > Would the ppvpn WG be willing to cover this (with Cheng-yin's help, of course!)? > > Thanks, > > - Mark > > > > > Sorry, I have to go now, but will catch up with this later. > > > > thanks > > cheng-yin > > > > Stewart Bryant wrote: > > > > > >>As I read this draft you are setting up individual PWs using > >>L2TP and then bridging across them. The bridging function > >>belongs in the FWRD component. I was working on the assumption > >>that FWRD was outside the scope of PWE3 (I had assumed that it > >>belonged to PPVPN). I am not sure why we would move it back in > >>scope, and if we did how we would set the demarcation with > >>PPVPN. > >> > >>The present (implicit) restriction of PW to pt-pt Ethernet > >>provides a clean functional divide between transmission > >>and forwarding. > >> > >>Stewart > >> > >>Cheng-Yin Lee wrote: > >> > >>>Stewart, > >>> > >>>Stewart Bryant wrote: > >>> > >>> > >>> > >>>>Cheng-Yin > >>>> > >>>>To clarify: the sort of thing that you have in mind is to > >>>>explicitly cover the multicasting of Ethernet over the WAN > >>>>using something like IP or MPLS multicast? > >>> > >>> > >>>No, No, No ! :-). I agree with you that "I am not sure the saving in packet > >>>replication justifies the complexity ..." > >>> > >>>I meant something like in draft-lee-l2tpext-pwe3-vpl-00.txt, encapsulating Ethernet in > >>>L2TPv3 and bridging at an LCCE. > >>>A side note is that a PPVPN/PPVPL may have additional requirements besides the > >>>emulation of an Ethernet wire. > >>> > >>>regards, > >>>cheng-yin. > >>> > >>> > >>> > >>>>Although this is not explicitly called out, you can do this > >>>>with the specs as they exist today, by for example, using > >>>>L2TPv3 in manual configuration mode and using an IP multicast > >>>>address as the IP DA. > >>>> > >>>>Is there anyone who has an application for this mode? > >>>> > >>>>The only use that I can see for this is to avoid replication > >>>>of broadcast packets when building a L2VPN, but I am not sure > >>>>the saving in packet replication justifies the complexity of > >>>>effectively running two parallel PW networks (ie the broadcast > >>>>network plus the point to point mesh). However that is a call > >>>>that the PPVPN WG need to make. > >>>> > >>>>Regards > >>>> > >>>>Stewart > >>>> > >>>>Cheng-Yin Lee wrote: > >>>> > >>>> > >>>>>Danny, > >>>>>I was referring to Ethernet specifically in my previous email > >>>>>http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03096.html > >>>>>The Ethernet 'wire' inherently allows broadcasting. In my view, a bridge emulates > >>>>>an Ethernet 'wire'. OTOH, whether bridging is done at PE/L2PE/CE, I believe, is > >>>>>out of the scope of PWE3. > >>>>> > >>>>>For services where multipoint transmission is not a property of the "wire", I > >>>>>agree multipoint discussion is out of scope. > >>>>> > >>>>>thanks > >>>>>cheng-yin > >>>>> > >>>>>Danny McPherson wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>Creating a multi-point system out of p2p wires is definitely a PPVPN > >>>>>>>function rather than a PWE3 function. But that doesn't rule out the > >>>>>>>possibility of PWE3 defining a p2mp wire of some sort. Whether such a thing > >>>>>>>is actually needed is an open question. > >>>>>> > >>>>>>I tend to agree with Eric here and would like to see some > >>>>>>discussion of drivers for the work. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>I think this should just be punted for now, left "for further study". > >>>>>> > >>>>>>My first inclination is to agree. However, begin that there is > >>>>>>apparent interest and it's technically chartered (at least in the > >>>>>>case of Ethernet), we should at least give it some opportunity for > >>>>>>consideration. > >>>>>> > >>>>>>I'd be interested in what others think... > >>>>>> > >>>>>>-danny > >>>>>> > >>>>>>_______________________________________________ > >>>>>>pwe3 mailing list > >>>>>>pwe3@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>pwe3 mailing list > >>>>>pwe3@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>> > >>>>> > >>>> > >>> > >>> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 5 21:37:34 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 VAA05190 for ; Tue, 5 Nov 2002 21:37:33 -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 gA62dPi00243 for ; Tue, 5 Nov 2002 21:39: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 gA62dMd04963 for ; Tue, 5 Nov 2002 21:39:22 -0500 (EST) Date: Tue, 05 Nov 2002 21:23:25 -0500 From: Ron Bonica Subject: draft-behringer-mpls-vpn-auth-00 To: PPVPN@NORTELNETWORKS.COM Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: pmesmtp01.wcom.com X-SMTP-MAIL-FROM: Ronald.P.Bonica@wcom.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: pmesmtp01.wcom.com [199.249.20.1] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Michael, Can you address the following issues: 1) Many VPN sites don't use any PE-CE signaling protocol at all. The CE points default at the PE. The PE points a few static routes at the CE. 2) Customers may object to being told that they need to use the same MD5 authentication key at every site. 3) Customers who MD5 authenticate BGP peering sessions may want to change the MD5 key periodically. This isn't too painful if you don't have to change all of the keys at once. It is impossible if the customer has many hundreds of sites and you need to change all of the keys at once. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "We are not on Earth to guard a museum, but to cultivate a flourishing garden of life." -- Angelo Giuseppe Roncalli From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 5 22:48:31 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 WAA09319 for ; Tue, 5 Nov 2002 22:48: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 gA63oLi15268 for ; Tue, 5 Nov 2002 22:50: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 gA63oId24249 for ; Tue, 5 Nov 2002 22:50:18 -0500 (EST) Date: 5 Nov 2002 22:46:52 -0500 Message-ID: <3DC890AC.EA91BCD3@alcatel.com> From: "Cheng-Yin Lee" To: "Muneyoshi Suzuki" Cc: ppvpn@nortelnetworks.com X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Bridging network or networked bridges References: <200211050018.JAA66735@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@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Muneyoshi, Thanks for sending this out. Some questions inline. It may be useful to list the issues not in PPVPN, the issues in IEEE realm, etc? Muneyoshi Suzuki wrote: > > Since beginning of the last month, several discussions about VPLS were held > on the PPVPN WG generic requirements, L2VPN, and discovery design teams > mailing lists as well as personal communications. The teams understand > that there are many issues to be solved, and feel that the issues should > be discussed in the public. So, the teams don't reach any consensus and > don't decide anything yet. > > For further discussion, this memo summarize and sort out issues rose on > the lists. Note that some of issues addressed in this mail may be beyond > the scope of the IETF, but may belong to the IEEE 802 committee. So, > discussions from technical as well as administrative viewpoint for possible > directions are expected. > > Thanks, > > Muneyoshi Suzuki > > --- > 1. Reference > > Bridge is defined in IEEE 802.1D-1998, 802.1t-2001 (amendment to 802.1D), > and 802.1w-2001 (RSTP extension). 802.1D and 802.1t specify Bridge > architecture, MAC frame relay operation, Bridge protocols (such as STP, > GARP, and GMRP), and management protocol. And 802.1w specifies RSTP. > > Note that the 802.1 WG is now discussing 802.1y (corrections to 802.1D, > 802.1t and 802.1w). In this process, STP may be officially obsoleted > and replaced by RSTP. > > Note that Bridge implementation of many products in the market is still > based on 802.1D-1993 or earlier specification. Also note that there are > many cheap Bridge products that only support MAC frame relay operation and > don't implement Bridge and management protocols. If a user install this > type product, loop free deployment is the user responsibility. > > VLAN is defined in IEEE 802.1Q-1998, 802.1u-2001 (corrections to 802.1Q), > 802.1v-2001 (protocol/port-based VLAN extension). 802.1Q, 802.1u, and 802.1v > define extension of Bridge defined in 802.1D-1998. It specify extended > Bridge architecture, VLAN tagging and MAC frame relay operation based on > VLAN tag, and GVRP. Note that the VLAN defined in the IEEE 802.1 is NOT the > technology that emulates multiple logical LANs over a single physical LAN. > > Note that the 802.1 WG is now discussing 802.1s (MSTP extension), and > some VLAN-aware Bridge products support per-VLAN based STP, which is > proprietary protocol. Also note that some VLAN-aware Bridge products > in the market support the stacked VLAN mechanism which is intended > used by SPs, enables transparent forwarding of customer VLAN tag in > the SP network, but is not yet standardized. > > 2. Terminology used in this memo > > 1982-style Bridge: A Bridge that supports only MAC frame relay operation, > and the operation is based current or earlier 802.1D specification. > > 1998-style Bridge: A Bridge that conforms to IEEE 802.1D-1998 and 802.1t- > 2001. It may support RSTP defined IEEE 802.1w-2001, but does not support > VLAN capability defined in IEEE 802.1Q-1998. > > VLAN-aware Bridge: A Bridge that conforms to IEEE 802.1D-1998, 802.1t-2001, > 802.1Q-1998, 802.1u-2001, and 802.1v-2001. It may support RSTP defined IEEE > 802.1w-2001 or MSTP may be defined as IEEE 802.1s. > > Bridge: 1982-style, 1998-style, or VLAN-aware Bridge. > > Bridged LAN: A concatenation of individual LANs interconnected by Bridges. > > LAN: LAN technology that provides the MAC service and is defined in > a series of IEEE 802 LAN standards such as IEEE 802.3 Ethernet LAN. > > Note that "LAN segment" means the medium connection, e.g., 1000BASE-T, > between Medium Dependent Interfaces in a LAN. The use of this terminology > may be inappropriate in the VPLS context, because it is not intended to > provide medium dependent service. > > 3. Customer View > > VPLS service is enabled by a logical Bridged LAN, which consists of > physical or emulated LANs and Bridges. This Bridged LAN provides > independent VPLS service instances per customer. From the viewpoint of > VPLS service customers, a service instance emulated by VSIs in PEs for a > customer is equivalent to: > > o A LAN > o A single Bridge, that is: > - A 1982-style Bridge > - A 1998-style Bridge > - A VLAN-aware Bridge > o A Bridged LAN composed by: > - 1982-style Bridges (loop free topology must be ensured) > - 1998-style Bridges > - VLAN-aware Bridges > - Bridges > > Question: Expected scenario from customer's perspective. > > Note that if a customer interconnects customer's VLAN-aware Bridges > through a VPLS service instance, it may have to be equivalent to a LAN, > a VLAN-aware Bridge, or a Bridged LAN composed by VLAN-aware Bridges. > > One of issues at here is what should be emulated by a VSI in a PE or VSIs > for a VPLS customer. A single LAN or a single Bridge may be emulated by > VSIs in PEs belonging to an SP network. Also, a single VSI in a PE may > emulate a single Bridge (remote-Bridge) and emulated Bridges may be > interconnected by Ethernet pseudo wires. > > The other issue is how the service instance handles the Bridge protocols > such as STP/RSTP/MSTP and GARP/GMRP/GVRP transfered through BPDUs, as well > as, LCAP and MAC control protocol for PAUSE operation received from/sent to > the customer site. MAC frames used by these protocols are sent to > multicast addresses. Emulated 1998-style and VLAN-aware Bridges must > terminate most of these frames, then appropriate action based on the > standard must be executed. Is this not in IEEE realm? (in the IEEE entity of the VSI) > > On the other hand, emulated LAN and 1982-style Bridge must transparently > forward most of these frames. This may decrease load in PEs. Note that > emulated LAN, that learns customer's MAC addresses, and 1982-style Bridge > must transparently forward customer STP/RSTP/MSTP BPDU frame, because these > don't join the spanning tree. However, when a customer network topology > is changed, the MAC address cache in VSIs for the customer should be > flushed to reduce the time for topology change. So, a STP/RSTP/MSTP snooping > mechanism may be required for these implementation. Are there some inconsistencies in the requirements? A 1982-style bridge is expected to snoop RSTP/MSTP? > > 4. SPs Requirements > > VPLS service providers must identify order of the maximum number of the > customers (e.g., # of service instances, CEs, etc) to be supported. SPs > may restrict maximum number of the MAC addresses supported by a single VPLS > service (or a single customer site). > > Question: Order of the maximum number of the customers assumed by SPs. > Thousands, tens of thousands, hundreds of thousands, or millions..... > And, the maximum number of the MAC addresses supported by a single VPLS > service. Tens, hundreds, thousands, or tens of thousands...... > > Note that theses values may strongly impact on MAC forwarding table size > in the VPLS. > > 5. Implementation Model > > VPLS service is enabled by a logical Bridged LAN, which consists of > physical or emulated LANs and Bridges. This Bridged LAN provides > independent VPLS service instances per customer. A portion of the Bridged > LAN is emulated by VSIs interconnected by Ethernet pseudo wires. > > 5.1 Support of VPLS Service > > Port-based VLAN (defined in Annex D of IEEE 802.1D, 802.1u and 802.1v) > enables per-customer based VLAN support, if a port corresponds to a single > customer. Thus, VLAN-aware Bridges can be used for the support of VPLS > service in the Bridged LAN. > > However, the current VLAN standard support only 4094 VLANs in the Bridged > LAN. Also it does not emulate a VLAN-aware Bridge for a customer, so the > customer network cannot use the VLAN. These may be unacceptable restrictions > for VPLS service providers and customers. > > Therefore, development of new layer 2 technology that supports SP class > VLAN service is indispensable. Note that the technology to be developed may > be independent from layer 3 technology such as IP and MPLS. Stacked-VLAN > aware Bridge, described in section 1, is one of candidates for solution. Is the PW ID considered a candidate solution? > Encapsulation Bridge which support MAC-in-MAC encapsulation is the other > candidate. Stacked-VLAN aware Bridge may have to learn customer MAC > addresses, while MAC-in-MAC may not have to learn these, so the latter > may be able to reduce MAC address table size. Is the latter addresses aggregatable, will protocols similar to "routing protocols" be developed then? > > Note that there is a possibility that the same MAC addresses are assigned > to different Ethernet interfaces. VRRP assigns the same virtual MAC > addresses to different interfaces. Per-VLAN based STP, described in > section 1, also use a similar scheme. Thus, if a customer uses VLANs in > the customer network, and if the same MAC addresses appear in different > customer VLANs, current Stacked-VLAN aware Bridge implementation may not > distinguish these MAC addresses, because it does not care customer VLAN > identifiers. This is an implementation issue? > > 5.2 LAN/Bridge Emulation > > PWE3 WG is discussing point-to-point Ethernet pseudo wire, which is > described in the following drafts. > > draft-ietf-pwe3-control-protocol-00.txt > draft-ietf-pwe3-ethernet-encap-00.txt > > PPVPN WG will use this pseudo wire as an emulation technology in the > logical Bridged LAN that provide VPLS service. A part of the Bridged LAN > is emulated by VSIs interconnected by Ethernet pseudo wires. That is > equivalent to: > > o A LAN > o A single Bridge > o A Bridged LAN > (or something like these) > > The emulated part must ensure loop free MAC frame forwarding, however the > use of STP may be inappropriate in WAN environment. Therefore, the WG is > discussing topology restriction of pseudo wires that interconnect VSIs. > > One of solutions is tree structure topology, here a VSI is a node and a > pseudo wire is a link, however details of this approach are not proposed > yet. Another solution is full mesh topology with split-horizon forwarding > scheme proposed in draft-lasserre-vkompella-ppvpn-vpls-02.txt. > > The split-horizon forwarding scheme enables loop free MAC frame forwarding. > A VSI forwards a MAC frame received from a customer to others VSIs, but it > never forward a frame received from a VSI to another VSI. It also learns > MAC addresses received from the customer network. Obviously, in this > scheme, a VSI doesn't emulate a remote-Bridge defined in IEEE 802.1G. What are the problems of not emulating a remote-Bridge in this case? > > Thus, one of issues at here is what is emulated by full mesh topology with > split-horizon forwarding scheme. > > o It is an emulated LAN, because it transparently forwards MAC frames. > > o It is an emulated Bridge, because it terminates MAC layer, then > forwards MAC frames to another interface, so it can interconnect > different Ethernet mediums, furthermore, it learns MAC addresses for > forwarding. > > Note that if it is an emulated Bridge, at least, it may have to be a VLAN- > aware Bridge for support of VPLS service in the Bridged LAN. > > The other issue is scalability. Obviously, full mesh topology is not scale, > if number of VSIs is increased. Support of broadcast and multicast is also > problematic, because it wastes bandwidth in the SP network and increases > jitter of MAC frame forwarding. > > 5.3 Routing for LAN/Bridge Emulation > > Topology restriction described in the previous section may not be > acceptable for SPs, because SPs can not deploy PEs freely and full mesh > topology may not scale. > > However, if a VSI emulates a remote Bridge, currently only STP/RSTP can be > used for routing. RSTP much improved recovery time, however, we need more > experiments of the use of RSTP in WAN environments. > > The final issue is, if RSTP works in WAN environments, it only blocks > links and constructs a tree or hierarchical tree topologies. It may not > efficiently use link bandwidth. So, minimum OSPF or BGP-4 extension for > MAC routing support may be required. From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 5 23:38:26 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 XAA10344 for ; Tue, 5 Nov 2002 23:38:25 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA64eIi25192 for ; Tue, 5 Nov 2002 23:40:18 -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 gA64eCd27718 for ; Tue, 5 Nov 2002 23:40:13 -0500 (EST) Date: Wed, 06 Nov 2002 12:39:38 +0800 From: lidefeng Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) To: internet-drafts@ietf.org Cc: rwilder@masergy.com, "Marco Carugi" , sob@harvard.edu, bwijnen@lucent.com, zinin@psg.com, ppvpn@nortelnetworks.com, lhj@huawei.com, Gma@futurewei.com, changwj@huawei.com, "Fu Y. Miao" , leh10814@huawei.com, l.b@huawei.com Message-id: <002e01c2854e$84f83ec0$22436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_IWid0mMDJrRucPo2alOqnw)" X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_IWid0mMDJrRucPo2alOqnw) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Hi,all, In BGP/MPLS VPN area, we proposed a new idea as to resolve the bottleneck of the capacity of some PEs when deploy the huge size VPN,the whole idea is detailed in the attached draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the Abstract is as follows,we are appreciated for your review. In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should maintain all the VPN routes of the VPNs which it belong to.When there are many VPNs converged by a PE,and the capacity of PE is relevant limited,then the bottleneck will be encountered.Another problem is that the current BGP/MPLS VPN model is something of a "Plane Modle" where the demand of the performance of the PE device are all the same no matter which layer the PE device is belongs to.However,the typical network is "Core-Convergence-Access(Edge)" model,and the performance of the device is superior in Core Layer and inferior in Access Layer,and the scale of network is large in Access Layer and small in Core Layer,the routes are converged in every layer,so in current "Plane Modle",when PE device push to the edge layer,it has to maintain more VPN routes,this makes it difficult to extend the PE device to edge layer.This document defines an model of hiberarchy of Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider Edge Device can be composed of several device and every device take on the different part,partake the function of the former concentrative PE,we call this model "Hiberarchy Model",In this model the demand of performance in Routing and Switching is strict to the PE device in High layer,loose to the PE device in edge layer. One HoPE can be composed of a SPE and UPES connected to the SPE, or be composed of a high-level SPE and HoPEs connected the high level SPE and and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connect to the high-level SPE as a role of UPE,and the new HoPE can connect a single UPE too. Regards Defeng Li --Boundary_(ID_IWid0mMDJrRucPo2alOqnw) Content-type: text/plain; name=draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt Content-disposition: attachment; filename=draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt Content-Transfer-Encoding: 7BIT Network Working Group Li Bin Internet Draft Dong Weisi Expires: May 2003 Li Defeng Huawei Technologies November 06, 2002 Hiberarchy of Provider Edge Device in BGP/MPLS VPN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-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 In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should maintain all the VPN routes of the VPNs which it belong to.When there are many VPNs converged by a PE,and the capacity of PE is relevant limited,then the bottleneck will be encountered.Another problem is that the current BGP/MPLS VPN model is something of a "Plane Modle" where the demand of the performance of the PE device are all the same no matter which layer the PE device is belongs to.However,the typical network is "Core-Convergence-Access(Edge)" model,and the performance of the device is superior in Core Layer and inferior in Access Layer,and the scale of network is large in Access Layer and small in Core Layer,the routes are converged in every layer,so in current "Plane Modle",when PE device push to the edge layer,it has to maintain more VPN routes,this makes it difficult to extend the PE Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 1] Draft November 2002 device to edge layer.This document defines an model of hiberarchy of Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider Edge Device can be composed of several device and every device take on the different part,partake the function of the former concentrative PE,we call this model "Hiberarchy Model",In this model the demand of performance in Routing and Switching is strict to the PE device in High layer,loose to the PE device in edge layer. One HoPE can be composed of a SPE and UPES connected to the SPE, or be composed of a high-level SPE and HoPEs connected the high level SPE and and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connect to the high-level SPE as a role of UPE,and the new HoPE can connect a single UPE too. Table of Contents(will edit in the last) 1. Introduction ................................................. 3 2. Working Principle ........................ 4 2.1 VPN routes ............................................... 6 2.2 Control Flow(Route Advertising and Label Distribution) 2.3 Data Flow(Label Operation and Packet Forwarding) ................. 7 3. Interface between UPE and SPE....................................... 7 4. Nesting of HoPE 5. Multi-Homing UPE 6. Backdoor link between UPEs 7. The Forwarding Procedure in Some Special Cases 8. Security Consideration 9. Acknowledge 10. References 11. Authors' Addresses Full Copyright Statement ........................................ 11 Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 2] Draft November 2002 1. Introduction This document defines an model of hiberarchy of Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider Edge Device can be composed of several device and every device take on the different part,partake the function of the former concentrative PE,we call this model "Hiberarchy Model",In this model the demand of performance in Routing and Switching is strict to the PE device in High layer,loose to the PE device in edge layer. PE device can connect to not only the Customer Edge(CE) device,but also a PE device,or even more generally an MPLS VPN network,and the connected PE devices formed the "Hiberarchy of PE",and the PE device which replace the former position of CE device in "Plane Model" is called Under-layer PE,UPE in short,and the PE device which UPE is connected to is called Superstratum PE,SPE in short,this architiecture is called Hiberarchy of PE,HoPE in short.and the architecture figure is as follows(figure 1): +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +----------+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Site3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +----------+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +----------+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Site3| +----------+ | |--| MPLS |----| | | | +--+ +----------+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ +---+ +----------+ +----+ figure 1: Hiberarchy of PE Architecture Several UPE and SPE formed the Hiberarchy of PE,which provide the conventional function of PE in "Plane Model",and their respective functions are as follows: UPE maintains only the routes of the VPN sites which is directly connected to UPE,it don't maintain the routes of the remote VPN sites or only maintain the aggregate routes,SPE maintain the routes of all the sites directly connected to this SPE and the sites directly connected to UPE which directly connected to this SPE. UPE distribute the inner MPLS labels for the routes in the sites directly connected to it,and advertise the labels to SPE with the Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 3] Draft November 2002 VPN routes through MP-BGP,SPE don't advertise the routes in the remote sites to UPE,it only advertise the VRF default route or aggregate route to UPE,and the route is concomitant with the MPLS label. MP-IBGP or MP-EBGP can be applied between UPE and SPE,while MP-IBGP is applied,SPE should be the Route Reflector(RR) for all the UPEs collected to it,and UPE play the role of Client of this RR,BUT SPE doesn't act as the RR for other PEs. If MP-EBGP is applied between MP-EBGP,the AS number of the UPEs should be the private AS number(64512~65535).In fact,the Hiberarchy of PE can be handles with the rules of Confederation,in which case every confederation AS is composed of only one BGP Speaker,the UPE collected to the SPE. The packet forwarding between SPE and UPE is based on the label,so only one interface is needed to connected to each other,this interface can be a physical interface,or sub-interface,such as VLAN, PVC,tunnel such as GRE or LSP.When tunnel is applied between UPE and SPE,an IP network or MPLS network can be deployed between them. Hiberarchy of PE takes on all the functions of the normal PE, there is no difference between them when looked outside,so this "special" PE can coexist with other PEs in the MPLS network. 2. Working Principle This section specifies the working principle of Hiberarchy of PE including the maintaining of VPN routes,distribution of MPLS labels, and packet forwarding. 2.1 VPN routes SPE can establish MP-BGP neighborship with UPE,if they are administered by the same service provider,they can be MP-IBGP neighborship,otherwise should establish the MP-EBGP neighorship. In the MP-IBGP case,if there exists the sites of the different UPEs collected to an SPE belong to the same VPN,SPE as the Route Reflector for the relevant UPEs,otherwise SPE act as the convergent PE for all the UPEs collected to it.Route-Target lists are used to select the right VPN routes from other PEs as the normal "Plane Modle" BGP/MPLS VPN(RFC 2547bis),while only SPE will exchange the route information with other PEs,UPE should send the import route target list to SPE,SPE converge the route target lists and derive the HoPE-wide import route target list,with this HoPE-wide import route target,SPE can select the right VPN routes which belong to the VPNs which have the sites connected the SPE directly or through UPE. This HoPE-wide import route target list can be configured staticly or derived dynamically between SPE and UPEs.The dynamic mechanism is as follows: Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 4] Draft November 2002 UPE advertise the ORF(Outbound Route Filter)[BGP-ORF] to SPE through Route Refresh(RFC 2918) message,and an extended community list is included in the ORF item,the content of the extended community list is the aggregation of the import route target lists of all the VRFs in the UPE,and SPE converge all the import route target lists received from the UPEs connected to SPE and derive the HoPE-wide import route target list. In MP-EBGP case,SPE should derive the HoPE-wide import route target list all the same with the mechanism as above.In general,UPE should adopt the private AS number in VPN routes advertised to SPE.When SPE advertised the routes to other PEs,SPE should omitted the private AS. The scheme in which SPE connected to part of UPEs through MP-IBGP, and to the other part UPEs through MP-EBGP is permitted. UPE selects its own VPN routes by match its own import route target list with the export route target list attached with VPN routes respectively. SPE advertised the VRF default route or aggregate routes(by which UPE transfer the VPN packet to SPE) to UPE,this default VRF route can be formed dynamically or configured statically.When formed dynamically,it can be filtered by the ORF mechanism mentioned above. 2.2 Control Flow(Route Advertising and Label Distribution) This section specifies the mechanism the network distribute the labels for the routes in the VPN sites.The following figure(Figure 2) signifies the control flow between VPN1 site1 and VPN1 SITE2,the control flows(route and label distribution) in the two direction are different,there are four steps in every direction,labeled (1) through (4) in the direction from VPN1 SITE2 to VPN1 site1,and labeled (5) through (8) in the direction from VPN1 site1 to VPN1 SITE2. | (4) | (3) | (2) | (1) | |<-------|<------|<--------------|<-----| v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ |VPN1 Site1|-|CE1|---|UPE|---|SPE|---| P |---|PE|--|CE2|-|VPN1 SITE2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ ^ ^ ^ ^ ^ | (5) | (6) | (7) | (8 ) | |------->|------>|-------------->|----->| Figure 2: The control flow(route and label distribution) Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 5] Draft November 2002 In Figure 2,the meanings of (1) through (8) are as follows: Label (1) through (4) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: (1) CE2 advertise a route in the VPN1 SITE2 to PE; (2) PE distribute an inner MPLS label for this route;PE advertise this route to SPE through MP-BGP with the inner label,and the relevant export route target list attached; (3.a) SPE match the export route target list in the received route with the HoPE-wide import route target list to decide whether or not import the VPN route,in this case,they can be matched,then SPE will import the received VPN route. (3.b)At the same time SPE will match the export route target list in the received route with the import route target list advertised by VRF in UPEs connected to SPE,in this case, the import route target list of the VRF in UPE correspond to VPN1 Site1(called VRF1) will match,then SPE will advertise the default VRF1 route to UPE,with the inner MPLS label distributed by PE attached; (4) UPE advertise this route to CE1 through the route protocol(RIP, OSPF,BGP,or default route), Label (5) through (8) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: (5) CE1 advertise a route in the VPN1 site1 to UPE; (6) UPE distribute an inner label for this route;UPE advertise this route to SPE through MP-BGP with the inner label; (7) SPE replace the inner label distributed by UPE with another inner label distributed by SPE,then advertise this route to PE through MP-BGP with the new inner label attached; (8) PE distributed the route to CE2 with no label attached. Of course,the LSP should be established between SPE and PE in two directions respectively,This mechanism is the same as RFC 2547bis. The procedure of forwarding VPN packet with the two labels detailed in section 2.3 2.3 Data Flow(Label Operation and Packet Forwarding) This section specifies the mechanism of forwarding the VPN packets in the network with the route and label information derived by section 2.2. The following figure(Figure 3) signifies the data flows between Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 6] Draft November 2002 VPN1 site1 and VPN1 SITE2,the data flows(Label Operation and Packet Forwarding) in the two direction are different,there are five steps in every direction,labeled (1) through (5) in the direction from VPN1 SITE2 to VPN1 site1,and labeled (6) through (10) in the direction from VPN1 site1 to VPN1 SITE2. | (10) | (9) | (8) | (7) | (6) | |<-------|<------|<--------|<-----|<-----| v v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ |VPN1 Site1|-|CE1|---|UPE|---|SPE|---| P |---|PE|--|CE2|-|VPN1 SITE2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ ^ ^ ^ ^ ^ ^ | (1) | (2) | (3) | (4) | (5) | |------->|------>|--------|----->|----->| Figure 3: Data Flow(Label Operation and Packet Forwarding) In Figure 3,the meanings of (1) through (10) are as follows: Label (1) through (5) specifies the forwarding procedure in the direction of VPN1 Site1 visit VPN1 SITE2: (1) When the VPN packet of VPN1 Site1 visit VPN1 SITE2 arrived to CE1, CE1 forward the packet to UPE based on the default route or the route derive from dynamic route protocol between CE1 and UPE specified in the (4) of section 2.2. (2) UPE push the inner label based on the default VRF route,forward the VPN packet to SPE,the inner label and the default VRF route are specified in the (3) of section 2.2. (3) SPE POP the inner label pushed by UPE specified in (2) above,and look up the VRF route,push the new inner label which distributed by PE specified by (2) of section 2.2,then push the outer label distributed by P and forward the VPN packet to P,in backbone network, all the P router in the path of LSP from SPE to PE swap the outer label and forward the VPN packet through this LSP until the packet arrived to PE,or optionally the P router pen-ultimate hop the label. (4) The P router pen-ultimate hop to PE POP the outer label,forward the VPN packet to PE. (5) PE POP the inner label,forward the VPN packet to CE2,then CE2 forward the VPN packet to the VPN1 SITE2 with the route in this site. Label (6) through (10) specifies the forwarding procedure in the direction of VPN1 SITE2 visit VPN1 Site1: (6) When the VPN packet of VPN1 SITE2 visit VPN1 Site1 arrived to CE2, Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 7] Draft November 2002 CE2 forward the packet to PE based on the default route or the route derive from dynamic route protocol between CE2 and PE specified in the (8) of section 2.2. (7) PE push the inner label distributed by SPE specified in (7) of section 2.2 based on the VRF route,then push the outer label distributed by P and forward the VPN packet to P,in backbone network, all the P router in the path of LSP from PE to SPE swap the outer label and forward the VPN packet through this LSP until the P router pen-ultimate hop to SPE. (8) The P router optioanlly pen-ultimate hop to SPE POP the outer label,forward the VPN packet to SPE. (9) SPE swap the inner label in the VPN packet replace the inner label distributed by SPE with the new inner label distributed by UPE specified in (6) of section 2.2,then forward the VPN packet to UPE. (10) UPE POP the new inner label,forward the VPN packet to CE1,then CE1 forward the VPN packet to the VPN1 Site1 with the route in this site. 3. Interface between UPE and SPE UPE can connect to SPE with any type of interface and sub-interface, even with tunnel interface,in this case,UPE can connect with SPE through an IP or MPLS network,and because SPE and UPE are MP-BGP peers,the routes can be advertise directly through TCP connection. In MP-EBGP case,UPE and SPE can set up EBGP peers across the IP network or MPLS network by Multi-hop EBGP,when UPE or SPE forwarding the VPN packets with the label,they must pass a tunnel, if the tunnel is GRE,MPLS encapsulation must be supported;If the tunnel is LSP,the network between UPE ang SPE must be MPLS network, LDP/CR-LDP or RSVP-TE must be supported in UPE and SPE. 4. Nesting of HoPE One HoPE can be composed of a SPE and UPES connected to the SPE, or be composed of a high-level SPE and HoPEs connected the high level SPE and and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connect to the high-level SPE as a role of UPE,and the new HoPE can connect a single UPE too.Figure 4 in the following signifies a three-layer HoPE,and call the PE in the middle layer as MPE(Middle-level PE). Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 8] Draft November 2002 +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +----------+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Site3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +----------+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +----------+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Site3| +----------+ | |--| MPLS |----| | | | +--+ +----------+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ | | +----------+ +----+ | | | | +----------+ +----+ +----+ | | |VPN1 Site4|--|UPE3|--|MPE |------| | +----------+ +----+ +----+ +---+ (Nesting of HoPE) figure 4: Nesting of HoPE Between SPE and MPE,and between MPE and UPE run MP-BGP,if run MP-IBGP,then SPE worked as the route reflector for all the MPE,and MPEs worked as the route reflector for all the UPEs,and MP-BGP advertise all the VPN routes of the underlayer PEs to the upperlayer PE,and advertise the default VRF route or the aggregate route of the upperlayer to the underlayer PE. So SPE maintains all the VPN routes of the whole HoPE,and the MPE maintains the VPN routes of UPEs connected to this MPE.UPE maintain the VPN routes of sites connected to this UPE. SPE advertise the default VRF routes with the label attached to MPE, MPE replaces this label with the new label,and advertise this route with the new label attached to UPE. The upperlayer PE should create a HoPE-wide global import route target list,filter the VPN routes that don't belong to the VPNs connected to this upperlayer PE.MPE converge all the import route target lists of the UPEs connected to this MPE,and SPE converge all the converged import route target lists of the MPEs connected to this SPE.And this convergence can be configured statically or derived dynamically,in the latter case,MPE should forward the import route target list of MPE to SPE through ORF. When the VPN packet from the local site of HoPE is forwarded to UPE, UPE look up the relevant default VRF route,push the label and forward the packet to MPE,MPE POP the label,look up the default VRF Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 9] Draft November 2002 route to SPE,PUSH a new label forward the packet to SPE,SPE POP this label,look up the VRF forwarding table,PUSH the inner label,and the outer label the P router distribute for this route,then follow the RFC 2547bis forwarding procedure. Because MPE has distributes the inner label for the destination address of the VPN packet from the remote site,when the remote VPN packet is forwarded to SPE through the MPLS network following the RFC 2547bis forwarding procedure. SPE swap the inner label,forward this packet to MPE,for the same reason,MPE swap the inner label and forward this packet to UPE,then UPE POP the inner label and forward this packet to the local site. 5. Multi-Homing UPE One UPE can connect to several SPEs,in this case UPE is called Multi-Homing UPE,all the SPEs advertise the default VRF routes to this UPE,and UPE select the best one or treat them as ECMP(Equal Cost Multi-Path) and share the load among them.UPE advertised the VPN routes to all the SPEs,it can advertises all the VPN routes to all the SPEs,or it can advertises one part of VPN routes to one SPE, the other part to the other and shares the load among the SPEs. 6. Backdoor link between UPEs A kind of backdoor link can be setup between UPEs,so that the sites connected to these two UPEs can communicate with each other directly without passing through the SPE.And these UPEs can be those connect to the same SPE,or can be those connect to the different SPE,these UPEs advertise the VPN routes to each other through MP-BGP,The control flow and data flow are the same with RFC 2547bis Procedures, and even theu can cross a network,and the packet can pass through a tunnel such as GRE or LSP. 7. The Forwarding Procedure in Some Special Cases In one case that SPE connect two UPEs called UPE and UPE2,and these two UPEs connect two sites called site1 and site2 respectively,and site1 and site2 belong to the same VPN and visit to each other through SPE.The forwarding procedure is as follows:When the packet sent from site1 arrived to UPE,UPE push the label based on the default route and forward it to SPE,SPE POP this label,then look up the VRF route table,PUSH the label distribute by UPE2 and forward it to UPE2,and UPE2 POP the label,forward it to site2,and in the opposite direction,vise versa. In another case that SPE connect one UPE and one CE,CE connect to site1,UPE connect to site2,site1 and site2 belong to the same VPN. The forwarding procedure is as follows:When the packet with no label sent from site1 arrived to SPE through CE, SPE push the label distributed by UPE,forward it to UPE,UPE POP this label,then look up the VRF route table,PUSH the label distribute by UPE2 and forward it to UPE2,and UPE2 POP the label,forward it to site2. Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 10] Draft November 2002 8. Security Consideration The level of security provided by this architecture is identical to that provided by the RFC 2547bis,there is no security problem introduced. 9. Acknowledgements The authors would like to thank Li Hejun, Cao Xuegui,Chang Wenjun, We are very appreciated for their support 10. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [BGP-ORF] Enke Chen,Yakov Rekhter,"Cooperative Route Filtering Capability for BGP-4",draft-ietf-idr-route-filter-06.txt. [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, September 2000 [RFC2547] E. Rosen, Y. Rekhter, _BGP/MPLS VPNs,_ RFC 2547,March 1999. [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work in progress. 11.0 Author's Address Li Bin D201 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : l.b@huawei.com Dong Weisi C401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : lidefeng@huawei.com Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 11] Draft November 2002 Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 12] --Boundary_(ID_IWid0mMDJrRucPo2alOqnw)-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 6 00:42:16 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 AAA11760 for ; Wed, 6 Nov 2002 00:42:15 -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 gA65i8x06647 for ; Wed, 6 Nov 2002 00:44: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 gA65i6i29524 for ; Wed, 6 Nov 2002 00:44:06 -0500 (EST) Message-Id: <200211060543.OAA73412@infer.nal.ecl.net> To: "Cheng-Yin Lee" cc: "Muneyoshi Suzuki" , ppvpn@nortelnetworks.com Subject: Re: Bridging network or networked bridges In-reply-to: Your message of "05 Nov 2002 22:46:52 EST." <3DC890AC.EA91BCD3@alcatel.com> Date: Wed, 06 Nov 2002 14:43:17 +0900 From: Muneyoshi Suzuki X-SMTP-HELO: infer.nal.ecl.net X-SMTP-MAIL-FROM: suzuki@nal.ecl.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: infer.nal.ecl.net [163.138.70.32] X-LYRIS-Message-Id: Cheng-Yin, Thanks. I summarized the issues but I don't have authority to select a specific approach, it should be decided based on the WG consensus. I'm expecting WG discussion. So, I answer my personal feeling. > > 3. Customer View > > The other issue is how the service instance handles the Bridge protocols > > such as STP/RSTP/MSTP and GARP/GMRP/GVRP transfered through BPDUs, as well > > as, LCAP and MAC control protocol for PAUSE operation received from/sent to > > the customer site. MAC frames used by these protocols are sent to > > multicast addresses. Emulated 1998-style and VLAN-aware Bridges must > > terminate most of these frames, then appropriate action based on the > > standard must be executed. > Is this not in IEEE realm? (in the IEEE entity of the VSI) Odiously the IEEE 802 is responsible for the protocol specification. However, IMHO, emulation technology is the realm of the PPVPN WG. > > On the other hand, emulated LAN and 1982-style Bridge must transparently > > forward most of these frames. This may decrease load in PEs. Note that > > emulated LAN, that learns customer's MAC addresses, and 1982-style Bridge > > must transparently forward customer STP/RSTP/MSTP BPDU frame, because these > > don't join the spanning tree. However, when a customer network topology > > is changed, the MAC address cache in VSIs for the customer should be > > flushed to reduce the time for topology change. So, a STP/RSTP/MSTPsnooping > > mechanism may be required for these implementation. > Are there some inconsistencies in the requirements? > A 1982-style bridge is expected to snoop RSTP/MSTP? I think the snooping mechanism is not indispensable but desired. A 1982-style bridge may also be expected to support it. > > 5.1 Support of VPLS Service > > Therefore, development of new layer 2 technology that supports SP class > > VLAN service is indispensable. Note that the technology to be developed may > > be independent from layer 3 technology such as IP and MPLS. Stacked-VLAN > > aware Bridge, described in section 1, is one of candidates for solution. > Is the PW ID considered a candidate solution? This section does not discuss LAN/Bridge emulation technology such as PWs. > > Encapsulation Bridge which support MAC-in-MAC encapsulation is the other > > candidate. Stacked-VLAN aware Bridge may have to learn customer MAC > > addresses, while MAC-in-MAC may not have to learn these, so the latter > > may be able to reduce MAC address table size. > Is the latter addresses aggregatable, will protocols similar to "routing > protocols" be developed then? We can say it is aggregation. But it seems to me an tunneling/layered/ hierarchical model rather than aggregation. > > Note that there is a possibility that the same MAC addresses are assigned > > to different Ethernet interfaces. VRRP assigns the same virtual MAC > > addresses to different interfaces. Per-VLAN based STP, described in > > section 1, also use a similar scheme. Thus, if a customer uses VLANs in > > the customer network, and if the same MAC addresses appear in different > > customer VLANs, current Stacked-VLAN aware Bridge implementation may not > > distinguish these MAC addresses, because it does not care customer VLAN > > identifiers. > This is an implementation issue? There is no standard that specify a Stacked-VLAN aware Bridge. So, this is an implementation issue. > > The split-horizon forwarding scheme enables loop free MAC frame forwarding. > > A VSI forwards a MAC frame received from a customer to others VSIs, but it > > never forward a frame received from a VSI to another VSI. It also learns > > MAC addresses received from the customer network. Obviously, in this > > scheme, a VSI doesn't emulate a remote-Bridge defined in IEEE 802.1G. > What are the problems of not emulating a remote-Bridge in this case? I think we must identify what is emulated by it, because we must verify conformity with existing LAN/Bridge implementations. Thanks, Muneyoshi Suzuki From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 6 06:32:27 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 GAA12901 for ; Wed, 6 Nov 2002 06:32:27 -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 gA6BYNx13820 for ; Wed, 6 Nov 2002 06:34: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 gA6BYKi00438 for ; Wed, 6 Nov 2002 06:34:20 -0500 (EST) Message-Id: <200211061131.GAA12624@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-as-vr-01.txt Date: Wed, 06 Nov 2002 06:31:03 -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 : Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches Author(s) : A. Nagarajan et al. Filename : draft-ietf-ppvpn-as-vr-01.txt Pages : 17 Date : 2002-11-5 This document is an applicability statement for Layer 3 Provider Provisioned VPNs (L3 PPVPNs) that is based on Virtual Router (VR) approaches. This document describes how VR-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-as-vr-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-as-vr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ppvpn-as-vr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-5193429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-as-vr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-as-vr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193429.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 6 06:34:46 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 GAA13030 for ; Wed, 6 Nov 2002 06:34:46 -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 gA6Babx16481 for ; Wed, 6 Nov 2002 06:36: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 gA6BaZi04441 for ; Wed, 6 Nov 2002 06:36:35 -0500 (EST) Message-Id: <200211061131.GAA12640@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-l3vpn-auth-01.txt Date: Wed, 06 Nov 2002 06:31:09 -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 : CE-to-CE Authentication for Layer 3 VPNs Author(s) : R. Bonica, Y. Rekhter Filename : draft-ietf-ppvpn-l3vpn-auth-01.txt Pages : 0 Date : 2002-11-5 This document describes a CE-based authentication mechanism that PPVPN customers can use to detect security breaches caused by misconfiguration of the provider network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-l3vpn-auth-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-l3vpn-auth-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-l3vpn-auth-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-5193437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-l3vpn-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-l3vpn-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193437.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 6 14:02:53 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 OAA07064 for ; Wed, 6 Nov 2002 14:02:52 -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 gA6J4dx25362 for ; Wed, 6 Nov 2002 14:04:39 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gA6J4ai21144 for ; Wed, 6 Nov 2002 14:04:36 -0500 (EST) From: "Jim Guichard" To: "lidefeng" , Cc: , "Marco Carugi" , , , , , , , , "Fu Y. Miao" , , Subject: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) Date: Wed, 6 Nov 2002 13:58:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <002e01c2854e$84f83ec0$22436e0a@HUAWEI.COM> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: london2.cisco.com [64.103.110.74] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I briefly ran through this draft and it looks like normal hub & spoke using existing 2547 mechanisms - could you explain how this differs ? thanks, > >-----Original Message----- > >From: lidefeng [mailto:lidefeng@huawei.com] > >Sent: Tuesday, November 05, 2002 11:40 PM > >To: internet-drafts@ietf.org > >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >Miao; leh10814@huawei.com; l.b@huawei.com > >Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE > >Device in BGP/MPLS VPN) > > > > > >Hi,all, > > > > In BGP/MPLS VPN area, we proposed a new idea as to resolve > >the bottleneck > >of > >the capacity of some PEs when deploy the huge size VPN,the whole idea is > >detailed > >in the attached > >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >Abstract > >is as follows,we are appreciated for your review. > > > > In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should > > maintain all the VPN routes of the VPNs which it belong to.When there > > are many VPNs converged by a PE,and the capacity of PE is relevant > > limited,then the bottleneck will be encountered.Another problem is > > that the current BGP/MPLS VPN model is something of a "Plane Modle" > > where the demand of the performance of the PE device are all the > > same no matter which layer the PE device is belongs to.However,the > > typical network is "Core-Convergence-Access(Edge)" model,and the > > performance of the device is superior in Core Layer and inferior in > > Access Layer,and the scale of network is large in Access Layer and > > small in Core Layer,the routes are converged in every layer,so in > > current "Plane Modle",when PE device push to the edge layer,it has > > to maintain more VPN routes,this makes it difficult to extend the PE > > device to edge layer.This document defines an model of hiberarchy of > > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider > > Edge Device can be composed of several device and every device take > > on the different part,partake the function of the former > > concentrative PE,we call this model "Hiberarchy Model",In this model > > the demand of performance in Routing and Switching is strict to the > > PE device in High layer,loose to the PE device in edge layer. > > > > One HoPE can be composed of a SPE and UPES connected to the SPE, > > or be composed of a high-level SPE and HoPEs connected the high > > level SPE and and build up a new HoPE.This build is called nesting > > of HoPE,and this kind of nesting can be done for many times.Thus the > > former HoPE connect to the high-level SPE as a role of UPE,and the > > new HoPE can connect a single UPE too. > > > >Regards > > > >Defeng Li > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 6 18:29: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 SAA16855 for ; Wed, 6 Nov 2002 18:29:12 -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 gA6NUkx28135 for ; Wed, 6 Nov 2002 18:30:46 -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 gA6NUii05704 for ; Wed, 6 Nov 2002 18:30:44 -0500 (EST) Message-Id: <4.3.2.7.2.20021106194857.028ad4d0@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Nov 2002 23:10:17 +0000 To: Ron Bonica , PPVPN@NORTELNETWORKS.COM From: "Michael H. Behringer" Subject: Re: draft-behringer-mpls-vpn-auth-00 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: mbehring@cisco.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: amsterdam.cisco.com [144.254.74.238] X-LYRIS-Message-Id: Ron, Thanks a lot for your feedback. Please see inline. At 01:23 06/11/2002, Ron Bonica wrote: >Michael, > >Can you address the following issues: > >1) Many VPN sites don't use any PE-CE signaling protocol at all. The CE >points default at the PE. The PE points a few static routes at the CE. True. Our scheme requires a routing protocol between CE and PE. >2) Customers may object to being told that they need to use the same MD5 >authentication key at every site. True. They might. We need to check with customers whether this would be acceptable. Of course this is only required on the PE-CE links. >3) Customers who MD5 authenticate BGP peering sessions may want to change >the MD5 key periodically. This isn't too painful if you don't have to change >all of the keys at once. It is impossible if the customer has many hundreds >of sites and you need to change all of the keys at once. One way of handling this is key-chains and soft roll-over, as it exists today for IS-IS and OSPF for example. Thanks for your feedback! Michael >=========================================== >Ronald P. Bonica Ph: 703 886 1681 >vBNS Engineering page: 1 888 268 8021 >Ashburn, Va. >=========================================== >"We are not on Earth to guard a museum, but >to cultivate a flourishing garden of life." > -- Angelo Giuseppe Roncalli From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 6 19:11:06 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 TAA17797 for ; Wed, 6 Nov 2002 19:11:06 -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 gA70D2x09182 for ; Wed, 6 Nov 2002 19:13: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 gA70D0i22696 for ; Wed, 6 Nov 2002 19:13:00 -0500 (EST) Message-Id: <200211070012.gA70Cm828384@zrtps0km.us.nortel.com> From: Jorge To: ppvpn@nortelnetworks.com Subject: Felicidades!!!! Sender: Jorge Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 6 Nov 2002 19:19:23 -0500 X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-Priority: 1 X-SMTP-HELO: 210.73.150.67 X-SMTP-MAIL-FROM: sandy@psyknet.dk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [211.21.61.242] X-LYRIS-Message-Id:

 

FELICIDADES!!!!

 

Usted y su familia han sido elegidos para participar con nosotros de 8 dias y 7 noches inolvidables, donde tendra la oportunidad de mezclar el magico Mundo de Disney, las exclusivas playas del sur de la Florida y el exotico encanto de un crucero a Las Islas Bahamas.

 

        

Llame gratis en EE UU y Puerto Rico al 1-800-546-8034

Fuera de EE UU, llame al 001-305-264-6888

Su número de confirmación: R-11052

Para reclamar su premio llame dentro de las proximas 48 horas. Oferta valida para una familia.

Horario de atencion de Lunes a Sabado de 9:00 a.m. a  9:00 p.m.  hora de Miami
From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 02:41:01 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 CAA06205 for ; Thu, 7 Nov 2002 02:41: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 gA77gka16842 for ; Thu, 7 Nov 2002 02:42:47 -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 gA77ghm10081 for ; Thu, 7 Nov 2002 02:42:44 -0500 (EST) Date: Thu, 07 Nov 2002 15:42:15 +0800 From: =?gb2312?B?wO6x8w==?= Subject: =?gb2312?B?tPC4tDogUGxlYXNlIFJldmlldzogQSBuZXcgZHJhZnQgYWJvdXQgUA==?= =?gb2312?B?UFZQTihIaWJlcmFyY2h5IG9mIFBFIERldmljZSBpbkJHUC9NUExTIFZQTik=?= In-reply-to: To: Jim Guichard Cc: internet-drafts@ietf.org, rwilder@masergy.com, "Marco Carugi" , sob@harvard.edu, bwijnen@lucent.com, zinin@psg.com, ppvpn@nortelnetworks.com, lhj@huawei.com, Gma@futurewei.com, changwj@huawei.com, "Fu Y. Miao" , leh10814@huawei.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id CAA06205 Hi, Guichard The hub & spoke is the relationship between CEs, but SPE peer with UPE by MP-BGP, they are all PEs, and they all can admit VPN user. Libin -----ԭʼÓʼþ----- ·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] ·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org ³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; leh10814@huawei. com; l.b@huawei.com Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) I briefly ran through this draft and it looks like normal hub & spoke using existing 2547 mechanisms - could you explain how this differs ? thanks, > >-----Original Message----- > >From: lidefeng [mailto:lidefeng@huawei.com] > >Sent: Tuesday, November 05, 2002 11:40 PM > >To: internet-drafts@ietf.org > >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >Miao; leh10814@huawei.com; l.b@huawei.com > >Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE > >Device in BGP/MPLS VPN) > > > > > >Hi,all, > > > > In BGP/MPLS VPN area, we proposed a new idea as to resolve > >the bottleneck > >of > >the capacity of some PEs when deploy the huge size VPN,the whole idea is > >detailed > >in the attached > >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >Abstract > >is as follows,we are appreciated for your review. > > > > In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should > > maintain all the VPN routes of the VPNs which it belong to.When there > > are many VPNs converged by a PE,and the capacity of PE is relevant > > limited,then the bottleneck will be encountered.Another problem is > > that the current BGP/MPLS VPN model is something of a "Plane Modle" > > where the demand of the performance of the PE device are all the > > same no matter which layer the PE device is belongs to.However,the > > typical network is "Core-Convergence-Access(Edge)" model,and the > > performance of the device is superior in Core Layer and inferior in > > Access Layer,and the scale of network is large in Access Layer and > > small in Core Layer,the routes are converged in every layer,so in > > current "Plane Modle",when PE device push to the edge layer,it has > > to maintain more VPN routes,this makes it difficult to extend the PE > > device to edge layer.This document defines an model of hiberarchy of > > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider > > Edge Device can be composed of several device and every device take > > on the different part,partake the function of the former > > concentrative PE,we call this model "Hiberarchy Model",In this model > > the demand of performance in Routing and Switching is strict to the > > PE device in High layer,loose to the PE device in edge layer. > > > > One HoPE can be composed of a SPE and UPES connected to the SPE, > > or be composed of a high-level SPE and HoPEs connected the high > > level SPE and and build up a new HoPE.This build is called nesting > > of HoPE,and this kind of nesting can be done for many times.Thus the > > former HoPE connect to the high-level SPE as a role of UPE,and the > > new HoPE can connect a single UPE too. > > > >Regards > > > >Defeng Li > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 06:27: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 GAA11389 for ; Thu, 7 Nov 2002 06:27: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 gA7BTna19562 for ; Thu, 7 Nov 2002 06:29:49 -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 gA7BTkm12265 for ; Thu, 7 Nov 2002 06:29:46 -0500 (EST) Message-Id: <200211071126.GAA11180@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-tc-mib-02.txt Date: Thu, 07 Nov 2002 06:26:48 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Definition of Textual Conventions for Provider Provisioned Virtual Private Network (PPVPN) Management Author(s) : B. Schliesser, T. Nadeau Filename : draft-ietf-ppvpn-tc-mib-02.txt Pages : 7 Date : 2002-11-6 This document describes Textual Conventions used for managing PPVPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-tc-mib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-tc-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ppvpn-tc-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-6175129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-tc-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-tc-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6175129.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 06:31:02 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 GAA11715 for ; Thu, 7 Nov 2002 06:31:01 -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 gA7BWSa23121 for ; Thu, 7 Nov 2002 06:32: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 gA7BWPm16790 for ; Thu, 7 Nov 2002 06:32:25 -0500 (EST) Message-Id: <200211071127.GAA11225@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-vr-mib-03.txt Date: Thu, 07 Nov 2002 06:27:03 -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 : Virtual Router Management Information Base Using SMIv2 Author(s) : E. Stelzer, S. Hancock, B. Schliesser Filename : draft-ietf-ppvpn-vr-mib-03.txt Pages : 24 Date : 2002-11-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In paticular, it defines objects for managing networks using Virtual Routers (VR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vr-mib-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-vr-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ppvpn-vr-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-6175157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-vr-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-vr-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6175157.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 06:33:31 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 GAA11852 for ; Thu, 7 Nov 2002 06:33: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 gA7BZ8a26786 for ; Thu, 7 Nov 2002 06:35: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 gA7BZ2m21301 for ; Thu, 7 Nov 2002 06:35:03 -0500 (EST) Message-Id: <200211071126.GAA11208@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-requirements-05.txt Date: Thu, 07 Nov 2002 06:26:57 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : Service requirements for Provider Provisioned Virtual Private Networks Author(s) : M. Carugi, D. McDysan Filename : draft-ietf-ppvpn-requirements-05.txt Pages : 47 Date : 2002-11-6 This document provides requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use for the provisioning of a VPN service. This document expresses a service provider perspective, based upon past experience of IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer as well as a service provider perspective. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-requirements-05.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-requirements-05.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-requirements-05.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-6175149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-requirements-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-requirements-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6175149.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 06:38:19 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 GAA12178 for ; Thu, 7 Nov 2002 06:38:19 -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 gA7BeDa03789 for ; Thu, 7 Nov 2002 06:40: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 gA7Be9m00060 for ; Thu, 7 Nov 2002 06:40:10 -0500 (EST) Message-Id: <200211071126.GAA11193@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-mpls-vpn-mib-05.txt Date: Thu, 07 Nov 2002 06:26:52 -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 : MPLS/BGP Virtual Private Network Management Information Base Using SMIv2 Author(s) : T. Nadeau et al. Filename : draft-ietf-ppvpn-mpls-vpn-mib-05.txt Pages : 50 Date : 2002-11-6 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, in response to customer demands and strong input from vendors, it describes managed objects for modeling and managing Multi-Protocol Label Switching (MPLS) [MPLSArch]/Border Gateway Protocol (BGP) Virtual Private Networks (VPNs) [RFC2547bis]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-mpls-vpn-mib-05.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-mpls-vpn-mib-05.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-mpls-vpn-mib-05.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-6175138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-mpls-vpn-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-mpls-vpn-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6175138.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 09:39:11 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 JAA26162 for ; Thu, 7 Nov 2002 09:39:10 -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 gA7Ef5f03979 for ; Thu, 7 Nov 2002 09:41: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 gA7Ef1s20421 for ; Thu, 7 Nov 2002 09:41:01 -0500 (EST) Message-ID: <014f01c28669$d05318b0$d75510ac@temp0er> From: "Mitsuru Higashiyama" To: "W. Mark Townsley" , Cc: , , , References: <200211011519.gA1FJY601724@tcb.net> <3DC2D23D.FFF906F4@alcatel.com> <3DC2DC33.5000807@cisco.com> <3DC2DF8C.5F0033E@alcatel.com> <3DC2EBA8.9020006@cisco.com> <3DC2F00E.AA52A419@alcatel.com> <3DC785EE.5000706@cisco.com> Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00 Date: Thu, 7 Nov 2002 23:27:34 +0900 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.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-SMTP-HELO: ns.anritsu.co.jp X-SMTP-MAIL-FROM: Mitsuru.Higashiyama@yy.anritsu.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ns.anritsu.co.jp [133.236.48.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Mark, I have a questions. > P2MP wire properties fall within the "could" rhelm of PWE3 (as chartered), and > the discussion on this thread has been more about whether they "should" or not. > Most of the current mindshare on this topic is within PPVPN, particularly on the > subject of a "bridged network or network of bridges" debate. P2MP wire discussion will be in PPVPN and return back to PWE3 if there is request to packet format. Is it correct ? > So, to the WGs I would ask, where do CE-based L2VPNs lie? I would prefer within > the same group working on the larger issue of ppvpns. This would require at > least a section detailing how it looks when the PE and the CE are collapsed into > a single box, and perhaps any associated provider-specific requirements are > adjusted to "customer"-specific requirements. I would like PPVPN deal with CE-base include multi-point issue. Thanks, Mitsuru > > Would the ppvpn WG be willing to cover this (with Cheng-yin's help, of course!)? > > Thanks, > > - Mark > > > > > Sorry, I have to go now, but will catch up with this later. > > > > thanks > > cheng-yin > > > > Stewart Bryant wrote: > > > > > >>As I read this draft you are setting up individual PWs using > >>L2TP and then bridging across them. The bridging function > >>belongs in the FWRD component. I was working on the assumption > >>that FWRD was outside the scope of PWE3 (I had assumed that it > >>belonged to PPVPN). I am not sure why we would move it back in > >>scope, and if we did how we would set the demarcation with > >>PPVPN. > >> > >>The present (implicit) restriction of PW to pt-pt Ethernet > >>provides a clean functional divide between transmission > >>and forwarding. > >> > >>Stewart > >> > >>Cheng-Yin Lee wrote: > >> > >>>Stewart, > >>> > >>>Stewart Bryant wrote: > >>> > >>> > >>> > >>>>Cheng-Yin > >>>> > >>>>To clarify: the sort of thing that you have in mind is to > >>>>explicitly cover the multicasting of Ethernet over the WAN > >>>>using something like IP or MPLS multicast? > >>> > >>> > >>>No, No, No ! :-). I agree with you that "I am not sure the saving in packet > >>>replication justifies the complexity ..." > >>> > >>>I meant something like in draft-lee-l2tpext-pwe3-vpl-00.txt, encapsulating Ethernet in > >>>L2TPv3 and bridging at an LCCE. > >>>A side note is that a PPVPN/PPVPL may have additional requirements besides the > >>>emulation of an Ethernet wire. > >>> > >>>regards, > >>>cheng-yin. > >>> > >>> > >>> > >>>>Although this is not explicitly called out, you can do this > >>>>with the specs as they exist today, by for example, using > >>>>L2TPv3 in manual configuration mode and using an IP multicast > >>>>address as the IP DA. > >>>> > >>>>Is there anyone who has an application for this mode? > >>>> > >>>>The only use that I can see for this is to avoid replication > >>>>of broadcast packets when building a L2VPN, but I am not sure > >>>>the saving in packet replication justifies the complexity of > >>>>effectively running two parallel PW networks (ie the broadcast > >>>>network plus the point to point mesh). However that is a call > >>>>that the PPVPN WG need to make. > >>>> > >>>>Regards > >>>> > >>>>Stewart > >>>> > >>>>Cheng-Yin Lee wrote: > >>>> > >>>> > >>>>>Danny, > >>>>>I was referring to Ethernet specifically in my previous email > >>>>>http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03096.h tml > >>>>>The Ethernet 'wire' inherently allows broadcasting. In my view, a bridge emulates > >>>>>an Ethernet 'wire'. OTOH, whether bridging is done at PE/L2PE/CE, I believe, is > >>>>>out of the scope of PWE3. > >>>>> > >>>>>For services where multipoint transmission is not a property of the "wire", I > >>>>>agree multipoint discussion is out of scope. > >>>>> > >>>>>thanks > >>>>>cheng-yin > >>>>> > >>>>>Danny McPherson wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>Creating a multi-point system out of p2p wires is definitely a PPVPN > >>>>>>>function rather than a PWE3 function. But that doesn't rule out the > >>>>>>>possibility of PWE3 defining a p2mp wire of some sort. Whether such a thing > >>>>>>>is actually needed is an open question. > >>>>>> > >>>>>>I tend to agree with Eric here and would like to see some > >>>>>>discussion of drivers for the work. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>I think this should just be punted for now, left "for further study". > >>>>>> > >>>>>>My first inclination is to agree. However, begin that there is > >>>>>>apparent interest and it's technically chartered (at least in the > >>>>>>case of Ethernet), we should at least give it some opportunity for > >>>>>>consideration. > >>>>>> > >>>>>>I'd be interested in what others think... > >>>>>> > >>>>>>-danny > >>>>>> > >>>>>>_______________________________________________ > >>>>>>pwe3 mailing list > >>>>>>pwe3@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>pwe3 mailing list > >>>>>pwe3@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>> > >>>>> > >>>> > >>> > >>> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 11:05:28 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 LAA29908 for ; Thu, 7 Nov 2002 11:05:27 -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 gA7G7If25227 for ; Thu, 7 Nov 2002 11:07:19 -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 gA7G7Ds11088 for ; Thu, 7 Nov 2002 11:07:15 -0500 (EST) From: "Jim Guichard" To: "=?gb2312?B?qKQ/ocCorg==?=" Cc: , , "Marco Carugi" , , , , , , , , "Fu Y. Miao" , Subject: =?gb2312?B?UkU6ILTwuLQ6IFBsZWFzZSBSZXZpZXc6IEEgbmV3IGRyYWZ0IGFibw==?= =?gb2312?B?dXQgUFBWUE4oSGliZXJhcmNoeSBvZiBQRSBEZXZpY2UgaW5CR1AvTQ==?= =?gb2312?B?UExTIFZQTik=?= Date: Thu, 7 Nov 2002 11:00:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-MIME-Autoconverted: from 8bit to quoted-printable by cisco.com id QAA21980 X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: london2.cisco.com [64.103.110.74] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA29908 so can hub&spoke with 2547 - you basically export routes from the CE-attached PEs to a hub PE that imports the routes. The hub PE exports either a default or aggregates to attract traffic from other CE-attached PEs and then performs a lookup to forward the packets to other CE-attached PEs .. Jim > >-----Original Message----- > >From: Àî±ó [mailto:l.b@huawei.com] > >Sent: Thursday, November 07, 2002 2:42 AM > >To: Jim Guichard > >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >marco.carugi@nortelnetworks.com; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >Miao; leh10814@huawei.com > >Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy > >of PE Device inBGP/MPLS VPN) > > > > > >Hi, Guichard > >The hub & spoke is the relationship between CEs, but SPE peer > >with UPE by MP-BGP, they are all PEs, and they all can admit VPN user. > > > >Libin > > > >-----ԭʼÓʼþ----- > >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei. > >com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; leh10814@huawei. > >com; l.b@huawei.com > >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE Device > >inBGP/MPLS VPN) > > > > > >I briefly ran through this draft and it looks like normal hub & > >spoke using > >existing 2547 mechanisms - could you explain how this differs ? thanks, > > > >> >-----Original Message----- > >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >To: internet-drafts@ietf.org > >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >> >Miao; leh10814@huawei.com; l.b@huawei.com > >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE > >> >Device in BGP/MPLS VPN) > >> > > >> > > >> >Hi,all, > >> > > >> > In BGP/MPLS VPN area, we proposed a new idea as to resolve > >> >the bottleneck > >> >of > >> >the capacity of some PEs when deploy the huge size VPN,the > >whole idea is > >> >detailed > >> >in the attached > >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >> >Abstract > >> >is as follows,we are appreciated for your review. > >> > > >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >Edge)Device should > >> > maintain all the VPN routes of the VPNs which it belong > >to.When there > >> > are many VPNs converged by a PE,and the capacity of PE is relevant > >> > limited,then the bottleneck will be encountered.Another problem is > >> > that the current BGP/MPLS VPN model is something of a "Plane Modle" > >> > where the demand of the performance of the PE device are all the > >> > same no matter which layer the PE device is belongs to.However,the > >> > typical network is "Core-Convergence-Access(Edge)" model,and the > >> > performance of the device is superior in Core Layer and inferior in > >> > Access Layer,and the scale of network is large in Access Layer and > >> > small in Core Layer,the routes are converged in every layer,so in > >> > current "Plane Modle",when PE device push to the edge layer,it has > >> > to maintain more VPN routes,this makes it difficult to > >extend the PE > >> > device to edge layer.This document defines an model of > >hiberarchy of > >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider > >> > Edge Device can be composed of several device and every device take > >> > on the different part,partake the function of the former > >> > concentrative PE,we call this model "Hiberarchy Model",In > >this model > >> > the demand of performance in Routing and Switching is strict to the > >> > PE device in High layer,loose to the PE device in edge layer. > >> > > >> > One HoPE can be composed of a SPE and UPES connected to the SPE, > >> > or be composed of a high-level SPE and HoPEs connected the high > >> > level SPE and and build up a new HoPE.This build is called nesting > >> > of HoPE,and this kind of nesting can be done for many > >times.Thus the > >> > former HoPE connect to the high-level SPE as a role of UPE,and the > >> > new HoPE can connect a single UPE too. > >> > > >> >Regards > >> > > >> >Defeng Li > >> > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 11:10:53 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 LAA00172 for ; Thu, 7 Nov 2002 11:10:52 -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 gA7GCmf01400 for ; Thu, 7 Nov 2002 11:12: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 gA7GCis19778 for ; Thu, 7 Nov 2002 11:12:45 -0500 (EST) From: "Ferit Yegenoglu" To: "Michael H. Behringer" , "Ron Bonica" , Subject: RE: draft-behringer-mpls-vpn-auth-00 Date: Thu, 7 Nov 2002 11:08:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <4.3.2.7.2.20021106194857.028ad4d0@madrid.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-SMTP-HELO: mail.san.yahoo.com X-SMTP-MAIL-FROM: ferit@isocore.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: mail.san.yahoo.com [209.132.1.30] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Michael, I am also not convinced on the practicality of using the same key on all CEs belonging to the same VPN and for PE-PE authentication when exchanging routes for this VPN and updating these keys seamlessly. However, I have a more specific question - how do you address the case where a CE belongs to multiple VPNs? Can you still have the same keys used on all CE-PE, PE-PE, and PE-CE segments? I am assuming that the PE that this CE connects to has to use K1 when advertising this CE's routes to VPN1 and K2 when advertising them to VPN2. Does not this reintroduce the possibility of misconfiguration that your approach was attempting to eliminate? Can you comment? Regards, Ferit -----Original Message----- From: Michael H. Behringer [mailto:mbehring@cisco.com] Sent: Wednesday, November 06, 2002 6:10 PM To: Ron Bonica; PPVPN@NORTELNETWORKS.COM Subject: Re: draft-behringer-mpls-vpn-auth-00 Ron, Thanks a lot for your feedback. Please see inline. At 01:23 06/11/2002, Ron Bonica wrote: >Michael, > >Can you address the following issues: > >1) Many VPN sites don't use any PE-CE signaling protocol at all. The CE >points default at the PE. The PE points a few static routes at the CE. True. Our scheme requires a routing protocol between CE and PE. >2) Customers may object to being told that they need to use the same MD5 >authentication key at every site. True. They might. We need to check with customers whether this would be acceptable. Of course this is only required on the PE-CE links. >3) Customers who MD5 authenticate BGP peering sessions may want to change >the MD5 key periodically. This isn't too painful if you don't have to change >all of the keys at once. It is impossible if the customer has many hundreds >of sites and you need to change all of the keys at once. One way of handling this is key-chains and soft roll-over, as it exists today for IS-IS and OSPF for example. Thanks for your feedback! Michael >=========================================== >Ronald P. Bonica Ph: 703 886 1681 >vBNS Engineering page: 1 888 268 8021 >Ashburn, Va. >=========================================== >"We are not on Earth to guard a museum, but >to cultivate a flourishing garden of life." > -- Angelo Giuseppe Roncalli From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 11:22:36 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 LAA00713 for ; Thu, 7 Nov 2002 11:22:36 -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 gA7GOVf02934 for ; Thu, 7 Nov 2002 11:24:31 -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 gA7GOSs00944 for ; Thu, 7 Nov 2002 11:24:28 -0500 (EST) From: "Jim Guichard" To: "Ferit Yegenoglu" , "Michael H. Behringer" , "Ron Bonica" , Subject: RE: draft-behringer-mpls-vpn-auth-00 Date: Thu, 7 Nov 2002 11:19:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: london2.cisco.com [64.103.110.74] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Ferit, the currently published draft was published in error and is the wrong version - we will update with the correct version as soon as we are able (we cannot publish the draft at this time). However, to answer your specific question. The intention is to create a 'generator' value at the exporting PE router and then run the key against the 'generator'. This will be advertised, along with the hash, within the MP-BGP update and the importing PE router can use its local key against the 'generator' and compare the result with the hash. If the VPN is extranet then clearly their might be multiple keys which would imply either a) trying each key against the 'generator' or b) selecting the key based on incoming RT value for the update. Jim > >-----Original Message----- > >From: Ferit Yegenoglu [mailto:ferit@isocore.com] > >Sent: Thursday, November 07, 2002 11:09 AM > >To: Michael H. Behringer; Ron Bonica; PPVPN@NORTELNETWORKS.COM > >Subject: RE: draft-behringer-mpls-vpn-auth-00 > > > > > > > >Michael, > > > >I am also not convinced on the practicality of using the same > >key on all CEs > >belonging to the same VPN and for PE-PE authentication when exchanging > >routes for this VPN and updating these keys seamlessly. > > > >However, I have a more specific question - how do you address > >the case where > >a CE belongs to multiple VPNs? Can you still have the same keys > >used on all > >CE-PE, PE-PE, and PE-CE segments? I am assuming that the PE that this CE > >connects to has to use K1 when advertising this CE's routes to > >VPN1 and K2 > >when advertising them to VPN2. Does not this reintroduce the > >possibility of > >misconfiguration that your approach was attempting to eliminate? Can you > >comment? > > > >Regards, > >Ferit > > > >-----Original Message----- > >From: Michael H. Behringer [mailto:mbehring@cisco.com] > >Sent: Wednesday, November 06, 2002 6:10 PM > >To: Ron Bonica; PPVPN@NORTELNETWORKS.COM > >Subject: Re: draft-behringer-mpls-vpn-auth-00 > > > > > >Ron, > > > >Thanks a lot for your feedback. Please see inline. > > > >At 01:23 06/11/2002, Ron Bonica wrote: > >>Michael, > >> > >>Can you address the following issues: > >> > >>1) Many VPN sites don't use any PE-CE signaling protocol at all. The CE > >>points default at the PE. The PE points a few static routes at the CE. > > > >True. Our scheme requires a routing protocol between CE and PE. > > > >>2) Customers may object to being told that they need to use the same MD5 > >>authentication key at every site. > > > >True. They might. We need to check with customers whether this would be > >acceptable. Of course this is only required on the PE-CE links. > > > >>3) Customers who MD5 authenticate BGP peering sessions may want > >to change > >>the MD5 key periodically. This isn't too painful if you don't have to > >change > >>all of the keys at once. It is impossible if the customer has > >many hundreds > >>of sites and you need to change all of the keys at once. > > > >One way of handling this is key-chains and soft roll-over, as it exists > >today for IS-IS and OSPF for example. > > > >Thanks for your feedback! > >Michael > > > > > >>=========================================== > >>Ronald P. Bonica Ph: 703 886 1681 > >>vBNS Engineering page: 1 888 268 8021 > >>Ashburn, Va. > >>=========================================== > >>"We are not on Earth to guard a museum, but > >>to cultivate a flourishing garden of life." > >> -- Angelo Giuseppe Roncalli > > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 11:24:40 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 LAA00796 for ; Thu, 7 Nov 2002 11:24:40 -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 gA7GQWf04540 for ; Thu, 7 Nov 2002 11:26:33 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gA7GQUs04682 for ; Thu, 7 Nov 2002 11:26:30 -0500 (EST) Message-ID: From: Sasha Vainshtein To: "'ppvpn@nortelnetworks.com'" Subject: FW: Doubts regarding draft-sajassi-mvpls-00.txt Date: Thu, 7 Nov 2002 18:22:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" X-SMTP-HELO: antivir1 X-SMTP-MAIL-FROM: Sasha@AXERRA.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [80.74.100.67] X-LYRIS-Message-Id: With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Sasha Vainshtein > Sent: Thursday, November 07, 2002 6:17 PM > To: 'sajassi@cisco.com'; 'hsalama@cisco.com' > Cc: Ppvpn (E-mail 2); PWE3 WG (E-mail); Eric Rosen (E-mail) > Subject: Doubts regarding draft-sajassi-mvpls-00.txt > > > Ali, Hussein and all, > I have serious doubts regarding draft-sajassi-mvpls-00.txt. > I would highly appreciate clarification on the following issues: > > 1. The draft, as posted, assumes that a unique unicast IP > address is allocated for > each Attachment Circuit connecting a customer site > participating in the MVPLS > with its adjacent PE. (The draft considers the option > that such an address > is allocated per PE per VPLS "due to PE limitations"). > IMHO this raises strong > scalability issues especially when dealing with IPv4 > networks, because > IP addresses that are unique within at least within the > scope of the provider's > network are a scarce resource. (I think that similar > issues have been > raised by Eric Rosen in his comments on > draft-ietf-ppvpn-cl-tunneling-vpn-00.txt > that have been posted on the PPVPN WG list) > > 2. The common approach to PWE3 and PPVPN assumes (and this is > reflected, > e.g., in the PWE3 charter) that these activities affect > only PEs but not the > core routers in the provider's network. IMHO your > approach contradicts > this approach because: > a) Adding a new VPLS instance requires allocation of a > new multicast IP > address, and all the PE devices participating in this > VPLS instance > must join the multicast group associated with this address > b) Adding a new Attachment Circuit requires an IGP update so that > the network "learns" routes to the associated IP address > c) AFAIK, each of these operations affects all the routers in the > provider's network. > > 3. In Section 8 you describe the process of forwarding of > "known unicast" > frames in the egress PE like following: > > When an egress PE receives a unicast MVPLS packet > from the core, it > performs the MAC SA lookup, and possibly learning, > as has been > described in Section 8.2. The egress PE does not > lookup the MAC DA of > the received frame since the destination IP address > of the received > packet readily identifies the interface associated > with the AC. The > packet is immediately delivered to that interface. > The IP header and > the L2TPv3 header are removed before the Ethernet > frame gets forwarded > over the AC towards its destination. > > > This text raises several questions: > a) How does the PE distinguish between the MVPLS packet > and any other > packet with the destination address that has been allocated > for the Attachment Circuit? IMHO, the vague reference to L2TPv3 > is not sufficient, because the L2TPv3 switching engine would > most probably just discard the packet with an unknown Session > ID - and in order to make the Session ID known to this engine, > it must be explicitly set up - via signaling or manually. > In other words, your forwarding decisions seem to prevent > "normal" usage of L2TPv3 in the same PE > b) How are other packets with this destination address (e.g., > the ICMP Echo) processed? In other words, is the IP address > associated with the AC in this PE treated as one of the > IP addresses of the PE, or not? > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 12:24: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 MAA03022 for ; Thu, 7 Nov 2002 12:24:23 -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 gA7HQIf04031 for ; Thu, 7 Nov 2002 12:26:18 -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 gA7HQFs05373 for ; Thu, 7 Nov 2002 12:26:15 -0500 (EST) Date: Thu, 07 Nov 2002 12:08:27 -0500 From: Ron Bonica Subject: RE: draft-behringer-mpls-vpn-auth-00 In-reply-to: <4.3.2.7.2.20021106194857.028ad4d0@madrid.cisco.com> To: "Michael H. Behringer" , PPVPN@NORTELNETWORKS.COM Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: pmesmtp02.wcom.com X-SMTP-MAIL-FROM: Ronald.P.Bonica@wcom.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: pmesmtp02.wcom.com [199.249.20.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > >3) Customers who MD5 authenticate BGP peering sessions may want to change > >the MD5 key periodically. This isn't too painful if you don't > have to change > >all of the keys at once. It is impossible if the customer has > many hundreds > >of sites and you need to change all of the keys at once. > > One way of handling this is key-chains and soft roll-over, as it exists > today for IS-IS and OSPF for example. > How would this work? Ron From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 13:15: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 NAA04998 for ; Thu, 7 Nov 2002 13:15: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 gA7IHlf18367 for ; Thu, 7 Nov 2002 13:17:47 -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 gA7IHis26937 for ; Thu, 7 Nov 2002 13:17:44 -0500 (EST) Message-Id: <4.3.2.7.2.20021107181131.02c00840@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Nov 2002 18:16:23 +0000 To: Ron Bonica , PPVPN@NORTELNETWORKS.COM From: "Michael H. Behringer" Subject: RE: draft-behringer-mpls-vpn-auth-00 In-Reply-To: References: <4.3.2.7.2.20021106194857.028ad4d0@madrid.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: mbehring@cisco.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: amsterdam.cisco.com [144.254.74.238] X-LYRIS-Message-Id: At 17:08 07/11/2002, Ron Bonica wrote: > > >3) Customers who MD5 authenticate BGP peering sessions may want to change > > >the MD5 key periodically. This isn't too painful if you don't > > have to change > > >all of the keys at once. It is impossible if the customer has > > many hundreds > > >of sites and you need to change all of the keys at once. > > > > One way of handling this is key-chains and soft roll-over, as it exists > > today for IS-IS and OSPF for example. > >How would this work? Ron, For using routing authentication on IGPs such as ISIS, OSPF, it would be impossible to change all keys at the same time. So one defines a key chain, which contains the old key, and the new key. The algorithm basically checks both keys. Once you have rolled over to the new keys, you remove the old ones from the key chain. Michael From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 14:31:29 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 OAA07304 for ; Thu, 7 Nov 2002 14:31: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 gA7JXKf02085 for ; Thu, 7 Nov 2002 14:33: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 gA7JXHs23951 for ; Thu, 7 Nov 2002 14:33:17 -0500 (EST) Message-ID: <3DCABFA2.9040502@cisco.com> Date: Thu, 07 Nov 2002 19:31:46 +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: Mitsuru Higashiyama CC: "W. Mark Townsley" , Cheng-Yin.Lee@alcatel.com, danny@tcb.net, pwe3@ietf.org, ppvpn@nortelnetworks.com Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00 References: <200211011519.gA1FJY601724@tcb.net> <3DC2D23D.FFF906F4@alcatel.com> <3DC2DC33.5000807@cisco.com> <3DC2DF8C.5F0033E@alcatel.com> <3DC2EBA8.9020006@cisco.com> <3DC2F00E.AA52A419@alcatel.com> <3DC785EE.5000706@cisco.com> <014f01c28669$d05318b0$d75510ac@temp0er> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: stbryant@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mrwint.cisco.com [144.254.98.48] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > > P2MP wire discussion will be in PPVPN and return back to PWE3 if there is > request to packet format. Is it correct ? > That looks to me to be the best way forward to me. Stewart From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 15:01:36 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 PAA08677 for ; Thu, 7 Nov 2002 15:01:35 -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 gA7K3Vf14228 for ; Thu, 7 Nov 2002 15:03:32 -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 gA7K3Ss00504 for ; Thu, 7 Nov 2002 15:03:29 -0500 (EST) Message-Id: <4.3.2.7.2.20021107104923.01c94318@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Nov 2002 12:02:36 -0800 To: Sasha Vainshtein , "'sajassi@cisco.com'" , "'hsalama@cisco.com'" From: Ali Sajassi Subject: Re: Doubts regarding draft-sajassi-mvpls-00.txt Cc: ppvpn@nortelnetworks.com, "PWE3 WG (E-mail)" , "Eric Rosen (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: Sasha, Thanks for your comments and inquiry. Please see my reply inline. At 06:16 PM 11/7/2002 +0200, Sasha Vainshtein wrote: >Ali, Hussein and all, >I have serious doubts regarding draft-sajassi-mvpls-00.txt. >I would highly appreciate clarification on the following issues: > >1. The draft, as posted, assumes that a unique unicast IP address is >allocated for > each Attachment Circuit connecting a customer site participating in the >MVPLS > with its adjacent PE. (The draft considers the option that such an >address > is allocated per PE per VPLS "due to PE limitations"). IMHO this raises >strong > scalability issues especially when dealing with IPv4 networks, because > IP addresses that are unique within at least within the scope of the >provider's > network are a scarce resource. (I think that similar issues have been > raised by Eric Rosen in his comments on >draft-ietf-ppvpn-cl-tunneling-vpn-00.txt > that have been posted on the PPVPN WG list) Within the scope of the provider's network, the private address block [RFC1918] can be used which can provide very large number of IP addresses to address the scalability concern. >2. The common approach to PWE3 and PPVPN assumes (and this is reflected, > e.g., in the PWE3 charter) that these activities affect only PEs but not >the > core routers in the provider's network. IMHO your approach contradicts > this approach because: > a) Adding a new VPLS instance requires allocation of a new multicast IP > address, and all the PE devices participating in this VPLS instance > must join the multicast group associated with this address > b) Adding a new Attachment Circuit requires an IGP update so that > the network "learns" routes to the associated IP address > c) AFAIK, each of these operations affects all the routers in the > provider's network. As described in draft-ietf-pwe3-requirements : "PWs can be path-oriented or non-path-oriented. For path-oriented PWs, core network devices must maintain state information for them. If a large number of path-oriented PWs are used, core network devices will have to maintain a large amount of state information" Furthermore, because of route summarization, not every time a new Attachment Circuit is added, it generates a IGP update. Also, the MPtP and MPtMP PWs that are used in this draft, are not defined yet in the PWE3 framework and may need to be defined in the future. >3. In Section 8 you describe the process of forwarding of "known unicast" > frames in the egress PE like following: > > When an egress PE receives a unicast MVPLS packet from the core, it > > performs the MAC SA lookup, and possibly learning, as has been > described in Section 8.2. The egress PE does not lookup the MAC DA >of > the received frame since the destination IP address of the received > > packet readily identifies the interface associated with the AC. The > > packet is immediately delivered to that interface. The IP header >and > the L2TPv3 header are removed before the Ethernet frame gets >forwarded > over the AC towards its destination. > > > This text raises several questions: > a) How does the PE distinguish between the MVPLS packet and any other > packet with the destination address that has been allocated > for the Attachment Circuit? IMHO, the vague reference to L2TPv3 > is not sufficient, because the L2TPv3 switching engine would > most probably just discard the packet with an unknown Session > ID - and in order to make the Session ID known to this engine, > it must be explicitly set up - via signaling or manually. > In other words, your forwarding decisions seem to prevent > "normal" usage of L2TPv3 in the same PE We are just talking about a shim header for encapsulating Ethernet packets. Therefore, with respect to L2TPv3, we are just talking about the encapsulation portion of it and not the signalling. If you prefer, you can use some other name for it. > b) How are other packets with this destination address (e.g., > the ICMP Echo) processed? In other words, is the IP address > associated with the AC in this PE treated as one of the > IP addresses of the PE, or not? The packets with protocol-type of L2TPv3 for that AC gets forwarded to that interface and other packets with non-L2TPv3 protocol-type gets processed internally by the PE. Regards, Ali >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 15:14: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 PAA09340 for ; Thu, 7 Nov 2002 15:14:50 -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 gA7KGdf18821 for ; Thu, 7 Nov 2002 15:16: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 gA7KGbs18816 for ; Thu, 7 Nov 2002 15:16:37 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; Subject: Note Well Statement x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Sender: scoya@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: scoya@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: From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 20:51:44 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 UAA20860 for ; Thu, 7 Nov 2002 20:51: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 gA81rZd27941 for ; Thu, 7 Nov 2002 20:53: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 gA81rWs10352 for ; Thu, 7 Nov 2002 20:53:33 -0500 (EST) Date: Fri, 08 Nov 2002 09:53:30 +0800 From: =?gb2312?B?wO6x8w==?= Subject: =?gb2312?B?tPC4tDogtPC4tDogUGxlYXNlIFJldmlldzogQSBuZXcgZHJhZnQgYQ==?= =?gb2312?B?Ym91dCBQUFZQTihIaWJlcmFyY2h5IG9mIFBFIERldmljZSBpbkJHUA==?= =?gb2312?B?L01QTFMgVlBOKQ==?= In-reply-to: To: Jim Guichard Cc: Lidefeng , Lidefeng , leh10814@huawei.com, "FuY. Miao" , changwj@huawei.com, Gma@futurewei.com, lhj@huawei.com, ppvpn@nortelnetworks.com, zinin@psg.com, bwijnen@lucent.com, sob@harvard.edu, "Marco Carugi" , rwilder@masergy.com, internet-drafts@ietf.org, dongws@huawei.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA20860 I believe that 2547bis not mention the hub & spoke PE. I think my proposal is the supplement of rfc2547bis. On the otherwise, not only some UPEs can talk with each other by SPE, but also a HoPE can talk with other PEs in a MPLS domain like a normal PE. -----ԭʼÓʼþ----- ·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 ÊÕ¼þÈË: ¨¤?¡À¨® ³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; marco.carugi@nortelnetworks.com; sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) so can hub&spoke with 2547 - you basically export routes from the CE-attached PEs to a hub PE that imports the routes. The hub PE exports either a default or aggregates to attract traffic from other CE-attached PEs and then performs a lookup to forward the packets to other CE-attached PEs .. Jim > >-----Original Message----- > >From: Àî±ó [mailto:l.b@huawei.com] > >Sent: Thursday, November 07, 2002 2:42 AM > >To: Jim Guichard > >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >marco.carugi@nortelnetworks.com; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >Miao; leh10814@huawei.com > >Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy > >of PE Device inBGP/MPLS VPN) > > > > > >Hi, Guichard > >The hub & spoke is the relationship between CEs, but SPE peer > >with UPE by MP-BGP, they are all PEs, and they all can admit VPN user. > > > >Libin > > > >-----ԭʼÓʼþ----- > >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei. > >com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; leh10814@huawei. > >com; l.b@huawei.com > >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE Device > >inBGP/MPLS VPN) > > > > > >I briefly ran through this draft and it looks like normal hub & > >spoke using > >existing 2547 mechanisms - could you explain how this differs ? thanks, > > > >> >-----Original Message----- > >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >To: internet-drafts@ietf.org > >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >> >Miao; leh10814@huawei.com; l.b@huawei.com > >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE > >> >Device in BGP/MPLS VPN) > >> > > >> > > >> >Hi,all, > >> > > >> > In BGP/MPLS VPN area, we proposed a new idea as to resolve > >> >the bottleneck > >> >of > >> >the capacity of some PEs when deploy the huge size VPN,the > >whole idea is > >> >detailed > >> >in the attached > >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >> >Abstract > >> >is as follows,we are appreciated for your review. > >> > > >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >Edge)Device should > >> > maintain all the VPN routes of the VPNs which it belong > >to.When there > >> > are many VPNs converged by a PE,and the capacity of PE is relevant > >> > limited,then the bottleneck will be encountered.Another problem is > >> > that the current BGP/MPLS VPN model is something of a "Plane Modle" > >> > where the demand of the performance of the PE device are all the > >> > same no matter which layer the PE device is belongs to.However,the > >> > typical network is "Core-Convergence-Access(Edge)" model,and the > >> > performance of the device is superior in Core Layer and inferior in > >> > Access Layer,and the scale of network is large in Access Layer and > >> > small in Core Layer,the routes are converged in every layer,so in > >> > current "Plane Modle",when PE device push to the edge layer,it has > >> > to maintain more VPN routes,this makes it difficult to > >extend the PE > >> > device to edge layer.This document defines an model of > >hiberarchy of > >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider > >> > Edge Device can be composed of several device and every device take > >> > on the different part,partake the function of the former > >> > concentrative PE,we call this model "Hiberarchy Model",In > >this model > >> > the demand of performance in Routing and Switching is strict to the > >> > PE device in High layer,loose to the PE device in edge layer. > >> > > >> > One HoPE can be composed of a SPE and UPES connected to the SPE, > >> > or be composed of a high-level SPE and HoPEs connected the high > >> > level SPE and and build up a new HoPE.This build is called nesting > >> > of HoPE,and this kind of nesting can be done for many > >times.Thus the > >> > former HoPE connect to the high-level SPE as a role of UPE,and the > >> > new HoPE can connect a single UPE too. > >> > > >> >Regards > >> > > >> >Defeng Li > >> > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 21:06:42 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21162 for ; Thu, 7 Nov 2002 21:06:42 -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 gA828Qd07689 for ; Thu, 7 Nov 2002 21:08:26 -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 gA828Ns19865 for ; Thu, 7 Nov 2002 21:08:23 -0500 (EST) Date: Fri, 08 Nov 2002 10:07:28 +0800 From: =?gb2312?B?w+e4o9PR?= Subject: =?gb2312?B?tPC4tDogtPC4tDogUGxlYXNlIFJldmlldzogQSBuZXcgZHJhZnQgYQ==?= =?gb2312?B?Ym91dCBQUFZQTihIaWJlcmFyY2h5IG9mIFBFIERldmljZSBpbkJHUA==?= =?gb2312?B?L01QTFMgVlBOKQ==?= In-reply-to: To: "'Jim Guichard'" , =?gb2312?B?J6ikP6HAqK4n?= Cc: rwilder@masergy.com, "Marco Carugi" , sob@harvard.edu, bwijnen@lucent.com, zinin@psg.com, ppvpn@nortelnetworks.com, lhj@huawei.com, Gma@futurewei.com, changwj@huawei.com, leh10814@huawei.com Message-id: <000001c286cb$979b0fc0$2e426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: miaofy@huawei.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA21162 Hi, Jim: This draft is not to replace 2547, but a supplement to it. Actually the VPN in the draft is completely works under the mechanism of 2547. In the traditional 2547 VPN, only one type of PE is defined. When deployment, PE will not has so many ports to attach many VPNs if the PE is at the core layer of the network, because core router generally doesn't have a lot of physically interfaces. If the PE is at the edge of the network, it will have a lot of interfaces, but now the botlleneck is capacity of computation of the router. This draft is to solve the problem, UPE will provide abundant interface to conenct sites to VPN and SPE will have enough CPU/Memory to process routes. Regards Miao -----ÓʼþÔ­¼þ----- ·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 ÊÕ¼þÈË: ¨¤?¡À¨® ³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco Carugi; sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) so can hub&spoke with 2547 - you basically export routes from the CE-attached PEs to a hub PE that imports the routes. The hub PE exports either a default or aggregates to attract traffic from other CE-attached PEs and then performs a lookup to forward the packets to other CE-attached PEs .. Jim > >-----Original Message----- > >From: Àî±ó [mailto:l.b@huawei.com] > >Sent: Thursday, November 07, 2002 2:42 AM > >To: Jim Guichard > >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >marco.carugi@nortelnetworks.com; sob@harvard.edu; bwijnen@lucent.com; > >zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; > >Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >leh10814@huawei.com > >Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE > >Device inBGP/MPLS VPN) > > > > > >Hi, Guichard > >The hub & spoke is the relationship between CEs, but SPE peer with > >UPE by MP-BGP, they are all PEs, and they all can admit VPN user. > > > >Libin > > > >-----ԭʼÓʼþ----- > >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >leh10814@huawei. com; l.b@huawei.com > >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE > >Device inBGP/MPLS VPN) > > > > > >I briefly ran through this draft and it looks like normal hub & spoke > >using existing 2547 mechanisms - could you explain how this differs ? > >thanks, > > > >> >-----Original Message----- > >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >To: internet-drafts@ietf.org > >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >> >leh10814@huawei.com; l.b@huawei.com > >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE > >> >Device in BGP/MPLS VPN) > >> > > >> > > >> >Hi,all, > >> > > >> > In BGP/MPLS VPN area, we proposed a new idea as to resolve the > >> >bottleneck of > >> >the capacity of some PEs when deploy the huge size VPN,the > >whole idea is > >> >detailed > >> >in the attached > >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >> >Abstract is as follows,we are appreciated for your review. > >> > > >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >Edge)Device should > >> > maintain all the VPN routes of the VPNs which it belong > >to.When there > >> > are many VPNs converged by a PE,and the capacity of PE is relevant > >> > limited,then the bottleneck will be encountered.Another problem is > >> > that the current BGP/MPLS VPN model is something of a "Plane Modle" > >> > where the demand of the performance of the PE device are all the > >> > same no matter which layer the PE device is belongs to.However, the > >> > typical network is "Core-Convergence-Access(Edge)" model,and the > >> > performance of the device is superior in Core Layer and inferior in > >> > Access Layer,and the scale of network is large in Access Layer and > >> > small in Core Layer,the routes are converged in every layer,so in > >> > current "Plane Modle",when PE device push to the edge layer,it has > >> > to maintain more VPN routes,this makes it difficult to > >extend the PE > >> > device to edge layer.This document defines an model of > >hiberarchy of > >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider > >> > Edge Device can be composed of several device and every device take > >> > on the different part,partake the function of the former > >> > concentrative PE,we call this model "Hiberarchy Model",In > >this model > >> > the demand of performance in Routing and Switching is strict to the > >> > PE device in High layer,loose to the PE device in edge layer. > >> > > >> > One HoPE can be composed of a SPE and UPES connected to the SPE, > >> > or be composed of a high-level SPE and HoPEs connected the high > >> > level SPE and and build up a new HoPE.This build is called nesting > >> > of HoPE,and this kind of nesting can be done for many > >times.Thus the > >> > former HoPE connect to the high-level SPE as a role of UPE,and the > >> > new HoPE can connect a single UPE too. > >> > > >> >Regards > >> > > >> >Defeng Li > >> > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 21:45: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 VAA22314 for ; Thu, 7 Nov 2002 21:45: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 gA82lEd12481 for ; Thu, 7 Nov 2002 21:47:14 -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 gA82lAs03313 for ; Thu, 7 Nov 2002 21:47:10 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 07 Nov 2002 18:46:28 -0800 Subject: Re: =?Big5?B?tarOYDogtarOYA==?=: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) From: Ray Qiu To: =?ISO-2022-JP?B?GyRCSURKIU0nGyhK?= CC: Message-ID: In-Reply-To: <000001c286cb$979b0fc0$2e426e0a@HUAWEI.COM> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" X-OriginalArrivalTime: 08 Nov 2002 02:46:21.0949 (UTC) FILETIME=[05914AD0:01C286D1] X-SMTP-HELO: RS-SC-EXC4.rs.riverstonenet.com X-SMTP-MAIL-FROM: rqiu@riverstonenet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host60.riverstonenet.com [64.95.122.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA22314 Miao, In this scenario, does it make more sense to just use the edge PE (MTU) just as a L2 transport box? For example, you could use a cheap L2 switch, and assign each customer a separate VLAN, then 2547 PE will terminate the VLANs and does the IP/MPLS forwarding based on VRF information. - Ray On 11/7/02 18:07, "Ã縣ÓÑ" wrote: > Hi, Jim: > > This draft is not to replace 2547, but a supplement to it. Actually the > VPN in the draft is completely works under the mechanism of 2547. > > In the traditional 2547 VPN, only one type of PE is defined. When > deployment, PE will not has so many ports to attach many VPNs if the PE > is at the core layer of the network, because core router generally > doesn't have a lot of physically interfaces. If the PE is at the edge > of the network, it will have a lot of interfaces, but now the botlleneck > is capacity of computation of the router. > > This draft is to solve the problem, UPE will provide abundant interface > to conenct sites to VPN and SPE will have enough CPU/Memory to process > routes. > > Regards > Miao > > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 > ÊÕ¼þÈË: ¨¤?¡À¨® > ³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco Carugi; > sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; > ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; > changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com > Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE > Device inBGP/MPLS VPN) > > > so can hub&spoke with 2547 - you basically export routes from the > CE-attached PEs to a hub PE that imports the routes. The hub PE exports > either a default or aggregates to attract traffic from other CE-attached > PEs and then performs a lookup to forward the packets to other > CE-attached PEs .. Jim > >>> -----Original Message----- >>> From: Àî±ó [mailto:l.b@huawei.com] >>> Sent: Thursday, November 07, 2002 2:42 AM >>> To: Jim Guichard >>> Cc: internet-drafts@ietf.org; rwilder@masergy.com; >>> marco.carugi@nortelnetworks.com; sob@harvard.edu; bwijnen@lucent.com; > >>> zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; >>> Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; >>> leh10814@huawei.com >>> Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of > PE >>> Device inBGP/MPLS VPN) >>> >>> >>> Hi, Guichard >>> The hub & spoke is the relationship between CEs, but SPE peer with >>> UPE by MP-BGP, they are all PEs, and they all can admit VPN user. >>> >>> Libin >>> >>> -----ԭʼÓʼþ----- >>> ·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] >>> ·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 >>> ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org >>> ³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; >>> bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; >>> lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; >>> leh10814@huawei. com; l.b@huawei.com >>> Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE >>> Device inBGP/MPLS VPN) >>> >>> >>> I briefly ran through this draft and it looks like normal hub & spoke > >>> using existing 2547 mechanisms - could you explain how this differs ? > >>> thanks, >>> >>>>> -----Original Message----- >>>>> From: lidefeng [mailto:lidefeng@huawei.com] >>>>> Sent: Tuesday, November 05, 2002 11:40 PM >>>>> To: internet-drafts@ietf.org >>>>> Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; >>>>> bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; >>>>> lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >>>>> leh10814@huawei.com; l.b@huawei.com >>>>> Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE >>>>> Device in BGP/MPLS VPN) >>>>> >>>>> >>>>> Hi,all, >>>>> >>>>> In BGP/MPLS VPN area, we proposed a new idea as to resolve the >>>>> bottleneck of >>>>> the capacity of some PEs when deploy the huge size VPN,the >>> whole idea is >>>>> detailed >>>>> in the attached >>>>> draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the >>>>> Abstract is as follows,we are appreciated for your review. >>>>> >>>>> In the deployment of BGP/MPLS VPN,the PE(Provider >>> Edge)Device should >>>>> maintain all the VPN routes of the VPNs which it belong >>> to.When there >>>>> are many VPNs converged by a PE,and the capacity of PE is > relevant >>>>> limited,then the bottleneck will be encountered.Another problem > is >>>>> that the current BGP/MPLS VPN model is something of a "Plane > Modle" >>>>> where the demand of the performance of the PE device are all > the >>>>> same no matter which layer the PE device is belongs to.However, > the >>>>> typical network is "Core-Convergence-Access(Edge)" model,and > the >>>>> performance of the device is superior in Core Layer and > inferior in >>>>> Access Layer,and the scale of network is large in Access Layer > and >>>>> small in Core Layer,the routes are converged in every layer,so > in >>>>> current "Plane Modle",when PE device push to the edge layer,it > has >>>>> to maintain more VPN routes,this makes it difficult to >>> extend the PE >>>>> device to edge layer.This document defines an model of >>> hiberarchy of >>>>> Provider Edge Device in BGP/MPLS VPN,where hiberarchy of > Provider >>>>> Edge Device can be composed of several device and every device > take >>>>> on the different part,partake the function of the former >>>>> concentrative PE,we call this model "Hiberarchy Model",In >>> this model >>>>> the demand of performance in Routing and Switching is strict to > the >>>>> PE device in High layer,loose to the PE device in edge layer. >>>>> >>>>> One HoPE can be composed of a SPE and UPES connected to the > SPE, >>>>> or be composed of a high-level SPE and HoPEs connected the high >>>>> level SPE and and build up a new HoPE.This build is called > nesting >>>>> of HoPE,and this kind of nesting can be done for many >>> times.Thus the >>>>> former HoPE connect to the high-level SPE as a role of UPE,and > the >>>>> new HoPE can connect a single UPE too. >>>>> >>>>> Regards >>>>> >>>>> Defeng Li >>>>> > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 7 22:31:15 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 WAA23308 for ; Thu, 7 Nov 2002 22:31: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 gA83XAd28150 for ; Thu, 7 Nov 2002 22:33:10 -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 gA83X7s15184 for ; Thu, 7 Nov 2002 22:33:07 -0500 (EST) Date: Fri, 08 Nov 2002 11:31:43 +0800 From: Miao Fuyou Subject: RE:Please Review: A new draft aboutPPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) In-reply-to: To: "'Ray Qiu'" Cc: ppvpn@nortelnetworks.com, =?gb2312?B?wO6x8w==?= , lidefeng Message-id: <000001c286d7$5c98bec0$2e426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: miaofy@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA23308 Ray: I believe we must take most advantage of existing SP network to deploy VPN. In most cases, the network is more possible to be a IP network comprising routers. It's almost infeasible to make the SP setup a totally new network under current telecom depression. For example, the accessing layer comprises of LAN switches and strong routers at core. Acttually we came out this solution when a SP wanted to provide MPLS VPN service on its existing network, and it performed the function well and cost less budget. There is no doubt that VLAN/sub-interface is a solution to solve the problem mentioned, but it only works well under specific environment. So I believe UPE/SPE are good alteration. Regards Miao -----ÓʼþÔ­¼þ----- ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 10:46 ÊÕ¼þÈË: •c•Ÿ—F ³­ËÍ: ppvpn@nortelnetworks.com Ö÷Ìâ: Re: µªÎ`: µªÎ`: Please Review: A new draft aboutPPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) Miao, In this scenario, does it make more sense to just use the edge PE (MTU) just as a L2 transport box? For example, you could use a cheap L2 switch, and assign each customer a separate VLAN, then 2547 PE will terminate the VLANs and does the IP/MPLS forwarding based on VRF information. - Ray On 11/7/02 18:07, "Ã縣ÓÑ" wrote: > Hi, Jim: > > This draft is not to replace 2547, but a supplement to it. Actually > the VPN in the draft is completely works under the mechanism of 2547. > > In the traditional 2547 VPN, only one type of PE is defined. When > deployment, PE will not has so many ports to attach many VPNs if the > PE is at the core layer of the network, because core router generally > doesn't have a lot of physically interfaces. If the PE is at the edge > of the network, it will have a lot of interfaces, but now the > botlleneck is capacity of computation of the router. > > This draft is to solve the problem, UPE will provide abundant > interface to conenct sites to VPN and SPE will have enough CPU/Memory > to process routes. > > Regards > Miao > > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 > ÊÕ¼þÈË: ¨¤?¡À¨® > ³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco Carugi; > sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; > ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; > changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com > Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE > Device inBGP/MPLS VPN) > > > so can hub&spoke with 2547 - you basically export routes from the > CE-attached PEs to a hub PE that imports the routes. The hub PE > exports either a default or aggregates to attract traffic from other > CE-attached PEs and then performs a lookup to forward the packets to > other CE-attached PEs .. Jim > >>> -----Original Message----- >>> From: Àî±ó [mailto:l.b@huawei.com] >>> Sent: Thursday, November 07, 2002 2:42 AM >>> To: Jim Guichard >>> Cc: internet-drafts@ietf.org; rwilder@masergy.com; >>> marco.carugi@nortelnetworks.com; sob@harvard.edu; >>> bwijnen@lucent.com; > >>> zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; >>> Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; >>> leh10814@huawei.com >>> Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of > PE >>> Device inBGP/MPLS VPN) >>> >>> >>> Hi, Guichard >>> The hub & spoke is the relationship between CEs, but SPE peer with >>> UPE by MP-BGP, they are all PEs, and they all can admit VPN user. >>> >>> Libin >>> >>> -----ԭʼÓʼþ----- >>> ·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] >>> ·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 >>> ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org >>> ³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; >>> bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; >>> lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; >>> leh10814@huawei. com; l.b@huawei.com >>> Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE >>> Device inBGP/MPLS VPN) >>> >>> >>> I briefly ran through this draft and it looks like normal hub & >>> spoke > >>> using existing 2547 mechanisms - could you explain how this differs >>> ? > >>> thanks, >>> >>>>> -----Original Message----- >>>>> From: lidefeng [mailto:lidefeng@huawei.com] >>>>> Sent: Tuesday, November 05, 2002 11:40 PM >>>>> To: internet-drafts@ietf.org >>>>> Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; >>>>> bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; >>>>> lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >>>>> leh10814@huawei.com; l.b@huawei.com >>>>> Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE >>>>> Device in BGP/MPLS VPN) >>>>> >>>>> >>>>> Hi,all, >>>>> >>>>> In BGP/MPLS VPN area, we proposed a new idea as to resolve the >>>>> bottleneck of the capacity of some PEs when deploy the huge size >>>>> VPN,the >>> whole idea is >>>>> detailed >>>>> in the attached >>>>> draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the >>>>> Abstract is as follows,we are appreciated for your review. >>>>> >>>>> In the deployment of BGP/MPLS VPN,the PE(Provider >>> Edge)Device should >>>>> maintain all the VPN routes of the VPNs which it belong >>> to.When there >>>>> are many VPNs converged by a PE,and the capacity of PE is > relevant >>>>> limited,then the bottleneck will be encountered.Another problem > is >>>>> that the current BGP/MPLS VPN model is something of a "Plane > Modle" >>>>> where the demand of the performance of the PE device are all > the >>>>> same no matter which layer the PE device is belongs to.However, > the >>>>> typical network is "Core-Convergence-Access(Edge)" model,and > the >>>>> performance of the device is superior in Core Layer and > inferior in >>>>> Access Layer,and the scale of network is large in Access Layer > and >>>>> small in Core Layer,the routes are converged in every layer,so > in >>>>> current "Plane Modle",when PE device push to the edge layer,it > has >>>>> to maintain more VPN routes,this makes it difficult to >>> extend the PE >>>>> device to edge layer.This document defines an model of >>> hiberarchy of >>>>> Provider Edge Device in BGP/MPLS VPN,where hiberarchy of > Provider >>>>> Edge Device can be composed of several device and every device > take >>>>> on the different part,partake the function of the former >>>>> concentrative PE,we call this model "Hiberarchy Model",In >>> this model >>>>> the demand of performance in Routing and Switching is strict to > the >>>>> PE device in High layer,loose to the PE device in edge layer. >>>>> >>>>> One HoPE can be composed of a SPE and UPES connected to the > SPE, >>>>> or be composed of a high-level SPE and HoPEs connected the high >>>>> level SPE and and build up a new HoPE.This build is called > nesting >>>>> of HoPE,and this kind of nesting can be done for many >>> times.Thus the >>>>> former HoPE connect to the high-level SPE as a role of UPE,and > the >>>>> new HoPE can connect a single UPE too. >>>>> >>>>> Regards >>>>> >>>>> Defeng Li >>>>> > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 00:48:11 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 AAA26747 for ; Fri, 8 Nov 2002 00:48:11 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA85o5112230 for ; Fri, 8 Nov 2002 00:50: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 gA85o2K07149 for ; Fri, 8 Nov 2002 00:50:02 -0500 (EST) Date: Fri, 08 Nov 2002 13:50:03 +0800 From: Bin Li Subject: =?gb2312?B?tPC4tDogtPC4tDogtao=?= In-reply-to: To: Ray Qiu Cc: ppvpn@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id AAA26747 In theory, VLAN can transport via WAN link. But it'll as expensive as other WAN technology. And it's not the only choice. Users can access PE by VLAN, ATM, FR, PoS, E1 and etc. Why should we use label to separate VPN site? MPLS label can work on any Layer 2 technology. Each IP interface/address will never consume more than resource MP-BGP, but many IP interface/address will consume more than MP-BGP. In the other word. HoPE is very scalability. MP-BGP is a dynamic mechanism, but VLAN will be configured each by each manually. BTW, if SPE directly links with UPE, UPE needn't run LDP/RSVP. -----ԭʼÓʼþ----- ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 11:59 ÊÕ¼þÈË: Bin Li Ö÷Ìâ: Re: ´ð¸´: µª Bin, It sounds to me like an implementation issue. VLAN can be supported on WAN links as well as 802.1Q. IP interface/address would never consume more resource than MP-BGP and LDP/RSVP. - Ray On 11/7/02 19:51, "Bin Li" wrote: > Ray, > The key is the distance between UPE and SPE. Sometime, you must use a WAN link > between them. And when VLANs are used to separate sites, you must configure > many VLAN in a PE, and assign a VLAN to a VRF. Usually, a VLAN in a router is > a sub-interface, it should have a IP address and consume some resource. It's > costly and difficult to maintain. > > > > > -----ԭʼÓʼþ----- > ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] > ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 10:46 > ÊÕ¼þÈË: •c•Ÿ—F > ³­ËÍ: ppvpn@nortelnetworks.com > Ö÷Ìâ: Re: µª From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 00:56: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 AAA27012 for ; Fri, 8 Nov 2002 00:56: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 gA85wh116189 for ; Fri, 8 Nov 2002 00:58: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 gA85wfK12835 for ; Fri, 8 Nov 2002 00:58:41 -0500 (EST) Message-ID: <20021108055806.56193.qmail@web20414.mail.yahoo.com> Date: Thu, 7 Nov 2002 21:58:06 -0800 (PST) From: Kevin Liu Subject: A new book on "IP over WDM" by Wiley 2002 To: ccamp@ops.ietf.org, gsmp@ietf.org, ip-optical@lists.bell-labs.com, mpls@uu.net, ppvpn@nortelnetworks.com, te-wg@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web20414.mail.yahoo.com X-SMTP-MAIL-FROM: kevin_h_liu@yahoo.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web20402.mail.yahoo.com [66.163.169.90] X-LYRIS-Message-Id: Book Name: IP over WDM Book Author: KEVIN H. LIU Publisher: Wiley ISBN: 0470844175 Date: Sep 2002 Book Cover: IP over WDM explores the coming together of communication and computer networking technologies: optical fiber using WDM (Wavelength Division Multiplexing) and IP - the Internet Protocol. Fiber optics technology is revolutionizing the telecommunications and networking industries by offering the enormous capacity required to sustain continuous growth of the Internet. Meanwhile, IP is rapidly becoming the dominant network protocol for a global and ubiquitous Internet. In his pioneering text, Kevin Liu demonstrates how to fully exploit the fiber bandwidth capacity by WDM and the universal connectivity offered by IP, by carefully integrating the two technologies and optimising systems to play to their strengths. He presents IP/WDM architectural and internetworking models, discusses network control and traffic engineering and highlights issues specific to IP/WDM networks. Features: · Performance studies, simulations and case studies · WDM network testbeds and products comparison · Standardization initiatives · A comprehensive review of optical communications, routing, signalling, and other optical network control and management functions · A comprehensive review of IP over WDM networking architectures, IP/WDM internetworking models, and IP/WDM service models · Detailed coverage of Internet routing, MPLS/MPlS/GMPLS, IP/WDM network addressing, WDM topology discovery, IP/WDM routing, IP/WDM signalling, and IP/WDM restoration · Detailed coverage on Internet and MPLS traffic engineering, and IP/WDM traffic engineering · Discussion on IP/WDM group communication, TCP over optical networks, and IP/WDM network applications This detailed and precise presentation of a new paradigm in network engineering will appeal to all telecommunications and computer network engineers designing and building next generation systems as well as graduate students majoring in control and traffic engineering for next generation optical networks. ++++++++++++++++++++++++++++++++++++++++++ TABLE OF CONTENTS List of Figures List of Tables About the Author Preface Acknowledgements Chapter 1. Introduction § 1.1 What is WDM enabled optical network § 1.1.1 TDM vs. WDM § 1.1.2 WDM optical network evolution § 1.2 Why IP over WDM § 1.3 What is IP over WDM § 1.4 Next Generation Internet § 1.5 IP/WDM standardization § 1.6 Summary and book overview Chapter 2. Review § 2.1 Telecommunication networks § 2.2 Optical communications § 2.2.1 Optical communication impairments § 2.2.2 Optical switching § 2.3 WDM network testbed and product comparison § 2.3.1 WDM network testbeds § 2.3.2 Product comparison § 2.4 Communication protocols § 2.5 Internet architecture § 2.6 IPv4 addressing § 2.6.1 Subnetting § 2.6.2 Unnumbered address § 2.6.3 Secondary address § 2.6.4 Classless Inter-Domain Routing (CIDR) § 2.7 Gigabit Ethernet § 2.7.1 Gigabit Ethernet architecture § 2.7.2 Gigabit Ethernet applications § 2.8 Multiprotocol Label Switching (MPLS) § 2.8.1 Label distribution § 2.8.2 Traffic engineering § 2.8.3 QoS § 2.8.4 Virtual Private Network (VPN) § 2.9 Distributed systems § 2.9.1 Design objectives § 2.9.2 Architectural models § 2.9.3 Clustering § 2.9.4 API for distributed applications Chapter 3. Characteristics of the Internet and IP Routing § 3.1 IP router overview § 3.1.1 IPv4 datagram § 3.1.2 QoS queuing models § 3.2 Traffic engineering § 3.2.1 Shortest path routing § 3.2.2 Equal Cost Multi-Path (ECMP) § 3.2.3 Optimized Multi-Path (OMP) § 3.2.4 MPLS OMP § 3.3 TCP traffic policing § 3.3.1 TCP flow control § 3.3.2 TCP congestion control § 3.3.2.1 TCP Reno § 3.3.2.2 TCP Vegas § 3.4 Internet traffic characteristics and models § 3.4.1 Internet traffic statistics § 3.4.1.1 Metropolitan area network § 3.4.1.2 Long haul backbone network § 3.4.2 Traffic models and long range dependence § 3.5 Internet routing § 3.6 OSPF § 3.6.1 OSPF messages § 3.6.2 Link State Advertisement (LSA) § 3.6.3 Routing in OSPF § 3.7 BGP § 3.7.1 IBGP and EBGP § 3.7.2 BGP messages § 3.7.3 Path attributes § 3.7.4 Policy filtering § 3.7.5 BGP routing § 3.8 IPv6 Chapter 4. WDM Optical Networks § 4.1 Optical modulation § 4.2 Optical switching component and technology § 4.2.1 Optical Amplifier (OAMP) and repeater § 4.2.2 Optical Add/Drop Multiplexer (OADM) § 4.2.3 Optical Crossconnect (OXC) § 4.2.4 Transponder § 4.2.5 Switching fabric § 4.2.5.1 Opaque fabrics § 4.2.5.2. Transparent switch fabric technologies § 4.2.6 Optical switch/router § 4.3 WDM NC&M overview § 4.3.1 TMN framework § 4.3.1.1 TMN logical model § 4.3.1.2 TMN functional model § 4.3.1.3 TMN application functions § 4.3.2 WDM network management and visualization framework § 4.4 WDM network information model § 4.4.1 WDM object model § 4.4.2 An example of WDM network and connection MIB § 4.5 WDM NC&M functionality § 4.5.1 Connection management § 4.5.1.1 Routing metrics § 4.5.1.2 Static routing and wavelength selection § 4.5.1.2.1 Problem formulation § 4.5.1.2.2 Heuristic algorithms § 4.5.1.3 WDM routing constraints § 4.5.1.4 Wavelength scheduling algorithms § 4.5.1.4.1 Intra connection scheduling § 4.5.1.4.2 Inter connection scheduling § 4.5.2 Connection discovery § 4.5.3 WDM client topology reconfiguration § 4.5.4 Signal quality monitoring § 4.5.5 Fault management § 4.6 WDM NE management § 4.6.1 NE MIB § 4.6.2 NE interfaces § 4.7 WDM signaling § 4.7.1 Wavelength routing and signaling § 4.7.2 Circuit switching vs. Just-In-Time (JIT) burst switching § 4.8 WDM DCN § 4.9 WDM network views § 4.10 Discussion Chapter 5. IP over WDM § 5.1 IP over WDM networking architectures § 5.1.1 What is optical burst switching § 5.1.2 What is optical packet switching § 5.1.3 Three IP/WDM networking architectures § 5.1.3.1 IP over point-to-point WDM § 5.1.3.2 IP over reconfigurable WDM § 5.1.3.3 IP over switched WDM § 5.2 IP/WDM internetworking models § 5.2.1 IP over reconfigurable WDM § 5.2.1.1 Overlay control model § 5.2.1.2 Augmented control model § 5.2.1.3 Peer control model § 5.2.1.4 Discussion § 5.2.2 IP over switched WDM § 5.2.2.1 IP over OLSR § 5.2.2.2 IP over OPR § 5.3 IP/WDM service models § 5.3.1 Domain service model § 5.3.2 Unified service model § 5.3.3 Services § 5.4 Summary Chapter 6. IP/WDM Network Control § 6.1 IP/WDM network addressing § 6.1.1 Overlay addressing § 6.1.2 Peer addressing § 6.2 Topology discovery § 6.2.1 OSPF Hello message § 6.2.2 Link Management Protocol (LMP) § 6.2.2.1 LMP control channel management § 6.2.2.2 LMP link property correlation § 6.3 IP/WDM routing § 6.3.1 Routing information base construction and maintenance § 6.3.2 Route computation and WDM switching constraints § 6.3.2.1 SPF algorithms § 6.3.2.2 Dynamic routing and wavelength assignment § 6.3.2.3 Lightpath protection § 6.3.2.4 WDM switching constraints § 6.3.3 OSPF extensions § 6.3.3.1 Opaque LSA § 6.3.3.2 Optical switch capacity opaque LSA § 6.3.3.3 Optical switch connection opaque LSA § 6.3.3.4 Traffic-related opaque LSA § 6.3.4 Routing behavior § 6.3.4.1 Routing loops § 6.3.4.2 Routing oscillation § 6.3.4.3 Routing failures § 6.3.4.4 Routing stability § 6.4 IP/WDM Signaling § 6.4.1 RSVP overview § 6.4.2 RSVP extension for optical networks § 6.4.3 RSVP extension implementation architecture § 6.4.4 RSVP message extensions § 6.4.4.1 PATH message § 6.4.4.2 RESV message § 6.4.5 Hybrid label allocation scheme for optical networks § 6.4.6 Discussion § 6.5 WDM network access control § 6.6 GMPLS § 6.7 IP/WDM restoration § 6.7.1 Provisioning case study § 6.7.2 Restoration case study § 6.8 Inter-domain network control § 6.8.1 IP/WDM network reachability and availability § 6.8.2 Inter-domain routing information exchange § 6.8.2.1 Routing information exchange between IP and WDM domain § 6.8.2.1.1 Optical Virtual Private Network (OVPN) § 6.8.2.2 Routing information exchange between WDM networks § 6.8.2.2.1 Dynamic provisioning model § 6.8.2.2.2 OSPF for information exchange § 6.8.2.2.3 BGP for information exchange § 6.9 WDM network element control and management protocol § 6.9.1 Simple Network Management Protocol (SNMP) § 6.9.2 General Switch Management Protocol (GSMP) § 6.9.2.1 Adjacency protocol message § 6.9.2.2 Request-response messages § 6.9.3 Optical Switch Control Protocol (OSCP) § 6.10 Summary § 6.10.1 Network control vs. network management Chapter 7. IP/WDM Traffic Engineering § 7.1 What is IP over WDM traffic engineering § 7.2 Modeling of IP over WDM traffic engineering § 7.2.1 Overlay traffic engineering § 7.2.2 Integrated traffic engineering § 7.2.3 Comparison of the two models § 7.3 IP over WDM traffic engineering functional framework § 7.3.1 IP/WDM network state information database § 7.3.2 IP to WDM interface management § 7.3.3 Examples of reconfiguration triggers § 7.3.4 Traffic monitoring and measurements § 7.3.4.1 Traffic monitoring methods and tools § 7.3.4.2 Traffic engineering flow definition § 7.3.4.3 Traffic monitoring sampling granularity § 7.3.4.4 Measurement granularity and traffic matrix § 7.3.5 Optical signal performance monitoring § 7.4 Teletraffic modeling § 7.4.1 Classical Telephone and data traffic model § 7.4.2 Novel data traffic models § 7.4.3 A bandwidth projection model § 7.4.3.1 Fractional Brownian Motion § 7.4.3.2 Traffic projection principles § 7.4.3.3 Model parameters § 7.5 MPLS traffic engineering § 7.5.1 Load balancing § 7.5.2 Network provisioning § 7.6 Lightpath virtual topology reconfiguration § 7.6.1 Regular vs. irregular virtual topology § 7.6.2 Topology design problem formulation § 7.6.3 Heuristic Algorithms § 7.6.3.1 Lightpath topology design algorithm survey § 7.6.3.1 Residual Demand heuristic algorithm (RD) § 7.6.3.2 Spanning tree topology design heuristic algorithms § 7.6.3.2.1 Residual Demand heuristic algorithm (RD) § 7.6.3.2.2 Residual Demand Hop-count Product heuristic algorithm (RDHP) § 7.6.3.2.3 Demand Hop-count Product heuristic algorithm (DHP) § 7.6.4 Virtual topology migration § 7.6.4.1 Topology migration heuristic algorithm § 7.7 Reconfiguration for packet switched WDM networks § 7.7.1 Packet switched WDM reconfiguration overview § 7.7.2 Reconfiguration conditions § 7.7.3 A case study § 7.7.4 Heuristic algorithm description § 7.7.5 Heuristic discussion § 7.7.6 Lightpath reconfiguration migration § 7.8 Simulation study of IP over WDM reconfiguration § 7.8.1 Traffic generation § 7.8.2 Simulation results § 7.9 IP over WDM traffic engineering software design § 7.9.1 Software architecture for overlay traffic engineering § 7.9.2 Software architecture for integrated traffic engineering § 7.9.3 IP Traffic Engineering to Network Control Protocol (IP TECP) § 7.9.3.1 Inventory request and response message § 7.9.3.2 Traffic statistics request message § 7.9.3.3 Traffic statistics response message § 7.9.3.4 Virtual connection status request and response message § 7.9.4 IP/WDM User to Network Interface (UNI) § 7.9.4.1 Lightpath create request § 7.9.4.2 Lightpath create response § 7.9.4.3 Lightpath delete request § 7.9.4.4 Lightpath delete response § 7.9.4.5 Trap § 7.9.5 WDM Traffic Engineering to Network Control Protocol (WDM TECP) § 7.9.5.1 WDM TECP message types § 7.9.5.2 Create and update trail request message (TReq) § 7.9.5.3 Explicit route trail request message (ETReq) § 7.9.5.4 Trail response message (TResp) § 7.9.5.5 Event notification message (EN) § 7.9.5.6 IP/WDM address resolution § 7.9.6 IP/WDM traffic engineering tools § 7.10 Feedback-based closed-loop traffic engineering § 7.10.1 Network topology implementation process § 7.10.2 Network convergence § 7.10.3 A testbed study on IP/WDM traffic engineering § 7.10.3.1 IP/WDM testbed description § 7.10.3.2 Testbed experimentation § 7.11 Summary Chapter 8. Other IP/WDM Specific Issues § 8.1 IP/WDM group communication § 8.1.1 IP multicasting § 8.1.2 IP multicasting in presence of GMPLS § 8.1.3 IP over WDM multicasting § 8.2 IP/WDM network and service management § 8.2.1 CORBA reference model and Telecom facility § 8.2.2 Connection and Service Management Information Modeling (CaSMIM) § 8.2.3 Optical network service management § 8.3 TCP over optical networks Chapter 9. Concluding Remarks § 9.1 Book summary § 9.2 IP/WDM network applications § 9.2.1 MAN and WAN network transport § 9.2.2 Layer 2 or layer 3 VPN, VLAN, leased fibre line or wavelength channel § 9.2.3 Optical interconnect § 9.2.4 Bandwidth brokers and traders § 9.3 Future research § 9.3.1 Scalable common control plane for optical networks § 9.3.2 Next generation of TCP/IP § 9.3.3 TCP/IP performance studies in presence of a number of parallel paths and unifirectional LSPs § 9.3.4 Optical packet switching § 9.3.5 Service protection and restoration § 9.3.6 Optical network applications § 9.3.7 Optical MIB development Bibliography Web Site List Acronym List Index +++++++++++++++++++++++++++++++++++++++++++++++ __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 01:35:11 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 BAA28315 for ; Fri, 8 Nov 2002 01:35:11 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA86b2128386 for ; Fri, 8 Nov 2002 01:37: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 gA86awK16706 for ; Fri, 8 Nov 2002 01:36:58 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 07 Nov 2002 22:36:12 -0800 Subject: Re: =?GB2312?B?tPC4tDogtPC4tDogtao=?= From: Ray Qiu To: Bin Li CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" X-OriginalArrivalTime: 08 Nov 2002 06:36:06.0610 (UTC) FILETIME=[1DDDA320:01C286F1] X-SMTP-HELO: RS-SC-EXC4.rs.riverstonenet.com X-SMTP-MAIL-FROM: rqiu@riverstonenet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host60.riverstonenet.com [64.95.122.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA28315 Bin, What I meant was that you could use normal L2 technologies, such as VLAN, PVC, to tunnel the customer IP traffic to the 2547 PEs. This way you could use a much cheap box at the very edge, instead of a router that needs to support MPLS and MP-BGP. I agree that hierarchical design will help to improve scalability if applicable. It seems that the method can be achieved by configurations (MP-BGP and BGP policies) and it doesn't require new techniques. - Ray How many customers will you connect on the UPE? On 11/7/02 21:50, "Bin Li" wrote: > In theory, VLAN can transport via WAN link. But it'll as expensive as other > WAN technology. And it's not the only choice. Users can access PE by VLAN, > ATM, FR, PoS, E1 and etc. Why should we use label to separate VPN site? MPLS > label can work on any Layer 2 technology. > Each IP interface/address will never consume more than resource MP-BGP, but > many IP interface/address will consume more than MP-BGP. In the other word. > HoPE is very scalability. MP-BGP is a dynamic mechanism, but VLAN will be > configured each by each manually. > BTW, if SPE directly links with UPE, UPE needn't run LDP/RSVP. > > -----ԭʼÓʼþ----- > ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] > ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 11:59 > ÊÕ¼þÈË: Bin Li > Ö÷Ìâ: Re: ´ð¸´: µª > > > > Bin, > > It sounds to me like an implementation issue. VLAN can be supported on WAN > links as well as 802.1Q. IP interface/address would never consume more > resource than MP-BGP and LDP/RSVP. > > - Ray > > On 11/7/02 19:51, "Bin Li" wrote: > >> Ray, >> The key is the distance between UPE and SPE. Sometime, you must use a WAN >> link >> between them. And when VLANs are used to separate sites, you must configure >> many VLAN in a PE, and assign a VLAN to a VRF. Usually, a VLAN in a router >> is >> a sub-interface, it should have a IP address and consume some resource. It's >> costly and difficult to maintain. >> >> >> >> >> -----ԭʼÓʼþ----- >> ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] >> ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 10:46 >> ÊÕ¼þÈË: •c•Ÿ—F >> ³­ËÍ: ppvpn@nortelnetworks.com >> Ö÷Ìâ: Re: µª From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 01:48:29 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 BAA28605 for ; Fri, 8 Nov 2002 01:48:28 -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 gA86oP102480 for ; Fri, 8 Nov 2002 01:50: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 gA86oLK23355 for ; Fri, 8 Nov 2002 01:50:22 -0500 (EST) Date: Fri, 08 Nov 2002 14:50:19 +0800 From: Bin Li Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogtao=?= In-reply-to: To: Ray Qiu Cc: ppvpn@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id BAA28605 Sometime, It is necessary to provide VPN service at the very edge. Users don't want access PE by a long distance L2 link which is expensive. UPE can aggregate them and separate them by label. It only need one WAN link. It's cheap than many WAN links. SPE should do some more in this mechanism. The PE just according rfc2547bis will not work well in this environment. So I commit this proposal. -----ԭʼÓʼþ----- ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 14:36 ÊÕ¼þÈË: Bin Li ³­ËÍ: ppvpn@nortelnetworks.com Ö÷Ìâ: Re: ´ð¸´: ´ð¸´: µª Bin, What I meant was that you could use normal L2 technologies, such as VLAN, PVC, to tunnel the customer IP traffic to the 2547 PEs. This way you could use a much cheap box at the very edge, instead of a router that needs to support MPLS and MP-BGP. I agree that hierarchical design will help to improve scalability if applicable. It seems that the method can be achieved by configurations (MP-BGP and BGP policies) and it doesn't require new techniques. - Ray How many customers will you connect on the UPE? On 11/7/02 21:50, "Bin Li" wrote: > In theory, VLAN can transport via WAN link. But it'll as expensive as other > WAN technology. And it's not the only choice. Users can access PE by VLAN, > ATM, FR, PoS, E1 and etc. Why should we use label to separate VPN site? MPLS > label can work on any Layer 2 technology. > Each IP interface/address will never consume more than resource MP-BGP, but > many IP interface/address will consume more than MP-BGP. In the other word. > HoPE is very scalability. MP-BGP is a dynamic mechanism, but VLAN will be > configured each by each manually. > BTW, if SPE directly links with UPE, UPE needn't run LDP/RSVP. > > -----ԭʼÓʼþ----- > ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] > ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 11:59 > ÊÕ¼þÈË: Bin Li > Ö÷Ìâ: Re: ´ð¸´: µª > > > > Bin, > > It sounds to me like an implementation issue. VLAN can be supported on WAN > links as well as 802.1Q. IP interface/address would never consume more > resource than MP-BGP and LDP/RSVP. > > - Ray > > On 11/7/02 19:51, "Bin Li" wrote: > >> Ray, >> The key is the distance between UPE and SPE. Sometime, you must use a WAN >> link >> between them. And when VLANs are used to separate sites, you must configure >> many VLAN in a PE, and assign a VLAN to a VRF. Usually, a VLAN in a router >> is >> a sub-interface, it should have a IP address and consume some resource. It's >> costly and difficult to maintain. >> >> >> >> >> -----ԭʼÓʼþ----- >> ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] >> ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 10:46 >> ÊÕ¼þÈË: •c•Ÿ—F >> ³­ËÍ: ppvpn@nortelnetworks.com >> Ö÷Ìâ: Re: µª From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 03:08: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 DAA10022 for ; Fri, 8 Nov 2002 03:08: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 gA88Aa124823 for ; Fri, 8 Nov 2002 03:10: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 gA88AXK05996 for ; Fri, 8 Nov 2002 03:10:33 -0500 (EST) Message-ID: <00ce01c286fe$345695a0$d5736051@c2f4r3> Reply-To: "Brian Powell" From: "Brian Powell" To: "MVNO world" Subject: Doggie Fact Date: Fri, 8 Nov 2002 08:09:40 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01C286FE.345695A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: mta06-svc.ntlworld.com X-SMTP-MAIL-FROM: bpowell@arran.prestel.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mta06-svc.ntlworld.com [62.253.162.46] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_00CB_01C286FE.345695A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doggie Fact: A recent MORI poll of 2,000 UK mobile phone users asked about loss or damage to their mobiles - 4% said "the dog ate it". With an estimated 46 million mobile phone users in the UK,=20 this suggests around 1.8 million mobile phones=20 have been chewed up by dogs. Not a lot of people knew that - and even less know about Mobile Virtual Network Operators (MVNOs). The MVNO market is one of the few areas offering great potential = opportunity in an industry which is otherwise in the doldrums. To make sure YOU don't miss out on the chance to gain a better = understanding of this brand new market opportunity - visit: www.mvnoinfo.com, where = you can access our highly-acclaimed reports and can also find FREE WHITE PAPERS and a Community Section. Alternatively, contact Brian at: brian@mvnoinfo.com or Katalin at: = mvnoworld@thailand.com -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------ Messages are e-mailed to keep you up-to-date with new MVNOinfo topics, = products and services. If you prefer not to receive these messages, = please reply with 'unsubscribe' in the subject area. ------=_NextPart_000_00CB_01C286FE.345695A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Doggie Fact:
 
 
A=20 recent MORI poll of 2,000 UK mobile phone users=20 asked
about=20 loss or damage to their mobiles - 4% said "the dog = ate=20 it".
With=20 an estimated 46 million mobile phone users in the UK,=20
this = suggests around=20 1.8 million mobile phones =
have been = chewed up by=20 dogs.
 
 
Not a lot=20 of people knew that - and even less
 know=20 about Mobile Virtual Network Operators=20 (MVNOs).
 
 

The MVNO market is one of the few areas offering great = potential=20 opportunity

in an industry which is = otherwise in the=20 doldrums.

To make sure YOU don't miss out on the chance to gain = a better=20 understanding

of this brand new market opportunity - visit: www.mvnoinfo.com,=20 where you

can access our highly-acclaimed = reports and can also find

FREE=20 WHITE PAPERS and a Community=20 Section. Alternatively,

contact Brian at: brian@mvnoinfo.com or Katalin = at: mvnoworld@thailand.com
 
 
 
--------------------------------------------------= -------------------------------------------------------------------------= -----------------------------
Messages=20 are e-mailed to keep you up-to-date with new = MVNOinfo=20 topics, products and services. If you prefer not to receive these = messages,=20 please reply with 'unsubscribe' in the subject area.
 
 
 
------=_NextPart_000_00CB_01C286FE.345695A0-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 03:10:35 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 DAA10079 for ; Fri, 8 Nov 2002 03:10:35 -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 gA88CW127380 for ; Fri, 8 Nov 2002 03:12:32 -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 gA88CTK09183 for ; Fri, 8 Nov 2002 03:12:29 -0500 (EST) Message-ID: <3DCB7174.6E5CA448@cisco.com> Date: Fri, 08 Nov 2002 09:10:28 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bin Li CC: Ray Qiu , ppvpn@nortelnetworks.com Subject: Huawei draft References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-4.cisco.com id gA88Abot027927 X-SMTP-HELO: sj-msg-core-4.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-4.cisco.com [171.71.163.54] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA10079 Bin, > Sometime, It is necessary to provide VPN service > at the very edge. True. > Users don't want access PE by > a long distance L2 link which is expensive. True. > UPE > can aggregate them and separate them by label. > It only need one WAN link. It's cheap than > many WAN links. Why many WAN links ... I don't think there is any need for them. Your proposal may work indeed but IMHO adds unnecessary level of complication for SPs who already solved the same exact problem with a trival solution ;). The most commonly used way (- deployed already in multiple production networks) to achive exactly what your draft is after is so called managed service where CE (from original 2547 point of view) is not one routing context, but one router with multiple routing instances (multi-vrf) without any MPLS or any vpnv4 BGP sessions between such a box and PE. Then each vrf simply comunicates with PE by for example frame relay encapsulation over the same physical link so WAN link costs are independent from # of remote VPNs. Thx, R. Bin Li wrote: > > Sometime, It is necessary to provide VPN service at the very edge. Users don't want access PE by a long distance L2 link which is expensive. UPE can aggregate them and separate them by label. It only need one WAN link. It's cheap than many WAN links. > > SPE should do some more in this mechanism. The PE just according rfc2547bis will not work well in this environment. So I commit this proposal. > > -----ԭʼÓʼþ----- > ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] > ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 14:36 > ÊÕ¼þÈË: Bin Li > ³­ËÍ: ppvpn@nortelnetworks.com > Ö÷Ìâ: Re: ´ð¸´: ´ð¸´: µª > > Bin, > > What I meant was that you could use normal L2 technologies, such as VLAN, > PVC, to tunnel the customer IP traffic to the 2547 PEs. This way you could > use a much cheap box at the very edge, instead of a router that needs to > support MPLS and MP-BGP. > > I agree that hierarchical design will help to improve scalability if > applicable. > > It seems that the method can be achieved by configurations (MP-BGP and BGP > policies) and it doesn't require new techniques. > > - Ray > > How many customers will you connect on the UPE? > > On 11/7/02 21:50, "Bin Li" wrote: > > > In theory, VLAN can transport via WAN link. But it'll as expensive as other > > WAN technology. And it's not the only choice. Users can access PE by VLAN, > > ATM, FR, PoS, E1 and etc. Why should we use label to separate VPN site? MPLS > > label can work on any Layer 2 technology. > > Each IP interface/address will never consume more than resource MP-BGP, but > > many IP interface/address will consume more than MP-BGP. In the other word. > > HoPE is very scalability. MP-BGP is a dynamic mechanism, but VLAN will be > > configured each by each manually. > > BTW, if SPE directly links with UPE, UPE needn't run LDP/RSVP. > > > > -----ԭʼÓʼþ----- > > ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] > > ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 11:59 > > ÊÕ¼þÈË: Bin Li > > Ö÷Ìâ: Re: ´ð¸´: µª > > > > > > > > Bin, > > > > It sounds to me like an implementation issue. VLAN can be supported on WAN > > links as well as 802.1Q. IP interface/address would never consume more > > resource than MP-BGP and LDP/RSVP. > > > > - Ray > > > > On 11/7/02 19:51, "Bin Li" wrote: > > > >> Ray, > >> The key is the distance between UPE and SPE. Sometime, you must use a WAN > >> link > >> between them. And when VLANs are used to separate sites, you must configure > >> many VLAN in a PE, and assign a VLAN to a VRF. Usually, a VLAN in a router > >> is > >> a sub-interface, it should have a IP address and consume some resource. It's > >> costly and difficult to maintain. > >> > >> > >> > >> > >> -----ԭʼÓʼþ----- > >> ·¢¼þÈË: Ray Qiu [mailto:rayq@riverstonenet.com] > >> ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 10:46 > >> ÊÕ¼þÈË: •c•Ÿ—F > >> ³­ËÍ: ppvpn@nortelnetworks.com > >> Ö÷Ìâ: Re: µª From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 04:01:24 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 EAA10989 for ; Fri, 8 Nov 2002 04:01:24 -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 gA893F115338 for ; Fri, 8 Nov 2002 04:03:16 -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 gA893CK22344 for ; Fri, 8 Nov 2002 04:03:13 -0500 (EST) Date: Fri, 08 Nov 2002 16:51:05 +0800 From: Bin Li Subject: =?utf-8?B?562U5aSNOiBIdWF3ZWkgZHJhZnQ=?= In-reply-to: <3DCB7174.6E5CA448@cisco.com> To: raszuk@cisco.com Cc: ppvpn@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=utf-8 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA10989 Robert, The difference between HoPE and Mulit-VRF are: 1 According Multi-VRF, PE and Multi-VRF CE need one sub-interface and one IP address for every VPN. But according HoPE, SPE and UPE need only one sub-interface and one IP address for all VPN; 2 By ORF mechanism, SPE NEED NOT configure VRFs which already be configured in UPE. But according Mulit-VRF, PE must do redundant work. 3 According Mulit-VRF, In the worst case, PE need run one PE-CE routing protocol instance for every VPN. But according HoPE, just one MP-BGP instance run between SPE and UPE. It's independent from # of VPN. 4 SPE and UPE can link with a tunnel. To do the same thing, there need multiple tunnels between PE and Multi-VRF CE. In general, HoPE is some dynamic mechanism. But Multi-VRF is some static mechanism. And in general case, the cost of HoPE is little than Multi-VRF. -----原始邮件----- å‘件人: Robert Raszuk [mailto:raszuk@cisco.com] å‘é€æ—¶é—´: 2002å¹´11月8æ—¥ 16:10 收件人: Bin Li 抄é€: Ray Qiu; ppvpn@nortelnetworks.com 主题: Huawei draft Bin, > Sometime, It is necessary to provide VPN service > at the very edge. True. > Users don't want access PE by > a long distance L2 link which is expensive. True. > UPE > can aggregate them and separate them by label. > It only need one WAN link. It's cheap than > many WAN links. Why many WAN links ... I don't think there is any need for them. Your proposal may work indeed but IMHO adds unnecessary level of complication for SPs who already solved the same exact problem with a trival solution ;). The most commonly used way (- deployed already in multiple production networks) to achive exactly what your draft is after is so called managed service where CE (from original 2547 point of view) is not one routing context, but one router with multiple routing instances (multi-vrf) without any MPLS or any vpnv4 BGP sessions between such a box and PE. Then each vrf simply comunicates with PE by for example frame relay encapsulation over the same physical link so WAN link costs are independent from # of remote VPNs. Thx, R. Bin Li wrote: > > Sometime, It is necessary to provide VPN service at the very edge. Users don't want access PE by a long distance L2 link which is expensive. UPE can aggregate them and separate them by label. It only need one WAN link. It's cheap than many WAN links. > > SPE should do some more in this mechanism. The PE just according rfc2547bis will not work well in this environment. So I commit this proposal. > > -----Ô­ê¼óê¼þ----- > ·￠¼þèË: Ray Qiu [mailto:rayq@riverstonenet.com] > ·￠Ëíê±¼ä: 2002Äê11ÔÂ8èÕ 14:36 > êÕ¼þèË: Bin Li > ³­Ëí: ppvpn@nortelnetworks.com > Ö÷ìâ: Re: ′ð¸′: ′ð¸′: μª > > Bin, > > What I meant was that you could use normal L2 technologies, such as VLAN, > PVC, to tunnel the customer IP traffic to the 2547 PEs. This way you could > use a much cheap box at the very edge, instead of a router that needs to > support MPLS and MP-BGP. > > I agree that hierarchical design will help to improve scalability if > applicable. > > It seems that the method can be achieved by configurations (MP-BGP and BGP > policies) and it doesn't require new techniques. > > - Ray > > How many customers will you connect on the UPE? > > On 11/7/02 21:50, "Bin Li" wrote: > > > In theory, VLAN can transport via WAN link. But it'll as expensive as other > > WAN technology. And it's not the only choice. Users can access PE by VLAN, > > ATM, FR, PoS, E1 and etc. Why should we use label to separate VPN site? MPLS > > label can work on any Layer 2 technology. > > Each IP interface/address will never consume more than resource MP-BGP, but > > many IP interface/address will consume more than MP-BGP. In the other word. > > HoPE is very scalability. MP-BGP is a dynamic mechanism, but VLAN will be > > configured each by each manually. > > BTW, if SPE directly links with UPE, UPE needn't run LDP/RSVP. > > > > -----Ô­ê¼óê¼þ----- > > ·￠¼þèË: Ray Qiu [mailto:rayq@riverstonenet.com] > > ·￠Ëíê±¼ä: 2002Äê11ÔÂ8èÕ 11:59 > > êÕ¼þèË: Bin Li > > Ö÷ìâ: Re: ′ð¸′: μª > > > > > > > > Bin, > > > > It sounds to me like an implementation issue. VLAN can be supported on WAN > > links as well as 802.1Q. IP interface/address would never consume more > > resource than MP-BGP and LDP/RSVP. > > > > - Ray > > > > On 11/7/02 19:51, "Bin Li" wrote: > > > >> Ray, > >> The key is the distance between UPE and SPE. Sometime, you must use a WAN > >> link > >> between them. And when VLANs are used to separate sites, you must configure > >> many VLAN in a PE, and assign a VLAN to a VRF. Usually, a VLAN in a router > >> is > >> a sub-interface, it should have a IP address and consume some resource. It's > >> costly and difficult to maintain. > >> > >> > >> > >> > >> -----Ô­ê¼óê¼þ----- > >> ·￠¼þèË: Ray Qiu [mailto:rayq@riverstonenet.com] > >> ·￠Ëíê±¼ä: 2002Äê11ÔÂ8èÕ 10:46 > >> êÕ¼þèË: •c•Ÿ—F > >> ³­Ëí: ppvpn@nortelnetworks.com > >> Ö÷ìâ: Re: μª From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 04:22:33 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 EAA11300 for ; Fri, 8 Nov 2002 04:22:33 -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 gA89OP120088 for ; Fri, 8 Nov 2002 04:24:26 -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 gA89OMK10464 for ; Fri, 8 Nov 2002 04:24:22 -0500 (EST) Date: Fri, 08 Nov 2002 17:07:09 +0800 From: ma shaowen Subject: HoVPN To: Bin Li , Ray Qiu Cc: ppvpn@nortelnetworks.com Message-id: <00dd01c28706$3abaf640$af226e0a@m19126> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-SMTP-HELO: mta1 X-SMTP-MAIL-FROM: marshal@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.15] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT But if you implement RFC3107, you can easyly control the route with a label send to the UPE and ... ----- Original Message ----- From: "Bin Li" To: "Ray Qiu" Cc: Sent: Friday, November 08, 2002 2:50 PM Subject: > Sometime, It is necessary to provide VPN service at the very edge. Users don't want access PE by a long distance L2 link which is expensive. UPE can aggregate them and separate them by label. It only need one WAN link. It's cheap than many WAN links. > > SPE should do some more in this mechanism. The PE just according rfc2547bis will not work well in this environment. So I commit this proposal. > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 04:55:42 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11810 for ; Fri, 8 Nov 2002 04:55:42 -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 gA89vc126346 for ; Fri, 8 Nov 2002 04:57:38 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gA89vZK25386 for ; Fri, 8 Nov 2002 04:57:35 -0500 (EST) Date: Fri, 08 Nov 2002 17:42:50 +0800 From: Bin Li Subject: =?gb2312?B?tPC4tDogSG9WUE4=?= In-reply-to: <00dd01c28706$3abaf640$af226e0a@m19126> To: ma shaowen Cc: ppvpn@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA11810 Yes, BGP can work well there. So I didn't define LDP or other Auto Discovery protocol to instead it. -----ԭʼÓʼþ----- ·¢¼þÈË: ma shaowen [mailto:marshal@huawei.com] ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 17:07 ÊÕ¼þÈË: Bin Li; Ray Qiu ³­ËÍ: ppvpn@nortelnetworks.com Ö÷Ìâ: HoVPN But if you implement RFC3107, you can easyly control the route with a label send to the UPE and ... ----- Original Message ----- From: "Bin Li" To: "Ray Qiu" Cc: Sent: Friday, November 08, 2002 2:50 PM Subject: > Sometime, It is necessary to provide VPN service at the very edge. Users don't want access PE by a long distance L2 link which is expensive. UPE can aggregate them and separate them by label. It only need one WAN link. It's cheap than many WAN links. > > SPE should do some more in this mechanism. The PE just according rfc2547bis will not work well in this environment. So I commit this proposal. > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 05:28:08 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 FAA12410 for ; Fri, 8 Nov 2002 05:28:08 -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 gA8ATi116421 for ; Fri, 8 Nov 2002 05:29:45 -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 gA8ATgK11912 for ; Fri, 8 Nov 2002 05:29:42 -0500 (EST) Date: Fri, 8 Nov 2002 05:28:56 -0500 (EST) From: Senthilkumar Rajasekharan To: lidefeng cc: ppvpn@nortelnetworks.com Subject: Re: Please Review: A new draft about PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) In-Reply-To: <002e01c2854e$84f83ec0$22436e0a@HUAWEI.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: caip.rutgers.edu X-SMTP-MAIL-FROM: senthil@caip.rutgers.edu X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: caip.rutgers.edu [128.6.236.10] X-LYRIS-Message-Id: Hi Defeng Li, Some questions on your draft .... Section 2.1 SPE advertised the VRF default route or aggregate routes(by which UPE transfer the VPN packet to SPE) to UPE,this default VRF route can be formed dynamically or configured statically.When formed dynamically,it can be filtered by the ORF mechanism mentioned above. <...> Is this procedure mandatory, i.e should the SPE always advertise a default route or aggregate route to the UPE? And should that route be advertised with an aggregated export target list of all the import route targets received via an ORF Route Refresh message from the UPE? Section 2.2 (7) SPE replace the inner label distributed by UPE with another inner label distributed by SPE,then advertise this route to PE through MP-BGP with the new inner label attached; <...> I don't understand why the SPE would replace UPE distributed inner label here ?? Section 7 In another case that SPE connect one UPE and one CE,CE connect to site1,UPE connect to site2,site1 and site2 belong to the same VPN. The forwarding procedure is as follows:When the packet with no label sent from site1 arrived to SPE through CE, SPE push the label distributed by UPE,forward it to UPE,UPE POP this label,then look up the VRF route table,PUSH the label distribute by UPE2 and forward it to UPE2,and UPE2 POP the label,forward it to site2. <...> What is UPE2 here .... may be this is a typo !! Thanks & Regards, -Senthil On Wed, 6 Nov 2002, lidefeng wrote: > Hi,all, > > In BGP/MPLS VPN area, we proposed a new idea as to resolve the bottleneck > of > the capacity of some PEs when deploy the huge size VPN,the whole idea is > detailed > in the attached draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > Abstract > is as follows,we are appreciated for your review. > > In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should > maintain all the VPN routes of the VPNs which it belong to.When there > are many VPNs converged by a PE,and the capacity of PE is relevant > limited,then the bottleneck will be encountered.Another problem is > that the current BGP/MPLS VPN model is something of a "Plane Modle" > where the demand of the performance of the PE device are all the > same no matter which layer the PE device is belongs to.However,the > typical network is "Core-Convergence-Access(Edge)" model,and the > performance of the device is superior in Core Layer and inferior in > Access Layer,and the scale of network is large in Access Layer and > small in Core Layer,the routes are converged in every layer,so in > current "Plane Modle",when PE device push to the edge layer,it has > to maintain more VPN routes,this makes it difficult to extend the PE > device to edge layer.This document defines an model of hiberarchy of > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider > Edge Device can be composed of several device and every device take > on the different part,partake the function of the former > concentrative PE,we call this model "Hiberarchy Model",In this model > the demand of performance in Routing and Switching is strict to the > PE device in High layer,loose to the PE device in edge layer. > > One HoPE can be composed of a SPE and UPES connected to the SPE, > or be composed of a high-level SPE and HoPEs connected the high > level SPE and and build up a new HoPE.This build is called nesting > of HoPE,and this kind of nesting can be done for many times.Thus the > former HoPE connect to the high-level SPE as a role of UPE,and the > new HoPE can connect a single UPE too. > > Regards > > Defeng Li > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 07:26:33 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 HAA14451 for ; Fri, 8 Nov 2002 07:26:32 -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 gA8CSS126675 for ; Fri, 8 Nov 2002 07:28: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 gA8CSPK16751 for ; Fri, 8 Nov 2002 07:28:25 -0500 (EST) Message-ID: <3DCBACDA.64BC7414@cisco.com> Date: Fri, 08 Nov 2002 13:23:54 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bin Li CC: ppvpn@nortelnetworks.com Subject: Re: ??: Huawei draft References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-1.cisco.com id gA8CNwPP009348 X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA14451 Hi Bin, > 1 According Multi-VRF, PE and Multi-VRF CE need one sub-interface and one IP address for every VPN. But according HoPE, SPE and UPE need only one sub-interface and one IP address for all VPN; SPE yes when it does not also serve some sites of given VPN directly. But UPE - no the above is not true. On UPE you will have excatly the same number of vrfs as you would have on multi-vrf box. > 2 By ORF mechanism, SPE NEED NOT configure VRFs which already be configured in UPE. But according Mulit-VRF, PE must do redundant work. ORF has nothing to do with VRF configuration. It is just a vehicle to push your bgp inbound policy to your peer. > 3 According Mulit-VRF, In the worst case, PE need run one PE-CE routing protocol instance for every VPN. But according HoPE, just one MP-BGP instance run between SPE and UPE. It's independent from # of VPN. True. > 4 SPE and UPE can link with a tunnel. To do the same thing, there need multiple tunnels between PE and Multi-VRF CE. True. > In general, HoPE is some dynamic mechanism. But Multi-VRF is some static mechanism. And in general case, the cost of HoPE is little than Multi-VRF. Also True ;). But we already have also a dynamic mechanism to achive exactly the goal here. What you are proposing here it is the trival case of L3VPNs inter-as mechanism (option b). Cheers, R. > -----原始邮件----- > å‘件人: Robert Raszuk [mailto:raszuk@cisco.com] > å‘é€æ—¶é—´: 2002å¹´11月8æ—¥ 16:10 > 收件人: Bin Li > 抄é€: Ray Qiu; ppvpn@nortelnetworks.com > 主题: Huawei draft > > Bin, > > > Sometime, It is necessary to provide VPN service > > at the very edge. > > True. > > > Users don't want access PE by > > a long distance L2 link which is expensive. > > True. > > > UPE > > can aggregate them and separate them by label. > > It only need one WAN link. It's cheap than > > many WAN links. > > Why many WAN links ... I don't think there is any need for them. Your > proposal may work indeed but IMHO adds unnecessary level of complication > for SPs who already solved the same exact problem with a trival solution > ;). > > The most commonly used way (- deployed already in multiple production > networks) to achive exactly what your draft is after is so called > managed service where CE (from original 2547 point of view) is not one > routing context, but one router with multiple routing instances > (multi-vrf) without any MPLS or any vpnv4 BGP sessions between such a > box and PE. > > Then each vrf simply comunicates with PE by for example frame relay > encapsulation over the same physical link so WAN link costs are > independent from # of remote VPNs. > > Thx, > R. > > Bin Li wrote: > > > > Sometime, It is necessary to provide VPN service at the very edge. Users don't want access PE by a long distance L2 link which is expensive. UPE can aggregate them and separate them by label. It only need one WAN link. It's cheap than many WAN links. > > > > SPE should do some more in this mechanism. The PE just according rfc2547bis will not work well in this environment. So I commit this proposal. > > > > -----Ô­ê¼óê¼þ----- > > Â·ï¿ Â¼Ã¾Ã¨Ã‹: Ray Qiu [mailto:rayq@riverstonenet.com] > > Â·ï¿ Ã‹Ã­ÃªÂ±Â¼Ã¤: 2002Äê11ÔÂ8èÕ 14:36 > > êÕ¼þèË: Bin Li > > ³­Ëí: ppvpn@nortelnetworks.com > > Ö÷ìâ: Re: ′ð¸′: ′ð¸′: μª > > > > Bin, > > > > What I meant was that you could use normal L2 technologies, such as VLAN, > > PVC, to tunnel the customer IP traffic to the 2547 PEs. This way you could > > use a much cheap box at the very edge, instead of a router that needs to > > support MPLS and MP-BGP. > > > > I agree that hierarchical design will help to improve scalability if > > applicable. > > > > It seems that the method can be achieved by configurations (MP-BGP and BGP > > policies) and it doesn't require new techniques. > > > > - Ray > > > > How many customers will you connect on the UPE? > > > > On 11/7/02 21:50, "Bin Li" wrote: > > > > > In theory, VLAN can transport via WAN link. But it'll as expensive as other > > > WAN technology. And it's not the only choice. Users can access PE by VLAN, > > > ATM, FR, PoS, E1 and etc. Why should we use label to separate VPN site? MPLS > > > label can work on any Layer 2 technology. > > > Each IP interface/address will never consume more than resource MP-BGP, but > > > many IP interface/address will consume more than MP-BGP. In the other word. > > > HoPE is very scalability. MP-BGP is a dynamic mechanism, but VLAN will be > > > configured each by each manually. > > > BTW, if SPE directly links with UPE, UPE needn't run LDP/RSVP. > > > > > > -----Ô­ê¼óê¼þ----- > > > Â·ï¿ Â¼Ã¾Ã¨Ã‹: Ray Qiu [mailto:rayq@riverstonenet.com] > > > Â·ï¿ Ã‹Ã­ÃªÂ±Â¼Ã¤: 2002Äê11ÔÂ8èÕ 11:59 > > > êÕ¼þèË: Bin Li > > > Ö÷ìâ: Re: ′ð¸′: μª > > > > > > > > > > > > Bin, > > > > > > It sounds to me like an implementation issue. VLAN can be supported on WAN > > > links as well as 802.1Q. IP interface/address would never consume more > > > resource than MP-BGP and LDP/RSVP. > > > > > > - Ray > > > > > > On 11/7/02 19:51, "Bin Li" wrote: > > > > > >> Ray, > > >> The key is the distance between UPE and SPE. Sometime, you must use a WAN > > >> link > > >> between them. And when VLANs are used to separate sites, you must configure > > >> many VLAN in a PE, and assign a VLAN to a VRF. Usually, a VLAN in a router > > >> is > > >> a sub-interface, it should have a IP address and consume some resource. It's > > >> costly and difficult to maintain. > > >> > > >> > > >> > > >> > > >> -----Ô­ê¼óê¼þ----- > > >> Â·ï¿ Â¼Ã¾Ã¨Ã‹: Ray Qiu [mailto:rayq@riverstonenet.com] > > >> Â·ï¿ Ã‹Ã­ÃªÂ±Â¼Ã¤: 2002Äê11ÔÂ8èÕ 10:46 > > >> êÕ¼þèË: •c•Ÿ—F > > >> ³­Ëí: ppvpn@nortelnetworks.com > > >> Ö÷ìâ: Re: μª From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 07:33: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 HAA15208 for ; Fri, 8 Nov 2002 07:32:59 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA8CYq100394 for ; Fri, 8 Nov 2002 07:34:53 -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 gA8CYoK23328 for ; Fri, 8 Nov 2002 07:34:50 -0500 (EST) Message-Id: <200211081231.HAA14906@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-lee-ppvpn-ce-auto-config-02.txt Date: Fri, 08 Nov 2002 07:31:56 -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 : CE Auto-configuration Author(s) : C. Lee Filename : draft-lee-ppvpn-ce-auto-config-02.txt Pages : 14 Date : 2002-11-7 This draft describes the protocols required to automatically configure a Customer Equipment (CE) to support a VPN service offered by the provider (aka as Provider Provisioned CE-based VPN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-ppvpn-ce-auto-config-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lee-ppvpn-ce-auto-config-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lee-ppvpn-ce-auto-config-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7155526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lee-ppvpn-ce-auto-config-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-lee-ppvpn-ce-auto-config-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7155526.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 07:37:27 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 HAA16138 for ; Fri, 8 Nov 2002 07:37:27 -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 gA8CdG104736 for ; Fri, 8 Nov 2002 07:39:17 -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 gA8CdDK29633 for ; Fri, 8 Nov 2002 07:39:14 -0500 (EST) Message-Id: <200211081236.HAA15877@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-bgp-ipv6-vpn-03.txt Date: Fri, 08 Nov 2002 07:36:01 -0500 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : BGP-MPLS VPN extension for IPv6 VPN Author(s) : G. De Clercq et al. Filename : draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt Pages : 14 Date : 2002-11-7 This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method extends the 'BGP/MPLS VPN' method [2547bis] for support of IPv6. In BGP/MPLS VPN, 'Multiprotocol BGP' is used for distributing IPv4 VPN routes over the service provider backbone and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding route distribution in 'Multiprotocol BGP'. This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and using various tunnelling techniques over the core including MPLS, IPsec, IP-in-IP and GRE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160355.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 10:31:44 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 KAA23026 for ; Fri, 8 Nov 2002 10:31:44 -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 gA8FXc104270 for ; Fri, 8 Nov 2002 10:33:39 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gA8FXYK06631 for ; Fri, 8 Nov 2002 10:33:35 -0500 (EST) From: "Jim Guichard" To: "=?gb2312?B?Pz8/oeqorj8=?=" , "=?gb2312?B?J6Gnoeg/P6ikoac/Jw==?=" Cc: , "Marco Carugi" , , , , , , , , Subject: =?gb2312?B?UkU6ILTwuLQ6ILTwuLQ6IFBsZWFzZSBSZXZpZXc6IEEgbmV3IGRyYQ==?= =?gb2312?B?ZnQgYWJvdXQgUFBWUE4oSGliZXJhcmNoeSBvZiBQRSBEZXZpY2UgaQ==?= =?gb2312?B?bkJHUC9NUExTIFZQTik=?= Date: Fri, 8 Nov 2002 10:28:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <000001c286cb$979b0fc0$2e426e0a@HUAWEI.COM> X-MIME-Autoconverted: from 8bit to quoted-printable by cisco.com id PAA00387 X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: london2.cisco.com [64.103.110.74] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA23026 Hi Miao, I understand that this is not a replacement to 2547. I also understand that hierarchy is one of the tools we have to help scale networks. However, what I am driving at is that 2547 provides all of the necessary mechanisms already to run this type of topology - deployment of 2547 is a matter of design and no new functionality is necessary to be able to run the topology you are suggesting. We have many deployments worldwide that already use this type of design to provide central services to their customers. This does not mean however that the topology is appropriate for all 2547 customers. There are a number of issues with the proposed topology that one might consider: 1. In most real world deployments the number of hops between UPE and SPE will be > 1. This may introduce unacceptable latency and so on, especially as the design is being used for transit traffic rather than central services. 2. Using this method introduces additional IP address lookups between ingress PE and egress PE, plus label disposition/imposition. 3. Unless the SPE is located locally to the UPE then the regional VPN traffic will be concentrated toward certain points of the network, instead of being distributed across the whole infrastructure. 4. If the SPE is located locally, then aggregates can be injected down to the UPEs but this is assuming that the address space is designed in such a way as to allow this aggregation. Most Enterprise networks today do not have such a well structured addressing plan. 5. By injecting aggregates toward the CE site you change the customers routing view which may actually require the injection of more specific routes. 6. The SP has to keep track of the aggregation and configure it appropriately at the SPE. 7. How do you take care of customers that want to run OSPF or ISIS on the PE-CE links ? how would sham-links work for example ? 8. To deploy H&S designs one must use different RTs for the same VPN and then apply policy to filter correctly. This may not be such a big deal but is a further complication in the provisioning and management process. 9. If our goal is to offload the edge routers from having to carry VPNv4 routes or run MP-BGP sessions then perhaps we should use the L2-transport functionality in MPLS to carry the edge traffic to an SPE. This has the advantage that the CE can exchange routes directly with the SPE which is useful for other applications. 10. How do you take care of customers that want to run Carrier's Carrier architecture ? regards, > >-----Original Message----- > >From: Ã縣ÓÑ [mailto:miaofy@huawei.com] > >Sent: Thursday, November 07, 2002 9:07 PM > >To: 'Jim Guichard'; '¨¤?¡À¨®' > >Cc: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; > >leh10814@huawei.com > >Subject: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > > > > > >Hi, Jim: > > > >This draft is not to replace 2547, but a supplement to it. Actually the > >VPN in the draft is completely works under the mechanism of 2547. > > > >In the traditional 2547 VPN, only one type of PE is defined. When > >deployment, PE will not has so many ports to attach many VPNs if the PE > >is at the core layer of the network, because core router generally > >doesn't have a lot of physically interfaces. If the PE is at the edge > >of the network, it will have a lot of interfaces, but now the botlleneck > >is capacity of computation of the router. > > > >This draft is to solve the problem, UPE will provide abundant interface > >to conenct sites to VPN and SPE will have enough CPU/Memory to process > >routes. > > > >Regards > >Miao > > > >-----ÓʼþÔ­¼þ----- > >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 > >ÊÕ¼þÈË: ¨¤?¡À¨® > >³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco Carugi; > >sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; > >ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; > >changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com > >Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE > >Device inBGP/MPLS VPN) > > > > > >so can hub&spoke with 2547 - you basically export routes from the > >CE-attached PEs to a hub PE that imports the routes. The hub PE exports > >either a default or aggregates to attract traffic from other CE-attached > >PEs and then performs a lookup to forward the packets to other > >CE-attached PEs .. Jim > > > >> >-----Original Message----- > >> >From: Àî±ó [mailto:l.b@huawei.com] > >> >Sent: Thursday, November 07, 2002 2:42 AM > >> >To: Jim Guichard > >> >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >> >marco.carugi@nortelnetworks.com; sob@harvard.edu; bwijnen@lucent.com; > > > >> >zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; > >> >Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >> >leh10814@huawei.com > >> >Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of > >PE > >> >Device inBGP/MPLS VPN) > >> > > >> > > >> >Hi, Guichard > >> >The hub & spoke is the relationship between CEs, but SPE peer with > >> >UPE by MP-BGP, they are all PEs, and they all can admit VPN user. > >> > > >> >Libin > >> > > >> >-----ԭʼÓʼþ----- > >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >> >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >> >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >> >leh10814@huawei. com; l.b@huawei.com > >> >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE > >> >Device inBGP/MPLS VPN) > >> > > >> > > >> >I briefly ran through this draft and it looks like normal hub & spoke > > > >> >using existing 2547 mechanisms - could you explain how this differs ? > > > >> >thanks, > >> > > >> >> >-----Original Message----- > >> >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >> >To: internet-drafts@ietf.org > >> >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > > > >> >> >leh10814@huawei.com; l.b@huawei.com > >> >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE > >> >> >Device in BGP/MPLS VPN) > >> >> > > >> >> > > >> >> >Hi,all, > >> >> > > >> >> > In BGP/MPLS VPN area, we proposed a new idea as to resolve the > >> >> >bottleneck of > >> >> >the capacity of some PEs when deploy the huge size VPN,the > >> >whole idea is > >> >> >detailed > >> >> >in the attached > >> >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >> >> >Abstract is as follows,we are appreciated for your review. > >> >> > > >> >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >> >Edge)Device should > >> >> > maintain all the VPN routes of the VPNs which it belong > >> >to.When there > >> >> > are many VPNs converged by a PE,and the capacity of PE is > >relevant > >> >> > limited,then the bottleneck will be encountered.Another problem > >is > >> >> > that the current BGP/MPLS VPN model is something of a "Plane > >Modle" > >> >> > where the demand of the performance of the PE device are all > >the > >> >> > same no matter which layer the PE device is belongs to.However, > >the > >> >> > typical network is "Core-Convergence-Access(Edge)" model,and > >the > >> >> > performance of the device is superior in Core Layer and > >inferior in > >> >> > Access Layer,and the scale of network is large in Access Layer > >and > >> >> > small in Core Layer,the routes are converged in every layer,so > >in > >> >> > current "Plane Modle",when PE device push to the edge layer,it > >has > >> >> > to maintain more VPN routes,this makes it difficult to > >> >extend the PE > >> >> > device to edge layer.This document defines an model of > >> >hiberarchy of > >> >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of > >Provider > >> >> > Edge Device can be composed of several device and every device > >take > >> >> > on the different part,partake the function of the former > >> >> > concentrative PE,we call this model "Hiberarchy Model",In > >> >this model > >> >> > the demand of performance in Routing and Switching is strict to > >the > >> >> > PE device in High layer,loose to the PE device in edge layer. > >> >> > > >> >> > One HoPE can be composed of a SPE and UPES connected to the > >SPE, > >> >> > or be composed of a high-level SPE and HoPEs connected the high > >> >> > level SPE and and build up a new HoPE.This build is called > >nesting > >> >> > of HoPE,and this kind of nesting can be done for many > >> >times.Thus the > >> >> > former HoPE connect to the high-level SPE as a role of UPE,and > >the > >> >> > new HoPE can connect a single UPE too. > >> >> > > >> >> >Regards > >> >> > > >> >> >Defeng Li > >> >> > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 11:36: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 LAA26172 for ; Fri, 8 Nov 2002 11:36:40 -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 gA8GcX119740 for ; Fri, 8 Nov 2002 11:38:33 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gA8GcUK20393 for ; Fri, 8 Nov 2002 11:38:30 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 08 Nov 2002 08:38:00 -0800 Subject: Re: ??: Huawei draft From: Ray Qiu To: , Bin Li CC: Message-ID: In-Reply-To: <3DCBACDA.64BC7414@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Nov 2002 16:37:53.0665 (UTC) FILETIME=[2F58FF10:01C28745] X-SMTP-HELO: RS-SC-EXC4.rs.riverstonenet.com X-SMTP-MAIL-FROM: rqiu@riverstonenet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host60.riverstonenet.com [64.95.122.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On 11/8/02 4:23, "Robert Raszuk" wrote: >> In general, HoPE is some dynamic mechanism. But Multi-VRF is some static >> mechanism. And in general case, the cost of HoPE is little than Multi-VRF. > > Also True ;). But we already have also a dynamic mechanism to achive > exactly the goal here. What you are proposing here it is the trival case > of L3VPNs inter-as mechanism (option b). Exactly. - Ray From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 12:05: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 MAA28124 for ; Fri, 8 Nov 2002 12:05:12 -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 gA8H78103042 for ; Fri, 8 Nov 2002 12:07:08 -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 gA8H75K15979 for ; Fri, 8 Nov 2002 12:07:05 -0500 (EST) Date: 8 Nov 2002 12:03:15 -0500 Message-ID: <3DCBEE53.35AD537F@alcatel.com> From: "Cheng-Yin Lee" To: stbryant@cisco.com Cc: "Mitsuru Higashiyama" , "W. Mark Townsley" , danny@tcb.net, pwe3@ietf.org, ppvpn@nortelnetworks.com X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00 References: <200211011519.gA1FJY601724@tcb.net> <3DC2D23D.FFF906F4@alcatel.com> <3DC2DC33.5000807@cisco.com> <3DC2DF8C.5F0033E@alcatel.com> <3DC2EBA8.9020006@cisco.com> <3DC2F00E.AA52A419@alcatel.com> <3DC785EE.5000706@cisco.com> <014f01c28669$d05318b0$d75510ac@temp0er> <3DCABFA2.9040502@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@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Stewart et al, An emulated LAN is not necessarily a PPVPL. (e.g. a bird is a mammal, but a mammal is not necessarily a bird). May I know if this type of logic is acceptable? thanks cheng-yin Stewart Bryant wrote: > > > > > P2MP wire discussion will be in PPVPN and return back to PWE3 if there is > > request to packet format. Is it correct ? > > > > That looks to me to be the best way forward to me. > > Stewart From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 12:47:38 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 MAA01985 for ; Fri, 8 Nov 2002 12:47:38 -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 gA8HnZ109465 for ; Fri, 8 Nov 2002 12:49:35 -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 gA8HnUK13048 for ; Fri, 8 Nov 2002 12:49:31 -0500 (EST) Date: Fri, 8 Nov 2002 17:48:00 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Cheng-Yin Lee cc: pwe3@ietf.org, Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00 In-Reply-To: <3DCBEE53.35AD537F@alcatel.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-102.4 required=7.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT_PINE, USER_IN_WHITELIST version=2.43 X-Scanner: exiscan *18ADEg-00062l-00*SlzMwPC1jxo* (SECM, UniS) X-SMTP-HELO: prue.eim.surrey.ac.uk X-SMTP-MAIL-FROM: l.wood@eim.surrey.ac.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: prue.eim.surrey.ac.uk [131.227.76.5] X-LYRIS-Message-Id: On 8 Nov 2002, Cheng-Yin Lee wrote: > Stewart et al, > > An emulated LAN is not necessarily a PPVPL. > (e.g. a bird is a mammal, but a mammal is not necessarily a bird). Birds aren't mammals. Lactating (monotremes lay eggs, but lactate, making them mammals) distinguishes mammals; hair's a secondary characteristic of mammals. Avians and mammals are vertebrates, if that helps. > May I know if this type of logic is acceptable? Reasoning by entirely false analogy to confuse a point you're trying to make while waving undefined abbreviations around? (PPVPL?) Oh, absolutely. It's a longstanding tradition, and the only way anything ever gets done around here. As for logic, you might want to figure out your propositions (the major premise and the minor premise), your syllogism, and your fallacies. L. From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 14:04: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 OAA08604 for ; Fri, 8 Nov 2002 14:04: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 gA8J6n100720 for ; Fri, 8 Nov 2002 14:06:50 -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 gA8J6kK28662 for ; Fri, 8 Nov 2002 14:06:47 -0500 (EST) Date: 8 Nov 2002 14:02:48 -0500 Message-ID: <3DCC0A58.930B1AD8@alcatel.com> From: "Cheng-Yin Lee" To: "Lloyd Wood" Cc: pwe3@ietf.org, ppvpn@nortelnetworks.com X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00 References: 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@nortelnetworks.com X-SMTP-PEER-INFO: kanfw1.ottawa.alcatel.ca [192.75.23.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Llyod, Thanks for your clarifications. To get back to my original point, let me try with another example : An emulated LAN is not necessarily a PPVPL (Provider Provisioned Virtual Private LAN). (e.g. a human is a mammal, but a mammal is not necessarily a human). regards cheng-yin From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 16:55:01 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 QAA17626 for ; Fri, 8 Nov 2002 16:55:01 -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 gA8Luv127046 for ; Fri, 8 Nov 2002 16:56: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 gA8LurK10665 for ; Fri, 8 Nov 2002 16:56:54 -0500 (EST) Date: Fri, 8 Nov 2002 21:52:46 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Cheng-Yin Lee cc: pwe3@ietf.org, Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00 In-Reply-To: <3DCC0A58.930B1AD8@alcatel.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-102.2 required=7.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC, QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05,USER_AGENT_PINE, USER_IN_WHITELIST version=2.43 X-Scanner: exiscan *18AH3c-0006FN-00*gdi7/FNUAKQ* (SECM, UniS) X-SMTP-HELO: prue.eim.surrey.ac.uk X-SMTP-MAIL-FROM: l.wood@eim.surrey.ac.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: prue.eim.surrey.ac.uk [131.227.76.5] X-LYRIS-Message-Id: On 8 Nov 2002, Cheng-Yin Lee wrote: > Llyod, > Thanks for your clarifications. No, thank _you_, for giving me the opportunity to be on-topic _and_ talk about breasts. L. > To get back to my original point, let me try with another example : > > An emulated LAN is not necessarily a PPVPL (Provider Provisioned Virtual > Private LAN). > (e.g. a human is a mammal, but a mammal is not necessarily a human). > > regards > cheng-yin > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 19:31:17 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 TAA24111 for ; Fri, 8 Nov 2002 19:31:17 -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 gA90XC115187 for ; Fri, 8 Nov 2002 19:33:12 -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 gA90X9K23199 for ; Fri, 8 Nov 2002 19:33:10 -0500 (EST) Message-Id: <200211090031.AA00064@sasagawa-xp1.adsys.ts.fujitsu.co.jp> From: yasushi sasagawa Date: Sat, 09 Nov 2002 09:31:45 +0900 To: ppvpn@nortelnetworks.com Subject: SUBSCRIBE ppvpn MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.10 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: fgwmail5.fujitsu.co.jp X-SMTP-MAIL-FROM: sasagawa@adsys.ts.fujitsu.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: fgwmail5.fujitsu.co.jp [192.51.44.35] X-LYRIS-Message-Id: SUBSCRIBE ppvpn ---- yasushi sasagawa sasagawa@adsys.ts.fujitsu.co.jp From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 21:10:47 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 VAA26449 for ; Fri, 8 Nov 2002 21:10: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 gA92Ce129013 for ; Fri, 8 Nov 2002 21:12: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 gA92CbK23880 for ; Fri, 8 Nov 2002 21:12:37 -0500 (EST) Date: Sat, 09 Nov 2002 10:11:19 +0800 From: Bin Li Subject: Re: ??: Huawei draft To: raszuk@cisco.com Cc: ppvpn@nortelnetworks.com Message-id: <002101c28795$5ed528e0$0100a8c0@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=UTF-8 X-Priority: 3 X-MSMail-priority: Normal References: <3DCBACDA.64BC7414@cisco.com> X-SMTP-HELO: mta1 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.15] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA26449 > Hi Robert, > > > 1 According Multi-VRF, PE and Multi-VRF CE need one sub-interface and one IP address for every VPN. But according HoPE, SPE and UPE need only one sub-interface and one IP address for all VPN; > > SPE yes when it does not also serve some sites of given VPN directly. > But UPE - no the above is not true. On UPE you will have excatly the > same number of vrfs as you would have on multi-vrf box. *********************************************************************************************************************** What I said is the SPE-UPE interface. *********************************************************************************************************************** > > > 2 By ORF mechanism, SPE NEED NOT configure VRFs which already be configured in UPE. But according Mulit-VRF, PE must do redundant work. > > ORF has nothing to do with VRF configuration. It is just a vehicle to > push your bgp inbound policy to your peer. *********************************************************************************************************************** So import route-target list of UPEs can be transport to SPE by ORF. And SPE can form a HoPE wide import route-target list dynamically. *********************************************************************************************************************** > > > 3 According Mulit-VRF, In the worst case, PE need run one PE-CE routing protocol instance for every VPN. But according HoPE, just one MP-BGP instance run between SPE and UPE. It's independent from # of VPN. > > True. > > > 4 SPE and UPE can link with a tunnel. To do the same thing, there need multiple tunnels between PE and Multi-VRF CE. > > True. > > > In general, HoPE is some dynamic mechanism. But Multi-VRF is some static mechanism. And in general case, the cost of HoPE is little than Multi-VRF. > > Also True ;). But we already have also a dynamic mechanism to achive > exactly the goal here. What you are proposing here it is the trival case > of L3VPNs inter-as mechanism (option b). *********************************************************************************************************************** It seems like inter-as mechanism. But they solve different thing. SPE and UPE are in same AS most time. And according inter-as mechanism, SPE and UPE should advertise all VPN-IPv4 prefixes to each other. *********************************************************************************************************************** > > Cheers, > R. ----- Original Message ----- å‘件人: "Robert Raszuk" 收件人: "Bin Li" 抄é€: å‘é€æ—¶é—´: 2002å¹´11月8æ—¥ 20:23 主题: Re: ??: Huawei draft > Hi Bin, > > > 1 According Multi-VRF, PE and Multi-VRF CE need one sub-interface and one IP address for every VPN. But according HoPE, SPE and UPE need only one sub-interface and one IP address for all VPN; > > SPE yes when it does not also serve some sites of given VPN directly. > But UPE - no the above is not true. On UPE you will have excatly the > same number of vrfs as you would have on multi-vrf box. > > > 2 By ORF mechanism, SPE NEED NOT configure VRFs which already be configured in UPE. But according Mulit-VRF, PE must do redundant work. > > ORF has nothing to do with VRF configuration. It is just a vehicle to > push your bgp inbound policy to your peer. > > > 3 According Mulit-VRF, In the worst case, PE need run one PE-CE routing protocol instance for every VPN. But according HoPE, just one MP-BGP instance run between SPE and UPE. It's independent from # of VPN. > > True. > > > 4 SPE and UPE can link with a tunnel. To do the same thing, there need multiple tunnels between PE and Multi-VRF CE. > > True. > > > In general, HoPE is some dynamic mechanism. But Multi-VRF is some static mechanism. And in general case, the cost of HoPE is little than Multi-VRF. > > Also True ;). But we already have also a dynamic mechanism to achive > exactly the goal here. What you are proposing here it is the trival case > of L3VPNs inter-as mechanism (option b). > > Cheers, > R. > > > > -----Ã¥ZYå§<é,®ä»¶----- > > Ã¥Â'件人: Robert Raszuk [mailto:raszuk@cisco.com] > > Ã¥Â'é?Âæ-¶é-´: 2002å¹´11æo^8æ-Â¥ 16:10 > > æ"¶ä»¶äºº: Bin Li > > æS"é?Â: Ray Qiu; ppvpn@nortelnetworks.com > > 主é¢~: Huawei draft > > > > Bin, > > > > > Sometime, It is necessary to provide VPN service > > > at the very edge. > > > > True. > > > > > Users don't want access PE by > > > a long distance L2 link which is expensive. > > > > True. > > > > > UPE > > > can aggregate them and separate them by label. > > > It only need one WAN link. It's cheap than > > > many WAN links. > > > > Why many WAN links ... I don't think there is any need for them. Your > > proposal may work indeed but IMHO adds unnecessary level of complication > > for SPs who already solved the same exact problem with a trival solution > > ;). > > > > The most commonly used way (- deployed already in multiple production > > networks) to achive exactly what your draft is after is so called > > managed service where CE (from original 2547 point of view) is not one > > routing context, but one router with multiple routing instances > > (multi-vrf) without any MPLS or any vpnv4 BGP sessions between such a > > box and PE. > > > > Then each vrf simply comunicates with PE by for example frame relay > > encapsulation over the same physical link so WAN link costs are > > independent from # of remote VPNs. > > > > Thx, > > R. > > > > Bin Li wrote: > > > > > > Sometime, It is necessary to provide VPN service at the very edge. Users don't want access PE by a long distance L2 link which is expensive. UPE can aggregate them and separate them by label. It only need one WAN link. It's cheap than many WAN links. > > > > > > SPE should do some more in this mechanism. The PE just according rfc2547bis will not work well in this environment. So I commit this proposal. > > > > > > -----Ã"­ê¼óê¼þ----- > > > ·ï¿ ¼þèÃ<: Ray Qiu [mailto:rayq@riverstonenet.com] > > > ·ï¿ Ã<íê±¼ä: 2002Ã"ê11Ã"Ã,8èÃ. 14:36 > > > êÃ.¼þèÃ<: Bin Li > > > ³­Ã<í: ppvpn@nortelnetworks.com > > > Ã-÷ìâ: Re: â?²Ã°Â¸â?²: â?²Ã°Â¸â?²: μª > > > > > > Bin, > > > > > > What I meant was that you could use normal L2 technologies, such as VLAN, > > > PVC, to tunnel the customer IP traffic to the 2547 PEs. This way you could > > > use a much cheap box at the very edge, instead of a router that needs to > > > support MPLS and MP-BGP. > > > > > > I agree that hierarchical design will help to improve scalability if > > > applicable. > > > > > > It seems that the method can be achieved by configurations (MP-BGP and BGP > > > policies) and it doesn't require new techniques. > > > > > > - Ray > > > > > > How many customers will you connect on the UPE? > > > > > > On 11/7/02 21:50, "Bin Li" wrote: > > > > > > > In theory, VLAN can transport via WAN link. But it'll as expensive as other > > > > WAN technology. And it's not the only choice. Users can access PE by VLAN, > > > > ATM, FR, PoS, E1 and etc. Why should we use label to separate VPN site? MPLS > > > > label can work on any Layer 2 technology. > > > > Each IP interface/address will never consume more than resource MP-BGP, but > > > > many IP interface/address will consume more than MP-BGP. In the other word. > > > > HoPE is very scalability. MP-BGP is a dynamic mechanism, but VLAN will be > > > > configured each by each manually. > > > > BTW, if SPE directly links with UPE, UPE needn't run LDP/RSVP. > > > > > > > > -----Ã"­ê¼óê¼þ----- > > > > ·ï¿ ¼þèÃ<: Ray Qiu [mailto:rayq@riverstonenet.com] > > > > ·ï¿ Ã<íê±¼ä: 2002Ã"ê11Ã"Ã,8èÃ. 11:59 > > > > êÃ.¼þèÃ<: Bin Li > > > > Ã-÷ìâ: Re: â?²Ã°Â¸â?²: μª > > > > > > > > > > > > > > > > Bin, > > > > > > > > It sounds to me like an implementation issue. VLAN can be supported on WAN > > > > links as well as 802.1Q. IP interface/address would never consume more > > > > resource than MP-BGP and LDP/RSVP. > > > > > > > > - Ray > > > > > > > > On 11/7/02 19:51, "Bin Li" wrote: > > > > > > > >> Ray, > > > >> The key is the distance between UPE and SPE. Sometime, you must use a WAN > > > >> link > > > >> between them. And when VLANs are used to separate sites, you must configure > > > >> many VLAN in a PE, and assign a VLAN to a VRF. Usually, a VLAN in a router > > > >> is > > > >> a sub-interface, it should have a IP address and consume some resource. It's > > > >> costly and difficult to maintain. > > > >> > > > >> > > > >> > > > >> > > > >> -----Ã"­ê¼óê¼þ----- > > > >> ·ï¿ ¼þèÃ<: Ray Qiu [mailto:rayq@riverstonenet.com] > > > >> ·ï¿ Ã<íê±¼ä: 2002Ã"ê11Ã"Ã,8èÃ. 10:46 > > > >> êÃ.¼þèÃ<: â?¢câ?¢Å¸â?"F > > > >> ³­Ã<í: ppvpn@nortelnetworks.com > > > >> Ã-÷ìâ: Re: μª From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 8 22:21:37 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 WAA28815 for ; Fri, 8 Nov 2002 22:21:37 -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 gA93NB109944 for ; Fri, 8 Nov 2002 22:23:12 -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 gA93N7K22312 for ; Fri, 8 Nov 2002 22:23:09 -0500 (EST) Message-Id: <5.1.0.14.2.20021108222053.024ebc68@nxp.com> Date: Fri, 08 Nov 2002 22:22:24 -0500 To: ppvpn@nortelnetworks.com From: Waldemar Augustyn Subject: Fwd: I-D ACTION:draft-augustyn-ppvpn-l2vpn-requirements-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: smtp01.mrf.mail.rcn.net X-SMTP-MAIL-FROM: waldemar@nxp.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp01.mrf.mail.rcn.net [207.172.4.60] X-LYRIS-Message-Id: To: IETF-Announce: ; Subject: I-D ACTION:draft-augustyn-ppvpn-l2vpn-requirements-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Layer 2 Virtual Private Network Services (L2VPN) Author(s) : W. Augustyn Filename : draft-augustyn-ppvpn-l2vpn-requirements-01.txt Pages : 18 Date : 2002-11-7 This draft describes service requirements for Provider Provisioned L2 Virtual Private Networks. It covers point to point VPNs referred to as Virtual Private Wire Service (VPWS), as well as broadcast domain multipoint to multipoint VPNs referred to as Virtual Private LAN Service (VPLS). L2VPNs are a class of Provider Provisioned Virtual Private Network [2]. This draft is intended to supersede draft-ietf-ppvpn-vpls- requirements-01.txt [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-augustyn-ppvpn-l2vpn-requirements-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-augustyn-ppvpn-l2vpn-requirements-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-augustyn-ppvpn-l2vpn-requirements-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. Content-Type: text/plain Content-ID: <2002-11-7155851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-augustyn-ppvpn-l2vpn-requirements-01.txt From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 9 03:59:50 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 DAA14436 for ; Sat, 9 Nov 2002 03:59:49 -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 gA991UB07941 for ; Sat, 9 Nov 2002 04:01:30 -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 gA991RS06361 for ; Sat, 9 Nov 2002 04:01:28 -0500 (EST) Message-ID: <3DCCCEC3.22D7D86A@cisco.com> Date: Sat, 09 Nov 2002 10:00:51 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bin Li CC: ppvpn@nortelnetworks.com Subject: Re: ??: Huawei draft References: <3DCBACDA.64BC7414@cisco.com> <002101c28795$5ed528e0$0100a8c0@LocalHost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Bin, > It seems like inter-as mechanism. I am glad you agree. > But they solve different thing. > SPE and UPE are in same AS most time. That is fine. That is why I said trival Inter-As case. > And according inter-as mechanism, > SPE and UPE should advertise all > VPN-IPv4 prefixes to each other. No - absolutely not. If you found somewhere any statemnt like this it is a doc bug :). It would be highly not scalable to have such a requiremnt in place. Filtering on advertisemnt of vpnv4 routes or at inbound processing of those incomming is a key to scalability of any inter-as case. Cheers, R. From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 9 04:02: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 EAA14492 for ; Sat, 9 Nov 2002 04:02:04 -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 gA9940B10907 for ; Sat, 9 Nov 2002 04:04: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 gA993vS09900 for ; Sat, 9 Nov 2002 04:03:57 -0500 (EST) Date: Sat, 09 Nov 2002 17:01:28 +0800 From: Miao Fuyou Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogUGxlYXNlIFJldmlldzogQSBuZXcgZA==?= =?gb2312?B?cmFmdCBhYm91dCBQUFZQTihIaWJlcmFyY2h5IG9mIFBFIERldmljZQ==?= =?gb2312?B?IGluQkdQL01QTFMgVlBOKQ==?= In-reply-to: To: "'Jim Guichard'" , =?gb2312?B?J6Gnoeg/P6ikoac/Jw==?= Cc: ppvpn@nortelnetworks.com Message-id: <000001c287ce$97bf3ae0$2e426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: miaofy@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA14492 Hi, Jim: Please find my commnets inline! Regards -----ÓʼþÔ­¼þ----- ·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] ·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 23:29 ÊÕ¼þÈË: ???¡ê¨®?; '¡§¡è??¨¤¡§?' ³­ËÍ: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; leh10814@huawei.com Ö÷Ìâ: RE: ´ð¸´: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) Hi Miao, I understand that this is not a replacement to 2547. I also understand that hierarchy is one of the tools we have to help scale networks. However, what I am driving at is that 2547 provides all of the necessary mechanisms already to run this type of topology - deployment of 2547 is a matter of design and no new functionality is necessary to be able to run the topology you are suggesting. We have many deployments worldwide that already use this type of design to provide central services to their customers. This does not mean however that the topology is appropriate for all 2547 customers. There are a number of issues with the proposed topology that one might consider: Miao: Actually it's not a problem of topology, it's for the planning and design of the network. If 2547 alone can work under for every network and meet all the VPN requirement, why were VPLS, Martini VPN, Kompella VPN and many others proposed? 1. In most real world deployments the number of hops between UPE and SPE will be > 1. This may introduce unacceptable latency and so on, especially as the design is being used for transit traffic rather than central services. Miao: I don't think hops > 1 brings more latency if a packet must go from an ingress PE to an egress PE. Actually it follows almost the same route that 2547 one will do if the network is not very careless designed. 2. Using this method introduces additional IP address lookups between ingress PE and egress PE, plus label disposition/imposition. Miao: It's a ONCE-FOR-ALL work for a site, so the effort is trivial 3. Unless the SPE is located locally to the UPE then the regional VPN traffic will be concentrated toward certain points of the network, instead of being distributed across the whole infrastructure. Miao: UPE can process it locally in such case, no SPE involved 4. If the SPE is located locally, then aggregates can be injected down to the UPEs but this is assuming that the address space is designed in such a way as to allow this aggregation. Most Enterprise networks today do not have such a well structured addressing plan. Miao: Refer item 3 5. By injecting aggregates toward the CE site you change the customers routing view which may actually require the injection of more specific routes. Miao: No aggretes injected in HoPE actually 6. The SP has to keep track of the aggregation and configure it appropriately at the SPE. Miao: SPE will do 7. How do you take care of customers that want to run OSPF or ISIS on the PE-CE links ? how would sham-links work for example ? Miao: Only default route is needed in HoPE at PE-CE links, so why to run OSPF & IS-IS? 8. To deploy H&S designs one must use different RTs for the same VPN and then apply policy to filter correctly. This may not be such a big deal but is a further complication in the provisioning and management process. Miao: Repeat, it's not a problem of topology, not to say H&S 9. If our goal is to offload the edge routers from having to carry VPNv4 routes or run MP-BGP sessions then perhaps we should use the L2-transport functionality in MPLS to carry the edge traffic to an SPE. This has the advantage that the CE can exchange routes directly with the SPE which is useful for other applications. Miao: L2-transport is not always applicable. CEs don't always run MPLS. 10. How do you take care of customers that want to run Carrier's Carrier architecture ? Miao: But, what is the problem? regards, > >-----Original Message----- > >From: Ã縣ÓÑ [mailto:miaofy@huawei.com] > >Sent: Thursday, November 07, 2002 9:07 PM > >To: 'Jim Guichard'; '¨¤?¡À¨®' > >Cc: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; > >leh10814@huawei.com > >Subject: ´ð¸´: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of > >PE Device inBGP/MPLS VPN) > > > > > >Hi, Jim: > > > >This draft is not to replace 2547, but a supplement to it. Actually > >the VPN in the draft is completely works under the mechanism of 2547. > > > >In the traditional 2547 VPN, only one type of PE is defined. When > >deployment, PE will not has so many ports to attach many VPNs if the > >PE is at the core layer of the network, because core router generally > >doesn't have a lot of physically interfaces. If the PE is at the > >edge of the network, it will have a lot of interfaces, but now the > >botlleneck is capacity of computation of the router. > > > >This draft is to solve the problem, UPE will provide abundant > >interface to conenct sites to VPN and SPE will have enough CPU/Memory > >to process routes. > > > >Regards > >Miao > > > >-----ÓʼþÔ­¼þ----- > >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 > >ÊÕ¼þÈË: ¨¤?¡À¨® > >³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco Carugi; > >sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; > >ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; > >changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com > >Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE > >Device inBGP/MPLS VPN) > > > > > >so can hub&spoke with 2547 - you basically export routes from the > >CE-attached PEs to a hub PE that imports the routes. The hub PE > >exports either a default or aggregates to attract traffic from other > >CE-attached PEs and then performs a lookup to forward the packets to > >other CE-attached PEs .. Jim > > > >> >-----Original Message----- > >> >From: Àî±ó [mailto:l.b@huawei.com] > >> >Sent: Thursday, November 07, 2002 2:42 AM > >> >To: Jim Guichard > >> >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >> >marco.carugi@nortelnetworks.com; sob@harvard.edu; > >> >bwijnen@lucent.com; > > > >> >zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; > >> >Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >> >leh10814@huawei.com > >> >Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of > >PE > >> >Device inBGP/MPLS VPN) > >> > > >> > > >> >Hi, Guichard > >> >The hub & spoke is the relationship between CEs, but SPE peer with > >> >UPE by MP-BGP, they are all PEs, and they all can admit VPN user. > >> > > >> >Libin > >> > > >> >-----ԭʼÓʼþ----- > >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >> >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >> >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >> >Miao; leh10814@huawei. com; l.b@huawei.com > >> >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE > >> >Device inBGP/MPLS VPN) > >> > > >> > > >> >I briefly ran through this draft and it looks like normal hub & > >> >spoke > > > >> >using existing 2547 mechanisms - could you explain how this > >> >differs ? > > > >> >thanks, > >> > > >> >> >-----Original Message----- > >> >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >> >To: internet-drafts@ietf.org > >> >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >> >> >Miao; > > > >> >> >leh10814@huawei.com; l.b@huawei.com > >> >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy of > >> >> >PE Device in BGP/MPLS VPN) > >> >> > > >> >> > > >> >> >Hi,all, > >> >> > > >> >> > In BGP/MPLS VPN area, we proposed a new idea as to resolve > >> >> >the bottleneck of the capacity of some PEs when deploy the huge > >> >> >size VPN,the > >> >whole idea is > >> >> >detailed > >> >> >in the attached > >> >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >> >> >Abstract is as follows,we are appreciated for your review. > >> >> > > >> >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >> >Edge)Device should > >> >> > maintain all the VPN routes of the VPNs which it belong > >> >to.When there > >> >> > are many VPNs converged by a PE,and the capacity of PE is > >relevant > >> >> > limited,then the bottleneck will be encountered.Another > >> >> > problem > >is > >> >> > that the current BGP/MPLS VPN model is something of a "Plane > >Modle" > >> >> > where the demand of the performance of the PE device are all > >the > >> >> > same no matter which layer the PE device is belongs > >> >> > to.However, > >the > >> >> > typical network is "Core-Convergence-Access(Edge)" model,and > >the > >> >> > performance of the device is superior in Core Layer and > >inferior in > >> >> > Access Layer,and the scale of network is large in Access > >> >> > Layer > >and > >> >> > small in Core Layer,the routes are converged in every > >> >> > layer,so > >in > >> >> > current "Plane Modle",when PE device push to the edge > >> >> > layer,it > >has > >> >> > to maintain more VPN routes,this makes it difficult to > >> >extend the PE > >> >> > device to edge layer.This document defines an model of > >> >hiberarchy of > >> >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of > >Provider > >> >> > Edge Device can be composed of several device and every > >> >> > device > >take > >> >> > on the different part,partake the function of the former > >> >> > concentrative PE,we call this model "Hiberarchy Model",In > >> >this model > >> >> > the demand of performance in Routing and Switching is strict > >> >> > to > >the > >> >> > PE device in High layer,loose to the PE device in edge > >> >> > layer. > >> >> > > >> >> > One HoPE can be composed of a SPE and UPES connected to the > >SPE, > >> >> > or be composed of a high-level SPE and HoPEs connected the high > >> >> > level SPE and and build up a new HoPE.This build is called > >nesting > >> >> > of HoPE,and this kind of nesting can be done for many > >> >times.Thus the > >> >> > former HoPE connect to the high-level SPE as a role of > >> >> > UPE,and > >the > >> >> > new HoPE can connect a single UPE too. > >> >> > > >> >> >Regards > >> >> > > >> >> >Defeng Li > >> >> > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 9 07:59:15 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 HAA17683 for ; Sat, 9 Nov 2002 07:59: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 gA9D0mB04244 for ; Sat, 9 Nov 2002 08:00:49 -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 gA9D0jS10818 for ; Sat, 9 Nov 2002 08:00:46 -0500 (EST) Message-ID: From: Sasha Vainshtein To: "'Ali Sajassi'" , "'hsalama@cisco.com'" Cc: ppvpn@nortelnetworks.com, "PWE3 WG (E-mail)" , "Eric Rosen (E-mail)" Subject: RE: Doubts regarding draft-sajassi-mvpls-00.txt Date: Sat, 9 Nov 2002 14:58:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-SMTP-HELO: antivir1 X-SMTP-MAIL-FROM: Sasha@AXERRA.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [80.74.100.67] X-LYRIS-Message-Id: Ali and all, Thank you for a prompt response. Please see also several brief comments inline. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Thursday, November 07, 2002 10:03 PM > To: Sasha Vainshtein; 'sajassi@cisco.com'; 'hsalama@cisco.com' > Cc: ppvpn@nortelnetworks.com; PWE3 WG (E-mail); Eric Rosen (E-mail) > Subject: Re: Doubts regarding draft-sajassi-mvpls-00.txt > > > > Sasha, > > Thanks for your comments and inquiry. Please see my reply inline. > > > At 06:16 PM 11/7/2002 +0200, Sasha Vainshtein wrote: > >Ali, Hussein and all, > >I have serious doubts regarding draft-sajassi-mvpls-00.txt. > >I would highly appreciate clarification on the following issues: > > > >1. The draft, as posted, assumes that a unique unicast IP address is > >allocated for > > each Attachment Circuit connecting a customer site > participating in the > >MVPLS > > with its adjacent PE. (The draft considers the option > that such an > >address > > is allocated per PE per VPLS "due to PE limitations"). > IMHO this raises > >strong > > scalability issues especially when dealing with IPv4 > networks, because > > IP addresses that are unique within at least within the > scope of the > >provider's > > network are a scarce resource. (I think that similar > issues have been > > raised by Eric Rosen in his comments on > >draft-ietf-ppvpn-cl-tunneling-vpn-00.txt > > that have been posted on the PPVPN WG list) > > Within the scope of the provider's network, the private address block > [RFC1918] can be used which can provide very large number of > IP addresses > to address the scalability concern. > Does this mean that the scope of the proposal is limited to a single AS? > > >2. The common approach to PWE3 and PPVPN assumes (and this > is reflected, > > e.g., in the PWE3 charter) that these activities affect > only PEs but not > >the > > core routers in the provider's network. IMHO your > approach contradicts > > this approach because: > > a) Adding a new VPLS instance requires allocation of a > new multicast IP > > address, and all the PE devices participating in > this VPLS instance > > must join the multicast group associated with this address > > b) Adding a new Attachment Circuit requires an IGP > update so that > > the network "learns" routes to the associated IP address > > c) AFAIK, each of these operations affects all the > routers in the > > provider's network. > > As described in draft-ietf-pwe3-requirements : > "PWs can be path-oriented or non-path-oriented. For > path-oriented PWs, core > network devices must maintain state information for them. If > a large number > of path-oriented PWs are used, core network devices will have > to maintain a > large amount of state information" > Furthermore, because of route summarization, not every time a new > Attachment Circuit is added, it generates a IGP update. > Also, the MPtP and MPtMP PWs that are used in this draft, are > not defined > yet in the PWE3 framework and may need to be defined in the future. > Please note that the notionof path-oriented PW has been dropped in the latest PWE3 Architecture document (draft-ietf-pwe3-arch-01.txt) exactly for the reasons I have mentioned. > > > >3. In Section 8 you describe the process of forwarding of > "known unicast" > > frames in the egress PE like following: > > > > When an egress PE receives a unicast MVPLS packet > from the core, it > > > > performs the MAC SA lookup, and possibly learning, > as has been > > described in Section 8.2. The egress PE does not > lookup the MAC DA > >of > > the received frame since the destination IP > address of the received > > > > packet readily identifies the interface associated > with the AC. The > > > > packet is immediately delivered to that interface. > The IP header > >and > > the L2TPv3 header are removed before the Ethernet > frame gets > >forwarded > > over the AC towards its destination. > > > > > > This text raises several questions: > > a) How does the PE distinguish between the MVPLS packet > and any other > > packet with the destination address that has been allocated > > for the Attachment Circuit? IMHO, the vague reference > to L2TPv3 > > is not sufficient, because the L2TPv3 switching engine would > > most probably just discard the packet with an unknown Session > > ID - and in order to make the Session ID known to this engine, > > it must be explicitly set up - via signaling or manually. > > In other words, your forwarding decisions seem to prevent > > "normal" usage of L2TPv3 in the same PE > > We are just talking about a shim header for encapsulating > Ethernet packets. > Therefore, with respect to L2TPv3, we are just talking about the > encapsulation portion of it and not the signalling. If you > prefer, you can > use some other name for it. > > > b) How are other packets with this destination address (e.g., > > the ICMP Echo) processed? In other words, is the IP address > > associated with the AC in this PE treated as one of the > > IP addresses of the PE, or not? > > The packets with protocol-type of L2TPv3 for that AC gets > forwarded to that > interface and other packets with non-L2TPv3 protocol-type > gets processed > internally by the PE. > I am afraid this cannot work in a device that supports "normal" L2TPv3, because it would not know whether the L2TP packets with one of its own IP addresses should be forwarded to its L2TPv3 switching engine or to the MVPLS decap engine and, from there, to the AC corresponding to the destination IP. > > Regards, > Ali > > > >With best regards, > > Sasha Vainshtein > >email: sasha@axerra.com > >tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 9 20:35:02 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 UAA28650 for ; Sat, 9 Nov 2002 20:35:02 -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 gAA1awB13013 for ; Sat, 9 Nov 2002 20:36: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 gAA1asS19019 for ; Sat, 9 Nov 2002 20:36:55 -0500 (EST) Message-ID: <3DCDB7C0.7010305@cisco.com> Date: Sun, 10 Nov 2002 01:34:56 +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: Cheng-Yin Lee CC: Lloyd Wood , pwe3@ietf.org, ppvpn@nortelnetworks.com Subject: Re: [PWE3] Re: Comments to draft-ietf-pwe3-arch-00 References: <3DCC0A58.930B1AD8@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: stbryant@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mrwint.cisco.com [144.254.98.48] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Cheng-Yin Lee wrote: > An emulated LAN is not necessarily a PPVPL (Provider Provisioned Virtual > Private LAN). What specific details of the PPVPL and / or PWE3 drafts prevent you from deploying the system that you desire to build? What features are missing? What features are you prevented from turning off? What features must be done differently? Have you already documented the specific issues, if so, please could you remind me of the mail, or refer me to a draft? Regards Stewart From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 10 11:53:36 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 LAA19552 for ; Sun, 10 Nov 2002 11:53:35 -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 gAAGtQv26434 for ; Sun, 10 Nov 2002 11:55: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 gAAGtO012553 for ; Sun, 10 Nov 2002 11:55:24 -0500 (EST) Message-ID: From: "Marco Carugi" To: ppvpn@nortelnetworks.com Subject: FW: Note Well Statement Date: Sun, 10 Nov 2002 17:54:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C288D9.A7FA79EA" 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_01C288D9.A7FA79EA Content-Type: text/plain; charset="iso-8859-1" FYI, as requested by IESG secretary. Marco -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: jeudi 7 novembre 2002 21:12 Subject: Note Well Statement From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ------_=_NextPart_001_01C288D9.A7FA79EA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Note Well Statement

FYI, as requested by IESG secretary.

Marco
-----Original Message-----
From: The IESG [mailto:iesg-secretary@ietf.org]
Sent: jeudi 7 novembre 2002 21:12
Subject: Note Well Statement



From time to time, especially just before a meeting, = this statement is to
be sent to each and every IETF working group mailing = list.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

        =         =         =         NOTE = WELL

All statements related to the activities of the IETF = and addressed to the
IETF are subject to all provisions of Section 10 of = RFC 2026, which grants
to the IETF and its participants certain licenses = and rights in such
statements.

Such statements include verbal statements in IETF = meetings, as well as
written and electronic communications made at any = time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or = portion thereof,
    - the IESG, or any member thereof = on behalf of the IESG,
    - the IAB or any member thereof = on behalf of the IAB,
    - any IETF mailing list, = including the IETF list itself,
      any working group or = design team list, or any other list
      functioning under = IETF auspices,
    - the RFC Editor or the = Internet-Drafts function

Statements made outside of an IETF meeting, mailing = list or other function,
that are clearly not intended to be input to an IETF = activity, group or
function, are not subject to these = provisions.

------_=_NextPart_001_01C288D9.A7FA79EA-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 10 13:58:20 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21666 for ; Sun, 10 Nov 2002 13:58:19 -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 gAAIxpv12514 for ; Sun, 10 Nov 2002 13:59:51 -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 gAAIxn001894 for ; Sun, 10 Nov 2002 13:59:49 -0500 (EST) Message-ID: From: "Marco Carugi" To: "'ppvpn@nortelnetworks.com'" Cc: "Marco Carugi" Subject: Setting up the PPVPN meeting agenda Date: Sun, 10 Nov 2002 19:59:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C288EB.3AF96952" 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_01C288EB.3AF96952 Content-Type: text/plain; charset="iso-8859-1" Hi. To all people who have requested a time slot in PPVPN Atlanta session : I'm setting up the agenda : in order to focus the meeting discussion and try to address the main points, please provide me asap (Tuesday morning as deadline) few words on what will be discussed about the document (and more in general in your slot). I'd like to put that on the agenda below the ID name indication. Please remember that we shouldn't have presentations of IDs, but basically issues and future work plans. Thanks, Marco ------_=_NextPart_001_01C288EB.3AF96952 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Setting up the PPVPN meeting agenda

Hi.

To all people who have requested a = time slot in  PPVPN Atlanta session :

I'm setting up the agenda : in order = to focus the meeting discussion and try to address the main points, = please provide me asap (Tuesday morning as deadline) few words on what = will be discussed about the document (and more in general in your = slot). I'd like to put that on the agenda below the ID name = indication.

Please remember that we shouldn't have = presentations of IDs, but basically issues and future work = plans.

Thanks, Marco







------_=_NextPart_001_01C288EB.3AF96952-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 10 16:01: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 QAA23889 for ; Sun, 10 Nov 2002 16:01: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 gAAL30v23573 for ; Sun, 10 Nov 2002 16:03: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 gAAL2w016171 for ; Sun, 10 Nov 2002 16:02:58 -0500 (EST) Message-ID: From: "Marco Carugi" To: "'ppvpn@nortelnetworks.com'" Cc: "Marco Carugi" Subject: Your comments on 3 possible new PPVPN WG documents Date: Sun, 10 Nov 2002 22:02:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C288F9.9F933858" 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_01C288F9.9F933858 Content-Type: text/plain; charset="iso-8859-1" All, I'd like to have your comments on the list about 3 drafts before Atlanta meeting. The intention is to move them to WG document status asap (note this is in line with what discussed in Yokohama) and I'd like to see if still and which are your major concerns. Hopefully, it will be possible to officialise something at the Atlanta meeting. Thanks, Marco - Generic Requirements for Provider Provisioned VPN : draft-nagarajan-ppvpn-generic-reqts-01.txt (deliverable agreed in Yokohama based on IESG input). Umbrella reqts document for specific L3 and L2 reqts documents. Info RFC track. - Requirements for Layer 2 Virtual Private Network services : draft-augustyn-ppvpn-l2vpn-requirements-01.txt (agreed in Yokohama to supercede the current VPLS WG document). - draft-luciani-ppvpn-vpn-discovery-03.txt : agreed as WG doc before Yokohama, but the authors just resubmitted it now. So, I wish that we check it again. Intention is to progress it similarly to BGP-autodiscovery draft (already WG doc), as one of the discovery methods. ------_=_NextPart_001_01C288F9.9F933858 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your comments on 3 possible new PPVPN WG documents

All, 

I'd like to have = your comments on the list about 3 drafts  before Atlanta = meeting.
The intention is to = move them to WG document status asap (note this is in line with what = discussed in Yokohama) and I'd like to see if still and which are your = major concerns.

Hopefully, it will = be possible to officialise something at the Atlanta  = meeting.

Thanks, Marco

- Generic Requirements for Provider Provisioned = VPN :
draft-nagarajan-ppvpn-generic-reqts-01.txt (deliverable = agreed in Yokohama based on IESG input). Umbrella reqts document for = specific L3 and L2 reqts documents. Info RFC track.

- Requirements for Layer 2 Virtual = Private Network services :
draft-augustyn-ppvpn-l2vpn-requirements-01.txt (agreed = in Yokohama to supercede the current  VPLS WG document).
- = draft-luciani-ppvpn-vpn-discovery-03.txt : agreed as WG doc before = Yokohama, but the authors just resubmitted it now. So, I wish that we = check it again. Intention is to progress it similarly to = BGP-autodiscovery draft (already WG doc),  as one of the discovery = methods. 

 

  

------_=_NextPart_001_01C288F9.9F933858-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 10 21:14:07 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 VAA28809 for ; Sun, 10 Nov 2002 21:14:06 -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 gAB2Fkv14628 for ; Sun, 10 Nov 2002 21:15:46 -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 gAB2Fg027199 for ; Sun, 10 Nov 2002 21:15:42 -0500 (EST) Date: Mon, 11 Nov 2002 10:15:46 +0800 From: Bin Li Subject: =?utf-8?B?6L2s5Y+ROiA/PzogSHVhd2VpIGRyYWZ0?= To: ppvpn@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=utf-8 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA28809 ----- Original Message ----- å‘件人: "Bin Li" 收件人: å‘é€æ—¶é—´: 2002å¹´11月10æ—¥ 11:12 主题: Re: ??: Huawei draft > Robert, > I am glad that you agree to HoPE is better than Multi-VRF. > HoPE will be confused with inter-as solution easily. But they are distinct. > 1 SPE only send aggregate vpnv4 routes or a default vpnv4 route to UPE. SPE should not filter vpnv4 routes which UPE advertises. On the other hand, UPE must not filter aggregate routes or default route which SPE advertises. > 2 Because vpnv4 routes are aggregated in SPE, SPE must terminate the LSP which is from UPE. It pop the vpn label and look forward vrf routing table, then push a new vpn label. In inter-as case, ASBR just swap the vpn label. > 3 UPE should advertise its import route target list to SPE. SPE will form a HoPE-wide import route target list to filter vpnv4 routes from other PEs. In inter-as case, ASBR may send a ORF to a peer ASBR, but the ORF is used to filter the routes which the peer ASBR send to itself. > 4 I must describe twice, SPE and UPE can be in same AS. In inter-as case, two ASBRs are in different AS. > > The above mechanisms are not described in draft 2547bis. And the PE just according 2547bis can't work as a SPE now. So I commit this proposal. > > Cheers, > Bin > > > ----- Original Message ----- > å‘件人: "Robert Raszuk" > 收件人: "Bin Li" > 抄é€: > å‘é€æ—¶é—´: 2002å¹´11月9æ—¥ 17:00 > 主题: Re: ??: Huawei draft > > > > Bin, > > > > > It seems like inter-as mechanism. > > > > I am glad you agree. > > > > > But they solve different thing. > > > SPE and UPE are in same AS most time. > > > > That is fine. That is why I said trival Inter-As case. > > > > > And according inter-as mechanism, > > > SPE and UPE should advertise all > > > VPN-IPv4 prefixes to each other. > > > > No - absolutely not. If you found somewhere any statemnt like this it is > > a doc bug :). It would be highly not scalable to have such a requiremnt > > in place. Filtering on advertisemnt of vpnv4 routes or at inbound > > processing of those incomming is a key to scalability of any inter-as > > case. > > > > Cheers, > > R. > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 10 22:04:01 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 WAA29572 for ; Sun, 10 Nov 2002 22:04: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 gAB35vv27425 for ; Sun, 10 Nov 2002 22:05: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 gAB35s029900 for ; Sun, 10 Nov 2002 22:05:54 -0500 (EST) Date: Mon, 11 Nov 2002 11:05:28 +0800 From: Bin Li Subject: =?utf-8?B?562U5aSNOiA/PzogSHVhd2VpIGRyYWZ0?= In-reply-to: <001001c28926$4cb09a40$0100a8c0@LocalHost> To: raszuk@cisco.com Cc: ppvpn@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=utf-8 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA29572 Hey Robert, Please check my reply in origin message. ----- Original Message ----- å‘件人: "Robert Raszuk" 收件人: "Bin Li" å‘é€æ—¶é—´: 2002å¹´11月10æ—¥ 19:25 主题: Re: ??: Huawei draft > Hey Bin, > > > I am glad that you agree to HoPE is better than Multi-VRF. > > No - I have not said this. Both static and dynamic options are well > proven to be usefull - so there should be no jugment made that one is > better then the other. Customers should decide which one to use. ************************************************************************************************************************************************************************************************* Maybe I misunderstand your reply. you said some YES when I listed the diffrence between HoPE and Multi-VRF. I think you misunderstood me early when I listed the diffrence between HoPE and inter-as option b. I aggre to that both of HoPE and Multi-VRF are useful to improve the scability of 2547bis . ************************************************************************************************************************************************************************************************* > > > HoPE will be confused with inter-as solution easily. But they are distinct. > > I dobut it. > > > 1 SPE only send aggregate vpnv4 routes or a default vpnv4 route to UPE. SPE should not filter vpnv4 routes which UPE advertises. On the other hand, UPE must not filter aggregate routes or default route which SPE advertises. > > All of this is fully doable with ASBR-ASBR inter-as option b. ****************************************************************************************************************************************************************** It can do able with inter-as option b AFTER the HoPE draft was commited : ). ****************************************************************************************************************************************************************** > > > 2 Because vpnv4 routes are aggregated in SPE, SPE must terminate the LSP which is from UPE. It pop the vpn label and look forward vrf routing table, then push a new vpn label. In inter-as case, ASBR just swap the vpn label. > > No. That is not correct. There can be Inter-AS case where ASBR set's > next hop self for vpnv4 routes (your case) as well as the scenario where > ASBR's do not set next hop self (LSP is not terminated at them). ****************************************************************************************************************************************************************** No. The inner LSP is established between two PEs in diffrent ASes in inter-as option b. The inner label is swithed at ASBRes. Only one ASBR swithes label if It does NOT set next hop self. Both two ASBRs swith label if It set next hop self. The inner LSP does NOT terminate at both of them. ****************************************************************************************************************************************************************** > > > 3 UPE should advertise its import route target list to SPE. > > SPE will form a HoPE-wide import route target list to filter vpnv4 routes from other PEs. In inter-as case, ASBR may send a ORF to a peer ASBR, but the ORF is used to filter the routes which the peer ASBR send to itself. > > Yes I see what you are trying to achive here. Limit the number of vpnv4 > routes not just advertised by SPE to UPEs (as that would be do with ext > community ORF on the UPE-SPE), but you also want to limit the number of > vpnv4 routes which SPE keeps (to match given HoPE requirements). > > That alone IMHO does not justify to have a draft for it :) And if even > that should be idr WG draft not ppvpn as what you are really after is to > install ORF filter from any UPE as inbound on the SPE. That is also > implementation detail (all is internal to ASBR/PE/SPE internal operation > - how it handles incomming ext community ORF messages). But the idea is > no bad to implement it ... :). ****************************************************************************************************************************************************************** If nobody knows HoPE mechanism. It will not be implemented wildly. ****************************************************************************************************************************************************************** > > > 4 I must describe twice, SPE and UPE can be in same AS. In inter-as case, two ASBRs are in different AS. > > That really does not matter. You simple have instead of EBGP vpnv4 > sessions to UPEs IBGP vpnv4 sessions (with SPE most likely reflecting > the vpnv4 routes _at least_ within the HoPE. > > > The above mechanisms are not described in draft 2547bis. And the PE just according 2547bis can't work as a SPE now. So I commit this proposal. > > Good luck :). > > R. > > > > ----- Original Message ----- > > Ã¥Â'件人: "Robert Raszuk" > > æ"¶ä»¶äºº: "Bin Li" > > æS"é?Â: > > Ã¥Â'é?Âæ-¶é-′: 2002å¹′11æo^9æ-ï¿¥ 17:00 > > 主é￠~: Re: ??: Huawei draft > > > > > Bin, > > > > > > > It seems like inter-as mechanism. > > > > > > I am glad you agree. > > > > > > > But they solve different thing. > > > > SPE and UPE are in same AS most time. > > > > > > That is fine. That is why I said trival Inter-As case. > > > > > > > And according inter-as mechanism, > > > > SPE and UPE should advertise all > > > > VPN-IPv4 prefixes to each other. > > > > > > No - absolutely not. If you found somewhere any statemnt like this it is > > > a doc bug :). It would be highly not scalable to have such a requiremnt > > > in place. Filtering on advertisemnt of vpnv4 routes or at inbound > > > processing of those incomming is a key to scalability of any inter-as > > > case. > > > > > > Cheers, > > > R. > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 10 22:10:42 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29696 for ; Sun, 10 Nov 2002 22:10: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 gAB3CUv01336 for ; Sun, 10 Nov 2002 22:12:31 -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 gAB3CR006079 for ; Sun, 10 Nov 2002 22:12:27 -0500 (EST) Date: Mon, 11 Nov 2002 11:11:57 +0800 From: lidefeng Subject: Re: Please Review: A new draft about PPVPN(Hierarchy of PE Device in BGP/MPLS VPN) To: Senthilkumar Rajasekharan Cc: ppvpn@nortelnetworks.com, lhj@huawei.com, chang@futurewei.com, "Fu Y. Miao" , leh10814@huawei.com Message-id: <002f01c28930$18fc0400$22436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_0em36t8h9wMuZ2zPGHL3CQ)" X-Priority: 3 X-MSMail-priority: Normal References: X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_0em36t8h9wMuZ2zPGHL3CQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Senthil, Sorry to answer you so late! I will answer all the questions on the heels of them(you can find my answer as following ). BTW,I am ad hoc appreciated for your pointing out a big typo in this draft,I have correct it and send you the right one, I am very glad to discuss these questions with you! Keep in touch! Best Regards! Defeng Li ----- Original Message ----- From: "Senthilkumar Rajasekharan" To: "lidefeng" Cc: Sent: Friday, November 08, 2002 6:28 PM Subject: Re: Please Review: A new draft about PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) > Hi Defeng Li, > > Some questions on your draft .... > > Section 2.1 > > > > SPE advertised the VRF default route or aggregate routes(by which > UPE transfer the VPN packet to SPE) to UPE,this default VRF route > can be formed dynamically or configured statically.When formed > dynamically,it can be filtered by the ORF mechanism mentioned above. > > <...> > > Is this procedure mandatory, i.e should the SPE always advertise a default > route or aggregate route to the UPE? And should that route be advertised > with an aggregated export target list of all the import route targets received via > an ORF Route Refresh message from the UPE? Yes ,this procedure is mandatory,maybe from the point of view of working principle,SPE can run dynamic routing protocol with UPE and send all the routes in SPE to UPE,then UPE should store and maintain all the routes of the VPN in HoPE,the dvantage of this scheme will be forfeited, The default route is advertised when UPE connected to only one SPE. In the case of load balance where one UPE connected to several SPE(this situation didn't denoted in the figure of our draft) to balance the load of some VPN,then different SPE should advertise the different aggregated route to this UPE(the aggregated route is created according the match export target list received by the respective SPE between of the import route targets of different part of VPN in UPE ) > Section 2.2 > > > > (7) SPE replace the inner label distributed by UPE with another inner > label distributed by SPE,then advertise this route to PE through > MP-BGP with the new inner label attached; > > > <...> > > I don't understand why the SPE would replace UPE distributed inner label > here ?? In this case,It is SPE and not UPE that established MP-BGP with PE(the PE in the remote point of HoPE), so SPE must replace the inner label distributed by UPE with another inner label distributed by SPE,otherwise, when transfer the data packet from PE to VPN1 site1,ths data packet can't reach UPE,it would dropped at SPE for the reason that SPE didn't recognise the inner label attatched with MP-IBGP NLRI between SPE and PE. > Section 7 > > > > In another case that SPE connect one UPE and one CE,CE connect to > site1,UPE connect to site2,site1 and site2 belong to the same VPN. > The forwarding procedure is as follows:When the packet with no > label sent from site1 arrived to SPE through CE, SPE push the label > distributed by UPE,forward it to UPE,UPE POP this label,then look up > the VRF route table,PUSH the label distribute by UPE2 and forward it > to UPE2,and UPE2 POP the label,forward it to site2. > > <...> > > What is UPE2 here .... may be this is a typo !! Yes,you are right,this is a big typo,It happenen when I add the page header and page footer to this draft after I finish this draft,I overlay the several lines of page header and page footer to the original text by mistake,sorry to confuse you,I have made the correction,the right one should be as follows: " In another case that SPE connect one UPE and one CE,CE connect to site1,UPE connect to site2,site1 and site2 belong to the same VPN. The forwarding procedure is as follows: (1)When the packet with no label sent from site1 arrived to SPE through CE, SPE look up VRF route table,and push the label distributed by UPE,forward it to UPE,UPE POP this label,forward it to Site2. (2)When the packet originated from Site2 arrived to UPE,UPE transfer the packet to SPE on the basis of default or aggregate route,SPE then look up the VRF route table,POP the label,forward it to Site1 as an IP packet." > Thanks & Regards, > -Senthil > > > On Wed, 6 Nov 2002, lidefeng wrote: > > > Hi,all, > > > > In BGP/MPLS VPN area, we proposed a new idea as to resolve the bottleneck > > of > > the capacity of some PEs when deploy the huge size VPN,the whole idea is > > detailed > > in the attached draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > > Abstract > > is as follows,we are appreciated for your review. > > > > In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should > > maintain all the VPN routes of the VPNs which it belong to.When there > > are many VPNs converged by a PE,and the capacity of PE is relevant > > limited,then the bottleneck will be encountered.Another problem is > > that the current BGP/MPLS VPN model is something of a "Plane Modle" > > where the demand of the performance of the PE device are all the > > same no matter which layer the PE device is belongs to.However,the > > typical network is "Core-Convergence-Access(Edge)" model,and the > > performance of the device is superior in Core Layer and inferior in > > Access Layer,and the scale of network is large in Access Layer and > > small in Core Layer,the routes are converged in every layer,so in > > current "Plane Modle",when PE device push to the edge layer,it has > > to maintain more VPN routes,this makes it difficult to extend the PE > > device to edge layer.This document defines an model of hiberarchy of > > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider > > Edge Device can be composed of several device and every device take > > on the different part,partake the function of the former > > concentrative PE,we call this model "Hiberarchy Model",In this model > > the demand of performance in Routing and Switching is strict to the > > PE device in High layer,loose to the PE device in edge layer. > > > > One HoPE can be composed of a SPE and UPES connected to the SPE, > > or be composed of a high-level SPE and HoPEs connected the high > > level SPE and and build up a new HoPE.This build is called nesting > > of HoPE,and this kind of nesting can be done for many times.Thus the > > former HoPE connect to the high-level SPE as a role of UPE,and the > > new HoPE can connect a single UPE too. > > > > Regards > > > > Defeng Li > > > --Boundary_(ID_0em36t8h9wMuZ2zPGHL3CQ) Content-type: text/plain; name=draft-libin-hierarchy-pe-bgp-mpls-vpn-00.txt Content-disposition: attachment; filename=draft-libin-hierarchy-pe-bgp-mpls-vpn-00.txt Content-Transfer-Encoding: 7BIT Network Working Group Li Bin Internet Draft Dong Weisi Expires: May 2003 Li Defeng Huawei Technologies November 06, 2002 Hiberarchy of Provider Edge Device in BGP/MPLS VPN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-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 In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should maintain all the VPN routes of the VPNs which it belong to.When there are many VPNs converged by a PE,and the capacity of PE is relevant limited,then the bottleneck will be encountered.Another problem is that the current BGP/MPLS VPN model is something of a "Plane Modle" where the demand of the performance of the PE device are all the same no matter which layer the PE device is belongs to.However,the typical network is "Core-Convergence-Access(Edge)" model,and the performance of the device is superior in Core Layer and inferior in Access Layer,and the scale of network is large in Access Layer and small in Core Layer,the routes are converged in every layer,so in current "Plane Modle",when PE device push to the edge layer,it has to maintain more VPN routes,this makes it difficult to extend the PE Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 1] Draft November 2002 device to edge layer.This document defines an model of hiberarchy of Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider Edge Device can be composed of several device and every device take on the different part,partake the function of the former concentrative PE,we call this model "Hiberarchy Model",In this model the demand of performance in Routing and Switching is strict to the PE device in High layer,loose to the PE device in edge layer. One HoPE can be composed of a SPE and UPES connected to the SPE, or be composed of a high-level SPE and HoPEs connected the high level SPE and and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connect to the high-level SPE as a role of UPE,and the new HoPE can connect a single UPE too. Table of Contents(will edit in the last) 1. Introduction ................................................. 3 2. Working Principle ........................ 4 2.1 VPN routes ............................................... 6 2.2 Control Flow(Route Advertising and Label Distribution) 2.3 Data Flow(Label Operation and Packet Forwarding) ................. 7 3. Interface between UPE and SPE....................................... 7 4. Nesting of HoPE 5. Multi-Homing UPE 6. Backdoor link between UPEs 7. The Forwarding Procedure in Some Special Cases 8. Security Consideration 9. Acknowledge 10. References 11. Authors' Addresses Full Copyright Statement ........................................ 11 Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 2] Draft November 2002 1. Introduction This document defines an model of hiberarchy of Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider Edge Device can be composed of several device and every device take on the different part,partake the function of the former concentrative PE,we call this model "Hiberarchy Model",In this model the demand of performance in Routing and Switching is strict to the PE device in High layer,loose to the PE device in edge layer. PE device can connect to not only the Customer Edge(CE) device,but also a PE device,or even more generally an MPLS VPN network,and the connected PE devices formed the "Hiberarchy of PE",and the PE device which replace the former position of CE device in "Plane Model" is called Under-layer PE,UPE in short,and the PE device which UPE is connected to is called Superstratum PE,SPE in short,this architiecture is called Hiberarchy of PE,HoPE in short.and the architecture figure is as follows(figure 1): +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +----------+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Site3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +----------+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +----------+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Site3| +----------+ | |--| MPLS |----| | | | +--+ +----------+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ +---+ +----------+ +----+ figure 1: Hiberarchy of PE Architecture Several UPE and SPE formed the Hiberarchy of PE,which provide the conventional function of PE in "Plane Model",and their respective functions are as follows: UPE maintains only the routes of the VPN sites which is directly connected to UPE,it don't maintain the routes of the remote VPN sites or only maintain the aggregate routes,SPE maintain the routes of all the sites directly connected to this SPE and the sites directly connected to UPE which directly connected to this SPE. UPE distribute the inner MPLS labels for the routes in the sites directly connected to it,and advertise the labels to SPE with the Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 3] Draft November 2002 VPN routes through MP-BGP,SPE don't advertise the routes in the remote sites to UPE,it only advertise the VRF default route or aggregate route to UPE,and the route is concomitant with the MPLS label. MP-IBGP or MP-EBGP can be applied between UPE and SPE,while MP-IBGP is applied,SPE should be the Route Reflector(RR) for all the UPEs collected to it,and UPE play the role of Client of this RR,BUT SPE doesn't act as the RR for other PEs. If MP-EBGP is applied between MP-EBGP,the AS number of the UPEs should be the private AS number(64512~65535).In fact,the Hiberarchy of PE can be handles with the rules of Confederation,in which case every confederation AS is composed of only one BGP Speaker,the UPE collected to the SPE. The packet forwarding between SPE and UPE is based on the label,so only one interface is needed to connected to each other,this interface can be a physical interface,or sub-interface,such as VLAN, PVC,tunnel such as GRE or LSP.When tunnel is applied between UPE and SPE,an IP network or MPLS network can be deployed between them. Hiberarchy of PE takes on all the functions of the normal PE, there is no difference between them when looked outside,so this "special" PE can coexist with other PEs in the MPLS network. 2. Working Principle This section specifies the working principle of Hiberarchy of PE including the maintaining of VPN routes,distribution of MPLS labels, and packet forwarding. 2.1 VPN routes SPE can establish MP-BGP neighborship with UPE,if they are administered by the same service provider,they can be MP-IBGP neighborship,otherwise should establish the MP-EBGP neighorship. In the MP-IBGP case,if there exists the sites of the different UPEs collected to an SPE belong to the same VPN,SPE as the Route Reflector for the relevant UPEs,otherwise SPE act as the convergent PE for all the UPEs collected to it.Route-Target lists are used to select the right VPN routes from other PEs as the normal "Plane Modle" BGP/MPLS VPN(RFC 2547bis),while only SPE will exchange the route information with other PEs,UPE should send the import route target list to SPE,SPE converge the route target lists and derive the HoPE-wide import route target list,with this HoPE-wide import route target,SPE can select the right VPN routes which belong to the VPNs which have the sites connected the SPE directly or through UPE. This HoPE-wide import route target list can be configured staticly or derived dynamically between SPE and UPEs.The dynamic mechanism is as follows: Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 4] Draft November 2002 UPE advertise the ORF(Outbound Route Filter)[BGP-ORF] to SPE through Route Refresh(RFC 2918) message,and an extended community list is included in the ORF item,the content of the extended community list is the aggregation of the import route target lists of all the VRFs in the UPE,and SPE converge all the import route target lists received from the UPEs connected to SPE and derive the HoPE-wide import route target list. In MP-EBGP case,SPE should derive the HoPE-wide import route target list all the same with the mechanism as above.In general,UPE should adopt the private AS number in VPN routes advertised to SPE.When SPE advertised the routes to other PEs,SPE should omitted the private AS. The scheme in which SPE connected to part of UPEs through MP-IBGP, and to the other part UPEs through MP-EBGP is permitted. UPE selects its own VPN routes by match its own import route target list with the export route target list attached with VPN routes respectively. SPE advertised the VRF default route or aggregate routes(by which UPE transfer the VPN packet to SPE) to UPE,this default VRF route can be formed dynamically or configured statically.When formed dynamically,it can be filtered by the ORF mechanism mentioned above. 2.2 Control Flow(Route Advertising and Label Distribution) This section specifies the mechanism the network distribute the labels for the routes in the VPN sites.The following figure(Figure 2) signifies the control flow between VPN1 site1 and VPN1 SITE2,the control flows(route and label distribution) in the two direction are different,there are four steps in every direction,labeled (1) through (4) in the direction from VPN1 SITE2 to VPN1 site1,and labeled (5) through (8) in the direction from VPN1 site1 to VPN1 SITE2. | (4) | (3) | (2) | (1) | |<-------|<------|<--------------|<-----| v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ |VPN1 Site1|-|CE1|---|UPE |---|SPE|---| P |---|PE|--|CE2|-|VPN1 SITE2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ ^ ^ ^ ^ ^ | (5) | (6) | (7) | (8 ) | |------->|------>|-------------->|----->| Figure 2: The control flow(route and label distribution) Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 5] Draft November 2002 In Figure 2,the meanings of (1) through (8) are as follows: Label (1) through (4) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: (1) CE2 advertise a route in the VPN1 SITE2 to PE; (2) PE distribute an inner MPLS label for this route;PE advertise this route to SPE through MP-BGP with the inner label,and the relevant export route target list attached; (3.a) SPE match the export route target list in the received route with the HoPE-wide import route target list to decide whether or not import the VPN route,in this case,they can be matched,then SPE will import the received VPN route. (3.b)At the same time SPE will match the export route target list in the received route with the import route target list advertised by VRF in UPEs connected to SPE,in this case, the import route target list of the VRF in UPE correspond to VPN1 Site1(called VRF1) will match,then SPE will advertise the default VRF1 route to UPE,with the inner MPLS label distributed by PE attached; (4) UPE advertise this route to CE1 through the route protocol(RIP, OSPF,BGP,or default route), Label (5) through (8) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: (5) CE1 advertise a route in the VPN1 site1 to UPE; (6) UPE distribute an inner label for this route;UPE advertise this route to SPE through MP-BGP with the inner label; (7) SPE replace the inner label distributed by UPE with another inner label distributed by SPE,then advertise this route to PE through MP-BGP with the new inner label attached; (8) PE distributed the route to CE2 with no label attached. Of course,the LSP should be established between SPE and PE in two directions respectively,This mechanism is the same as RFC 2547bis. The procedure of forwarding VPN packet with the two labels detailed in section 2.3 2.3 Data Flow(Label Operation and Packet Forwarding) This section specifies the mechanism of forwarding the VPN packets in the network with the route and label information derived by section 2.2. The following figure(Figure 3) signifies the data flows between Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 6] Draft November 2002 VPN1 site1 and VPN1 SITE2,the data flows(Label Operation and Packet Forwarding) in the two direction are different,there are five steps in every direction,labeled (1) through (5) in the direction from VPN1 SITE2 to VPN1 site1,and labeled (6) through (10) in the direction from VPN1 site1 to VPN1 SITE2. | (10) | (9) | (8) | (7) | (6) | |<-------|<------|<--------|<-----|<-----| v v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ |VPN1 Site1|-|CE1|---|UPE|---|SPE|---| P |---|PE|--|CE2|-|VPN1 SITE2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ ^ ^ ^ ^ ^ ^ | (1) | (2) | (3) | (4) | (5) | |------->|------>|--------|----->|----->| Figure 3: Data Flow(Label Operation and Packet Forwarding) In Figure 3,the meanings of (1) through (10) are as follows: Label (1) through (5) specifies the forwarding procedure in the direction of VPN1 Site1 visit VPN1 SITE2: (1) When the VPN packet of VPN1 Site1 visit VPN1 SITE2 arrived to CE1, CE1 forward the packet to UPE based on the default route or the route derive from dynamic route protocol between CE1 and UPE specified in the (4) of section 2.2. (2) UPE push the inner label based on the default VRF route,forward the VPN packet to SPE,the inner label and the default VRF route are specified in the (3) of section 2.2. (3) SPE POP the inner label pushed by UPE specified in (2) above,and look up the VRF route,push the new inner label which distributed by PE specified by (2) of section 2.2,then push the outer label distributed by P and forward the VPN packet to P,in backbone network, all the P router in the path of LSP from SPE to PE swap the outer label and forward the VPN packet through this LSP until the packet arrived to PE,or optionally the P router pen-ultimate hop the label. (4) The P router pen-ultimate hop to PE POP the outer label,forward the VPN packet to PE. (5) PE POP the inner label,forward the VPN packet to CE2,then CE2 forward the VPN packet to the VPN1 SITE2 with the route in this site. Label (6) through (10) specifies the forwarding procedure in the direction of VPN1 SITE2 visit VPN1 Site1: (6) When the VPN packet of VPN1 SITE2 visit VPN1 Site1 arrived to CE2, Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 7] Draft November 2002 CE2 forward the packet to PE based on the default route or the route derive from dynamic route protocol between CE2 and PE specified in the (8) of section 2.2. (7) PE push the inner label distributed by SPE specified in (7) of section 2.2 based on the VRF route,then push the outer label distributed by P and forward the VPN packet to P,in backbone network, all the P router in the path of LSP from PE to SPE swap the outer label and forward the VPN packet through this LSP until the P router pen-ultimate hop to SPE. (8) The P router optioanlly pen-ultimate hop to SPE POP the outer label,forward the VPN packet to SPE. (9) SPE swap the inner label in the VPN packet replace the inner label distributed by SPE with the new inner label distributed by UPE specified in (6) of section 2.2,then forward the VPN packet to UPE. (10) UPE POP the new inner label,forward the VPN packet to CE1,then CE1 forward the VPN packet to the VPN1 Site1 with the route in this site. 3. Interface between UPE and SPE UPE can connect to SPE with any type of interface and sub-interface, even with tunnel interface,in this case,UPE can connect with SPE through an IP or MPLS network,and because SPE and UPE are MP-BGP peers,the routes can be advertise directly through TCP connection. In MP-EBGP case,UPE and SPE can set up EBGP peers across the IP network or MPLS network by Multi-hop EBGP,when UPE or SPE forwarding the VPN packets with the label,they must pass a tunnel, if the tunnel is GRE,MPLS encapsulation must be supported;If the tunnel is LSP,the network between UPE ang SPE must be MPLS network, LDP/CR-LDP or RSVP-TE must be supported in UPE and SPE. 4. Nesting of HoPE One HoPE can be composed of a SPE and UPES connected to the SPE, or be composed of a high-level SPE and HoPEs connected the high level SPE and and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connect to the high-level SPE as a role of UPE,and the new HoPE can connect a single UPE too.Figure 4 in the following signifies a three-layer HoPE,and call the PE in the middle layer as MPE(Middle-level PE). Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 8] Draft November 2002 +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +----------+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Site3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +----------+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +----------+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Site3| +----------+ | |--| MPLS |----| | | | +--+ +----------+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ | | +----------+ +----+ | | | | +----------+ +----+ +----+ | | |VPN1 Site4|--|UPE3|--|MPE |------| | +----------+ +----+ +----+ +---+ (Nesting of HoPE) figure 4: Nesting of HoPE Between SPE and MPE,and between MPE and UPE run MP-BGP,if run MP-IBGP,then SPE worked as the route reflector for all the MPE,and MPEs worked as the route reflector for all the UPEs,and MP-BGP advertise all the VPN routes of the underlayer PEs to the upperlayer PE,and advertise the default VRF route or the aggregate route of the upperlayer to the underlayer PE. So SPE maintains all the VPN routes of the whole HoPE,and the MPE maintains the VPN routes of UPEs connected to this MPE.UPE maintain the VPN routes of sites connected to this UPE. SPE advertise the default VRF routes with the label attached to MPE, MPE replaces this label with the new label,and advertise this route with the new label attached to UPE. The upperlayer PE should create a HoPE-wide global import route target list,filter the VPN routes that don't belong to the VPNs connected to this upperlayer PE.MPE converge all the import route target lists of the UPEs connected to this MPE,and SPE converge all the converged import route target lists of the MPEs connected to this SPE.And this convergence can be configured statically or derived dynamically,in the latter case,MPE should forward the import route target list of MPE to SPE through ORF. When the VPN packet from the local site of HoPE is forwarded to UPE, UPE look up the relevant default VRF route,push the label and forward the packet to MPE,MPE POP the label,look up the default VRF Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 9] Draft November 2002 route or aggregate route to SPE,PUSH a new label forward the packet to SPE,SPE POP this label,look up the VRF forwarding table,PUSH the inner label,and the outer label the P router distribute for this route,then follow the RFC 2547bis forwarding procedure. Because MPE has distributes the inner label for the destination address of the VPN packet from the remote site,when the remote VPN packet is forwarded to SPE through the MPLS network following the RFC 2547bis forwarding procedure. SPE swap the inner label,forward this packet to MPE,for the same reason,MPE swap the inner label and forward this packet to UPE,then UPE POP the inner label and forward this packet to the local site. 5. Multi-Homing UPE One UPE can connect to several SPEs,in this case UPE is called Multi-Homing UPE,all the SPEs advertise the default VRF routes to this UPE,and UPE select the best one or treat them as ECMP(Equal Cost Multi-Path) and share the load among them.UPE advertised the VPN routes to all the SPEs,it can advertises all the VPN routes to all the SPEs,or it can advertises one part of VPN routes to one SPE, the other part to the other and shares the load among the SPEs. 6. Backdoor link between UPEs A kind of backdoor link can be setup between UPEs,so that the sites connected to these two UPEs can communicate with each other directly without passing through the SPE.And these UPEs can be those connect to the same SPE,or can be those connect to the different SPE,these UPEs advertise the VPN routes to each other through MP-BGP,The control flow and data flow are the same with RFC 2547bis Procedures, and even theu can cross a network,and the packet can pass through a tunnel such as GRE or LSP. 7. The Forwarding Procedure in Some Special Cases In one case that SPE connect two UPEs called UPE and UPE2,and these two UPEs connect two sites called site1 and site2 respectively,and site1 and site2 belong to the same VPN and visit to each other through SPE.The forwarding procedure is as follows:When the packet sent from site1 arrived to UPE,UPE push the label based on the default route and forward it to SPE,SPE POP this label,then look up the VRF route table,PUSH the label distribute by UPE2 and forward it to UPE2,and UPE2 POP the label,forward it to site2,and in the opposite direction,vise versa. In another case that SPE connect one UPE and one CE,CE connect to site1,UPE connect to site2,site1 and site2 belong to the same VPN. The forwarding procedure is as follows: (1)When the packet with no label sent from site1 arrived to SPE through CE, SPE look up VRF route table,and push the label distributed by UPE,forward it to UPE,UPE POP this label,forward it to Site2. (2)When the packet originated from Site2 arrived to UPE,UPE transfer the packet to SPE on the basis of default or aggregate route,SPE then look up the VRF route table,POP the label,forward it to Site1 as an IP packet. Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 10] Draft November 2002 8. Security Consideration The level of security provided by this architecture is identical to that provided by the RFC 2547bis,there is no security problem introduced. 9. Acknowledgements The authors would like to thank Li Hejun, Cao Xuegui,Chang Wenjun, We are very appreciated for their support 10. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [BGP-ORF] Enke Chen,Yakov Rekhter,"Cooperative Route Filtering Capability for BGP-4",draft-ietf-idr-route-filter-06.txt. [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, September 2000 [RFC2547] E. Rosen, Y. Rekhter, _BGP/MPLS VPNs,_ RFC 2547,March 1999. [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work in progress. 11.0 Author's Address Li Bin D201 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : l.b@huawei.com Dong Weisi C401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : dongws@huawei.com Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : lidefeng@huawei.com Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 11] Draft November 2002 Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Libin, et al. Hiberarchy of PE Device in BGP/MPLS VPN [Page 12] --Boundary_(ID_0em36t8h9wMuZ2zPGHL3CQ)-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 10 22:12: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 WAA29756 for ; Sun, 10 Nov 2002 22:12: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 gAB3Efv04040 for ; Sun, 10 Nov 2002 22:14: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 gAB3Ec009301 for ; Sun, 10 Nov 2002 22:14:38 -0500 (EST) Date: Mon, 11 Nov 2002 11:14:13 +0800 From: lidefeng Subject: Re: Please Review: A new draft about PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) To: Senthilkumar Rajasekharan Cc: ppvpn@nortelnetworks.com Message-id: <004001c28930$69a742c0$22436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-SMTP-HELO: mta1 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.15] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi, Senthil, Sorry to answer you so late! I will answer all the questions on the heels of them(you can find my answer as following ). BTW,I am ad hoc appreciated for your pointing out a big typo in this draft,I have correct it and send you the right one, I am very glad to discuss these questions with you! Keep in touch! Best Regards! Defeng Li ----- Original Message ----- From: "Senthilkumar Rajasekharan" To: "lidefeng" Cc: Sent: Friday, November 08, 2002 6:28 PM Subject: Re: Please Review: A new draft about PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) > Hi Defeng Li, > > Some questions on your draft .... > > Section 2.1 > > > > SPE advertised the VRF default route or aggregate routes(by which > UPE transfer the VPN packet to SPE) to UPE,this default VRF route > can be formed dynamically or configured statically.When formed > dynamically,it can be filtered by the ORF mechanism mentioned above. > > <...> > > Is this procedure mandatory, i.e should the SPE always advertise a default > route or aggregate route to the UPE? And should that route be advertised > with an aggregated export target list of all the import route targets received via > an ORF Route Refresh message from the UPE? Yes ,this procedure is mandatory,maybe from the point of view of working principle,SPE can run dynamic routing protocol with UPE and send all the routes in SPE to UPE,then UPE should store and maintain all the routes of the VPN in HoPE,the dvantage of this scheme will be forfeited, The default route is advertised when UPE connected to only one SPE. In the case of load balance where one UPE connected to several SPE(this situation didn't denoted in the figure of our draft) to balance the load of some VPN,then different SPE should advertise the different aggregated route to this UPE(the aggregated route is created according the match export target list received by the respective SPE between of the import route targets of different part of VPN in UPE ) > Section 2.2 > > > > (7) SPE replace the inner label distributed by UPE with another inner > label distributed by SPE,then advertise this route to PE through > MP-BGP with the new inner label attached; > > > <...> > > I don't understand why the SPE would replace UPE distributed inner label > here ?? In this case,It is SPE and not UPE that established MP-BGP with PE(the PE in the remote point of HoPE), so SPE must replace the inner label distributed by UPE with another inner label distributed by SPE,otherwise, when transfer the data packet from PE to VPN1 site1,ths data packet can't reach UPE,it would dropped at SPE for the reason that SPE didn't recognise the inner label attatched with MP-IBGP NLRI between SPE and PE. > Section 7 > > > > In another case that SPE connect one UPE and one CE,CE connect to > site1,UPE connect to site2,site1 and site2 belong to the same VPN. > The forwarding procedure is as follows:When the packet with no > label sent from site1 arrived to SPE through CE, SPE push the label > distributed by UPE,forward it to UPE,UPE POP this label,then look up > the VRF route table,PUSH the label distribute by UPE2 and forward it > to UPE2,and UPE2 POP the label,forward it to site2. > > <...> > > What is UPE2 here .... may be this is a typo !! Yes,you are right,this is a big typo,It happened when I add the page header and page footer to this draft after I finish this draft,I overlay the several lines of page header and page footer to the original text by mistake,sorry to confuse you,I have made the correction,the right one should be as follows: " In another case that SPE connect one UPE and one CE,CE connect to site1,UPE connect to site2,site1 and site2 belong to the same VPN. The forwarding procedure is as follows: (1)When the packet with no label sent from site1 arrived to SPE through CE, SPE look up VRF route table,and push the label distributed by UPE,forward it to UPE,UPE POP this label,forward it to Site2. (2)When the packet originated from Site2 arrived to UPE,UPE transfer the packet to SPE on the basis of default or aggregate route,SPE then look up the VRF route table,POP the label,forward it to Site1 as an IP packet." > Thanks & Regards, > -Senthil > > > On Wed, 6 Nov 2002, lidefeng wrote: > > > Hi,all, > > > > In BGP/MPLS VPN area, we proposed a new idea as to resolve the bottleneck > > of > > the capacity of some PEs when deploy the huge size VPN,the whole idea is > > detailed > > in the attached draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > > Abstract > > is as follows,we are appreciated for your review. > > > > In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should > > maintain all the VPN routes of the VPNs which it belong to.When there > > are many VPNs converged by a PE,and the capacity of PE is relevant > > limited,then the bottleneck will be encountered.Another problem is > > that the current BGP/MPLS VPN model is something of a "Plane Modle" > > where the demand of the performance of the PE device are all the > > same no matter which layer the PE device is belongs to.However,the > > typical network is "Core-Convergence-Access(Edge)" model,and the > > performance of the device is superior in Core Layer and inferior in > > Access Layer,and the scale of network is large in Access Layer and > > small in Core Layer,the routes are converged in every layer,so in > > current "Plane Modle",when PE device push to the edge layer,it has > > to maintain more VPN routes,this makes it difficult to extend the PE > > device to edge layer.This document defines an model of hiberarchy of > > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider > > Edge Device can be composed of several device and every device take > > on the different part,partake the function of the former > > concentrative PE,we call this model "Hiberarchy Model",In this model > > the demand of performance in Routing and Switching is strict to the > > PE device in High layer,loose to the PE device in edge layer. > > > > One HoPE can be composed of a SPE and UPES connected to the SPE, > > or be composed of a high-level SPE and HoPEs connected the high > > level SPE and and build up a new HoPE.This build is called nesting > > of HoPE,and this kind of nesting can be done for many times.Thus the > > former HoPE connect to the high-level SPE as a role of UPE,and the > > new HoPE can connect a single UPE too. > > > > Regards > > > > Defeng Li > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 10 23:10: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 XAA00717 for ; Sun, 10 Nov 2002 23:10:52 -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 gAB4Cgv24651 for ; Sun, 10 Nov 2002 23:12: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 gAB4Cd022896 for ; Sun, 10 Nov 2002 23:12:40 -0500 (EST) Message-Id: <5.0.2.7.2.20021111110422.03db4ec8@localhost> X-Sender: tk019/imd.m.ecl.ntt.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Mon, 11 Nov 2002 13:11:35 +0900 To: erosen@cisco.com, ppvpn@nortelnetworks.com From: Takeshi KUWAHARA Subject: Re: FW: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Cc: murayama.junichi@lab.ntt.co.jp, suzuki.muneyoshi@lab.ntt.co.jp, tanikawa.masaki@lab.ntt.co.jp, kuwahara.takeshi@lab.ntt.co.jp In-Reply-To: <200211011610.gA1GAlPP012211@sj-msg-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: kuwahara.takeshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Dear Eric, Thank you very much for your comments on our draft. And sorry for delay of my reply. At 11:10 02/11/01 -0500, Eric Rosen wrote: >Is this a useful technique in the context of L3VPN? I have a few comments: > >- The proposal seems to be restricted to backbones that support IPv6. This > limits its utility rather severely. (Well, one could use a 6-in-4 > encapsulation around the RFC 2473 encapsulation, but that seems kind of > silly.) We don't think the utility of our proposal is severely limited compared with MPLS/VPN, as MPLS/VPN is restricted to backbone that supports MPLS or MPLS over GRE/IP. Of course, MPLS as well as IPv6 has several alternatives as a lower layer network. We agree with your point of the usage of a 6-in-4 encapsulation in this case. >- The proposal requires that the ingress VFI map a VPN IP destination > address to an IPv6 address which uniquely identifies a VFI. It then > assumes that somehow each PE belonging to a particular VPN knows the IPv6 > addresses of all the remote VFIs in that VPN. Each spoke-VFI belonging to a particular VPN doesn't need to know addresses of all the remote VFIs in that VPN. A spoke-VFI has to know the addresses of the hub-VFIs, then other addresses of remote VFIs are learned automatically by CTCP. >It's not worth considering > the case in which every VFI in every PE is provisioned with the v6 > addresses of every remote VFI in the same VPN; that would subvert the > manageability/scalability claims that are being made. The provisioning of every VFI with addresses for all the VFIs, whch makes a full mesh topology, would obviously subvert the scalability. Therefore, we have adopted the hub-and-spoke topology that would lighten the provisioning of each spoke-VFI with only addressees of the hub-VFIs. > So we must suppose > that there is some sort of discovery scheme which passes around the v6 > addresses dynamically. Thus, we are proposing the CTCP to solve this issue. > Given this sort of discovery scheme, my observation is that it could just > as easily pass, for each VFI, the IP address of a PE, along with a 32-bit > (or 20-bit) label value that selects a particular VFI in that PE. This > could then be carried as part of a GRE encaps (or as part of an MPLS-in- > IP-or-GRE encaps). > > Then we would have an encapsulation which works equally well on v4 and v6 > backbones, is much more efficient on v4 backbones (if somewhat less > efficient on v6 backbones), and is more scalable from the manageability > perspective, as it doesn't require the provisioning of v6 addresses for > the VFIs. As a matter of the flexibility perspective in configuring the SP network, our proposal can introduce the same configuration approach as an IPv6 network, because it is based on IPv6. > I think the authors need to make a case as to why using a v6 address to > identify a VFI is better than any of the existing schemes. We consider that CL protocol is necessary to adopt CTCP. As for the CL protocol, IPv6 is suitable because it has huge address space that would make it possible to accommodate a large number of sites and VPNs. >- The proposed encaps doesn't seem applicable to the 2547 style of VPN, as > that distributes PE IP addresses and MPLS labels, rather than VRF > addresses. Of course, one could imagine extending 2547 to pass the v6 > addresses, but it's hard to see the advantage of doing so. RFC2547 proposes mainly about MPLS signaling and BGP-4 extension for supporting VPN. On the other hand, our draft proposes a method of controlling VPN tunnels by using IP-in-IP. So our draft is not directly related to RFC2547, above all, it is not necessary to refer to the Info. RFC. >The draft doesn't really discuss what happens if there are multiple hubs, >though I assume that the hubs don't want to send CTCP messages to each >other. The draft seems to assume that each PE knows (for each VFI) whether >it is a hub or a spoke; presumably this is a matter of configuration. But >to avoid situations in which hubs send CTCP to each other, each hub must >know of all the other hubs. The spokes also have to know of the hubs, so as >not to send purge messages to hubs. (At least, I assume that the spokes >don't want to be bombarding the hubs with useless purge messages.) I >imagine that hubs are supposed to ignore any received purge or redirect >messages, though the draft doesn't seem to mention that explicitly. > >It's very difficult to know what topologies are supposed to be ruled out, >how those rules are to be enforced, and what happens if through >misconfiguration an "unsupported topology" is created. The strict hub and >spoke hierarchy seems to be the only thing that protects against >long-standing loops, so it's important to understand whether this is >restriction is acceptable and enforceable. For example, requiring that >there only be a single hub is obviously not acceptable, due to the single >point of failure issues. Multiple hubs can be connected to form any type of topology. In this case, routes between DF-DF, DF-PE and PE-PE are controlled by routing protocols. A tree topology is obviously desirable as a mesh-type topology increases the load of routing. Also, as you have mentioned above, hub(DF)s must ignore any received purge or redirect messages in any type of topology. As for the bombarding to the hubs, we think it only occurs in the case of a malfunction of routing protocols, and if it's necessary, a PE may be restricted to send duplicated massages. >One problem is that the hub doesn't seem to remember that it has sent a >redirect to a spoke. So suppose that S1 and S2 are spokes attached to the >same site, but S1's route is, at some time, the preferable one. The hub may >now redirect some third spoke S3, so that packets from S3 for the site in >question go directly via S1. Then let us suppose that routing changes so >that S2's route to the site is now the preferable one. S3's packets will >continue going via S1, as long as S1 has a direct route to the site. There >doesn't seem to be any way to get S3 back on the optimal route, ever. +<-----DF | v D<---(preferable route)<----S1<---+<---------S3 | +---------------------------S2 In this case, when S2's route becomes the preferable route by some reasons, the route from the DF to the site will be changed from DF->S1->D to DF->S2->D by routing protocol, hence S1 will then sends a purge message to S3. After some packets going via the DF, the route from S3 to the site will finally be changed to S3->S2->D. Therefore, the problem you have mentioned will not occur. >(I am assuming here that one does not want to relegate multiply homed sites >to the case of an unsupported topology.) > >I think there needs to be a rule that cut-through routes must not be >distributed into the site via the site's IGP, i.e., that the CE routers must >only default-route to the spokes. Otherwise I think loops may be possible. As described above, a CE router can be multiply homed to PEs, and loops will not occur more than that may be occurred by routing protocols. >Another problem: any procedure in which control messages are sent as a >response to the reception of data messages is somewhat suspect; throttling >of the control messages becomes a necessity, though this isn't mentioned in >the draft. (Perhaps this is regarded as an implementation matter.) Unnecessary overlaped redirect/purge messages can be resiricted in sending PEs, but we think that is an implementation matter. >Another problem is that the redirect and purge messages are unreliable and >unsequenced. Purge messages may fail to get through in any sort of timely >manner, and the result may be black holes that last for quite awhile. Purge >messages which arrive late may already be obsolete, undoing the effect of >redirect messages which were sent later but arrived earlier. Redirect >messages which arrive late may already be obsolete, undoing the effect of >purge messages which were sent later but arrived earlier. If a spoke loses >a route, there will be a lag time during which the hub hasn't recomputed >routes yet; during this time, there may be a "war" during which the hub >constantly emits redirects for the lost route, and the spoke constantly >emits purges. With no sequencing, some of these messages may get processed >after the hub recomputes the routes, and this may greatly increase the >effective routing convergence time. Restricting unessesary overlaped redirect/purge messages would lighten this problem. Additionally, if the topology is a hub-and-spoke or a tree type, the time lag of setting routes would not be so long since the PE only needs to send accommodating addresses to the upper PE/DF. >The use of a connectionless control plane is also suspect from a security >perspective. There needs to at least be some optional method for >authenticating and ensuring the integrity of the CTCP messages. When the >control plane sets up connections, one can talk about using IPsec, TLS, >etc., but when each control packet is a datagram, I'm not sure I understand >how the security would be done. The "security considerations" section is >only one sentence long; no one has ever let me get away with writing such a >short security considerations section ;-) A closed IPv6 network would keep the security for VPN, just the same as the 2547 style of VPN keeps the security by closing the MPLS core network. Regards, Takeshi Kuwahara. From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 10 23:21:31 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 XAA00807 for ; Sun, 10 Nov 2002 23:21: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 gAB4NSv28713 for ; Sun, 10 Nov 2002 23: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 gAB4NP028645 for ; Sun, 10 Nov 2002 23:23:26 -0500 (EST) Message-Id: <5.0.2.7.2.20021111131212.042afec8@localhost> X-Sender: tk019/imd.m.ecl.ntt.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Mon, 11 Nov 2002 13:22:24 +0900 To: Benson.Schliesser@savvis.net, ppvpn@nortelnetworks.com From: Takeshi KUWAHARA Subject: RE: FW:I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Cc: murayama.junichi@lab.ntt.co.jp, tanikawa.masaki@lab.ntt.co.jp, suzuki.muneyoshi@lab.ntt.co.jp, kuwahara.takeshi@lab.ntt.co.jp In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: kuwahara.takeshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Dear Benson, Thank you very much for your comments on our draft. At 11:25 02/11/01 -0600, you wrote: >While 4-in-6 tunneling is a concept that could be applied to the VR model, >I'd suggest that the CTCP model is naturally exclusive of the VR model just >as it is the BGP/MPLS model. It supplants the route distribution mechanism >of both models with a new one. I think it is said in the VR draft that the hub-and-spoke topology is applicable. So why wouldn't it be possible to apply CTCP to the VR model by using IP-in-IP for the tunneling? Could you please explain the reasons in more concrete terms. > > With regard to its going forward as an informational RFC, > > I don't really see why it should. [...] and this particular > > solution seems to have a number of unresolved issues. Unless > > there is already widespread deployment of CTCP, I don't see > > what the interest is. > >I have to agree with Eric's comments (including those not quoted here) on >this draft. While it's possible that this model will actually work, I don't >see how it's a better alternative to any of the existing models. We think our approach has much advantages because it can lower the load of control by the stateless procedures, and the routing loop problem has been solved. >In fact, as >Eric points out, there are a great many concerns with the model. If it had >some hope of becoming a stronger solution than what exists today I would >suggest that we work through these concerns and help it mature. But I tend >towards thinking that would be wasted energy. Please refer to my reply to Eric. >This draft is interesting for discussion, but not useful for >standardization. And if it's not employed by more than a single provider >then I see no reason to bother documenting it in a public forum. Our approach has already been employed by several providers, and implementations were made by multiple vendors, of which interoperability has also been tested. Therefore we believe it would be useful for the public. Regards, Takeshi Kuwahara. From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 11 01:51:44 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 BAA02601 for ; Mon, 11 Nov 2002 01:51: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 gAB6rZB17694 for ; Mon, 11 Nov 2002 01:53:35 -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 gAB6rTW03736 for ; Mon, 11 Nov 2002 01:53:30 -0500 (EST) Message-Id: <200211110650.PAA90663@infer.nal.ecl.net> To: "Chen, Weijing" cc: "'erosen@cisco.com'" , "Marco Carugi" , ppvpn@nortelnetworks.com, "'Muneyoshi Suzuki'" , "'kuwahara.takeshi@lab.ntt.co.jp'" Subject: Re: FW: Fwd: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt In-reply-to: Your message of "Fri, 01 Nov 2002 13:35:46 CST." <905A1C4ABF353F4C8CC16FA9F53DD0D63226E2@trimail2> Date: Mon, 11 Nov 2002 15:50:56 +0900 From: Muneyoshi Suzuki X-SMTP-HELO: infer.nal.ecl.net X-SMTP-MAIL-FROM: suzuki@nal.ecl.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: infer.nal.ecl.net [163.138.70.32] X-LYRIS-Message-Id: Chen, > The other problem with this draft is that it is unknown how the proposal > handles the Internet access from VPN and inter-VPN access. > Nonetheless, the scaleable and manageable operation issues of current VPN > brought by this draft are still a valid and major concern among service > providers. Witness the draft > http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt, it raises > the same concern. The solution proposed by the late draft may have some > same disadvantages layout by Eric's email, such as rely on IPv6 as core > network, encapsulation in IPv6, etc. Although IPv6 was chosen for the > solution, it doesn't prevent the solution from expansion into IPv4. But > from the ongoing industry and market trend, it seems too late to do anything > other than MPLS VPN in IPv4 space. > Once again, we operation group in service provider has very serious concern > about scaleable manageability draft-ietf-ppvpn-cl-tunneling-vpn-00.txt does not claim that the MPLS/BGP approach is not scale, so it also does not claim it is much scale than the MPLS/BGP. 2547 mainly discusses BGP-4 extensions for VPN routing, membership discovery, and MPLS signaling for it, while, our draft discuss IP-in-IPv6 tunnel control mechanism. Scalability of 2547 is already discussed in draft-ietf-ppvpn-as2547-00.txt. If you have scalability or manageability issues about 2547 approach, please specifically point out it on the PPVPN WG mailing list or to the AS documents design team. Thanks, Muneyoshi Suzuki From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 11 02:20: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 CAA12665 for ; Mon, 11 Nov 2002 02:20: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 gAB7MAB28436 for ; Mon, 11 Nov 2002 02:22:10 -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 gAB7M7W01148 for ; Mon, 11 Nov 2002 02:22:07 -0500 (EST) Date: Mon, 11 Nov 2002 15:34:41 +0800 From: Du Wenhua Subject: Re:RE:RE:RE: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) To: Miao Fuyou Cc: "ppvpn@nortelnetworks.com" Reply-to: duwh@huawei.com Message-id: <0H5E00MPDHNRGC@mta0.huawei.com> Organization: Huawei Techlonogies, Co., Ltd MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: duwh@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12665 Hi,Miao Fuyou, I appreciate this draft on account of the following reasons: (1) Hold quite a big advantage over expansibility. (2) There exist no cross-operation problems between diffrent vendors. It is not necessary to recompose the protocols between the equipment. The rework lies in the inner SPE, which does not affect the communication between the equipment. So as for the other PEs, SPE is a standard PE of RFC2547bis. (3). Do not need to recompose the data panel of the current equipment. (4). Once recomposing the control panel, a PE equipment will become a SPE equipment. (5). It can construct many variable topologies by nest of HoPE, such as tree¡¢partial mesh. Other methods can achieve the goal also, such as Hub&spoke, L2-transport. Hub&spoke is more simple, but it's topology is not flex enough(only surport two stages?) . In L2-transport, U-PE or MTU does not need BGP at all, it is low price, i.e ethernet switch. But,the data pannel of N-PE or SPE is more complicated. It must -route- IP packet over ethernet over PWE3, i.e L2TPv3, marteni-draft based tunnel. As I known, many devices can only bridge PWs£¬can not route. L2-tranport consume more cost of bandwith(a PWE3 header, a ethernet header, about 20-btye). In HoPE, it requre additional IP address lookups between ingress PE and egress PE, plus label disposition/imposition. IMHO, it is not a issue. Many device in the market can pop 3 labeles, then look up IP long match, then push 4 labeles at wire speed. So,both can do, just like we need a sedan and a van. Yours ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Du Wenhua ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡duwh@huawei.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-11-11 >-----Original Message----- >From: Miao Fuyou >Sent: 17:01:00,2002-11-09 >To: 'Jim Guichard' >Subject: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) >Hi, Jim: > >Please find my commnets inline! > >Regards >-----ÓʼþÔ­¼þ----- >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 23:29 >ÊÕ¼þÈË: ???¡ê¨®?; '¡§¡è??¨¤¡§?' >³­ËÍ: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei. >com; Gma@futurewei.com; changwj@huawei.com; leh10814@huawei.com >Ö÷Ìâ: RE: ´ð¸´: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy >of PE Device inBGP/MPLS VPN) > > >Hi Miao, > >I understand that this is not a replacement to 2547. I also understand >that hierarchy is one of the tools we have to help scale networks. >However, what I am driving at is that 2547 provides all of the necessary >mechanisms already to run this type of topology - deployment of 2547 is >a matter of design and no new functionality is necessary to be able to >run the topology you are suggesting. We have many deployments worldwide >that already use this type of design to provide central services to >their customers. This does not mean however that the topology is >appropriate for all 2547 customers. There are a number of issues with >the proposed topology that one might consider: > >Miao: Actually it's not a problem of topology, it's for the planning and >design of the network. If 2547 alone can work under for every network >and meet all the VPN requirement, why were VPLS, Martini VPN, Kompella >VPN and many others proposed? > >1. In most real world deployments the number of hops between UPE and SPE >will be > 1. This may introduce unacceptable latency and so on, >especially as the design is being used for transit traffic rather than >central services. > >Miao: I don't think hops > 1 brings more latency if a packet must go >from an ingress PE to an egress PE. Actually it follows almost the same >route that 2547 one will do if the network is not very careless >designed. > >2. Using this method introduces additional IP address lookups between >ingress PE and egress PE, plus label disposition/imposition. > >Miao: It's a ONCE-FOR-ALL work for a site, so the effort is trivial > >3. Unless the SPE is located locally to the UPE then the regional VPN >traffic will be concentrated toward certain points of the network, >instead of being distributed across the whole infrastructure. > >Miao: UPE can process it locally in such case, no SPE involved > >4. If the SPE is located locally, then aggregates can be injected down >to the UPEs but this is assuming that the address space is designed in >such a way as to allow this aggregation. Most Enterprise networks today >do not have such a well structured addressing plan. > >Miao: Refer item 3 > >5. By injecting aggregates toward the CE site you change the customers >routing view which may actually require the injection of more specific >routes. > >Miao: No aggretes injected in HoPE actually > >6. The SP has to keep track of the aggregation and configure it >appropriately at the SPE. > >Miao: SPE will do > >7. How do you take care of customers that want to run OSPF or ISIS on >the PE-CE links ? how would sham-links work for example ? > >Miao: Only default route is needed in HoPE at PE-CE links, so why to run >OSPF & IS-IS? > >8. To deploy H&S designs one must use different RTs for the same VPN and >then apply policy to filter correctly. This may not be such a big deal >but is a further complication in the provisioning and management >process. > >Miao: Repeat, it's not a problem of topology, not to say H&S > >9. If our goal is to offload the edge routers from having to carry VPNv4 >routes or run MP-BGP sessions then perhaps we should use the >L2-transport functionality in MPLS to carry the edge traffic to an SPE. >This has the advantage that the CE can exchange routes directly with the >SPE which is useful for other applications. > >Miao: L2-transport is not always applicable. CEs don't always run MPLS. > >10. How do you take care of customers that want to run Carrier's Carrier >architecture ? > >Miao: But, what is the problem? > > >regards, > > >> >-----Original Message----- >> >From: Ã縣ÓÑ [mailto:miaofy@huawei.com] >> >Sent: Thursday, November 07, 2002 9:07 PM >> >To: 'Jim Guichard'; '¨¤?¡À¨®' >> >Cc: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; >> >leh10814@huawei.com >> >Subject: ´ð¸´: ´ð¸´: Please Review: A new draft about >PPVPN(Hiberarchy of >> >PE Device inBGP/MPLS VPN) >> > >> > >> >Hi, Jim: >> > >> >This draft is not to replace 2547, but a supplement to it. Actually >> >the VPN in the draft is completely works under the mechanism of 2547. >> > >> >In the traditional 2547 VPN, only one type of PE is defined. When >> >deployment, PE will not has so many ports to attach many VPNs if the >> >PE is at the core layer of the network, because core router generally > >> >doesn't have a lot of physically interfaces. If the PE is at the >> >edge of the network, it will have a lot of interfaces, but now the >> >botlleneck is capacity of computation of the router. >> > >> >This draft is to solve the problem, UPE will provide abundant >> >interface to conenct sites to VPN and SPE will have enough CPU/Memory > >> >to process routes. >> > >> >Regards >> >Miao >> > >> >-----ÓʼþÔ­¼þ----- >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 >> >ÊÕ¼þÈË: ¨¤?¡À¨® >> >³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco Carugi; >> >sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; >> >ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; >> >changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com >> >Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of >PE >> >Device inBGP/MPLS VPN) >> > >> > >> >so can hub&spoke with 2547 - you basically export routes from the >> >CE-attached PEs to a hub PE that imports the routes. The hub PE >> >exports either a default or aggregates to attract traffic from other >> >CE-attached PEs and then performs a lookup to forward the packets to >> >other CE-attached PEs .. Jim >> > >> >> >-----Original Message----- >> >> >From: Àî±ó [mailto:l.b@huawei.com] >> >> >Sent: Thursday, November 07, 2002 2:42 AM >> >> >To: Jim Guichard >> >> >Cc: internet-drafts@ietf.org; rwilder@masergy.com; >> >> >marco.carugi@nortelnetworks.com; sob@harvard.edu; >> >> >bwijnen@lucent.com; >> > >> >> >zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; >> >> >Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; >> >> >leh10814@huawei.com >> >> >Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy >of >> >PE >> >> >Device inBGP/MPLS VPN) >> >> > >> >> > >> >> >Hi, Guichard >> >> >The hub & spoke is the relationship between CEs, but SPE peer with > >> >> >UPE by MP-BGP, they are all PEs, and they all can admit VPN user. >> >> > >> >> >Libin >> >> > >> >> >-----ԭʼÓʼþ----- >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 >> >> >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org >> >> >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; >> >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. >> >> >Miao; leh10814@huawei. com; l.b@huawei.com >> >> >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE >> >> >Device inBGP/MPLS VPN) >> >> > >> >> > >> >> >I briefly ran through this draft and it looks like normal hub & >> >> >spoke >> > >> >> >using existing 2547 mechanisms - could you explain how this >> >> >differs ? >> > >> >> >thanks, >> >> > >> >> >> >-----Original Message----- >> >> >> >From: lidefeng [mailto:lidefeng@huawei.com] >> >> >> >Sent: Tuesday, November 05, 2002 11:40 PM >> >> >> >To: internet-drafts@ietf.org >> >> >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; >> >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; >> >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. >> >> >> >Miao; >> > >> >> >> >leh10814@huawei.com; l.b@huawei.com >> >> >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy of >> >> >> >PE Device in BGP/MPLS VPN) >> >> >> > >> >> >> > >> >> >> >Hi,all, >> >> >> > >> >> >> > In BGP/MPLS VPN area, we proposed a new idea as to resolve >> >> >> >the bottleneck of the capacity of some PEs when deploy the huge > >> >> >> >size VPN,the >> >> >whole idea is >> >> >> >detailed >> >> >> >in the attached >> >> >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the >> >> >> >Abstract is as follows,we are appreciated for your review. >> >> >> > >> >> >> > In the deployment of BGP/MPLS VPN,the PE(Provider >> >> >Edge)Device should >> >> >> > maintain all the VPN routes of the VPNs which it belong >> >> >to.When there >> >> >> > are many VPNs converged by a PE,and the capacity of PE is >> >relevant >> >> >> > limited,then the bottleneck will be encountered.Another >> >> >> > problem >> >is >> >> >> > that the current BGP/MPLS VPN model is something of a "Plane >> >Modle" >> >> >> > where the demand of the performance of the PE device are all >> >the >> >> >> > same no matter which layer the PE device is belongs >> >> >> > to.However, >> >the >> >> >> > typical network is "Core-Convergence-Access(Edge)" model,and >> >the >> >> >> > performance of the device is superior in Core Layer and >> >inferior in >> >> >> > Access Layer,and the scale of network is large in Access >> >> >> > Layer >> >and >> >> >> > small in Core Layer,the routes are converged in every >> >> >> > layer,so >> >in >> >> >> > current "Plane Modle",when PE device push to the edge >> >> >> > layer,it >> >has >> >> >> > to maintain more VPN routes,this makes it difficult to >> >> >extend the PE >> >> >> > device to edge layer.This document defines an model of >> >> >hiberarchy of >> >> >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of >> >Provider >> >> >> > Edge Device can be composed of several device and every >> >> >> > device >> >take >> >> >> > on the different part,partake the function of the former >> >> >> > concentrative PE,we call this model "Hiberarchy Model",In >> >> >this model >> >> >> > the demand of performance in Routing and Switching is strict > >> >> >> > to >> >the >> >> >> > PE device in High layer,loose to the PE device in edge >> >> >> > layer. >> >> >> > >> >> >> > One HoPE can be composed of a SPE and UPES connected to the >> >SPE, >> >> >> > or be composed of a high-level SPE and HoPEs connected the >high >> >> >> > level SPE and and build up a new HoPE.This build is called >> >nesting >> >> >> > of HoPE,and this kind of nesting can be done for many >> >> >times.Thus the >> >> >> > former HoPE connect to the high-level SPE as a role of >> >> >> > UPE,and >> >the >> >> >> > new HoPE can connect a single UPE too. >> >> >> > >> >> >> >Regards >> >> >> > >> >> >> >Defeng Li >> >> >> > >> > >> > = = = = = = = = = = = = = = = = = = = = From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 11 08:41: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 IAA18143 for ; Mon, 11 Nov 2002 08:41: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 gABDhTB03722 for ; Mon, 11 Nov 2002 08:43: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 gABDhPW25733 for ; Mon, 11 Nov 2002 08:43:26 -0500 (EST) From: "Jim Guichard" To: "Miao Fuyou" , =?GB2312?B?Jz+h7D+oqD8/oaeh6D+h7D8n?= Cc: Subject: =?GB2312?B?UkU6ILTwuLQ6ILTwuLQ6ILTwuLQ6IFBsZWFzZSBSZXZpZXc6IEEgbg==?= =?GB2312?B?ZXcgZHJhZnQgYWJvdXQgUFBWUE4oSGliZXJhcmNoeSBvZiBQRSBEZQ==?= =?GB2312?B?dmljZSBpbkJHUC9NUExTIFZQTik=?= Date: Mon, 11 Nov 2002 08:38:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <000001c287ce$97bf3ae0$2e426e0a@HUAWEI.COM> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-MIME-Autoconverted: from 8bit to quoted-printable by cisco.com id NAA25950 X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: london2.cisco.com [64.103.110.74] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA18143 Hi Miao, > >-----Original Message----- > >From: Miao Fuyou [mailto:miaofy@huawei.com] > >Sent: Saturday, November 09, 2002 4:01 AM > >To: 'Jim Guichard'; '¡§¡è??¨¤¡§?' > >Cc: ppvpn@nortelnetworks.com > >Subject: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > > > > > > > >Hi, Jim: > > > >Please find my commnets inline! > > > >Regards > >-----ÓʼþÔ­¼þ----- > >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 23:29 > >ÊÕ¼þÈË: ???¡ê¨®?; '¡§¡è??¨¤¡§?' > >³­ËÍ: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei. > >com; Gma@futurewei.com; changwj@huawei.com; leh10814@huawei.com > >Ö÷Ìâ: RE: ´ð¸´: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy > >of PE Device inBGP/MPLS VPN) > > > > > >Hi Miao, > > > >I understand that this is not a replacement to 2547. I also understand > >that hierarchy is one of the tools we have to help scale networks. > >However, what I am driving at is that 2547 provides all of the necessary > >mechanisms already to run this type of topology - deployment of 2547 is > >a matter of design and no new functionality is necessary to be able to > >run the topology you are suggesting. We have many deployments worldwide > >that already use this type of design to provide central services to > >their customers. This does not mean however that the topology is > >appropriate for all 2547 customers. There are a number of issues with > >the proposed topology that one might consider: > > > >Miao: Actually it's not a problem of topology, it's for the planning and > >design of the network. If 2547 alone can work under for every network > >and meet all the VPN requirement, why were VPLS, Martini VPN, Kompella > >VPN and many others proposed? well VPLS, Martini and Kompella are talking about layer-2 application - we are talking about layer-3 here which is a little different wouldn't you agree ? > > > >1. In most real world deployments the number of hops between UPE and SPE > >will be > 1. This may introduce unacceptable latency and so on, > >especially as the design is being used for transit traffic rather than > >central services. > > > >Miao: I don't think hops > 1 brings more latency if a packet must go > >from an ingress PE to an egress PE. Actually it follows almost the same > >route that 2547 one will do if the network is not very careless > >designed. well I think it is fair to say that if you attract traffic to a particular point of the network then the optimal path from an routing perspective is more likely to be overlooked - this is not always the case but you cannot assume in an architecture that all networks are built the same. > > > >2. Using this method introduces additional IP address lookups between > >ingress PE and egress PE, plus label disposition/imposition. > > > >Miao: It's a ONCE-FOR-ALL work for a site, so the effort is trivial maybe I misunderstood your description but if the hub has to route inter-site traffic then we must remove the label stack, look at the IP address and then send it back on its way - this is a per-packet exercise not per-site. > > > >3. Unless the SPE is located locally to the UPE then the regional VPN > >traffic will be concentrated toward certain points of the network, > >instead of being distributed across the whole infrastructure. > > > >Miao: UPE can process it locally in such case, no SPE involved how can it if it does not have the routes ? if it has the routes then we have 2547 no ? > > > >4. If the SPE is located locally, then aggregates can be injected down > >to the UPEs but this is assuming that the address space is designed in > >such a way as to allow this aggregation. Most Enterprise networks today > >do not have such a well structured addressing plan. > > > >Miao: Refer item 3 so item 3 says there is no aggregation and the scheme is rendered useless. > > > >5. By injecting aggregates toward the CE site you change the customers > >routing view which may actually require the injection of more specific > >routes. > > > >Miao: No aggretes injected in HoPE actually well if it is just default route the same comment applies and is actually even worse. > > > >6. The SP has to keep track of the aggregation and configure it > >appropriately at the SPE. > > > >Miao: SPE will do how ? there are many ways to generate such an aggregate, each of which have their own implications. > > > >7. How do you take care of customers that want to run OSPF or ISIS on > >the PE-CE links ? how would sham-links work for example ? > > > >Miao: Only default route is needed in HoPE at PE-CE links, so why to run > >OSPF & IS-IS? default is not sufficient for most customers - a large subset of Internet customers today want more than just default route. OSPF, ISIS, EIGRP and so on were introduced so as to avoid changing the routing view of the end customers - this is a desired requirement that HoPE does not service. > > > >8. To deploy H&S designs one must use different RTs for the same VPN and > >then apply policy to filter correctly. This may not be such a big deal > >but is a further complication in the provisioning and management > >process. > > > >Miao: Repeat, it's not a problem of topology, not to say H&S > > > >9. If our goal is to offload the edge routers from having to carry VPNv4 > >routes or run MP-BGP sessions then perhaps we should use the > >L2-transport functionality in MPLS to carry the edge traffic to an SPE. > >This has the advantage that the CE can exchange routes directly with the > >SPE which is useful for other applications. > > > >Miao: L2-transport is not always applicable. CEs don't always run MPLS. CEs do not need to run MPLS to run L2-transport - the PEs do the L2-transport. > > > >10. How do you take care of customers that want to run Carrier's Carrier > >architecture ? > > > >Miao: But, what is the problem? the problem is that you cannot run an end-to-end LSP to allow this type of architecture to work .. regards, > > > > > >regards, > > > > > >> >-----Original Message----- > >> >From: Ã縣ÓÑ [mailto:miaofy@huawei.com] > >> >Sent: Thursday, November 07, 2002 9:07 PM > >> >To: 'Jim Guichard'; '¨¤?¡À¨®' > >> >Cc: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; > >> >leh10814@huawei.com > >> >Subject: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of > >> >PE Device inBGP/MPLS VPN) > >> > > >> > > >> >Hi, Jim: > >> > > >> >This draft is not to replace 2547, but a supplement to it. Actually > >> >the VPN in the draft is completely works under the mechanism of 2547. > >> > > >> >In the traditional 2547 VPN, only one type of PE is defined. When > >> >deployment, PE will not has so many ports to attach many VPNs if the > >> >PE is at the core layer of the network, because core router generally > > > >> >doesn't have a lot of physically interfaces. If the PE is at the > >> >edge of the network, it will have a lot of interfaces, but now the > >> >botlleneck is capacity of computation of the router. > >> > > >> >This draft is to solve the problem, UPE will provide abundant > >> >interface to conenct sites to VPN and SPE will have enough CPU/Memory > > > >> >to process routes. > >> > > >> >Regards > >> >Miao > >> > > >> >-----ÓʼþÔ­¼þ----- > >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 > >> >ÊÕ¼þÈË: ¨¤?¡À¨® > >> >³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco Carugi; > >> >sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; > >> >ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; > >> >changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com > >> >Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of > >PE > >> >Device inBGP/MPLS VPN) > >> > > >> > > >> >so can hub&spoke with 2547 - you basically export routes from the > >> >CE-attached PEs to a hub PE that imports the routes. The hub PE > >> >exports either a default or aggregates to attract traffic from other > >> >CE-attached PEs and then performs a lookup to forward the packets to > >> >other CE-attached PEs .. Jim > >> > > >> >> >-----Original Message----- > >> >> >From: Àî±ó [mailto:l.b@huawei.com] > >> >> >Sent: Thursday, November 07, 2002 2:42 AM > >> >> >To: Jim Guichard > >> >> >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >> >> >marco.carugi@nortelnetworks.com; sob@harvard.edu; > >> >> >bwijnen@lucent.com; > >> > > >> >> >zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; > >> >> >Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >> >> >leh10814@huawei.com > >> >> >Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy > >of > >> >PE > >> >> >Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> >Hi, Guichard > >> >> >The hub & spoke is the relationship between CEs, but SPE peer with > > > >> >> >UPE by MP-BGP, they are all PEs, and they all can admit VPN user. > >> >> > > >> >> >Libin > >> >> > > >> >> >-----ԭʼÓʼþ----- > >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >> >> >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >> >> >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >> >> >Miao; leh10814@huawei. com; l.b@huawei.com > >> >> >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE > >> >> >Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> >I briefly ran through this draft and it looks like normal hub & > >> >> >spoke > >> > > >> >> >using existing 2547 mechanisms - could you explain how this > >> >> >differs ? > >> > > >> >> >thanks, > >> >> > > >> >> >> >-----Original Message----- > >> >> >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >> >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >> >> >To: internet-drafts@ietf.org > >> >> >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >> >> >> >Miao; > >> > > >> >> >> >leh10814@huawei.com; l.b@huawei.com > >> >> >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy of > >> >> >> >PE Device in BGP/MPLS VPN) > >> >> >> > > >> >> >> > > >> >> >> >Hi,all, > >> >> >> > > >> >> >> > In BGP/MPLS VPN area, we proposed a new idea as to resolve > >> >> >> >the bottleneck of the capacity of some PEs when deploy the huge > > > >> >> >> >size VPN,the > >> >> >whole idea is > >> >> >> >detailed > >> >> >> >in the attached > >> >> >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >> >> >> >Abstract is as follows,we are appreciated for your review. > >> >> >> > > >> >> >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >> >> >Edge)Device should > >> >> >> > maintain all the VPN routes of the VPNs which it belong > >> >> >to.When there > >> >> >> > are many VPNs converged by a PE,and the capacity of PE is > >> >relevant > >> >> >> > limited,then the bottleneck will be encountered.Another > >> >> >> > problem > >> >is > >> >> >> > that the current BGP/MPLS VPN model is something of a "Plane > >> >Modle" > >> >> >> > where the demand of the performance of the PE device are all > >> >the > >> >> >> > same no matter which layer the PE device is belongs > >> >> >> > to.However, > >> >the > >> >> >> > typical network is "Core-Convergence-Access(Edge)" model,and > >> >the > >> >> >> > performance of the device is superior in Core Layer and > >> >inferior in > >> >> >> > Access Layer,and the scale of network is large in Access > >> >> >> > Layer > >> >and > >> >> >> > small in Core Layer,the routes are converged in every > >> >> >> > layer,so > >> >in > >> >> >> > current "Plane Modle",when PE device push to the edge > >> >> >> > layer,it > >> >has > >> >> >> > to maintain more VPN routes,this makes it difficult to > >> >> >extend the PE > >> >> >> > device to edge layer.This document defines an model of > >> >> >hiberarchy of > >> >> >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of > >> >Provider > >> >> >> > Edge Device can be composed of several device and every > >> >> >> > device > >> >take > >> >> >> > on the different part,partake the function of the former > >> >> >> > concentrative PE,we call this model "Hiberarchy Model",In > >> >> >this model > >> >> >> > the demand of performance in Routing and Switching is strict > > > >> >> >> > to > >> >the > >> >> >> > PE device in High layer,loose to the PE device in edge > >> >> >> > layer. > >> >> >> > > >> >> >> > One HoPE can be composed of a SPE and UPES connected to the > >> >SPE, > >> >> >> > or be composed of a high-level SPE and HoPEs connected the > >high > >> >> >> > level SPE and and build up a new HoPE.This build is called > >> >nesting > >> >> >> > of HoPE,and this kind of nesting can be done for many > >> >> >times.Thus the > >> >> >> > former HoPE connect to the high-level SPE as a role of > >> >> >> > UPE,and > >> >the > >> >> >> > new HoPE can connect a single UPE too. > >> >> >> > > >> >> >> >Regards > >> >> >> > > >> >> >> >Defeng Li > >> >> >> > > >> > > >> > From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 11 10:16:07 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 KAA21688 for ; Mon, 11 Nov 2002 10:16:07 -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 gABFHtB21302 for ; Mon, 11 Nov 2002 10:17: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 gABFHqW10644 for ; Mon, 11 Nov 2002 10:17:52 -0500 (EST) Message-Id: <4.3.2.7.2.20021111095826.05688cb0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Nov 2002 10:17:08 -0500 To: "Elwin Eliazer" From: "Thomas D. Nadeau" Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt Cc: jcucchiara@mindspring.com, , , In-Reply-To: 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: At 03:28 PM 10/15/2002 -0700, Elwin Eliazer wrote: >Hi Joan, > >Thanks for your very valid comments. >Excuse us for the delay in responding. >My responses are in-lined below. > >Cheers, >Elwin. > >-----Original Message----- >From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com] >Sent: Thursday, October 10, 2002 11:13 AM >To: ppvpn@ppvpn.francetelecom.com; sam@coronanetworks.com; >elwin@coronanetworks.com; benson.schliesser@savvis.net >Subject: questions on draft-ietf-ppvpn-vr-mib-02.txt > > >Hello, > >A few questions and comments on the MIB. > >1) Is the Internal Virtual Link used to connect to VRs in >the same PE, or is it a link between VRs in a different PEs? > >Elwin> It is for VRs in the same PE. > > >2) Is there a one to many relationship between the vrTunnelIpAddress >and the Virtual Routers? > >Elwin> One to many is possible for the cases of tunnels having a >Elwin> demultiplexing field. Is this field defined anywhere in PPVPN documents? If not, then please do not support this relationship in the MIB unless there is strong opinion from the WG. This is the sort of thing that can get standard MIBs in trouble for interoperability. >3) do you want any scalars to configure the number of VRs on > the device? > >Elwin> That will be nice to add. Knowing the number of active ones is always helpful instead of having to determine that from a MIB walk (especially if the number of VRs is large). >4) regarding VPN-ID, have you considered adding some sort of > mapping table to which is indexed by VPN-ID, VR? > > >Elwin> This could be for quick searching. Inverse VPN/VR table?? >Elwin> Sure...That sounds okay. Consider making the implementation of these tables optional and only the basic table mandatory. Sometimes mapping tables are nice to have, but they put an unnecessary burden on initial implementations that might want to just get the base objects implemented. >5) Having a TC called VrIndexOrZero which is like the above but > includes zero, where zero needs to be defined in the Description > Clause of the objects > > * for VrConfigNextAvailableVrId have zero mean that no more VRs > can be created. (for example, if the device is out of resources) > > * for vrId have zero mean that VR 0 is the NULL VR. > >Elwin> Good suggestion. > >6) Limit the vrName to fewer characters (32 is probably good, but > could be bigger. 255 seems quite large). This description > should probably say these names need to be unique within the table. 32 characters might not be long enough. Is there anything in the VR specification for this? If not, perhaps it should be added? Having the MIB guess on something like this could be a problem if the protocol later allows the use of a 33 character name. In the least, the variable should include a reference to a protocol/architecture specification justifying its size. >Elwin> agreed. > >7) vrAdminStatus: could testing be added here? > >Elwin> Sure. What does testing mean? Be specific if you can. >8) vrContextName - why is this a read-create and not a read-only? > >Elwin> This allows the user to specify the VR context, or community, >Elwin> for the particular VR being created. If it were read-only, this >Elwin> would mean the device is creating the context for the VR. > >9) vrType, not clear what this is, could more description be added? > >Elwin> This has to be removed. > >10) (minor) please change the vrStat to be vrStatus > >Elwin> will do. > >11) RouterId should this be 2 objects ( AddressType and Address ) > (as in the INET-ADDRESS-MIB). > >Elwin> good point. > >12) have you considered having the VrIfTable indexed by > vrId and vrIfIndex ? (seems like a VR would want to quickly > see all of its interfaces). > >Elwin> No, a VR is identified by the community string itself. >Elwin> We are suggesting managing multiple instances of the >Elwin> "VrIfTable" using a model similar to that described in RFC2571. This is not very standard and runs into all sorts of problems. For instance, how does one format the community string? What are the security implications? >13) vrUp/vrDown traps need to contain a varbind. The vrId is an index. > >Elwin> No, the vrId MAX-ACCESS is defined as accessible-for-notify. Why? You generally only use accessible-for-notify if you have an index that comes from another module that you want to include. In this case, it is beneficial to just include one of the objects from the table -- perhaps VrName -- that will implicitly include the index? Also, I strongly suggest adding a rate limiting value for notifications such as we have defined recently in the MPLS-TE MIB called mplsTunnelNotifMaxRate. --Tom Success is relative; the more success, the more relatives. -Anonymous From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 11 11:23:08 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 LAA23642 for ; Mon, 11 Nov 2002 11:23:07 -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 gABGP8B06044 for ; Mon, 11 Nov 2002 11:25:08 -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 gABGP1W25512 for ; Mon, 11 Nov 2002 11:25:01 -0500 (EST) Message-Id: <200211111622.gABGMFIX006885@sj-msg-core-1.cisco.com> To: Takeshi KUWAHARA cc: ppvpn@nortelnetworks.com, murayama.junichi@lab.ntt.co.jp, suzuki.muneyoshi@lab.ntt.co.jp, tanikawa.masaki@lab.ntt.co.jp Subject: Re: FW: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt In-reply-to: Your message of Mon, 11 Nov 2002 13:11:35 +0900. <5.0.2.7.2.20021111110422.03db4ec8@localhost> 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: Mon, 11 Nov 2002 11:22:15 -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@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: > +<-----DF > | > v > D<---(preferable route)<----S1<---+<---------S3 > | > +---------------------------S2 > In this case, when S2's route becomes the preferable route by some > reasons, the route from the DF to the site will be changed from DF->S1->D > to DF->S2->D by routing protocol, hence S1 will then sends a purge message > to S3. S1 sends a purge message to S3 because the DF's route to D has changed? How does S1 know that the DF's route to D has changed? In this example, D is "locally attached" to S1 (as well as to S2), so I don't see that S1 has any reason to send a purge. > Multiple hubs can be connected to form any type of topology. In this case, > routes between DF-DF, DF-PE and PE-PE are controlled by routing > protocols. Are you saying that when there are multiple hubs (or anything other than a strict hub and spoke topology), you don't use CTCP? For robustness, I'd think that every VPN would have at least two hubs. From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 11 14:47:49 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 OAA29102 for ; Mon, 11 Nov 2002 14:47:49 -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 gABJncB04034 for ; Mon, 11 Nov 2002 14:49:38 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gABJnZW24007 for ; Mon, 11 Nov 2002 14:49:35 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 11 Nov 2002 11:47:37 -0800 Message-ID: Thread-Topic: questions on draft-ietf-ppvpn-vr-mib-02.txt Thread-Index: AcKJlT1HQcm18KQJQlGZSM9Hnzs3aQAHHiGA From: "Sam Hancock" To: "Thomas D. Nadeau" , "Elwin Eliazer" Cc: , , X-SMTP-HELO: exch-srv.CoronaNetworks.com X-SMTP-MAIL-FROM: Sam@coronanetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [205.219.34.104] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA29102 Hello All, I added some comments for item 13. Cheers, Sam> -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Monday, November 11, 2002 7:17 AM To: Elwin Eliazer Cc: jcucchiara@mindspring.com; ppvpn@nortelnetworks.com; Sam Hancock; benson.schliesser@savvis.net Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt At 03:28 PM 10/15/2002 -0700, Elwin Eliazer wrote: >Hi Joan, > >Thanks for your very valid comments. >Excuse us for the delay in responding. >My responses are in-lined below. > >Cheers, >Elwin. > >-----Original Message----- >From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com] >Sent: Thursday, October 10, 2002 11:13 AM >To: ppvpn@ppvpn.francetelecom.com; sam@coronanetworks.com; >elwin@coronanetworks.com; benson.schliesser@savvis.net >Subject: questions on draft-ietf-ppvpn-vr-mib-02.txt > > >Hello, > >A few questions and comments on the MIB. > >1) Is the Internal Virtual Link used to connect to VRs in >the same PE, or is it a link between VRs in a different PEs? > >Elwin> It is for VRs in the same PE. > > >2) Is there a one to many relationship between the vrTunnelIpAddress >and the Virtual Routers? > >Elwin> One to many is possible for the cases of tunnels having a >Elwin> demultiplexing field. Is this field defined anywhere in PPVPN documents? If not, then please do not support this relationship in the MIB unless there is strong opinion from the WG. This is the sort of thing that can get standard MIBs in trouble for interoperability. >3) do you want any scalars to configure the number of VRs on > the device? > >Elwin> That will be nice to add. Knowing the number of active ones is always helpful instead of having to determine that from a MIB walk (especially if the number of VRs is large). >4) regarding VPN-ID, have you considered adding some sort of > mapping table to which is indexed by VPN-ID, VR? > > >Elwin> This could be for quick searching. Inverse VPN/VR table?? >Elwin> Sure...That sounds okay. Consider making the implementation of these tables optional and only the basic table mandatory. Sometimes mapping tables are nice to have, but they put an unnecessary burden on initial implementations that might want to just get the base objects implemented. >5) Having a TC called VrIndexOrZero which is like the above but > includes zero, where zero needs to be defined in the Description > Clause of the objects > > * for VrConfigNextAvailableVrId have zero mean that no more VRs > can be created. (for example, if the device is out of resources) > > * for vrId have zero mean that VR 0 is the NULL VR. > >Elwin> Good suggestion. > >6) Limit the vrName to fewer characters (32 is probably good, but > could be bigger. 255 seems quite large). This description > should probably say these names need to be unique within the table. 32 characters might not be long enough. Is there anything in the VR specification for this? If not, perhaps it should be added? Having the MIB guess on something like this could be a problem if the protocol later allows the use of a 33 character name. In the least, the variable should include a reference to a protocol/architecture specification justifying its size. >Elwin> agreed. > >7) vrAdminStatus: could testing be added here? > >Elwin> Sure. What does testing mean? Be specific if you can. >8) vrContextName - why is this a read-create and not a read-only? > >Elwin> This allows the user to specify the VR context, or community, >Elwin> for the particular VR being created. If it were read-only, this >Elwin> would mean the device is creating the context for the VR. > >9) vrType, not clear what this is, could more description be added? > >Elwin> This has to be removed. > >10) (minor) please change the vrStat to be vrStatus > >Elwin> will do. > >11) RouterId should this be 2 objects ( AddressType and Address ) > (as in the INET-ADDRESS-MIB). > >Elwin> good point. > >12) have you considered having the VrIfTable indexed by > vrId and vrIfIndex ? (seems like a VR would want to quickly > see all of its interfaces). > >Elwin> No, a VR is identified by the community string itself. >Elwin> We are suggesting managing multiple instances of the >Elwin> "VrIfTable" using a model similar to that described in RFC2571. This is not very standard and runs into all sorts of problems. For instance, how does one format the community string? What are the security implications? >13) vrUp/vrDown traps need to contain a varbind. The vrId is an index. > >Elwin> No, the vrId MAX-ACCESS is defined as accessible-for-notify. Why? You generally only use accessible-for-notify if you have an index that comes from another module that you want to include. In this case, it is beneficial to just include one of the objects from the table -- perhaps VrName -- that will implicitly include the index? [] Actually, the value "accessible-for-notify" indicates an object [] which is accessible only via a notification [RFC1902]. Since the [] vrName could be NULL, the vrId is more appropriate to include in [] the traps. Also, I strongly suggest adding a rate limiting value for notifications such as we have defined recently in the MPLS-TE MIB called mplsTunnelNotifMaxRate. [] Adding control for Rate limiting is a good idea. From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 11 15:01: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 PAA29426 for ; Mon, 11 Nov 2002 15:01:08 -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 gABK36B15246 for ; Mon, 11 Nov 2002 15:03: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 gABK33W24477 for ; Mon, 11 Nov 2002 15:03:03 -0500 (EST) Message-Id: <4.3.2.7.2.20021111150116.05872a00@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Nov 2002 15:02:15 -0500 To: "Sam Hancock" From: "Thomas D. Nadeau" Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt Cc: "Elwin Eliazer" , , , In-Reply-To: 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: At 11:47 AM 11/11/2002 -0800, Sam Hancock wrote: >Hello All, >I added some comments for item 13. >Cheers, >Sam> > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Monday, November 11, 2002 7:17 AM >To: Elwin Eliazer >Cc: jcucchiara@mindspring.com; ppvpn@nortelnetworks.com; Sam Hancock; >benson.schliesser@savvis.net >Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt > > >At 03:28 PM 10/15/2002 -0700, Elwin Eliazer wrote: > >Hi Joan, > > > >Thanks for your very valid comments. > >Excuse us for the delay in responding. > >My responses are in-lined below. > > > >Cheers, > >Elwin. > > > >-----Original Message----- > >From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com] > >Sent: Thursday, October 10, 2002 11:13 AM > >To: ppvpn@ppvpn.francetelecom.com; sam@coronanetworks.com; > >elwin@coronanetworks.com; benson.schliesser@savvis.net > >Subject: questions on draft-ietf-ppvpn-vr-mib-02.txt > > > > > >Hello, > > > >A few questions and comments on the MIB. > > > >1) Is the Internal Virtual Link used to connect to VRs in > >the same PE, or is it a link between VRs in a different PEs? > > > >Elwin> It is for VRs in the same PE. > > > > > >2) Is there a one to many relationship between the vrTunnelIpAddress > >and the Virtual Routers? > > > >Elwin> One to many is possible for the cases of tunnels having a > >Elwin> demultiplexing field. > > Is this field defined anywhere in PPVPN documents? If not, >then please do not support this relationship in the MIB unless >there is strong opinion from the WG. This is the sort of thing that >can get standard MIBs in trouble for interoperability. > > >3) do you want any scalars to configure the number of VRs on > > the device? > > > >Elwin> That will be nice to add. > > Knowing the number of active ones is always helpful instead >of having to determine that from a MIB walk (especially if the >number of VRs is large). > > >4) regarding VPN-ID, have you considered adding some sort of > > mapping table to which is indexed by VPN-ID, VR? > > > > > >Elwin> This could be for quick searching. Inverse VPN/VR table?? > >Elwin> Sure...That sounds okay. > > Consider making the implementation of these tables optional >and only the basic table mandatory. Sometimes mapping tables are >nice to have, but they put an unnecessary burden on initial implementations >that might want to just get the base objects implemented. > > >5) Having a TC called VrIndexOrZero which is like the above but > > includes zero, where zero needs to be defined in the Description > > Clause of the objects > > > > * for VrConfigNextAvailableVrId have zero mean that no more VRs > > can be created. (for example, if the device is out of resources) > > > > * for vrId have zero mean that VR 0 is the NULL VR. > > > >Elwin> Good suggestion. > > > >6) Limit the vrName to fewer characters (32 is probably good, but > > could be bigger. 255 seems quite large). This description > > should probably say these names need to be unique within the table. > > 32 characters might not be long enough. Is there anything >in the VR specification for this? If not, perhaps it should be >added? Having the MIB guess on something like this could be >a problem if the protocol later allows the use of a 33 character >name. In the least, the variable should include a reference to >a protocol/architecture specification justifying its size. > > >Elwin> agreed. > > > >7) vrAdminStatus: could testing be added here? > > > >Elwin> Sure. > > What does testing mean? Be specific if you can. > > >8) vrContextName - why is this a read-create and not a read-only? > > > >Elwin> This allows the user to specify the VR context, or community, > >Elwin> for the particular VR being created. If it were read-only, this > >Elwin> would mean the device is creating the context for the VR. > > > >9) vrType, not clear what this is, could more description be added? > > > >Elwin> This has to be removed. > > > >10) (minor) please change the vrStat to be vrStatus > > > >Elwin> will do. > > > >11) RouterId should this be 2 objects ( AddressType and Address ) > > (as in the INET-ADDRESS-MIB). > > > >Elwin> good point. > > > >12) have you considered having the VrIfTable indexed by > > vrId and vrIfIndex ? (seems like a VR would want to quickly > > see all of its interfaces). > > > >Elwin> No, a VR is identified by the community string itself. > >Elwin> We are suggesting managing multiple instances of the > >Elwin> "VrIfTable" using a model similar to that described in RFC2571. > > This is not very standard and runs into all sorts of problems. >For instance, how does one format the community string? What >are the security implications? > > >13) vrUp/vrDown traps need to contain a varbind. The vrId is an index. > > > >Elwin> No, the vrId MAX-ACCESS is defined as accessible-for-notify. > > Why? You generally only use accessible-for-notify if you >have an index that comes from another module that you want to >include. In this case, it is beneficial to just include one of the >objects from the table -- perhaps VrName -- that will implicitly >include the index? >[] Actually, the value "accessible-for-notify" indicates an object >[] which is accessible only via a notification [RFC1902]. Since the >[] vrName could be NULL, the vrId is more appropriate to include in >[] the traps. I understand the meaning of accessible-for-notify. It is generally a better idea to not use it in cases where you can just send an object in the varbind that has additional information, since the same index is also transmitted in the varbind. --Tom >Also, I strongly suggest adding a rate limiting >value for notifications such as we have defined recently in the >MPLS-TE MIB called mplsTunnelNotifMaxRate. > >[] Adding control for Rate limiting is a good idea. Success is relative; the more success, the more relatives. -Anonymous From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 11 15:16:24 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 PAA29885 for ; Mon, 11 Nov 2002 15:16:23 -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 gABKINB23470 for ; Mon, 11 Nov 2002 15:18: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 gABKIKW07169 for ; Mon, 11 Nov 2002 15:18:20 -0500 (EST) Message-Id: <200211112014.gABKECIX010167@sj-msg-core-1.cisco.com> To: asodder@tenornetworks.com cc: ppvpn@lyris.nortelnetworks.com Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt In-reply-to: Your message of Tue, 22 Oct 2002 21:00:54 -0400. <00fb01c27a2f$a65e3a80$d303a8c0@tenornet.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Nov 2002 15:14:11 -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: In your proposal, you still require the mesh of LDP connections. However, rather than having a PE dynamically assign one label for each emulated LAN instance it supports, it assigns one label meaning "emulated LAN service". Then the packets sent across the network need to carry that label, and also a globally unique VPN-id to identify a particular emulated LAN instance. So let's compare the overhead of your proposal to the existing proposal: - Same number of LDP connections. - Fewer LDP messages sent and received at startup time. - Same number of labels need to be looked up (i.e., no savings on size of lookup table) - Data packets have to carry one more label. Further, either that label has to be long enough to be a really globally unique VPN-id (i.e., 64 bits), or else there is a manageability problem. - That extra label has to be looked up, for each data packet, by the egress PE. Further, as this label is a different type of label, this requires additional lookup logic, which means the forwarding path is made more complex. So for a modest savings in messages to process at startup time, you increase the per-packet overhead and you complicate the forwarding path. This just doesn't seem like a good tradeoff to me. Further one also needs to examine the implicit claim that per-VPLS signaling has no task other than to assign labels. If you look at draft-ietf-pwe3- control-protocol-01.txt, you will see that it does other things than assign labels, such as allowing sequence number synchronization, allowing MTU checks, allowing passing of status information, etc. From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 11 15:18:50 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 PAA29994 for ; Mon, 11 Nov 2002 15:18:49 -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 gABKKmB24494 for ; Mon, 11 Nov 2002 15:20: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 gABKKiW09105 for ; Mon, 11 Nov 2002 15:20:45 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 11 Nov 2002 12:18:31 -0800 Message-ID: Thread-Topic: questions on draft-ietf-ppvpn-vr-mib-02.txt Thread-Index: AcKJvR2KwNr6g0EFT92Gfswz8PKKxgAAiWZQ From: "Sam Hancock" To: "Thomas D. Nadeau" Cc: "Elwin Eliazer" , , , X-SMTP-HELO: exch-srv.CoronaNetworks.com X-SMTP-MAIL-FROM: Sam@coronanetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [205.219.34.104] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA29994 > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, November 11, 2002 12:02 PM > To: Sam Hancock > Cc: Elwin Eliazer; jcucchiara@mindspring.com; > ppvpn@nortelnetworks.com; > benson.schliesser@savvis.net > Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt > > > At 11:47 AM 11/11/2002 -0800, Sam Hancock wrote: > >Hello All, > >I added some comments for item 13. > >Cheers, > >Sam> > > > >-----Original Message----- > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >Sent: Monday, November 11, 2002 7:17 AM > >To: Elwin Eliazer > >Cc: jcucchiara@mindspring.com; ppvpn@nortelnetworks.com; Sam Hancock; > >benson.schliesser@savvis.net > >Subject: RE: questions on draft-ietf-ppvpn-vr-mib-02.txt > > > > > >At 03:28 PM 10/15/2002 -0700, Elwin Eliazer wrote: > > >Hi Joan, > > > > > >Thanks for your very valid comments. > > >Excuse us for the delay in responding. > > >My responses are in-lined below. > > > > > >Cheers, > > >Elwin. > > > > > >-----Original Message----- > > >From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com] > > >Sent: Thursday, October 10, 2002 11:13 AM > > >To: ppvpn@ppvpn.francetelecom.com; sam@coronanetworks.com; > > >elwin@coronanetworks.com; benson.schliesser@savvis.net > > >Subject: questions on draft-ietf-ppvpn-vr-mib-02.txt > > > > > > > > >Hello, > > > > > >A few questions and comments on the MIB. > > > > > >1) Is the Internal Virtual Link used to connect to VRs in > > >the same PE, or is it a link between VRs in a different PEs? > > > > > >Elwin> It is for VRs in the same PE. > > > > > > > > >2) Is there a one to many relationship between the > vrTunnelIpAddress > > >and the Virtual Routers? > > > > > >Elwin> One to many is possible for the cases of tunnels having a > > >Elwin> demultiplexing field. > > > > Is this field defined anywhere in PPVPN documents? If not, > >then please do not support this relationship in the MIB unless > >there is strong opinion from the WG. This is the sort of thing that > >can get standard MIBs in trouble for interoperability. > > > > >3) do you want any scalars to configure the number of VRs on > > > the device? > > > > > >Elwin> That will be nice to add. > > > > Knowing the number of active ones is always helpful instead > >of having to determine that from a MIB walk (especially if the > >number of VRs is large). > > > > >4) regarding VPN-ID, have you considered adding some sort of > > > mapping table to which is indexed by VPN-ID, VR? > > > > > > > > >Elwin> This could be for quick searching. Inverse VPN/VR table?? > > >Elwin> Sure...That sounds okay. > > > > Consider making the implementation of these tables optional > >and only the basic table mandatory. Sometimes mapping tables are > >nice to have, but they put an unnecessary burden on initial > implementations > >that might want to just get the base objects implemented. > > > > >5) Having a TC called VrIndexOrZero which is like the above but > > > includes zero, where zero needs to be defined in the > Description > > > Clause of the objects > > > > > > * for VrConfigNextAvailableVrId have zero mean that > no more VRs > > > can be created. (for example, if the device is out > of resources) > > > > > > * for vrId have zero mean that VR 0 is the NULL VR. > > > > > >Elwin> Good suggestion. > > > > > >6) Limit the vrName to fewer characters (32 is probably good, but > > > could be bigger. 255 seems quite large). This description > > > should probably say these names need to be unique > within the table. > > > > 32 characters might not be long enough. Is there anything > >in the VR specification for this? If not, perhaps it should be > >added? Having the MIB guess on something like this could be > >a problem if the protocol later allows the use of a 33 character > >name. In the least, the variable should include a reference to > >a protocol/architecture specification justifying its size. > > > > >Elwin> agreed. > > > > > >7) vrAdminStatus: could testing be added here? > > > > > >Elwin> Sure. > > > > What does testing mean? Be specific if you can. > > > > >8) vrContextName - why is this a read-create and not a read-only? > > > > > >Elwin> This allows the user to specify the VR context, or > community, > > >Elwin> for the particular VR being created. If it were > read-only, this > > >Elwin> would mean the device is creating the context for the VR. > > > > > >9) vrType, not clear what this is, could more description be added? > > > > > >Elwin> This has to be removed. > > > > > >10) (minor) please change the vrStat to be vrStatus > > > > > >Elwin> will do. > > > > > >11) RouterId should this be 2 objects ( AddressType and Address ) > > > (as in the INET-ADDRESS-MIB). > > > > > >Elwin> good point. > > > > > >12) have you considered having the VrIfTable indexed by > > > vrId and vrIfIndex ? (seems like a VR would want to quickly > > > see all of its interfaces). > > > > > >Elwin> No, a VR is identified by the community string itself. > > >Elwin> We are suggesting managing multiple instances of the > > >Elwin> "VrIfTable" using a model similar to that described > in RFC2571. > > > > This is not very standard and runs into all sorts > of problems. > >For instance, how does one format the community string? What > >are the security implications? > > > > >13) vrUp/vrDown traps need to contain a varbind. The vrId > is an index. > > > > > >Elwin> No, the vrId MAX-ACCESS is defined as accessible-for-notify. > > > > Why? You generally only use accessible-for-notify if you > >have an index that comes from another module that you want to > >include. In this case, it is beneficial to just include one of the > >objects from the table -- perhaps VrName -- that will implicitly > >include the index? > >[] Actually, the value "accessible-for-notify" > indicates an object > >[] which is accessible only via a notification > [RFC1902]. Since the > >[] vrName could be NULL, the vrId is more appropriate > to include in > >[] the traps. > > I understand the meaning of accessible-for-notify. It is > generally a better idea to not use it in cases where you can > just send an object in the varbind that has additional information, > since the same index is also transmitted in the varbind. > > --Tom [] This is a good point. Even if the vrName were NULL, [] the vrId would be implicitly transmitted in the varbind. [] Therefore, using vrName is a better option than using vrId. > > > >Also, I strongly suggest adding a rate limiting > >value for notifications such as we have defined recently in the > >MPLS-TE MIB called mplsTunnelNotifMaxRate. > > > >[] Adding control for Rate limiting is a good idea. > > Success is relative; the more success, the more relatives. -Anonymous > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 12 06:38: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 GAA27749 for ; Tue, 12 Nov 2002 06:38: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 gACBdpp25511 for ; Tue, 12 Nov 2002 06:39:51 -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 gACBdmS06490 for ; Tue, 12 Nov 2002 06:39:48 -0500 (EST) Message-Id: <5.0.2.7.2.20021112192739.04a35ec8@localhost> X-Sender: tk019/imd.m.ecl.ntt.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Tue, 12 Nov 2002 20:37:08 +0900 To: erosen@cisco.com, ppvpn@nortelnetworks.com From: Takeshi KUWAHARA Subject: Re: FW: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Cc: murayama.junichi@lab.ntt.co.jp, tanikawa.masaki@lab.ntt.co.jp, suzuki.muneyoshi@lab.ntt.co.jp, kuwahara.takeshi@lab.ntt.co.jp In-Reply-To: <200211111622.gABGMFIX006885@sj-msg-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: kuwahara.takeshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Dear Eric, At 11:22 02/11/11 -0500, you wrote: > > +<-----DF > > | > > v > > D<---(preferable route)<----S1<---+<---------S3 > > | > > +---------------------------S2 > > > In this case, when S2's route becomes the preferable route by some > > reasons, the route from the DF to the site will be changed from DF->S1->D > > to DF->S2->D by routing protocol, hence S1 will then sends a purge message > > to S3. > >S1 sends a purge message to S3 because the DF's route to D has changed? How >does S1 know that the DF's route to D has changed? > >In this example, D is "locally attached" to S1 (as well as to S2), so I >don't see that S1 has any reason to send a purge. In the case of link failure between S1 and D, S1's route to D will be changed to S1->DF->S2->D by the routing protocol. Then, S1 will send a purge message to S3 when it receives packets from S3 to D. Consequently, the route from S3 to D will then be changed to S3->DF->S2->D, and by the redirection message from DF to S3, it will finally be changed to S3->S2->D. It is difficult to control the packet from S3 to D dynamically by the DF so as to load balance between two routes S3->S1->D and S3->S2->D. To solve this issue, one can be managed by ether not letting the DF to send a redirection message for the packets destined for D or operating a routing protocol to set S1-S3 and S2-S3 as routing peers. Therefore, we think CTCP does not restrict the network topology. > > Multiple hubs can be connected to form any type of topology. In this case, > > routes between DF-DF, DF-PE and PE-PE are controlled by routing > > protocols. > >Are you saying that when there are multiple hubs (or anything other than a >strict hub and spoke topology), you don't use CTCP? For robustness, I'd >think that every VPN would have at least two hubs. CTCP can be applied to the topology of multiple hubs. When there are multiple hubs, a spoke is able to choose an appropriate hub to send packets by the routing protocol operated among multiple hubs and spokes. So, it is possible to change the next hop to the backup hubs in the case of failures. Regards, Takeshi Kuwahara. From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 12 08:23: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 IAA29813 for ; Tue, 12 Nov 2002 08:23:50 -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 gACDPfp11085 for ; Tue, 12 Nov 2002 08:25: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 gACDPbS21382 for ; Tue, 12 Nov 2002 08:25:38 -0500 (EST) Message-Id: <5.1.0.14.0.20021112081107.02842eb0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 08:21:51 -0500 To: ppvpn@nortelnetworks.com From: "Joel M. Halpern" Subject: Re: FW: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt In-Reply-To: <5.0.2.7.2.20021112192739.04a35ec8@localhost> References: <200211111622.gABGMFIX006885@sj-msg-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: EXECDSL.COM X-SMTP-MAIL-FROM: joel@stevecrocker.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ns.execdsl.net [208.184.15.238] X-LYRIS-Message-Id: There are two cases recognized in your document. In one case, you require a full mesh abong all PE devices, and do not use CTCP. This is roughly similar to many other tunnel protoocols. However, the primary focus of your document is CTCP. The use of CTCP places very specific restrictions on the operator(s) VPN support topology. All cut-through creation messages are generated by DF. In order to generate them, the DF must have received the message directly from a PE device, and be forwarding the message directly to a PE device. Therefore, in order to function, all PE devices must be exchanging routing information with each DF. Yes, you can have multiple DFs for load sharing of packet forwarding activity. However, it that case they ALL must have routing exchanges with ALL PEs in the VPN. And all PEs in the VPN must know about and deliver routing to ALL the DFs. Note that this requirement for complete coverage applies to all PEs in the VPN across all providers. The necessity for such topology restrictions, including the additional restrictions that DF entities MUST be distinct from PE entities, is driven by the fact that as shown in the earlier IETF work on cut-through, without such restrictions it is extremely difficult to avoid inducing loops and black holes when using cut-through protocols. You could try to claim that by creating separate groups, with PE devices forwarding from one group to another, you can get multiple hub and spoke clusters. There are quite a number of interesting topological constraints you would have to your document in order to make this work. Even determining how such a PE would know which cluster to forward packets to is quite complex and beyond what is described in your document. Note also that you describe the control exchange between the DF and PE devices as if it were a normal routing instance. While not a very complicated exchange, it is certainly different from any existing exchange. For the DF receiving the advertisements from the PEs, it must learn the reachability and associate it with the IPv6 soure (a minor tweak). However, the DF should not advertise reachability to other DFs or to the PEs. PEs must ignore any reachability information they get from the DFs since the nature of the protocol requires that all packets from the custoemr site are forwarded to the DF, and packets from the provider are checked against customer learned routing only for forwarding. Yours, Joel M. Halpern At 08:37 PM 11/12/2002 +0900, Takeshi KUWAHARA wrote: >Therefore, we think CTCP does not restrict the network topology. > >> > Multiple hubs can be connected to form any type of topology. In this case, >> > routes between DF-DF, DF-PE and PE-PE are controlled by routing >> > protocols. >> >>Are you saying that when there are multiple hubs (or anything other than a >>strict hub and spoke topology), you don't use CTCP? For robustness, I'd >>think that every VPN would have at least two hubs. > >CTCP can be applied to the topology of multiple hubs. >When there are multiple hubs, a spoke is able to choose an appropriate hub to >send packets by the routing protocol operated among multiple hubs and spokes. >So, it is possible to change the next hop to the backup hubs in the case of >failures. > >Regards, >Takeshi Kuwahara. From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 12 11:47:03 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 LAA06022 for ; Tue, 12 Nov 2002 11:47:03 -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 gACGmxk08822 for ; Tue, 12 Nov 2002 11:48: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 gACGmtS16358 for ; Tue, 12 Nov 2002 11:48:56 -0500 (EST) Date: Tue, 12 Nov 2002 11:29:36 -0500 From: Ron Bonica Subject: RE: draft-behringer-mpls-vpn-auth-00 In-reply-to: <4.3.2.7.2.20021107181131.02c00840@madrid.cisco.com> To: "Michael H. Behringer" , PPVPN@NORTELNETWORKS.COM Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: pmesmtp01.wcom.com X-SMTP-MAIL-FROM: Ronald.P.Bonica@wcom.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: pmesmtp01.wcom.com [199.249.20.1] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mike, There are at least two ways that you could do this. One approach, which I think that you are suggesting, is to put an old key and a new key on the key chain. Another approach, which I think that Eric Gray is suggesting, is to have many keys on the key chain, with each key destined for one or more remote PEs. (Guys, did I get this much right? If not, the rest of this posting won't make much sense.) Within the first approach, there are at least two possible implementations: 1) Immediately, upon configuration of the new key, distribute all routes into the iBGP mesh with both keys advertised 2) Don't advertise the new key into the iBGP mesh until all PE's have been configured with the new key. When all PE's have been configured with the new key, visit each PE, refreshing the PE-CE peering. This will cause all routes to be readvertised into the iBGP mesh with the new key (only). I am a little confused about how each approach would work if the provider network used route reflectors. Could somebody fill in the blanks? Ron > -----Original Message----- > From: Michael H. Behringer [mailto:mbehring@cisco.com] > Sent: Thursday, November 07, 2002 1:16 PM > To: Ron Bonica; PPVPN@NORTELNETWORKS.COM > Subject: RE: draft-behringer-mpls-vpn-auth-00 > > > At 17:08 07/11/2002, Ron Bonica wrote: > > > >3) Customers who MD5 authenticate BGP peering sessions may > want to change > > > >the MD5 key periodically. This isn't too painful if you don't > > > have to change > > > >all of the keys at once. It is impossible if the customer has > > > many hundreds > > > >of sites and you need to change all of the keys at once. > > > > > > One way of handling this is key-chains and soft roll-over, as > it exists > > > today for IS-IS and OSPF for example. > > > >How would this work? > > Ron, > > For using routing authentication on IGPs such as ISIS, OSPF, it would be > impossible to change all keys at the same time. So one defines a > key chain, > which contains the old key, and the new key. The algorithm > basically checks > both keys. Once you have rolled over to the new keys, you remove the old > ones from the key chain. > > Michael > From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 12 13:03: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 NAA08543 for ; Tue, 12 Nov 2002 13:03: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 gACI4ak28352 for ; Tue, 12 Nov 2002 13:04: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 gACI4XS04483 for ; Tue, 12 Nov 2002 13:04:33 -0500 (EST) Message-Id: <200211121802.gACI2GIX015573@sj-msg-core-1.cisco.com> To: Takeshi KUWAHARA cc: ppvpn@nortelnetworks.com, murayama.junichi@lab.ntt.co.jp, tanikawa.masaki@lab.ntt.co.jp, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: FW: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt In-reply-to: Your message of Tue, 12 Nov 2002 20:37:08 +0900. <5.0.2.7.2.20021112192739.04a35ec8@localhost> 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, 12 Nov 2002 13:02:16 -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@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: > In the case of link failure between S1 and D, S1's route to D will be > changed to S1->DF->S2->D by the routing protocol. I don't believe I mentioned "link failure" in my example. > It is difficult to control the packet from S3 to D dynamically by the DF > so as to load balance between two routes S3->S1->D and S3->S2->D. To solve > this issue, one can be managed by ether not letting the DF to send a > redirection message for the packets destined for D or operating a routing > protocol to set S1-S3 and S2-S3 as routing peers. Well, sure, you can always turn CTCP off. > Therefore, we think CTCP does not restrict the network topology. The fact that you can turn CTCP off doesn't mean that it doesn't restrict the network topology. > CTCP can be applied to the topology of multiple hubs. When there are > multiple hubs, a spoke is able to choose an appropriate hub to send > packets by the routing protocol operated among multiple hubs and spokes. > So, it is possible to change the next hop to the backup hubs in the case > of failures. Now you are suggesting to run both CTCP and a "routing protocol operated among multiple hubs and spokes"? I don't understand at all how that would work. During a routing transient you could get two hubs independently redirecting the spokes, and the routing might never converge. From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 03:37: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 DAA24744 for ; Wed, 13 Nov 2002 03:37:40 -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 gAD8cbk23921 for ; Wed, 13 Nov 2002 03:38:38 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gAD8cY017043 for ; Wed, 13 Nov 2002 03:38:35 -0500 (EST) Date: Wed, 13 Nov 2002 16:38:12 +0800 From: Miao Fuyou Subject: =?gb2312?B?UkU6ILTwuLQ6ILTwuLQ6ILTwuLQ6IFBsZWFzZSBSZXZpZXc6IEEgbg==?= =?gb2312?B?ZXcgZHJhZnQgYWJvdXQgUFBWUE4oSGliZXJhcmNoeSBvZiBQRSBEZQ==?= =?gb2312?B?dmljZSBpbkJHUC9NUExTIFZQTik=?= In-reply-to: To: "'Jim Guichard'" , =?gb2312?B?Jz+h7D+oqD8/oaeh6D+h7D8n?= Cc: ppvpn@nortelnetworks.com Message-id: <000001c28af0$011913c0$2e426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: miaofy@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA24744 Hi, Jim: As per my understanding, your primary concern is routes. Actually the problem is very similiar to the one in H&S topology, in which VPN network views are not available at spoke site. Sure, the sites connected by HoPE have not whole view of network, but the question is: really the customer want to know that? Anyway, for L3VPN, routing is an add-value service provided by SP to customer. Sometimes customer concerns VPN topology, however, such function/service can be provided by Customer Network Management, which is more convinient to customer. Note that HoPE works under specific network environment to meet specific requirement, it's not cure-all. However, it's happy to find that most network are planned and setup with a hierachical topology, and where HoPE can works best. Regard Miao -----Original Message----- From: Jim Guichard [mailto:jguichar@cisco.com] Sent: Monday, November 11, 2002 9:39 PM To: Miao Fuyou; '?¡ì?¨¨??¡§¡è?¡ì?' Cc: ppvpn@nortelnetworks.com Subject: RE: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) Hi Miao, > >-----Original Message----- > >From: Miao Fuyou [mailto:miaofy@huawei.com] > >Sent: Saturday, November 09, 2002 4:01 AM > >To: 'Jim Guichard'; '¡§¡è??¨¤¡§?' > >Cc: ppvpn@nortelnetworks.com > >Subject: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > > > > > > > >Hi, Jim: > > > >Please find my commnets inline! > > > >Regards > >-----ÓʼþÔ­¼þ----- > >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 23:29 > >ÊÕ¼þÈË: ???¡ê¨®?; '¡§¡è??¨¤¡§?' > >³­ËÍ: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; > >leh10814@huawei.com > >Ö÷Ìâ: RE: ´ð¸´: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy > >of PE Device inBGP/MPLS VPN) > > > > > >Hi Miao, > > > >I understand that this is not a replacement to 2547. I also > >understand that hierarchy is one of the tools we have to help scale > >networks. However, what I am driving at is that 2547 provides all of > >the necessary mechanisms already to run this type of topology - > >deployment of 2547 is a matter of design and no new functionality is > >necessary to be able to run the topology you are suggesting. We have > >many deployments worldwide that already use this type of design to > >provide central services to their customers. This does not mean > >however that the topology is appropriate for all 2547 customers. > >There are a number of issues with the proposed topology that one > >might consider: > > > >Miao: Actually it's not a problem of topology, it's for the planning > >and design of the network. If 2547 alone can work under for every > >network and meet all the VPN requirement, why were VPLS, Martini VPN, > >Kompella VPN and many others proposed? well VPLS, Martini and Kompella are talking about layer-2 application - we are talking about layer-3 here which is a little different wouldn't you agree ? > > > >1. In most real world deployments the number of hops between UPE and > >SPE will be > 1. This may introduce unacceptable latency and so on, > >especially as the design is being used for transit traffic rather > >than central services. > > > >Miao: I don't think hops > 1 brings more latency if a packet must go > >from an ingress PE to an egress PE. Actually it follows almost the > >same route that 2547 one will do if the network is not very careless > >designed. well I think it is fair to say that if you attract traffic to a particular point of the network then the optimal path from an routing perspective is more likely to be overlooked - this is not always the case but you cannot assume in an architecture that all networks are built the same. > > > >2. Using this method introduces additional IP address lookups between > >ingress PE and egress PE, plus label disposition/imposition. > > > >Miao: It's a ONCE-FOR-ALL work for a site, so the effort is trivial maybe I misunderstood your description but if the hub has to route inter-site traffic then we must remove the label stack, look at the IP address and then send it back on its way - this is a per-packet exercise not per-site. > > > >3. Unless the SPE is located locally to the UPE then the regional VPN > >traffic will be concentrated toward certain points of the network, > >instead of being distributed across the whole infrastructure. > > > >Miao: UPE can process it locally in such case, no SPE involved how can it if it does not have the routes ? if it has the routes then we have 2547 no ? > > > >4. If the SPE is located locally, then aggregates can be injected > >down to the UPEs but this is assuming that the address space is > >designed in such a way as to allow this aggregation. Most Enterprise > >networks today do not have such a well structured addressing plan. > > > >Miao: Refer item 3 so item 3 says there is no aggregation and the scheme is rendered useless. > > > >5. By injecting aggregates toward the CE site you change the > >customers routing view which may actually require the injection of > >more specific routes. > > > >Miao: No aggretes injected in HoPE actually well if it is just default route the same comment applies and is actually even worse. > > > >6. The SP has to keep track of the aggregation and configure it > >appropriately at the SPE. > > > >Miao: SPE will do how ? there are many ways to generate such an aggregate, each of which have their own implications. > > > >7. How do you take care of customers that want to run OSPF or ISIS on > >the PE-CE links ? how would sham-links work for example ? > > > >Miao: Only default route is needed in HoPE at PE-CE links, so why to > >run OSPF & IS-IS? default is not sufficient for most customers - a large subset of Internet customers today want more than just default route. OSPF, ISIS, EIGRP and so on were introduced so as to avoid changing the routing view of the end customers - this is a desired requirement that HoPE does not service. > > > >8. To deploy H&S designs one must use different RTs for the same VPN > >and then apply policy to filter correctly. This may not be such a big > >deal but is a further complication in the provisioning and management > >process. > > > >Miao: Repeat, it's not a problem of topology, not to say H&S > > > >9. If our goal is to offload the edge routers from having to carry > >VPNv4 routes or run MP-BGP sessions then perhaps we should use the > >L2-transport functionality in MPLS to carry the edge traffic to an > >SPE. This has the advantage that the CE can exchange routes directly > >with the SPE which is useful for other applications. > > > >Miao: L2-transport is not always applicable. CEs don't always run > >MPLS. CEs do not need to run MPLS to run L2-transport - the PEs do the L2-transport. > > > >10. How do you take care of customers that want to run Carrier's > >Carrier architecture ? > > > >Miao: But, what is the problem? the problem is that you cannot run an end-to-end LSP to allow this type of architecture to work .. regards, > > > > > >regards, > > > > > >> >-----Original Message----- > >> >From: Ã縣ÓÑ [mailto:miaofy@huawei.com] > >> >Sent: Thursday, November 07, 2002 9:07 PM > >> >To: 'Jim Guichard'; '¨¤?¡À¨®' > >> >Cc: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; > >> >leh10814@huawei.com > >> >Subject: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of > >> >PE Device inBGP/MPLS VPN) > >> > > >> > > >> >Hi, Jim: > >> > > >> >This draft is not to replace 2547, but a supplement to it. > >> >Actually the VPN in the draft is completely works under the > >> >mechanism of 2547. > >> > > >> >In the traditional 2547 VPN, only one type of PE is defined. When > >> >deployment, PE will not has so many ports to attach many VPNs if > >> >the PE is at the core layer of the network, because core router > >> >generally > > > >> >doesn't have a lot of physically interfaces. If the PE is at the > >> >edge of the network, it will have a lot of interfaces, but now the > >> >botlleneck is capacity of computation of the router. > >> > > >> >This draft is to solve the problem, UPE will provide abundant > >> >interface to conenct sites to VPN and SPE will have enough > >> >CPU/Memory > > > >> >to process routes. > >> > > >> >Regards > >> >Miao > >> > > >> >-----ÓʼþÔ­¼þ----- > >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 > >> >ÊÕ¼þÈË: ¨¤?¡À¨® > >> >³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco Carugi; > >> >sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; > >> >ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; > >> >changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com > >> >Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of > >PE > >> >Device inBGP/MPLS VPN) > >> > > >> > > >> >so can hub&spoke with 2547 - you basically export routes from the > >> >CE-attached PEs to a hub PE that imports the routes. The hub PE > >> >exports either a default or aggregates to attract traffic from > >> >other CE-attached PEs and then performs a lookup to forward the > >> >packets to other CE-attached PEs .. Jim > >> > > >> >> >-----Original Message----- > >> >> >From: Àî±ó [mailto:l.b@huawei.com] > >> >> >Sent: Thursday, November 07, 2002 2:42 AM > >> >> >To: Jim Guichard > >> >> >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >> >> >marco.carugi@nortelnetworks.com; sob@harvard.edu; > >> >> >bwijnen@lucent.com; > >> > > >> >> >zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; > >> >> >Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >> >> >leh10814@huawei.com > >> >> >Subject: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy > >of > >> >PE > >> >> >Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> >Hi, Guichard > >> >> >The hub & spoke is the relationship between CEs, but SPE peer > >> >> >with > > > >> >> >UPE by MP-BGP, they are all PEs, and they all can admit VPN > >> >> >user. > >> >> > > >> >> >Libin > >> >> > > >> >> >-----ԭʼÓʼþ----- > >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >> >> >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >> >> >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >> >> >Miao; leh10814@huawei. com; l.b@huawei.com > >> >> >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE > >> >> >Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> >I briefly ran through this draft and it looks like normal hub & > >> >> >spoke > >> > > >> >> >using existing 2547 mechanisms - could you explain how this > >> >> >differs ? > >> > > >> >> >thanks, > >> >> > > >> >> >> >-----Original Message----- > >> >> >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >> >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >> >> >To: internet-drafts@ietf.org > >> >> >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >> >> >> >Miao; > >> > > >> >> >> >leh10814@huawei.com; l.b@huawei.com > >> >> >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy > >> >> >> >of PE Device in BGP/MPLS VPN) > >> >> >> > > >> >> >> > > >> >> >> >Hi,all, > >> >> >> > > >> >> >> > In BGP/MPLS VPN area, we proposed a new idea as to > >> >> >> >resolve the bottleneck of the capacity of some PEs when > >> >> >> >deploy the huge > > > >> >> >> >size VPN,the > >> >> >whole idea is > >> >> >> >detailed > >> >> >> >in the attached > >> >> >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >> >> >> >Abstract is as follows,we are appreciated for your review. > >> >> >> > > >> >> >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >> >> >Edge)Device should > >> >> >> > maintain all the VPN routes of the VPNs which it belong > >> >> >to.When there > >> >> >> > are many VPNs converged by a PE,and the capacity of PE is > >> >relevant > >> >> >> > limited,then the bottleneck will be encountered.Another > >> >> >> > problem > >> >is > >> >> >> > that the current BGP/MPLS VPN model is something of a > >> >> >> > "Plane > >> >Modle" > >> >> >> > where the demand of the performance of the PE device are > >> >> >> > all > >> >the > >> >> >> > same no matter which layer the PE device is belongs > >> >> >> > to.However, > >> >the > >> >> >> > typical network is "Core-Convergence-Access(Edge)" > >> >> >> > model,and > >> >the > >> >> >> > performance of the device is superior in Core Layer and > >> >inferior in > >> >> >> > Access Layer,and the scale of network is large in Access > >> >> >> > Layer > >> >and > >> >> >> > small in Core Layer,the routes are converged in every > >> >> >> > layer,so > >> >in > >> >> >> > current "Plane Modle",when PE device push to the edge > >> >> >> > layer,it > >> >has > >> >> >> > to maintain more VPN routes,this makes it difficult to > >> >> >extend the PE > >> >> >> > device to edge layer.This document defines an model of > >> >> >hiberarchy of > >> >> >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of > >> >Provider > >> >> >> > Edge Device can be composed of several device and every > >> >> >> > device > >> >take > >> >> >> > on the different part,partake the function of the former > >> >> >> > concentrative PE,we call this model "Hiberarchy Model",In > >> >> >this model > >> >> >> > the demand of performance in Routing and Switching is > >> >> >> > strict > > > >> >> >> > to > >> >the > >> >> >> > PE device in High layer,loose to the PE device in edge > >> >> >> > layer. > >> >> >> > > >> >> >> > One HoPE can be composed of a SPE and UPES connected to > >> >> >> > the > >> >SPE, > >> >> >> > or be composed of a high-level SPE and HoPEs connected > >> >> >> > the > >high > >> >> >> > level SPE and and build up a new HoPE.This build is > >> >> >> > called > >> >nesting > >> >> >> > of HoPE,and this kind of nesting can be done for many > >> >> >times.Thus the > >> >> >> > former HoPE connect to the high-level SPE as a role of > >> >> >> > UPE,and > >> >the > >> >> >> > new HoPE can connect a single UPE too. > >> >> >> > > >> >> >> >Regards > >> >> >> > > >> >> >> >Defeng Li > >> >> >> > > >> > > >> > From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 12:00: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 MAA08440 for ; Wed, 13 Nov 2002 12:00:32 -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 gADH2Ik29765 for ; Wed, 13 Nov 2002 12:02:18 -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 gADH2F005800 for ; Wed, 13 Nov 2002 12:02:15 -0500 (EST) Message-Id: <200211131657.gADGvmS77400@merlot.juniper.net> To: "Marco Carugi" cc: "'ppvpn@nortelnetworks.com'" Subject: Re: Your comments on 3 possible new PPVPN WG documents In-Reply-To: Your message of "Sun, 10 Nov 2002 22:02:21 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52897.1037206668.1@juniper.net> Date: Wed, 13 Nov 2002 08:57:48 -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, > > I'd like to have your comments on the list about 3 drafts before Atlanta > meeting. > The intention is to move them to WG document status asap (note this is in > line with what discussed in Yokohama) and I'd like to see if still and which > are your major concerns. > Hopefully, it will be possible to officialise something at the Atlanta > meeting. > > Thanks, Marco > > - Generic Requirements for Provider Provisioned VPN : > draft-nagarajan-ppvpn-generic-reqts-01.txt (deliverable agreed in Yokohama > based on IESG input). Umbrella reqts document for specific L3 and L2 reqts > documents. Info RFC track. > > - Requirements for Layer 2 Virtual Private Network services : > draft-augustyn-ppvpn-l2vpn-requirements-01.txt (agreed in Yokohama to > supercede the current VPLS WG document). > - draft-luciani-ppvpn-vpn-discovery-03.txt : agreed as WG doc before > Yokohama, but the authors just resubmitted it now. So, I wish that we check > it again. Intention is to progress it similarly to BGP-autodiscovery draft > (already WG doc), as one of the discovery methods. From draft-luciani-ppvpn-vpn-discovery-03.txt: To date, proposals for VPN discovery have focused on including VPN information in BGP and IGP routing protocols. This method has the unfortunate effect of increasing the size of routing tables within the set of affected provider domains, even for those devices that are not involved in the VPN. This increase in size may be quite significant in some cases. There are other disadvantages to linking discovery and signaling to each other, and to an existing routing protocol. Routing changes or recalculations could interfere with the discovery and signaling functions of VPNs. When PE equipment is connected with explicitly routed LSPs, for example, such interference is completely unwarranted. Likewise, VPN changes (adding or deleting VPN support) impact routing tables with unnecessary updates, as this information must be propagated across the network via the routing protocol. The analysis of using BGP for auto-discovery in the above two paragraphs is superficial and contains technical inaccuracies. Moreover, if there is a consensus within the WG that there is a need to compare and constast BGP vs DNS for autodiscovery it would be more appropriate to have a separate document on this topic. Therefore, I request that the above two paragraphs be deleted from the draft before it would become a PPVPN WG document. Yakov. From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 12:29:37 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 MAA09545 for ; Wed, 13 Nov 2002 12:29:36 -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 gADHVOk05810 for ; Wed, 13 Nov 2002 12:31: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 gADHVM017081 for ; Wed, 13 Nov 2002 12:31:22 -0500 (EST) Message-ID: <410-220021131316454191@DellXP> Organization: Polyglot Ltd From: "Polyglot" To: ppvpn@nortelnetworks.com Subject: Polyglot Translation Date: Thu, 14 Nov 2002 00:04:54 +0800 MIME-Version: 1.0 Content-type: text/plain; charset=utf-7 X-SMTP-HELO: chinapolyglot.com X-SMTP-MAIL-FROM: info@polyglot.com.cn X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [202.106.155.97] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09545 Polyglot Translation Polyglot is a professional multilingual solutions provider. Our rich experience and professional team established us as a leader in the field of multilingual solutions. Polyglot can provide fast and accurate translations of financial, legal and technical documents on over 30 languages, such as English, German, Spanish, French, Italian, Chinese, Japanese, Korean, etc. We also provide software localization, website localization, simultaneous and consecutive interpretation for international meetings. For further information, please visit our website: http://www.polyglot.com.cn Contact us at: E-mail: info+AEA-polyglot.com.cn Tel: +-86 20 8657-3608 Fax: +-86 20 8657-3965 Add: 968 Office Tower, Central Hotel 33 Airport Road Guangzhou, China The message below is written in Chinese characters: +T916y0/hf/uL0VFsU/g- +T916y0/hf/uL0VFsU/hmL04AW7Zj0E+bWRp5zYvtigCJ41GzZbloSHaEThNOGmc6Z4QwAk4wW8x2hH7PmoxTyg- +ThNOGnaElh9PDXhuestOhmIRTuxXKFkaec2L7YoAieNRs2W5aEiYhlffdoSYhlFIVzBPTTAC- +YhFO7ID9Y9BPmw-30+WRp5zYvtigB2hFHGeG4wAV/rY3d2hH/7i9FnDVKh/wx/+4vRmIZX322JU8qR0YeNZYdO9jAB- +bNVfi2WHTvZTymKAZy9lh072/wx/+4vRi+15zVMFYuz/GoLxMAFftzABiX8wAWzVMAFhDzABTi0wAWXlMAGX6XtJe0kwAg- +a2RZFv8MYhFO7I/YY9BPm49vTvZnLFcwUxYwAX9RetlnLFcwUxYwAVb9lkVPGouudoRUDFjwTyCL0VSMTqRm/08gi9EwAg- +UXNOjovmYMX/DIv3i7+V7mIRTux2hH9RV0D/Gg- http://www.polyglot.com.cn +gFR8+2W5Xw//Gg- +dTWQrg-: info+AEA-polyglot.com.cn +dTWL3Q-: (86-20) 8657 3608 +TyB3Hw-: (86-20) 8657 3965 +VzBXQP8aTi1W/V5/Xd5nOlc6je8-33+U/c- +Ti1ZLpFSXpdRmVtXaXw-968 +kK5/Fv8a-510403 From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 13:31:26 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 NAA11847 for ; Wed, 13 Nov 2002 13:31:25 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gADIXKk25063 for ; Wed, 13 Nov 2002 13:33: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 gADIXI027659 for ; Wed, 13 Nov 2002 13:33:18 -0500 (EST) Message-ID: <0536FC9B908BEC4597EE721BE6A35389E1C123@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: yakov@juniper.net, "Marco Carugi" Cc: ppvpn@nortelnetworks.com Subject: RE: Your comments on 3 possible new PPVPN WG documents Date: Wed, 13 Nov 2002 18:30:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt08.hc.bt.com X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,marco.carugi@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: I support Yakov's proposal (on consensus) for a study to contrast/compare (i) adding new functionality to existing routing protocols vs (i) providing the new functionality by other means. I am sure many other operators would welcome seeing such studies/work carried out. It would also be helpful if the technical inaccuracies mentioned could also be expanded upon. regards, Neil > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: 13 November 2002 16:58 > To: Marco Carugi > Cc: 'ppvpn@nortelnetworks.com' > Subject: Re: Your comments on 3 possible new PPVPN WG documents > > > Marco, > > > All, > > > > I'd like to have your comments on the list about 3 drafts > before Atlanta > > meeting. > > The intention is to move them to WG document status asap > (note this is in > > line with what discussed in Yokohama) and I'd like to see > if still and which > > are your major concerns. > > Hopefully, it will be possible to officialise something at > the Atlanta > > meeting. > > > > Thanks, Marco > > > > - Generic Requirements for Provider Provisioned VPN : > > draft-nagarajan-ppvpn-generic-reqts-01.txt (deliverable > agreed in Yokohama > > based on IESG input). Umbrella reqts document for specific > L3 and L2 reqts > > documents. Info RFC track. > > > > - Requirements for Layer 2 Virtual Private Network services : > > draft-augustyn-ppvpn-l2vpn-requirements-01.txt (agreed in > Yokohama to > > supercede the current VPLS WG document). > > - draft-luciani-ppvpn-vpn-discovery-03.txt : agreed as WG doc before > > Yokohama, but the authors just resubmitted it now. So, I > wish that we check > > it again. Intention is to progress it similarly to > BGP-autodiscovery draft > > (already WG doc), as one of the discovery methods. > > From draft-luciani-ppvpn-vpn-discovery-03.txt: > > To date, proposals for VPN discovery have focused on including VPN > information in BGP and IGP routing protocols. This method has the > unfortunate effect of increasing the size of routing tables within > the set of affected provider domains, even for those devices that > are not involved in the VPN. This increase in size may be quite > significant in some cases. > > There are other disadvantages to linking discovery and signaling to > each other, and to an existing routing protocol. Routing > changes or > recalculations could interfere with the discovery and signaling > functions of VPNs. When PE equipment is connected with explicitly > routed LSPs, for example, such interference is completely > unwarranted. Likewise, VPN changes (adding or deleting > VPN support) > impact routing tables with unnecessary updates, as this information > must be propagated across the network via the routing protocol. > > The analysis of using BGP for auto-discovery in the above two > paragraphs is superficial and contains technical inaccuracies. > Moreover, if there is a consensus within the WG that there is > a need to compare and constast BGP vs DNS for autodiscovery > it would be more appropriate to have a separate document on this > topic. > > Therefore, I request that the above two paragraphs be deleted > from the draft before it would become a PPVPN WG document. > > Yakov. > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 18:50:18 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 SAA22076 for ; Wed, 13 Nov 2002 18:50:17 -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 gADNqHk04598 for ; Wed, 13 Nov 2002 18:52:18 -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 gADNq9022394 for ; Wed, 13 Nov 2002 18:52:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for MPLS-VPN-MIB enhancements Date: Wed, 13 Nov 2002 18:51:30 -0500 Message-ID: <28F05913385EAC43AF019413F674A017044A33A1@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Proposal for MPLS-VPN-MIB enhancements Thread-Index: AcJJOWHMYqmE064iQgOW1cclj4ekVwA0vL+QEFjKIeA= From: "Lai, Wai S (Waisum), ALASO" To: "Thomas D. Nadeau" Cc: , "Ash, Gerald R (Jerry), ALASO" , "Chung, Li-Jin W, ALCNS" , "Van Der Linde, Harmen, ALCNS" , "Zhang, Leah, ALCNS" X-SMTP-HELO: almso2.proxy.att.com X-SMTP-MAIL-FROM: wlai@att.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: almso2.att.com [192.128.166.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA22076 Tom, Regarding (1) about the practical use of the dropped-route count, here are some examples: 1. Engineering of the routing table - to properly tune its size via the max threshold. 2. Understanding of customer demand for prefix routes - increase in demand could be due to growth of the business, or re-homing. Re-engineering effort might be needed if this is the case. 3. Trouble shooting and understanding the customer service impact - customer might inject too many routes due to provisioning errors. 4. Router resource management to optimize router performance - the overflow counts can be summerized at the per router level for forcasting and capacity planning. Regarding (2) about VRF/RD/RT association, the proposal is to associate RT with the RD index and not the VRF name index. Currently, the mplsVpnVrfRouteTargetTable table is key on the VRF name, but one VRF name could have two or more RD number assigned to it. Also, while the mplsVpnRouteTarget uses the same format as the mplsVpnRouteDistinguisher, it does not provide the RD index. An explicit association between RT and RD is needed. In this connection, I believe that some clarification of the example in "Defining the VPN," page 8, is needed. Clearly, the first "100:1" in mplsVpnVrfTable is the RD number. However, the second "100:1" in mplsVpnVrfRouteTargetTable should be the RT number and not RD number, am I correct? If this is the case, then giving the same number to RD and RT may cause ambiguity in the example. Thanks, Wai Sum. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, August 21, 2002 1:36 PM To: Lai, Wai S (Waisum), ALASO Cc: ppvpn@ppvpn.francetelecom.com Subject: Re: Proposal for MPLS-VPN-MIB enhancements >I would like to propose the following enhancements for consideration in >draft-ietf-ppvpn-mpls-vpn-mib-04: > >(1) Currently, there is the mplsNumVrfRouteMaxThreshExceeded >notification >when the VRF maximum route threshold is exceeded. It is suggested to >add >a counter for the number of routes dropped due to such threshold being >exceeded. The reporting of such a count is useful for capacity planning >and for threshold tunning purposes. What practical purpose do you see in counting routes that are not added beyond knowing that you have exceed that operator-defined threshold? >(2) In the mplsVpnVrfRouteTargetTable table, it appears that there is no >explicit mapping between the route targets (RT) and their associated >Route Distinguisher (RD). It is suggested to add such association between >VRF, RD, and RT in this table. What do you mean by an explicit mapping -- an index? The current RouteTarget table contains the associated RD for each RT entry: MplsVpnVrfRouteTargetEntry ::= SEQUENCE { mplsVpnVrfRouteTargetIndex Unsigned32, mplsVpnVrfRouteTargetType INTEGER, mplsVpnVrfRouteTarget MplsVpnRouteDistinguisher, mplsVpnVrfRouteTargetDescr DisplayString, mplsVpnVrfRouteTargetRowStatus RowStatus } --Tom >Comments are welcome. >Thanks, Wai Sum. ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 20:18:19 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 UAA23635 for ; Wed, 13 Nov 2002 20:18:19 -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 gAE1KHk18563 for ; Wed, 13 Nov 2002 20:20:17 -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 gAE1KE001590 for ; Wed, 13 Nov 2002 20:20:14 -0500 (EST) Message-ID: <3271707.1037236774793.JavaMail.nobody@wamui06.slb.atl.earthlink.net> Date: Wed, 13 Nov 2002 20:19:32 -0500 (GMT) From: Matt Squire Reply-To: msquire@mindspring.com To: Yakov Rekhter , "Marco Carugi" Subject: Re: Re: Your comments on 3 possible new PPVPN WG documents Cc: "'ppvpn@nortelnetworks.com'" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Web Access Mail version 2.0 X-SMTP-HELO: conure.mail.pas.earthlink.net X-SMTP-MAIL-FROM: msquire@mindspring.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: conure.mail.pas.earthlink.net [207.217.120.54] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I have no problem yanking the referenced paragraphs. Although I disagree on the inaccuracy, I completely agree that they are unnecessary. So consider them gone. - Matt -------Original Message------- From: Yakov Rekhter Sent: 11/13/02 11:57 AM To: Marco Carugi Subject: Re: Your comments on 3 possible new PPVPN WG documents > Marco, > All, > > I'd like to have your comments on the list about 3 drafts before Atlanta > meeting. > The intention is to move them to WG document status asap (note this is in > line with what discussed in Yokohama) and I'd like to see if still and which > are your major concerns. > Hopefully, it will be possible to officialise something at the Atlanta > meeting. > > Thanks, Marco > > - Generic Requirements for Provider Provisioned VPN : > draft-nagarajan-ppvpn-generic-reqts-01.txt (deliverable agreed in Yokohama > based on IESG input). Umbrella reqts document for specific L3 and L2 reqts > documents. Info RFC track. > > - Requirements for Layer 2 Virtual Private Network services : > draft-augustyn-ppvpn-l2vpn-requirements-01.txt (agreed in Yokohama to > supercede the current VPLS WG document). > - draft-luciani-ppvpn-vpn-discovery-03.txt : agreed as WG doc before > Yokohama, but the authors just resubmitted it now. So, I wish that we check > it again. Intention is to progress it similarly to BGP-autodiscovery draft > (already WG doc), as one of the discovery methods. From draft-luciani-ppvpn-vpn-discovery-03.txt: To date, proposals for VPN discovery have focused on including VPN information in BGP and IGP routing protocols. This method has the unfortunate effect of increasing the size of routing tables within the set of affected provider domains, even for those devices that are not involved in the VPN. This increase in size may be quite significant in some cases. There are other disadvantages to linking discovery and signaling to each other, and to an existing routing protocol. Routing changes or recalculations could interfere with the discovery and signaling functions of VPNs. When PE equipment is connected with explicitly routed LSPs, for example, such interference is completely unwarranted. Likewise, VPN changes (adding or deleting VPN support) impact routing tables with unnecessary updates, as this information must be propagated across the network via the routing protocol. The analysis of using BGP for auto-discovery in the above two paragraphs is superficial and contains technical inaccuracies. Moreover, if there is a consensus within the WG that there is a need to compare and constast BGP vs DNS for autodiscovery it would be more appropriate to have a separate document on this topic. Therefore, I request that the above two paragraphs be deleted from the draft before it would become a PPVPN WG document. Yakov. From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 21: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 VAA24519 for ; Wed, 13 Nov 2002 21:06: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 gAE28tk29121 for ; Wed, 13 Nov 2002 21:08: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 gAE28q007486 for ; Wed, 13 Nov 2002 21:08:52 -0500 (EST) Message-Id: <5.0.2.7.2.20021114105538.04a4a070@localhost> X-Sender: tk019/imd.m.ecl.ntt.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Thu, 14 Nov 2002 11:06:18 +0900 To: "Joel M. Halpern" , ppvpn@nortelnetworks.com From: Takeshi KUWAHARA Subject: Re: FW: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Cc: murayama.junichi@lab.ntt.co.jp, tanikawa.masaki@lab.ntt.co.jp, suzuki.muneyoshi@lab.ntt.co.jp, kuwahara.takeshi@lab.ntt.co.jp In-Reply-To: <5.1.0.14.0.20021112081107.02842eb0@mail.stevecrocker.com> References: <5.0.2.7.2.20021112192739.04a35ec8@localhost> <200211111622.gABGMFIX006885@sj-msg-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: kuwahara.takeshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Joel, Thank you for your comments on our draft. Please see my comments inline. At 08:21 02/11/12 -0500, you wrote: >There are two cases recognized in your document. >In one case, you require a full mesh abong all PE devices, and do not use >CTCP. This is roughly similar to many other tunnel protoocols. > >However, the primary focus of your document is CTCP. The use of CTCP >places very specific restrictions on the operator(s) VPN support topology. >All cut-through creation messages are generated by DF. In order to >generate them, the DF must have received the message directly from a PE >device, and be forwarding the message directly to a PE device. Therefore, >in order to function, all PE devices must be exchanging routing >information with each DF. Yes, you can have multiple DFs for load sharing >of packet forwarding activity. However, it that case they ALL must have >routing exchanges with ALL PEs in the VPN. And all PEs in the VPN must >know about and deliver routing to ALL the DFs. >Note that this requirement for complete coverage applies to all PEs in >the VPN across all providers. >The necessity for such topology restrictions, including the additional >restrictions that DF entities MUST be distinct from PE entities, is driven >by the fact that as shown in the earlier IETF work on cut-through, without >such restrictions it is extremely difficult to avoid inducing loops and >black holes when using cut-through protocols. Thanks again for your clarifications. We also see loops and blackholes in the cut-though control as major problems. However, as for scalability perspective, we find it very attractive that we introduce the approach of keeping reachability by using default routes and improving packet forwarding by using cut-through routes. Therefore, we have been looking for an approach that would solve the problem even if there are some kind of restriction if it doesn't severely higher the load of routers. >You could try to claim that by creating separate groups, with PE devices >forwarding from one group to another, you can get multiple hub and spoke >clusters. There are quite a number of interesting topological constraints >you would have to your document in order to make this work. Even >determining how such a PE would know which cluster to forward packets to >is quite complex and beyond what is described in your document. We also think multiple hub and spoke clusters are effective to scale with large networks. In this case, delivering routes among multiple hubs is considerable. We think multiple hubs can take any type of topology and routes are delivered by routing protocols. However, the mesh topology is desirable for the hubs' topology, as cut-through controls are needed for each hop of the hubs. Here, the destination of a cut-through route is changed hub after hub until it finally reaches to an egress PE. >Note also that you describe the control exchange between the DF and PE >devices as if it were a normal routing instance. While not a very >complicated exchange, it is certainly different from any existing >exchange. For the DF receiving the advertisements from the PEs, it must >learn the reachability and associate it with the IPv6 soure (a minor >tweak). However, the DF should not advertise reachability to other DFs or >to the PEs. PEs must ignore any reachability information they get from >the DFs since the nature of the protocol requires that all packets from >the custoemr site are forwarded to the DF, and packets from the provider >are checked against customer learned routing only for forwarding. It is possible to operate DF and PE devices as a normal routing instance. However, we believe above-mentioned approach is much effective in order to lower the load of routing by using the hub and spoke topology. Regards, Takeshi Kuwahara. From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 21:13:03 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 VAA24660 for ; Wed, 13 Nov 2002 21:13:02 -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 gAE2F1k03105 for ; Wed, 13 Nov 2002 21:15: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 gAE2Ew012064 for ; Wed, 13 Nov 2002 21:14:58 -0500 (EST) Message-Id: <5.0.2.7.2.20021114110847.03cc4540@localhost> X-Sender: tk019/imd.m.ecl.ntt.co.jp@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Thu, 14 Nov 2002 11:14:29 +0900 To: erosen@cisco.com, ppvpn@nortelnetworks.com From: Takeshi KUWAHARA Subject: Re: FW: I-D ACTION:draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Cc: murayama.junichi@lab.ntt.co.jp, tanikawa.masaki@lab.ntt.co.jp, suzuki.muneyoshi@lab.ntt.co.jp, kuwahara.takeshi@lab.ntt.co.jp In-Reply-To: <200211121802.gACI2GIX015573@sj-msg-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: kuwahara.takeshi@lab.ntt.co.jp X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tama5.ecl.ntt.co.jp [129.60.39.102] X-LYRIS-Message-Id: Eric, Thanks for your reply. Please see the comments below. At 13:02 02/11/12 -0500, you wrote: > > CTCP can be applied to the topology of multiple hubs. When there are > > multiple hubs, a spoke is able to choose an appropriate hub to send > > packets by the routing protocol operated among multiple hubs and spokes. > > So, it is possible to change the next hop to the backup hubs in the case > > of failures. > >Now you are suggesting to run both CTCP and a "routing protocol operated >among multiple hubs and spokes"? I don't understand at all how that would >work. During a routing transient you could get two hubs independently >redirecting the spokes, and the routing might never converge. The reasons for introducing multiple hubs are to lighten the load of hub and to improve reliability. Let me explain a procedure with the following example. In the figure below, each spoke announces accommodating routes to both hub1 and hub2 by routing protocols. And each of them chooses an appropriate hub to forward packets. Here, the load of each hub is lightened by spokes choosing hubs dispersively. +-----+ +-------+ +-----+ | |-------|spoke 1|-------| | | | +-------+ | | | | | | | | +-------+ | | | |-------|spoke 2|-------| | | | +-------+ | | |hub 1| |hub 2| | | +-------+ | | | |-------|spoke 3|-------| | | | +-------+ | | | | | | | | +-------+ | | | |-------|spoke 4|-------| | +-----+ +-------+ +-----+ When a failure occurs in a route between hub and spoke, the spoke determines the failure by routing protocol, and then changes the forwarding route to the backup hub. In this way, reliability of the network can be achieved. As hub1 and hub2 have the same routing information to each spoke, routing would converge. Even when improper redirection messages are sent to the spokes during a routing transient, each spoke sends a purge message when it cannot forward packets to the accommodating CEs, so that the routes are changed properly. Regards, Takeshi Kuwahara. From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 23:32:45 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 XAA28742 for ; Wed, 13 Nov 2002 23:32:44 -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 gAE4YSk12361 for ; Wed, 13 Nov 2002 23:34: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 gAE4YQ009367 for ; Wed, 13 Nov 2002 23:34:26 -0500 (EST) Message-ID: From: "Marco Carugi" To: "'ppvpn@nortelnetworks.com'" , "'agenda@ietf.org'" Cc: sob@harvard.edu, bwijnen@lucent.com, Alex Zinin , "Marco Carugi" , "'Rick Wilder'" Subject: Atlanta PPVPN meeting agenda Date: Thu, 14 Nov 2002 05:33:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28B97.06C7D11A" 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_01C28B97.06C7D11A Content-Type: text/plain; charset="iso-8859-1" All, this is the planned agenda for the PPVPN WG meeting in Atlanta (Wednedsday Nov 20th 9H-11H30). Speakers: please remember that ID presentations are not wished. Focus has to be on problems to be solved, issues, future steps. Marco **************************************************************************** ***************************** Provider Provisioned Virtual Private Networks WG (ppvpn) Wednedsday, November 20 at 0900-1130 ================================== CHAIRS: Marco Carugi marco.carugi@nortelnetworks.com Rick Wilder rwilder@masergy.com MAILING LIST: ppvpn@nortelnetworks.com ARCHIVES: //standards.nortelnetworks.com/ppvpn/index.htm Same agenda with direct URL access to IDs will be available at //standards.nortelnetworks.com/ppvpn/calendar.htm Agenda bashing, minutes, blue sheets - chairs PPVPN WG status - 15 min - Marco Carugi ID status, milestones, L3 and L2 solution space, progress expected before next meeting, issues and missing work, liaisons (ITU-T SG13 on L1/optical VPNs, IEEE 802.1 on L2 VPNs) PPVPN GENERIC REQUIREMENTS - 10 min - Ananth Nagarajan umbrella requirements common to L3 and L2 VPNs (agreed in Yokohama) draft-nagarajan-ppvpn-generic-reqts-01.txt L3 PPVPN - CE-to-CE authentication for RFC2547 PPVPNs - 5 min - Ron Bonica Update, issues - draft-ietf-ppvpn-l3vpn-auth-01.txt - CE autoconfiguration - 5 min - Cheng-Yin Lee update, categorization of mechanisms, intra-domain and inter-domain auto-provisioning draft-lee-ppvpn-ce-auto-config-02.txt - IPsec Protected Virtual Links for PPVPNs - 10 min - Mark Duffy approach for virtual links with (or without) IPsec, value and applicability context, issues, future steps draft-duffy-ppvpn-ipsec-vlink-00.txt - Multiple Instances of OSPF for the PE/CE protocol in BGP/MPLS - 10 min - Kunihiro Ishiguro overview, comparison with other proposal, issues, future steps. Relation with planned progress of 2547. draft-ishiguro-ppvpn-pe-ce-ospf-01.txt L2 PPVPN - L2 requirements - 10 min - Yetik Serbest Update, issues, future steps. draft-augustyn-ppvpn-l2vpn-requirements-01.txt - L2 framework and L2 DT report - 20 min - L. Andersson, E. Rosen, M. Suzuki, N. Finn Update, service and reference model (problem, team discussion), cooperation with IEEE 802, issues and future steps. Progress in solution space. draft-andersson-ppvpn-l2-framework-02.txt, draft-andersson-ppvpn-terminology-02.txt - CE-based VPLS - 5 min - Cheng-Yin Lee Update, list discussion on work partitioning (Tunnel Endpoint Discovery, L2TPV3 specifics), future steps draft-lee-ce-based-vpl-01.txt - LDP-based Signaling for L2VPNs - 10 min - Eric Rosen update, proposal' s value and positioning among L2 (VPN) signaling schemes, how/where it should be progressed, relation with L2 solution documents, future steps draft-rosen-ppvpn-l2-signaling-02.txt - Virtual Hierarchical LAN Services - 5 min - Arnold Sodder positioning and value in solution space, mac-in-mac frame overview, issues, how and where to progress this draft-sodder-ppvpn-vhls-01.txt - GVPLS/LPE - Generic VPLS Solution based on LPE Framework - 10 min - Dinesh Mohan positioning and value in solution space, issues, future steps draft-radoaca-ppvpn-gvpls-00.txt - VPLS based on IP Multicast - 5 min - Ali Sajassi positioning and value in solution space, issues, future steps draft-sajassi-mvpls-00.txt L2 PPVPN interworking - positioning and value, issues, how to progress from now - draft-sajassi-l2vpn-interworking-00.txt - 5 min - Ali Sajassi - draft-moreels-multiproto-mpls-00.txt - 5 min - Jeremy De Clercq - IP over LAN Service (IPLS) - 10 min - Himanshu Shah positioning and value in solution space, issues, future steps draft-shah-ppvpn-ipls-00.txt CONCLUSION - 5 min - chairs Recap of main open issues and work items, team work, expected deliverables Just if time allows : - IPv6 for Large Access Providers - 5 min - Weijing Chen positioning and value for PPVPN (problems addressed), issues, future steps draft-allen-lap-ipv6-00.txt - BGP-MPLS VPN extension for IPv6 VPN - 5 min - Francois Le Faucheur Update, next steps - draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt ------_=_NextPart_001_01C28B97.06C7D11A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Atlanta PPVPN meeting agenda

All,
this is the planned agenda for the = PPVPN WG meeting in Atlanta (Wednedsday Nov  20th  = 9H-11H30).

Speakers: please remember  that = ID presentations are not  wished. Focus has to be on problems to = be solved, issues, future steps.

Marco

*********************************************************= ************************************************
Provider Provisioned Virtual Private = Networks WG (ppvpn)
Wednedsday, November 20 at 0900-1130 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CHAIRS: Marco Carugi = marco.carugi@nortelnetworks.com
Rick Wilder rwilder@masergy.com =
 
MAILING LIST: = ppvpn@nortelnetworks.com
ARCHIVES: = //standards.nortelnetworks.com/ppvpn/index.htm
Same agenda with direct URL access to = IDs will be available at = //standards.nortelnetworks.com/ppvpn/calendar.htm

Agenda bashing, minutes, blue sheets - = chairs

PPVPN WG status - 15 min - Marco = Carugi
ID status, milestones, L3 and L2 = solution space,  progress expected before next  meeting, =
issues and missing work, liaisons = (ITU-T SG13 on L1/optical  VPNs, IEEE 802.1 on L2 VPNs)

PPVPN  GENERIC  REQUIREMENTS = - 10 min - Ananth Nagarajan
umbrella requirements common to L3 = and L2 VPNs  (agreed  in Yokohama) 
draft-nagarajan-ppvpn-generic-reqts-01.txt 

L3 PPVPN
- CE-to-CE authentication for RFC2547 = PPVPNs - 5 min - Ron Bonica
Update, issues - = draft-ietf-ppvpn-l3vpn-auth-01.txt
- CE autoconfiguration - 5 min - = Cheng-Yin  Lee
update, categorization of mechanisms, = intra-domain and inter-domain auto-provisioning
draft-lee-ppvpn-ce-auto-config-02.txt
- IPsec Protected Virtual Links for = PPVPNs - 10 min - Mark Duffy
approach for virtual links with (or = without) IPsec, value and applicability context, issues,  future = steps
draft-duffy-ppvpn-ipsec-vlink-00.txt
- Multiple Instances of OSPF for the = PE/CE protocol in BGP/MPLS - 10 min - Kunihiro Ishiguro
overview, comparison with other  = proposal, issues, future steps. Relation with planned progress of = 2547. 
draft-ishiguro-ppvpn-pe-ce-ospf-01.txt

L2 PPVPN
- L2 requirements - 10 min - Yetik = Serbest
Update, issues, future steps.
draft-augustyn-ppvpn-l2vpn-requirements-01.txt
- L2 framework and L2 DT report - 20 = min - L. Andersson, E. Rosen, M. Suzuki, N. Finn
Update, service and reference model = (problem, team discussion), cooperation with IEEE 802, issues and = future steps. Progress in solution space.

draft-andersson-ppvpn-l2-framework-02.txt, = draft-andersson-ppvpn-terminology-02.txt 
- CE-based VPLS - 5 min - Cheng-Yin = Lee
Update, list discussion on work = partitioning (Tunnel Endpoint Discovery, L2TPV3  specifics), = future steps
draft-lee-ce-based-vpl-01.txt
- LDP-based Signaling for = L2VPNs  - 10  min - Eric Rosen
update, proposal' s value and  = positioning among L2 (VPN) signaling schemes, how/where it should be = progressed,
relation with L2 solution documents, = future steps
draft-rosen-ppvpn-l2-signaling-02.txt
- Virtual Hierarchical LAN Services = -  5 min - Arnold Sodder
positioning and value in solution = space, mac-in-mac frame overview,  issues, how and where to = progress this  
draft-sodder-ppvpn-vhls-01.txt
- GVPLS/LPE - Generic VPLS Solution = based on LPE Framework  - 10 min - Dinesh  Mohan
positioning and value in solution = space, issues, future steps
draft-radoaca-ppvpn-gvpls-00.txt
- VPLS based on IP = Multicast   - 5 min -  Ali Sajassi
positioning and value in solution = space, issues, future  steps
draft-sajassi-mvpls-00.txt

L2 PPVPN interworking  - = positioning  and value, issues, how to progress from now  =
-  = draft-sajassi-l2vpn-interworking-00.txt   - 5  min  = - Ali  Sajassi
-  = draft-moreels-multiproto-mpls-00.txt  - 5 min  -  = Jeremy  De Clercq

- IP over LAN Service (IPLS) - 10 min = - Himanshu Shah   
positioning and value in solution = space, issues, future steps
draft-shah-ppvpn-ipls-00.txt

CONCLUSION - 5 min - chairs
Recap of main open issues and work = items, team work, expected deliverables

Just if time allows :
- IPv6 for Large Access Providers - 5 = min -  Weijing Chen
positioning and value for PPVPN = (problems addressed), issues, future steps
draft-allen-lap-ipv6-00.txt
- BGP-MPLS VPN extension for IPv6 VPN = - 5 min  - Francois Le Faucheur
Update, next steps  - = draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt

------_=_NextPart_001_01C28B97.06C7D11A-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 13 23:49:07 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 XAA29541 for ; Wed, 13 Nov 2002 23:49:07 -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 gAE4p5k17371 for ; Wed, 13 Nov 2002 23:51: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 gAE4p2j16861 for ; Wed, 13 Nov 2002 23:51:02 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-361e8576-b4a8-48f7-8d93-a04b707fcf47" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: Information... Date: Thu, 14 Nov 2002 10:19:43 +0530 Message-ID: <4D148FEC6C003445B94D5B264288DBE934E218@blr-k1-msg.wipro.com> Thread-Topic: Information... Thread-Index: AcKLmT/e5WBrxuNnS+axSmSojTJrkw== From: "Shankar Ananthanarayanan Kambat" To: X-OriginalArrivalTime: 14 Nov 2002 04:49:44.0431 (UTC) FILETIME=[4044E7F0:01C28B99] X-SMTP-HELO: wiprom2mx1.wipro.com X-SMTP-MAIL-FROM: shankar.kambat@wipro.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: wiprom2mx1.wipro.com [203.197.164.41] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPartTM-000-361e8576-b4a8-48f7-8d93-a04b707fcf47 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, My question may not be relevant to this group. However, if pointers = related to My question will be greatly helpful. Are there working groups or drafts for running Ethernet over ATM, FR = etc similar To Ethernet over MPLS? I guess Riverstone Networks is introducing a = product similar To this?=20 Regds Shankar K A ------=_NextPartTM-000-361e8576-b4a8-48f7-8d93-a04b707fcf47 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************************** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. **************************************************************************************** ------=_NextPartTM-000-361e8576-b4a8-48f7-8d93-a04b707fcf47-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 14 06:14:35 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 GAA15605 for ; Thu, 14 Nov 2002 06:14:35 -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 gAEBGNn06480 for ; Thu, 14 Nov 2002 06:16: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 gAEBGKj02138 for ; Thu, 14 Nov 2002 06:16:20 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt Date: Thu, 14 Nov 2002 11:15:18 -0000 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt Thread-Index: AcKHR0bnhMQ2igNdSuGQan5tV08uYQEg14bA From: "Francois Le Faucheur (flefauch)" To: X-OriginalArrivalTime: 14 Nov 2002 11:15:19.0351 (UTC) FILETIME=[1DC18C70:01C28BCF] X-SMTP-HELO: ams-msg-core-1.cisco.com X-SMTP-MAIL-FROM: flefauch@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-msg-core-1.cisco.com [144.254.74.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA15605 Hello, Feed-fack on -03 is sought. The main changes from -02 to -03 are: - generalisation to describe IPv6 VPN operations over various tunnel types in the core (MPLS tunnels, GRE, IPsec,..) - optional use of the "Tunnel Type" BGP Attribute under discussion (see draft-cristallo-bgp-tunnel-attr-00.txt) for optional automatic tunnel determination - generalisation to describe IPv6 VPN operations over IPv6 core, in addition to over IPv4 core. - added section on IPv6 address scope and relationship to IPv6 VPNs - added section on Management VPN - SAFI for "VPN-IPv6" Address Family changed from 129 to 128 (ie same SAFI as "VPN-IPv4") - added section on Encapsulation (to clarify actual encaps headers in the various cases) - editorials Thanks Francois >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: 08 November 2002 13:36 >> Cc: ppvpn@nortelnetworks.com >> Subject: I-D ACTION:draft-ietf-ppvpn-bgp-ipv6-vpn-03.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 : BGP-MPLS VPN extension for IPv6 VPN >> Author(s) : G. De Clercq et al. >> Filename : draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt >> Pages : 14 >> Date : 2002-11-7 >> >> This document describes a method by which a Service Provider may use >> its packet switched backbone to provide Virtual Private Network >> services for its IPv6 customers. This method extends the 'BGP/MPLS >> VPN' method [2547bis] for support of IPv6. In BGP/MPLS VPN, >> 'Multiprotocol BGP' is used for distributing IPv4 VPN routes over the >> service provider backbone and MPLS is used to forward IPv4 VPN >> packets over the backbone. This document defines an IPv6 VPN address >> family and describes the corresponding route distribution in >> 'Multiprotocol BGP'. This document defines support of the IPv6 VPN >> service over both an IPv4 and an IPv6 backbone, and using various >> tunnelling techniques over the core including MPLS, IPsec, IP-in-IP >> and GRE. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-bgp-ipv6 -vpn-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 14 06:51:44 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 GAA16357 for ; Thu, 14 Nov 2002 06:51: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 gAEBren11768 for ; Thu, 14 Nov 2002 06:53: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 gAEBrbj15074 for ; Thu, 14 Nov 2002 06:53:37 -0500 (EST) Message-Id: <5.1.0.14.2.20021114065017.064a0ea0@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Nov 2002 06:52:54 -0500 To: "Shankar Ananthanarayanan Kambat" From: "Andrew G. Malis" Subject: Re: Information... Cc: In-Reply-To: <4D148FEC6C003445B94D5B264288DBE934E218@blr-k1-msg.wipro.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Nov 2002 11:52:58.0738 (UTC) FILETIME=[6074A520:01C28BD4] X-SMTP-HELO: vivacenetworks.com X-SMTP-MAIL-FROM: Andy.Malis@VivaceNetworks.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.221.212.131] X-LYRIS-Message-Id: Shankar, Ethernet over FR is specified in RFC 2427. Ethernet over ATM is specified in RFC 2684. Cheers, Andy --------- At 11/14/2002 10:19 AM +0530, Shankar Ananthanarayanan Kambat wrote: >Hi, > My question may not be relevant to this group. However, if pointers > related to >My question will be greatly helpful. > > Are there working groups or drafts for running Ethernet over ATM, FR > etc similar >To Ethernet over MPLS? I guess Riverstone Networks is introducing a >product similar >To this? > >Regds >Shankar K A From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 14 10:24:50 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 KAA21588 for ; Thu, 14 Nov 2002 10:24:50 -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 gAEFPkn14890 for ; Thu, 14 Nov 2002 10:25:46 -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 gAEFPhj15519 for ; Thu, 14 Nov 2002 10:25:44 -0500 (EST) Message-ID: From: "Marco Carugi" To: "'ppvpn@nortelnetworks.com'" Cc: "'Rick Wilder'" , "Marco Carugi" Subject: RE: Atlanta PPVPN meeting agenda Date: Thu, 14 Nov 2002 16:25:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28BF1.4EADD6F0" 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_01C28BF1.4EADD6F0 Content-Type: text/plain; charset="iso-8859-1" I forgot to mention - on request by ADs - that it's assumed people will have read all documents listed below. Marco > > All, > this is the planned agenda for the PPVPN WG meeting in > Atlanta (Wednedsday Nov 20th 9H-11H30). > > Speakers: please remember that ID presentations are not > wished. Focus has to be on problems to be solved, issues, > future steps. > > Marco > > ************************************************************** > ******************************************* > Provider Provisioned Virtual Private Networks WG (ppvpn) > Wednedsday, November 20 at 0900-1130 > ================================== > CHAIRS: Marco Carugi marco.carugi@nortelnetworks.com > Rick Wilder rwilder@masergy.com > > MAILING LIST: ppvpn@nortelnetworks.com > ARCHIVES: //standards.nortelnetworks.com/ppvpn/index.htm > Same agenda with direct URL access to IDs will be available > at //standards.nortelnetworks.com/ppvpn/calendar.htm > > Agenda bashing, minutes, blue sheets - chairs > > PPVPN WG status - 15 min - Marco Carugi > ID status, milestones, L3 and L2 solution space, progress > expected before next meeting, > issues and missing work, liaisons (ITU-T SG13 on L1/optical > VPNs, IEEE 802.1 on L2 VPNs) > > PPVPN GENERIC REQUIREMENTS - 10 min - Ananth Nagarajan > umbrella requirements common to L3 and L2 VPNs (agreed in > Yokohama) > draft-nagarajan-ppvpn-generic-reqts-01.txt > > L3 PPVPN > - CE-to-CE authentication for RFC2547 PPVPNs - 5 min - Ron Bonica > Update, issues - draft-ietf-ppvpn-l3vpn-auth-01.txt > - CE autoconfiguration - 5 min - Cheng-Yin Lee > update, categorization of mechanisms, intra-domain and > inter-domain auto-provisioning > draft-lee-ppvpn-ce-auto-config-02.txt > - IPsec Protected Virtual Links for PPVPNs - 10 min - Mark Duffy > approach for virtual links with (or without) IPsec, value and > applicability context, issues, future steps > draft-duffy-ppvpn-ipsec-vlink-00.txt > - Multiple Instances of OSPF for the PE/CE protocol in > BGP/MPLS - 10 min - Kunihiro Ishiguro > overview, comparison with other proposal, issues, future > steps. Relation with planned progress of 2547. > draft-ishiguro-ppvpn-pe-ce-ospf-01.txt > > L2 PPVPN > - L2 requirements - 10 min - Yetik Serbest > Update, issues, future steps. > draft-augustyn-ppvpn-l2vpn-requirements-01.txt > - L2 framework and L2 DT report - 20 min - L. Andersson, E. > Rosen, M. Suzuki, N. Finn > Update, service and reference model (problem, team > discussion), cooperation with IEEE 802, issues and future > steps. Progress in solution space. > draft-andersson-ppvpn-l2-framework-02.txt, > draft-andersson-ppvpn-terminology-02.txt > - CE-based VPLS - 5 min - Cheng-Yin Lee > Update, list discussion on work partitioning (Tunnel Endpoint > Discovery, L2TPV3 specifics), future steps > draft-lee-ce-based-vpl-01.txt > - LDP-based Signaling for L2VPNs - 10 min - Eric Rosen > update, proposal' s value and positioning among L2 (VPN) > signaling schemes, how/where it should be progressed, > relation with L2 solution documents, future steps > draft-rosen-ppvpn-l2-signaling-02.txt > - Virtual Hierarchical LAN Services - 5 min - Arnold Sodder > positioning and value in solution space, mac-in-mac frame > overview, issues, how and where to progress this > draft-sodder-ppvpn-vhls-01.txt > - GVPLS/LPE - Generic VPLS Solution based on LPE Framework - > 10 min - Dinesh Mohan > positioning and value in solution space, issues, future steps > draft-radoaca-ppvpn-gvpls-00.txt > - VPLS based on IP Multicast - 5 min - Ali Sajassi > positioning and value in solution space, issues, future steps > draft-sajassi-mvpls-00.txt > > L2 PPVPN interworking - positioning and value, issues, how > to progress from now > - draft-sajassi-l2vpn-interworking-00.txt - 5 min - Ali Sajassi > - draft-moreels-multiproto-mpls-00.txt - 5 min - Jeremy De Clercq > > - IP over LAN Service (IPLS) - 10 min - Himanshu Shah > positioning and value in solution space, issues, future steps > draft-shah-ppvpn-ipls-00.txt > > CONCLUSION - 5 min - chairs > Recap of main open issues and work items, team work, expected > deliverables > > Just if time allows : > - IPv6 for Large Access Providers - 5 min - Weijing Chen > positioning and value for PPVPN (problems addressed), issues, > future steps > draft-allen-lap-ipv6-00.txt > - BGP-MPLS VPN extension for IPv6 VPN - 5 min - Francois Le Faucheur > Update, next steps - draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt ------_=_NextPart_001_01C28BF1.4EADD6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Atlanta PPVPN meeting agenda

I forgot to mention = - on  request by ADs - that it's assumed people will have read all = documents listed below.

Marco
>
> All,
> this is the planned agenda for = the PPVPN WG meeting in
> Atlanta (Wednedsday Nov  = 20th  9H-11H30).
>
> Speakers: please remember  = that ID presentations are not 
> wished. Focus has to be on = problems to be solved, issues,
> future steps.
>
> Marco
>
> = **************************************************************
> = *******************************************
> Provider Provisioned Virtual = Private Networks WG (ppvpn)
> Wednedsday, November 20 at = 0900-1130
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> CHAIRS: Marco Carugi = marco.carugi@nortelnetworks.com
> Rick Wilder rwilder@masergy.com =
> 
> MAILING LIST: = ppvpn@nortelnetworks.com
> ARCHIVES: = //standards.nortelnetworks.com/ppvpn/index.htm
> Same agenda with direct URL = access to IDs will be available
> at = //standards.nortelnetworks.com/ppvpn/calendar.htm
>
> Agenda bashing, minutes, blue = sheets - chairs
>
> PPVPN WG status - 15 min - Marco = Carugi
> ID status, milestones, L3 and L2 = solution space,  progress
> expected before next  = meeting,
> issues and missing work, = liaisons (ITU-T SG13 on L1/optical 
> VPNs, IEEE 802.1 on L2 VPNs) =
>
> PPVPN  GENERIC  = REQUIREMENTS - 10 min - Ananth Nagarajan
> umbrella requirements common to = L3 and L2 VPNs  (agreed  in
> Yokohama) 
> = draft-nagarajan-ppvpn-generic-reqts-01.txt 
>
> L3 PPVPN
> - CE-to-CE authentication for = RFC2547 PPVPNs - 5 min - Ron Bonica
> Update, issues - = draft-ietf-ppvpn-l3vpn-auth-01.txt
> - CE autoconfiguration - 5 min - = Cheng-Yin  Lee
> update, categorization of = mechanisms, intra-domain and
> inter-domain = auto-provisioning
> = draft-lee-ppvpn-ce-auto-config-02.txt
> - IPsec Protected Virtual Links = for PPVPNs - 10 min - Mark Duffy
> approach for virtual links with = (or without) IPsec, value and
> applicability context, = issues,  future steps
> = draft-duffy-ppvpn-ipsec-vlink-00.txt
> - Multiple Instances of OSPF for = the PE/CE protocol in
> BGP/MPLS - 10 min - Kunihiro = Ishiguro
> overview, comparison with = other  proposal, issues, future
> steps. Relation with planned = progress of 2547. 
> = draft-ishiguro-ppvpn-pe-ce-ospf-01.txt
>
> L2 PPVPN
> - L2 requirements - 10 min - = Yetik Serbest
> Update, issues, future steps. =
> = draft-augustyn-ppvpn-l2vpn-requirements-01.txt
> - L2 framework and L2 DT report = - 20 min - L. Andersson, E.
> Rosen, M. Suzuki, N. Finn =
> Update, service and reference = model (problem, team
> discussion), cooperation with = IEEE 802, issues and future
> steps. Progress in solution = space.
> = draft-andersson-ppvpn-l2-framework-02.txt,
> = draft-andersson-ppvpn-terminology-02.txt 
> - CE-based VPLS - 5 min - = Cheng-Yin Lee
> Update, list discussion on work = partitioning (Tunnel Endpoint
> Discovery, L2TPV3  = specifics), future steps
> draft-lee-ce-based-vpl-01.txt =
> - LDP-based Signaling for = L2VPNs  - 10  min - Eric Rosen
> update, proposal' s value = and  positioning among L2 (VPN)
> signaling schemes, how/where it = should be progressed,
> relation with L2 solution = documents, future steps
> = draft-rosen-ppvpn-l2-signaling-02.txt
> - Virtual Hierarchical LAN = Services -  5 min - Arnold Sodder
> positioning and value in = solution space, mac-in-mac frame
> overview,  issues, how and = where to progress this  
> = draft-sodder-ppvpn-vhls-01.txt
> - GVPLS/LPE - Generic VPLS = Solution based on LPE Framework  -
> 10 min - Dinesh  Mohan =
> positioning and value in = solution space, issues, future steps
> = draft-radoaca-ppvpn-gvpls-00.txt
> - VPLS based on IP = Multicast   - 5 min -  Ali Sajassi
> positioning and value in = solution space, issues, future  steps
> = draft-sajassi-mvpls-00.txt
>
> L2 PPVPN interworking  - = positioning  and value, issues, how
> to progress from now  =
> -  = draft-sajassi-l2vpn-interworking-00.txt   - 5  min  = - Ali  Sajassi
> -  = draft-moreels-multiproto-mpls-00.txt  - 5 min  -  = Jeremy  De Clercq
>
> - IP over LAN Service (IPLS) - = 10 min - Himanshu Shah   
> positioning and value in = solution space, issues, future steps
> = draft-shah-ppvpn-ipls-00.txt
>
> CONCLUSION - 5 min - chairs =
> Recap of main open issues and = work items, team work, expected
> deliverables
>
> Just if time allows :
> - IPv6 for Large Access = Providers - 5 min -  Weijing Chen
> positioning and value for PPVPN = (problems addressed), issues,
> future steps
> = draft-allen-lap-ipv6-00.txt
> - BGP-MPLS VPN extension for = IPv6 VPN - 5 min  - Francois Le Faucheur
> Update, next steps  - = draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt

------_=_NextPart_001_01C28BF1.4EADD6F0-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 14 16:27: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 QAA01409 for ; Thu, 14 Nov 2002 16:27:04 -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 gAELT6n29295 for ; Thu, 14 Nov 2002 16:29: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 gAELT3j19466 for ; Thu, 14 Nov 2002 16:29:04 -0500 (EST) Date: Thu, 14 Nov 2002 16:27:56 -0500 (EST) From: Scott Bradner Message-Id: <200211142127.gAELRuaq002839@newdev.harvard.edu> To: ppvpn@nortelnetworks.com Subject: liaison statement from the ITU 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: please see http://www.ietf.org/IESG/LIAISON/COM13-LS35.htm Scott From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 14 19:13:33 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 TAA09654 for ; Thu, 14 Nov 2002 19:13:33 -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 gAF0FWn23165 for ; Thu, 14 Nov 2002 19:15:33 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gAF0FSj27929 for ; Thu, 14 Nov 2002 19:15:29 -0500 (EST) From: "Jim Guichard" To: "Miao Fuyou" , =?gb2312?B?Jz8/qKw/oaehpz8/P6HsP6ioPz+orD8n?= Cc: Subject: =?gb2312?B?UkU6ILTwuLQ6ILTwuLQ6ILTwuLQ6IFBsZWFzZSBSZXZpZXc6IEEgbg==?= =?gb2312?B?ZXcgZHJhZnQgYWJvdXQgUFBWUE4oSGliZXJhcmNoeSBvZiBQRSBEZQ==?= =?gb2312?B?dmljZSBpbkJHUC9NUExTIFZQTik=?= Date: Thu, 14 Nov 2002 19:10:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <000001c28af0$011913c0$2e426e0a@HUAWEI.COM> X-MIME-Autoconverted: from 8bit to quoted-printable by cisco.com id AAA12998 X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: london2.cisco.com [64.103.110.74] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA09654 Hi Miao, > >-----Original Message----- > >From: Miao Fuyou [mailto:miaofy@huawei.com] > >Sent: Wednesday, November 13, 2002 3:38 AM > >To: 'Jim Guichard'; '?¡ì?¨¨??¡§¡è?¡ì?' > >Cc: ppvpn@nortelnetworks.com > >Subject: RE: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > > > > > >Hi, Jim: > > > >As per my understanding, your primary concern is routes. Actually the > >problem is very similiar to the one in H&S topology, in which VPN > >network views are not available at spoke site. Sure, the sites connected > >by HoPE have not whole view of network, but the question is: really the > >customer want to know that? and the answer is, sometimes yes, sometimes no. The point is that H&S can provide this topology if really required, and is indeed deployed in several networks that I have worked on. Anyway, for L3VPN, routing is an add-value > >service provided by SP to customer. Sometimes customer concerns VPN > >topology, however, such function/service can be provided by Customer > >Network Management, which is more convinient to customer. sorry, but I do not get the point you are making ? > > > >Note that HoPE works under specific network environment to meet specific > >requirement, it's not cure-all. exactly. However, it's happy to find that most > >network are planned and setup with a hierachical topology, and where > >HoPE can works best. I would suggest that most networks are NOT built this way - hierarchy in general is a good thing, I would not argue against this. However, the type of hierarchy you are describing is most advantageous to the SP and not the customer as it introduces a number of complications as I described in my prior email .. Jim > > > >Regard > >Miao > > > > > >-----Original Message----- > >From: Jim Guichard [mailto:jguichar@cisco.com] > >Sent: Monday, November 11, 2002 9:39 PM > >To: Miao Fuyou; '?¡ì?¨¨??¡§¡è?¡ì?' > >Cc: ppvpn@nortelnetworks.com > >Subject: RE: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > > > > > >Hi Miao, > > > > > > > >> >-----Original Message----- > >> >From: Miao Fuyou [mailto:miaofy@huawei.com] > >> >Sent: Saturday, November 09, 2002 4:01 AM > >> >To: 'Jim Guichard'; '¡§¡è??¨¤¡§?' > >> >Cc: ppvpn@nortelnetworks.com > >> >Subject: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >> >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > >> > > >> > > >> > > >> >Hi, Jim: > >> > > >> >Please find my commnets inline! > >> > > >> >Regards > >> >-----ÓʼþÔ­¼þ----- > >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 23:29 > >> >ÊÕ¼þÈË: ???¡ê¨®?; '¡§¡è??¨¤¡§?' > >> >³­ËÍ: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; > >> >leh10814@huawei.com > >> >Ö÷Ìâ: RE: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy > >> >of PE Device inBGP/MPLS VPN) > >> > > >> > > >> >Hi Miao, > >> > > >> >I understand that this is not a replacement to 2547. I also > >> >understand that hierarchy is one of the tools we have to help scale > >> >networks. However, what I am driving at is that 2547 provides all of > >> >the necessary mechanisms already to run this type of topology - > >> >deployment of 2547 is a matter of design and no new functionality is > >> >necessary to be able to run the topology you are suggesting. We have > >> >many deployments worldwide that already use this type of design to > >> >provide central services to their customers. This does not mean > >> >however that the topology is appropriate for all 2547 customers. > >> >There are a number of issues with the proposed topology that one > >> >might consider: > >> > > >> >Miao: Actually it's not a problem of topology, it's for the planning > >> >and design of the network. If 2547 alone can work under for every > >> >network and meet all the VPN requirement, why were VPLS, Martini VPN, > > > >> >Kompella VPN and many others proposed? > > > >well VPLS, Martini and Kompella are talking about layer-2 application - > >we are talking about layer-3 here which is a little different wouldn't > >you agree ? > > > >> > > >> >1. In most real world deployments the number of hops between UPE and > >> >SPE will be > 1. This may introduce unacceptable latency and so on, > >> >especially as the design is being used for transit traffic rather > >> >than central services. > >> > > >> >Miao: I don't think hops > 1 brings more latency if a packet must go > >> >from an ingress PE to an egress PE. Actually it follows almost the > >> >same route that 2547 one will do if the network is not very careless > >> >designed. > > > >well I think it is fair to say that if you attract traffic to a > >particular point of the network then the optimal path from an routing > >perspective is more likely to be overlooked - this is not always the > >case but you cannot assume in an architecture that all networks are > >built the same. > > > >> > > >> >2. Using this method introduces additional IP address lookups between > > > >> >ingress PE and egress PE, plus label disposition/imposition. > >> > > >> >Miao: It's a ONCE-FOR-ALL work for a site, so the effort is trivial > > > >maybe I misunderstood your description but if the hub has to route > >inter-site traffic then we must remove the label stack, look at the IP > >address and then send it back on its way - this is a per-packet exercise > >not per-site. > > > >> > > >> >3. Unless the SPE is located locally to the UPE then the regional VPN > > > >> >traffic will be concentrated toward certain points of the network, > >> >instead of being distributed across the whole infrastructure. > >> > > >> >Miao: UPE can process it locally in such case, no SPE involved > > > >how can it if it does not have the routes ? if it has the routes then we > >have 2547 no ? > > > >> > > >> >4. If the SPE is located locally, then aggregates can be injected > >> >down to the UPEs but this is assuming that the address space is > >> >designed in such a way as to allow this aggregation. Most Enterprise > >> >networks today do not have such a well structured addressing plan. > >> > > >> >Miao: Refer item 3 > > > >so item 3 says there is no aggregation and the scheme is rendered > >useless. > > > >> > > >> >5. By injecting aggregates toward the CE site you change the > >> >customers routing view which may actually require the injection of > >> >more specific routes. > >> > > >> >Miao: No aggretes injected in HoPE actually > > > >well if it is just default route the same comment applies and is > >actually even worse. > > > >> > > >> >6. The SP has to keep track of the aggregation and configure it > >> >appropriately at the SPE. > >> > > >> >Miao: SPE will do > > > >how ? there are many ways to generate such an aggregate, each of which > >have their own implications. > > > >> > > >> >7. How do you take care of customers that want to run OSPF or ISIS on > > > >> >the PE-CE links ? how would sham-links work for example ? > >> > > >> >Miao: Only default route is needed in HoPE at PE-CE links, so why to > >> >run OSPF & IS-IS? > > > >default is not sufficient for most customers - a large subset of > >Internet customers today want more than just default route. OSPF, ISIS, > >EIGRP and so on were introduced so as to avoid changing the routing view > >of the end customers - this is a desired requirement that HoPE does not > >service. > > > >> > > >> >8. To deploy H&S designs one must use different RTs for the same VPN > >> >and then apply policy to filter correctly. This may not be such a big > > > >> >deal but is a further complication in the provisioning and management > > > >> >process. > >> > > >> >Miao: Repeat, it's not a problem of topology, not to say H&S > >> > > >> >9. If our goal is to offload the edge routers from having to carry > >> >VPNv4 routes or run MP-BGP sessions then perhaps we should use the > >> >L2-transport functionality in MPLS to carry the edge traffic to an > >> >SPE. This has the advantage that the CE can exchange routes directly > >> >with the SPE which is useful for other applications. > >> > > >> >Miao: L2-transport is not always applicable. CEs don't always run > >> >MPLS. > > > >CEs do not need to run MPLS to run L2-transport - the PEs do the > >L2-transport. > > > >> > > >> >10. How do you take care of customers that want to run Carrier's > >> >Carrier architecture ? > >> > > >> >Miao: But, what is the problem? > > > >the problem is that you cannot run an end-to-end LSP to allow this type > >of architecture to work .. > > > >regards, > > > >> > > >> > > >> >regards, > >> > > >> > > >> >> >-----Original Message----- > >> >> >From: Ã縣ÓÑ [mailto:miaofy@huawei.com] > >> >> >Sent: Thursday, November 07, 2002 9:07 PM > >> >> >To: 'Jim Guichard'; '¨¤?¡À¨®' > >> >> >Cc: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; > >> >> >leh10814@huawei.com > >> >> >Subject: ´ð¸´: ´ð¸´: Please Review: A new draft about > >> >PPVPN(Hiberarchy of > >> >> >PE Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> >Hi, Jim: > >> >> > > >> >> >This draft is not to replace 2547, but a supplement to it. > >> >> >Actually the VPN in the draft is completely works under the > >> >> >mechanism of 2547. > >> >> > > >> >> >In the traditional 2547 VPN, only one type of PE is defined. When > >> >> >deployment, PE will not has so many ports to attach many VPNs if > >> >> >the PE is at the core layer of the network, because core router > >> >> >generally > >> > > >> >> >doesn't have a lot of physically interfaces. If the PE is at the > >> >> >edge of the network, it will have a lot of interfaces, but now the > > > >> >> >botlleneck is capacity of computation of the router. > >> >> > > >> >> >This draft is to solve the problem, UPE will provide abundant > >> >> >interface to conenct sites to VPN and SPE will have enough > >> >> >CPU/Memory > >> > > >> >> >to process routes. > >> >> > > >> >> >Regards > >> >> >Miao > >> >> > > >> >> >-----ÓʼþÔ­¼þ----- > >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 > >> >> >ÊÕ¼þÈË: ¨¤?¡À¨® > >> >> >³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco Carugi; > > > >> >> >sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; > >> >> >ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; > >> >> >changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com > >> >> >Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy > >of > >> >PE > >> >> >Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> >so can hub&spoke with 2547 - you basically export routes from the > >> >> >CE-attached PEs to a hub PE that imports the routes. The hub PE > >> >> >exports either a default or aggregates to attract traffic from > >> >> >other CE-attached PEs and then performs a lookup to forward the > >> >> >packets to other CE-attached PEs .. Jim > >> >> > > >> >> >> >-----Original Message----- > >> >> >> >From: Àî±ó [mailto:l.b@huawei.com] > >> >> >> >Sent: Thursday, November 07, 2002 2:42 AM > >> >> >> >To: Jim Guichard > >> >> >> >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >> >> >> >marco.carugi@nortelnetworks.com; sob@harvard.edu; > >> >> >> >bwijnen@lucent.com; > >> >> > > >> >> >> >zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; > >> >> >> >Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >> >> >> >leh10814@huawei.com > >> >> >> >Subject: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy > >> >of > >> >> >PE > >> >> >> >Device inBGP/MPLS VPN) > >> >> >> > > >> >> >> > > >> >> >> >Hi, Guichard > >> >> >> >The hub & spoke is the relationship between CEs, but SPE peer > >> >> >> >with > >> > > >> >> >> >UPE by MP-BGP, they are all PEs, and they all can admit VPN > >> >> >> >user. > >> >> >> > > >> >> >> >Libin > >> >> >> > > >> >> >> >-----ԭʼÓʼþ----- > >> >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >> >> >> >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >> >> >> >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > >> >> >> >Miao; leh10814@huawei. com; l.b@huawei.com > >> >> >> >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of > >PE > >> >> >> >Device inBGP/MPLS VPN) > >> >> >> > > >> >> >> > > >> >> >> >I briefly ran through this draft and it looks like normal hub & > > > >> >> >> >spoke > >> >> > > >> >> >> >using existing 2547 mechanisms - could you explain how this > >> >> >> >differs ? > >> >> > > >> >> >> >thanks, > >> >> >> > > >> >> >> >> >-----Original Message----- > >> >> >> >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >> >> >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >> >> >> >To: internet-drafts@ietf.org > >> >> >> >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > > > >> >> >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. > > > >> >> >> >> >Miao; > >> >> > > >> >> >> >> >leh10814@huawei.com; l.b@huawei.com > >> >> >> >> >Subject: Please Review: A new draft about PPVPN(Hiberarchy > >> >> >> >> >of PE Device in BGP/MPLS VPN) > >> >> >> >> > > >> >> >> >> > > >> >> >> >> >Hi,all, > >> >> >> >> > > >> >> >> >> > In BGP/MPLS VPN area, we proposed a new idea as to > >> >> >> >> >resolve the bottleneck of the capacity of some PEs when > >> >> >> >> >deploy the huge > >> > > >> >> >> >> >size VPN,the > >> >> >> >whole idea is > >> >> >> >> >detailed > >> >> >> >> >in the attached > >> >> >> >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the > >> >> >> >> >Abstract is as follows,we are appreciated for your review. > >> >> >> >> > > >> >> >> >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >> >> >> >Edge)Device should > >> >> >> >> > maintain all the VPN routes of the VPNs which it belong > >> >> >> >to.When there > >> >> >> >> > are many VPNs converged by a PE,and the capacity of PE is > >> >> >relevant > >> >> >> >> > limited,then the bottleneck will be encountered.Another > >> >> >> >> > problem > >> >> >is > >> >> >> >> > that the current BGP/MPLS VPN model is something of a > >> >> >> >> > "Plane > >> >> >Modle" > >> >> >> >> > where the demand of the performance of the PE device are > >> >> >> >> > all > >> >> >the > >> >> >> >> > same no matter which layer the PE device is belongs > >> >> >> >> > to.However, > >> >> >the > >> >> >> >> > typical network is "Core-Convergence-Access(Edge)" > >> >> >> >> > model,and > >> >> >the > >> >> >> >> > performance of the device is superior in Core Layer and > >> >> >inferior in > >> >> >> >> > Access Layer,and the scale of network is large in Access > >> >> >> >> > Layer > >> >> >and > >> >> >> >> > small in Core Layer,the routes are converged in every > >> >> >> >> > layer,so > >> >> >in > >> >> >> >> > current "Plane Modle",when PE device push to the edge > >> >> >> >> > layer,it > >> >> >has > >> >> >> >> > to maintain more VPN routes,this makes it difficult to > >> >> >> >extend the PE > >> >> >> >> > device to edge layer.This document defines an model of > >> >> >> >hiberarchy of > >> >> >> >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy of > >> >> >Provider > >> >> >> >> > Edge Device can be composed of several device and every > >> >> >> >> > device > >> >> >take > >> >> >> >> > on the different part,partake the function of the former > >> >> >> >> > concentrative PE,we call this model "Hiberarchy Model",In > >> >> >> >this model > >> >> >> >> > the demand of performance in Routing and Switching is > >> >> >> >> > strict > >> > > >> >> >> >> > to > >> >> >the > >> >> >> >> > PE device in High layer,loose to the PE device in edge > >> >> >> >> > layer. > >> >> >> >> > > >> >> >> >> > One HoPE can be composed of a SPE and UPES connected to > >> >> >> >> > the > >> >> >SPE, > >> >> >> >> > or be composed of a high-level SPE and HoPEs connected > >> >> >> >> > the > >> >high > >> >> >> >> > level SPE and and build up a new HoPE.This build is > >> >> >> >> > called > >> >> >nesting > >> >> >> >> > of HoPE,and this kind of nesting can be done for many > >> >> >> >times.Thus the > >> >> >> >> > former HoPE connect to the high-level SPE as a role of > >> >> >> >> > UPE,and > >> >> >the > >> >> >> >> > new HoPE can connect a single UPE too. > >> >> >> >> > > >> >> >> >> >Regards > >> >> >> >> > > >> >> >> >> >Defeng Li > >> >> >> >> > > >> >> > > >> >> > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 14 20:33: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 UAA12675 for ; Thu, 14 Nov 2002 20:33: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 gAF1Z6n04648 for ; Thu, 14 Nov 2002 20:35: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 gAF1Z3j25308 for ; Thu, 14 Nov 2002 20:35:03 -0500 (EST) Date: Fri, 15 Nov 2002 09:35:06 +0800 From: Miao Fuyou Subject: RE:Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) In-reply-to: To: "'Jim Guichard'" , =?gb2312?B?Jz8/qKw/oaehpz8/P6HsP6ioPz+orD8n?= Cc: ppvpn@nortelnetworks.com Message-id: <000c01c28c47$3ac74620$2e426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: miaofy@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA12675 Hi, Jim: See my comments inline! Regards -----Original Message----- From: Jim Guichard [mailto:jguichar@cisco.com] Sent: Friday, November 15, 2002 8:10 AM To: Miao Fuyou; '??¨¬?¡§¡§???¡ì?¨¨??¨¬?' Cc: ppvpn@nortelnetworks.com Subject: RE: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) Hi Miao, > >-----Original Message----- > >From: Miao Fuyou [mailto:miaofy@huawei.com] > >Sent: Wednesday, November 13, 2002 3:38 AM > >To: 'Jim Guichard'; '?¡ì?¨¨??¡§¡è?¡ì?' > >Cc: ppvpn@nortelnetworks.com > >Subject: RE: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > > > > > >Hi, Jim: > > > >As per my understanding, your primary concern is routes. Actually the > >problem is very similiar to the one in H&S topology, in which VPN > >network views are not available at spoke site. Sure, the sites > >connected by HoPE have not whole view of network, but the question > >is: really the customer want to know that? and the answer is, sometimes yes, sometimes no. The point is that H&S can provide this topology if really required, and is indeed deployed in several networks that I have worked on. In HoPE, the spoke is UPE, contrastively the spoke is site/CE in H&S. It makes difference, even if the topologies are similiar. Anyway, for L3VPN, routing is an add-value > >service provided by SP to customer. Sometimes customer concerns VPN > >topology, however, such function/service can be provided by Customer > >Network Management, which is more convinient to customer. sorry, but I do not get the point you are making ? I mean that routes of VPN are not necesssary to be known by each sites > > > >Note that HoPE works under specific network environment to meet > >specific requirement, it's not cure-all. exactly. However, it's happy to find that most > >network are planned and setup with a hierachical topology, and where > >HoPE can works best. I would suggest that most networks are NOT built this way - hierarchy in general is a good thing, I would not argue against this. However, the type of hierarchy you are describing is most advantageous to the SP and not the customer as it introduces a number of complications as I described in my prior email .. Jim Agree, actually the solution is most suitable for huge network, such as SP and gov network, and such networks are what we concern most. > > > >Regard > >Miao > > > > > >-----Original Message----- > >From: Jim Guichard [mailto:jguichar@cisco.com] > >Sent: Monday, November 11, 2002 9:39 PM > >To: Miao Fuyou; '?¡ì?¨¨??¡§¡è?¡ì?' > >Cc: ppvpn@nortelnetworks.com > >Subject: RE: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > > > > > >Hi Miao, > > > > > > > >> >-----Original Message----- > >> >From: Miao Fuyou [mailto:miaofy@huawei.com] > >> >Sent: Saturday, November 09, 2002 4:01 AM > >> >To: 'Jim Guichard'; '¡§¡è??¨¤¡§?' > >> >Cc: ppvpn@nortelnetworks.com > >> >Subject: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >> >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > >> > > >> > > >> > > >> >Hi, Jim: > >> > > >> >Please find my commnets inline! > >> > > >> >Regards > >> >-----ÓʼþÔ­¼þ----- > >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 23:29 > >> >ÊÕ¼þÈË: ???¡ê¨®?; '¡§¡è??¨¤¡§?' > >> >³­ËÍ: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; > >> >leh10814@huawei.com > >> >Ö÷Ìâ: RE: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy > >> >of PE Device inBGP/MPLS VPN) > >> > > >> > > >> >Hi Miao, > >> > > >> >I understand that this is not a replacement to 2547. I also > >> >understand that hierarchy is one of the tools we have to help > >> >scale networks. However, what I am driving at is that 2547 > >> >provides all of the necessary mechanisms already to run this type > >> >of topology - deployment of 2547 is a matter of design and no new > >> >functionality is necessary to be able to run the topology you are > >> >suggesting. We have many deployments worldwide that already use > >> >this type of design to provide central services to their > >> >customers. This does not mean however that the topology is > >> >appropriate for all 2547 customers. There are a number of issues > >> >with the proposed topology that one might consider: > >> > > >> >Miao: Actually it's not a problem of topology, it's for the > >> >planning and design of the network. If 2547 alone can work under > >> >for every network and meet all the VPN requirement, why were VPLS, > >> >Martini VPN, > > > >> >Kompella VPN and many others proposed? > > > >well VPLS, Martini and Kompella are talking about layer-2 application > >- we are talking about layer-3 here which is a little different > >wouldn't you agree ? > > > >> > > >> >1. In most real world deployments the number of hops between UPE > >> >and SPE will be > 1. This may introduce unacceptable latency and > >> >so on, especially as the design is being used for transit traffic > >> >rather than central services. > >> > > >> >Miao: I don't think hops > 1 brings more latency if a packet must > >> >go from an ingress PE to an egress PE. Actually it follows almost > >> >the same route that 2547 one will do if the network is not very > >> >careless designed. > > > >well I think it is fair to say that if you attract traffic to a > >particular point of the network then the optimal path from an routing > >perspective is more likely to be overlooked - this is not always the > >case but you cannot assume in an architecture that all networks are > >built the same. > > > >> > > >> >2. Using this method introduces additional IP address lookups > >> >between > > > >> >ingress PE and egress PE, plus label disposition/imposition. > >> > > >> >Miao: It's a ONCE-FOR-ALL work for a site, so the effort is > >> >trivial > > > >maybe I misunderstood your description but if the hub has to route > >inter-site traffic then we must remove the label stack, look at the > >IP address and then send it back on its way - this is a per-packet > >exercise not per-site. > > > >> > > >> >3. Unless the SPE is located locally to the UPE then the regional > >> >VPN > > > >> >traffic will be concentrated toward certain points of the network, > >> >instead of being distributed across the whole infrastructure. > >> > > >> >Miao: UPE can process it locally in such case, no SPE involved > > > >how can it if it does not have the routes ? if it has the routes then > >we have 2547 no ? > > > >> > > >> >4. If the SPE is located locally, then aggregates can be injected > >> >down to the UPEs but this is assuming that the address space is > >> >designed in such a way as to allow this aggregation. Most > >> >Enterprise networks today do not have such a well structured > >> >addressing plan. > >> > > >> >Miao: Refer item 3 > > > >so item 3 says there is no aggregation and the scheme is rendered > >useless. > > > >> > > >> >5. By injecting aggregates toward the CE site you change the > >> >customers routing view which may actually require the injection of > >> >more specific routes. > >> > > >> >Miao: No aggretes injected in HoPE actually > > > >well if it is just default route the same comment applies and is > >actually even worse. > > > >> > > >> >6. The SP has to keep track of the aggregation and configure it > >> >appropriately at the SPE. > >> > > >> >Miao: SPE will do > > > >how ? there are many ways to generate such an aggregate, each of > >which have their own implications. > > > >> > > >> >7. How do you take care of customers that want to run OSPF or ISIS > >> >on > > > >> >the PE-CE links ? how would sham-links work for example ? > >> > > >> >Miao: Only default route is needed in HoPE at PE-CE links, so why > >> >to run OSPF & IS-IS? > > > >default is not sufficient for most customers - a large subset of > >Internet customers today want more than just default route. OSPF, > >ISIS, EIGRP and so on were introduced so as to avoid changing the > >routing view of the end customers - this is a desired requirement > >that HoPE does not service. > > > >> > > >> >8. To deploy H&S designs one must use different RTs for the same > >> >VPN and then apply policy to filter correctly. This may not be > >> >such a big > > > >> >deal but is a further complication in the provisioning and > >> >management > > > >> >process. > >> > > >> >Miao: Repeat, it's not a problem of topology, not to say H&S > >> > > >> >9. If our goal is to offload the edge routers from having to carry > >> >VPNv4 routes or run MP-BGP sessions then perhaps we should use the > >> >L2-transport functionality in MPLS to carry the edge traffic to an > >> >SPE. This has the advantage that the CE can exchange routes > >> >directly with the SPE which is useful for other applications. > >> > > >> >Miao: L2-transport is not always applicable. CEs don't always run > >> >MPLS. > > > >CEs do not need to run MPLS to run L2-transport - the PEs do the > >L2-transport. > > > >> > > >> >10. How do you take care of customers that want to run Carrier's > >> >Carrier architecture ? > >> > > >> >Miao: But, what is the problem? > > > >the problem is that you cannot run an end-to-end LSP to allow this > >type of architecture to work .. > > > >regards, > > > >> > > >> > > >> >regards, > >> > > >> > > >> >> >-----Original Message----- > >> >> >From: Ã縣ÓÑ [mailto:miaofy@huawei.com] > >> >> >Sent: Thursday, November 07, 2002 9:07 PM > >> >> >To: 'Jim Guichard'; '¨¤?¡À¨®' > >> >> >Cc: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; > >> >> >leh10814@huawei.com > >> >> >Subject: ´ð¸´: ´ð¸´: Please Review: A new draft about > >> >PPVPN(Hiberarchy of > >> >> >PE Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> >Hi, Jim: > >> >> > > >> >> >This draft is not to replace 2547, but a supplement to it. > >> >> >Actually the VPN in the draft is completely works under the > >> >> >mechanism of 2547. > >> >> > > >> >> >In the traditional 2547 VPN, only one type of PE is defined. > >> >> >When deployment, PE will not has so many ports to attach many > >> >> >VPNs if the PE is at the core layer of the network, because > >> >> >core router generally > >> > > >> >> >doesn't have a lot of physically interfaces. If the PE is at > >> >> >the edge of the network, it will have a lot of interfaces, but > >> >> >now the > > > >> >> >botlleneck is capacity of computation of the router. > >> >> > > >> >> >This draft is to solve the problem, UPE will provide abundant > >> >> >interface to conenct sites to VPN and SPE will have enough > >> >> >CPU/Memory > >> > > >> >> >to process routes. > >> >> > > >> >> >Regards > >> >> >Miao > >> >> > > >> >> >-----ÓʼþÔ­¼þ----- > >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 > >> >> >ÊÕ¼þÈË: ¨¤?¡À¨® > >> >> >³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco > >> >> >Carugi; > > > >> >> >sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; > >> >> >ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; > >> >> >changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com > >> >> >Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about PPVPN(Hiberarchy > >of > >> >PE > >> >> >Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> >so can hub&spoke with 2547 - you basically export routes from > >> >> >the CE-attached PEs to a hub PE that imports the routes. The > >> >> >hub PE exports either a default or aggregates to attract > >> >> >traffic from other CE-attached PEs and then performs a lookup > >> >> >to forward the packets to other CE-attached PEs .. Jim > >> >> > > >> >> >> >-----Original Message----- > >> >> >> >From: Àî±ó [mailto:l.b@huawei.com] > >> >> >> >Sent: Thursday, November 07, 2002 2:42 AM > >> >> >> >To: Jim Guichard > >> >> >> >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >> >> >> >marco.carugi@nortelnetworks.com; sob@harvard.edu; > >> >> >> >bwijnen@lucent.com; > >> >> > > >> >> >> >zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; > >> >> >> >Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >> >> >> >leh10814@huawei.com > >> >> >> >Subject: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy > >> >of > >> >> >PE > >> >> >> >Device inBGP/MPLS VPN) > >> >> >> > > >> >> >> > > >> >> >> >Hi, Guichard > >> >> >> >The hub & spoke is the relationship between CEs, but SPE > >> >> >> >peer with > >> > > >> >> >> >UPE by MP-BGP, they are all PEs, and they all can admit VPN > >> >> >> >user. > >> >> >> > > >> >> >> >Libin > >> >> >> > > >> >> >> >-----ԭʼÓʼþ----- > >> >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >> >> >> >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >> >> >> >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu > >> >> >> >Y. Miao; leh10814@huawei. com; l.b@huawei.com > >> >> >> >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy of > >PE > >> >> >> >Device inBGP/MPLS VPN) > >> >> >> > > >> >> >> > > >> >> >> >I briefly ran through this draft and it looks like normal > >> >> >> >hub & > > > >> >> >> >spoke > >> >> > > >> >> >> >using existing 2547 mechanisms - could you explain how this > >> >> >> >differs ? > >> >> > > >> >> >> >thanks, > >> >> >> > > >> >> >> >> >-----Original Message----- > >> >> >> >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >> >> >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >> >> >> >To: internet-drafts@ietf.org > >> >> >> >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >> >> >bwijnen@lucent.com; zinin@psg.com; > >> >> >> >> >ppvpn@nortelnetworks.com; > > > >> >> >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu > >> >> >> >> >Y. > > > >> >> >> >> >Miao; > >> >> > > >> >> >> >> >leh10814@huawei.com; l.b@huawei.com > >> >> >> >> >Subject: Please Review: A new draft about > >> >> >> >> >PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) > >> >> >> >> > > >> >> >> >> > > >> >> >> >> >Hi,all, > >> >> >> >> > > >> >> >> >> > In BGP/MPLS VPN area, we proposed a new idea as to > >> >> >> >> >resolve the bottleneck of the capacity of some PEs when > >> >> >> >> >deploy the huge > >> > > >> >> >> >> >size VPN,the > >> >> >> >whole idea is > >> >> >> >> >detailed > >> >> >> >> >in the attached > >> >> >> >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and > >> >> >> >> >the Abstract is as follows,we are appreciated for your > >> >> >> >> >review. > >> >> >> >> > > >> >> >> >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >> >> >> >Edge)Device should > >> >> >> >> > maintain all the VPN routes of the VPNs which it > >> >> >> >> > belong > >> >> >> >to.When there > >> >> >> >> > are many VPNs converged by a PE,and the capacity of PE > >> >> >> >> > is > >> >> >relevant > >> >> >> >> > limited,then the bottleneck will be > >> >> >> >> > encountered.Another problem > >> >> >is > >> >> >> >> > that the current BGP/MPLS VPN model is something of a > >> >> >> >> > "Plane > >> >> >Modle" > >> >> >> >> > where the demand of the performance of the PE device > >> >> >> >> > are all > >> >> >the > >> >> >> >> > same no matter which layer the PE device is belongs > >> >> >> >> > to.However, > >> >> >the > >> >> >> >> > typical network is "Core-Convergence-Access(Edge)" > >> >> >> >> > model,and > >> >> >the > >> >> >> >> > performance of the device is superior in Core Layer > >> >> >> >> > and > >> >> >inferior in > >> >> >> >> > Access Layer,and the scale of network is large in > >> >> >> >> > Access Layer > >> >> >and > >> >> >> >> > small in Core Layer,the routes are converged in every > >> >> >> >> > layer,so > >> >> >in > >> >> >> >> > current "Plane Modle",when PE device push to the edge > >> >> >> >> > layer,it > >> >> >has > >> >> >> >> > to maintain more VPN routes,this makes it difficult to > >> >> >> >extend the PE > >> >> >> >> > device to edge layer.This document defines an model of > >> >> >> >hiberarchy of > >> >> >> >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy > >> >> >> >> > of > >> >> >Provider > >> >> >> >> > Edge Device can be composed of several device and > >> >> >> >> > every device > >> >> >take > >> >> >> >> > on the different part,partake the function of the former > >> >> >> >> > concentrative PE,we call this model "Hiberarchy > >> >> >> >> > Model",In > >> >> >> >this model > >> >> >> >> > the demand of performance in Routing and Switching is > >> >> >> >> > strict > >> > > >> >> >> >> > to > >> >> >the > >> >> >> >> > PE device in High layer,loose to the PE device in edge > >> >> >> >> > layer. > >> >> >> >> > > >> >> >> >> > One HoPE can be composed of a SPE and UPES connected > >> >> >> >> > to the > >> >> >SPE, > >> >> >> >> > or be composed of a high-level SPE and HoPEs connected > >> >> >> >> > the > >> >high > >> >> >> >> > level SPE and and build up a new HoPE.This build is > >> >> >> >> > called > >> >> >nesting > >> >> >> >> > of HoPE,and this kind of nesting can be done for many > >> >> >> >times.Thus the > >> >> >> >> > former HoPE connect to the high-level SPE as a role of > >> >> >> >> > UPE,and > >> >> >the > >> >> >> >> > new HoPE can connect a single UPE too. > >> >> >> >> > > >> >> >> >> >Regards > >> >> >> >> > > >> >> >> >> >Defeng Li > >> >> >> >> > > >> >> > > >> >> > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 14 22:10:56 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15954 for ; Thu, 14 Nov 2002 22:10: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 gAF3Ctn18922 for ; Thu, 14 Nov 2002 22:12:56 -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 gAF3Crj25790 for ; Thu, 14 Nov 2002 22:12:53 -0500 (EST) Message-Id: <200211150312.gAF3CJE29151@zcars1ky.ca.nortel.com> Reply-To: <> From: <> To: ""<> Subject: ¿í´ø Date: Fri,15 Nov 2002 10:48:38 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Mail_Part_PPP_SMTP_01C11A5B.CEFD965"; type="multipart/alternative" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-SMTP-HELO: www4.chinadns.com X-SMTP-MAIL-FROM: qf@mingyunet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [211.154.211.73] X-LYRIS-Message-Id: ------=_Mail_Part_PPP_SMTP_01C11A5B.CEFD965 Content-Type: multipart/alternative; boundary="----=_Mail_Part_PPP_POP3_01C11A8E.4ECE36A0" ------=_Mail_Part_PPP_POP3_01C11A8E.4ECE36A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Íø¹º¡ª¡ª¹úÄÚ×îרҵµÄÍøÂç²úÆ·Ö±ÏúÍøÕ¾
Íø¹ºµç×ÓÉÌÎñ Ifnetworking ÎÒµÄÕÊ»§  ¹ºÎï³µ  ½áÕÊ  
  É̵êÊ×Ò³ » ÉÌƷĿ¼ » ¿í´øÉ豸 ÍøÂçÂÛ̳ |  ÎÒµÄÕÊ»§  |  ¹ºÎï³µ  |  ½áÕÊ   
ÉÌƷĿ¼
¼¯ÏßÆ÷-> (16)
½»»»»ú-> (142)
·ÓÉÆ÷-> (40)
Íø¿¨-> (37)
¿í´øÉ豸-> (27)
  ¿í´ø·ÓÉÆ÷ (25)
  Cable Modem/·ÓÉ (1)
  DSL Modem/·ÓÉ (1)
ÎÞÏßÍøÂç-> (56)
´òÓ¡·þÎñÆ÷-> (10)
ISDN¡¢Modem-> (15)
·À»ðǽ-> (10)
DTU/NTU (6)
²¼Ïß²úÆ·-> (142)
HomePNAÍøÂç-> (8)
µçÁ¦ÏßÍøÂç-> (4)
KVM¹²ÏíÆ÷-> (9)
´æ´¢Æ÷-> (7)
IPÉãÏó»ú-> (2)
ÍøÂçÈí¼þ-> (5)
³§ÉÌ
Ìؼ۲úÆ· ¸ü¶à
D-Link DES-3226 24¿Ú¿ÉÀ©Õ¹Ç§Õ×2²ãÍø¹Ü½»»»»ú
D-Link DES-3226 24¿Ú¿ÉÀ©Õ¹Ç§Õ×2²ãÍø¹Ü½»»»»ú
£¤7,000.00
£¤5,100.00
ÆÀÂÛ ¸ü¶à
Jaht WA-2204 4¿ÚÎÞÏß¿í´ø·ÓÉÆ÷
Ôõô¿ÉÄÜÕâô±ãÒË£¿ ..
5 ¿ÅÐÇ(×î¸ß5¿ÅÐÇ)
¿ìËÙ²éÕÒ
 
ÇëÊäÈë²úÆ·µÄ¹Ø¼ü´Ê¡£
¸ß¼¶ËÑË÷
ÐÅÏ¢
¿Í»§·þÎñ
¹ºÂò°ïÖú
¹ØÓÚÎÒÃÇ
ÁªÏµÎÒÃÇ
»íÃâÌõ¿î
µ÷ÊÔ¼¯³É
¼¯ÍÅÏû·Ñ
³§É̼ÓÃË
¹ã¸æºÏ×÷
ÐÅÓþ×ÊÖÊ
²úƷĿ¼ ¿í´øÉ豸
¿í´ø·ÓÉÆ÷
¿í´ø·ÓÉÆ÷		 Cable Modem/·ÓÉ
Cable Modem/·ÓÉ		 DSL Modem/·ÓÉ
DSL Modem/·ÓÉ

¾ÅÔµÄвúÆ·
D-Link DI-804 4¿Ú¿í´ø·ÓÉÆ÷
D-Link DI-804 4¿Ú¿í´ø·ÓÉÆ÷
£¤1,350.00		 D-Link DI-713P ´òÓ¡¹²ÏíÎÞÏß¿í´ø·ÓÉÆ÷
D-Link DI-713P ´òÓ¡¹²ÏíÎÞÏß¿í´ø·ÓÉÆ÷
£¤2,350.00		 Hardlink HB-1204 4¿Ú¿í´ø·ÓÉÆ÷
Hardlink HB-1204 4¿Ú¿í´ø·ÓÉÆ÷
£¤980.00
ifNetworking SAR-7104NW ÎÞÏß¿í´ø·ÓÉÆ÷
ifNetworking SAR-7104NW ÎÞÏß¿í´ø·ÓÉÆ÷
£¤2,100.00		 ifNetworking SSR-8104 °ÙÕ×WAN¿ÚVPN¿í´ø·ÓÉÆ÷
ifNetworking SSR-8104 °ÙÕ×WAN¿ÚVPN¿í´ø·ÓÉÆ÷
£¤2,700.00		 D-Link DI-707P 7¿Ú´òÓ¡¹²Ïí¿í´ø·ÓÉÆ÷
D-Link DI-707P 7¿Ú´òÓ¡¹²Ïí¿í´ø·ÓÉÆ÷
£¤1,500.00
D-Link DI-704P 4¿Ú´òÓ¡¹²Ïí¿í´ø·ÓÉÆ÷
D-Link DI-704P 4¿Ú´òÓ¡¹²Ïí¿í´ø·ÓÉÆ÷
£¤790.00		 D-Link DI-614+ 22MÎÞÏß4¿Ú¿í´ø·ÓÉÆ÷
D-Link DI-614+ 22MÎÞÏß4¿Ú¿í´ø·ÓÉÆ÷
£¤2,400.00		 ʵ´ï CMX2101 Cable Modem
ʵ´ï CMX2101 Cable Modem
£¤1,450.00
DrayTek Vigor2200X 4¿ÚISDN/¿í´ø·ÓÉÆ÷
DrayTek Vigor2200X 4¿ÚISDN/¿í´ø·ÓÉÆ÷
£¤3,200.00		 DrayTek Vigor2200 µ¥¿ÚISDN/¿í´ø·ÓÉÆ÷
DrayTek Vigor2200 µ¥¿ÚISDN/¿í´ø·ÓÉÆ÷
£¤3,000.00		 DrayTek Vigor2200E 4¿Ú¿í´ø·ÓÉÆ÷
DrayTek Vigor2200E 4¿Ú¿í´ø·ÓÉÆ÷
£¤2,000.00
¹ºÎï³µ ¸ü¶à
1 x AMP 504958 1-10Ã×ST-SC˫о¹âÌøÏߣ¨62.5/125£©
£¤270.00
×Ïú²úÆ·
01. Linksys BEFSR-81 ¿í´ø·ÓÉÆ÷
02. MAXGATE Ugate-3100 4¿Ú¿í´ø·ÓÉÆ÷
03. Jaht WA-2204 4¿ÚÎÞÏß¿í´ø·ÓÉÆ÷
04. Zyxel Prestige 642R ADSL Modem+·ÓÉÆ÷
05. DrayTek Vigor2000 6¿ÚISDN/ADSL·ÓÉÆ÷
06. ifNetworking SSR-8104 °ÙÕ×WAN¿ÚVPN¿í´ø·ÓÉÆ÷
07. Jate EA-2204 4¿Ú¿í´ø·ÓÉÆ÷
08. Linksys BEFW11S4 4¿ÚÎÞÏß¿í´ø·ÓÉÆ÷
09. MAXGATE Ugate-3200P 7¿Ú´òÓ¡¹²Ïí¿í´ø·ÓÉÆ÷
Ìؼ۲úÆ· ¸ü¶à
3COM 3CRWE62092A 11MÎÞÏ߱ʼDZ¾Íø¿¨
3COM 3CRWE62092A 11MÎÞÏ߱ʼDZ¾Íø¿¨
£¤1,220.00
£¤1,000.00
×îвúÆ·£¡ ¸ü¶à
¶«·½ 12оÊÒÄÚ¶àÄ£¹âÏË£¨1Ã×£©
¶«·½ 12оÊÒÄÚ¶àÄ£¹âÏË£¨1Ã×£©
£¤37.00
  2002Äê,¾ÅÔÂ19ÈÕ ÐÇÆÚËÄ     153640 ¸ö·ÃÎÊÁ¿ ×Ô´Ó 2002Äê,ÁùÔÂ21ÈÕ ÐÇÆÚÎå  

Copyright © 2002 Íø¹ºµç×ÓÉÌÎñ£¨Öйú£©ÓÐÏÞ¹«Ë¾ : ¹ÜÀíÔ±

×ܲ¿µØÖ·£ºÉϺ£ÊÐÌìɽ·600Ū3ºÅ˼´´´óÏÃÎ÷Â¥8Â¥    µç»°£º021-52896330
º¼ÖÝ·Ö¹«Ë¾£ºº¼ÖÝÊÐÎÄÈý·388ºÅÇ®½­¿Æ¼¼´óÏÃ1009-1011ÊÒ    µç»°£º0571-88211246 88211216 88211253
ÏúÊÛ¡¢·þÎñÁªÏµÐÅÏ䣺sale@netgo.com.cn

3COM Do It Myself

------=_Mail_Part_PPP_POP3_01C11A8E.4ECE36A0-- ------=_Mail_Part_PPP_SMTP_01C11A5B.CEFD965-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 14 22:58:20 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17317 for ; Thu, 14 Nov 2002 22:58:16 -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 gAF40Hn00330 for ; Thu, 14 Nov 2002 23:00:18 -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 gAF3sej10586 for ; Thu, 14 Nov 2002 22:54:40 -0500 (EST) Date: Fri, 15 Nov 2002 11:52:56 +0800 From: Miao Fuyou Subject: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) In-reply-to: <002e01c2854e$84f83ec0$22436e0a@HUAWEI.COM> To: ppvpn@nortelnetworks.com Message-id: <000001c28c5a$7bd50ae0$2e426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/mixed; boundary="Boundary_(ID_tBfXfRGAMpXzaBktuQdoaw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: miaofy@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_tBfXfRGAMpXzaBktuQdoaw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Dear All: Here I attached slides to adress the idea of hierarchical PE, wish it will be helpful for you to understand it! Best regards Miao -----Original Message----- From: lidefeng [mailto:lidefeng@huawei.com] Sent: Wednesday, November 06, 2002 12:40 PM To: internet-drafts@ietf.org Cc: rwilder@masergy.com; marco.carugi@nortelnetworks.com; sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com; l.b@huawei.com Subject: Please Review: A new draft about PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) Hi,all, In BGP/MPLS VPN area, we proposed a new idea as to resolve the bottleneck of the capacity of some PEs when deploy the huge size VPN,the whole idea is detailed in the attached draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and the Abstract is as follows,we are appreciated for your review. In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should maintain all the VPN routes of the VPNs which it belong to.When there are many VPNs converged by a PE,and the capacity of PE is relevant limited,then the bottleneck will be encountered.Another problem is that the current BGP/MPLS VPN model is something of a "Plane Modle" where the demand of the performance of the PE device are all the same no matter which layer the PE device is belongs to.However,the typical network is "Core-Convergence-Access(Edge)" model,and the performance of the device is superior in Core Layer and inferior in Access Layer,and the scale of network is large in Access Layer and small in Core Layer,the routes are converged in every layer,so in current "Plane Modle",when PE device push to the edge layer,it has to maintain more VPN routes,this makes it difficult to extend the PE device to edge layer.This document defines an model of hiberarchy of Provider Edge Device in BGP/MPLS VPN,where hiberarchy of Provider Edge Device can be composed of several device and every device take on the different part,partake the function of the former concentrative PE,we call this model "Hiberarchy Model",In this model the demand of performance in Routing and Switching is strict to the PE device in High layer,loose to the PE device in edge layer. One HoPE can be composed of a SPE and UPES connected to the SPE, or be composed of a high-level SPE and HoPEs connected the high level SPE and and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connect to the high-level SPE as a role of UPE,and the new HoPE can connect a single UPE too. Regards Defeng Li --Boundary_(ID_tBfXfRGAMpXzaBktuQdoaw) Content-type: application/x-zip-compressed; name="Hierarchical PE.zip" Content-disposition: attachment; filename="Hierarchical PE.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAEVeby0gu/ym6MIDAMPwDAATAAAASGllcmFyY2hpY2FsIFBFLnBkZuycB1QT27v2 Q+9NUEGRKl1KElpA6U0QpKMgIALSpAhIU4ogCooU6UUiXaUKCEqLgNJ7EelI70ivId+A5yj/e+L1 Hq6fa33LL8qamT07M3uS/bzP/s27MyyqMnLcYB4IAwkhy/BIczsJIbAmzMDHYHvNkoTw7FkSQt4L pjZmjuYMMKBQHdiUs7jhaGrPwCt3w8jRVMbU2NbEFHiLmBgJoYOjvamRNQmhgv/RR2BSHwlibMMh 8Rs0hLTGpPT5FDIcHDsYjt732DsFNsWcT1gItJmLOvru4EbnSBpHP/dmxF8K9KFTsWQOmuwUBomF PlMXX09jWGGpIDsSYZGbSJCZU/XSs89gIr4wTsysx+NSJO5uyocpzJmrJwZJCE1tTP4+ObC633TY 39cABkO+l/L/x5VputqZMvCqGpmZAhuqRvamNo4MAn9dprqpg+0te2NTB4b9qnK2wL6va3wMgnt1 /rpoXlV7W2MNU0cGyNc37pdJA7WBgzkwCH8v/LsJYAF0ny5Y8F98vBk6vYG0hRRIbySeGOtd5/fb LLySw58wvN+Tn/ngWlvvIsBV2zKPn8dFtLXd4asc38RnR4z9aA46O86Y/vDDcAI0cJfHtlG54MGN Ownyix+TzRvHTOZtd1e2WHFtnzQ+MG+YER+8VOnZ4LKYKQCm5SwtQ7zCmyhNgjuPf6S7k+7v4SmI 2Jwoztvc2a3EWx6pLdkZJ0MIZHsWvSUJLIrqJX9CamlwR+n6O1UObZq6aQbUUitB+3HXD9hWV1Il oyQoi4ZiIaSM9zPyxQf6n8bHNwwGGqpEDsbqkMlDRuY3Fl3WdzcfwQZjH7RXbi59oKUfjMo23JVW TqKxcd9ARI9pTF3fZPrM2NM1UQ2/GFmYVj3RmL/QNL7isruy9tQVtXGnqI9+QYU3XgzJbuyQYUk/ QJehTKH8JlyMVm6u3KFqshCWNJdAPRIzkQezvHJvWuppR1RfUzm9gcd6spF/5+JDV97yjYWQTcNr w3IXEmPBCTe2n7VuiKJ2VxyLzrqbiuUkdEkuZu7EBH8K9okRuj/tP3lydXsMx7BobN2GRbxiwHIg F7WiYGFL1yQOj2dfgQdFCukN6SWWCuo0brVMFXQmrgSl1W8HLahE8hpG12+2Q0luJrectbszPyj+ kixesDW7PuhYL18Hztz6mn0yxmCNgcvZ1qCyWcb2ocIsf7iis3WL/rwjmKAwIur2VK2Th4swAiYG d2yxNRh8o3Yr7hGVbxRs/NXR3NCKhdcrn6StqNrPgTh8H1eImiR1UDfQeR0xTstvRYyarIGQH9xN qfi42rfmMWDzOY0VN+lp9RrpvEaWvUOeJ89h0FzJyobl++yVKJphW1oHqJ5WBdV8GX1tz/T+U6H5 GohW74GpMBnLo24s+zbvz1Lg2xJVARD7G0+uYlxQefZe6z6cIv1xl7HYq9u6ymqxq9fJahZDodSd DnHkwUbH5cJruv1AAbpZ12uije95IUcukccxay3SgGA2PMMmwj4XJw16+hDQi+bL5w1Bo2EUnPxc p1VksEffy7q4h7BjMFSSybdAuoRJKIKN5T8mmTadTwZ5hc7kEE+8uktJgQGb6oltg+ARYdAYjSkn xEFuSwTqZSq/EIw5B2J73dkTNgx7j1/DodRrPxonI6Gi2xMBeUCEATOy0AsrG/HHLuQPeBjbjWU3 DElQwo8Lx6+5DL7z5BIGA3OQjHQg114BgQ80tEoRKSVxXy/lesiWAFwC3/poTh9T2mlM+zrOq478 9snkwaHaXNFKY2EyEk32eKPX8oBPKUKUweyjvahEoD7fk+TjmHx39LlZWUruEYFgU25g6Ckm4CPC T//QUH4+BxSc1weKDksCWtFnj2Xycf62RFNuopmeMBdFcGhEQfQcfXGTuph3uOYJJobKrDiFlyQU XsYzdf7JW+QYMNcxGXV3P6+4nC9ynYyYkAiLOE16pguBtvVS8cAKA5shvdL5VWCHtsNzERmJ+8Ux kuGMmCvZGprDtMBxgkOPUWib+nkFvKJJG3ikrjFBWRRZAOF8CQEuROqkvNZ9/BrQeQLazvv472qX z+D202kBxzTTjhBeEFEDjmqnrt/EbCEAV4i67VKUGE6KQX1zhb7p5O4Ijz7ZUZVPeJas9fcVlrEE Vi9wZoDfTGnYulnUyYZispH06PV96QkflnduS6zcYK/WXNM0mMQtt/UeEO+9I63Onnq2N7BSUqhj sUoLzLpGcyUkVstP5EGS2xEfrfrnL+114FuFpwtcuxByMOgV5za17kDBdVuxoEeP+H36eEfTTulg 2IiIZUi90MtTZV6RpK3mGIXEGmie9lC2sIrgiRh/nqzK2UDDeYly5yO50lTDUfo3KjPgTn3CUTjp EZcvQ1cm/Nd17eRv5EMCaza1C6K2Ch4JhVPoEymJC3GZGt3p9x50uTaQWhIgeD7pZGb6tMOMsq4j /LaThcpGiWnw6cfNBc7KJVJi1hyym7Lqqu5ffLFGNcgQ2bM5F/uNGi/Az1zPDDqXGtMuFhE//GSx r6Mpl94cb0omwY9CD6rLZigqVMTQKJabOhglhPvCPlYrpKjTwqFBO2CW7lUNTVnV9Gnzc0dCnNb9 1HNzOfWIQx2oDUWwXJq4tzj8hIog/rkvv3w8QRT5fuZVBscH6XbSniZIZwSZ4wnnMlYlztl5hWTN p/y3n6s39tweNbJUKVxT6DhdPa4wfGN7gJ4Dbj0w0DFHgqLeZhHl6k1rTFUpsi44kxeU+Wnbdrsg qGBuCtZfMJV2XpeyY9h8blzC2SKM8nEFu8CJJDU/OXz5lDbqIBHBiKthMP0khV1b05sZI88DihrA 1y94R81eID+THiN5yU1gMOeKlVOgW9aLBphI2x0qj37K5YDgU1AyKmGb566o4pNmG7bx2uAHL1or zsrGTmtgM6TkqM2elYmt08B+9n7uuU0SQlEDe5J+KSfd6zKnMkUwdOGxRV1s6jAVhrAYL/VeiREZ V+BLPOyhlgQHFr8YoLbJxs1WzIQ2zTgmULXKTZ/l5xKyQBTg04xnYjCWo4FxqlIMsb7bHhM3NTvq KwL/dC4z9TlQFoz10oFP8xkgOJ4AddeH+8FL1eIhELsUbXXCU/FrbnZFenGeF4C3lJ7JLs3fTOYF 2Ud0DZw4wsaEaT/MVFKmEAYKBodDdeXcPsxiwJxMzunKiTTOYgi/Ja23ozspTAFIL6uUg9shhzyY QnuAqo4jD2/0DRCtLPfCgDoQwDjipQO84nLzueWbzmOPJqdYczi8IQ+mjCiQnRKNV7BTqnz+JhqI cDyURffeXfb3ijvq0/G0GwuypMA/+qZir4BPGGqR0cGLbfJGy/LYC8NlAuwi0TOYEXqjQJRSuYwT ECgXSIVp32bJ4vAi7gkQ9+a9rtwQvL0fwGZhLECsPR5wesoXRGyo8yj6MngOA33c6sYDmjf0Zgy3 xlGL///pwAVvMluOLotFLI2wORiToNxRkUit5bsxCWu3X1zR8Onj5tDu+6LFGTdgxnF1OXUmKU6p W+NcAhcWYjFRVCPeNoM90uTt55e0Hq0z/FkKpSRqD5KYag3dpxvZBQbHBsJsWnOPDKU2j0wzKveu igrRwvkSOjJrpVtUZi9Uj+T2hI6nI2MftMLDHj9oVVDpAIfSDrcTilA88C23PvYQqbt037ksfApm /ZHmqGHmEv+1mEbmZLH1lNao7RvbOrpkbYoivllUKU1XpOlNjzq6u58BNsVMA5YM5gbtxFRpXuR5 OkpOQrSJc4NuRUR1TxtJZlyxe3Cr1m23qFvl9cPoWDP/AE5UarHuk9Pnwz8RjJO+9XgE2cWeiBJt sNza7X3AXJGSv/SqgPRoSBYINYTPRelcur6W9wX33qIuww3kKzIXhXWO6xQeWGVKpLOxQSE2NG5F VbC8s+HMaaHdsZMhzV0pfCuN9IWeRFMec9xQlfWPjMdXIji0Z2WJPUve9+sPYtGRD56m4x+U9Zvu N/J7YyORLCPEYT9eTL1Zsn0yukyUXutdFsO5EZu4IKToOfNSw4zKnqZKQQQDjKpGGONcQK12EYMw VVxrprt3qylpDQkOpO11ZFUxgwBVXxnJulRgCM6LBAk5lso5RihQwrMuafYO9kwCl5kLb9K7RpUh CcfK+73qM/fA2aD3qnbb1+RFZmWNufGJcSCpE7ruXu+AGtsxJoET7MRiFgZJLOeCjxOajJqfJxv1 xaSpNfti787ATdVHZ1adLSB5iT0YLJXGyEVVY54wmBawkewaTjD5PsurWSg4pJLAsjBXg4HZ1yHM len0UMDKPYdR05Q0iSriiU/VqxMna6ifEEPUX7dpMCTJ1kZZXQqmqnneSuug0wrswp/T2L6DNRfq TGbacE1Sy4Xm1pQBizF/uhgOJJ69II+MKASThrlu8EZ1G5x/4TM2N3wDP7i14t1Hy840CTmS2ULN TeDdDtSfzmauUdUoGF1tn1ImbHLRnlyfUr7TtrPIwqK2mn75M0cwOIllDqtpOEmiyi+Cf9wYaJ1c kDr4ukg6FQNzjBEV11mcnkj2o0lwKXUG5gcesRmbuJAKOgG7t+p2VVcSBgXg5ATBFK5qLzvjMee6 2/kHt+e/7NWIF2zL7wEuC2+NHt7WaBnmTXoUOLC/ekvCMFVNjRqhiGYcJg2HfaF0NYewsdCLd7vP hXF6mltsJ4VxIHKTQo7AXqP1mZabhCb3+rOlazmCKRwRpCxpEts527fYYTiQivmuhFHg+6+c71KB j4aOXxx19HmiwWCMuwa8J38hpJ1EUeVuwDFY/7NRqpoWg3E2473dzPJrm0kXhWy4HDFEgN3mMFWg Mv1nYmBhsnIV1xxoQ7r5kapWO0ITGV8MHOB0VI2qCUNUcWpwhS0tdqBtUgSaCZ+paoayIrblfe8D F3gv3RtYMONAJco53rgneKlWwew3k2Hr0imLrbaE+c13z3XEevdOHJ2ND0JCQ0/FXYxlld+dlbS9 3bL2Iv/jxOC5LOOguQJjnxvHA7hBGw4QVE+OtDtZ/ZXbVx8M0HwysR6KNBIr6C8xsJzarhbLti7U yFgN9FecMbs0n5MFvUD9ybJHJYikblfBR63gmtXRwXrto7eJrgWvwTc9uKI1e/XmVOLaaFgNdQb6 88b8xeem29q8rQ0KPuhO94ZC8/N6sujEPtlvIudmq8I3aDTuNIuWHxPge7+TynbHWvjcQtFN87fy ThVUbsW3V5ENgZU2rs52TPl6HaJn2eSK6+WeW0PFLwSkdGsUWE3EzDt+jDHy0+yC5B9zmirTUlcq b8u45+QfL56mZVVEzO6+Y7/wkjct3CFmxCqzWw/+Yi5093R1ZNv1VtMCtlJS/vfIWzbwODMX/QUY /PMy6XazCL0Hc+HFZcrONdIgvjs+fVwd88qSg8s+u+PPC5eRrkqZhaGQ0YIFSpBByYsF5Ep74Zkb wkEYL1MXZD8v26ptxuo5NH158p6t9Kp7k16zO5yCWqnUuDWzRIyWbaFJEjQfL2WnW2/4qriYLKG0 +IgRYvt15i1cZ15m6bL23mWeRWucCOU5SoU1a2YDogFT1TMDd1UVehJVLWaN0ggRunHriHMbE56e Y0HI27FmJ0tUzs6OEQ3r3yWODw1lm/F20bGr4nlTKOkcjQUUBqzLWJ4tP5Zc7N0rZKDKxSu7VzNA 8X6vdBHXG/cxxiSohDVHcHlNHcdbhv6jNeblMQx9R83hzNvMfUf7yjIU3M/gO+NArieLHbtXjEnj ZrsIi0/q20x2fRyxIvGGKzhkLzrNE5okD0p9uWunY7ed4UyYRVABnIJChORzloQcEVLM9D1b48xF Oy63vRPUfMYmXwDq25H6OeOYDQVvC+CNAgeGxmEt7b1J/wsdvgsORDcsgAAjW0Lu8XgU+RdAhGvy ZVwtYrLrSQSbWUOJTkAo2q/O9nDunpcOA3PJ44akIaBRZGxe93QYknzv+voBC9y1FCAqtYg9uNvY bnnxbgAVruDTgeShADNfD/gA0CZ6Q/Xh82DtvApAuHJKPXhxH+SBFnBbNFQrArXpUq41OGpzSMjx V7JruxDm86pxyon7JkvIkSIHlsaXSUzunbPsML2sij4Ovd0vWMsPSQVKaM7loDbCbLSTqByBOANR /CscBX4NRwohxadEVMppjGXX5D9wtHjc9wCiEhDUEQkjVDX4xYYPAgGBz3qc2osoz/bDT8+Dv4KS 015QGgqgc0I4bZ2G83sypZ0MA0IXNAd4zzP3oDgbVXtCk/yaKVwgdN1fg4jT7O+G5TbTuxfd1Esg 2gtwMvV3H2o8Q+KbeT3cC5hQiUqOFgPZUL7AvbjCSQxEnZ408/uEOMB5tmTasqXKgfMqPiMkSZPA dX7dJ87JDxyR5crRvQVHFAahSvkcEc49SFNIPVvjW3rOx0EeQEtIZxMGqPrEsgeLzR6Mtqf6B4vD EU4v5k3nlYsuJr0WQ80L3Zp9VfpasuDRB7GNTQcIoien8g5ZvfFYv5OSB0ldwwSJx/x2MxB/8qr6 3coLlc5pLJj3PrtEUZj54UYwd15mgVXUeJlIT7k9LuvZNeU2tr7bnydKo54mnCrlXi39Aj07MV20 gkAM7rjOFVKPFV6QOKpy3WxXH7dJyDDxNbJiLKn0rVWxVt/nm7TbK7g4J99Xvg51Ur54NnP27MfX xMpVWdFCyq/7bjE9KhZpuqqbcNpu9+OrsZOJJyPWezY8UsLzLtxBCNyecdA74q5vfUzfoddKrNYu rUdEd+HWm4k794Vot0fzXQeurhJyuEq/vTi//VroY+nTS8xEpU+blq4/dy6WihE48un27mVq6Iie Hd9g05cj5WylXnxPtaN4a9PJrdYIfeUL3T7PZVrJVFgNSI/FYr4q6cVR+9h/j3/DSfqhozjTg74c NoThdnehqPcrPexRP2+BAMh67v1bW+5K2xacCVxZtoRNwoFe5RHY/skSt5dBaz0+N1M0GZI2ie0N tGoEcSCz9VfNjweeHKv327kfpQm4idVDvfVXtkHZU49u8vtj0jhFYAcMmtUKkNF6DWs/cyc7TkVv w8tMeGQeg9CE3/nzIwq6N5EU3fBYf8w5pUnZM5gGcqM480rAkKXl0aUYr5DkmrecfcOAi0VuLwrI s0cBu/HmIwhNzobQy3fBUfxxrUsoaUZvcOJYIX/QBpWqXM4OSjXz6ord5lu4no8XH9O26vnKMiT2 WJeirwJbsJo0wvgWCsKEsBKDkQMO6FHtTMpnH4XY0MaSI0R+YmucOBlGsUlxJT/Q9XICJXIFDIxY Wvw3xvGqiJ9S43QpekOY2Ia32amZV4xTNZQxK/xme18QY/Ss5+BPOHBKewUc20KGGXM+C6hZMIvT PQKEkbeXamMC9i7tg2UaBLumJuH4zGg33JLuTUuzOjDesruy7iiWPrQGO5slyh/qDUnEkYQC+vWh eRZNZU4f/+lUzHkgNCMMA5Kiqe5RbIA+JEtsf9mZU70AfEB2yi0XCCvwP96jSxpa85+IqxFfoRaz oIt32ntTAA/PWRPiqCM1z4+wQoCD1Vwl02EDlgb3++0GMG8M42mGYtJ0Ip/T9QDeTlnsFX6bJSfd 2POO+frD+7GNw8pJ3Yy5gzsIpKVV+IhwhbvwEE55ridDznIUtePZ/nORdOS6TPU3sQlOFzCQMZJJ 0uJ4j5F3N+FIrXmhPt09u2F7ZhTPhX7dqFtZv6jY8rpeEyF9AAu/fE9PVuZ0VnZRKk++HTeyr7ZZ UJWX3kWSkpKKO8bhpHqYf335pw7V5gtmb736KTTP0NlfmTSveNl+RIlTiDs/300Q65kwhdrdUBYW CQrtSoO+xrWH0tXdcjdr6KzCyzdSBW7FtScibx13/wCaMVfHNiyejRCBhZeMPyDHqU3ymHz/2cN8 xNZR1MNP4pnxY6W1haFQOvkj8njceO4yxhwGTzCiJpKMVHM/mNxIgdDaaEMvzXa/5t3oyUe4lLSJ fYjtMph49073xTGmaB6oTViWSHwY5l3i85JHHidzsGEoLMqww9aYdqkiiRUfcBeTVffNfqIaHrV3 ZeyYwayfWDAWavKVCt3xdv6AW+eQ0CIjp+Ja7h4xIZXgX6PElvAkcG/NXMHw2cQxHqoYv/ua1uGp ZyMJlfPlCISAhUySavG544TKJlucH22aU6QoWyeVBGo1MoMvshiA3vlKUYbwHrNpBpaZavZHju/V 5xBIjSfyZVVMOn3RdG93hNug6ENmWeB4soOvnpO35shSJaTWaMjwT6uvriUkCKvLsEYmdJhvkbM/ oWo9wULrw6wmK8McZqfKrIKSzfl0RwIhgRXClNh6dHu0KO3YZYpMtem1TBagThJ3jK3eCT8qtRMs m3erGGVlyjia8JraJZL9zDeYbLrynpNnqlXMcfffZUr8/PCNu9LeUYwerePtWF6QSeIZNnc7djRR QFGYPag2LUBEmgLbuSzGT47d2xxL9j5wuuOSjoFM0sDZMFtvneGU4S9iCixLNVeXsQgbPfmQGDgZ N64RPTuEiuJxqp+o8BEtGaswuweB185TtH7xLaY2T+6UGdWn+NCiasLOdKLA79qz201w3RL+7icc SxzDvvb9H/MzWSEDR+tv1Z8LZdVNMiFfvwCc3VD47m1WZZmyS6/05qP5KUheIJhJpqP51U7gEPeB LZiWPmz12lcn+5t/SlTug1ok8hMK3gxslUnVfOHgpphCywxnMshw4t4/UjoDduvkJU0/c5cx1tah +POUrcG0WZJ2zcnn24aMHgqc8PUpBk5UaUYr9lb7IjFvmxdepWz8uS9bpkvvJMGNHGU2FpxqDlxB cRbv/bEsTnj2qbZn8/C4Jiv7UDaVSFZxHjcfTfBWqo+5nyXCczuDN67ZaHMqapmpXpS3YPG+5cAj 3Oc04BMXMFjs2mpoFj8a3Pn84K5sqxLfTJVs5Yj1EuVb6sjaS42SaQ+06x3OjPa7iDSwfVaIsX7m D+k+ntZo4k574WhJ2ztRJ/UYtw/ZMctM6cm3n51qPzWmUBNJraygE9DvUbZrbk1IKvUE8wHfyzfX jo++M8Y7r/pkWw6c7h1jdNZN5MFbqpK7Qrrn3IltFZuzi1g3Uu98IWI/hWES37zQpfPR+cvqZRzD GdK3ntkeW58Nhxo3O+lRrsgls8528SRN+ReEBZmWW5XuKu9pmUrJLnuPGtw6S0cV48ia/MFldMKz 2GMzbaYZcXZmyDvnw/M3g8ZXdweX8ehzMQoCWXd2uvNmeMuERzYoy4Pim1C6jVimjhtWOczzJ6bt sao2oH7pOh+D5S+Or4tt6JvG4k7ypg9guK7EknERrdRmp/MaetwiGaTTQWQ/49P0fD6+Hn82K3Ah 3rm5eMImvlLfOl+se5O2ybKumzctrv9aXXdTalzjWJiDVSqtMWs1fUA0bQH0uv2nj1G1cu+o0+eC obnmPrTuPfHUupMRsOMj7vJnQuEpn57ER/eYeCwwKyQhPvD3Luan1bLR6ywP4Myetao2LXvgNmgM Nm0yOzMUbfwW0UJrIH9KFNtAyKJ/KUbuTbnsLWrb4eZX0ZNWGSqCxCU5OlhI2mvRC/c/pdl1SpDm 5yKj2mVjZdLzci26Ckykzub4iHHHkD+ejgnE1jVw0ZW5XJ0mn5/rJM0vvj0SFlqC/9SPx5c0TYXH t+maQ21KzoSrRqgUx40KWAqfXKXIg09cmKx4N649xY1/ONWvOepSwoG3qehQc29kEqNqtPFelH4A rLdWML/VrQEWkMn4SMVwsz0/J8q+oJ7DrDDGfm2GYyJDU9C0r9+haSotrjMsz/ACTPwG09Mrnx9H 33DcuJmsjRQc6zgBZS/dTiKeLkq/Keb4JSUkYDLu5Ji02Uhy9WZLt1hKdRTFU+XuQFz6JlqRTX8Q C6IEKw1R4qni2Yqp4tEtouLZvdN+7zhOiZKS+vrc6bci9GlFLnc0ggJ8rNk+VhacMGi/sMh2d/JZ vo8L3ymKU3HEwScV5Oq4WajSLsc5FFSe4zMjO9pzVKJyvPvDEnmKv+In5YubPQVmYzMfwCnvSD6M RJQ5EPYxjjgFvbpBJ2Uy33ib/NFJxQQhdudnAcUpZ24rSV6U3MpWSy7rNNeVGrEc6jt34s6qLbvy 1QE1XIPgD9A6QqWrsySQQJS/78PFgaGJuxqE258l4KBNbrl26SuMJxoC9XvbY51YYwJb+SeevU3+ dEktzu7yJfVj8JuyQ/dIrsfimY96rnfcmsVv5jGKOsW8RXLUu1HPH0tPxXVZAyZMJO/yePJa3nUO Qerq+2LrfU39UZ6h/idz3C9i+IFv1Qp3gTeoRVJBlabbn1f0XYtbFLSraDByIUavju72ux8xUDpi oHpETnqQmZYChBg+TUybv7kU92SJ9eTgk0VYYFna5jgeL43ts83QPkKuKXkVjBJtkZQQI9kkbLyK J8RFZwMhsxhSmJcGZy3OjskUafiHfb7B3u1hdtkl9IL4FMacHR4jlJnr2KJAQKTnyZNiMfXEKXV6 iuG0WvJ3XzflnNZKxCvj0iqzqCrk0eY244r3ng3WI1hwF2AlvDCUONZ825We2sMr9eYtU57lrl6c Tm7igLmHuWcqBumnkO8HA+tLL1s32ltpi6rqzTdYYlmS2z3COpbzoGoH25HnaujVGiJD+pHx49W2 pIvpMI/YwADS4ZFu8fu0BecNYcrtUOOuxarUd1q5lnmrhZv4bhyJMEM2B57ygcmjcovvroAKSi9j FcTi4LzjfGvyaF3c6bxTh4rrE66H4NkjHhUrTU/LlkHONoxmVMaCK9kOjYz05k7dAfUr4eD+4NqT Zdcxa6PImzB4nepR10VLxgX0l1WyYHE3G+sWp0XKUP0vT3WU2cfkSl6uWqtYJns7fsoAOltwjaxl u+SzlYGy/pNTvjz+aYOcKM7sCausbG/f2qsXvuj22rxL7Lsa4rVts30scg7EuHhZYCFm6yX9fUZt 69GN+ZcsgQsW/Vvpdz8+Nn0qeI+dYoh2mLgDRRpRaF58ohlfrI6L6OrmDtJVuXWjtlpcakYscxyF pSaygUQ7O2E/3b+/JgwGgw+U8/3SCQq8cmAGMPjbBoQBDP0fT10AC6CZu4B2Zgj430wNmdPpf9gn SPUREnwXB8qrSq2fevzp6zOoitz7c6lzx9TbnCx4ewx8k/lP37M52faojabmEckKU7bRJNb7yDK+ kXj62giBXj6l+y36iTQ3Zi6JbDUFlRlzvBhy3swjbrMLqWP3UTrmC/GXdt1UECNV4fV+0/LoSpWv 7nt1gzichPf0TbCtM2HgsrDjQT52CRXJXtUPIFfMw02/bKgPlKJoV+6c4Y3HVpR9hH/dm5SagiN8 +Srder9PtseIUQguuVNUKtjZM6Di3sBAMb5HuGQ85jEZjHR59Qlwg1+ljNgdVgz5RCh3tZDMbTc6 Wjp3Xi3aSiQRH6VNGplYOOH8xPrYQiQvXXl79A7G2SN1cBM7Fw/WYrI56e2WtXbBbfX8vraSR8kr LHN9kfxQQ/WL7ucFFlmsPivd+xIxiP+Z+yPwp030mQOz3EXX5wlFIiHLvCU3QZ+kVQRtwGqgTKLt MsYjaw3583YuZOYrVsndmmVhd58YDo8RECxREXSVui+/JR4+g10QyByHsUObhhNBOckqq1aT1gRK SyJ8IzYnn97hpDFt2Su7GxSeqPLkc3EOiOLW0TIiKJQfN9PIcmDqnk514l338HbNdkZs5CfVYjfH ELWujMSEM+PH7jY5eBu3TJ1NsLEs1kzNME09OXGdpqB3RsRgSzuQ0/Ce32PSxwJRVoapjqzVhVyW hnEL6tsXNiLdVZDy91doLGV7o8dP3xwhmyrq7LysX3TEu+XxCfySTPzzIieVLC+ScOgGssSCT0jl l1YXul4dV5p+y2uhaNjG416r0jdGtNbldNldT33ridO40gCvgxvjFYKLreOo8pR5m+m3Hf3bWNJV /gmY4yXC3jPvXG+auzy+fHGCdMJCSb/GNeY8N1MPUyq1cFOJ8f28POLKV3KVtk4ClXbHHhkJP+pI 4l+O4CNxCHV5H3e+Bxp3WZiDVtXuzE2MtBBjYlhFTHRR8mDztQnqx7PCZpIjlx/VbPQPr1JHbwrV TRFTKj4/RcFFRrL68jTn6Ma4qm0cxfJLE7bxp7ciGjjrMmLioxtOUGXoNSjexIR9fCgarHU05DNh tbWfqNVwvUAKb0ovPCmuuLTg6onWQK8rfQiBN746+f0h4rReePdcFItvk3prP3u23UtFW+Ds20Wi gbVtJK3Dt3lMLxTDKZ/1ATJ5MZ2LwPk1q6nVsH5GtKpNWBjbhQWHayMcUFFK3nfHqvGX4BFldCdy 014JXhA1dpe9Z9CvKPql/ean9YZV0cshhsyF1B0d13H11FpfjwXlhm88Aml7laSsVAbE5IQrhbrd ED7iNTR8e3ghrNek/l01rJPuLNczAcVhWxRVCS27ixxVgOpCMEsV9sAQP/VpP7dcJdjb1i+3JL8o s5YyuywOEFU9xlpY5PSQjuENsd7oYlLfmuSd4nvHwccmHGrzPvOkAi55qc2UVy1VjzBVXZWmTJ4t N74Q3sbHSHjTWq5W2j3j64LPCJA9d6ZbaxXJ1bL82WFpReU5prafJMImfQopxhp94DKp12UVY4xJ n9pc6G7TrV9sBLNN5KY495ZVe5/sm0vIowrdvXkuqc53Si3y/atJr4KkUw8Xily56nQbrNQE+awH /HK9LYKd8kgicigZxbxheM9OHx99oPNUzaOldCBKvrX0ldKJ44tLs4ySPOmzzKH8rzlEg44+4kpu uiTfvaSMwLYmwZoI94VilFRx3fjwShjUq/sKu1cbqni3rSi5ipi6ONlZc8TlyYw/+ewRm7f0qzWP RUys/SYaufIEm7Mox0sMVfnPBfi7m8RqY78d5gsNuUEZk1f+7uMOXJB6nMX3LU1F3AL59epFFeGB cwWBuPILOTE+5ZJVLglI8L235Xw+BU/OSYgWDfNFlim5yScoNUxbVSMCu/r5HCQ3sMlw1Z5I1dzS VQ0I8nBNHe1eHjI0vsDEgt6gvs+f44cIfy+HoDOoSxevWZoaOwLbGreuOe4Xnbf+aloqRtbAloU1 +IA9yEhrfjMHXh0Lkz0L4QNWFUwtzMwdGfaqSlk4Oqia2kvbWtvZ2uy5nvC+Nd2wtdewMzIGjihj 6mRhbKouL/XdhiDg74b19+WgPqHmQaSSQNtNQSZeIOCF6gVJgwhwcXHxcPHx8QlICAgJSShISUiI j5ygoSKnoqahZ6ADXoxM7OynmU+zMLBxcXGd4YFCoRBu6LcX6h2IAh+EASLEwqAAYVKAsChAqPeg NhAIAwdj/wX6+sICYWBi4+Di4RMQEpGDMLAxsDCxMXFwcfHxsEiMMIB3YmEzHgHjSKoZUTLdvAvB pQpJeCXFfPqo+jUof7m9tzQeyxN8jdYvxg4Cxz4nLub6sMqEaprIViQ5Ch6nbtMaNl3Ku1fZfmtk WY4tLNk3P/x9x+hKyusPnWOr2ted7kekFlR9HF8Tktcxc34QmVZY3TWxzi6scMncxS/q+ZuaT5Mb BDQcsPOXLVz9o1+8re2e2iQ8wSmiqGvp9jDmZVFdz/QWqh+EDcJG9YCIsYDGAlcDEgcVrmajQEeg u4YNmUgrFOh9AAoUuczlqYsCLTKLj+3Ut4vPEriZIe/yXkCBclhQ3Wh71/5Xtb8GFRY8UMyPbngB EfgXwwsizSFuzSGBrjxVPpCUPtY5KA6zhgaDxY3rCWaJwXHp79Lh0VbJQ0+aiUC5Vfi56Bv3bYIm /8GODzlcx4f8pONDf0HHh/72jk/y53X8Ic8Cs51st64t1530u7vd8KXSGcOpiaUsvO3rnnXrmZ5p 8LpCLkAQRqEokNIJz0mtR/aIHTka8ZVXabu+l/7Lrh/pAvqt64GFDhSjHXZD/s2w+6suXmseUAWO MdThHJHv6BUcA2TDFWOcyDsGoFBlvHn0LfvmB/wCB0oFDycK6E9EIfALRCH020VB9geKAlEgv3ua LIN+yaLee7ebfiNYLMezNo2HaNvEc1hiqxwFYo0LWhXaFUBM6TxFgaQMfryB+JEmhL5r4oBXQCHo NAGF/nuv0P6mCQeNc5T/qQrKfVUkvMRXRts26He9HpAr9JBjJP7/XhW/QBTQ3z9EwvnzRLHWVN8r yntj9kc9Gvp99MMPO1AsiLZHC/37KN8B1djv0wyVNR2a5Z8arjQrMMJ07uqIQ7s0y1ngx0GJ5fgq 6Jv2XWwHtYbuZzP/gw4t8JMwL/gLerTAb+/R5H9ej14WzzBcSpj2XLo+WFfSPHN857kbfCe6cCkb uvUBBeKkSwPivPVOut62IQpUl5aEAtUWoUADEYVrCBQo/KI8ChR6CwUq5bad8wRqxwcBtWdQIDfD H+nj+wAcciCs8vOh0wc/+N9HfP4OqNr3oE95jnkv6DNE/4UHqft48NYWvwtt6/i/qfc/xCt8OIkI /kQisF8gEdhvlwjlHxj0Q9/thuw86rmItSW/xGtxlmyKviZAzG+DmSxRDL9yMsjbcarrR/3929ga KnQg6vKjpWH+Q9Awf8tBHKbcH+RAGUT/soQr+5bwFok/gL6/C6Dr7/yHxGGhn/R34f99f+f//Th8 5A+0hIUsxFL2DHzJbXA9ZWJQ33PMsEt8dBWxoNRcBgT/OkSWZ+2M50CEnlioB/NSRoE764782OUb W8obQXVlvihQ+WV3IhTIO3frOAqEY/oDZfAf4OED92L40fIw/7/nYQH+dqj6ASdg6PrUQFyj0qQ1 1Nnc8FrVrnYCB1REhY/+F8b835H4YNsOicTC/70w9ozwfy2M34/EJ/88YayW8KaEIoV49Sq2Lou3 2/+1yTTqfvzvP8ar9h7sl2jhD4/hsQ1npb+c/lHv/zYYh8IO5IgF0JKvwCHIF60v/I2+Svvo+2IQ /w7axglA0fV+gUOiL+z/vi0I/H72/QNtYWn3xW76OAqU1r27ohO5enHVUAgp1ryeWIJ46flyEzG1 5ll6lFZ8VZ4SCYOHy5Mh1d6jQCpmY2qVKJDmTfH26E2dDvE1zLIEFCjn6CoZ0iv7B9oQ+D4KhxzU BlqGFvj3DI3OGS78DdEtEvtDplxl/GT0jRNCq41DUvR+buz/sjUI/H6M/gOtYeUM2eptXqQAChSW LfUOBdLJRYHaDTcVD5RnBTY36p+CxxSJiguYCm2s39HW8Axy/rC/qgVv2M1eThePRhpOaHtCtxBN P7rDJHCAoA88/UQQLUELHoagWw6oQ8P4HBHgHBrnKP/2DmnpffOowCTAQts+wW/qFTgo3kMyNPhn yeVfIZDfD9EUfyJUZHsuFWwBZsC2gALd5mouKwVQoneGbAeOQM5mi22to0BcthniSx4o0HpunojO Vrrv7lPDsctPuZBaFYCTZC9lNIXvvvzsmaazqdNCNImzgvkjiXwfvUP4D/RMtNAteBjo/qeBaDbL fLMQhX0LqcgnwEOvkG8KFuA7UHpI6gb/JAv9KyxE8Pdj9x9oITNQFKjzzuAm/0JdUQMKBAyvdpVF l7LyxJE6jShQqMpOemr6JpEYo2OnJ6PZe56Y7NEzG74XGTVqNJfI9y3DZxPeuetIv+ckPxpbCaLP QguipW7Bw1D3f3CH8Z40sBVYJzi/TJuNnzjB9WZ0GRNUSUZAir5134V74H6U4CGxG/yzVPQvIA/B 38/df+INKXgWYilvL+W85x1uXE0ee7ehmmfw9rxjMhu2NQN4h3gG/b53JEZ2NG9qrTSvVO4uqW9F o0CcZdG7UZ4DioYa4mM67eLtZNu1hgooUO8pd2YU6MatlSDkqx/dvhX8PtqHHhjuC6HFdKHDYPo/ nUSmWeqbk8h8dZIpAmK0zRP6puaDTiJ02Hl8P0lS/wonEfr9pP4HOklnPQoUjriCAinvXn1tjwKN 2XaJt3tGcV9BbOqtNq8MjhM5JCFPihmG2zh6JpnVL2U2Ba3c2PTQyrOl7yS6PiD+8lhjiacmp2fs rgcnHCB++MO0TcTE8I+QROgAsB9UCVpgFzoMsP/TVGS+571bvia+KxAEhOibJ4RWJYdF9p9lvn+B qwj9fmT/E10lO9twKf87kTSVlXrWtf8NJCJbq4CpXPwbSCI7sjfVAVOp9iyB8b4wXEqZgk8FokAu 9obqiDElwFVO7X4ZW5FH5kW20q81Gcp49sI8fySX7wQPPTAGE0ZL8MKHIfh/mAqxzN9DsBiO/SFY RTQBPtrGCX/X8kEpHxbff5ID/yWW8vvx/Q+0lKAuz039Uc9U0SUB+RnETtYS0OM3TyStDu7quNJP Be481veU3fJcSNiUmtnibUeB3Mnqjhu2esC3Jz1UCzN2oaPHVuFVd7wH8jaagzW3PRGIpxpzu7u7 ty4Wbm9v/mj4JfSdB6AHQF4YLcgLHyp7fvBe19csifG37HnL1/R5+SABLnqtoAV54cOC/M/y579A K8K/H+T/wFtdSx5puy/GPffzJKGr4qsXoV/zJPAXKNBLV/h+oqQXBbLyHKMRn5Jfyhrc1kOB2GtR IEXxcCcUqGdwU+7iltpOendkHu/1H82kEkafPxdGS/LChyH5zu9TDfsAKCn/1ED9d/5cIP9rAr2y gOAY+tahJXnhw5L8zzLov2C2ofDvJ/kTf540qrfadzMnUKA0ceRshmem+PSA55YDCjRQd3BH1sg0 2VYI8mpx0HPxaflV73mxZyjQC/qPRGm0PHF2RTcrGlGgmIzBzZd7yx/d6RL+ju4Q6PdiGFp0hx0q w47GO75lSb6m2F/Z/iCNCIOi0wfssOT+sxz7L7AO2O8n9z8xS8KbQb/0YtpwyWlwPbekfgZv56Vb 5M7TQgBIIHv3vzjjUwBcsd7DFcRuFwo0La8BUD59iDNgGygQUmHacyppiQcF2put++LURSS/h+yC 0kBkKe8PVAI7gO4HOyJadIcdBt3/6SKX/gb3mr9y7Tv46egbhzbXDjskuEN+lmv/BSYC+/3g/gea SMpqLFJjmn7pWvN67gv36yiQ5taDnag85OxLw8uITrEEFIj1zJ5CknY7AYUYOO9Eiy8wOnr2IJBK TShQKBtylCdoWwcQiOvgkgkKVOLbfXTvXywKJHAZsay1t/zRqAv2nd35D4z5wXxo4R3M97/Ov3/1 FeZvM9hNnu9PYS+Pwt9F28Cvp7T9r1ACOyTAQ35D/h32//Pvv+PnfEXZu6cNAG0onQTGW3FveNJR IP/jzz3bqlCg9TQeopco0LDsNP3KKwRyqv71VvRuyhgKVPsRBYLMeaR6vnD1XLqFaCg2fAGfNjDc eWq7zGtvMFpa+6N7XLADKXihg70TLbqD+Q7D7v90FoXvSfiar0n4StsfpBq/nvIfOgHzHfa34D9L w/8CdwHz/X58/wPt5cFH+lXbF561seKc6Fd7dwFZ1ACeE02/wGi9B/Kj7tK7F4LWgwtQoNeIpX0H kt+u0fff+/e3pewtf6CWr1/sV7lA/+ORUegfysT3v07Mf7UV6WdX7bMwsz2uZ4W88lYS4wVVpBAQ /KCFMPRyOSTRQ35Dbh7M9/+T879BLhN7jz94DbDIaJXZGFfc3iNEugD6CKWBh2XZI3aU9D13L1z3 UC/2CN8x0Nly3jxu24Z4VIcCqaBATHNbOouuhlODowaRKNDV+jYUaJbGzRDp8yNc+fqV/uUrBx5W AAajxXow+DBc/09fIf82gyWa/esMlmQCSvQNBKMFezDah7/9T3Tys5z8r7AV8O9H+z/QVtJWs3e1 zunsXkCB+DR3X+/9mhYYc9XCxwnhHxGbmquGm9Cd8lueqoB0gJFXalDNcZ1Vsk0xwy3znbv/Uax5 m+f5mr7abJ5nzdf/P8rLf/1i0dgKGC3eg8GHSs0fpBWNfVNR/dtUXuybyitW/PgftA8t4IPBhyX8 n6XmfwGsgMG/H/H/QFop3wrffX5rYesSgOnShP/d1soN8TF+z9Q85JSbIP1SjHj75d2V0pNkm8r0 UxkokJuBXymFG9MPBfId58EHwzUEPc5DDoPz/7QT1e9zV2oufMUUTQIy9C2EoMV5MPiwPP+zhPwv 8ZPfD/R/5F2w+l0tfUOk6M7DyC7eTa1bnisLS5yGVxBjWp0oUDuipsh2znbHhwsp4DjYM7iJq7Nl OYUA6IQ4e6Xzk4f9rDjMiT4uD1H39f+PPQT2A4mgJ/lDPNHtvz7ThPi94l9ZRojO/yHvXKOauPY2 vqu1xtKW9nihtNr01Z5qQcFMwLvEowe1RYuKgKKId9pCF8dS5Ggrczy+ra9VDN5FqjmAgtzCAQoI iOMdBCvXgJdqVIhcIo2EREmY2fsN1wx1ZmWtaRb5kA+sTDZf9of559nP/9n7t7tSxmQtD2epDmP9 0leDnIFupiJ4c1SHBZBuVog1GSpL165S2lETQwwiMEefDVN2rEfgTCQCqoV8H0IWkhrQ1eoKO84v TUJgUWBHuf/moepmvMoeauxW7iTzJZrreOEQtrKg49ww+jizY+cAdGNQjjeu9ubvmT35+55hI1jm x3iCXcCV6oYNQAIvsADXzQp1o0zfhoDjW2nwJHkpkNqGwJHdPgY3DtdmwfMGU3IlBU/EJ/s7P/8F epyEJ+TFdh5UmuhgA56Qqx5iMOhBnvV58qY0cufWwtqg+1sLa0LIO5sR+PWo4ZOtGyyggd6E9Gph Jr0JOKDeXgJjzelbYi3rWmLFHOGNYZ4cjfRGFxGuqDfMVBhvjlKxAO3NCkWkGoHIYELnGqjwk7Sm HUPg41QyxQu6ZiJQL5Mc+UKTrvgFgcUE4xNrMRgZcS6T+xUDsyvnQIljMh199XC7J3WX8ZJY5sfs yrmS4oQDkLsLLMCKs8pkRK7zoda2S4pjtbnQm1jhNl49YcfXBgkJqbHdQ+4N6PDDh0vg8bLibASy E1unI9C0jz5c4FXS4umYPStVpcu8hUDMRMMna5nQDrrTf5eZWXECTrC4l6N2L4++qD24O2q/PHjY EOYZujB7c668OOEAZO0CCxDjrLB91XQhF0+Wwj1kSoL+Pkwu0I9XS2OU4fpkVaOkJOnxM7dXvK49 /H5Q4t6L7UMalRW18Wy7GAU0gNx0+kvGTJATcELIef+BkkuvgR6g+kqelKUGGInqAq4MOaGpGN0M pFyBBShy9lbYn4omswxe4j5ZcjRQfSsNSsLbHFZKSmfk6nfIb+arWrbBuJnUbKUU1kqaxxFVD4xD CVmNBQ/xsU2peqd2fnF+kNveC0PVE2UnsnzZqoQGk6MTHwTMNDkBJ5xc/zOInWBRL5u+/DyjJz8v G/YmywyZ83OuSDnhQOTnFoDKWWF+rnFORWDBpO12NXj80UIbpaiidHWo24m6aE3t6LKEfAQ6gD9O /cuJgBftWN9/I05uGv39Z+bJCTgB5V6yFNWD+mLxmO5Y/KrtsPeYJ+jKHItzZcoJByIWtwBVzgo9 RYE2BXrvCNJ7w7lS6iuDlQjwg0fwqBTCj1D41hBnAuonyO/WNWr5TVnqcXiQOL4aTygrjqSkbuKl MEY0tkXsmDNLeludhcCTUhEM7vpkqxM6Wo7uKZjZcgJOcDk6gNpr3IdfBn8VG3i6936a4ORuT7GM bZ+VkS/XTye4AuaEpiLx6eYolIE331ZIodbsTyNjERis8z0dFqKwbeeXFI5LwSfgF6H3xQY8ORJG r34rXH9W3nSk56u/mPwrAqnh1AdMT2w73AV0wBz9FWQmzAk4IeZechw2s8f13VYj7Do6lenGS2ee oJEw119LuNpuU5G4OSyHBRhzVmg5bL0R8J7xQh9avj1dn1RLVJ3aJcNlnxfCn7WVeBChfU+ueRHh zvwom7n7+9ebT165MCTs80fyQVk+X/3KXiLTWUqE2ZRzQszRGlPzukoktO9c+u3uc+kZW3nJLBXC bMq5IuaEJmJxzAw3/AkswJgbYYUi8iCdDCNcmwoD2pURQVXbidYastZeu+snUZXfubLU0UvhCdn1 HWsfizU10lIYSxx8SjS/r3PqemSrBhpTbnK/amA235yoci8JBq0a5nbnGaG8X1jmxxyFc8XKCU1F 4ebQCwtw5axQL27paxFwiEiiRE9sZioDyCR9ogaB4xNVabg6sVlSBdfmy1tC4Wk5PIV/6B/yPA+B ZSEIeIqinHI7ViOQNBWBREmx3YrfbS+F7X9Idj1sTpWdYN1NRQfK0WuFmSgn4ISU69eoGtzVqArt W1z1nEvXsYV/U5mNOlemnNBUGG6OPpUFoHJW2KfSfpBEJimrtyeqE9OXNktKTuU9VdU5Q3HbyLJA 3B7X4Mel381sL0UgnrwWjN97s/ePNQc3YuOE0+lnBJm5cQJO4LiXdaPv+r/BXZUQt5P3Kcv0jKXa b3YcnbiLqRjcHLJhAXCcFcpGvLYWetsTla+LawN0yzcjsNBB5I8rlsZQH+ZLWrbAM/XdsuBFSUXV 5yWaNt2gZjy7SH/sUJeObCiQZtyvXfG7cnZgqpa1OGg702kXRwmYKXECTpg4eqdquEdnp+q1EYt6 NhgKlndtMLx8gwU9KpjG7MK5kuJcTIXf5mhUWQAVZ42NKhhL5smH4oUjm6h5utALb3Uie6v0u9UN 34+BGh++F1wqfobXr9jhqZsvuoTAgXVakeJdBIZC91gEhhGNu+H+NNv2xQj8XaQJ+wK/HKL/H4Oq pLCWCs2N0xf4zJg4ASdO3Es6IuyLyNf3ROQTeakslcLsxrly4lwGIiK3ACjOKv1H51bc1fJGBIp+ Yv+iFGXL9TGHOjfshknuqqjFN7r26+aXtYTDhE6twSf7b2gPvyjNIGc+9F0BxzxzPL768hPWtJCG jhPSUxBmdpyAEzxu2R+UJTkwtjcDWZ/aXTBOvP+yzI/ZsHOlx7mYyMrN0r6yAD7OGttXqRJFLel7 ZiMCTsTjQsfxujAERh6QRRwRVYUoVo7xbfKipkDv3gE/XGuDACGK/hKBamdIwk2JCCwhOtp0x1hr g3YlOT1JZ+bGCTiB414SEy/areTd15JnruNlME+QmRwn4IqOczGVpJtDTSzAjrNCNfkV3parf8nV uxscSXCIzm8VNTYLz5lKpk2CB/w9n+fCeTHwlOjBXIMXIdSj5ZpWqDZYlDQEop4YNET8Iqpg6DPV Tv9dnUpyqVNJPs5zvcG6MZFOjqMbFGZ0nIATO+5lEekL0td3B+kZD9hWXczwOAFXepyLiSDdLCJi AXycNYqIFxm2t8KztcbZXVS0IkvfoB6fCvPIPUqRFB+7PQ+Bd0UqRSicjMtLGsi1Bv1gFQsjDa7f 5lyMmQaHcaLBMYhFX1Q+vCcqf4eXxjhBbDKzSedKg3MZiKjcAjg4KxSLRCoHl7U9wzsqliOQU6a/ EGFrsOkOkud3EPAtM7hylXsIAkG2WudxlICImoRAyzp4ph5PmKoeQlCpourzYs11OKfA6/7WxPwW z7Biqfs3jqx1QnPorvTXk9GhY5xocJXG7YlXl126Xf1qce8pckH3KfLMRJYlFWZEwdE7vRhXFJyL qbhc8OerBLMACm6kFUrFLIl2g6N+Eilds/sQTN2EuxNHSsvVuGxfemOuOm8kAlfvUCN8ERgeqFka QC6WVKxW4gpBIBkd2HHv2Ay5btFKBD5eCZ8rbuVCr1H4jaN4YR5bIILRKHD0JRXGTIHDOFHgXpKT 4X1B+tWeIH0+L5Nlfoy+HOPKgHMZgCAdswADzgrVRPT8jn45fiOFcGB6KqBSierfJE1T1Y7E3VJq 8Q14CB9rHHS6VRanapQUF8x020vE4WOfPtU7wT3k3v2rv6ljW3phk5mDdIwZBIdxAsH9UVJ64aJ2 xaGdghLXwPNknhwNAkeXO64QOBcTIbpZBMUCEDhrFBR+e9UteARXOZbjdZ4z9d4InE//GwKRs1RN vlAtlWm87174qcC3YsUk+DkCer9cqj51FALjcWrSKqj2scEPEfCowbNvY1tsYTTom6Df28dozDFO 0LcKWnIYKuxUkV5L4tUTqxfxFrBMjzFWx7gy31xNxeou5qiNgffl71pfbTQajIhdqwyBG9kVCAQ7 16UgcCgoHt4OKDKssD6uiDiNJxlMimeWOo5aiMAyPpQEKtz1B+BpEeVWVpK9PV0thNEBHeV+hb46 ewQWpVONk9akkPsQSPCFGrY4BKNB4IT0ZRczBA7jBIGroR00H27TtfDa0JcgftVz0DyA5cJojBkC h3GFwLmayNq7WNZ/umYG3saPskI9WYWAzPCCH1M4Vhj8uo8QBhxOdyeoFWW6iGWpG6i3e/92iWHS JgRO51JPP6xDIHkl3mTw9N/xpiHQfDRA74E/uMxaHzQCXL/6YHbvHAhw/WzJ8Nk2ndUx2ygp47q7 XLPYulw0Ctx0+jBH/+46AAE7ZgEKnBX6ElV+rf6cqlHc4P/CDwHfMdQ7pPKCMqC5jogTnQwN8EFA 4V6NQCypPKHPRcDBKZGybVhdKyN0S8NEjfgM5T1NMNzp/11EpKTcMT2kIks/JDjtSCbb9l6MRoWj b0XBmKlwGCcqHIOUjDPmh14buorl8mGWfVuYEQzXKQPGYY4m3tVUuG4OLbEAGM4qtQSXTSxrwrGX HzICKnSOIyn+wc6Hvwa0HsPP4EWXDebFPlzvS37fN8JaF8ZF/2T6qp+Z/4Zx4L+5/lJOO5++pOt8 Oq/3fPqJEz3Y9scs1xViQsZUHePKgHM1kaoLzeHYLcCA41shyseNMLzmx6iAknzPdASuGxZRvmrp ISUCrdG4jEzOlRHasemazJQdhqXYMgcEPBx6h3LcpAgkffu9v86nSCbXOon3Eg639QXwTEVruMJv OQL8k9TrorrSzyR1bUTsAnLbl15kRLhmAgJitgsQMBo8zrXfm8rs7jnB45gUpo90ktQNdb/8d5YL pDEjPq6fWeGKj3M1FbybQ2AsgI+zRoGxMxiPUQgshHMKhxh8xw9EpSjK+W+4PjZEI67nNbQf3I/v mWD42L2g1T6giq/6el58+770JvGLnNgKcr6vpqjjHhsCCKPh4ibTC4MZF4dxwcX1KMzbV4pvjl74 Xsx7TfaffNQrMN3XqueP4v3GPD0jK65f24srK87VRBJvFn0ZeAf/ivUVxXNti/Ie2wXoGA3/5kL3 3sz4N4wL/g1b3vdjL/TosRN9O0y8QrvPC15m2WaFuTB7b678N1cT2bnQHN7bAvy3cdb3Yv/eyUAc SS5Q2OTr78Ozvq38w05KZbg+NuBqxJLzDcl4SWaZbrLdz1pPnU9nSj6o7VSSwYKXiuov+j/gVyRS gpSCK3oXBBJcw/+Jz5doridL7tnCpTsW1Hl23PYW5fDJOL34uuTFf5PxYJHOXcuPFKnW4ag8WyfR zEPgAx9CCP8PryupfYJX2JLbWGN3GjxuGj0wYYbHYZzgcQxLqnl9wXt1d/B+OYLlrkKMGR6HcYXH uZoK3s2xpLIAPM4Kl1Qq/JG7pFJ0s0DevjRQI25zegFHrKTGkcV1Ufun8+qiUrzJMARGQXe/9Lr0 9ly1gwwfg18jDrAXg5EkRz+UizGT5DAuJLlKWngo9Orq9tJqoZvWnr+E95h5gswkOYwrSc7VRLZu jvjQAiC5V61wIVX2lKiBm1okd/A0svSeKBOBVaznPDAjCU44BaOPM/toLiQ4jHYlwc25nR2pER8d 74n8Nv+nK/K74jHsbZb5MW5fx7hy4KaYiMmFZgAmYhbgwH1khe/5LFHdUxhzLOMRAvxAzW+FYtv2 DlGC4gkC9+ZRfol6SZTzVHiX3ywTVZM7txHPyxHwSYKJ9Tz/4TpXfLBuSf549VdwqDr2W896GWmr 8CVy7Mj4GWJNCgLb2b8EoPJLCJzGW6/tMlh4BOr2DoUHEChizdVpILl+6ypmkBzGCSRXQ2Od9K6r er2LcF53bpjGgsnCmEFyGFeQ3BRTsbrQHDU28Kbczgq9yx1yCzxAphQEthbpF6ilLZIifhO/JDKg VfEeUVfiihcdfgPXzjGUA0E9Kn4XgeadCHyKd1yJEiAgGwwPIvBiN2sPl4aPE9DX88z4OIwLPg6T 0QpDOLzz8NTZ3qNTm7sPrGeNYWG6Y8z4OIwrPm6KiTzdxRx1YQF8nKMVMoAa8JRIBD4THXZeE64/ J9fE6+YaxxxV+vEP04lGyb8vIBAXYVOG53i2tvObiJvnX3RsNKjVThhDlhpHMyIMujIhnRLpapxl uGIkAokIzLimTyfjCA0CDQbFqdS/QMDh873wqPaMVgWXn7SjJik9lHIyaYazflUN/jzkRQO5JRCB zQhE4EWjegZY7Y2RVefar0vMzKrDOLHqGDRpcN9er83dh9+vjGABxWNTmL0+V1rdFFP5vFmKb+C9 vjWKUiMUPvENX9AqwQryRft0hxG4Y6s5hMBGUaUnFWUQoAXQJbqN/KH/B3st0Kw+vbfMzKLDuLDo sCq61++qhN7boZ2iVF0UCDaIKUYj0dEbEVxJdFNMRPIu5nD6FiDRTbS+QmgW5eCtx+WVolv54hYJ uXmqRtwmje8wqIB9JDWOVOY14s1TPRE4KMPPSxtiETh7XwQ9vKG64NRuGP8tArpJvh0lV+Edifrw jfZcdapnSzQCnyyS7MUdjKPpEwr24ZrdEe4Kuy1iGKUqPh/3u2F1VzlGZ4fKg8u0ge/DT/kvDt+R NN+aSh4UqT7JEsl+DtF9hD/wsaPmyBs6Sm3gf0LaKMUPCCyZqoNqtjo0cvBcO3+NjePMrQguHDxB Z/d53uDZNr2KtMGjzyV5dbmk+Pk8H5bpMW/Y58rBm2Iiz59KP0g/jXMhDnQr4i9gvhUW4msR8+/e 99pcsnPK5HDdP0dWv0FGZucn/HpkUPBalfqZ41l73ftBYYtjHF69fUmueOj9Y/32R+mj33W48s3s f9Tuf2PkurwPzgUVvfZ6VtCamn0/iQtP7Hr46KrOcUp2yxfFZzvunHV7a7Tnwf7/dHKO3fGPlCRt 6v5obdaY29GdZLBR53562PRW3albD//kv51ReUtoa5H7Bs+FuU83VV7HEoqP1wW/jUdvzWuvi8tI PL3qOda0wd5r46ItOTzRzYLV5JaKFVWVkzrsv83Yl5T58bR7r/KfrFkla7uQ4RX9RXNenv3EbR+6 FR1vXzD44fnclIYd6xOxClnoN9gK9ZwdYsGz/UMvbQvxvaW/9vmm+OQn9Rsz6v/V8cGGR6Nt//2j o9Bjb8alocEn177TVj9hfZbLuYLRb2+9UfMK321u/39OipBoZyoX+MbWrsv5+bNFuzZm/++pjg1e rX6UqDm8Zn/6POmVr6cdjn7tRtCw2c+vJz7O1uPVqrQxa3b7/3h3yyfYmwdr/vJdS6TnNRxVKAIo 6YVM39qUpsdEmPSj2x/8P3nnHtXE1a7x3VorSPthj0sp3lK1XioKygQhaonWtmhRqSIiIMSWKt5z FFHEkql6XLb1EpUPEW+pUkAIEAWRFoHRqlyVqAgoVmLlGqIfMhAgITNzkiBmkJmTs2ZlkT+y1BUY dK39x7w++9nPu3/vzMYH8ok/5imLka7AyB8kEt+y2wLFqoWX5my+H/9gkSpSEQ23Z6uLeEGSxF+x ij+iVoc/ifP8PRbtqnj51OOzzsplqwKj971nvy/4X6mzwg/bngzIChuVWBO4cOuOFR8MWfvhoVlX 5M/Z7t9tefpwm+hw2ITbj1dOn3dy5vSmssSf76n2pyq5aT5RvAsNnzcE2OdsHHTUK9x9Y0ATvEo8 EfmqdHfpVSi8wvaTc69+rMh6iP+5YrHg4JmOs5vWtqSMmff5M1Xq3+cy99b77Q+QRcZcuVx9tP3K R4NCrwyoS35apFjpuOakT27H492eo+W2G+cN2Tl7rrs/7T8gHjgFqE8/gFpaTkdF+XpJ7GsPbpxQ wbk8MP0l4LKDspSuv4fU1LhOmpgmCoKKhld4poR+b7OmCgjW5fKb+AukBflbliwOdM8JOT4tJWZl /a3hJVeApjw5LzfSj7/8emO4a17FnF8Dg9+vr7j31GXO2fELj3jtzfStlIinNZ0cbft+R1XBMc+U 1X9XVY1MSIz6ff2MolcrktVK5Zpc7wHnn1V3rUQ/Czs08nTA/O0P0e2HJ3LcrXhBeMb2EZc25+dv /rr9wZqKPxaWzR9xPKTIRiGr2LJvxYd/PLp7sbpqUXal9ax1wcsWqcZG7lbfvbfhRtZI+8yRTxbG +P8zafEHGxaKJtS5Re5Qpw0Ha/Kefx2fNwedM+/+riWswDzx/p/s+X8cS+IL5wiHbA/yPlDJT/5n 9fsB//l0Q0CNdPyt0XZEWQNL2cUdOfpIwk+LL3g+Cb7qppn90bM/CzCBNL8gOOm3oeuOtz96eYT7 r1vhjlsJwMtoufyoad17VZ/mXp0dLLx5eYzNZ7JAwaUzCbX8dVUhq7ccqEnBHf5/j+KbuOjvRTUq jnoU/PEunH9KHiHUJDmH40sEB1j5Y+DT9dlBcVpbuegcN0p0vqDlgKhelaC+rDmSxz20k/VA80te CjxeIqwZXdCGjOOLWYWKms6CrZhTIUI8LEM646SsRxVnCXB7TDief6UZn9xa0O7SQAB/ZLaKzxW1 1pSoYkTYBk1zXQ4OS4VO9UGwUtyKnGhVEcB9DhK7dRg2sRVbIvD8WSJ3FTWFoqu+ghfmEMBbdPya dgszvhFzUrTiLf9oJuzEnT3uq3mVDVjNzc5vmjU/COPaEIm0q+DAqxiivCW/o+FIScFI2bnZTqP4 gvAXmbM80DnSGsEeNXc+vveV/9nxqjEhLchcjKXdA80Ln7bkmEYIdcp+EwjvEeC3nGEDNOtwSFXe 64O2E8UAJJ3hRp7h7ExNJHVmQiT17vEKwfNtBgZDhj1KN+fk0PpB16kXR4KRsslrZnqSa6y7ygSw H2czwEgHW94WJUspIcB/QTjvTiq2kQC3dHelWh1gfwK0jOfWaUrKuC+sI0KwPU6LCHBpAu3Lb2jD ciNbZWrEqDMTxGil4dQoeH6obo8O2RhOjdL0p0bXfrJqoikA6jYspozRmUbasGaY4tTIDIzRDy2v AJ7BV0M0kohK9S6NeI/O3OYqePIGNG1Q11q4uCMVThQVZzloC+O7KAJ4joAbfQ5uQzRf23PbLifi +1e+9SO6+iARRWeQTSI1UdSZAVE0c7mhOiBdzwgUaqiO8/rqEA+yOkyzPEPg0mt1TM9UjfRPzTBF k6IZgKK2FlgdyFUP/FPbFBa6vmQv/pjVedT9ElyU6GjT9QP8fK76BgEmnhEqXXEXRO6r3fJ9EUT/ De2lQDJSlCwe1EhRZyZI0RVviiM4VDfwAwo13AiEukd+JGFW+6nXRyKKkuM+pkTRmUY6qkxRHGYA ig60wE6T0pIns502vaB9sw0MUKjXtoOaAerMgAGaaeihenRvka6H6s4q6YLXHJ7Kv+fqmwWvhVnV 0izQUHq91sfw7NLVSBfVDFN0UZkBAjrE8t7tVm4KDz3fBKNrZcU5UoWd5mKESBObhUog9W0CTBmT qP2ff7NGHNDFI0BxYhwBirIJUH0iqx0hQLSXBwGiwgiQO43/Etb+7XNC7d9W6Huk6CqFNFSTtAWB qEmhECNSKGmcR3DwJzOhSmjZgtcIRNfuaR6XcauLlOuDSKDQXhrA0EC7GmmFMsU0D2czgEItcJpH e9R1/JjmYJXXALUH6rR+jq2cVXjI/efO8bYX3K1uNgr3bpfTnhkZuJ+Q60zy20ZpmyFG3M97ZN8M 6Tc/0Jtu8r8XdN+sSKfptoAM6E9ytwXEFP3paqTVyRTjziAzoD8tcNxZa3MagkoUIjRC1hHfIAuE 63iV3Fol0uwpzdNKQTGSBhcp4OoTAe5RgvFoytXIiRqPOr9N6sWdwuK8/QS44RdpQ4C96Wo7Agxc Q1MhEAn5OcON/JzSOEOMkJ9lhrtHel0YkH48dFi4Egq9e3jYKnTXO+lxNIM4IBLws1f5MvTNrsZ6 kVxNUR3975tHWmAjYI5TfBTm6hTwl9qPW7bt9bfjaiPtev6MXb1NMHnlKNGvwwdNep4mTm6iLQFS GxKJSANRkzwhRiRPKpHo8cehryduzLQSUy+QRPPkkB8z9MeuRhqRTKIRZqB5WqBGoHgSLq4nQOJj vM03Ruml5Lli7tKOCzlIMpysQuTtcO6wUVylx1CMI4r2sMWW3iLAkpC6pTcJsHwrtyxW5fuQ2/5u 3nkCXBqmtMV+ohu2AZGYns69aoTSaEOMmJ5vy4T3G/PgozcPF2qsltCszuCyyTLBFOnpaoz4YQqZ MAPS0wJlom2qrXK3E+ZCgH9LvrhOAN90ApTxVN+Qnqcdkd4NHC06lT2b67LGtbPjxxXesHDnbf2X PqI7uKRVzI3FeA0rYEiNlNIdRUEkiKczKZ2GqCGeECOI5z1Shcz3HrJ+bXLIhZ5LFVsS9BnEDY21 DfUCDQzP3irC1GEbi6hNUiT977A/skSnIYHRq2qtKExqJsBuB2lertZfPFHYakQI9kLirrsC4cBP 4aICAnSkZ8zyVYv342d5dX5nHTCfv7SKIkFTSqPx5H/gRF+V7z2bxoFt79KWCWkSB5v8dlI7ckYs z7eFpBxa+kZKXo/i+JlmFAdEQnmS7RBTlKersVEcpqgSM6A8LVBKFBAByn+UqdjNxdl3CKDdauGL Z6NpGVzM9y4BopZoxAlilY372O3l8NiQW46nJLVTO/d7jfUuXI4O0UvHPpWoHN/O0ikK7T7LmTrH hqj5nRAjfmcvL6JTkXffDF3O+lZfHjetaTCFkAHe2bs8mBpyY0G2KayIGeCdlnhcJUpD0AxdYK0T kQiHUoHukEqqGKQTkUYJR63Qigg3haUXkQsxD6UqnzZp200cXaaOJcCUvFj8JFz9Dc+bW+dbxi2z 7SriLSDAk9GR4wmwKaxNiF2mO+SFSGxPiPxSUrM9ISZszz6Scj/j2x5JyeqONtJzra5Srw+ijLch pmhPVyPxtkkkxQxoTwuUlPISAkQjqwiwGF+duY0AdfxKbhl8ctoqRBWglLbJ6m1C47CR7rzoLdvh uJASNLVU2LZJJfDJ4LPKbdZWc5OH382Bl0+BT+OCKaJ6Aoh+TVQhDc9pPQqJ3enc61WkdvGM2J19 1OWCYWbmd93Qkb8OW1vTLJAyLoeYojvdjMXlppAXM6A7LVFeJBIeesXgUUrzcuHish6LMkut1KqL V49FiXkoUS3TqksBnMNxSuKh8XKR/AgBwrfxliF1nlp5GY2/qmvzwDJi7rPaS3lfwk84dJdUIRLW EyLvyKixnhATrGcfdXln8IRurKf/x1P0WM/0eVZJ1MujxnpCTLGebsYQIiYRl/539RYoLsJKWBVY CyfMRl08FIgmDdW+9qoRcUoZ7ruLJT+iORwIf6WGm8+rvlConcoIEGlbbMe7LxB1NQq+zUrBodrh SlH+j3urMzqlR5d3wQhy1vsljuNhXlldXbS3NCADL5QNkf09NS8UYsIL7X0MBn1S+ejOx4VLundj mdOX6XdjN1KtB9IUDGWjOsSUF+pmLHA3RcGYgRdqgcdgqCART6qH9VlKlJKr9IK6sxRREgGSd4n0 YcoTAmyE6+y5cg80TdYVQIDJRTrySPQOAlTJVF97qZdqxI9jMpzW0jViQWyawJ0a9gkxgn2WG3oW H33w5Sn7AUWvo0ab7uEcN//HehjN6qgDd6agTzdjgbsJ+hUhM4A+R1hedRSoy/DUBgIkcrEXKXAq t6kaVocSoLqY/IO0miZb9TFs9TXhRW6Th3Lvf9x/I0ASq8ImcZTjmf/O3vrXXQKcSpGpknWftIdg BgQom8wjgKgRoBATBCiFhqzsaer960t9z9bl+VZx1OtzoTb0TAmgbsbyeFNIiBkQoJaYpDilsNCk Jh66Q9aRnlOiGKRJjojRnM3SWhRn3dHYlHPxWgOzWWdgELySAE0e3lrzzzq2UysfBMAWNMHyONSR ALqm36TRXhhb8FWzZ3VMLh3JDXIhOXrydoaaIgoxoYj2UROH1zMH/E++Nicaqwya1VHn8kwZom7G cnlTqIkZGKIWqCbxytOYdxML/V7akZ4UuZYAy9UHNCczsBfJPD+k3P08ASZO1VVJHF6urZKgnZpY bvPY7XAVgnmWEiBqElbrKOzy1RbJLhn6AwFy9j8epvt1mgAufkirj+6TdgdGwoKyyT231FhQiBEW tK+8LJB++UZgFukF5sZx6/epV2jggvZqCmbKBXXrj6jeDFxQCxSYZ9kS/NMgbXl4jtTuvc784Sgm wC92F+EH+QToSHS0SSbA86+aWG2XEUxekqmOxePrCFBUQQDnl4IEOGkXjIYhd67xkkRNQTzNWX6r 07ag2twi2sMvEii0160RalAoxAQU2kde5LGT3wiMQ/fUtPV0cSQ1KBRiCgp1M5bWm0JgzAAKtUCB OVDBUvKT4KLT3CnUXz7BtVVRqFWdWFbz2M06W18bOR9fJOw4epUAmQiq1yCPrsLAX3S/ekRF90lX LAa0Jxsi90hSoz0hRmhPij7i+W8mo+3f3z0ZTWT9Ec0KKdGeEFO0p1t/pPdmQHtaYLzSoMMsZGod SW1+SJ3DGR2ypFLrQaLsRf9O24ZoPANhfNFawbJrgmhNkK96p8qO/wA5WEyAJQQY91Lt27KLJ5fV BsUQYHXJAwK8sI/gYftoTctMkr8ncdkhau4nxIT72UdVmvzeqMrKbtty85z1SOr1uVL7e6bgTzdj gb0pVMUM4E8LVJVEpQT3+dwXX0SA6cvxTN3NXO2Oq0hUP1hUgaiWK3kqSHMjDP5WWznafVeCsNDO V2mrcuep12n29Hq8fLfjxfbApS8y4MLu37SZvQHO2VtVqOGcEBM451tuRQ83MahK/B69qtwosn6P ZoWU8zYhpnxOjrHQ3hRupd/xnBbpVm6oo/GLYc3qlVqnPn/w//Vd2yZuHRtOyMDkETNZ6ClumR/e ljvSVrWYJU8hQETQz7kfRYyjLRGDC5hBPgSjBsNBTMBwffXkzehN/xGv9WQczfQ0iASH66UnDO08 x1hGbxI96X87b5HHYCW4TyAPm635NabSSeUTBrc1o1N4q5A6n3IClCGF2fyXfM0+B8xlu6xKpnrf V71BjmjNyQeStvJHgm0vuJwdrDMZSHH3b3oN4dAUCLWNZ0CP64tJ+eBWTyTP7o7kr31rVUdTH4b6 JR8yMGXHcYxF8qaoDzOw4ywQkjKoXKIMUNhhU/laEZirzsTFkd8TIP4wAZoXsFYg5fwUnv6oK+wk qySJAItCuu4Frh2ENsFl9nibnd8eTbaoLR/OHUhXGGRsnDP5ObVlZ4CN66Mcex4V/Tk4Rx3754n8 wY6qHHDT13oozeIMVUt2SUyhcZz+yOLNAI2zQNmQqlsJ4PCvVPys5kYItosA0QdWaL04vjoDz9F6 kptiOBGeHujUfgX3PIufkhXaeWKp3OMNcEIWOlBrzzd61f4pk6dq9uzIrdz4dEduBV/zeC0B7p7Q ftIeBZMgcmT6LkQNkYMYQOQoUFtzeyKTB92ZvHiy1T7q5ZEYcmQNYcqQ4xjL5E1RLGaAyFmghjwk wOFNiMolpM5f1JIaQ4CJKRqxN+6SToDaclH0ujZJ3RUCLEYov6ItBwN5jj29VzlQ23IG5Lm+nuPN Cdap18F7Od0tRg518M4UO8fpj+DdDNg5i8xFZKoV2OpOUeF5ZRbug6x0n4ROjtyslRB+he0vmoO8 Ln94qAg/KS3MJEBmYguHAPJD5MfXvItfejlkzklpVqWXEuD0VO0nbZGQ7sSTtjBsaugcmxF0rk/S /nCZIWl/8Dppx2jwW+zp1Ek7U+wcpz+SdjNg5yzw7EqelwUnp+G/aMQJ6qd48jX1JDTttGKnOrm5 UVSc9PyV+zvet5/9+G7iweudAxsV9yvjaNsZSRA6znTyu0fpvtmMIHQ+b/F3vT0/H9rDF/IM7eYL edNcUGQbGHTklng2UwYdx1iKbgIAL9sMDDp7CzyfitVkaM3EU03xiRC0NBUX7Wyd4icqmZWljpTd yW5+uQu/MBv7XJGGV4qaxiNl1YZHCRmN157B4+QpasdOVmH2RveDeYPQqeWnMnxpyoRNItGRyRBs ahIdmxGJrvflRG2Z2PRMA0yL7w7P05OssmjWR3n1nc2URcfph/CcbQYWnQWG521OKQTwmBZhVwHH nci1UXDvl6wKdT9VE9tWOUqakE2ALhAIYz85Ivh1ulnlbBKEzo389lND6NiMIHRv+Qn/RkMm7t/t KG5ZW4+jXt8MykyczZRBx+mHTJxtBgadBTqKa0ox7hO5Ue2Df5GGbdAaCZ4/Hg0fFSP+SJ1vBRLP q50sq6ppVLLkGeh4eKMw7iGcIC08jKW5C5fip7njXgodrs5Je4RmEKC+hItv0n/SlQmZQ0d2FNQc OjYjDh0ZYz1/qM5RfGEgvt+73o18L1ZZO9Es0RCHzyA/Zui9Z0w3lodzTFEq/W++LRBl/b/knXlU E9fix6fFKlQr9llUVMRXXKEs2cSV0VJc6oKKEGQRfaio0PIsUtxgav1ZX1UIglZxS0EUWSRFBQSE uCPQypqAoIIGZIkUCQmQMJn7AqgZDjMnvzMvx/yRPzwMl+M594/5nu/93u+9n5FGXEVjAWQgZ8cH BzYYd5sX5lokIzOQ25jr7UYkKRyL8RoZorhS23zy7a/eHHQqgFJClJOInshOuDPxLDp84iBm0TEp segGJQ71x6K2bbzSx3nIPmIoIJ4gMYuOSZVFR7PTVIlrI3LoAEanh5HD2BVArnO7FEEle3mKxEp+ +YWDAkSwKhc7JytD/Pmy8bXSrjAn4kfBvMP7P205fy/vk+BVL2o/vu624y9yjcwh0QhxKqcEosPt TPn2aSToPRi+5HY/GT7rlmEJiUaIUzlVEh3NTkMtTtfCNwWZOkDRfaGHPvKchwbzWc25Pt3iMP/y vfx2IVppKjt4BC73uFmcMnENdkbwMHTjS45UmFqExfKjXvNbJsht+h7J9IAjz9kN0ANx/KZEnhvk GXg9uPfpIfuuYTXJBOcQ64Fi/qbZaerDteEZOmDP6aFnPFZUAsgyLFEJvxo+T+yDJioSpAA6/VXb VUSS0MItxzZm17YGYfG12AVksndgZxaA1gYCyBmOtMns8QJQoj2AEriPxrr/bXwnOKIO7XvYmiI4 Q3aiiolnzuHVQsycY1Jizg3YrOpTy7sdXUeDfmR80i+GO4nnR8ycY1JlztHsNPXh2tit0gF0Tg93 q2STEtFEccXeBEkCb00Lt/BC1us2kS3G6TAp9kNMESlyOnXfvO4iAF1EHwQgNZ+9+0dWhTPVVDnG HHv8OHEmp0SVG+wcai249GvhguFukvnZE2uBciDX1IZrwzh0QJXTQ+O4KKvEXE35ZZ9yKn3k67YC aKkl7I00rDmrnJzNbd2JXarvNwYXZSpccYsr7ZB/3IKk5ytORfc5iW9OatqzSve/xQv8UmSk8sCd TscdxmASA+SYlABy+C0ru8qqihFLp/Vv7I4ff3pm385uYZERnXh+OILcAHlQzuKaOnBt7FfpACGn j/tVWCyaVTsMyTVpVjrKg/JG9oJ9yxWHJY37zTCpm7kLtobzBql3D3WWL4bvAOj4JhncMA5AwzCn WAAZ8ZsOYxFXjbtXAugbWBq8DbkbqPinyleSSaWCy+T4d5EYHsekBI8b5CQMdVPuaNBflWfHG9aQ iIXwc21MqvQ4mt2H6Mp1gI/TyxDSeyjXq7YJQPlHyH8Rw+m1irPRvUd3g7nVbcqVBX0nd7OLW0Ow y712g9h5+3aH3E5NQ+fVsd0xszdWp73uviItDnE8OQa+ESHmyTEp8eRw+1iOC0arNOOi/rqzo8Hw Ps1klRkKSWZIeOucSZUpR7PT0JxrZSNLB1A5fdzISuE2VKLsS5sBZMN/mWs1XR4MIJPjgrCTcHlg w3ozdrOLchbm+m7AA5ENBxAfjtkOoApbDMW2JABoNb+nQ36KVB64b5/je3VilhyTEktukKUMkEf/ 18+znxrWEc9QTZMbIA+qNDmanaZqXRuWogOcnB5ayl9YVa3kRqbCSZVMAgLlHp7KL68jGfboVWvs uLdzZybmeBa7AD//WpVJ+JKJtdJ2TKKKKlcBFPlKZSScrsicYW/aDngf7LWTO712Mi2LVUB2TpGJ Z8nhgwoxS45JiSVH4CQW76XiaNDvJKsNC0hmSHjTnEmVJ0ejaajWteIkOgDK6aOTuKDBR0ud24W2 TnC++3VFo2R6CpaF/iqGU5Ev92YBaBzc1hCE2SG1hY3oRpWJkDqGGg838LguMR6OSQkPN9gx1OX5 trfluYdhOfEEZxGX51TpcDTahyjPdYCH00PDSFBmIIKON0hP6ToAZRQr8sKMVZHdktv5BEDsYlVC b3MKBJC/sczWQknjR1oDqHUTdqkeuWwv+YSvTIErbnGkD7GFOS7PfkzIbnUOfpTq9IMVqVBwaR2f PIjhcExKcLgy3JXAhb1XAiuGvEO9s5hvL5YX7TBikSiFOK1TxcPRaJoqdJoWlKIDPpyJHvrFfK7M 10phjaZuOByNpWxBnPgni0okiOAYrylTkmUCoPtPlF+wATTaT7rGB13JLfUSIw00PzTGr6fm1Nxa +Yr1AJq2HutseJyJuYxBCn5DcrNIKxIcGm7A0ooYDcekhIYb5Cmj1eV6ydtyPcqwimSCxOU6VTIc jfYhynUdoOH00FPgzieKdUhBMt+S6ClHmcKveMpttpdY8auLlCsLsGjkS/WgzePiuLYm7qOceQ5H +XHIl69fK2ywX9GjEV4/iEhXYLNIynViPhyTEh9usLG8vzRYUtJ/2Tw7kmwFhgPE4dVCFRBHo2lo 17XiKzogxOmjr5h3lz/GTiJtViWIyHmewhVAt3iLABQ+v62ZjUlSBVLX6rwjOexSd2tsFYAUHpnK +pQxAJqOKK09MYnbcCSaj/2mivB7SNddOCIcDb/uIibCMSkR4UpxhaLKTob32ok6p/c37jmbDJ+R zJA4p1MlwtFomhp3pjb08eFz+jj900eTKpeMbRcAqCC9FEABtqJkAEX7X8SqfPJVi61ppWHxSKIq szhfl8QplwJorTnG9WtwUhzH4mGlQ3Fh+l6ehIHF+PSUeOSy5aYAWsFTNllvSEaPAegyG5OS1iQ4 RhwDvwIjZsQxKTHihPir6Aa9F0fci3Gu0n8XvdDTyJp4impM3ICLI1QxcTSahiK+9zP1/7tqPnyu H6OHruIJIIHqFT/VYFWqCvBuDMznBM+Jr3QvloetTfFVjnr37yAHS9wCoPhM5evJIgAlrUeaVSF/ n+FsALX85qNYjjy/S6oQHCRugEKI4zwFSNyAjMIYtX1Hil9c5Pttr9T+ba8bhk9J5EHIemdSpcTR aB+ietcBJk4PI0pbdqXiZlsTp9G7ywNAbDPl56g4T+zTIuLHweeDfNwA1OBUAaBYVHxGkQkgS5sE pXGjV6WAL18TDDchc8U10gDsgPe+sHBuiRUvsPS64pOAqyevkZ7+xWHjBpxTIcbGMSlh4wabydLi r9Vm8nW/mUSTnepSw+MGmAlVeByNpql014aZ6IAep5dmggi+Km5G6IMf0nxK5VYmSvOo3oepPu2n kEtI/l1VhjENUbDR/e9HSIWhTu52+KPAxJA4JgVIHOtGCe4W+7hvzoxvfn+Lffz4t9fY/7xj5EQ8 wTnEyZ0qJo5G01C2M7SR3HXAiTPXQ+CPA1/1np9S+hRmO/MA9FC1jGJLUqPFAGqPQQRoUqaAL/uS J72WHKpajK21BNByy3dDGQ6pAErctd9b7pYvqJXZcI7yLasUOdil0vaQBo91ADI/r/wUFhV9yxV1 8GOXoHu2u6BhIdIZAOKQfSSBiQPMsQa8qsQpnxJgbrDHGKoPDpvO6D84/LnRVJIZEqd8qpA5Gl1T G68Ni9EBZU4fLWasKnuMAdBSbGHuJ6rocYhfBkfaLkIUsYFSTr1hY3dUBPLrDNWPw0vaTX3Kzdu+ c7zYfYzXzOnKiC1FF7Ol+T01pKAgHFXODqcMFjFVjkWFKvfWY0bdq3q0tvibO71rLzUB4tHqvrXX 3XCjjwknyLIjLuipQuVodA0FvVY85sPn+I/0TxedslZxDdm305k4UBwe28kiBsWxqIDi6OvUCdyx ryW0UJ882RzfF8GzaCTnr1jEoDgWVVAcja6hT2doIYKzdECKs9C/N/vvXlyiCbqkYXi24hl2hd1u fsJGLA5RxPrcD1t9qzEJKbxWLLcbe07mLHfrbc4/7riQqEriRXD9be/n5qUJSlpyzj0FE0CXWSG7 kcVc6cMkbo0xtiZ0ici5p8oVzjBH4xSch9yuP5KQAFjuJDMPh9s2IaAkXc6VOgJokhufgf0HERVW vkJKjdE9ZFU8C4eZm83CjxNmdxYlzNzgddUo9akVulvfqZXCVUZWJDMkPC/Pogqao9E1dfFaWFex dECa08N1VRvywolbBv+ZU9u9xk/K6bDpwr5Yr7RAH4kiI+YYiiKTXdFgAI3BnDx4Il53psRSgJgh D/jHydWgxs7h7+6yiLFzLCrYuTJclWgRNGr7DsMp0UEmu2WMoM/CV3zhJdnz0d1CI0Pi6eGocwNm RzWu0zUU7VroEVk6oM4N0cOVVPFrvhDb0sp9glxFi2rgawDyJL0FwlJj4xiz6PhxwjDNooKNo+O+ XjBuxZmfh6hfcpPel7xotdEsksmpN83whkQZGEfX0JYztMBWZOkAGDdFD9/y+bDoNXb2VNoLAJn7 SZ/mcoy7e+DLDa8AVOOo9EhQcCNt7bFq8xYBXIEe2MPvLAGQWyKWUG/oPVrOQgzkq7OnS3ZgwySx u5zrBahxA5ufMRa9OJcjTQbQXvJffEDJHQDFI+0PDqpCPIBER4dhxwGUT1avs3DEuQGrKmLiHIsS cU6I56EY9IUXx/dnUiwY/desfElwWiw1cm7Aqooyco6uqV1naENlHz6Vj9XD7PIE3YkdR5Nz/Nrz FUskqa3cfPNm88Jwn/aG8XxRIQvJPzECkS1UCYKvfPFoHIBaDgBoGdJzL5IGIIEBFgWgrsNkG7ks HGiOhn/ziEFzLCqgOboAJw0LRt/FKpw0+i+155wlOa7FUpPmBkiDMmmOrqFZZ2pDGjogzVnpISyo EUkOB9C38AnbDSGKm7XSi/Kv1WNWbYrpdTx+E/fnPADFhQ0vRjKc27vNm/l/3urq2ayyrAPYWbRI PZoWpjKXGTwlLBfaCpAGEwAlAGjuAwUPjeNLAdSosp0yRReALFcdxX6TXZK1YevOj1Vai5eLa9HE ubYKTyHSGdjViO70A9BWAIUh+WPeDpAGHDXWjjVgs5gYa8eihLUjMCYDHFTCov+CfNFoIwbJHNWB H784pUy2o2vq6rWivw8f+PXRmpowxit2yJJ2Lj0nGz4mPwGgJ8bSaABthsuclZEqG1qCMWM60EMD f5DLAZf38VvMxNw6FhVuHb0cH/hd+s4OG7z/mnTs8Ut931n4c5bRQuIpqtF1+JMrLMroOrqGip6p jdCvA3TdV/qnhhY4A2k/XVsGP87mtHLRrfZSTkfqxR6VG5iGKy1QcVYT0mLvDKAoAXIrtTEWQFee wdhyV0ySc+EwdnEXgOTW7J7C+9gTruREQXemJMW5NQZAM1dwjyKW6lHejJxjiPRwmFPD2J0cLLLt 0a24v1ULvTIz+VhQElAs85uALTPvOvGE2/LYHo2C22ZehwXnAuVTkOduY5ULaxt7ioZjvwd2KBsO AWi1vRyTkIlRDc5j0Rn4ceJdCSrgPFrvRrTKk1QinLw9fmNAQOL7A5cBv/e1PUm7DYNIpqfel8Bv vlHm5jE09Pv2+Nv2sykr8UNvTPwDWqyHShwatrj6mcvWwgOz7ELku00qRqDh6dmX/zr5ccDGNskb qyum8gn+wSvPWg6pulPbUOf6S/3eF7yJ4yzv/bDg35URI0w2ZU266Z8/9NPr/huEx45wcs8crHtx X241K71126MrPU+uOIyc6Bw18I82trGh/05OlKVExMium1XF9JLExtw8Utc8UnThcd3/+GdbUNIa 1J7v5Ou8NPP1lrKH9MuPTosCRiExP2Z1i+LSEuI9O+nNvqYum1fszDCE/8zxQneWupeXWfeY7ko7 lnht2uyaIeavNngKOvLSXGK2tWRlmX61Z7JD/unuJQZ1tzKTG0P/lUAvFQT9QHeXLAzl0N5EDLuz J5D9WPFg1ZaLSa/qN6fV/9QzyffFROOff7FiLD+admdYwPmNn3fUz/jXdebNnImjfiwQfmTu8PXA P1qHcWXzxEvYsZWbMs59u+Lg5vT/u9Dj69LuoYRbQoQRPMfUe9/NPhEztMDfaEHnw4SX6Qqkou2q 2YbD3r9U75xJ/yxK+I99reHODxBQ2uCjTM27xq5Mbn7JD06dUjVpVlNZ87T9ebJCfo936GYej13+ IEzsteyP+d+VXipbIQ8Vn0Q6sxUFPht4CUeUwpvRG3fXXFweHyPpEbY+WzKzu3Ktl/fJg0NMD/qO vDp3d7jxac/M4IkJIu9lO390GzFq62fH5t5ofsl02PT9s4ofuOHBUx88cbdbdHqWXUt5wn9K5Ieu yuBU12ifuMYFjZ6mt/yHRTrvdvD3bEG8kqfxnR7ve5zB2C00nnzhzX5hZgWW5bYy7Oi5rvMBW9tT Ji1aUCe/+vRC+s+v1h/yrA09dSPteWTnjc+HBd0waEh6ViB2t9ly2jW368m+5WbNxv6LRoXMW+jg QfofQJmtp+JsGaO9/Wx0NNuZZ1p/1H+qcE7aJ9daIZi5IVNmH+8nEtlPn5bK3cAoGCNcnhL0r+Fb qqGwbbmBLYFLi/Mffr9qpbfDLb8o65RT7q/ujym6AaGCpLzc0PWB62437bbPE84/4u079JWw5Blr /nmLZRHOP6ezK3nJ1i2nzYyHdlXnH1+esvFpdfWEywnR8dtpBW/ckhQy2ZZcF4PYuuc97pKZwccm nPV03FUh2RU+bY6Doc8G7Pqu8X989/Dhd4s7y7YIby4rdxwf5VcwXFwr/P6g22c3q/668rx6RXal 0dxtvmtXyP8Zuk/xV8mOO5kTTNMn1Cw75fFi+soRO5ZxpzbMDv1RkToG2pL3cvGlvPmS+YtK96wy 985LPvSTaeDN44mBnPmcUbs2uByuDEx6sXGo599TdniKii3um40F5Y3msh54glnE5Z9Wxi2v8c2Y jc77vC4rXxlW/DDfN/H30duiOqtaI+CR93fb7ASQz/X2tKqWbUOqp+RmzPPl3EubNHxmrXfYH+cu 1wduq/bb+P1hUQpm9f8butQCS+ILRPI5ionIuD1Y4JnmvRw0kf5f8s4+qokr7+P3aY8raLe4tZbH qs2q29YjFtQwg5SWdOta3AJSRcQ3jFu70KotjyK1UmFWbY+1VtOWRUTFlFJBCCRVimx5G61VEdC0 ImL1qbHKW4gUHRIhw8zcJy9KbnTmyTlzcsgfOchJCP5x/5gf3/v9fX/3cz/g5mVsl5x+htjfXrki 3+Ivow7KMpV5Z+5sV7abC+gjzO5a2WcbJReYHbUlxGSN4uaEM0ZyUrJKUme42X9mHRtUR8KLTWR/ vlZy+VIuBKee+YA7/V0PN6X3zF2sA4KlZJg5Wabsvdlgzlayq5metmqO0CqC2lcQJlUvuafXDEH4 S2TOujHsc73svIzITzT6EGVXCrV8DvH3aghilV9WWfYwkzvZIEMvd+c35tmN3MyIn2l5Swd782T/ 6z3MW4p8I6nRDpzZfjsbNt853dexu+HMON3BsKDxyRkf3Cp/MYJ6SXszYwstm81tvb00d7L5maQ7 5CusxLIJ+usHL8z7glFI+3VfZSh+guCr6jGPMm9zUnOz04vQWArmAJjOmIVe/YzxE0wxMQTT2EHH kJJibV9JIwft86rZNvucn+LzBv/6EICp0z5FbGdX6mrcyg1UIMwDANMR3rdNqTBpIHhCyskbS9k1 EPxoPULVG0AsheDOZFkb09Aku+WblsRuCYqC4NtnBQvAMZc1CzXN/FhSTAyWtAVpIaVYb7FtfBU5 OnjZflfIKYnveIES4O/gisaSSl0MZs1wRwfJA1jSP3pfCVwnjiUxmrQWehOj2mL1uDUGub6DUg8f SCTq+0qJQmV9RYClNP6RCUHk00Rn3M71JPPaWJnxSCH38eIHfiVUIQiEdAb6N5gfQoqJgJCWL0Tq w9pilaYgkMVVq2waUfaRwBW3mINB6jS5KJpBKnUxUzXDHZOLHmCQ+nlhgZDHIri/+JVIqHcatnK/ SPo/D/+WOFsYOHLgLeLGK/QJCJ47sMsUsrsUgtere+gnjMlF1anJdFwH8VN2fnr0TRVxQRPGfVQj 2HNFEaRom4cfQYqJQZAuGiyOSOmodxLVSXmONs/XtjZPGSZwry2G8c9YieaPSl3MWLmjMjyAHx3m hdMn5xuuhgWtvSV0DhZzEEOlTn9W+YmhmAhiaDkyVfW/Udq5Jy43jnccUdp/79bazb5PCSzQUXpO 6xPdwnQxWjXDHaNVHgCGjvK+h7tXViKn8roIKlFXX601+DOH05RMTgWlkdKnIJj6TKHl7/67jGrZ gByC+sJ8CM5WQnBtT8VdEoKsmAgIMlMhqHkhuZuw/O+DCsv/NtgGp4RKBbmSE/0zy08VxURRRdFb QCJjrSZiOXJs6bKdP9I4wvev/Et0cEWdgjfRXFHpEFwEgnmAK+qFF4HczTzOfcHsvBLzKB1BBb3z kp9eUvdZ+Cf9k/2+Dvc52anYukEv2D5yYEKlIah75seEYqIwoehVaSmxlh3QHxwz5uds47eN3/jO FXjsebkimGhIqNTF9JM7rkrDPAAJ9cKr0np71CSlMSipNF3foQ5dAtEmb5G1msieSG2tRQ3qSTVx 1kBc27MsPDNjMlVyLP05JqJtyVo6ul9RX/sxBCeWpI+EYOtR2h+CYf8UKhAEDjrD6QnkN8+i4KBN yImkyFhbh1XqwINettNEGqt8/y6wRF6aCCYaDyp1NaEU4o4aGXr7PM4LJwSrgw5lsiFBy36gl8ia 1t/7cVJruv/974kr12dMWTxe+elTw5+/oVYVdwkWAjKchD5m/NxPTBT38yGlKHA45SKbU6466tPO vz4E+4nWqWjsp9TFZJJblMID2E8vVAqKK+JU7RAU/sIZ47NNMSZ5CBuu7fu6miwmis2k/i5RM2a8 zBQxmg1VZkX4sfN/hGBeUtv8kxAsXCdryjHHX5TdfaQ2D4Jvx5j82H8JXdKBIfDPmU41wm+5RcE/ +cRisNU62n5JR1WuzzWBFfJiQTDR8M9gV1gQd2iFB+CfXqgVxml+pg+DWAyCf2tePQ5B/FEImuTm 15HP1bu15xImKPdVhsmwf4b0921eFEsoNp6yvY1TNnKaXpUsh5V3LCKkNHlesDOF4D5nopE1P+4T E4X7/Akpk5RYS5HEIkPfo+2pdWWawK1oGEL7dCoTsW472FVq7ZYyGXq3/SdvtB0agjpGW7Th+R4I PgzQ1tZYzMZVgx+jJNlbmnDrEYmA5BIZlQFB39GyF+Np1cdcrrxtSW4AG/eDRVg0VMn5LK74N6Iw 3hxPaogVnHChIJd4BKOPJ787F0X95NGTUYPQkTft0JHGdUJtqVn82bZo7mewi2zbLXriAe6nF+qJ QQpB82adObinvrIRAsumi4sOo9RlMjb+HASZ8xhVgco8MnzihmZiYtKPgfs0rdP6P46ZGFu3kBpl 049tZmUzt0FilRXBHdcsgWybH/aJiYJ9OrsSS32M/uqN+wcmdhyxHZio+sjnN4EF8mfbolGfwa6y bXfYEg+gPr2xgaVUk1SZNcO2KklawPkMa9tKaxhuVZJOTShtsCiJrERiU5Kvsy9qzXFGrfEkRy2g cyCYWpvD7SWuvS6PlbXFN8ma/AbOyudCcHVC+mQI1qYaFewRwa4vQgKVomaZnwSKiSGB8unKaGQo ZPRo2xasscj3Nf41OmCgTufuRMNAg10k325RFg/AQL1QWZobIMgil0MQza0sXw9BW3KLrInY+8Jy 0rzMpDXq2kem5LPjwuVZ720g8pMaqNLzCuNac0ZcWbKkeWTiNVnxU+eqiYVTif1cxlRlOwTKTwvN ZMcNwW0YQvuc6VQu/LZeFO3zYZFB7t4cfe9Oj0ChQ+L8tE9MNO0z2FWU7g6V8QDt0xtVRqORU985 /Mr52hqivum+XXmRNllEJua+Xcm+qDEvsIjMGaI6NKhITh3SK/W7IfhgvXwB2RZpUZkJ3O02YwRb lv2z5O55+d+Iq6GCk1UICVSKbM1wfhIoLoYEyisyjtOsO3Lsp1ljfV/lXSI+nT9UF80CDXaFHXGL xgy9zfdCjVG0EOaEVqIgjMIiDCSjpizPvvnpfJOOi98k0e9mdiUQc2iiJ8/8qoEOaoIg3a/eX/5z hnKgM+ONihJO2vqUSXl689ZrZf3azxcOECSZG9vNcVxqTMXAgPBpDgdkNFgajD6ovIYfFwMZfaAz NuqdxMcG4/joRjsNa4/A8W98Om8cj4tmjAa7iuPdUDC4BxijXtgXozIKuaJ2wpaxZJpkphipPWNR FkFQvElpC1muQrCGaBsr00dQat3AMgimnLWiSrLeh+CKzvxaDD2fUf2SXRaUKDSphU/nj+NxfkAo LgoQ2uyYanzik3OfbSkZ3IbZWSHVk3z0AqtzlC+Ofiza7LtK4t0w0Yh7AA76tPeVxxm6iSvtgKBQ xt4qIUplXdcIOgWCa/XoL9Q3u/zoL9iVVYrDsq4I09bfw7+CoEhyaWTh+MAD/1O57odzEOwr0ZmL ra9CPTHcgQ0NRskFOD82FBeDDX1YREoGk/o37Ul95TGBDBKfwZvU46K5ocGuknp3iIgHwKHeGK4E lUiooi459b6u72h1g2E4U5yWzeRWWJzKTGujbOrBQxYf867Vx5BcCwRdEbEQREu+2GgREAjYuV2E Pp8KhMA6F1w0IYYNzpjTE3ktu0aI/4bPQKx9KPo5r7XHxbBHH9STMV/e32390QbYVZ32yRBYHC97 FBfNHsVchfXukBMPsEe9UE4OmfazsV0S6k1t39Gi9EQIFtLbmb1l7K1i+RKyOTwPguemWaskn2u2 VMmKjUyOrGfiBuIKyUaehyDzebY1UDEQbymSTTrqLQiqP/5ljPVrPwTYErI3zvoquAdDcKLBSLcJ 58eJ4qJwog/pyzfIbYSrD9sUpiHKdxb/CvlxorhonCg2BPE97gGcqBcqzPVKDfeXFZb6iBxn2X0d +E+gCoId/oeJC6ch6CsMHFkMwY05XRLjEZLVN5TTOdyhNgjOXoJgZndGAVG0iaBSycYqeZGya4Wc yU3uDVq/orXmrFATDEf4oujJEpyfL4qL4Ys+qC/GqCcHFWaXTWGqLgukk7gDLhrstDqxfh5zFd+7 Q2E8ABf1QoXZfkliSi4izu6XTeV/e5WzVEWdRXZyJD0T37U6+9b02VyUou/zYxCUk5RNhCIG6hJ2 WL/uq4r1VahYHDjQYOkM9HN+cy8KB/rQiLHPk1H3L//A7Jd/NL7pO1tggbxhPi6aBYoNQZiPe4AF 6oUxS4eVxVBusSStp5PaAg5YySYtFhOSOVb5b/V6kolMILioxIwFVRlZzIp4eqPZP/kCubMegnkQ TOqm4+9skut1rSuyIVjZcAGCW2PT5Ow2QdcyE3H4qDPgB4XiYkChD6jKY6ZpDlWJtqlK9SiBUXzc AQl1UhXRkFDMVXTvDlXxACTUC1Wl0KTh4l6O56IgmL6QK7ee3rXsuM4q20coL5HmhSa5WcqcSCXe sFSOZd9VoKjzjzf5mcPl9NvMFqePF34YePhuwvxbZUSd/Z9Qeo87QJ7OqsIP8sTFgDyd7YqNEDRq 8CD8vn32g/D1vwvcMYJLedN7XDTLE3OV3rvDrgw5ytMr7coJOos7nNpDL7Z49dkj/r+fjGtlbcFE QRmrT8Ml1D5Z0xLOWDPOzxwt0ZdAkLbik5o/pU0SrBGHD5iB7mz4IXK4GIjcQ4LymUNQztltSqXP Df7l8UPkcNEQOcxVTu8WQRl6P++VjbAGLi5BzoYxn2a3BJnjUgljDzVVvpxsi2uGoImsq0zuTma2 BbDYBt0VnfkP8fRqPWlxJ49pjM2XM9bfkoW+LzlQRtbb/wmLSKhAgfD7eBGUuYdhKo/9OHgtIRZv cyY/LvT1F6gQ/mBeNGMOcxXMu6NCPMCY80KWyvBmjWmZwZ+dlmyRgVfock6V/iYEh3ZB0DNXsohs Ti6R27pdqXslDUUQRCUN/JSQOJzqIprGckb/JVuYSqXxNFEzTKg0ULzcTPRzftcuAi/3oHa8MpjI x9oT+SrKp0NgcY66RY2SaLQcNhSJvAfQcl6oHFq6F4KAx0u5XOZEErsJgqztiyx+nFtZxlVbfMlJ FVFITE8IuvsdF5nL7dPV+UeypbIvO4iCCmqYxaKviWn9XqcvZba8X9Oy5tf3ay4lM78kQnBuj+VV sB2M0OZQWC/OT5vDRdDmeJhcrwxShi4usKEkyup8yvnXh/FH86Jxc5iraN4d5eIB3pwXyshFCHat Jc1YUttS5Z3SbAieK2FUsRx2FILWZmXW20ZN23cQRJO87wQLwgGpC57uVBD85lwEpO4h4zFoO7ZE WbVDdcBns8DaHMWKzmKK5tPhQxG/e4BP55XhiM68iF3Zr6zLM1VwceTi8OepKenvWjQk+ZLfDman fGApMVrJ7dXWlUNQXngnFAL9Z+jHVbH13TEB5S+V9JiPnodg/zTLq2CNIMfl0U0MP50OF0WnezBv X12E5O2J9/L2Gl8Z/wpx/rxdNJwOH4q83QNwOi9sYOlrK4hiNbeDURXQv3LFVfTzlHq/YSNd3NOp rC+6cTv8v2JPXd/8SOHO4/3DOg0/t+QLjjUiqLpQ9CnjR9XholB1cU6oXucisB+Fr6ry6RQoAn4L LhpVh7vK0t3A6sU9gKob64VNqhymzGInfmXq9yRR50s55cbeqUuUDS9W0Om6xsqe7k3c12HsywY1 16Lsmkw2XXN8VFDWWXWdmKQvoQP7JXWVa8J31g6npjXvK4sXKhMEWIcyI3B+YB0uCljnFKKPtt1o O9Jx7CrHfia+UeEbIbBEXmAdLhpYhw9FjO4BYJ0XxujGoBIIIl5I879E5O+pGWmQ/dywPCV8380c Y8t4bUElBAMggWD/FUhyx4WuO8cRUt0stAL4SXW4KFKdk6eIfsHoSMfPRdnT8S0+3fzLC+FPx0WD 6vChSMc9AKrzQltRZVJxcelr6DjuVTW72uIm5Eu5LOJzFbmUbIu/RB6St07RXbnZaZLoy6jJxBpF /kWiQFu3i1WHK+Zz+2WTuhUBx15SX6bKIGhvkHFrba9CZYLC6lBbwQ+rw0XB6lDodcoq222zI5Fz 7VL7ufbGx4QGrhBcHdodEI2rw10l46HuqJWht+BeSL027i5l8iB41Bz/TWpym1+/pL5msoqYQhzn 4o53EMW7uJzlj2+kD+v0Wfd+TNjOPAtBCcE+w/dOcNodhdWhtoMfVoeLgtU9YDvykr5x2I4Cu+3I FTpz6EDVOdkO0ag63FU27g7b4QFUnRfaDr84COJe7KNTfkrT0EUtZNPBbc1E87wa7oDpArGGND2t M/ZlzOF/2xy2ffOIrtyTtcNS5/2me6Rs0epzwiUSKlAi/M5cFKYOaU9NtpTI44Nn1s/Zz6xXan1a BQrEUcDooVzRiDrcRTQ+0w03EOIeQNQ96YUack3DpJKYvkbeb8hY05RG3rnEtIw1bftU1rT0P9qS 8fO5fc2n01feUBgvqRu4PPLLW2TXOHOg7a1QMSBEuulOxcDvv0UR6R7QC6QYptknqZp9fhdYHf8J ddE4OtxVHu4OtfAAjs4L1eI83QLB1IwiVtY+MswgZ4roQiMEe6f1lBJUYZeyiVtZqetO4b7RcQeJ Pyck3/0eggXJEMTIPg+sGFgOQVEIBIXKOv/Fv/udSN19nbG9SSxp3ic4VIVi6NBS4cfQ4aIwdE6t qtm2VlWKw39E2sdHZvvc5F8hAqFzWqBor+4qD3dHp8oDEDov7FSZniliigwX0wqpQs38LmX9we9v 9dwM4hS9Y7RJxFjCSOxVfxjW3wBBPnNqLXH1j/e/BaNwB2VOGoo2hvgpc7goytwDwqEetBnvfWWz GaoUn20Cq3PUKiocoglzIa7CcHcIhwcIc14oHPmmFi5uLHlhhKJFbl6YCMHcqbIEom3+fvbPlcru ddyhVrswxLJq2cVqpbHX/EgXUX6Gzs60KcmqKvWRX1sW/254OanEJFgcyIA68vyF8MPkQkTB5Jya VY/amlVSR6rxfZ4t1Wg46vsy7xJD+GFyuGiYXIirENwdvSoPwOS8sVfF5THf64YTNWP07GxzSu3j VtxvE72d6tg8gTMuksRy8xW3idbF6THm12QnIPjiHyZZ239DMJybkweBL9m5ndtd6tcfDcHfZMbU t4kfkumJFmFRCVYLYshnoY8oryEPEYWRe0BKCpCo/L17UflOgQOCIfwYuRDRGLmQIYjKQzyAkfNK F2Kdyl2u64TgzKfCPxhk5Tp6f6Z1djdVeaWHjT5rG92t1HZv5AqsekNMT1jVv/G4+ggTdj1+MTfh dsDe5T+0C2WGIQhXToqhn/8feWca1dTV9fHz1AlLW2ytA3WIr7NQRIh4g1riUESLShUBBSFaVLSi 1IGCWrhVa22rEBQVqUMEVESQiAjImMeqIGBlkDBWUcMceTAhAZLc3PMEsORS7115131Y8iEfWAkn sNb5cHf2/p//3r9DqtoRWly51f/MLo4Tei5a2BnXDc1KpSA1IAS0nDVxma5wR3R45n1xioX0A1pO H0+x4ni1ZZjLlU0QzBS8zDSdpvCFYMQJYeBp9hOf2nXjXBod1XNwp78XXFG5IQQCdvg2CErMcQzf HA3B1wJVqyKMMjoIl6QTHHWEnCiH0CLK/SOfXCfckr6z+5b09HsGYvL9kRPlENpEOUSXpd4X+aQf iHJ6mE/+xMurpbdTlLYaXeLto3B1U09MRJMR7IYZfsLdoS0FX3wOv8h+tkijSATSsdUyCS7VCJUb EITUabIItz0kfcjrloPuhztzyd3OXDI11SqXqkcRIeLkiDKFHCeH0MLJvZ1GCI76nm5HPc2TghSP aJlyxBMthDZTDtHhqPdJHukHppw+5hFHzPdYkYOk1NyWnbM2UVkvnRaHp2K/itnx6MT9qRCMZrfU 7sFnodV59dgGTQqhzBdaQlyvVl2EnBCH0CLEvZUvtJ75zjee+Q6KqUDEktQzR2jz4ZB34Jkj/cCH 08N8Ea1ORoWtr1FV0RoIkguUWYFGGrFuwmurgMClQKPNW2x9INhuJDefpLYQhJhB0LwRv1KDXkWk gwTqOHZJBleWjS9Id3z6fXRas4Pvw3jb3aaUcULQ6UTVQU6HQ2jR4YoJ84ALOucBSwY+7JkrR7rn yvNTKYDviBYQ1ytd0AbEIbrMc4s+iJR+AMSN0MN0MZ8n9zRVmmHxHkdD8bjNqK3gdH6hFBUe5zek SFNHQHC/Qv2pCwTDvWSrONgKXtF6MVpr4YWFe6mqwuZWK5avg2DqOryt9nEK7jgSzT2DZqZSuSMI gQ3Xq7IiZ8MhtNhw/0gp72ltdbNuW/2KwSuK3ZHa6ghtMBzyDmx1pB/AcHqYUNhtFco1aG6swITs Xbo6TlDyF68RkZoKKvPVK3LxUHSidnHm44LIlgbew/R5NscEkejEV6+UM/FfsWPB63eLKKsvS3Jb HSGnwyG06HBvZ5Uve6bM/+qeMk+rpgDAIwQ+HPEsizYfDtHhqvdJUukHPpw+JhVGx5PH+Gm0xbQQ FTnMUzpBkMFfCEHQ/JZGF1waL5Q5VWb9lu5StNYMXwmB0jVFXRM3EoJpqNrMDZc6G6KhAvyMRr7v oyy6CDw4C2LRRc6DQ2jx4IoIVqL9ni8maVS69vZpwzeXtP9kUE2xQ3KNTpsHx9Lltc/ui/h49xp9 tP7FR4NGlIySCCHITSqCwNtcFAtB6PYovJyTo6m0phYFXkZjNILFIVEaqV4KwWoGzvOqtVWewC+z 1TYFeUn7+VImHs5RFbpmuiiMIVjOVzeYecRixyG46oLLKP0RAiCOSaxwyAFxCC1AXClhBp1prynA 4gie4sbuGfRHxhQ3USNaRlzvoKGr6Vk67PfOm+v/96B595p+pB4mFTcIhJonPKzWtEgj3p2ZOOcU 31agXlugCFwd56ke9vfPYS4esxmCyynqVxNEEFxfhzZqBP4BAxYETWc4Snv02R+UAUIAxPUKEHIp TwMQ10ufTJhjVcpctfSNjr89a3WXjo8davAjRXSQgt4R2nw41rtw3PuBD6eHAqUlrUx5p6WBW+/e 7gqByzj1x5g4S8xpEgki2Rf2cJwhqLUtgSACE/+uTIHAZGa02qh+fZlQoFjly25A54qrZN74QfcD gUG8QlO+T1GicpD3jdO3qLp+EQIvrldzCjkvDqHFi3srlVwm2Ikbu732R6sorp5GtNC4XqmENjSO pctr74tU0g/QOL1MJajw84JG1PLtNwmcIoXpCDXjZOebKRxJGHoFzflDI2CM/ZQu2A89K5RxoZXt s4jf0eRsOIQGG87qdqFWthev1Yj2pQWLemT7H192yfaMlRSThogVuWynDYdj6XDZmX0h2/sBDsfQ Q8qPjUDznIepOXlpDnwIsjVFlIs0PlQMgSQcFWLXU4QC+US+7FZsgKYUW20Cgb3J30vJNvEQxOz9 wV3hnCOsls/kHhOYlCvT8StFEr9a1zUQMC6o32eL8r/iiVoFEXbYvm2OWKCfbDoEXKr7ERACVc6q 16NKLvFpUeXeSjEDey4SuT3LqdtWUVFcPI0Q0HK99kdb4ety4fsiw/QDWk4fM8wojfAYCcFSfEHm II3uOCIoZoeYL0SVET4ybo1BfcfJYPTX6ZqXo3YSY84TRsuOxVEdx/mN3PbkiCJsiYssR1VFBQdC CCi5WcQHjxwlh9BByb1JMcPulf+xqGBRV45Zqs0xy7tyzL1LQ0eSb1BLkusdGLRVvA5nvk9SzLsX 8f/Sv7hokzeLq6guTkcIcLheDhw5HA6hA4ezXKOV37M6FYW24WRjfHf37pdUXVdzyOU3bTYcS4eN zuwL+d0PbLhJ+vdc/6cTkDgCs6s1TFM+xa+5SBinZorFfsoIzv3ArzPqr6N5twoUs0adlzsonDsN 8/daL8ZoVHg+u+bf7s8YRdFqi9j0e8rZEFy18vNHl/Bk2dd5VUb4qgA7kYOq3ImdzMAildxsXvvN 66g3W2ErZwSxWzaisDBJwZMthmC8s4CJ/4KK8srq0CIjbB+lA08Ay7GIvgk5WA6hBZZ7q6gy6PHg zbpH2x+xhi6l2J/2BI54rECbKsfS5cH3RU3VD1Q5PaypWtAXtrxi9qP06o5VXjJu68x2/NN16knY Q1FIsLWBKCTWCfOFYCRu68oX8TtSpCZCdBz6QHCCOha0iDnirC5CjphD6CDmigkWouGeQZ6OiyeY 9pRR3Q77rRYKjjtCYMwRY4E2Y46lw2HvCwOxHxBzA/WwjCp4JSjFNzfzKtAbWH4V+xYEbtSDH1pG HLMTR6tdJxfSdBhxloQLC4oX3C3/dPKpN2WVwaddKjqtxaCSYnekM+kIbTqctQ6fnNkHJEWkH+hw k/XwMZ/PFr3Cz4UlvICA4SX7K5Nr1KFiX62tg6Bqsdo1WskLMUfwSkaTkF2CHdwnaCuEwDkGj64x cB+usEIHKL5Omyb9Fh8ijdjrUCPEjGpdBMmjsKi5XFksBPupf+HAwrsQXEYlDw5rJDwEomND8BMQ 5FAa6wS8XK+qihwvh9DCy5USGChdVdW1HuWyrdtWT1dT0LMQcrwcQhsvZ63LVmf2RYy9e0U+Sg+V SwW2Cz+BxaZ7SXKUdtL4Zl4Oo5GRF8SR1H4mEOVZoTmnPkDlCzThIFC/eDgagqaDECxDVfdCLCAQ DsBPQtB+lPIMlwCVsyC6cORQOYQOVM5SSAgMw2Fl5SVf95xUFS/tdkO+o8C9IwSsHDEwaGPlrHU4 6rP7IjD6AStnqodooHo0NgiCr9inzD38lHeqZVGKRdo10xbltOd8QQPvUBYEkYGGBWiyg6SD0Sh4 lNGu2qRJVwfxc1i+djUhUJNYpvPVbEWpuRCtHQFBNARzHyj5WKRABkG9JuUUK9shMPE4hp+RX5G3 4GsyR6nNxPbiaixmv7nSrRRt82mvx3Z5QbAFgkA0Z+SbBUp5o2XYWfU6JiZn2CG0GHZvJaVLhG6v bW8s+iIKhDzCIrfoaXPsrHVZ9H0Sfe9e7OtjWmrAmXUufnYSnmV6Gvu44hQEFUayUAg2sYsd1CGa FGSHzw5vxY70fqEOBoLWJ8oMckodQodSZ/mEKPYdu/qFB2jRQ1d+7b5QYR2VnUjA1FkQl+nKfWsd zvzsvtD7/YCp+1z/oqGJnYxKzlYXsx+ncZt52BZExm2Nj1JpcoFxkHoSJk5tQJsQBwhOCtGM+PoI CK49ZeP2Trg0/eJRPGovBAozF1XefbyCJz2V25EijXNoDodgxnLeMdREu8qfnn4clR0NtK0dtYuL h7Q8zIj8j6bIKx6nGAULvQvkXmPwZYz2UxW8pscIdpLdMiORLTzvo5iMPnMepV5QXa/KN8Qv+bSq a49A8DWiwKVUwaiF5Fl1fiVr18kPJOhA8iw6j6AXd43WM+07A9LTvqd13757vD7OxiCEYn/aIwli VUgbk2etw9hHiOP1LNqh+K7PJD4BS/QwFAcHLql86rgl7+CcWX4K/xElH2BBSWlX/zz9nveGFulr 02vGijHbfVecMxlYfre69rnTzzX7X/DHjja5t/uL78qCPxixMXX8ne05g99P3O5Revw3bubvh5+/ uK8wnZPUvPXhNVXFNZuPxjqc7P3hTPOIgO9iY+RxweHyxHHl4Z3UsJF3fnve+JHo4uPn/+PH5rCw eY8kx9bTYWnKq83F2ZZXH54VeQ9Dw79P7RBFJkRfdmuzbPQ0dty0fFeyAftR+npsV9HaJ8VmKuO9 Ccdjbk1lVQ1k1Hm4CVuzEhzDtzalphp/vm+CTc7ZDrsBzzNSYusDvom2LBLu2W25VroggGvxOnjI 3X0+Lo+VD1ZujrpeV7MpoeZH1XjPF2ONDv1syrQ/lnB3iPeFDR+31kz/JnH2nfSxw77PLf0Xw2ZR 7w/NAnnyeWI7l4iyjcnnv1p+eFPSTxdVno4SVzW7ya80mL84/t4O1qnwwbnbh37Rlh39MkmJlrTc GOdx1P3nyl0zLD88WfrJgeYghwcoLKrlqOOzbrmUxTa+FPjGTy4fP6ehuHHqD1nyPIHKPWATn+/y 5EGgeP2ym/N3FF0pXq4IEJ9G29KUuRwPfvRv6tI7oRv8q6LsL4dLVaXNT+1mdJStXu9++vBA48Oe H92Y6x9kdNYtxXdstMh92a7vnT8YtuXD43NvN76cbbNx59OS3bwg3ykPKtbOWnh2zqymJ9G/FCqO 3JCz451COZH1X9S7GWdsHxLi4G+z3a0JXR87VWD7+MDjZKZ/qdGEi69/KE0pwVOdVwQeO99+wXuL JG78wi+eK278dTHpUN26I27VAWG3E56FtN3+eMie2wNqrz/NFa+dufmsU2Z7xQH7cY1G2xcO85u3 wMaV8h9gsbmb8lwxUyI5Fxrq4sA3rjm2fUqpdcKgW82APdsjRY5c9hKJkGlT43kezNyRpfZxe74x 3FwJArdm+jT5LC3Iyd65coW7TYbXSbO4sLV190fm3waY8HpWZsA6nzX/bvBHskrn/+buObiutPCp 1fwLk5YFOxxKcinjx5o1nR1nNLi9MueEfdyGvyorx1yNDr28zSL3tfN1pVy+OdNxQMTzZ6q10hm+ x8ecc1u8t0S6N2iqtY0BxwNP3PvZzR3Z2TuWtBVvLr2z7Mniz0565RqKq0t3Hnb+8E75n9eeVS5P Kxs6d6vn6uWK/ws4oPyz8Nu7KWOMk8ZULQtzfTFtxQffLuNNqWUFfK+MHwk2Z71cciVrvnT+wqJ9 KxnuWbFHfjT2uXMixoc7nztsr4fj0TKf6y82DHb7z+Rv3UQFk+6PGwWf1DPkKvaYccFXf1wRaV/l mczC5n38PDVHHViQneMZc2n41pNt5c3B7I/u+8/cBQEnUZJQ3rR1YOXkzOR5ntx7CeMNZ1S7B948 f7XGZ2ul14adR0VxuOn/b+lKE1t6OVeksFaORUfvw31+b9zPxWIs/fGVgUcZ2ePRc3VpHlEaebn8 IjuUF5EjOcqrU1xVJmDBWezjfoxi7NesOHQSnysalyMTTPSJZTwUizpydqnNHwpgyRNBR1QBo7z0 AgQPxvvj2bdb8OmtOW1W9RC4CuYpfNi8VlG+Ioyn/hZrqc3A0QKueZ0HKo9tFZxpVUBgM18QvmuE emqremWg/S/8RoTXtEe63hZdlgGBI+9kuqaImdSgNhe34pIX2BQ/3NKuSMkpq1eL7nV81YJt4kbJ BPwCVc7R12FQKMlurw/OzxlTfXGe+VifQP9XSXPtpPMLRIEHlezF+KHXrhcmKcZ7SQQL1AxNFbTQ 32zlCYzL7Ki+FMgthOBSxogB2FacqRD2eqHsR9HySi1YxJueWeTAUhYdYKnj35Jh+PABnWBrJqFO YXbVKZGNBqtJ98fSwkp7NaTQhpVa6+qz6gsMUD/ASt/XvzIlRc6H4BMmznl0Q70dgvudg1Otpqgr BJJJ7Fos/wn71dD9XuqD5sshuDmFMgC0DVmsOcQHj/T4lkUHQVqmPUEa7mk/oaz80aIC7RR68fqu A9wHrkOnUYQAKdqERRtCaq2jJ8uiD46QWP0AIf1Q/0LgOZrshfH3lyn3YbEHO0VuppjTWC+NH6La gua130CjeXkppprQ2BgKgf1naIPTsd0CbIkxW5YQjR9Z+4+PKCKERUCOWiDEddJDVhYN5GjSGkJ8 dB4qMfd8YajNEYZdOSJRYHCXYoOkyFEWbeSotY6GKos+aFpk9QNy1EgPA0SQbIdPNopjSLflH8Ir GB0hNjfR3OiZhqpN6MsFyrsQTD0fJEeCb0DwVUaL8hOZT0yGr4/SqR4tDIsKWCGKRYv58/CfMqkO XVlE4ijhnIdFThxl0SGOOvcEh6P9hG3eW+IJI4LbYrr8h8TvDP4g3x85cZRFmzhqraPBqi9Cox+A o4P0sPPkcX7VPHPvV1TzrywtI5TZ63uVnBHKosEITdK2VN0vX91J53k0dunUepPXTV51nxmPnn6n pvU9cN95qBHFBkmHk1h0EaGWs3S0VVn0QVsVqx8QocP07+FuZcdxpBFNqHRLdV5GgXgUdm0/DwtP kfKZygcQmIyP1nzx78Bi3VQcCPKioyDITYPg2ZmUNgEEpx3sIAj1hSDTzKcZ1fz1Ra7mr8VdTVNU oUK4e5NYIpFzRFm0OKKEWz+GOxp2qoj/kne2UU1d6R7ft72OWLyls6xaWx2qzq1dorwkWHJESafW obe+oAIGVIxTrTiVXqYqeqWF09blcnxFSxHR2gxaQSAkt1KlgnC0WsuboAJSdTSOEjUgjR4TJYdz 9r55QXMi+9ysdVYW+ZAFrpzEL/tDHv77//z389uLnANLNSfn2F1EffugyfglOlGi/OhNJhYlKgl1 cz7KE7d+yLyAEvXBWz8eZZ+Eu9itV2KeZ6LpkL9OCTAE1myL+nv32IADUX6n72Z9ucYg1D+SOcmg 0gi+fcaTQWWiyKDn+f7Z37YF+t2TaYvtg7c5pi0yBXA7MicY1EUkxIJBJaFujj954mY0mRfAoD54 M9pDo4aitZ0qOl33+NAdXRKpV7bJ282UcUZTtVUO6igNWdtJXt+9MCo7cyytPpbxBhutT0xhZnVn 1VVvROBUYoY/Al8eYYYjMOBDoQrhAUHD+FtwPBBUJgoI2uwcR7Jqg73HKn098qk2JNi1oSFH4FiG zEkFddEGsVRQSai7Q0oRnqiR/jfQr/ngEcETIYeyuYiQhT8xifLmVb1vx7RnDH/yb/SSVZlvJoxU bRk2cNxNTUlxh2Ah8M4n8b9meNynTBTus69UFDzxysuW9N7OsU0AZyjD4z5lYnGfklA3p5M8IhVe wH36oFTQsAiW3Eag8DI0KXLNMWZlBBfV9PjACaqYLLZQhkdk1dCRcnP0EI5Q5UQHcHPPIDA7WT/3 NAJxn8ib8yyKFvmj56rzEfjfoeYA7nOhizlkPOinxKVI8KZbFPQTpxZPuq1jn3ecHKo86HdDYIVY 6KdMLPRTEuoOCeIJsfAC9NMHxcI0IcD8aQg3CYGvte+cREBxBIFmpeV93ueaHU3nkkap9lZEyid9 GNH9+LP5sWTWup/tj/GqBqh9WCLP45R35pNShmoU7E3xMJ8SfmqNx3zKRGE+z/PKZKntkF3s1CHO MnEE1xWf+/2KXyEe8ykTi/mUhLoLrj1SJv3vt3/vi75DS9LHGKs2jDMi8GlQU3WV1W1c7QxgVRR3 TxtlG5IISlXL6UwEHh8pm6xgSjbC/Up94v4gLv4nq7BoaXVjDiz+F1mosCgoLbkYChcK7+aOcP7X E+/PReE+MXrivDFw2RIHc6Rh3aBpApXizLf5iicW+SkJdXd1hycqxQvITx8UlE4pAq2f6SzhxrqK BgSsuy44K5LWlMk5xTkEsmezJQUlFv+o0WtaydHJZ4L3atsndG+MGR1bE0e/ZBeQDRZVK1wTaNMV wS1XuEC+jed8ykRxPl19ibVAhvxjTu/UxK4vNtqnJiq3+N0SWCA+3xaL+ZSEusu3PeFLvID59MUW lkpD0WW2HNsmJelBjZm2xlVT50CblNzVEkynVUrk6kC7lBzIbWmyxJuaTKchPY/JQ2B8dR7cQ15/ Xxkr1yua5c0BPbXK9xC4OipjLAIpaaYs7nvBxi+PAirlt7XwFFCZGAooTliGOA+GjH1+hn0P1qAV IO3InCDQSfxNolgQqCTUTfjtEWXxAgjUB5WltR6BHGoRArPgkqOrENCntsmbyT0TF1GWheYmk+62 /+qD3GtRypz/XkMeTK6nSxuzTCmWzPiy1MBW/+XX5cXDzp0g48aT+2DmeNVtBFRbCi3UnZuC+zAe 6VPiUi54Xy+K9NlXZJwXbo6d1nuZh5/fJYEV4n29WNSnJMxdmu4JlfEC6tMXVUarVdI/OA1LY3UV Wdf8xK9MZsxWkYl54ldyW7SWeVaR+YU8QYQUKelDBpVhBwL/s0o5j9LPsKrMKHhfb4rmynIvBD5q VL5LXiUET1fxMKBS/tYMjwGVicGAYkXm6Ujrrvx8x0jrxEGR+CW+hc/VxYJAJWHuuCMe0Zj+9/k+ qDFZbaQlqZ0siKQnRXdSrIa2fvctrx4066BifaBhB7s9iZzOkMZ8yzudTEgzAhkBdcOVFzJVPXcz 55SrobR9mFl19rMvr5d1N+2M6yEpan9sF4QwLaa8p0dwokPmJIyGS/mOH08YlYkhjD7TGrPFLIOd ifx2eyJf/7dBhEDF4BN5sYxRSZi7RN4TFeMFxqgPdsbozEJYdJu0pyzZZrk5RupIWVRFCBSvV9lj lqsIrCT1I+SGaFqj61mIwJu1NlxJzloErugsf45h5rIll3PLQpYLntZ6SyCRxwNCZaIAoa3Ok40t 80792vBKzfu90HVJ+Hw7Lq6S9bspsD4sIFQmFhAqCXMXx3viXKMXAKGv+l6B/MI0w9I7CBTKuXtq slTecZ1kViNwvY7/H5pbHQHMLm5JZdZheUe0+cvfov6BQFHgJf/CkcHf/K3ik5/OIbBXrbMU214F 22JOdGg4n2Agw6NDZWLQoRgdUT+N61c44vqKnX5t+AVG4ON6sexQSZi7uN4TOuIFeKgvJiwh6kC6 qENJr9U9PnKivnMgW5yey+4vt7oVia1ZNv7bQ1Yv87HNy1CwDYGO6FgEZgXuWmfVEAS49zpIw0E6 GAHb8eCiUTFceOZ044zruVVCEDhZBM/eu3wZ8fZeDH+0j6QkPD38ez7OfsCrpEHgVjUZD0DKt1Fi AaSSMHeZvScUxQsAUh9UlEPmfVxsRyD9QdPjI0UZyxGIYzaxe8q4e8XKRKo1Kh+BNybY6uQgbLXW yeJ1bJ7cOHoNeYXiZjQikD2Oaw/O6lFYy2S9jl6GwImNl4fafvYhMCmRehhvexXciPGYouH8nhOe KSoTxRTtKzHfOflty1YU2EWmfp7QsXkZ3t6LxYpKwvojxvcCVtQHReZGhRb+cbG1QGa8Zt2BffNj cAkCm4cfJi+eReBxYbB/MQI3p3cEmr6nOEP9USYPHtIjUHsJAUlXZgFZtJ6k06iGSmWRqmOxkt2f +jBk1eL2qlrBXhiPM+oyY4LnjMrEcEb7SMx7zjn1mvOOOfXK60IxpQzv68WCRiVh7nJ8T4iMF0Cj Pigymy4FmlOLyNp98vH4x6vQWhc1VuXJCzSO/tjm8NszpsGZWY93HkPgKEXbdSi6pyZps+3nibDY XoXKxYkGDZfy/3Lj0aAyUWjQvqeN/Z7erSb5YY7d5jesGDRdYIVYNKhMLBpUEtYfsb4X0KA+GLjc sZEZjlqNSfvZZH3QNzbOSZvVimSPUH2tWUWxM5JIOHN55rzKzBx2sYJZZxmeepHaWofAbATGdDGK B+uVBl374lwEltRfRODeiHQlt0HQu8h4Rp9HdpfhuaEyMdzQPsIyx3mfZ815xyUhJ4YJEKxlBN7o i6WGSsLcxfieEBYvUEN9UFgKzVoYP1UBZyIQGgeP2oZ5rduuWtXtF1SXKEucWWmRsqfSyDnW2rFu vgqyaoYrzAGWKCWzgv3C5eO4T4MPP0qae6+MrHH8Cib5TrKnq7DgyZ4yMWRPV9NiJwa95JyLH+GY i6+rGRQisEJ8ki+W7SmRuEvyPeFZ+h3t6ZOe5RSTAw+nGZkEq2Of9sL/986UIteHkwVlnCH9rUB6 r7w5EZqqXguwzAo0qBFIX/z3qt+njxGsEacVCOP9ySbwUDlCDFQOIynOafgaxzR85dd+V7ELJHhY ORdJEWvrJe5Se49ISv/bep9siNXD+CQlF8luyW0LscSnkSYjPV65iNLHtyLQTNVUpHalshuCuElr dFd0lt8pmI8MlNWiDNaaWn/NXHVPTqwN/KaMqnP8CssIIVAiWDtPiODO9aWrDD4z+4k7kcyzu5Mz wYNeEqgQ7LUhhFjqnETiLqX3QIUQXqDO+SBcZWCr1rywczg3IdUqBG8zR2FJxgcIHNqOgPG9wPlU a6paaW96pe0JrC9CYGZyz/mk5QPpDrJ5BDQNT/yCrVCZzpJVAwRKg+AD5yT8z7HWnRABnOujHoPP PI3nJb3xfIPAACTBw81F8D8W69sl/RDPE17AzfmgdjQxDxEIerEU7mdPJXPrEcjZNN/qyuGSMnjC 6k1Ol5CFZGhSyKMf4Iz9cK+uZvgMrlT+1R2yoJweYDXqK2Paj+sMpewXa6vaVl5bW3Uplb28HIFz u62vQn1hgkeg4wN8CTyBjhBBoMNgut52brXetW+1yg74afDrwxPoCLEEOonEXUzviXLxAoLOB4Wk BYHtKZRlUrJ+gepBaS4Cb6jZklg46QgC7a2qnBUmrf4HBGZR2CfBgnBy68JDXQoCa9AJEdy6vuaD Vw+9WfwBv0yB5WGzeEI0tU7SD1k84QVqnU/GJDrLfG5Jt6om31wO46mEqHH0mxkfW2Uk9VLAZnar smcBOUQF9zTVHEXgaOEDAgHDNv7HlbF1XTFBR6eojZYjjQjsm2B9FSwT3gg9r+1L4Jl1hChmXZ/w /aMiXvi+rDd8Py3A7iLwzDpCNLNO0g/hO+EFZp0PNrIM1eVksQZuZksKmGuwuJIZR2v2da5jio13 VXVFN+9H/Vvszzc+e65w68nuAXc7L7QdFDrnSPAIdkQo/8uHN+KiCHbxLgjfwX+c9fJXvafltzUM tZ2Wrzzl1yFQA84y5cuFaH6dxF2q7gGCL+EFft0IH+xU5bFlVkdxja3bnUw3lkLVuofjE1X1k8uZ DF1DhbFrPTwQyU3t1MA2VcdYqvm686OCsruVN8gxBjUT3B1YU7Eyamv1QHpC694yhVCV8Ch2fI4E gafYEaIodi5x+mrbJFasv3MSa5djTL4hZ9B/CSwRS7EjRFPsJP2QpxNeoNj5YJ5uClEjED0xffgl 8uDuKv9O+YX6Rauj9t7KM7WNbCqoQKAHJJHc58EUPCl0ATrBw9fJ+BWAx9cRovB1z9iKlnd4MXlN b0y+yc+IXyAeX0eIxtdJ+iEmJ7yAr/NBY1FpLoHxGSuZePiOhvvI6ieUC2AOubOEWkDpFZeoQ8r2 N3VXbt01BxrK6LHkyqyDLWRBU812ThOVNRfuk4/pygo6NkXzK12GwO16OUyxvwoVCh9hxzcWeIQd IQphx4dhL5XarsCM9ecNuy91DLvX3x40RWCNzoic3yIQDbGTuovICU/USv+bcB+kYZt2lLL5CDxv UXyXlqoP6A6sqxpbQr5JnoTxJ++Qxdth3qIX1zGHdYac3rdJm9j/REBNcn/APQkdfif4CDu+78Aj 7AhRCDtX35HyUX7yd0/dd8phBw51ncAYIhGOzcgJ0QQ7qbuM3BPOwwsEOx90HgHxCMRPfsysPp+u ZYraqOZvN7SSrbOr4Dfmi+RKyvyqzvQ4czr+sTVy02cvdOw/XT0gbfa/dM+Vzf/onHCNEAI1gvfm ouh1vA5VrK1GXnw6yb7NMcleUeR3TaBC8N5cNLlO6iYjl3jgckLCC+S6l31QRa5r2TRqkqFK2d2Z ubI5nXpwiW0bYd6wRd684Mcm9ci5cG/r2YwlN7NMlzT1MJ/66h7V8Zol2P4oVA08UF2oSzXgPbgo UN2zisGvBkenSut3R2B5+FxcNKZO6i4X94ReeAFT54N60ci0ITA+s4iT3/aP7FSyRUyhCYE9E4yl JF3YoWqGSyp0Xavhdzr4Lfl6Uuqj4wjMS0UgRr4zuLxnEQJFEQgUqmqGJ/wWcCptxw3W/rBc3bpX 6HgVwcfT8WsFj6cjROHpXPpVQ+z9qtVOCzLEwdsa5fdP/Ap5cDqXBYq161J3ubgn2lVegNP5YLvK /IcitqizJb2QLtTO7VDVfXv8nvFWCMx6OLQpmRxBmsg9mk8ju+sROMj+nEJe/Y8n/wQjcSd9Tkrw /zbj6XOEKPrcs8qhcTqNYrvTKFnvt1FgefhIXDR6TuouEveEcngBPeeDynHQ3AbjR1AXX8hqU1ri liPw3nh5Eqmfu497vULV9Qk81O5QhlhOI285oTI9tDzXQR79hcnNtkvJ0krN99faEn7rnJqsNgtW B++0Ou8OKwJPmSNEUeZcGlZL7Q0rqTPb+D7Pnm3U/zhIjl8injJHiKbMSd0l4Z7oV3mBMueL/SqY zx7XDSSrhhq4aZbV1S/aOMDNzCb6zmejoGl+YCycm3WfbE/IiLH8WX4KgV1/Mcv1ryAwEE7PR2AQ dXcT3FEa0D0LgXflprQV5E+pzGirspQIVgvPk/MP9OH5coQovtyzWlLAOzWS4uDJV+4SGBck8Hw5 QjRfTtofibkX+HI+6UNs53MX6e4i8MsW4Ted8qM6Zl+27RRvmuqKkZtVaz/EW9HUtQ4W2ASHDE1a 2r3upOZ7NvKGIgGOuh+0Z9FPtwWjQx5wTspPRPDAOUIUcG7es/LCu4IhJd+B0qIE0A0EjzjnUjKi rbub6NwjjSwvEOd8sZGlVunbWMWhZQgEUzergsZZ0hAYuqs1M0fenKpPHKUwxHJvwfgnHywgzf4I UPK8vyLQEgJZ+GEhAnOonoeWXMHq4F2hzg/W8aA5QhRo7llBKXbeob4sxXGHemWtXxd+gXjQHCEa NCd1F6x7QlC8AJrzQUE5B3/V0T+UM9OtziQl1bJgITemjDwWwZZOhLuSYh6Vw2n74Lfy6+9YPQlF j9SZHkDaalVKEdh52yojWY93Vg68b/wiaYNNTE7ZxOSN45NqBY8q8ilzfKOCp8wRoihzfXWEl6sP ceTqFVMFIPKEEzTn0tQSDZoLd5Ore0RIvACa80UhiWXTtl6IeXApZLr8l4Qy5g49Tg2Ps5s75Rpy TPpxBF6RG/WrYSipq7vDLrFqiKBgOLFxrid28dg4QhQ2rq9gOJPzD3qT82ihCUEZPjkXDY0L74/k 3AvQOB8UjELuGNn68D7ZcyEOgWNNTHVmgNWvj1c9uoyAoslqz43TUxFYGWAOGcuFUTsnItD1F3io nSyIoAdQnFreciLLdBa+XRl7bW1hRVdMWo1m+qogwULhWXW+78Aj4whRyLiLvNnABNtsYMu/1zyd Mg9zTJnXZwuw4AknM85FL0Qz48LdJehhHqgULzDjhvqgXkxRmZcGMRNZzeJN2VD9ITmdyqk/T5Ot 27R3y+njQxE4c5l7WYHAkGTTXCU7S3VhUSepD0tm85J7ruZO1llmJiLwRiJ8pG8sh7HDyNrdZNVx wYSEh4tz2VrhcXGEKFzcs5ry3NNsfeY2R7ZO+ukFlofP1kWz4sL7I1v3AivOBxVF/ugyE0fWllDj cU+VnJpq+afKEEEHUVfquVm1MJsc4/wwuLHpgPGuqqYyMmordYAcc+8eEww3s1t3LFp1S3D/JRPI 1vHAOEIUMK6vrDhJpGccI+cVxwXI8AQeGEeIBsaFu4nWPaIqXgDG+aKqBHY3N8Ic0hh0nrwVE8nE I3BC+ycEtk8xGhSQ1rSa4q9Ub6lUXEiYCGcjwCwo59rVwxAYR3ITF0J6vj+ZTcHdVgO/XnDXxQPE hfF3XXhAHCEKEHeBFydKn5861urTnXdTD3Fc4V7xs8Dd1AQeEEeIBsSFu8vbw/+PvTOPaura/vh5 xQFLW7Q+pdQhtjhCFUMEVJSr8lNUVKwoURFii4p1KM+poJZch2ftq0pUtEgdIqAiBImggCKQOoEM NcygVFHDHHlISICEm3t+F5Ka5Gdu83u3WfBH3h8swr6wctbK2ez93XufzzGGf/S8Sv/E9PyjnlAl Vi2lEOQkF0KwxV7EgyBsczRewcomUq2xhexLaCyhWDxvSKKU8yFYRsO5ATVzFSfwS4jSVZibvIcv YeARrM6C1RlMuTUEi/jK+ol+POwoBFeYuJS0RaJFjGNo5V/0yfqRcYSdiqov0z6PbtOVg8VrdRa/ Vp9Hn08Cg1e/qcpxtNvwlLFxUwy04buhWX/ZcXpe2A81wcDiA0EpscvDa+wKCQXvzcBZp/hzBcqV Qjl7Wby/cuAfXwc5eOx6CC6lKl+PEkEQtwptIFT+XvOpEDT+zFJ4oM/vkTqJFjNO10n0CnrC/leb 70Rc8Z+pFVl2dEcWnqX5ATIP0YuNI+yUFX0PdN+J5f23/d4DPtKcVq641VzPqfNtXw0Bc4RyECbO FLMaRYIo5PwOljcENXNLIIjExL8oUiGwnRSjtKxbU14qkH+5C6lHp4srpVvw/b572ce4BXb8wMIb ir5brp1OIhsCVn+sqt3ooLsd9cp6wk5F178bVS5ptRe/VjXf8/aRzHap3/SdqELYKat7Q+13I4QV Ynk9L+9NMq6gpV8IG1CHd18ksgrldkOUtJNdL8awWsLRy2j2PULRWAcpmNj3by3k7qER8pOdtR/o Z8cRdgpS/maB1qH2RYSQn691qP2B+lD7cnMxyRrperU8Yacs5g103xlGEPPE8npezdNMkALkKiB2 e7iSlZvmyYcgi8irmJKEMDEELRFoKRaXWiqQfc6XJvFCiOxsmS0EHrZ/mFJcEyCI3fm9r9w7u7RK NolzRGBbobiDXy5sCapZvRwC2nnl+4gobyFX1CqIdMd2f+OFsYOk4yHgkN2koP7UVZvVUXe36tX+ hJ2K+H833vTRXDviqLp2JBcf4EC2SL3qn7BTlf+Ohpr0Rgk3vYCgM8VwY0VIkqEQzMdnZfQlFMkh QRFy3H42qogMlHKqzes6Toai/xpPfDvs3mLNKqY1b3WL7jjKb+C0p0QWYvOY0uzOSjKIkPozVAcc Hf/QD50j7BRUvjreDCTCzVLhnO6AoyHDl6jI8PeiB/QjWaOD3uY9sXaqIt/RQPfeOPGm50X+30zP O9pkTeJKspvX1R9C92vGFB19rp8lR9gp6HOH5Rp97q8SG5rRlE2XVJO+I0kGtNRvqWd7UwbKORpo uTOMItB7gShnY3r7+99dVMUhmHuNRZriGX6V2UI7NUksDlJEsh6wl6bXxaG5SUL5ZKtzMk+5d1d3 /b3WC7GETs9Dqn/1fU4rjFHSeXfuK6ZAcMUxKBidx5VmxXErLfEvQ9xFnp0VK5AUGhal4GRx26/H oVsQ+VwZ7RjS/BUKC5LlXKkbBCO9BQz8R1SUW16LFlpiu8na9er9oNrGUx11HpAoe0pEunczLXNN z151Hj7PZcBUsjXqnaon7FR1vaOhrr1REq1eQNKZYKLVjL6cyy1C8u9UdXwZIOW0TmrH/75KaYM9 Eh0PnWYuOs5bge2CYCg+dzVfxO9IldiWoiPQh4ITf+ISGkDdNB01r59QR9gpqPkircajl1lffy+3 UXZvcytVXz6pj/llkiVqIep0ynGUGXWOBjrzRmg8EqvreS3fxwRzK+FrQRm+von7BL2G5VUiSRD4 kB4aUX8oqt3u5KDzgERqU+HMOWjdfFCy8m7F30efeptpqQ61p8lI+A7qN1Rtdl13pKyzDbTZGUYA MhLL63mdPdoEd/sMRPQaPxue+BICWoD09wyOZUcncqWmFoJKN+XqGAX3uL0z/pTWWIqUYPt3C9oK IPCOxWOqzX0Hyx1RM/nStHGSTXh/SeROz+pSzLKGKUixwqKnc6Q8CPaQ/8CCBXchuIS2PDxIiHwI REf64ycgyCZrzKv3g75MSz+ojrBT6sxrs1S6M62rGlGj6svfcSXhcKnfUk+mRZlV52ioMc8wiqv1 vGi3MkFR8wTbhp/AeHcCWrIV7pKEJm42rYGWe4zVUvOpQJTriGaf+gCVzSK8QqB8+egTCBr3Q7AA 7bx/nA5BqRl+EoL2w+Q1Xy1GHV2nnqofUkfYqYj+Ui3/GGwxqryiZKmmpqW6mT39OxKGvPot9fgH ZVKdo4Gu/BSj+EcvoOrsTJA2VIfyjkGwEDll7xekuFUljZbP0djsmhXjXvAF9dwDmRBEsS2EaIpn SwetQZCf3t65jghe+/GzWJ7Gmsgmwsx4vhKRl9mXojVDIIiBYPpDBR+LEkghqCMCUJGiHQJbvyP4 z7LLsmZ8eYaVcqLYQ1yFxe6xV/iUoW2B7XXYtgAINkDARrOHqg3kykcDxnPULSvrJ+MRdkrFgHdC 1EWt4bFNqjZ/Phgwi2yVJG1+yoA8R0NtfuM4Yc+XA0wxSNXjjFpmkHsL1+FOGnJUfgqCJ5bSMAjW IUWeyuNEQHLHp0S0Yod0v/2JT2hVA3Rq0foJeISdQjXAoVirHDDYonsO2UyDNYq9rLqygTXgf0hW qQXB0/EJyhQ8RwPd/SlGqQj0AgbvC9PziUYkBW05U1WEPE7jNHGxDc5STmtCdCcRGKyPKW0w8e16 tNHZE4KTpWh6Ql0kBFefIbjHClxy58JhPHonBPKJzM7cB/gTruRUTkeqJN6zKQKCCYu4R1BbjZU/ /s5RVHqYPbfGahsHP978KD3q30TiVzRCbgULtghlAcPwBbT2U0+4jY+dsZNI84QbSOm5QPlo9Lm3 lXJWVV1nngV+MbBVWXMIgqXOclxC6pIaCp9j179mrQckJQsqHD56V8XazWymRVeQItzS39/j7fgm Q3V8n+dlvo9siZqahU6BjjKKz8nAbICz9gH+qdQdsqeLFh+DeSbokP3Y854+89qQu99pcpA8eEjJ B9ix5LQrv51+b8vaZskbu6vW8mGbdy0+a9un4m5VzYsVP1Tveckf/ont/e0z/1Ee+sGQr26PvLU5 u9/7Nzb7lR39iZPxy8EXLx/I7ZySmzY+utr55KrrR8M9T+o+nGQfGfIPXqwsPjRCdmNERUQXmmzo rZ9eNHwkuvD4xV98bA8Lmna0ZM/195yf+np9UZbDlUdnRFsGohHf3e4QRSXGXPJpc2jwt/Zat2hb ijmSf2cNtq1wZXHRxE7rnYlHY5PGTq3sQ6v18yltzUz0itjYePu29Re7R7lmn+lwN3uRnsqrC/k6 xqGwdMd2h5WSWSEc+pvQ/nd3BzIfKx4uWR8dV1u9LrF6X+dI/5fDLQ/8YMfwOJJ4t/+W82sHtVaP //rGlFt3hg/8LqfsbzTXOboPJ7K5MhexOzOy/KuUcwsXHVyX/M8Lnf5eLauVSGNQWSjfLeH+1qmn IvrlbB4wsy0r5lWyAi1pvjbC77DvD0+3TXD48GTZx3ubjnk+RGFhDUuZkJnELOc1vBLsShhdMdKp vqhh7PeZslxBp2/IOj6fWfyQLV6z4PqMrYWXixbJQ8Sn0bY0RQ7Ljx/zk7LsVtja4Mpoj0sRks6y pmfuEzrKl63xPX2wj/VB/4+uTQ8+ZnnGJ3XX8BiR74Jt33l/MHDDh0en32x4NcX1q2+flWznHts1 5uGTlZNnn3Ga3Fgc82OB/NA1GZKwIowVVTezzsc6fXP/457Brpt9GtE1vLGCuY/3Pk5hBJdZjrrw 5vuy1BL8tvdi9pFz7ee3bGiJHzl75gv5td8vJB+oXXXIpyok/Gbi8+NtNwf133HTrCbuWY545aT1 Z1ZktD/Z6zGiwXLz7IFBLrNcV5P+ASyy91GcLWK0tJwNC2N68q2rj2weUzYtsW9SE0Cm+KXKnC8F iETO48YmcP0YOUPLPOJ3fG2x/ilgb8wIbAycL8zO+nbJYl/X9ICTE+PDV9Y+GJp3E2ClcZkZIasC l/9aH+ycWTbjJ1//frVlBc8cZ5y3WRDqeSCZWc7nTWw8M8KyX/vT7BMe8Wt/f/p02JWYsEvf0HPe eMcpZLL1GV5mkS+ed66UTNh1dNhZH7edJZKdx8ZOczVn+eE3dn56fWtW1tZ5bUXry24tKHb79GRA joW4quzbg94f3qr47erzp4vSygdM3+i/bJH8s5C9it8KNt1NHWadPKxyQfjql+MWf7BpAXdMzdSQ 7xQJQ8H6zFfzLmfOkMyYXbh7Cc03k3don3XgrROxgZwZnIE7/bwOlwfGvVzbz+ffozf5iIQ2D0ZY weI6mqwTGTYi9Mq+xVEelf4pUzGXQS9uZyvZwqxs/9iLgzeebKtoCkU+ehA8aRsErBstiRWNG/s8 HZ2R4uLPuZ840mJClS/7+rkr1YEbnwas/fawKB63+/+ZLjcikks5Ivk0xXD0k9144C8NezhYrEMw voR9mJY1Ej1bm+YXTSjORReQMG5kdsthbq38iiIRC81EjgbRirB/ZcajNnyOaES2VPB5II/2SCzq yN6mtH8kgCXFgo5oIa2i7DwED0cG41k3m/HxrdltjnUQrBa4yAMRbqsoTx7OVW7CmmvScVTIsa/1 Q2W8VsHPrXIIXGcIIrYNUY5tVS5he/zIb3DmNu6QrJmLLkiHwIt78g6RytjUK+3FrXjLS2xMEO7g XqhgldcpRfc7FjZj6zjRUgFf2Jl9+E04LG3Jaq8LzcseVnXBxX54IDv4dfJ0d8kMoYi9X4G44Qfe rD5vIx8Z0CKYpaQRudDs4IlLTmAcRkfVRTanAIKL6UPMsI04Q16q8418mEVDRaVP1b5Ymj5ZPxeV sFMo/Hr9IR+8zPy7CNoMrWzFrTtbibpv7kGyRA0VVbfDQhmL6mRoVMsIuCFieT1f9n3f9JKVVBkf go8ZOCv/mnIzBA+6zma12qGrIWixQWqwvGLk9YA9Acr99osguD6G3A00M11TdXS0ft4pYadQ3i3X lJa8zGxGlVfkzxFqzrvnz++u7z7wHWBF5gh6MSqEnWp918nAUBfdKKWlXoCefmh6jvACTQnA+HvK Fbsx3v4u2ZshZjXUSRL6d25Ac9uvoTHc3FQ7wkG+CoPA41O0fsWR7QJsnjUiTYzBD638P49I/USL cUrX+WesH3JK2P/zGmzyci0v6So2MXbMtNDEC//ueJF0zzyRbI0kA1mUOadOBgay6EaZfewF0Kml CbqJIMUdH20ZT5N8k3cAf0LrOO56Hc2JmWTRuQ59NUtxF4Kx547JnEOvQbAwvVnxsTQwNn1XoGJF HVoQHh2yWMRDi/gu+D8zyEuy2qBTnfqPftIpYadQkvV+6yI2XT2KDQlaRxE3RHX3KJJ2mCeRLNGZ ZECLMuvUycCAllEcpBdYp31NcGTlcV6li/2W1+THbTV8UobuP1j9gFLC/p8XOJM1I1klv87vIgPl D58/ts72TWNA7acREba3qlvfA/fTBgwiW6PGCXWXSLnCaWAqi26UqaxeYJQONL0t3orEsySRjahk Q1VuulBshV3dw8UiUiV8huIhBLYjY4ggsBXj+XSyIMiNiYYgJw2C5z+ntgkgOO3pDkHYLggyJgY2 ocRvX+AQvy3unrkidRitO0B1kib9KFPC/hfvHvGyGUiIizVaB6LyF3WLi7z5JFflqt8z8F1xQRln 6tQDl48Qy/vv7SM9ERTCfsVPYEeeepop3CX238ywbKA9Our6Y4eNZZSr+f16zoGdDeQlJg2flOGs o631A0oJOxWeSYG2uHbryon6vT3EkZ+vOsTxaoAb2e4nGZ2ijCh1MjA6ZYx72ojl9by0NsGL2lqb EwQSvpgr2VPVfrmuyhetYZUj1TJBs4cwk4gMuYIENEeMPv/ZxzWMbSOJTwkZi7nXrNqiWNzByc08 BMHdVSEWEBxIUlhB0Hc9qZ9owUnpOmm5fjopYacy31SsOezkZePWXYxljHJ5GyfmqOKEnHSWYyrJ fBNlSKmTofkmZ6N4Ss+r62EmOGSYbn85TOls73NPsQop3q7+8fPqEKs/vj5bu509fuVw7k9D+497 lcCLayR3B63RJp2dph9AStj/4u2e6rBxRSOk1VeGvGf+kmSN+hGkhJ2ykDYw2GScsNELEFITDBsS PBbn1UIQ8wSXMsNlnjKWs9JV2B6VLohD4+SChjY0Y8hwROY+WDmNe9rdUvnlAwiWBNR8eR+C5duQ 4gg5swRpey8zEoLrQ2SWyn1kF4aoP0/VNnTQdRUSRU6JRqovcrwty+5Q3xnSZE66SBIgCWUeqbMh IIlRAkcvAElNMHBIv7CU7bVXOkJwij/nVwiYSRAUs+QLtewJocLffEdwf0lzQRzXO3e0f+/thXKC Hna/XMHNx/mtPCRCyarzRhkKwWPy8pUWg9RBu+FNJ2GQ0ikxSAu0nMXMjXAVLy3A4g5Vz/t2rnmh /kXSJ5OoccoMUmdDPW/jOEvPq/FBpqhH+KgkRUHEiXHNEOy1E2ZmECqkUmyJcQXK13zXroMXdoHx iIQNQXvSjelMBe8Qfp5Vs+q8nXLFPSLI8CXxj0/jcS/RGKacKeCjfvifuIvW7SJTdLaofvVOp0Qj 1RNbtG42/FbFO8njk1Wv6BogqY4qoVMGkjobaI0bJbjQewFIaoLBRcyAoPT7KvmU5ty0fAiIPAxf 7CJJuIEomb9BELYE413hyS1cP9tZin4W8GDSL/zqLzoOeX7m9Wi5ZGB3MDko55biO2ldMYY0CaNP JmmN00kopHRKFFJdvUK4yeCLS/84iHE7sfsgRloJ2WF1+mT9rXE6ZQaps6HWuDH0Cr0XGKSmWObi JggkN7pa4F1hZY/dY3ZXcUso7t8VVur50xRiIqwg8bTusBIVXiKUr5AKpfdxyTJFBAS2mRH4GfT5 QpYXUsMsRootO3P+l7yzjWrqSvf4bjuOIJ3SuVap0zpptaMuUOCcQAGtpNVSXYMWFTG+Yeg4FVvp cEeLXKxyruOa5VWraC3ie0oRMBDCKEUqiEetowgqIgR8uZpeIUJAisREyeGcs+9JouQcYTdrnZVF PmSBK4fwwf0hD//9f/7P/m3FTAhuj94wFoKkFFMGcwzZIsZ4iFIpv/WFIRClmBhE6UAiM5w3WbJm uG1XVtPq/QFimQ5Kaahg5yiaUhrmJDd3jcq4gVLqgSqjrYEgk1wKwWw2oXQ1BPrkJlk9sXfSUtKy xFxr0t33WZPDvBGpyPzbl0ROYo2x6GqGKcmSHleSLNH6rLgrKxh55RQx3584wKb7K+9DoNyabyFb 7yF3ZhgPQ4oLi2Zg14+JwpD2FxzeTaFrnt5Bko64g+Tp/5ncz8hgojGkYc6CeJcojhswpJ6oOMXF CuMPDiNz9XQlUV3/zMdMpsyc4MQ88zFZDcWWeZzgXCRORQSpFMZcg9KwA4L/Wq2YR+qjOcUZzT7U m2YwJVl1ksdXFR8StyOQQ1oYD1EqFWzWEIhSTAyidEDBcZybPbnPtl2r2eU9FbFKB6RU6GpEQ0rD nAFPXKM3g98F8EC9yWgiLPEtRN4UY+iMDpLWGLkKsPwhx6xj5WkSww56ezwRRRFd2ZZpHVRQPQQb fKv9FHXpyt629DllalbaMtKsvLD+H3dLemp3zu8lSPJQbCfLsikxZb296AMjmIN+GiIV9AMQ9FNM DP30ufaZNZZ52ZHmX7Gl+dUN3lNQdTNwmo+Jpp+GOUvzXVI3bqCfemD3zJiez6ruE7ZUZrdZZo6R 2lMZpQqCgjSlLZa5DcEqQj9KZphh1Oh6l0Aw4ZIVk5K5FoJbOstHMdRcuvBmVknQCuTQF4Yj0nwM gS7FRKFLtY4xySrrkOTrVX9+hogvsyPiK1Z7taCW6Chl4QpFdwOcRfmuGJLE3EAu/YPnlclFqp4t aoUgX8Y8UBNFsva7BLUGgrvV/F9omtt9qV1MQkXGUVn7DPM/fon8DgKVpNEn/83Ag/9Z/vdzVyDY r9ZZCqyv6NaZg2kaIkAmYAimKSaGaTqApqj7ov6/2aP+8t+i4ktMOnDUj4mGmoY5i/pdoiluoJp6 YiITpJYYVe0K41rdk+OnajqG0gXrsuhDZZyLwa0NNf/DuZzH+cLqcUi2CYL2GbEQzJbsSuX0BAJm ZjthyDEGQmCdOFaNjmFC0qO6ou9mVSJ5dJiUZ/6Fn0eE+RcDRu0nLwv7BorPvW8bFCuc4JWGWuHA YFRMNBg13Fne7xJ1cQMY1QPVJdd8gIltlxj/UvvkuGrDCgjmU5vpvSXMgwLFIlIbmQ3BuInWaslh tVy1LEul98m63v6SuEUy0Vch2D2eaQnM6JVzxZKmM/4VglP/vDnC+nUAgtBF5KM46yt6a8ZjnYYI mlII1ikminXaX26O8EBynxy1CU71Vm8pYpUhCPMvmnYaPhgjAJgbaKceKDg/lxez7yzjyiT6DW5P dvDHwEIItvgdJa5fgOBJfqBPAQT3otolpmMkY6gppfaxuXoILjVCgHem5xGqNMKYQl6uUKiU7csU 9KHkR0Grl7VUXkL3y3j4U8ERFgyBP8XE4E/7yc1M3vH4c/bj8RUTkOEmAn+KicafhjubAXCJ4LgB f+qBgrO5UWJOVhGXDsj8B368zXLVUcWp0D5J19tfWP1/y4bp7KyMJztPQFBKGm2aNKO3Kn6L9euZ yFhfkUXjAJaGSAV/whHAUkwUsLT/BLNX3z1xx4MX2JoANd95R6IW6ZjnF2qh2CZA+KCMBLiBV+qB AU2rFQtRyhmWlguJ+oCDVtRKE2dRdo9SfqtZTdLR8QQ7a0X6vIr0THqZnEq1+CVfJ7dVQ/AxBGM6 KXl3msKga1mWBUFCzXUIHoxap2A2oT1NCK8NwGfQYwiYKSYGZtpPZObwLio9Z7/bpCIBNfGPhSLa AKJRpuHORgBcIjJuQJl6oMjkm4vZuKlydhYEwfPZUuvpYW4jdkl5f5iykbTMNyssUvpsCjGHqyBu O5aXUeUnN/taIhXUSnqj4O35XwUefRw/90EJUWX/Rk8BOHCjz4kMAjeKicGNCs2MDV30at9x/EV7 7cfxqyd6Y6hFIqYARANHw51NAbjEyww6b9QjvcxZKpM9mtJFLeT8/PRhv/aTKUmmDyHyShjDuncl xv2y+kWsqfINX8tsiUENwbpl/1P5+3Vj0JXi8AeY4G83gnSHiSHdDSAvjlP45+yn8CuGoa44wXis O6G8iDb9zhJ/18jL4Jt+j2ya1bBx8QpmCr01qynIEpdCmLqM/oqlpD5OC0E9WVWe3JlMbwpgQr/U 3dJZfiunPjeQnHV5udikvZG++oEsYq3kYAlZbf/+FUmJQBUKwuyLgOH1B7y8fP7jPtcit7mWn77x /g9UnfCuKxK8L9rrO0v4XVInbkDheSDfZai22Lykw4+ZmMyJwvtUKVu44S8Q5G6HoGumZAGpTVYr bI2xlL2SGhUEsxJ7r8WvGGpsJ+pHsSa/RRvpcqXpAlE5BFkgfAqeYBAYQcHDRFDw+inJy+efRfvH //U02p/mdQ+1QkcJC9p1ohl44YMS7buBgeeBOlJLPYIg4JUi9hB9NpFJgyBz8wLOs7MJJewpzrP8 VEjkE8HxQY9/YKMPsft1VX7RTJHsm1Yir8w4hLPxq2JaTuoMRfTGtZVNq+6srWxMpm+ugODKHu4V 3UHmYfEEnGEMgcXDRGDxBqCGve/YfM2zbb5KXvf6F2KJCCweJhqLF+4s4ndJ0biBi+eBotIAwfYk 0hKaqF+s7C7KgmCcmi6MZUOPQ9CiVWauNBXrf4BgNjngE7osHDC9kGBhWSDsuwiYXn9T4qiK6/Yc v4D1SkWtEJHji0bpRQxKju8GlJ5Hxio6ywImoUdZlW0uY+PIhZHjjRM2fMFJSnKj7xZ6m6J3MTFc ye6trSqFoDS/OwICw9f8tytiqztjAkrfU3dZjl+F4MBE7hVdLLyj+4IGMQKkh4kC6fUL7j9X8YL7 z54G973ekxGrDEcE96JJehGDEty7gaTngc0uw+kyokDDbqEL86g7bEEFNd6oOdCRShV0tSmrVfce Rr4Q+++f17+Yv+1Mz5C2jrqmHPTUJI+rFyHoqiK4epgorl6ckDQsrAX7ufxyi1czqhYQmbxorl6E s0zeFahhzA1cvVEe2M/aR5dwXuMOXb0n0Xi1iFWmPvJfpKyZXEZt0F0u7+pMY7+fwkzt0LBNyvax ZP1dx1t5JW0VPxNjDGoqsEdSVb4qctvpocaJ2v0lcmS18Oh6Qo4Fgq6HiaLrCcL4l6wnvmJ9HCe+ cu0H9GuueE9DrXJguh4mmq4XMShpvBvoeh6YxpuC1BDMmLTOr5HI2VPp0yGrq1m6JnJ/8z5T05u1 eeUQ9IJ4gvnvQJI9g7zoHeNh9cIFdYDA6mGisHrPGY6GabyQ/frTkL3Oqw2xRgRWDxON1YsYlJDd DVg9D7QcFeZCNm7DKiqOnaZhPuechmIxm0nsLCQXk3p5I5mraJmgu9XcZpYYSoxjiVUZOQ1EXm3V dkYTmTGXPSAb05kRcOI9zQ1jCQT3a2Rsku0VWS58tJ7AciDQepgotB6P3T08Onqqj1U2eMfso+3H 7K+84D0HtUxHwC7oIoiG60U4C9gjXFIxg2/SPZDebdpRRGdD8JJFfiQlWe/bI6muHFtITCDOsHFn WomC7ey+pa+kUkd1hsynP8Zvpv8EgZpg/jjQE3qwno/W4zsSHIHWw0Wh9Z53JNmJRxyOJM/uSG6j Dj3iwYiEXTRZL8JZwu4SR+IGsp4HOhLfOAjiJj+h1lxbV0ypmsj6w5u0hPbjSvag+TqxijT/QWd6 kh418KN2yub1w9oP/XR6SMrH/6d7sWTB51d+pVIiUJUysHfHRVH15jlExcdaKa/0naGfaD9DX3He qxtVJ45aDhO8L9q5O0nYcVfcuoi7gaj3mgcqyt1iOoUMNVQqejrSV9WvI7sb6aZR5k1bZfWLf6xV vzmX3a+9sCHhXoapUVPDZpPfPCDb37AE2h5RNYHzAHrBwpoY2KHjogB6z6sHryYmvWarieFeBtQK B07VcdH4vAhnqbortAN3Az7PA7XjKtUEgX+6ipHd95nSoaBVVL4Jgr0Tu4oIY367sp5NKNd1rmGP 6NjDxFvxyY9PQjAvGYIY2c7Ast6lEKjCIMhXVvkt/MX3bMqOn2nbwwq1dj9yUAvnY/MEFYPA5uGi sHm8ntbw6DW2ntYahzWJtlmTU+O8HiIWyYPmCdco2sw7S9Vd0dLC3QDN88CWlvmPKlrV0bAu35hf PLddWX345IOu5iA249GI2kRiFGEi9mq+mtJTA0EO/e8k4vbvnv1DBuq4g4onjRD8kUZQ8XBRVLzn VUTzzIEkJXxncyAFO7xSUCscOFDHxSLxpMHOAnWXqIgbkHgeqCI55iY2bhR5fVhGk8IyfwUEM/1l 8YR+7gHmrXJl59/Z3Ba7SsQyGlnDKaXpkeXFdqL0IpW12yYryys0x+40LfylY2qi2oyuEd4kPP9G LhxBv8NF0e8ETS2prakl7ctCjm3MtmUhl1ejaKs4gn6Hi6XfSYOd5eiu6GnhbqDfeWJPi82mT+qG EpUjDMx0y5rTr1iJxfXUZmPr+tGsaYEklp2b8ZBoWbghxvKR7CwEuz4xy/SvQzCUjcqGwJts28zu KPLtmQ3BhzJTykriXDL1Nqcyheia4Tn2cMHHFOHYRXHvnteVPEfanpTwNG3/FgVbxRHcO1ws904a PBhpO+4G7p1H+hPr1O9SXRsEF7eif+iQleqoA7uts8EpyltdzOxLttHg8trOVDbPKj5EcPzyntQz mmP0lJ/lC9nRDwP2Lj13Hxk44jwQnjRU8AuErRcFwpv3vNQ4ro9ISlDb7/FK89Kj1jgwFx8XS8KT BjuJ3V3T7HIDCc8Tm11qpb6Jluf+FYJA8l5lwHhLCgQjdmnTM2X1yfpFo+WGWOZdNu7ZG4sJsw8E pGzfZxA0BLE0+2k+BHPI3keWLHSN8O6M54fyOAKAh4sC4D0vLgWOS+OTEuyXxpdfRh1NxBEAPFws AE8a7CyUd4m4uAGA54HicoW9oTP+UEZFcY4lKdmyeAkzpoQ4EUYXTWJ3xcc8LmOnH2APy+5O47wK aXxTZ+pmjZyFKYJg531OUjKe7KwY+rBrY/wmq7CctQrLuJOhl5CjjzifficwMAj6HS6KftdfUxyZ /PKX7Jl8xVgUKgJ3APCEjS+xADxpsJNM3jWi4gYAnieKSiydsq0uprsxKEp2cWEJ1Wocr2ZP0ls6 ZBpizLqTELwu69KvYYMJXXUrncDpCVo8HDg74RwwjsDZ4aJwdv3F44hDPJ6m7mtR9FQ8ZODUHRcL s5MGD0bqjrsBZueB4pHPnCC0jx4SvXXzIThRS51O9+XcvL/y8U0I5LWcee+KSoZgla85aCyDkTsn QdD5CZvbQuSFGYeQjFrWcCrDdIF9vyL2ztr88s6YlCpN1OoAdLnwjLzAjyBQdrgolN31vgHI89dn WU8iNvym6tn59nefnm+/nIa6ZRt3sOyE2iGWZScNdpa+Y66oFzew7EZ4oHa8pzQvD6Am0Zplm3ez 6k+JKDKz5pqR0H5d3FZmPDkCgvM3mdfkEAxPNM1V0LOVdUs7CD2WSO9L7L2dNVlnmbUIgnGL2Mf6 q2Vs7Eji0h6i8iQ6UeFh7ISbLQTGDheFsXteX17sy+V/N9GWy5drvO6iVojI5cUy7KTBg5LLu4Fh 54HqInt8k5pPXCok/Qd6qmDUZMP/Kg1hxgDyVg0z+xK7mxjjeDPwau33XW3KqoopkdvI74kxDx5Q gewWetuOpaub0TuyEFQujwDZ4aJAdv0lpo+WeuOM/bB7xXYUIQJHgOxwsSA7abCTWN41CuMGkJ0n Koykp/4qm0l0BVwjmmOmUHEQnCr+AILt73UZ5KxRozXF3Tq9tUJet3AS+zEE1OIypkU9EoLxBDNp CWtc4EPsJtk9nL1PQ+/DeOA6TLAPQ4DrcFHgujpHCBk7dvnUsZyL77uHe/n0p5fWK1H3cOMIcB0u FlwnxZxl9SEuqZLB9/Cve16VtHFuxa9bC8Gl0joIkoKaCyHYvSqHvaG4yG2+xtWlHyFUnJOJKTF+ z8yEYJ6EVSbqo6hd7BEZE1lbXbqu2Chl9yl6ry2ulFtGQTCrmGmbtKyQ/hqCPDlrQkcqPJKdVLAj Q5DscFEku0YprwEWa92TqXlp5Er7OfjLL6Lu5MbfReT3Yll2UsxJfo/jLqmdwff8Iz1QYZZAoOU+ 6Fn6gDrO3C+Qsopvi6NIZmGtJX2eejnz6rN/mzJY1acQHCljHrzVDEHBIsIwCYKvvMIhaN+joKKJ u+fQdcID2QnrBGH1RYDshM6Fk5flU3kCM9YmMAXveK1GFcnAIDtcLMhOig1KZO8GkJ0HWpeu8ibq x662jNb4J4shkI9mfk93nO5QtDeT38sOrVEsgEAf1QBBNt2xnyqDwD8wn/FtXdqkJS1zU2RtxOSO 26YkdmP8V+nbldcCipPrSqghSUWZx9EDxTywnXDIBQG2w0WB7foLyxFeErnSntZfnowcDHPA7YTC IhZuJ8WcpfUuERY3wO08UlgI7cRaA4H3fzimqLMEjGAk31gf/qToziJyiYvnOG8zKpWS0+v73kGX h8PXBwsaTQiGHS6CYRf6wzXH2flr8zhXP9Nxdv7GNfvZ+VOByPONYQhfLxZiJ8WcxPRSl/h6N0Ds JB5IH4okuU97FqOoLo8phuACt7GSGzW7OyDo3kdo6YIyLWkeU2w6XriB257N84cg2v/ZWyciNRCo vlwfb1lwUaszB2ZsI/1vUBVsbl13qn7xfAgkh5hhsuaaPyubH5HZM+i0z2Lp9FTTBAgykDc+4Dz6 Xajw04roAYii3/XXm9/03ZDybkic/YaUFtQt3HgYogcgFoAnxZzl+C6RGzcA8DxRbvw4TzISgpns +5VDOEvyT/K6bGfQBwSVnWzKaPFq7flmB7FlAveyeUb3KEW9pOuL6Tk9XxcbMp6cyK6jP5KbLvbe RkKLcB7wLlhQHwjgHS4GePdUb17l5ObD2mk2wZnpEBw7sv6cytsLscZwRLQvFncnxZxE+67Rm8F3 +S94XnU8Nnd23EbeJY/zCHYhAn+OINjhYgh2+Pw+fz5dajcbjsmVlRr75Mo7yJl6BMEOF0uwk2JO knipSwy6Gwh2Yz3v8/2LleY4gp6h9ymn7rBH5d2SbwM7OlKpbMX59DmnWguI6uO1lmC/g+YYywJr 5v7io8MqzqfXyFrOxN+V1OUz2P+Td65RTV3bHl+3tgrFFluPWkSMFuuLKpKFomLZtlyliootAipC rKDYiqUoKmrJrlprq0JUtEh9REVFCBIRAeWVWpW3gCAPoYIaHhLkIIEASXb2OglUkpyymzv2zZAP +eBAdmCM+WFP/nPO/1y/xUu7I7NF4PLMHcH4Qm5HViy32pT8IsRJ6CKvdMOSGcQFGSeL23UtFvfH pAskjFCs9SscFSdJuR2OCIx1F0DyZ1yYV9GAPzAldlKb+Br4u9labgsF/o5JC3/390rLSG3j9x6v Lxhv7EgVI8UWPl34HbTRZePrpdAaAPidARZarfjTBdwSrCCttvsLvw5O+/Qu8l+rFJZEjvBI2Bwj 4RGeG7ENgZHkgtV8Ib87RTy1DLfA7wmO/kNKqEl42ieFKUh4TDokvBIN/9HR5y0fV8dxVn21Va9J f/1to2iKEDVAeFrjOLogPGijw6TXi/s4ABy8Nw2wtip6ISgn17dwH+FXifxq7DoCnv9wxEQNsoOz mFofULTadEB2TI0LGJSdQ+W/Jhx/VWn59p6LTy0yKqOKkOJcPF2GHWTq8NqhPqiPzAFg2E0wwLd9 HiZ8QZ6KSHiKAMOv488Mjmm3HLtc34BAtaNidbSMe8TajqxiiMqwh8SenYLOYgTcY8joOiOv4dKZ +CDp8tRJ4m/IIeLzQS51ZYRpvYcgeRQRNZfTwUNgF/U3LFR8G4GLeNu9fcomHwHhoSHkUQSyqc15 DQieVqUFKSB4kBYEr1wTytJTaV3pa2p8e635tAaj2v5jhBQQPCZdCB5k6rLmoV5S7fU37aMMsKl5 RASSRwleml9btsxJHN/CzWY0MfJCWW31owXCvJl49vGhuGS+MisEiqc5HyAg2oPAIlx+54gNAmWD yGMIdB2gnvlqoO9sZmi9lP03/ZAO+o5ZpgHidnQcV1H5cHnfTCvnr6vkDxlVUeVH/00/pAu/g0wd rrytPvIDDgD8zsoAmUWNOC8UgcXYcWvvHbKbtR1R0s/Uz6xaZZOe8AXPuXszEbjANinCk13auhlN goL0LrmvUrz2kKeIfPXTBLZSZibzFZi03LoMrx+BQDQCc+/J+MQFQQcCjUoBKpF1ITDV+xD5q+SS pJVckTFKMa3ZubmWiNllLfMsxzsDuhqJQD8ENiDAxrNH/vWAsvOBatLezBna73f/wwBIi7T3d4k6 p7E/5vuXzZ9KxcKHM/q3+SFd2h5k6rL59ZOEr38cYIgi9ZyEDR47nNq4zLRU7LD0OAKPTDvCEfDF SlwUR5SC5ETaRrYT+7W//ENOaEwDNGfRkIKlB+mw9JilmuMAx5515EFqJtLRX3rvh1hnbEsRpQZM Tysn6ML0IFOHu2+rj4kAHACY3seGlxMiLBlvO1lbghWmclq4xAa7Dk57fJRcKQxmoQpLovnWc1xk 54LAsTI8Pb7xPAJXHmOksxspTjt7gIwKQkA6zUOed5d8xBUfz+1OEce5tEQiMGUJ9xA+Vf2UPznt MN5xgL2gflQghzzSmpN+4d/Kwq/EQjoKFfsXSfzMyUWMruOPuKJCO+IY1jolESs7HSCdgNe4j1LM r22U55uQ5wLaFfX7EVhuJyXFlCmpRvnNVP1p1vig/5EFpIPys1FNrB0HfWKiEillWvr4OPetb1r2 nvGPm2R0iCpE9cxittZz2jMLHbsBdppn/GfTT8jXPbR4Hyw0wIQczF5Y9dh1Q96eWTN2SINHPBxK hCalXr5/4g3/ta3il1ZXzKTmm7YtPTX1zcrbtfVP3H6q2/WUP+aDqXe2fPJdRdjQEV/dGntzU/bg txM3eZcfPsjJ+G3fk6d3pVazklo25lyRP7ri8O4Yl2PaH063Ph/yHS9GEhcWKUm0qIxUQc1G3jz4 pOld4dnCJ//Pj61RccvWtuwFPi6fp7xYX5LFvJxzUug/DI/cfqtbeCEh+qJnJ7PJx8zVd0lgshFW kLaGCHywsrRkmtwsKOFwzPWJs6vfZDR4e5a1Zya4Rm4U3bpl9vHOcQ7ZJ7udBj1JT+E1hqyLZj4o 27qFuVI8P4Rj8zJsyO2dAR6FsnvL1kfFNtT5JtT9IB/r83SM6d6frKDzoYTbQ/zPrH2vvW7yukTb m2ljhm3PLf8fhsNn2h9OY3Ml9s1OHucrvko+vXjJPt+kH8/KfVzbVisw0Y7yML5j/J3Ns49HDs7d ZPxJZ1b0syQZ/rD1qoX3Aa+fqgKnMN85Vv7+7pZQl3s4elDPUsRnXveo4DU9E2yLn1A5dtbzkqaJ 32dK8gRyrxBfPt+j9B67ec2ia/M2P7hUskQa0nwC70yV5bK8+dEHFeU3w9cGV0c5X4wUy8tbHjtN 6a74co3XiX1vmu3zeffq3OBQ05OeKdvGRAu9FgVudx86bMM7h+feaHpm6/DVt48fbuGGbvvo3qOV Mz49OWuGqDT652Lp/qsSLN4tnHWh8ZNGT7P0TUOOuAQ7bPIU4Wt4EwULCncXJsPgctNxZ19+X57y kLzlvpR96HTXGf8NbXFjP/3kifTqn2eT9jas2u9ZGxJxI6HmSOeN94ZsvTGoPvZxbvPK6etPumV0 PdrtbNFkuunTYTvs5zuspvwFVGLtKTtVAtvaToWHe7jwzeoObfqofE7CW9dbAGbrnSKxu+gnFNpN mhjP9Ya5I8ud47auM1lfBdgbMwJEAZ8XZWd9u2ypl0O637FpcRErG+6OzL8BiLLYzIyQVQErfn8e bJdZPu+gl8/ghvLixzPnnbFcFOayN8mjgs+bJjppYTq4qyr7qHPc2j+rqswvR4df/Nom96V7rEwi WZ/hOuj8kxr5SvGUbYfNT3k6Bj0UB4VOnONgxPImE4NGX9uclbV5YWfJ+vKbi0odRx/zyzVpri3/ dp/7Ozcr71+pqVqSWmE8d6PPl0uk40N2y+4Xf3M7xdwsybx6UcTqp5OWDv1mEfej+tkh22XxI8H6 zGcLL2XOE8/79MHOZQyvTN7+H8wCbh6NCeDM4wwL8nY9UBEQ+3TtYM9/T/jGU1hkeddiFCptZEjk mLlF2OUfll5wrvZJnk3Yv/fkVraCXZSV7RNzbvjGY52VLWHYu3eDpwciwEpsS6gUbXyzakJGsr0P 507CWJMptV7sa6cv1wVsrPJb++0BYRxp9X97dEmEiS/mCqVzZGPwD3aSAb817eIQMcxgchn7ACNr LH6qIdU7StlxLjmLhXPPZ7cd4DZIL8sSiLBM7PAORgnxS2YcbsnnCC2yOwQfBvAYOc3C7uxAhXWO AD0sFXRHFTEqy88gcG9sMJl1o5Wc3J7dObMRgdUCe2kAxm0X5ksjuIpviNb6dBIv4lg3eOMSXrvg 13YpAg7zBJGBIxQT2xXL2M4/85vsuKKt4jUL8EXpCLhyj6UpSxnL5wrr5nay7Snx0Q6S6fRAxqpo VAjvdC9uJXw5UR0CfpE8+8DLCFTWltXVGJafbV571t56TAA7+EXSXCfxvCIhe48McyT3vlx9xlI6 1q9NMF/BUNZCnwZPW3aU4MDu2nNsTjEC59JHDCI2klBapvWFcpkFqqGqNrO1briGFFRVSIeq6trX PkCoQnFDjWoF9lQrURFG7hQhqomqWg4LpE1UZepa1dIHkQgOAFH1bcMrVlIkfATehySr4KpiEwJ3 VYez2q3w1Qi0WWL1RH4p9sJ4l59ij/USBK59RJ0G6p2u2Vp9NAUnFdLhpFZoTHeh67iKyoLPitSH 33PW9Mx37zkaf0iVCP3jVSBtUCpTx1KXjV5GSwMASn3H8BLhCZ7sR/B3Vch2Erw9qrY3o5nV1CiO HyLfgOd1XcWjuXkpVsoE+SocAefR+HO3Q1sExEIzrCMhmty/8r8+oswTDSyqjdYfYwosKqSBRU1a oZElqmET3PqJiVovTHr0IvGKUTpVjP0vZEHaWFSmjoUsG33sPsIBwKKaGmCaCJKdyAmmcQzx1/l7 yUeM7iMO1/Dc6Okmcl/82XzZbQQmng6V2IVdRWBxeqvs/Y6AmPRtATK3Rrw4IipkqZCHl/DtyR8z qEeymlRUrfkPBRUV0qGiuveliInKo9gQr3EU0Temx6NIXGWUQREi7H9BC9KGojJ1LGjpJUEGgIn6 lgGurBTmV9tb+7+gPG4L1RhTqP0HlgJjCmlgTJM0VrIKVqgwQQVjPp/YOPWlyK9htLn55Jt17W+A u0HGw6liVCehdoh0J5xQx1aWjT62suAAUEyHGd4r3o7FscTnRbh4Q21eelHzKOLKLi4RmSLmQ9k9 BKaOjVaKwGaC5ylnIZAXHYVAbioCNb+mdAoQOOHihED4NgQypgW04MqfPstR/nRzz84VZcJoXDCq VTRRoE4hLdSpxsUlribDVd3FGo0TUZXLe7qLgjeMHSiiVMNOtU062rBTqGO7Si8Xl8ABgJ0a4MUl neG/k0eJQ1Uug2ROYuuv55k2MXIOO/zcbWl6wcHoznPO3qAm6hmTml0K7bSaawp2KaTFLi3W7K6H q4qiwX2nOEJDe09xnDZeQPX2U+xO0UaXQh27U3q57w0OALrUAO97a2+NF4j5zVzxrtquS421Xng9 qwKrkwhanYsyldKQJ4jHc5vxml89HcLZluK45JCJhFP9Kn/Z0m5OXuZ+BG6vCjFBYO912SgE3lpP mScayFIbrbqcAlkKaSFLS9WnnZQ60TONhePs+3RiZa9OJBovpIqSYsGJNrYU6lpwstNLprz+9trc ALcM060vhSvsrD3/kK3CSrf89e2HdSGjXv0bv3YLe/LKMdyDI4dMehbPixVRp4PGbpPWm0bBI4W0 eKR/l43LfZ20f+/1ImmxRkKKGCl4pJA2jxTq2GzSj2wMAI/UAGVDTMaQvAYEoh+RHR4REhcJy07h UNR1IV0Qi8dKBU2deMaIMZjEabhiDveEk6nii7sILPOr/+IOAisCsdJIqcdDrPONzPMIXBshMVX8 QHmzCNSgkjK1U4WiJadFJe1POfrmsj5/3Sxym4rxAymopJA2lRTqIpLoRTgGgEpqgMLR8bGpZLe1 YiYCx/mf/Y6Ax3UESlnSxRrP48OK7ntZcH9Ltcdmrrfr7vre3RXn7LjX8183bgHJb+dhkQpWozsO ZYJC6vmVBoeUqeV4U3BIIS0OabFGskBVqrhqEBZ9ek3v1LNGf1IEqYEh1U4W2t24LtNbP8ny+rvx 9wyxH+Hj4mSZUicmtSKw26ooM0PZhVQ3mxJcgeIF30F18sIqIA4TsxHoup4410PG20+eYdWvOmOl cPtDKTJ8cVzhCTL2KR7tIfUQ8HFv8h/SRePmEVutV5Sie6eFI+1HWzTuQvTvBZ4UnDB2osoXtTeu JYC0iaRQ19UjesmXASCSGqC4NEMEyr6vldq25qUWIKCsw8il9uL4REzhcR+B8GUE7zJPauIwPqgM H+93d/pv/LqPu/e7jHfNWSEe1iMm+6TcMjKIodIY6iJsFpU3ToEhhbQwpNr9ijJNhp9b/uokRsL+ npMYaVeMGqlipPDGaUNIoS5vXC/9ygBASA1xzMWNF4gTVR64SlZ2WRWyVcOtouYhKll5zp8ja1bK ChbH6JGVCxEPi6RuHUUdd0jxl7JIBKZmRpIn8ZrFLFes3qMUKzWV57I+R6DaIsQSAf9tHRxFAvWI WINRCrVGXxSMUkiHUdqfyAzXWC3xce6pygruGy+hCFONKZ2pVTnSxpRCHca5flRmADClBqgyZfkI nBCsQWApuTZpCwL1ARVYKX5y2hqB1FNS1FHbYLI1SmHuwDrxbRAe5ZcvvlrI6fCXst0SAxhlJhtq sNiR99PxFVPxUyR7KrcBAe7BaKmg8Rl1ZabBIWVqJw1F10+LQ/p3wdG4T3R4710kaRMpD6VTcEgh bQ6prS4nXi+KMwAcUkNUHD6fJb6hbmQKMzPwvNJXfcxcmUQpOC6v+piIh3zpl0rBycbT51jHsMSX mrhNYQgEb2F9Kah3ViqOBfmyvsNJkRjxgNFZyPpfvHoO9ZaWBqMUahVrFIxSSIdR2q/gqA/O/nK+ p1wrcDbGKKKcTeHJ06aU2uoinuhHb17/FMAA9YZTgUu96vDL9uKZTs0CIl6szADp6ChJLemxk9EU RoR64QtkeOt56WfNMutSBEJM80axHrC58ufs5SlxJKwbKeFmfb+3JrG76MgKOS4QnHFtIUlym0uK XP4PJ0bU+FNbqDUPoMCfQjr40/8an6lsmaF9bv7Swz1ufn4YFfwaUuBPIW38qa0uN18veTMA+FMD nJ6J2dFkTAPe48qESzCJC+x1ZbgxCMTu5PbYMtUIbMLrzbAmJ3F8rdwTgcm5Kk7Kie0IVNVKF7rI viB4jyISrTdQb33NpnLzKdilkBa7tEy9J/nHituVBR/kLH7FiLdx72HEp482aqAKUZ3K2hHSnQbY 6rLy9bIlOQDo0tGGlybZslLyaiMC0ZjiRRx+FRPV4LKtCNTkaX4QLxSZyo4q1qZxrmAiJ8nefzuc QyCGUW4SPWb66e9SA/+4j8BvcbXSWNVX6tGZGmpqq81MoICaQjpQ0340Ja7P6l/Xa/WnxhtVU8Q4 h8Lqp001tdVl9etFUwYAa2qIjox1HEMcI2KJt9d2XU/Pbx5CxO6KIM6kKLsYpmqgNvXsJWWPs1nV 4wjICgRETq4ILGUc3aHUEwQUn4vwpijxdARUK8cxFi4KW/aCVueaiAxKIB2co9H8a7+PFM0/HTLq 3+RlZd9C8d0VPYtiPJHRj1QR9k9GhbTJqLa6/H69qMsAkFENUF0uSU4pXEUM8bqirusxIRsQWCE7 QJxMVLyIZa0SlDmcR2Dix6psiSLL/kPeuUc1ce17fJ+2XrH2lp5lldrHSas91QUKCDOAWk1PPVTP UYuKEEUx9thKj9pyK6VcaWWux9VjrVWwPvHRXHyAPHOVIpWIo9UKghURAj4bLUQekUZCImSY2ftO CJoZYTdrzcoif2QBK2H4Z/+RH9/9/X3377P5almSxKbLja99Sl2nuZmXENg2hmv0T+1W8MWyRmd6 H4GTX14bbvvaiwC5kO6Isr3it2YC2CkhbEoRGNgpIQl22lduDglIcv/I7BGcyv/CHcgnAjHmXzLu lBiQIwBuwJ16oODcLlHD15fwZTLzJX5Ptu8H/1wENvocoa6cR6Azy39oDgK/hrfKzEdprqWyiEmH h/UIXKhDIKgtJZPKXkOZEumLGmW2qnWJkt0f3xGweklj6QV8v0zAPxXNsBAY/ikhhX/aR25mCObj z9nn4zUsLtwkMPxTQjL/lHB2BsAVgkO4gX/qgYKzoU5mic+mLuyV+/b/9gbkq6OcV6F0mfG1j2z+ v3HtNDgrtTPtOAJFtKlHk6Z3l8dutH09FBnbK65oCAexlAieIPpD/y0AQhKxtO8JZi/HRXFH5/Q0 AS7+e8jfcIt0nOcXa6HkJsBAHAkg3AAs9cCApsnGhSjiDUvj+Ti93z4ba6WetyjbRqq2F6ym2Zmx FJy1PGWeJmUHu0TBJFl94q/QmyoQeBeBUW2Mon2NskXXuGQXAksrryBwb2SykluP9TREoKANIITQ ExiaKSGFZtpHZOYIbio9Z7/c5CThdQ+zxgn9twEIySxTwtkRAJeIjBtYph4oMlkWNYyaooCzEAic D4ts48P8RuyC6u7TqjraOt+itAazZxKpOXwF8duxzNRyH4XF2zpVyXzIrhM9nv+5/5EHsXPvFVLl 9m/sKQDCwRt9TGQwvFFCCm9UbGZ62EXPPZrH3/uifR6/4u6QYNwi+z8FQEgmjpLOTgG4wssQAw4c 9Ugvc4bZAY8kGpkFvJ+f9vTv/WZeJdcTVGYh15IcIjPtkdcshObSl7yts2UteQgkL/mq9I/Jo/CV 4vAHE0T/uzGoO0IK6q4feXFM4dfap/A1x3B3nBAC2J1YXqSaftJZ4u8aeRl40++RTbNKGBWr5Caz X++qD7BGJVJmo8lXuZjWR2kRqKHLS+Lb4tn1fhz5qe66zvofCmZFC81bl2fUZu3VlNX35BM/k+0r pCvs378jKRNxhYIx+xJoeH0JL8+ce/ehayHn9biWc7OGPI+rE8F9RaLnUr0+6Szhd0mduIGF54GA l8FatWWRwYcbF8+LwltMEcxd+w8EDm9GwDhDFk1r4/OUPY2xxN2yymwEZsV1X45dPtjUStWMhGaf hevYEpX5PFU6CFsgQgxekOgPGGMvAYPXR0meOfco2ift0b6mFTdsSQggeKJ2nWQIHjkQ0T7hBgie B+pIFdOBgN+z+XA/eyaOW4PAjg3RvGeHSwvhSd6znM2lsqjA2IAH38OZ++EeXbnPTC5f/m0TlVls GsTb+JURjSd0Lfnsus9K61fe+qy0Lp69thyBn3fyr9gOMiHg4olAwwSGi0dI4OL1gw17y7H5+mvP 5qvwtNcxzBIxXDxCMhePdBbxu6Ro3ADG80BRqUVg8yraSsbpY1Tt+bsQeCOPzY2E5DEEGrWqHR+a 1frvEZhN9/sOXxYOmh4RKC4LjH2XQNPra0oEVdGb45/2+hduhf3n+IRklh45EDk+4QaWnkfGKjpr NLe0S1WeYSmGUfSCqWNMY9d+xEtKfJ33RnaTsjuGGqaCu6vKixAoymqfiEDLN8LHmsiKtgi/ojfz jNZjlxDYO45/xReLYHRf1CDGkPQISSS9PsH9imxBcL+iN7i/g2OJERiSHiGZpEcORHBPuIGk54HN rpZTxVROAdzI5mYyt2COhhljKthrSGJyjM2qiuxf70/9Q+RPt794ImvT6a5BzYbq+oPYU5OEgKs3 UdRVxXD1CElcvSgxalhcC/a5fI3O6zdcLWAyeclcPdJZJu8K1jDhBq7eSA/sZ6WzhbzXuMVW7Iwz XcqHqqQO34WqyknFzFrdxRJj2xp4YDI3xVAA61Wto+maXxyPMgubNbepUS15jH+XrLxk5dRNpwab xmn3FCqw1SKg64k4FgSGrkdIouuJwvhltomvyKEPJ7780w7aMRaFQ2bjFokJ4yXD9cgBCePdANfz wDDeHJCHwPTxyT511MGdpUMN8urKxQlT9zSkm+tfrsosQaAbxFLc//jT8DT2ondCQNULE5UBhqpH SKLqPeY3at8WZOy1vRn7Ya8OzBoxVD1CMlWPHJCM3Q1UPQ90HBpLLoxau5KJgm8XcCt4o6GMgTuo tFw6htYr6ujDysaxuusNzRZZS6FpNLUy9WAtlVlVvpkrmJo6F+6Vj2pL9Tv+ZsFVUyECdyvlcFXP K7ZchGQ9kePAkPUISWQ9Ibs7ePSUoTbVEEzZB9un7C8+NeQt3DId+bqoiSCZrRfiLF+f6JKKGXiP 7oHwbvOWfDYDgSetikOJ8XrvLllF6ehcaix1GkadbqJyNsP0xc8mMUd0LTt6f43dwP4ZgTyK+1N/ 77Dn6gkhWU+0fcGQ9QhJZL3HDUlG3KFHhmT5Ebsh2YGbeSRCMAG7ZLBeiLOA3SWGxA1gPQ80JN5R CERN6mQSLiermex6uua79VpK+24p3Ge5Qq2kLS/qzJ0p4f2/1U7e8MXTrfvPnhqU+O4d3ROF0St+ /p1KmYirFIx1lwTVE7Sxptkq5dlHI/Q/20foS8q87uDqxFHLoq6vZKBeiJOAPcgVty4SbgDqPe+B ivKLmk2kyZZSZZchZWVNMt1ex9aPtKz/Wl4T80NV3stz4R7t+bVLf0011xVUwgz623t060tW/563 2JoQ8PMCxTWBMeiS+HmPq4ewJobbakLzs5cBt0JMqC6ZnhfiLFR3iXa4gZ7ngdpxialHwDclm5Pf HTrZoGSzmSwzArvHGfMpU1arqgYuLdG1JcBDOvgd9Wps/IMTCMyLRyBCnuZf3L0YgexQBLJU5T4L fvM+k7jlNtvzZnmedg/+nJaQmieqGAw1j5BEzRO1tJ7saWklOKzJMDsAbLLXbcwiBcw88RqlmvkQ Z6G6S1pabmDmeWBLy/KnbDbbUJucZcpSz21VVXx34p6xIQCmdgyviqNGUmZqd8Hnk7sqETjI/rSK uvGfD3/weboDihc8UfRPGgPFIyRB8R5XkQKHA8npcSC5u7w24laIydMlE/FCnOXpLlERNxDxPFBF DlrqYdRI+srTqfVK6/zlCMzwlcdS+rl7uVdLVG2fwMONdpWI5ArktSdV5g7rE61UURmza1uPrCzT FBy9Vb/gN8OUuDwLvkYEB+GFF3IRGPgdIQl+J2xqRc7saWoFO+B36el2+F0+DrZKYOB3hGT4XYiz GN0lPS03wO88sacFM9gTusFU6fAWbpo14dSzNmBxDbPB1PTFK9AcLYuEc1PvU40L1kZY35GfQWDr exa5/gUEBsPwDASG0M0b4JZ8767ZCPxVbk78kPoxnnmNV5lcfM0IHLvocCAGe0dIwt49riuZgrB9 eW/YrsbOJmKwd4Rk7F3IgITtbsDeeaQ/sR36XaxrRqDsa/wvBnmRjtm7zXY0OFF13cjNvtBzMrik qi0JZtrEhwqMXdaVdLrgKDv5tmIBfOW+3+7FP97FB44CDl6wKEHBcPAISRy8eY9LjeD2iOUZ9sL5 3us+bo39Y/EJySC8ECexu2uaXW4A4XlisytPpa9nFYffR8Cf/rXUb4w1EYHhW7UpO+Q18fqFryha IrkQGPXwQQxlGYoALU//JwK1AZCFH2QhMIfu7rDuwteI4M54USiP4d8Rkvh3j4tLjuDS+OX2S+M1 TV7tmDVi+HeEZP5diLNQ3iXi4gb+nQeKy8/wqs70fTETzjuWVfHWmEXcqELqeCibPx5ujY14UAyn 7YXfyX95m/cqtOllnbkdmngLk49A2l1eUlI70zSD7xvXxa63CcsZm7C8cYK8gD/5KITfiQwMBn5H SILf9dUUQSaf0Eu+D8LdDUk4+Hfixpdk/l2ok0zeNaLiBv6dJ4pKJJu4qTqivS4gXF62oJBpMo3J gyfYjQZ5ATUq+QQCL8iN+gQYSOkqmtilvJ7gxcNBsxMfAyYxNDtSEs2ur3g4UvePe1P3D3DjiGQg JnWXzLILHZDU3Q0sOw8UjyzuOKXtuE91V89H4HgVcyrFm3fzvqoH1xBQVPHm3Rgej8BKb0vAaG4C nTYegbb34OFGKjPUNIjm8uS1J1PN5+Fbmshbn2WVtEUklheEr/bDl4vAyJOiz2j/Rp6URLK74jgA WTvPNohY+1T5o/H2UPt4+8WvcJdskw6UHSkuaalOPtRZ+j7BBfVCugFlN9wDteNNlWWZHzOeLViy YRvM+4AKp3dUXjZR2m/UzcWmE8MROHeNe16BwLA481wlO1tVvdhA6SfEselx3Td2TdJZZy1E4I2F 8IH+UjGMHEFd2EmVnsAmKqSAYifabJEYih0piWL3uL484cjlN9tz+f1eLbgV9p/Lk5IRdqEDkcuT bkDYeaC6yB9cY+ZTF3Jp3/7eabg8uvamqiXU5Edfr+RmX4DbqFGOh/6Xqg4Ym1XlmslTN9EHqFH3 7jH+cCO7acvi1Q3YHRkZiMnlSQzHjpTEsesrMQ5Y6k37rLtmH3ZHhuHYkZI5dqFOYnnXKIwbOHae qDCyrppLcAdl9LtMNURMZqIQOKn+CwKb3zS2KKCpQGuOun7qa42iesF4+C4CTEwx15g3AoExFDd+ ETRFD6W20XAnb+/XYPdhpIBbN0G0D8Nw60hJ3LpqQQg5NHjKaN7FO67hTui9s/6Ilx63yP49PCmZ WxfqLKsnXFIlA+/hX/C8Kmnm3YpPuxaBC0XVCKwKaMhFYNvKg/CqsozffL1RnXKIyuadTESh6QA3 A4F5MqiK04czW+EhOTe1qqIoWW0KhunK7ssxpQrrSARmqbnm8Uty2W8QyFRAMzZSIQUgu2DRjgwD siMlgezqBGPwkUNte7I8QRr5sX0M/uIU3JXcZFD/+T0pGWUX6iS/DwpySe0MvOcf4YEKswgBLf9B 36X3q+bNfXQwVG5Xh9Pcgipryry8ZdxzD3/Wp8LsDxA4VMzde7UBgZyFVMt4BD73CkOgdaeSmUn9 8iO+TgQcO3GdYKy+BI6d2Lnw8rJsikBgEnoEJne8179xRdI/x46UzLELHYjInnQDx84DrYuxpJ75 wdic2hTbGYOA4hXuj6zhlEHZ2kAfkO9PUEYjoA+vRSCDNexhihHw9c/ivJsW12tp69xEeTM1yXDD vAqui/08ZbPqsp86vrqQGbQqf8cx7IFiUsC1CxJ/HDFWXxLXrq+wHBIkkR/b0/qLibiDYaSDbScW Fslsu1Bnab1LhMUNbDuPFBZKO66qhQrq++aostrqN5yTfWt782dl+y7qMFX2I+9tRiYxCvaLR0/w 5eHw9YGiRhMGYUdKQNiR318WzM7bXP0Mwez8zd7Z+dVeRswagzG+XjLDLtRJTB/sEl/vBoadzAPh Q1Np/tO+i1NWlESoETjPb6wUpoJtBgTa0yktm1OspS2j1OZjuWv57dk8XwRm+j58dHxqAQLZn34R a40u0+os/qmbaN+rjAYerm5P0sfMR0C2n3ta3lD5d1VDB50xnV3zz0g2Jck8FoFU7IUPpAB+R4o/ rZgegCT4XV+9eerRBSnHA+0XpFR24C7hJoMxPQDJ/LswZzm+S+TGDfw7T5QbH96TjEBgBnyrdBBv Sb6kr8jTAv5CMRnx5tRGr6aub7dQG8fyLxumt49U1siMH0072PWNuiW183hGNfuOwlzWfQPLLCIF vLtAUX1geHekFN5dr948d7b25uKqt3sEx0Gs/9FOrD+7e8gwzBqJ/qN9UjLtLsxJtO8avRl4l/8H z6uOB5Y2ww3sVfKkAGBHiPw5BmBHSgHYBc1/9M8/YabdbDhOrrx3yH5yZRjuFBeJAdiRkgF2YU6S +GCXGHQ3AOxGe97n+zcbzHE4O10/tIS5BY8o2mXb/Q2GJCZDeS5lzsmmHKriWJU10GefJcIabcvc n+j4Lpv36ZXyxtOxv8iqs7gJuZqzDIFAJpn039Q7KvP5HNUNbzh37fSGiO6rUfLjMvYAk3pe1fl/ OdQquTXcItssN75HoctFVpV5GgJ/iqaD4VdUQ0X9Xaram12DD/EF9LswUdqCod+Rkuh3fXdaXo9i /PH28fqLgThuKumA3z1WalJ9fZizGN8lGy03wO88cKNlpO6Eq67IL2p0XXPjzKkd/p3w+YXcaLa8 IW3LRK+GtNwoNhGBETA8Rt2g7io2+WqpV6if6K2/UxIOEp5oUpjEkPBIKSS8K4L8MSF40LLIaa/6 Pdpb2UP6Y004ID0pAOGJ2nGSQXhhTkJ6l6SPbuDgPeWBe6uqe3Qd/KBNdY3KZytvyI8hsAg/YkI6 QHY9JB7BHzBWWwrILkhw/8LNeWeuPv/69kc7LftcvOYq9hSXg2EnPsUlmWEX5iRrD3YF9ZF0A8Pu dQ/8tL8pb7gH9+46egcBWZz5Zmmqd1e3PFN/F4Eb07iYLEaVFhAKr8tatfJadt0a+sFlBKKzYVaj V+wwK0k9aZ1TMsa0Ag42ZXwa0ahlvfUK+rgPe3BSqjkXgWT8L0p0+QwCh6j2n9bzJh+Bhk2D4VYE yvDhvACCJ95pYSB4pCQIXp0AymLfaR1xmBp7NH/yNa9WzBoxEDxSMgQvzFk0H+ySUht40+7jgabm GvsJ3MrmauLay5jppoI2VZmsRVaxWdmuf5FuqCCpsu3PUJa3+KqguTvlLyDQug6Bv1HdZ9MmIKB9 En6LQOcGfM9XgL6bIOqnYtB3pBT0XZBWUB8Jw161Xb3o6GnZb5I/uR1HrSdDMKZfMvwuzEkqT7ik PtwAv/PzQGZRE5W7GYG/y7cHLEliftCZD1rfdjzzMzJjbqvpZtW/TiFwIGVoFXU8or1L1kJfPNnZ /T4vXuvgXrbS8fRoCi8zY9Wc3FoXoKX0wxHIQmDST4yaPUCbEWjiBegK04mA75JNcKflsMUI55f6 cOMNMw06Njs5gFlURz2I72xiP4lDYDkCKVTZiN4HeOfjIO2R4rYyhrRHSiLt9ZWo/xWcH3uvN+a3 4Fj4ZAgm5pdM2wtzFvO7pggHvh3giSLVDIPvKpKmt6uCNCXyb6zbEbjmbd6GwPvyKxFcGi9I0yGR 3sF+KX75nZoQdANEvWgMS4+UwtILqhG2A4b1HEd+0sFE+vKwnYm0dsgMzCoFMD1RTUiG6YU5SfcJ l3QE3ADTG+d5NdEq/3/yzjSqibPt4/PWqlBsse1RioipxVoVZQ2DiBJbqmiD0goYFSFUVKxLUxEU sWSqvpbWhaiUAiqmSgVZIyKiCKRWZFVAEFCsRGUzQR5kIECWmXmyVJO03OU981LzIUc8gQTPuT/M 3/+13b/rMtITL6ilVeVzurjyjc59nN6sJJnCGMyPYFbyzqtPEZGzFwEdr0cKsjrOEND5hzSc7ouj 105H4UmhBCSZw5BVFOP3uehP5YN5aIZXVwIBzfTkHkJmad7lzbh2GOmLYi9qM9vOwY92lxWc/Y8i 8Ku1lJgRNVurxcEW+FLKwE/3uaIqZ/lxWvfMHFr9KZZkGtK80gxbKOiQVZrgv7B6sbYDBPS5swRH gZLUoPycHBx1PgCULMig/OyVFWv3UQtMlCalkGVQEP3l+CZdfcc/AzY6AjqipmahU6AjzfJzGWY2 wFn7jv9c8oJ81UWLd6DFBijIMezFTQ+9N1bshe12ScIn3B0nP5Kbn3w79rWtgd3oc+vz5hKLLWHL Ts56/d51Qdsj3+9bIx7zJr8360bIgm8ao8dN+PLqlCtbSse8kbMloOHwQU7hif2PHhdLrOHcrk1l 52X3z7u9NdnruO6HNrZnIr9JTxVnRCeIcyzvJSihZhOvHHwkfKvldNWj/+fHtkRN146e0kVBXkvy nm2oLXFILotv2ToeSdh5dbDlbHbKr379DsIgc+/1ntsvG9FuXVsr335nVV3tHJl5aPbh1IvT5z54 ndIe4FffW5TtnbBJdPWq+ezd77uVxg96jHpUkJfeEbkuxeFO/Y4Qh1XowkiO/fPosdd3sxhV0pvL NySltbeuz279TjYl6PFk033fWzvSD2VfH7s1MfDt3tYZ63KoV65NHr+zvOF/KG6f6H44h80Vu3Z6 MM40fnn51Gee+9fn/u9pWZB3zxqMJtrVEM1zz7qxbe5PCWPKtxgv6C9JeZIrRe52Z1oGRPl/37R9 psObxxve2dN1xOsmQtxpY2JZRRcZjenCJ/ywrGn3psBPa4XTvy0SV/Bl/pHreTxG3U1259qlF+Zv u3Ou1lMS2RmL9OdLy5kBvJSDWMOVmMDwB0n0XxNQWUPXQ4+Zg40r1vrH7n/dfH/QW5nzwo+Yxvvl hU1OafFfun3nynHjN755eN4l4ROq25dfP7wbwj0S9uHN+6vsPo6H7UR1KT/USA5kimlZvjHMsx0L OvzMC7aMPeoV7rbFT4SsTZ/OX1S1p+qyY3iD6funn3/bkHcXv7pyGfvQqYHErRt7MqZ8vOCRJPOP 07n72lcf8BNExl3Kbj7af+ntsTsujWpLe1jeucpmQ7xv4cD9PXRLoemWj8fvcl3otgb4D4haWz/p yVrHnp6TMTEML55566EtHza4ZI++2AXRqAF5Yudfg1tanD+ansUNcCyf2EDP2LHOZEMTxN5UyBKx llSXlny9fJm/W0Hw8TkZcavaiydWXoLk9WlFhZGrWT6/PQ13LmqYf9A/aEx7Q81Dp/mJVkujvfbl Mhp56XNE8ZamYwaaSo/RMwL/aGqySE6J+fUr+/LnK9OkYvGGQu9RZx41y1ahM8MOW5z0cw+9i4Ye me7iZsQMwHNCJ13YVlKybXF/7YaGK0vr3CcdDy436RQ0fL1/5ZtX7t0+39zkmd9oPG9T0ApPydTI PdLbNZuv51mY51o8WBq35vFHy8ZtXsr9sG1u5E5p1kRoQ9GTxeeK5qPzP76zeznFvyj9wHfmrCvH Ulmc+ZzxoQHeUY2stMeBY/z+M22zX0u1VbGlGVHXQRHLaBaW0cnfLTtLfxB0ea7c9e1HV0sxdnVJ aVDqL+9uOt5/ryua9lZxuM12AmLm9GTfE216vWla4WXXIM6N7CkmMwX+7AunkltZm5qCA7+OasnA rf9vb50T0dBfy1skLtLJyHu7cdYJYQRHnuoQji9nR1FKpiAn2/MDkhQZp+dpWgz3TGlPFLddkizN lkcX0Q7votTKfyzKQKx4nBbL0j7+B6x0Sllny2Dpdsy2jE/creMPJlVT7jUkEtDNKeF4yaVufEZv ab9TBwGt4btKWDRub0ulJI6LbZZ3txXgSDXHtj0AEaf38n/ulRCQ23x+wvYJ2PRebDmb/gNP6MwV 7UDXLkKWFhCQN/f4NUUoY/UUs+3sxXseyz/chTt43JEyGzuwlhuDn3XL13OS+vi8allp1PM4or6n ZKAjurLUQnDa1XYyix3+LHeeBzq/uoW9V0pzx/c9X5NoJZkS3MNfiFEUsdDH4XOWH5NzHAcFv7A5 NQT0S8GEUfJNuKOkXucFPMyigaraz9VZcO0EoKo6kaGqer9IH6y8VbcZrbSvm9DdVfHKRUujNMAh 5wIKv6SZqi7DDWuNBJPISQ9M1TcML1zJE/MI6B1HnHkrE9tCQMXK61m91sgaAuqxorXJK+toz4wj grG9tp4EdOFDsBA0U11zdTJpACnViQwptVFTXLLyVgIj1mvN9FLVfJXipcbvgXQAKPCSJqW6DDPV ZT8itSU9kFLfNDwdPEIuB8t5EY3S3fL0vcq8t7CTKexAs8bKNiIVA5lICrciz1qhjy9jCIg+CXnq eyiEL19sTuvLTsEPrPrLR0CZaHFR7XX63QAuqhMJLmquj5ZIFGZhpQWwowepzOLsFSM66IQArApp KqrLMPNY9iMy+qgHKqqpAYqEf9kDn2aaQUG/qtyH36cMHnW7gJSn2JjI1iNPFkqvE9D0UxyxM+7E FzIUweAnAeAfwPcRtbmoOlYC4KI6keGirnypkR3eyu0muipR7zfJvgMMqQBcVCfSXFSXYWa0RkQk esCijjbAqZWqygeutlufgZ9wDcnU8S+PD6DGSYJkmquZyiq763P9Xtn4ss9ehkq+qlApZ6fRJdAJ AWNZpDGmLsOMZdmPyFiWHjCm4w3vAe+lZTDRMyIE3SioKKjuNJOfj+DKE/JQnqP0JgHNmpKisIFt 8nQ/GZOAKlKSCKg8n4Caf87r5xNQrJcHAcWEEVDhHFYXovjt0xzFb3eqhq6ActHaMKr9NMIA1ilM inWqtbnESt2ls3J/3/XF+Eitp2p8pJJqvGDoU8Ia2qlul4407dTlVWwucdID7dQAN5f0x/yGH5Mf avIaJfVAbb+abyqklB12+2HQyvSsm9GNp5x9oUJwkUkDL1XRcLQeuaFza5gUvLRGO7l+VxUTuWsi IjXTJP93o4egx39oeClMGl7qMsz01IhsfIP1AC81wI1vvd1ZfJTXyUUjBAPnOgT+SBuzkdYq5nfT q4sU3lDBz0LKO5Hmn/3cYthWaMblyOlyj7bVW6XLBjkVRQcI6PrqSBMC2ndRakZAozeAhAJrQUvt 5+p8MHR2DZOCltZp7jtZqaYMyzRThrWfqGwi/75RM+iMQ993gkljS12GG3ByHhGdvPr82sIApwwL bM/FYM62fr9LV9PqQv788YPWSLMXf6cGhrBnrJrMPThx7EdPstLTRGAxaM02aQckMIBHCpPikQ7h GqM0S3i+Ui8YqQw3Xgg4pf3Qs00waSKpyzCzTSNjG3ogkhqgbaB4Kp7eTkAp9/E+RpzYS8x0xtyq B84W8NOQNAlf2I8UTphME3u8i7lwYz1MsS+KCWh5cNsXNwjIZzutLkHCuEvrf63oDAFdmCA2xb4D 7haBtbikDrrP4dAZOUyKS/p351hY/RLfW/zbQnWKYWNsCzqlM0AsJLNy1crtf9879AAmNUDv6Jtt Kt5jizkR0E+8T34jIMZFAqpjSj7Tej8ruvq2vyX3RL4rzWmD8+DAtyu9Ec6um6pvfbm3cF5vOi0B Y3asRByl/Cpg/QrWQpE6aDe9YQCKFCaFIq3RUot3kHIXjzv9pbWsC1SvH6lcYewCOCUARQqTRZFS 7YZre4+MWl59Qv62IWYkPAS9LFU4xUfdBLTHurqoUJGHPOg0lXP52DOem/L2hTUrg4ayCWjgYs48 hjT9AJ7IbFudaI35/q6wGR6aURWLpz1GUhgSRo3J09F9r4H1orV9hKrziAISeFJI0r+5S80KDUSu +LclKne5NRZYwNJQSXX1QpZKSrUbpj0+Mu6iByqpAbpLpyMB1X8rkFC7K/JvEZAiEsOXuaJZOTSM cZuAYpbL05PTJSZuU0PrkanBxTYneK2zBw94TfUu80HHq9xkv4Rbj4dSlCYDDsMcAO1xGIAihUmh SHVyliC1UJZohLJKHYY1GbuCTjn0HSWYLIqUajdci3xEchY9oEgNsdTFzeKjOcpWuNJYIqyr2MoC V3XnWKWxPOW5SDsVxkLLoKiM5Wzc3WqJb1913w0cXSFNIKBZRQl4PNL8GdOb1saoo9WZysqZSwjo gWWkFQFtDevjYNnAOjGsRSp11Cl/AUilMBlS6RA2886S6R2znouC20+8Fz/jSmvva1BlNjAq06BK devEZFGlVLthOucj4zJ6QJUaoMvUVxJQLH8tAS3DA3NDCKiN1UirQ+LnrOVL/MTVfYJ2kx1JmIUb M/brUCQpuBLNrOL0bZWwfXNYlHqTjc20tIm3CxCfWchJnD2L205A3IMpEn7HE3Amo8UiddCVDCDv J8Ui/bvhvPZyL5y9nboZf+sdYI0MwCKFybJIqXbDNeNHxG/0wCI1RL/h8ZjoJU0iU1VUiFTUvchj 5knFCrvxepHHxN3lSVYo7KYUKXCxTWWi54RcYTQBhYcwV/Db6Aq/scSft/V5YDlxdyj9VcxPkQcu wMuzsBan1FEnWANwSmEynNIh7EZbO95qjq/Q2A1wSA2o9C/aIV0EGA56MjJ28+qLAAZoN5xGROLf iiS7ok4enXx5FqoQgGRSkliAM3ZThNHyI/7IIinSfUbySafUto6AIk0rzJh32FzZU/bneRm4Y+tE Mbfk233NOYPVR31kCJ+f6N2F43iYV55MBr40AmsIqFRHnXIAgIAKkyGg6pbPVJ0Zd5MX/fx3R/3Z z3/fqB4kHEA/nywCVQXP//erZ3pAoBpg9Qxlp+Cp7YiqLxMjpom9HNV9GW4qAaXt5qoaMw8IaAvS Zk4TeqBZApkfAc0oV7JSYncSUJNAsthL+oU8/X5cju1G4OAXTAX18wH8UpgUv7ReMyj5x6dKFnaN VtVM3c+/9hS0LA4G8EthsvxSqt1w/fyRmJSE9cAvnWR4OimV1uGZHQSUQsOeZSCZNFEzIt1BQM0V 2h9ktYhMpcewwGuc8zSRh3jff9x+IaBUSoNJymSbU9/kb//9NgGdyBBI0pSv4NqZhmxK1QEnwACy KUyGbDqUq+zQasqo+/0VDcZzAad0AvT7ycJNVYj8f99W9EA3NcSmjG0GBU0VMdGdgoGLBZWdY+Vp EXHyxDxFIuOgrKjNOn1OkeZsU6Y5fLyRgEQe3gS0jHJsl8JSCAhbIkKESagNASkHj1MtvTAqe1E3 vTmuEMilg5208n+d/74BgFSYDCB1CIdZq9X3r1H3/W8dBS0jgZ0AfX+ykFQVg+/f9xg9QFIN0GPO iU9i3iIKuq564GJq5EYC8pFGyeNzsGdpzNX8erczBDR9tlIxSXi9QjEBu+QJtO6poUgTH6NXEVDM R1irDUfGUAhmtwBdT0AFB+5PUP45SUBOq/m9vspXcISmxT2l6qQJAO4pTIp7OoTpOC7QJDPu6hvw FU+MqYBjatCnTjrzCmTRp1T7VzIKoAf0qQG6zqN8Hj4tQKETuoUiNDt1xSadgH40O4/UlhDQQIqN SRoBPVkkovRl8zFhZa40AT/XRkDlDQTk0MVORlJ3I2gY/9Y1ZipXFMCUJ7J6bUMCWgvLwXUzLRaq 7nUWAAsVJsNCHcJzxmnaNJNmqto0t8qMPwUpBpD+k4WhUu2HGwYYEcvRAwzVAC0nqoEiZqUi5Sdp s4b+9gGukEeZwocSKN1TtykLAa2R7rgnZ+DoZQLK5aMqV/KQlfn/qPzzwmaUr0DVaPClVEedIAiA L4VJ4Uv/Ps6scBorjdOor89XbjaGQcfUzAboOA1ZfinV/pXMBuiBX2qAvZoOJSUiV5G4tJYEt1mf UoJXGhWpSow596esEL6c7o/gnhvZK66xY+UBDOkuiRmrln+ogoCWE9AHXVJGz26mUNAaEEdAgZW1 BPTMPIKJ7QfnNrBWQUCbSQ8D4KYwGbjpED7jqTVMU6PednIrBNjcBMBNYbJwU6r9cPMAI2I0eoCb GqDRpIh5uO8CBu5JQHY+eK7yOrEiGivntr/BbeBLfMRMiaP8ehjyuUJDipgsmVNmxhCbStyY0k3y vTpv++yxOd/v/8WzHKRM/QUeCdAASP9iNAAAKUwGQKqb0ngrbMb75Yqg4hof9SWycUZ3QWfUSFun akGWQEq1H24iYETymVcOIDXIfOa6NBY/H9YtXaVI6t3f+Kef+rbS2qhIcg4mjIAp6Ala3Wq8r9DC VLKMIswgoIiAHwrfjvgALBRN7m+v8xQC0HcwGfTd3/zlvdnxL6rNm9QrT26lgZbLwVrkO53+EVny nQpI8wrM5dXn/QZZOKvEff2ZmKv8YFyjrcQ3DOnrRmcx1/LbfOsJqI5fls/qYsn3W2NOoYImgWQM Q7pZyFckL+N4ffX32CHPaC47Kady+BXqr38wFBeQTgD5Pgk03l9pLzU+mhBMvfgkqchoOUglGiHr 4AXIcvFUs9v/6CYjohI9cPEMEPYytp4n9us0w2azFI6wUJqLp0euI6BzRwioewllJb+elcFUVcbC 4imVqQTkGSyr8d84FhUhdeZ4n9nqvfJ8bl8JUjgaKA9tJJ5OygxA4sEkkHhDpSlaCvmzyV8E2gcM zwU0+clC8VTjDP++j+gBimeAPlIt7SUg67cy8UT59WBsNwHFRq1U5Ox4YA5eoMhYbqQjKYidv23/ JZyeiJ8QlJnRsUza8Q4kOQ8drUjjt3i1XhUIM/9L3rmGNXGtbXhZ2y3Wtrhr0dKq+EmrFpRTwIkn YnWjtmpREYIIokWlLfSjliJqhanbr3V7wOBZtDUFVOSYIgWEiKP1wMnKMYBaRQXkECkSEiBhMusL gZqZymqua3ZKfuQHVyYzf9aPvDzreZ933UPu2JxXHXRvc15VCHl7IwS/HtV8opvINEgegzs8HQHJ m84CkvecqPyLnlqu0BZNxnqzdMQSaYw8xuaLLSNPq55/v6wYAZJngrJSCUFUMKF0CWzwEbanHoNg UgqZ7EG5nIegXiI88olc1PAzBEuJAa/QZaEj62lPH9IeIMw7C7LeQGJCr4yC/jx/LfKk5QxEns+W rufsNCh5vhHoeiYZrtQqvdRru4UFsYpsypPwdp0smxLxuUZWQqrMd5N7/Xt88FFC6nhJQSYEmQnt MyBo3ke/LfYoanW3zZyd0qY8fwuCk1M1n+iCoR3lpzeJMQRbD2PF1hsgwA+gBfjW/QH++eFOAy8T c0AE+GzhelrKx9/f8DICXM8EG17Nl7LxpDRqN5l8VnWPShKrJsvSTkrDVUltTcKixEdPXYd4XH+w /YWEvZe7X2qSllXHo4coaai9GQ6MH+DAXh1jhdrz/BN8mFkM1n2j+T+Z3UUVw8DZPMYWtaeFePyl fBiCPowZAbVnaYJdrRgyQ+M47pFFRwNlt1IpYXiHzSph8cxsVUTtzdy21q1U3Cz1HGkaVS1ssSYq 7utunc1oEj/AJzanqOy6rQpyg1z3Xhommyo5kcFHlQtGA+4xwBYYAriHsQLuMY9P9pJZ5498NnK8 PqVv5LhzuCNqkTMQ5cLWvDsNRiSPGYG4Z4KRvNw+BYKF07aNqcLjj+aNkPLKin1DXU/Uxcirx5ac zYWgB/jh6m/sCOoy8u3vGA21x2WUAQK1h7FC7T3vOrxpSXtBf9I+D3UUEkOg9jC2qD1tyf/trgMz AmrPBF2HWJFMeUYEqTypeWnqzzRmw9+HOoJHJxM+RAO/ijjjXz+l9k5dk8KqOUNmjQcJ4ivxsyUF Ueo0V8Fy6iRvYqvANmt2Wo0sA4LHxTwqWPuJLBg6bo/hOhC4PYwVbo9O9PawnvBpsNnEQ6EWWxSc 0KX7llj4yrYOKR6CGuTCdKw9RvcKY83ac9IXsc8wSLUMvkc3QZy3fH8qGQvBUCX/dFhIg3m3VVGe dTI+Bb9MeV5uxJOiqBjf18JV52qbj/R/9ROQ70KQEq4eP9AVcr4eo5P2GJsXBGkPY0Xae86PWD8D 318r6APf5x40+w2xRh1njxGOYKw5e076QnaD2BEjcPZM0I6Ye0LgObNLFVq6TaRKrCYqTu2U4JKP 8qjvFeV4EKF4q1beFek28KVk1q7tL7f8cPXSS2EfPax9IcPrs1//olJmoCoF4dxZMfZobaz5vZXy 47L+17jvPpCjfY174ndmX6DqRFfLGOM+a9uuJ2Z3MsRrGDEj8PXeMEFFuS8iwwiX5jz/bmlkUMU2 or2KrLZU7NzDq/C5UJIydjl1QnIjYu0jgbwqrZiKJQ4+IVreVtppL5E1QcPpOTBrAmHPWeH0nlcP XS9rhLaXlbTNbBtqibqyZWyzWLP0nPQl6wYRDyOw9ExQPG6pqiGwiUxU8x6PmCX1JxNVCXIIjk9t S8VlCS3CCmptbm1rKHW6ljqFT/AL6cyBYEUIBO68aLvsHl8IEjEIEoQFY7x/N78Stv8Bqb3YmCI5 gRzWwugMPUbJIBh6GCuGHqOjNVTb0Zqve6XvKOvFfXlIAepAI0aj6Dkx7rP28vqydYP0tIxA0TPB npZifCKZKK3cliBLEC1vERadynnSVmdPCTosSgJxS1yOH0/7elZ3MQTx5PVg/O6rf/whY3VMh8nT vpaH9gDh11lh8p4Tkvk6skTwj9o2b+4i1Ew8pqPkMW0Ia0oeR1+obhAlMQIlzwSVJF5RTXlaEuUv C6r9lSs3QrDIhueHNyw/qZ6QK2zdRJ2p71MKD3Uar/KiUN6hfKEFz8xXHTuklZYAcVr6vWrv36Vz AlMU6CqhDcTTB2kxBBAPYwXEo3e1Ri2e8GnwJz8GxkY/q5N+LH4kCsCK0Yh4jDYwayIeR1+UbpDG lhGIeKbY2KJiyZzaYXieRbN6vjL00mu9COMK1S5Z4/ZxlNzLyoNaLniK13tHuCsX8K5AcGCdgtfw JgTDKLdYCIYTTbuo/anm3Ush+BdPHvYJ/kuI6n80OpOMrhmabWcYAAQLD2PFwntOWYbSAveA/sD9 GzPUIhEsPIw1C48zKIG7EVh4JmlSesd/fWubIMjfg/4i5WXWqk4e6h0SDhPeaVMvLdTOCOeWtIZT Z3vVB3fwC+gOv5yWTs56wPemxj21Pe77y2N06EiD43EYGQoCjoexguOteE5rTuu0pi96z+lC7skQ cDyMNRyPoyd6N0zLywhwPFNseaUIG6pJ/pn1ENgRj/JsJyvDILA4IIk8wqsIaVg1jt/soZ5Oef5x wwdXjICA4MV8CkGlPUVSGxIgWEb0dCiPoWuE9ip5RjCPYOJhrJh4A6iLrgUW0Pcu+VwbFGkVoyHx GOrCGonH0ZfLG0RdjIDEM0F1+ZWqqZX9nK1y03iW4BClz2r1xAw8CyNTp1EH/Nw7s6n5J6lTvPvz NG6FkI2tlbdTMo2JSYUg+rFGUwRd0eJhT9t2+O3sVZYrvcoyKcelEDn/iNF5eAwLg+DhYax4eH8S FaCL5ZdqY/ncUrNHqAXqKpq5PtYuX08sbxhFMQIKzxQVxYMM21vm3l5l78bL985QNcomp1A55G4p Lw2fuC0Hgjd5bQ2hlANeW9RIrtWICVo5dGC7Pw0CI8B2GCuw3Z+VY+hiXfBe0xe8i4eiTiVi0xHB O2uqHWdQgncjUO1MUDgS1Fm4pOMp3lO2EoKsEtWlSHONl7cRdt6GgF+ise5tbiEQBJkr7K3VjkT0 NAha11Fn6vGzmOwlQp3Cq7wokN+g5oo97m1OyG11DytIc/vSFl0uNBvPMCMIph3GimlXrpuAvLbi Ss3lFc+mH2v6DrknzzX7BlUsiPSdNdCOoy99dzREsRgBaGdhgsIxW6gIsFVNI9PW7DpEpWzA3Ygj xaUyXLJP1JQty7GA4Npt9Rt8CEYFypf7k0uFZb5SvMExkIwJ7Ll7bGatcskqCCatojobbmVTHqPx wqN4Xg46TqGx7Ji7LATLDmPFsnteXHSmpD+XrzXbgVoiIpdnzbHjDEoubwSOnQlqC6/ztmolXphM 2Ax0JVanEJW/CZsxmS1xp1i9tJA6hE/U3bS7VRLX1iQsEM9y3UvE4ROfPFHZUbvJvft9v6xD78em o3J5BMwOYwWz+7PAzKMd663pO/AuXoDcj+lQdsz9GGuUHUdPKG8YiTECys4UJcaqu+IWdQRvsy3F 69xnqTwhuCh6H4Ko2W3NfEqWJpF73rm0R8wv855GfQSByidbXZ8yGoLJuHraakrmNQI/RFBHNcZ+ K3oXRkPXOTJ2YQh0HcYKXVdGCyBDORpdGaGbgty9QzsFKZ6EPLyIQNdhrNF1zvpiemeDFMngG/g3 Ta9ImjRWZUy7BILCzDIIgu3rkiE4FBRP1fjnazZfk8oiT+OJGhvjniGLUy+CYIUVJQxscFMdoE7z 1K4lRZnbRDIOFePfU+qTx1daQrBEpG6atiaZ3AfBWT4lR4cpNJYdh7EjQ7DsMFYsuyraMfhRI7R7 slBaEDmq7xh8sQgFjsB0PDvm2Bdrnp2znuxeezL4vy+ewXf8o01QYVZDINH80o812JZprL0Xh/I/ LHIj1N4lysgVKQHqkX/87RRQiRsgOJ2tfjKhDoKkVXizxv5/bcaFoOWov2oxfv8XdKHQYHbMQkEY fRYwO4Z1GTVnRG+Z6CbBPj6tTR3Fjsh9GI1nx5AY1jw750GJ643AszNB79KWW6260NYkaPTr8oGA P079T1J6SerfUkfE8X4I9feCoMGtEoJYUnpClQ2BjV2C2rzRt1pCKJeH8ZrwmdK78mBqh9/XkVHC UltRSFmG6qXg1CPn0RPFNL4dc8IFwbfDWPHtBpKWH9c+25ala7dlxauQU2E6wh1zKow14c5ZX1Jv EGUxAuHOJJUFl0wtacadnr9I9y9T2lqorQ72Xrzr334MP4Pn/6IxN5bhKj65/dkddHno/IADozGL ANlhLEB2Lj+X0s7OL+s9O3/Zl3Z2/lr/2fmfhs9HrFLHsmOWB2uWnbOejJ5jEGtvBJadlQnyh1wJ ze/9mNq/KNddBMENzd6KL0s7JIWgPQaXkEnZEkIxUSQ/nxyh2aGtsIFgsc0ft7Jc0yBI/Gq7n9Ir X1KrsBPsJWxqVGLqTFl7eIPPSgisflC/zKsr/lBY10HELiS3fupBRobLp0AgQL74AaNB8FwYGyAE BA9jBcEbQHE4uvTyWh/DvvgAEkeBgOBhrCF4zvqSfIMojhEgeKaoOGM0vmQ0BIuouXkvaWzJt0Q5 L9r+fVwVGyIX1Js1dh/cj++eovnYtbDd0r/Cqu3z+fHd+0TNgq6s2DJyAV+e33MXjS2iQe8c6AXC RUDvuGygd/2SM/Jqwc2xi956+/iQwmc+n6P1+VenD3994AVydbg75pQLa9yds55k3zBqM/g2f4jp lUanolV6F/lyeYxGsGP8drgIgh2XDcHOaeWzf/2cxc/96+/L4nPTUUNcXIeBDTqXNcDOWU8WzzGE QecaAWBnbXq/7997aY4W5MKGEbmqe9Q5frvVYTupNFwV638tctnFxiS86HyJ0mHM9wp3pVdv6v5C x6lEjU8v5tVf9rtvVZagdkwWX1U5Q3DWJXwLvkAov5EkvGtOLY9YWOfeU+PJy7Ii41SCG8Kun5Lw YJ7STWEVxWtbh8PSTKVQPh+C8V4Eh/oPXldU/RgvMye3ImN8Lo1+x3VhPBjY2XNZ0e8G2mfpWsZ9 QX7uRbN7qEUOTL/jsqbfOesL8g2xzeIagX5ngtusNvyhm7Ccd1Nc2708UC7osOui3liltiYL6qL3 zzCri072JMMgGE25+YjqRN3ZMhsJPg6/Thz4i5rQofAYJ4W5CBQelw0Kr5yWQHI8tA1iWkn0HZ4/ L0aB6bmOA+f0XNYgPGc9Ob0hEkiuETh4L5rg7qrkCVFFbWgV3sZTyeK7vPMQrEYfMOHqQHac6U6M BwNbbS4bkJ0T7T0MN+dpu1dLnvWuKvto8+JvzGpRaxw4ceeyJtm56EncOYbgPnKNQLJ7xwR/77N5 dU+ok8fSH0JgFSj/LU9g3t3DO9vwGIK789U+CSphtD1G3bFqkfAqyR1bic5SCLwSqYR6M79RShd8 qHJZ7mTZZ9QwWexX7vUS0ryBT2SNIeNnCuTJEGxDf/GHpVcgOI23X9+pcfkQ1O0dRh2AIB8Z0XNp KDzmbguBwuOyQuFV0cgs/bstD132+Fnf6fqb9qiuFlcHw2N0tbisYXgu+hJ6jkGKbfCt+xgTtDa3 yU3UATJZHNier1ooS2sV5ls1WxVF+bc3vEXUFbng+YdfwRVzNXVBqB8WvAlByw4IPsB7rkY7QiAZ Sh2EoGsXsu/LpSHwHBl7fQQCj8sGgeckoVUIZ9SET4PXJgXGPTsT/FlfOn/z3PB5qApxGbhCWGPw XPSk884GqRAjYPBsTRBd1IgnR0HwIe+w/Zpw1YVaebxynu6ebZtq8gMR0ST89yUI4iJHlOBZ7u3d Vs3EzYtdPes1AraDOkkW6+6mR2qkZopIzVNW2UvwBgsIEiCYeV0lIuMIOQSNGhEqV3VBYPPRXuqo 4oyijVr5wxj1NOliaS2ZONNetboK7wzpaiQ3BUKwEYJIPH90/w20AdIx91yYvWUEc4/Lirk3gEyN 0sX9iX1x/81AVJ7JdRo47ueyxu656Iv7DVOEg98VMEWZaqI4j/nhC9uFTuJc3j7lYQhum8sPQbCe V+6ujtZI0kLKOaaD/Jb58Rc1QWsKMHrSCKgelw1Uz6mC3hXQVgRtttKj7xi+eIPZA8QiaUg9hniy Ruq56In4nQ3SFjACUm+q6ZVECy8Lbz9eW867lStoFZIbMbmgIy2+R6MLllFqa1Ka04S3YO4QHJTg F9MaYyE4d49HLfakZOJTu6j4ryBQTuP3FF2jbgtlhwu7s2Up7q0xELy3RLgXt9HdFU0R78PluyLd GsZsElDRbQUX437X7PzKxynHwNLgEkXg29QHVl2HbwtbbmHkQV7bexk8yfchynfw+15j1HNrG3uK R1A/hnSoG76FYBmmpGTIitQB/Vx6/zPTHiD6FmyAfo69jete1FK/RlkvDqBZqaS+Mc5CsxbUGhF9 C9ZAPxc9AwIY/ag/l31FDnbj4nWwwAQr8h+RC+7c89hYtGO6Q7hyi0XlK2RUZu7ZX4+8ELy2TfbU 9pyl8u2gsKUnbV6suVLb8MDzu/ptD0Vj37S5+uWcL6r3v2KxLmf8haD8f7ycEbSmat8eQd6JnQ8e XlPaTs9s/aTgXM/tc66vjXU/yHxoZx8b8UVyoiJlf4wiY1xNTC/ZbPSFPQ+aX6s7devBf/nYHpa2 hrbnuwW4L8p+sqH8htPZguN1wSPxmM053XVx6QmnV3c6NQdYeqxfsinLjHdT7EtuKvOuKJ/WY/lV +r7E85O4d1+0erxmtaTjUrpHzCctOTmWU7dOcM0/3r1w6IOL2cmNER8nOJVJQr908pbNjRA4Pt0/ 7MrWEP4t1fWPNsQnPa5fn17/Tc/4gIdjzf/9nS1n8d70K8OCf1j7z476KR9nOF8Qjx25ubBqiJXr PObDaZFCxSzpQn5s9bqs7z9csnN95v+d6gnwaPdR81rCq/aL5qdd/Zx7OOYfhUHD53TeSHiUqcIr 21LHrdnl992dTe85vXqw6vWvW6Pcr+OwrMFfnXbpPL86ufkREZb2Ts346U3lzZO2X1IUET1+EetF In7F9Uip7wc/zf687Ez5EmWE9Ajemasq9F8jStijrrpwaO2Wu/GLT8fIeqpa7y18r7t6ha/fkZ0v Wu4MeC115pYo8+Ors8PGJtT5fbBps9crIze+um/mz82PnF3X/e+9yi+FUWHvXr/t7fD+8ekOLRUJ /ylVfpuq4KV5HvKPa5zTuNryYtCwaPctrkGrW3Df5EmE2/+Td+5BTV1rG1+f1gqlLfa0yvEalVY9 olBFIFuUWGmLFhArIKJCbKniPaciXrBkVzuOba2mykFExFSpIBBINSItAttb5SpREVBsiRUCBvQg IRESkr2+hKjZUVZzZk+G/JEBJyHBmfVHXp71vM+7fqtqR9U59221jmOPPf6qNv8W+dviQO7eo12p 61d1CMZ8MPueKuePY3m7msN3L5PEJ5093fDjk7NvDY45O1Ca9WdZ2xLXlYdDi7ru7PAfLXNc98GQ rd5zfJYi/wO86bZMnXLTvaMjJSEhLEg4vGnvuvdqsdODzjwCrBmR+Uqvn6MbG70mTsjlR7qXDav1 F8R87rCyHnBXF3FaOfPEJVc3LgiM8CmMPjhVkLSk+cqwirNAU5NVXBQfzgm58GCbV3HtrO8jol5t rr3+p8esVOf5+4N25YXVCbOnth4e7fhqV33JAX/Bij/q60emZyT8vGZa2ePFWWqlcmVR8MDj9xp6 lsj/FfvDyJRlvptvyTfvm4D52LEjSdHmEb9suHp1w8dPbq6s/XV+te+Ig9FlDm2S2o3fLH7j19vX TjXUBxTU2c9cHbUoQDUufof62vW1F/NHDs8beXd+0tK/Jga+vnY+/z0pM36LOncYWFl8/+OTxbPk sz64sX0BI6I4e/fXwzm/Hsjk8GbxhmyODN5Tx8n6a8Wry/777tpljWLnK6OdYHULQ9nDGjl6f/rX gSf870adY2q837r3W4mWK75aEpX509urDz65/Wg/680r21y/hIAt6jh9u3X1K/XvFp3zjuJdPj3G 4V+SCO4vR9ObOKvro1ds3NMoIF3+t5dOtrLkP5c1qjD1KPyf20nOEVkcT5M5fRu5gLuHcXUMntJc EJmmc5wBx1gJ/OMlHXv4zap09WnN/mLWD1sZNzXfFQtwZyGvcXSJghjPyWaUtjV2l3ypdSsl4K1q ojtNzLhdmwrB72O2kVfPtpOTOkueeLRAsJTwVnFY/M7GClUSX7tW0y4tJHExz605EldmdxKHOlUQ +Mwikr8cqp3QqV3A9f9WKPPit8bIl3+Ezy+EIJh/8LxuL+P8QOvW1kl2/KV5bys53e+Gml3Xom28 3P1Ju+YLXpqCEIp7SvY8ToI1HVe7WvZXlIyUHPN2G8XhbnuYN9NPPkvcyN2pZvmSux4vTXVWjYnu IOZoGbrN0Afbpi44oOG5d0t+4vKuQ/BT4dCBmtWku6rG5AE51MI0klX1noH6DgKtyqSDVg1+Zh+i fP31TG7nKAqTO9gwtHXG2U6AWKQRrPrCfoV269fc0JYl0ERMK4BVX7O97Uq+UgjBP9xJdmWOdh0E V/TntDpd8KUQdDizpJqKatZD+7ho7U63AAh+eQ9dCMbpLqaJk0bgUpl0cKl1xuZSlK/DkDVfvPJO QFXovRpxpcc0j7B/l7UMAleC7EegyoCS05i8Tru/a2a4a5pFWktWgKW+YXtlcA8/F60RxtWpt2uy d+p9b1EbW9Yizx3cswov78rBM/jl+S668vgsAQL/EfiD0L2bCM3Hw1mK0xnk7iUvvIWsEgoadZrJ EAoCjcqkgUbNC6HUiE4rnCnMx2DDVNaJYrtA1AqNUY3pAmn3X81MZU2zyASkFcCojjZYJMQ5P/Jd RwFDvqZiF3mH0f2jzy94WYarQ88X+P056osQTDjKU3qRHoQsTLcXnBuJ/gF5LJFJRaOaKAkCjcqk g0Zd/LxGonpDCtMqMQxqna5D7qg8EINatMmoHmYGtSxSJFYAow6ywcGVqoq73m7rH6I/4UaWqfsL Hx9Ej5MGyzTPOJp1+/rci7dLh5R+8myr5L6wd6skWmiXg1qhsQZNVIA2zNTTzGTWNItMZlkBZjrE 9j7gnSwBW368FZevkpQXitucNKfi+JrkfLnQXf07BJPHZOhkYIMme1kPG4LyjDQIygogaDiU/4SA IDHID4KEWAiKpnIe4brfPsbT/XZb79wVslwoV42afBoRxFMmLeIp5faSqKiYXpftazw6UrnQcGrw TdS1vExPxHwVbeapp5n5KovcXsK0AvPUBm8veZJwgTyg2VsfNFDtJ3dbM8tRxij9wefbbmfHEz52 lx/wdm2WoXtMRoSpu5fJhgiBMGXSQphep3rrmN49ke/zHZH705tIjtrVoj7+fd9EwqRNMfU0Mzxl kXvfmFagmNrgvW+d7bmEXNjGl8dJuk62SCJwKbuO1aQk2v3FxTptKCdy8bI2vOHQMp8ErrNccC5+ gsZPGr5eHdjNKy/eDcHF8HgHCHadUTtBMGglslAo9NJpJh0eBL2USYteWm089qQTirF1t0sXPp95 r1xiOGEosqtDrbHvi0eYtPGlnubmm7wsUif9769H2uCQYaHbyQStl9uyS+pwVvWmpz+Ob4p3evZv 3IpN3ElLRvG/HzZ44v3c7KxWdDFQRptMNiQILimTFpe0D9UYaBylWHXCcOfbIhTdh2kkk5rummiT ST3NzDZZRjasQCa1QdmQk5lkdjMEGXdIRViSMkjJ9tL6iLtOFBJZeJaKkD3Bi4aOYin93tZi/EQ/ R+2nVyBYEC399DIEIV+yqpNVYbdYTwYUH4fgl6FKR+3XyNtFmBQ+6XTTzyHCkdPik76sHHMoGN/K p2CSNfYzUavsG0zCpE0o9TQHJrGIdliBUGqD2qGY4qjc4ab1gOA/wrkXIAg7A0E1W/UJ5fXc/eJr EaP5Rwq8WR4rvbq7vlocjPO2/t77NJRfSQo7s1nJWnbLYtxdTVSh+1cUJul0k8wbwSRl0mKSXqdU i6/7bIexa+zffXYdT2XlO/rreCr22X+IWCMTkXnTBpJ6msu8LVMr/W/H37JFPyLE5efUOp2Y2A7B DhdxcZHOhdxtc9TwCe1DoY/+6IULR8CScyHoOiOaGabO3k2msqXhqS7a0Es6kRHKBVWJZNZfeEaY Kuy6w4NBigHoaqHcQDLD5COKsO+0wKQvacv1ReK5Rm0xkE8q59rPQ9UL4vATbTSpp7lbSCxSL1ZA k9qgtrS5Q1DzlUQ1o728oBIC3T6MDPSW54pY2rBrECQs0GSnZ6scfMZtrsHHRV9xPSJsmtK9O2hc cGmIfEivlnyj4teQmxl6iUFvwpiocBzBI2XS4pGaOBZ3Q6EYgYuVcw2FMtT+Y9QqEQeUaPNIPc0F 5BZxLFbgkdpio4ufS8hF+iBcLyxxLlVcfXtL3DZYLywPhJi6TScsLAGjV1hOJN0Sq0IVYsVlUr5I nQzB5OJk8jDe8Ak7mCUNq2ZVO/aUsedBcHd0vDME62MVPO1pdJeYgit1N2l+IXClTDq40j5k5h/z JrRMftwa3XzkcPjkX5s6B4CKh8hdGYVWatIlpk0r9TSTm1tGZaxAK7VBlampgCCRWA5BILkibxME Uk4dqxo/PHU5oVqmFCskzQ4xadqRPuzEjZvxtOgKeU4VT7FexQ0VcRg1DqsaWFnDrhXiIZPxFJI7 md8MAf/7DBXRch/tYyg40ummJYNw/bRwpC8LzoDSBc+ieC9DFF85DnkqnUIjNS0Zuqbfy1wUbxG9 sQKN1Bb1Rihky88ajUxVcRFeXv3Mx8xUK3VyE/TMxyTdEqoW6eSmBC/E3DLZ8pMyvmw/BNs2sRcR Un+d3owmH0sVflpR0g3Gkyr2h/hdDH1ylkIqdadu1jAEqRSjQyrtQ26otRPSWzsV3fZz+l4kZqSV vlA7dJsAXuaYJ5aRm/5vAtig3PDqcFVEE57uLffwayM0uXJdAahGpCklZNh2hmy/Zl8E/pEabz+u mtumdquGIN6x3Il9g8vvecBdmC8g3ZuGKflXv9rVIOoW/xjSgxNEavAjkiRjg/J7ev7mxIgRg9p7 HTrlw9p3OwCjg0E1bZ7FzH577Jrjz0koGw0klAI3VEiJITCoGG0Mqpe5MN8SdYNZAYNqg80zOTeD zGzGe0OZBCVLGeRuCGX4mRBkbef3pjJ3IViHS4ezZH7yXEnPMggmlek5KYlbIKiXqD4OUn+qyb6T JHJbhZz6wt5HhPkYgmGK0WKY1hinJG8v1wPsrhubZn8YwvzzXXYtqDX2HeZjtBGmXubCfEuMSWJW QJiOsL06KVFXkzktEGSwtA8FeA6rtQFXx0DQUE59I7ex1VF9QLviPO8Uq9VPueu/Pj9BkMmodcgY 5Xr03wVfXroGwRGBRJWlf0S2zjAj3HSGCTUBQ8BNMTpw05dEZdLzoH+jIegvl6KyS4yCNjXZLtJG m3qZC/otIilWYJvaYh7jJmDIM1vZ8i2SrjOFFW2DNVlxSZrUfJ2Hma5vpk0+dlLncDboHQ5B1kHQ 6hcMQSDjwFadnECgndeKy9LkrhDoJ44zRwdpZ3A/avdvSCpCEumwaRTrb/KnG4FHxejgUftQl+WU wP8PQ+BfWWH/CWqVfQf+GG1Aqpe5wN8i+mIFQKoN6stJZYo2uJUh/1zcdSYzfhUEIeo9msMi7cMs djhR43McgglT9BWTRtboKiZyqyaZ1T5uM15PaP2rIEiYqG1y5fWE6Qpmu0T+BQSFu+8M1X+lQOAR TnSG6h/RuzMK83QG1VpjCOYpRot5+rKLSY+m+Jh0w3TZaHsWYpUI5ilGm3nq1R9DAJgVmKc2KDr3 CoTku5G6MvEfqduVHf3VNRuC75xO4TevQtCV4eqQBcH9j1oZitOEVlaRp04mT0ohKKuFYPojbjqe uR2XxxKV59mZ/NZItiaV0+m2KbKpqAzZMcMoEFSTYywYAoKK0YGg9iE5rxsDmhSX3oDm2kD7IFTF 9D3Gj9FmoHqZGwOwiOJYgYFqg4qzp5ah5GTiZSmsyX0/vUvqyqNUJ0PJjPZxG/Q9gKZ4XzKA1/Xj OQjyCHmvKPn1lEZ8p/96pjL6R2TVGKmlM9xN/oYjqKUYLWrpi2PMeqH52Sg0xw1Cc9L+A9Qq+x4K wGhTS736YygAswK11AZDmhY9HCJPZ1uarkZLXY7qcSt1OqOSMJz/n9xNhMY/AicDVnEXnecmaiLD 1FtVTpybxN5yCBZAMP6ROqxjO1smaYpMgmBFxU0IHg6PY2u/QTub6ZRWAJVGjyGQphgdpGkfMhNA maL5Y5HB2eTY+yNWSWGamhQMbaapl7lBAIvojBWYpjaoMxlKIRk6O4wMgOD9EDJPf4pYtxkr4ze/ xq8lVCFKtspdczEWX6irId2WLJ1X6hSmdFT5sNWrNTtNXg7Z4XrqScSnD0V4qeEbOQuAGbmjL+gM gjuK0eGOmhoah7Geg84cfDrRPOX13onmgpGoE5YYhTpqsn2kTR1lmhsEsIiZ6XfoqE2amYvqRPJU bLt6ic7Q+772dz8p1rOkM/B0kVYW58mQH2FVh5OKopGOqkCGTABBXOS3RW/FjUeXidH3TzPpmyFw dxgd3N1L6vLPKYef7cU+e3rRyW/2foglUmh3JrkRbdod01zobxlp6X/Tb5NNswoyNIKt9dZ8n1Tn pgqNxRXt8sns5YQ0tAaCaqK0gPOIo/nGReuxWVIvUb0apl4rI3TO5XWhouY2d9NDFraFcVRElBu+ /0ZOMFSdIMw+DRyeCeJlwLeBQ59ryQ+9WpJ2zW4hqkYo7TuT1+nafKa5gN8iNWIFFJ4N8l0G1wiV y9qctFM4Oj2Yo84js+M/h+DkPgja5zEWEzUcAbu3KRZ7mFGRCUFAdM/1iFWD5a149XBS4RS+U1PA V1zFiwYhi4NKwZtu8gbC09Og4PVlUUKeG5RLT6P9a3ZS1BoR0T5tDh6zX6J9K3DwbFBFxOpOCFze zCFTNRejtdshSNyzWOfXyRUislDnVi5n4xn4+xFuT86S/qnkEUmpk782h3WwBU/Plw/SWfh1QU2/ SWQ5mp1biurW/bmlqJajubMKgmuHdI/o/jGFi2dCGsYQXDyMBhfvRUlRBLzzXFQCekVFFGMnQiyQ AsXzNHmdrqdnmov4LVIyVqDi2aCo3IJg33pC5REtXcrvyEmCYIJAkx1MepyBoKmGn7haIZSehSCQ 6PMZuiiMKL0Z75sWBcK200Dp9SUlH1Jy/EtPc/wU1OFKzAOR49PG6TH7Jce3Ak7PJlMViWqxdkU3 v/S4Mp8MJZb4TJRPit+gExVOreN3mr3snqX423zysLg0D4K8jA4MAtkP1JfPB5c/CnLJmyVoV52p giBliu4RXTCUs/sm7WEETA+jBdN7ObgXUIL7zwzBffkj+9mIVSJgehhtmB6zX4J7K8D0bLDXJSvO x7Nyye802enqP8ms8+qJ8tyUtq3qrPYH/PLM+499/i/493tfDcjYe6F70IO2G3Vp6LlJCloPM8m7 EWg9jBZaL/QF2LBvFOX+N4cYA1qvza4ZVQyITJ42Wo9pLpO3BG0YswJab7gNNrSSNSKd3fhTU34o Wl6VQ/K3dk4O51fMzFfHSyoL2h9tJ094a2e35ZJ1/FZnorrB+FK66MH5e/h4mUDt2s0oLVjns7d4 sHxKzRFRGLJcKIA9E5QFhgDsYbQAe6YHJmc7j13z+nPwy5QpBvDLNPtZqDUijDttwB6zX6J4KwD2 bDCKV7gJIPCbGudUi6cdKnJoY92oWB7jc6QxWVE3SpxeAEEPiMC1X7sS5AXkfe8YhazHNKkCBFkP o0XWe9lzLKEk7JeeJuzx9vMRq0SQ9TDaZD1mvyTsViDr2aDnOK/MJkPj16lDybm52rU6q8FeSibi P2YTSwlpWC1xkt00SVLf+EDJkInkzvg6XtotPF1cuk+b68P7lExhjX/Eczk3K/e2XARBcwWLXN/7 iCwYKl3PxHMg6HoYLboeFeDtG/z+mleMovGGQTSG2DNRK0Rk67TJepi5bB2zSLH0v0G3QXi3Yn+O 5jgEA1VhP8dypI7djPIi52x8En6BDL3QgmftI5OXv7lVfUoiS3z6YwRP8x4Egq3aMX09Qw/VU7l6 Jjt9BFcPo8XVe8mNOBsx9zcNmPuC43YNiDUiuHoYba4eZi5dt4gZsQJXzwbNiGMoBKEzu9Qx1+OE 6sw6ovrYNzV4zYIi8qjyJr6OUI6QKLq4H/X9tMZ7z1evtaZeLh4Uu+AvyQDR4rXX/qZSMFSlIHw7 LaYepYf1tr6HZZwIXmM4Qp+ZaLcJVSfGWjZRFNo8PcxMwj7dEncuYlbg6b1jg4rSINTEEh6yInZ3 G3ddddz/s3fmUU2c3R+f1laxtsW+fV2oYlppXaDsRkQto6W4FBUVBWS3iLi1qSLFpTC1/iytC0FQ kVqNgIosJkUFZI1WJQKtrAGEKmgIW6QxIQESJvO8A0STvGaa35k3B/5I//Aw3BxP7jkzl/t87/d5 PsMW1aJ1JtKDh+Fq7xvlGVPXYD9ziyMCn9AltcwyLJEd+5TdOUVmNXhJWBNq+DwbzZogEOek8Hkv d48XkyzXoMFJVtpPRt8SpagqW42tWaTZeY66THW9NI8RYOcZYPO4L68DkHlkqgJuHbdAEICmylMk ADr9sfAKIk7pZFRjgXlNXaHYhSbsHPK+H60nF0BraQByg2Oscvp9AZTqAKAUxr1JXn8Z3wqLbkYH LzZncH8m3qWlzszTKBkCZp4jKWaexjwraGCedTkkSdVKlEfn64jeLOToSKDkSUPzHHX56nqZaI0A NM8AJ1rSaaloqqBmX4o4hbWmk1F6LvepkGeN0bsnlIcgJogEOc3cv6CvDEDJ6N0dSONbz/8RW+oq Kp69o8bShYCK50iKivdSH3FWvTZia9oQoOigURNRjqrC1VAhpKF4jroMdb00khGA4hlgI0mW1mHr TdhVb9DrAmTrNgNomTnsh/DXnFG8n8fo2oldbBlqFO4KJlxTwJB0y17tRLI48vi4wc4SlM/MfFjn 9Zfgk5AMKXGVqG2EV9vtZGejnX+Hx//Xl9I5m9lsPa/mom9VuuhPxi7QmqPyK7VVCWmtrstF18tU awTwd4Y41cIS0dymMUjhhA6Fsyy06O0BXnG1PErc9q0pJvGguGNr6M+QFq8IN9kS+BaAjm+UwvzJ ABqDuSQCaCy7PQqLvmLctxJAn8GSsC3IbzT5B3iXSSeuGDXNPk/jMdWq2fG4Xrz2UWpeu6vSa883 aiEqGa1eOx4nLduHwWvH0/vHax8WhTKw7de3qR1AnMPEvwjgrCb5mbiBzcFhjAahYmXJ4N7gvPKu cOzSQO9BbPyC+sJvMjPRBc2eXpjpM4vTvr+1EhmOyrs7VDn2VI0PtCp7PE5G2a/9r06jNu0aOv+e 60NwNlH5hUMZOmjESQt7Haa7PqZdeHrDL+wNcdqVweDXoZ4XNwHIiv2k0GKmLAxAE45zI0/C1TT+ BlPPDnfFXGz984A3Ih0HIDacsBVANdYYigWnAGg1u79bFk9cIWrvjJ+j/oF2/h0eJyPktfQWtenX 0Evj84KNmgmSVCHwNHsLaQSeoy5HXi+9ZQQQeAbYW/7A6pvE13PkLrhe2UGTefsopl9Dsh3QK5bY cT+3nhzM+Qx2Dn70Ka5U2OKpTRIRJsYFzBUAxbTiHYXeG5M/5pnwgN/Bgb5ya6CvzMillhBtfFTe VOViTEO+aOff4XEyIl+9pYzfGqh6f9dbQ6fdc6uNqogSVFW0Zn4kFT7VRocjr5+OMgLoO0PsKO5o 2JFKN1GttQvM8bombxPPzMBy0Z8EMBOZvi8XQJNhIT8Us0GaStvQQLyZEHcOFchOYwewnY12kB0e 14fnPsr1hedec1PpuT80+pMgRzutOh7PnaSOp9oMg+eOp/eP5z4csBRFNsLtfob0V64DUHa5vCjS GFfy5oyeBwDyLMeFu9CFBqDtxlJrM4UtO8YSQF0bsYstyCUH8etsRQZcU0CXFGOL8t0ffpOS1+UW do/pssuCuFzURLyGFNEOscPjZER8ldopxGW36m+u/eBFsSwbLJa0EKOviYpFq/GOx0kqeKqNLuPd Vh/FMgIEuwkG2DgWMqRBFnJLlOkfFYdlBCMu7JNlFWKEe5TVniPOnQCgOw8U//YE0LshkjUB6EpG pa8A4duGoAkh/Y3x85tkKzYAaMYGrId/Pwdzn4iUnEIKc4msFOVN1bbK0g6vw+P6sORHuT4XJe6j lJZ8rtE+ohS1WvJ4nKRyp9oMgyWPp/ePJT8M5QL3PJCvQ0rS2ebarvIVGeyaPxkdDmILdkOZYmUJ FodMVwWt7pcnCdsZ9/IXOB1hJyHTnz6VW2E/oUeifXfxiNdjdtoteTsb7fg6PE5Gyf93g/lUdZy3 5uZnQ+sxH6NqghxV8DrN9RhZeB3VRochr58WMwLwOkNsMZS+6vvYSURoUYHw3BbI1wOogLUYQMcW Cjs8MTGTK1nfUHQ437PSyxJbBSC5d46iJWMigGYiCksfTOwxDoljY6dwYb+XeBWmBquz1ViFaYfV 4XEy6r1SzXwMcsX7yrjzq3cxX2VFbmamHkj93tXJGsr/2OghUY5aLXo8TlrA67Lo5+ilSIZfwE82 vCJpx6XKJBEXQCVZlQDaYc1LB1Dc9mSsPoCDL75mVEZeQFJxGeN2TZykWAagtRSMEcJ3kR/HLsAK p/LSrH0ssT2WENBf4V3oKTMB0AqWot3SPx09CqBLnpiE2EpR49fZa6zItPPr8DgZuV+rfvzdeXBN FqqyId1H2Q+uykofEWz5Un7r4DXVTiN90opfh3NvZ6eX4hl+xT/RADuMD4C4+JMez7eoxKW9hz0W cILlwlZ4lcsi12YEKcY//3eQjqUGA+hCjuLp+zwApW1AOnD5v99oHoA6TwXIXZFHvxEXihrATrNQ CIQ+CYCdhnTBCwQvk/HPN4FtC2QOmo75DgSILuU30l6WLmQhdlSbYfHqRwBiZ4DSRZhXJ78hbKe3 +fV6A8jTVPEOKigSBHTy2Enw2dAADwDxXWoAlIgKfpbnAMjcKkVh3OZbx2XL1oTB7ch8QaNkB3bA b3/kMUaFBYtWeU3++o4rJ68S7SVW3tahp1Fze4t2qB0eJ6P1tXWW84EvVmWHBldlpT+OtSPKUiuo Ho+Tlvu6jHq9NJYRwNoZZGNBuB+XdyB2L19kBlTKLCYoKLEDFx8FiOKRiwjnN1zbmITLPdFvX0SI y0MlB2w05rLa6XV4nISuv16hdmj+s4FD8zd9VYfma24qD81nj3UhyFKFsNMsD7IIO6qNDoveXi/K fgQQdhQD5A45sfHnPV4RUJrnxgJQMb608hQz4wQAEiUgXDQth8uWTmdJrqZH4Au0teYAcjV/Hsp2 YgIodfe3fjIPDrdJakU/wjavl+djFytF4XzvdQCinFW8AfPKPmfwutmJS9G9W93RyHDJLADRid70 oLzrQyVF1ZDY2tl3eJzMFEBLx7FXmZcViwZLqvTEWCuiLLWy7/A42TmArS4jXy8dZwTYd4bYcSbh smQigJZhiwpfx1XJIXYVHGO9GJEn0iT0FqO2vtho5KdZ+I+opSKTgGqK8Evn5L6jrA56b3ZiJbrE U8LpbyTCFSnvobLnaBSIdtYdHich9pUtZ/zt+skr3jv9Sslzke/sPCjyf3Mc+ypBeirInTqEG0+b rMi31WHr66fXDL/Gf8XwCqNH2iVoJHqJvPImDF7ba26P0s6tw+Mk1LndOpU6N3vpD/+QEZ97nXAH lwpbpzkAJouto9rqMOLt9SLPRwBbZ2Z4z/dfAwzHCehS/rg8+UPssqeIcsJKIAiXJwbciVxd0JaG lF4tl9lM+kXqJvMYsNxf7T6Xiqv0Mrjlpt8jSmWKwjY9/7Z8DoAuUcP3IEsYkuI0RqMxtiZiKc+t v349nE1Bk+T0Ykbvr2nIDljmIqUcg4UbEVCRJWNInAE0zYNtj/2I8ErrWpFKY3QvsYevxrybp+G1 aGfe4XE96Xr7F/Ni5yEXP7fS6A+iJFWyXsM0JQu9o9rqcvH1ssgaAeidAS6yhMhjF0YV/Ht+U9+a EAm926oX+/cGhRl6jxcT7WjEi0lfj4YBaCLm4s3isfpyxOZcxBS5yz7+NzWhIuA5aoh57QQ8PE5C zFep2Y9m4wanw2ol8e5gSVw9aZRGkKMDgUlPln9HtdVh0uvFfhwB/N1rBri6Kn/KrsWCuxgPkCto WSN8FUA+f3O6RMWvs5+rYcdp59fhcRJC207t1Qv1qwdnVyteTK4qhhDzebeM6olyJLDbyRLsqLY6 7HZ7PeAe8fSGX2Z/aIDP+0KY9xQ7E5/5GECUEMmfhXTjvn74Er8VQI3OCu8UOSPG2gFroHRy4Rr0 wF52TwWAPFKxlBYjv3dlVGSUbHXeTPE2bIw4cbdbCxc15nuysyehyfPpknQA7SP+JQBU3ALQBUR0 9yCu8QHEOzIGOw4gDrE/r4bA01xtaUfg4XFS/rw6kWVoteX+Aj+xbYvyvfL+Yx0IslRB8DRnWmQh eFRbXfa8vV6Kbfil+yQDlDYP0J3YcTQ9P0TEkS8VM7sYHEoHpfRYgIj/HptXSkU4J95EpIvwumAr Ht+bDKDOAwBajvTfjrEFEHcUFgug3ijiqa8a+s5WY62vHX2Hx8lIf65ahZiFjt8amKZCFm3bMmTN /84c+xlRgRAcoydLv6Pa6rDm5+ilQEaAfmdhgMiiNiT9GIA+h09Y+4fLbzRJkmWfqmIWQvnMZha7 nfF9EYCSIseVI9luoj5KB/v3gt7+TXj/OoCdQctU0cxIvNPMYilgWa01F+FPAFAKgObflbPQJLYE QG14D6qS9wLIfNUR7JT0olSIrTs7SWEpcBU0oanzreU+tUgPrbcN3RkCoM0AikQ4E5UBYv2jQu1R NQfL2lF7eJzUTODlLvWuyutPHPL6y04RkPCVX6qlS5Gl7VFtdXn9+inC4R8KGGKXasfsWz3Dl4oY dvl58FHZCQA9MJbEAWgTXOWmiME70lJsTkI3ekjzx9/UhNpMQGMkrZ2lh8dJzATsqtWHAqEDFaG2 r9J56Ah+/najJwRJqqH0NPoSWZQe1VaHvz9HL1OBEUDpfWx4JdEJZyOi001V8P08ehcD3ewgoXcz k/vxvmByTGGGCnLbkU4HNwDFcpECZlsigC4/hDHX9Zg4/1wUlrwbQDJLz/7SO9gDhvhESV+OOMOt KwFAs1cwjiDmqihrVv5RRBIV6cKftJOOxQjvFST9hS/8qkxlk0DFjnJpyBRsOaX3xANG530HNBYW zr4Gc3+hyT5EHnlMUixqausvG4edp3Ur+IcAtNpBhokJK1IF8qMO/GVW+4BgbEEG5Gc7MLcegCwp e5SZa5BKSW06PwTy+92ogShHgrEFWZAf1U7H7gAH9WP+88hX5HDPLf4FLTHAihwduaThofvm0gNz bcJleybUvIkey8q79MfJV3cECsXPLC6byKZsD1t5xvy1+ltN/Ob1P7Tse8yaOtn89q5Pvq6LfnPC xtxpN7ZzRr9xbbt/7dHD9MKfDzY/viOzmJvVteXe5f4Hl53enuoWq/mhlXVixNfpqdKM6ATpNdP6 hAGm2cQbh5s73uadu9/8P35sDSq6QkUclyC3ZTlPg6uK7S7dO83bMR5J+Ca3j5eUmXLBp8euI8jE fdOKndlG8O/5vujOSq/qKst+k92ZR1OvzpjX+Bql1d+H212U6Z6wpTM31+Tjve87cU73LR3VXJCT 3hbxRYpdJTd0l52XeFEE3fZZ9Jhbe2me9+V3VwUnp7W2bMps+a5/WtDjqcbf/2Bh73ok89aYHWcD 3+lumfXFtTk38qeO/6ak9hWK06eaH1pGMqQLBEs9E+s2Zv/y+YqDm7L+71x/kLvIWwF3htdGs5yZ t7+cdyJhdMn2sZ/0FKc8yZIjNcIrpv5Rfj807Jxt91Zs7b/2dx1zu4uASn6Agll01bMuveMJO4z5 Yf20ue1VHTO+LZKWsvv9IjaxWJ7VdyMFvst/Xfhl5cWqFbIIwUmkJ09eEuDPSjmsqL0RF7inMdn1 QoK4v7br4dLZfXVrff1OHnzN5GDQ21fm7zlmfNonJ2xqCs9v+c5vPN4cv/mto/OvdzyZ47Txq4c1 uxjHwj66+8DLZvHpuTad1Sk/VsgOXZHCzPVxAUltn7T5mBRsHxPjtsdpu08n4ps+g+1yf//9bPs9 tcbvn3v2bW1ODZbrsTLyyC+9Z3dsFmVMW/xJs+zKn+eyvm/dcMinKSL+euajmJ7r74wJvT6Kn/aw ROBlFXx6fWHvg/2uph3G2xePD1+wyMmb8D+AKmsf+Zkqe5HoTFycpxvLpOXI9o9qHTNfv9oFwXP8 c6QOF0J4PIeZM5gMf/uSibWuGaFfjAtugCK3FNI6acvKOcVfrVrp51QQEmuZEe/Vemdi2XUI5aYV FUZsoK272b7Hoah24WG/oNGttRUPqQvPmi2Pdvs+y7OOlW7ZedrUeHRvA+e4a0bgnw0NUy6lxF3Y alvyzCNNLpUGF7qPSmx+1O8lnh12dMoZH+fdNeLdx2Y4OhkF+GPXdr/365fFxV8u6akKrr2xvNr5 vdiQknGCptqvDnq8daP+j8uPGlbk1Y2dvyVo7QrZBxH75X9UbLuVM8Uka0rj8njvxzNXvrltOeMj /ryIb+TMiVBw0ZMlF4sWihcurty7iuJXlH7oOxPajeOpNPpC+vjd/u5RdbS0x4Gjff76cJsPr9zs jukkUN1GkfbDU0yjL323Msm1MSh7HrrgneZcjiKyvJgTlHr+3S2xPfVd0fDbd/ZY7QRQwDVRZn3n ltcaPizMXhBEv505bdzsJr/IX3+51ELb0hAS+FUULwOz+P+FLnbC4gslPJmjfCoyeS9G+7ljHx1N tduDrYqMohRPQ8605vkn44pzxTk4jpHIEUUxWmWX5JlodBF8NJxShf5UlIGYseg8U46EPZ2WTrkn 4PVxdiqs77FBTTW7L7mcUl97FkB3p+3Biq8LsVndnB5qG4C82QtkNJjRzSuTxTMU21AhvwBDyunW rf6INL2bfapbBiCnheyEnRMUM7oVqyJdf2R1ODA6Q8W+LsjyAgC5M2Lz8bWMWbvCWtCNiR6jH4Vj dksr5QF1bQre7b7PhegmerKEzSrv50Q9iwdcUfF/2Dv7qKjKfY8/N69XkNPBUxnXtyalox1QaO9h UKSY0gxXiKSI+IbjSYNSupxEMinYRztdK1M0IsS3yUiQt5mUkOTFrWXFizImIqY3x5QRBzB0MyPM Zs9+zp4ZdfbGeZq19prF/DF3AWuGgbV4/pgf3+f7+/6ez9Pbvq3xpzHafeHBY1My3+mqmB5JPau5 lrmRls9kN91astff9ETSbfJ5s4TbDL3wzpS5O5gsaZ/2i8ysMxB8UTNyCPM6KzW1CB7QMy12oio2 jX/BNY4hkKqYGKRq7H37kJpqsdT+/O3KQet25fAOrxLHa8R4RFXBjL9YoqoMdzay5RIqkRuIqsM9 b7dSaVRD8IiUVZwqM6+B4KTliFZPILEEgtv+ch3T2Czv8k5PMm8MngPB139F14F9tmtaqODN57jB i4nhpLbyekup0idbL9R5zZ7YHnCrI+n6rtGj/vZtW89D4GSt9yhUHTie7cLEYlJluJPZLswVrSXM DZjUhz2vDq4QR5IYdXorvYEp2WjxvbWdCn07pRrWn0g09JYRhcqGykCuPv6eDUHUaOJG3Ja1JPPS KLnhUCH7waIBP0KVCcaDomJTBT9w3IPFREBRKxbwiuQ5f04t/HlqUWpTi89QIygYj4o6TfC62AYs 7mQqC3PFBCTmBiqqrwdWCXkkkn3Kt1RCvdG4if1F0rc94muivjDIp38VcfV5+gQEE/dsNU7dVgbB yzXd9COGlKKatBQ6rp04k5ufEX2thDirDmf/VYvsyGJ8KCq//4MhoKiYGCjqwvsVEiUd8caqr+zY 4NWrbDebHJ6F3E7ZiagCVhcmlogqw53MaLmkPtwARB3qgTMrTY2XwoOTu5AnbjE7w1Qq3IUgGKaY CIZpBW8q6//maGafuFA3om5uU9yVFs0pmQyP+0d9+1BwcrT3o6g1Ou5vYqIxpriTsSzMFWNZmBsw piM87y3eIy9VUPs7CCpR21Cj6fRjDqYrmbxKSi2lf4Ag4IlCTgPeZEqW9isgaCjMh6C+CoLLn1fe ISHIiYmEIDsNgtopKTcJ7rf3ZXG/3WkdukIWDO9+UcH/WwTrFBPFOuXfWRIVa7EW/IqJtVZM40Hv CMQi7bBTQUSHiYad4oNwaQm3vP+/tGQwRCH7OLuD2XIxZggdSQW/8ayvXlL3ScSHff6+X0Z4fX8j a9M6PbLBhNnZpdKpAmONYJdiotil/NveUmO5LdFB+4boLtIkAHG77t2/mPKgYxANL8WdzE254qo3 bnmD76s98Kq3nm4VSak7lVS6tvdAuzaB0Cla5W1GsjtKc4wThgZSRdR3Epc/XxqRnelPlR7JmMhE 6hYn09F9WQ3HPoDgxOIMHwg2Hab9IBj6GrJMeNBSTPgmRBhrUdDSZt6Bp6hYayd25v1BDn8f2yDH C4gL4O7+TQcqIRpbijubbZrqkkIZfGs9xgMHDGuCD2SbpwYv/Y5eLG9ee/fbCW0Zfve+xq9Ym/n0 orHKjx8fNumqqqS4A10NvLEm/hQdhuCRYqJ4pA+Ixhe8cdtVRbZ59C7vFxCLlDoea8JEA0lxJ2NN rpENNwBJPVA2KLaILbkOQeEvrCE+1xhjVEw1R2h6v6whi4liE6m/Q9SOHCs3Rj5qDlPmRPqa552E YG6Sbt73ECx4S96cZ4o/J7/z0LH9EHw90uhr/ifyUhGMhyXFhbWCMOSisKQOlGOIvSubbBs5amz1 DkOt0jGQBBMNJpU6A5K4RDrcACb1QOkwTPY1vhtslkHwmXrGcQjiD0PQrDC9zHtdtU1zOmGccldV uFz22tS+3vcWxhJZ63+wPo1TnmLVPSXyPLOifSEhpckmdPuKhyLFBXE3AkWKiUKRnuFVS2rs0JUz o3gDsyttjJKqo6irR7AQhBsXDSKVOgu8XVMsg+/G/+KJhkRNUEdoTigmdUPwbqDmWC1nQy51+jJK 0tyljrAcuwhMKZVTmRD0Hi6fHk+XfMDuVegW7w00x33HqYyaKm3KYYt/IwrjTfGkmljO/kG58G4e CRG8RRHuXRSQ9EFxERaMv7VgTn3tHYkqGPvJJ2FRi3XwUifJuGvUxQ1QUg9Ul04pBC3vaU0h3Q1V pyDgdmJsdDilKpeb409DkD2XKSkoMflEjF/XQoxPOhm0S902ue+DmPGxdQuoEVY1ed+kbGHXSSwi g96GhaCScQSJFBNFIhVaFmud+NvrxEYsqZYhO10hCAMvGkQqdZaNu8SyuAFE6omdLqWKpMotGbhF WNIDmzIt/S1N5zCLsNxQh9GdnLDISyVWYfky95zGFGfQGL5nqfl0HgQBx/LYncTllxWxcl18s7zZ t79eMRuCS+My/CFITjNkmQ+hm8Q8TqlU0P1CcEoxMZxShzJjP9p36CPr0b5TS7xnIlaJ4JRiojml UifBuWtUxg2cUg9UmZZGCHLIZRBEsysq1kKgS2mVNxM7pywjTUuNGoP2uk9qvnlMhCLnf9YR+UmN VFlTliHZlBlXniJp8Um8LC9+/HQNsSCA2M1mBiivQ6D8uNBEtl9Fb814IFJcWDMI3y8KRPqA4Pg8 GXiPj3LBxkepftPrGmqNiCBeNIZU6iyId4neuAFD6ol6o1YrqG/sRqbpWC3R0HzPx0ynjZzcxNzz Mbnn1Kb5nNz8RNSEBRcpqAN6pX4bBO+sVcwndVGc3oxjb+kMkeby3J8ld5oULxKXwtAzWjxEqVSw V0MgSjExiFJHcuNjRzlemGPDYn/qPRuxSjupdIDciO4COOOduEZuBr8L4IFyk9VKmBLaiIJwShbZ STIqiqsA0+h8o5aN3yDRb2O2JhCzaKJ7v2lGJx3cDEGGb4Of4udMZf+NzFcqS1lp2+NG5Y/vbbpc 3qfZvqCfIMm9sTdZlk2LqezvRx8XwewI1BCpoB+AQKBiYhCoA9pnI954ff/9WCbZluZX1SJDylBE mi+agCp1lua7pGzcQED1wOYZlVnIFl0nrKlMtlFujJHaUhllEQTFG5TWWOYSBGsI3Si5PpJSafuX QvB0vYWRkvM2BBe1ppdi6HlMyS+55cGJ6JmvUFSaj8CXYqLwpS32KclHPnx4ymOf3r3nfesU6z3v JSavD1Hrs5exTPC66D6AsyDfJQOSbiCXjva8GvmJbmbL2iEolJu7Sokyecdlgk6F4HID/weqax2+ 9A7ziuqsg/KOSOOm3yO+gKBIct6ncGzQnn9UvfXdaQh2lWpNxZZHdNfMzjQNEdASMATTFBPDNH1Q T1S8oD/5btBPeM9ALHIqIugXDTWVOgv6XaIobqCaemIcE1wqoYo6FNTb2t7DNY2dw5ji9FxmbyVn YXBLLy1g3wHO4LxpMTgk2wpBR2QsBNGSHes5NYHAPLuD0OdTQRBYxo2LxsWYQzJndUddzq1Fsuiw qTzjL3DVCDAqJgaMOkBcThvn3JeX6D9Z5aVaiwL+YDwsqsBeicaihjgL+10iL27AonqgvBww7jbH dkioVzW9h4syEiFYQG9mdpabu4oVi8mWiP0QTJxsqZZ8toWrluXrmTx59/h1xEXSHNUEQfYkc1tQ Vn88VywbtNQqCGo++GWk5WM3BLLFZE+c5RG9MeORTkME/8sRpFNMFOn0Ab0pSLI7mFdt590btyCH 8ach4n/RoNOQQYn/3QA69UC9uVKlZp9azlVJ1BhuT7bn26ASCD7yO0ic/RGC3sIgn2IIrs7qkBgO kWZ9YwWdxx7QQVB/HgL8ZmYBUbSBoNLIU9WKImXHcgWzN6UneO3yttp6dK+MRz4VHl9BkE8xMeTT gWpjmGxXm0+salPj59WOKhd7TQsXKNbwhzgL/12iNm7Annqg2mw+LzGmFBH1u+UBjp9eYrnaqOMk KE/SPf5Ni/Vvy5jJzsnq3X4EggqSsgpSZH9dwkeWj3sKY3lElowdVBoiFXRuEaBSTBSodOD0Micy 9lPAr9qOyZ961Pt51CIRowCiOaUhgzIK4AZOqQdGM+0WHEQF51bafkzSBe6xEFZaOX+SPUr5mWot yUQlEOycxMz51Zk5zPJ4er3JL+UsuaUBgrkQTLhJx9/eoNBr25bnQrCi8SwEXaPSFeb30YZmGq8J IGhHISCmmBiI6QMS84ldYubYDM0JZI5pJ5gKJUY0wTTEWfLvEolxA8HUAyWm0Khm456LZ+dA8MwC tsJyapjbhNUrrw9XnidNC4wKk5Q5kUa8wtUPtxUryKrzizf6miIU9OvMRsHLC94NOngnYV5XOVFn +0SH/3bK6ACJQVBGMTGUUaGPsfCKzjxmP1SM2Y7hN05BobAxO2ZUKDGiMaMhztJ/l/iYQaeMeqSP OUHnsAfTuulFnJWfOfyPvjMky3UhREG5WZ8eKqF2yZsXs4baMb6maIm+FIL05R/W/iV9ArpS7O4A 43fLcATfDhfDtxOKy4kZ9UeH19B5RwsmJg4PMtWAapPXDcfLw3lsO0GeKpptF+Is5HeNsgy+1/fI VlkjG5egMIczH+e2Bpvi0ghDNxWgWEbq4logaCbrqlJupjDvB5pl67QXtab/iqdX60nOs/xJbWi5 kLm2Sx72tmRPOdlg+/wDNQlD1Yhjj4+LgN89yHQ5s+D+TVsnl1mHYco1XkdQdeI41cdFs+9CnKX6 rqgT3A3sOw9EugxrURuXdvqZJ6dwevA8XcGWZLwKwYGtEHTPliwkW1JKFdZ+WNpOSWMRBHOS+s8k JA6jOojmUazBb/FGpkpp+JGoHYoqEJyPvcMFP3Ds6HER2LuBDiV65H1/MtmW52u8/he1Psd5Pi6a eRcyGHk+7gbmnQeqiIbugSDwz2XsXuZEknkDBDmbF3JWnV1RztZwZuX7EqKQeCYh+M43bNRedpe2 zi/KXCb/tJ0oqKSGcu59TUzbUa2+jNn4dm3rml/frj2fwvySCMHpz7lHZNsY52HwBFhhHIHBw0Vg 8BxIyouaF+2iMt8qKiefQwFVccxxsI+LJuGFOAv2XVI2bkDheaConINgazJpkiXplihvl+VCMLGU KYllZYchaGtR5rxuUOu+gSCadPgMXRh2fl7IM8LCcOzccRH8vAekxMBL7x+2NbvUXldQK3Sc3uOi 6XmywUjvcTfQ8zwyT9GaFppX9Cnr9hsr2ThyUcQk6umMNzlRSTnv+xGzRdG/hHhUye7U1FVAUFF4 OwwC/Sf8l6tjG27GBFY8W9ptOtwEwe7J3CO6WHin9QUbGwQ7DxfFznsgri/lxfWr78b1S1FtLhzB zsNFs/NkgxHX425g53lgm0t/rJIoVrEfMSUF9K9scTU9iVLt7lxPF3ffUDYUXb0V8R+xP1x576HC Lcf7ht7o/Lk1HzkrifNIemGCNxqCpIeLIunFCdDCwlL4ykbSW+ylQ5UCwqWLJunJnEXxrmAL424g 6Y3ywG5WHlPOeY1fmYbPk6imMla5vidgsbJxeiWdoT1V1X1zA/tluPm5ThXbquzwJ5sv218qKL9R fYWYoC+lg/okdVVrIrYcG0ZNbtlVHo8sFh5PTwCuwBE8PVwUT0+QwT9qPeK1kncgP9Z2IL9R6R2O WqY9hRdsBkUT9WSDkcLjbiDqeWAKbwguhSBySrrfeSL/81qfTvnPjctSI3ZdyzO0jtUUVEHQDxII 8z+DSPY48m53nIfSmyYoBARKDxeF0hP6ja1GXrgebfMbO7x+Q6xQ6jhcx0Vz9GSDEa7jbuDoeaDf qDaWsHEZa+g4dobKvJqzGYolbA6xvYRcQuriz5MHFG1Pay9eu2GU6Mspf2JNVv45okBTt9Wsisia x+6WT7iZFXjkWdUFqhyC641yNtn6iCwWPktP4DcQLD1cFEuPz+pOXWm9xNPffjD4nO1UfWMxanQL R7D0cNEsPZmzXD3MJQUz+AbdA2Hdhm1lzH4Ihpjiv0pL0fn2SRpq/UuIp4njbNzxdqJ4K5u37M/r 6YNafc7dbxM2M3+FoJQwP+HoGXKUHueT9AR2BEHSw0WR9AbYkf98Kvuerpy26Uq413XEAu0UvZBQ wcJF+3Jn0bpLzIgbKHoeaEZ84yCIm95Lp55JV9NFrWTzvvdbiJa5tewe41liDWkcrTX0Zs5y/LQl fPN7wzv2fn9saNrc37QPlS9cffoPyiQMVSYI1y6KoMdrYPmP8H7s5XtDWrJ465BWsb9XOqpK7GUs UDzR6DyZk2Add8Xlirgb0HmPeaCYXFYzaaRMX6vo68xc05xO3j7PtI4yvv+xvHnJt5rSsfPYXS0/ Zqy4mmU4r2pk95OfdpEdY0xB1qfIiuCR8p4RVgTCmosi5Q0QDvto/Or91i5WiZ/Xv1ALtJesQDhE U/JkztJ0lwiHGyh5HigcTXQrBAGZRWb5dZ/wTgVTRBcaINg5ubuMoAo7lM3siirtzVT2Ky27j3gy IeXOUQjmp0AQI98eVNm/DIKiqRAUKuv8Fv3ueyJt2xXG+iSxtGUXcjwL59PxBAWDoOPhouh4gl7W TGsva8R9wPfqu4fk30IdWsRliCxdNBxP5ixLd0knyw1wPA/sZBmfKGKKOs+lF1KF6nkdyoZ9R7u6 rwWzWT0jNUnEKMJA7FS9G97XCEE+80Mycenhe1/oGN1Ov5OGCbpGCPodLop+N0BEDvKwEYk25H3V bRRsFefB7wRhiGj4XaizHN0lMuIG+J0Hyki+sZWNG0WeHZ7VqjAtSIRgdoA8gdDN221+skp58y32 QJtNJmLNKvm5GqWhx/RQB1HxE52bbdWVldWqQ7+2Lvq987mkUiO6SHiz74KdDIJzh4vi3AnaWUOs 7Sy7cCTejc9f8Z6OWGQoIj4XjbkLdRafu6Sb5QbMnSd2s9j9zFHtMKJ2pN4805R67M8WMHEzvZlq f28ca1goiWXnZd0i2hZlxJhekp+AYMffjXLdf0MwjJ21HwJv8sZmdluZb180BC/KDWmvE9+l0OM5 lSlBlwzPrgv+ayMAd7gowN0AXfmCF7In3g3Z/4Y6jIgjAHe4aMBd6KCE7G4A3HmkPbEM+y7T3oDg p4/R33TKK7T07mzLSHCa8mK3ObreOhFcpbm5ni2wSA/xTMLKvvXHVYeY8Cvxi9hxtwJ3LvvuOjpm 5BHvpII+EoJ4h4si3s0fKDRDeGm71Ja2H633akEt0vGZd1w09i7USdruml6XG7B3ntjrKlXqWpn4 A6sgCCKv1gZOMqVBMHJHS2aOvDlFt3hcvD7WHMrG3XthCWH0gYCU570BwblglmFfK4TgFbK/x5SL LhLe3fCCLB5Bu8NF0e4eEBd77yvRdjl8VTOKnorbWXdCcRHNugt1Fsa7RFzcwLrzQHE5zV7QUt9U 0rM4v5KcYlqy1DyhnDgylSmbwu5IiLlTyc7cze6TX57BORWSGqs13GYpzsCUQbD93+SdaVhT19bH z60TFltsrVLqEG9xhCLCEYOKxOFFtKBYUUAQokXFVixX0YK2cKpea1uEoDhRhxRQkUEiIiBjalVm ZVDmKtowRy4mJECSk7PfAJWco+6b9zlvHvmQDz7BfeB5zoe9stZ//df+7WZVSuH0hGeNetF50PNw X2K53ZdYZmRYFcIHHsmgO4p8gYDuLGmB7l7NKcMc1F58yYAXnxkNLcZIqDvKyUnaqLv5Grx47aSU IUDd6WJKccb3hZQ7iarM7Vj5binyFvHMRCID/1nISsI+PZABkI9ZnU3+xFysoagF36zKJvDUoQbX vTL8CwHXWdIC11FTx+bRg277/ZIBtz1RrwPygtYQt502tG7+W3HbhwBap4OJI1aZhlV2vcAU5esB klYqzw02UAl5E253LUBcS1W6vdPODyA7DaTmxkoLfrgZQDq2EJcbsStM8Qi+MpH1KJsjySOWZDk/ /jY2s8NpX0GS3R5TeKyQNDxFi0CQdZa0kHUVpMOHS/oOH/6+bvDoYcnAefbMZmidRYLWUfIGbWjd fE22u4U2wmUIoHXjdTBv2HCl3qZyMzzJ62gEkbgNs+OfKi4TY5XHeK3p4ozxALlbq/zIFSDjfCRf sPHV3PJNQqzJwgeP9FHUn1nYIHPcCJAZG4nupgfphPMErPA0lpMB91JIvDpqnQXh1VnS4tW9klvi 1KLkb0P+e70Q2AtCDHnarLr5b8WQHwJWnQ7mFlZ3rXw9VpjAN3nTT1nKRP6jP7ltTLEpv65YubqQ iMA+VS/OeVAa3dnKLchaZBvCj8Y+ff5cPof4GQ8J27RHAC/GrGGGPARYZ0kLWPd6gllGOt1eMnC6 vTgahq23VEPrqGPCtKF18zU48tpJMUMArdPFFMPoffiAOIV1mpZhAqdF8g0AyeYtBUioTWebKyFO qpRsqMv9Jcu13M2MWAMQuXu6sjFxAkBmYkozD0Lsoo9F8InTKmm/H16HkSB1FpQ6DAKps6QFqSsn 2Y8O/ouNVQpeX32rY8bBgVsdN8JudbQkUeqoYUJXwTM12fTztBImb1/Bf6x7YdKqkiuGokqAFKaW A8TXXJAAkIidMUQNO19Vfs0oD76ExamkjFOKOFq5EiDrGATXp8lOfpy4xFLalhalHuCJUSKSrShz z3GVGQHEkadsNfNKwI8B5IorIYH7KSRsHUqueVAItg6lha2rIp18Rx1UVVkSyYn8ZsC6L3GDXbuN zoVY97ThdUwN1r2lpVZC5+1r/gk6mGE8AFKp2udnmkzLVeLeBSXYJ3l2fKVbqSx4XaK3cuzLf4c5 RNw2gFxKVz6fKgBI/EaszQwg3+lZA6T9NFvugD35Ax4mJHIdNUzeLPVRGuQ6inSZOn9udcralS/n 65nr+ufrE1bC0FwoCVzHpKzTFfrMt+HWo0MArtNB7dKZWS2/1dnKafHscQeI62TlB7gwV8huF/Cj WRf82S4AabJ7BJAoXPirPB0gJnNilQYtm6or+bIv9rFasYXCeokvcdDzu+BQbpkpz688RT7C99qp G9BRYpQEsqOMt6AQkB1KC2T3Wlp5/yPHwYhx6Y+YkndgBRlKgtktoKzTVftMTS69NrIKOgQwO53M KljlZ6VtmOXrPySzy2Wm45WME30/TGeLzmCXsfw/VMLGKEDuin8/uAIPDrWsn0v5roYw61AazDqr m2VqWV/hphL1m0pXDor6P/+nX9RnAdihRlSNrKMGB21kHVODP49qQ9SjQ4CsY+ggbMiWr9rtZ5Ts okwnHkDyVFWVqzgpQggQUSRWicenV/Kln/IkNxKCVLXZOhOAOJi8XEqzTQJI3N7vPWUu+ZUN0jmc EL5JjTyLuFwuCmhyXw8QxgXluyxB8edcQRc/yh7f/5UzHhwgmQUQDvRiB5TEurOi7tY3NwBQWqy7 17LNSLVtuXp8n21ZshB2yTZKgt1R8iFt2B1Tk3+vlWQzBLA7XUw2hio5MgEgK4klOSNUauQIv4IV br4Uk0f5STiNei29J8Kwn2epPo7ai4zYDxmdu5bH9B7jtXF60qLK8RWuknxFPRRRhJLgdnMp0QGB 26F04HZ/Z5uxd2r+WFa6TJVuxqhvcGA695didxpGT4K8ohpt90p00Bb4Gkx97SSbt6/v/6F7wdEt 7RDWQ2+KR0m0Oopph0JodSgdWp3lerUyn0v54r/f/8WfeRg2uIWSUHVWlHXaulyDAY9qRZcPAarO WPf29n/6qI3jcfsm/Uz5Y+Kqq4hxco5QGCCPYt8NXpvdEo8V3SiVzTU8L3WSufRZ7e90XYxTyfNi VuPvnk8Y5bFKi4SsO/J5ALliFRCIreBK8uK59QbEF0H2AidFzQZWGgOPlnPyuD3X4zFflsxOyghl dW7BQFmqjCtZDpApLnyU+AkTFFU3Y+UG+H6od4+SOHfW1H0MEfS0OHevlVhX1F3iqJdQSMj9jKia cUdNIrQZd0xN7r1WSqwhYNzpYInViT2z41awSrIaer/wkXC65vQQH21UGuMFgvCwBXqC8IQN+D6A TCDs3HkCXm+62KQSm4zd4x//LxGhBt5RTgajEOAdSgd4V0EyHfX9R3gPQwePofg79B9DibHWWw95 QwjwDqUNvGNqMOa1YTiiQ8C7G66DVVXpc34Vsa2DW4tdw4vrWTcA4gE/UYKqgXVo3yk+0gOIwqYD rLMk3bNQsUSlIRwHG1Z/LOlvWMU/0dsPe8M30+RR2rA6aw32OqoNuiM6BLC6aTq4221YgufEuTPJ zwDC8JH8mcMx6FWwrjQ1A6R+udI9Vs4NN2cSdYz2StYj/OB+fncZQFziiNhGPc9xMitsmGxt5kzx 18QocdRep8ZK3KDJlZ9miMcs5EgSAHIA/h82KLsNkEuY6N5hlboHiCBkFHEcIPlQPx4l0e6odRaE dofSot1VkRgs/XVWPIk4seVvP74G2sya92Y/HqVNvLPW5MejWom1t6/XDXVQ09Tiu4njeEKWjyhf bi9O6uDmM9oYRaFsUdMnfEGRFZZ/cgwmXaIKC77yWcHHAGk/CJBVmOJOuAVAKocRJwDScxTe6yVx 7iwomw/CuUPpcO4sK0kBoj+2uub39aSRyD9W9iej+1+MdoQFiNWbA4Q27M5agxk/TysBMgSwO1Md hBS1YAmhAPmcddLcK0B+q0ESI1umXjPtlM98yuO3cg/lAiQ6WL8US3MS9TLa+CXZPYqtqvR1kDiH F6tXk4NViWYWT8mSVZlXYk3jARILkIX35Dw8mi8BSIsqBVXIewBi4hVCnJZelnYS63MMlWZCB2ED HnfAXO5RhXX79bTgu30Ash0gwVj+hL8X4NJHTdazonaUIWQ9lBZZ77Uk9c6gu586d8Ddvz929GrY O0LcfdpwPWtN7r52QvDtdwN0MUe1Emiza4C9iGuZlck6JjsJkFoDSQRAtrIqnJThqnxkT8yL7MKP UD/+S0SQmgGULjQEnYfSQedZPiR3A5z7R5DHLdYf7Ajoj+vvCJSchRZuJHgeRcXRhudZa3D152ml JTAE8LzPdC8o2llpmOhsQwXrQSang4tvZ0o4XUkxClVeMApVGuPCjFasnekEkBOVWHZSSxRArj5m EQ4bCHHWxaNEzF6AyMxcFUV3iVqu+GRhb7o40akjEiCzHbkhmIl6lTcr6xgmORps12S4m0OEdxZk R/9HVfhVTJYZgjLfUqnPRGIVo+dkLbf9ARM/weqcncKqPO8nm4Y9cTFULmloURTrE7/5dSmbjgBk LVNGiKExqUb3WfV9N5MeQHoWdNB9Fn0N6+X9B/pRB1VcGjt4Lx6njkjn/ojM3qMngb3km++uR2nD +6w1zAUwyef6remH5NvuW3yIrNDBkBwZvKLusfP2ooPz5wbIAsc/GoOHpmZeuX/qHd/NneIXpleN ZBN37lt9zmR4ze2Gpqcbfmw88Iw36WOTO3sW/6s6bMz4LRlTbu3MH/luyk6vqmO/cHJ+Pfz02V2Z 6fzUjh0FVxW1V23fn+R0gvpwjnlU0L8S4qSJYZHSlMk1kX0Yswm3fnna9r7g4oOn/8/H5qCsw1+U b+fttDL9+baKPMsrBWcFvmOxyG8zegXRybGXPLot27yNnLc67k7TY5VkbcJ3l7s9rDBTGO1NPhZ3 Y4Z1/XBGs5dHZVdusnPkjvaMDKPP9k+1zT/baz/saXZ6QkvQl7GW5ZX+eyzdxEuCOBYvwkbd3u/n +kB+b822mPjmxq3JjT8opng/m2Rw6EdT1CEk+fYo3wubP+hqnPVlyrxbWZPGfltY9Q+G7TLqQ7Ng rnSR0N41qnpL2vnPHQ9vTf33RYW3s8hdyWoPqArjLU+6s8v6ZOTIwp2jF3fnxf6VKscedV6b7HXU 88e63bMt3ztR9eF3HaFO9zBQ3sRWJuXecK1OaPuLvy9pWs2U+a0VbTO+z5UW8RWeQVt5PNeH94KF m1Zdt9lVfrnCURYkPIV1Z8oL2V682F+UVbciNgfWxzhcihQrqjoe28/urV63yfPU4eFGh73fv7Yw MNTgrEf6vkmxAs9Vu791GTN2+3vHFt5s+2ue7ZZvHj/aww3dN/1erdvcpWfnz21/GPtTmezINSkr aUMEO7plcYuHUfbOUeFOgbY7PdqxTQkz+HYPvnuQhgZWGUy9+OL7qvRHRIbL6uCQ8z0XfLeLEqcs XfxUdu3Pi6mHmjce8WgIOnMz+Ul4980PRvnfHNYU/7hQ6DZn29kNOT213zlMbjPYuXRswKIltu7Q PwAV5h7ycxWoSHQuIsLViWfUGLJzetWC5BE3OhDWPK90KfOSj0DAnDkjieuFFk6ockj0/1J/Wx0S vCPHr91vZWl+3jdrVnvaZvucMEs849Z8d0LxTQSvjM/NCdrot/731kBmbpXNL57eI5uryh5b2Vww XhXmdCjVtZqXYNZ+drLByJ66/OMOiZv/rKubeCU24tJXFoUvXOLlUum2HOdhUU+fKNzEs/cdm3jO Y/neR+K9oTMW2OqxvYiUvZ9c35WXt2tFd8W2qlurHi7/5IRPob6woeqbwy7v3aq5f/VJnWNm9eiF O7zXOcr+GfSd/H7Z17fTJxqlTqxfdcb92czVY75exZ3eZB30rTxpArIt968Vl3NtxDZLy/evYXjm Jhz5wcjv1vE4P44NZ+xeL+ej1X7xzzaP9PjPtK89BKXGdycbgoctDKmCNXFy2JUfVkc71HunWeOL Pniaka8MLs3L9477bdyOE901HWGs9+8GztkNEHaKKLmmfcfwumk5aYu8OXeSp+jPbvAMvn7+SqPf jjqfzd8cFSQSpv+3pcvtLPGlQoFsgXwS9vF+wu/XtgMcPM4ykFgTfJSRNwU715zpFaOSnI4XWRHc qHzRUW6z7Io8GQ/LZR0LYFTgP+cmYsY8jmByvoT/qV8Co0Ao6M3frTQv4INHD/m9MaWMmqoLALk3 JZDIu9lJzOrK77ZqAYg7f5HMj8XtEhTLznCVX+OdTdkEVsoxb/bCpAld/NNdMoDY2vAjd49XzuhS rgl2+InXxuS2+4s32WGrsgHizD2RpSpmjFuV5sIuQvQMnx5AWNqXy9nVLUrBnd7PO/GtnBgJn1eq yD/64gyoFOX1tIQV509suLjIfJJfcODz1IX2YptSQfBBOWs5ceiF+wVj2RQfEX+JkqGqhpYGmq05 jnPQ3obfgjllAPkte/wwfAeByiopH/BJFjVF1cKacpc1CsGoonQwqs4vFcQ4b4c+BWFMqVfQ/nrl xk96KZCXVFNUqbKaNkXVWtOkljY4ROgQUFTf1b1yJV3KA8iHKMEuuabcCZC7faeyukwxd4CIjFlN ePFD1vPRB3yUB80dAXJ9OjwQ1CNd1hQxDWGjonTYqNXq7tI4b/2pX/luHU5qLw1cZ3L35uh/wuLg zVwVlDYc1VrDWJeFVtpLQwBHfU/34uApluaD8w5Uy/fjCQf7lG+OkN3WIk4apdiOFfVcw2K5Remm qvjYEgEQh0+w1g0he/j4CiOWJDmWOOL2yiNomJBQqBYUyxuCQkVpoFBT15OCRJUsjEkcVH39gQGU ydABFDUHlerJ0+agWmuYyLLQyuzjEHBQDXQwSPhp9sQ0g0SG+KviQ0Qtozfc9jpWGDtHX7EV+2uJ /DZAZpwPlTLDrgHk8+xO+YcSv7jsfX7yDS1Y2ZmYoNWCBKyCt4j4dw68KUvGoFIaQBAMKkoHg+oy GCDO+n2XmVBDZGBG64YNtJ4icVApeYQ2B9Vaw4yWViJkCDCoI3RwauVBcf0ic9/n8GO2anIp+sr2 gbQ4aZBLU9VTWXdrlt2uKRhb8PLat9R5a/vrpBSe3k3YG0LGsmhzSxdoGMuy0MpY1hBwS8fq3gbv YiWyxVHtmHh7Q1F2qdAQv3qAi0emi3mo/B5ATKbEqnLALjzBQ8EGSFFsDEAKMwHy5HR6Nx8gp5zs ARKxDyA5Zn4dmOq3L3JUvy3sH7qChgvpKlHKboTATVFacFPSPSXjnPtBQcbL1ajfirUDPC3/0Ysh b6kmnFJAQShtwukCDdNVWrmoBB0CwqkOXlTSHfE7cRwPqXMaJrcXm39lY9DGKDhm+1OvsUG0rd6d Vs6hvW3wDpMaWIoyKcIaAixFaQFLy8jK2r+/Jlo+WBE5GPdXRJkKvcew7Q+ZnaJNLF2gYXZKKxe8 oUNALNXBC966OpP4Yp6QKz7Q0HO5pcETa2JXsxql/E6H0lxVbijiJ2GFQuzJaQ/biGBjcWJa0Azc vmmjr3x1L6co9whAbm8M0gfIoRtyQ4CM2AYNFBKp1IJylghCKkVpkUofqk87qRLF1OqagrWDM4YV bgOEhg9h176h1pABJ9qw0gWaBpyYWomT/yXv3KOauvI9vsfeXqF2hplp1Vp1qDpXXaC8ck4s0pKO luodVKqA8QHGjq3Yai9TLTpS5Uzr6nLUKjqUIlqbKhXKK7maIhXEo30oD+UhBHyMpqNEeUjRY6Lm kLP3PUnUnCPZzVrnZpE/soCVcPhn/5Ef3/39fX/7swfeXI/0wRnDY6EHs7gpoYu/Yxcqmlc/+HVs +8bhD3/GLF2dMXHBKPXWYYMnXNUUF3Xhi0Ew2yTakGAopDJJFFIXqvHEC4+ud3vbcaFIXbn/K5hV YiikMskU0kg3o02ekQ0vUEh9UDYYWAiLryNQcAGalDnmOLNqChfdcO/AMbqIKrLQnXepqqGjFOYZ z3CR6uwZAdzcHxCYk2Kc+z0CCe8pmnMtyhbF3UHH9yPwv0PNAdzfsXeJyAQs0gjx5xDjyCWxSPsr xyuC+fRzjttE6ur9/4RbpWsWqUwyizTSHY3EI9rhBRapD2qHaVKA+YNQjkTgU+20EwgoDyPQrLL8 WfBcs6PhbPJo9Z6KKAX51pT79zbMj6cy1/1of5uoPgO1d4oVuZzqxnxKxtL1+P6VgD4aIUy8CQx9 lJBEH20UVMsymf0+t1iBtOQ7pIXxj3W9SiIMY8gl40cj3WXenqmWgTfkv/NFR6KlmCMsrxQTehH4 ILjheBXvQy51B1jVNHdTG207exGcWqJgMhC4d1g3VckWfwz3qYwL9wVzid/xMqNlSuqzYdG/qQKl RUlrqSXwF+pFcOMIIfqIujbwhCQMaT91aZzXMM2pLo47R84U+Mfh6oV0WS+EZBRppLs7RzxRL4QX UKQ+qC7dMgT0GwwWore24gwC/E4Mzo5iNDoFpzyLQNYca3F+sWVI9Jj39dSYlB9C9mjbJ93/OG5M fHUC81u7mmyyqPXw/UCbyGC3YUQYJhsnMPxRQhJ/VORZZI5CcUIWz01zFEo67owS4SSQPlYoki28 u3zcE56F8AKB1BdbXWoNzehsObhNWNKD6zNsDa6G7sE2YenQRrLdvLAoSgLtwnIgp6XBkmhqMH0P mXlsLgJBx3PhburKn1XxCqOyWdEc0FejmonApdEbxyGwKs2UyR3C9okJAaBUJmx/ERhAKSEFUOpC Zn4/c/yNoFtdKdf3LFoU9G37nUHgzFzsrsxJKBX1iQnJhNJIN8m5Z1TGC4RSH1QZfR0C2XQSArPh 0rLVCBhT2xTN1O7JSbRlsbnBZLg+ZE0eNzJalf0/71N5KXVMaX2maZUlI1GXGqgfsvyKomjY2WNU QhC1F2YEqa8joN5aYKFvXMXuzAgBgjRCXDKufT8hCUHaX3AGPcIsysIcYTxfMpgeGeGEkD5WMhJt vzzMXRjvEb3xAoTUF/VGq1Ux3ziNTP3xKqq2+aGPmcqaebmJe+hjclq0lnm83JymjkWGFqqYg53q zh0I/G21ah5tjOX1ZjS8ZTTN4HQ5TYF361WvUpcisXNahABQKhNt1jCAUkIKoNSF3AhrJ8FROxP9 ozGLdCJKH6sdiU0AeZg75oln5GbgmwA+KDeZbZQluZ3Kj2LIGd20VcPwBWB5Ps9sgMr1gZ07rNuT qRiW6t1vmdbNhjYjsDGgdriqKUPd15HxenkJlLUPM6tPbfjoiu5+w86EPoqm98X3QAjT4sr7+vAn Rggn+5SQidoBGPYpIYV9Km6f2ZOZ6Y/OnMueeJDnL/TT4wrHdZ5PSAWgysPc5fkeKRwvAFB9sHvG ZBTAwuuUPZfJMivMcTJHLqMuRKBovdoezFxCYCVlHKHonMFoDH2LEZhYYyOlZK9F4KLB8locO9da fCFHF7ocO/hFRGDyfAJDLyUk0Uv1zkHJliQbBLvxUdfszAlHnn9sjJ8Rt0bXeT4hFV8qD3OX53ti UpLwAr70ed+rk9NsMyy9gUCBgrtZQpUquq5Q7BoErtQK/6C51hXA7uKWVmZ+reiaYf7o5+gvESgM bB1SMCrk879WvPfdWQT2lBgsRbZXfO/MCTYlRNwEAgM2JaSATV2pym8fZjLLlz6I+4f6v4hZpAzj /qWyTeVh7uJ+j6iKF+CmvpjJhJYEMoVdKmat4d7hY3Xdg61F6TnWfeW8j4mwNdSCvjjIu5x3bS6H hm0IdM2IR2B24K51vKIgwM3sojrzmBAEbHPHhaPjOCIjpjf2Sk4VlkpHyAT2X/TfG8NHJaTwUV0I TJIz9j9zwhH7n+nD4X8ImevYn5DKSJWHuYv9PSIxXmCk+qDEHDTv5eK7Apm/NNw7XLhxOQIJ7Gbr bh13s0i1kNZH70dg/CRbxeRBPV8xS9ZZcxW9Y96nLtJcbD0CWRO49pDMPiVfMOsNzJsIHPv4wlDb 114EyIX0nUTbK36DJsCeEqL/5xjsKSEJe+pCc2QvC7yM4/R73WzcaD4hAJ+KxhWkgk/lYQMxCUB4 AXzqg6rzU4UW/nEJXyexI/md2effhhQjsGX419S5UwjcKwgZUoTA1ZiuQNMhmuusK2Nz4UEjAjWt CET0ZORThespJo0+U6kqVHctUVn3pd4JXb2kvaoG3zYTkFBFp1kIDAmVkEJCdaE5Tz9KaUbsDran NGdl2IgTQ0IlpJJQ5WHuZgE8IjleIKH6oORsbg00pxZSNXsVQa7fXoJ8eVTzOpQb2DvmXVsfoH3j dDgr897OIwiU0YxdlWb0VSdvsX09lBnbK7ZqnOxSQibaBGHYpYQkdmn/aWZeacY5lcZxdL5O76/A LdM5GiBSGqn4UnnYgIwGeAFf6oNRzQ0bIaKMNy7tp1KMwZ/boCttvFXJGqH+VLOatsYmU3DW8ox5 lRnZ1iVKdp1leOo5elstAnMQGNvDKm+vV3Ua2pfkILC07hwCN0ekq7hNeG9DCPoBQiQ9gWGbElLY pi50ZpZzlubMiXkOb3PZ/78xqxSgTUVlLRVtKg9zNw7gEaHxAtrUB4WmwKyFiS8r4SwEwhJgme00 Mb8bq1Fff0rdSlsSzCqLzHoyjXqdryF+T5afWT1caQ6wRKvYFdYPRY8TPgj5+m7y3Js6qtrxjZ8I cOJHHxMaDH6UkIIfFVsa22Rz/AvBD4um0XFpSkWMXwtujc7SFnUtpNJH5eHuBgI84mcGHD7qk37m JJsNv07rZRfwpn76U7/0m2mVwkhQ+TquM10eyOxRNC+EpqqRAZbZgZ0lCKQv+UfV79LH4gvF6f3D RZ9CDPaOkIK966cvz03a/bDbvOLBhSed/jGYJQqod6L4SCr1Th7uLvz3jLgMvO/3ycZZHUxMVnFR 1q05baGWxDTK1MsEqZJoY6IegWa6uiK1J9W6KZgj3zdcNFj+U8m+00nz5uVprUl/PmP1TUXk2sDP dXSt4/sXBCUSVycYvy8Bi/c47KUx4dEWrNFx60nebb85uCpxFrJc9Fyq1w93l/R7pEq8wMTzQdbL YL3WvLh7ODcplVeEV9gyWLzxLwgc3I5A78zA+bQ+tURl74yl7Q6sK0RgVkpfY/LywUwX1TwCmoYv /NBaoTadoqqexJaHEIcnsswYHB4hAYfnyqYIKuTBmf17uMuACTkm45cKxJOHD0jG7wUgng/qSAN7 B4Hg35TCfdaTKdx6BLI3z+c9O1yqg8d4x/J9MVVAhSWH3v0Gxu6DewzVw2O5UsU/b1D55cyTvI1f Gdd+1NBZav1wbVXbystrq1pTrReWI3D2M/4V30QWMPJEzGECw8gjJDDy+onKq4LUsvFVe9Ho9vkd wixRgMgTbb6kIvLk4e6ifo8UjRcYeT4oKy0IbF9FW8gU4yL17dIcBMaXWIvjIXkYgXa9OnuFSWv8 BoHZtMt3+LJwgvWIMHFZYMy7BLCeKzERVcaDPL/O/zXcKjF5vlS4njx8QPJ8L8D1fDJcMVjmc0vv q6v3m8thIr0gegIzceO7vKyktgZssW5T9S2inlHD3Q3VZQiUFdyORKDzE+HjyvjanrjgspdKei2H 6xHYO4l/xReM4CS/qEmMQesRktB6LgL8ZYIAf/qDAH+0fxRmmS9iAnypbD15+IAE+F5g6/lgw6vz eDlVpIFbrMX57GVYVMlOYDR7u9exRb0d6trCq7eifxX/408bBhVsO3H/yY7uprY8/AylgLQXKcq9 MaQ9QhJpL/Ex9rC4GNbYi6FypF87rhgw2bxU0p483F027wn4MOEF0t4IH+xq5Vp1vOO4bK39LIWp L4XqdXeCFqrrppazGw1nKnp71sMDUdzL3RrYpu4aRzdfcT7K13VU/kSN7SxhQ+4HVlesjN52fDAz Sb9Hp8SWi4C3J+ZaYHh7hCTenvj0pA3MOn3ZIw7M8hX7HTPHb/hPxa0Sc1xfKnFPHj4gmbwXiHs+ mMmbQksQmDE5fXgrlfdZ1ZBuRVNd0proPddyTW2jGvIrEOgDyRT39xAansDe/k4IUHsviuoAg9oj JKH2+tuOBYKovfFB1F7qPwOzSgxqj5CK2pOHD0jU7gXUng/ajkpzMUzcuJJNhNM03Du821AtgtnU zmJ6EW1UttIHVe0TDRevdZgDO3XMOGplZl4Lld9QvZ3TRGfOhXsVY3syg4+8pDnP6BC4XqeAq+yv 2IIR4vZEtgOD2yMk4faERO9l8S+8vWrFf/wxa83Qv5lla85+8vSzScz6X9W94i/HrRETskuF7ckj 3IXskR4pl4F36T7I8zbtKLXuR+AJi/KrtFRjwP3A2qpxxdRE6gRMPHGDKtoOc5N+s4792tCZ/eDX 5M3W/0KghOL+4OodfsJeiNoT7vZJDGqPlITa6+dIxj0i35+pdpDvK5r8/uV6jaQTtPdYpUh15xHu YnaPGBIvgPZ80JAEJCKQOPUeu6YxXcsWttHNX2zSU/o5VfBz8zlqJW1+3mC6lxHj+q0+avOGp7r2 fX/8ybQ5/zYM0s1/5+wvVEokrlJce3dSEmRP0Mh6xlYpX76+WjNIm7Fck7tr10ex0aGgkPb7K65O nLU8RfRcqnGPcBO0R3jiEkbSC4C9Z31QUa5orWk02Vmlut+dsbI5nb7dam0bYd60VdG86NuGklFz 4R79qY1Lr2aaWjV1cD/9z5t010hLiP0triZIAU8vTFwTrg06KYmn1189HnWzxi2zd7OKdH7puCU6 y/ZF0XOp7jzCXbbuCfEgvQDT80HxqGfbEAjKKOQU14dEdaushWyBCYHdk3pLKaagS90Ml1YYetbA rwzwC+qF5NS7RxGYl4pAnGJnSHlfEgKFUxAoUFcPX/BzwMm0HT9Z7W+Wl+j3YMe1SCFET1QyGIge KQmiJ+ppLbP3tKY7L/SVjXvGkYgM9icwyxRg9CJEz6Wa+Qh36bonmlqkFzB6PtjUMv+h0FrY3ZJe wBRo53apa784erP3WijMvDO0IYUaQZmo3ZoPou7XIZBn/XEVdenXD3+wwTrp5OTJIkV7Fwwnj5TE yesnJNOdfd43i+x93god7gYiMty1YSclY/Ii3MXqHlESL2DyfFBJ8sxtMHEEfe6pzDaVJWE5AjOD FMmUce5e7oUKdc978GC7QyniOY2i5ZjadMcyqIsqO83mZNmlZVml5tDltgU/d7+cUmLGV4lgJF44 SktiiHikJCKeqK01ztbW+jJl/85HdfKAi/97/0jMKgVIvHDR6iXbdXdhuicaW6QXkHi+2NiC+61H DYOpqqGd3HTLmuO/sTGMm9nNzI0No6FpfmA8nJt5i2pfsDHO8priJAK73jArjM8hMBjG7EfAn+7Y DHeUBtyfjcCrClPaCuq7VHYMrzPF+JoR2HaRAcDA8EhJMLx+yvKEIHIf54jcK7r9ruJKxnXkTkqG 4UUMROROegGG55MmxTYAnGToQOD0Vvwv3YoyA7s3yzYmnKa+2MvNrrFPCVc09KyD+Tb1ocKSl91f d0JzyBr1k3IBHH0reHfSd9exqSMpoOPJSNEfMOZeEh1vXj+t+cqpNY7s/eg23ElFEkPHIyXT8SLc ZO+eaXl5gY7niy2vErWxzao8+CYCIfTVquAJljQEhu7SZ2QrmlONC0crO+M5OUx8+GARZR6CAK3I fRuBllBohW8VIPA63XfHkoOvEcFd8sJknsRA8UhJUDwX6iJogTkuk6/Ixl0JSWKgeKRkKF6Eu2De I+riBSieD6rLWXjewHxTzsbwnmVVqmXRYm6sjjoyxVo6Ge5KjrtbDqfvhV8orkzj3QrNjDKYbkOG NzGlCOy8zmtK5r2dlYNv9X6YvMmmLCdtyjL+KFmDnYAkhUQ8kYXBEPFISUS8x0Rlqb8zl/+1PZev eNEPu0LXV9OTkml4Mje5vGckxQs0PF+UlHhr2ramuNutoTGK0wt07A1mQgk8at3SrdBQY9OPIvCc ote4BoZRhtob1qW8muClw8m2E88Ckxi2HSmJbfe4dDwR60zezzuS98ppuIOJJOE6eSclg+1kA5G8 k14A2/mgchRwRyj9nVtUX1MCAkca2OMZAbyZD1LfvYCAsoH37r0xqQisDDCHjuPC6Z2TEeh5Ax5s p/KnME/SXImi5Vim6RR8pTL+8tqCip64tGpNzOpgfLkIfLzIjWCwdqQkrN05wZHEmSfPn5j3cP7x 6eo0200QRSf81uFqxfUxd1Iy0k7mLn0P90SteAFpN9QHdeMltXlZMDvZqlmyOQuWvEXF0Nl1jQyl /0TbUc4cHYrADxe4Z5UIPJNimquyzlY3JXVTxvAUa25K36WcqQbLrIUIjF8I7xrry2H8MKrmM6rq KD5OEdDsxLssDM2OlESz668tj0zJMkcuX/yc34e4JWJyeckkO9mA5PJeINn5oLQo7l5gE6iaYjrI 1btKroRu+Ze6cwoTTF+s42bXwCxqrPNhSH3Dgd4OdXVlVPQ2+gA19uZNNgRusW7bkbT6Gn47RuBy eQzOjpSEs3tcX6YJDvaedxx5r6jwu4hZoxNmJ96OSYbZydyE8p6RGC/A7HxRYgLvN9fDbKo3uJG6 FhfFJiJwTPsnBLa/1NuphIxGb0q8eHxrpbJpwWQ4BwF2UTnXXjIMgQkUN3kxZOYPobJo+Blv7Nfj N2ECeF24aBOGgdeRkuB1TYIAMj6W15UhzinIQ4X2KcjKbbjjiyQGXkdKhtfJ3MX0hEeKZOD9+3O+ VyQdvFMZfluPQE1ZEwKrQq8VI5C1Mg+eV53mN1/jmzK+ogp5FxOnYw5wMxGYFwjVKcYYdhf8SsFF N9SWpWsZGcxV9TUuqlJaRiAwS8t1TF5SbP0EgXwlNOHDFAHNTibakWFodqQkml2r8CD8dPuebI0g iFz24CD8dBzJnnQS7cRjX5KJdjI32b19xPj/XzwDb/iH+aDCLEZAz3/Sc4zBTbyzny+Dqk+1/0fe mUY1cbZ9fFqrQrGF1ipFxNjiClWEkMGtjJYqKiptEVARYouKC5aqWHAhU/WhtipEQau4RUBFCBJR AWWLFgQBJWwBlCpqWIRIkZAACZO5nwBqMk+Z5j3z5siHfMhJMgPn3B/mn+v+X8vvnsdXLhfIWd8l +ipNXr/2sfH4tQA6n6Z8MVYEoIQVaJPK/e8ymA6g5j+YChf08Z/kQtHA2RGFQuLzKeDsCNZFJRCV TNSHDPkn9RYdM04bvCATiVrLBOtCGWhHfyvV+gEA2umhdWlNr1LcaH3ObvTuXAkgTwvlR5g4W8xs FvFjkDPbmB4Aqp9XAaBoTHxSkQYgq6lxSuPGVVVCvvzb7chzdKa4RuqP7/HexQrjlFjzAkqvKQb7 Xz52lbyhWANwR2xwIQHcMSgB7vqLLOdWv9mVhfbuygpbSJvC1Ig7YlMYZcQdXVuhXieBZQAQd3oZ WFDhF4Im1O6fH5KZpXLrEUpaRM+H8cy24+gFNP9PlbcxC1J4YrvfXCGXh9oOTCPU80hIdgwKJDvG 9RKN2fmve2bnb63SmJ2v7pudv29uuJhklWqYHVEelGF2dC0lerpOnP0AwOxoegggcuSrnvfjSmZh uisPQHmqrZWnJClSDKC2KFSIJaQJ+bLPedKr3BDVBu07KwC5WL2+lOqYBKD4wN3eco98Ya1sKvsg 36pakYFfKG0Lql+5DEC0M8r3EVHRIo6onR/tjO3Y4IaxgqSTAMQmPfmBoUHBYxAsNgkFj0GJgtdP xKGra5e5fRD7Qrkhg2yV/VPwGJQpePba6vg6iTgDQMHTx4hjqrIlIwG0AJ+TNVjlSkL5Zchhm7mo IjpAyq4zaOyKCEd/n6R62+/cZsYsp7VudortOsRrYnemRpdi8z2l+d01pNwihgb1bhpBICTUOwYV 6t2rkGOSk/vJ16PMT7xT8NrlD3fqdfl/njU0JFnfdA0BE9ZN1eXbaynr6ybYvH2T/47+KaND1iKu IT1bnqFBsCOWuUkIdgwqBDu7ZWp7bvmPX/4+4Hy6GWkHlxpgR8wAUwbY2WupxNN14s8HAGBnqX/P 9989NMcRmHO9UbriEX7Js412dKpYHKSIZuayvslsTEALrwrk00xPy1zlHj0193fbz8arbHoRUnfL +zGtNE5py83IUdgD6CIjKBidz5HmJXBqjPFvQ5xFrt3V7kgqDYtRsPM4nVcSUH9EPk9GC0Nav0dB SYqcI3UC0BgPPh3/DRUVVjWgpcbYDvIivgb9bjrhZ5qEfsegRL/rb5v1JmE8vK+Mnz6NtAFfA35H qJpSht/Zayvj62SXNQDwOz3cZbWiT+dxypB7GbVd3/pJ2e1TO/FPVigtsbuiw+EzDESHue7YdgCN xOet5Il4XWkSKyFqgd7hH/kXTahJeMQ5YRISHoMKCa9Mo/443Kg3Pawhib7R+atSMjA9YwZJlZ4y B89eS5VeJ/XHAcDgvaeHuyvBC34lvraF8wC9jBXVIFcB5PUv4yVqjh0dJtTjSDh2DCocOzuNcxgq vulNXi1+k7rK7aPNZ4w1qCVbI0m9nTLHzl5LvZ2uC+wjYwA4duP08HmfjYhe4KeOJz8FEM1P+lcW 27irG7lY3wCgGiflyjgF57CNA/6Q1ixEKrA9O/gdJQDyiMfj6gy8h8sZ6CD5N+kTJRvxoZLoQNc6 IWZc78lPNcViZ7KlXADtJP/CBCW3AXQebbuzT2XyASQ6OBQ/AqB88gK9BgiPsNuCSUB4MCUQXqUm l6Vvt+WmZlD88Gq2PsfQsf9VwmoUHjGpRRmFZ6+tPk/XidjevnU31UNr8wDbgh/BuBl+bfkKZ0lS Cyef1kQrDGO21Y/iiwoZaP7RYahsjkoXfOXTu58CqHkPgBai3TmHbQEkHIRHAKhzP3naVwOAZzuN 8FD2b/1hKgA8O6GGQoZv6xneSvCLeTMR/ENfcf7+cEMXMoUw+lUITBmCZ6+lOG+vC4XAAwDBs9ZD cFEjyg0D0CLkqI1PkOJGrTRW/pX6mnWrYuITHv85Z282gGJYRgI01bWti9bEv5fZ2b1GFcD24Kew IvXVZJYq1EziKRF5pY0QrR8BoDgAzbyj4GExfCmAGlVBqEzRCSArn4P4H7ILslZ8WZapcorYRVyL xe+0UXhVoh0BnY3YFj8ArQMQC80f+eoCqQGC1cQ9BiG1DJMQ92BKxL1+wtRwdbX/975qf1G3oRPZ Kvuv9sOUoXv22qr9uhHh288K6GOYeo7TGzyDnNs4dhnpyCH5UQA9MJZGAmgNUuaqPKwKSc64fVQ7 Fkp8+xdNaCQFNHPSMAlSD6aC1LMr18wKbOtRhEZn5fC+IfyMQoMmkkVqAPUIwZMyUM9eS4XfXhdp AXgAgHpf6J8kmpFUtO1EbRlSnM5u4WDrHKTs9qTYblVcMAtTWmLim8/RZgdXAEUI0cykxmgAXXqE 4C7uuCTj7H48NhBA8ime3YW5+AOO5GhBV5ok0bUlCkCTF3MOolbqq7xJGYdQ6X7WvHrTLWz8cOvd zJi/VTu/Mgu5KSjxF8j8zPGFtM6jDzjNxQ5YBNI6+RoiPB0gH4c+9jBVzqlt7C4yws8FtCvrQwH0 jYMcl5AqUo3zY/T8Mmvc6D9vAVPB+dn2JK57QEuvYpSli8axLRvP9XVx2ho8JVtj/3kLmDLOj6Gl P8BBc85/OnVFvu3ExcfQfD1U5BDW/IeP3NYV7oGnBcmDR1QMw8JS0i/eP/au/+pWyUvrS2Zy803b l5yyeq/6dm39E/df63Y+5Y3+1Cpn65c/VYUPG/H9zTE3NuUPef/aJp/KQwfYWSf3PXmaK7eGU1rW 373U/eCS44ejXSOIN6faRIf8xI2XJYZHya5ZVEf1cM1G3jjwpOlD0dniJ//P2zagpGVbW/48X9cF aS/WluXZXbx7QuRvgkb9fLNLFJMcd96rw67J18xtzeItqQbIvYxV2JbS5eVlU7rNApMPxV+dML3m PVqDj5ewPTvZLWp9882bZl/sGOuYf6LLedCTzDRuY8gPcXalwm1b7ZZL5oSwbV+GD729I8CzWHFn 6drYhIa6Ncl1v3SP8X062njvr9Z0l4PJt4f6n1n9UXvdpB+u2d/IGG3yc0HlOzTHr4g3p7A4slli Z8/oqu9TTy9avG9Nyn/Odvu6ta1UIs1BleE8p6SczdOPRg0p2GT4ZUde3LMUBVrRetnCZ7/3rw+3 TLb7IKLy410tYa53UFBaz1QmZV/1rOI2PeNvTxpXPQZ+XtY0YXe2rJDf7R2yhsfzLL/DEq9aeGX2 5tILZYvlIeJjaEe6ooDpw4s7oKy8Ebk6uCbW5XyUpLuy5ZHz5K6q71Z5H9v3ntk+3w8vzwwOMz7h lbZ9dJzIe+GWnz2Gmaz74NDM603P7B2///FRxVZO2Pbxdx4snzb3BDytuTzutxJ56GUZkuQeyYxp /LLRyyxz09DDrsGOm7ya0VXcCfx5xbuKU+nBlcZjz77cXZlWgd/0WMI6eLrzjP+6tsQxc798Ir/8 19mUvQ0rQr1qQ45fT358uOP6R0O3XR9Un/CoQLx86toT7lmdD3a5WDQZb5prEjRrjuNK0n8AZTZe ilNl9La2U5GRnq48s7qDm8ZXzkgefLUFQux90mQO5/1EIoeJE5I4PvSCkZUuidt+MFr7EGKtzwpo DlggyM/7cekSb8dMv4gpiceXN+SOLLoOYcKE7KyQFQHLbj0PdsiunH3A23dIQ2XJI8bsM5YLw133 pnhW8bhTmk9YGA/pfJh/xCVx9V8PH5pfjIs8v8G24KVHgkImW5vlNij6yePu5ZLJ2w+Zn/JyCqyQ BIZNmOFowPTBrwWOurI5L2/z/I6ytZU3FpY7jYrwKzAS11b+uM/jgxvV9y89frg4vcpw5nrf7xbL PwvZpbhfsvF2mrlZinnNwuMrn05cMmzjQs74+ukhPyuSRkJrs5/Nv5A9WzJ7bumOpTTvbG7oL2YB N47EB7Bns00Cfdz2VwUkPF09xOvvcRu9RALLXAtTUN5Ik3Uj5hbhF39ZEuNS45s6HZv10ZOb+UqW IC/fN/7c8PURHdUt4ciHucFTtwCIea0tubp5/XsPx2WlzvJl5ySPMZpc6826cvpiXcD6h36rf9wv SsSt/2+XLjQjkvMFIvkMxWj00x14wMmmnWws3i4YX8raT8sbg55qSPeJVTnOxWeRSE50ftt+ToP8 oiIZC89GDgXRyrDfsxNRSx5bZJEv5X8ewKXdFYu68rcobe7yQUU5vytWQKuuPAOgO2OC8bzrrfik 9vwORiOAVvJnyQMQTruoSH6co9yItdZn4qiAbdPgg8q47fw/2uUAcpzNj9oyQjmhXbmU5fIbr8mB 07xNsmoeujATQG6ciAzVXsbyudJG3I63PcXGB+F2zqUKZlWjUpTTtagVW8OOlfJ5gu78/S+PA2Fb XmdjeFG+ee3ZWTajA1jBL1JmOktmC0SsPQrECd/7cuUZS/kYvzb+HCVNtRmaGzxl6RGMTe+qPcdi lwDoXOaIQdh6nC4XEt5Im1pgNVfVdjrhuGuYBKwKUwGrur22D26DfHsstaV65mTjpd7dSrLA4CLJ EtVQVQKVCKYMVWVoa9nSBZUIHgCo6vv6t1lJk/EA9DEdZ967rNwEoNyeGa12a3QlgNoskXqsqBx5 YbjTT7nHZjGArownl4G6t2s6wUeToFJhKqjUKnVqyW2Q5diqaoOvJzRavWz2azgZNWryjbr2d6Gc bsNPyGTQ/+gVTBmUytDS2mWrk8TSAIBSP9A/GTxBU/0w3s4qxQ6Mu6fH9WaJmU2NkqSh3evQws7L aBynMM1aJY/vIwHkMgp97n5wKx+bb4ZIk+Pw0OX/c4tUJRpYVFvCTzEJFhWmgEVNWaahkZ7TGzRj RWJfrCgzuEC2QnWhhrhAqtlXhpaeLFtd9D/CAwBFNdZDkfBTnfFxxok0yYaivfgDWtdhxytoQdxU o+416LM5itsAmnA6TOYQfhlAizJbFR9LA+Iztwco3BvRkuOxIUtEXLSMNwv/TxZ5OlaTiUpI/pAw UWEqTFSPNwKxtBy7Ydi4sE8iXhEeFy/pJTwm7yPdS6l5qIQWZpgyD5WhpUFLJ/IYABzqYD1sWCku qpll4/+CdN4WVhNM6cTEIQnBFKZAME1Rt2RV3FogWHC7+q7J3aXF7k+EgnsMOsP9px4WXc5yww/J 1kiS26TMMGVo6cmy1UVPFjwADFMT/XvE25FEpiS6GZWsqy3MFIhNsUs7OVhUmoRHV9wBkNWYOFUI 2IxxvbqZACqMiwVQQTqAHv+R1sEH0DFXZwBFbgdQ1pSAFlT112fZqr8W93ZckQpG44hRwn6EBHQK UwKdapxa4mZpUvXpgpOTx732FSf7fEVhA9l4OkwCOoUpg04Zb+PMEngAQKd6eGZJR+Qt/Ah28KHr IIWzxGbDbOMm2t1Djr91WRrHOBrkPGfvDWwizy2puaV0B8Jug4RbClPilpZoumqnsRv811x60zO1 sa9nKn0n2cAUrIEuJTz9lNGlDC09Uzo57A0eAHSpHh721t6axJfwxBzJztrOC4213mg9swqpk/Fb XQTZqsBQyE9CC8To4z+8HCNZlpLE1JAJmHP9Cn/Fki52YXYogG6vCDEC0N6rClMADV5LqhMNZKkt IbVDgiyFKSFLy9XTTm6WvY1Nlk5vmjjcjPqmnY6QARhhNbSU2MRBGVrK0NbX5KATobx9Z22uh82F mTYXIpUONl5/KlYg5Vtfff28LsT09euz1VtZk5aP5hwYOXTisyRuQjO5GjRamggddCQ0UpgSjfSf UeOcRq/txvi+bnQrw9kkq1TzSIltfpR5pAwtPU26iRsDwCPVw7ghweNxbgOA4h7gUs/jMlcZ00Hp KOiMyeQnoAlyflMHmjViNCJzHq6cwTnmbKz8NhdAS/3qv80B0LItSHmU3LMC6Xg3OxpAV0bIjJW/ kJ4pAmtQSe2IzyGJI6dEJe0ndAxS9xut6+s3KhpBdqIurOaS/o9YqHpyWBuPRCexYwC4pHoYO6Rf GMt22SgZADrK++oWgDyvAqicKV+kcT0pXHDf24JzMn0Wwljr0NW528MNZQfd6f3ozrmH89q5SJSS 2eiB0hX8YvL8lQaJ1I5Q6yYhkcKUSKQlGmoZ5DTY18lFo1uW3kcoSTc0qCJZpAaHlLDRoswhhbWV u3Ujlrfvxz/SR0fCQyWpClWgmNgKoF3WguwslQ+pERtjHL7yBc+xZ+bCOiARkbAA1Hn12kxPBTcU P8OsX3HGWun+pyrK8CSJxcfwhKdonKfck89DffB/kYvGuSP2hEeUxL9T4pH+M7gQBWPZB+792/Ar MsGox56IoqZq4WEthXHdRJcBYJLqYXQR0wEk3F0rt28tTL8HINVODF8yS5J0DVF63gdQ5FKMe5Er N3L8LFCIfuaXO/Ukr+6LrlDXz9zuLpOY9EaTfXKOEA+k9QQZ8m0YTFYYJwGRwpRApETP0qsT9VmI 9Fe8klDSVBdM4uApc0hhbbVxnViWAeCQ6mOqi5PEl1zrqYH3BJad1sWsngSXQDy0J7A8581QiFWB BUmk9QaWmOMVArm7VCDNwSXfKaIAZJUdhZ9AHy9iuiH1nuVIuXF3AXMBgGosQiwB5L9dylYmk6eJ NTCldEL6iwRTClPBlPYbZtRzfVG/9831nSAdPyfBlMKUMaWwlsq5bqLMAGBK9TDKCIsAdIy/CkBL 8NUpWwFUH1CFlKMnpqziy71kAmltg9G2WKW5I/PYj4ForF+R5HIxW+ovZ7lfC6AJjdY9RhJG3s9E l1mhp3CWFacBQJwDcXL+f8k716imrrSP72mXFUtbpqtaalubVmeqCxQQhHOorWm1FN9BSwEhXsBo nUqtdnhHi1SrnNdxzetYq2it4j2DF5D7WylSQTxqO8qtcjPgPVZACEgjMVFyOGfv94QgOQeym7XO yiIfsoCVQ/iyP+Thv//P/9m/3XoHvzUTcEj9xTWD8f2SOKSDBMf9de/HdJQqCx2luBR3924QgUni JVNIg+wl8Q7RGydQSF1Rb/LzlfofrEbm0plSqqL+sY95izHychP+2MekXs43RfJyc5E6HeybqdQf 06q02xD4cqUykm4J4/VmDLzfYgjlClJrZQ8vKd+nrgfjZ7QEhNIA0V4NQygNkkIotSU37laQY9Ws 3uKprMEeI7dySgfIjeQugD3aiWPkZui7AC4oNymNlCmumUqfqg8M7aDZPD1fAaaXjxg1ULFGpt3G bo2jQhhKl2aa3sH41iOw3qPCU1mbrOppS/6oKAcGNL9oVF1Y949bBd3V2+f0UDR9MKoTQpgYXtTT 8ztnRawA1CkBon4ABoAaJAWAOqB99vqyFZ+m9ecyS/vy/GexMSUGgBokGYAaZC/Pd0jdOAGA6oLd M31yBsy8S/XGMjuNcmN4gCWWUWUikLVG1ZvLXEdgOdUyWq4N1edpehYgMKHcTEjZtRqBaxrTB+FM BJt9NbXAdyl+6ovE5fkYemmQJHqp2jonWTbz3JWa6f3guqrpveqSvcBtI26FmDF5yejSIHthvkOG JJ2ALn3Z9arkIlMPc1sRyJBz93KoXHn7LYpZhcCtCuEf8praPZgd3KKSlOPy9lDjP36b9m8EMmUN 7hmv+hz47+K/n/8FgX05GlOW+RXfOLNCTaeIaQkYqGmQFKipDUnJE4T9Sy1hf0Up7mq4oGCM95eM NQ2yF/Y7RFScwDV1xUjGN0emz2xX6ldrHp04XdkxnM1am8oeLOJtjL+5n+Z16Bhvcj43mxwaNiLQ HhqFwGzZjiReUBDgZrZT2iN6HwTMM8eZY8K5KckhurBbqaVYGl1QsMD8izY5GDRqkBQ06iB9iRXc 13vDcgVJia/bTdwaMeZfMhqVsBf5O0RhnIBGdUGFOWbcz0W1y/QfVz86kbl+KQJzmE3sngLuXpZy Hq2elobAmxPN9XIEqvl6WZjE7pXr3viCukZzYZcQ2Dmea/ZJ6VHw5bJGo/8rAqf/eXWU+Ws/AoHz 6AfR5lf87kxAO50izEEIDO2UkEQ7HSw56fFWH/M3y6H3inLcVD6BoZ0GSaadEkMyBeAE2qkLSs7t 4nz4p4V8mYS9wu/LDvzok43AZs/jVN0FBB5l+LhnIXAnpF1m+J7mtJWFzF54rAWB8gYE/DuT06nM NZQ+ka4qUWaq2hcq2YMJD3xXLmwuLce3zAT4U9ExFgKDPyWk4E8HCc6saquluWG5+aQk3u0OrmBs G39CMvyUsDcF4AjBIZwAP3VBwdnUIDMmZFLl++Veth+vQ746yngV2ivTvfG5uQXQvH4GnJXyaPtJ BAppfa8mhfaUxW02fz0WGfMrrmgIK650SsBk0R9sdwEISbjSQXPMvM4cteqM5cB8ZcSIqbhV2saV EpJxpcRQDAUQTsCVumBI02rmQhTynqX5QnyL9wEzaaWRdyk7R6u+y1tJs2FxFJy1NDmyJHkXu1DB JJk8E+roLRUIfIjA2E5G0bVGqdU0L0xFYFFlHQL3Rq9VchuxtobwE/QChBh6AsMyJaSwTG2ojPWy 0hvvW1TmeVymSVhRpmKVkYwyJexNAThEZZyAMnVBlckw5sPodxRwFgJ+c2Ch+QgxvxMrV919WtVA m+YYlaYA9lwi9RFfQfx+LD2lzFNh9DBNUzKfshtEb8/5yuf4w7iIewVUmeUbOwhAWHGjA1QGgxsl pOBGxW7GTC6qGWk9k09YzuRXLB9B4BZpnf8XOS7JvFHC3iSAI8wMMeS4UZc0M+eYXfB4oo6Zyxv6 GU//3m+GFfKWKVR6AaddGyTT75PXz4OG0lc8TLNl2hwE1i78V+nza8fiK8VqECaL/ndjQHeEFNDd AHl5aeJ3/VsxywUnJf/l1oRZoIBzFyRauGTLby/yd4y2DL3ld8mWWSWMjlNyU9mvUxt9TdGJlEGn 91LG0i3RagTq6bLihM4EdqM3F/iF5prG9JSC+UxL88blmXyD+kryynvy4NWyAwV0heX7d/QkGFcl GKsvAYQ3GPFSM8e6B4vt3YMVyHCXzBEYEB4hGYRH2Iv4HVInTgDhuSDhZbg637igw5ObmMArwrtM Icxe/zECx7YioJspi6HVCTnK3rZY4h5ZZSYCs+J7auKWDte3U/WjocFz3ga2WGW4QJUOwxaIkIHn L/oDxtZLYOANdimC+ugL9ye7bcCt0Ha4T0hm4BFDEe4TTmDguaCOVDMPEPB+LhceZM/Fc2sQ2LUp hjfscFEBPM0blp+yqQzKL8734Q8w7CDcpynzDONy5d+2UulF+mG8h18e3nxKo81lN6wubVx+c3Vp QwJ7dSkCv+zmX7H9Y0KAxRMxhgkMFo+QgMWzISrvCxPLyN6y+ekrHF+VsKLxxCZFMhqPsBfyO6Rs nMDGc0FZuYzA1hW0KTC+Zb6qKzcVgTdz2OwoGHgCgWa1atenhvyWHxCYTdt8wheGFag3xU9cGBj3 LgGoN1hMhHVx3pLkFyO367g12k7yCclAPXIoknzCCUA9lwxWNKYYblG3qizNWASj6bnTxusnrP+c l5WEBo/N7BZlz3zqBRXcU11WiEBhRlcwAtpvhG+XRFV0hnsXvp2jM524hMD+ifwrvlwE5/dFHWIM To+QhNMbHN3nCKL7xX3R/V5st2uK7eiekAzUI4ciuiecANRzwW6X9kwRlZUHN7PZ6cxNmFXCjNfn 7e9IYrJ0baqKzDv3p/0h6j+31z2RseVs97C2jtrGI9jZSUKA1wsW7VgweD1CEl4vWkQbHlALRy3j +Klut3G1gEnlJeP1SHupvCOAw4QT8HqjXbCntZct4P3GTbZid7z+Ui5UJT3wmqeqfKuIWa+pKtZ1 roGHp3LvdOTBRlX7OLr+lvWt9IK2ktvUWG0O49MtKytePm3LmeH6iep9BQpstQggeyKYBYGB7BGS IHuiOP7J3mNfSwSH9N0th/Qrbo4Iwi3TmseLNoSSMXvkkOTxTsDsuWAeb/DNQSB00lrPBurI7lL3 DnltZeyqafua9hoaX61OL0agB8RR3P/40PAs9rZ3QsDXI0WFgOHrEZL4egM9x1xBzH7eErMX/+p2 A7PGQEzMLpmuRw5JzO4Eup4Leo4SYzaMXr+ciYbT87jPeKuhnA93Uduz6fl0i6KBPqZsnqC51tRm lGkL9OOo5SlHLlPp1WVbubxpKRFwv3xsZ4r3ybfzrugLELhbKYcrel+x5SIk7Ik8B4awR0gi7AkQ 3i+Ehb3jzuvGOOtx4fOWs/ZVqhGzcau0TdgjJBP2SHsJe7BDCmboTboLQrwN23LZNASeNCmOJia0 eHTLKkrHZVMTqLMw+mwrlbUV7o19Lok5rtHu6vs1bhP7ZwRyKO41W0/Y0XpCyNcTORIMX4+QxNcb 4Ejcxu7su/5kYlXv9SfFa3AX3xJBmIhdMluPtBexO8SOOIGt54J2xCMagei3HjGratbmM5mNdP2h jWpK/WEpPGCso5bTxpc1hkfJIbYf1VM3rXu6/eBPZ4Ylfvir5omCmM9++Z0yCcaVCca4S+LqRVoF xf31Zc+M/EvfvFaBn6J3Xiv7KbdNuDIJtF0mkol6pJ2E3d8RNy4STiDqjXRBNbmVzybSgdpSZXdH 8vL6tXRXA9s42rjxa3n9/B+rc16NgPvUF9YvupNiaMirhGn0t/fo9ldMPr2P2JIQAPT8xCWBceeS AHoDe1nWQfnFab2drKx4Nwq3QkyqLpmeR9pL1R0iHU6g57mgdFxiGhHwSs7k5Hfdp3Yo2Uwmw4DA nom6XEqf0a6qh4uKNZ2r4FENPES9Hpfw8BQCkQkIhMu3+xT1xCKQSSCQoSrznPubx7nEbbfZ3oel Oep9+EEtITVPVDEYah4hiZon6Ge9ELaqt581w0r+Xmw5OV+1dEQYZpUYah4hmZpH2gvVHdLOcgI1 zwXbWcbXMtnMjstrM/QZ+RHtqopDp+7pmnxhyoNR1fHUaMpA7cn7amp3JQJH2P+soK4/+/gHn6db sXgBwaL/0hgsHiEJizdQRo4LYBLLLDD8Yl8chpXAYPEIyVi8YHt5ukOExAlYPBcUkiPGRhg9mq57 OqVRaZqzFIGZXvI4qiViP/d6sarz7/BYs0Uoorg8+eXTKsMD0xPtVOFFJnVnr7IsKcn7/mbj3N86 3onPMeKrRDAJL9rfYwh4hCQCnqilFdDb0hJcGrHMEqNXhYwIxawSQ8AjJBPwgu3F6A5paTmBgOeK LS2Yxp7SDKdKR2m5GaZVZ54zM4vrmU361nVjoCFGFgUjUu5TzXPXh5s+kJ9DYMdio7zlJQSGw5A0 BEbQbZvgtlyP7tkIvC83JH5KnU9g3uB1JhtfMwLPLpo6x7DvCEnsu4HK8m9B2L6sL2yPxx5OxLDv CMnsu+AhCdudwL5zSYtiHvyN1bQhcPFr/C8d8kINs3+neTw4UXVNx80u750OLq7uTILpZvGh/OKW dCedzfuenXpbMReOue+9J/b8XXzcKIDhBYjyEwwMj5AEw4scJDWC1D2sD41/BguPsPLwxLO/knl4 wXZSd8c0vJzAw3PFhleOqqWRVRz7KwI+9J1S7/GmRARG7VAn75LXJ7TMG6PQRnFBMPrxG/MpozsC tHzvMgQu+0IWfpKBwEd0zwNTKr5IBPfGizJ5DAaPkITBG6wu1gbYssMWdXkeR1YlgjGZvGQIXrC9 TN4h6uIECJ4Lqssv8IpG/0MRE8JblhUJpvkLuLEF1EmCzZ0Ed8SFPyyCM/bDQ/Jb03mzQutf1Ri6 oJ73MLkIbL/La0rKo+0lw+/rNsRtNCvLObOyvHkqsBw/+igk4IkcDIaAR0gi4A0UlSfDrJF8nSWS L0l1u49bI8bnSybgBduJ5B2jKU4g4LmipkSxiVtqw7safEPkF+cWMK368TnwFLu5Q55HjV17CoGX 5LqWVdCP0lS0sot4OcFrh5VnJx4DJjE8O1ISz26Adiwa8af+1P0XS+re7tZme4WklWUnjk4ks+yC hyR1dwLLzgWVI4M7Sakf3Kd6aucgcLKaOZPswXt5L9XDqwgoqnnrrgtJQGC5h9F3HDeZ3j4Jgc7F 8FgzlU7oh9Fcjvzy6RTDBfhuSdTN1RnFneGJZXkhK73xxSKw8YGiz6htG09KItnV9Q8//lw3y3wU 8Wxk//BjneV8e0m52z1cudi28aRkkl2wvfR9sgPKhXQCyW6UCwrH2yrjEm9mEpu3cNNOmPMJFULv qqzRU+pv8tuK9KdGIfDzVW6kAoEX4g0RSna2qja2g2qZHM/uje+5nvqWxjRrHgJvzoMPWy4VwagX qfLdVOkpbKBCCiB2oo0WiYHYkZIgdgPFJdNqS/py+Sq3/8Wt0HYuT0oG2AUPRS5POgFg54LiIn94 lZlDlWfTXraeSrgc+vINlZbQe9PXKrnZ5XAnNdb6ps+l6sO6NlVZydRpW+jD1Nh79xgfuJndsi12 ZRN2O0b6YXJ5EkOxIyVR7AYrzHTBod46y2H3qtQR4ZhVTrady5OSOXbBdnJ5x2iMEzh2rqgxsu76 S3AXpfOuoZrCpzLRCJzOfw+BrW/rtAqoz1Mboq+d+bpEUTt3EvwQAWZ+Edec8yIC4ylu0gKoj3Gn dtJwN2/u12A3YqSAWzdZtBHDcOtISdy6WmsGGTVuyTvjeA/v3n/p46kNGyyXPn48IhC3Sttj9aRU cB3hZy+rn+KQMhl6D/+S65VJG+9XPLvUCJQX1iKwwrcpG4Gdy4/AK8qL/P7rzdrko1Qm72XCC/SH uZkIRMqgKr4lhNkBj8q5adUVhWvz9QFwr7KnZn6pwjQagVn5XNukhdnsNwikK6ABG6mQApJdgGhT hiHZkZJIdg0Bgv5XlHlblmdNI/+2qC+/fw93LTfpbzu/J6Xi7Ag/O/m9v79DamfoXf+LLigxCxBQ 8x/01BbvWt7exwRA5Xf5ITQ3t9qUHJmzhPvj45+NKTDzEwSOFnH3Xm9CIGsepZ2EwFduJALtu5VM GHXrPL5OBCw7cZ1gzL4Elp3YvPD6ssp6d/2qJy1312ctcfsSVyS2WXakVJYd4TcUkT3pBJadC7oX XXEj86OuLaU17tF8BBRjuOfZjjMdyvYm+rD84CplDAItIZcRSGM79jFFCHj5ZHAerbGNatoUkShv o97quG5YATfEfZW8VVXjnZ9QW8AMW5G76wR2ppgUsO38xR9HjNuXxLYbLCzPjZzVdziF8IvpPZxS 2YG7iJv0t53Vk1LxdoSfvazeIbriBLydS+oKpZ5YraX8Bz98r6w1eY/iZN+aH/6s7EqljlEXz/Pe ZnQSo2DX9b+Drw6rs/cTtZowFDtSAsUu8Ica68H5mkje18daD87fONvHp9fgDjiSAbZDelIqxI7w sxPSBzjE1zsBYidzQfbQNJr/tKdyyori8HwELvD7KoU+b2cHAl17KTWbVaSmjWPzDSey1/O7s0gv BMK8Hr91cloeAplfrIszxVxUa4w+KVtorytMCTxW25XUMn8OArKD3NPypsq/qJoe0Gmh7JplUWxy kmECAinYCx9IAf0uUPxpxfQAJNHvBsvNU/3Z5bOzRpmzy6pxuHu4SQz9jpRKvyP87KX4DlEbJ9Dv XFFtPHlH8iICM+G7pcN4Q/JPuk6+3fc9iklLMKQ0u7V2f7uN2jyBf9kU2jVaWS/TfT7jSPc3+dqU RyfTatkPFIaLPdexxCJSQLvzE332MLQ7Ugrtrk9u/sirzfvV03m9eab/YgfCL6p3L3a+bcRzmCVa UXdi+yIVdUf42Un2HaM2Q2/x/+B6xfHQ2NlxHXuZPCmg14kOmZMYeh0phV7nP6ffnM8I4P/1g35W xLNVvf/5i5fgpulJAbpOvD7J1txODB/gEGvuBHTdONf7cP9mxjiOYkNb3IuZm/C4okv2nU9HRxKT pvw5+aPTrVlUxYlqk5/nAWO4KcYcuD/x4FAm79Ar5c1n427JajO4ydklPzFTEEgPTPqS+kBluJCl uu4BI9aHNoX3XImWn5Sxh5mUC6pH/5dFrZCbQoyyrXLdYgrVFJpUhhkIvBZDB8B/UU0VjXepWg92 DT7BF3DvSFHQguHekZK4d4M3WenWVrElwy+Zjhu/J63QO/EmSyr0jvCzl+E7ZJPlBOidC26ydNSv Iao6eVWJpjsi3pDywOcRHDmP+3/yzjyqqWtt4/urVuHSFluXUkSMXhyhSknA5IhyVKqoqFgRURFi i4qtA0VRUUtO1WvtdSAqWsQpKioySEQEFIHUOjApIMhcQWWSIEUOBMh09hegNUnLbr51viz5I4vF ipyDa+0/zsOz3/d5z29bKTKrj4RgRtVHYjwUWyEYSs1aIawWdiaT1kWEJfFAdPQfJKEm4Gm9JcxB EPA4dAh4BRrRo7Pv+779WOq2sGt3W/jiGqPZiBVq8O+0F0i7jNcRz+slduwD/F1/A9xX5b0WFVNr mgRlxDVFTgV+AwIv9KslHDW/jjWZqXUDUWTT4dcxNQ5fyJ+vqiLmv+1Z5fcA5qPTjQJRK2QjHna6 JbadjpCdpQ/YI6cP2HWjDfBpn4pXv6ZOh8W/gIDh1/ZbGt+0U45fqa2DoMJZuSJSJjhiy6bKGeIi /Kli9w5Rez4ES6OoyBoj78FSB6KfdFHKOPJbaiB5IdCtpkhhWuspSjJTREzht8VAsBP9Axfm34Xg EtHyYK+qvoeg+uBA6igEGehUXgN+p73RQsDvOLTgd8WaQJbujVa0mj6xad0fqfxdZD9rMiKVp0vA Y9vpSuVZehHbuy/ZzQywqilTBFBHFTF3/FoyZC5kXJMgg9HAyD7MbakdJqrOdiAyjn9ASKardCFS vsj8FALxbgjmEvJ7R+wgKOpHHYOgYz+636vBvbPTiu4Q3DsOHe4ds0gDwe3sPLKk9Jcl6tHI3/J7 DpJ/tAKZL6rhd9oKoQu/Y9vpiOTt9aKQPoDf2RggsqieiDkMwTz8uK3PdtmtqrYI6Uz1NZtm2bjn QtErwZ50CC7yTPKIJLeWTkaD6FFqh3y1ysB2U6cVOeqr8TyV1YwXKnFpsW0RUTsEgkgIpjyQCRUX RW0Q1KtMqEDWAYG1z0HqZ8llSTO1JM1MObHRtbFKEbXTVuZVTLT7d9QrAvwgWAsBj8gY+scFdPGj Ju05aHeVEaQ9Di3S3t9t6j11xm/fk/E/khrPQS0SkfHThe2x7XRl/PrR4LtvCBiiS72iWHWe211a BMw7Kfgh6XEIykzbQiFYjRe4KY+oHMmFsg9vVezT/vgHSWj0A7RavQiUHocOSo9ZqNkQcO6eRR6s MSvmPLi7KZBzwXgKYpkaLD2tQo4uS49tpyPbt9dLV6APWHqfGZ4oxHgS0XKyqgDPTeE3CRRr2W38 1rgIucoYzA8rrRSNt18RYrYbBMeKiNS4+gsQXH2GU64eFHnn3H4qIhAC6URPefZ9qkxAHs/qTCZj 3ZrCIZgwX3CQsFZfFY6/c4ho28+bVWsWwKeONGemXvxdtfUrsJSawfwNeRI/C2ouo+N4mUCcy1Yc w5snJOBFZ/ylo4nKpWbK6VX18hwT6rx/q7J2HwSL2FKKRGpSTfJz6PrbrHED0bagQ/Kz62paO/eb ZtJlUipdWrn6ThusVqR7tyJTvYyaUYvs/Vx7Dl2UH9tOx3AAW/MVfw59Sb7r1sUnYLYBSnIAb3b5 M/e12bsnf75dGjTk6QeKw4kpVx6feG/Dqmbyjc1Vc6nF+q0LTlv3L71bVfvc48eanS+Ewz+1vrd5 2nclIR8M+er2iFvrMwb8K2G9T/GhA/y0U3ufv7gvtZmc2LQu86q87KrTR8PdjmnfnGR7Ifi7mChJ bEi4JMGyNLyLaTb01oHnDR9Vn8t9/v+8bQvzm7a0ZMzydZuT/HpNwUPmlcyT1RsGEeHbbndWX4yP vOTVzmzwNXdfPT8gyQh/dGelIuDJssKCiXLzwPhDUTfGcir6M+p8vIpa0+Pdw9eJb982/2zHSKeM k50u/Z6nJsfUB38dyXxStGUzcxk5PZhv9yZk4N0d/p65sgcL10RE19Wsjq/5QT7C98Vw0z0/2rBc D8bfHbjh7KqPW2vGf51gf+vO8EHbsor/h+E0U/vmRJ5A4tjo4nmh5KukM/Pm712d+J9zcl/3lhVK XLy9OEToHHdvI+d4+ICs9cbT2h9GvkyUEU+br1n67Pf+sTxgAvPDY8Wf7Go67PaAgE9qucq49Bue JTENL0Vb40aXjpj8qqBh7PfpkmyR3Dt4tVDoWfiA17hy7vWpG59cLpgvDW48QbSnyLK4PsLIA8ri W6GrgioiXC+Fk/LipmcuEzpLFq/0PrG3v/le34+uTQk6bHrSK3nr8Mhq77kB25Z+MGjth4em3Gx4 ae/01aZnTzcLDm8d86Bs2eczTk7+XFwY+VO+dN81CR7nEcq9WD+t3ss8df3AI25BTuu9xMTKmLGi Wbm7cpNYQcWmI8+9+b44+Sl1e+kC3sEzHWc3rG2JHTFj2nPptd/OJe6pW77Pqyo47GZ85ZH2mx8P 3HKzX230s6zGZZPWnPRI6yjb5WrZYLp+xqDtjtOdViD/Ayyw9ZKdLmC1tJwODfV0E5rXHFw/phiL f/9GE8DtfZIl7Et+1dXscWPjBD6srKHFrrFbvjZZUw5469L8xf5z8jIeblq4wNsp1e/YxNiwZXX3 h+bcBIqi6PS04OX+S355FcROL556wNt3QF1x/jOHqWet5oa47Un0LBHGTBSftDQd0FGecdQ1dtVv 5eUWVyJDL31jl/VmabRMIlmT5t7vwvNK+TJywtZDFqe9nAOfkoGHx2JORlwfKiFw2PWNDx9unN1e sKb41txC52HH/LJMGquKN+1d+uGt0sdXK8vnp5QYT1nnu3i+dFTwLtnj/G/vJluYJ1pUzA1b8WLc gg++nSsYU8sJ3iaLGwrWpL+cfTl9Kjl1xpMdCxne6TH7fjD3v3U0yp8/lT8o0Md9f4l/9ItVA7x+ H/2tV3We1X1LM1hYz5DIcQvLkCs/LLjoWuGbxFE4fvz8doaSl/cwwzfq/OB1x9pLm0Lwj+4HTQqA gJvQEl8qXte/fHRakqMv/178CJMJVd6862eu1PivK/dbtWl/dSxl83+7dFmMk5eyqqWYbDjx6Q7K /1TDTr4iihlELeTtZzwcQZyuS/GJUNWc88/hoYILGS37BXXSK7J4RUg6fmg7o0Dx3/RYwkrIr7bM aBP92z+GkdlY3ZkRoLTNFMGnhaLOiDxGafFZCB6MCKIe3mymxrdmtDvUQ7BC5Cj1xwWt1TnSMIHy W0VzbSpF5PFt63wISUyr6OdWKQROU0XhAUOUY1uVC3muPwkb2ALxFnLlLGJuKgTugmN3VJsZq1dK 28ZWquWFYsx2iunyRMYtqVdW3+uc16xYzY9oEwnz5Bn734TBopaHHfUhORkWVeccbYf784JeJ05x IafmVfN2y3Bnas+bFWetpCP8WkTTlQzVbmhG0MSFRxV8VmfVeR4/H4LzqUP6KdZRLGmR1gd6nEXN VLXjaJ1xzUFAVTl0oKrubysIlntXBWGltV9hde9XbgQYxSEWqUaqaufsdJGqbDtd41r6QBJx+gCp +i/D264kS4QQfMKiuI+uKddDcL/r7axWG2IFBC1WeK0ipxB/bbzTT7nbdj4E18eghaCe6+JoFdMI UCqHDii1RKPHyxo88psNq/trtJd6zje5f9Z4OEoHCMIKXVAq207HaJedXtpLfQBK/dDwdPCcSPJT CHeWyHYoYnZ3Vb5pjdyGejJuoHwtkd1xjYgUZCfbqPTxVSgErsOIVx4HN4sUs83xtvhIat+yv9xC ykQDi2qnlXojsKgcGljUxCUaIlGZhZWaibrF2aTbLCIGGKEQEWomqnYsT5eJyrbTMZRlp5f5xz5g opoaoEhESS7UaNNYBvlNzh6qjNF5xOk6kRU5yUS+mng5XXYXgrFnDkvYIdcgmJfaLPukzT8qdau/ zKOeyA+LCF5QHUMUCB2p/6Shm7KaSFStBhACicqhg0Rd+lYgJoOn/U0iPWNaN8Yg91MIJCqHLhKV badjTEsvCukDIur7Bji4kptT4Wi74TX6bVs1xJT1l8cH0eKkATFN1BjMevTF3dLMQZl/ngPHZi7q 3iclnDQSolaImMyiizBlM3VMZtnpZTKrDxCmgwzvAW/FY7nkBTFBrq3KTs1rNFNc3SlQhCeTQpbs AQTWIyJVHrBREeMl50KQHRkBQVYKBJU/J7eLIDjh5gJB6FYI0ib6NxGq3z7HV/12Y/fcFVIuGoeL aj6NGIJzitHinGqcWuJu0k0MsnJ+S/39LXNR9/RIzkpjTu+rxD5HzFfRZZ2ymTrmq/RyagmnD1in BnhqSXvoL9RRxcFyt34yF9L2m6mmDYzMQ04/dVqZXnQyuveKvyewAd1hUqNLWezJWo9c74U1Rgtd mq9ZWft274mc3+6IrHp4Jik1RqWox189PPW51nW6lTVTx/CUXs57w/qAXWqA5721NseJSGGjgNxZ 1XG5vsqbqOWW4DUSUbNrXrrKG7JFcURWI1H5s5dTKM+KjE0KHqtwqV2+Qbagk5+dvg+Cu8uDTSDY c0NmBsH7a1BCwTSYpXYcrRu9l9YYLWZpofqNJ5VRjCwpzVz0dsgwc1m3TaTIUYfAYRrUUkzrOt3i mqlrwImtF528++LawgCHDFNtL4cq2bZev8qW44Wb//jx3zXBZn9+j1q1mTd+2XDBgaEDx72Mi4kW o8WgMdukuSHBEDhSjBaOtBfXUJ/1tml1z9kiOeeNHRGrROBIMbo4UjZTx2iTfmyjD3CkBmgbJBVF xdRBEFlGtXmGSdwkXLbSKa/jYqoomoiWihraibQhw3GJy2AlJjjhYqr88j4EC/1qv7wHwZIAvDBc 6vkUb38v/QIE14dITJU/II8VwTSgpEzt57D3ihyjBSX9u3NM1xhQz+w5WCQn2XgqapW9Q0kx2lBS pi4kiV68ow+gpAboHW2fmUp22SodIDgunPkLBJ43ICjkSudpXI8LyXvsbSk4leKIO6xhd3Z8v9Sd 4G9/0P1PD8EjStgag4crufVLCZZMlIvsX2EaGFKmZuKNITCkGC0Mab6GWlhW3We7uWpYy5Uea6kw RrxKiyEwpBhtDClTV+atH7W8+4L8Y0OsSIQEmSRTOcW4Zgh22eSlp6nqkIpGU4VApHwtdOp6+cLG PxYneRB03EiY4imL2Ued5dYuP2uj9PhVZTNCMjb3BBX9goj0lHqKhIQP9Q960Th7xF7rEUUU8LRw pH9zl/zFeTPV7tJz+sijI8bzUHrp/fUnjDaRlKnr9BG96KUPiKQG6C6NLAiKvq+S2jdnpzyCQLUT oxY4knEJuNLzMQShCxUxV2KkJk6jAouIUX73J50S1nzWuc9tlHvmEnJQt5vslQqKqEBGl8mgt2FM RDaOITCkGC0MqVbNYtUjFDVqMXNmj1B8Ue8oYRocUm2h0C7hdeXjeqlZ+oBDaoitLkGciEzoysG7 jGWnTS6vq8GV1ziwy1heCTFZo8pY8FhGt7FcDHuaJ/Voy2u7R5GLZeEQWKeHUyeJynlcd7zWsxAv NJVncedAUGEZbAXBhq1tfGU8sk+MaWBKWVrtLwSmFKODKe3FZj6ZM7be+o3Yr+6UxXLrWzWt74FH U5C7MjWnVLtPTJtTytSRnOvHZfqAU2qALlOUA8EJ0UoIFlCrEjdDUOtfghcSJyeuFEm9JHltVXUm WyKUFk7cE5sCiQi/HPJaLr9tg5TnkeDPKDJZW4lHD32cSiyxJk5TPGtBHQSCA5FSUf1L9M5MA0TK 1JYMou6nBSL9u+G8p2YtTu4J4x/5G3+BWmTvLxthtEmkLF1hvF78pg9IpIboN0Ihl7ypLmRy09OI 7MI/65gpMonKbtz+rGPCngqli1V2k0GkYrZRXPJyg6AhBIKgzdzFolpXld9YUm9q21yUCWFPGO25 3C+ICgw5p4VpUEpZWps1BKUUo0Mp7cVuNLWzpEc7s1FnkWBqTulftEO3CcDSRT3Rj928+yaAAdoN v4SQetcQVxxJB5dGkSKOVAlAOixCUkV57mA0hCgOexOzZETzBenMRpltIQTBptlm3Cc8gfwVb1Fy LMWqGSoRPPx+T2VCZ96RJXJCJDrr3kRR1Fa3ZLkc/cYIpgag2rO02gEIACpGB4Cq3T7rTmac1e+c +/6R529H5pT2iDyfNgSVpSvP14tw+gCCaoDdM5IXSUXVEd25TKgEl7ixenIZQRQE0TsE3cFMBQTr iVpzvMGFjKuSe0EwPqsLlXJiGwTlVdLZbrIvFTFlYQm2a5GDX5g9Ks9HEEwxWgTTIvWg5K/LukjY +equWWlPnp+KGzWg1ojI82kTTFm68nx9TEpifUAwHWZ4OsmQFVLX6iGIxJWvY4lruLiSkG2BoDJb 80ZctdhUdlS56g7/Ki52kez53ek8BFGMYpPI4ZPOfJcS8OtjCE7FVkmjuz7RvTM129Rei5uAIdim GB22aW+uskUdymz4I+9nISNMB0TeT5tvytKV9+vFVvoAcGqIoYxtLIOMEnPJbVUdN1JzGgcqoneG Kc4mqwoZZldHzfrcZVWZs7GrzBFRJRCIXdwhWMA4ul1lKRAo54iJhghyEgRdg8dRlm5Ke96sZtfK sDQkmA5z0Kj/tf58IxipGB1Gai8Os1Ij9y/tyf0fmxvPR60SkfvT5qSydOX+evGYPuCkGqDHXJac VrqLGeTXeR03ooLXQrBEtl9xMkH5Opq7XFTkdAGCsZ91KSaCKlIpxme7IhxvHhVIlIuUrrkQhI5T 1kziyz1VgtlRRa6GIHVf2ZCur9MQOCwXtXp0faJ3aBroU3utMgGBPsVooU97MR2WBkDLt+f195z1 xjMQy9Rgn2rNK9Bmn7LeyShAH7BPDdB1nqcIqdE+Kp24Wqi2ZmduTYqB4L9mV4mChxB0RE4yiYbg 5Swxoy1epGzISZSFU5drIcgqhoDZxLtCRO0gyP9l79yjmrrSNr5bx0+snTLzWaX2lo7OVD9QIHIr 2ppOKbUzaBERogjGllbaaodVKWWklVPHr8uxXoL3WzXFC5Rb+CpFChGPVisIKNeA18YWIjdpJCRC Did7fwcSyTl6drPWaRb5I7PUlcPLHzlrJa/Pft5n799JJqtVsmxF5zIZfTCx12f1stayC/i5GQuG yj3OgoGhBguBofJozqO2mOaA11BMczFibASuYzD2XzAL1c/eZgCHSI4TWKguKDkbmkTGxGziwgGJ J//lNci0RwWjQ/tEuj99MDgIaF0bAufJ+9JPIFBE6odUae5ARdzGwT/3ZGbwFds1Nnqpvx9nEYSh lwYLopc+uJ2ZURrbweB4y9n5ql4cZTuYxS/lKI1gfqnfiOwNcAK/1AWzmrZBREQRY1xazydovb4c pK40M1ZlxyTFTuVqkg6LI+C8FWkLVWm76GVSKsXkkVhPbqpE4A0EJndT0p41sg5N67I9CCyvqkfg 9qRUmXk93tsEsgYCbCx9MAZuGiwEbsqjM/NYm2kuL7RsphkYOx9zl0GYgYBgtqmfvf0ADhEaJ7BN XVBosowFMOolKZyHgO8iWDR4nJhZjV1Q3HpE0USaFhllJj/6TDKxgOkhZk2WKa/wkBrdTXNk1Lv0 Ok550SfeX9+Ni7hdSFRY/uK3BNj4o/cJDYY/GiyEP8q1NIMyE/mc172mOWd5cEppPPawpQ0/yh06 C8aP+tvbEeAQPzPi9FGX9DNnqF3w62QdtZgx9SGP/NpPhlUSrT+RWWjuSA0U6fdLGpZAQ9lT7qb5 oo48BFKX/bvsj6mT8Y1i8/5izrcQw70LFsK9e0Bfnpi+9960+S3LM08ujhn7N8wtsrB3nPxIMPbO 31767xhxGXnf75KDsyoYFSczz6a/2NPsY4pKJgw6vacsltRGqRFoICtKE7sT6fVe5oCPNFc1pv+S Uu93kIx5ebTAoL6ctvq2JPhj0ZeFZKXl768ISjCuTzB+XwAX737aS+2i4SXYOctzT466uy3EdQn/ 806DBUPx/O1F/Q7pEidA8VwQ9jJGXWBc2uVhnp7IKMLLVBHMXfsWAse2IKB7XRRNqhPzZEOTseS9 oqpsBOYlDNTGrRij7yQaJkGDx5J1dKnCcJ4oG41tDzYPj2OZMTy8YAE8PD6bwuoQa8g/wa0Nd4+Y kF8wEc9/REJ+JxDxXFBHaqheBLwey4cH6TMJ5jUI7NoQzXh2uLwQnmQcy9lcIovwjfO5+y0MOwj3 ayo8wsz5ku1tRGaxfjRj41eGt5ZoOvLpdR+XNa+88XFZUyJ9ZQUCF3czr/ghMguSx4EOB2MgecEC IHkPiMqrrNTy3KtDTVOocivC3CKLkcdZfAlm5Pnbi/od0jROgOS5oKw0IrBlFWkKSNDGKHry9yDw fB6dGwkDjiPQqlbsetdQoP0Wgfkk7xW+LWxkPX9fbltgzLsAsh6fmHA6w5LnV3dgT1oGY/J8wXQ9 /xHJ851A13PJcEVjijYv71dUZBiLYRS5eM5U/bS1HzCyktjkvpHeJBuIIcYr4N6aiiIEirJ6ghHo 2MwuqyIru8O9il7M05mOX0LgwHTmFd8wrKP8rCGxny8/W4+pOyjAj2cF+OOtAf7ssRLe27S+q6Vj uG0t2MiPSIDvBLieCw68Ok4VEzlKuJHOzaRuwBwVNVWvPNCVQuXo2hWV2T/fmfNQ5A83P304a9Pp /tHtXXXNR/CbKFmovWBfzheQ16szdSHZfNR98GFuMyQNNYMq2K0d1wy82TxTF+zX7WXzDqAPM7c3 8n59kgtOtfbRhYzjuEFX7k7QX8qHipRezyWKqlnF1FpNdamuew08PNv8UpcSNis6p5ANP9pKmYXt qpvE5I48yrtfVFG6cs6mU2P009X7C6WYdrF+pFb18Of8gte7M/Xffl5/kMwaEm/bc/xWhmXPMYF5 rq/1TR9YbjF1we59BDJ55vb+k8mPBDbJJw+BuTNSPZqII7vLxnVJ6qpik+bsb9lnaH66JrMUgQEQ R5g/8ybhadwT4K0fleX6BU4f8LP2mLpjovbFrKj9nDVqrxobhrlLftYeUxdsyEcgamdu7z9R+wj0 gcqYC6PWrqSi4CtK8/uM25DFwF1Eei4ZQ2qlTeQxWes0zdWWdqOoo1A/hVgpP9JIZNZUbDEr58gj 4AHJ5G6514kXlZf1hQjcqpLAVUOv2IZh8/Y4toOft8fUhfh0NtLbL+S591a9+7s/70ia8E+jX9LF +b9/PFa/5qGqZZin7lrf0nKPwZy6UJceYC9kD3ZIu4y8S3dBoLdhaz6dgcAok/RocqLWvV9UWTYl l5hGnIZRp9uInC1wX+xjKdTXmo5d1h/jNtB/QSCPMD/Ld4XbYW/9OK2dwlnt87P2mLoQg/6AI5li Q983WtD3pTq3m5h7tJH27usUoe48wF7M7hBD4gTSngsaEvcoBKJm9VFJtakFVHYz2XBovZpQv1EG vzTWEytJ45MaQ19aKP+levaGTx/pPHj21OjkN37SPFwY/f7FX+mUYFynYLy7IMoea5A1arBTvlqw WvlwQdoKZUn2tn+FzfEB2TfcPsL1ia2Xgzh1ocY9wE7QPtMBT2Fkbm/kjfvjLqgoPxbQyWRAR5ms vyttZUMq2dNEN08yrv9C0hDzXU3e0xFwv/r82uU/yw1NyiqYQW6/TXY+ZfIeusT2BAuo58vtCYxB FwTUe1A9hqdZkfFD06ycOrc03C3a2vYFTl2oOw+wl607RDycQNNzQfG4RDUj4JmWbZbcGje7S0Zn U1kGBPZO1+UT+qxORQNcXqrpToJHNfAQ8Vxc4t0SBBYmIhAuSfcuHohFIDsIgSxFhcfiX9zPJG+9 SQ9drMhT78dt17J+sJbvox+nZfgpekz9t3LzI8OGZlohrCf6Ro63JCI05kij9V2HrtmJCFMXauYD 7KXrDhlqOYGj54JDLeOz2XR2V2Nqlj6rIKJTUXmo5LauxQfKeyfUJBCTCAOxV/nJ7P4qBI7QP6wi rv3+3j9csG793CzXwZy1Cz8oj6kLMewPCEmIbc77fs7QnLe0zu0n3D1iDLtgTl6AvVjdIUriBE6e CyrJEWMzjJpE1j8ib5aZFq1A4HVPSRyhjThgfq5U0f0hPNZqUYpIs1LSeFJh6DU93EkUlVN7dgxJ S7xK+c2N5sW/dL2UkGfEdwlrS3wg+xf8SDym/lufVBc5bnCs9VVCRvpwn1jA+NVjMAhW65tapIMz BxbMxAuwF6Y7ZLDlBCaeKw62YAZdohlDlE3oMIeYkk49NggxbqA26Ns+fQYaokWRMEJ+h2hdvDbc 9JrkDALb3jRKtE8gMAaGZiAwlmzfALfmu/fPR+BViSH5XeL7ROpPjM7k4nuGZds5BoCfhsfUHRK5 j2JF7pHWyH2s2y1cy2Aid8E0vIARidydQMNzSZMyuAE4VtOOQPkX+B+6JEUa6sCOwW3CyYqrOvP8 C0O7hEtrulNg5qD6EL5x8f0pp5Xf0LNvShfDZ+547Y39/hY+dWTh8fw4IQo/Ho+pCzH3Cx/QmqM2 rbFk76WfYddk/Hg8pi7Y3dvJ3h0z8nICHs8VR155Cm0zLT32NgLe5M9lXlNNyQhM2KZO2yVpSNQu eUbaEWkOhFH3CjGEcRwCpGTfewg0+kAavpOFwAJyoNe0B98jrIfJc5J5fioeUxfi5nnUhTUCszxN vrTQ7WfMTbKgeBx1EQzFC7AXzDtEXZwAxXNBdbkIL2v03xZToYxnWZVoillqnlxInAii82fAbXHh d4thyAF4SPLjK4xbIfVPaww9UM+YmHwE0m8xmiLvS1eNuaNbF7d+UFnODCrL8yUBF3A7IK0fqnU5 xrEw/EQ8pi7E6N8nKsvHDufyFx8dyuVVM7BrMRsNj5uiCKbhBdrJ5R0jKU6g4bmipETSyZvqwnua fEIl5YsLqTb91DxYQm/skiiJyaklCDwh0WmToC+hqWyjlzNqgpcOG9vuvr3A/Gw7pu6I5H1UmC15 r7Yk76rlmIOJ1rfkWV4JBtsFjkjy7gSwnQsqR5b5BKHuvUMM1C1C4EQNdSrNnTHznoq7VxCQ1jDe XReaiMBKd6PPFLOYTJ+BQPeb8FgrkRmkH02a8ySNJ+WG8/BlVeSNj7NKu8OTK5Shq73w7cLy8Rw3 wo+1Y+pCfHy9bQ9k4ytnLp9eOLz/sdpyzj13m9v/4poFE78LZtoF2ovfxY5oFicw7Sa4oHC8qDDG e1EzaOWyDTtg3jtEKLmrqlZPqDcXtBfrSyYgcO6K+XEpAuMTDBEyer6iLraL0IoT6H0JA9f2zNKY 5i1B4Pkl8K72UjGMnEhc2E2UleDzFBbOjrvM4sfZMXVHBPOjwoZdiZ8lmM8NdPscd4uYYF4wyi5w RIJ5J6DsXFBbJHevUIuIC7mkJ9+VypxHNl5XdATpvcirVeb5F+AOYrKt6H2p5rCuXVGhmj1nE3mY mHz7NuUNN9KbtsaubsGvxwJxwTw/z46pC7Hy9wvMK6yTvdWWM++qg9j1mI1mx12PCabZBdpJ5R0j MU6g2bmixIj6Gy7BXYTOq5ZoCZ9NRSFwsuCvCGx5UdchhXql2hB19dQXKmnd4hnwDQSomGJza95E BKYS5hlLoT56HLGDhLsZZ78Gvwpj0evEnFUYP72OqQux73WsBHJcJKMr42zbIPdlD22DVGVjzy/y 0+uYumADby+n93dIk4y8gX/C9ZqknbEqHj1qBC4U1SGwyqclF4EdK4/Ay7JyZvH1fF3aUSKbsTHh hfrD5tcRWCiCigRtKLUNHpWY59RUFqUW6P3gPtlAbUyZ1DQJgXkF5vYZy3LpzQhkSqEBn6awcHZ+ nBUZP86OqQux+02sk/CRSUNrsiRWEulnOQlf/QKGHWF916Fr7r4vwUi7QDvh/cyZDmmekXf8E11Q YZYioGa+6Xu0XnWMtY/2g7KdBaGkeXGNKW1hXrz5D/f+rZfD7HcQOFpsvv1cCwI5S4gOxv5/4vYC Ap27ZVQY8eP3+EZh8ey4jYIx+gJ4dhzrEv/SuME2sW0FW6Ecih1VpW53cF1ia2aOxAhG2gWOSF7v BKSdC3oXXWkz9Z2uXd4W1xeDgPQZ8x/prlNdss4W8rDkYJIsGgFtaCMCGXTXfqoYAU/vLLN7W2yz mjRFJEvaiVld1wyr4Lq4T9K2KGq9ChLrCqnRq/J3HcdvKWYh7rhbXPgRd0xdiNnnk5avlg8vyz4f WpZV/YzdFmaD3HG3hQmG3AXai+odoixOgNy5pLIQ6uk1HcTMBy++kdWZvCaYRdsHL/4i69lDHCPK v2fMzaQUSkp/OlzBt4fND/hyBrP8LDumLsDYf1vLOj3/8uDp+dOxrNPz1ZbT8xeDxy7A3KUNZ8dt D8E4u0A7Ib2fQ6y9E3B2IhdEEM0hme/7HrOssjS8AIHzzNpKqlfu6EKgZx+hpnOK1aRxcoHheO5a ZoW20BOBMM97pRNzlAhkf/RpnCm6XK0xess3kZ6XKRU8VteToo1ZhIDooPkRSUvV3xUtvWTGXHrN e5F0WophGgJy3LMfrJ+6paUCOAsgfg4eUxcyBuBRHD9benndgrGv+gXzcG7rm/K1lNBBQJC9JN8h iuMEDp4rKo4H40smIvA6fLlsNGNLPifrJek+fyWojESDvNWtrX/7VmLjNOZlw9yeSbIGke6DkCP9 mws65H0nMuro16SG8oFreHIRi3vny24QMYZ7JxbCvbNKzh/ONl5/9PUnn/qs4p7NTwoZsvlnd4yd yH9/Yl9WA3PuW6jND7IT7DtGbEbe5T/kep1x19jddQ33eHnrh2C5ZvPcme8Uvz8XC2HYzVw0/D9/ 0rgH/ue3RPGqx3B7uMS+/P5cLBhhF2QnivdzhD8XOwFhN8X1vt+/DPIcJ9BzteNKqRvwa2mPaKd3 V1cKlSE7l7bgZFsOUXm8xuTr8aUx3BQ9GLo/3Hsom7HpVZLW03E/iuqyzOJc1VnKH4HMgJR/Eq8p DOdzFNfcYcTauS3hA5ejJCdE9GFKfl7R9385xCqJKdQo2iLRvUmg2iKTwhCCwLPRpB/8N9FS2XyL qHOn12BTfDGLf/dCAOcX/MZeLIh/x7fMGp4YJ1lyfNV43BZ8MQt/58upC/X1QfZyfEesssROwN+5 4CpLR/wUqqiXVKs0/REJBnmvdx98fIl5Cl3Rkr412K0lPTeKTkZgIgyNKWgp6C/We6qJZ4gfyG2/ 0hM2Fh7npLAYw8ITC2Hh1bMCyKTxQ/NhVktYDs8X/jcGTW99Sx75EUzCC7IT0zsigBQ7AYT3Oxdc XdXcJpvgO92KK0Q+XXVNchyBpfgDJmIbyc4vcCbnF/xOWyyEZDeT9SSG67FDw6t5w6Or6xbe/MlR brdx98gfuIsFk+yC7ATufo4AP4qdQLL7swt+31+UtNyGB/Z88xMCogTD9TK5e/+AJFN7C4FrIeaY LEqR7hMEr4o61ZJGet0a8m4tAtHZMKvVLW68KYAYZVpQOlX/Phyjz/govFVNu2ul5AkP+sgsuSEX gVT8DzJUewaBo0TPD+sZk49Ay6YxcBsC5diEXsxC4XFXWxgUnlgQCq+JTWaxrLYibdHjP6yn67/D UVbFNhgeZ6glFgzDC7IX0Ps5pNlG3rp7uKC1uUJ/CLfRuaqEnnJqrl7ZrSgXdYgqt8h6tE+SLZUB RPnORwnjy0xfkOafKp5AoHMdAn8jBs6mixFQj4LbEejbgB37ilkIPDFnrY9B4ImFIPBmqlkdkhQ/ eHwrJ+Hw8Jngf1jC+YviseG4Dgng7xDBGLwgO+G8v0M6xAkYPC8XRBe1EblbEPi7ZKfPshTqO43h iOkVW81LR029WUC2K/51CoHDaeNqiBPhPf2iDrL6ZN/A24yArYMH6Cpb9Zs0RmqmFZglpiYfNaGd gEAWArN+oArow6QBgTZGhOqpPgQ8l22Cu43HjDq4qMzDPKMrrEtDZ6f6UEubiLuJfW30hwkIrEAg jSifaC3gDZCNuRfAHS1jmHtiQcw9Hpkab0v7Syxpf/UdXJwpnsmf9osFY/eC7KX9jmnCkZ8KuKJM tUO/W9KUuT2KmapSyWbTTgSuuBt2IPC2pD7cnM5I0lzov6+X/pz78is9wRoKcGbSGKieWAhUb2YD eyoQP9gRrK2VSZZj+Kp2t27MTbKQehzxFIzUC7KT8Ps7ZCzgBKTedNdriU7JCaJnr6ZecqlU3q2g VwQZ5L3KIwOMLkzaYp5Cd5W0E51B4QhsVxMnlW0ZCHx9QwLDoqBedWgDPPIRAqYZ0oHKc/CKQr/z Qn+xPi+8ex8C/zNPsYnwtFULpqk2E4YNaaFajw/lMF1XcfLwL8zKr/4ZkweqXVXz/+T9B1AUa/v2 i5JzFkHJKAgoaXoiIFmSKAIGQKIEyTmjZBUkZxNRQFBQgmRBUBAJSpQgOQqIBMmZM70Wrb3Ot/+1 97dPnV2n6lS975rpmebxDt3P9Xuubpp1S/YDNe7NhO9pP9uwe3GyS0JvZXuSHbf5/EdusO7Ljc7s tlIfpDuu7k/fPyTQxG4frPyPZ+TfB/qhwZkZ9sX/4Fv833mgHwI0rsFHLR1p1Gl12B9uuZX+DyhW n6FY/J9i/B98i//bD/TD/Z/cH4CF/6Y/7v/+Gfn/tHHBRKD8/4dnJJmf8sDw1dstgRhxz22v499o 9iJLq158TSSyM1laWT6Xe3Kb3db98rOzJP0fRqfHrj+Y8hkv4Dhxtt5F2qkviub4rUquCtvPZFRv bY16I8Kia54Gj403bJ/DlC5YNeXufs+VoeO4EvffL0XFMnyd8l6u50c9WX/L2f8EfLIZS0XY2Bzd ZGrb2P+HX4sddiy4/v6sZHZFtfyXRVcj8KLp8aQdg/8Tj8qtyedFOVn6G8Cc2cmr5pecyyhkv7wz 2HPu1O3uEtk96VYU8bL4DG6QhPuHkX7P6vuiq0+sflZWnhT25pH5/HhLhXisujxvxtc0B+jscXUB dFfkfKMRy1HkH7wdddp2PmlYZL76MWVeNBWwy2U2zkEf9OAcUj286AO5XYoJ4+qUoOlbVMU7DgaP 5l5CbhmF/34p4pe2LjWvopPRd6ss+eKlYPPSe6m7Zld/39yX/enZG1Wg+KbeHpfwhKzZllJ6ozFn onTH/9vSa06jEMMHA85CAG1cL9Odhcgrn/wPO6eN99+8L9bpy5ubqHV/w9fPhZntmjtz9/16S+2u oa95QYFO9ye/eQO1wvP2ndldl7Z95xP9N6p2mo2NCnLC9nsr4k28BjPVs56s7PYuDKsIbfVpGxgm BpOcDDajey3pFUn/WL/cnSNn0lDN2eMGDcNt2gjJkrkJlMwth+FvLmmR7vyfvuuKyz/GiP/szgnt 2L7/el32zfV44+cz0jP6J6ttyWOueMnY6v/0N8g7U6vUdqetDOnVS8+Tuny3t/zbQeWNy37hyZsp drd/53PJS49tvx5KLQ36oXdff9T3UUnRSMxGCSO5awnx9Kvh5nldUYvH12s2v99R55yjt5Vn8JSS k7n5P/7AYZeY/s6zLuTv38/i43WuFJycCrfl75UoIi1eIJBFGZWvY7MsJyexAmfepBkhm1l61fNd TaktBgj8rGocfzqqtn9udNC4bChTbRknkv9I90cDS2sJwV7Pq/c1vnqO1+pmvbDve8+HGZqR/ejt GEafTzmtFnUlqFSnryBP5OdjTnqyzYHPser5JkMDA+wvcuKzrBHNyzde7ayvW9RcJc4YG9nVXRFy j2B/pq/o9m3FLfKMhAyFsdHBWze2QvvGRnvljS6L3gq1bkW2OMtm6vnRXofgG7QV/V9zRwYuVfVR SlqZaV/a5vW9s/O1w+ZDOfvJUvZBtUc3xwUu09iopfFP43w9dt6wEFi8n1DOfn9+5bx8p7cGt+H7 vPsBJx0rYl86Rp+PZnAzuhrS5/hq3IRMf5HPRn+y/XQDJ+th9wz3+q4sO2fUi4DLz9UHzcpwe1KM Y5Wf9/3aGz+bvUw/ZhW30b8QJUvX4CXqfEhg/PZ3Uf9PK5IBvpoyKbPo+iIuaqFRQ7/C5BdTjlYD liYOIZP5B+f+r32U/VN2Jat5cltih8P/hPeB49M5n+i9l4DXgYZfCHcjl/+zH1VGmfgV56VU2fi0 jM+/Q9J+bL/YKdqLei8b4cndtffwfb7/6YLoSc7Pa7WnHPO4m+Yntz4774s11R5+667dymzn7u9N OST4xOV10FiydCC4+nkDPXNIcLNWattRNm11snX7Udq+zd7SdPWBf3u02A8j//W81dqk1e1DApnz tU+cj++fWd3X8FMPLZjDpv10XTFQ8lerPiS4mhb3Ds8yp2f3xeZXD36P7/F7HgAqnTvGfTP7k/Vb F5f2zKMz12oL2nc/hyw/Ouz53bg5E9X6mX00VUqMw9HP61eppMrK+fZJv8AdWcWDoOWbKae3uSx/ 18rtc+NhSN5LRCN2Lxq5NZruF91xSJBefZx4z+oAud3zn5f/8aYWxN8nqyJw8D94jf/mf1hVI/93 VtW/HkltTOcyNup03NH8Ncb1EHvO6fwG23mN23Hf/U3kpQU15Y3PWJNLHnaX39T2ndCq2+x2/By9 Kuh/uDPzu35nvlCIy3/k8OuGk+VexWT05OfaaO7F87JzflYyL8579LnLbqTJRb+WtROe8/94X2oh 5SH9pLvAwNTi6Er/Ix2Bu15+yZ7bs/XGh9J+WwYDLgfCbGkKlU5zV91lvl/5ItEnRbZo4DnZ9smH cfVzvVl00OOfZuSb8ym6o16dpNXtPzRMrh7KsOcSl0rMD+5WqPd+yL+V9lqJMuLz0zPNUUbh8dOu dp6aibKVd+xxXzvccIa+yA2RIffxN4/ChyKFkwPPzDDNmdos+6I8+3k0RDZDLFN3v/SMO1dGXP1Q Wi3md/jZcI2h3Wktg0X6wZ3YBFK34aC8S2PGhxJ+BUQz0TIBPCORQTy0QVNR+LftN1Vf3A7TJJ1r YFl8FszTn0nPU1f6m3mqm8OXIPBJ1ujxn8QvJilSg9yajJvKuPfXizae72uXyfR77dxdIyRxAPq9 ev2aCIgKcowxXL51a80mk8frO8kZ7n33+nodqcTzwbypcRc/ZihuyplUKX4Y/xWfkcs+W2RvUvZp Yg5fgTJNjxGsyNCu+ijpW4Q59jvpW70WP4x6vOSUuP6J+IszFaVRi2aWxeJnzqFzUiJjuu36bJ8J z8wl6Ww64dpTjk1opNl779NQzaBP/ppKOBfU7LXummA/OxgvOXQhfSnoIWtMtDRJoo7kBYLCZaFJ C+R0x10VOeLvTArEEnr1DwRxhE2B8kSFHybYT3AMrcckJ9SvxUjpFhG3oiooZmcep2QkseGanhXJ h53s53W7oWFF0B+QcooOR4mk4GhoIpHqT/rBd45A8gIvYpgD62eCSfcze+LlVBxjYF21qt2gziim VM38G3zjH35Kpu2d9s2TfNcqpAzl7p9G0u3zPykv//i9hneenKmJ/mZMAOEFRp+HvCMmZxgDAocU AjopTnnWlKipEpzqqqO3liPPsFqru2fio0BQ8MhrzGKUVOQe+bWGkLNXo+ZexLwLRA45Bdp0BAQu lTD5PaSqFI6S1iVoZhHNfZ0fmKGKiZVPzE+XZxUukn/05YN8q3FGcGrtPXLD4jry64VkFIbFFyiu Fz/AvzZQ2Fvsk/CVrO8eSxCMu/xYU19v8p5MEr/mr2+ksaY5O8fPevSymn5qO6tcuOWTyXPzbg0j oyhmQ3LsU6O1QkCR821G09k4fvPcOPRtu+QVErYdodoLtEouCbJqrPxXO+4LCAhUqRIbijsSGPen 0pKNLLPexo4wkGifl5JmIttbTqjbGufzflwUzJlCMkb0gTPi7K+eBQ3zurn998TU3cGkMeTI+7NF cjQP6Bpj1pqaubeZnuLsAl4kxjTQyX2s4I0xJxB+k5+7G84nFletunKqGXyzJ8m3PeRwvUUkmC9B ePsC27srJOcuCcQ6EczyoVisQifuXCg6FcKTdetSNrN/GEddHE7u4RKbh4YcRfzDhf5XGeqN6sgA ytGHCxpsHQ0eJjwD/KjfF86+X38XGHpCzyxWmd3vMe9HxtHJ0Mc/GvmuheH//6aRT49J7SBOxWFg IDP2bP8txtf3+R/iypt5n5rI89rshMlf+5Agl/CL1D/3+7kdTVLXjY6uR1MZVDeGMiiTvuFfv2Tk p6OdBW3dvrKXm0RjSliS8jOibimxsbsTtPXnumVERLqTRBQVaQeKvx+mqGMddQDSw5c2nSzCl65Q 8IUvtfNMUV0vfE51udA8bOmKDR/VepbR74arTgm1dNyLrOoBDG0cfNoEiBhbtAFF5iY2wMRg9uTH NQJGlRz+B00J9cyxHb87+SYIGDLIKa58r3x3z1mdxFr1g8Rv55DYU2uqjPyXTcitN1yJ7+9NUT6g WVV9y+mBe8gsd0Ke7/EbIFLgwYfmLpeFubbW42I61Qa/XT6Bb/ZE3mzhli5aWzA8Zmxh7BXPNMLk 0SXlP60+f+ID7/osXV8o8fiF4y4qPuJKWSQBUejHdepf+sNIjqEYieKVuWjOOLUp8RJuhRJbNRAi 7z2PJeu+N2dNxDB2V/zj09MnsHunRTz6FY49pO1EmWEr6Iau6J3jYnyU8PkLmvXchPqK4OlRc/oY u86QgZansmHm8XLXmsPk3T7EKbg1JyuW7B1/OLutztLJT82mRWrL1cmvfkqL3/YM/vVs543eKxUX 9GtleeNPfTc/VpqITpk101tp1jCM0fR4ZXzSwtKXN/tXvulUQgGWKq6lj51Rz8KsgPi1XfKZhnPs liyM4aJ6QPhZvautjUJXhp6nrai7aPGpbMcXTvC/wrnsdhgDr8SrCXIosHa5H5e1hTJjqeNVk9KZ uKODzZlVop9o5c8G1EqW/dzir08ZeTwnKfOQXF2xgG+tMI7FIDhEWPJcwGkZgK8M9Z5gqCJU5gsu JRJ3QvQENleYFrtF17N2P5IVY9TvdWsSfOPHaXfX4bPwdJJ8scr32CCZOCdHghjUmAofD+EexWmO gFVGb917xDy0pBe0Vc7SKj1G3+3jqqfwbBosah2JIdkKJshmpBi9RcZLeee9l4gWZTy55kMBp+Xi mSBJJn6GJ6i1ZReX0AvVUwxP+8h4Ub9pFR7cap5wdp9rYxXUJq8IOSX4XZ6xJpE/7FozV9hsHGnY JZJzzE9UXwg+/yGmaR5XqxD70DzqVJXJw1PHmqmU3JqZlM7EHQ/LPWcbeernjmGmauKvjNCRFvyn ZnoZTTcMCZTKXhlrmtv6EobZvTaVi13CUqU3bbIzappbFugwf5e4zKDk0SZ8AT/o/VNV5g9PSeWc f940lWCcEXpGoiXNPPquLOuv2M5ExvMrs2ucyQS+MQKYHRMuwoNlaYeI80CHKm4O0aHKpcunTf/B 7GPw+btXuBblwf9FMN72EnBW5ru4/PpKJJDbGgSQ0Vk/Hh9MYHAlOcXU/dUyk66ZmYbr2tMHXNek tL6zShrNemVM3o8C32y5d/yuXEpyaeU5wScpz9NJKRadVJ28dfpp28FkT34sI2/qBb467qmEJnYj 1dRLREyZ1UkfSCLPUK+kL25HXThx3cWTMnPDGbWcxMDtGUpKIf2lg9T04dsZmtNMqcIfSybeoRCW WzefatnptEluRpyrr5n5+ZuiqMLA42P8nezeYzokDwVIublUTC+uyzHIT1CqPgjGPnt6LqjhmCHT m0z6OHRJVKIZ+YGaqeCTSY/LOSKD8mSUtFV8vZ7hPJXyC+3uPQaMbCS59gYyXL4xDOnlsXh9n5u1 OdeYdEyFDHxzRsGBuqszfOodpsPaUzlI4x3SeLZECi0/eY0/viWTcTFfbE3hepeIUaGciGOxWBNR D23ekswK0n1z7k7yF7VHuQKU/hXS/PhTw2FqyXhchSva2o0vJ3lnSs9EzY0OIxt35vp+tgQze4eJ 9u9YBkFCjhYtosH47Cgjp7VwI+x8i5eEn9RKCq6C0zfxolT6iyZhjkpifRr/ruJPDSoai0ZdwmQc M0xJ5lXe9lGTZLWMpdZJiuvHenztZ0pT+jyMBrcTy1Z/jyRsx2ZoxOfN7CbOmr0WvhT3rT1ng3p7 /cSTqd35WcXELaAb2WyB56WG9PSkC1R2wopJhKRDr3Ma8KnzvCSPEUVU3u1qkYtDJXr5rxHyRc1s ClV+7CSP2XoyFoa+SsL8hdz/uxf+i1syW919YeFycXNj7TdlDu7v4TgrWy12S42b0mqGLTw5feU+ uPWL9r1vIog7z1mmnpFPf1IV0K8RPem5lnFx0dW0q7HmerRMupzdK5RqsuwOAdO5jQXBJyUT3svG 0XyXroR8v3u/wjAx5sf1J99ksuZMr7HqNK3a54qMeDksRnm1bY7p7Z4iVn2zzZVsN+glQsezj3p4 25lgzrLXN3cxJbzTIe1951dyWYlJx2a35WPcD/1kth7qf6qsEfKgGL3ic9DgbOY6pM3Gaz36IKN4 8LLLdOvyASZILGZ3hx63OWZW36Xz3Z7A6/OEDvXjZ+iFY590HpezqrU9leM2xZLJsZ+5pfBuUuph 0aRUZMa9gdzK5ZShc65UlO4HLbkT46VSa2h3fg6N0MyzqdFSDySFnwaT1hmGnRdEhJFMhiUoplWc P54/MRfU1zI33VtJMqQoeiyaiLp58t78TuyWy0CrtVhOTfLGv2/2/V0GBJSvnuUNFp+7yO5+IpWU N9GmNUA0cm49TdXz9yyxREnnqL9jcib9x67rgYFfWOScvioTrIoRHwtIogtXIBs/fErQ+4rm4z6a sCKP5uMumpCDFKCY0SEhpEOe7N8sdcMlWDC8KaCc0KsSDV6+e5kg/CbZ+NbTsR/7+BFX0IEPLZRa 61ILso3fC2uevDdpG9Td+yacZ8+IcYvjZxmrfEXNGdU3qcqnAoqS43lHydWkryuZ4Dq6blG38nTI HU/u0bhAEDjOu/ls9DB636U5lqMxcPZ69Rul+t6+95oFBpujUUra2jhOtqxAPZT4KwUpyes0esYr 2UamzDyUGw/kidQzl+UPxxdoJqy6UY4Z1+pNulGxzwl6OwyNsosDT3yj0YiN9yEmomlom9M+JNzq oC5caDUkuDNLuurztopgUzw4eponE7WcIaTg4HOHaLVwNmFqIojgd0cCf34YUbWia+4yG1UH3dcu hw+WxJw3iUjeaRK4WsUyBikQNmVYfLHd/0kUuvr80tkxzeBrmRt2dqvPW2ZQTwuM9JjTeW3GxpxP kq1yBlzmiusgSFkJved1uBtwL2mFeu7Lo4ndvO3DCr8s/qTD5Js5z9E/Z3RlWc/g2P22PjJb1p9e 8mFlXdGrtbhQzvLo9af0s980mK3PR2S+79verUh+61wy/u6rT6WLTnX51Hq3RQ7dSMLgWJyfzKsc ut4bG6eHHMtFB4NKPAeoyrTGAWP931Z7u0gJH5e1qdnmzvhMAZUrUakc0hI73BOztwAUanXA/6V/ D4/6aFqjRfFz4ZsYFlL58JOYZgmelGfVdFz1xx9rxjx7/MHWnHXqjKnmRwV5B1OyShHBpstfCtXs SeaGLnxMHAP3kF+UonI5hhBcyeDBIoLtbtw5hZLOrNdy0PH3MDUtIooXVL30hSdTTt701APpRGVm vhczlLRU+YKcAaqHT3e1GAIuHu6G8DZMizYhv4h7KZYI+UsHoypWM9EA15YfKw3N+1FL4mAx+lit D4/Ir8WM7XY7XqujAaiYs4KWxLK0Pmye/Jg7tsvBZ7LsG4UU35IJZztxNy2Hlib0liY5Dc3jQJ2n 589eyorQSxHoDD77xDZRmJ3wQfbex3IS47jmAr/Xkm+4bSXQ8Z8GJkr4e1l2u7//jBcriInW9y66 0nNqej9o8qp6eU39YNqdVh9kxX5vSut6wU2abl+caO+spDnrl44X03e5VxI5JzIRBWkj8wzcmwf2 0evrlVE1tDf0Gp/t5oZfFxikKeMY0Nev3JA0GMa8KqO0X7bPfJNSXb63/2QPtW290j2V03wlPu2M 7D799tyVtjf556mSerLqo0XOL2RTfvr5iqTViQc3NS1a+kKyd9NdJOmdCaXfA6nI+efj7NyVb7AX C/qiTYb9mPN7o52kowV187jHbzJqFWrLflwPyjRJOaC58vSppk+iH4mtjdIHtn2K9jxUoMl9v3vz RUofdvYo6I0e0ASR7jAuuki8FaxRkA0q16XjpeqdUdn6adHEo5siWz8ZOwUEm9j73VuSL6YOTbqf qLF2kTaOU96H159kvufCB+CAxjj7RIBVxduHIwVu31ofBqEPO3d5OPm5zs9KVbN7T+ln6VFkP+gW 6boXGjT7e6jz+lmm0EByaRENG1IK7ZZJYdF17ufNqwGOuy6sJPEz0799bKt4npz/6Jtwkayrc8p7 YfqgTEC7+TSGvzKGp4mvnYTvV2jQhZUv9xW0BZtOt1+aZ7nrwez9wkn+FDNJrGUgw3t5eRrvJO4C 9xxqhaby7K8MUydF3bOkpXzv6se6Trz9lhcaVLJCM+PldL9bj67jNL2qBQHmSTzV0p2crOIEY9XL GVkLxl9HP6+bieQkPRIUeX8t6Oo5W1vngVMJYyIrdhSTb91dih573DHs2rUkH18MoGM+vyEZtqPx aF5wY+R5SknRu2+7lYD2XdSP9W5b8tfvRct/v96QNFRZst3T6uPxO9H1WsUgfqO3LM7eyb60YKEC PA5CpRg9Ty1eGHpYccxZYEKjISV09/gEXfdT+asna9eMf94obXLZzNGKzz8d/ejrBfkTE0mXVyhV BZJNY9TS5X+TkQqF6Fc3esh3ZbBkn2LO4nSIvRMU1FAv8uybVIyG9Lf0tftBU/UiLoNaMX65Shm0 pJSh+ua7A8cYQz+FZJasW1rycInohgZxNIgALMzmvDbfr0pwCzYp/lojU9JMoJNY47xJrMngtsa5 G8KPP0tVxYYAL3W7+EOfM9aPOZXnLS4s39ahoR/5VcP7sS+k9cT4fP25mOUfHifOOYVHkJJ6j38t Rd/2ir8cwT4yJfwhBOvdyTBxeQMd4RU/Scufa6GpQiNQcV8n77yoYxYHm0DHlvynrzUTSa8JW7X9 xncVBduN9+PcDWS7mFr9NS77d7Ktu+anqdvg9O9TT9vG3h1qCS9gd7PRen/wQ91F6jjxGu3BqmuD k/98i5RXpPHrPAydZ8wHyf2h21Me7L8SsRM1/AWe7e5x0Sqfq+oXpisj39Gh9Z1SHq7EXllv/6r5 SOGOXV7vyEBSaeS5uxEcngL3LSdH0yhNjzWcCb3M8IwHI28X1C9Lberv4mEhoJmuSm3fhDJFZtX8 woRdt6Z+JC/v1dRqaHPfo/pwfkLYMzBOg1bj9LvcW+xf5fq4sxkJqPsUA4nW006u5T+XW7cke/1G UHP3ifxVQqprfqaqT79o3hy2HH+aoJX+E6lo1Nqhlf4DGcxlw5y79YWhmoaT5KIMssJAA3Uxb1v4 bvh0wHO5T5YPelo75NNHjimejzO4w5C78aWQvFmZ56Zu74eEggun9I5nfSCk7jsXQWQlR5uXcIwB XYGZ3p2O9nmoFcDXz05GKRz5kXw/pBwZmnm5u/q+Nm3w5e4LYUS6ip7eiS1kpppInJLGT1oKcQap HPV98jFFsbozl3kCpNeCvGv0DAPuPP7w2SVGi22rg5kXWyMd6K3rdtHFWT7Ay6qF6YYS4UiGxDUv WlKrkNvW5WNvA+lECIMMBQMkSpoo5DMIpjqAH6V+7oQN3lpnjjvlyr/SuoMp89aadmX7qlMgTNXB gHZabvJGjRL2T/FS0nYIRauGbtbSq1oJ1ca0KTRr1T49jJ7/fFNDRFtLP+hg5pupIfv62zEVwZeb dl7Mye7Ov1M9fqpLVJXz2SKeU/kXKi7N8/zcrQ6W/xa7/dXA27ekYueU+IBQXsoM5nG/md20m9N2 7n4vJapdSaqmtYzAnqfCSoctcrP08njm9FJ7w4+HX489E8BcsUvtP1/kbbra8MOf4llIc0dHfse9 6oxrdTaxn5aunEbqXeUSexYeVPhJ5Jk5V4zGlU888XLBQceoVo6Ve0UuBJEoiVzUF2zSHDrlSU4q FKaPeZnIk5KZK/+EjlQtTJ+PPJ1HXSs8iIeqi7m8aaNU4CNzOL2KROr+d70wFWqr5zyXnf85l8Ju blxrI6diOi5VIx/Lkn2ayTekl5z5Hp/v54NblM6V1Nr05TQjTINTtalqbLdDOn1OSlV/P14fir3j yPN7fRyI2tpZplKuruRsZBo6ZSYv/9TL1T5SYMT82OkwrIR64cRlI1ShV7wvrcjIlFcwtc3Jb4z1 1A7jPWejW9mFQpRpUH6azq4FFRa2dfhpcquNsW9ap/Y5Z187k4JEQ87t97ki02zJN4luhnezCDny 2r4rsZv+xNujQXJcYZbwUZ/RlMiL8nzso1HZd+uVZFZ6l91PuJuwdo4+WAw+ObBWXd6cZWBmo24k a9hXJFNoPDi3M2BAHnX6q4phliT7p+zCosdVZK/PGZwd3ixL2vEw+IWZKFNq/mWhX9Du738m8fLZ Z9cwL+20v2cVq1kcCifuN39PTJH7cMqwq/pS5l7OzS4jNq18jWfyD9yR96qHsm9YY30+u/vihfTW DEtOkeG34kjL51KBXXoBbGsB6TzUmuGpBszmhDadNuFBwnIiTzk0Y0gf81sHKc4Jy9E+faUVQ5rL X9BFAX7nM/TPltcTIooJgtIKgzapiwJENv2mEtWCqiTfin3wnzMRvm04rWZDIH8qPUlatY2oc+Ut nYA/P0fzex7OU7nyBZJUCiTl+do+ct8mBqZkuy98a40KGpIfBVS9rO1OVJ+uTlPjcMy8LZlgc9Ih 84wJcwPv+9W8bxcY6jPG51y08+Ri0mZPGv2UbTjjJ1/mW0lteqz2npGjMSufgM3vIg7XBLor51NU Nayu8AmwpcUZODHwCaRO3fPRikn2Wjy+oSjvMnFyRGTrV3+DeqgJB5XpMbFrH80FQy9Xc/i8DjZk eDaSYFB/xiH2aW9qypORGEWNySfzPcryXRMsUahHFrhVQsz0ocJNYlyrWdfEUn9IVilePgOL9vZ1 5j8776uqCx9KlA4o2X5r75QJcbFof4DOmHr49oNOU8d9Gn6+8NpT62jetccjszayP2/O6yfMRe3o WLzkHNEm/+Fa+i1jl4hJoK2w/B5XpnTO3lzLfOanHr+f736J13v9EuwhnMF8kMy8+y0x/2qvNPUB fm7t2X05/1LsI2nfhxJO60x7/d7b5s8GfkRIjSaRsR0efBFjWKVu2CNC1Mr99+31A8f3cjRXcwnH jEa1WxxLm26s5XSm5YvhdVZZ/vFk0mUXZlWBtzUaxLRh5oKqt4cm0GXUcSdLBT9l8DxxDh8SYOZD OnzPagtyAzLJ+JXArdgvAUHmyiJUj8DdTw32pYZaCMtwHN6qHSpCfnbnqT7+ie7u2nNBh6bY6sO1 OALVpF8K0W6WQXT9vj8KGJ/xyxDePcvY7y8V/3sk6I1gk/nQKVd5+TOZSauCm8SkTyKGRwwZT2YT s3Aq2pJTESVFOR8U/rpVRd3FVI7LvFe29fmcxNCvsYVHWo3PriKGvFw3HrBHiz0qapxsPZf++4xk BLpC6UdQUP7vM3aRaPx5bxaJP++dJvHn/RB43mPx5309rY3zz9BxsvJlm+P7K8otGUXEC0vXhvrP OUiwFV6aFrubc694zHG/SX07utTg6a6CvV4p/7eky4czNmjRBOcpZyHFkE/ClRvztpvdRoP6Cr6v dTdKo86JDbGeeB71rt09QbJc5EneV3/1jYFk/o81/G2yhts/Xuw+W8c5r/WfsZPWTrlsGABokZXv yvYdL2e9d/KBlVTvj4B3Ay8GMLUiOZyaMh/utPZ9Ti+UvxX8kew+LRU7M0bwV0F2YfuJPhcmQc0s fpIVHP+gTr1zUmKGbmLSIpCtvymt4fnyuA9+Mg9EDpNelETnD7wNZ2NxJK06FIwk0PWsYRbUPHwi v3SW6pr/7Y6fYUSlaSdRx9PlpgUeKMafvJi3m//ujAVz7s4XBsvKRR7N1SfyYmiqa3dv92OtSQLj 2mlshbFs2T13e30pp4P+kWXv+JfBcjUCD2LoKP+RZafFuEi5ksIvbXGup2LzqbrGAtz7GJQJUekP 9FooQ9lu6K+0j9GzNQjKMdmRCARyGnnO7O8OHidZ6gAXtsGuVk9VtQhsZ4Xatb/L0dgk65dcrCEk JDPddHsFLmwJdNvmRAOkUXWYyHzROukvhfddYv+VZfsF1sch6zJ0lAYMPFxPi+9d1wrwtKI7bqRI OJCh55OyXP6/ynKZ9X8XtoP9P5QSo0PKjWiPFraxtG0+nIUPRSklZpmlmSaWZDmZnrYYq1qOP36P 3s3ZE5B95FpRcuE+t0hGWUJ9DdudKWPrWjau+z3CTzZ/la7uSyzpL71fWib69GRh5vHuzc/n77Se FbFf3O0ajUfqbPWcmEkzeufhXtH/g9Wu4vErJUu7XZ9efwdqAwfHBunmjOTF3d4fnRtll8vLf5VO 49GQmziP/AZ9PpeudKGPyXrdz8Ae4rzDU/kHAqhBkfxH2oRpdSexy4YD8cnE5cvx4s8zWeg7E+Zy PwWXfDKuprZJ/fCQ97SUjfPEt/6om7ps4iVm+6sZan4k8hWZLALblCNa9VzHM6t4xrRay1Sfk8g3 ZCZJXBQhlG8yS3JK1e6TY1jN/fTh8VgU78lXh6dmOg+eAloxa7lKS+RUxVxvf+HV6FDpW+b+ul+6 W3/mA44L3YYMm7n8ZqturCQyNs2WmOHsm0OJ6qGbxhcuDBg7ilwMuSATkIymMp3ISyT3n2bzFQwN 26OZJqYmvRVrfOwlsyAn69z1b9EXmEmUbTrx66hfTWY2sQGk8j5TzvOFXiuKw7cseFWfBr5g32OT 7kql+8omu8LXIqsWyfNSqZ6I9GTczfMaw+eDjWiZL6gZPedbSOe5tDJQSWEawKPx/mU7WYKjIE/V uXGanwVDkx2zBXvtJttkraYCEhlKJRVO2+Tiu6dNmFqvHSicPU9l4Gs7rAae/De5g8uYb79LOH6z 9ZUIkbzEBwPabwr5NRZMlSvhM9oRPYiPDr4+rS6eX5cb9/MPXzQd32UfjNiYnMnfNHlTVizdnx/d v2ulrnFM1kBCpnv/q4f1rbX+2wXdXwWOL+Z1Bjel1WwuFgrs3Bj8gLEaHMMUeVDYryykr6iN6L+X aSxv2Eo6Mco0qW96V31vUfY9P/4T1D//3Ura8hxlSlMLpidlRL7KkJNHzypnuNVFVIXpb17fdZe/ wbf0KH6+NvRhfvkQNfO9C6Yd70K6GGPdjK9SSjKTXLgd4yQnf56PjJ+EeUrRtON8VJDb1qCTDZfc nJ1qla2IgjzA9wD3qPQ5DytT8BlZ5iwF0w6F6KBLqjT6gp/Dux7GuPUlRwepqtKoC0YKUtxrSCeJ CMKp0lzdp0cse9Y+vrGdTzDHoFqV9i7LiOGC3O2Yi+FBBKo0vzvu9pD+jj7plYo82E3RHmL00K8X Cy5/MHZZTVZGM6alX4hDO1VOMr5osDB7TlTV/Nd7EZeTcjGfU0etMhEsiJXrIUHCjaYu3Sa/utQi PlWbuzGTAKaaYcryHGbWqlsUpLcipj95pywGCTYCS5LjjjnivTqqVKQnI3oCBY8Tk1D+8rYGDnyM diLe6zofT1KZ+7VezcJ+F5EwZmcy+8kk6K2K261PGc9mP1D5H87VteCPgkWJ3jn9ePcW/6ntLoBp rVKzObv0282LD2rZuDks0vN+q4suPCp+/F6MVbVomL18xKos+72SEduP3ce7evgzPpxt4MudVqPd BpkvjP5sricO7fR289xwNZaYZ/0vagdSZ8+E1GxobCgbuHl+GlQffF/qXfLawVXaT1g1rVaGjISe 4mDYV245YIzwQzf4H+KgHMIPMiT+ZCmSF8N3K/kcT2YklNrEzI/684alHBQ/EWRIilKKoiY9Zd9b 7DIk4sOvydPL0frC951ciXP4yDXmUOxnpo9uj1jcouQrqEk/RumjJjR5liuUMtlIFdqLKN5kyC1L sEjUbQyaRm+MWIjusyq0z4nhQok+zOiaiwr2TIjckY12kdXkMeUMDxC4GK7nM+75dUuQoTTKgr4b T5Yl1onq21YJr0UO+gTbLraNsW05pHyeR0rQH15KjpfN9D/zyyXlwFCAdfP8PoWb6eSlgtPLl/xI JJ1Tf8hmcade7loBjLPxs1X88e4dyc0XPfh3490/xEZenm7GLt9M3CjbUpkWJ8U+r/Z55lMj3Sme WIu+tOoh6ryTdG3lpPbFlbvWT0tmiLZ01A/UnzRnXxexCTG8Y3QzOB7j8KNlz2FJb7HdNV9a406n gcLORpJ3gVnfhx9fd0q2v24YzMiK/Sii6eRCu5R4yky6+RuPjHtxIzlLr6ToaAu+PNanoq+zWp5Y jnAKXnldvpC7m7tq8y7/bZmilUAC93sZMgPaCjYn9JhNXU9AHqGOP7+Bb2NFUrzcHGnVNVe9C02y PU7J0/laX3jCBVmefPta/HlOtDQ/bUSwMuCK54fiNpG8jQVTi2HkrEQ6D7lmuBE98xSBTWdeVBCH nAhboGAT4bfnLwmzXQmQHE+HNGOIc5W6UVQuBKUcKhIu/+zZ+s+e+nHKMVFE3wodpsU1Y8hyLSiL SRiyCG2eYPWIKLoI3k7R8FeSkFgH3GwzBFhUcwhtQkOmjBiQFeH0bL8EKRiGAPVxwpcsnr/xW00c Qx+7hyslXzZxmt2pjftq/LDc+F0t08w1kvsjybsn98zcHB51dj+TsltbO6MdkTrSMDkXNX6hGvHt WbUpzfqZOycVa5pjGzUdgSLxb88MHGnWXzw/oVjzUh//0atM/F5sySM3vM1yscKxiBbDakVhZSMO FxwrP2sWx8pFUdXL02JZedNfakefVilelBgX0zqc6TJVZsu+IabFndSeK91SLPopL0vkziZH0fvc oST91mQbdXRbSM2rmrui1BWXrUStlz96tz+rvHm2WIW2bUDWOMvN31Imxosbm2L68lj3Z8xqLzdr v9HgBm+I9rDUY3KHLI213q52Plk/X5qK24HSYz5162bmJ5ykx3a2/WgruJz++eSQvM+h6pgu9UDN Bb0FUZ2awxuzN1NGXMgEQw2+FKpyEcr7UVWZomY/ycn7mD64fMdD3uPUA3RiBX7NYUpWOSKY8kx3 UwmQpNA+hrBqyOBBMtYnZ30J4EEggrMImaf4b8dM2tRyJvptDluw7LMKPVxPYn4QFNFAA1Az8/GZ 4qJdjmnGRD+WZ0JczMkc1fGJzlkjlu+49UD6kqf8bcqrlV7Ryv12zbXKTjd4TOqqVjmL2Q73aPI/ yspa5C3Ri3XODd92kXj9SrZ290Z3msqj62szv23X97wfxNgcnD/UFfFPHc+Pk23PuPE5zdI6b6Jh 7FvglPuMe+PZrXrgduLjNQ8b81folYbFq9vUxgS225uO+2xUQvy2laiF0qTr+nwPC96WGd98/HxN 72JndYnPGXuJr+4X7rQz/fpaY/Hat20ndfogSaKnaF51ldL1SSbt4Bkp7p4Yv7J+7JXx8DzL0I2C uY3HYlnf5xm2ZfiS5WVivdLMJH8OuB9X68gU6eKaF0X5D77EKAx+xVAPuaVYSx03VJHC4Pr2ttYR 4jYm3+pyA7WIM8mUaSN2osV/IhtLLzFmP/p2VcBYLtNDts3ljWCv4Rn/n24OD0AsttiaOj0VJDVM 2iqOBLE48daI4SYnaR4GMask9+HVZRqfJ1qFNseClVmpbtibdgSozF3f9dxUvHr8n03z8KDrz05E ZXKI/bM5HwFulh0WGYuqxQWLM9RcfH2n81aw7KxCjcuovxQPpaqO2rHbN97ynP3Idp5P+W5Cwcsh UZrhishF3pWvwQEj9hS9KTl0hDWDDMKx4Ovu1ZhzdH3kFLPDD3jsDQJ53JYwVWnkfZoUA8Nq3o/U Iwi/jjAtq9NcH8sSfnSCuCuQvzBch+q2s/Pn6MyTF8SIX+qfuFDofRL3rq5i5W5096L9U9ewBMfU tKvTz2aw8ts/tg3V27baLt9oKbIhffR640KDt1EYs3Mqq5RS8sx0AuOMd9GNBm8H8jBcO60K40xl ttDEeexltrfm+K9fpAl9Vvv+gerTqXBFOyfeEFcO4VMhrkbT5KUCDX0F30ZSBPvmNfP3mIh9/Otf sFFxGChQ5rjpZs3wLyvuufBftxiLc+5dfV1TI9Qrc4n9juFIztuEXbfxhEcu3GKCIqVC2IKNdssH i2Y/pHGyMpdf5rq5DOBGq/qGBmIqSEp67+ed4z9mPS/Y/etrFX3l71W0mmfcIt+wWlW8m8CcRldK lpTaprFa32uDL1rTs0XpBhlnTWbm2y8qfVhot40mrGxKyjfg4+H5yUw5E8kkwXSCwcNOLeG9NM/i 4zi56Te35MaK+O9WINymikjPDbKR3OO6egpLR2waLaQXmkJCFBQtMq4QQNj5OWmZrMxSgDtvs9F1 7goJ9ztZVoAmVKbs3kwQ4fjnhKzMZHqaUNmye+rAAzq53sDRtgZpXp7O/jh7/2HiUxdjExS3Z88V 8R/+Pi5w7AWRvklB0sBeU2puZ/Sv6pv7k/WJe28dOAzQO7HvMhxkXYh7llQWKyUPVNG32rlf6vzc OX1dy9c/a+PVavQ1r3W/qxNbFNtEg3nfDrkHM6oqv4/+1v/p90xz+azs1iRPgs/WOX+uhQsNjlvc j6617mgP/CLIuDarnr+QcCi6JOZ8Kw6rNfByQ3B1DGvJ6VJZ3rf6RndzE9FXXvBG/nOC9Wt5Uvve +bP2VeX8q+6dwllJ3w5PW00pVvWJNXdsu3XsD3o7aiRzcpaqpMgivlj5dHUM6Y+WSdqjDGs3aso+ 2mvYs5q3VCnG0SzeGpzZ+TFj6zIwVdJsHd99JueyxrPkDWOXgU3vB8XHTjyVR951Yroz75dV3H2i 5I5aIOl5fga7mXmuV9kCu9Tfq4w3CR44UAWt/ZJfGFoUzYsmHBplaoqtIxhxpJxyMiOYKSdxmRQP WNInEiI58XSefZheyPxE3apIILM5zdhW0hiuZcOUoBa/UxYiYFA/SHU66ZaVh6M7fZGwDNnyHfXC xfPuFGMbSSYPwdf1Bzw63G+OMdTNicgPVLDIW8k4usvSv3nJUPIufkUUf6KZBArp9l/iuRYYX2xg SiPH+KJO1Fjo8adPnLJRtxlqaKrRA9U0yYaCqsjCz9abmK8SSjt906uuZ/eQTsfu+ZEt3nRp9HQo Xo7WO1dhVyqQ3i4nxLR8UtAjSJp4ukSuXa6IZepkITFhKmE949DJQlRgCmF3FkKdpeOk+P4lSY0W uhsUbE84TIOpJZInTRglklfPyuZKZ/Q3FlwbTQld+8rPkuW4xv2o8IOQWDih0UcpPkfM8duN2rcI Hw4+Q/dgr5dySWqwew+PChTaREt+Qr9SDlezbTGMV5Y57cYtVrDtfXiGn+Wbmtrbr1Xrjk9KEfob K2oGvE+u6ivp/hja234qKKXl8fzXhe8Pi49ZCLRoJKQI7hYIzt8Q/ZEbR+opppNL1b+981Zby2l3 dcBMTrSY/xwrJUWopNJHvcwLUSRk9zj1mbId6UOlXvBpVtqeYPCyo+R2oOH0tvvQws9OpBAtFMse Qlj0OUG4QYOI8MPnJCfeuoBZM3Uv4sG38dE9dyYr1wSCoofTqE+SXeDW/+j6IWDZ7GKXVhs5WQN+ k/+kIjnPfJ2j5UQqQ4yVXXNZ7SIhY7ZqS8bdtcT+uMOtsHjKq4EihTrq9n7mV77NqngYvT74PX7x QA9L94Ztv2lYs5y7MvDn5ulNA07/rKeFM9Hfzrnvx77KfS+rfadnW+VstU+tkPPde3cDF67/PIxe 0Bwe+rW0JeJee1nQK5F7z5mhfl7nADfwMHTwUYKa/aNd/9IJbnXSyoYejUWGa94PyeOrL71qUX4z rHGcKyeKY2Mgp4aS+9WnE3ezJbMlQ9A9eg8VUzY5ejOpbJJs9Tqo50Mx0349B9sxNv4nEWm0Vf7i S1+805g53WlNFhvOd690/zjglRgNsaf+LhM5P/yjr0yJyerZmbm51DLa9si0gmab+J4zeZdvPMvH 6NkXD/g324zOnGzRMJkl8/XjjmtI5b7ulLXCFEyFe7gypTbMN7hdFWIz37x7EbPcJ53+ejCOx/eO pv4mSTH9iRjiSw856GmaCF9ciJIkmyLAT4YMxC4BQrFdARmuAfy4rIpbcnTi/NovEDzkj+MmBfWj CCXqEppufQ7gMLl46rdFcIdWHfM9XQwxcVeAkJ6nBiER+Hoqh4DQui5uiupTKQn4gRq7jjBFCtml D95OC/fTibDbhqJSZCQU+sWFv+VymbDelb9OxEjYPTRc1Ha6GLsbiUtVW0P+7rVdRTp73NeyMh/t XnTMdK1KSFVuK+zqbrqs5cNWGd28/8B1MjFD+WcY8E11XfsB28vYFs3TiY9P2mT1nlOMxOE/DnUU UoysyMS/Ie/ObcV/WEiy4LdCVyTo/T3GzJWxkmc6hrWSZ/2srKAOYupwJ7Gr5hhj7bi/gent9eyS vqWrA9kkxkRXGxyJ3PV+4GLvT9htYvV9u+/l0fWQ0VN/katL5xm0V7B9ddbHP9MdNxdSApQeZusj ub0S+65MxStzdzc98xixVLfYS43C2L6vkRVWZ698nXrpzMQF5+1Blh6srPGx8td5Ms53JjbMQh9X SDvvbvtcHkrFv8F/Ujtepr9IlX8/m6qlJ59I5te+XtG5in1vbnECD4m4xDxKknTBpEIafhc5cQIl iThB3zsEYcX8gS2cDQTM06pbhWZWzNMUN94sMwQ8t3s4JE8jp1VmzlvGRSGnFXUvnJgsXVDlI3t/ Km3GlxH29mzZwLTkA4MRcQJZCaZUarIxAf24KBeZfzZFe06wyT4h95M6tnmPQHxKtWzfnV4OIywU stKpY6p+MHlO4wwpL0dgzc2PxIp3Tp0XL1n9SNxOr7PSXuXsdJ/kweKDmLoOWmamE1UzCkSKPVkx dZo1TEwnXoXht0p1VE1yP1JT9jN9VmnC4zk/3/IQ3afuhYOoUe3NwXtBOtsfRo8Vcfw23h60EWg5 zp/U9iihZeNM07P13QSsVPnbmbiSTJtiZ1t6LQ5LTrOX0j+fOf3MtU8o7BHrW7onmFKwKJNNNXyb tffV8wNl5d6znU+zLs+lRadvFJj9qMmJXvrxSXap+3RGvKS/dRnJXG440+JOmeoCsioCKChrKURU bq+iX9po92S9Urse/+rM9cuvdsRe/tw9r/idkmY4PTOrcEZlwS8rjpVsoU3owpOOy4UpBXdyk1J/ iZnP+w0Ts1XxU3S9JS91ffcuX4bMzV+RR4WI2KeWN6Y+kjBllKEpsj7gvSNFFoPJ7JvD7/sxCg8I pUcZVOUbA6IcKaIy7cTI1u7gf4SNuKqGN/Saw8kHDpvKmwytE2ZytViS+barIQEOjhRJTfhXo0Oh pp6QeRISNx/FGMwbJYaqdvbh9mDbsyQLi1nVrfyNAbomlCyYYxRHEKl9j7+w9f8YIlVX/0BkAAiR aXiInJuBIPLgCCLXQIi8i4fIT6l4iMwAIXIKD5FU5/EQ6QxC5K9/IZI0BQ+Rav9ApNLp/wUiX/wD kaEVvg/3rd4ZvMjTsxF+9JtJGZddLyotJs/d9ahLo/TqNb1GMU7s0GCgyeOz1JaJPYH1ne9Khe4R 3z5RtlTOrODtfyuOd0PLRjoImzUZepb7EBMVkXyFezxk1SiV+21mpscrNc0JZ14t70z1ThL7ooGK quSFdxU/7H3sbc0P7Cf55If7yuZAvCzyMV1v+Pmw51iewI0r+am60kU73EU3nV56UdNfc2hBmhTz iwKkOh9JaYm1k4ScN1QlWhMqZqcoz7vd3Jvy9XKJNw59+yCg2kKNbnEgLVT/tj996HMBXFBCGhdD 5aVmDxfpwIAOi4sfhfjLyRtEr07cal08s+QS+uih5VMq4xcX2pjJGsSuMuXakZGRiF89pUJCfOox //cKW38PIuSdVsIPATS3L7ZlVzcEMN++OHUNPxkj+YkGTsQ02DXvfLQkL+p6Nj8aT9/wG/U87UG5 7rO0B2/5acyjPQ287aY0hWIjOQwtimOpn1/DuNDG79LSK8cbl5yvyqplFiFnbRa7qZ/wtJ/41IAq 4W1VdqHfYdbRhheE7BtyE7qVf2mq2Te4WX/rTexVHpP3tifRSuhXlgulk92uvZUqtCU1S+tbP/1W Z1teYqhlcT9M7Ndazn7x98hBMqLlVNpf7Gt1ZmzfClV/RssFEh1Q/lQkYPXoVBwMrko6hl05a9iK IJoaXxH0vsfhOpuxqqh1WqwvMXDt2i3CyKaUcaemzuVM1/c548iuTRNt1PjeFcRrthdPg46jSgP7 OEpfr5IR+ObfUufKuzUy5Ww/knef652FFRdNyprrXAo7lmaB8FPkjGPYSKP0r9+WCuOnV+4De/PK l7cOqiWkAr546l8N4DvbiLzP4QywjCQzvHL8oT9gYdfhZxHsWLtxy+GWp9fKrSVcSWGl6WaG9/pe 7N4zMebV+6bvNb+whm0rIIwFf1B/upvxGPxQ4TEu6mYYIbuhYwype7o4moWJzdDY/37gra/yqgfh XumA9Hn+nU8lpVpmiADjCylXr1A99GUkFr2nrTobfnLWIPL+hfehgWWPFbVVf4Sf4GO28aKrKH+t X/yUmWnjFJmBeVZMLitijPgKFaUPI3H+ihkvQsy0rvR6GOHKqZ+Y+ppEhVNGDQGtNcxMy6fIJOtf xylMGDYEtPMI8Q3ZszOL5gQJNMh5Mrr3C6BZ4hZMydyiLvI2i96OybIR5utToglLzuvl4ev5RDPR 8wbVWVzsenf3G4Vd6FhgCGf4RTeMb+v51MtXqOgti0q61z5R8Hba+ZjeEQ/3lXz63oeXTPjZwS0f wXDfnWs92TGqLIgm152GezFyLHnK/JcNKR6adVPzfehvGJiXsPOx3uTB7C8vn8Dse60wYPYJ3K5I GUkHXD5fI33nk9UpOvLUalMU42f68uAbHnWRg/LnqPyfR2W9rBqXfCoxkzu8rDUxWPGFNm2RdHOs F3NJOOoOqpza0Uzd76Tn7edvy0t6o48rl9/+NWq6bT9FYz9hXxFBc3nmWT799vhUaOHYp36B05nJ j5YYu+lvyDSK2+iSerAnPRSY1kEII1BvUtsFJTNnI54jw9qgNwftWijkGLqei0Tz6pqJUklC0qcA jfeMqmKzDpsnpAr1L1omi5x/Qsq5Qik9gwMyKCKDVXIbd0je1teOUajvG1OQTxTUfutiUol31kCr mN18wxMXWEh/5dEd8tpcmlTZs7Tt9W9Px+WIXS+vzBtf0N1/NeZ6ozZvemSuaKd4SIowM+0e9am0 5Pd1JGnRFeJXDe5y7NZd5hMT95O3ThrzUaqZmvqksbIy/owzIyEgTG1j6+ZlqqmrJ+lJfBlk+D36 XKav6L6hH3TuePPIbUBRa6dgg0Nm55rezPsDbUpuL2Zdnbv3q3eqTxdEtDBFmKkwX/keVptNnoyM up9aTFKA7Z0zdLZSd1hRc2AxZhkVY+FmTWOtL+Y0Ei79MH45rDJbNOp+fDDr07zgqjog9y2zsc7P 745nekZfhcs+ItPgQ2mTi5lcdmEbt6mkr7op1XX/LLETScHmz++tLC1fXvnov37zbvNVjTZ2/fI7 74JX69mSkrvbUu7BVH3zb0YMruft3IiN9nUqdlzmM1X5LcH/a2LUMilrwIV5xt61z7DctstzrL6j 0Mr0frSM+Tw5pkS+M8Pw6U462o6zfbZ6sGReZ105JSX3zX2F3bLA/mu7b0aGat88e7ajXTo/oBJm 1qpb/oPxY7L4s1OTIgGeZmEKvwifvGjqsKNi0zN1nRv/NZVUImxZ3XfRQG+NserS27MX1lV6rtmG vrpjmPfitagEh73IJ2T+fPxmW8Tbln6Zl8nq33/m3sy7s2xQ8/K6+/abm549eWzx1DPFVYN2P91z et09Rx1GxsiGyr5KqRYvkru4uxTtkWs5mo79T79X+ecxQAgUGvxjo9BXf58ZCXvGgua/z1PQvOUC PgsBenaYtoWro7uLmYUrzz+7Kjviv/v3nTgP+DAJbfABC8oInn+fX/rPBsDz71Nf/9lA8iARKPGj TfD3MqFnOYCfA0f/iKaLo9lVCzce4O+jFcQU8f8SPhBXcD/Yw7n+Zof679NlrO0RPP88K1D7nw2A BwD+bCB5/nny0b8bKB7k393QPP88b+LfDQzPP79v+u8Glgf1dwAcD+rvABI86L8DIMR50H9HwFcB /XcIBMCD+TsGviiYv4MgUDxY2ChoHixsFAwPFjYKlgcHGwXHg4ONIsEjActZnEfi7ygAgkfi7yj4 avz7APajTSTPv8+IPtpE8fz7fNyjTTTPv88PPdrE8Pz7hMOjTSwPAlZcAMeDgJUXkOBBwAqMf4uA lRiJP1JgRUbio4KVGYmPClZo/M8hYKVG4qOC1RqJjwpWbCQ+Kli18f8IAlZu/KmAgNUbf0QiYAVH 4aOCVRwfEQJWcvzhh4DVHIWPClZ0FD4qWNXx4SNgZUdh8QclbCgcfhM2lAQPACs7PlcAVnY0/oCG lR0NHtJ/h0LjD2pY2fGFAeDHNRq/CRsKg9+EDYWPClZ2fBUBWNnR+KhgZcfgo4KVHYOPClZ2fMkB WNkx4Kn2dygMPipY2TH4qGBlx+8IwMqOwUcFKzsGHxWs7Bh8VLCy40cFYGXH4qOClR0L4E/yv0Nh keDfDv+7iQIfQf53Ew3OMX838dMArOxYLA8SVnZ8vEhY2bESPEhY2XHi+M2/Q+EQ+M2/Q+GTQ8In FXxUsLLj8FHByo7DRwUrO74SSFjZcfioYGXH4aOClR2HjwpWdnzZkLCyS+CjgpVdAh8VrOwS+Khg ZcfXGAkruwQ+KljZJfBRwcougZ80YWXHf4OClV1CggcFKzv411hQsLqDfxYFBSs8OF2hYJUHH8iP gpUe/JMXKCR8PDR+Gz4eBr8NHw8fHQo+Hj48FHw8fHzwmR0fK+o/czs+Pvjsjp/eUfD5HT/Bo+Az PD43FHyOx0/yKPgsj5/mUfB5Hj/Ro+AzPb4WKPhcj5/sUbBWgE/GRcF6AT6cFgVrBjhHo2HdAJ9d iIa1A3xuKBreD/ysj4b3A19rNLwf+HkfDe8HfuJHw/uBn/nR8H7g36Ph/cDP/Wh4P/CTPxreD/zs j4b3A/+zaHg/8PM/Gt4PvACg4f3AKwD6P3qLjw/eD7wGoOH9wIsAGt4PvAqg4f3Ax4aG9wOvA2h4 P/BCgIb3A68EaHg/8Lmg4f3AawEG3g+8GGDg/cCrAQbeD3zuGHg/8HqAgfcDDeIFbDy8ImDg/cDX CgPvB14TMPB+4EUBA+8HXhUw8H7ga4uB9wOvCxh4P/DCgIH3A68MGHg/8L3AwPuBAQEINh5eHDDw fuDVAfMfCsLHB+8HXh8w8H7gBQID7wdeITDwfuDHxsD7gdcIDLwfeJHAwvuBVwksvB/4WLDwfuB1 AgvvB14osPB+4JUCC+8HPnYsvB94rcDC+4EXCyy8H3i1wML7gc8VC+8HXi+w8H7gBQML7wdeMbDw fuBrg4X3A68ZWHg/8KKBhfcDrxpYeD/wtcTC+4HXDSy8H3jhwML7gVcO7H/YFB8fvB947cDC+4EX Dyy8H3j1wMH7gf8OB+8HXj9wcEjF6wcOTql4/cDBMRU/Fg7OqXj9wMFBFa8fOCR8PDR+Gz4eBr8N Hw8fHwo+Hj4+FHw8fHywfoBkh4P1A8DrBw7WDwCvHzhYPwC8fuBg/QBREIeFj4ePDwsfDx8fFj4e Pj4cfDx8fDj4ePj44KsFvH7g4OsFvH7g/rNiAPCLC9h4eP2QgK8Z8PohAe8HXj8k4P3A11oC3g+8 fkjA+4HXDwl4P/D6IQHvB/69BLwfeP2QgPcDrx8S8H7g9UMC3g/8z0rA+4HXDwl4P/D6IQHvB14/ JOD9wP9bEvB+4PVDAt4PvH5IwPuB1w8JeD/wsUnA+4HXDwl4P/D6IQHvB14/JOD9wOciAe8HXj/w zAQfEAd+AB8Rv8oR/886Thz8ADYmXkPwH8AGRf+zLoQNigZXhvC24EuGRy/4oGjwA/igGPAD+KBg pPDWoMFI4b1Bg5HCm4MBI4V3BwNGCm8PBowU3h/MP2tY2KAYMFJ4hzBgpPAWYcBI4T3CgJHCm4QB I4V3CQNGCm8TFowU3icsGCm8UXhhQfxnsY1XFsR/lttYcL0NbxQWXHHDG4UF19z/WXTjI/3Pshuf BuI/C2+8viDgS28ALzAI+OIbwIE+DbxRODBSeKNwYKTwRuHASOGNwoGRwhuFAyOFNwoHRgpvFA6M FN4oHBgpvFESYKTwRkmAkcIbJQFGCm+UBBgpvFESYKTwRkmAkcIbJQFGCm+UBOhkwBslAXoZ8Ebh NQcBX6Ij8aKDgC/SkXjVQcCX6eC6EwFfqCPxuoOAL9WReOFBwBfrSLzyIODLdXCxioAv2JHiYKRw p0QcjBTulYiDkcLdEgQYKdwvQYCRwh0TBBgp3DNBgJHCXRMEGCkWPigYKRY+KBgpFj4oGCkOPigY KQ4+KBgprFFIAIwU1igkAEYKaxS4AEfAF/RI0L+CL+mRoIMFX9QjQQ8LvqwHV+0I+MIeCfpY8KU9 EnSy4It75D9eFrxR/7hZ8Eb942fBGwU6WvBFPhL0tODLfPDHEfCFPhL0teBLfSTobMEX+0jQ24Iv 98F/EQFf8CNBfwu+5EeCDhd80Y8EPS74sh8MEgFf+CNBnwu+9EeCThd88Y8EvS748h/MCwE3AJCg RsEtACSoUXATAAlqFNwGAEuBgPsASFCj4EYAEv2PSwgbFNQouBUAVg8B9wKQoEbBzQAkqFFwNwAJ ahTcDgALjoD7AUhQo+CGABLUKLgjgAQ1Cm4JgD1CwD0BJOYfRxM2KKhRcFcACWoU3BYA24qA+wJI UKPgxgAS1Ci4M4AENQpuDYBHAgLuDSBBjYKbA0hQo+DuABLUKLg9AB48CLg/gAQ1Cm4QIEGNgjsE SFCj4BYBeLwh4B4BEtQouEmABDUK7hIgQY2C2wTgIYqA+wRIUKPgRgES1Ci4U4AENQpuFYBHNQLu FSBBjYKbBUhQo+BuARLUKLhdAJ4ICLhfgAQ1Cm4YIEGNgjsGSFCj4JYBeO4g4J4BEtQouGmABDUK 7hogQY2C2wbg6YaA+wZIUKPgxgEK1Ci4c4ACNQpuHYBnKALuHaBAjYKbByhQo+DuAQrUKLh9AJ7U CLh/gAI1Cm4goECNgjsIKFCj4BYCOA8g4B4CCtQouImAAjUK7iKgQI2C2wjg1IGA+wgoUKPgRgIK 1Ci4k4ACNQpuJYCzDQLuJaBAjYKbCShQo+BuAgrUKLidAE5QCLifgAI1Cm4ooECNgjsKKFCj4JYC OKch4J4CCtQouKmAAjUK7iqgQI2C2wrgNIiA+wooUKPgxgIK1Ci4s4ACNQpuLYAzJwLuLaBAjYKb CyhQo+DuAgrUKLi9AE62CLi/gPrnGgy8Uf9chYE36p/rMPBGgRoF9xhQoEbBTQYUqFFwlwEFahTc ZgCndATcZ0CBGgU3GlCgRsGdBhSoUXCrAVQBBNxrQIEaBTcbUOh/rhnBBgU1Cm43gMKBgPsNKFCj 4IYDCtQouOOAAjUKbjmAWoOAew4oUKPgpgMK1Ci464ACNQpuO4DyhID7DijMP9e3YIOCGgV3HlCg RsGtB1DREHDvAQVqFNx8QIEaBXcfUKBGwe0HUAQRcP8BBWoU3IBAgRoFdyBQoEbBLQhQNxFwDwIF ahTchECBGgV3IVCgRsFtCFBqEXAfAgVqFNyIQIEaBXciUKBGwa0IUJ0RcC8CBWoU3IxAgRoFdyNQ oEbB7QhQ0BFwPwIFahTckECBGgV3JFCgRsEtCZABEHBPAgVqFNyUQIEaBXclUKBGwW0JEBsQcF8C BWoU3JhAgRoFdyZQEuBVTnijJMDrnP+50CmB/+A/lzrFwQ9QsA/Ay/fwy5348QC4M4HGaxQAdybQ eI0C4M4EGq9RANyZAHkGgDsTaHEwUvilT3EwUvjFT3EwUlijQAQC4M4EGgFGCmsUGgFGCmsUGgFG CmsUSE0A3JlAI8BIsfBBwUix8EHBSHHwQcFIcfBBwUhhjUIDYKSwRqEBMFJYo0A2A+DOBBqvUQDc mUDjNQqAOxNovEYBcGcCxDkA7kyg8RoFwJ0JNF6jALgzgQbA69zwRiHBK93wRiHBa93wRiHBSOGN QoKRwhuFBCOFNwoJRgpvFBKMFN4oJBgpvFFIMFJ4o5BgpPBGocBI4Y1CgZHCG4UCI4U3CgVGCm8U CowU3igUGCm8USgwUnijwPsG4M4EGrxzAO5MoMF7B/5z8wB498B/bh8A7x/4zw0E/95BABv0n3sI 4I0C7yL4720EaPAD+KAY8AP4oGCk8EaBdxP853YC8H4CuDOBBu8ogDsTaPCeArgzAZI5AHcm0Jh/ 7naADQreWQB3JtDgvQVwZwKEeQDuTKDB+wvgzgQavMMA7kygwXsM4M4EyP8A3JlAg/cZwJ0JNF6j ALgzgcZrFAB3JsAlAwB3JtBY8N4MeKOw4N0Z8EbhNQqAOxPgKgOAOxNovEYBcGcCjdcoAO5MoPEa BcCdCXBhAsCdCTQOjBTeKBwYKbxRODBSeKNwYKTwRuHASOGNwoGRwhuFAyOFN0oCjBTeKAkwUnij JMBI4Y2SACOFN0oCjBTeKAkwUnijJMBI4Y0CNQruTICLLADuTKBBjYI7ExhQo+DOBAbUKLgzAa7L ALgzgQE1Cu5MYECNgjsTGFCj4M4EuJQD4M4EBtQouDOBATUK7kxgQI2COxPg6g+AOxMYUKPgzgQG 1Ci4M4EBNQruTIALRgDuTGBAjYI7ExhQo+DOBAbUKLgzAa4xAbgzgQE1Cu5MYECNgjsTGFCj4M4E uCwF4M4EBtQouDOBATUK7kxgQI2COxPgShaAOxMYUKPgzgQG1Ci4M4EBNQruTICLXwDuTGBAjYI7 ExhQo+DOBAbUKLgzAa6XAbgzgQE1Cu5MYECNgjsTGFCj4M4EuMQG4M4EBtQouDOBATUK7kxgQI2C OxPgqhyAOxMYUKPgzgQG1Ci4M4EBNQruTIALeQDuTGBAjYI7ExhQo+DOBAbUKLgzAa79AbgzgQE1 Cu5MYND/3E8GGxTUKLgzAdoFANyZwIAaBXcmMKBGwZ0JDKhRcGcCdBgAuDOBATUK7kxgQI2COxMY UKPgzgTmnzvf4I3699432KCgRsGdCQyoUXBnAtwbgDsTGFCj4M4EBtQouDOBATUK7kyA/wAAdyYw oEbBnQkMqFFwZwIDahTcmQBjAuDOBAbUKLgzgQE1Cu5MYECNgjsTYBoA3JnAgBoFdyYwoEbBnQkM qFFwZwLMHIA7ExhQo+DOBAbUKLgzgQE1Cu5MgMUC4M4EBtQouDOBATUK7kxgQI2COxNgfQG4M4EB NQruTGBAjYI7ExhQo+DOBNgSAO5MYECNgjsTGFCj4M4EBtQouDMBdhGAOxMYUKPgzgQW1Ci4M4EF NQruTICNB+DOBBbUKLgzgQU1Cu5MYEGNgjsT4LECwJ0JLKhRcGcCC2oU3JnAghoFdybAwwuAOxNY UKPgzgQW1Ci4M4EFNQruTIBHJAB3JrCgRsGdCSyoUXBnAgtqFNyZAA9iAO5MYEGNgjsTWFCj4M4E FtQouDMBHvcA3JnAghoFdyawoEbBnQksqFFwZwI8VQC4M4EFNQruTGBBjYI7E1hQo+DOBHh2AXBn AgtqFNyZwIIaBXcmsKBGwZ0J8IQE4M4EFtQouDOBBTUK7kxgQY2COxPgOQzAnQksqFFwZwILahTc mcCCGgV3JsDTHoA7E1hQo+DOBBbUKLgzgQU1Cu5MgDMFAHcmsHiNQsKdCSxeo5BwZwKL1ygk3JkA Jxck3JnA4jUKCXcmsOh/7i6GDYoG7y+GNwoN/pIBvFF4jULCnQksXqOQcGcCiwYjhTcKDUYKbxQa jBTeKAwYKbxRGDBSeKMwYKTwRmH+uRMaNigGjBTeKAwYKbxRGDBSeKMwYKTwRmHASOGNwoCRwhuF BSOFNwoLRgpvFHjHNtyZwIL3bMOdCXA6RsKdCew/923DG/XPndvwRoH3bsOdCXAGR8KdCSx4/zbc mcCCd3D/cSb+337h5M+fENbn+fdfwZPrvy//bv3z947xL/+Mz3P0Wy+of3dB/bsL+t9daKnQ/+6E +XcnzL87Yf7dCfvvTth/d8H9uwvu311wuKMBJP7dSeLfncCbqf99RR29/rsfeJPyv69H+/37KzL4 n0ccxY44Ch5xFD3iKHzot3YQRwkgjjJA/EkBcZQD4igJxFEWiKM0EEd5II4SQRxlgjhKBfxzb0d7 HiWDOMoGOMoGOMoGOMoGOMoGOMqGlgo4ygeAOnGUDXCUDXCUDXCUDXCUDYCC6ggc5QMcZQMcZQMc ZQMcZQMcZQMcZQPgoEoCOOgoONrzKBvgKBvkUTbIo2yQR9kgEVAlkUf5II+yQR5lg4QOLOjIOsoG eZQNEgVVEnmUD/IoG+RRNsijbJBH2SCPskEeZYPEQpVEHuWDPMoGeZQN8igbpAR0WB8d10fZoMSh SqKO8kEdZYM6ygZ1lA3qKBvUUTYo6ET58/thKOhkOcoGdZQN6igb1FE2qKNsUEfZoLBQJVFH+aCO skHhoNPvaM+jbFBH2aCPskGLQ5VEH+WDPsoGfZQN+igb9FE26KNs0EfZoJFQJdFH+aCPskFD5/5R NuijbNBH2aCPskFjoEqij/JBH2WDPsoGfZQN+igb9FE2aAloNoEqiTnKB3OUDeYoG8xRNpijbDBH 2WCOssEgoUpijvLBoKAp6mjPo2wwR9lgoJkMmsowUCUxR/lgjrLBHGWDOcoGg4NmvaP9jrLBSECV xB7lgz3KBnuUDfYoG+xRNtijbLBH2WABqJLYo3ywR9lgj7LBHmWDPcoGe5QN9igbLAaqJPYoHyw0 OUOz81E22KNssEfZYI+ywUpAlcQe5YM7ygZ3lA3uKBvcUTa4o2xwR9ngAKiSuKN8cEfZ4I6ywR1l gzvKBneUDe4oGxwaqiTuKB/cUTa4o2xwR9ngILGB1OaP3ECVxB3lgzvKRuIoG4mjbCSOspE4ykbi KBuJP4ojcZSPxFE2EkfZSBxlI3GUjcRRNhJH2Uj8URyJo3wkjrKROMpG4igbiaNsJI6ykTjKRuKP 4kgc5SMByedf/RSH3qCgN7ijN3/mafxbaHcA2h2SUXFIR8UhIRWHlFT8zwSHfwvtDsmpOBraHZJT cUhPxSFBFf8zMyDEIVEVh1RVHJJVcRy0OySr4pCuiv85pRB/SOEPKvxlhT+wAKUJ4QIC8edYRPwB hj/E8AcZ/jDDH2j4Qw0wbPjDDX/A4Q85/EGHP+zwBx4gegAHgBL9ww9/AAIiCASEEAiIIRDAH6FC QByBgEACAXEEAgIJBEQSCAglEMCfGR4B4QQC4gkEBBQIiCcQEFAgIKJAAH+mRgREFQgIKxAQVyAg sEBAXIGAwAIB/JlTEBBcICC6QEB4gYD4AgEBBgLiCwTyz8mIgBgDAUEGAqIMBIQZCIgzEBBoICDO AAeAEoVYAwHBBgKiDQSEGwiINxB/gQMBEQcCQg4ExBwICDoQEHUgIOxAQNwB/lI7lChEHggIPRAQ eyAg+EBA9IFA/ZE4BEQgCAhBEBCBICAEQUAMgoAgBIH6ow0ICEQQEIkgIBRBQCSCgFAEAbEIAvVn UkVAPIKAgAQBEQkCQhIERCQICEkQEJOADA4lCnEJAgITBEQmCAhNEBCZICA0AQf4w/VQohCfICBA QUCEgoAQBQERCjgAlChEKQgIUxAQpyAgUEFApIL4iyoIiFUQEKwgIFpBQLiCgHgFAQELAiIWcAAo UYhZEBC0ICBqQUDYgoC4BYH5I44IiF0QELwgIHZBQPCCgOgFAeELAvNHVRAQwiAghkFAEIOAGAYB QQwCohgE9q+wQCSDgFAGAbEMAoIZBMQyCAhmENi/wgIBDQIiGgSENAiIaRAQ1CAgpkFg/woLxDUI CGwQENkgILRBQGyDgOAGgf0rLBDeICC+QUCAg4AIBwEhDgJiHMRfyEFAlIOAMAcBcQ4CAh0ERDoI CHUQuL/CAuEOAqIdBIQ7CIh3EBDwICDiQeD+CgtEPQgIexAQ9SAg7EFA3IOAwAch8VdYIPhBQPSD gPAHAdEPAsIfBMQ/CIm/wgIxEAKCIAREQQgIgxAQBSEgDEJI/BUWCIUQEAshIBhCQDSEgHAIAdEQ QuKvsEBEBEBEBEBEBEBEBEBEBEA8BIj/ERYAIiIAIiIAIiIAIiIAIiIA4iFA/I+wABARARARARAR ARARARARARAPAeJ/hAWAiAiAiAiAiAiAiAiAiAiAeAhA/BEWACIiACIiACIiACIiACIiAOIhAPFH WACIiACIiACIiACIiACIiACIhwDEH2EBICICICICICICICICICICIB4CEH+EBYCICPjjqfwxVf64 Kn9slT++CtxY+eOs/LFWoET/mCt/3JU/9grwR1gAiIiAPw7LH4vlj8fyx2T547IAf4QF+OO0QEQE /HFa/lgtf7wWiIcA5B9hASAiAiAiAiAiAiAiAiAiAiAeApB/hAWAiAiAiAiAiAiAiAiAiAiAeAhA /hEWACIiACIiACIiACIiACIiAOIhAPlHWACIiACIiACIiACIiACIiACIhwDUH2EBICICICICICIC ICICICICIB4C/loyAEREAEREAEREAEREAEREAMRDAOqPsAAQEQEQEQEQEQEQEQEQEQEQDwGoP8IC QEQEQEQEQEQEQEQEQEQEQDwEoP8ICwAREQAREQAREQAREQAREQDxEID+IywAREQAREQAREQAREQA REQAxEMA+o+wABARARARARARARARARARARAPAZg/wgJARARARARARARARARARARAPARg/ggLABER ABERABERABERABERAPEQ8NfMASAiAiAiAiAiAiAiAiAiAiAeAjB/hAWAiAiAiAiAiAiAiAiAiAiA eAjA/hUWiIgAiIgAiIgAiIgAiIgAiIcA7F9hgYgIgIgIgIgIgIgIgIgIgHgIwP4VFoiIAIiIAIiI AIiIAIiIAIiHANxfYYGICICICICICICICICICIB4CMD9FRaIiACIiACIiACIiACIiACIhwDcX2GB iAiAiAiAiAiAiAiAiAiAeAj4awMBEBEBEBEBEBEBEBEBEBEBEA8BEn+FBSIiACIiACIiACIiACIi AOIhQOKvsEBEBEBEBEBEBEBEBEBEBEA8BEj8FRaIiACIiACIiACIiACIiACIh5Dif4QFCREREiIi JERESIiIkBARISEeQor/ERYkRERIiIiQEBEhISJCQkSEhHgIKf5HWJAQESEhIkJCRISEiAgJERES 4iGk+B9hQUJEhISICAkRERIiIiREREiIh5CIP8KChIgICREREiIiJERESIiIkBAPIY/u8cUPwGP4 n2tr4PPm/j7M7ZKFg6WbFfhYpn9+Dv+JsrWdm4ULj5iy3S03iwsWZo7mFjz/XqCDnnun+vB1QnvU gDhDY1qA52Ozc/K9Hsn+ORd7FlPLjnc9X8xmdZxgKOd7UabXMOhpJ8BbonPvnuYydhRb+/se0afo 7/VnBdTo8usKghibcISnMwx9h1/jxOKZvJSO0RXeMWBc5i7w9jpTd3XvmMdCGF/CcRr/3kJetYtd HP5p4936AhyC1JaZIfuP2gt3Sweyzgdf1iKdPn3+vFmo0pOIRxk0D0n9AI3giOPjsawM6d4fgwi+ qhqZxyMyEpSHw8XvUNa/9H9E5kZt49RV8jyJhWTj9lRaPFBMmCP/beubgpPaWyr2SOUMRp/4H583 3tHOFN7fZviqSyPH1Nh6NpVZkfhzMEeyzRXyWYuCr/w37XDjs0UZxwiNg4pfKsR2KpFm+mLQvxBF PQJXWw8noi0J3gYin9tfryHra36MzGn1Y2j/EnbDzo0tb/2xR9gJc5lTz7KyLuVEZOU2/u71saJ/ 5cHyMx5hxI2j70op3V4w447MTVkpKkpZOPbNNEBeKm1HEY04vckqdrthQs8nu1n5KdNI6XyjHenn SfbGRfdAwdawJwcN5p4Sr25yjLlTm2EP2Dwvst362XZYavTF0/sdR9Nt2a4r+xEFa1cxp80t/DiR Ywsxx3bSK5Xa37p0/db8mMmqonXO8/cDdEsm27OhQtTiT86mDtMz8auxX8oXWm0r7JoU5e7IHRph mbyTpaynyBfZ2/S+o0MVC14Tn/OhdDXgbGb+lEj98pXLiElcUmdOSpnyd0raMIc6TbZekSn1t2s/ MFjKaneXZT2f/cBg5x3hS2bjgpGSpl3UJr28z2slI3m8pxEGAp8VNkdCkXFKmVZvH2x2V2Pk15d+ vfKeVK17qG1wZagnfr56OuJFbGnsx4vPhiwf//J4PIdqTfgd20Pnem98W2fKpdCmrqesRbK2eyvu A6t6ZnIX8ZsGYa9hss8RU62eNOPJYvGR88eiZBZu+BMeyLzu+h8e5/jPufDPeywC9Z8vUDz/zzzO 8Z8HM/6fPawR/fdzWIi4/+H8lvjfOL+ndL46GJYzygSxENEYzDM2ZF+V6+MLqX1G4fQaJfpU7vU3 D0bz2CoP2z55hg/3MUpZz+k7dLoyZxlLvimsL3yJOb8nUWZGLHQqncmp/aQft+WD5HGnKCaqwyuH p25ovEnp4PKvTvrIJqSR9nAmT0XgnNlHSYpjyQwC0TraHbJfvbaeMJMxMAm067iImPE1Xi0S6xvo nn/itbwdbpkzmiyzPx+eM1rNpBKSFhr/KK8+/vh3yWPn+P0uy4p9unh3HW2z/7bpp//mOTaxN4EK kVZhdr7hz7PmyKyWE3XnZnuVT7hJhz+t7iksQyhzUaZStNxWEOe7GH5Rl69UmcVeWGFt65lS5HOh 58cDVle/BIiNqXGynyEeo0rcJ2B/pR96M3FG2YfwGNuXfj6Cn8QUKTc6lPh865x9lPQzmkJ7m8+o fnup0OjUx3AVQ1lioClpdjMjPU6jwyq6WXhL2eRtYpNGYFAJ39hYsItSxK+nph/inlYjra/IuaDq VoWflFMSien8WJc3D68WZhF69dYq6821YAfnUEtD5VaAKf7X2WBfVEX6+VN6mJJ31q1qJYykT0gt j+mEPF6/MzBzduKhasZpXuXeKbXCi6W2JWdfn3rxtbwKl2F38qFtmoou2Wf2FJL4oLFiID4oJqUw 6di1meO66pV0kpYpn65y6iG4Us1b5E8KLY5JxjtPtgg/ksAI3EAyveX9LDrheMN05en5iBe+X073 Wih+SGJsEQ4FzhU9UEKutFqXYJbiYz/1eF+Ya/lgmvHl7oGltC5zWM/jqXtmTI8NjHSvGdj/UOUT 7X/FYGeKOi35rKlbnADTbCHlhrC51kIZb3nCuEdVLEJkmzOcznaV4rYRV/OnNhKP4Z242GIml5ZX wMRtZOMcQCG0IJQd0ZozoksV4CwxHpERc3VRIJ5M1+27wNgEW5czUTNWSS/wtlIGh0yizsXTau4P teu1InkqtUMqMfdsqE5xIiZ9z556484Y9GoxOOeRt/PYS5If94Nnwj890M4RfDYzPM7I4Mo5Vszi ZRt3Vv0Zy6CprlKdkoQxlfCSSZ6OK9n3/ohcNqv8ccEmKpeMdNNEGldSDEN4k/rZ7cGRJMGDOda8 JSGb3CcON77qXB7Tb9CKO/+J/bjIeOXx/WCHEZUrNza5DrS8gqPbf/NNTnZ2it3/OBMv1jDfXStb X/554lx1bvbWzfxFaW9hzPTSyuHmwp6vIyv5tP1ZR8cXw3seSPuZ8nnrlquiOdZiV+pqAdTvZP27 bxY5TZP9Bj20bFk5lIp9Na/eZ01PP5bxMvaiQlv8tyvjv1UFHomdND4b1DjyYXr3o9X7aIOz/GE+ 9Qlqd00r01kRxxcvXb78Lf8M59h3kntNLKuEt19/Kk1+M4JR+EKa47++fRPHYth1Tl9bRnMnJ2GT qnqWuzWhb0NR228i3fCKoZfHVuTE1WAdlwxKF8o9+3ga1yCDapFYzJLvncEIvdErCU7VVc9eXq5h ehh3g9eTRyI+yB54ierAv1oDQrPjNrmngdsK7zkqMl8LWhoxuv4g7TY3QjxDFlQkIMW2zqyGbRoW Wwi/cjC6p2xpbVi8/fhd5i+DtZT56xELAiqG25dU9ZHh1oO3p0uyi0oorN+ZLXjm1X+9pTajmLgq P2iWkHynyE2OuSz7uT+K/EIOMZPM1F07s95f7z/8GhjYo04j7zv2o9soXtpz4ElJpZCvn43lCxG3 28gUY0d70Q6x88EzUwOfhj3JevkXBD+sfcZNyuRGVjzdGDF5UplcYXerabGY/XLXwRUF18JKydpP TTGsx7bdwi3uPHVYfIPEvHvOGqJHueNor1+2Lz/Mz2n4pdmaWuzz8FdZMTqH7/etN01xH2TL99lo anAl6vRfVLwCctzIXX/vkA0S09V/kJr/1G43UOPZJ/tx+YfpwLtUD6d57GEq3YgmA6bcs375VPvI 2x7uWMs7ur70DrieF62uv957aPUryL5YDX9nbrz77VZr5f2MJL839QRr250ybP6XVlR8NTsro1+U /+6eM3V0/SSy8DVHSkfWznh4tKpyuLF+k3tRpb1g1lPMPY91fT/gc6XS6Kkf+/ZPle7b9SrvFMQl +gVWpCwZTJhGR+6GohcKS6XL7r6vHBoesisr2Chz9Cx7I5uNHj4Irj4I1PGoS2O9Ux013LqT2ngs ZIsctenztnJgcOjMV6n9p7NJ521rj3u7rzlTBDxsoJ0q/zbi8/4mr/uTzxxtswmz3Kgr5xjIhL92 Bb6vUxV0zXpU4T9slhqccq79t1XcPe7S4E1p80M3Asmfwge5Isk5ZimsxY9nemg7kty7SG+W1+0+ 2Zk1z85sqSnHeSfPaO9x+z0QUhB9GD8zG0Zmvbwu9Hxi6tL5rf3OjJ0LydUGC8H9M0uMyW31T0OO +5M8Rl2yLYvKkcXJSF5aLeHN3OvRxoUbPuXMWIqcCk1ofPvCd8ortDlFlsP3ZcPv8L724qtrSkXc ZjevEwvMUKw7Y/aS7M/Uo9TLL869M5O9kVh1/aQQQe/KA2mWpSGV48kii7bh6uabtbidr0VbK9/n 3y5pHDb+pLty49pS+2y1dqM2lwtNqefbx6a5vr8otppxDLgQdoUTlFqe96xY7nUwyb3Su0RyKSp1 TIVI59nFMc45yjcCDbEBxg9F5Af1hO91MMpFkqT3ZvBuxZpcUxEv5NmKMpkWvh10P3VMOSie9tca kYcIh3J/+bNfCwRlefSvyIOt40nOydO7emqNUxD/8sHRUZpmOVAqD5DyllGaLsvRk1jcCeKmvOlO Yv+ABFHVGE/Bo0Ikd8WJWuEXxQtXF4bo+dAriRXHpYhu9FOp6Na9/8hjQR50j8WNWNU5t7BLOt+O ftMv+AZn/lcfzfbXCvwBHJRyCCsKB74T3xkjjBgMrqQLz1Hc8CQRLZTmLekkylEOQkp/iCYRkwoK 4a0bM7wSeppX7hlhnefNK6GcvK9i64zRtLw0akHk+R+Vn5IO4R7v/KC78eL+MIXt9zo2so5SPRO3 X7c6OM97XlSi47S7Rs/eXe+nymB2nd3f7Jb8sjRvFAk554fvpLweJAXPSDJSUDILXCR+IqUfS2Ja FISUMghLOeXC/Aiv/5K30GfwEV+/djLBYViCL4PUglz7WQE1xdCb0nSbOvw3/Szf9AR1NOzklsg0 Vz1ua26ku9LOfiFoISuRoZ4OQ4vk+nR80SdopNNcZzall78eauwmwmNJIEvDLqdIK87SxaL9PnDZ tez+NeLmDtJHN3N/Vn/jVKXtp/k5S6aJNQk13OvyRQeLBxQ3XrkzGjxSwvNN5E6e5pXLXEKfX4U6 yDclZoa68On2MebrMZirWL1SOYmQlo8koaCl8SAsP9fhfM897+6bZ0pJtLl36V/dNWPWWi9c4xRe IMhjcXAMB0zvBHFR8uY/S1R0og5apHThS1AvCl3vFT5dfBony5Rsfeyew2KgiaJKoYd8B2fGHFdL 6DylOBNPGaVCGslpQp8gNspstbOmC89bQn9SnI0gyWekzVfRbSRLciBUpG6l+/LaghFfB4za8lvx +tHJmMl20s/ZrIIxh/y1N30mlaPEyc/TmMg99WdYqaA0Edn99FmJGOdRTVZMbSFiTv+Anr0gHveQ Sc5pLLy63mRp+7Jr6+jjNPHK3+IsV6P9nJXpz2KeUwqz14sWv8t7NZ/3cyfd+7x/iv+jQ7Ssl5tP nUcT1Sr9rGi8gSJRrEFudOpUUiR/pXGNt+/B/nae7Hvv9X3jlXiBqJmDByibeNblK6YXInmMLqCX jp/Q5ThZpyNzN/mQUNjbY3msdWmlpW7ynBzHea6UPYB1+e6G+8HG3lLBrTWcfyx1/46F3/LY98lq T/+8ds8Sp0yLE1+Hc78OCT4Z+HDmSX+npNqvOIu4/oeUe7/f45523d1R36XjJqdPlUvm+bId/ogh hFs83cLQlG/yc/mVVWKzwle5HzfcBG9c7iYZmmR/smqo9lzGxivI5RjVU5PVb7NhF9QNacQZnoo9 e0D9NJCsdMAnM5qm9uVrlusMXMMkag2I0I/fx0rkogaxbTQZzTSWWTEOQa73eLiHzLWoZpBpH8sM 7rkc16ZoeWgomnAl/WLuWW4Zj2OqTxGUCQwneplvEV2WIpAjuE9+keAKwTUCPQKjE4akHeyBHPI7 mQHJXensCj7kTSwvGKKQ9Gqddopd132o1bToeIS+EMRcnBWRU3YU5pFI54q5FWROvYbheU1Hr+JI VN/JPjs+m3JirN0/qcv3xfriG2oqczRKbiDqy01BQwXvgnp2SWbZtOgvDjNXvp2bOr35w46fIid4 zK2OpP6YsPX7km0emuX+8dMt5M3bmtFqISW1Dc9DKjuIKgZOTtVzUPEoWPYqp3+/Gs+AsmM2qqZd 55nWzUSdRP8cuc93sVj0w6/LLM/Mi5TnN4aYhPuUWbhsPQuzOHrChePtiGNtjuUHP2r+5cL9tZ9w YSt3iLDkZIJ5R4qwpHBNgHYotW5QOS0Fa/lU5/4z5o5w5ZNULB4HVglNv0cd3JRvr5Iliu6oHR47 PzNPMuluzzJa4DEX8JPYJWXD+aUk4UJMti3ud6q2u/PVzgrPnvfJ/gk/t4HAB6fry6aNsToP7lxf iFX+spQZiwk5Q0e3HadNC9BfZGL+mTXIvfAtRTPcMN2n+Xx9n1l2TGtDdBOLYZyIaQLi6i+JQRr/ jCLDtp03V3T0qp5o9H4WSkj9SlqWKat9VTJH43ymsnsZjZmf/8NrdsXbjHcC0XshUZh5bDXS9qQk zome+hzi8bkrOs+kvNxUq370xxeI5rROlkhp6LDO/XTqcp/tJC9O0vsUtGBpPCDuF710yy+O48U8 9RAtnaUSp7/nJS7ORS9zCUb+EKGYIms93WpmFeXrJ/K2ilrDvuU2VIal3GXJDH0k4qHCyE6d+SWy cbU4NFJi42QRIkuJbXEbyRJKbZXOcilkLJIjzENhepb4iuATi052dZOSbwjZTu2ByyVntHAyt4dS lfpJNvrqsVEC9+9rVv9iL3/LUPK2+1xYhgVLfZsbSylNaiHnO0fzY7mxX6levfCgtrh745qCPOeJ 8x5vg2zmFx7lRt9g/vCS1pvDmHs1IDggMuBRQEZAoTiV6p6xmYsN50Aj3/3xL4qXws/xvHhK2HAN HfD4LGcDG3b0AkOm/SSWy9QvI+Tx6BPeH+unGkxby8SV0tyzAm/Yvq2peTO+X0cyrHvf7oXQ85LC oGIfeTq2u5hKtTb3c6vNW8PbQ9U+/oUjF+5sxdJLea/cfaRjsptfSsSf9lTH5Mrl86adxI0HnRNO URzEhSjb+PmXbamPUVYf0wdFRcoW69RVTpb2BG1+SzMcvb8Ui6D6Ih7k7C1wtUWrppFpsNt6VCFQ 4VxxntTaHbQpedlksAt5vwJWLVJ09kqupBjB25MUQm6/1TzVzwzXqilKnha6JlojG9ZmItPOkMbA KSeSBTTOvzj/XmXBRcBZNqxegVAd0Kz8iBlnavcfEdu86o7++eUzI8OjaMp1Na+D/R738ffXkV0y XwNPkxsEY5pKMc29alR9urUCrzI6hSrbRWcdPp4xqPTJZNZu22J8kqEOKEZcLDsZZzRr/eitH+2C Va9jsZv0FZ1uNc8nCs3bAZFCiXy5it9etyXd+rJUpPz7y8k3QcO9rrXsi7VPJxyl3BzHOM7EujvO 6JZWBsuGZM1ZTvUQsa+uT7t5J3uEzP0k2nviZndu8KtMoaz9ie7dZvLkJx5jxxup4pk45qOa0+oz ZKM1DB/dbDov6xvBa3OJsl7HRM9vR/RwYqq5fbVbltOk6K5g3dXH08YyEtJ1b7YM/WJqvSip/dJP YLObQqId03xs5PYlOG6oif9e2HE10LtGymO5PJbo/oaio0KD18w8ti+QPtscEBjr8y4yIyH70Wos P+XVu6R1K+Pcyjrvl5fX6rkON6bYY2X9VzdKTwm0jm0mnpl4X6GsbMv16jnB5qsfqisKOyHI8NN6 BPSRdFvz8SHRqakVqw0WTqnVBDX0udpU8XrXmV4kZ4RaFly8x5N87zlSM/sHcenzIjtCgXohNrG6 i2NcRbn2gjxCt1Sy7+/aOJ02FG/X1FQyOT1d0sVzt6cilpMtubGeTeBliwagG3WqczlK+Nva65LB R6Sv3TQSz1quqgqezjhrdeycYF6AzvXGAatPkkw/g6rN1G2AS/p2L292lrc8lJREMpVcN1KXHGp5 eMqyvj4123l+isfqeLEWndDD7OjCdeLapI30/s+vPA6wRZqdLY0aIkIPEpE1WVkv78v2cHCmrypn XreXON1IVPZS/V3b7Ba798kLkhLvIt9kLqDvjCfYSh4MpCSfyflo/k2A825TvW5C57Xr8cr0g3F3 3QTkeCgtWfmpQ2t3SXsp89jFb4waCYhfKLuUUPUi4r7B/rqrhpM+vXWb2c0Bpxv+v7/Oly8deBxY PupwsrBy+MBfxW97CSmynLytgWL4cXcrdDEmbIkB/ea08z9q3M/5Yd3ycEC8ZYhCEncwKMfe6u8U OPDJ6fXAQ7faLlCP93JLo0XrikURcb+JqSUe6VmxTKy8znazEs1NZGDZuZtJqfN+u4y5dPeVWr4u zw0Bg7awsBtsUomip8RaXlBdtci0Omt/ev7pmZuRxS/sk6VZytpunnt19r18mdLyN9Rls4K5GPI6 1WGPx2bJpImaHbq0XO/05O6teWAUnLOUhS7Y2ShyfO5u9Dr+afjWeNflzN6RW2d4zka8+WhywrB0 4qoZg74klxeqkVBidSzo2RBpw4T6HOH7BLYx9WYK44s0y9lDkWIVr11NOzV1a1IV6GXf8irdUy4v UsqMY2RL8WWJjCXWp3A79jTTq1KUTN+2WYf1ZY8kQPFmTySc3LFOwJ7soDFtW24Ce9dUUuamVU5Z mxFr8BfPF47TXav2kuSbOvL5ij1R105+n6r/LFrO/kmeQbnOlHU/64olO59ak/Npg4UioeJby3dt FOPMiZ80ksnpEbRU1MUVDjkqLscRKuJw75uigBccPdZy4h3JmAwiyowBS6Rprt9O3ZeML45xn9js VdNRwUpCEVWHAlcLB9IRgfYHmxKDm90HORLn35m/v3h7YWF6Uga/DL7knbmoFekJEA5Lc+zV7pbl EAjveMgyT7ofZ2av0v9py5z3O2wmxsX2/FLJoWVxgIc1cg67m9H/a0zdIFwMyWV8cuoYs/G3J8JF Qs8Uw8k8AnhFsnSLHTFNYe8Wghb57HbzNAMTFRyYZE+Fo/T5lJ+4hS5Y3omoPWdj/W5y7ifOkPPF /OWBM/H0nO6vvxW1Pdp6VoqfyV7q5TwJsSbPK4y4xUr72uWz1NukjDtjtBKhArac1Tv33JsPUGZ7 T+JeRJSI7kznL+24JWY/mzP3TZ7gvZqznzr7KTm/vSlej71x70DaO2p1psKD1v5Or+OPilWfB7Wt zP7k8m+ZKb1Y+C5HCmWRYB5wYDLPRujs9fOr2VxjG76kLxPd+TFy8VJbb18McsQzJNld0eWMbajg atBbVRq7D9Q6d53PX0giuMNjE+i0LIaIe6rEsvxTnrlH+NQmlanWzXuxPMJjHJclz5ppxSp/UPhA ZJtQyhuZFB6rbPnyPuLOLdKFJr47FfxxOam7/QkBcTashznbr75bs1N8fHi3idLr3i/GrBelNbYh BnKvqXJuKJwaqqj4wFBucvozBa9WU+Z0b1/T6Swsd1cW8q1RAS0vboIhS1DP0v/99vbtfVpWb/kS Ebpyg7kZb/kOUn15oz4L0yK/hwTZ937yzTzsM+8g6czqvNCVqXRP/+IXIqXRC5eCyayfPBdjjC92 TkRqPOZv/K0Q3lqpb8rhWXz+Ypuz1oTBQWhyJp9N28vKCNedWFxO21fdHE1kr1o40Ctkm8Zw+asL Wl0q8ObOtc4bPPeEwjZCXe7PqkjorAFp8YiOaGZebxsW6fuPlW7czHzedv2b+nGXPQOjMdN3No6l Qb3i6c0ND449Pk/iQ1uefmoj59uNjtZFpZpVUZqz8/bnTn+l2r+B3qYdvo58fWuh13yytPbaZsEo Hd2siYpG0XFh53NzYYyYFFpV2pFAJEPOUmeEgNvr1PjEkh2SWNtoIaOquitNVNbrkjJDYq/T1tmz vNXPaD1P2sw7busVFhO9ujPU/9RULPiJT5FH30P7c0E/mr0oa24+7CXkfOW64imTfPWhjGjt2V6a FONxx6AHovQXlI9lt6RNYz/ezHBN/T1dl+j1YPjcPa8b7OPUNtrEbz6sG6iPUmMoaeK+nQk4p+c4 r//Y1U4sXJbU9p56r27iF+v0Fg7Mb/asX1a2qW2Rzt2PMT/jpYlFU+akqTrI4zJ2s2qe8V0uV/YR Pky7hbyeJjM26E/E3VH4dftaqrBWiygL57XIlo+zVJak/hhKa270llfviYWTc6mI99jGZ+soJf+D 2NfF4V4JvepXHvjssR+GrJcOvEBUfu7mQZlpb81xbb/V25hR96wv1vIc0DwRVLTYRxs/pCgmwxkk K3qpeFFiqm2xH/eraOGqvq5U/u7VRiJM0ZUQhliN999QhiFJH51YEyjnR4oX2n+dinJ4o+fWZoVs MpYaHCESfazQJOKy3vkh4AZlKVmUy5h8qg2lepN7udZeOH/n/bS1/cfexD/k79a85aF83vHOXIX8 C3X7iUsXNRerGjp0tMLzLpVSeTbdNxKLJS/jKKKOtWWk/uYTvvRq/fZnN6R6cFZ7W9Cqq+xG/b1P ndliH24yNLLMuZ1s+aTVLnyXf0MpjcWbmKyUUwrb1mK3apq2Tiy7MWEkOys/FBRjqnxyV65ecO27 yKUNPTEqxdpHNP08qnuE1GR6fBTK5ERRnsdp+Voue/34/GgkhVudyC3struHVBjAWf66y7nKl8hY ypuJVZd39eLXJ22PzQaVpo4dp8oxVJVxzJPDOejPqpovuolT8/tn3dp++Rnb53eeoIofq1Pyufh3 23VRvX4Pi4e4YRllWZmWTJHPzzONW73vX3Rdufi24hUqwFRa7Bsv0WagNyJCbEmX+S2356/dznIz lh3KXnpeDjfsAXH7p+Rr/9OVsT9/6AyDwYj/55v/L/6ls/9LV8Nw/0dXw9CI/+OrYWjgf+NqWOm1 D1HPxJn3iA7GU17dGCgsK6I1yDtzPfvGzYUX0usTJJYZpgvMEc/3d2UGTZhe1tjfVyDwHvnyDIsh DetbpnnCV0lyY+K1OQmJgLgVzoJ780k6qd90Ikm/fwvFVuvpRU8Sr1idre2E2OQbyROTjBg+MT7G rbuBm6PcZct0qVxl3CaH5wadzjIUxmawDC3FGL6gyr99PVfu1IbAJKpO96SMNwHhTQGCcXdOwi3B lsSi66d1u2uDbNE0Hi5so1fG7X/thdsmBrd96GTLjHa494J9uda/JrhOMOw+kzrrJVHh4lC+EKE6 6St2X4gxgpEiPGVrcVeN2rsi3LUiWc20vjJMT42ka15a369dl/naFZbcPtFho5BlYCfgrqd0Rrh8 diXPMYHybJLHT3HAIO2uk0iXbHmA6Mg23XXZgXS76+78QwVW+amXGYLOWIwEZoWz3Cug+/Lx4wT7 rWQdtRMvHe5lbwdwji3/nJ525aX5/OB3eXN8fnzi8zHb1KcOboqeFHQc+a4bpD7uHdLJmm2S2WjN PCMsfeQE18XeholO9qIvX3aYp6wduJzMrnB+ZJW/9yV25QOlWm3S1qQzeaTMy5fGKz/yy2lEU2zl vw4cBvtnX5LKFtS74Htna2fKtyo3Y+4L0u30pUyHsfRhJdtjzwsuHTvGerNIWdEymUvjZ27mRab8 XG1tQX0M67kZCrNh+cPUjs0zIWK3VscoXyxvmv7uHVjd8mw7FzRVatB2nEX/6W7F4V4FKXY89A7u bPC6XEq7b0iC460z7zDxTEUO6XndzLvXxsh63N68VV6vIxH7gJ2g5x/93j/wcpMsGPMaUBkmeb4g s0s83BVq8z+ce/8cs/+eewDmP1+I///QVel/zrj/9Tz8H+46Qf/v3HXyS2c4ykyFUabXQDdsap19 zJVSFZdzuKtqJaJAREJJWXzOmXH6gUVwaLECX7jL2wGE4w8po3omMfGhbVOU4r7H5sl24RF+CpWW iKnunlpjd9/rhhY+xIfG+y+NG25x3nk2JvA9g95vttZnxP/91tjcR6W3ZTXcXwc297vpWRWjDyt+ 7BvT1HjO0wyniT1Yj0Fi0tZlT/ZiyKgXHHe4D359fztj7D/sv7L3ydhIZiltb3t6lXv9Sq3u3TW3 QAG/brFLh7Z728+N19L8yKQOix6dltnm3zgnh7w38oSExyg9wCqZsvDTo31TjowFAv6yY3dTTl4I q2F//oWq4nbhcutpjy9f2aR8hmkLTFHf2sQHb0uH8Etb39sg+On/MKDwVjyHBZnKczPeOBOvJwiy e/JngqjKOFtRPeFW0mHO5k2NGb2YMywu1j4XjHK8B/iUGYMztVhOjUfcoAvNVT+9ciIvQfgyLZDE ZH9a53Yx75jLszPdvOnkBV9fi68M47S8p96pFXeecM60M89EdHKqcPIzeixLSmTau+URBP1Uo3Gv 7+CafODyKqcTd1zluL1FfHP//CXhqpjH166WqJ2uap6657mUbyQ4nPHWJ8TklLpp77zHjfHPqmaf bEg+Uglc5mHwEMYspFztOT/QUJn+wzP36dXL0kY3jnPKO53qEEmI5GBrqQysfERRRVQ4JX3jq6PI a46ztvKaGjk3KNxSL5VkZToAs+79PwXaXjmHiFd+nzjk2Rv/fOJJxOkzFkPTOEBLrq6JZLwp+4QQ ipYjQZzmZKQiuvGCLMvge7nYS8+rQ52KrO3MLt97x1lp2cFlx/z0paBR0KkFzVNXvmdcSKNo+1Xx efZl2QOe49REH66d0lq7xZkrcJxBrW3Mizm48ySThylFcXhjNsWaa7cEw1nzxL5ULR/USsOF91+0 hG6fe/YqXz9pLtPhZdHZjzVNHHHd6S1WoReDz171uSShckqHiLjlbMYNIu3m5HxpeTGliHi7N2dX ZTS+Xr9zt/Li+9ypYqNwkhIS5R8SbN1xfdR9hUnV/Oduf7+nFOni/p6sisToXEPss4tRFS8739QJ EooVZZ47dp3jekTLdLr0x3cTzpSp7HNqPkqmv18IzMlUtYRpqTMI/xBMTa0LVF5oPnY6ieDxl3TX EkvNe2wJXekU9hkJE53pLCrndq0CIp5MZleRn7iPfSn9Zk38tcTtn1HN81HErWykzDqXFNlnTC+h yVhkz/ICypmP2ZeeJRN0Gmt0iCi6BntM9PAHNIoPFQk2lqOKuMm7Hi/SZzILvG5srt2gjm51SkC5 B+rZ7VoyiIS4OzGYvOAemg6OZl2qOdyViVzevr5Ee1dma6H9zp7f3rODaR3/O3Sv6Xev8FLQ71vu T9REy/5yXF/6sdu7/7p1snddWT9k4Kb1vM2b1/gFk6HAsYJ3DkLdVQ4vgg09hYKXQ1Q+WP4eUTFp Hy39vsNmQCEy4ifu7bkSVhNzm+vJA40Vq4d+Ud1LHO7funItH1Rd+p4v4yVKj2pReP5F+57V4K+h +/0vFkW3foTKvbQn5DnPNW91TIJTqUc5JmRbTfY3xQri+0Mjzw1KCveXaX5Rvh9/XL37fCB9/obp q0YFVtOh3rhHNsM2v1uCWiJaklqy79w8VOdqmWDXomVxG9ZmueSlauMwx3T7S+fHJpuXrBcBrGqH ZVxiX2dkwidb08bkcwVCrnQXWHKr2N4WBlPqNjD3XuYXihDORGj0Kks8sMZotPG9v3HhA9bqYcH1 R1IkiZ1F+d121zZQcSFNvxtLx3gIc+vC616W79C9zDdz41RKDz8rtYL+qD+C81A6zXIyujrM8GGU os6pbvF7hOEMG3zHfvVfkY0U+K6a6hZ3mtHxh9xzWm2ncvwCjOT98GKg6+ADzRnqVwphxAQA/8ge udy4m9zwL2WCW1sVPzvmO2TF6Gej3rmSX/tym5QpbkkkIkkjsIRw0iTr5rCpyQAy6vgY0eNRUtwJ zYRvJ0JGiDq8qNKPp3+P8V5eUJDrC6MbEYoYka0ZtbOki7At4OPDSh/Uno4L1zdF3zbVDyUc5N86 +JG0UOF9VU6SmO84udZNWveIU8lRz+cdOqgGHShZvhu4hzS2YkkWRzpcuQQbagSiGxRx+N6aT1Ix pUu88C0/rOsjFGe0bv+1d0d3u5B/pOVqQdXlhyuG5e9Izr558+QlsmHz56VY3S+RuSi5TCdnJlSc REi29q615vYXiw9OVPkSP+p2jx8o7LxPU3Txcy4dGnlzO+S652NPbLRUhGOB08cH2rM9hP6Prsl8 2Sz9un/+2A331u/rr4InCFw2bVXreTlnrm41kF9TWpTf/7w+WOP5ZuBJeZ9DyMDwImPzpx6bO4/b 6di/Le6gNbwuDxjGsbD3hpYO9mA2Vy8ZlCYbxkYVzqCvH6P/qXtWmj3g6oi+kPT39A/8Jea7Em9W q6WbZ0Z0HX1Hq8p37H72RJYtvpapnX7aPRN79nz9dYGwW/cGGqOIWQ07iFHNBrNbyaHo2Hn+NGKl +02kce0/sYJZsY1ZJSuUeuR34yPjrO+d8I4gVZx3E85qrhp7Kl3fkTxzNbjhjlam3HpU2XWlxwdK au38VtpKUyxRd7ZeXPyqk9wyJlFlK7p+HRBd724v0v/e3RJien7NBbhjO0WN2XuTHcBA0krL//V+ WZm6/cK5yrPji6dfYEbut6xH+Dh86orxyXws9cSrR2jv4ftpukXNJ5cbr5HxCoYfO9mfJzHnzpkf Jflym8p5/KvIef47N2xYEBUAbZOO59WVnsnQu8e/cJY1z+IM7cg4H9REigiw8Z/PcE4Qo+hS5uFs ufatveLhYvHpUXWJ8EW76lHyVI4ZgV+VaJ1djDrHKSlmv7i2pZFXhTgxk+M3xoZ68xesC0f4pz8n 0Gm/8+flszPlqfA2G3c2KmyImJWiElYX9Xh+8so52o1khJGJQeXeDB1Xp8iT9YyusV8EpRdkv7s5 XhfnyNU9f/YEBa8MOrrWrO68TBfi4ppv7ntzPgHpFtYtkq9z34N0CwdvWVcSXit3pNI8tGQ+Xs9Z LtvIoPFZzk9Di/EXQTTmTPIjbXsZBp828uAn51kOjz/4GhW1eIOElNRPSBLVEiuQRvxASiM8/8Kz 6oeJAt5zZDy5IdqmYbzcNcxPJOujdCzDGkwfqOhJJ3EauJJEmrZV+u2AR/DJGgnSXo63/ftU/ryj I+2IZ41rXu7Ouvb0q/hjlJj8vXfEMUzBMmsauZN1/mLV9vuySn9F79/8Xxuuqw8Ruviovi+wsJQM b/eVu3WN9ZyC1tbsyPX6cWZa7k41WQZaz/Txr5/8Kmt8z7+76R6iMrxu+20ZPXmbU5e7115ncKgd eev6ppVHf7qDTtYgl1umreR5ya7XCVYs5zrGgJ74F+fH/j2SRTurpedI/c0C13zn11yKym4MVNmE XdAjGr/8IFBK/QlGiOllw5DH2mdS8wxlggeDnSYvTxQbR+vO6wr65JbVcwmuF1NE4Y5V0lF56wqk ikzfUH1yW0ovuVoj5um5rMBwoWd6D2Z/5Jm4dTjVsCjYPAhOebPu8zj0lktZOd9ZAPvqdhgXh1yd RaJ9Ju6hQ2ixkeOPCvKlN9fuf2qmeWD/3fUL/6Z6Y7bfjoQHcGfidMGLLLK4dPQ2abdJH5PCrMvw dSpDK9t333rfa7/uWpJ5ajNpGGrYnjtzQ5j2EzasMv6hTsrHtFn9RRMFO0wfNX8x+15VRjF7MtvV 3AhK3TfXfnh6Kkw7MzsA7s1lia+uXyuO0qNUcxNpfZi2jpu2vJ+1l/94SbNYo6nYctg8QeJumJb/ KZq23GhBVcu78050K0XPM6h8CN3RowzZZPHnhHOaOaN7bt0l3mjKTC2p5JF0Db3h8uGYeo6Tz9kL 2R/jFAS7KPsPNxfIqsSDHMayfdMNcJa6B6NTOq1R+pWMNZFGa68yrsQkqTFsGsRtyr8h4Zs0jydQ btQj1ZtCkMVFBMqfqTO/pftUtruttjOt47t1p1V2qvDKxeLpCuK8eK4I93DhuJxXuiHXFbUEZM4I 2giIFtm9zyEyp057N6TBYS/UxnQtpPQKVrMgW7rxYWFj/EVuniEJzW/HtTsXh0P0U98GXTVaOlTu SNf4Gim4snm7dPw5529Dk0DA/n4bc5KbVdOXq5K43oyUtVzjid8637Id0nkHTXKTQn+aLKZxh50d lqUkTn6wXWP9Q9XfkzapIC95tHtIhpyGn0ht1qxo9srngPzoX7ICguVbQL68ruLdqPgWy088Rblx GzVFOCGVmTH/6uBzkkwrrqQlmFpHinpSOo7mzvaIerN9FU5ClosDJSZCfMIsCrrfZEmLRV1UxjQC Pe5fXy533dtMyxteOH5jUteoXaxs9euzvB9+7w/KrEdEtW5tkx0qRQUnNBoVVVaVOnIZaxvW3A0/ nHil9/Y+Z1LFjDTrqFsvu8xmaKeJy1makdWam/2pduMiKVSczWQi1dUprz98fOf9lpR6FGPyafCO 4qEftd6xG+i34QvFgX4zDlG+X0V8IjXGj6kPStrxdGKiPVtoGdm79gTXbzXgkmQtgrFxReMl5VJY 9UNH4zxiY/X9IIrm0dsvjCtv3U3HMBwuur5Tb/hEXXIra8x4nNU9ijXf0Zu6QIVDPGCavrFTyq79 rsvQ9VezlfPnLOXvWhBnF38Z4HhZ9W1k9vrH82pNxsJ+wafaSGUa5Y/phb7/NKkVIeyR3RH/as3z Paf87Day61KB1ZjCZ/kFp5JJwbxkga4w0l+Pz5x5pJA3r/Bydvb896zsyyuEd72umbwnuKGwaH2G /RjwaPGOxUTRQ+zXvl93v5hGMQmUBJAF9irpYfnefoiM+tFg6WCOIhqM5Py6IdwAKIiWZY+d7S86 dp0xZJMgrU2jr1eKmsK9D3dtJO+3ht049RnCVzU8XECI3l5PXnb4tMdgRCSrjdfIfHPyV/NPHaYv V30AS6QS3Y1X3mXJeUw3CC79EJh7n3PwyoebYyc8lna7ktvwBOt6+8Hu2JV8jcAKrqdhH6j83pm2 2V7caI2wumvN8bQW01jYWBWC894cKVA8ZycrVc9g8FMncMmNRcfRnOWRHe8Se3ZcLklsY5Ck7rLI tDtboj/PMe1rr/jJgFgc8w1P5WdDd5gfneOosD5zNpwlbHkOiYh7erU0KUzXrPkuqjiLMpH0e9WE kNa7wWfS8kOuPPUEtzSU3l4iLVCLzuE1v6XGF/zr2AumInmcgNJ1fmXtGSpji9jvlwqB7pfi35xf /8q1z++rbBFratFjsFL7HkvR2dBCZcn49Kasc4LSXQXtCKCCp0EFp/dFNXj1wTcSBTaDPA1zKzXL 7/svLyCTovWtyCf7OjaUh0+OuL0w+kQW7XNe8nSvw0WVGNN7RFOXLMcxzjaAVJbP1hfZ+5t0zu/D FDUurRKxYk8ic1BBwkwymQoAAUOS+YPQuHyGSS2vL4r3T0Q71PNrOO+RfLVaNFcQH7twXIjV07x2 QHeQ+2x7jGna8fkZxlRsX/fkAzZRCRdDx692S93PD4SMsKPd80ka3kOisa2WUuY+d2nGnHdu1TT8 5Koq568meBs3287FItkR6esnLEPUa51d94n4/b3521H27YarYl58v68bFG1N8Xy4f9dNrhV9b66M 9/wjXUT+CGEFZ9C9hyEChE1vsLVPo31rHgVY3kezJtw4kU/Loq/OcJs+lJHAMY1P+DRxed2hDP8u WqF1eIeomJuXhzliys4XEPKl47BosX0cNb5VwWE8Qsw+om3nETd67oTMHRruqM/WT2j6YtmZq6PY ZbzoDq+eWWpjq+ezl6Ws50iVB2cal3rKcNZVIte1r99vzZLhGLW8hK+Rb7G+sWgYCD+ZT28GTjSv EEyvxFOJ1KUGh/cPR/p+1piRvy9T3696Nte3kOhHmPKbu/d6MfNks/oz5aQhDECh6DXt+Xh76/MO y+wtVafKwpv+kQrVasvkp1Opx0wbnI/vXXx0iaXJTeLUT6fY6iEOg67y5wzZUdw+/siV0Gv7iqPd ccJ0VXxORdJrnUnLTWOORNFrwiHPjMyVevMa0xvXq5aa0PviEW5O166ayw+sKudR27jaX36JGM6W zLqqTlZqzl15lbPo9fVIDTqE/1Ssb5p71dld99Hfdz4IPf88bn4qZuvOMO+z+fpvBmntFhzv+672 zMuY9TRtXVNBbr1EZzwbCRC/8ehM1svKlO7L9Oyecrf84+eEbrGFjb3IIDDTto5o/9BF8IgO95PP NfPNgGdpVJN9yXKF9Vrh3KfDw4P15yeSPtRQZhFzuMm0E1DfYzHOXeFaVn1ywvvCQ+JyH1/VW2m+ USJCzC0hLeMhp7hcBjFV4qI/0/ZDWtJuXBlXF7r06tpNhoVsJze1+idPIysiv6z2NeaOzI6m3iNu bzgtLfBo5/rYbujMhepb7ZSWzN61p+6wvcQJRKLPvcx/GaPsy4UyTCdbQR9+Dy2W7VE7Hv4i64Lw HveAh4ti/dTCqzfmHYyyJymVf2S4V6X3iSSLzqLQA2Z1wBaK39E1qNJ6xyZssmE1kUej77xMQsGH pgsBd/iT3xdfOkn5q4Pf+ufa2Kxu5MXb9uxzgJVFf1FAytyNr5oKbX05mHyMT9XN8t74tf3yWN+7 bYs385ulyD+rDGAuc4lFFqy4jTdpGp+MX3+60JmTdPkD6bgMOkql2PvDdM7FJT2uzi2SvsVP4pdj aKrOnJ47vs9Vyl1XW3tl42Ou49WNq9opqmQlx0bJZ9aEEreYTz+tXyykL45/caWq8vWyrZ+pMCKC aEdt/3aZfEt0qb0CUefjM4kOmB9a3YkkX3z4CamT4gJOZvJpRlg5RT1+RFlx4nf3HRcTfamq5ybU 97SdEMWWAQhjjJTUmSRSrKRLS3mws0s/dVNJccDZulsi968TvHrIakXJSvhm01rrkFkpgDuXQjXn GwHrlsL/i71/gO5sWdvF0Q47tp2Obdu2bdu2zY5t2046Tjp20rFt49/da6299zrf/nDOuXeMe8f4 j5G3fsW33sJ85px5alZp99Y3Fxhbcq1WskicDm5aafYJsGmgXmy5ARGoHvbj4xUzFGcCl5OokixI wqrSV6SjK0qMtRu3rzKqMlXU2HR6uMdumnOz5+yB9gF/nryAR0XRuFj4jvVJnxVgWeGT4WI67mSM r+PMXRYQTsdEOdVCnlS9GsAgG5gKrGpI3573DbDegD/UGuDHC6ydpv49jYtqHQGcri/uAgMWIGn7 zrIPNesjezu55JBtRtIOKmyoXpSYF8BnA+8Lwm6AhSeDR1tObuqEsGtmz0uyOXtQtENtbnnKpE2f a46u0EC9ct9NYetJSKDn95eBu22X7pABH9C+L5zdT3vbK+3Uzaqfhh4IgEkfaHSoqlrzxyByXdSQ ghLFg6punvrq+ZNXOAEhvEKNFD5DeJ2OYbc0UyJ731+vRBG0FAHZRiTrQHjfrqB2m6Jurg+MqSxO 5jDePT4VD8R4v6+9uV5dVy+WFuqDL1DqsgtnvZ1FHHBiokzWYH894h6MQ+5yzz1JqACVl6l7gFxe vsd23G8tbj0cVYCU5Xx73WPqe87CiWZsEXoL0ENnjxQAU23MmwR1BI84jQ+gmMZ/CxXH160XpWjU XRwo6Sl0JglqjAI2o/t4TDjpkvEkFPI6PVL4gkMgxQZjilaLHGuWmQDRqbjnJceRZsTd1MGqsa9g cvmGVo/bFdcqrY6lsJv5Fopy2zFFJGMd+wX3IQglh2GOmg1BiM8ExKV0vP0bNtIiP6TjJUoe6i5O MNIusdfTncvH4/aiz+O5DdKTSRVkzSN6UeJadFWIN7ySnhIWkKe3TsXz0baKz4gLMYkVbG0wAWvX 5RHVsuz5ShIDeHUUKvwO5+ZWbDX55YCoO52lYEYeJLtWtQv4hDD6CmsXi1rA4TdnYDmUAvMAqDC4 hPLOGQEZ7Kg0Q5M2PhHJbAECKVnFd93ph2Uy+vhda137oNGpXArKrYlaiYb+eX0KrYKjZkpMQIQA xzK6IwBt1F1sJZFMlTykNcEmS/AtZ38NqwQi6lCwZ69CXvCQitROAn1TplQ15Y3AWkD4QTlrXkO6 NBDKUBHFWqPeaMLpdJI+UTeTdNcb3jChaTrIxkAr0cTZPXRpZ7lGSZASdA58dJQ3XcMeArHhniGI xJhcqOJwAkhBSjkszSzBbdEytyQ0Apv++uN6hMCe8M4ewrnDu0j1Bi0SfeU3l5f5Osx5eMHqvSAi QgtuvXNY1tsd7jYW9DA4IspQ0dh4EH26TQANtMHaz7Vhl54rnuE8vWNqqqx3p+cWmPShUXH+A5IP jkqLpcdlx7OndbcMTsvCAqOtYIJ4Re8H4jvM8hrKpsww0rLFXvhl3EnBdhglBsXzUwk11v3ly+N4 54F1Ei3wRod1iNsJxh5kae6MQ0MsVE6mHXNWJGeNZm3Bq+WtNjm1GNYjm4mFE1JnS+Wu8YRkuNPQ o/RIBd42pn1v64/CFUsLdeRr93eO3VXFTKu9+Rv1I7EWQSg9S4x0dTMjr2/6ypM688UhEej1QZ2h KhlOT6OXg4UU31KSmLJzWmdnvy1exAtJZnNZPDXpp0+H5Vm094TT7EcMvFp5MXrRcZTpfJdRRWdV +vmi8KNsoOtMzc6OthycRsMBlAbSJEHawD1KDMy+Fr+2r+T1abfZ3efe/PndtPe+ZlciYIJM3saA NKA+ZbFn4xg2JALobu6LD5apCJfjhbvLrExrJDSzU/ojrmsOCaCVsj2IFYAugEQ4dGbBZP80k/RZ 6mBoJ3uvEj2ECysJp4l1mfziwFyKIJ4g2Q6cBYp4Y+CeyhzC1ExdkusJQeWF/rFYM9UJhw2Rgkp4 Wl0XepwulKt6ZFoG3nOVdKjMnFxMcN9MRkDuW/69djRf0Qv5ZoNHCAIF8zRv9EiiSsDtnP7NXFvE vLD+7qhSdd9ylTYilLaOyKvs0UxnTxY5LlXg3bHVEdTutpLRmVMdVlq8iMHQjkfcgv96WuTcYWUp Ju7VV+xr4BDlRtbeWWJ8m2wpCjT3Qif+b56025J6sdjcGBD15VKL8D1J676MZLPqSWR+Yr7ylHAU luxbwuDNlCetu51mMw4LN4Ql5vFEyTfSctv7wdfm7N/kc1q/wJva1ONuJ4HmIu3hfXoqMogbN37W ymqBEDXewRzbG5f2ZCcqgQA2OlQGyYvXk5kOTd0SQRElpzrLwRxt2BNzoHIP8tMEHh9WMMb7IMYc obtS2JEfTQbmGggqrmIZCYQQ1URgkc7t1YFggfDLieRMJwV3x4dTIrKy53ITR4OInEjJ+VKjrE0A 3vGIYCjyjXnG/osxDE5g6/KTNqbk4mJV7Yp2BvX0xWUTtBk//wqvhirWpVuWOJGLKRYy/7SLIq+y l4Jk2uv4AE7c/b46xYO1us75972vwLZfv5CvHrjpAYiTb7mVE8mtmGJSDhkC1UcElNGTTqEaX3fQ fpOZNgSdJIMad1w3IXgkjAQiwBbkQRH+mQIYOIuuaNukx14jMRfLhir3rSisyTAR1qQ44iWmuNgm FAHOYr0+VfyT2bX4tGfNoiOCBTT2VaF/szM+3RTaD6lOgUcekyZDWnzJGUXqo4yw5sM4GPh7LgXb KbzbO+Xme4yI1vaDgNjJ9MDl+zALdILIa7JYbUik22+3hjqslEH2vGcr3HIcNBXXrs/X3y1zx23d R9u8eZujJEClIvUvXZ3jTU2L6i6/DDPeK1s/7L4d8XHhTfjfsw+xUKNbZZICtYscc9a8oOOsGqGs kUNmda1WEwl7MoqKaGkU8QuvkW0X4xYNhafUutcpdcBswidUoBMsLHE0uEVy1w8ACG+YbbvRZLjR qWgQbihENLC5+ZIVFpx0cuvygiOPubZtbbVzM5NlScP4tJXEmFzgxYfYFGOIHlSTpREnLrvT8uwn FJFIpI/BdpgxOXfVoquht50MAWPjJ7UfkIDSvnfHCfoiA/k4ikdjImoB0+Te9SAiL2lxvbK7aV1w uzZ4XLzrXB4GVuucDPYuBpDwzKN04XJVoZJcmNC6q/KUU1m+dax3PhzqeRV+cL/xPFdPp0ZT35jm 5d+piqBysKtbHZWUCe4pKIVttpUJ58mOXBNBlVlhUVE8h4QrNXpcmLAub5z8eF52YG31kvSjdnS9 31vE7e55syxpyddjJp/Fs4SFSBJ1o7ldZxWvkFbB3wKE50L1QJhDVRSkK5bJU+Ve3A1LKH7u1yMG LNSsunfOWa1F/9FqAar8lIcqKGiJqLwYfBqCIjrHlOH+7QIlvEe3b3qLo5OSWQKV+0Lo3aH2DgVt 4fLEuLa1Rqx2j6AQgFjA7XY1nslIX3RFU5ntq737XuKYWYpIc2E5TBdVrwg7+8bCdJ3oXZh+lSDc 69LMAP28DaErd2VzWuWrwqjyo5wDMqlfkYmMP/GeeWJx4K45Ujhxa1pxYnlBpgNTpX1VEdmB+Upq PINAzi2SbUoG+D0eppsQTkwZItOLmYgFQkhxKc30ZkMJhU16HdgNkn4sExu7M5xgbSk+imCA/tZx jeSb5I8iDrAFBbulhQH3RyWkkJMS1m3ixtqg0hqgKBt+Kwcmf/aUHpklEpKDWPGxLzLnzDVQ5RZk WcYMsmf7OWXHiPcRRkz+/GmaihZo+hxsGgZeeuBVXZiycwnt95+poR+Yap6jSGGwZh4RJm2DoE3E iln6EF8dm7fW4jcxcVZUCh7QrtHgD/ErJ4A3mJuM+x93XEDKxYAJmoE0djakCDG1VlZT+jgSu2xH KpVdFRF5ne4KixxDZKFG39JpfZmkV8F1/SSwEx4kj1+MrTZAoICAtyJMpq2j9eq2z3m6MBSv4ssf j2H00RIriPwxt24kimv1vmrLomTFyfHaOed+hybDfb2cxBbajh2CPxkaCuEWjNUSI7nBwVXeU/Gr AB9/PiOeco7dzoq5QmR9eoKhty6Y2qm8c21cL6UekiDdjkFESnkNyN5h8o6+1FI9yzig++DGP+d8 Cs0uYSpd2NkjuhBL14y+vNHH5FHJtsPQhLnNkU+2EdTxYtS52IHwWuPGpeodirAL4vaumBLh9x58 HEmme2JinzR4zyTiK8ewqiRB7rChHnx0ZxtqiUNuSul4QeUV3Q/8zxY9/ONTfFY6Jra/pTDg/Xer Hhj+eUjd/2Thw/9oecO//eie6T/56J7pf+ej+1OV79GYQ/A4/p8BAUu8AmyjxXynZnlmubzg4dXE 8z4BZIjywgTDTghHG7rCqo3YwozGe/t3IHiNWpwSTLHgoNErzSv94CIkcmABbBDugLRte64ua+96 bhOfh3in+VCO0WJwary/3HFSaG4qpcle1InE5cYsJ5Z0smq3Nj95Xs63U9jhqXo6ZJGy+t4QcE4z +F0xdZD3puNdiYEp6mbqvej9qXpyMrvbXanb/en5qfz5LmKs+gSVJlvH29vtfXvv6UBnPpvzXejt dOxqx8SAcTPdveJ4Y2cy+a7l/ZZB9nYxjen9qHmJ5p583perCPwOBCyKpDeASid3yX+KHxUcdJwl CkVukd1xSsjfXxubskTagLx6JlOCY/vOUVgw4sSTxEN4Osz+LOr00BYT1VAfb7q2hPG0GBtyqTxz i+7SP9JUotwTCVB9m1FDP88/WAVdfgoUp3FJJ7SNZdm5QLvJHFoqimXWfUV04kLW9EkWxqP+EFl9 jl37SAMj6oTd/2uEy8qAQwMnPDXq0O41By6NQL+sJHSRi40fzFk6qWOgJoXCEagnHMD9aWJFfq10 PQTKQCkAX0G7tHCtzufWzBKGBrVTMNEg00/SlNs/0HxBIpK2RojNAamzEdL2oJHyxmZtDfL75dv0 8zlxxywQlhVykcBexDWBsj7Lidg0uL4JjyE3o+EJi8SqyRhkUdUW0EQUpYiHjq2moCBfCgawZM5j ylcDR62IWLjS566Zfk9waiAJg1YjTEBGT2mSTxLUGUTWVtEsn2PUMdqGhnu/lvjCGoA2LTIslfsm at1juoAudLogqO0BEVgU2E5PwzZrrO1PpIDLPzy3i+cpdarnbW8LbXU6PbOzndGvAFO1OIQDE6Mf fXwWTwrJFLRkUFC8oxXYEo6zWE8Nj5aVg0drAlUep+oYHPqF/itQV9gLeBSbxTJE6vQIKDDuIgb6 Aa/DJ/msXs69DFLkLw68UMbVQ2fV13EMhhoXN/GupXCKHZWaaiTJ5Gv7gNg8EVQaFJYHmGx2hJwb BTdlpMU39oGun3LWRNfmy0XHxBgthbS3H6yx103PwwgP8aW3i/oCtMcKhchvr+DhyZHiSmknUWpc v09JBR5+9RVipdPAbwgtdywaICVWl7xBZCjiQmRz3yPk9V8T1m3tqOK3fIY8HJHSDIOZScXQxJsJ uz30pwqU3pZ9HHWyKpJYrF1FmGe7WLofDoQxbTFK3dom2Ag/9PTx22S3WQaV6xM8+GSaa6NkMSDd 611uiKtGJJf0OLtsaHlc+9JWgaBVV39UMJS8lVWCvEyNlBxjfxQpWjNh5q72QJbEqggZ8t6JoxHJ gDXff8DcfXrQU/QJZ0fqx8cmN2x25IXX7cEKx+NrVRMENyzPU8vgRQLPXDVNtzdMpchdMe+01Jsa V9fDrlxnQve8TOVOZWtDlYMFcaWRtVRBI5qtgYJSnZjSVb/RTxFSUnLAqSiDZ2xCfoO201OKuuAC 9XmvHf8o7hk/vLoO2PMFJy7cQ1UzlAeCDyTmXwYmxCcWQEx7BUub2HkZsmhLHMaUGck3KaPvMmKs Ey0MmKq0q2LBgM/uT6K3Wm+2IhNAjqJCBhhJS5J3bpodhFKagAP6kkkTzt/k+cwl9/hq9gOSVh9x mdfOFWDxue2DDYrmTAa8+nSijF+1ovTrGvcXwpwNBtJ9wFSo/DheiaLefgM4TlAlM6wgR4Bzgxcj K/3epjbolr1d8JnCGGq03F5ITfDc60QEYaIfBJGj9RJo0JI7UGMpIPQQQnhQoExUesnMYTUSEF9O 46/BOgxXcGZM5xilWpkLq+Xk3LcJ7qV26qTwLsXrWDrfrijVTi3VPyfrYShoKy58Tk6xOvrMJ9hp Dn6TmDJUA50yKTwlsIV4/F78qdMa/HYLaRwWfsqEA/iT7JYLpOUEHDUYku+wWlgghw1KG6xW2K99 Ycs5ovCbhoEga0EMTGC0bpiC568n0g17fU2RfDudgE/2GRMoUx0RYs6rysGvNxEiATDL6q0aV9fF OGB6I4Fvuno5AZrHF0KNCraMbr8H/mDu+byHy4Nk4DJMCXirfViO8WETsTmNkhsuTBmMcKIL0VLN rtHBNcGTAo3eiZ3PwnE4BeEBRAH6acaJqfvdW6U3nUtHj3DSOYKjoJOQ6aPLGpchFp2WA5jUUPdD XbcjnmWCNmi5K1OZJxKEC9b1revcBzQV78cTwrKnUqZVT2KZ+gbyjxUJnOgC7Aig7FFNI6gktr3i mgF7nPUM/XEvyX5Unm86w1HJJu13zo5c6NY4UCqwwYsPn0++w63dyYhPmiTWS1ddPVimrtb6SDu8 B3TXlJWd78DEMugAPeD39mYVEJlz3tV8ZvHKn42aStkD9nly5GgwYUCvMg6YN61pxehha0q3/Gif dBVyYLbRtazxpvWdrTRW5ZnKKjFCZkoqliD62tTIFC3OkZ6VsuB6q/fERll6KhbCpTz1Ose+Mmqk Sw3t4NbMujOIAsjwXqnw5KaVZC+AvpsWk2MvO7csnbvIgRjRRimPbMBx6QGWe7qcDieETZGi3xUO En03PIbhvQPsq5Kx2Spbp+0H9zmzuJWKJsg94sCezVgjHS88r9AxDTWdl38oIuriKGpTWllIjpyK eyBL1CX+uAaJHCJ5FDRcYIBi5+T9gFbxVmzZ3Bmhi3M6OQhS5PStbx4djMDayjAWQdtPOlgBdDVu gco3zcmwczlp9ROye6kJbslufgSCWS9kA5hZL/glLVnNS03+ioTuZ5sial9UpEnpHgkuK1QSJNJx Ayl8QdGiKALSBHT4xBFB0DgaOnMMIguueQF14h3lolpOc6YIIdIUYjVDjDCauiY4jpX5G3Y286xN TpmpzvSxsk39enTHo2XRK3FuIZ6GrPMDa/3JMKUNaHk2ycVPgWiCEb3nqyBFjiSJiC79OfTd9Qtw llAmLTymc1Hxb1IgQhOed2/WdvKlV71R8CpmzCCaIFcOQCaZ/X0Mw9WxfsQct8vdHkE9Mb1YANfQ WE5ApAIrklOZASBjbEvMAHoNA8WQvq/7IvoI++hN0CRz0VtIkMFoG590aAG2X9pBmE1iuwL0kJ8v KtjF2V2+hRvkvjFzSEfshS9Z449elYaYFskbN2msc2HSj+iRHpBsTgF6uK8BNssw6/bV5UlCfXNq 7oQ0f6gtbj1+ya5hAerkXXEcSlzZmg3mC5P5AcexcBHtC6sfdB+/nP9ZX2xrGW6T0EDyxweSs9rE aboCFKYeQFPGJs3uxFj9D4z4HyPW/5yXvL7WLCkPE2QvmZWXLvzoV8v0zQYfyN+XO/xqe597P9Vd zkPdOKwgNlbkDa7rcfQs9+rdXWk0vzsXa0wfMbdv3e2unhnyFpdvH1VJ82B/X9PcOtINOUHPsuj8 9tZsw6FFPtNQqfFDrrRkOa7y6rD32kE1bzkh2n1H/uijgInH0m/1kQY1bCysAUWe0Lr0cKDbBSUM OKwEQCOAlUfEAVJ6PhMgWycnp9hvtCVaHD5xy8wPoTDiixIxd+xmDfHs+oB8hdMtxBNzEhPVnKwd yaSTDKTo6omfPRVKlNnXuDwGq/Jvc0M/b1Z5dBOiwgDod5bS9odFR0g2J7kJxeQUIAF9bfF9+Ixk N9ejj7+Q/LPXjEUCtt8kOXvLQRG8R4utifN9rEbK4022ZEAYOj26rIh68yeDhbg7Yw1rIOHDwixu tBExVHDPXtQpSCqOH05QEbqQtDMWKb1oSAEl0A2qd3Fk9gIB0AK0vYkhlQhSZbArDR6AVvI2jFZm L2DSgyRQN8sw8BQM+maK5/oYSuR0Ucv1fYwvW0YY4DRsEWaEHbsNrSFV3xizWOJWyYkDP+J1ztit CVUawsCJMS4Rl3KtVOu1lN5KxCV7tJfDoMGSsNBhXmM/rcrWWfCO6I+8MbCvbKTIpHxHg7PcMOFK 2w0liFJBUvbv77rjfHA61laX3fVq88eKoy3JRpC2N5zxz8iY4xSdT561RwV4rrj1GY0OPcY+hcc3 rh68WCC0bsVKq5ZxBkgGG3FC8mdWMpL5XOof2bUuN18bNEl3/xn2ngwViOwCFy4xBrvfA5+rKHcJ D812cf6R6w7JA44aYUgP74NHM/EBDdPzYn1jTxOPsIAtaDc7766tT7aziFZrcvCjbxUiG274kZ8a YKaDPW0nG0ckXJtm+kWWYYX7S7KJ6jLv88QgR6gKKXyPSLmdF1+zS0KH1JzP6OeDQvIkyd1g6Cuu aVR2QE8Hv4cDOtNCs9cSNE3eGj0IfW75+RZ+XlrbziF/dNCuVlEsFAtkc8wpfKBEemc0YDDaRIcq ah96zbMeKwEHmBqL001myFdc8dvvnmt8qZ1oDxHlL3suD4v1P8xBs1YNdngncTtDloTWtj5upJ73 r2xKX9e9IB3qz+xBB97f7NdGUx0hN1RJOUxjAkfdzcFqUTjN75o+aM/ORdvPXJ2aU86qTB66+Tud N+D2z5ZXpjHWGvsRz8Wqf8Tfps1SqTz6xK1QhSQOrKxDCasrOBO2oHClfOy+4X5OOZkcbVjSeWPs Ug7RSd/bWnTP1enhezX50DUJe58VSy36lDIi60h1i9ol0rzHc8hlMdW7wJET0yxm2Zo5YsLnmQC9 5Nk6flDfsAYsAu7/LQW3N8I3AtOSDd9NtSZDjLIhXpEQ7hsJ3VQVn40jHnAqw5Kh2sbl3cLmSWje pFA6QWNb/Sec5GPLWsSNzNO5kcykTSHB4J7PKHi1oNUrJFmcRUZ6fuPMoFns2YHjWa2Vy48p3cdk KIL4cGANRr37ELmHCfzGw3MAfryfUdzllZDoA8j7h1wRS+MEkyGtigJw6c88WUtl2VTOyScorMnl JGmT2tgg/Eoe+smDBlRt2+aQ6GjyZIxlIEleRC3nfYknGVE0xDI8zw+7mm7Z50OGtw6vqrUX6Ry+ wU0GTCI9UxYAX9TdUqP0SdbKwqHUI6K4JXRSFn3eQ89PVqlvxY7EPL4+uDSqNZm3DXsJJFwEYaCv PC/LkAjSuWAokjpNR2Orddy+JOh4pz3B3fnIr/Ah0ml/uPIZfF5sSHjXjIsO+yBKHt4X7yck/HLP VxpKwIM0jpTm3xx/aLYA1judEeZIqSW2PTJlHIix4q8j4JLu4HAYLiIUEJt833w2nTlAJDjQeySP SGFItBOq2Cgb58QYF+4FRznNzE1gwPQVw+1LeOpGf0UE+JIRZ0EwQvT22Hfe6kx1jUPKMCs7Lgd9 BIE2T3+jcMc2hcm7OLn8nMtEpiN4UX2RT5X0WHbmpgzCSsWQEaUnilhfCskI6JQXTaEBzGvh/NqL lAoe4wTrsiw0AXGCou9Tdz8tMkKMz+BLwYyJHAvpygVA2fp1rX1z/1xoIZKTRoDKwJ/OgfmpGJUR UVHOYxxKvzYMDTJgmyyUPzWiizQNiZMkxfcgMlx49zTmkq24fz1DTq6GjbMoG6py8lWDn0eWcvdc +kBdas2U1rhWcvzqE7Kheom8GheqFuP0R0lpHn6EC7I2r0AM/esAuKKQyg2BKfvPUSHxALaSiNFl PYAWvNY5L3/CWQ9edmXa0BNgtS4TusfTpMdpyEdHIOIBjOEpF04526ysQGk3d/r41uJn4hiUnQ2C htnr+ugNnFJfVrzX5s9uWvtZ8DKICdb1rC9ud9oii9M5WbYujienbuUTUqhm6AZFSUdTNgAGxLqY cTrGh7dugz65BE7MjV3nmpKs+8QibMFEcacW4sPOxSBnpoC9tYnqtgpBqx5TFc3zOUnts70C300t Gv4Esy2Ft9YFPiDN3f2XF+7j8wHXz+hN/id4iz27EQ4OZyJt7fPtVF2SXog151ix/imu7Cwtba8j U1CRg3cHPWFaZ/vF943hOmPfqu/4u8taPXOyHye9lI6Cy+KDlIhmaclm08VB7Ujbmi9KXK7RZG3U oC4/C6tTB9v1Z2LYaSZ0jUTXMqHUPl6ULzJJslI6sqlfei6OPAUgrXbe2K/wglhtMC8Nleg6uvlQ EJw7p0RCuff02D5Hq+Nv2NpFfbHxg+eZ7pE2YmNc7v0hvYgV3a91VZTAkr4qLWIolU8enACBLfc8 Rdv6o0iYS985X2QwWIo+/VZAx29pbyVFeHw0JyfIjIErMvUYoFJM5VgP0CARpCmVXM9KMXGPWmH0 /kIprzlgHV0knKDoABcvhZcxlUZw8jDCVvzC+NipFgs3NlWJuQAevHIN1XsbMqqLMc8ttfpqj66y YKM3/pvBNvEh2Qa3Z4xzptciDvXBSKKomDPsOAn5UahgJDJOnJx7uL3/yAbJbICVohFue0lvSy61 D8wGiYdydyxaQ1kSfwN6tzYkk0kkZ0J1e2Q1YgiJtoxmtrb/LRP3o5OlCDvNj7jzzqTqsxftuNOz lJgKjKPWynCVQLUsS+0aziikwN2AfpobJQSmSn4CvQVyrwJ4KeEST4hjKGfx09z0eMbIRwcC+V1t XE6jKEdzLDPEOw0kkp4Mfti23rI+7XkGhXUZglEqXWId9e/ZtBYF/QQE25EJ6DhS/Z7IjchySkbb qEoEb0K4giuoNEIQUd6G0VH6hHtgqWwcYW98rFJO7HkPt7GnKDrxPlh0CZ8I+MXOc75wIv6YKx5B O34II0oofUkwFG/dxahMUXTDCQtvLVJiEqxlzDNvGUTGCavLB5J8j20vGgEIQejO7kKZc8Lu9TEc 2AVrhNdkrSX4Ujcyhd6Tdak+wKhEM9WQroi8LGqM7zEeiME5JCzvlthpj25S4C8n7KkdVKbWblzW SM8vX595OC+9JtyazXfbxhntOCvLJruTUvb5oMHYvJe5bVhqmLy1cI4FwZAVT86HdyFEmFMOq8fC ht39RA7XzdmUg+euqP7n6NQVrzvfzoU4aD9TeJ4keXjel5kz9XG8/3CH2UbQ5nYdL39i9/igRkta ED7UkCSkAXZGoaWOelX7Og1VHm5eW678wKNrJ195eVP/yYAADXYj5pOD8veWNUVZaiph0kbmQ/rH tnUd1njOyO8GthnI/RFXMPyujUJQmL51gfGun3PKzF/Qc3I3nZLEAaTsFHY2YCOVx82Gt+bBOgEL mAroc1Q5E4ey751dfVYPw2La2ttW8OMqmxhEZ7hAD45hfthOu/CEzSefQKhXDeCYQnTVvAmQRBa7 biVsUMM/ADvrRLv09FO0WBsiHeyvxNixoORcHKc/T/r4SX18ysJH8nnV8jKQoqGC9K3B5hBgT0m+ g07ms/Oz6GSGZ0VXPyewLQsir5wk1qjuB03InH/cH7G2bV7ulNVCbX5/no+6gk7R9SU4VtGB0G6Y QO22Mi8RO1axsc5K1TC4urm4m/S+WXvt8L6rxoyxm9vMwijCnKz3cb/KMKk19TB+lFXffO2R0O6K RQR8Dpb59A5t/w7JxsWhYZKlkYbp6e0AGlmc3d3WC/GEbed5KKX1nkPhfmBucuUnGOE01xk7LMzW BivlHwXoqHwbm0OH7U503q9WZWelMSoNcdv9tl1kYYdjFSKNg8E5KX4Xfg64cQ3tH0XurOVbbx/Q EGLWL3YC5NLC3fNckoPNn5t1UuMUqU4KpoZXX8HflTjZpOuVUUQNmhmc7Vl1Vkoif2pLlZtjlqqw 9CTPjQpYe6KxtikdmBckBjG4v9CYyfo2tqjzcRDB83p34pNwkp26MJTS5xTQTwTsGaNzUYfdXeHz MYlERyfVyxfaxyGNBm8ljo4OHsUeeoZbYtWruz0xJLE6w7faJ5WCS2w/pPz9vmHbpIV/oSQbn8+q K4cG9quZWeSMt3BQSbt0A16helS+8OQiNi9cYCmyZBugZz9yYv6rh0a56CSEzheCAjSqmjLV4kr9 9HK/LzuXyvakUSmW3+Acu5mzgQFFLGOZ6av8RLOwMBYLIu6whIQPR0ILYPOaO3NUoGerimbjGoTs bXIilTDDTKXGbdHlMFt7ieHwZE/BxT+vWSVgkKdZlpJn6kTo88QWOzbhhge4MmslwJENRvuvhyJ4 ibDZhN8Vyama1doDt+VHrBncrn006lB12lEqtYgk1SCNLH74HjHF554sz6erttHEgcwEUfRuH1MT jwSqLqHvSDoGIaVsZUNTvAf7+C+76XFmmCjdLeHDgF0CiqSeH5c5TLjgOB1TYMBDZIhrQY8Sm387 zZT6ysAZCzdWxx2emJK3KAo/wlAr3+uQ11FtDiRHRAgZGv9JoZfOUH1ZKCh3bEmCgTXcblP60Pne 31POplSpTI5VVpzYLhZCETucWK1MGzmfEW2gDyofo0ePXBgCYyDkxL7xJwaxVzUVjp4UtmqsAsOw cULVqMSskmdfiHj1EWM5sCxU/Thz1Nc+q1XNJ7Us3XNxRJAdewhIll53Q1QDkI1zvq/LbESNcBlz kzCHAt0ZRpMDimd2DhYE93eibHed9/aoy2CQP6BrFHQW7SdBHUirHawDnoJtaPLkQvUYA0m/bUfx qiP/AYtOcdmXsGcRayljMnlQbK8L74IJ7lFtkoRdYWK2K3k28PrqeK8vDcY7UOrq6TjkbTttgpyn d39/NmKzMa7TNPkxBShmYWKjncdyyo1jKrJLMiKCZ/EFthYRZLMSgZbVmIp+omt34TMEJWhqcgJ0 HfiTW5cqNaqJZUU3IhUiEmWDZlIRWGM1CiqCueDY0UB8SQ5/EePClMxu6Odu6aSULEmmrcCDKGDw OHfcUMGhqpWaDjwb1TW6Ipe2zzUbadppBRNF7gL19hjbyqXBQN+N1XDcfxSHMba7f2OAAgl+WQn2 k4Faxd+P1MQ6iiKnibgT7NNNn6vX4QyUReUmhWQ/vxOIECL7LJSHXlwMMTGCLps4Op04moErNjJF r61VRlxnB4CY70tQgRYRqZTzgC5N6bBZAhvpvKkQEdKY39ZjD/4IByl+KMVIApQhBtWiLCGgJ74n cTpMoIUrVSgGmjWbK1E/rRgSjNe23RVT5ayDdVxfg9k66QLC4LrlCiC1rJry2WckCI4TU4bp267A DuPkDJ+t+pXmgk698joEU31lQYZ46cqrUH6IjiUIAebMypdRbNKvfSK+Y3W5p1pJo9OlQub3aTvf BDB/wHh8vxqpoDMYG6dvV1goGUsl2OelC6pEedQieooYFBSs+1FRHw4+o0DzOJJZQmfHIS9qBmxl 2OAGHQgCM9cVcfboh4o/Ue5UpLlv27Nw8bWvPO3seWFluBIirWh0yoWEqpoSoS+lX1EqzY0UyYoX wNqnNC3vQvq5jHqm6aAunmG9ya5glggi5zsjp8xo5DEVZOFkP7z6ukuj8YZJA/do1vANY2mZU+Gp Lm6EegfnU9wK3OUa3MATRLLKcMNYs7iWFmn6kfoqNP/y42gEG0H83BCsQ71hKB4cpgG5SSfOyoR6 PYEC6aYvN5ZeuQr9AknxgRNusAdwqv4tWBcF0sRLH/w5on92EBzwuLAUx0erBQDmYRwmvQt9qjdI /u3JycAAbD1kLh5SCF0A+HECbCZtys1yxMb35FSC8+ukpScMBWPl4VMpSj9Q8uTluBuEQxuUAwJx ZNJhXID+RHJEsh56Yq9chs66BT24pFdxrM8sXXDkRuwcxt4jwoWLoC2RcAu4xgaRxHGt8BLMAthA eQ0NzPq9KbLLoWxkxObytBASjzTRVMvSbYiQyc+RNG3aMww+N+eObvbMYw/B3ipw8onmntWoB5pp 42LkbWdnOWzXWnCOF+tdOCC+4vafl+EcrD3ILCRlr8KPnqg5WNJ+0BbwHXl5cHeb+ryVV3+9eMfx wBHdJg6JXZ5icDPVydB7gZnCXb0C0ug9mITJej1lscLdurpZcLl8fE2nUQeaNOk2TUa92L+8N3rR suA9ezjrTTDRadJ4a3/+WH2zofBqp7QZem5KPV5119G2Tg/r+MEYRW6GAb/MGBVakV6kNmI4e5pg OIvF+QRR9zh2n/N27jE8IyHpIgl/o8lzGemCjU0fttwEFZjUEg0mz3OZk68hXC1ilddaMmSbk7uo RiHwhYKZKN6J8dDO4QTvnjEfMr86Ec6JgviRdewTfzDx18oaIzDNTcZ2RgxCI9k7GLqGUiFE9W2t GUxTtJ2hH1r6LyGnCKLjOEWIH7Tti7dJ9c00YdUO7TPjyeZTEMvH9Kqq5KUdP1TsCnHGVo/PNZRS 9ypV25uFhR7rhHmmR9qE528084kETFp3QYm0NR0DqsWjxcvn0GxNs6S4i6PLKCNDFB1pJZWWjdQo 23sjjyUtgyG+l9S4Eh9BjdKqTx+0lfVoHVhgsUqCFJ7wnwmgx4cIJVXYBdpb1klFac4sl523zknl 8MPWqUyJ9A86WQNi6e2IKB0wy2bCwpLdcFVsfaPa9+RafjeKqh5aGqjx4Ttgr0j4ONRza/viXoZy Y1Yz8y2tj8r6rVG/N6reX6bc4vQ+XQQWHLLJFyKxK7H9QIT3KSTAHwkg8YjqU0Az1SczGJv0s7Md EAUiidFnnrgKsk9swQiDwPB0PZQAaIf1U34bPjXeOKgFL8zdZlcb3S2rJBplepSqwLXrq+9uUXDR ABA48iEnn1lyP6ijX8SXPOFGSOYsGfjOpySr0+f3NpqgscbKKU6DYobdWwxeDNhcY60o+SJZnF87 z3QWWwzIcB8Brm9E6eYaTd/fxAu0yLQ8QYRZKDqEenQ/ejlufHz77sUnAXzXkOHibykPLukVeMg1 tYefAqpqsvE5dD7QfPxogThaun5sSD5Yc6+2e7Y1WxMvChp8iCLdPyL4FGO+DkBXXLxmLp3tXrR4 X2A0s18fUehPschc7SCrLb+C+eCenmaW+MS7vICZMQzoXFoDrVs9UBcnpB/tHh/tmne3uvEAwL4L ssQjv+EkFCtcH9oqrD9xVHe4wToknBQjthBrxsUkbxKotepHPGgKjvB1uPXtQXMyXp7EPUnECeXu biSB3Bc7su2lZx9lxhq0oaZpt7KNq6MR7y0LscFbANHMT03rf/2ai3qfRTliLAASDLjzPkV2LWsb gdkpp2pEBpX9sbuJO0fyRfs/W/vwj81WWOlYWf+W8t9vtvL/jbUP/3aLFeb/ZIsV5v+dLVZOVb5b Y7IhFE19BgAI7JrAR7tK+UQR5PPjOw7UDO+CNDMkZawUY3vIAE6dHyKe6Cb6N77oa8zdr6/E525A 2C94ohpKhvXLdVRjWbhLfIYt7RE8AzEDz9zx8RKPHO5DIq0p+5rIl6SJm6nwr4e+3dhcqVGOYUpF iQrfnixtCFnf9bJFZEBY3M1zH89EJQu/1wxgluzVT772lqO+wD6dvg2vlObVcXGHqXOlyFYybi7O 8xvhQ5YFBq+oHmG93epnd7Oyc3J7Ojz6PZ9OCoceMeCKvbt4dhzgLIyZeBYwgABh+EXzXMeRQT7a 7n/mdgeRKg5iSnvQYcU3A2YGgaIfuxxrI+U1M3N7XVt/Tjunof6cA+dFVDLRsjRWo43msTygbWq2 s/RxsqcglotA3TRd5uSUMO4fEDY+8h3nokNmKh9CIjeQOmPjANeHm5N9XyQkOxqW+sanSmqayo4F 2J3JLdLNPlVARe/TnhsJvwl9D6XhviZ2N7e7i+14IRyPJkawgxVpuW4l4UV3W+FsUeD4ChcLtbXP GT51eRiDICrb3L3Dbl+DrMYMv1VB0DP7LP9ZLAq5dIQOLy6VH3INFByKEfKissB0egyrZhGkofsr v4lMVsw51zNL8kzPiw0nxebd7oBOa+DDjc/lTr7M58vGoQ+gFpAPGtwfHl1Di50bRyw36a3pbnWd V54/XT1lroSoF2MMDQrmyO9EmP37/rVLd2QGtRaD2xMStPkTU0znnuHGM+WnZTIZIxlKHmM7RZPT nV66Ozxxla3f44quIiag8WqSTuiHFAQsDM/nNvubTfSpwmUUy1fUOe16WkfQAU8sz08Uw5wWMCF+ xMbmiMWvpvI3Qyup9ZiANhqWLOXXHfY9s6c3AgUI96KT+X4ZMQfIBziIMlNOMmLJviFCg3IxDieS xee1x4erSejh7zOe8tHC82tbEwJ8O/6OufBmW8jBob7koAZnXxCWFrz/FghhpSVc+Ga4Jjo/7D8h ZknNLBY7uG+ewKu0kfEwLkV9//2ErP9ny0GOZpeeFdSyBq3yF+4GCnCb8wWXe58LLhA4azDRN9H3 wCwMJTjzKuALTZqFF9D0ON4x5CQJQDlwgEFdiGlZGYVgPEiie/U+GdbE0dvCimH1sGJ8Lkkfv5sX D4wWd2rTTQxj+lbCiefXngWN9jUKebgHKwCmBfxenBQwNyJC2vZA/wD02k6JHEUu5q5jl/Vr7pWs EQQSW4jItt/cSOS44shLtahxA9HXOHOSr6WkPwZTlFNCwMkH0XBvnLx4erHE6YAoFj/VURWuafWH OanAl/uiKXx7NlwDt7PD7u9R1reNmsIIdIZYgEDO1SunUy2h8u2+qhkyjY470QHfxnosFZcCVAjG /GYdukcdOiSxr5KOYNAC49yozUjaCS1Oanbbx+Rf93weEPV4P7TLf/wUxIpCjfhpIV4aMHJeIKO3 JxvJNIEAMwZ7fm/ZgwVeY4bRZSkB68NasqaVB2+uZaqhA5LXY+WT8L2W/+aMbybzNbbgaZJApCny wpt8KMcVmNq3y1dxwDlWGKIcQQpNV3as73LJ5ENfVpg23UymU01l3qyWOgBrVf1ADVVOdDCFocRF /RasoywoV4mTmxE1BCHl3qkbLre3HwRdKY8oYdriv6hvgyA1HCLOILNP83TFtzZD5cW9V0kcXvZU UK1jd+haVLp9IANMSABWnEpLAiBdtk8iPNAZl36wFn7D4URxvPFTY9xhBwH3LyvAof5sWx7oRlS+ hdBmkOVph6rdxK3REjOqVWxbR3JOYFUt9u3rh2hSOlGu3SE3T3nnAc2EQx1O/CZApOFAV3F/vwaG Nn7YhlPgsgyJJK2km0UP/hLcdYTCNjF8k1UgLoE6BGUeUexdmzSq5QA5L4clqIQywIrhV8aplPmA O1uAH2bPd8K81hh6H3KZT9o3CwzRQX6F0z6Bhr5gQDiB4vCDPfKB6Z/WSSSdEIjRirC+UBYpG4Nc dNPmqQWHV0MWZM+50o/YErCyb9rkJpBtGSNyVZ/bJeiZ/tDhXl2AOA+WMc7XRDqfGH6ypBGHpENO Da5j2QyZ5L75PMmN9X5xFxLieZ/VYWDBAtEUbUHSFiiYLjvDR7H+lOGrUAlxDbEhftj35P1+dfAt 38Db8fHocbMOfqKRDKrQxQfs1vwa7WGXPqSqb0rIYTYssclRumgULeb68W66PcDAO7W7xT1+q9SM f2jmhk7WbWEghzLThawf9ppGc+ukDn+icTkbf9rhJKwKGidAIrKjiX2NiV4rp2SwOvRJHiPPW/mU /83pwuX5+6vxuXGWpQ3nxk83RWmyP8Dasqi2sS9d+EFje7n6heqQdBY6ol1mN2wg08zl3CmKI7uN i7PqtOwtuj9jr5lo327WpKF8l1kkbZAG4Xpt811r/zWfoQ6hQCAZfeoVKOnQrFUOYSVn+G61pAk6 C9OJbHg4srqptZqZlHSFXQB1HVcM8mtok4DGlwizLfEOKrEIetuAItIvB/xymU5ORQVRo3x0tqp0 2JI0ZmecGeAeSd8QJ+/6+KEwlqpdZSiRf0xkUMS95NeloMjvMGN2U8NJaJ27muQzmqo+fMs4PCUF mdiTGC4iNsdIe1CgaXBqTb6fdSYoJYBkJ6ltXSqQwEgvlypT8nJYZ2BRW2WpLia6sdpHvo4dXMgu +2y2xmyupUMJu+OcSMqhqoOTAaGb5IF9GclcV4hGtzKcFEtVfMV8KNiTmEXe54zFkpdyr3bOCl/f QWGmtn73JasZx2/vh22/PdAdFRX2NBC/yJ3vB2ezFxBR3oT4AIZ+4tHtQAknfwEELAGvsrNARyQ5 xwhYfQykViD/EFzPJifwcszZAp4vVMTuvm2uKpudfHh0vj+qo2zyVD9/mAJxamn8g04cvZlEH+G8 dJ+iXHA0HSKdEyJSKh33/smzt79Zsv6MchUAoan4UVeow5X1thK2th+lfWob4vY2e6jfuuATRi7T uTrHpycAcLMlcyiUcPhNG85TujQDpJBqYDsYVQY9sehRW/Rl6No1kCvXkVdzBX2oxd6qhQjQxja+ 70RyOi3CssobXjV+Vj6SxAVZWqH6W9efeKmONntUuQRfgXxqcrjiLDkLFTXsH863CjMXnhNydx9d DOy/v5nlDQoVFWp9WpkFpa27QABOBj1tOLn4otuMqS9YWnOezL8WJjCMFhyihZA9eEUCgKy+1Tcr Zh6dpsgGOh0NMMkROSHMcWwjcHAXMvDMgNeu/rFCuy3L/1zvXK5psOxc25F5+MW8Z/QdZ+4ScOc3 mF3CrPwCM9DfYIbSBsjZFd/5C8xqnvAFww5sXcIXUGKwtZsaFzo+wvEOiPiUnUm6PsE8/jAJe0Gr n/PJmLGDxYFso+zlTLPL9IfjU5KHTQZqCe0bj5+3Bf9Bp9DFOJdQOYlynm/PQptxHvYiupo+b7vH E79nLGaK1TY5aX7xFHGTURFC6PGJQK32gozpSj+kWVrfDVvvfhYcEUphHcW+g5l3mEY6PF1wqQne O9KUrCY0iXfhhF2rBrn801kNOqUaiGmC0gyvgTLswjcQx+KjRUyAVrPANxGnfY/vGpOsKKBJwh/w 8QBfoFzhyIXQgCTgrQFds2nnxVJ0U+xDLxOWRSF7nZRtuVcDkKjX4gi89XxxuQqRZaeOz0wBW6kS /S5Y4KS5X8ZxX2/1P/CzO4fKMnZ4XPONEOe45ijCrlnBqagxYdXB4lrxcTra+tw0unkwW2eSJx9F TdB/MBBx4qtIprp9+0Gi1di0/1GYLOUwSwsX/BEerQeK6jXWRS+JBsNbBJRhL2dJNB9pYIIV1Nct cvIVOQQlXlomU/lkvmuyi6KUTkt9UMcWvcUUzab0UNQYGG8b9xMvpXR0v3lsn8REbF/MPOrMSpSF lkDwOxJWEtWO9MChzty4eNn+Zdc6zSLkA0XkNMSHRb+odKEw6EALqYmFohLU4rF395ARForqZ19k Crqcu6Ea74ABWtADSz1B6hBzJjH4xBHCPe/UQkZrCxmrFIntq4ZoLyR6I7dmQ0IyYM6O7T3NrTSJ 4DeW0q44E6d9tSLYHo3CrcflENWHTRY7FYTpaPCUHAdQxZMnblFwyiSCBlHhznz/4o5sZR6iMvwY bs7YSYrxSqn9h+o1446CojVGAO8PeAYkfwj5yHwAhIFIcNCqVlG8Cat3zCA5hd5C+NJNqjBikiaL YZdHNlb99M4L3xjoWqH0jV3TB2rhzsw50UKdnjAVDOjOywS0gQP1eTDY0Xh5woRHAr7lcD/48IIv A/VP0fe2pp0WxA+8txR00yP6LvxK187SURvWPzbbbAHGElWslHThSnbdBouGg8aWJlLxfEdKM8Pl klq1LnWh1uFM8KrTiYSdsojK1K45bUtfqP1Z5/1OV7wNNLYfQrxTYJmrxyOCxxQTVBrp0FBOaxz8 elIFLLUeBHbascG5/AiIZMAPv+MZfJc88swqCs9GQg36ju3WyZnr4FbmWdThLXE9MFDy2E3G8F6+ EOk1Ab2peOMpNJgcehY97TVkMgx51xdQOfOUAXda2mJ651obWf+p0+fWKv3SAby6hO3dFDEhfkDF Imhkwhp/q1cq6YjDZRVuYyJilJOAkrvsqt0GVSN+xVl3o3IjM5h1CKWIZePZ59MDw5Pyf/JOyvyP TQgZGFn+tgsh83+/C+H/5jvp/7IRIcOvXT7/Ohn0f/K+yvxvtiJk/jdG/qr8Z0DBSd/xd1jR3sno V8rPOGk9q18ZaH96+fUcjH6bScNnb6Zn+fvF1t7BUcBUz/5nXb/efPX+DNEzMf0MqpgZOpo64Gng sTDR/jq+9rcwMDHh/Trj+JewsrLhMTOz/DrCHo+BgeEP+Rn36wjj33l/hn/9/j4O9x+l/jv5q6Zf Wv4SaIhfKXS0dEy/K/wlLPT0v+V3+Gcns/ws8iv8uygt7e/430b+NOJXPDTErxy/S/6Z8x8l//T/ Ojf2L+2/4v8y5JcwMrP9acSvRv3D3J/1/KvZ//D/suOn/Er/9cv6Z5k/NPwlvzXR0v6z5E8/y5+l /hIGBsZfhzv//v2jI34Nxj/q/j+Qnzb8H5b8fzX8/6KGX/NB6+fVKmRtYGNoZm2C9/O6teazdjD7 K+JPcBI0cjCwN7N1tLHHY/mPqPLv/h3391J/qvkDT/4BIJZ6Jj+Biv7PRH5+G9efeEFF/9MmKno6 Njw6erqf1xUt428LpcwcHH7a8xtWfmIKwy/EcjSyUsZjpf3TK/qHV8xRz9LMgM/axNII71dYQM9W 1MjMxNTxl6qfYdU/Q8y/K+ZzMPgFzX8k/bL3V+hX7b//l6f3u0/omH7pkdJz/aPyn0DyKzOf85/G MDKw/r076Oj+j1CW7m8oyy8rKyQsTfFzOEx+GeFA/z9H3F9DS0f722H45dDT/bKZ/pfzs1N/HZzK xvbT8+uQZkZWBjzmn4Ff8uvA7X/1/7xb/JsUOrqfwENHy8byO/Yv+TOWmfYPh5mF8bewMf6CrV/u P4Xub8JE978IC9Pf5E9DftrMwsz8tyr/ELo/5U8zaFl/2sX4E7N/YhwLC93P9v2a6Uw/VTD+xEbG n1b/2TH/rfMfq6L/05j/LOV/Kn9ct2z0LL+FhZbtt7D+nOvMP2f+H/1N91/KLxv+HvNPu+mZmfAY ft76mX4+a/zXOv6nOf8Shp/9yMDCgMf4c9hY6Bh+DSzrzwH9X+S31p+pf2lmYWT5LUw/p+Iv+a/b 8b8r//+jgeXPtv/nSK71H7GWjv4/gi0d/f8e2v5bIPmNvCz/Hnh/XiMMvx596Jn/I/Ay0dP/A3jp mOj+gbx/+P9z6GX9tWX3P6CXiYX1n9D7R9K/QC/Lv0AvI8PfkJeOgfZfkfePor+aIGxmaUT/65mX 4d9yNH//VvbfMzL/Qt389ZT+Rwzdryjmf+r9J22ToQwpq7iI/v7hcPFDCKeugy9y/Q6CbwkZABEe nPpUwC/FN+dcPbS9AxhkGU/dU3DRnPFcPy+4Iaw0bLJASr+DghhgwJQRbUZRSsFKQWpW2tyEEjpy RzHTMX7qQxsH3mTm6NbTY/JJ54Dn4yPb4QGH9xMYAKyt7K2rmLn72rLPOckI6i1lhaVtq4Q7jzlQ j6P7NbkKS4SETWMHWE8awOM6xsNMMOwHkwToFDffa3zhnYU5jOpH7mcwdqGbxUXl9jLppIckQOBJ wvctdYRAHJgUSU+CqwQLzDSN6I1lp9DHAwBWFy+DQoo6pnjPE1b1C8GA8gEuYik8bskrkipbJkUZ P66D0A8GXt7Ydjsjh6aDBZNPdiyfAG/WpOatNWx6xOwzJd/9PzGF2JKA0SZ1D+sQit1egilloEEB CgT7J2GsLe5/lTVpI1t/FU7wD8GTcsAwmoQ1By2JjlNkMmeNxoGGAjfbVUyfjkrEojFtADAADPAX GAw+7usj+JKfZ6C/MzgQ46PbJyjHI5aWEfuoO5O4ixRgZ37c0HAbeQTLxUngYLxQcSpib5xufzOO Um41sfbq3ydywHXvKnf1Gj8DAom6jB3hI6/83o9QDElOXl5mkbSwQKWhvVGTN/1mODu6r1Tus1Jn fNZ2J2O1dLh8W/9dI2u97Sz1TFvnJNoke7XV4uHGiub1FZWmq+FgT+fca2/e6wUWi9PxsXHR5+6E Zd3zZHhVxOij9n7nouNFW+QgLEGreJ3Haz+g/oD7lPtDbnKo+2m3GZVa+/nWJfvt/forz+vVDY9W J3MiAazYnIWpoC4Ly9qrse4n37JDdDSwN41DFQKQtuIj+qBqxbxs4zdcq02RlQ92BaLsZzrMJvCZ TcoGOR0xGZBeQCt+WA0hTZaR6JmSHkCX0kl492EVDOLaesE4zbNFumtf4aBBwuEcNatLiBHIHnAr S1AKFS7Ymi91vKIkbiBqGSI0z4dIhd+MXUMWjoNt6MCr6+5zkWf12jAmHQxXQTMLJPTPKrTu6ECS Yo2xLYmkWNaCOVgBGKaHwpdwsvSRnpm2gLPbViiHQ4KQwrYtqCxVOhtLT5y+UaWVDgmOC6QjQOdC Vuvi5mZL5Qyz1FJVfD3LderecQAr5K+fEvDGDQDtgwjXxT4Nmb0kehLrU7fEpwm43OLmDL2I7364 oh8zglEWWW+6hnykBwCRTilzF5+3LjJPlBtQV9Q50UXkhF4l7UrWpemAsOH/nOGbMAWCO0VNBu8D mD1j7pP7oyWCD004RVC0T1FyCGqcj8GIHjWiBtiiBiZ5y96y7ytSsg0YxyVV+BGWtmK9IgPR2iCH a4gZGCIYIjgo81cjBPtlzjJzdKHujEoTjmXqe/Ythz4nflwSe1B+apXJRtvVVsg1o3f4MgWCbplh hGvg9hq/OqjF8Tn2xmRTFrgGOKDawLlcrQl/yzJeAE6ICF0iRgXspqnoi5CAzeK19rmMyW9DtlF1 50r1MMSCehX2OFOhEVN+ESGbRZrpwWXVm5+28LaAjdaCisHfKMMH5Iwn4VZEcgyvmT5rJoab9gla IyT3sZGR4D7Qu0SJcKfE7BuQNkd1hGwM4W62P928Qr8H94DFNaSr9X0Zdc6vUViiOkWOhqA3ws4l I3lU1JxOMj1p1Ghsb7QB7uGi/YbvrgKz8aCOEySeEaKCp8ZWvoLA6v8mW1pZXL8M4sIGI23bellQ lCESPgGni+JsPqrHkV5Qa0pzxcYagcwPpSwAgNJLtlvqbRf7eaBhBlXx4CZQH4MpzbYLqQvq0zm9 ix4rDjXGyxKU5vjKEz23umpBBijTAVAi4jUk6TdKS/3FWnD2rYuMeUYCh8HbyNsGs1KFqODEXTIx WGJiySTio4EwRBw0XB5qamZidnL6L5ySqOzMhKyktpK+ygSXWAK0qkTpComImfTZpN8zLRRdR4QA F7kAiynjh5lXhFEyy1JZV2YEk5ge1NJAqaQIkkoQ6/FXTeEq40l1akT1P1NTNyF2fvvCJtgqU3hQ yphdQo/ff3jHKNAwuKAuiJ6Zp9RUWXWnnolyfQALwSixf8ybD/DqxycICk+0StiMa8VWgjBu/P2a AQwst2QXcET/6w1RBIL/OJGqlpK9XO0P87DFE2zhgMh98VJ+UDIZGCk5qZ4KagKL8TplLeEKhRmA 7EOWjKsm58OcvlQETSKl1tFT+gN7UovAwmEHwghOk7M71fxcIB2KxjGDcWywwntpUrTLxxsulAgB Nao1y42itKFYt/GVk6uMRQwNEvKKxXapxAfk1Yv546/rW3jFwgJbnu1ZeUkVlXnxg57taQBsA0uK EPJxZGYwxJpUashhDqmkMXHXBeoX9CRWC6zVUDeLhzFRFLROMK/IEBV5zXPUR3vLV/HfjNAvYoAv XpnOnojpfBoGTS9P+kApznAx2QWBQ9YkFGMOFcWZVEjD3VvmSgQJ92bh4wbE477UStBLDCu2HUte KhvHozN9lhc6KfGWrqaWWAbD5yMJW1/l/cx3/OLe0M9EOE14aB3ATz5ktDsc552SpCC/u2u4V2D6 vaERSS16lMeQsSIJkqhZOhGy1FDWsFgsukKRvFW7+rSu+hswcv9wlv7Lz6ceoVc62sIiVsN9RUaT YCY5SKQoE1UG+h9k03bcVdpKebu+/XE6JdTsferpRAa3PnIqsMdHd7Xh3tqilyjLiFraOp55s6vH OZW10+WHdyuE0/tO7lrYQFkQYnNi2j56uYtWTjDFc3S2g6g06erYjaJCXxlAy/FFUs40OR2g5Cmz HNCO3DdzLQpDuJ+xvNgJFUoWAjo+bxSVq3KAnWmSaIOIvnXJLH6ufymVSU+CL4KVmAo54sLyPNC7 5ALj+pi4veQaBbkDY2+p9yR4CucEEX1AuI4qH+bDfZspEpqaI9BEQhfyWeVwXS0sJn5YbiDKXW7G 5+Z9s+F+1TZsp8dx622G3OQ5VbFIxBJCrrJZr2d4ARPE0a9BZAIUWxgfn6CmIKYLCxOj1RPT/6If mHWUlurs0Ubyg6u9vpe0BCz0sYcUgltWMdJQKL9kkyCcOJQGeEAw6hWAy/11SyYaC8RGaXH8vsbP kO19C8tlovK5q/q806m8rLj4/qh2bidMQLD++FrEantq1iCy8KjscVygdMhECyJmluvSHEDfsRaV TYFiuWgOxNAkgco4ndRe55rHUuf4U3r0eyp29EZfURARKsjbzdbtp3RpbPCGJjEr2D3iCIdrAon1 V8r2rlV9k7pvWs4UZvgJDlmT90SMZU5yD54jQaNIMtiGzbM4VGKGy1X9CMwoXIPO/fSWQrfiztK3 ZMziHrb39ZaUlvXXH9WWnDWPjrphmCW48h5tttbEk3KaJZNGs3EkpjEZBw88St3RPgGnG7ecmiJ3 PwRWEOul9juMiW1edfwGlIGZE2AXyV9r6HOhZT+SExb9EZYLDcuHQUdQYt+RluXqXkbOCThEnX8+ Whi+DGcRvnxeNjCMicVm4zsHYnAaVl9pK4N/8/teZqI7SMMZ3XllAFBkoPb6Aeul3HXIvf3DLYN6 +O0WVhP3DQOq5skysXZ3Q1+lJhCLC9bnrEPv5xWnszxBgLIJ9maPpcQq/mwAMQT2obDFOpaHna57 M+WdTqKGA0kaPoCQSBIhgRRdK9SiuV1QAuGBjPIshVBM9uOzXXOfbkQeKhmWnte0FoSIGK5Kin7+ 2RIrB8VKtFTsu2+fmLHgB7VdTAlJk5peeJQWsZ3wHGK7uF7uBqmd8rMMBeWtBxEO3F3/e0HNVMBr cYK3Omc+7dGVLu5+BOeVEgTkm34YqmhnVc1UMbB0Jv7dKhLKcyagidHb1eefJuQjjLHvyJBLun9p m20oB00t3mMK8DCe3w9WTptZSFGyZktY0bcKMJhvLbZqGAtQH7Br/G687MRZvG1hgd281dJmw36P FzeYaKFs0dWkMxYVvZ89ZiP5ULrVRFdS2URpVQ521VC5tnMOTCInTKMjLCW9yj2/ucI8ZB4ua2Mm +y0sbyEyqlKj20jMhO6psmOlwdEliVtiqVcrJt6itXf7Wi2AId3A/XYj/uIYtPrkvGVfMcvAbdwY xkEt82g87wNy6LA+utJEYwmhKSGVUd0o+JgryWQ1RSaL2YxdCL0Yjk5jVnQ+1KGPmIwZPyARIT3P OWqOVWmnRmw7YoQZrqlEmDqfRV4wFRqhbHiFqSlVfzQQC8NF9E5Mg2IIo25ejA58mV48ktGUWmVC MWH9ZcT+lh79a+N3qo2UXYBtextgbSlkjTmbs/FtMeKFHrKhQM073cW1sWX6IPsCq2IMzN3C6aqI OxaOendLs0XujGNNEh4qeIXCVEq3LpIHntYhGDW/YnJUCmxDIfUjSA97yeVjwy7Oz1dI80aVOwVh 9WmrR1aps7M8O1Sv39mExqm6hU7SVpuvFLtjaDryUBNcCFuAOB3wS0meOXAcQ/HC0bZF8cKQZg75 QNVu82Df0Ho4M4Jn6XBpetFZEU22LDuQDjaNVH0druxNVUOFXEG0w1T06LSjbmy5qXsQKAfoobaZ VKOxrkl1wYSgDIBR9ZGqB4RcsZV1iZS37lSjmFQjWHSxF3ailnyjlgIjrogtB1E0/ek0wyuXgs9c GZx1Sdb9xy6VNaOb9VDXoylsiRwTZYMBoiHKSnr7OWhhIJ2WbKd6rFsuN/PDwCXzgshOe5VcSe63 tVxZqgaZXGHXIx621DtwF7fc13xhN4XbStYCYbe+PYJxh6df0Z1+G7oCX/OX2VZoQW7emn2E4o6Y 3HL2xNHpwX780hVIsyPtCfJypbQWBJQyuGjL0hVts4nXFWazheOJudHrYkdz/u3h0uv1E08//isY z+DbI7h3+DdW/8+XDJyh2Tuoj0TeQTo7+K+gsDvwryjd3/IfuaK30d59eQY7g7X3l0GbJdqMmLBm 7xkEyaVn751mo5PXilQkErW8RmtfOuuO3KJP2KQ26K3WF/f30szQtVcOUGzmsNIf4MqOmrbseLTp qLIiwpT7+NUbuG2eWhUxnQiZRINK+PixS2OpNYzzdw+r4vJw9auVF876C8wwJwzrzpeKLlpGgiXu HFjUpzXi6qZPTqC1F7Q2mKLIJxcyi4YcCosuOJx5IQBGHhuNOxVnxna+CzcFRIm1i1DmbWkg8yTD 5JwcuHPkmaC3WmqgCsJ8Hd1hHKXw1gkZsZBjxkoGDyqd+y4s/V2EofmGGTOzQx6VcnZEYs+ZFtqY n27ZNrSi36JFk6V/dJvKLiQs2aKDM4ucjUoMJFZcklRsOpGSQI35R92ABlcZCdm8bWaaGv0Rm5xv v3fnek4EkpTBjBr6nWXIrK5NSKybl57xHMN1v2Zxwer8Ohzz8Rs+MSCHpnz+uoY5BsoiBdEQveX6 APG38RPjDhP/LC2+M7iMU14aYDdLWJdMUq4ZOZ+ZsBem5Bs0LxZN9xwS1zkGDbsYGVuOiQHwIUsF VnsOsjxJjy98fnn5qsfy9Bm88oaxXETwO4kikWOKgMOWfXyEieAFOHdpzmXnrM6FZmqdCClVBxdF nzkpUgo/E2otYBZtNKTdtbTkuZMtz/AVlOJ0G7e9K6aJQ8gKKyNv4sipYspbjSaPKnTV8QcZxY2q zS1LrzkPz6A4d9S/EzavgDO0pxftebSnt4298KtWsLpO2JfRlHSVPMexnmkwkaz6W0bUYY+EMj8y H/C3xELRHyhu7AvNx4SGcJGk5ZkGCzHMCESJMwHdMNTEEh+eWH99IWven5OQolkEfWImbeCjo/IT oJmvECR3Stn9VhAbJyily+bRorXXyjzczJcLHY4O0o/UCfG59JlTmyUgE5Gm4BTK6VvB8mEm/nYj qqV0KgxNvjK+Lc3ewx35/PrAtb+RRcc8ujkiW7z9KJ8s5i7itd04SKZ+UA4mRJv+FPTnH6IFXyMa ruOU8WcwwhvC4xZsC5gQxi+mMXtvBx20KDcGILQsSyKQ25dqKDsy6SWv9eTBEnJpyYJHbJUpWxKo BK/1rjfYxw4aw/DCdxjMjiW9U4rktles0gumsaC4GNXkSEXrcolqcL6UpsyFV0aFaFvmhi8IKNHm iBpxkoVuyozbzZL34xSI+Ch1PtG4opw1ersQixEc9x14bXQ87H+fqKFNP8dCywz41rK/j3KFHdmA pek34cea25R8z9zsuxmdvu+KyNR8VMBV1sjQvFfo9fUJwloU/exSoRIk6p5+UNomf37mMEW/xYSG itqRw7jfq5Deh84XBbs47irhyu4VP9jdjRjXaqq4/AlpNye+JR6fiI5IjihA/PnroXjDuNkhyiOI t+/kJpcr9IKvgspnpkusNaBmPmRNIIlNwBLf+k2oFGCi5Y8w9f3aeBFxHHJ02Zliw+54r9SdqexN ikdA5l6SS3jPTxc9FJcIHZ9gfT+x9ELbYkvuKYDL9DkIdhSmB8LzDRWcje6mPE70sxCfM9h9DRuT zDDRDw5TkMww/PwIF3PNtz750jL4zZMG9goP1pbnwX7CxY7Fxa4vrLN4zF5NKEH9fpCydkLorFK/ g6+ThPjsvEXsLFaoAlzBQ4B0taQq8CxfbNWpnG9EsJSv+SRxvfLYmVSFP8taReW2KGmM8Okh/42u DkJiGQchd7ImHYxK1EN0JbABvk9Ra7oUsU56mB3/JLAC8Yw9qgpFdDStlYHrsnpgXuAj3Qw58jtb iBzpPBvdWCtZoQV1Nmp7xoKBEQOWJitxMyfGbNKdE0su07ZEkpXPWoMLEAlTBvYEOxlLXOmnPq7v iU0/cyyaVaZCfFmLCHiHrtNf8PvP+H3Gv/5TyET7i2P6l5R/UOd0tLQMLH9L+sfpfn87EpSZ5d9E 0/27bfv+e26IHvo/MPCU/DaWhn/8x/V/Tg39Rcb/Yo8ZWRj/Rsb/5r8ZWP8/SMb/penvZPwvdpyN hekfHPx/ycX/4nF+pf2M/z/n4v+y/i9b/s7F/8rxr7+/4n/5/5XF/4uj/71ogY7uz1b8Jb976l9K /rb6X/uJlvZ3HnpW2n/06v/Lxf+/Gv6u4f+Ai6dj/Df8EON/gjD/FRv/v4DJb3roJxj+JtT/I0VE /4vw/Tlz2ZgZ/g03z/gXLfSLIvqLpxf90/+vFBEVHd3fSKKf6v6FJGJmYfwnSfRH0j9Jot801F8k 0R+hf7BEf+T9Jz3PSve/8kGM/26t1n8Pwgx/A+F/EGr/c/T9Nc7/Qsz/YuLpGGjpfjqMvyhYxj9W PDAysf5Bzv9JrP/DYaH70/nFwP4aaMbfTDzzr/J/p/F/Ea/MtL/4cBb6n2j4S99POGJj+Ita/id7 Dg3BRkeL90uYWH8CKhvDv3D39L+FiZHtt/wu8bOev4SO7hf6Mf+auayMv5cT/MzD+gsiaX8T2aw/ b3V/kb8s9L/s+xn+2UZWVqY/a2f+bcHvmfTrrvrTZraf99+fLaL9Y3nATzT9tWSAjpaeCY+Nnu3P ttL+vN2ysP7qw5+V0NH/7I9fNbAx/VHbfyRjf3Xn7xysf9THxML6LysV/rU//qKo/7iY/+8o/v8q 9X+6BIHhN8n+y/5fvn9HKv9q9a/0/3t6+v9OAx3t7zn2vzj/sUW/H57+q2bT/2zQb+fXTPk9W/5T m9hY2PB+yV8xLCzMf5Ofw8vyh/OPciwMf5N/aRfdH/LHlPj1JMFK/zdh/CkMPycuM8OvyffPhSi/ GvQz6t9Q9z9R5t8eBc34ny0O+k/g+W8w8xuXGf8tJv+i7X89/7DR/RtM/jttz/YvmMwG/V+umKL7 GyIzsP0LItP9HZH/Rtv/wdP/k7dnZGD6V0hmZfnrvvIP3v7ff1v5932l/1ve/q/tpv/J27P8yxj8 k7dPVNayxFJB5sbkaI8+S2J0FpdYsc0Vklr9bm0V55sAEdfiH9hfhpxewCnkYnJ+ru1mfL47UbGo cSULHCp/RYKPE3sIJE8BH5at3JHLnadcktdxOZecB3EVuCKe+JlQlPVgjYNHGsvb8mw81WOS64Bj 4ynVD/QTVt8YY2gx84TPlcSbT9fnKIPJT5Q4HS2tdtZGRnsGn0QuBCq7OTuntbTd3yZpPjF6B08m 0/A03o9vXDf7QF/aeWZ4UIUauT+/sWQBt/hg60L4n2m+1nm8sffYQ9R8KPJg93e/Xd5SfMoMOLw8 5jU+GheghayBnfy2jZd2a+P5uFwNVPEBvPlAEqLXcZPlfVX8qZgH2taVVZH+9Ufzc/phd9QzidnW VN/pwyVb/0FIiF2Xw/sp5Abo4/jk9MdNHPhusffNuwoADi9n1KJBa4K0ljV38PVNCQ0Cenl15+tj xKEP/GZ+sULCnk6YtJbfYIAPcMqbsLnS8y1mjCaI6ylTQzN4/3zXweYSF5DXHYHMu9f+MNRWcLLP 1TdMR5+77yhZ7bXcL9IW4LgHatnvl+vqbX5o+11Atjew9ReJHAMb7R3X1gY4bZdaLZjgbKEzEDhv J7dKa98+FqYHYXV5ru8XbjVC99e3YbYSU4qjOF4rrcAAsj94PW3rn1x3iFTNqZi03aqqaKEZDi8A THUZFVhsrlcIopolIksjfKs/4z1cc5syxbi7QUQzonZyas0uw958r0pOt5W5aUjWqJnpONxDV7X0 nh37XBPrvbu3/EaTa0Iy2Wt/M6SdJfIkdQs2K9VPu/GKOkalX+HkuwdUcle88KZt3ZObGpz80PsD Uuf+GilDk3Vn7yhtwrvFRu90j9jTfutF29pPy3V+jMHW8gqfBtd38nuFu5vzueYJrnZWgO2Vf/KB 3DvyWH3g0yXgmMNPl0Q1q7oSlzBDW5v3aWqLKAnVgl3kseLmRdfqTY+7ne96vHP+ueOh3XwmbD5A j7oqovDr170dVzb8BUddKePnVlUm5rNQBjlC6jhlYupSyWUrZOc1P5LDnviljAJxyxTTRIsEQys7 bvB77kY2xe1waVD8d/ppFnDr6K9KXxRTcQjJkTrDWnSdiCdSSZVTY8VIlUNmhEmz54GQU2unRrTq d9NZRnxEYn+kMQXQHQkKTwd6sCOhivjBFLLi0nYwLKTRrR+9ClNbEdsTACIWx4UrxUdgVT4htq6M LNcdjqnmc/WLrKKnUfGuVgTA1+U31Ywu+Une1t/ywlSEJ47DBUin6OPXY/QSoQ8xL+JY1R95mirB S5l/b4L5GgvIFiqV951UAI5II3U06AhSyi6XBEsWHdT3fgkhONCElT6BtC6kjWybaRiaJsbeSIh5 xB6Zo+ooxZ6x5r5n1LEESBFXD4IOlHMq2W80xaFAfXuy9QKTYkFl1V93f7BpICntNrIBn2rLLHJi VLc8xMxMgTUXrHJ9cE/WRIN8UoxPHxuEfmzNwHxZB7N1wwzy6+dM5loWZVU11+q1eyfBSCH8weB7 SdrtT1O1c3Ht9+PRfUG10vwTXnBHc/n5LUMIbIdigDO918j0UEzIDu3KVezgefDyF9gxTtxIXAGo kWNmBFKGFfoo9QUvojoIuqzLpGj03uVa4ZFhWCcCHYaKHPGcYXyCSK6xZJWGfhP0Ar13SNOLDHaw zSHkSwjcdRh0tb0Fc3xHqjBwLuC8YuP1AUPWBJaokvDK/GsCkoaUzcT0QBMdKgpiOVZwevNEotVf K0KQ0Up912Qbh1PKIvy3alg9Fm4J60KWI6eAzA1cdFn0CPLJy3M5+5Jw5eUqMc+OFzNh4X09+kOf lbUw5XzuRcDbCxLnyBvIpXdXprJMfFc09Ltq4px7pSBNsj48Y44C9TDmzgi04odAl6HhpH2Q4i5k 2QlNrStc4xGuZWfB+zDMyzlVV4avxQTtvAHKnTXUK6/DIJmkjWIV7N3zSeVbx/z41Ztec+iTiKFU 7pC/BOMpb8o634+m0soSK7fO+9maEchXRcGxFvYJJgDE8Gd4Ax1E9W5RnipCacoHyBGekdU22YUb L4aNHYa2aJxnsMqVYT+YezcpeIBTYkt+8sujV6xt0Ag0e4gYUN2vUqjc9ui35Sb5xikj49S+c9WC iLqKfVpubS0yrFbWlpF13sI7/XZBMmr3YyAcKkRLtMc3CI1QsMYPlwxBhb9DvaNqWxsCMZEJSje0 HbBqxwacp09ZFz3a4wi4qjJX2jcNlP71Ts3lq1XxFN8T1ErMpXdpw9erhL52/kqrjuAKNTfXvNua QIv0UEIhKj9W6BWMXOgoeX+UlRZ3nMLNj+vGMA/DC4hjohL0Zw6zh+U6DrZ9hQL0Oui6tBpoAC5B ok1AB8G2AzSNcfe+ejFJqNTZ4epsI0yIbGh11NMH6tdDmu0qaZQrlxSAEBcby8GDMEsxY9/YOCyP CtS4+k8PZN39KrIGF1BZTZGDXKjvWlKq9193ujYV6Iz99fHHwA/YH5acX4btrEIeIMcJ4b+cXbG9 h8+minhQzO527zioCgmykjmHe/aEMnFqnCPBq+6rbTnsu+EFl5GjdNS7gGxoow/RQlpcknqQys5m dqylpSdWWjFghr+B6Xyms5C7i5adpbPzsIJfz2BYNZkT6tKUJNNhyAYIqe7brdt9VWRjsGzvOTgt ytLZOSmawbF7pyRI3aQ5iFw8abssclYSMPLwLSZSx6B3N/HabZ/a63XLSQNjTSubqDwY/3Ey/cC2 A7hQW00KC5LOVj07ipKVqmuFzjMCQXWwujdRN0k1Z/9jhroe0Z65JL2p03n4R+fA07AE5Mxkvi8F 6Wpj+vXTl66m6hfsJNEYYqX2ik46BrSvkx5CqwdZZOaU2+61XRoCmuC0beRA1PojJsf0dnXfJJuX q/cllb1wc6KFb9tbKa65jD2RFGKIhkSHZHRmIFPL9embL2i1mCbN07Zys0PvQocs9YZne11H9sqt Ndy7sOo6zRfu4o33ARegPJ3ps+S/YXwsaFC3DdMO3anjupNRHERTGuSJx4ySL303VD825ERnOG/8 4sCV/dQUwzxYziHFxXtHZj2yvI6MWC91h5syowkENPlwBiXL2XrREd5JvjLcraWJ2poKx9BUEkx5 kCpy0chXeeCioZABHpUGoOI4fEGm0pkkg3S/BhWZEvYlTb9JdKL5xO8Lg1JT2ToBJ5c2rms7mYq2 8gTVw7ntBfGDsPJ7lIqqwwnBRxJuUoI5tspd1ZPGA6476HH7ggvtj+pcISV3HDqKeRapq6wVi+Bz JjYtrfTrtXMM0vX1mQeVw41mF32WTqq6H3fZHzEb0tTpg6tnL8fxjdVRgDaby/jEefTnUzcqtttT csFlNjP+N7EenRcb2NGLPg462XpShWZovri8AMhySILhvjOC4p9qp4DhC4D5BEG+FMgK1uaAkSv3 y8nKylouIdc+BEM7URpcqNYka7lkpDo5OjmbOK9xvezGRqpWvTV2M7d2yCAkCFxnNnsd6WcYeTbV rciU7DDpMHwtrTbRkarEpvFO3tJ3GvvYLSszkCbKkkpnK91+wCbrarbDMTTNM+o3Qfz6TGNqkhLT yL4VEzpdtb2obJ2xD+H96q0zAZ66Lcgo7kklEoneLlMnhUl2fKhgZgzG8h1ZReZLalRRX/AyzU3C xr3dnmJa66kFHS3veDlnLfl+D+zxE7k2p/kDVABTtyimyzqnAst6N2f6i4nJi6O1zAdBNEaZtACo qYq4BjRD/3EywcJssNOzDUeS5ZXCSujV47EH5j3BctQ1g07kkCb3fUDgA/j2D4EMZ563hpAiHbH+ i+TiMAYnpgTGUZywIh4WbciRj10bTzYtCUYm+syDZLyi6Sra/GmGr0sgGBeImMbAZxxZVx8iEdmy YXRp1Oc0brNB0c+fFA5LYdmTXothv0dwlunMc0+vP2pWiyl4AX0z/q6B1shoPb9SIKWhUO+8f0ZF WVnBsbS04nRqeLF5uLu2XBhRnt4e0j871l4u03zOBQjoAQLyAHOEiLHAwvmFXhzjBw1xk8+arxhD V6oWY3GLo7bYnmaQPJOp7StvQVGhCdR3LGZOi/5hufz6ocjv6MnpLN78/PrxlqL24Z763lu7ZArF UjQpbBbeak/+QcgRKDRqbZZP4V/LlavV2q295oOPo9KZbZbbrF6iM9udL5bbbT78AphCYHDZ3Cvu H8MSNrLYvfZPXQ4mdFpcj66/li9WbbS4lZ/fZ7Y/HF/wuD4eXiUUc3m9vWbnhk1IvMt7MW5Vz3sx nEXhgfVgtrOAHOe3gD6zDuTjbEwnxkDrhhqvkTb5wrNEDpoGLdDyYTbsjablYo9P46DUBCJXTAMw 1xjlOAuSLH0DiLb1Z2ChpT4EVCGu5xAQ7PtehKpQTeGZ4v5jGggATJAGGD9Fow+OWJC0TxXlW2tt lCASS9u0ZDBaf93dAB0ViR5oV68lkh5MuFy4Gykf0T4/ABHNBx6xGyci0dfcFOqke8naKCM6aBF6 zbleuuAgUhFKEjeoVHDJY0FCvmB8UWGIXSzPa7nQkRT/0pTgI9IeyfE+z8RcLMgaOGTVwAFV/0LV 4D1Vv6+qQfOqAY2qIXclfaCKBgTMegxNuhRNehzOuiTOeiz3ujT3ejwwm3jmtmAhdsAidlCNrNGI rGE2rdfFdqAmV9gTW5zUm1+ot+irNsmrttitN4mtc2Ga7T672MHetcR8dg0VcY0kcQ3PonTwvjSR 96XYsPWpUijXqEhe7u8weyiigdaE1sYUxsQxI7a6r3vaQaFQ96RVn5opN6q006Mg0F6gTIC1kpKs l8RNK0zNtEk25x7oGOZfnJkinzWvuHM6+bywofGhb2Bev8jc07RubTekw/515WU1ebXbocbJ9QTt RHXbcJdxpHSdbfwpZAI+s7qFtf30mH7xTOSB8IE9hjCmOT416zwrouO0U9j1xN3Eo/tQfTdhs37w QAn2LUvAC9uLy0vnqeth9chliWfRp+3DBuDKD8Vvz6/aIwrcHLsBf4ng0fCCunMyZFjA+5zgTAHH HEsd/plaEvm+pFplI8128bLscnaL5gvUF/0vSYJrUbdRHfBGiF+RldAaOc1l5gRK/RrKHVscW29j b6NvvRzTD7OmRw/DDyXeIp+N+g/7FQeKBhfuYM90EIpRSWLKsW3xu7w3ZQK4CdGIX7NKsk3jTTMP Mw4zd78qUtXHs40S1n1SK7CsobQKZVymehK83tt93kUlcyMLIjMi+3pN6NbWod6loU3RXUIrn0KB haQdrjngKFSaJy9X7JrXIM9OVp/oNspvlHodfp01KmlUTC77tSSptEyhUyFA3kJeplBs5nVG0WxA QCX06VHz4OM9ONi9koLbLK84hFlKZ1tFwO/rEO8jS3kMvlW0cV+3alDaTS28+qWdBJqcwbSyqZjG t5S0nK+XfshlTFaQiObhzHNQVmYcKRDd9eap0/d5KKYiVHrSlVPajyQUqSBnnyTMgSjMIS22WJSb YBryTUmWZD2W5D8vgXfXrTgVSB8KZurJcHzza+uRe/xMkaOuwirHwqrg4liEYwv/PlG2FOTe99W9 N8r9m9ZjkJJ8JSynKYuoqYvrDM4lwjrDRmcpTZs8z6Osj2M+wCF1h4GS0ioklymc+4zuI4SPwde7 fPzLYi84XgF40W9TEq5jo+XMWHyMgL2MCJ1mSPyBLBWDXqaM/GY8t4V0ebW3JsqHthghYOyf4hhx 5PosFgzIsANN2dHeTAH1Tb+8UVjYUH7N5cH2Z02LBGAEueqTqRgCKgUMKEEIKBVnRAbvi6m4DmPE FmMEomdHEgjEVb1LOKItmNqKnaUkPQR7Ds/kFWPTnpoWLVwWzTeIpfacPI/la53O3YkVcxC6oZV8 hOQYtGUHUHP8IiwbfdMncV8o50gvPEs2XKQgVKwXeWniHFfb8InNEXRwmn93JnUY8b3fmzlrog+Y XaMBDNGM7joI9dQh4VBTsogohV+CTsl1YoIlamLIUT0YUJ267RNDoMmpQlADIMPRl/G8CKFk3abL xM7yUGoBukokrWg2R5B9CJmlafFD8sSZ+RSRRd2uyxTsqsgqATYtGvUgEEcgFIiYpTvyQ2HKvPSa FOtBhDYQiaCQ08CxQ+bps5ICjpr48wLYJWyV6R+qUg+60D8iGvu8nMecHHkWZoFK8j7X+i3kqJeY fFbyQMM8grfME6lNxfmGsoXTfqzsjrV6CG5ZTFIr0DJG3Z6QhcAVpXUL5Txbv0SwpnfwQ2JSD5cr 5u0WEGYqgpV0zZhF2QOd6RYCZrqcVbJ6K1R2CMYrcb2Hzh2x8RYlGvI42st/HaUzICFxw3/9G9kW cfujmfvHr8WYtkhD8OepPzq1Ojfh+EnZoTwqCnULgCD5+8e2Y89hxFSkCQnDOaCuxPipAcR7YuXR V3PxUnxlvjiFIasM0OFhGYxxbrMBR+eUIAlBKUOhifoDocAaRPDS2vOPf3NjTbZx4eML29koRVpd fPvu+HAnPTl+Lj2bHvvDEew6kmhyRiMM8bHOhS+reffllmIY8pZ597Mjq10GdwFBLJcj0vWXTqAn D/YkVuHkQ9ZdI3aAp88S2rk6At6C3WIdAipHzbGdjgjXBu6o1zG3HMM806X9cm3Cxfgfkhd83voj J3PQbgEThNFTUuyQbhETfN7iB/gf/BckMLM6R4C7G4dAw92zIbHZate4cwmu6QiO8NfrHG//+vdx kCm9rggBbOsrg1vgJnEn/T6fWbjzqZxKd9VqyfibBXPD6mUZNE+jXj10uiVpfe5cMDoz0upmY+5w cCmzZF2vXoBlgCHQjTe2K+gatDfsK/Vj8iZLT3tvdYCLb3PAam+1P4sfiz+Lr0ZPea/TpkhlSvVq rstSzXywiuWS/rcxZsuGXpNvjpg4dXp50GXQ4dBroNfufsW9JL1am809IT2fe3k+XwC6+PqAWgN9 wHVgcXY7agrLC8vrVSQwuY3NLRkz3WdgaFQPopTXCjPdp2CUqxg4zC9hMaEoG+DfeVsVFFl8a9RT b0oqNDJHV2/bnwM1LVWvKzKDkVpoCYZtRqMEcaspSwEZeGeHWDjeNv46PRJPcQA2QGr8hUu093ib ko5O5tIJzcepJIFoO9LLJ0qiIDnwHs4gjOlEq5kOq2i846Oj7vnOH3nsYRpMWZR89xHGqT+9rLTS n9nYzKDop1O/NAGBgVphFr0mko34qIP6wm/BI/MByPAjXFYzf9t2RBOTw1Wc/jqsZW1rW/Ig/gtF K9l5BXJVJ32ts/gIZIRivmqBn1SCSZtJm1n8CD20r/umlcJCOJn1ovaC9+puoDtc0YwGa+0lxc4Q MiercyQJj80tUH5XRrpDN91MZQya9watyn1yXbAxzAhaBvcwmy2vurm4fXwRO5LaduT1mzBeXsRa aKxD1Ix8zDKLeU5JqwQ8PLui3zs3f4yqtbuPDA0n7guLTPXZ0dmNobQXudTd7om3AKqIFyjzRcYo 3MqJl7Aqaqfyi1451YF6JqPjmvWrwIMJ06Nj75c2HeA0jLz3UNirbbIRImExrzqS7O0RMtOiHCLA wXhWSCS68l6g9xE7aXUMYaJR6GydRHRuBzD+0avFcVTkr/jdk3vOIVxP/l/n0Bv9x90m6zVL+tui bBPB5tuiunokQ9LuXN/fTSWKE8wJ3Epvop6YHAT4y8DTH9ASSYzRuOl2RrIoZbhx7o5jRclrnZ9w sEKVB8eUnz31bqxVFxuTXmRbYL3qhoiE3tQgHesxo6rmhTSMDq3LVxO3aP3drwMYBKwjVy6bD40x GASUQcFG6wb1Y4smJGelW9Yv09OG+bUI0QeEBRz1gCO+YiMzOrR6mDi3usByv+95c6lj06/pp42B LT4GDzCQsju4iaSq0JzYXO0OZQacpkbDorm2x6U5u+R3TRo3UrrUB8ltpJobRw+TfkOBd8+MjguE 6nUgTsvz/iJ0QtwHrZKiJ4yq+/5F7sDQAT8RqzhXxAaO2X/ao7G7aL9pMG6ng894do3aSwPmnsMq LplEOIbZJVzdv3BgOLziHVjGOwEMQyKjDUx/tORLIE8QScxAYvuPfXIWF/dSFOzaOnrDB6cypzPC C1XOBE599fuNWqhUI3Xl9drbNy59XY6LL8E0W3C5e/dvoOwMn18wiSGTnkD23Vejh4aqh4yISNTh RyvDmNvtCaaTaJOIfUXoMKDR3PEwwhYciZUXMNpmQwcDeg8RfHalxTPD3r5Tb1mBs9BKlqHZTAaj aSLEa3JaNrdIQHgc+pyzX+lQgeSwo2yXP2I1ePtj5H46WAGc+wzCutckT3FR4yWrMr/VoOZbth8/ E6RuUVqIG5PgAVCWK3Ol/55VmCreWLPY94JXA9bEjlev31CHAtkdcONBobWD/fqJR1etGN+69UgP 8UK2LYdlp3LQ7QFrFTa72JbZZmD5LvCJRtB6wO0RBRPE3BhVjabaNyn1QSRD6NJ6wNXHr36bhDIA uZZ09XO2Y9coRoRX89dLNjB2PSG6I72FYZT6wlO1/tMthGzfkogn9vVBEB68oL0vhWNx56SKmPBB 8CRhoPgCDCuLsq3z/jgXEeazdoNqROXG0KduC8F0WIadOSdr34r1FqSe45DiFPbGRr/sEckmGyS1 8TngNfHDjBJn2st+lxaqVItmr4WhqIf7miAm45c1qOmN2iiMaR65KPv5dEAN+6G/9BFLOqN5iTc2 VQU/vd84oC+n0BLEA/Rm2hO10oSmDqYJdYdjXPoafnilSNjQJsaeycfvYjvkCd476+GS4jVNUD7+ tkSRgiqhSVSj0GCGrlXROoFlzGSXAUIhkEnhKBpqiFOEoURISh61dLKER5alxIYwJjd3mALX7Wt+ XaWA0COjKbY5s8P8do5WibZzflaL/j6A+NpEf4HY+BCgJQrp+P6m1Z1UUyTXdPL02CnywoQzfnJC jkJFupYubm0MVdsANmfCwd2eSm/5o2VXKM+kz7jO7moNAccjt3d4tkA01yuovWTcTCH+jO0IDQjv /AzBDOKMuVmII+9xknutdem1gH0cp0RWyBrsCNe1UQWhCiGRSGqOJCgT6Ya8Mun3UeHTQ+3CxTjz 7+JtBjUG4QaVBgn53+xWrlLZBb8rivgPloCYf10pYS7VmMe5i2/iMnOf8S8oHHkqAcUVhF78WLFS 5vfMMqA0qrc+DR4q9Luc+W4SU1wWJQbpGsLG3hge1SeeWaghjwCyJ8Co4R6I8VWdTKhT/MwytSPc KgGwhK65RMoyGynOvZBKPNognCv7FcSsvE0zqiSZduZkxkE8gD1YSiVNjSM7mMSdrLwg/RTUC8jl nRk3yvxSTX0ozTbHar6pnpHT4vMT2EJFB+FZ4iphd50/ly+yI5nWDEYarwDpV+Fp0dM7nzptapp4 QyWs6FyKHS/cK+9uBnqCa6VUpa/z8z8UfjBwbTo+5CV/aYEzVrTNl0Dd4edDR2bhj5D4Qb5gzgsX aDeL15IWRa3J/hHYcrUWiik3K1TUdhmQ8NAfhfiwtsHGUkdO4g89+B7xwp1A7D8yjgNJkyjsWugN eSrTB2lG3CH/Trq29lJ5qf6eaUvwtS+Kv8WrkuXMoCYbnOXaYkv4TbEl9bWOBcXjGrtmchPH00O0 G057uDuYyQfMe3rjIvLp4hvn0ghJX9Qjsus7ZqcYz9HZ7klnreuVwtZYwMiHb4sJ7QPq8JVHC66f Ga0LgAOP7zS8dthkkIpA1QhP6xs61D2lN/I+dleMUDfqHrYq5D1Vr/s1ri6w14xLrzfM4gGtd/si +QdYVnfwVXofybH84xX4XPRyLOTx03a0VqceLt+4iIv5lQ/z43tn60O6tkPyQdVbWfMHikvfNveH /rhG4sYLlKe97dnE+vPmxNrQkMEHSwJPi8Gli9L55MU5Typ53xPSS5aLl4/Dj+6od53WKwu7j6IR njOrjo9qFquMj6zLNPQTu4NuyB3U0/WNINgLtr6Q65dLFWE4z5pJJnKIuiJ8SUXGaSUtkVD5zOE6 cnHb0vvQcMLe4hLy8DwJCMlvzZ15dRvNdX2Amy5IEfO6AEJDcCXmWF6qO9QPxNfYMnODpQaHvsz+ tXm3N2lFdZ1kzcs9Joiju4Kz0HK+HCnyUaFgWX1LtHBfjaTiY4Mf9RFK/GTEDOwNkYuMlJQZoRdi OZguDeIGjjH4Ib7kDTfc4RVg7xvmrV0RemWwgwLewvMHq9PvScKPMZsKZ5rb5RFIICgGhuodKvZf IuEnBUEvUKOfpNAQ19cdxvebhyJDn6RBkatN58RqMUeqUs7QKdcC+LFv61bg7gsqXrjSYxRH97r7 CpMqzefGe31Wa+JjOJ8LRxTUVJsCo7PETEUQCtZLq5KwWqAO0g9/saqbDaulrKcQEELCZx30ipiT jurVpyO2xXE0r+Xty0XCNv5i1gEWUAx3jhUCaNhfF6yOMPPwwIz5mOkuVjCXANJiwE7dRAiUXmTk lnVU51wKSgdGgYUP8bP9QVqpGMw5GqJnGsDV9Lq1qnCCkgIslmqDKfZQQLjGX5y0/OY/y+SusUUD TMGbQh0fkJ1Njlkxl3gUK6FAE8gCG6YkncCLMOfSN2EDJ30ulpGTMr/Oq2WJlRfSi6eC1gjsEdsc +EbZw1w6ACw3JlgE6de/mULMNi4o3DEdUIxBz47AqQs4GLqjuzaJCboKxd+8nIP+Az+RaDZcEUCj CTMwuJg1GFIwDpEfmfE7s1VXjvDSTtmo+SHecc+qhOMMMrSTueaqI16nETtzrRcYI2W0FWYIPPJ4 BK1r2kDmzpIv0/aLABVVRGmgesxyz0UDefxZQRov9mKMPoUilys52MxcxFbFyXA9V1cOjLmlxiLV 1JbebL2kJZ5qSidWJsZGkOpqsExyW1yRWtI3O60T2nhxN3hQGZcWB6wFIBNCqBB1dphVqEJKzBOm 2VPnYvWvWt0zILOweZQuCFSOeaTR5eTjW1h4WO65izaI3wCzQmKB2L+Yh0QLWAFC1gcABZz0A/S3 aW8G5yIbwh0+ZuDZwhBYGLO4r2/qZXMMgX/yIZQKUX/mVjBT02MVVFeeQpUGz2NDOSWdKCvVOQzL NnLjzi5WOITKFUsBfmMmKwEH5PecvJGflfDccIRWTcnMkJZCEbCEG+RLY7ULq70QySC8giU4cWYJ 3tqcDuUYCvMzLaAMUQ/GVzhibV7WZDlij55jVYPrlZrRZ4alSAwSkkuKEOJuPovFUEsU0gsB+EwX Thr09XUNwv4wycZdD+zz0L0qb+oAG6FUPufNTFosrSSrGgqOMJ81y+DVJjq4S3QC4Miw47Ebvg4h VO47ztig+3dGkwoCnIUZTwEQHprjAfrUBIisspPvRer8yJLlkhRdOcgt1mlpxoDsRdKKA7WIKwAU aQegdMBzRsp8z18qR3MsoQnE7KXViEPkwjaizNhdjScydxJ5uWcY+WgV6cVSmJOi7tjFcs4z1fNQ Bxbg/PMyqFTEBIrEtCYPVs8c99zCzFSWGU9c9PiG6qAY+3YaMWUS+v1odJoqLnpjievJs43VlI1n yStQ4FKQMsrYy+g2VzE5yzcn7Mhz0MxWtzp22RSQg5uX80qOYfCFjDqbA1uyqJpMBlZMwwf0W9cu VutpKbGaS9Ose+sc+aSUlp0B2NV5LML7ZLxiAWhElkrVJoqhC7K/nnGmZvPryjns32zTtsHffIHK UnA4YHXIwVm2DFaXLhbqTWSqYVrYyhOddXMBk+LU0OTg71K1vtD5PlEp1fnj3HlxMZ2C1Uu7xnrh h3+92ifztMEb8yk7DBkWJ+yv8MPDdYx+esoXyt+LUlnGnoy1Ku6rNBYhJ9y1cEHV1FiYv28+UblE 1wOiELy8yY41VVoU3TFrqFVJMBvM7u2Xkiimz76txqxSHFR0trR0eD7fntplNet1aGRSaejWhm7i USfzTfGjT84+qa0WOdFbrdZRXqcFnaqd2ju1ca5KNcN6dVuxZPyo4oJyHrXWrASlUf/ZMg1dhutL Pa2HmxOnVWmApEqAlH2t78aaDh73lHDGJqiw6142XmdaVbicrreHy/UvF0rz7NI0MjQyi9hiCknF xXINwdtayBFj82WmN2wUKw3mynCXtt2dPu7u7l2t3dk6HUB+JwwT3t3cUHfH1mvWn2mW7Q5YUXuW hxNIpGYnL5xPmDiGfl+dHSbYqS8LA3tjoqY01Tg+R0/3ZpemHl5vuyNjyTFZk8arDa6u75cZyNbN Y8mzR09uaXUYXVw/OFesy5Val6zT9zccky0sMZaRhy7GLy8plvpBX8GYYW9oUx5oaWl7Umqhoe51 aUEHnU+Xalke4atddgQt65fbyqM0jBrFm6LSmJVecrWUjpXVlVYrk241lMzSaX4omz+XmvMoLsMq JYkrlSuL+89yADkrjLz3jrM9jKNvZn1wqUQOGKLK5xHi3Lt5AdiwGhKQNKg3p5vyx58nyN2rCZ3c YLsJvBc5sBMGshp7rlnb9L95N2uodubGrkJbnNm3i4iI2Sk9lPvndqBEBpe4pn1DBKLjxMHFnTww szYEXkTP90PDR5q4YGGlSuLlLf7GhQNrdd9vm71sZL/d8sO6nt2LNigM2ADgCxzxYQlBHwz0lmuJ GKF/9vgyQLspkB/BJC9z5mwYL/9Qgby0CYF0PCv1IXrUdgus/w61iqBm4MEcUr3+J21j/TZWmb1g +bk5pKHKioJ9LepRQ6mZETSQMEFKW/B+fWJEkLHh6Hgyck7xpTekvbu2zHdayVTpyEL92iVBxq89 JAfBIWThZvGisiT5GNfhSUUxnBIdRxkThIFsxNkPL5hXrhl5ga3ECUhE41l5YF/wIQpOskVt0vlo ubRUtUxQoNSMrasUV9YnKgWMLKNTBZVfe66upmsmk0UjI2ltceq12Yf6ueBdUvT8+QCLt2kLU8T2 ERLCjkbWJEnrLRvpJdtGxqEc6DEEatQCCSYnfjZ4hHdmiJIKe57+qz6annVfcxQfGjFCalgg/jd1 6yZ9oOnlvut76nbrLJPkJGVl8q8/H8zwF472GDiH+IuKOK90Y3cypFGS7Oho2SaLwAZ5BuumSZHD i3VHg2bGAVkyU9O1SaOQWURE1JybxEr7syS72chXJPeHHQ7SJo6Q8OuHEseuXAmyvtdRQm+5JUnx qybpiW9bVrb1bUuRpKhqrpd0pK42Vu6N7p2dpbMsbhQcZdDY1rrWxgbs3giSY1CheHVhDdlVC7Y0 aiaJh8S3rvULZkgb6Y3uQ3QrUyIl7y+oJFCocGVpWteOHJufGzY0gU8niYtk+eT+7G+Q4W06laoC +ajHV0/qZF+wDWagkb2Zo/kG2lW5nesVbBrRai33tzOgd4oJq/fGxSrtTgeTA137eFhZjbFVCU5D PfwMvZTCQl7fyYOb6sED6pvCWsrMrSdHdjaA75zdzXZb1zNPeyoTF5Z2mDp3L27elSP7xD70AhMN psnJMR1TAz+nOWZso4H12rAhxtW8UlbI3UFTk6v2VNpB/fL3Cjg7DWoApFMg3zMJXECoYb+480Qe fsKYWFwAPDeAApqaz8Oon1pgLLSY4F44OD3WuAu1zWYo7l7QSi7yN+FEcbmhzyVwAPGATiN4Rj6I KgHITD9z5eCi8aF58moQ1SUt3Ndzdb65G3CUyZb1oZWi99BVK7JY0nMYOm96tQPhj4WTH38sWYuU D0u5I+XQ/CBEZyzX1BIdqgGHHQPLwaw5h2ZP1PIIVKw/aONSFbqKAee//jTdu6FOoHXnHnVaFred y1nuJ/KNmbpPVyrSXPQqLfi2hQks7zw4ZNCwCS9wsjyeYEquvJ/Bsw0hBANxa+i7cMDrB3REzcwe jZJMd4xWlwk/3M5DFtnXM2XgiEMnp05EzBOskrG2yazeEpiBemkE8MhsOVPERPFKsX72CVZP4t1U wQRWz+dTm/jK1BhvLaOsIaJ95lv37DwcS5d8m6OXE3bB5UI03o2ak6wPplZRM46VqILW9lXeyIZm jcC2DZCcPeo5WSBPPGAEPFiUXlgzIdpjkUe2L2h9rB0uMMoPs2q+92b58l3hoN7cm+yiSnL+C3af mfdzrHSbrDZAw73U13DJ+77QqMbq2dCkKVEqxrH+2DmrIiW/tR2w5+Agk1E5rEAlwMFz37SdZySk LC1XRtyIUo+wgT4CpJMLrnrutuDHqeBZnvu2d90C3zpgWZvyxlrRIlxSpwmKaziPIRnLGzAcWCue LzdmJAw0DgF2lwwKx+qvX+KlXft+iSLYAhu9ZZTfu4s8UYZzanJR6FH1/j6CGXRygEoE9uwu48Jf V3rWfXdnkpojrsVL9/T2govi7B0uOArmgPvy7U7r87tjDyJuauvYSzH8eQR0mvcBrbHwAhcOi3Pp Zo4nZHJXwo/MzB9mdmZzZ2IdlW+XPIfVhH7u/BszeelWZzeeBh8WQkUtd8to1DeUCzwPTaK8F1PW 5ygn6R7ve2ctQ+ZvnhRPgo8es7KVdzH0qIcg2ry+drEgnK7JC7AhxhCf+F6eJ4MgqGwFBkxqcm97 h22rOAVxHaGiHBWn8bhEeeNevFqyh8cmv8aKyuCSb6WIW0xmFdQjkCnFKbd9lVBWZxMTtD8HMAfN z5Ou2j9RLfwwI7wPrpuG64NF2vND5kI4JPLaJW4UJi/RhV/o1ixCncPP4QRWHCIVF8AyCxCTmRK+ 3oFdW7ptrjozZuG+dYIKRDbxxnfq8Nk5ctHSCl/QHkB3rjl73TJxKdNwie3Mwz16Ak59dvAahxv6 fttIOEEM8+F2kb7n4l1vzAsfsuH3LhCn2LS6z+PuQlJ/M0axE4RzsCkqvvzWrlH1sJB7bdr2MDL/ VHolbXHSiuuIU0boU/s9C5Z6PfNWMPtDeZUJJ2VdbDpw8ciutxKu5lODVkKOLkRZLYz3tZlEBEvR 9vU6uXzevMnYUk+NlTkfBoWD4nLtTDqNBq0Ispw3vdyCXRs5Rt48Sg2oooVquocrr0Uocv3purxQ hIpcvLWTyvBjVq68JaIwduZyeGX9FwpzMcn7T264S8BhuvVzbTjftEaVPKAwy6bFRfi5iNuPY9I1 NPKz08D91UUFCPMBnMVzWlnw6XOdKKPg56SxnmXG576ZoGueCijFyJSxYI0ZL3QzxnYGeb5Md459 FLaPBqy0nF96tLfF8s4AlgMBx/MiDAOKHQL6VQDZqaHBDepa10TxwSyxMlxPrzixwxSK1Z5ADonQ AwxJpzHaYaazgrY3cdhxmZHsMEu9hGjEJBALpBFjexQhygwBmP3YENdtZzjDueA66/ox3bXx8NJ1 8ZCgT0AWa2mG1j7ASObdfNFPpNa23MGt4PW+h5i9KbPOWfM00B8oamoZfvRtw1kyCQXJcQCX3ue0 1rPG7ZAK0szofe3A3cP0EvQdwHvnfORCSBksKPyL0I9NnZS6Ax/vs7yMie93M7d3D+fSO91dXuYm /aRI5BFIjZiTtFQrkRMVll7qflIZs56eOg65/Hrmay5fLPXzWZ4OYS7ASGNR2PDjPV4VQcrGGFrI /Z06oLQIe/j21fK2AeFFQyNJv20ig5ZbuZXVmTMbmCbTtX0hbxCxklNSU9yPEg+aqWarX/KCb1U8 tEg1Wu9E+nTUWfxI7Vaz/UUKDh+TAhcYWBlRVXuQukRy4hpTpHyaKGltz/BmIMhJHXpR1zetridn ntf+isHNfuKaM5M5Bha2Fp4gYOtyKF/o/VgvINVMn5r2ILVmmVYTmRTDSHvoyyvlerCQhvlwkx7x YL+w+kgaxj7HK/GCAYF3ppnuu941ZDB/lMDajpVVndkGqpYT0BCJJc7QeWnpD5gYq+1HXq1F1K4j NAx0Nve6+pfB6dbWfJY2jhgZxgbHqKg7xgui+sPgre+ivhNcz+RCEOGVgihTafJIvkraIaDTQN35 VL6NX8SrajgWGiEXIL4ul2HJKliU4hXC3zjMr3hmTstvkzuoAJMHOOXa8pxRiacSPb47+n1XU+i2 i11Eu0IxRhZiFR3RRsmtGm+Er/XdIRqoVz1zwZ+jUVGMpybZVzj2zB/Qgj9GhV6AFDIqqBTcC9/H EM9r29SdQy+JWYHI968gHXXKU6voUEWFXnXcYqsQBFT2K7gqICUitXnKSerooScaTTBz3kgGI3tt +3AFpdCz7LuzvRu53Za3lMQv3g1TlopV9MuYqYcCb35M1B4kliErEiejJiqmnSr2MxLhbv7kDp2Z I90uLE3EmlBtYgOIUbLLoVBQS7BgrTBN7GL58bUN2+c4q+uwRtMj/y4/U6m79ow6zEt5fXkr+sd0 TDxVk7XC1sr2ACzLZRmzd7LA2v8DE4Dsf9HUi38203J9hLepP/rhGmYqVBAbj874MH72F7/svDrA /Xzr5dVzfaurX3mx61K3sjIrOzurkrtVdECtbtnQ36pW7xMt/Iqr4DcvjtlKSmycPbW8hX/5smHj /Gjx3nWOgLMYu8whFz8qN1J7t8jlVy8rFf9MtczSmXvIM/snlEpCoVjtORzrWlVKy8BRopuP7hDz 3K9QHqDHA8h54f1ahDMiJRWzhMcvdeXnmoIrra5agSviz0RWMCwzJpMf7J3YnyPAGSo4cvO55sKo 3BzV2HdVRdNCUfcuroY7i4PveaJWuXUOB1GaZZkmIcSs2rGqxioum76WZIYukapb+m9P3MPmKg1p SrG5BhFxUmxyljoNhiV+LGDTkEzYkSUaJJ2PhwV0klULqOQFfG+q/bkDYx0GKWX0Prd2U0AZ5DBt 3xf5ZK72lZU978ztrR8ZuXSzYLSudrRwFDbyrE9SvyO+0NdqpQtqCH6PVZaX6uP21jb06Pur0xSH 7rYM49uuIX2n2b6qp/JYfNEuLs7MU2WbJPaVStjifwhUVgYQSkPnwAciYD85OG8L8oOnqAMdC4NV aAdH2I8G8DMBChGEFzwHB9o8xINWg1Kh1SExtGYkJbz+FUUcsUKjK7JxfVavwxxYVV2lCtUEG1qb w01taxq71/d0dDaNdzeOd6hm8dlLeZXjDcHxcCAgwiHkg7MKv4qsqBCfhfd14psXNvSCibw5U56O IOOdfiHd0d0QNudZ+fQskeZ3laNUPYGUbp7asaam19oU7OrUp3rTpeWmdfUbDzrct5Xlt021oZY2 Tt/BDY2VnQe9vQe7rGBLZ7y3NpSwveNWl/o6/i1SEivRBlyHuqA3WR7EH4D1TBz3kqIJeTwPe6Iu gNO9jIMlDgeYPEl9tk5g0RN/7Joe+6b/cbIQk/79yQ6YkslZPDkdWg1NsyMAlc5u4+AkpzudABf9 02Ot006z1QatBdxhp52k7XAleXL/z5h/pDmnve3IacbHWE+91NGuarmGX777JZ7Gxqbhlw7/9Gzv wmcTJ7c2bVpzCt/EhZ9iQbluITyAiU/37V4He/zzpztu/wvvZDTQk5N0p+a1I7WgIh3Wnupnthav rtbv2rJq0KRV/vgK09W9vf+bb45N49NXmNttiW3yvzqo/wCJvO1QkYgAixaoSarRlF+i8wR0hSs8 AS6tyMolXZcBKSWAtlTJeAo9TpaQP0xB1oCQ8EHlWAhtJcqFthTpCN+liqzK0gqOVnUFrriRgfDN VK1QaEGa/ZnF7kOOqkPe1F0ofRfP6ygmea+hZSeVjBoEEyICLLAcHNbyJquSRBmYcLsZUqTVICrR Pj2GMoTlAbuNkubnsyOQ9HQ6k+AmahK7HYggg3VSrsTwHL6AbdiOz4NM32J+zzR68QTOxio8wWxn 5mHfQfa1b0uzidevF5fTQ+vNZjNzT+0p3p9rK1YcswRVMmL+6cfZ1zFfMtufvCV2w5lRXta7Geuw eaC/wk2V7mYeHJ5kvv3AUf3r7mEP2Xq1zh5wbkLJKAg2QhQIiIMY0aDaIb8RYTIlVcyTpKcRwvQI TxKRCSM82Rkl2KcUoShVQgvSiKgyLaqYw4eQ0sLAOsEaId99d2JBl9DOGk4K8xNVANbCWI8Bw6VY r6W05Nb4Ns7p8zlGY+678W38tPgkcfDhx+SAmKbF5MDDV/nvPwwR88Shhb8RW97NZecQM/FtXE1+ 7BUxTChZKIPqaPm/k4gP/16CMgBJO+cQgUN+EUlF5NJIJifC588SgZnUiEQCvV8oiIhIUeYZOeJf I/woFUmwDL5biGUzoltisHxv+YWYisrTozIslrGfJ7fcX7YCFpYoPPPsd4JC/Ifvan9u4jqje3e1 Wr1sadFbsh6rlSzJki3LkgAZbMsvjG3M05lk2iZDyZTc6RA649kkZMLw/KHptCTjCZCWFLepiWma kgaMgw1tpyXIoZN/wAlJ2jQOtCWeSQYSwNZu+11JNjZQbH/Xd1f+wd853+Ocm8Wf0ieQKi/ySLAK ZogwBOIFniTK7bhVeJHeL+/N0wfkPdvITd7Dbbm9m2TIMsoUiigdSWUk+W2S6Zo9xm4nqZV5GYXc DMCJQIWhQ/bkbDzvqY4nWFetwRYIhlmrGIrEVLUgV3OVNYIVIxfW1Gj2ISp4nm6jAujRc2FPtKa2 jo0Q6WqKUYJUYZWQTTLEKsKMYQIJFLrbBkUNk5DnK7/0PC93kvWCQHYe8QWUFTRKybvxqHjhWLIb Ec9mQnyIE8MZe2qFKlR48c+/UvXgxjGkmWu9OjJ8jTtx7fVMqrDq5Gn6R/JNZnD2652XAoFLO+np 419GkcOl3H5X9t6iR0emrw3LfaiK/tOJ6xV3Up8OwQOF0gd/cVVJ3orH94VCRCkUEVI/Arw7qCiV pF7JOS2cRq+2+PxCMFSX1HoSRmdAVDlqaxIEIn1c68H6qAPr4xqiFo2I0vr9WmcgFIsn6tkawOjd WioqmdQiGRqGgENCTslYawowxvuhKqKzsA9gD5RFYnZBJN4FLZQJWR+Mm5XlOb4E3iLYJoboy+iP 2ea3kXqu9d+/G/mEO3F9qL5Vmf61XBg5p3yxgNq/oueODRyvVL45TXD7w8j0Z2/KmwC3C69/Zfpg vfxWNeM7mPr8NXkT/VgJNg1BTXcFULNDVUWpNLUKNEA7bP+pXGvcaDJX1sTTK3p6123YqFvLaauj 9alMdlVTc996gztsb1zdkmtr79AEhZUcdvNrsTkUCB8I9rcKOOg2MyaCagZRfG8v39FHre931KTS K1ZmG1etbm7JtW80ttaLQdD7kSin9bZKGakfCQGmXtJWrieA6/s6JLtX0vb3MXbidVUE4UWVSYzs AraLNvHMvGS7V6PPU4CqyehtsGeWUoGChAmLnTUD9CsAelSkBvyY3cymwyxjNyOeY+z2DBe6ly31 lsIB5dDY4HOHXimR1dgEZM1+KX+qfDT5/V2foRgjHh1wpvv8zM69//ztxwObw6+hwx7l90fOrkPo w969b+xi1fOcym+cQyt+vv/xgX7n0LXFjKL3b25ue378W/RU9dZYxI9O/eWTN+u6uwNo49NdG/qV 86+ix5Qe9NflypmnfnLQN34/7aUZqfs7e4myUF6qGrqkCdg+lmuOxbLgkzitWJ1oybVyjqCloZkR vA7M+QLtTPCAsBybmsJezAkmmCdZaziB/EKA0KfRunNkvDSjR3OWdiosNfm8CUnbIFnckrapnbHc w12RGPlqmZBsuVmy5DNC6hJTdS9b6P9SVe4jIIu9bwKpNxf2K4dGX3722dPnj6v6fthBqLkmf6x8 eHHb8/9AdRxQ40oBNUNfnBy+2nRQ/TmMpYZC48kzMJZuMIMofeTgEwOPeH55NYLcbuXGqOy/gS59 s6Vt99iNMhXK6tKUyoZ3fPCgKQWLsjifnDDBndBpMSqbcwcsPsy4sQtTEWxgDPsoSgy4wYK6JecE 3U5RpT1agshUMiZZWKIpHiQEeEPwG8tTArg9O3hF+G3lQ5C7KASsIYGYRAF84akXsrGgTsc7HI+j fX2pSn2l0EGfXpO+ned0PXcGNyGafs5iCGSVwfaoQfXj3e5wpKWy0pOOpa3prrldGU71nZ6eF9bV O+x1pQx0NsjAB1WzltqQq/Y3OztxMGppxEwzppKQRZCk0dbmcTb7W3whyemXnJ4JugOSmckW/3++ 2IZF1k13C4J/WF5WocFu41AIgbkFnQuJVYdLCXLEYKlFwrxZQMszS5I2OR3fQ3u21PF63tNGj3al 0KEdDAoq4dt59HYi/bTqZ71y9xPxSkOFkFVeytlsBoMp3N5c7/OqZXTBxqy6c6Yxbl8AxZUNZS2Z 7q3Vmu7C5u3Mmu96t/bZsnVJu6EiVpd1eRJzbzG76tVWVx2lJUiprpeViA42EtFRHuA9RJ3NpTTL RBartHoT48U+hKkAFu3Y5sLuZbjSjCmVze0T1ZXDFZTOwnmcjDYU8IJNWku5IewQLggBgqM7x2xG k6Rlz9OdFKI7zzJmqUI1TneeYyySYYrRMnA/S9moqaLBhSq6WdQnpVIyzcgz8LXgSEDGlHt0/rvU j0BNKCNYSTC8kOKJWiMHj8pv5wMNgCbro0fzqHPN3EV6tEF+h7lSmCi9hGaIEHFzK5nMJ5PM+8qF uYvsZaUD/XT2GHNFeaahYRI+KZ6lrbSA37ySc0PdDeViDuy0YKsWa6qwpwIbeGxSY5rFjMZgsjo9 amaYpnxuvaNKq7a3WgAXB2WF0wxBnngII4QJwgBRAaGlO3NavVqiOQlN6QlkGodmiiaQySXAZmbA 0snEE5ZXTREr0xKwSqJP4FmAJnQPMvOhuj53UWUohBbDsjTYy7Mr2cvJ2WOTRZzyi2GBSjqlPFP2 SHwZERG0YAzUYIr6KJcCyefBVfU4GYKuxBEB++O41oj1VAWodrMTq4ZdmDFgDarS+4OR2qRaqxmn 144xqYSvIgaJj9WzZikebSVohSEiECEIESII4YcQIDwQPoJaldEmUVa3RI/TXWMuiamQQF2vyelM kq4qTjG63zAlkUSgU0qSSF5Ak/T+TBHNeSVV+pOWJagSXFnRKvDgXjMCLyJy5dniyT0Ea/ad/NzF /KSqKV+YYLoOz22FY/Jh0Ocn2b/l8wD/q4fn6tjt+eI5WWKiRMNdJoodzrz3gAoVqcExO7aYsGGc Xj5mxHwVdsAtJ3qw24+h8RkdpnkLc1SNtW5Re5SmbDavXeSNHsk9TnfndC61TqKXVXol1zidPity egmNo94zgZfFCdRL0YmbUJNQmMX5mTUpxZFanKjT8EaeXvAmAGZCVpaUJWAmEE+ywprKMCmryCy+ v1f4Dz09j4ViJt2azB9+8sltC7dybcrbk/IPWIa8Ub5uUE5OHoHLV0niUf575X+MV3tMW9cdPude P3AJxCY2DkRJjI3BCQGDn7x9jQE7GPMyxjwMcQKYCyEJ0AvDPBLCmBrCmpgIpG5VWbpOUTeJRApN ZLp6mlgzsU3rVLWVskxKtgqmtlGkbfK2JoC3c65NmmX7Y9f3nHvOPef+4N7f4/s+jpL7BPEKDWgD 58AFMEYdqAAd593a7MwKT4eXHhiZOC9Ib6Ezs2lRpigIv0Mp0o94J8jjqSN0XeGAJ7eQ4dcxqbmj ugQzA5rEx5m0VH7aKvwWCyD4jdnGvl/SbuWS4gBiCYRol4Kb8nKNmDAYDXodxgo95hAyiUSMAQMR BwQteKKQZ0CNAWMJphPJStTQkkSMUQWtS7E8NaBnMd7odcgamvAQ/LALLPYgBMpAz6N1Ev81gzEZ W5Aiy8t5jhmTY8aS/fAh/CDbMlNdOuPI+/zBg8/hB5e/IohP3lr69HFkW+UcdNVMVyvVr3751ZBa WT1d0zTgVM1GIhfvKRdef30xxeXM3x9H8PlE3P58p6tOSDc70yTJMmczLbzw4MFi9cnBhjmLOLnm Ujnja3C5ftLgY8ov1SSLLXMNgyerPR0dnF+Xpis12gxFSYa3wt4y2p6R2ThXX1dvM6eYTClmGxrO NWbJ20db7BVe97E3OzpUnrYSdZlYpRKXqUvaPNvuYkN21iGd7lBWtqGYilZn/hfIz8dAMRgADBgF E2AKzMCLlKS+wjQ6MUUyI5P+oTPNHm8Xze2f/hlRBC6CdLiIFIYELlLCI3SqkM4R5dDAUWWmwqXv ow1mJMkElnB5mLGFB0qQQHuPsYYHKrBSe4UJm+y1jaQpPBAkqqm9/a7WjlM+7pnwSHgw3NePtyQM h4fCfXr6Yh9I5RwKEglUvADIZOcnLT1DTncQau64BkTgaj8arZhOh84GCTv1ykz5cKirrfZ8aCgI NyjRTF1zyDUT8FR7QpM0NRhyoU23ewIX34cbYBKuU9KuQKe1MzRiHwudCHht3pBfw+wpYLhBouq2 PzCySlSBPWx6ogzcRLmIGr6gSvdks4Ads/d3J2g9jON5I6ZfYupFvfl3tG1zE1XEMO7wDD+I7iE7 wuLiWKxvCDfUO7GAj5FplOksD0SBjYJUj6SmVholz9FI1mpQaKPQRNGKA56bhpWnGJMsA9qcwdWi WvDfTSFBTa/4H02rV0hfapgTEDzO45Xy4zefrbxbW3qhcHXWXHvMbbpbdliW03D2beOI3q1sucB5 /Gzlmk53jeu4ptU9k4+PT6Afe46NxQa48/u/9vv/MTb2T78fnTuppJdcK78dybplq30Xfnajgdj3 xu+SE1KuO7KqPZMH9kje6LXq5iPHsGX46bxuYez5gaz9x8QfPSIVExOIbICqf/2B9yWvDimkBESY TKCTSkpP5+byIW2KS6S5qdM5Jm5OkHDcVk0jZeWgpEl0fm6uJI5bxOyVjvKYOIGE0cft1a/CS0Ae q1VqlmexrlU/CUdrc1SWopqtxt7CkiVtH4I2pFkgdgX2BMQChuQT2Ic65LxklhUnpclE2ph3Y87l Lka2bSrIaP6aUbXz+7XZy2uRez0jjyeE1yJfDNxTH5YVf/f0ay7lO1ACi3y9RY+W3npk6uaEMixL kB95ulSpiKzvfDL7i7XLRDbsuzQSuZUdGV4+pam9OrvWAPsjPyjo3uEvPXq0RDw9WYJSHlShLsz5 JdCjUR1oAqfAWTAGPqKSLFabo6aJl9QKRuXTpI/2ooSqoUSj9WX9dKuScpJ1tKHiKJ0UJOqoxMRC WpM4LSW9o4ZWrjRI1FJyDaAs9c4mbmm77Vxnlb2GdBsPX+XVKY2MPvVqvMPqPhckau50Mu6y9mE0 ohJ7mfbGUiaHF693t3NzVqEMiKMcAkvLpGhXoI6pi1h2sEBhijENxIQLogQ3ug+lErsBOYXHfl8d ix1YSaIpm0RRXJCwTsKVPqpFY7m273keKTIyjfgxKY+faTBm8vjKZKk2IxPGTGDjxqijWckqfeE+ eVd//vjwYmKipM1S2S4VZ91wnZ1PFIo7bHUX1En1bd9b/yM0GQI7jivGvKxeYmVIfpI/VPHD1Uvz hd+Pz0sZPXhZRlbWJulE3h3P8vjYzZtj48t5gR7f/LzPN1/VbbN2d1tt3fA0ZX5nqsXVeFld1lIp Umm81wbMLV2jJU1ne3uv33J8O7L2p8iNgN54BbZGbvRmKQZh65uT1ittDRMf5v2IUU39fLN7anY6 8uHYzeXx8eXl8aj9eZ/V50Pmu1meCgDvPsuOEhBTPYAYqhsxghOgE7wKGaqqONttsdprOU7pEZqW 0YO5dJue1tH5tJs+RmvCbVq6Xh3OptsMhaYTndy2cE5zuL6RdubQ9U66hao47vB4eS3heiFNBOHf Vsh9dEIQ3qMkgr00KaXrB2mSnBKAdObMQabrzE8JE/oXuggTJRSWlqVr7S2ammZ1bYO7y4nA4G5O Q6g54CpDQyr+ZKDIEqL2JQgxnyWpxCSOiIFRM55ASxCuv1dZWBmwBqFlxV4TqEU3KIFXygiMhvaA Nwh/TAns+5k46gwk44Lw3J2qgN3VZV+F54BAHSVnbOxFqRu6CKNELsrXCgowlVNvFjzZUCOE2BDF UCF6Cv+MfmhfFCKiTyNutxkLZhYe8JhFCgw4MQ74DTBgvYaojSQNRzZERFCaxuex00z4AgagYOaR /y8GvFz7cU16AYB47c9+w9VbdU8/01m55Jaa87FoS2BScX+Vs2VRVJL5tnSldXu9UpE1Puk/758c m0QFehxd8AQNv2ZLPqr9OxINTRbRGm3P9r0eLXd9u5Rc205YON01NNTZv4DGby++1qT3Kru6yFsR XYU8zQI/tsjTtp15u4c29/mhzVPjA/4WfuTTaHwRTbdGAzB3RRE7TKwgJr+rqTyUGGkopKSQjBLS CUg9qWRKkhOED6n4BJCeqchKP5h1VYWZhEBxkAFiRnBfEYQpt2X3wS4N2HnyArR/oxcRO33pWxlf +P4Yk40xFQPRx18+2se53nf0aN+Wt+/oAue6WZ5WtuU1y+VznD1bYawnOxfgHN4QGUY9X26Gc2jV HBk2y5FaWcjLi/wFvSQn+o4oK3FOqkE+oCllJvg319Ue09Z1h++5DxvbGL99/QDb+G0wNn5cjDEP kwIGAwFDgARCAAPhAnk02SU0TUgISbN0eaAtpJrSNl069bVsapJ1EXRRtGpKNqmKtv3V/NGpzRRt 67akUlctUhPf7BzbJFHle8491/d3jn3O+c73+z63jPVWsWaWCRjsLKmUu1lGRi5KMbfU6pJznmrO CHX6QFypDHJWF4dpOZHVozSSorefurZ1n5a1cg1InudUuh9ZPEU0+v3ZApsiVJqbr832VKzYrBoF HVKEYZxGVYogSQWZX9V4KMITjXoejYAHDx+Ck8Ct1wVWajyP/+WJrgTfvxrAu4Ppxyf0OkIbuEle RKHfZTw14D7fpNdRZCBz2VNT48G7A49+8D64HgwSv8hc1unB86tBQP9GY6Vwv8WaJaNlSSyULUFe +d+vxWBJsAqScYnEKPm5GKNEhZ8SvwWtMBGawOxvlLfxZbFuFcx+JBKKHoj9D7JrgTI+3HOsAT1m z7o8Z8GQ9VLAY4TOYTjvN2ASIJgwnLhGHQqS/0bmFPwonf6umvjlfCrFcanU/KFkMtlEbeffBdf5 OyuPvqX+mCnu3sf1pLg5Xn8zmbyZhIrl2UxkkGsRdv3QeRW5PWXl3gqfv6D4LQxgaCYiUMzKrawW aK+DNCYGSYwEaciLGAojzVLUg3RAMm29JnRwKjOn/xhMYQQevgonvQabKkhk8iy0of+i8ykVKZsc DoYV2QyqCCkIlELzmY2wYAo5VpqtHc+1CZeDphwRivDdGq8bGKhDhb/Nd4GrIAhC4Arfxd8GJnCO n+X/Bj+z4NwP0wAbx9ueYGkA4FpBY8rP5frVDWQugyuwV74fGicAzsHuzw+w8dLKpRV45bSMIEO2 QkfSjPViW7ExbBqqmc/iHXqDsRgCMhhqSbS2JTemejdtHtw6PEqXdMhV6kgDFa0DirLGmVnBJLWT ZQmhSEnuZCVFzelxso6d1OoqmG1Ux1JUMhklSlbBwXgLhjGx0hKzGwOEsdhaFgwxjc0tiSJvmBIV yRUqtVanN0RiDc9+bFt6fHJm1qQc5YbHuLDTy7ndYfMarsWUObWCrpzVXbe7WXrx54scpQiYPtYD 0JaUupBPRdIf6QyX0yUUQn0TcbpUEYoGSNnA5KClUQNaXBQAI6CCgUBF2IyQNNQ7EbhhQgI5CdjW 0sj4wmGhwKGgPCXgyFr0zgUr6tqbdVMTC17Ga4cx9boe26HPP3iXbixnZj4BN6pwugpk/lsx2dBB 7I5NbdUVMF/g4PzZiHv5iK8NxA6aZT3WFSu/471NSsnmaGl9bTzlV4jsBn+HygUaef6DAXBH325X lMq9b4wIyw215hK5PWwyVfoLQxu739nuU+AaUPtZfT3oVgWEEn6t4VTM4KdvJI4es5a9apc0n+7p 00QkiTZFSi6mDFJ8l4dZ4x8TH+oqajxlZhGpUAYrGiI9bzOyJv6nQplaXaR3P3nyFDMJzCpMYNjv sHg2czz5B1kgaIKqOIUdxpaxt0AonkyXOKteSFGd9KD+qFwSDPenJwVnT2KCgp79Lx84XLB3wd+U GCKPsnQn65nbfZLd+Tq7V9kyPEXK2bNR1kaBBXbvzrO0h4IZxRyXEZj4QjiYDAweHk6NjZR8DGLY C3jPtSrO6RxJrz/Gm6qqJmamzgxd2G2sVVIFc/sJ9WtNhzlwnFPXcpYJbiTNjfX7W7jAAY7SD3HG Ge6M+DVOmuS8aspiPDMyBgIi7xqewqTr1J7T0OtCev2TA1beeebkyT1UZ7K3/Js8Ku/nTA/93CDP gLnuXaEXcmgQOhH0IP5ypvXZLULk2ypVXogTWg2tpQWAyFEpbGtpFSyMKq+rhYSqKotwCGU1jUJs aGQXndPaLqTyXS7UjdYg2BKu/Eh0Tpu7vvdM6I5MLU3bvLEil7PIUsiEfR4A9lirI/1lu/c0plwR 60QBMAsCPL/PEiopKSAoIXnwywbXmElLF5utRyxttZRYSJTv+fQKXlQpa/G7VMGQwSbwOnxWrVRD UFsnt2wefuixOQxGnSvo1+vXDMVO+O+cJodGc+nHodCLztDym5VlBl+FqIyGBkQvk6rBOws2Jvwh HwVbblW5PIv80ZbF8v6mZXwU3H3FZFKYCjUlRbzPkui8ABbnHFoNVDzHMjR7XqrTF763bDwlKtXE O+vimiLbaMAUiWh9vmr7WKtIPr3FasW3bN9sNnuiI/NGgxnUboArHBlMGPSWHOpXBTKI+gosgtVD Dh3H/hKP2qUyhVpjMJbanWW+YKQ6Wt8Qb062d3SmevuMFgGGE2R5S6JtaHQsXVixjRWIJAOEgFWp LKvg1fjGCqYLc5ZVwABhubuUiVQ3JAWVfYRIIjNaovXNvUNjhdKYois1Spo644YNZAfXyanaNTHO hA+kiT5OGvRVcu4NnMokdZPla3gvpkNgy+Nu3evdj+ZB93yBYPXfz7NnnjgRJiF2HAhwiP2YLNnZ FBEXAiSVrVXIBCJwqYBACNA3gixkAKzNOMi1YWfgENIIU4g21ULEmc6sRaS15KVvLt3lv2w7XtLk 7AgWbgrXdSh//88bx2pBq6WM+6uIfkOsFznA57Pn+Ht6qiEo0PHXK2sC32QOKZZv4KdH5uOZDN92 F+wFu3uTO4q9rpjZVGfurrp39yOT9Se6/edVarowbquP2cx/AO47F3f118W/Tgy3TYT5lxK38ObR r/i/Z07f9BPXP/nK36FI7zS3rOD1lnDjwvR/wJ9L9K1zrz9+ebp9Hr+Y/tMXhpfkantNd39iqECi FGo0qVHNz3La+WtyjbqPVcIcug87gp2CZiq1qc8RqyXsxr5NjLazp3dwaIewq3142wFi19yh0YPT 4yemJk5ub2aNS9JF9sTxsWkWtLMvznSwuw6yc/OKOXahi938LQOPEbGdPcmKjPZVwMZFXpY5ARZ2 kcwqFC4tIkAIC+yOigATa+ocHBreNjo2PjE1PbNj/sDS8eL/c16uwU1cZxg+RyutLMsXWbeVkGRJ u0iyLOvm1dWy7DW+IFuGgG0MGOwEcO0NNgbktbFx7IAz5jIT4gChE2bK0CG9QUuTSdNYhhQy7WQS epv86KQEaKYZkrYzSdqZhuRXvfSsLsYhaadlZEtH2j368ek57/d8tLF2/KnDR5+VNtbtaT9ebO3o 3DQtls/sK9WmEsc5eVfZDFea4tSNaVGAUdRx1gSnAzTnVZfKrWLvItRn8VFkFe6zfH4JiZcLwDxI SIK8wmyX8SBhyxeZe7NjXW5bbutybObYy+Ufgg1SAl6kQ0qRiCOBJbs9uwjRNAJReBMmhLxCbZbO duqAQ2jmXlE2pzRETiuJcCYBpQ6UEohPqXb5j0aRiKiWCgEo3EkTGRlwSNX5JYX6PS0+dmZwwq6k G1a7TouGRRVObejV0/oilyJwzlS9qPIa3TbnWKjDTM4wzCr6RkU/Wbwerj7/3c7a+M+dzcqI3evd SNXoDsXIetLhcdTR5qlyjWOuk/8l5T8TTDqK4/HddyWYznr2AjaW/INUrDLNb99hhefHw5hS+SRe JOsrVMqr7WaqZm1Hf0+XcVfojE36wVvaelvcMDo53ritc+fj5T0U894i2eePamfHjfVMzQbYUadQ iKphacmswryuzNRisjWFcbhu5KS3uFGjVJjNFC42KppgcaxaJjFoGbwRdfXL92+LF8XvI3e2SwYk 77wJBKOGL+F3xD9FdkiDXjCEqJ6BScZlJWMYZYlH6aZEo0+nf2LDxj6sf2i4c2/vOBzr3jyDTW2b RkRiW2WNaXiaoVruPcGub2abRpS72X1D7N4DxWPsVG2li7U0RFnbZFcvC9PwrddsbWy/JS0KMgYf 62f1bP1sP5ucZmVbWdnU3n3J9U02i4xKi7oYRiIAT9nsgUg01tDUnEhuQMrYvRmRv2toeGTv+IHJ gzNUqLi2bZ94KuWn45hbp6/EBjmN0kpiKU6RhtGFKTdnAiEODa7x16Y4uUa+KIoDU07so5mhNSuS eUYFvLM56l1a+gKNOAjspeyM94Dt/PPHH+XOBpFzg3yjz5wbZc5Hl2GXksugC6SHHbbs4GAL27SE QDmUkBmk7Q4o8E4J6ir0a4Qy2owimfgK4+iKQLiAf+4whAkB8AdLSk2H8Z/Mj+5xqsL1NurbokhE 7nbr9av5F7mxfSfgWSdUXXvhveC/aP7UryYn7xaWYP8wU6/z3UvnqiLdm7btLBMRPRtj1T2GgH60 qWVNuC6in6ZLC/VcD3/d3q51E4edztrY7s+oDvZUqd/fc1PrOrKj1yHaPF0tUStEwxJ5QdinMRYF HCZXaYE4FKyrltn14bb9h1NwTMYYTVCm4Bd6t/b1Dui1zzu2BtA05PKoENVz5Zo+oycWlIqbRn/c oFAQhMUKG4NyD9QpzRaRx2SIJaFAdI7etaBCejzrqVnOsTReCI6CivuF+ELOXx+6Itl23wPQ5+gU ACAS3BYfQ10+Cg6CW0zD+e2wS2WkevskQzSAElwqK6zy+EKRmnhdY3NLoo3dn+LGxg8aJgYZlt7A 2odYxQ5Wv4W1TLC0wq4XWwSZ9WEA3Y6FnFWeSKJNsg62HCSlKpYTS/oLZdqRwXFOktrfz2kPcrCT oyiyNy06xKi7OdLoW8c5RzitxEhCJx66UJzv7l7v0l+Qfn6cp/Cr2OXHVOFmxQqHXW7zsDcnnyj/ Hpjm8qJMeNFgD8xTsAHhCiFFjTxUL8rQhksdmXkqq59SjFKFAwKBRJk076iqFau8dorJp1PjI5vb y+XXXUF7JHJ5SO33d9kmIpG98unwBo9H8VSh1BJ19tfWdKpvpvccOdr5o0Wfy9dBvjJhr2VlZTNq rbaSOtldBOvNFvjYtDW4apXySOv7znK12vZOkTmxfcvOjQOX5gOBkf7n/jwB25PuivB2/i58sd0U CR/ie+EH69e/wpOQ+57H62vgy8m1SnVz81rF774coJ7s+PByRT0TPlneE1kbg39MWMtNg3wH/MTy jNtTzxeVwN9MmS0ahtdTcEeTljAx/MWjv392ZDNJCl7Qff82ziIvkAMCUMALYmDPgs5k0hlCvtVX 4SVQCQyiGFNoLZoFylm80oqn4dwC0E/oTBPl7qvwInAAGl5kiqOaeax0XqZzRMvFskWREmD5+ST/ a4Jsv1XkunRZNNNSJRZQpgDWzLNtxRqjlVaLihZGALsqmzfCT4tbV6yxx/lrSKvfhmvQ420+yl+D eniCH+X/ih6j8MTL8VbhUmsd8fn16/+8QicSdCDRCq/Sra00emNbuVP4pl3wBPoCPXyOT2W/QjTF X4cN7376KTyQEHas+H+4dgahEKD3VU+FMQ0vMcWkflaXrRmpw6/BOXRUbahaZuCCF1/3Z4uVhsmf Gfxmw1V4AOhgEpXsnlCie7kaPVSw/1KroFUDH7FGL2ETS+v+/8rAc7t2wbmvFeWbedJbLPoixJNQ GFlljiT8DZgCRlEMkHB4Aegm9JYJ8zcApXdEzf8RqHsZm1P8TzxRocyUQImslvAj1ioV1yKQPifq Evwv+GvJR6iaBrH0Lmz47ddpKhASvuAsqlwFcAEP8IMAmtpqQBycY9wGZ2WVT+xVgqISg8Pl8VfT AbmNCIaQYdTiOJSHa+ISyyxhm1UqCS86oEw5Ljd5fcJ9ITTh1ciDbmelK1Ybx6sweYkMuwIfAxAN AHLHfInHVMW53SXBRdEmIFt2haV7H60I5uzolXEHIh/K+WDWiMvUgCJBUGELhsLZPCYyPR4lslrI bAdKVI0WhlUqGoMElBASKLWhoMUcKmwYDvA37tzmb8CB6rYjO55ZDL456YzLSj17Ws78KXphy2yD SFXxZS2tgwkn/zeYLOBvwS06/mXa13bT+0Mxe+wUf/4O/2sYQh+fO7aqSDN44rzn+xaJzVF7xXfs ByWw3cq/AZv429Bm5m/hXgP/d+eH/JUyaOSnyyCX8Ujklt9BddcBN3LIp8ExcBZqGM8nGrgdTM4W 6CZnj5/Cp5+3rsIshopUdc2ab/2b8WqPbeo64+fcp+3kxr5+XT/id/xIQuLgxL6xMcl1eS68VpEG SNPwCIUUloUQewQYUprSlDAYaPUqrQ2I8FonDZCSzXNIG1WsYzTppm4qU6uVreqAjQpU1lX80dZ3 O+caSPfPNFs+5/icc4/O/X3f9/t+X0+GcdZ2L25Z/e3WtvUdm7s07c3TiCqjIITc2Qm6kZvrdgNU blq9vpqsmhw6/tKBPLEup2vudh6ndNhAS9sbkzt7GxPJJ1bTKw0AWm32msXswcHatpEfUa8cZVi3 x+vrYvfv6Xh2Z08v3alavzlD7eEskZZW6qDh6Jv7X3lzcGXn/jzRNrHnOMdNEUuAAQwSbeMHjxtQ ptUVUBMO627pbj2ylX7ObHNmVQwrFFWiEC+GFT8nDedqn2acgiHWg4EwGQg+jhmW0VKYo8OEaMZF TwTlXZHETezhBrPiBAGkAtEG/MUPIa/AlUxRYHqxqMSJWSH7R/UUilUzaayPRHGKppUBTtroESwT sbhEM8EA6TYGUu4Gg/EIR4ZcV0ZHr0gMxbVYF+qiFcs9C60VDCmI0nJRIJkfp86ovImVPLpAtcVS Oj/Q8XOzJrm+JJjbUuus8JKqI7tGMroGT/W2lfuePvD6DmuV3mafp7EIQktD//K1rU9WV8NQa2tl ZdsTeoPFoC/huBK/xUj66zmWqV/Ualna0D98/vxw/3dLLa3tXVGXqynapdaqol63qNLK7RVLqLIF C2x2oSpmMwtWC9/GMd44K5iW1eoaOzWG/gWrdvZJjZV+/aJFrQaz2WwyJCpNTkdyYSXx9KbtT9XW btpeXXXBKdi1Op1K5SmzWwCgkP/WMi6mGjgQc4ogCfZJgSqNVscHQ1XzVH633lLu9IqNSVXU3W2L dhvV0N9darSVknSe6JEMQJtIe9M1jelIWmCPOzWOYyBPxHOkmNbXCPpJ4oeYd5U0hHPTvfAtXD8U i41HlDBHBgKPTIfDnjXF6t28iRJ5xaQ8thzPY2rgGzxelsZm543sI1v6cdlw1fqtFdbpD2EUJv55 4faJWxHz7V/k/n7oe/LX7/2Wupq71Jpqsz/155G3Rgurstk/Mi+anYsX263HzsoPPohe/PrIoY5m uJK5UPgBMfWTKLHj44mb60rl+WtCpcFQZHVPZvl8yaighajWxwyhfB1C2akZZKUQzYXIgDNs1dor o2RTYsiYLNcONVFEYIjl3XWkdchpbHKyFJmHI1IQgpokr3FX1oSjtE8kKTpEEeV2cAxaxQGhjtOk fVDwkfwk8QwgwjcfgaR0jyMvHlaU7hyGmHD5x1J4fp3HR4qC8DCAWMoTEQngQSEjGrxIwiIUxYcS FsbwKCjisCiC6YaMzw1ntk6a1+je+CD7dokVsnD4i/x7hY/k6WMb2tWRX18qm/pNZpmfe/2F0b/C 3xtLevvfqtLsKivX9u2Cl2FihVvO0G9cvbpv+MiOQPz5331f/pv8YSiUhN0nerLxXCq0btfBwokS urGhSUi+XSuyWp6PRCCkAcToMr30NWAFLZIakJTBLDAszBOdE1bVv+jLsBuw8Oy43qrPw27JaAIA EghChjUYTWbBUsadtmJQQDMudG/eDN8uFqLBesEP66GIEwsGhPEFoQ/6WR/UdfU+RzTJ97Pw7Oa2 pdKyZdLSDZ1yRxbqClee6yVu/uWUnsgW9kKzyWIrt5jMRGGAyOpP4aoJ1DAb0U15FDdrJb54DZWm pJQr0+rK9OrLsAVYiI2SCfJ6fEm0qEaraJHX0tw0XA5MwERsBDQa2cP3Hii8CcL19Q/uFS/Nkh5D 0E/SBgNqWIOHJCNFo2EzkcOFhJw7V4CxRhg7dx7G4jBWOCfnEoWJQmFioiBD+D5cAp3X++CSPuiU P+mTp/quy5/IU5DF6/gHinhTh5S3MP4SDKoR+pPEClCKPAp5GLqE2axApuTnBhFxMvFq3b4DFWfk G7Mz8o0zFQf20dfe/fxoKJd7R/4Yut/J5UJHPy+eS19H56bA+9JelSWUKNpJgQADxOuLFrPZyx1O l9dX4Q8guqmeV1NbVB1ICTQmkN5oapYS7kEAlBU0LapjcV/F/KZmOuENLCRTgCB16ADGzioHo1PN apUpWFUXoRID8TxcI6lTWl6wUeyACv/TAHqAGoAD9oFYHm4fTw2ASbgdmLAQvIc+iKOEuNL8V6r7 RnWJUx6KrygbFHma9+E+KAp+f7GP1qNJpTeJAsv7eaUX2CBNF3uTD03iniyf9d+XZ1fM+Gdm/J/B mDzzGR7NrIBRNGjBc9GWmQCaQrvQHB7Ntsiz9/2zd9LSYfjshHz304yUSacOj4+PSOmMlL4j352A 20ZSmTt3MqkR+dUJaERbM2lpZHz8cArtyHwKjRPya4fRVmz7LAxQz1OzoALFmgZo9IKDttKsexqe BV5ghSeRg+JgM3m1eWKzVEJyQMNp0S7WPUlsArRCToqsK2Z9DBN2W0zNmJNFnORRUhewkBOw37Is 0nV4mXhRO7q1v1fLvjBm9708Jux2Wn56aIeoY+suJp2OsUud2zouEkHT3Sl4zRsY7dmw97WXA67r Y8TzT1aWj06fxncHX9H/ZtzACPy/0kIK3YtGaWdLjgUUq6fgJLEWcAoTKByJriUwgEQUF0BiMqAw oKAH9Ee+PxW+ONzS4eHmlSe3S99pX9Xp+hmhZ9yRscIW+UZEcoV3po4Mm3f/YSl0EDZAKvyUQX5N AhbMA7slTiAdKr3N5ac9nDaU4hB2VUCL2hLgQQg6EM4nUdIg4UnJTJdUOUh6kAImFac3CeihkBqC KRhHGyCMj7OnqXDhng4TeZHf52oVvuiDCF+/h/eQvIf/v3CGKerUV5uy9LWC+RuAZ08/BlwVvph0 OccuPoMAz1KnvnyXvvZl4/9CnlAQ+AdjRfWGG2yVtAJDE+pSLXodxulSOS6j13XCk+PEoAsPaaRU OQhoBqAtNgftduXRi0LSjTtwGpFNF4D/4bpagJs4zvDunaSTTg9LOj0sy8GSTraEDTKxJMsyrpEf NSAMOIYGG1JKsIshhUmAGOymMbGSEsCxTaiBFvNITRI3gHnYZjAESjPFPApmMi1jWtpJaBrako4L aXlNUl367+lkmMxqH3e7e9p/99v/+/7csfhYWC/xFxgOj2PjRAd3DSzODwENMArEfOsIcUhucCoa vyqQ/6yi2B2Y1vVzYXvN4/NcVLk44xhuLP/6N7J35BdzXX5PaHtP/P7JvIhjyo8i7RvNa+Fgs/FL JfjrJShhm3wOnC6JPRsiLKdTsHozrY2ph6hlJ1hrDOtjSjyEV/brYixUEaMS6TpZDdJ3KrlOuZk2 dMrPUPWIoX6IlFCzufeEzxPaRyzRNHAz5EEvkHjTGNYXATLhMJNJ7jQ7DX6DM+g08FQBbsNtQiNJ +N+Q24bJ47CsGG8R1gmN8dnUAG6rGyY19Eirnw2r16E01BxJodNi2KyNGWSKVFof0w3hS/1KNXcW sMkC3JYjA7SUwKI6FiE2heY61YZOrdwyRAWOM5QslTadpQLgAGYhFYYdgVoreklR7BMjiEMU7YGz S74Ni/ZYzX4rscfzbZMUsOCHS4VeobFO6MWnIdeex7VC73nZi7h26cM6sGpDHdUqmtVCxYbxQjBJ tCsd7GJAc/EQ2wbQ7ohVqwfCmARModJlIwUDt8nhVNqyTwPociCr4cJpVLTMaH6Kd/tyVSqCRhYb Ilm612xAGtABTJOnMqUq1ekwJDtHaVMhhVbvzPJMCqgcp+FWpkG2AU5Np1IJXDNOqSSaeMwMaFpc ZAx4Kb2BDcgP8RCYWDP5oN+YCUwg4/xmngKyMLg53mINQqAC9OYJKhg/XNuQHwBtpnPbfTXVnMst 2Lq7S7EBBEjZrl1lIEyEO4drcra6eY7j3Z2Tav7g4qpr3M0TqDZfh5s3VteJI7vLhf90CXfLBA2+ V4b17bm11Ua+kgz1tRvgq6vK2AUiK1+WfSqLwz5WRVLkSkzLlawmxZCaxursp6lFoEfmIxO1KKLX 4TSx08BZoNPEnMFTkRZ/jnRQm8guEB8Fzj/ZAqvNMtrN+eGQM41yszPo5mQ0b/Ab5VRmUFYqXHbh 2iaef0U44MLBuBIHXULvere7Cde4hMuyON8k9CY6Arzwqya3ex1e6BZGqEdk4sL1PHgbgoIjgAIK EKEEv28FlDsAD6sjLkqrphlWb3kKIMAr0ziZ0WaXKWMqpDNnyPiY9qZ6CL8U8apucuN6EYSIqEMk GWJL6BCH08W7QHojpE7IyHsPEoC3ho1JjwSm+j2Y8Ts9DMOBRANhRrQZtoYwb4Vn2kl7Qjz1u4v1 eE3dhbi9rv7g6CiWsvA9qG/V1QsdF+v34PCe3cL53eG6C7Jn++Ithw4dqsNrSBI6EgmvoWJ90NOH 9TgF64W7dX2Sl1KsgJ3ggF7KIh6TFWlMEA4SE1gtF5NpYyyQDNJoRdvE99pU/RCe0Z/aw4CzNYi4 lYgGji4TlD/vQAY9cuZZPYkG7Q9Z/YzVw4TkVfWO7e8LI8JcPIBDt649Eu4Lm/A6rLBfLyu9fri0 73DpjpKUCnwMBHYQH9meJ2wWHgiPhDep0StXWkZaWkakqEnkTSOaAASZjxYMer1ametDfADpkQzX HPexywP6wGnwS+nglyzgl1gfysjUZmTST9vAJ53gmJdzuJyep3OJnxHFMgCQOCCJJg3hBM9bgBPz g2CCA9H5JAKSm8QQMiC2k/oZxmSKYwyJkW9jZrh92wWhQfi78KmwwWA52tV+Dp8r9E4sLJw4MRyf HZ5IWt5C+s/CXNgMsh3EYj8+Rt1N7fz1yE5swduEDcLVA0fPdouTxvNU75PDhbnifnxzQ9EiH0Mh 9F00F81D5yK2iumzKp+pnsdUzeQMCKvUGnu6Y0oBW15cwoLv8qJyKF1oJpRzwHfvHTTN2WiRDeG9 A0GLq+oUXgm8+26/z+sjxBQIFlYWlhTNcuTkpTM2rNZwporpjA5NqXqmWsZszVPZ59G2Jl1BTlNR SVOmLq+IzuwRpRLZSSmuHA824SdmuO9iWBVOjEqIEwKiZNTJhYyIbH4A3J9HCjA9UhBKglEpIBWP IxiAzsQDguiKMZv8UniDQ0TVWKGDA6HcV5CNDQOLW7fOaqj4Z8X0FS+XL2nY9EFqxk+bWXPupddf f7ft+eqZxc+19rXfEvroL4J49Q9a1i56NT6Y9/3Yj2u3bNz88c4VK5ZTR/XCl0L/m0sHti3Pfb98 19Sp097zHev4Tu5TG6h7o6N/+uYn26KbI33vvLEf78UD9obGaYPHNsb2482Zzc1rO/D+F5atApIc R/ECtBK1oh3oIDqBrqC/ogdYjb+IWCa5vRMWPrd4Z/e+93o/OHjh0uWHj776n3ASy7AyMtmUNlTT v/Rqq/6VVzfE3ti4qWPbjo9/f+2zv/3jX1/+977pEFuF5lOa8oronC13lCAu9p5QpLp8efkF+0uM GIHHSyPKCi2FUo8O4RVoPuqH0otM8OYFYDuHzlJYFCldUr985aoXV69tXN988szZj347PDL6xxt/ +eTmhA/hm/36Cd5TVANaRpoK/RDVEHHMR6WFM4ZOnvkI1jtyFZZ04xNYEKzbVPnosyO3bp/CFFZg NpItH6s+GHurBgwkf7G6EexoBTvAVNNxmc5ipDSp6Q7XkmYlgDIcUSt9UwIF5XOGR5WVJSpg0hmo EHTEEbjaF9FxbIlYjMidlT2pagtsxM7uPft+uR+24s7DEhNGZMNQKvoFzKpGb0E5hqqh7ELPQrlV fD6CLYPFM4pvj8F/DXYpu24bJWwSZzAmaiyC5rgI0iSaE4AOJyujJDiTE63h5MzkFGP48ZSwJMGJ Bs/yAHJ5VzBABLdHIbUCIakFcM8PZUkti1VqEbluzpdaCkZqgXRXMNLX6CwPSWJf8r5YRZ2fzBZr fogkUMMkid8OJTP35APpJImTbhVxeiHrkx8mf0SSNDA/9MQfMWRJ4xmMIQujpT8XrU920o3X98mj 0elq01bWnh2N5qR1mzUV0ai855ovOnPytR6x09ydlhONZtvZt03qGdC57/rkmdF6r7xUmWspMps0 Znu6zWZPhwY2abl0OyEtk8ZkLrJOVpYqvM9b/091lUBFdZ3he9+btwzD7PNmYYZhBhiGdUYYxpEt DJK6QJpKktOmqIn7AioKEgnao6G4RGMGzcSKCMhiPMGoFFxAVBLwkFBMPDbLscVoImRperCnPba1 lXn23veAYzln7nv897377v/f//++73cx+VR8cQmt5ziOgrQe/VElxfF0PuPS/zwhQ0DnryRcuA69 a7KYdXIdl8O52bmUg4yn57IpBvQVtLDFYMYLvy4VVqBLi+OpfNYVxeL16fjiUsEcCDvEyeYLu3QV FKSMdEz7Z0ouKEg2hdXphNmOkZSCAteU99yhMOxhEnFF75LmMc7iEorDW31z5kNoFy79cnRhRJd1 FovRFGnGLq+Y2TcXzumz9W7sLP+3af7oZMW1SoqdTJ7UdUqqd+GgTO12FYneNkcaTRYxYujtuTTc SyLP8Jf0nFwnBBetjRUgX8kGqQcgAfz6UrjVGk7rjDH9RBagEYqoEZbcBWpivV8KZDrOKrGFS7Hw VUTa+lHRmYl1IAFdAboqkPJ7KAh+LCbcuG4mRI7AHOxVEU5CSDlDjEi8QOvB1IBzJkbMR5Im1Jzk V+UvdN9csnXTkQ03jj2CS1JMcXDlf46NlP5uU/krn5x5uQo1CtBC9NyBd1ve6Lh4/XTnX0OrQp+h 1U/92PnB0PX22lY+fyzk4v+4FOsifikzgNA5AXjBfL+akxoZK5hVp2Rq2MQ6VintQZ7JY60gxVPn TKmz252GXsIMkCJC28ZEloE9yRB5LQOTGtZ6cbjdjEFSPk0rSgufT+NBeh6VCI1qTMPpsH7wpmtg GhoBYjNkIaNWVBdkbXzTvHCwqaioM/D274uKmgYWRuzfmFVQvaKjl9/9BDwBfG0vHByGVn58ZIQf g1aSdVbtLhks4x8cfKus7K2DUFM2WLK7yvkK/6dOHmmuKr4TOifnQ9PQMIzgvx8e4n/AXj9pZMLo WMCBKNDsV0qizApJJEPqI5QSIwjPC0OHKwO0MDLEIiBFB5zVpdHAq8gEkEEHIoms81LpLp26R5y5 MjVjJLIu6UC4RkkDfZ4MnTwptEQa1NkqiSJAQqRkhI5INaERkXTi4UQ2ws+Qe0Il3j3MRpPqmdbI gPoeNep+JHabg6MZtd7AxdptPoxGaow8Zz7rvPYhfA7eh2PwuQ/7O2/ye/hCvrB+Z2PjzvKOjvKV 232c5LHGt2PJkh0+zWOK821fuVGhkPzIsqLGZOXUsKAxU0EOKPcb9N4oW6xXEi0DkNJLEklLjSyr JpHsE7I9GrFm5CxZ4qxdakCZtLFpc9iA1hlIs5kCipQ5AW2aopcoAWJO4FR3Y5U57WnGlOx0z7iH U9+HXfPFTalNITegIDZFDIbYXUY/rYHS8fRTivQMvAW7oKVry5Z7x4/dCZ3kM/htZOTJiooTLRVb 24i3eTf/PD/eXY6mG0aJxfBjuH/y/nsVFc14+uOWLwoyz73WcPdOw7/5HiJ7S1tzRWV7G1HU8mVh RqdgfwQXhAbLW7G9XawXepR+FnhALtjgD/eAVF+NEdhyaqypfSgFCCAnsrodVqOjhyg9T3hAPNWH jt8FwhAmxNtUmOXDo7m6zPRAdKYrXgJ6iZXAjGlTCMt0uIT4ibHKyJ0Q+BOK3mt9M9RkMMzERKAm FBoEGsjEMIQQG9/TYaRHzzTv77uyrGz0/Pu3VjiX/9DYOvZNw5xnN8Ck+49gctrSn/WsXbR+73+P NlZsbm6q2NzETzZf2tMNAzcm3rkyPnLy6I2i4Vfr74+3NX7H3Wy+CbX813+vOvvJEb688pdl24ik 11paKypbWoVei6+kR6gxkAYywVF/JGo+XchMsWEyuVLL6c2OxGRXqmdOpk5li8HlEx2twjBjtKK5 SOscerYnUemMTg1zQZXW5pA4UdAuRI945LIUdNftYmmIY0qA2chuJFwe0thLaAA1I8UzxJ8oX6Z+ AuLiCYS9ue5cFE91jDrd6cEc7hMHTo1HtY5A5B6Did6LBQl6iCbRsyonDWdrBJkO+4LVx1+MKlx5 aFWEpyZQlZ1f3XT1qmbv2dzUA8PXXlf6Gwvfzasnk2reeH7TfPLE5DKJ597F8u7eDeZdX5yoN5/6 A/99x7KUf/L/+Irf11pzclHtL2w7nQuWLSdr72x+n/908rfkKNSWdj3eVQvdHV2n9o0J/WuQHkc4 TSLEKrkg0XB6CSP0ODQwo1EOoHAvJyhERDpSRaO6DruMwmSFWV2URiVgkRFmAQ6uRotQeESpJ9CQ wEoPJ6baFjDdpmDw8XntHOTsXvtMdjF29O9MDp6hfZPPhA7A3ipoGhiApirYEzrQMrB7z0fBYJCY tz+4vf4a1PAPrtVvD+5fd662v7/2nMCoy5k91HcgGbxzAQAyDkT0wUZgQRts9Kv1gKRZqUweHRuX kBSuMOkvo8JSEBv9Mks0am0T2Dhakow5Fiii0OXiTjVUy6QOdHvJHwfi1CQZcRnORWvN7VpmMvUS GwDpDrkjJiYw3kTg1FgqZMK0RMUxwGmhGleNC6lhR4f9/4mhQ2LP4/EaGC8ut6dSglTDxN80v2Sd ty6wyuzbcXibLsYfXPzTT/sGOvPeywvmNS+Q2CB7Ylfb2crIytHGI5GtX0+uPbQ2Lj/4+Y26G9+Q O75d0c9/O1lDjkN5aTf/r8nlODpPRumPUJ+rApl+1NUSpISiGWmYLFyuUCoRhOz2a1ggWlnRqlJC XAJSfGhAPDmoZUgIGQidEPogdPjoxWsOF4ZWw8z1/BDvWQM/5YfWwUzieGjCQO0NOQ2ENrRKMPHe NXBEeIxoKDws1PNt1oT0Tzp4Bmzyq4CcMQGDPdFL5fhqokAOKuFu0ywlg/GPBXGIGKNMLIn2ecCv cDiUKoPdkTjLy2bK03Ehg8w6C7BgksAiQqhXFHs3mMJAXLi5IbFrEGRROjElJQx6rQYdhlYQ3hqB KTD9EbQwO1uLRAdJOGkCib4Z1COMq5NyaixlDdnzM1+6PrjQbZZTGnNg8uiXtxs+b9rywdCe3GuB srQok8ORurOHON3SXhY8uPrP8GJ6HaF4YWt19WH+NKz6S1wbf/nCq/GtL0L1rXdP3Gvnb7dvPwbn vVz5P7qrBaipKw2fc+9NbgjkRQI3QkLIg1wkhERCXhAgRh4C8lowyLiDpYgNSAVr8EmtMl22llF0 LajbbR0fOxa3uitajYi2axe7VtZ3fWy37bayW+0OM53Vda2V656bG6jjzCb/uTn35OTcP+f83/d/ /ycwESpb+hl4vqp/6NfBl7aFkbqOvM0rR5BMBFVe1dT5CdgDRCcli1XExVNKJNYT5CGs0qsWPTtB FJ4hn5qhYMUWeOZUnVDOvtHRcu9n7w5hprXw8Gp4eGjFKqZqNVO7hqma8+xYJRpbzVR9DduZcagK twZbpBNueNP//QpwccnbhuJSDYJehSw6RpBACLrF3SRQUDjZHRUVE8LEXhEROyMBiZQYnE9EkyFs 2ZBComZ5mxJHAZaQ+Niyo/Hx1IyT8CmIDh/4ZISyJ2TTVSP6v+NujtA5ncRGNGJmPZAhMsKgDci1 seiKIzaSQr0Rs2M9g317YBEzCnMUzMVdUJkKM1OhchdzUQFz0GjRnr5BbOwE07IPLoC72mETrGSu M2thD0xnjjDvtDMvMe/tgztOIHI8+jRDsIMYAHrET7ngF14JNNjx5Gw9ARLSuoUi6zCiWim28JjO bMOT2aiPA9lYznECEHFCPDGEtXslaLsSdHozXymyG5w20SksC9DACX3HyURln5pWn8TmR+Kfg8BP OQqlpzD3PuCyVWxEBfLkfILlHmm4InCwCZ/iwpx2RpCAQ4eBi/oUmmVnEuNxGgnIecTa95nF5879 F/72x7a2vFe9/t83jDXkZOf10F/2lC9+78fBOxCf7Xv9PDFL1VVpavW+zUTDK/ufwHccV7ElY9+M n4ASONrZ6fPN0Vfk5ubRXYXF669ST45hjbJP362qYq4UiN2zZjEXVIqoDfvhMog2gABvMB9GPUbx 4gSzQSmoBnu8cZqkXAooaIvVV1ElKBHEprgKePNYZUmBEizHG4Xl9ojSuilMFMI6vJTdqtGak1Is ZYRKCmIVLl8FP7tA4A1hWceFqq3aKlp6BgVUNihCdM8DZsQumcJsLZ55EiuYkgNTgiDM95zmjHB+ pGhhp3F0g3Y5JSKnUN7PMrAbLeWhFGDQsno7stOEVo8hWfzT1gOtzgANUwlRbsQJGbvpUI9EK2Ug +J8/GLn/1Q9WSB5YvpUpT6pZDhWQgLmQrq9v2bqICTL/nvcb5uVB+O6l4fHde3Ywjcz1W0w9swQa Skr8wftjbzF3Px7owqlO5s3dDS2wtDL4xfv777eta9379JdLUdmz4Mjor3TajsWmzRUrBx8y2384 ffnG4b1zdhSfnWT2XiWIrn/5/VtaWp/MnYR7upnHA2ex88yh3uOIqUrxF/AHfBMqb+Rg7hGeJAQX DHkJcQhbflS4AUazvA6EgIekQx0qXHwIuX50L0Z3InQntUxMeh6iBiyeSU+C9IknYdKDUBqnI20y rSzLkTLdwx/skh1kOoeZoZ2x7CfftO4csxIm3rogmuqA5/wpHwHRCFlCRJ85Q14hQE4NbRATrIsS nojN7zJYNyQWCkeQU6xzJKw7QrCuTDxkL5xTyCd0yLOscnumU49cUfB5071S5BPsHYYVu6SDsPcU /sK6UdjLjN8ci5nqABRUh0Ayv5P3O1ADRsA98B8wCV/1Lg2MfGc1muxa186u17b3E2uuAXFxU/OS wIHBg6GR02c+/OiPZz/+0+i5T/58/tMLY3+5dOuvn//tiy+/+vvX39wZ/8c/v7177zvr9x8E8E0B 05qAa2dAs37g4uUrVz+7cfO28Pvua1sCrweM9YHqay6NiTAOwwB4jLbgIf4wBAPeLdXf3p2431Tc YWtesv61Gzdv3X5u7Qnlxs+e3KsFodNnCP/VkeHt/QMHn/Pn4qXLV+4rH207INbvPhSM2R2MfzuY OKjdFtQ3BjuCJfklwc5gTpd9Y9DmDw7XBkeebH20PyhbGizIsRX0Xw9ei0mM1z8aHiGv9css4whj k+M/1XUc0FhGR8Q9hbxwSTMFPYQ1dHFHcGhBL5bq0SIcWsN4jKw0+QxgWTnAFospfJbqaCMyhNFw 1egMY5Nme5E6aIodnU6uoiTDfBlPktNVE8mOkqhSYgGPczSJZnNLGRGuOXzT08uHCZVP0pyuCP+O piN1WDxFsmP88NLhh7C6keJzT+N42hleiaQjRiNzUpw5bZSTIjmjSGQ0MpKkM6dVdrxTZ8+yZcYp 8M0qv/vFAqk2R124oMBfl660YBh0uwoycgUdc3WpOouUMqpoY8kKXnymqtJu52EYHWuvqXW/lVSq ktnbM/3RvHllZTZFWnVyR/XG+ZJtjaUltNIKMZhidKjzdS5f6uYqF6XXZqiVDk1KYnYpOTc/9c22 XDoVx6CDSllQN3+D5A+rO7Q1JrmlPK1MKyGT4s3YHGOmgzI5eY5F0iat1iw2q6IyBTqzxJysbxb9 3MF3mCi7a+YcmBGX5/fn5fnn53o8nq1OV+sMm4gvaS3wlsYuqnA71dmaaEWKKKbQ7dYkSwrbJDFy qUjWVqgwSMQeT02amq81Kzz5pS9Shb4+WiC3JTW4YJ1J+8amyqTZcjJhmadCasnILyoyZ6jcedEx umhRdmoqRS0tTtrXkjVPLJLHx4ir8lQZxa2qO+YMn0EkdntV6VZHebxVY7HVzm2fIZAXJJXl5BTV 6lP77UJXubpebjJgGZLUDMqq09jjLM3NljiHRpeuzJgpnYXpTAp/Ull2lI/9V1xDCRJlv0PAzl/J +whpCBcoAANQ6S1sWrUGb5TJFXFI3KkElC2s+JK1Or1BmI8EYIqRru4VuGvwTYj1CF7qzDRTemF/ jLkYicLYRHWSRpDfbds0DFtADWw51ujuNr88gq0Ar8BRQMHRDwJmWyMeCGGveH9WjOGVCxu6Nm7m TclK6aqujb2bJT0OAFlxmV4o8PjUmvCzU4ypldULG5okfiQ5VUk0emyUr8+KVClfgrSoIsrT5+gJ YYuPdjqsnafgUtCM1QO/BQkUVDJxcKU4PHPNEnmFxYx0ciIMZi7PsjO4KzX1gTIG5UQgoJE5kdEk Z7QegYDijKSQOTnT/Y/xsg9q4szj+PPshoSEhCwJIUEIJCQQIJBAyCYEAiwJ7/iCioIvwIByhbH4 ihVQK4QWa28UCtFz7jpe6/Xun1ZQQBv1qu3djeLVzs2c59Sb6j9Xrp2b0evMnUNHz6z3PLtJRGu1 2WT32Wc3O/v9fZ7fG+/f2IkXe4iSCIcF5Gd8Fg/FBew5zw8K/OFJUEBPWBQWyHGVBXqzCmm1GS3f jbJOgw4t57RomzgZLW+9fhPV5ohymtUOW4aXyE0oW8PBZ1L4j87wfotFnlqlO3xtqaVxu1WTTZIn O3cxTYxRl2hfosrS5us8rZW9nd61hIDIUdq6l9tWXdmnbUyTOTZMERV2cVF9ytp4cxqRT2VZNDlp qQ5+5dGpaXlqS6bcQhjNynXaZYUSb2TlpaampqSgHTvGBhuTXYrotL0jjdLWqkJ7kiVLnLZE+Vvf q2u9G2Klakoa/7Pqhs1vbKyVSzVyyp6fUOis7aAah3enRMcXqdfjbAyA6JygFHhAPfg1o/SkZ9TC EpGzkLTJKS+pyWFsAfjBuZIcX0rGiCZA9M7AEaMC1QyzKSVGMj0A9zGUDGR4vSJVvdNKZxRl1apQ 4cbIJHKKIa2j9YV0X1EWmpktqpeQEDeE+nAPyC8qvvgNpQlQhq+h/MCnmMgawl++6BAJUVQPYXRG OkA0jepmQNtBQYFKyAf6SLGG4ja/mNQKPXTg6O8UxInOLfcq0+saj/zq+rGvDjqa928afbXBdyxr iJ09/A/2r3DZgvL3NxcufAxzO72la0Tu+JFXKrdl74Z/DN6dOJQTa61kaUFp6Zn8jhX6uKN7Bqcu Z28b2lDT/oZhx8+h4vpXMKtUdnPqk4d3x5bubK1MSFGWF/e/W1MD6eDllb4u3Q6Hhm14/Dhi/WrQ FA0A+BQwYBETXE8fZ+RyykOaRQ4nqcmvSS/LRzxm3WafVnOR6EX/UeCCWpY+YoQjWrcMA4kFwGjM dDnsFo+oriaCo4y0jNY57X2uTDRzViepc5E6zIN34MVAXCGLYxyofsZA+LzvUjzx5wIa+5iDy83Y 6UQhF8WuZ9TbACqZDQbawfMRcBcWtTEZJkIPhdgFRca4umUVHIp3v+BQvN7Bo4A66PoaWtiZ75Wf YBTsjc0VpY1CjKJim3k36yZU/rcwCvh56Zm8jgY9dQyB+DRrm299Tfuw8X/sd9dvs7c4Dg/uji7d 1VapSlUw7j7Egf2cKF85/IpuJ62Gs09xWLeIQyGavYZmGXT9JCPX5ma6nJra8gSxNwaUiXE/I0P9 DD3tStfgKtrg9RkuoihdBjLhiWmbVhmAJ2bLZC7ShqkoSABiEtKd5cIqKtdMjQm15kuoX7SCJCgG OtTcuGbcQqv7PNQBHS6pQk2N9R5vc94zOE7oAlc78fVSmBVyDxEwhOKmOgJD6eTNr8ZXEBd1uJzh b4SocgnFWRwXw/4kBB524Z+jc1tqe6rNqUyLJbcjWPP9pavsA/rDP8N+CM7PFdwZtFjln7W1fgm1 tt6N1z7q/aWvtdNR7abter0drqlgvztzYOmO4/KqvGwzJOv6//Z+W9lgz0ePavJvZJiUuiSfx8P+ 3d7n+ezIlnX7DiabTFotIhG2eTXYEA2fS+IDRALZX1ae4BU7azW5mbUXCRq4gBgZXfbjJM6SLlkZ SXIobCDXLIzQeA6KaatQh0m4Iw0ksjgfiTgQ1FMk9t/TRGIYF8cQCyf4oVVJER+WTDauw0wzqUNO wd8IUWIT/pAgAT1Q/M2Ra1tqt1ZhFrkWngUUIRbsQfbxhSsFt4esFuoPrW1fsl/belvmIizsNGJB /KsCxk2/vmz7caoq35zNBhGL99qYoZ4PH9XYbphMCt2S4XIPNGEWh7esxywyk59m0RJhQaKKB4j+ EjWHRiLUwR1j1NFKKSWOkUuU0li5RCGLo8QKmUyBksQwI1ZK45VKqUQux2cqShxPUeJQrSKnUNkh FYiwH0EggCcYJRwE4KmrUYJL0IUcMgrtSSIJxargPQo3DIgCMj4XiA7GWsyx+6k/oaOGG8jRB3ek 6fo4PYRqCEUQmiB0nhKlPdgZ9fChkAjCrd3sO3BbNzvOvtMFt7LjXVFzDwv9gvfYRHxpnB3vxrNo h06f0SwDO6YlMTGcvGhxfHS0WMqfyaNl6EzGCxAuFiaDvwkLEz4tKRlJYsOS/v2jksJyojgti4QQ Q13Bb4Pfdode3x880E0konMgxO+Meto5tKyLQCVoABtAG3j7rMGa1ypIRP5wrgFIV7YJEtBwxr1G 5MFHyplZF8Dvm9rgTh2kUB7J2yiQBKDr3Cq1oapNgNKLa6ZyWXIZPirt5ubLSIQA1Ymr4CZQiY5K 6/0gVzFyPzX345IIFfqFC0nkIWH/yKBpfWiAFn5BnCFS+6n0kSIQpZJIbFLBsGs46LhIaVgAwzkm w5COzCU47x+YnBzon2JvTQ70nZ7q9/v7p6b6+6dgJt5PDvj9JU1NJSVNwdOhQbO7eF1TCTHf7HY3 N5Wwt9hbREP41r7Tp/YOTMLMyQH8UH/o0X7+1mAyPja7iXm/uxk1Bk8e6YeZ7C2uS+BZxAA1MCAi DBOf7Us5oPKRg2KjT3NA7hMD05g+QNR+rBgVngS5Y0loPCMdBZu11uACWiBoB8rCo/w8JQX0OhDH 7RePYRpB2xUFNoUqnlhcOJ+CZ2AB2s6wK9gv0LZiE9wDJWjrY99iF9B2iBiamJmZmJidnehob0ff dmJ+8f34//i2J38LyqDszm0Yy/7n9h32vy1Xr3Cfq7y3RNRqQcn0kpGkAJxgVMmDnGDNIJbL6dSO LblA7AYaeHMaaUVK55FALPQbrPPRi4TGGej0uJ8gq8EPqZdK0ZM1y9WPVj/z7vlg9bTBZwzAo0yC 3peBcVl9+O2RCJB3PGUMFbavneWEGAIEShqJKPu8FqFms81ztOaRB3DkFu7df5Ei2sH1MricpUPL HtdHetXLVcKd9O+qDzU3t725b+/wiYaePL8GHn2pakvP60fL9+5tXF2/tfhIb+NQS9aBXT3P2MAN +hgJbfTp9dbiHF8u5ijJ9ln5pZt4gShG8CaY2CRfMbeI6UKNacyGjZEyVhgg9vDWSQsQzHTOcWSd zoh15nnj3L/H5VRu9GTCGnS9yFBhPzfQTtuzFgs1Bz/BZuMjS9dtP/R2vtk3tHbtxu1bu0ZH29t3 bJ/8RdNLLWfupbtW/5/zag1q6kzD33e4WOqB5IQcEggETi6ARkAD4WJRQ5VKWHW9EitQa1lgECks FQVCgA1uEW9A1QriZapYV3dhBbwgoHXbqtjOdnZm3Z3OuNt2tsh0d4s71eDYWXNmv++cXEhChdkf 6MlJzpz3fZ/nfZ7nK3hrA8zNzVqZtCN6R9n6KmVY3bamY8Bj2xVADVr1obJwuSJCGamSqpWRjCIi LCpUqg6LUisRb2r1tCxcLJOFqyPDI/gNUUZawqIGiVX6QH5X1DekbarWqGGoRfukIGp4kVDKwgaJ avviaLV4euljE7aHeJrWdFs6d4NKa/aL1/jabRHGg/gX7RSjg4lUIq2kIDOb3TrO5sHunWYz+xbU zsw2+FI+scx2r5B9BsvgaQ+eJYBS/dxQpVSWHx8vUF6MHUKlMvAlvTgmRiVQqeh8H0G+z94AIJUq yehB+LJeFHtCqSTl7RqNiCwBohL/Y/ZwgJMaItCY/QCDDy/p+No6MUbxx5vZUEsxh2JohtbOmk1d eRsLCtraGDX8kj068Nm1D7JnnIj8bXVR4fYSP3inbPLc4b3HPbkTj5w7Tx+gtchkMcx8yzy8fKIF lhh++VItDLdy8wcJU39CmxxtG88LnVQ11Tx4ZmAVctgHv2IvkCK/5GSXO2M7kdDYR6DTa7XJs5jI RwsqVtR29TYf7x29vKluz6Zdu2DN61vW/nLH5s2bZ5rN88WLzzS0j/z4t8cwUFmmvcmaK8pLflZ1 aAfw4A0DMq8DGfGKXiif6i6ytkjnPJg26RBhAuFTpNnqdNTxmQw1OSWYQQEF+Myi49PygywbRRjZ Ts2MDT6//C3srKqy/cB+jcKgW08aoENRu0jPSBULkn1jFlkieMRfQdDj5rjbqvnxbVEY+qVtKmer Sa1h+FZqGyLFbld8mCKtkjQXD0SSF6yCnyOFiec4maB2BgqJI4AlxcxiLj/u7TK/09p7v2///otw s8X4WqYxr7F447ri4zON6dutO7c3lW9prig+W3Vkf+X593NKUjOXJ+f+oaBsXcGm5Xm50+1M4TDQ oewtJ+r0lBY5V1yqY2dCLVK8RHNlljhuknIdGpSBNykpv0cqt8lxJqXVTjUovDov9nFuMP7+riAr JtDhz5lOFf6zGFlj9XqTKaF0ya6zvXs6f//Xq4Z5W7b8vLx0s3HG1bHFlMwbHlq8uMfcOvLk/g/s Q+JE5Tulq3a3l3nyLALMQ0zb5shnZPiThRYVPyh+TDij4jEl4mhq7o9rixkkcq7ZkxtaKj0II6o9 l8rGB1W7vb9wUijDpVB+/3dkhasLvob15o4OM/4zZGUZsgyG2WY9CZdeA9knfHq9e+f2NOk1EmQM ox7TAQ0NA2gs8iF0LYCG/gAQPkTUAxE0DmDq4GsSGvu4QWBJGbdLy7h791CMG9UlIT4QEmGilhJO 4y3QdPfMmdHRM2fu3jnb3X3Wu6EH7GMY9ICP3rCK7WDrASCm1E2BxRkBgOJKPQyCoAF1RcLsyzi2 Bo6gUoUoSJCwFJeOCp6wjT3ijNL2/JF7uX6JlJ8k0atA4v1h9rZvnWdhXT6XZG+4V6ICdfrAWCUk RBQZwSgEElWGgGgAJFLsBhAGj4IIVKSEK1BA5OEi9XNxlQqGEvmKZUNEGrpff4X8HAR1ROIhi/mB 4zHbxhHFxsc4RZvAwx63PhKOI2dLw38HFy0E+W69IBV3Bmz/OTRaTCRtKF97z/8WUc7+IrRp2e2B o6/uW9lcdH5k9doNnt0ePZxXoj353q6DYbKWzPfqP1y+ssK99zhQ0ydGapJ+Wa0WhEZkCFHL4QiP SNRyKNdyHB4FuqPhSXUVdy4OUeOwHNFBZrwMRwEADOo6BM0h1kU3vnsrannMSvHdo9bxP9jXH3mI ul+IXajdW/dXOsKNt4LDh+kNyz8c+fcXnZ2ZliU7i07++sK19sINufs9h3BcIGxvuJO84lxFOU03 6hryDRXrilfm6NxdOgSEAiNys2CJmAqiKQlNSyTB5GhA8KhPRQBAlyQVGBoaSA/CvgEguBA4CEX9 /ntwnOPznDA9LSEN+xb/Ed8QposwzJ501SXqlJQS0iiFeedX4tnZsrLfshvhZfYfkPFi77MDRJTt mwMHYBl72B1JBSi8juJD+gBNC0IySIRaKMxGHSrs+EXx+F3B+IXQ6AeNSDPS0FcYPym6knPY3XJj rvVpugs5BNv49KhFK3WIuFRyYhQtnh6qZUXRF+988wlstf2TUUCmZ+1uz9ZOBQadamn/zegRdoHf 6KU4N2wUYAEo6iM0mKcMI6Mprj8R6krAyx76tRpdyaCB0w9qBEUpJepHznMxdoSwABJ9lhK/4uXv Kad7Y66lxKQcP+ghhNgYJbpoREiCdjljsNhhmt7opdaVFza+VrXw3lef9B690W1u+U9Hdt4bmV1e +ri6+4puLyVkrY///mz4cH03+/GN6m3Zhe6YSkBWH0EOwuz+AKF4CGmPyCGQnJYTJn1A8OcgRZxC E+jrHCSZxn7ULgYvH4GHBBOfroQTBz0pmCRKQXGR8fH3dnn43Rd/umZrgg8fNK/xrPpuMzz93bFj 7K1PP3BLNJEgBmjB9qtkSFSsryz+IwQFhUAJACoeFD2Ji+a+FQdF30SVShFAGjjPIZUKfE+O7i1C 94KcHmXlULKO2xMhB5VXHoSulOf0ZZwLOemUOGOhN1aGoesdJz4ePdll2XcRbuhvOvBHY0de5poi L6zWl3ZX7uuoPVnytunNynd3mCVbVxVXr7u3yLg2NXurIR94cdWoJ0kNxYhopkYgoDWD8HU9pVbT shofugarCUlKY+WDkNSTogtA+pX/w9h7ymGQYLWhdDIx4ToT2o+JKM2JvE6EkFNFGm+gSOc68/gk Jf7UcdCns7G8eHdmheaz8U9/d+TGeZPlX5icK054NUydurbwXYEQBj/+8ulwu/kizLhZW5Bd5IY5 hZKZGqdYIW/h/UFPFDh4SPkQQo6g7ZSjzyIuiKgwYWkiCYONDgT1/bI2zuRJZPJC+KrT5K2sK5mM ceBPb/fQEVBosShFQXEpxZvKbw6hCGAmqlr6+lpa+vtb6upM0+aB55dg8P37UMx+f//P7PdVsBJW sofYQwCCHmIt/ItPNepXfAP4IEENAP4wC4CECcCdTZNcZ9CenKVLjMYlS3OIMfz/EmMOfh6OEDZf 0v48kcI9X8A/b/N4vqfW1Ntba+ohxmp7e0ymnh78PDjit8YvyfH8Ae75/055P0jUAloMlAr0qtzJ SZjHdk9OsueIsUmYy57DlzDXQ1M0I0gyT+E0A09xakIOwzRkAiKYxqsHYh7PP49ULMYv0yXxL/OY 9RHu7fZXeqdBrg7+B9NVk81Vk+2oJour5n+MV31sFMcVn7e7s/fh893t7d3tHWcb79l35+IGhwPb sTB0+SMUoZo4atUAkim1K+JIVGnBfyRKZR/+B6dqcFAxxDQB81E3imqF4g/OhAKBIJGkIooQhPxR Y8CqVFOitnFosbmhb3bPcLZjq5Zu5nn2zfv4vTdv3qxb0BpYyBooAymdBok9TKfZw7nm4OI0w+yK G0d7hJ1mr7czW7c+Jb5PFzZlgVcTnDFj+RqP62wzrPW+Wf18CVmzJo8HB4NtBgoULKIfEx2UkzOD dRqLyOWTodPTpYN8z5rnjxvNTbgFYwib3nxx296927btXTCa31g8e2e92kpIBVlJXjxHluNF/RQ6 wXtpdIaXhpqzSCdwTccZ3USnqs5iO7IEeBOS4q7xevD0OaRLcS2Es4s7jde2WR3um/XhMT2/t1rO 8ajOCZL2f6OwLzeP9k1Hch8/3vy3MDSPN6KQbKhfs/a9MJ11XyNevJIm+n3tLnzPHj8lpvDh0ekJ 8FMgC03Ek027jBlXqMYmiyh+AR8FJUis8MG0swEvETZ/kfo1FMNbdy9eT73ORthLt+D6JDSyw5P/ Ze/AFrpyYyVrZqNX2ZH6TZVwAPRr8PxUG2ydnISfsiMTjwg7NNeySLs3wC3zpmzE15kf4pZJaFn+ jAMBWtCHJujRRCIuVCKRzD2h0svXL95F1Tc7diGBmotTmTj87D8P0LhDDzLsKP3txufZkavsJnup clM9/OQqdyNjTLAj0DjJud7OqcYir4aAVQOv3txqrOjYUJchUxm7QXKqr8WP1ZfzN83kR+4zQn3m BMlW2zqstln+35j8T6ptNeeXevZJPVNbc6qGSGy8iomY0RSlHBqgxyRC+DGV0Miak7avpApmIvWV iVRMV3QRRcEaLmgfvYwCJ/9CL08+Q75N6nFT6vGsVGEFlyqsmF/qDmn11IVL9PIlafVkZl6p602p 66dtXWfaum6OVECpwKUi7A872A16GcrEV6a2zpXrICsNp10gYjtpl6iATauRL6ckIhOxU+iUHCSN 4u1HJUyaGu+9jGI+lWqsdgetV3TVplTrio3WTV2ApktUvNQkrZq60IjEZObSbF3JflnkItcbbrvY LqXsxA6k00GBa7EddZhaskq898zmibuS0DUcwIuSLzZZkqFMWt1oquD5skb8t7QbNRScFAjK+ke/ KIIwLLzBcwBfd3zAvHEIfXAMjrIteP6PsQbWwPc+Omx7Rl7yZO/r1l7omLNXfFZc+/C0MMbHhx9Y ejFP5+q1cnWm3jKe3DP10rpv0zs1Z69QzxP9iV7wwk5ZQUQpiQ5iUkmSmIYHQ5QIoiTRYdhFoOJv 2HlXjPGeGyioKoh7M21wq6cHRoXvDsMVYXfmVZa0zo4VHRuJGgECokRtspCSUaxIZZss4f15j3fx 98z+PaaqlIpin1A+PCyUZ67hOJYlMteEcpT3OdkjP4fyHGSp4UTvuBSHLKQFauTZLaF2h10aFvYQ SzIfKipQtq6qOqgA6udCuLdXCLMNvayO1fWKH8MjBuwjBlDLPoJHaDV40GqfeWc9ZUS431S2O5x5 TsBax02XuBankw4LhOTlOIBQxABiokgBhMkD++Eu64MfssD+AyyAc5/4d7jJ9J/zLnI7i8LIdt5T 5qDkIUkjZiqwFLry3W6PpVMyPXPiisctHp2hNCZSqnKlagxJVVoCOw7CTvbGQbanuxt/bA/s6IZf HpR+3D1jZUd3tznlxkkjmwzN7iami2iA2+P1qUHNq9BRTKJfGOHAqEIEu2WQaY9X8QWCXi3vz/Ac Xtt3iIqzVjFxf0zhwGPvkaXQ0ISuaNUa1kubZtN0JWFL2BS9OgEHdoNnvKNjHLwd4+Md7J+cZv/a PS5un7M0brISjP8TzHwkQEIkQoqITkrxzfmK0RjWYbGuJgQ16k0Ifn0mpGix6g9qofCiSEFh0WI9 WlIaiydKOdCR+EyoTdYA5zVZiy3e0mwAuHvZ9CIN0NAwOxKqCCLVaQzXFVEFNabHKFBVmTdCra1w oo19JjSxK+wzOMGutLa1sfpWSGbehiQkWT0sa5svimwDu2JuaW1l9W2wLGdLWxucaGVX8HLOqZcq InXO8Eg03xuNWaOsOj+AjaQAY7hxSCu2FzQbrjRsOFWUSoDWbChIGwWBVNH+Rc3h/XiaHU5fYbE1 ypInv8WThhcGIy6thbM6ToZTEl+IyvEWAyu/w3CVpuKlXf6WgBboCleMYSkeq1nkzSzK1NTcm56x 8HNE+R/vW8f4Opaq7OTFsq1Mf8eMwjtIr8SfUoI3hR7glFryeHE5p/ii+B7i0wub2Z4kggabkN6R TGKpvIGF81gSqzZWT9Yg9Jsfcnk3Z+pmsOCmHAyDZCm5M+BwNceiaeHNwRIINC8NI2UUhspkT1E5 9RVS2eMrK7dGOehwIdZ5aRgZQt7wUimIpOEOlewvaincHyI2qaWsPC10Di3xvOVrWVyApFFYGHOC Fs0LhMCZF4jGrFGmHl/BYklJC88OFUq2snKJcnJJl9YS6io0G38N0dJqHqPlra2tNX8TtZkxPtSa +HoX4rMGjnNVVTViKsQQaFm2IajBoMahjscTuI5fEWxcwg/4WXzv8HmVY5hgg8mecyqC+a77Qk8y OfSlyr6A73huDiQHbrk5ou7b/Rx13/meJHy/nO9Rzx5JvnPRZyGvfnkq+adRH+f03X4/+f4dZUYG F5KXjbjkzwv5/ZFQqb88JEvBvIg/GImUBssjsj0oOSKekN/Z7sBM3D6AVaNdRcLwe4jfSUNqJCh1 Uurscnd6ulQEbayGX4tKDTYfCA72CghP9v9lT2/hZ1wtra5Sl/u0IA1INlksERLxWKxUFCg6X1XV B3mDt5WmwEg/uNjEwG2l0fW7D9mgNMz+uOtVdvz3X69aNSEGXQfPww/YiTPd+U353R+yAdx0x7ts F/yI9bWvnOj9wwQRoJEM0XPUhz6WkGYjLFFVJILD6RFd7oLQonah2B9tdwku7HV+ZYTdEnWKDhtx e0S1uKCoUwn5g502m+IYhkmicpemf3i2+PkiuWtKdhHDHNSLqzVZ8Wq2uF5sS1Qp3gTEK1dU44so gQ8jG76P4N2/ggvso2s/+WTtCPuG3R9Z+z/qyz62ifOO489zF9uYvPn8Er/mxXc+27GdOLbjXGwn xImdV8gbEGBUqH8wIMAkVgmQ2wJrPS2bRFFgELZOLRD+YNVGygrqlkZUop2KFHUUaUXquqlMXekQ G9HULauYyB37PXdOSEm2tCv5Y7nc+e55nvyc536f5/v7PpOT9DOdnadeHTvV2fnShV+o9JOTbZ9I M9I//9g6Odl6E+fj/Jszvzl9/vyZrq6XLlx4uRNc5XznmT+v7snKS8pOkeq5QqSUXrkQkbqnPYvn 1T0tTWspXkuBh8EfSjdwAFeNkov0PlSqgHRDunGGXKAJHklDrvn9UaVZ6pA7Awv+Gw7tB2+Rp6by MG3JWsfx8YslWfsEdQxpYKuKn6MLx6mGi9rsigmqDqlgp0ojw4S8S93/K3XB0cL8o4XWCSqJVlAt yfw8DHNS0WpKcTq6z281gIbpPp96uFedmp5S3r9Bq6ajEVOUg1cuKJtSTVTZk8LGzjRG3aJuiQ7x FWoTtUl8JT00lKpojtalNj0xsPtAV3lbrtsBV3nIjGHPnjvqji5Xh+D3ebfb17Y3t5e2EIs/O988 tBLpQMXsqDFZpFLDa4aCV6ItsiPLBJ6EhPwwaSoCe5A312e22ItXnDUqaZgm9Mjg0GFkxrjEpAPj Q2Ax0C6mVuCddSiSV//Tf+Bn1knd+JJLuk4+3vv01vVz56TrPGUVb/fjA3+XLdjUXenXuOG5HdLx 28SIHTlCbNlneNvgQfxX2DPCuv8+eL+fyN7PhNaDwzcZ5LJeqNOvQFB67r5uyNcYBtEEtReZwA+a mVzZl5FSirnRZCx4g9KTRUFWgSiSmiIyZmWFYxXNw68TnDLxihyYRew04DI8kMUD5LJeeiKbxSXn KBsYxxOyfZR6wE7SP74n7bl3Dx+7h49K36Zq5vtJ3EA8ZdHcO88Hj+VBfhREESSgBGpCKdSOVqNe tA79Idls8wQsii+p8NRG64SGxlVN6da29jXdPb1Wva8+Fk8km1MdnV19/WvXFXGrW2qGIgWDSD+o drr4QJWKG8enkhvUJ31DlZHKkwhZ5VD1sQQJBH+2ek13rzHAujy1dUKyuSVFYpNQDO/tiQcyQYud o/kMG/VmKk176eK92iCrHQlnIpWRETpXsuUqDMohW6B5AoKa5H65oMgDYozSIddqZwVidEi58vPu sZljBI8AXtDEeQSGw1w0ooJVgCMmDnsEMxbMGvk0azyG3LMh90wfk65Jvfg1HIHjNalXugbJGpF2 S3+CYzcewWUbQi3+0Xx/tisUCklcOp23LS0OptOSL8Em6J+zCVa6CxfxODw64Qbfi7PxN+Cc0ZGn eYHBkfWESMT536CKjkm/fMq664rl4+3lG/F1SZuGH/GzNP3UbFS6P84mZgbgkb49G5feSb5YC72P cFGJqlAIRVEMNaJm1Io6UTfqRwPoZjJlq6ye5aKyTqiPrWpKNre1d3T29Pb1W/WBOOS3JdUK6V27 bv1AEdedDg9FAQpAw0ncbXVQI5OxUX0yMOSP+ufIiCcaSSjCRU9vv7Ga5d2VdfUxBYyOThJNz/n6 GqozIcGX8VvsHprLsAoaIUCjNhP1Rx9FQ+bi8aIR1Tx+ODaGL1qu7LJ+0OXmVy8THbt3+PNH/Qc2 B0uSfnxlufj4SzIMfAQtttIFbBj17kXZKOfGqb5kq73MWR1UuYd4RUMIHLxMB18GZEAchYvCaqtj VVdeOcs/CgfD+crHcW/S+b8icmuWEeJACScwajo3JOfH5lBZgpVI1KyJcsAKUPL4WbkzNnanq6tr mUDpC2/cEILwsIX7ypB8RRVxexZQYtIHZC2YDwqjgKKAAcoDOlIdXPH/qSJmwewRPEAG5P3xl5gP SAW42NXNe5cJjuaD/tEC347g5kDSgk9+XRVZyn24+AXOw6T35XzEfPthYOfZDzsXqMpjv5T7sC90 H2zOfTh5ms3Y57kP+/K7DwUOwsbjF40skf/+RCSyTGREP7a+tcv6wvZvlOKdX5cLJ+IX1Y63kj+w Osgat0A6yyt8/kBVdTAUjhBICBBk5YNskIVOEuzWp2s8Q+5cQXENcW4OSChzwrBZPSDDmHiF1eEj oWrmYjE2tjmeaSy12DIVfjbDKQw0VmhHKjNuzr0IA/IW9osITD9MfzD434sG74E6IZDKwUPeMck7 5NiQyzUNnzy00bl7Q67vy0hCaMPGcFjcn05TTFr8M7zrM7kc34cTMDjExlkRzgQ0n447E0sm+1/n qU/GxsTSu2lxZ1rJ8Mz0bF7FAghzP53GZfApFpLEvwfB5QHowYO5LLejUQ2L0BWU/GLrmUVbTy/a emrR1pdnWx9hyoW8KIBqUC2qRw3QnUYdaA3qQx8mBVuZ09VqsZWVO1lXjqSGTqWC9Jn1kUoZsxrQ DaITRY6kD1xKW6uDKMzmnOacjAyF+TDQZbFYObkCtaQhBInAtHohcqUMa01Uic44QmtSrZmOumAo E2b5jBf48mYcgFiHdsSecYQdc4QRwMgxi9gcY8GHkOlmux76kyWUBg4hSoCjASseHK1HIytPBFyu WcjJi0AkJoedh6C3FG6pcJhsb4C4tpT0kTPGnorxDQ0tLYlERfysU+AoXM/GXuca3O7mA+Uxp1jP 1i+JW55rq/RdfHDrN8fG7l9Kp7+T4OJnWcH1Uer3FfVlZ+JsbKaAjXMPYi4B16dSuDReVj/BxVhE o7EH7ep96j6kQzbEom1JB85T2exOVqOmGGQx6HWGbLHDmqWyFkuxehwfTtp0KgtLVzgYZKV0w/qK YQ09rJlwvKu/hoIiCLryovXKCpfTIZK0kAYlLaEaA2acDMaMUa3BajXHwX00Eq4TMB/FDNxEGc0Y tQ/T2Iu9Tc9Lb2959skyyYGf39q/vRZXid/Dk70XjlzFl6l90iX6W9LvsFf82/iLWRjYKF2CxkNv emtxNfR7xUNPj+C9VxfMczDpyC/Q6cEmaQqdDDJabNiSpYsMWWfWaKQLyTwdmEG2AqODtpcNr7QP Fw2zhmI8jK7Z3mUnVganxakpYn2ndKLM03+aKsySY90e7HZHyYzJtE0qXFISAe3SeBgj3Kj3iYdL n3x2i/R2tonMGOb9qXQIZlkd2dG3VRLeeefIq334sngYdzduwauyL45TDJnzzAncDY3Zy1j6ba33 TVXg6lXp8ImnyTrPzbUY/UzDqn50Bf2b8KoBiuq6wvfc97e7sMt7vP0BFgLLsssGEIQFViyGHaw/ GadGTWpMFHEEU5ARGit2olUC+QGjGdLYtI01jk4zmTEdA0KCbIhEq5BkKuq0tHYyVeoE21hCOk2Y jNV9l977dhEItIV577x3z3n7zvm+d37urLWT02sIST0081vRSXhKbIxWhNmat0Vt8lFE18/N0fzX Z07OfAYZUD5plC6LqUiib3egNJRFO9ZDtAp1B+3LzIiLUW3JD4hKojd3cenSZWIwoPTCm11yeoCK 7mKjkMBkYravjMqeYHEwUeZRL7QHbQVqsteXWyCm53BCjHnxUhGCpYZeXNhtTLBlM5mzrBiYRA8o 6Uy6coyuEKQhnSw5ekyVjKmuNDWpRA95/P6Op4TWC9UfL9gdGQjc2OPN5BHYeE6U4hEUFWcEigOY KgozvZm6SjelxhyGogIU0dpEXhLd8Sg/5IHjmTHkGnmNa+73kAqvBIXwFJ9ICieq9myESe2tMair 3Vv1OOHwY/119Z9nC5ADdeG9Ay44KnGpEvnV6aNhdBUOV+zbsp3Y8Pc/I4cb2tbXwRdiKom/XLV/ G3yudcPtP+14uoG48OqQk6z1CeCGfeEffSCPDT0okevk+XtjZz682LKzYRtx4NXEfSshdlvlIWoE WkUI+As+ifyBHObaQjFf/TEH8mEnQkaEyBoDot8SR3uGipy0a+TSCaSczqVtwXTJqDgSncmprgxf 1pKypStXKXxgeU25NY6vgcX+3BoEvbD3XbUlrzyPXgTdKDlXMsbEximqIzHZ5cvK9QdKlpSttDqX 84t3IU+qcxfXC3u68tpXhWAPZW6CFvMIcfrEgCIdYAaZCss7haVaPBK8mRkcYOSxO3gVeMQVB+I9 kIFUUaI8RBT03wZWNV5grFHriBa5mXlBgLJqQHfyU2A7ZJk9pNKDbyWRI2RI9MJbbr6fnCVo456q CRgKb4WHQdtQvWc7+fkX3DEHOUyGxey/19dprqNdUC2m8hKpTru3GFbCWN2W/RVkx1XuGAkR+471 B+qh/jOG6R0kXSHvkMTqpq2X4ctwFTwCIw0/rL9GErg3ZPIcuS74oMOpJdvgJ+CWHhwak+99F74H Y9sadrZc7O/l3rhLJsn1QxU/iE0YhRvhKhvsgAWS7wIJ41EreYUM5Qx/HYMob/mkRc/IRJqLhagh aAHEywlJznR3tt+4wNMHb9I0XYCLuu32ND3XFBOClIiB6PPzkrywH0oo+T4oRylIgnNdKSqw1DKz tKEDHSMimlMl0XTLY6UynhVFB00Ou91mFWltLKJ7Cy8uYn1XzYAAr1h5d5onYGd9oNDLed3piJZJ BxJH/qn9W1tNdrtcLTVrtm58Mm8hhdIMzjDIZMtHsIR8/Sn5mNyqHZw40vWbHx//yzC540yC/WLq R6dJBimtPFH+SveuysqR5hZIPgLL4WVydVgLvNhBxnpGQjubnqmt6oJLneRDMrm2YzOM0Yo2hVIr 6oYO+r1P17oZGnENWTujPk5p4lC3NMmfOBdBu3kG2nXBWGyyJ6W7s7IXGP1prLh5EpG/DxfRgV5m WPMo0Yd1AzFlgV016VhLKIVi7UMqxdonJf4vrPU80NMAvB7M5pnC+ICXIe0vYKhLCAlQzOB1p0uZ Ga4C3iYLHKK92CYjf4E4cp38K0xuka9IaGHekxu3rqlpcbngJdyNxfBr7W93vz4xWAtOWPQpmMmF TrKJNCc5wTB8nbRsGiZXoB1WvA7OluaRzZWN77aXn6gk3yEZp/Hm/NPVNc/sf/r9v/aQsXfIbRDh HxWdj04icj6K2xUd0TPzIBrVQOc8LKRRrM/cx5p2IeMTtAvxtE7ZQA06bIrJao5TLTJt+DFWc7xq UUwWVe3FzwWNVrPVajXHyLJ+Rw0VxWQ0GPQ7DFaMQYrcpWGO3nHz/VaMyaRarb24tEcyWywK+63S 94wG9mwfHKMeGekEbOKeBWSKibGYzb34hR7BqqqyQttcwRkATjLyyNBPycWUlhKE8PMI00lCHqeM yhN5/lLFL3+jC1Q2zpZL8kqjC1ERR//yF7ZacrOFffJFKhOmLywzL5ghpRJcnOIyYgeABJAJEADj E3cXacl4VPj4Z/eMWidewzXXklehnp7Iq7XQQH5aC/V4FI/evcQf1zq1Tj4zqqrXT7pldArQ8V+B +kxilCvMVoUOusohEa3vEkSxF78YNDNQRR5zIi8KPFtJAGwFwDxwPF3/NUJ8O+YEkUchaEaQ9zdH yTgqo2fah1uF3GwDC80QDZbGQyMTOu4SAZPHtFjcB5uZwzSqzRG/dA9WoLPiphk7okF979OKzqJT 355mqAYzjdg4Y5oBXbOKPqOgwm7ZotDy+EkXH2ehIhhrepZHFgUsssKbQ9CCJH2YoJsQjQ0SNEtp Srpob4lsNAqQw1VE473ENa0jL4xP7RvGYe+6cDOJhy9h/CaZuD/8T9z8hqhEZd5du7+TOz9rf5cV jeb8vNEcY5q50UhZ9BkDerxLYry0Bo3IYKVjG+a4yB1YmaEBPoBaxNHOIEJt0GRAQImTDKIQgjak D000Sm2chci4YdRQZqhQwQUuGz1O4VFwaE0Cd1fDzeS2Tk7ToNYUnR2z9HgGpGvT8UyuisYzMF88 4j6mmRPPbuGAsI7Gs7KLj0RgFgWrSL8wQTTwEvc+jQBBUtBE2z8n8Lz0Z74XJrsMoiFv0fiEwgZA LVI8WRgsaVSXw0UTRck8xTsGwo3cwYPhXQPCOnp5iDsYbhzU/Ym8dQX6RCyO+jnTl4e/5Uvk1SLz hWe+oKhzv8R9uJC200mGqBbxZlyLeBNxJqAEVHCASzo1AMwT6s7A7vt+NQ6iWd78bpY3SLoxk+kD s5g+MJNp3EaZ3oBE3DaLaez8/0wrEaZxrnaTf+jeb3Gq9nud6Ztkt3Zzap9wQ+d6yHBwmmvyiyjX Q/NxLeUzzRyuVfER4b1prg/M4XoDrT4vBY0SipLdh6sp4i3IkBfhumwO1/+hvcqjmryy+Lvv+7KR ANkwEBYFFFBaUEIISIQoKAgugEvAtTVUrai4AS7FBWtpCYtLsW51KyqR8bCpDQO1M2fU4/yhc5iO zmiFUgiOnhk9M3OY/uGQMPdLAoWO7X/zneTl3ndP3vfu79137+8CJhIZ4FGD2Y75yvHcDo4i3g1H kZ04XjDETsDs2pXr3Wmkkz84CuPhHaX9ZEcjJ55LWG5HZPjI28GIB15G3AeNKf4n5w0yzGxwDcx0 CHydWypSjOzuBe6qaOx+vhnZD5d3CxDVlZh1PUlpi1AgsNLdBhHLKFmW8XRpKpaHGs+TxxewEqxb jKSMLyqjvA6Yh+evIxTmGcQM2vhMjdCjBsuhuQUusnhJXnKEm2McAxz/5vokd+Ob4KpF7HDl4QTg CDngR4sRouUXDTbby+kuhwIqmKzBJlZib3I00l040+j4i6PoLlS4I9m1/zTycFSeu4O5/EtnrDwk y8bEyigLP2RUrDiREPwBVxIhaf2qRcLVYURCIFQKBEKvYY2PGl8hlzs1FwGQubQQFwFgvGRYrajA U85KPUCiYIhQWsZ6lCHd4FvxIsuFngKJnEpZqFF484Q1gvsSK9haFPexoCNgrh5FPsKJOeo20l3K VW/C7X8FDkQXmJOCfQB8uBLChHFo0ql0l73cvon+G8wYr2JHMVRAxzCukI22csg23QUzmO/edRS5 IueO47Ibs8ej0XRi1sOrRQsXPZYWDF8nLp5U6elJgVKnJhQphUKRRCx2aq5YR0rk1Agf8wnfQyTi NCUQrO14DzHsRR5iiYgIyhgOM2+8OCyPm/IU8YU1/DZwIP+x2cekYq+osUTmR4EdFnhuYRIIZMHI a2Q6EdUx/7JbXjH7XlHjf3ZXUiPWH0tlDzVyU3YL7bN3VtotoKLGSle0ufxNI9/yZ43hLrXscycK xwwJgDhQEQaQkI9+Gt0+EgCjyEMpEnnweTyjRKyUSMSj3BKYDa74mMCMQeCAAenDUPMEJlrt91Lt 60oAI+IYr8u9Sn8UBF5Svd45IKEAVbAMqVxwuIiG82rR38ED6K89iEahx5ghLGZm9ggKe8xuFNyc iPMsjXSN8tcEHcxOVoLZRUAm3mDLCK8MN5l/k+HVMPwa2gbPCRPtwPtOol/hOG2qAm+0AiPSxPgM /s1Es7jLDC+54HOtRlt/abWHP7cazbI3maBi1GrRJB9rRy+fOFcTI+9XEBXxJ+NJKAknkWjXEB1J JMkkBX3KJAvJImIky8lqYiLrSAEpJNtJCdlD9pGDGO1mcph8Sk6QM+Q8qSMW8jW5RzrxDjxjsEPr 6u1nuh8/6bH1DfRY6YnW7sXf/NlKTxnaHz162t397XffNRSsXbfGtGr1suVLjdlZ8+fNTZ+dOtMw Q58Qn7NowcKMzDlps1KSkqcnamOnTX37rckRkyYGTwgMiNPFaKKip0SGhYeEBo338/VRyqSemHV5 LBC1/zgVdhTeHmK+gK66fOnihbOfnzp5vPbokarKessXdefOnz7z2Yljn1bXfPLxoQ8P7C/9YNfO oh1bt5g/Ki87uHff7j3FJdu2b9r4/vr38t99Z+WKvNwlmws3pHVU3Gi9+fv796wDd6z0g5utA/fv 37rW3k7jSAdpo7Wtt39zu/0rp3YbychVqm/pKLvVTnkYHE1Qd5R7eVyOW/f3UaZSh1Ih0Z0iibrm QYOKDElSQqaKUiFpolRmlSGURilSqEiREKLBkLESmkyRIdGgiIh3X87x/I5r9c/r83meu7PuvfZ3 77XXvPedf8rlUFthpRu+t3eGdji1c+GWCzGyH1tUjHbfaJ2yTnHGngavLa4/UqbMTKpJ+uS3NvjZ z/cxPj9kjGao7NNbdyHX1au5Y866+2U1FRVYjYeUnPJz848f55TYvfze9XBpq6q6kqricBV+5HiL gSlte4b2833RXp8aZe/uQ5AqevPqD5LXP127fuR2bOZil/k5qzwKQ8x+3u1bXaiuUXs5M9W/tCk4 sH9M9Abnz1nng256t0r1aakunXmQD3iX8zJXe/dwg80mc+d8rWQzXHe4K2wv9vx7jWtCxEG7svzU pCYP9zNnHfu5DngS0HLoVNfkl/n3HFJORQxf4Z4WsKqX4uiuuvhFe9ZGraiy/rIpMIn3yR/j1D76 4fQPnXfePz7a9s5wQoPjMqtV+0w/lLqvsey5znXWtT2j9ucM8Ht6qKYp5odVZJ+VTK5RiG7BmoTw 40Wq6Xftd+Lbaihixi7L4nyba10OpR+ud53semeYHrwx4Xmk1bJ9Otrncs9dPH7bonTw1eD8W5cP XX7645hV19FMB/e2nE+xUyabx+TEhYzIo7aaDV+m/mZCbUlFcuXdJ0Fhe0o14+d8Gab36Fpzs8fQ deG8ybYcriExurbmmcGmDOsVt0pveTTZ3HijE9Rz/sPSoA03e//UXvA4ITzozK2izRP9a7hEOeWO tO2ztm0L6et8YXD0HtsCmW3M7OOtMp/K3egxw2Tnm7qdnxn8Ti7RKrZ++M9TRXEREafKjDZnO69Y v/5H746++2sy7t+/P7FJIWaR8YJFi4IfG5k5te0YeVeztDPv/eMQjY/aN1a0RWdMpx3UDDoOvzn4 rqjCO+BqsvTIKfW3wjTNDbQ2KaZbj1D4qBUkk2WIO3aaZzq8fzXvStWFqxt77ryu/3n5iYOvNxtL Nj0xMKBy9XgsT0+nbLWe35Lli2z21lnYWH+sfpA9+3Pxgbfv9/kUV1ilTklVr6tvv9kwheQClv/9 7dXkYNMj05ZmLE7Bgy/hXktzda63b9dZNoO/l5Nol24XunOgxefYq4OaMy3Sx1+ynRuUrZWc2tMl qf7ckMrczLlE4zl7Ylxt3jOHuxfnLJzw893ZRoV9q7L7Lz7ncTP/ZFuv44aNBWMd3PpOzcvtzGp9 ENHL9vMNmymdk27kmwzXxyZl/i1jfVz6wJ1rX+Wu+Xx6IT8zq7HPaKxAqv+Xqicypj2HS3rL+G8e 5L9FyT1GTelQT/XBofKx+l82qX7X+EtKo+/14p7v/cwkSqOKtPpuWR228SbWa0TdOP+hhyWqR4uo sB7yVzervDDp07r3rwoNhXZMOlIyRA4buMxUNrVoZZy0+96/fTSkCafhd0J7ZQ84LRnq7agwNmRk ttKuvf0CsuViimXnyRx3pC9JNxepYqbGl/qscBp2IrTDSVqpYHJVz4TkAWcL5lT1rnXqo2SKRxVs yMv6/HZ0BpnkuS+4eVS91nP36V4yRy4pXrhYvXWz3Zi+g82tk/Frw2/def/kCZ5DJgQ4DxxuNqL3 iKxDl9TNFPoOSNtoWrZjyalD5ZKZhVMLbXdPcdsZrdIq6f/tSXz1SMfaCZ1zZ+a4NnV8u/zt7trm jgtrbaRzsSFHC2bH9Z5Z7BvXw8+6f2mBpb+KqqPKnZDJ3+cdkPb5tbGynv3qAvx7qBQumSc13WnI 2FDlbMU5hcv9FR4VzP8if2JLrKPRyo3hZXIJjuTKTSpVO36mf1dZHPIhW3pNkW6Z7MXndlXygc9p /2Hr+3gWLPYf+HRzcAvzffjnYoOWPtxffeoW+feveR785a+augFBfUPr+qptW7pazapgympFq8Ib ZT0OFrh/0TywKacl3W4apnZqZFhJ6+aJdf7mEc4jtXtxM+wC8P3jBo7aRY3BdphFjY3pa6aiOy2a 2a1QLHVzznYTRXya1g6tFqdb11ebaYy5cftAaNjDSXsVt7qct/Dcsb0kMm3ZjSGLHY/sDyuYVDyt vHb7Q8XrzuFRAzSlTvOJ9rPPmmtpWDrHmpYdfhveIjVriKn1tHDVFt/XqxLGrLHdvXTeYq0McpT7 6aa4lMgHpxU1Q428ptlO3Wv+ZmT5zRcLZLYPspu+2efq6vF3dKM/9+3cmzaOcd8+0UVx0qhJq21u 7COyFD1VZbQOz9eZ65GSMtt97tL5Bx4qWiWGHEl9e3igTPTyC/Kj28rj3mHYctW/njwyxydbJ1qo 5Yc5dj4eUT47XmH0miUL940wjzvEJaTMXr654Gbk4WzKyJ46s2ZXdElYxpa6V1sLwq4mux1WLHar Kh48VS7KVuGIVsYcxSkzDkTo2mu8f75ka0pBuIyFjI7VTaPOMZFHZd1KMkmLXaZv5O4omL7iJ+rs rtWW9dIdozk9ArO9W3FO5l3YmOjqFQGnYhRSVHRWzbiOZcyZ/Hr7EtshMx4pLYi6GhBxLPeGAm8r iczdH5sSaffcPv6U7gEtbf+bmVj56D3X/Wd4eVuavZ6lNz5uzIxB1YqGesf847nXMwr3fswoyDPw qrbbnxqJ6fZVUM5vOzov3ntN++a0Ma1xs/UDtY876WMKEamziG1RC8Kc5y7dONr5lPc1g6p6jxPe faafUFtSHZJctC7Hx8Zwd4Kf5fXOG4t01+xfYvEw9d7SYKcZNvVhjtFDN2YxvkqXJ1fOmkor+E1y u9lgMeIg4WyZZ6vbsiT39sKtZj7Dtia125Sctz3eULVw77uEFTZd7aejpmVZOkwdd1J/76NTFSmT JKb7QiznL49udZR9t3Sq+vQnvtR+Nmyk5pTt+z1GD/0UNmWaq0rgrZNlGSa1veXjzygtSBs1NXTJ +K1uuccs/e/HfU5VK15cEWUtGzW+pzuhkKIVJXXk7/du82tNjz2VUsrL7m83OXT34HR82ch7SnnF NoP76+zYWXF/wPBrs85sQUkDfld1OM/NmFaWUhYv1WNKeJ72iujJ9fNjG8bXeJcXthRu56M50xdj EuNspPM+7VKtMh+4f3PcTNtBFe7v3lVTp5IsbeNfEy7ckeeF66xWBD7QUrDpnb9rbGOPI28cCxJf OBve8Tsxsl0m9mbqq9kZIy3zLJPZcTc6Zkw/vdvITlU/bVmRz3hynrNVjbta7NU1dETcZNlpt8Pu vl2VUF7T27Wv8gvZlA3Xk5uZQ+ujDJb6h/ZOf3BEc5FbpYbRU52H+lKaEzpre1N6UtIrZHySMl7c 1coJMR82RMUvTMXP4qHc9jhKB09b8vGt8pHkM/Fl40iNCsvRHqOc98vELzM7Gj8gyXIs7bT0UyXZ 6p2jOihBj/FYLjPmlvM1LWOtfXZ7x1y9HjJkpAo2tSyxvnWH5ZjNStFv3xz5kUJpNo+5H/TyONkc ecW4+fDd6it1hSFZ+Y7nTmSWGmw5/Hc/E0lt8yl+15CdD/fXHXT2kc+uY5d3Sfo5ZwY//pl2JXtf 6rcLw8kLrt8tf4bfdSSj5HQmlkiGjDHuKD/4bO3F/BN6n57V3l+f7lBcVmTWfP9yivrrR4/eyH2q XPC5rqI08mBl1br6vLa7ze/H8ee9n74/e7H2erR+e2BF4Laxj22e7Nx0sWvCGZcfI25HV2aq+Rju 3rPjcqv/xfTLeM9A65Nyj181Wyg/DqhGtYxDfIm8nFLnt6ED81fl37yx3fPAjo5BScGXvSadfM2/ CFwY+cCkRJ0602fXkMahi9b8zD5d7vJyQ8PFDV9aFPbsVm81Sc7Sr/RskTz7sOJL4ONXwwxLHBT7 dvb52uopdXqLdOGLjTd/NBtYnzvqc6dwf4Q92//lU7f047c5pqzDZeVyp/KCC00GKw0Snlz0yZ/p u8vgSGJg1vmf917OPTAz5IdXcsPRCp8v+9Qt/TO72nRz1p54yh7vcDhq5zsrKSPgSkZjuLTy3M7c 2ZYLI/1Swu5mpjU+nZP7dpLptZlWQXs9E+07Ow+Py9xj6Fu3M1D2bLT+hgtvxiQ7PZuYEmP88MKp 9qt+ruWnHhXqjouf92Bt1KRRTSumNmW4ZnYMy8de1kQNTND3zEQCufzlacbihD7tRgbsHurp2AO9 +o064VjrneC68GnXsh9Nmq9u6w57HybdyPhGWZ5TORCx87Tqibu2iU8Wl6j/eFX5ZPjXEuMNLoOS Xxw97uy+4OX+HPvtdl3H8LZnxs0n559qcNw6bE3zC/NehS69wkuDB675/vZ4yjPHrrMvbZc37D/F rjW/0bLTKCv8RFx1FeO9xrZZ/6N210/l1kcm6hs8i1fv+XkpPOpY04bGhg2512YHLXy2febJCaFW VW1qLiMWa3w5uOPKqk9rLdb9vcxJZVyDyusljWcDZqTstzr32qp+5sWjOTPOmnxL9nTVVws4vbLk cL8bHhPnei6YS9Zlzc3y0bze5LXzx5VMXQ8d76R8rU/urcbMzfnEms7k1qX9m/XU1twK9n+atP3Z 5fEvW/JGZlb0uxXip7B7XO3fr/Q//Fz9fL9G7DHPjCr/0xuDmHNHlj0cqr5HVSXwtFtN+CKVku+D eg076OvxNauyLUstIXJwwed3rRubT8UG+hmlzT8Z05Vf2rEhNzc54yr+/NZm8mDTfO/1Vm3Fb6LW qvuefPoUP5bS2OYRf5APjK01Vs9Z/yBEc+Yuwx8VH7PWnW3+2Wpknr8ldM6PhsyDezrb0jcwDh9m zThgbygzrWB734+KixZM8DUtG6BdMrQVGyW9a2hk3LQBi9S1nKTSNWTie+zydQ9TKT+ZNtvt1exe /PSHubl672w+n/l0aszsxhRjrxWVN9ZczDXLzf3UI6prVMnE+aVNE2pz1Lg7HXfz1zatvfIsv2Nt P9LiMreL+Zp375I3feRSndcHuYY7z7U/mC6qfPbNIrS6IuXaq7RAS/J724qWF14BhhuOpd+70Jnv E3q+xyOP0P7W5ppGr01NGjeMeld6Jbk6zfd5kauchllvGf72tXYVkxpLS51UZZNFK7PjGqRKqjbK tZkQCuHR11PeDtCqdrnz/nzq+dRraQkX2zc0baWGRfcffSQmJsbC4tAIeeWRqw/EvTr0nqm5U6V2 z56gb66XtrJVdFwtJe8SGWa/cLrSfH7nK/+Ghb73NiZyefGJuWM37pWON59Z4ciE9bZfFvPObFBI V8mjYtNppXEec6wVNZWTl84LdpLMnGIhXd76vkh7gH2aa2h5UMmzIz/ent9k7b8i7ZJZAj2zc8T4 +CetsrLDGf0txjVqw3O2NJuXBvSXlpvsGpHQeHvTN2NDNvY2n91QEbYo4Of38V/mbXAactRseO0y pcSIrZF38VZWT+XxrkZNqZOPPtm43pS0aFxZ+rBj2OeicWtnnnufsOnRjfpLQW4dO1q+Z4Z6Rj9V CGq9++FCaHPYKOaKgWt41yPNWsWHzSvXqwYFtyi/y1GSnE+scQvQDDgw2jBb971SmtV8l3nj3sYx 6XNzPJoZ8yfR/K0Ds9fad8Sdf7+lV+ibOgPb1BlGc1cE+mpfu7h/t3n6PUP/rqTKqNPfCm9eVP8w K0tFSbUpX2VedFVA4EeuMwzLHPexqvLgA6XE72XtxyZ/eHD78PdY9Uy/k7UrzD6P9b//pm9j5sJ1 Lwq/e631aa84fe/DzHsXFc4H2387vm3H3uD0p1hEwuPNjWkLyhryEgdJfTWM2rKjasoE42c7td1M dDOqlGMd6sxuL/rh4veT02/U9W+7eLXiUZSnedPkl/p7p67q0fyX8za3wY0yB29/eDPTZIt1zFd5 8uIA/aRzO6U9h+6QBGnIJg46mrxq/fe+Q7ba+bUdK/ygIz/rZEMvuaXH9rne7ey/vfzt5+WZqwOH lanEuTumqu2qdmbeDZGNM5Ip3hx+uPqEl/WoW6b24VGD32YGFNwpOxQXsoQ6pKHLECraZoOGLj68 S85x5ZICJWtHru/ENdVBswzaJ4d4hGXT+GwNtWGmWu1asptW3T+xcfbmoj1Rb++qGGk9Kdvnmimv /tfbeOf6gD4znPKvp/RLHjK6z/NBh4cpqQ1zD7EKnHPvtcmht4ee56wd0xv3mpZTRxelKzuOVHpc clq52H3QumiPoxbXWmRNbcaqGgwtjxgclWNgRErVah2ZNq015U6PjfZjTYotyrIHlGdr2wYoSorp +busR/TDw3vbLpc50NN7c5QONqJfrLSljnp5qPIklR612T2djkRvJTSHuJFehzS9DlmE7unZgE9J HUhY7pQ+r5WranbUbqxU6qqnQQuP9pqvfHyz80vVzVpElGa9TLRiGh1nOb1kdVofeec6i3G+CV09 TSPHfzHa2HAmfox8e68hvpFqhj0kpx/Ivkgv9d89f8s+rcHGynKbbY6W3bTXLb7Yt92gX2UJUefd EjVGfqr2GYs5RsOMl5qEm6q7jO91tMfyxMmZI7xOvdHsJ7NNarTdfOfhTTKRUh2jS2ZbKDoc2nJv YJyZnF3U1piS9Rnk2xOySRbS9fNUYjbtUzR5wRUl7fsw6IQ8//cRJa1dZ+709nkmm3VnmWr4tSBS /rZUdJ8TjG4/3X3xtzT7KPZY6rhs8A4nKY0HFmnNPdZuf2pj2eOCSX8vx1y8wKRHivzlW22DyytM PCkVg95EmbOP0jrv3jpD3FhrqRHRnzYWaE21vaT7+cq0tsLgNYrR9Qkz3K4Zn438a/212rR+fjLm edHxj29N4SoTbm8bGmGmPs+up9Q804mjJlQayykuHxxZn1zttrokbV2Y2emixKjx5/nEz5MeGT7e HrpcNjvuU2+ZbAwblOQSq1baX5U4fL9rR/MWWafcLVdS/PvffrBc2SDxwoo7kZVFe5gtgTGPYk63 n/5gMCdXWYbcIp1WMT1l+Lip9nPP/DS1fnFrxdBnynkv2HF3g15y2goaEyymv3VQ5/L37lP4htlq eAUFvjALOPiY8Xv5df+wc+d8g6tLG7iaD3GPv8bEfipTWGp/xyLg1ue5lR0n0i3DooKqD8Rh5zI7 DDqo9ISfI04U7nteXv7C4dCG73JD1HTbh/SVnSl5Ts1+b6b9t7n7rlhf56V1E3fjlxSnTckd5nsr e4SDakHHsWUhUQ4Lzy7Ma6i68Wro93vDzJQ1r944TWVoFLwqtS/BfU4cCLJ6WvDzet/KLHs1o22z 6iSJrc/DvGo8vv6dn1/A77/X8mTh7tEexl4+770qmyd0ROxaG1V/OSvAfP2blfUxuX3Iw+/e1C+4 KLV8/dsG31yrhOEV2UXYqfJlaQfjgtvra2edin/4TZvyPOtpeOXzF+PvntOvhlz4UZbnGfBh3uf7 XhfmfwlvXeWw8ZBHRnKku07eqwT74JurdX5ePZWg/8NvbnPGhq/bzh77XBp2Uq/ukfHuD4vnXnT3 KdrBuprXJy2ak3PhRYptxD61VzuL1th55BPJI7+b3Xi61dYn9ufZjiJ1/TdNX4Jk2xp6vkn/+KRX 01n1GwHNq7raHG5JEvKMvb6G0z6nVZ4Z5c1a5NPSPMTY7/KjA9O7Kr/aXdle5U1rSPIWrGwOK219 Yu2X2mkT/KG3a+yj1fTUNffL375O2rKrqb3FqO+RVU19VjcGqzgqZ/7syNHVj2sr/NK54vTJ7KT2 A3SjsVVWjdLTYVEGsqk7y8oiBivLj7uUN+DwRM+eNhNKqyIk5ke8vHCv7Ts3SJWr2h68+iz3h1Pk 6+/bE86NiA3vbbdN933irV57btx5XNNoFHzwg6x365wvIZ+1P/woSrrtMM4wddT4/KDiixvet+Sr 7zf4vO/FoQd3d+xQkfPYc/l7y4FhEXO1R86KHf56wmIH48XEp22li59pTr25+uN8gwDzDS18y/P1 FQsnTm/pqAtJz/yx9vW5xHmqF0YZL9IpDX+bXh3/aL46viawpb/UvNIf8u5rzCLkZV1WOfv4ers4 efz603PJcnlZEmd4CSb59TeN0RTz369Y/PdXHI5h2B9fYb+/+pNMdEP+H22BRN960mSJ/mwXf1+J /jQPJ1cXs38/J0oki/6Pg/7NYWgoL6s/3d3ZR7KAQjQbCY7988H++iBxivr9x28K/c8INJv+RE+/ Vb4StCX92QGrXRA4AvJB/2Xt5O2CvkDLJYWx8rLGxv/dBE11A4/I5G+E31CMGIr8/4X6RRVD0b9x KNH0PJh+houzu5OZp79kgURYC0cREpqnBZb/4uB/gExEGuDr6S0xnGw+eTKGUZMwjOHR/0gMYwn0 iWgs+c8nw6C/KQxDZIzG/v2ORZ/0P2N/037xm/8ea/wbxN1z1SQnXxfJ6Enj0WACx3Eaxyme5nSE jbj7rnT5vQhhIgr9H2H+799oIooRJjL183X7v8UyvxeL/2eBvDDO2tvT2W+pi7dktOlSb88lTr4S pGpzvd19EYnSwyTL0CRz3ZFA1vroiE7hD+n8kux/zutfgU908nVa6emK/nuSyzInv5W+U7ydAoRh 1L/D/iXbTDGTCGS629P+n2ItQBOuFKb4F3WuG1qotac7OuQFmB6PLFGCS3A9jOPxX+c/xcnDw0mC 6REUw0n+mXbRHzPTf8yMVvH/NfGCf2f+80P4foaTr7e7vzCAIhlc+IYgEJYehpPIb+iRHC0Q2V9e RA/jBY+hh1Ok8IExGPPrOwr/rZD/WbO/t8sy5CUEWSEDxf73T8LQNElLlv1DYzkSzS3555tV/6OR AsCfNEHz/qShf4SwSDEvJ+YlcIYmxDSCZeB8SIchhuCL/qRxNA8wSIwkxTQKp8E4JELRfMgYOfE+ 0D9ScMF/0jiaEfEyyEp5wMuxtJgXxwiGgjSOAzQO4OI4RokxcJwB8kO8PAl5CbH8cJwjAS5BwTXj DEdDXrG+IF6GAPP9E6vEGCxYH/FLi0W8JNwvycP5SJwH6yNJuF+kB4CXQuoBMeB8FE4CuVA8Bnhp GgcyoFgKroXjwFpohgfjkEi7waDE9oF4WbBmhmKAnFmMA/tAIQniUhCDJWhwHizHgv2yOAZxCRJg cBgD1sIxYr+BeHkM0DgM6i7HQVvgKRboFTItIFMOeTbAy9BiXgIjxD5HwAC2j3hJMQaBUUB3CRwD Z05gKM2CvMAuCZwAsidwHocYONENL9wb8mHivSH/TMD5eFKsa4iXEcuAIHigBwQJ7QNhUHA+DugB QTI84EUxENBIaB+IF+gBQVFwPhoH/gBhwPkoqFcETcL90jzQK4QB/AFBE3C/TDdrYVgKrpkHdo54 gc0QDE+Cs2RpYDMIg+2GFwPny0K/RgiJBMTggKxY6HcJjqaBHvA4iD0IA/hnxAv3xpMMkBXPw7Xw BNwbTwKdJDEc7A15Tk7Mi5J6XHzmpODxAY0HNoOqEeCfUV6Ci88X8VLifQgpHhiHUjOxnIWCCtJY oKckQbNg3D85sGgcBWwQ8YpzLsRL0mAcyYM4iDCAPyUFZjGNwsV5GKKxwK+RKGeFtF8lrYjGg/yP pKF9IAx4RhQP8iGShvZBMiTIIxAG0EnEC+yDZGgQF5C1gTiIMGjISwHfTrJIOwCNp8B+UWkAaUjL xTQOZXGABn07wmDgOJgzkBwP8klk+SCvQxjQjjgeA7go5xevmRI0EGJA3eUZToxLYTSQH4WKb/F8 lHAikBfIT0gxxbgUDvUKYVAQF+YCFEouAAaK52AfOIxRFIGxYBxyxmAcUjWxriEMID8KxXMwH9nN WlCs7QYD+HHEC3wYRdHAZihkMuA8UIndDS+UPU2CmELRPKhNEQaoZxAviCkUislinaRQ5QjGoZwB jsOAn6QYHgdrYWkS6AsqDcD6GA7UnBQK+2AtHAniluBiwRkhEwS4HA3sF3kh4F8QBsiLES+UFUpf wLmhUg2sGZkMWAsPbQudONBdGmO7mY/nxPJDvEAPaBSTwTicBnU8LbRHIC/I0ZFagViGPA7wxQgD xHhBJQEGQYOcAWVNwI4QBohHiBf4OmQeIPehUe0stmmEAfQA8YIzQlk7C+ZDJRPApWB/CPFCWaH6 HKyFBj0jAQPEaRrV50AuNAtyfpqBuotSBlysu4gX2CDN0HDNLA78PcIAtoV44fkiVwLkx3ajuywO fCzihXvjYH5Fc93IgMOgnLlubIuDtopKl24w0ISQF/g1mudAPwdltvAsUZoNzhylneK1MBgDaTgJ YhnCAHUAg8H+FdICcEYoNWPEuoEwQE6NeEGsRaoG4gJDwXwSYfDd8II6nqFgPolSTDgfBfNJhoL5 JFJJ0HtgULwUnwfCgPOhUAFkz+BQBgxDw/l4eEYoXoJxDAfqeFROA/1DGKAWF0hiH8awDOjJMNyv vr0YA8qKZaBc0PLAfDzs2yIMkNMwHAn3i0IKWDPPgp4HwoDy66buZnhYq7FI78GZo2GQBm2f7SYO Cq5JrBsIA9QViBfkICyqncV7Q1oPciSEAeIR4gV2yXZTO6OyB5wRwgC1qdDuBLiorgX7JTlgbwgD 9A7Zf66C/6RRGOgLIHUGvh1hAHtjUZyG83Egv2JRygDHMSB/Rrwgv0LZC8j1BLUHskLBFuIyIBdl kcMCNEERIAaIg4gXxA+WJYAvYVkO5CAoLcaADNABgzVzGMjNWI6BcmZhXxTxgjqURSUTkCkP4wJa MvDjiBfk7ajsBn0zBAtyKYQB98YzIM/hUNYqHsfhOOBFGCBucSjDF+NywkUOoMGcGmGAPhKHEyBH 4gjYj+AImFMjDBADEC84I5QxgPjBkTTQSYQB+kOc0MgEvCywDw6pKeAlaeAnhTYrwKVoOB+Ng7wT YQB7Q7xwPpS+AF6UTAFeVGwA+aFcAOyDwUH9wTEw90YYwI8jXlAHINMCfpxjaZATct30swWzBDrJ suCOiuNIqEMsDXwO4gU2yHHQVjkehzJFBwzGIfMFa+FJUBtwPAd8HcIAfo3jCRB7eAz2FHgh2gJe HsieF1JoQEMoYhrKY7vBADGPF04E8MKeAloJkAHCAL4d8YKeDE/AnhsSKaQRsAfFExTQcZ6Ed7M8 yQM9QBggriJeRqyTPAXvAnmKATkIwgA9X8QLevU8UiEwHyqKgVxQOQPngzkDT8M7NJ4hQQwQ2qcQ lwF+CHkSkPPzbDeyYkhg54gX9A94FvbcULoLdZeFdzE8S4CeB8/hIH/mORbEN4QBfBjPYSB/RqYK fCxKi+GakYOBuBy0BRTPRXtDygzvQxEG8DmIV5xPIl5aHPNwDMfFNbGAIY4zuNCxA/OheA7nA/Fc wBDrBqIR4rwJ/3XhDWgghgoY4ngu8Ir1FBcu/sA4VJ+DtRCsWNcEXjgfiudAViie0xBD7NsFXnGc Qby0WE9xobEHx4E+nMArrkMRL+gd4r+aI4BGYED2NLgnwX81OACNE/t7AQPqKQP6DLhQJAK5sKCv ImCI/b3AK/Z/+K9EW0zjwD2igAHXwrJQhziQI+FC2xbgongOxnGU2H4RbzfnBu+nBQyx/xN4gU4i xRffkyAauF9ANEyclwi84hwd0cCdv/C0VByPBAygB2jDYB84ShPBfASUAY4zYh8m8IrzdsQL7qdR 9UGIc2U0jgJ+CIf300LlAnwiTmFQziR4LyXwimMA4iXEuajwLFdc/woYQE8RLzw3GuR1SCx4N7y8 OCcUeMVxC/GS4hwJ0UCfBtEIcT9b4BXnrMKTQHHPF9FYcZ4jYMAz4sB9CqKBezAcR8kF0A2OFcda gVfcg0K84I0DTsC3lwKGOC8WeMU5Dd7Ney5ceM8llp/wnguMwygQK1B4A/sgcA7IT3jPJZafUOoC DAEE0MB7UQED4hLgjgXRQE8BLYQCcQFhANtHvCAeCVdZYC0UAfIDhAFiMoFcLMClQF8PmTkG9BRh AN+OeMX1IC5ceUEaB+wDYQA/hHjhmTPdnAfDwPOlOWAfiBeeB8MB+0DpUDe84P2uwAtlz8KcEB2b uF+MxtHA/yFe4P8EdQFr4cFbRDSOhGvhQN8R8ZIgFyB48HZBwIBy5mFcIDFoR8izi3s8Aoa45yHw YmJcEoM+R/h1iVj2CAPkhCQG6vhfT6fFsieRSorlTAoPhyEv0GeSoMX9DVx4zwVoBHi7L/CK61rE C/NJ4T0XWAtJiHvDAi/wGyQF3tchGie+X0A00PcWeIFvIimYS6H0XnwfIGCA3BvxAp+DJA/yWJKh xPWqgAH8BuIFtoUyOJBfCdd0YB8MBffGgDdjiBfcH+EkEl83GCAvQZkAqElIDvowkgN3BAIGyP+Q BkE94DGQK5NIzGAfsHeNaDzUSUQSY1DCqyeIAXwJiYp2MS5K9TDxOAoH93kCBrBpFD2AHSGVBOdB CT/xghggF0AZKzgPtDPgw1DEA74YYYAzQrxABhQB6zKK7GYfyHWKZYp4gT5TJHg7gxwx6DXjQosb zIcUEJwHRQN/ILSpAQ3FbrG+UN3UzhRyf2AtKI2ANJjvIl5QL1AMeAuLaGw3NAzUM4gX2CDF8KDG oeDbaQEDxArEK+7xIF7Q90ZOEryJRuMYqKcseGeOCy1BgMvjIJYhDHEfWOAFPpbiu5Epz4MaEWEA XyK8BROvj8bAO1VEY0FPQfjho1hWNIaDeERj0OcIb63E+6WF2yLIC+oU4ZoE0Ahw343GgbtPgVf8 Nh7x0kAuNAneUAkYUFYEDepaupt4TiMnC+SH4jmQXzfxXHjPBeajwPsDRMNATEa8QNeQ9sG90TCG IssHeRjiBbZFdxPPaQb6EoQBbIvuJp7TDA3nY2EdjzDE70oFXjgfiudANzgM9KoQBoi/NEsCP0l3 E89p+LsnAUPc+0c0aIM0j4HYKPwUpRsMkD8jXpDX0Tz4TaHwSwXgT2n4uyxEg2fJCC+DxDSh8oEY wJ8iXhCPGCEyABrsWTJCtQF5gR4wBLRVhoCyYrqpxREvkIFwFQPWIiSPEAP0PBAvyBkYlACC+VA8 h7wMlClKCsF8FKxTGOFRKhhHAT1FvOK7Y8RLgXqGYbqRAQ3exgu8wLYYhgC2xTDgNyECBoiriBfk YQy8y0I0FtS/CAPUGogX5Ego7IP6l+HAm0UBA545C3sKDAd79SwGewoIA/gXhgO/exJ+9gniDCto PsQAvk54YiPGZXGY5wg/5hbLgBW0DfKCexKWgPk9SxKglmSFZhCgwbyYJcG7XETjgeyFn9l0wwt6 r8jdQ/lRMO6zwo9RIC+UHwXeqwhZBOhjIgzgh4QniwADhSgwHwPe7AgY3eAywAaF55NgzSwGZcqQ oCfIMhTo0SLTAneQLPztMKLBHlQ3b8FwlsNA7s0i1QX7YHkQB4W3YGDNHPhdvtBuh+fBsSCGCm/B wJpRCSaeT3jPBcd1cx7/r7BzWdVgSc7r/MB5hzPR2FV5T2h6ZBk8MkhDoUFDH4HAuKHdA6Gn17e2 MJhYBZrtHdT3R1ZWZmRkXLOE6nMf8VzveZWvAQ+t8Y94rmC7ZFNu7Jrn8ypfA6xkXdQXj6V57YaH x9KUlxXa1d3lfNiVT5aV5rkpTy5YxbO+J6JEY4maree64lmDnbo75xqlcyY8tP6ClV35TOuEZz1a L+Gh+36wkjkHxUS043n5sHufZd0nK1zy70RI6N1yIGltbJ8fOaJ0dkfd1T4Kj4+xWBeNGuuxXMuc 8JBNIVjt6XOHdL1LqIyeU4wNWO3pqOMay/2wK9/HewFVvq6riydbtK1vfh/F2IDVer4ffqbbhvTn +zoW4r6q7RCsv9vtXXfJizPGWOnPt/u7EZPl5xxDEKx0wkgInXl3KPY3NJ9HwWqt3flI5yImS7Th uJZgtWfutG+RmCzz9TkTrHQuUnn0e/vjPZZinsDK3nS3fYs356q+0W6eg2098Z4me9N1jDU8dMch pUG0+/jdruqwwEN7OljJg3tP3YONbFB9y7u8p++p/n1qjNX5a3j+RPPZDbbOX8MKKh5NuSPtx1Nn bD1Tgm3VroI7vtp94FHnFGy1WbanP3VfhraqHgaPqnuDrXeh0E69S+JRr3onPKqNDGy9+wW76h7M 7Elm/5R60XM5KjTmqfOjRerWeJA8p/MDbD0/glVuRmin6kihvfVOB7baRvLVVK8qtFVt8PCocg1s PQNCk++95bpa5RU8qo0RbLXnBKvcw5ajrJ5HeU7yCmzVaRpBs3VO30fnRyP4V3N/R7UXN67T/r1b 7wuNYMn6zYP1772v1hXBPfW7hYfWBgFdeg7totLarOcCPKrtJjTl1xLdWWVsw1Gs922K0QSrNf52 xUDmBvHWOx08qm4Bturt7cfBJZp8zNxSqg4CVnISo77GPLfWBs6JD2yNa2kYVes6fdfU+sOwbJp0 s4bRSOMjYU3PLY956T7TfgwIlXaUD9EoRaN1sGX/wxta9diGAu3nlC/UuMDpfe9b9b/2o3CYh86y H8VYNPkWG4LNfOVfBavfi9DRmFmAdf6a8yvAVj0n2KVv2ZrnnsVmmmzrVKz0+IZia+Ghbx6sxxdx Wvd+m4rTgkfV5UOTPyBYxa62tmT/g4fHPL1229LdvkUMSW8KD8nEtnq1J1JqrerZoSm2Fh6Sz23r Ph2a5Xg7H++x5ZcE67k/8u+3aHqSz+HhdRCVS7Rr+UydLD9n+Rys5p7Sn/495YjBQ3MQrGRsf1WL oVGwts5BeOgbdaK2RfsYS1O+Gjyk1wWr8603xao1YrLq9+i2XYPV983s6f5BTJbmoMu/D1Z7urvO Tsux6vcYig8DW23wlA7UuupTcaXwqHZHsJIvhKFoLEu+DnjorMVMKNo60tH7HtqX4aH9FqzOsr6t n+ZaobtGtBLP6fZ9geuMnruKV85zilcG6zm4H2O58huEJj8YWOlw41GOTiOtTevvKocoz6muaWiq GUIpYN1nxqM4GbCag2wFrY3hWjnw0NogFKLO88i+1Fi6bKqEREs2DecvcKqa73iqbQ4e1T4EVnfT MRQvENrRPg+ParsJ7a02FCoLS08crhEAD+lrY8jPHqxquEQVGF4b0/toEOQgrHypUSM+1uka1RYO 1r+3vWeGYyvg4bnaQ/dfyjP4947f7TySOcHqLBv3kbwfd+nOHh6S95gxNS/RY+vvRTJ5/q5tAMFK D5uPZfF8VWscHpq/6Vo+RDBr3c/m7xEeOreClW42o2XWbz6bvwcuG40lGm/dC7PLnhja0tlNqZz6 PSg96987mvs5huTf7LLpg/U8ByoeU3H18JAcCtZzP5U/k5u9YivyXNedJFjJnLnkwwjtSMYSMlb3 QrBaz9GUPVdbNTSCzaXTWOlm0zEYpJPIdjMdIwJWuve0Lzo3MNXIg4fXKY46YZWr31CRNJaruuyU OdYeXI/8v6GpfiI8NM/BSp5SDkq/9ypuGB7SGdarfOzQ5LfPVW1K5oRH9ZOAlc6aFa49s7rqAMFD +l+wNeY4WNUWiWCyPr4chwJWd6HlXORGhxG974c+vlwDO1jVMwrtSFcJD917gpUfYkWn1nNLPQXg 4W8+lf/bPmp2UT5bcmh96PzRGGQrWFt1/Uij8vfYihMMTXUHSd/y97iqZ5TnVLsSrL/H9bm17sf3 uIotA6t9vq7ySNt+lNsHD3+PqzzXRtxXHd9+1Qsiz22NeT++g+1XeR1Uq5e+u1/VeQerMW+0/krr Pis2linRuuTLdn2Q0FTHITTlvoL1u43Hv5frpflaxu4hf3xo12OeqjVESqHOo2AlE3cOLmHXx9zn ADZNtROouuDxHZ+Ne6k2KViP76geKCYyz9/xnTNHt+fl+gwlPNvP+YzfzkkKVnUC2/nw2RDjVefv PKpj2M6HHzYSUfcjanaZr/3Ep1nHPO3jPYjQMVZzf5r39OnKVYCH1sFpytkL1j7rkwu6nxuS98R9 VZlNXJWw85GdJjy01oj70u85dis01f+Dh3yLZyr3KzeNj7Es233CQ/eKaJNa9/lqNSahUb5d32Mp 3hus9vTZiunIRVe51/Dwu+0lPfac4fe4ipeCh7/lcfwBsVv6vlf11kOzfzVY2aTvoxjc0BSLDQ+d 3dTiMu0qpuO6njQ8tFeDVXzEfVVXKBPVpYte5ziB9ViabWm3qx5FQ7Wo3zdYz0H/GMt4dCbjPjdf 1ailWp/fY9hGER5+N+ci43KQ7khdq7pewsNr40PPvvNobdylOmPw8NqYPpNzpMiGd7fPAOKvNL5l O1w0avM9jv24WzWnwOouHjXRc5CNpN87ysULTTFeLVtV99WonbrHh4d0i3sV4xWaarD351EtTHh4 H13pdf/Z57HSXq1TeNR7Hn0h/Xuv9kwnsmCaR50rsNXf0/Ha+PeUtwiPKnPA1rMMC1SV952aWMaq /gvYug5Ck7+sPzkC/JzqKYCtvgSyo+rZ2ClOr7nK0jVN9Tax1nlOl2pPwMNjdh2+YOW/DE3x8vCo 8h5svTN1Ch3r91zXqv8UbDa23iH6T2HYSnPPJnjU8xes5/nIf5nblvJi4FF9O2A991e9ejo1sT54 1DvJjwu30l46/YimnAF4VD0CbL2T4E7WXL2vahfBo56hYLVXKUokHk253J3iSqZJJgar3Nz+U1jD PLROX5qBCava4JEQyrGDR5X3nYIZGssY2oMfsVHw8DwP9QwLVn2maL9VdX541DtE/0nIrrTo46ZJ H4dHtaOHduvdL1j5t2jTpfX8Wh8HW3XRn7AC/R4XOPPweo4+rt+zPo72J7lGrJXGbH38JzxC2Cs7 a2hv1TfA6gxtj8740FTrFB765gRA1/XcHsU79vZxroaHvnl7FO/Ym2v09Nbkh4VH1c06sVt1XghS 0u915VbBQ98jWH2PZp2adnL6HgSnfGC1zwkt0zcaytPsP8EBxkru/jgrK20qNrQ316YHK70Ed7xo SzVM4eF1NZWzEqzyygm70d7CgK/fW8p7D1b1SzoiW7+3FX8K1u92FH/aSQ0X32MZG6x/7ypOPzTV Ye5cqD+wkolRE/Ut+/Mx91fx3mB1pqCY1PHxInUsKFjmq55mwco+/tPisMoDSlLWbxSsx9I/xjfU g4IQr3rvAevxDetNxFDVueof52qw9V5LiJfWWp+KsQlNNniw0s14DdM+3mPK1pznHr/Hkl3lZ1r0 bssyJ1jJ8XwOyft+ZHuFh3T+XEkk72niLr5XPk14SM/uZ0injpj0+ruqQQePeocFq7VGGZaKHY/8 q/CQXjw+ztrxWI6PV/GO8ND3pSSqnntV67lj3hX2VbzjT2k5jc8xVNluPss+YrzAVltQsF37jfRf 0bpiccBqv7Et6/cl/krvMZT3BNbf1/arTmxUXWvhYZrtV4gXf8ulmA54eG1EzxZtyZfQiY3Seyzl jILVOqWtm7BH/pQ8p14VYL02jnqMhKZa/PCQLhWs5+Wqtnofti3Bw9/jytYcmvflfHwGhIf07OEe D8EqLjLHh+/O81HsG1iPxf2Z+kccVCdOS2OhapKw8td24qDq+xKnVb/btL822KYzgDgojdlxWqEp FqJPx16Gtqr9uX/EaXX6KOrdhmKd+5zqiQQPnbXzQwfOCe95yTVP8+f+TD9tkcVjqW5KJ4ZK7+s8 Q7CSidS10txv+QzhobNxuj9Tn+6xFNrSvSI8PL7juz0pU+JxP+bAPaDAep1e5cpgQZH9Lzw85qs6 +Z2yC3V861UeODxk/1t0ABZWtZpCO9KlFkmKxvrdmvplhabeYv0j1gqs9uVqtqusLt8iPHQPDVZn Y04U3Y/WaLrPrEg7jaWrNyCVuKSrrKnYUHhIxhLWrPFN+egpCyu5sabi6sHKNkzPRPFdWzKHno76 vWV7yYpOrbnaU2deeHiunBOM2i4dbp0uGba2fQRrq49OsLZ5ZMiS2esohg+s/B/r2ga/rvWD8JCf ZDmXou/HPpGde6j2zLV+sF2fOjTVMsuLKe8OHtKfN12WhFU+WKfvYf0e+1UOKljprFlpWkPb+RCd OC2NmcRAYbvO5O1ak/DQ3t/cCIW1Pk5slGmPdNH9oY9vx5KEpnhHeGg976H4jWAV70gakOTLdi+m 0BTvSPqR58A1tvC+Sb4EK/myt8+tfVR3Ic8p9hes7vb7qE9NJ05L3zLnvmmKo+3bsZd9u55HsMoN Aqt9uT/sV+dRTFGnjpfe48N+dR7V0uvUyarzch7fXc6jnKRgFW/WP/oewkNjPq/izYJVrAHdTbU2 KENa12mwWmukdwvb7Vs8eJSNlc/6dNUFIyVOelM0ft0DgpUednIx0/iW/ZyHC6axHt+2X+Psj/Gt q/tHfs1j2ao31+lJqPnbH+Pb6scXrO2sHz0J4aH9RpqSxnctN+gr6OcUex6a+o0Fqxjm/tFXEB6S ifexTYYrtp57fX+jxpbegy5fotm3GE1K+st9fX8LVucgKZTi+3GW0buwzt/98BMzzcKOx3PaVesl NJ+198PX+9FXEB46F4LVume5iO+075O+h/puOWv13FSeYf+Iv4KH322q3hJtBiQT6UkomuOvwMpn eLd6hiHBvIairOj3tu1wlJnQPGcT6j3Oq/Pjfvhwb/RYjfmqHiM8TLuqQYfFo87fiDjQeX6vaguD rWMZj/09g3SmR8/JnwK2zsGgkvWqtCabETzqnQls3dMDcSVsV80keNR1P36ytIVVbuTgtDjmUWUx 2Lo22Pn1zAtNtozxI6GNrXF4ZAlXmR0OukcNYq08llPt48GuagcexFB98Kj7A2y9xyOF6hmQD/RW eQ+Pev6GJv8MrpN6fwtNPc3g4bURuaH3ONKbBjFUxqp2DNi6Z/DGe66u7mDw8L48qkVN91qtXY5B zfNV3wKw2jM5frWnaQRYx0zzzDovNMrUWF711h40e6vz976KGwZb73TjpZqUaJ4r4rREoyqWaNLr BuGiHzy01kj10HNdet2gDpXmqqsXBFjtS8r/1bVBswphh2UTpfM1946LpHRCvYPBo549YLV23+V9 RB0q8VhPvTOBrXaa0K7OAELo9W5LtdDBVj0sWOVHDQr/asxb+VFgvbciEjUH9/VeyOVFYznqmR2s Yo+weFQdJDTVKQIrOdQoGyyaenPQEqn6gMBWW+mgmF59t2jtkrEUBazv255bfRjjp/hYpTXZGeCh uc+pr29Ooac6Vy3nqsbc1LsabNUJB23I9dzHuRoekpOt92rTD7ZJJrbxMVc5HTVm51JEyXmqDjxo K+MxH63xYOv9Y/wkqlfa0t0FHpIHzXlUwapG2Whb9R3hoTUebL2/DRIhNS/2J+Mh8BrfqtU56K2o 73bkh4WH5Djpb3q36NTCXtV3hEe1P+c5xebRHkx6cY9K+MHDa+iqx8ig72HF9lcxbfCodgaw0m37 q3pVhFZIzwmParcFq32Ur6ZzlTgtYZv89mClZ/eufsyDwCCN2TYysDprc8WWftCHavPBw+/RrR90 274GjmfNy7Ae1seSfOnOHR447zTmqDQa81QOTLDqHTdwROj3VpNugQNONMeSjO6aHKEp3w+szqN+ Hsm1ftRvbGAc1vse1Uyii7vGF0XWYzk+Q0krr+OjrHjlMV71PYRHtUGF9mrucwSYRqUOPad+aGD1 PSIUdZek7JvmoMknAlbnTBaRzoUxrKOHh86KYLUvx1BuUGjKj4KHxzLkwxjZqpKTY/reM4byo8Dq XBjT8nks33WH45pDs3weS7VnB6ZrffNluRuNRut+hK3GbPsVPCTbh+vmEfqm+zkmeL2b7VdU7ZZM /Ii/GsRf6Xsc5fyMj/grSpRpH81HObLwkB1kOG4z2C19iPgr0ezbAas1TvyVsFSQ1XOKBwar/Uv8 lcbcH+03woH1e847DlZ9RwaxUXVdhYf2Gz0J9dyQL4EuYtI3wkNrYw7FkdFRVHuf2Ki6xsND+gaP iW9Ejvgu5cjmOcWXgNX5AUl8t3XH8JA8JRSsrtO51UuIzEjdhcJDtrmINZ0zM3qseJwtHSk8/I3O W/32ocknF5H4scaPagGDlf43r3o6jvUod30Qa6U5uKoZEqxqSoz1qt4wPPQ9gtW8rFd1nsbKRbnO AbFWH1itNdSmOlerKYYAHrrbr1xrNVfRY/VcV1wuPKRPrujZ4tsV70h5R8ls+g/WtUH/QdGG6jcN 4qA05qE+F6FZt6D/oGhLMZ/wkAwLVvKKMuqa06XcEXho72cG5JtYW/HegxpWGt9SHxiwWvdrqx/f oN2T+aofH1j5YmAr7P1Yu0fxDKF97K2ruOHccB7Z25drz9I+We+2H/VuDU212uEhubFpsVFpr2qD h2Y5Tq0rPfdcve9+Vcti7Da0XsJDd/b9YfvaTX3JBi4MvW9THGNo6psWrPXsjzpU8NB5vj9sX3s0 6c+YZOpepU6W5n4oJwn11PMyFRsarPoqgNU5uKdiYcdHbFSe29K5tnMpgl3+5ls1xeDhdeqcYFp6 y2YUTVRnCvFXem6r532wH2NxbFRoqiUA1usg06zve1U3GR5e9/fjW94rPfY8tnuHh+T9vuq1QFld ybrsItn1wkP74zyqsco1Rb6x3Jxl7wwPrclgNS+ndelDufZU/zk89M0PCbuV1hWzSPUcffPj3klg JbNxQ+i5od7aZDhp/Z1um+VxXTqiSySfKbNorO0gkbrSfTiiNAdzSD4f95Ygi0oy4mzFhsJD9zfa BYrvtgw727ag8PD624pdxRuve8U5igeGh+RuVGqvg7O9/q5yEODhuT+q2/OT9lRpxHhpXq7l2vnQ 0S9my0p7VSMFHjrPg5Vudl/vmUgcrb/74bMO1uNryocNzXN/X/Wyz3PKhx23e63dqfrK8NC+vB97 +k7LbK5b4jstx4P1WNbH+JZ6bMJDsj1Yjy+Kot5te6+Gh+4uweoedbd6fFGmXPv8o04WWMmme5Qf Ou5VfbM8Zz9dsH6P6z1N/JXe49pPd69lO67ewmMSf2W+ikUEW+9Rk/irUWmv+pNM4q9eY6vNMljZ HekoUOcUHlVvAlv36qRLhrBNPZtCky4Ptt73509VE9FUXyA0xf3Pn+oxlTb4r9LWB/ZUu8okAlDj GzpXJ30ARRta9xOtSzym7nmU3a96Jzy8DqZi2YNVzbhIK+mnP6X99S2XekoFK38P2VZVF50fta7A 1jN0PhRjFU12Vnh4bbiXON1cq74RySlfGzyqTAxNMcdI3Wr7n29ErH7vyrYEtuoCwUo/nR+xUfCo vgSwVT8NVnn0823Kq8xz8ueBrbE987X9KjTdieFRfQShWW7kSK52uNB0HsHDY7EPN7RTdYv5jlHt XPD4GIt8aMEqtmLmGlD1+zwnvwtYyef3Y19GCvn7TvUDAiv5/C7lBoXmdfou+VfB1vNtRmuqPubQ drWhUEleMpHSSprnrd7L83UeHzyqHhGaYsqDlc+Livg1Hgke3pdHNhm6W2kvZHt4fO6/MCnnVsfc HtngJw1O61jCQ+Nrj+oVTBqImqacEHhUnTXPKbc0NPkgZ2sfc/Dueu8BW+/dk8Z4eq7rHjWbcwVD Ux/tSdMw/d6QDwMe2gutyxczabykbzQU7wMP6QJtKG5pZqp0HrWpeGB4VB09z/k8orGHxmJ/Mjyk wzX3HsXqrX3etmpdwUPnfluqfxrslHxu7u0JD515zT3S6FzjdXp0r4VH9fGB9Xejcb1o22vcOj9Y f6OruGFcn9JFm3sngdXZTRHOuv76q1hdeEinIXZLY3HuMCU0JA/6q56iYDX33TkNRPnqbtDd4wFs jR8K9mMsXXGC8Kj3ULA6GymQpN8bihOEh3SGn6JJwh6/x5RtHR6SB33IFxPsqjZkqm7pjkMxEL2v 846DtT7eaeJhHtIZ+oc+3nfzes720Fi2zxkSvPV7R/m6oW3pfz3LXnN6Hs/VUcz27K4LCw/pf8Hq 7OmOvaQkTLVVwUPyqrumXbD+HuNVnCA8tNbG4+8xbL+aBHJrzK/qDYOVDKNdYF1ro6nHMDz8Hs33 vNHUs3j+BBnqOd9dhu1mwW7J2DEUJwgPj5mqA8JOnftj+t4YHrqHDh4UVn7OSXCA5nmqbwFYrd3h vsOEpmithYdkHQ5+0bZs+jNap8eSpSu+uWNrfK71HJriGOePYdRYzct8fIbOj3MLA1Yd83StjTnd 13cSB/XBQ/amYHX/ne4fOmdTvA88ZN+Y7h86UezqXHFVq2syPCTbg9W8cBDquW75zIFe1/N0r6NJ iINpqsMSrOUzsVt6j6FY3UkPQY3PtdrBSj+YzlWgrJX0duKvND73LYWkO0Q0JH/fpZhKsNIZiKES j22bUXj4+27b4eZRrcnQ9gdWubR5Tj710FQzc85rXT48vO6PckbndB7BXI/6pMNDdoFgpUstx15O TA917onxqr+3HuXdzeXYy0kdqrpOKWta55n4Kz3XlBvE8pPMDg+tjYhnj6U/kmGrK3cJHjoDiN3S +NwDlBJvfg/XyQKre/yyH5ZKNOY71JMLbPVhBKs+o9nRyiuHh2wAayoHi0qYsrXkGipbwXKPh0mb Qs3pfr02tnyk8PA63cormsu5wzmMVCcfHtof68PuvZzXS6UDnd3rKMYfrGQErSoqbT8f6/QO3VeD 1TrdOE9EU92j0OQvA6t5pryKfu/1Ot3OuQDr32u2+Ubs6gwND62hnFCyle6mmIRMqGLa4CG9natV /ea7K9YP65DsB7url25oytEOVrlB86OGFTy07oPVHWJPxTtO6lBpDtwPLTTrnXvadrOXfYt72ra+ p/JTglUM6dz743u49iwWMp1b23m92bwfc7U/vsdWXHOww2v3Kh4YHjo/9lEPgGCV1zupQ/XBQ7pP 1BLpPud5JHfPo3xdeGjug9XcHwogVNqrGEN4SJacx3a488pHn5Wh+qfw0Pwd17QLdujsPl018eHx QVOflWDVzzU01dAITbX+wErmRApJJzzDdtYsDcmIYLUHj2MvyeCVPp6buPZbsP7mU3WP5vnQx8+H Pn4+fNHHtXyiiipvJ89ZHw9WOmtUZe2Zs22/Px/nfrA6a89Rvu48H/7k8JA8yCrwvBz1LyNFQjrX +fAnn6P+ZcHaXnIf1QiAh3SfYLXP72N/Mq1cRHssmyivV9/3OqchNNV4I0tOcpeS+KI127loSVPn 9NIcxljpZsRQiQfGUvPQ97gfcShRzeT7vMO+jvCo8ayh2UZxyUqqNLxe5iHZecn+EtZnY05V2UA/ 4shCU/x9sB/fbakmOTx0b7zLsTjXvdTmR4wXPLQXgpXORRl1YY/qucHD62o7LohykcJe+6jCw3Nw VMOKDq/196h84jHfj310VScwWN2jFi1PH/OothawVWYTwVfvl4tONcM86nkJtuo+iy4AvdLGU22W eU53TrAey/gYn3MA4VHPPLAen/XYHxPFB48qE8FW2b5+TtZKW6r18pNKZr7yPQUrOb6eLdsrlZ7r ngbr99iyq4Smew88qs8mNOWHRnmWfA5NdVhCe+oZD7bK59DkXyX6pdo3qIpd9QOw9SwLdle5toiN 8nPqrwtWe/V9dJ9exF/VMb+P/Ktgqw68iL8SluAPPdf0fYm/0nNN94XQFI8Oj6qbkQZZ7wvrdczx Iv7Kv+d1/zb5HKjoVG14WG6q7ISH1sHrGrDrtR92kYah9xiqJwPW33eqnswiNqqutXcqpghsvRsE q15ldAqt5xY8vDasZ6/XcZGL2Ci9x1JNhDynGPDQ1CtqUcPKz+mMB+u14XyD9TqPDx5V9wHrebnK o48GIttSnhv+Hlc11Eib1b6kPE19t/DQucCWES3nZX2P9sqvAQ+PxTrwT/qvsE11XeDhsTTd7UNT TePVunxUizit+t2C1bpq2Zca8/B+I07rA1t14GDVx4RuJ9XPvojT+sBq7zf7YUPTHSw01e4AW++6 i5K8mpe1q/0KHjrLMDuKx1LfjPURQwUP7cssA8nEtuVXw+rt8W3d80JbOvNy7Xk0V1f1QeDh8R3Z GYgK9zq46iMGD+mE7crXhkvkg/YxB1dxI2CrrSW0q+/bnccHD8mD/lgn7K96IC8ab+r3XvXDCE01 jck4057uXX57eOjs6U02mWBlVwlNsfHw0BlPg8S6NvpQLdZF8y7/3tX50YdsLWTnaZ/T7EhjGepP B/bR+Kbi73/KH4g2febRxEjrZak/3er7lc5AnSz93lJ/umDVmyM05ZWHphoVYP2NjvwpC/Ok1t+R TfrHPWiafDuLQtt+TvdusP7mVzUH1rCvN8/p7gxWc09ZxDr3FHKtczoexeKA1Z4Zr2qL5GaluvHw kM7AVqjzPBwXuYiDquuU0uqmKZdsDedDhKaYCXhU/yXY6htbhEFpXoZ69MFDOgMlZfVuQ70L15jK DaKcx6P3jT6u93Utn5VTX/tjzF7temClh1HoRNil2ArKkmh/BCudOjcXz8H2WYFJ/wOrfTn29fc9 H99jb927SbgX3/PxPa5i4/Pcx/c4H98Do2ChkdynMd/uMTuXIlj1MVk/iVTmofcgaa9+yxl1rX63 +arecLBX5yAJUuLxqhZ/pLjvFdO1Z8FWOzUnQM2pWQQTa8xNtW3A6iybOVSEHfItwkN7Jlit3TmU G86Jp7VGMKfebag/XbDy+WfAygWFR7Wtg/X4tupUktFQbaU7GnDdRz8tperc76a43HWm6pZFMVO+ 2rpNPb15Tmv8XtUrzXO201znB+zn0f0tNNXI47l6/6C1WNVf9qH7aH3uVf1iujdWORnFVn3O6HBT /RU8V/d0tBfd8zZbpv4eLpv6e7nn1T1DJbO6DqBVfQNaXc/Q6jffNIuvPI5r30GrMXfQNObjuM3Q pNMQLlD9VtD+f1vV3/76p3/937//9ddf/vCHX3/5b//4r//++2+5Zaz8/Q9/+cvffsuX++0f8s// /D//8pff3v/3z3//7Z/+QNHU3/+U03f/PufJRvzzf9qs+/xTToo///mP//UT//zrL3/846+//N+/ /emvf/u3v/7+L7/+ktF1mP/d3/39//ofv/7yH1BLAQIUABQAAAAIAEVeby0gu/ym6MIDAMPwDAAT AAAAAAAAAAAAIAC2gQAAAABIaWVyYXJjaGljYWwgUEUucGRmUEsFBgAAAAABAAEAQQAAABnDAwAA AA== --Boundary_(ID_tBfXfRGAMpXzaBktuQdoaw)-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 15 03:46: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 DAA02959 for ; Fri, 15 Nov 2002 03:46: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 gAF8mmY01300 for ; Fri, 15 Nov 2002 03:48:49 -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 gAF8mkn24362 for ; Fri, 15 Nov 2002 03:48:46 -0500 (EST) Message-Id: <200211150848.RAA04398@infer.nal.ecl.net> To: ppvpn@nortelnetworks.com Subject: Re: Bridging network or networked bridges In-reply-to: Your message of "Tue, 05 Nov 2002 09:18:18 JST." <200211050018.JAA66735@infer.nal.ecl.net> Date: Fri, 15 Nov 2002 17:48:22 +0900 From: Muneyoshi Suzuki X-SMTP-HELO: infer.nal.ecl.net X-SMTP-MAIL-FROM: suzuki@nal.ecl.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: infer.nal.ecl.net [163.138.70.32] X-LYRIS-Message-Id: This is updated version. Thanks, Muneyoshi Suzuki -------------------- 1. Reference Bridge is defined in IEEE 802.1D-1998, 802.1t-2001 (amendment to 802.1D), and 802.1w-2001 (RSTP extension). 802.1D and 802.1t specify Bridge architecture, MAC frame relay operation, Bridge protocols (such as STP, GARP, and GMRP), and management protocol. And 802.1w specifies RSTP. Note that the 802.1 WG is now discussing 802.1y (corrections to 802.1D, 802.1t and 802.1w). In this process, STP may be officially obsoleted and replaced by RSTP. Note that Bridge implementation of many products in the market is still based on 802.1D-1993 or earlier specification. Also note that there are many cheap Bridge products that only support MAC frame relay operation and don't implement Bridge and management protocols. If a user install this type product, loop free deployment is the user responsibility. VLAN is defined in IEEE 802.1Q-1998, 802.1u-2001 (corrections to 802.1Q), 802.1v-2001 (protocol/port-based VLAN extension). 802.1Q, 802.1u, and 802.1v define extension of Bridge defined in 802.1D-1998. It specify extended Bridge architecture, VLAN tagging and MAC frame relay operation based on VLAN tag, and GVRP. Note that the VLAN defined in the IEEE 802.1 is NOT the technology that emulates multiple logical LANs over a single LAN segment. Note that the 802.1 WG is now discussing 802.1s (MSTP extension), and some VLAN-aware Bridge products support per-VLAN based STP, which is proprietary protocol. Also note that some VLAN-aware Bridge products in the market support the stacked VLAN mechanism which is intended used by SPs, and enables transparent forwarding of customer VLAN tag in the SP network, but is not yet standardized. 2. Terminology used in this memo 1982-style Bridge: A Bridge that supports only MAC frame relay operation, and the operation is based current or earlier 802.1D specification. 1998-style Bridge: A Bridge that conforms to IEEE 802.1D-1998 and 802.1t- 2001. It may support RSTP defined IEEE 802.1w-2001, but does not support VLAN capability defined in IEEE 802.1Q-1998. VLAN-aware Bridge: A Bridge that conforms to IEEE 802.1D-1998, 802.1t-2001, 802.1Q-1998, 802.1u-2001, and 802.1v-2001. It may support RSTP defined IEEE 802.1w-2001 or MSTP may be defined as IEEE 802.1s. Bridge: A 1982-style, 1998-style, or VLAN-aware Bridge. Bridged LAN: A concatenation of individual LANs interconnected by Bridges. LAN: LAN technology that provides the MAC service and is defined in a series of IEEE 802 LAN standards such as IEEE 802.3 Ethernet LAN. Note that "LAN segment" means the medium connection, e.g., 1000BASE-T, between Medium Dependent Interfaces in a LAN. The use of this terminology may be inappropriate in the VPLS context, because it is not intended to provide medium dependent service. 3. Customer View VPLS service is enabled by a logical Bridged LAN, which consists of physical or emulated LANs and Bridges. This Bridged LAN provides independent VPLS service instances per customer. From the viewpoint of VPLS service customers, a service instance emulated by VSIs in PEs for a customer is equivalent to: o A LAN o A single Bridge, that is: - A 1982-style Bridge - A 1998-style Bridge - A VLAN-aware Bridge o A Bridged LAN composed by: - 1982-style Bridges (loop free topology must be ensured) - 1998-style Bridges - VLAN-aware Bridges - Bridges Question: Expected scenario from customer's perspective. Note that if a customer interconnects customer's VLAN-aware Bridges through a VPLS service instance, it may have to be equivalent to a LAN, a VLAN-aware Bridge, or a Bridged LAN composed by VLAN-aware Bridges. An issue at here is what should be emulated by a VSI in a PE or VSIs for a VPLS customer. A single LAN or a single Bridge may be emulated by VSIs in PEs belonging to an SP network. Also, a single VSI in a PE may emulate a single Bridge (remote-Bridge) and the emulated Bridges may be interconnected by Ethernet pseudo wires. 4. SPs Requirements VPLS service providers must estimate order of the maximum number of customers (e.g., # of service instances, CEs, etc) to be supported. SPs may restrict maximum number of MAC addresses supported by a single VPLS service (or a single customer site). Questions: Order of the maximum number of customers assumed by SPs. Thousands, tens of thousands, hundreds of thousands, or millions..... And, the maximum number of MAC addresses supported by a single VPLS service. Tens, hundreds, thousands, or tens of thousands...... Note that theses values may strongly impact on MAC forwarding table size in the VPLS. 5. Implementation Model VPLS service is enabled by a logical Bridged LAN, which consists of physical or emulated LANs and Bridges. This Bridged LAN provides independent VPLS service instances per customer. A portion of the Bridged LAN is emulated by VSIs interconnected by Ethernet pseudo wires. 5.1 Support of VPLS Service Port-based VLAN (defined in Annex D of IEEE 802.1Q, 802.1u and 802.1v) enables per-customer based VLAN support, if a port corresponds to a single customer. In this case, a VPLS service instance for a customer may be equivalent to a single 1998-style Bridge or a Bridged LAN composed by 1998-style Bridges, except that the all customers share a single STP entity. Thus, VLAN-aware Bridge can be used for the support of VPLS service in the Bridged LAN. However, the current VLAN standard supports only 4094 VLANs in a Bridged LAN. Also it does not emulate a VLAN-aware Bridge for a customer, so the customer network cannot use the VLAN. These may be unacceptable restrictions for VPLS service providers and customers. Therefore, development of new layer 2 technology that supports SP class VLAN service is indispensable. Note that the technology to be developed may be independent from layer 3 technology such as IP and MPLS. Stacked-VLAN aware Bridge, described in section 1, is one of candidates for solution. Encapsulation Bridge which supports MAC-in-MAC encapsulation is the other candidate. Stacked-VLAN aware Bridge may have to learn customer MAC addresses, while MAC-in-MAC may not have to learn these, so the latter may be able to reduce MAC address table size. Note that MAC addresses are not unique. VRRP assigns the same virtual MAC addresses to different interfaces. Per-VLAN based STP, described in section 1, also use a similar scheme. Thus, if a customer uses VLANs in the customer network, and if the same MAC addresses appear in different customer VLANs, current Stacked-VLAN aware Bridge implementation may not distinguish these MAC addresses, because it does not care customer VLAN identifiers. 5.2 LAN/Bridge Emulation PWE3 WG is discussing point-to-point Ethernet pseudo wire, which is described in the following drafts. draft-ietf-pwe3-control-protocol-01.txt draft-ietf-pwe3-ethernet-encap-01.txt PPVPN WG will use this pseudo wire as an emulation technology in the logical Bridged LAN that provide VPLS service. A portion of the Bridged LAN is emulated by VSIs interconnected by Ethernet pseudo wires. That is equivalent to: o A LAN o A single Bridge o A Bridged LAN (or something like these) One of important issues is that the layer 3 technology is able to support logical LANs/Bridges, however, emulated service may provide different communication quality, such as throughput, delay time, error rate, and reliability, from physical LANs/Bridges. The VPLS service instance handles the Bridge protocols such as STP/RSTP/MSTP and GARP/GMRP/GVRP transfered through BPDUs, as well as, LCAP and MAC control protocol for PAUSE operation received from/sent to the customer site. These protocols may assume LAN class communication quality, however, for the emulated portion, it is not easy to support LAN quality. Therefore, robustness of these protocols must be identified. If it is problematic to use these protocols in WAN environment, which may be low-throughput, long delay, high error rate, low-reliability, in addition, frames may be miss- ordered or duplicated, MAC frames for these protocols must be forwarded in high-priority or through a special communication path. The other issue is how the service instance handles these protocols. MAC frames used by these protocols are sent to multicast addresses. Emulated 1998-style and VLAN-aware Bridges must terminate most of these frames, then appropriate action based on the standard must be executed. On the other hand, emulated LAN and 1982-style Bridge must transparently forward most of these frames. This may decrease load in PEs. Note that emulated LAN, that learns customer's MAC addresses, and 1982-style Bridge must transparently forward customer STP/RSTP/MSTP BPDU frames, because these don't join the spanning tree. However, when a customer network topology is changed, the MAC address cache in VSIs for the customer should be flushed to reduce the time for topology change. So, a STP/RSTP/MSTP snooping mechanism may be required for these implementation. Also note that a loop may occur in a customer LAN whether the VPLS service terminates customer STP/RSTP/MSTP BPDU frames or not. However, it is not practically impossible to detect a customer loop in the SP network. If the SP network detect it, the SP is able to notify that the fact to the customer. 5.3 Split-horizon forwarding scheme The emulated portion in the logical Bridged LAN must ensure loop free and in-sequence MAC frame forwarding, however the use of STP may be inappropriate in WAN environment. Therefore, the WG is discussing topology restriction of pseudo wires that interconnect VSIs. One of solutions is tree structure topology, here a VSI is a node and a pseudo wire is a link, however details of this approach are not proposed yet. Another solution is full mesh topology with split-horizon forwarding scheme proposed in draft-lasserre-vkompella-ppvpn-vpls-02.txt. The split-horizon forwarding scheme enables loop free MAC frame forwarding. A VSI forwards a MAC frame received from a customer to others VSIs, but it never forward a frame received from a VSI to another VSI. It also learns MAC addresses received from the customer network. Obviously, in this scheme, a VSI doesn't emulate a remote-Bridge defined in IEEE 802.1G. Thus, one of issues at here is what is emulated by full mesh topology with split-horizon forwarding scheme. o It is an emulated VLAN, because it transparently forwards MAC frames. o It is an emulated Bridge, because it terminates MAC layer, then forwards MAC frames to another interface, so it can interconnect different Ethernet mediums, furthermore, it learns MAC addresses for forwarding. Note that if it is an emulated Bridge, at least, it may have to be a VLAN- aware Bridge for support of VPLS service in the Bridged LAN. The other issue is scalability. Obviously, full mesh topology is not scale, if number of VSIs is increased. Support of broadcast and multicast is also problematic, because it wastes bandwidth in the SP network and increases jitter of MAC frame forwarding. Note that this scheme does not terminate STP/RSTP/MSTP. If a pseudo wire fails, it may be restored using a layer 3 protection mechanism. In this case, there is a possibility that the recovery time of the layer 3 mechanism may affect failure detection of STP/RSTP/MSTP. Also note that if a single pseudo wire in the mesh fails, this is logically equivalent to the situation that the particular two ports in a HUB/Bridge cannot communicate each other but the remains are normal. So, it is important to confirm that the STP/RSTP/MSTP as well as the others Bridge protocols properly work in this kind of situation. 5.4 Routing for LAN/Bridge Emulation Topology restriction described in the previous section may be undesirable for SPs, because SPs can not deploy PEs freely and full mesh topology may not scale. However, if a VSI emulates a remote Bridge, currently only STP/RSTP can be used for routing. RSTP much improved recovery time, however, we need more experiments of the use of RSTP in WAN environments. The final issue is, if RSTP works in WAN environments, it only blocks links and constructs a tree or hierarchical tree topologies. It may not efficiently use link bandwidth. So, minimum OSPF or BGP-4 extension for MAC routing support may be required. Note that this extended MAC routing protocol may be closed to layer 2, it does not need to interact with IP routing protocol. From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 15 06:05: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 GAA04974 for ; Fri, 15 Nov 2002 06:05:20 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAFB7JY22904 for ; Fri, 15 Nov 2002 06:07: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 gAFB7Hn06883 for ; Fri, 15 Nov 2002 06:07:17 -0500 (EST) Message-ID: From: "Marco Carugi" To: "'ppvpn@nortelnetworks.com'" , "'agenda@ietf.org'" Cc: "'Rick Wilder'" , "Marco Carugi" Subject: 2 typos in Atlanta PPVPN meeting agenda Date: Fri, 15 Nov 2002 12:06:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28C97.1879AB94" 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_01C28C97.1879AB94 Content-Type: text/plain; charset="iso-8859-1" Hi. Two typos in the PPVPN agenda: > - L2 framework and L2 DT report - 20 min - L. Andersson, E. Rosen, M. Suzuki, N. Finn draft-andersson-ppvpn-l2-framework-01.txt (not 02) > - Virtual Hierarchical LAN Services - 5 min - Arnold Sodder draft-sodder-ppvpn-vhls-00.txt (not 01) (actually, Arnold missed the deadline for 01, but he sent me a copy. I referenced this one by mistake in the agenda) Marco ------_=_NextPart_001_01C28C97.1879AB94 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 2 typos in Atlanta PPVPN meeting agenda

Hi.

Two  typos in the PPVPN = agenda:

> - L2 framework and L2 DT report - = 20 min - L. Andersson, E. Rosen, M. Suzuki, N. Finn
draft-andersson-ppvpn-l2-framework-01.txt (not = 02)

> - Virtual Hierarchical LAN = Services -  5 min - Arnold Sodder
draft-sodder-ppvpn-vhls-00.txt (not = 01) (actually,  Arnold missed the deadline for  01,  but = he sent me a copy. I  referenced

this one by mistake in the = agenda)

Marco


------_=_NextPart_001_01C28C97.1879AB94-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 15 06:38: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 GAA05548 for ; Fri, 15 Nov 2002 06:38:20 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAFBeIY27975 for ; Fri, 15 Nov 2002 06:40:19 -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 gAFBeGn21717 for ; Fri, 15 Nov 2002 06:40:16 -0500 (EST) Message-ID: <3DD4DCF4.9E098938@cisco.com> Date: Fri, 15 Nov 2002 12:39:32 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Miao Fuyou CC: ppvpn@nortelnetworks.com Subject: Re: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) References: <000001c28c5a$7bd50ae0$2e426e0a@HUAWEI.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: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-4.cisco.com [171.71.163.54] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi Miao, Thx for 350 Kb attachment send to this alias :-). But it did not addressed the conclusion which I believe we have have came up offline - so let me resend it to the list. The only difference which 2547bis Inter-as option b does not spell out and what is in turn key to building your model is the installation by SPE received from UPEs by ext community ORF RTs on the SPE inbound (to filter from other PEs or vpnv4 RRs). I am not even sure why this would not be a vendor specifc knob not requiring any protocol changes. I think it would be good if you could spell out what new protocol changes are required before proceeding further. Cheers, R. > Miao Fuyou wrote: > > Dear All: > > Here I attached slides to adress the idea of hierarchical PE, wish it > will be helpful for you to understand it! > > Best regards > Miao From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 15 15:21:16 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 PAA18051 for ; Fri, 15 Nov 2002 15:21:16 -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 gAFKNFY02016 for ; Fri, 15 Nov 2002 15:23:15 -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 gAFKNCn18432 for ; Fri, 15 Nov 2002 15:23:12 -0500 (EST) Message-Id: <200211152022.gAFKMW214778@zcars0jk.ca.nortel.com> From: Union Subject: Steam... Organization: Home Reply-To: Gs-Union@inbox.ru X-Mailer: The Bat! (v1.52f) Business Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Date: Fri, 15 Nov 2002 22:22:13 +0200 X-SMTP-HELO: Localhost X-SMTP-MAIL-FROM: Gs-Union@inbox.ru X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,mleech@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: 80-235-101-162-dsl.plus.estpak.ee [80.235.101.162] X-LYRIS-Message-Id: Çäðàâñòâóéòå! ß çíàþ, âàì êàæäûé äåíü ïðèõîäÿò ïèñüìà, ïîäîáíî ýòîìó, ñ ïðåäëîæåíèÿìè î ðàáîòå. Íî íå óïóñòèòå øàíñ, ïîêà ýòî âîçìîæíî. Âî âñÿêîì ñëó÷àå âû íè÷åãî íå òåðÿåòå!!! Âîçìîæíîñòü çàðàáàòûâàòü äåíüãè â êà÷åñòâå îñíîâíîãî èëè äîïîëíèòåëüíîãî äîõîäà. Âû ìîæåòå ëåãêî ïîëó÷àòü 500 äîëëàðîâ â ìåñÿö, çàòðà÷èâàÿ âñåãî 10 ÷àñîâ â íåäåëþ Âàøåãî âðåìåíè! Âû äàæå ñìîæåòå çàðàáàòûâàòü è áîëåå 2000 äîëëàðîâ, åñëè ãîòîâû óäåëÿòü ýòîìó äîñòàòî÷íî âðåìåíè. Âñÿ ðàáîòà ìîæåò âûïîëíÿòüñÿ íà äîìó. Âàì íóæåí òîëüêî êîìïüþòåð ñ ïîäêëþ÷åíèåì ê èíòåðíåòó, à âñåìó îñòàëüíîìó ìû Âàñ íàó÷èì. Íà÷èíàéòå çàðàáàòûâàòü ñåãîäíÿ! Îáðàùàéòåñü ïî alexunion121@hotmail.com ( gs-union1@yandex.ru ) ñ ïîìåòêîé îáðàáîòêà ýëåêòðîííîé ïî÷òû. ____ __ ____ Óäà÷è âàì!!! È èçâåíèòå, åñëè äàííàÿ ðàññûëêà ïðèíåñëà âàì íåóäîáñòâà!!! From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 15 16:24:29 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 QAA19682 for ; Fri, 15 Nov 2002 16:24:28 -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 gAFLQSY18317 for ; Fri, 15 Nov 2002 16:26: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 gAFLQPn11702 for ; Fri, 15 Nov 2002 16:26:26 -0500 (EST) Message-ID: From: "Marco Carugi" To: "'ppvpn@nortelnetworks.com'" Cc: "'Scott Bradner'" , "'bwijnen@lucent.com'" , "'Alex Zinin'" , "'rwilder@masergy.com'" , "Marco Carugi" Subject: Status of current PPVPN WG drafts and updated milestones Date: Fri, 15 Nov 2002 22:26:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28CED.97BD218C" 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_01C28CED.97BD218C Content-Type: text/plain; charset="iso-8859-1" All, before our Atlanta meeting, here is an overview of the status of the current PPVPN WG drafts. Updated PPVPN milestones follow (sent this week, I don't know if they will be uploaded on the PPVPN page before the meeting or not). Marco 1) Status of PPVPN WG drafts Under WG discussion to be moved into the WG (Atlanta) draft-nagarajan-ppvpn-generic-reqts-01.txt draft-ppvpn-l2vpn-requirements-01.txt (will supercede draft-ietf-ppvpn-vpls-requirements-01.txt) draft-luciani-ppvpn-vpn-discovery-03.txt Other IDs to be moved into the WG (soon after Atlanta) draft-andersson-ppvpn-terminology-02.txt draft-andersson-ppvpn-metrics-01.txt Awaiting updates from authors draft-ietf-ppvpn-vpn-vr-03.txt draft-ietf-ppvpn-ce-based-02.txt (to solution document) draft-declercq-ppvpn-ce-based-as-01 (planned WG doc status conditional to draft-ietf-ppvpn-ce-based) draft-rosen-vpns-ospf-bgp-mpls-05.txt + daft-rosen-ppvpn-ospf2547-area0-01.txt (recent input from OSPF chairs) draft-ietf-ppvpn-gre-ip-2547-01.txt(not on PPVPN page) (pending status with MPLS WG) draft-ietf-ppvpn-l2vpn-framework-01.txt draft-ietf-ppvpn-applicability-guidelines-00.txt Updated from authors draft-ietf-ppvpn-as-vr-01.txt draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt draft-ietf-ppvpn-l3vpn-auth-01.txt draft-ietf-ppvpn-rfc2547bis-03.txt draft-ietf-ppvpn-ipsec-2547-02.txt draft-ietf-ppvpn-vpls-requirements-01.txt (but will be superceded ) Under WG Last Call (authors' request for BCP RFC) draft-ietf-ppvpn-cl-tunneling-vpn-00.txt Under IESG review for Info RFC (they are now back to IESG after update from authors according to first round of IESG comments) draft-ietf-ppvpn-requirements-05.txt draft-ietf-ppvpn-framework-06.txt WG Last Call some time after Atlanta (end 2003 ?) WG ID from draft-nagarajan-ppvpn-generic-reqts-01.txt (Info RFC) Conditional to IESG approval of draft-ietf-ppvpn-requirements-05.txt and draft-ietf-ppvpn-framework-06.txt : draft-ietf-ppvpn-rfc2547bis-03.txt * draft-ietf-ppvpn-vpn-vr-0x.txt * * Intention is to solve in parallel all the necessary protocol dependencies with other WGs (dependencies described in draft-rosen-ppvpn-2547bis-protocol-01.txt and draft-knight-ppvpn-vr-protocol-00.txt), before effective submission to IESG. WG Last Call will follow in reasonable timing for : - other 2547-based solution documents - draft-ietf-ppvpn-as2547-00.txt - draft-ietf-ppvpn-as-vr-01.txt MIBs draft-ietf-ppvpn-mpls-vpn-mib-05.txt draft-ietf-ppvpn-vr-mib-03 draft-ietf-ppvpn-tc-mib-02 To be progressed in reasonable timing after progress of related solution documents. 2) Updated PPVPN Milestones DONE NOV 02 Submit the layer 3 requirement and the layer 3 framework documents to the IESG for consideration as Informational RFCs. NOT DONE DEC 02 Begin submission of the candidate L3 approaches and related applicability statements to IESG publication JAN 03 Submit the layer 2 requirement and the layer 2 framework documents to the IESG for consideration as Informational RFCs APR 03 Begin submission of the candidate L2 approaches and related applicability statements to IESG for publication NOV 03 Charter update or WG disband ------_=_NextPart_001_01C28CED.97BD218C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Status of current PPVPN WG drafts and updated = milestones

All,
before our Atlanta meeting, =
here is an overview of the = status of the current PPVPN WG drafts.
Updated PPVPN  milestones = follow (sent this week, I don't  know if  they will be = uploaded on the PPVPN page before the meeting or not).  =

Marco

1) Status of PPVPN WG drafts =
 
Under WG discussion to be moved = into the WG (Atlanta)
draft-nagarajan-ppvpn-generic-reqts-01.txt
draft-ppvpn-l2vpn-requirements-01.txt (will supercede = draft-ietf-ppvpn-vpls-requirements-01.txt)
draft-luciani-ppvpn-vpn-discovery-03.txt

Other IDs to be moved into the = WG (soon after Atlanta)
draft-andersson-ppvpn-terminology-02.txt
draft-andersson-ppvpn-metrics-01.txt


Awaiting updates from = authors
draft-ietf-ppvpn-vpn-vr-03.txt 
draft-ietf-ppvpn-ce-based-02.txt  (to solution = document)
draft-declercq-ppvpn-ce-based-as-01 (planned WG doc status = conditional to draft-ietf-ppvpn-ce-based)
draft-rosen-vpns-ospf-bgp-mpls-05.txt + = daft-rosen-ppvpn-ospf2547-area0-01.txt (recent input from OSPF = chairs) 
draft-ietf-ppvpn-gre-ip-2547-01.txt(not on PPVPN page) (pending = status with MPLS  WG)
draft-ietf-ppvpn-l2vpn-framework-01.txt
draft-ietf-ppvpn-applicability-guidelines-00.txt


Updated from authors
draft-ietf-ppvpn-as-vr-01.txt
draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt
draft-ietf-ppvpn-l3vpn-auth-01.txt
draft-ietf-ppvpn-rfc2547bis-03.txt
draft-ietf-ppvpn-ipsec-2547-02.txt
draft-ietf-ppvpn-vpls-requirements-01.txt (but will be superceded = )


Under WG Last Call (authors' = request for BCP RFC)
draft-ietf-ppvpn-cl-tunneling-vpn-00.txt


Under IESG review for Info RFC = (they  are now back to IESG after update from authors according to = first round of IESG comments)

draft-ietf-ppvpn-requirements-05.txt
draft-ietf-ppvpn-framework-06.txt


WG Last Call some time after = Atlanta (end 2003 ?)
WG ID  from = draft-nagarajan-ppvpn-generic-reqts-01.txt  (Info RFC)
Conditional to IESG approval of = draft-ietf-ppvpn-requirements-05.txt and = draft-ietf-ppvpn-framework-06.txt :
draft-ietf-ppvpn-rfc2547bis-03.txt *
draft-ietf-ppvpn-vpn-vr-0x.txt = *

* Intention is to solve in  = parallel all the necessary protocol dependencies with other WGs = (dependencies described in draft-rosen-ppvpn-2547bis-protocol-01.txt = and draft-knight-ppvpn-vr-protocol-00.txt), before effective submission = to IESG.

WG Last Call will follow in = reasonable timing for :
- other 2547-based solution = documents
- = draft-ietf-ppvpn-as2547-00.txt 
- = draft-ietf-ppvpn-as-vr-01.txt 

 
MIBs
draft-ietf-ppvpn-mpls-vpn-mib-05.txt
draft-ietf-ppvpn-vr-mib-03
draft-ietf-ppvpn-tc-mib-02
To be progressed in reasonable = timing after progress of related solution documents.   =


2) Updated PPVPN = Milestones

DONE
NOV 02    =       Submit the layer 3 requirement and = the  layer 3 framework documents to the IESG for consideration as = Informational RFCs.

NOT DONE
DEC 02    =       Begin submission of the candidate L3 = approaches and related applicability statements to IESG publication =

JAN 03    =       Submit the layer 2 requirement and the = layer 2 framework documents to the IESG for consideration as = Informational RFCs 

APR 03    =       Begin submission of the candidate L2 = approaches and related applicability statements to IESG for publication =

NOV 03    =       Charter update or WG disband



------_=_NextPart_001_01C28CED.97BD218C-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 15 16:39:03 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 QAA20267 for ; Fri, 15 Nov 2002 16:39:03 -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 gAFLf3Y22882 for ; Fri, 15 Nov 2002 16:41: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 gAFLf0n26855 for ; Fri, 15 Nov 2002 16:41:00 -0500 (EST) Message-Id: <5.1.0.14.0.20021115163836.0163c488@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Nov 2002 16:40:28 -0500 To: "Marco Carugi" , "'ppvpn@nortelnetworks.com'" From: "Joel M. Halpern" Subject: Re: Status of current PPVPN WG drafts and updated milestones Cc: "'Scott Bradner'" , "'bwijnen@lucent.com'" , "'Alex Zinin'" , "'rwilder@masergy.com'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: EXECDSL.COM X-SMTP-MAIL-FROM: joel@stevecrocker.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ns.execdsl.net [208.184.15.238] X-LYRIS-Message-Id: I apologize to the authors, but I simply can not see how this document warrants publication as either a BCP or a Proposed Standard. Yours, Joel M. Halpern At 10:26 PM 11/15/2002 +0100, Marco Carugi wrote: >Under WG Last Call (authors' request for BCP RFC) >draft-ietf-ppvpn-cl-tunneling-vpn-00.txt From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 15 18:57:29 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 SAA24270 for ; Fri, 15 Nov 2002 18:57: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 gAFNxQY17384 for ; Fri, 15 Nov 2002 18:59: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 gAFNxNn21795 for ; Fri, 15 Nov 2002 18:59:24 -0500 (EST) From: "Jim Guichard" To: "Miao Fuyou" , "=?gb2312?B?Jz8/oac/Pz+h7D+h7D8/Pz+orD+hp6GnPz+hpz8/Jw==?=" Cc: Subject: RE: Please Review: A new draft about PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) Date: Fri, 15 Nov 2002 18:54:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <000c01c28c47$3ac74620$2e426e0a@HUAWEI.COM> X-MIME-Autoconverted: from 8bit to quoted-printable by cisco.com id XAA21025 X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: london2.cisco.com [64.103.110.74] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA24270 Hi Miao, > >-----Original Message----- > >From: Miao Fuyou [mailto:miaofy@huawei.com] > >Sent: Thursday, November 14, 2002 8:35 PM > >To: 'Jim Guichard'; '??¨¬?¡§¡§???¡ì?¨¨??¨¬?' > >Cc: ppvpn@nortelnetworks.com > >Subject: RE:Please Review: A new draft about PPVPN(Hiberarchy of > >PE Device inBGP/MPLS VPN) > > > > > >Hi, Jim: > > > >See my comments inline! > > > >Regards > > > >-----Original Message----- > >From: Jim Guichard [mailto:jguichar@cisco.com] > >Sent: Friday, November 15, 2002 8:10 AM > >To: Miao Fuyou; '??¨¬?¡§¡§???¡ì?¨¨??¨¬?' > >Cc: ppvpn@nortelnetworks.com > >Subject: RE: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > > > > > >Hi Miao, > > > >> >-----Original Message----- > >> >From: Miao Fuyou [mailto:miaofy@huawei.com] > >> >Sent: Wednesday, November 13, 2002 3:38 AM > >> >To: 'Jim Guichard'; '?¡ì?¨¨??¡§¡è?¡ì?' > >> >Cc: ppvpn@nortelnetworks.com > >> >Subject: RE: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >> >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > >> > > >> > > >> >Hi, Jim: > >> > > >> >As per my understanding, your primary concern is routes. Actually the > > > >> >problem is very similiar to the one in H&S topology, in which VPN > >> >network views are not available at spoke site. Sure, the sites > >> >connected by HoPE have not whole view of network, but the question > >> >is: really the customer want to know that? > > > >and the answer is, sometimes yes, sometimes no. The point is that H&S > >can provide this topology if really required, and is indeed deployed in > >several networks that I have worked on. > > > > In HoPE, the spoke is UPE, contrastively the spoke is site/CE in > >H&S. It makes difference, even if the topologies are similiar. H&S also has the concept of the spoke at the PE-router - each VRF that attaches a spoke site is a member of the spoke topology. All one has to do to achieve the required topology is export routes from the spoke VRFs with an RT value that the hub will import (but not other spokes) and then export a default/aggregate from the hub toward all spokes with a different RT - there is nothing more complicated to it than that. Jim > > > > Anyway, for L3VPN, routing is an add-value > >> >service provided by SP to customer. Sometimes customer concerns VPN > >> >topology, however, such function/service can be provided by Customer > >> >Network Management, which is more convinient to customer. > > > >sorry, but I do not get the point you are making ? > > > > I mean that routes of VPN are not necesssary to be known by each > >sites > > > >> > > >> >Note that HoPE works under specific network environment to meet > >> >specific requirement, it's not cure-all. > > > >exactly. > > > > However, it's happy to find that most > >> >network are planned and setup with a hierachical topology, and where > >> >HoPE can works best. > > > >I would suggest that most networks are NOT built this way - hierarchy in > >general is a good thing, I would not argue against this. However, the > >type of hierarchy you are describing is most advantageous to the SP and > >not the customer as it introduces a number of complications as I > >described in my prior email .. Jim > > > >Agree, actually the solution is most suitable for huge network, > >such as SP and gov network, and such networks are what we concern most. > > > > > >> > > >> >Regard > >> >Miao > >> > > >> > > >> >-----Original Message----- > >> >From: Jim Guichard [mailto:jguichar@cisco.com] > >> >Sent: Monday, November 11, 2002 9:39 PM > >> >To: Miao Fuyou; '?¡ì?¨¨??¡§¡è?¡ì?' > >> >Cc: ppvpn@nortelnetworks.com > >> >Subject: RE: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >> >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > >> > > >> > > >> >Hi Miao, > >> > > >> > > >> > > >> >> >-----Original Message----- > >> >> >From: Miao Fuyou [mailto:miaofy@huawei.com] > >> >> >Sent: Saturday, November 09, 2002 4:01 AM > >> >> >To: 'Jim Guichard'; '¡§¡è??¨¤¡§?' > >> >> >Cc: ppvpn@nortelnetworks.com > >> >> >Subject: ´ð¸´: ´ð¸´: ´ð¸´: Please Review: A new draft about > >> >> >PPVPN(Hiberarchy of PE Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> > > >> >> >Hi, Jim: > >> >> > > >> >> >Please find my commnets inline! > >> >> > > >> >> >Regards > >> >> >-----ÓʼþÔ­¼þ----- > >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 23:29 > >> >> >ÊÕ¼þÈË: ???¡ê¨®?; '¡§¡è??¨¤¡§?' > >> >> >³­ËÍ: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; > >> >> >leh10814@huawei.com > >> >> >Ö÷Ìâ: RE: ´ð¸´: ´ð¸´: Please Review: A new draft about > >> >PPVPN(Hiberarchy > >> >> >of PE Device inBGP/MPLS VPN) > >> >> > > >> >> > > >> >> >Hi Miao, > >> >> > > >> >> >I understand that this is not a replacement to 2547. I also > >> >> >understand that hierarchy is one of the tools we have to help > >> >> >scale networks. However, what I am driving at is that 2547 > >> >> >provides all of the necessary mechanisms already to run this type > >> >> >of topology - deployment of 2547 is a matter of design and no new > >> >> >functionality is necessary to be able to run the topology you are > >> >> >suggesting. We have many deployments worldwide that already use > >> >> >this type of design to provide central services to their > >> >> >customers. This does not mean however that the topology is > >> >> >appropriate for all 2547 customers. There are a number of issues > >> >> >with the proposed topology that one might consider: > >> >> > > >> >> >Miao: Actually it's not a problem of topology, it's for the > >> >> >planning and design of the network. If 2547 alone can work under > >> >> >for every network and meet all the VPN requirement, why were VPLS, > > > >> >> >Martini VPN, > >> > > >> >> >Kompella VPN and many others proposed? > >> > > >> >well VPLS, Martini and Kompella are talking about layer-2 application > > > >> >- we are talking about layer-3 here which is a little different > >> >wouldn't you agree ? > >> > > >> >> > > >> >> >1. In most real world deployments the number of hops between UPE > >> >> >and SPE will be > 1. This may introduce unacceptable latency and > >> >> >so on, especially as the design is being used for transit traffic > >> >> >rather than central services. > >> >> > > >> >> >Miao: I don't think hops > 1 brings more latency if a packet must > >> >> >go from an ingress PE to an egress PE. Actually it follows almost > >> >> >the same route that 2547 one will do if the network is not very > >> >> >careless designed. > >> > > >> >well I think it is fair to say that if you attract traffic to a > >> >particular point of the network then the optimal path from an routing > > > >> >perspective is more likely to be overlooked - this is not always the > >> >case but you cannot assume in an architecture that all networks are > >> >built the same. > >> > > >> >> > > >> >> >2. Using this method introduces additional IP address lookups > >> >> >between > >> > > >> >> >ingress PE and egress PE, plus label disposition/imposition. > >> >> > > >> >> >Miao: It's a ONCE-FOR-ALL work for a site, so the effort is > >> >> >trivial > >> > > >> >maybe I misunderstood your description but if the hub has to route > >> >inter-site traffic then we must remove the label stack, look at the > >> >IP address and then send it back on its way - this is a per-packet > >> >exercise not per-site. > >> > > >> >> > > >> >> >3. Unless the SPE is located locally to the UPE then the regional > >> >> >VPN > >> > > >> >> >traffic will be concentrated toward certain points of the network, > > > >> >> >instead of being distributed across the whole infrastructure. > >> >> > > >> >> >Miao: UPE can process it locally in such case, no SPE involved > >> > > >> >how can it if it does not have the routes ? if it has the routes then > > > >> >we have 2547 no ? > >> > > >> >> > > >> >> >4. If the SPE is located locally, then aggregates can be injected > >> >> >down to the UPEs but this is assuming that the address space is > >> >> >designed in such a way as to allow this aggregation. Most > >> >> >Enterprise networks today do not have such a well structured > >> >> >addressing plan. > >> >> > > >> >> >Miao: Refer item 3 > >> > > >> >so item 3 says there is no aggregation and the scheme is rendered > >> >useless. > >> > > >> >> > > >> >> >5. By injecting aggregates toward the CE site you change the > >> >> >customers routing view which may actually require the injection of > > > >> >> >more specific routes. > >> >> > > >> >> >Miao: No aggretes injected in HoPE actually > >> > > >> >well if it is just default route the same comment applies and is > >> >actually even worse. > >> > > >> >> > > >> >> >6. The SP has to keep track of the aggregation and configure it > >> >> >appropriately at the SPE. > >> >> > > >> >> >Miao: SPE will do > >> > > >> >how ? there are many ways to generate such an aggregate, each of > >> >which have their own implications. > >> > > >> >> > > >> >> >7. How do you take care of customers that want to run OSPF or ISIS > > > >> >> >on > >> > > >> >> >the PE-CE links ? how would sham-links work for example ? > >> >> > > >> >> >Miao: Only default route is needed in HoPE at PE-CE links, so why > >> >> >to run OSPF & IS-IS? > >> > > >> >default is not sufficient for most customers - a large subset of > >> >Internet customers today want more than just default route. OSPF, > >> >ISIS, EIGRP and so on were introduced so as to avoid changing the > >> >routing view of the end customers - this is a desired requirement > >> >that HoPE does not service. > >> > > >> >> > > >> >> >8. To deploy H&S designs one must use different RTs for the same > >> >> >VPN and then apply policy to filter correctly. This may not be > >> >> >such a big > >> > > >> >> >deal but is a further complication in the provisioning and > >> >> >management > >> > > >> >> >process. > >> >> > > >> >> >Miao: Repeat, it's not a problem of topology, not to say H&S > >> >> > > >> >> >9. If our goal is to offload the edge routers from having to carry > > > >> >> >VPNv4 routes or run MP-BGP sessions then perhaps we should use the > > > >> >> >L2-transport functionality in MPLS to carry the edge traffic to an > > > >> >> >SPE. This has the advantage that the CE can exchange routes > >> >> >directly with the SPE which is useful for other applications. > >> >> > > >> >> >Miao: L2-transport is not always applicable. CEs don't always run > >> >> >MPLS. > >> > > >> >CEs do not need to run MPLS to run L2-transport - the PEs do the > >> >L2-transport. > >> > > >> >> > > >> >> >10. How do you take care of customers that want to run Carrier's > >> >> >Carrier architecture ? > >> >> > > >> >> >Miao: But, what is the problem? > >> > > >> >the problem is that you cannot run an end-to-end LSP to allow this > >> >type of architecture to work .. > >> > > >> >regards, > >> > > >> >> > > >> >> > > >> >> >regards, > >> >> > > >> >> > > >> >> >> >-----Original Message----- > >> >> >> >From: Ã縣ÓÑ [mailto:miaofy@huawei.com] > >> >> >> >Sent: Thursday, November 07, 2002 9:07 PM > >> >> >> >To: 'Jim Guichard'; '¨¤?¡À¨®' > >> >> >> >Cc: rwilder@masergy.com; 'Marco Carugi'; sob@harvard.edu; > >> >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > >> >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; > >> >> >> >leh10814@huawei.com > >> >> >> >Subject: ´ð¸´: ´ð¸´: Please Review: A new draft about > >> >> >PPVPN(Hiberarchy of > >> >> >> >PE Device inBGP/MPLS VPN) > >> >> >> > > >> >> >> > > >> >> >> >Hi, Jim: > >> >> >> > > >> >> >> >This draft is not to replace 2547, but a supplement to it. > >> >> >> >Actually the VPN in the draft is completely works under the > >> >> >> >mechanism of 2547. > >> >> >> > > >> >> >> >In the traditional 2547 VPN, only one type of PE is defined. > >> >> >> >When deployment, PE will not has so many ports to attach many > >> >> >> >VPNs if the PE is at the core layer of the network, because > >> >> >> >core router generally > >> >> > > >> >> >> >doesn't have a lot of physically interfaces. If the PE is at > >> >> >> >the edge of the network, it will have a lot of interfaces, but > >> >> >> >now the > >> > > >> >> >> >botlleneck is capacity of computation of the router. > >> >> >> > > >> >> >> >This draft is to solve the problem, UPE will provide abundant > >> >> >> >interface to conenct sites to VPN and SPE will have enough > >> >> >> >CPU/Memory > >> >> > > >> >> >> >to process routes. > >> >> >> > > >> >> >> >Regards > >> >> >> >Miao > >> >> >> > > >> >> >> >-----ÓʼþÔ­¼þ----- > >> >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ8ÈÕ 0:01 > >> >> >> >ÊÕ¼þÈË: ¨¤?¡À¨® > >> >> >> >³­ËÍ: internet-drafts@ietf.org; rwilder@masergy.com; Marco > >> >> >> >Carugi; > >> > > >> >> >> >sob@harvard.edu; bwijnen@lucent.com; zinin@psg.com; > >> >> >> >ppvpn@nortelnetworks.com; lhj@huawei.com; Gma@futurewei.com; > >> >> >> >changwj@huawei.com; Fu Y. Miao; leh10814@huawei.com > >> >> >> >Ö÷Ìâ: RE: ´ð¸´: Please Review: A new draft about > >PPVPN(Hiberarchy > >> >of > >> >> >PE > >> >> >> >Device inBGP/MPLS VPN) > >> >> >> > > >> >> >> > > >> >> >> >so can hub&spoke with 2547 - you basically export routes from > >> >> >> >the CE-attached PEs to a hub PE that imports the routes. The > >> >> >> >hub PE exports either a default or aggregates to attract > >> >> >> >traffic from other CE-attached PEs and then performs a lookup > >> >> >> >to forward the packets to other CE-attached PEs .. Jim > >> >> >> > > >> >> >> >> >-----Original Message----- > >> >> >> >> >From: Àî±ó [mailto:l.b@huawei.com] > >> >> >> >> >Sent: Thursday, November 07, 2002 2:42 AM > >> >> >> >> >To: Jim Guichard > >> >> >> >> >Cc: internet-drafts@ietf.org; rwilder@masergy.com; > >> >> >> >> >marco.carugi@nortelnetworks.com; sob@harvard.edu; > >> >> >> >> >bwijnen@lucent.com; > >> >> >> > > >> >> >> >> >zinin@psg.com; ppvpn@nortelnetworks.com; lhj@huawei.com; > >> >> >> >> >Gma@futurewei.com; changwj@huawei.com; Fu Y. Miao; > >> >> >> >> >leh10814@huawei.com > >> >> >> >> >Subject: ´ð¸´: Please Review: A new draft about > >> >PPVPN(Hiberarchy > >> >> >of > >> >> >> >PE > >> >> >> >> >Device inBGP/MPLS VPN) > >> >> >> >> > > >> >> >> >> > > >> >> >> >> >Hi, Guichard > >> >> >> >> >The hub & spoke is the relationship between CEs, but SPE > >> >> >> >> >peer with > >> >> > > >> >> >> >> >UPE by MP-BGP, they are all PEs, and they all can admit VPN > >> >> >> >> >user. > >> >> >> >> > > >> >> >> >> >Libin > >> >> >> >> > > >> >> >> >> >-----ԭʼÓʼþ----- > >> >> >> >> >·¢¼þÈË: Jim Guichard [mailto:jguichar@cisco.com] > >> >> >> >> >·¢ËÍʱ¼ä: 2002Äê11ÔÂ7ÈÕ 2:59 > >> >> >> >> >ÊÕ¼þÈË: lidefeng; internet-drafts@ietf.org > >> >> >> >> >³­ËÍ: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >> >> >bwijnen@lucent.com; zinin@psg.com; ppvpn@nortelnetworks.com; > > > >> >> >> >> >lhj@huawei. com; Gma@futurewei.com; changwj@huawei.com; Fu > >> >> >> >> >Y. Miao; leh10814@huawei. com; l.b@huawei.com > >> >> >> >> >Ö÷Ìâ: RE: Please Review: A new draft about PPVPN(Hiberarchy > >of > >> >PE > >> >> >> >> >Device inBGP/MPLS VPN) > >> >> >> >> > > >> >> >> >> > > >> >> >> >> >I briefly ran through this draft and it looks like normal > >> >> >> >> >hub & > >> > > >> >> >> >> >spoke > >> >> >> > > >> >> >> >> >using existing 2547 mechanisms - could you explain how this > >> >> >> >> >differs ? > >> >> >> > > >> >> >> >> >thanks, > >> >> >> >> > > >> >> >> >> >> >-----Original Message----- > >> >> >> >> >> >From: lidefeng [mailto:lidefeng@huawei.com] > >> >> >> >> >> >Sent: Tuesday, November 05, 2002 11:40 PM > >> >> >> >> >> >To: internet-drafts@ietf.org > >> >> >> >> >> >Cc: rwilder@masergy.com; Marco Carugi; sob@harvard.edu; > >> >> >> >> >> >bwijnen@lucent.com; zinin@psg.com; > >> >> >> >> >> >ppvpn@nortelnetworks.com; > >> > > >> >> >> >> >> >lhj@huawei.com; Gma@futurewei.com; changwj@huawei.com; Fu > > > >> >> >> >> >> >Y. > >> > > >> >> >> >> >> >Miao; > >> >> >> > > >> >> >> >> >> >leh10814@huawei.com; l.b@huawei.com > >> >> >> >> >> >Subject: Please Review: A new draft about > >> >> >> >> >> >PPVPN(Hiberarchy of PE Device in BGP/MPLS VPN) > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> >Hi,all, > >> >> >> >> >> > > >> >> >> >> >> > In BGP/MPLS VPN area, we proposed a new idea as to > >> >> >> >> >> >resolve the bottleneck of the capacity of some PEs when > >> >> >> >> >> >deploy the huge > >> >> > > >> >> >> >> >> >size VPN,the > >> >> >> >> >whole idea is > >> >> >> >> >> >detailed > >> >> >> >> >> >in the attached > >> >> >> >> >> >draft:draft-libin-hiberarchy-pe-bgp-mpls-vpn-00.txt,and > >> >> >> >> >> >the Abstract is as follows,we are appreciated for your > >> >> >> >> >> >review. > >> >> >> >> >> > > >> >> >> >> >> > In the deployment of BGP/MPLS VPN,the PE(Provider > >> >> >> >> >Edge)Device should > >> >> >> >> >> > maintain all the VPN routes of the VPNs which it > >> >> >> >> >> > belong > >> >> >> >> >to.When there > >> >> >> >> >> > are many VPNs converged by a PE,and the capacity of PE > > > >> >> >> >> >> > is > >> >> >> >relevant > >> >> >> >> >> > limited,then the bottleneck will be > >> >> >> >> >> > encountered.Another problem > >> >> >> >is > >> >> >> >> >> > that the current BGP/MPLS VPN model is something of a > >> >> >> >> >> > "Plane > >> >> >> >Modle" > >> >> >> >> >> > where the demand of the performance of the PE device > >> >> >> >> >> > are all > >> >> >> >the > >> >> >> >> >> > same no matter which layer the PE device is belongs > >> >> >> >> >> > to.However, > >> >> >> >the > >> >> >> >> >> > typical network is "Core-Convergence-Access(Edge)" > >> >> >> >> >> > model,and > >> >> >> >the > >> >> >> >> >> > performance of the device is superior in Core Layer > >> >> >> >> >> > and > >> >> >> >inferior in > >> >> >> >> >> > Access Layer,and the scale of network is large in > >> >> >> >> >> > Access Layer > >> >> >> >and > >> >> >> >> >> > small in Core Layer,the routes are converged in every > >> >> >> >> >> > layer,so > >> >> >> >in > >> >> >> >> >> > current "Plane Modle",when PE device push to the edge > >> >> >> >> >> > layer,it > >> >> >> >has > >> >> >> >> >> > to maintain more VPN routes,this makes it difficult to > >> >> >> >> >extend the PE > >> >> >> >> >> > device to edge layer.This document defines an model of > >> >> >> >> >hiberarchy of > >> >> >> >> >> > Provider Edge Device in BGP/MPLS VPN,where hiberarchy > >> >> >> >> >> > of > >> >> >> >Provider > >> >> >> >> >> > Edge Device can be composed of several device and > >> >> >> >> >> > every device > >> >> >> >take > >> >> >> >> >> > on the different part,partake the function of the > >former > >> >> >> >> >> > concentrative PE,we call this model "Hiberarchy > >> >> >> >> >> > Model",In > >> >> >> >> >this model > >> >> >> >> >> > the demand of performance in Routing and Switching is > >> >> >> >> >> > strict > >> >> > > >> >> >> >> >> > to > >> >> >> >the > >> >> >> >> >> > PE device in High layer,loose to the PE device in edge > > > >> >> >> >> >> > layer. > >> >> >> >> >> > > >> >> >> >> >> > One HoPE can be composed of a SPE and UPES connected > >> >> >> >> >> > to the > >> >> >> >SPE, > >> >> >> >> >> > or be composed of a high-level SPE and HoPEs connected > > > >> >> >> >> >> > the > >> >> >high > >> >> >> >> >> > level SPE and and build up a new HoPE.This build is > >> >> >> >> >> > called > >> >> >> >nesting > >> >> >> >> >> > of HoPE,and this kind of nesting can be done for many > >> >> >> >> >times.Thus the > >> >> >> >> >> > former HoPE connect to the high-level SPE as a role of > > > >> >> >> >> >> > UPE,and > >> >> >> >the > >> >> >> >> >> > new HoPE can connect a single UPE too. > >> >> >> >> >> > > >> >> >> >> >> >Regards > >> >> >> >> >> > > >> >> >> >> >> >Defeng Li > >> >> >> >> >> > > >> >> >> > > >> >> >> > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 18 02:09: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 CAA14541 for ; Mon, 18 Nov 2002 02:09:42 -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 gAI7BeP06147 for ; Mon, 18 Nov 2002 02:11: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 gAI7BbZ19117 for ; Mon, 18 Nov 2002 02:11:37 -0500 (EST) Date: Mon, 18 Nov 2002 15:11:25 +0800 From: Bin Li Subject: The primary improve from 2547bit to HoPE To: Ppvpn Cc: lhj@huawei.com, changwenjun , lidefeng , "FuY. Miao" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: l.b@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi, all Since I have commit the draft about hierarchical PE, someone agrued that this mechanism can be realized just according rfc2547bis, It's unnessary to commit a new draft. The primary diffrence between 2547bis and HoPE are listed below: > 1 SPE only send aggregate vpnv4 routes or a default vpnv4 route rather than all vpnv4 routes to UPE. > 2 Because vpnv4 routes are aggregated in SPE, SPE must terminate the LSP which is from UPE. It pop the vpn label and look forward vrf routing table, then push a new vpn label. > 3 UPE should advertise its import route target list to SPE. SPE will form a HoPE-wide import route target list to filter vpnv4 routes from other PEs. > The above mechanisms are not described in draft 2547bis. And the PE just according 2547bis can't work as a SPE now. So I commit this proposal. Regards, Libin From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 18 11:36: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 LAA26017 for ; Mon, 18 Nov 2002 11:36:12 -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 gAIGcHP06487 for ; Mon, 18 Nov 2002 11:38:17 -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 gAIGcDZ13379 for ; Mon, 18 Nov 2002 11:38:14 -0500 (EST) Date: Mon, 18 Nov 2002 11:35:09 -0500 (EST) Message-ID: From: 88@ms34.url.com.tw To: 1@zcars0ms.ca.nortel.com Subject: =?big5?Q?=A7A=B7Q=ADn=B9L=B5=DB=ACJ=A6=B3=BF=FA=A4S=A6=B3=B6=A2=AA=BA=A5=CD=AC=A1=A4=E8=A6=A1=B6=DC =3F?= MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_10iN6SimAmnEettMEP" X-Mailer: yyqa8Y1Y4zAHbGb9UaHfjLZW X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: w8k2x7 X-SMTP-MAIL-FROM: 1Trx66q1rTbM@gcn.net.tw X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,svallis@nortelnetworks.com,tbastian@nortelnetworks.com X-SMTP-PEER-INFO: 98.c210-85-172.ethome.net.tw [210.85.172.98] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_10iN6SimAmnEettMEP Content-Type: multipart/alternative; boundary="----=_NextPart_10iN6SimAmnEettMEPAA" ------=_NextPart_10iN6SimAmnEettMEPAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiDQp4bWxuczpvPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiDQp4bWxuczp3PSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIg0KeG1sbnM9Imh0dHA6Ly93d3cudzMub3Jn L1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBl IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1CaWc1Ij4NCjxtZXRhIG5hbWU9UHJvZ0lkIGNv bnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jv c29mdCBXb3JkIDkiPg0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBX b3JkIDkiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdCBocmVmPSIuL2gxYTJAMTYzLmNvbSUyMCUyMK/B qPqnS7ZPqrqz0Ld+pfq60C5maWxlcy9maWxlbGlzdC54bWwiPg0KPGxpbmsgcmVsPUVkaXQtVGlt ZS1EYXRhIGhyZWY9Ii4vaDFhMkAxNjMuY29tJTIwJTIwr8Go+qdLtk+qurPQt36l+rrQLmZpbGVz L2VkaXRkYXRhLm1zbyI+DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6 dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K d1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPG86RG9jdW1lbnRQcm9wZXJ0aWVzPg0KICA8bzpBdXRob3I+QUFBPC9vOkF1dGhv cj4NCiAgPG86VGVtcGxhdGU+Tm9ybWFsPC9vOlRlbXBsYXRlPg0KICA8bzpMYXN0QXV0aG9yPkFB QTwvbzpMYXN0QXV0aG9yPg0KICA8bzpSZXZpc2lvbj4yMDwvbzpSZXZpc2lvbj4NCiAgPG86VG90 YWxUaW1lPjExPC9vOlRvdGFsVGltZT4NCiAgPG86Q3JlYXRlZD4yMDAyLTAzLTA4VDE5OjIwOjAw WjwvbzpDcmVhdGVkPg0KICA8bzpMYXN0U2F2ZWQ+MjAwMi0xMC0yNFQwNzo1MzowMFo8L286TGFz dFNhdmVkPg0KICA8bzpQYWdlcz4xPC9vOlBhZ2VzPg0KICA8bzpXb3Jkcz4xMTY8L286V29yZHM+ DQogIDxvOkNoYXJhY3RlcnM+NjYzPC9vOkNoYXJhY3RlcnM+DQogIDxvOkxpbmVzPjU8L286TGlu ZXM+DQogIDxvOlBhcmFncmFwaHM+MTwvbzpQYXJhZ3JhcGhzPg0KICA8bzpDaGFyYWN0ZXJzV2l0 aFNwYWNlcz44MTQ8L286Q2hhcmFjdGVyc1dpdGhTcGFjZXM+DQogIDxvOlZlcnNpb24+OS4yODEy PC9vOlZlcnNpb24+DQogPC9vOkRvY3VtZW50UHJvcGVydGllcz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDx3OldvcmREb2N1bWVudD4NCiAgPHc6Q29tcGF0 aWJpbGl0eT4NCiAgIDx3OlVzZUZFTGF5b3V0Lz4NCiAgPC93OkNvbXBhdGliaWxpdHk+DQogPC93 OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6t3Oy06n6xek7DQoJ cGFub3NlLTE6MiAyIDMgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1hbHQ6UE1pbmdMaVU7DQoJ bXNvLWZvbnQtY2hhcnNldDoxMzY7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJ bXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjEgMTM0NzQyMDE2 IDE2IDAgMTA0ODU3NiAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAt3Oy06n6xeki Ow0KCXBhbm9zZS0xOjIgMiAzIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtY2hhcnNldDoxMzY7 DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFi bGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjEgMTM0NzQyMDE2IDE2IDAgMTA0ODU3NiAwO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IrXYsWSy07bqxelcKFBcKSI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1hbHQ6t3Oy06n6xek7DQoJbXNvLWZvbnQtY2hh cnNldDoxMzY7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtZm9y bWF0Om90aGVyOw0KCW1zby1mb250LXBpdGNoOmF1dG87DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjEg MTM0NzQyMDE2IDE2IDAgMTA0ODU3NiAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA tdixZLLTturF6VwoUFwpIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwOw0KCW1zby1m b250LWNoYXJzZXQ6MTM2Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFuOw0KCW1zby1m b250LWZvcm1hdDpvdGhlcjsNCgltc28tZm9udC1waXRjaDphdXRvOw0KCW1zby1mb250LXNpZ25h dHVyZToxIDEzNDc0MjAxNiAxNiAwIDEwNDg1NzYgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxl LXBhcmVudDoiIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28t cGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTq3c7LTqfrF6TsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KcA0KCXttYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTq3c7LTqfrF6TsNCgltc28taGFuc2kt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KIC8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCkBwYWdlDQoJe21zby1w YWdlLWJvcmRlci1zdXJyb3VuZC1oZWFkZXI6bm87DQoJbXNvLXBhZ2UtYm9yZGVyLXN1cnJvdW5k LWZvb3Rlcjpubzt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCglt YXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0Ow0KCW1zby1oZWFkZXItbWFyZ2luOjQy LjU1cHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46NDkuNnB0Ow0KCW1zby1wYXBlci1zb3VyY2U6MDt9 DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI3Ii8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIi8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8 Ym9keSBsYW5nPVpILVRXIHN0eWxlPSd0YWItaW50ZXJ2YWw6MjQuMHB0Jz4NCg0KPGRpdiBjbGFz cz1TZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo0OC4w cHQ7dGV4dC1pbmRlbnQ6LTQ4LjBwdDttc28tY2hhci1pbmRlbnQtY291bnQ6DQotNC4wO21zby1j aGFyLWluZGVudC1zaXplOjEyLjBwdDtsYXlvdXQtZ3JpZC1tb2RlOmNoYXI7bXNvLWNoYXItaW5k ZW50LXNpemU6DQoxMnB0Jz6hXaRAoV6hQqZwqke7oaazPHNwYW4gbGFuZz1FTi1VUz5+PHNwYW4g c3R5bGU9J2NvbG9yOnJlZCc+pECl96jGt348L3NwYW4+uOqq9yCpsa2xILHAvlAgsGWzZiCmrLFi DQqnebNmIK23wEkgt37BWrNxs3Gko6XOfrzLvMuko7vdPHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+ p1akT7hnwOc2LTEyrdOk6zwvc3Bhbj60Tq/gvtamszxzcGFuDQpzdHlsZT0nY29sb3I6cmVkJz41 LTEwuFWkuKv5xPKpyqq6stelzaaspEo8L3NwYW4+s2+78qZuqrq+97d8sXqko6jTuNW41bbcoUa8 eKX+rNmltKv3udmm8aFDIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo0OC4wcHQ7dGV4dC1pbmRlbnQ6LTQ4LjBwdDttc28tY2hh ci1pbmRlbnQtY291bnQ6DQotNC4wO21zby1jaGFyLWluZGVudC1zaXplOjEyLjBwdDtsYXlvdXQt Z3JpZC1tb2RlOmNoYXI7bXNvLWNoYXItaW5kZW50LXNpemU6DQoxMnB0Jz6hXaRHoV6hQqZwqkex catLp1Gw06mxpVio06N4pEihRrOjuPKxeqazw/arWaFDPHNwYW4gc3R5bGU9J2NvbG9yOmZ1Y2hz aWEnPqXYq2Wl/qzZpHemszxzcGFuDQpsYW5nPUVOLVVTPjQwrmGpsa2xPC9zcGFuPjwvc3Bhbj6h RrF6pKOlsqVYut6+UKFGqEOuYTxzcGFuIGxhbmc9RU4tVVM+MTCkSLROpm6je6FGMTCkSCo0MKS4 KLROubO5TLj0tk8pKjQwrmE9PHNwYW4NCnN0eWxlPSdjb2xvcjpmdWNoc2lhJz4xNjAwMKS4s2+8 y6N4pqykSqFDPC9zcGFuPqSjrW6xeqN4pVu3+ar3u1CrT8PSqvehRqV1rW6xeq7jpsyqb8ZRwua+ TK/5tKujfKZhpOiu+LZPs7qkXaVppUio07ftPHNwYW4NCnN0eWxlPSdjb2xvcjpmdWNoc2lhJz6z c8Lqtlew06N4ptHB86FDPC9zcGFuPiA8L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2xheW91dC1ncmlkLW1vZGU6Y2hhcic+oV2kVKFeoUI8c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPqXYq2XB2Twvc3Bhbj6mszxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjpibHVl Jz4zMDCmaK5htbK3+amxPC9zcGFuPqFdplWm5rd+s6Oms6FerbmhQqbnoUKm7aFCpuahQqh8oUK8 1rzLvMu79KX+oUY8c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsdWUnPrOjuPKxeqazw/arWaFDPC9zcGFu PiA8L3A+DQoNCjxmb3JtIGFjdGlvbj0ibWFpbHRvOmgxYTJAMTYzLmNvbT9zdWJqZWN0PafarW6w 0aVbpf6lwbNzwuq2V7DTqMa3frnOtqQiIG1ldGhvZD1wb3N0DQplbmN0eXBlPSJ0ZXh0L3BsYWlu Ij4NCg0KPHAgYWxpZ249Y2VudGVyIHN0eWxlPSdtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAw MDFwdDt0ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MjQuMHB0 O21zby1hc2NpaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjpmdWNoc2lhOw0K bXNvLWZvbnQta2VybmluZzoxLjBwdDttc28tYW5zaS1sYW5ndWFnZTpaSC1UVyc+pf6lwbNzwuqo xrd+PC9zcGFuPjwvYj48L3A+DQoNCjxwIGFsaWduPWNlbnRlciBzdHlsZT0nbWFyZ2luLXRvcDo0 LjVwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NC41cHQ7DQptYXJnaW4tbGVmdDow Y207dGV4dC1hbGlnbjpjZW50ZXI7bGluZS1oZWlnaHQ6MjAwJSc+PGI+PHNwYW4gbGFuZz1FTi1V Uw0Kc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IrXYsWSy07bqxelcKFBcKSI7 Y29sb3I6Ymx1ZSc+PElOUFVUIFRZUEU9ImNoZWNrYm94IiBOQU1FPSKn2q1ur8Go+qdLtk+qurPQ t36l+rrQIiBWQUxVRT0ivdCn1qRAwkkiPjwvc3Bhbj48L2I+PGI+PHNwYW4NCnN0eWxlPSdmb250 LXNpemU6MTMuNXB0O2NvbG9yOnJlZCc+p9qtbq/BqPqnS7ZPqrq7oan6pfq60Dwvc3Bhbj48L2I+ PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgYWxpZ249Y2Vu dGVyPg0KDQo8dGFibGUgYm9yZGVyPTEgY2VsbHNwYWNpbmc9MSBjZWxscGFkZGluZz0wIHdpZHRo PTUwMiBzdHlsZT0nd2lkdGg6Mzc2LjZwdDsNCiBtc28tY2VsbHNwYWNpbmc6LjdwdDttYXJnaW4t bGVmdDo2OS41cHQ7bXNvLXBhZGRpbmctYWx0OjBjbSAwY20gMGNtIDBjbScNCiBoZWlnaHQ9MT4N CiA8dHIgc3R5bGU9J2hlaWdodDoxNS4wcHQnPg0KICA8dGQgd2lkdGg9MTY5IHN0eWxlPSd3aWR0 aDoxMjcuMDVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWlnaHQ6MTUu MHB0JyBib3JkZXJjb2xvcmxpZ2h0PSIjODA4MDgwIj4NCiAgPHAgc3R5bGU9J3RleHQtYWxpZ246 anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoJz48Yj48c3Bhbg0KICBzdHlsZT0n Y29sb3I6IzY2OTkzMyc+pKSk5altplc8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48 L286cD48L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9MzMwIHN0eWxlPSd3aWR0aDoy NDcuNDVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWlnaHQ6MTUuMHB0 JyBib3JkZXJjb2xvcmxpZ2h0PSIjODA4MDgwIj4NCiAgPHAgc3R5bGU9J3RleHQtYWxpZ246anVz dGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoJz48c3BhbiBsYW5nPUVOLVVTDQogIHN0 eWxlPSdjb2xvcjp5ZWxsb3cnPjxJTlBVVCBUWVBFPSJ0ZXh0IiBTSVpFPSIxNCIgTkFNRT0ipKSk 5altplciPjwvc3Bhbj48L3A+DQogIDwvdGQ+DQogPC90cj4NCiA8dHIgc3R5bGU9J2hlaWdodDou NzVwdCc+DQogIDx0ZCB3aWR0aD0xNjkgc3R5bGU9J3dpZHRoOjEyNy4wNXB0O3BhZGRpbmc6Ljc1 cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhlaWdodDouNzVwdCcgYm9yZGVyY29sb3JsaWdodD0i IzgwODA4MCI+DQogIDxwIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5Omlu dGVyLWlkZW9ncmFwaDttc28tbGluZS1oZWlnaHQtYWx0Og0KICAuNzVwdCc+PGI+PHNwYW4gc3R5 bGU9J2NvbG9yOiM2Njk5MzMnPqZ+xNY8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48 L286cD48L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9MzMwIHN0eWxlPSd3aWR0aDoy NDcuNDVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWlnaHQ6Ljc1cHQn IGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0 aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7bXNvLWxpbmUtaGVpZ2h0LWFsdDoNCiAg Ljc1cHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnllbGxvdyc+PElOUFVUIFRZUEU9 InRleHQiIFNJWkU9IjQiIE5BTUU9IqZ+xNYiPjwvc3Bhbj48Yj48c3Bhbg0KICBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtjb2xvcjojNjY5OTMzJz63szxzcGFuIGxhbmc9RU4tVVM+KDE4t7OlSKRX KTwvc3Bhbj48L3NwYW4+PC9iPjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KIDx0ciBzdHlsZT0naGVp Z2h0Oi43NXB0Jz4NCiAgPHRkIHdpZHRoPTE2OSBzdHlsZT0nd2lkdGg6MTI3LjA1cHQ7cGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0Oi43NXB0JyBib3JkZXJjb2xvcmxp Z2h0PSIjODA4MDgwIj4NCiAgPHAgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoJz48Yj48c3Bhbg0KICBzdHlsZT0nY29sb3I6IzY2OTkzMyc+wXC1 uLlxuNw8c3BhbiBsYW5nPUVOLVVTPiA6PC9zcGFuPjwvc3Bhbj48L2I+PC9wPg0KICA8cCBzdHls ZT0ndGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7bXNvLWxp bmUtaGVpZ2h0LWFsdDoNCiAgLjc1cHQnPjxiPjxzcGFuIHN0eWxlPSdjb2xvcjojNjY5OTMzJz6m 5rDKuXG43KFHPC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPTMzMCBzdHlsZT0nd2lkdGg6MjQ3LjQ1cHQ7cGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0Oi43NXB0JyBib3JkZXJjb2xvcmxp Z2h0PSIjODA4MDgwIj4NCiAgPHAgc3R5bGU9J21hcmdpbi10b3A6Mi4yNXB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbToyLjI1cHQ7bWFyZ2luLWxlZnQ6DQogIDBjbTt0ZXh0LWFsaWdu Omp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDtsaW5lLWhlaWdodDoxNTAlJz48 c3Bhbg0KICBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjp5ZWxsb3cnPjxJTlBVVCBUWVBFPSJ0ZXh0 IiBTSVpFPSIxNCIgTkFNRT0iwXC1uLlxuNwtpdWk0SI+PC9zcGFuPjwvcD4NCiAgPHAgc3R5bGU9 J21hcmdpbi10b3A6Mi4yNXB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToyLjI1cHQ7 bWFyZ2luLWxlZnQ6DQogIDBjbTt0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVy LWlkZW9ncmFwaDttc28tbGluZS1oZWlnaHQtYWx0Oi43NXB0Jz48c3Bhbg0KICBsYW5nPUVOLVVT IHN0eWxlPSdjb2xvcjp5ZWxsb3cnPjxJTlBVVCBUWVBFPSJ0ZXh0IiBTSVpFPSIxNCIgTkFNRT0i wXC1uLlxuNwtpu2uYSI+PC9zcGFuPjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KIDx0ciBzdHlsZT0n aGVpZ2h0Oi43NXB0Jz4NCiAgPHRkIHdpZHRoPTE2OSBzdHlsZT0nd2lkdGg6MTI3LjA1cHQ7cGFk ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0Oi43NXB0JyBib3JkZXJjb2xv cmxpZ2h0PSIjODA4MDgwIj4NCiAgPHAgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1 c3RpZnk6aW50ZXItaWRlb2dyYXBoO21zby1saW5lLWhlaWdodC1hbHQ6DQogIC43NXB0Jz48Yj48 c3BhbiBzdHlsZT0nY29sb3I6IzY2OTkzMyc+s8yk6KtLwXC1uK7JtqE8L3NwYW4+PC9iPjxzcGFu IGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9 MzMwIHN0eWxlPSd3aWR0aDoyNDcuNDVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0 Ow0KICBoZWlnaHQ6Ljc1cHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cCBzdHls ZT0ndGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7bXNvLWxp bmUtaGVpZ2h0LWFsdDoNCiAgLjc1cHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOnll bGxvdyc+PFNFTEVDVCBOQU1FPSKzzKToq0vBcLW4rsm2oS2sULTBIj4NCjxPUFRJT04gU0VMRUNU RUQ+vdC/777cDQo8T1BUSU9OPqxQtMGkQA0KPE9QVElPTj6sULTBpEcNCjxPUFRJT04+rFC0waRU DQo8T1BUSU9OPqxQtMGlfA0KPE9QVElPTj6sULTBpK0NCjxPUFRJT04+rFC0waS7DQo8T1BUSU9O PqxQtMGk6Q0KPE9QVElPTj6zo6VppUgNCjwvU0VMRUNUPjxTRUxFQ1QgTkFNRT0is8yk6KtLwXC1 uK7JtqEtrsmscSI+DQo8T1BUSU9OIFNFTEVDVEVEPr3Qv+++3A0KPE9QVElPTj6kV6TIOS0xMg0K PE9QVElPTj6kpKTIMTItMQ0KPE9QVElPTj6kVaTIMS01DQo8T1BUSU9OPrHfpFc4LTEwDQo8T1BU SU9OPrHfpFc5LTExDQo8T1BUSU9OPrOjpWmlSA0KPC9TRUxFQ1Q+PC9zcGFuPjwvcD4NCiAgPC90 ZD4NCiA8L3RyPg0KIDx0ciBzdHlsZT0naGVpZ2h0OjE4LjBwdCc+DQogIDx0ZCB3aWR0aD0xNjkg c3R5bGU9J3dpZHRoOjEyNy4wNXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQog IGhlaWdodDoxOC4wcHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0KICA8cCBzdHlsZT0n dGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgnPjxiPjxzcGFu DQogIHN0eWxlPSdjb2xvcjojNjY5OTMzJz6mYad9PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVT PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPTMzMCBzdHlsZT0n d2lkdGg6MjQ3LjQ1cHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0 OjE4LjBwdCcgYm9yZGVyY29sb3JsaWdodD0iIzgwODA4MCI+DQogIDxwIHN0eWxlPSd0ZXh0LWFs aWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCc+PHNwYW4gbGFuZz1FTi1V Uw0KICBzdHlsZT0nY29sb3I6eWVsbG93Jz48SU5QVVQgVFlQRT0idGV4dCIgU0laRT0iNDkiIE5B TUU9IqZhp30iPjwvc3Bhbj48L3A+DQogIDwvdGQ+DQogPC90cj4NCiA8dHIgc3R5bGU9J2hlaWdo dDoxMi43NXB0Jz4NCiAgPHRkIHdpZHRoPTE2OSBzdHlsZT0nd2lkdGg6MTI3LjA1cHQ7cGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdDsNCiAgaGVpZ2h0OjEyLjc1cHQnIGJvcmRlcmNvbG9y bGlnaHQ9IiM4MDgwODAiPg0KICA8cCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVz dGlmeTppbnRlci1pZGVvZ3JhcGgnPjxiPjxzcGFuDQogIHN0eWxlPSdjb2xvcjojNjY5OTMzJz65 caRstmyl8zwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQogIDwvdGQ+DQogIDx0ZCB3aWR0aD0zMzAgc3R5bGU9J3dpZHRoOjI0Ny40NXB0O3BhZGRpbmc6 Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7DQogIGhlaWdodDoxMi43NXB0JyBib3JkZXJjb2xvcmxp Z2h0PSIjODA4MDgwIj4NCiAgPHAgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoJz48c3BhbiBsYW5nPUVOLVVTDQogIHN0eWxlPSdjb2xvcjp5ZWxs b3cnPjxJTlBVVCBUWVBFPSJ0ZXh0IiBTSVpFPSI0OSIgTkFNRT0iuXGkbLZspfMiPjwvc3Bhbj48 L3A+DQogIDwvdGQ+DQogPC90cj4NCiA8dHIgc3R5bGU9J2hlaWdodDozMi4yNXB0Jz4NCiAgPHRk IHdpZHRoPTE2OSBzdHlsZT0nd2lkdGg6MTI3LjA1cHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVw dCAuNzVwdDsNCiAgaGVpZ2h0OjMyLjI1cHQnIGJvcmRlcmNvbG9ybGlnaHQ9IiM4MDgwODAiPg0K ICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoJz48Yj48c3Bhbg0KICBzdHlsZT0nY29sb3I6IzY2OTkzMyc+q9jE s6jGtrU8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPg0K ICA8L3RkPg0KICA8dGQgd2lkdGg9MzMwIHN0eWxlPSd3aWR0aDoyNDcuNDVwdDtwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Ow0KICBoZWlnaHQ6MzIuMjVwdCcgYm9yZGVyY29sb3JsaWdo dD0iIzgwODA4MCI+DQogIDxwIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5 OmludGVyLWlkZW9ncmFwaCc+PHNwYW4gbGFuZz1FTi1VUw0KICBzdHlsZT0nY29sb3I6eWVsbG93 Jz48SU5QVVQgVFlQRT0idGV4dCIgU0laRT0iNDkiIE5BTUU9IqvYxLOoxra1Ij48L3NwYW4+PC9w Pg0KICA8L3RkPg0KIDwvdHI+DQo8L3RhYmxlPg0KDQo8L2Rpdj4NCg0KPHAgYWxpZ249Y2VudGVy IHN0eWxlPSdtYXJnaW4tdG9wOjIuMjVwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 Mi4yNXB0Ow0KbWFyZ2luLWxlZnQ6MGNtO3RleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjE1 MCUnPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdjb2xvcjojNjYwMENDJz48SU5QVVQgVFlQRT0i c3VibWl0IiBBQ1RJT049Im1haWx0bzpoMWEyQDE2My5jb20/c3ViamVjdD2n2q1usNGlW6X+pcGz c8Lqtlew06jGt365zrakIiBWQUxVRT0ip9qtbqVbpEqoxrd+peum8aFBsGWlWLjqrsYiIEVOQ1RZ UEU9InRleHQvcGxhaW4iIE1FVEhPRD0icG9zdCIgTkFNRT0ivVS7eyINCkFDVElPTj0ibWFpbHRv OmgxYTJAMTYzLmNvbT9zdWJqZWN0PafarW6w0aVbpf6lwbNzwuq2V7DTqMa3frnOtqQiIEVOQ1RZ UEU9InRleHQvcGxhaW4iDQpNRVRIT0Q9cG9zdCBBQ1RJT049Im1haWx0bzpoMWEyQDE2My5jb20/ c3ViamVjdD2n2q1usNGlW6X+pcGzc8Lqtlew06jGt365zrakIg0KRU5DVFlQRT0idGV4dC9wbGFp biIgTUVUSE9EPXBvc3QNCkFDVElPTj0ibWFpbHRvOmgxYTJAMTYzLmNvbT9zdWJqZWN0PafarW6w 0aVbpf6lwbNzwuq2V7DTqMa3frnOtqQiIEVOQ1RZUEU9InRleHQvcGxhaW4iDQpNRVRIT0Q9cG9z dCBBQ1RJT049Im1haWx0bzpoMWEyQDE2My5jb20/c3ViamVjdD2n2q1usNGlW6X+pcGzc8Lqtlew 06jGt365zrakIg0KRU5DVFlQRT0idGV4dC9wbGFpbiIgTUVUSE9EPXBvc3QNCkFDVElPTj0ibWFp bHRvOmgxYTJAMTYzLmNvbT9zdWJqZWN0PafarW6w0aVbpf6lwbNzwuq2V7DTqMa3frnOtqQiIEVO Q1RZUEU9InRleHQvcGxhaW4iDQpNRVRIT0Q9cG9zdCBBQ1RJT049Im1haWx0bzpoMWEyQDE2My5j b20/c3ViamVjdD2n2q1usNGlW6X+pcGzc8Lqtlew06jGt365zrakIg0KRU5DVFlQRT0idGV4dC9w bGFpbiIgTUVUSE9EPXBvc3QNCkFDVElPTj0ibWFpbHRvOmgxYTJAMTYzLmNvbT9zdWJqZWN0Pafa rW6w0aVbpf6lwbNzwuq2V7DTqMa3frnOtqQiIEVOQ1RZUEU9InRleHQvcGxhaW4iDQpNRVRIT0Q9 cG9zdCBBQ1RJT049Im1haWx0bzpoMWEyQDE2My5jb20/c3ViamVjdD2n2q1usNGlW6X+pcGzc8Lq tlew06jGt365zrakIg0KRU5DVFlQRT0idGV4dC9wbGFpbiIgTUVUSE9EPXBvc3Q+PElOUFVUIFRZ UEU9InJlc2V0IiBWQUxVRT0irau28SIgTkFNRT0irau28SI+PC9zcGFuPjwvcD4NCg0KPC9mb3Jt Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+ ------=_NextPart_10iN6SimAmnEettMEPAA-- ------=_NextPart_10iN6SimAmnEettMEP-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 18 15:11:03 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 PAA02133 for ; Mon, 18 Nov 2002 15:11:02 -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 gAIKCnP06562 for ; Mon, 18 Nov 2002 15:12:50 -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 gAIKClZ15421 for ; Mon, 18 Nov 2002 15:12:47 -0500 (EST) Message-ID: From: "Marco Carugi" To: "'ppvpn@nortelnetworks.com'" Subject: FW: Please Announce Date: Mon, 18 Nov 2002 21:11:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28F3E.A2C0EE94" 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_01C28F3E.A2C0EE94 Content-Type: text/plain; charset="iso-8859-1" FYI -----Original Message----- From: Bob Hinden [mailto:hinden@iprg.nokia.com] Sent: lundi 18 novembre 2002 16:09 To: wgchairs@ietf.org Subject: Please Announce Please announce this at the start of your working group sessions. Thanks, Bob >X-Delivered-For: >X-mProtect: <200211181506> Nokia Silicon Valley Messaging Protection >X-Sender: hinden@mailhost.iprg.nokia.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Mon, 18 Nov 2002 07:05:57 -0800 >To: ietf@ietf.org >From: Bob Hinden >Subject: WLAN at IETF55 > >We are seeing some of the usual problems with the wireless support at >IETF55 in Atlanta. To help mitigate the problems: > >1) Make sure you laptop is configured with SSID of IETF55 > >2) Do not allow your laptop to run in peer-to-peer mode. Set it to Access > Point only mode. > >We are seeing many nodes running in peer-to-peer mode. It is essential >that people not run in peer-to-peer mode. If you run in peer-to-peer mode >(even unintentionally) it will disrupt other people and the overall >wireless network operation. Many new OS's will fall back to peer-to-peer >mode by default. Please make yours does not do this. > >See http://www.ietf55.ops.ietf.org/ietf55/NetworkTerminal for more detail >on OS setup. > >Thanks, >Bob (for the NOC team) > >p.s. Later today we will start confiscating the wireless cards of people > running in peer-to-peer mode.... ------_=_NextPart_001_01C28F3E.A2C0EE94 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Please Announce

FYI

-----Original Message-----
From: Bob Hinden [mailto:hinden@iprg.nokia.com]<= /FONT>
Sent: lundi 18 novembre 2002 16:09
To: wgchairs@ietf.org
Subject: Please Announce


Please announce this at the start of your working = group sessions.

Thanks,
Bob


>X-Delivered-For: = <hinden@iprg.nokia.com>
>X-mProtect: <200211181506> Nokia Silicon = Valley Messaging Protection
>X-Sender: hinden@mailhost.iprg.nokia.com
>X-Mailer: QUALCOMM Windows Eudora Version = 4.3.2
>Date: Mon, 18 Nov 2002 07:05:57 -0800
>To: ietf@ietf.org
>From: Bob Hinden = <hinden@IPRG.nokia.com>
>Subject: WLAN at IETF55
>
>We are seeing some of the usual problems with = the wireless support at
>IETF55 in Atlanta.  To help mitigate the = problems:
>
>1) Make sure you laptop is configured with SSID = of IETF55
>
>2) Do not allow your laptop to run in = peer-to-peer mode.  Set it to Access
>    Point only mode.
>
>We are seeing many nodes running in peer-to-peer = mode.  It is essential
>that people not run in peer-to-peer mode.  = If you run in peer-to-peer mode
>(even unintentionally) it will disrupt other = people and the overall
>wireless network operation.  Many new OS's = will fall back to peer-to-peer
>mode by default.  Please make yours does = not do this.
>
>See http://www.ietf55.ops.ietf.org/ietf55/NetworkTerminal<= /A> for more detail
>on OS setup.
>
>Thanks,
>Bob (for the NOC team)
>
>p.s.  Later today we will start = confiscating the wireless cards of people
>       running in = peer-to-peer mode....

------_=_NextPart_001_01C28F3E.A2C0EE94-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 18 21:28:38 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 VAA11442 for ; Mon, 18 Nov 2002 21:28:38 -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 gAJ2UUP18696 for ; Mon, 18 Nov 2002 21:30:30 -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 gAJ2UQZ22519 for ; Mon, 18 Nov 2002 21:30:26 -0500 (EST) Date: Tue, 19 Nov 2002 10:20:34 +0800 From: lidefeng Subject: Send it again. ///Re: Please Review: A new draft about PPVPN(Hierarchy of PE Device in BGP/MPLS VPN) To: nsyracus@ietf.org, internet-drafts@ietf.org Cc: rwilder@masergy.com, "Marco Carugi" , ppvpn@nortelnetworks.com, lhj@huawei.com, changwj@huawei.com, "Fu Y. Miao" , leh10814@huawei.com Message-id: <003501c28f72$3e88ed80$22436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_FNz+MLIu8t3Z061SBHZVIA)" X-Priority: 3 X-MSMail-priority: Normal References: <002e01c2854e$84f83ec0$22436e0a@HUAWEI.COM> <200211060438.XAA10375@ietf.org> X-SMTP-HELO: mta0 X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.10] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_FNz+MLIu8t3Z061SBHZVIA) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: QUOTED-PRINTABLE Because the cut-off for Internet-Draft submissions last time, the att= ached draft is not included in the Internet Draft Directory=A3=ACso I send = it again,there is little difference from the last one except some wording.We hope you can review it. Thanks & Regards Defeng Li ----- Original Message ----- =46rom: "Internet Draft Submission Manager" To: Sent: Wednesday, November 06, 2002 12:38 PM Subject: Re: Please Review: A new draft about PPVPN(Hiberarchy of PE = Device in BGP/MPLS VPN) > Greetings, > > We are sorry, but the cut-off for Internet-Draft submissions was Mo= nday > November 4 at 9AM ET. Your submission will not be retained (i.e. yo= u > need to resubmit) after November 17, 2002. > > If you receive this announcement, your submission will NOT be proce= ssed. > > Any submissions received prior to November 18, 2002 will not be ret= ained; > they must be resubmitted. Internet-Draft submissions received on or= after > November 18 will be processed. However, Internet-Draft announcement= s will > not be sent until after the IETF Meeting in Atlanta. > > AS you may surmise, this is an extremly busy week. Be advised > that it may take a number of days to process and announce your > document. Our goal is to process and announce all valid > Internet-Draft submissions by November 12 at the latest. > > Thank you for your understanding. > > > IETF Secretariat --Boundary_(ID_FNz+MLIu8t3Z061SBHZVIA) Content-type: text/plain; name=draft-libin-hierarchy-pe-bgp-mpls-vpn-00.txt Content-disposition: attachment; filename=draft-libin-hierarchy-pe-bgp-mpls-vpn-00.txt Content-Transfer-Encoding: QUOTED-PRINTABLE Network Working Group Li B= in Internet Draft Dong Wei= si Expires: May 2003 Li Defe= ng =20 Huawei Technologi= es November 06, 200= 2 Hierarchy of Provider Edge Device in BGP/MPLS VPN =20 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six mon= ths and may be updated, replaced, or obsoleted by other documents at a= ny 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 In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device shou= ld maintain all the VPN routes of the VPNs which it belong to.When th= ere=20 are many VPNs converged by a PE,and the capacity of PE is relevant limited,then the bottleneck will be encountered.Another problem is= =20 that the current BGP/MPLS VPN model is something of a "Plane Modle= " where the demand of the performance of the PE device are all the= =20 same no matter which layer the PE device is belongs to.However,the= =20 typical network is "Core-Convergence-Access(Edge)" model,and the= =20 performance of the device is superior in Core Layer and inferior i= n=20 Access Layer,and the scale of network is large in Access Layer and= =20 small in Core Layer,the routes are converged in every layer,so in= =20 current "Plane Modle",when PE device push to the edge layer,it has= =20 to maintain more VPN routes,this makes it difficult to extend the = PE Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page = 1] =0C Draft November 20= 02 device to edge layer.This document defines an model of Hierarchy o= f=20 Provider Edge Device in BGP/MPLS VPN,where Hierarchy of Provider= =20 Edge Device can be composed of several device and every device tak= e=20 on the different part,partake the function of the former=20 concentrative PE,we call this model "Hierarchy Model",In this mode= l the demand of performance in Routing and Switching is strict to th= e=20 PE device in High layer,loose to the PE device in edge layer. =20 One HoPE can be composed of a SPE and UPES connected to the SPE,= =20 or be composed of a high-level SPE and HoPEs connected the high= =20 level SPE and and build up a new HoPE.This build is called nesting= =20 of HoPE,and this kind of nesting can be done for many times.Thus t= he=20 former HoPE connect to the high-level SPE as a role of UPE,and the= =20 new HoPE can connect a single UPE too. =20 Table of Contents(will edit in the last) 1. Introduction ................................................. = 3 2. Working Principle ........................ 4 2.1 VPN routes ............................................... 6 2.2 Control Flow(Route Advertising and Label Distribution) 2.3 Data Flow(Label Operation and Packet Forwarding) .............= .... 7 3. Interface between UPE and SPE..................................= ..... 7 4. Nesting of HoPE 5. Multi-Homing UPE 6. Backdoor link between UPEs 7. The Forwarding Procedure in Some Special Cases 8. Security Consideration 9. Acknowledge 10. References 11. Authors' Addresses Full Copyright Statement ........................................ = 11 Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page = 2] =0C Draft November 20= 02 1. Introduction This document defines an model of Hierarchy of Provider Edge Devic= e=20 in BGP/MPLS VPN,where Hierarchy of Provider Edge Device can be= =20 composed of several device and every device take on the different= =20 part,partake the function of the former concentrative PE,we call= =20 this model "Hierarchy Model",In this model the demand of=20 performance in Routing and Switching is strict to the PE device in= =20 High layer,loose to the PE device in edge layer. =20 PE device can connect to not only the Customer Edge(CE) device,but= =20 also a PE device,or even more generally an MPLS VPN network,and th= e connected PE devices formed the "Hierarchy of PE",and the PE devic= e which replace the former position of CE device in "Plane Model" is= =20 called Under-layer PE,UPE in short,and the PE device which UPE is= =20 connected to is called Superstratum PE,SPE in short,this=20 architiecture is called Hierarchy of PE,HoPE in short.and the=20 architecture figure is as follows(figure 1): =20 +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +-------= ---+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Si= te3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +-------= ---+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +-------= ---+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Si= te3| +----------+ | |--| MPLS |----| | | | +--+ +-------= ---+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ +---+=20 +----------+ +----+ =20 =20 =09 figure 1: Hierarchy of PE Architecture =20 Several UPE and SPE formed the Hierarchy of PE,which provide the= =20 conventional function of PE in "Plane Model",and their respective functions are as follows: =20 UPE maintains only the routes of the VPN sites which is directly= =20 connected to UPE,it don't maintain the routes of the remote VPN= =20 sites or only maintain the aggregate routes,SPE maintain the route= s of all the sites directly connected to this SPE and the sites directl= y=20 connected to UPE which directly connected to this SPE. =20 UPE distribute the inner MPLS labels for the routes in the sites= =20 directly connected to it,and advertise the labels to SPE with the= =20 Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page = 3] =0C Draft November 20= 02 VPN routes through MP-BGP,SPE don't advertise the routes in the= =20 remote sites to UPE,it only advertise the VRF default route or= =20 aggregate route to UPE,and the route is concomitant with the MPLS= =20 label. =20 MP-IBGP or MP-EBGP can be applied between UPE and SPE,while MP-IBG= P is applied,SPE should be the Route Reflector(RR) for all the UPEs= =20 collected to it,and UPE play the role of Client of this RR,BUT SPE doesn't act as the RR for other PEs. If MP-EBGP is applied=20 between MP-EBGP,the AS number of the UPEs should be the private AS number(64512~65535).In fact,the Hierarchy of PE can be handles wit= h the rules of Confederation,in which case every confederation AS is= =20 composed of only one BGP Speaker,the UPE collected to the SPE. =20 The packet forwarding between SPE and UPE is based on the label,so only one interface is needed to connected to each other,this=20 interface can be a physical interface,or sub-interface,such as VLA= N, PVC,tunnel such as GRE or LSP.When tunnel is applied between UPE a= nd SPE,an IP network or MPLS network can be deployed between them. =20 Hierarchy of PE takes on all the functions of the normal PE, there is no difference between them when looked outside,so this= =20 "special" PE can coexist with other PEs in the MPLS network. =20 2. Working Principle This section specifies the working principle of Hierarchy of PE= =20 including the maintaining of VPN routes,distribution of MPLS label= s, and packet forwarding. =20 2.1 VPN routes SPE can establish MP-BGP neighborship with UPE,if they are=20 administered by the same service provider,they can be MP-IBGP neighborship,otherwise should establish the MP-EBGP neighorship. = =20 =20 In the MP-IBGP case,if there exists the sites of the different UPE= s collected to an SPE belong to the same VPN,SPE as the Route Reflec= tor for the relevant UPEs,otherwise SPE act as the convergent PE for a= ll the UPEs collected to it.Route-Target lists are used to select the= =20 right VPN routes from other PEs as the normal "Plane Modle"=20 BGP/MPLS VPN(RFC 2547bis),while only SPE will exchange the route= =20 information with other PEs,UPE should send the import route=20 target list to SPE,SPE converge the route target lists and derive= =20 the HoPE-wide import route target list,with this HoPE-wide import= =20 route target,SPE can select the right VPN routes which belong to t= he=20 VPNs which have the sites connected the SPE directly or through UP= E. =20 This HoPE-wide import route target list can be configured staticly= =20 or derived dynamically between SPE and UPEs.The dynamic mechanism = is as follows: Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page = 4] =0C Draft November 20= 02 =20 UPE advertise the ORF(Outbound Route Filter)[BGP-ORF] to SPE throu= gh Route Refresh(RFC 2918) message,and an extended community list is included in the ORF item,the content of the extended community lis= t=20 is the aggregation of the import route target lists of all the VRF= s in the UPE,and SPE converge all the import route target lists=20 received from the UPEs connected to SPE and derive the HoPE-wide import route target list. =20 In MP-EBGP case,SPE should derive the HoPE-wide import route targe= t list all the same with the mechanism as above.In general,UPE shoul= d adopt the private AS number in VPN routes advertised to SPE.When S= PE advertised the routes to other PEs,SPE should omitted the private = AS. =20 The scheme in which SPE connected to part of UPEs through MP-IBGP, and to the other part UPEs through MP-EBGP is permitted. =20 =20 UPE selects its own VPN routes by match its own import route targe= t list with the export route target list attached with VPN routes respectively.=20 SPE advertised the VRF default route or aggregate routes(by which= =20 UPE transfer the VPN packet to SPE) to UPE,this default VRF route= =20 can be formed dynamically or configured statically.When formed= =20 dynamically,it can be filtered by the ORF mechanism mentioned abov= e. =20 2.2 Control Flow(Route Advertising and Label Distribution) =20 This section specifies the mechanism the network distribute the = =20 labels for the routes in the VPN sites.The following figure(Figure= 2)=20 signifies the control flow between VPN1 site1 and VPN1 SITE2,the= =20 control flows(route and label distribution) in the two direction a= re different,there are four steps in every direction,labeled (1) thro= ugh (4) in the direction from VPN1 SITE2 to VPN1 site1,and labeled (5) through (8) in the direction from VPN1 site1 to VPN1 SITE2. =20 | (4) | (3) | (2) | (1) | |<-------|<------|<--------------|<-----| v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +-------= ---+=09=09 |VPN1 Site1|-|CE1|---|UPE |---|SPE|---| P |---|PE|--|CE2|-|VPN1 SI= TE2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +-------= ---+ ^ ^ ^ ^ ^ | (5) | (6) | (7) | (8 ) | |------->|------>|-------------->|----->| =20 Figure 2: The control flow(route and label distribution) =20 Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page = 5] =0C Draft November 20= 02 In Figure 2,the meanings of (1) through (8) are as follows: Label (1) through (4) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: =20 (1) CE2 advertise a route in the VPN1 SITE2 to PE; =20 (2) PE distribute an inner MPLS label for this route;PE advertise t= his=20 route to SPE through MP-BGP with the inner label,and the relevant= =20 export route target list attached; =20 (3.a) SPE match the export route target list in the received route = with=20 the HoPE-wide import route target list to decide whether or not= =20 import the VPN route,in this case,they can be matched,then SPE will= =20 import the received VPN route. =20 (3.b)At the same time SPE will match the=20 export route target list in the received route with the import rout= e=20 target list advertised by VRF in UPEs connected to SPE,in this case= , the import route target list of the VRF in UPE correspond to VPN1= =20 Site1(called VRF1) will match,then SPE will advertise the default V= RF1=20 route to UPE,with the inner MPLS label distributed by PE attached; =20 (4) UPE advertise this route to CE1 through the route protocol(RIP, OSPF,BGP,or default route), =20 Label (5) through (8) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: =20 (5) CE1 advertise a route in the VPN1 site1 to UPE;=20 =20 (6) UPE distribute an inner label for this route;UPE advertise=20 this route to SPE through MP-BGP with the inner label; =20 (7) SPE replace the inner label distributed by UPE with another inn= er=20 label distributed by SPE,then advertise this route to PE through= =20 MP-BGP with the new inner label attached; =20 (8) PE distributed the route to CE2 with no label attached. =20 Of course,the LSP should be established between SPE and PE in two= =20 directions respectively,This mechanism is the same as RFC 2547bis. The procedure of forwarding VPN packet with the two labels detailed= =20 in section 2.3 =20 2.3 Data Flow(Label Operation and Packet Forwarding) =20 This section specifies the mechanism of forwarding the VPN packets= in the network with the route and label information derived by sectio= n=20 2.2. The following figure(Figure 3) signifies the data flows betwe= en=20 Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page = 6] =0C Draft November 20= 02 VPN1 site1 and VPN1 SITE2,the data flows(Label Operation and Packe= t=20 Forwarding) in the two direction are different,there are five step= s=20 in every direction,labeled (1) through (5) in the direction from= =20 VPN1 SITE2 to VPN1 site1,and labeled (6) through (10) in the=20 direction from VPN1 site1 to VPN1 SITE2. =20 | (10) | (9) | (8) | (7) | (6) | |<-------|<------|<--------|<-----|<-----| v v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +-------= ---+=09=09 |VPN1 Site1|-|CE1|---|UPE|---|SPE|---| P |---|PE|--|CE2|-|VPN1 SIT= E2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +-------= ---+ ^ ^ ^ ^ ^ ^ | (1) | (2) | (3) | (4) | (5) | |------->|------>|--------|----->|----->| =20 Figure 3: Data Flow(Label Operation and Packet Forwarding)= =20 In Figure 3,the meanings of (1) through (10) are as follows: Label (1) through (5) specifies the forwarding procedure in the= =20 direction of VPN1 Site1 visit VPN1 SITE2: =20 (1) When the VPN packet of VPN1 Site1 visit VPN1 SITE2 arrived to C= E1, CE1 forward the packet to UPE based on the default route or the= =20 route derive from dynamic route protocol between CE1 and UPE=20 specified in the (4) of section 2.2. =20 (2) UPE push the inner label based on the default VRF route,forward the VPN packet to SPE,the inner label and the default VRF route are specified in the (3) of section 2.2. =20 (3) SPE POP the inner label pushed by UPE specified in (2) above,an= d look up the VRF route,push the new inner label which distributed by= =20 PE specified by (2) of section 2.2,then push the outer label=20 distributed by P and forward the VPN packet to P,in backbone networ= k, all the P router in the path of LSP from SPE to PE swap the outer= =20 label and forward the VPN packet through this LSP until the packet= =20 arrived to PE,or optionally the P router pen-ultimate hop the label= . =20 (4) The P router pen-ultimate hop to PE POP the outer label,forward= =20 the VPN packet to PE. =20 (5) PE POP the inner label,forward the VPN packet to CE2,then CE2= =20 forward the VPN packet to the VPN1 SITE2 with the route in this sit= e. =20 Label (6) through (10) specifies the forwarding procedure in the= =20 direction of VPN1 SITE2 visit VPN1 Site1: =20 (6) When the VPN packet of VPN1 SITE2 visit VPN1 Site1 arrived to C= E2, =20 Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page = 7] =0C Draft November 20= 02 CE2 forward the packet to PE based on the default route or the rout= e=20 derive from dynamic route protocol between CE2 and PE specified in= =20 the (8) of section 2.2. =20 (7) PE push the inner label distributed by SPE specified in (7) of= =20 section 2.2 based on the VRF route,then push the outer label=20 distributed by P and forward the VPN packet to P,in backbone networ= k, all the P router in the path of LSP from PE to SPE swap the outer= =20 label and forward the VPN packet through this LSP until the P route= r=20 pen-ultimate hop to SPE. =20 (8) The P router optioanlly pen-ultimate hop to SPE POP the outer= =20 label,forward the VPN packet to SPE. =20 (9) SPE swap the inner label in the VPN packet replace the inner= =20 label distributed by SPE with the new inner label distributed by UP= E specified in (6) of section 2.2,then forward the VPN packet to UPE. =20 (10) UPE POP the new inner label,forward the VPN packet to CE1,then= =20 CE1 forward the VPN packet to the VPN1 Site1 with the route in this= =20 site. 3. Interface between UPE and SPE UPE can connect to SPE with any type of interface and sub-interfac= e, even with tunnel interface,in this case,UPE can connect with SPE through an IP or MPLS network,and because SPE and UPE are MP-BGP= =20 peers,the routes can be advertise directly through TCP connection.= =20 In MP-EBGP case,UPE and SPE can set up EBGP peers across the=20 IP network or MPLS network by Multi-hop EBGP,when UPE or SPE=20 forwarding the VPN packets with the label,they must pass a tunnel, if the tunnel is GRE,MPLS encapsulation must be supported;If the= =20 tunnel is LSP,the network between UPE ang SPE must be MPLS network= , LDP/CR-LDP or RSVP-TE must be supported in UPE and SPE. =20 4. Nesting of HoPE One HoPE can be composed of a SPE and UPES connected to the SPE,= =20 or be composed of a high-level SPE and HoPEs connected the high= =20 level SPE and and build up a new HoPE.This build is called nesting= =20 of HoPE,and this kind of nesting can be done for many times.Thus t= he=20 former HoPE connect to the high-level SPE as a role of UPE,and the= =20 new HoPE can connect a single UPE too.Figure 4 in the following= =20 signifies a three-layer HoPE,and call the PE in the middle layer a= s=20 MPE(Middle-level PE). Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page = 8] =0C Draft November 20= 02 +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +-------= ---+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Si= te3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +-------= ---+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +-------= ---+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Si= te3| +----------+ | |--| MPLS |----| | | | +--+ +-------= ---+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ | | +----------+ +----+ | | | | +----------+ +----+ +----+ | | |VPN1 Site4|--|UPE3|--|MPE |------| | +----------+ +----+ +----+ +---+ = =20 (Nesting of HoPE) =20 =09 figure 4: Nesting of HoPE =20 Between SPE and MPE,and between MPE and UPE run MP-BGP,if run=20 MP-IBGP,then SPE worked as the route reflector for all the MPE,and MPEs worked as the route reflector for all the UPEs,and MP-BGP= =20 advertise all the VPN routes of the underlayer PEs to the upperlay= er PE,and advertise the default VRF route or the aggregate route of t= he upperlayer to the underlayer PE. So SPE maintains all the VPN rout= es of the whole HoPE,and the MPE maintains the VPN routes of UPEs connected to this MPE.UPE maintain the VPN routes of sites connect= ed to this UPE. =20 SPE advertise the default VRF routes with the label attached to MP= E, MPE replaces this label with the new label,and advertise this rout= e=20 with the new label attached to UPE. =20 The upperlayer PE should create a HoPE-wide global import route= =20 target list,filter the VPN routes that don't belong to the VPNs connected to this upperlayer PE.MPE converge all the import route= =20 target lists of the UPEs connected to this MPE,and SPE converge al= l the converged import route target lists of the MPEs connected to= =20 this SPE.And this convergence can be configured statically or=20 derived dynamically,in the latter case,MPE should forward the impo= rt route target list of MPE to SPE through ORF. =20 When the VPN packet from the local site of HoPE is forwarded to UP= E, UPE look up the relevant default VRF route,push the label and=20 forward the packet to MPE,MPE POP the label,look up the default VR= F=20 Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page = 9] =0C Draft November 20= 02 route or aggregate route to SPE,PUSH a new label forward the packe= t=20 to SPE,SPE POP this label,look up the VRF forwarding table,PUSH th= e=20 inner label,and the outer label the P router distribute for this= =20 route,then follow the RFC 2547bis forwarding procedure. =20 Because MPE has distributes the inner label for the destination= =20 address of the VPN packet from the remote site,when the remote VPN packet is forwarded to SPE through the MPLS network following the= =20 RFC 2547bis forwarding procedure. SPE swap the inner label,forward= =20 this packet to MPE,for the same reason,MPE swap the inner label an= d=20 forward this packet to UPE,then UPE POP the inner label and forwar= d=20 this packet to the local site. 5. Multi-Homing UPE One UPE can connect to several SPEs,in this case UPE is called Multi-Homing UPE,all the SPEs advertise the default VRF routes to= =20 this UPE,and UPE select the best one or treat them as ECMP(Equal Cost Multi-Path) and share the load among them.UPE advertised the VPN routes to all the SPEs,it can advertises all the VPN routes to all the SPEs,or it can advertises one part of VPN routes to one SP= E, the other part to the other and shares the load among the SPEs. =20 6. Backdoor link between UPEs A kind of backdoor link can be setup between UPEs,so that the site= s=20 connected to these two UPEs can communicate with each other direct= ly without passing through the SPE.And these UPEs can be those connec= t=20 to the same SPE,or can be those connect to the different SPE,these= =20 UPEs advertise the VPN routes to each other through MP-BGP,The= =20 control flow and data flow are the same with RFC 2547bis Procedure= s, and even theu can cross a network,and the packet can pass through = a=20 tunnel such as GRE or LSP. =20 7. The Forwarding Procedure in Some Special Cases In one case that SPE connect two UPEs called UPE and UPE2,and thes= e two UPEs connect two sites called site1 and site2 respectively,and= =20 site1 and site2 belong to the same VPN and visit to each other= =20 through SPE.The forwarding procedure is as follows:When the packet= =20 sent from site1 arrived to UPE,UPE push the label based on the= =20 default route and forward it to SPE,SPE POP this label,then look u= p the VRF route table,PUSH the label distribute by UPE2 and forward = it=20 to UPE2,and UPE2 POP the label,forward it to site2,and in the=20 opposite direction,vise versa. =20 In another case that SPE connect one UPE and one CE,CE connect to site1,UPE connect to site2,site1 and site2 belong to the same VPN. The forwarding procedure is as follows: =20 (1)When the packet with no label sent from site1 arrived to SPE= =20 through CE, SPE look up VRF route table,and push the label distrib= uted=20 by UPE,forward it to UPE,UPE POP this label,forward it to Site2. =20 (2)When the packet originated from Site2 arrived to UPE,UPE transf= er the packet to SPE on the basis of default or aggregate route,SPE t= hen=20 look up the VRF route table,POP the label,forward it to Site1 as a= n IP packet. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 10= ] =0C Draft November 20= 02 =20 8. Security Consideration The level of security provided by this architecture is identical t= o=20 that provided by the RFC 2547bis,there is no security problem=20 introduced. 9. Acknowledgements The authors would like to thank Li Hejun, Cao Xuegui,Chang Wenjun,= =20 We are very appreciated for their support 10. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revis= ion=20 3", BCP 9, RFC 2026, October 1996. [BGP-ORF] Enke Chen,Yakov Rekhter,"Cooperative Route Filtering= =20 Capability for BGP-4",draft-ietf-idr-route-filter-06.tx= t. [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, September 2000 =20 [RFC2547] E. Rosen, Y. Rekhter, _BGP/MPLS VPNs,_ RFC 2547,March= =20 1999. =20 [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work i= n=20 progress.=20 =20 11.0 Author's Address Li Bin =20 D201 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : l.b@huawei.com =20 Dong Weisi =20 C401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : dongws@huawei.com =20 =20 Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : lidefeng@huawei.com Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 11= ] =0C Draft November 20= 02 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished t= o 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 removin= g the copyright notice or references to the Internet Society or othe= r 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 b= e 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 ENGINEERIN= G 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. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 12] --Boundary_(ID_FNz+MLIu8t3Z061SBHZVIA)-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 20 08:11: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 IAA18196 for ; Wed, 20 Nov 2002 08:11: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 gAKDDv207075 for ; Wed, 20 Nov 2002 08:13: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 gAKDDtI08257 for ; Wed, 20 Nov 2002 08:13:55 -0500 (EST) Message-ID: <3DDB2276.23F1A4C8@cisco.com> Date: Tue, 19 Nov 2002 21:49:42 -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: IETF PPVPN list Subject: IEEE 802.1 actions on Provider Bridges 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 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 Wed Nov 20 14:46:24 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 OAA28865 for ; Wed, 20 Nov 2002 14:46:23 -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 gAKJmN202289 for ; Wed, 20 Nov 2002 14:48: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 gAKJmKI16753 for ; Wed, 20 Nov 2002 14:48:20 -0500 (EST) Date: 20 Nov 2002 14:47:37 -0500 Message-ID: <3DDBE6D9.157B6E1D@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "IETF PPVPN list" Cc: pwe3@ietf.org X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Bridge or 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 L2 DT, From http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0211&L=ppvpn&T=0&O=D&P=14365 > VPLS service is enabled by a logical Bridged LAN, which consists of > physical or emulated LANs and Bridges. 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? thanks, cheng-yin From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 20 16:58:46 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 QAA02691 for ; Wed, 20 Nov 2002 16:58:45 -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 gAKM0l227821 for ; Wed, 20 Nov 2002 17:00:47 -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 gAKM0iI21198 for ; Wed, 20 Nov 2002 17:00:45 -0500 (EST) Message-ID: From: Sasha Vainshtein To: "Ali Sajassi (E-mail)" Cc: "Ppvpn (E-mail)" Subject: Issues with draft-sajassi-mvpls-00.txt Date: Wed, 20 Nov 2002 23:58:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" X-SMTP-HELO: antivir1 X-SMTP-MAIL-FROM: Sasha@AXERRA.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [80.74.100.67] X-LYRIS-Message-Id: Ali and all, I would like to re-state the issues I have raised at the PPVPN WG Session today. All these issues deal with the unicast part of the proposal. 1. Allocation of huge numbers of IP addresses (an IP address per AC). This looks highly problematic in inter-provider or even inter-AS situations (where use of private IP addresses is precluded). 2. Involvement of core routers in the VPLS: with each new AC, all the core routers have to learn routes to the associated IP address. I'd like to remind you that the PWE3 Charter (I am not sure about the PPVPN one) explicitly states that PW functionality is limited to PEs only and that PWs do not exert control over the underlying network. IMHO the proposal violates these principles. 3. Forwarding in the egress PE. The draft states that it is is based on the destination IP address found in the packet. It does not state whether aIP ddresses associated with an AC are considered as IP addresses owned by the PE router terminating this AC,or not. If they are not, the packets with the AC-associated destination IP address should be forwarded as IP packets which seems wrong, because such forwarding does not persume stripping of IP header, MAC address look-up etc. If they are, they would be treated based on the protocol number and according to the protocol-specific rules. In particular,if the protocol is L2TPv3 (as mentionedin the presentation), the Session ID lookup would be done and,if such a lookup fails (as it should since the draft explicitly states that no sessions are established), the packet will be discarded (or so I presume). ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 20 23:50: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 XAA11922 for ; Wed, 20 Nov 2002 23:50: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 gAL4qg204974 for ; Wed, 20 Nov 2002 23:52: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 gAL4qdd15882 for ; Wed, 20 Nov 2002 23:52:39 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 20 Nov 2002 20:52:22 -0800 Subject: Re: Issues with draft-sajassi-mvpls-00.txt From: Ray Qiu To: Sasha Vainshtein , "Ali Sajassi (E-mail)" CC: "Ppvpn (E-mail)" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Nov 2002 04:52:05.0558 (UTC) FILETIME=[BD476D60:01C29119] X-SMTP-HELO: RS-SC-EXC4.rs.riverstonenet.com X-SMTP-MAIL-FROM: rqiu@riverstonenet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host60.riverstonenet.com [64.95.122.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I would think another potential scaling issue is that core routers have to track all the Multicast states for all the VPLS's. - Ray On 11/20/02 13:58, "Sasha Vainshtein" wrote: > Ali and all, > I would like to re-state the issues I have raised at the PPVPN WG Session > today. > All these issues deal with the unicast part of the proposal. > > 1. Allocation of huge numbers of IP addresses (an IP address per AC). > This looks highly problematic in inter-provider or even inter-AS > situations > (where use of private IP addresses is precluded). > > 2. Involvement of core routers in the VPLS: with each new AC, all the core > routers > have to learn routes to the associated IP address. > I'd like to remind you that the PWE3 Charter (I am not sure about the > PPVPN one) > explicitly states that PW functionality is limited to PEs only and that > PWs do not > exert control over the underlying network. IMHO the proposal violates > these > principles. > > 3. Forwarding in the egress PE. The draft states that it is is based > on the destination IP address found in the packet. It does not state > whether aIP ddresses associated with an AC are considered as IP addresses > owned by the PE router terminating this AC,or not. If they are not, > the packets with the AC-associated destination IP address should be > forwarded as IP packets which seems wrong, because such forwarding > does not persume stripping of IP header, MAC address look-up etc. > If they are, they would be treated based on the protocol number > and according to the protocol-specific rules. In particular,if the > protocol > is L2TPv3 (as mentionedin the presentation), the Session ID lookup would > be > done and,if such a lookup fails (as it should since the draft explicitly > states > that no sessions are established), the packet will be discarded (or so I > presume). > > > ---------------------------------------------------------------------------- > -------- > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 21 07:46: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 HAA29784 for ; Thu, 21 Nov 2002 07:46: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 gALCmg329499 for ; Thu, 21 Nov 2002 07:48: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 gALCmdd19585 for ; Thu, 21 Nov 2002 07:48:40 -0500 (EST) Message-Id: <200211211248.gALCmIC27754@zrtps06u.us.nortel.com> From: "Dr.Wilfred Mboyo" To: Subject: Urgent Letter from Zimbabwe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 21 Nov 2002 13:48:11 X-SMTP-HELO: your-tx4s5p2lf6 X-SMTP-MAIL-FROM: wil222@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: Sir, URGENT BUSINESS RELATIONSHIP Firstly, I have to introduce myself to you. My name is Dr Wilfred Mboyo from Zimbabwe. I was the chairman of contract review panel in my country before the problem of the land reform program. Before the escalation of the situation in Zimbabwe I recovered $16.8Million US dollars from over inflated contracts by some government officials. But I was a member of the opposition party the MDC(Movement for Democratic Change), and the ruling Party, (ZANU PF) has been against us. So I had to flee the country for a neighbouring African Country which I am currently residing. Before the escalation of the situation in Zimbabwe I had not reported The recovery of my findings to the panel. So this money was in my possession and I lodged it in a security company here in Africa and currently this money has been moved to their security branch in Europe. I have been trying to fly to Europe but it has been difficult for me to get a visa from Africa. So I want you to help me make claims of this fund($16.8m) in Europe as my beneficiary and transfer the money to your account or any account of your choice before I can get a visa to fly down. So that we can share this money. I have agreed to give you 10%,which would be ($1.6Million dollars) of this Money for your assistance, and 85% would be mine and the other 5% would be set aside for any expenses that we may incure during the course of this transaction. And my 85% would be invested in your country in any profitable business propossed by you. We have never met, but I want to trust you and please do not let me down when this fund finally gets into your account. Please if you are interested, get to me through the email address below to enable me feed you with more details and all necessary documentations. Please treat this as confidential. ( mboyo2000@post.com or mboyo2001@email.com ) Regards, Dr.Wilfred Mboyo NOTE: In the event of your inability to handle this transaction please inform me so that i can look for another reliable person who can assist me. From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 21 18:15: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 SAA25614 for ; Thu, 21 Nov 2002 18:15:32 -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 gALNH9323414 for ; Thu, 21 Nov 2002 18:17: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 gALNH4d12861 for ; Thu, 21 Nov 2002 18:17:05 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15837.34153.7463.330618@lohi.eng.song.fi> Date: Fri, 22 Nov 2002 03:16:25 +0200 To: ppvpn@nortelnetworks.com Subject: fate of directory based discovery X-Mailer: VM 7.03 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: rautu X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dhcp-204-42-71-112.ietf55.ops.ietf.org [204.42.71.112] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit there was not enough support in atlanta meeting to make the dns discovery i-d a working group document. i guess it would be appropriate to confirm that also on the mailing list, since not everyone who has been working on the dns discovery was able to attend the meeting. anyhow, i have always said that i don't care what the directory is as long as the vpn solution is internet wide and doesn't use bgp. some people didn't like dns discovery, because (although simple) it overloads dns with stuff that dns was not designed to do. so there may still be enough support left for a directory based solution if something "better" than dns can be found. i have been thinking for some time now that radius might be a another possibility for implementing discovery. it would go something like this: - radius is populated for each ce with information about the vpn that the ce participates in (if any) - a ce authenticates to the pe using e.g. 802.1x (or the ce is manually configured in the pe) - pe makes a radius query and gets as a response the id of the ce's vpn and a list of other pes that have members in the same vpn - the vpn's pe list is kept up in the radius server either manually or based on radius accounting start/stop messages this would be a very flexible and automated solution, since there in case .1x is used, NOTHING ce related needs to be configured in the pe. before spending more time on this, i would need to get an indication from the working group if there is enough interest for ANY directory based solution. -- juha From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 21 19:07:16 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 TAA27267 for ; Thu, 21 Nov 2002 19:07:16 -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 gAM09G305162 for ; Thu, 21 Nov 2002 19:09:17 -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 gAM09Dd01257 for ; Thu, 21 Nov 2002 19:09:14 -0500 (EST) Message-ID: <00c401c291bb$5ac27340$f300510c@6640bbc3r131> From: "Brijesh Kumar" To: , "Juha Heinanen" References: <15837.34153.7463.330618@lohi.eng.song.fi> Subject: Re: fate of directory based discovery Date: Thu, 21 Nov 2002 16:08:56 -0800 Organization: NetVault Systems 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-SMTP-HELO: mtiwmhc12.worldnet.att.net X-SMTP-MAIL-FROM: brijesh@netvaultsystems.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mtiwmhc12.worldnet.att.net [204.127.131.116] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Juha, Even though BGP was stretched to do what it wasn't designed to do, but people embraced it because of two reasons. First, VPNs are implemented by routing teams, and routing engineers would any day like a solution based on a routing protocol such as BGP than any thing like DNS. Secondly, a routing protocol brings distributed fault tolerant environment which is hard to match with any server based solution. I would think it would be very hard to sell DNS based solutions to routing engineers. About three years ago, we implemented LDAP based VPN discovery solution at a (now-defunct) manufacturer of first generation VPN routers. It worked pretty fine. LDAP has solid features for data sunchronization and storage. I would still have the basic design document some where on my disk. In my view, Radius server solution is far better than the DNS approach. It is easy to implement since it is simple to extend radius server attributes. Radius Server/client code is easily available from multiple sources. However, you would need to satisfy the need for relaibility by creating secondary and tertiary radius servers (all synchronized) for back up. But, these are already being done successfully for subscriber authentication and other radius based policy configuration etc. So I dont't see that a major issues. Therefore, I think, your radius proposal is likely to see much larger support. Cheers, --brijesh ----- Original Message ----- From: "Juha Heinanen" To: Sent: Thursday, November 21, 2002 5:16 PM Subject: fate of directory based discovery > there was not enough support in atlanta meeting to make the dns > discovery i-d a working group document. i guess it would be appropriate > to confirm that also on the mailing list, since not everyone who has > been working on the dns discovery was able to attend the meeting. > > anyhow, i have always said that i don't care what the directory is as > long as the vpn solution is internet wide and doesn't use bgp. some > people didn't like dns discovery, because (although simple) it overloads > dns with stuff that dns was not designed to do. so there may still be > enough support left for a directory based solution if something "better" > than dns can be found. > > i have been thinking for some time now that radius might be a another > possibility for implementing discovery. it would go something like > this: > > - radius is populated for each ce with information about the vpn that > the ce participates in (if any) > - a ce authenticates to the pe using e.g. 802.1x (or the ce is manually > configured in the pe) > - pe makes a radius query and gets as a response the id of the ce's vpn > and a list of other pes that have members in the same vpn > - the vpn's pe list is kept up in the radius server either manually or > based on radius accounting start/stop messages > > this would be a very flexible and automated solution, since there in > case .1x is used, NOTHING ce related needs to be configured in the pe. > > before spending more time on this, i would need to get an indication > from the working group if there is enough interest for ANY directory > based solution. > > -- juha > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 21 19:30: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 TAA28294 for ; Thu, 21 Nov 2002 19:30: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 gAM0W4309789 for ; Thu, 21 Nov 2002 19:32: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 gAM0W1d11895 for ; Thu, 21 Nov 2002 19:32:02 -0500 (EST) Message-ID: <20021122003125.52431.qmail@web12506.mail.yahoo.com> Date: Thu, 21 Nov 2002 16:31:25 -0800 (PST) From: Sukanta ganguly Subject: Re: fate of directory based discovery To: Brijesh Kumar , ppvpn@nortelnetworks.com, Juha Heinanen In-Reply-To: <00c401c291bb$5ac27340$f300510c@6640bbc3r131> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web12506.mail.yahoo.com X-SMTP-MAIL-FROM: sganguly@yahoo.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web12506.mail.yahoo.com [216.136.173.198] X-LYRIS-Message-Id: If I may add, the Directory based solution will also provide you the availability based on how good a distributed/replicated LDAP directory you deploy. The distributed and replicated base nature allows you the flexibility of what you want to do. Also, if the LDAP implementation provides cache subsystem then it would a very good fit for your idea. Finally, the flixible schema model and the easy to extend object attributes help to a great deal also. I have developed a cache based directory subsystem and boosted the environment through put significantly in one of my previous endeavors. I know many VPN's solutions which use LDAP/Directory based approach for information persistence for VPN connections/links. My 2 cents. SG --- Brijesh Kumar wrote: > Juha, > > Even though BGP was stretched to do what it wasn't > designed to do, but > people embraced it because of two reasons. First, > VPNs are implemented by > routing teams, and routing engineers would any day > like a solution based on > a routing protocol such as BGP than any thing like > DNS. Secondly, a routing > protocol brings distributed fault tolerant > environment which is hard to > match with any server based solution. I would think > it would be very hard to > sell DNS based solutions to routing engineers. > > About three years ago, we implemented LDAP based VPN > discovery solution at a > (now-defunct) manufacturer of first generation VPN > routers. It worked > pretty fine. LDAP has solid features for data > sunchronization and storage. > I would still have the basic design document some > where on my disk. > > In my view, Radius server solution is far better > than the DNS approach. It > is easy to implement since it is simple to extend > radius server attributes. > Radius Server/client code is easily available from > multiple sources. > However, you would need to satisfy the need for > relaibility by creating > secondary and tertiary radius servers (all > synchronized) for back up. But, > these are already being done successfully for > subscriber authentication and > other radius based policy configuration etc. So I > dont't see that a major > issues. Therefore, I think, your radius proposal is > likely to see much > larger support. > > Cheers, > > --brijesh > > ----- Original Message ----- > From: "Juha Heinanen" > To: > Sent: Thursday, November 21, 2002 5:16 PM > Subject: fate of directory based discovery > > > > there was not enough support in atlanta meeting to > make the dns > > discovery i-d a working group document. i guess > it would be appropriate > > to confirm that also on the mailing list, since > not everyone who has > > been working on the dns discovery was able to > attend the meeting. > > > > anyhow, i have always said that i don't care what > the directory is as > > long as the vpn solution is internet wide and > doesn't use bgp. some > > people didn't like dns discovery, because > (although simple) it overloads > > dns with stuff that dns was not designed to do. > so there may still be > > enough support left for a directory based solution > if something "better" > > than dns can be found. > > > > i have been thinking for some time now that radius > might be a another > > possibility for implementing discovery. it would > go something like > > this: > > > > - radius is populated for each ce with information > about the vpn that > > the ce participates in (if any) > > - a ce authenticates to the pe using e.g. 802.1x > (or the ce is manually > > configured in the pe) > > - pe makes a radius query and gets as a response > the id of the ce's vpn > > and a list of other pes that have members in the > same vpn > > - the vpn's pe list is kept up in the radius > server either manually or > > based on radius accounting start/stop messages > > > > this would be a very flexible and automated > solution, since there in > > case .1x is used, NOTHING ce related needs to be > configured in the pe. > > > > before spending more time on this, i would need to > get an indication > > from the working group if there is enough interest > for ANY directory > > based solution. > > > > -- juha > > > > > > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 21 22:14:59 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 WAA03543 for ; Thu, 21 Nov 2002 22:14:59 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAM3GV300408 for ; Thu, 21 Nov 2002 22:16:31 -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 gAM3GSd10002 for ; Thu, 21 Nov 2002 22:16:28 -0500 (EST) Date: 21 Nov 2002 22:15:28 -0500 Message-ID: <3DDDA150.712CCED2@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "Brijesh Kumar" , "Juha Heinanen" Cc: ppvpn@nortelnetworks.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: fate of directory based discovery References: <15837.34153.7463.330618@lohi.eng.song.fi> <00c401c291bb$5ac27340$f300510c@6640bbc3r131> Content-Type: multipart/alternative; boundary="------------6D530E452F41B363EBB1C56C" X-SMTP-HELO: kanmx1.ca.alcatel.com X-SMTP-MAIL-FROM: Cheng-Yin.Lee@alcatel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: m115-138.on.tac.net [209.202.115.138] X-LYRIS-Message-Id: --------------6D530E452F41B363EBB1C56C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brijesh, Juha et al, As I discussed with Juha earlier on, > pe makes a radius query and gets as a response the id of the ce's vpn > > and a list of other pes that have members in the same vpn > the above could be generalized for both PE-based and CE-based VPN site discovery. Section 5.7 of the main body and Section 5.0 of the Appendix of http://www.ietf.org/internet-drafts/draft-lee-ppvpn-ce-auto-config-02.txt (as well as version 01) discusses the use an Authentication Server and RADIUS to obtain VPN site information for CE-based VPNs. Question for Juha, and other providers, one issue I would like to understand is how important is timeliness of VPN site information (e.g. updates, add, remove site) ? Is it important to be able to update PEs/CEs of VPN information changes or is it sufficient to simply poll for VPN site information? How about polling less frequently, but have simple push/receive-trigger-then-pull mechanisms (which does not require keeping states about PEs/CEs that cannot be updated yet)? thanks, cheng-yin Brijesh Kumar wrote: > Juha, > > Even though BGP was stretched to do what it wasn't designed to do, but > people embraced it because of two reasons. First, VPNs are implemented by > routing teams, and routing engineers would any day like a solution based on > a routing protocol such as BGP than any thing like DNS. Secondly, a routing > protocol brings distributed fault tolerant environment which is hard to > match with any server based solution. I would think it would be very hard to > sell DNS based solutions to routing engineers. > > About three years ago, we implemented LDAP based VPN discovery solution at a > (now-defunct) manufacturer of first generation VPN routers. It worked > pretty fine. LDAP has solid features for data sunchronization and storage. > I would still have the basic design document some where on my disk. > > In my view, Radius server solution is far better than the DNS approach. It > is easy to implement since it is simple to extend radius server attributes. > Radius Server/client code is easily available from multiple sources. > However, you would need to satisfy the need for relaibility by creating > secondary and tertiary radius servers (all synchronized) for back up. But, > these are already being done successfully for subscriber authentication and > other radius based policy configuration etc. So I dont't see that a major > issues. Therefore, I think, your radius proposal is likely to see much > larger support. > > Cheers, > > --brijesh > > ----- Original Message ----- > From: "Juha Heinanen" > To: > Sent: Thursday, November 21, 2002 5:16 PM > Subject: fate of directory based discovery > > > there was not enough support in atlanta meeting to make the dns > > discovery i-d a working group document. i guess it would be appropriate > > to confirm that also on the mailing list, since not everyone who has > > been working on the dns discovery was able to attend the meeting. > > > > anyhow, i have always said that i don't care what the directory is as > > long as the vpn solution is internet wide and doesn't use bgp. some > > people didn't like dns discovery, because (although simple) it overloads > > dns with stuff that dns was not designed to do. so there may still be > > enough support left for a directory based solution if something "better" > > than dns can be found. > > > > i have been thinking for some time now that radius might be a another > > possibility for implementing discovery. it would go something like > > this: > > > > - radius is populated for each ce with information about the vpn that > > the ce participates in (if any) > > - a ce authenticates to the pe using e.g. 802.1x (or the ce is manually > > configured in the pe) > > - pe makes a radius query and gets as a response the id of the ce's vpn > > and a list of other pes that have members in the same vpn > > - the vpn's pe list is kept up in the radius server either manually or > > based on radius accounting start/stop messages > > > > this would be a very flexible and automated solution, since there in > > case .1x is used, NOTHING ce related needs to be configured in the pe. > > > > before spending more time on this, i would need to get an indication > > from the working group if there is enough interest for ANY directory > > based solution. > > > > -- juha > > > > --------------6D530E452F41B363EBB1C56C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Brijesh, Juha et al,

As I discussed with Juha earlier on, 

pe makes a radius query and gets as a response the id of the ce's vpn
>   and a list of other pes that have members in the same vpn
the above could be generalized for both PE-based and CE-based VPN site discovery.

Section 5.7 of the main body and Section 5.0 of the Appendix of http://www.ietf.org/internet-drafts/draft-lee-ppvpn-ce-auto-config-02.txt (as well as version 01) discusses the use an Authentication Server and RADIUS to obtain VPN site information for CE-based VPNs.

Question for Juha, and other providers,  one issue I would like to understand is how important is timeliness of VPN site information (e.g. updates, add, remove site) ?

Is it important to be able to update PEs/CEs of VPN information changes or is it sufficient to simply poll for VPN site information?
How about polling less frequently, but have simple push/receive-trigger-then-pull mechanisms (which does not require keeping states about PEs/CEs that cannot be updated yet)?

thanks,
cheng-yin
 
 

Brijesh Kumar wrote:

Juha,

Even though BGP was  stretched to do what it wasn't designed to do, but
people embraced it because of two reasons. First, VPNs are implemented by
routing teams, and routing engineers would any day like a solution based on
a routing protocol such as BGP than any thing like DNS. Secondly, a routing
protocol brings distributed fault tolerant environment which is hard to
match with any server based solution. I would think it would be very hard to
sell DNS based solutions to routing engineers.

About three years ago, we implemented LDAP based VPN discovery solution at a
(now-defunct) manufacturer of  first generation  VPN routers. It worked
pretty fine. LDAP has solid features for data sunchronization and storage.
I would still have the basic design document some where on my disk.

In my view, Radius server solution is far better than the DNS approach.  It
is easy to implement since it is simple to extend radius server attributes.
Radius Server/client code is easily available from multiple sources.
However, you would need to satisfy the need for relaibility by creating
secondary and tertiary radius servers (all synchronized) for back up. But,
these are already being done successfully for subscriber authentication and
other radius based policy configuration etc. So I dont't see that a major
issues. Therefore, I think, your radius proposal is likely to see much
larger support.

Cheers,

--brijesh

----- Original Message -----
From: "Juha Heinanen" <jh@lohi.eng.song.fi>
To: <ppvpn@nortelnetworks.com>
Sent: Thursday, November 21, 2002 5:16 PM
Subject: fate of directory based discovery

> there was not enough support in atlanta meeting to make the dns
> discovery i-d a working group document.  i guess it would be appropriate
> to confirm that also on the mailing list, since not everyone who has
> been working on the dns discovery was able to attend the meeting.
>
> anyhow, i have always said that i don't care what the directory is as
> long as the vpn solution is internet wide and doesn't use bgp.  some
> people didn't like dns discovery, because (although simple) it overloads
> dns with stuff that dns was not designed to do.  so there may still be
> enough support left for a directory based solution if something "better"
> than dns can be found.
>
> i have been thinking for some time now that radius might be a another
> possibility for implementing discovery.  it would go something like
> this:
>
> - radius is populated for each ce with information about the vpn that
>   the ce participates in (if any)
> - a ce authenticates to the pe using e.g. 802.1x (or the ce is manually
>   configured in the pe)
> - pe makes a radius query and gets as a response the id of the ce's vpn
>   and a list of other pes that have members in the same vpn
> - the vpn's pe list is kept up in the radius server either manually or
>   based on radius accounting start/stop messages
>
> this would be a very flexible and automated solution, since there in
> case .1x is used, NOTHING ce related needs to be configured in the pe.
>
> before spending more time on this, i would need to get an indication
> from the working group if there is enough interest for ANY directory
> based solution.
>
> -- juha
>
>

--------------6D530E452F41B363EBB1C56C-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 08:22:28 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 IAA24453 for ; Fri, 22 Nov 2002 08:22:28 -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 gAMDOFD25306 for ; Fri, 22 Nov 2002 08:24:15 -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 gAMDOC008559 for ; Fri, 22 Nov 2002 08:24:12 -0500 (EST) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15838.12228.127616.649068@lohi.eng.song.fi> Date: Fri, 22 Nov 2002 15:23:16 +0200 To: Cheng-Yin.Lee@alcatel.com Cc: "Brijesh Kumar" , ppvpn@nortelnetworks.com Subject: Re: fate of directory based discovery In-Reply-To: <3DDDA150.712CCED2@alcatel.com> References: <15837.34153.7463.330618@lohi.eng.song.fi> <00c401c291bb$5ac27340$f300510c@6640bbc3r131> <3DDDA150.712CCED2@alcatel.com> X-Mailer: VM 6.97 under Emacs 20.7.2 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 Cheng-Yin Lee writes: > the above could be generalized for both PE-based and CE-based VPN site > discovery. sure. i would not expect the ces to run bgp and thus we definitely would need a bgp-free solution for ce-ce discovery. > Question for Juha, and other providers, one issue I would like to > understand is > how important is timeliness of VPN site information (e.g. updates, > add, remove site) ? timeliness should be within a range of few seconds after the change has been administravely made so that the network manager can see the effects of the change without having to have a coffee break. > Is it important to be able to update PEs/CEs of VPN information > changes or is it > sufficient to simply poll for VPN site information? i don't like any solution that is based on polling. that is why i suggested that the change is always initiated by the network, not by the radius server. > How about polling less frequently, but have simple > push/receive-trigger-then-pull mechanisms (which does not require > keeping states about PEs/CEs that cannot be updated yet)? i don't like the idea of specifying any new protocol for discovery purpose. -- juha From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 13:06:16 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 NAA00364 for ; Fri, 22 Nov 2002 13:06:15 -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 gAMI7xD02584 for ; Fri, 22 Nov 2002 13:07: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 gAMI7u003126 for ; Fri, 22 Nov 2002 13:07:57 -0500 (EST) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322716@trimail2> From: "Chen, Weijing" To: "'Yakov Rekhter'" Cc: "'PPVPN'" Subject: Scalable and manageable network management and operation of MPLS/ VPN Date: Fri, 22 Nov 2002 12:07:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29251.F90D2630" X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: wchen@tri.sbc.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] 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_01C29251.F90D2630 Content-Type: text/plain Yakov, Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list archive. >>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"? In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the attributes on the port serving the subscriber. We have to dedicate resources to the subscriber that go deeper into the network than just their port. Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult. Specifically, the resources we have to dedicate and manage are: 1. Virtual Routing Functions. Nearly one for each CE/PE interface. Each one of these, from a management standpoint, is a router. Right now, large IP carriers manage hundreds to possibly a few thousand routers. With IP VPNs, we'll be managing tens of thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. 2. Connections between VRFs. Each VRF in a VPN has to have a connection to every other VRF in the VPN. The more VRFs you have (100,000), the more connections you have between them. 3. Connections between PEs. Each PE in a VPN has to have a connection to every other PE in the VPN. This connection maybe shared by multiple VRFs in the same PE pairs. However, tracking of what connection to be shared or establishing new one if not shared is another daunting task. Each single item above is translated into $$, which including recurring OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for OSS system. >>Also, when you said "we operation group in service provider", do you mean a specific service provider? Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of subscribers (number of sites), such as us Regards, -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 ------_=_NextPart_001_01C29251.F90D2630 Content-Type: text/html

Yakov,

 

Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list archive.

 

>>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"?

 

In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the attributes on the port serving the subscriber.  We have to dedicate resources to the subscriber that go deeper into the network than just their port.  Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult.

 

Specifically, the resources we have to dedicate and manage are:

  1. Virtual Routing Functions.  Nearly one for each CE/PE interface.  Each one of these, from a management standpoint, is a router.  Right now, large IP carriers manage hundreds to possibly a few thousand routers.  With IP VPNs, we'll be managing tens of thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump.
  2. Connections between VRFs.  Each VRF in a VPN has to have a connection to every other VRF in the VPN.  The more VRFs you have (100,000), the more connections you have between them.
  3. Connections between PEs.  Each PE in a VPN has to have a connection to every other PE in the VPN.  This connection maybe shared by multiple VRFs in the same PE pairs.  However, tracking of what connection to be shared or establishing new one if not shared is another daunting task.

 

Each single item above is translated into $$, which including recurring OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for OSS system.

 

>>Also, when you said "we operation group in service provider", do you mean a specific service provider?

Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of subscribers (number of sites), such as us

 

Regards,

 

 

--

Weijing Chen

SBC Technology Resources

9505 Arboretum Blvd.

Austin, TX 78759

512 372 5710

 

 

------_=_NextPart_001_01C29251.F90D2630-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 13:22:33 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 NAA00712 for ; Fri, 22 Nov 2002 13:22:32 -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 gAMIOaD07008 for ; Fri, 22 Nov 2002 13:24: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 gAMIOX015215 for ; Fri, 22 Nov 2002 13:24:33 -0500 (EST) Message-ID: <3DDE763D.1E5BAA62@cisco.com> Date: Fri, 22 Nov 2002 19:23:57 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Weijing" CC: "'Yakov Rekhter'" , "'PPVPN'" Subject: Re: Scalable and manageable network management and operation of MPLS/VPN References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322716@trimail2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-msg-core-4.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-4.cisco.com [171.71.163.54] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Weijing, Your below email clearly indicates that you are mixing VR based L3VPNs with the L3VPNs described in 2547bis architecture as non of your points apply to the latter one. I must admit that they are very true for the first type of L3VPNs though :-). Thx, R. > Yakov, > > > > Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list > archive. > > > > >>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"? > > > > In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the > attributes on the port serving the subscriber. We have to dedicate resources to the subscriber that go deeper into the network than just > their port. Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult. > > > > Specifically, the resources we have to dedicate and manage are: > > #Virtual Routing Functions. Nearly one for each CE/PE interface. Each one of these, from a management standpoint, is a > router. Right now, large IP carriers manage hundreds to possibly a few thousand routers. With IP VPNs, we'll be managing tens of > thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. > #Connections between VRFs. Each VRF in a VPN has to have a connection to every other VRF in the VPN. The more VRFs > you have (100,000), the more connections you have between them. > #Connections between PEs. Each PE in a VPN has to have a connection to every other PE in the VPN. This connection > maybe shared by multiple VRFs in the same PE pairs. However, tracking of what connection to be shared or establishing new one if > not shared is another daunting task. > > > > Each single item above is translated into $$, which including recurring OPEX for operation and OSS system > maintenance, and nonrecurring CAPEX for OSS system. > > > > >>Also, when you said "we operation group in service provider", do you mean a specific service provider? > > Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of > subscribers (number of sites), such as us > > > > Regards, > > > > > > -- > > Weijing Chen > > SBC Technology Resources > > 9505 Arboretum Blvd. > > Austin, TX 78759 > > 512 372 5710 > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 13:48: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 NAA01044 for ; Fri, 22 Nov 2002 13:48:50 -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 gAMIorD12713 for ; Fri, 22 Nov 2002 13:50:53 -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 gAMIoo002228 for ; Fri, 22 Nov 2002 13:50:51 -0500 (EST) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> From: "Chen, Weijing" To: "'raszuk@cisco.com'" Cc: "'PPVPN'" Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Date: Fri, 22 Nov 2002 12:50:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: wchen@tri.sbc.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: Robert, Thanks for reply. However, I don't think that I mixed the VR-based and 2547bis-based VPN. Regardless it is a VR or a VRF, from management standpoint, it is a router that we must management, e.g. route target id, import id, export id, etc. in 2547bis case. Also for VRF and PE connection, LSP labels in both end and sometime LSP labels in the middle. As long as they are something that we must establish or assign, keep track of, and troubleshoot, they require system resource and human resource. And those resources come with cost. It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us that it is not big deal since it is just a connection. 10 years from then, we are still bearing the pain of provisioned connection-oriented (S)PVC. IP is great since it is connectionless. Telephone (POTS) is also great since it is connection-oriented with fully functioned end-to-end subscriber initiatied signaling. Either one will work for us, but not something in between. Oh, well, I went too far. -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com] Sent: Friday, November 22, 2002 12:24 PM To: Chen, Weijing Cc: 'Yakov Rekhter'; 'PPVPN' Subject: Re: Scalable and manageable network management and operation of MPLS/VPN Weijing, Your below email clearly indicates that you are mixing VR based L3VPNs with the L3VPNs described in 2547bis architecture as non of your points apply to the latter one. I must admit that they are very true for the first type of L3VPNs though :-). Thx, R. > Yakov, > > > > Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list > archive. > > > > >>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"? > > > > In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the > attributes on the port serving the subscriber. We have to dedicate resources to the subscriber that go deeper into the network than just > their port. Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult. > > > > Specifically, the resources we have to dedicate and manage are: > > #Virtual Routing Functions. Nearly one for each CE/PE interface. Each one of these, from a management standpoint, is a > router. Right now, large IP carriers manage hundreds to possibly a few thousand routers. With IP VPNs, we'll be managing tens of > thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. > #Connections between VRFs. Each VRF in a VPN has to have a connection to every other VRF in the VPN. The more VRFs > you have (100,000), the more connections you have between them. > #Connections between PEs. Each PE in a VPN has to have a connection to every other PE in the VPN. This connection > maybe shared by multiple VRFs in the same PE pairs. However, tracking of what connection to be shared or establishing new one if > not shared is another daunting task. > > > > Each single item above is translated into $$, which including recurring OPEX for operation and OSS system > maintenance, and nonrecurring CAPEX for OSS system. > > > > >>Also, when you said "we operation group in service provider", do you mean a specific service provider? > > Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of > subscribers (number of sites), such as us > > > > Regards, > > > > > > -- > > Weijing Chen > > SBC Technology Resources > > 9505 Arboretum Blvd. > > Austin, TX 78759 > > 512 372 5710 > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 14:37:31 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 OAA02389 for ; Fri, 22 Nov 2002 14:37:30 -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 gAMJbQD06468 for ; Fri, 22 Nov 2002 14:37: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 gAMJbO020614 for ; Fri, 22 Nov 2002 14:37:24 -0500 (EST) Message-ID: <3DDE869D.691D40B4@cisco.com> Date: Fri, 22 Nov 2002 20:33:49 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Weijing" CC: "'PPVPN'" Subject: Re: Scalable and manageable network management and operation of MPLS/VPN References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-msg-core-3.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-3.cisco.com [171.70.157.152] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Weijing, All I can add to my previos msg is to indicate that it really takes a bit more to manage a router then assinging RD & RT in 2547bis. I wish routers would be so smart to just take two values and operate ;-). And to remind you it is all (along with applying PE-CE routing exchange template) what addition of new VPN site requires from your managment station. Also reg the LSPs as a transport notice that one may run 2547bis without any MPLS LSPs at all. Appriopriate drafts discussing how to do this have already been posted to this group. Oh and btw ask your vendors what are pros & cons of not using MPLS LSPs as your transport vehicle for VPN packets. Rgs, R. > Either one will work for us, but not something in > between. Oh, well, I went too far. PS. IMHO LDP LSPs are connectionless, while TE LSPs connection-oriented. I don't really see anything in between here :). > "Chen, Weijing" wrote: > > Robert, > > Thanks for reply. However, I don't think that I mixed the VR-based and > 2547bis-based VPN. Regardless it is a VR or a VRF, from management > standpoint, it is a router that we must management, e.g. route target id, > import id, export id, etc. in 2547bis case. Also for VRF and PE connection, > LSP labels in both end and sometime LSP labels in the middle. As long as > they are something that we must establish or assign, keep track of, and > troubleshoot, they require system resource and human resource. And those > resources come with cost. > > It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us > that it is not big deal since it is just a connection. 10 years from then, > we are still bearing the pain of provisioned connection-oriented (S)PVC. > > IP is great since it is connectionless. Telephone (POTS) is also great > since it is connection-oriented with fully functioned end-to-end subscriber > initiatied signaling. Either one will work for us, but not something in > between. Oh, well, I went too far. > > -- > Weijing Chen > SBC Technology Resources > 9505 Arboretum Blvd. > Austin, TX 78759 > 512 372 5710 > wchen@tri.sbc.com > > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: Friday, November 22, 2002 12:24 PM > To: Chen, Weijing > Cc: 'Yakov Rekhter'; 'PPVPN' > Subject: Re: Scalable and manageable network management and operation of > MPLS/VPN > > Weijing, > > Your below email clearly indicates that you are mixing VR based L3VPNs > with the L3VPNs described in 2547bis architecture as non of your points > apply to the latter one. I must admit that they are very true for the > first type of L3VPNs though :-). > > Thx, > R. > > > Yakov, > > > > > > > > Sorry for late response. I didn't receive your reply for somewhat > reason. Yetik pointed this message to me and I found it from mailing list > > archive. > > > > > > > > >>Could you please elaborate on what exactly you are concerned with > respect to "scaleable manageability of MPLS/VPN"? > > > > > > > > In a nutshell, RFC 2547 doesn't scale because it breaks the rule that > all we need to do to manage a subscriber is manage the > > attributes on the port serving the subscriber. We have to dedicate > resources to the subscriber that go deeper into the network than just > > their port. Establishing, keeping track of, and troubleshooting these > resources on a per-subscriber basis will be difficult. > > > > > > > > Specifically, the resources we have to dedicate and manage are: > > > > #Virtual Routing Functions. Nearly one for each CE/PE interface. Each > one of these, from a management standpoint, is a > > router. Right now, large IP carriers manage hundreds to possibly a > few thousand routers. With IP VPNs, we'll be managing tens of > > thousand to possible hundreds of thousands of routers (VRF), a good 2 > orders of magnitude jump. > > #Connections between VRFs. Each VRF in a VPN has to have a connection > to every other VRF in the VPN. The more VRFs > > you have (100,000), the more connections you have between them. > > #Connections between PEs. Each PE in a VPN has to have a connection to > every other PE in the VPN. This connection > > maybe shared by multiple VRFs in the same PE pairs. However, > tracking of what connection to be shared or establishing new one if > > not shared is another daunting task. > > > > > > > > Each single item above is translated into $$, which including > recurring OPEX for operation and OSS system > > maintenance, and nonrecurring CAPEX for OSS system. > > > > > > > > >>Also, when you said "we operation group in service provider", do you > mean a specific service provider? > > > > Any service provider with hundreds of POPs (or COs), thousands of PEs > (routers or switches), millions of > > subscribers (number of sites), such as us > > > > > > > > Regards, > > > > > > > > > > > > -- > > > > Weijing Chen > > > > SBC Technology Resources > > > > 9505 Arboretum Blvd. > > > > Austin, TX 78759 > > > > 512 372 5710 > > > > > > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 14:42:03 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 OAA02529 for ; Fri, 22 Nov 2002 14:42:03 -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 gAMJi8D07602 for ; Fri, 22 Nov 2002 14:44:08 -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 gAMJi5025522 for ; Fri, 22 Nov 2002 14:44:06 -0500 (EST) Message-Id: <200211221943.gAMJhdS32016@merlot.juniper.net> To: "Chen, Weijing" cc: "'PPVPN'" Subject: Re: Scalable and manageable network management and operation of MPLS/ VPN In-Reply-To: Your message of "Fri, 22 Nov 2002 12:07:08 CST." <905A1C4ABF353F4C8CC16FA9F53DD0D6322716@trimail2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37054.1037994219.1@juniper.net> Date: Fri, 22 Nov 2002 11:43:39 -0800 From: Yakov Rekhter X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Weijing, > > Could you please elaborate on what exactly you are concerned with respect > > to "scaleable manageability of MPLS/VPN"? > > In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we > need to do to manage a subscriber is manage the attributes on the port > serving the subscriber. We have to dedicate resources to the subscriber > that go deeper into the network than just their port. Establishing, keeping > track of, and troubleshooting these resources on a per-subscriber basis will > be difficult. In a nutshell, quite a few service providers deployed 2547 for quite some time, and thus have *practical* experience with it. At MPLS-2001 conference there was a presentation by Chris Chase from AT&T (one of the service providers that deployed 2547 for quite some time), titled "Scaling BGP/MPLS VPN Service And Comparison to Traditional Layer 2 VPN Services". The presentation has a fairly detailed analysis of the scalability aspect of 2547. I am not going to repeat it here, but just to quote from the summary slide of that presentation: Certainly scalable and solvable > Specifically, the resources we have to dedicate and manage are: > > 1. Virtual Routing Functions. Nearly one for each CE/PE interface. > Each one of these, from a management standpoint, is a router. Right now, > large IP carriers manage hundreds to possibly a few thousand routers. With > IP VPNs, we'll be managing tens of thousand to possible hundreds of > thousands of routers (VRF), a good 2 orders of magnitude jump. With provider-provisioned Layer 3 VPNs a provider *by definition of the service* has to participate in each VPN customer's routing. This is irrespective of whether one uses 2547, Virtual Routers, or (provider-provisioned) IPSec between CEs. So, the complexity of Layer 3 VPN service has nothing to do with MPLS, but has to do with the service itself. If a service provider does not want to participate in VPN customers' routing, the provider could either (a) offer no VPN services at all, or (b) offer Layer 2 VPN services (e.g., FR, ATM, VPLS, etc...). All of the Layer 2 VPN services I mentioned could be offered with MPLS. So, if you think that Layer 2 VPN services do not have the "scaleable manageability" problem, then clearly MPLS/VPNs (used to offer Layer 2 VPN services) would not have the "scaleable manageability" problem either. In general, when comparing scalability of Layer 2 VPN service vs Layer 3 VPN service, it is important to look at scalability of *total system*, and not just scalability in the service provider. There is a pretty good presentation from Bruce Davie (Cisco) at the Spring 2002 MPLSCon Conference on this topic. > 2. Connections between VRFs. Each VRF in a VPN has to have a > connection to every other VRF in the VPN. The more VRFs you have (100,000), > the more connections you have between them. Your assertion that "each VRF in a VPN has to have a connection to every other VRF in the VPN" is incorrect. It shows that your understanding of 2547 is inadequate. Please read draft-ietf-ppvpn-rfc2547bis-03.txt. > 3. Connections between PEs. Each PE in a VPN has to have a connection > to every other PE in the VPN. This connection maybe shared by multiple VRFs > in the same PE pairs. However, tracking of what connection to be shared or > establishing new one if not shared is another daunting task. Your assertion that "each PE in a VPN has to have a connection to every other PE in the VPN" is incorrect. If you would read 2547 spec (draft-ietf-ppvpn-rfc2547bis-03.txt), you would find in Section 4.3.3: Rather than having a complete IBGP mesh among the PEs, it is advantageous to make use of BGP Route Reflectors [BGP-RR] to improve scalability. All the usual techniques for using route reflectors to improve scalability, e.g., route reflector hierarchies, are available. > Each single item above is translated into $$, which including recurring OPEX > for operation and OSS system maintenance, and nonrecurring CAPEX for OSS > system. May I suggest you to get more familiar with 2547 before making any more assertions about it. Yakov. From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 14:47: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 OAA02668 for ; Fri, 22 Nov 2002 14:47:52 -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 gAMJnuD11877 for ; Fri, 22 Nov 2002 14:49:56 -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 gAMJnr003914 for ; Fri, 22 Nov 2002 14:49:53 -0500 (EST) Message-Id: <4.3.2.7.2.20021122141947.00b12748@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Nov 2002 14:49:34 -0500 To: "Chen, Weijing" From: Thomas Nadeau Subject: Re: Scalable and manageable network management and operation of MPLS/ VPN Cc: "'PPVPN'" In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D6322716@trimail2> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2791015==_.ALT" 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: --=====================_2791015==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:07 PM 11/22/2002 -0600, Chen, Weijing wrote: >Yakov, > > > >Sorry for late response. I didn't receive your reply for somewhat reason. >Yetik pointed this message to me and I found it from mailing list archive. > > > > >>Could you please elaborate on what exactly you are concerned with > respect to "scaleable manageability of MPLS/VPN"? > > > >In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all >we need to do to manage a subscriber is manage the attributes on the port >serving the subscriber. We have to dedicate resources to the subscriber >that go deeper into the network than just their port. Establishing, >keeping track of, and troubleshooting these resources on a per-subscriber >basis will be difficult. If you look at network management this way, then of course, any VPN technology you look at will not be scalable. However, the success of 2547 is indeed that a well designed management system can managed new customers by managing basically the VRF attributes. The typical addition of one (or hundreds) of customers should not affect the layout of your internal network or even the PE where those customers are attached if you did things correctly from the start. For example, many providers I know will size how many customers a particular PE can handle in their lab. Once they know this, they just provision customers in a single, easy way. Once they get near the limit, they order another PE. This also plays into the larger design of the core network of course, but I think that if your network is designed to slimly that it needs to be re-provisioned whenever any customer is added, that you should think about your design again. >Specifically, the resources we have to dedicate and manage are: > * Virtual Routing Functions. Nearly one for each CE/PE > interface. Each one of these, from a management standpoint, is a > router. Right now, large IP carriers manage hundreds to possibly a few > thousand routers. With IP VPNs, we'll be managing tens of thousand to > possible hundreds of thousands of routers (VRF), a good 2 orders of > magnitude jump. Perhaps you can explain to me why you think that the addition of one customer is going to affect all of the nodes in your network? I do not know of any deployments where providers re-provision their entire network based on the addition or re-provision of a 2547 customer. > * Connections between VRFs. Each VRF in a VPN has to have a > connection to every other VRF in the VPN. The more VRFs you have > (100,000), the more connections you have between them. You are thinking about this as if MPLS is a connection-oriented network, which it is not. The exception is if you are using RSVP-TE tunnels between PEs. However, a typical 2547 network uses LDP to establish sessions and distribute labels between PEs, not each VRF. In essence, you get paths between PEs over which you switch the VPN labels. I think that you are thinking of things as if there are actual connection-oriented paths between all VRFs in a VPN. Even if you use RSVP-TE tunnels between PEs, you can support many hundreds or thousands of VPNs between those PEs without needing a TE tunnel per VRF inter-connection. Thus only a small number of tunnels exist between PEs (as opposed to specific tunnels for each VPN or VRF-pair). > * Connections between PEs. Each PE in a VPN has to have a connection > to every other PE in the VPN. This connection maybe shared by multiple > VRFs in the same PE pairs. Yes, but why is this a problem? > * However, tracking of what connection to be shared or establishing > new one if not shared is another daunting task. Just look at the loopbacks at one VRF and that gives you pointers to the other PEs. If you are interested in figuring out which physical links are shared by which VRFs on a particular PE, then just look at the LFIB based on the label used by the loopback. >Each single item above is translated into $$, which including recurring >OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for >OSS system. I am not sure of that based on my experience with my customers who have deployed 2547 networks. Certainly CAPEX is required for the equipment to begin with, but OPEX is actually quite low for 2547 as compared to many other VPN technologies, especially if your OSS and network deployment strategy is sound to begin with. I am not saying that management of any network and certain 2547-based is easy, but I totally disagree with the assertion that a 2547 network is not scalable based on how it must be managed. --Tom > >>Also, when you said "we operation group in service provider", do you > mean a specific service provider? > >Any service provider with hundreds of POPs (or COs), thousands of PEs >(routers or switches), millions of subscribers (number of sites), such as us > > > >Regards, > > > > > >-- > >Weijing Chen > >SBC Technology Resources > >9505 Arboretum Blvd. > >Austin, TX 78759 > >512 372 5710 > > > > --=====================_2791015==_.ALT Content-Type: text/html; charset="us-ascii" At 12:07 PM 11/22/2002 -0600, Chen, Weijing wrote:

Yakov,

 

Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list archive.

 

>>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"?

 

In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the attributes on the port serving the subscriber.  We have to dedicate resources to the subscriber that go deeper into the network than just their port.  Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult.

        If you look at network management this way, then of course, any VPN technology you
look at will not be scalable.   However, the success of 2547 is indeed that a well designed
management system can managed new customers by managing basically the VRF attributes.
The typical addition of one (or hundreds) of customers should not affect the layout of your internal
network or even the PE where those customers are attached if you did things correctly
from the start.    For example, many providers I know will size how many customers a
particular PE can handle in their lab.  Once they know this, they just provision
customers in a single, easy way. Once they get near the limit, they order another
PE. This also plays into the larger design of the core network of course, but I think
that if your network is designed to slimly that it needs to be re-provisioned whenever
any customer is added, that you should think about your design again.

Specifically, the resources we have to dedicate and manage are:
  1. Virtual Routing Functions.  Nearly one for each CE/PE interface.  Each one of these, from a management standpoint, is a router.  Right now, large IP carriers manage hundreds to possibly a few thousand routers.  With IP VPNs, we'll be managing tens of thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump.
        Perhaps you can explain to me why you think that the addition of one customer is going to
affect all of the nodes in your network?  I do not know of any deployments where providers
re-provision their entire network based on the addition or re-provision of a 2547 customer.
  1. Connections between VRFs.  Each VRF in a VPN has to have a connection to every other VRF in the VPN.  The more VRFs you have (100,000), the more connections you have between them.
        You are thinking about this as if MPLS is a connection-oriented network, which it
is not. The exception is if you are using RSVP-TE tunnels between PEs.  However,
a typical 2547 network uses LDP to establish sessions and distribute
labels between PEs, not each VRF.  In essence, you get paths between PEs
over which you switch the VPN labels. I think that you are thinking of things
as if there are actual connection-oriented paths between all VRFs in a VPN.
Even if you use RSVP-TE tunnels between PEs, you can
support many hundreds or thousands of VPNs between those PEs without needing
a TE tunnel per VRF inter-connection. Thus only a small number of tunnels exist
between PEs (as opposed to specific tunnels for each VPN or VRF-pair).
  1. Connections between PEs.  Each PE in a VPN has to have a connection to every other PE in the VPN.  This connection maybe shared by multiple VRFs in the same PE pairs. 
        Yes, but why is this a problem?
  1. However, tracking of what connection to be shared or establishing new one if not shared is another daunting task.
        Just look at the loopbacks at one VRF and that gives you pointers to the other PEs.
If you are interested in figuring out which physical links are shared by which VRFs on
a particular PE, then just look at the LFIB based on the label used by the loopback.

Each single item above is translated into $$, which including recurring OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for OSS system.

        I am not sure of that based on my experience with my customers who have
deployed 2547 networks.  Certainly CAPEX is required for the equipment to begin
with, but OPEX is actually quite low for 2547 as compared to many other VPN
technologies, especially if your OSS and network deployment strategy is sound
to begin with. I am not saying that management of any network and certain 2547-based
is easy, but I totally disagree with the assertion that a 2547 network is not scalable
based on how it must be managed.

        --Tom


>>Also, when you said "we operation group in service provider", do you mean a specific service provider?

Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of subscribers (number of sites), such as us

 

Regards,

 

 

--

Weijing Chen

SBC Technology Resources

9505 Arboretum Blvd.

Austin, TX 78759

512 372 5710

 

 
--=====================_2791015==_.ALT-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 15:08: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 PAA03068 for ; Fri, 22 Nov 2002 15:08: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 gAMKAQD01448 for ; Fri, 22 Nov 2002 15:10: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 gAMKAN008107 for ; Fri, 22 Nov 2002 15:10:23 -0500 (EST) Message-Id: <4.3.2.7.2.20021122150558.00b16f08@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Nov 2002 15:09:49 -0500 To: "Chen, Weijing" From: Thomas Nadeau Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Cc: "'PPVPN'" In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> 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: At 12:50 PM 11/22/2002 -0600, Chen, Weijing wrote: >Robert, > >Thanks for reply. However, I don't think that I mixed the VR-based and >2547bis-based VPN. Regardless it is a VR or a VRF, from management >standpoint, it is a router that we must management, e.g. route target id, >import id, export id, etc. in 2547bis case. Also for VRF and PE connection, >LSP labels in both end and sometime LSP labels in the middle. As long as >they are something that we must establish or assign, keep track of, and >troubleshoot, they require system resource and human resource. And those >resources come with cost. Of course, the management of any new service is going to cost additional money. However, I think that we need to be clear on just how much. One of the advantages to MPLS L3VPN is that it can be managed as part of your overall MPLS management strategy given that it is an extension of MPLS. I think that making a statement like "it is not scalable because it cannot be managed effectively" is at best inaccurate. --Tom >It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us >that it is not big deal since it is just a connection. 10 years from then, >we are still bearing the pain of provisioned connection-oriented (S)PVC. >IP is great since it is connectionless. Telephone (POTS) is also great >since it is connection-oriented with fully functioned end-to-end subscriber >initiatied signaling. Either one will work for us, but not something in >between. Oh, well, I went too far. > > >-- >Weijing Chen >SBC Technology Resources >9505 Arboretum Blvd. >Austin, TX 78759 >512 372 5710 >wchen@tri.sbc.com > > >-----Original Message----- >From: Robert Raszuk [mailto:raszuk@cisco.com] >Sent: Friday, November 22, 2002 12:24 PM >To: Chen, Weijing >Cc: 'Yakov Rekhter'; 'PPVPN' >Subject: Re: Scalable and manageable network management and operation of >MPLS/VPN > > >Weijing, > >Your below email clearly indicates that you are mixing VR based L3VPNs >with the L3VPNs described in 2547bis architecture as non of your points >apply to the latter one. I must admit that they are very true for the >first type of L3VPNs though :-). > >Thx, >R. > > > Yakov, > > > > > > > > Sorry for late response. I didn't receive your reply for somewhat >reason. Yetik pointed this message to me and I found it from mailing list > > archive. > > > > > > > > >>Could you please elaborate on what exactly you are concerned with >respect to "scaleable manageability of MPLS/VPN"? > > > > > > > > In a nutshell, RFC 2547 doesn't scale because it breaks the rule that >all we need to do to manage a subscriber is manage the > > attributes on the port serving the subscriber. We have to dedicate >resources to the subscriber that go deeper into the network than just > > their port. Establishing, keeping track of, and troubleshooting these >resources on a per-subscriber basis will be difficult. > > > > > > > > Specifically, the resources we have to dedicate and manage are: > > > > #Virtual Routing Functions. Nearly one for each CE/PE interface. Each >one of these, from a management standpoint, is a > > router. Right now, large IP carriers manage hundreds to possibly a >few thousand routers. With IP VPNs, we'll be managing tens of > > thousand to possible hundreds of thousands of routers (VRF), a good 2 >orders of magnitude jump. > > #Connections between VRFs. Each VRF in a VPN has to have a connection >to every other VRF in the VPN. The more VRFs > > you have (100,000), the more connections you have between them. > > #Connections between PEs. Each PE in a VPN has to have a connection to >every other PE in the VPN. This connection > > maybe shared by multiple VRFs in the same PE pairs. However, >tracking of what connection to be shared or establishing new one if > > not shared is another daunting task. > > > > > > > > Each single item above is translated into $$, which including >recurring OPEX for operation and OSS system > > maintenance, and nonrecurring CAPEX for OSS system. > > > > > > > > >>Also, when you said "we operation group in service provider", do you >mean a specific service provider? > > > > Any service provider with hundreds of POPs (or COs), thousands of PEs >(routers or switches), millions of > > subscribers (number of sites), such as us > > > > > > > > Regards, > > > > > > > > > > > > -- > > > > Weijing Chen > > > > SBC Technology Resources > > > > 9505 Arboretum Blvd. > > > > Austin, TX 78759 > > > > 512 372 5710 > > > > > > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 15:27: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 PAA03313 for ; Fri, 22 Nov 2002 15:27: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 gAMKTvD06390 for ; Fri, 22 Nov 2002 15: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 gAMKTs018826 for ; Fri, 22 Nov 2002 15:29:55 -0500 (EST) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5AD5@trimail2> From: "Serbest, Yetik" To: "Chen, Weijing" , "'raszuk@cisco.com'" Cc: "'PPVPN'" Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Date: Fri, 22 Nov 2002 14:29:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: serbest@tri.sbc.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: Weijing, First of all, I need to understand your definition of "scalable manageability". I think you mean "doing nothing". In other words, all the intelligence will be at the customer's side, and the network will be dumb. Let alone that it does not make sense from provider's point of view (i.e., revenue), it does not make sense from customer's point of view as some of them don't want to deal with the complexity (e.g, fully meshed connections and route peerings). Otherwise, if you want to provide VPN service, all the things about RFC2547 you (mis)represented in your e-mail are necessary for this service, they have not descended from heaven. The pros of RFC2547 are explained in RFC2547bis draft quite well. In addition, the scalability of tunnels and VPN-labels are really non-issue. For the troubleshooting, there are alredy some tools, however, we still need to improve it. In utopic world, things could have been different and this service could have been provided differently. But this is an evolutionary step for a really working network. On the other hand, I don't believe one can design a new perfect network from scratch. thanks, yetik -----Original Message----- From: Chen, Weijing Sent: Friday, November 22, 2002 12:50 PM To: 'raszuk@cisco.com' Cc: 'PPVPN' Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Robert, Thanks for reply. However, I don't think that I mixed the VR-based and 2547bis-based VPN. Regardless it is a VR or a VRF, from management standpoint, it is a router that we must management, e.g. route target id, import id, export id, etc. in 2547bis case. Also for VRF and PE connection, LSP labels in both end and sometime LSP labels in the middle. As long as they are something that we must establish or assign, keep track of, and troubleshoot, they require system resource and human resource. And those resources come with cost. It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us that it is not big deal since it is just a connection. 10 years from then, we are still bearing the pain of provisioned connection-oriented (S)PVC. IP is great since it is connectionless. Telephone (POTS) is also great since it is connection-oriented with fully functioned end-to-end subscriber initiatied signaling. Either one will work for us, but not something in between. Oh, well, I went too far. -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com] Sent: Friday, November 22, 2002 12:24 PM To: Chen, Weijing Cc: 'Yakov Rekhter'; 'PPVPN' Subject: Re: Scalable and manageable network management and operation of MPLS/VPN Weijing, Your below email clearly indicates that you are mixing VR based L3VPNs with the L3VPNs described in 2547bis architecture as non of your points apply to the latter one. I must admit that they are very true for the first type of L3VPNs though :-). Thx, R. > Yakov, > > > > Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list > archive. > > > > >>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"? > > > > In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the > attributes on the port serving the subscriber. We have to dedicate resources to the subscriber that go deeper into the network than just > their port. Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult. > > > > Specifically, the resources we have to dedicate and manage are: > > #Virtual Routing Functions. Nearly one for each CE/PE interface. Each one of these, from a management standpoint, is a > router. Right now, large IP carriers manage hundreds to possibly a few thousand routers. With IP VPNs, we'll be managing tens of > thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. > #Connections between VRFs. Each VRF in a VPN has to have a connection to every other VRF in the VPN. The more VRFs > you have (100,000), the more connections you have between them. > #Connections between PEs. Each PE in a VPN has to have a connection to every other PE in the VPN. This connection > maybe shared by multiple VRFs in the same PE pairs. However, tracking of what connection to be shared or establishing new one if > not shared is another daunting task. > > > > Each single item above is translated into $$, which including recurring OPEX for operation and OSS system > maintenance, and nonrecurring CAPEX for OSS system. > > > > >>Also, when you said "we operation group in service provider", do you mean a specific service provider? > > Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of > subscribers (number of sites), such as us > > > > Regards, > > > > > > -- > > Weijing Chen > > SBC Technology Resources > > 9505 Arboretum Blvd. > > Austin, TX 78759 > > 512 372 5710 > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 15:45:45 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 PAA03804 for ; Fri, 22 Nov 2002 15:45:45 -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 gAMKl0D11583 for ; Fri, 22 Nov 2002 15:47:00 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gAMKkv000947 for ; Fri, 22 Nov 2002 15:46:57 -0500 (EST) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322718@trimail2> From: "Chen, Weijing" To: "'Thomas Nadeau'" Cc: "'PPVPN'" Subject: RE: Scalable and manageable network management and operation of M PLS/ VPN Date: Fri, 22 Nov 2002 14:46:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29268.2B105560" X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: wchen@tri.sbc.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] 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_01C29268.2B105560 Content-Type: text/plain Thomas, I guess I stirred up a hornet nest. To clam down the concern that I may advocate one VPN technology over another VPN technology, you can relax, I do not. As matter of fact, I have same concern over all the solutions. Now forgive my ignorance, please help me out on the following steps that I must do to establish, keep track of, and troubleshoot a VPN subscriber. If I am wrong, tell me what is right. 1. CE-PE access link: That is what I must do regardless what kind of services, VPN or not. We can check this off. 2. CE-PE routing: What do I need to do to: establish, keep track of, and troubleshoot? 3. VRF: Besides RD assignment for this VPN, what about RT? How do I know what RT to use? Is a management system to assign, track RTs necessary? What else need, MP-BGP? 4. Inner label (or VRF VPN label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? 5. Outer label (or PE Tunnel label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? So help me out here. -- Weijing Chen -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, November 22, 2002 1:50 PM To: Chen, Weijing Cc: 'PPVPN' Subject: Re: Scalable and manageable network management and operation of MPLS/ VPN At 12:07 PM 11/22/2002 -0600, Chen, Weijing wrote: Yakov, Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list archive. >>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"? In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the attributes on the port serving the subscriber. We have to dedicate resources to the subscriber that go deeper into the network than just their port. Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult. If you look at network management this way, then of course, any VPN technology you look at will not be scalable. However, the success of 2547 is indeed that a well designed management system can managed new customers by managing basically the VRF attributes. The typical addition of one (or hundreds) of customers should not affect the layout of your internal network or even the PE where those customers are attached if you did things correctly from the start. For example, many providers I know will size how many customers a particular PE can handle in their lab. Once they know this, they just provision customers in a single, easy way. Once they get near the limit, they order another PE. This also plays into the larger design of the core network of course, but I think that if your network is designed to slimly that it needs to be re-provisioned whenever any customer is added, that you should think about your design again. Specifically, the resources we have to dedicate and manage are: 1. Virtual Routing Functions. Nearly one for each CE/PE interface. Each one of these, from a management standpoint, is a router. Right now, large IP carriers manage hundreds to possibly a few thousand routers. With IP VPNs, we'll be managing tens of thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. Perhaps you can explain to me why you think that the addition of one customer is going to affect all of the nodes in your network? I do not know of any deployments where providers re-provision their entire network based on the addition or re-provision of a 2547 customer. 1. Connections between VRFs. Each VRF in a VPN has to have a connection to every other VRF in the VPN. The more VRFs you have (100,000), the more connections you have between them. You are thinking about this as if MPLS is a connection-oriented network, which it is not. The exception is if you are using RSVP-TE tunnels between PEs. However, a typical 2547 network uses LDP to establish sessions and distribute labels between PEs, not each VRF. In essence, you get paths between PEs over which you switch the VPN labels. I think that you are thinking of things as if there are actual connection-oriented paths between all VRFs in a VPN. Even if you use RSVP-TE tunnels between PEs, you can support many hundreds or thousands of VPNs between those PEs without needing a TE tunnel per VRF inter-connection. Thus only a small number of tunnels exist between PEs (as opposed to specific tunnels for each VPN or VRF-pair). 1. Connections between PEs. Each PE in a VPN has to have a connection to every other PE in the VPN. This connection maybe shared by multiple VRFs in the same PE pairs. Yes, but why is this a problem? 1. However, tracking of what connection to be shared or establishing new one if not shared is another daunting task. Just look at the loopbacks at one VRF and that gives you pointers to the other PEs. If you are interested in figuring out which physical links are shared by which VRFs on a particular PE, then just look at the LFIB based on the label used by the loopback. Each single item above is translated into $$, which including recurring OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for OSS system. I am not sure of that based on my experience with my customers who have deployed 2547 networks. Certainly CAPEX is required for the equipment to begin with, but OPEX is actually quite low for 2547 as compared to many other VPN technologies, especially if your OSS and network deployment strategy is sound to begin with. I am not saying that management of any network and certain 2547-based is easy, but I totally disagree with the assertion that a 2547 network is not scalable based on how it must be managed. --Tom >>Also, when you said "we operation group in service provider", do you mean a specific service provider? Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of subscribers (number of sites), such as us Regards, -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 ------_=_NextPart_001_01C29268.2B105560 Content-Type: text/html

Thomas,

 

I guess I stirred up a hornet nest.  To clam down the concern that I may advocate one VPN technology over another VPN technology, you can relax, I do not.  As matter of fact, I have same concern over all the solutions.

 

Now forgive my ignorance, please help me out on the following steps that I must do to establish, keep track of, and troubleshoot a VPN subscriber.  If I am wrong, tell me what is right.

 

  1. CE-PE access link:  That is what I must do regardless what kind of services, VPN or not.  We can check this off.
  2. CE-PE routing:  What do I need to do to: establish, keep track of, and troubleshoot?
  3. VRF:  Besides RD assignment for this VPN, what about RT?  How do I know what RT to use?  Is a management system to assign, track RTs necessary? What else need, MP-BGP?
  4. Inner label (or VRF VPN label):  Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)?  What about intermediate label?
  5. Outer label (or PE Tunnel label):  Where does it come from?  Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label?

 

So help me out here.

 

--

Weijing Chen

 

-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Friday, November 22, 2002 1:50 PM
To: Chen, Weijing
Cc: 'PPVPN'
Subject: Re: Scalable and manageable network management and operation of MPLS/ VPN

 

At 12:07 PM 11/22/2002 -0600, Chen, Weijing wrote:


Yakov,

 

Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list archive.

 

>>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"?

 

In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the attributes on the port serving the subscriber.  We have to dedicate resources to the subscriber that go deeper into the network than just their port.  Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult.


        If you look at network management this way, then of course, any VPN technology you
look at will not be scalable.   However, the success of 2547 is indeed that a well designed
management system can managed new customers by managing basically the VRF attributes.
The typical addition of one (or hundreds) of customers should not affect the layout of your internal
network or even the PE where those customers are attached if you did things correctly
from the start.    For example, many providers I know will size how many customers a
particular PE can handle in their lab.  Once they know this, they just provision
customers in a single, easy way. Once they get near the limit, they order another
PE. This also plays into the larger design of the core network of course, but I think
that if your network is designed to slimly that it needs to be re-provisioned whenever
any customer is added, that you should think about your design again.


Specifically, the resources we have to dedicate and manage are:

  1. Virtual Routing Functions.  Nearly one for each CE/PE interface.  Each one of these, from a management standpoint, is a router.  Right now, large IP carriers manage hundreds to possibly a few thousand routers.  With IP VPNs, we'll be managing tens of thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump.

        Perhaps you can explain to me why you think that the addition of one customer is going to
affect all of the nodes in your network?  I do not know of any deployments where providers
re-provision their entire network based on the addition or re-provision of a 2547 customer.

  1. Connections between VRFs.  Each VRF in a VPN has to have a connection to every other VRF in the VPN.  The more VRFs you have (100,000), the more connections you have between them.

        You are thinking about this as if MPLS is a connection-oriented network, which it
is not. The exception is if you are using RSVP-TE tunnels between PEs.  However,
a typical 2547 network uses LDP to establish sessions and distribute
labels between PEs, not each VRF.  In essence, you get paths between PEs
over which you switch the VPN labels. I think that you are thinking of things
as if there are actual connection-oriented paths between all VRFs in a VPN.
Even if you use RSVP-TE tunnels between PEs, you can
support many hundreds or thousands of VPNs between those PEs without needing
a TE tunnel per VRF inter-connection. Thus only a small number of tunnels exist
between PEs (as opposed to specific tunnels for each VPN or VRF-pair).

  1. Connections between PEs.  Each PE in a VPN has to have a connection to every other PE in the VPN.  This connection maybe shared by multiple VRFs in the same PE pairs. 

        Yes, but why is this a problem?

  1. However, tracking of what connection to be shared or establishing new one if not shared is another daunting task.

        Just look at the loopbacks at one VRF and that gives you pointers to the other PEs.
If you are interested in figuring out which physical links are shared by which VRFs on
a particular PE, then just look at the LFIB based on the label used by the loopback.


Each single item above is translated into $$, which including recurring OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for OSS system.


        I am not sure of that based on my experience with my customers who have
deployed 2547 networks.  Certainly CAPEX is required for the equipment to begin
with, but OPEX is actually quite low for 2547 as compared to many other VPN
technologies, especially if your OSS and network deployment strategy is sound
to begin with. I am not saying that management of any network and certain 2547-based
is easy, but I totally disagree with the assertion that a 2547 network is not scalable
based on how it must be managed.

        --Tom



>>Also, when you said "we operation group in service provider", do you mean a specific service provider?

Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of subscribers (number of sites), such as us

 

Regards,

 

 

--

Weijing Chen

SBC Technology Resources

9505 Arboretum Blvd.

Austin, TX 78759

512 372 5710

 

 

------_=_NextPart_001_01C29268.2B105560-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 16:10:44 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 QAA04259 for ; Fri, 22 Nov 2002 16:10: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 gAMLCmD00818 for ; Fri, 22 Nov 2002 16:12: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 gAMLCj018807 for ; Fri, 22 Nov 2002 16:12:45 -0500 (EST) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322719@trimail2> From: "Chen, Weijing" To: "Serbest, Yetik" , "'raszuk@cisco.com'" Cc: "'PPVPN'" Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Date: Fri, 22 Nov 2002 15:12:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: wchen@tri.sbc.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: Yetik, Not "doing nothing", but "doing manageable thing". What I am trying to point out is that things we have to do now does not seem scalable to large number. Sure if the number of subscribers does not go up, we will be fine. Hay, in that case, even CLI may work. -- Weijing Chen -----Original Message----- From: Serbest, Yetik Sent: Friday, November 22, 2002 2:29 PM To: Chen, Weijing; 'raszuk@cisco.com' Cc: 'PPVPN' Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Weijing, First of all, I need to understand your definition of "scalable manageability". I think you mean "doing nothing". In other words, all the intelligence will be at the customer's side, and the network will be dumb. Let alone that it does not make sense from provider's point of view (i.e., revenue), it does not make sense from customer's point of view as some of them don't want to deal with the complexity (e.g, fully meshed connections and route peerings). Otherwise, if you want to provide VPN service, all the things about RFC2547 you (mis)represented in your e-mail are necessary for this service, they have not descended from heaven. The pros of RFC2547 are explained in RFC2547bis draft quite well. In addition, the scalability of tunnels and VPN-labels are really non-issue. For the troubleshooting, there are alredy some tools, however, we still need to improve it. In utopic world, things could have been different and this service could have been provided differently. But this is an evolutionary step for a really working network. On the other hand, I don't believe one can design a new perfect network from scratch. thanks, yetik -----Original Message----- From: Chen, Weijing Sent: Friday, November 22, 2002 12:50 PM To: 'raszuk@cisco.com' Cc: 'PPVPN' Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Robert, Thanks for reply. However, I don't think that I mixed the VR-based and 2547bis-based VPN. Regardless it is a VR or a VRF, from management standpoint, it is a router that we must management, e.g. route target id, import id, export id, etc. in 2547bis case. Also for VRF and PE connection, LSP labels in both end and sometime LSP labels in the middle. As long as they are something that we must establish or assign, keep track of, and troubleshoot, they require system resource and human resource. And those resources come with cost. It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us that it is not big deal since it is just a connection. 10 years from then, we are still bearing the pain of provisioned connection-oriented (S)PVC. IP is great since it is connectionless. Telephone (POTS) is also great since it is connection-oriented with fully functioned end-to-end subscriber initiatied signaling. Either one will work for us, but not something in between. Oh, well, I went too far. -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com] Sent: Friday, November 22, 2002 12:24 PM To: Chen, Weijing Cc: 'Yakov Rekhter'; 'PPVPN' Subject: Re: Scalable and manageable network management and operation of MPLS/VPN Weijing, Your below email clearly indicates that you are mixing VR based L3VPNs with the L3VPNs described in 2547bis architecture as non of your points apply to the latter one. I must admit that they are very true for the first type of L3VPNs though :-). Thx, R. > Yakov, > > > > Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list > archive. > > > > >>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"? > > > > In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the > attributes on the port serving the subscriber. We have to dedicate resources to the subscriber that go deeper into the network than just > their port. Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult. > > > > Specifically, the resources we have to dedicate and manage are: > > #Virtual Routing Functions. Nearly one for each CE/PE interface. Each one of these, from a management standpoint, is a > router. Right now, large IP carriers manage hundreds to possibly a few thousand routers. With IP VPNs, we'll be managing tens of > thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. > #Connections between VRFs. Each VRF in a VPN has to have a connection to every other VRF in the VPN. The more VRFs > you have (100,000), the more connections you have between them. > #Connections between PEs. Each PE in a VPN has to have a connection to every other PE in the VPN. This connection > maybe shared by multiple VRFs in the same PE pairs. However, tracking of what connection to be shared or establishing new one if > not shared is another daunting task. > > > > Each single item above is translated into $$, which including recurring OPEX for operation and OSS system > maintenance, and nonrecurring CAPEX for OSS system. > > > > >>Also, when you said "we operation group in service provider", do you mean a specific service provider? > > Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of > subscribers (number of sites), such as us > > > > Regards, > > > > > > -- > > Weijing Chen > > SBC Technology Resources > > 9505 Arboretum Blvd. > > Austin, TX 78759 > > 512 372 5710 > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 16:15:12 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04340 for ; Fri, 22 Nov 2002 16:15:12 -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 gAMLH4D05318 for ; Fri, 22 Nov 2002 16:17: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 gAMLH2025577 for ; Fri, 22 Nov 2002 16:17:02 -0500 (EST) Message-Id: <3.0.5.32.20021122155509.008d6b40@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 22 Nov 2002 15:55:09 -0500 To: Juha Heinanen , ppvpn@nortelnetworks.com From: Mark Duffy Subject: Re: fate of directory based discovery In-Reply-To: <15837.34153.7463.330618@lohi.eng.song.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: Hi Juha, I am still interested in seeing a directory-based approach developed. And, radius seems like a reasonable approach. --Mark At 03:16 AM 11/22/02 +0200, Juha Heinanen wrote: >there was not enough support in atlanta meeting to make the dns >discovery i-d a working group document. i guess it would be appropriate >to confirm that also on the mailing list, since not everyone who has >been working on the dns discovery was able to attend the meeting. > >anyhow, i have always said that i don't care what the directory is as >long as the vpn solution is internet wide and doesn't use bgp. some >people didn't like dns discovery, because (although simple) it overloads >dns with stuff that dns was not designed to do. so there may still be >enough support left for a directory based solution if something "better" >than dns can be found. > >i have been thinking for some time now that radius might be a another >possibility for implementing discovery. it would go something like >this: > >- radius is populated for each ce with information about the vpn that > the ce participates in (if any) >- a ce authenticates to the pe using e.g. 802.1x (or the ce is manually > configured in the pe) >- pe makes a radius query and gets as a response the id of the ce's vpn > and a list of other pes that have members in the same vpn >- the vpn's pe list is kept up in the radius server either manually or > based on radius accounting start/stop messages > >this would be a very flexible and automated solution, since there in >case .1x is used, NOTHING ce related needs to be configured in the pe. > >before spending more time on this, i would need to get an indication >from the working group if there is enough interest for ANY directory >based solution. > >-- juha > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 16:28:20 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04619 for ; Fri, 22 Nov 2002 16:28:19 -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 gAMLUMD09733 for ; Fri, 22 Nov 2002 16: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 gAMLUJ007737 for ; Fri, 22 Nov 2002 16:30:20 -0500 (EST) Message-Id: <5.2.0.9.2.20021122162407.01c05d48@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 22 Nov 2002 16:29:34 -0500 To: "Chen, Weijing" From: "Thomas D. Nadeau" Subject: RE: Scalable and manageable network management and operation of M PLS/ VPN Cc: "'PPVPN'" In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D6322718@trimail2> 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: At 02:46 PM 11/22/2002 -0600, Chen, Weijing wrote: >Thomas, > > > >I guess I stirred up a hornet nest. To clam down the concern that I may >advocate one VPN technology over another VPN technology, you can relax, I >do not. As matter of fact, I have same concern over all the solutions. > > > >Now forgive my ignorance, please help me out on the following steps that I >must do to establish, keep track of, and troubleshoot a VPN >subscriber. If I am wrong, tell me what is right. > > > * CE-PE access link: That is what I must do regardless what kind of > services, VPN or not. We can check this off. > * CE-PE routing: What do I need to do to: establish, keep track of, > and troubleshoot? Depends on what you run on the CE-PE link, and what sorts of things you are worried about (i.e.: are you concerned with SLA or just connectivity?). > * VRF: Besides RD assignment for this VPN, what about RT? How do I > know what RT to use? Is a management system to assign, track RTs > necessary? What else need, MP-BGP? These things are covered as part of a service profile that you need to work out in your provisioning system. There are standard APIs for provisioning these things via SNMP, or you can also use other various proprietary interfaces such as XML or CLI. > * Inner label (or VRF VPN label): Where does it come from? Is a > management system to assign, track labels necessary? If so, single label, > or each pair of labels (both ends)? What about intermediate label? > * Outer label (or PE Tunnel label): Where does it come from? Is a > management system to assign, track labels necessary? If so, single label, > or each pair of labels (both ends)? What about intermediate label? As Yakov suggested, I think that you need to become more familiar with how 2547 works. You generally do not need to configure the inner or outer labels; the router does that (although you can if you want to). One good place to start to look for what needs to be configured on a VRF is in the PPVPN-MPLS-VPN MIB. Of course this is only a start, as you may also want to configure MP-BGP, link or QoS parameters for each VRF. --Tom > > >So help me out here. > > > >-- > >Weijing Chen > > > >-----Original Message----- >From: Thomas Nadeau [mailto:tnadeau@cisco.com] >Sent: Friday, November 22, 2002 1:50 PM >To: Chen, Weijing >Cc: 'PPVPN' >Subject: Re: Scalable and manageable network management and operation of >MPLS/ VPN > > > >At 12:07 PM 11/22/2002 -0600, Chen, Weijing wrote: > > >Yakov, > > > >Sorry for late response. I didn't receive your reply for somewhat reason. >Yetik pointed this message to me and I found it from mailing list archive. > > > > >>Could you please elaborate on what exactly you are concerned with > respect to "scaleable manageability of MPLS/VPN"? > > > >In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all >we need to do to manage a subscriber is manage the attributes on the port >serving the subscriber. We have to dedicate resources to the subscriber >that go deeper into the network than just their port. Establishing, >keeping track of, and troubleshooting these resources on a per-subscriber >basis will be difficult. > > > If you look at network management this way, then of course, any > VPN technology you >look at will not be scalable. However, the success of 2547 is indeed >that a well designed >management system can managed new customers by managing basically the VRF >attributes. >The typical addition of one (or hundreds) of customers should not affect >the layout of your internal >network or even the PE where those customers are attached if you did >things correctly >from the start. For example, many providers I know will size how many >customers a >particular PE can handle in their lab. Once they know this, they just >provision >customers in a single, easy way. Once they get near the limit, they order >another >PE. This also plays into the larger design of the core network of course, >but I think >that if your network is designed to slimly that it needs to be >re-provisioned whenever >any customer is added, that you should think about your design again. > > >Specifically, the resources we have to dedicate and manage are: > * Virtual Routing Functions. Nearly one for each CE/PE > interface. Each one of these, from a management standpoint, is a > router. Right now, large IP carriers manage hundreds to possibly a few > thousand routers. With IP VPNs, we'll be managing tens of thousand to > possible hundreds of thousands of routers (VRF), a good 2 orders of > magnitude jump. > > Perhaps you can explain to me why you think that the addition of > one customer is going to >affect all of the nodes in your network? I do not know of any deployments >where providers >re-provision their entire network based on the addition or re-provision of >a 2547 customer. > * Connections between VRFs. Each VRF in a VPN has to have a > connection to every other VRF in the VPN. The more VRFs you have > (100,000), the more connections you have between them. > > You are thinking about this as if MPLS is a connection-oriented > network, which it >is not. The exception is if you are using RSVP-TE tunnels between >PEs. However, >a typical 2547 network uses LDP to establish sessions and distribute >labels between PEs, not each VRF. In essence, you get paths between PEs >over which you switch the VPN labels. I think that you are thinking of things >as if there are actual connection-oriented paths between all VRFs in a VPN. >Even if you use RSVP-TE tunnels between PEs, you can >support many hundreds or thousands of VPNs between those PEs without needing >a TE tunnel per VRF inter-connection. Thus only a small number of tunnels >exist >between PEs (as opposed to specific tunnels for each VPN or VRF-pair). > * Connections between PEs. Each PE in a VPN has to have a connection > to every other PE in the VPN. This connection maybe shared by multiple > VRFs in the same PE pairs. > > Yes, but why is this a problem? > * However, tracking of what connection to be shared or establishing > new one if not shared is another daunting task. > > Just look at the loopbacks at one VRF and that gives you pointers > to the other PEs. >If you are interested in figuring out which physical links are shared by >which VRFs on >a particular PE, then just look at the LFIB based on the label used by the >loopback. > > >Each single item above is translated into $$, which including recurring >OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for >OSS system. > > > I am not sure of that based on my experience with my customers > who have >deployed 2547 networks. Certainly CAPEX is required for the equipment to >begin >with, but OPEX is actually quite low for 2547 as compared to many other VPN >technologies, especially if your OSS and network deployment strategy is sound >to begin with. I am not saying that management of any network and certain >2547-based >is easy, but I totally disagree with the assertion that a 2547 network is >not scalable >based on how it must be managed. > > --Tom > > > > >>Also, when you said "we operation group in service provider", do you > mean a specific service provider? > >Any service provider with hundreds of POPs (or COs), thousands of PEs >(routers or switches), millions of subscribers (number of sites), such as us > > > >Regards, > > > > > >-- > >Weijing Chen > >SBC Technology Resources > >9505 Arboretum Blvd. > >Austin, TX 78759 > >512 372 5710 > > > > Success is relative; the more success, the more relatives. -Anonymous From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 18:09:07 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 SAA06725 for ; Fri, 22 Nov 2002 18:09:07 -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 gAMNAxD05987 for ; Fri, 22 Nov 2002 18:11:00 -0500 (EST) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id gAMNAv009726 for ; Fri, 22 Nov 2002 18:10:57 -0500 (EST) Message-Id: <4.3.2.7.2.20021122134842.01c0bfa8@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Nov 2002 15:10:17 -0800 To: Sasha Vainshtein , "Ali Sajassi (E-mail)" From: Ali Sajassi Subject: Re: Issues with draft-sajassi-mvpls-00.txt Cc: "Ppvpn (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-msg-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-2.cisco.com [171.70.145.30] X-LYRIS-Message-Id: Sasha, I answered some of these questions earlier but let me elaborate further ... At 11:58 PM 11/20/2002 +0200, Sasha Vainshtein wrote: >Ali and all, >I would like to re-state the issues I have raised at the PPVPN WG Session >today. >All these issues deal with the unicast part of the proposal. > >1. Allocation of huge numbers of IP addresses (an IP address per AC). > This looks highly problematic in inter-provider or even inter-AS >situations > (where use of private IP addresses is precluded). I think we agree that we don't have an issue with intra-AS since a provider has access to large address space based on RFC 1918. Now if the majority of the traffic is intra-AS, then for the small percentage of the end-points that require inter-AS communications, one can assign addresses from the public address space. However, if one still wants to reduce the number of public IP addresses, then he can do one of the following: a) Assign an IP address per VPLS instance instead of per AC for that PE (this is described in the draft) B) Make use of VPLS hierarchy with Ethernet access network (QinQ access network) C) Use multi-segment Emulated LAN (one segment per AS) >2. Involvement of core routers in the VPLS: with each new AC, all the core >routers > have to learn routes to the associated IP address. Not quite. Contrary to MPLS labels, IP addresses do get summarized in the core and thus not every time you add an AC, a route update is needed in the P nodes. Because of this route summarization, the amount of the states in the core is relatively small. > I'd like to remind you that the PWE3 Charter (I am not sure about the >PPVPN one) > explicitly states that PW functionality is limited to PEs only and that >PWs do not > exert control over the underlying network. IMHO the proposal violates >these > principles. Either requirements draft or the charter needs to be updated to make them consistent with each other. I think the main reason for non-path-oriented PW is the network scalability (avoid keeping per PW state in the core) and if keeping per PW state in core is not a requirement for a path-oriented scheme, then that scheme can be considered as an alternative option. However, given that MPVLS doesn't use the traditionally defined PW (as in PWE3), I might use the term tunnel instead of PW in the next rev. of the document to avoid confusion. >3. Forwarding in the egress PE. The draft states that it is is based > on the destination IP address found in the packet. It does not state > whether aIP ddresses associated with an AC are considered as IP addresses > owned by the PE router terminating this AC,or not. If they are not, > the packets with the AC-associated destination IP address should be > forwarded as IP packets which seems wrong, because such forwarding > does not persume stripping of IP header, MAC address look-up etc. > If they are, they would be treated based on the protocol number > and according to the protocol-specific rules. In particular,if the >protocol > is L2TPv3 (as mentionedin the presentation), the Session ID lookup would >be > done and,if such a lookup fails (as it should since the draft explicitly >states > that no sessions are established), the packet will be discarded (or so I >presume). As explained previously, it is the later case (IP addresses associated with the AC are owned by the PE) and as mentioned in the presentation, it can use either GRE or L2TPv3 encapsulation. In case of L2TPv3, it only uses the encapsulation part without session-id as I described in my previous email. Frankly given that L2TPv3 encap doesn't buy us anything over GRE, I am inclined to make it simple and narrowed it down to only GRE. Regards, Ali > > >---------------------------------------------------------------------------- >-------- >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 18:12:06 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 SAA06803 for ; Fri, 22 Nov 2002 18:12:06 -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 gAMNE2D10095 for ; Fri, 22 Nov 2002 18:14: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 gAMNDx014442 for ; Fri, 22 Nov 2002 18:14:00 -0500 (EST) Message-Id: <4.3.2.7.2.20021122151055.01bfcf70@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Nov 2002 15:13:10 -0800 To: Ray Qiu , Sasha Vainshtein , "Ali Sajassi (E-mail)" From: Ali Sajassi Subject: Re: Issues with draft-sajassi-mvpls-00.txt Cc: "Ppvpn (E-mail)" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-msg-core-3.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-3.cisco.com [171.70.157.152] X-LYRIS-Message-Id: At 08:52 PM 11/20/2002 -0800, Ray Qiu wrote: >I would think another potential scaling issue is that core routers have to >track all the Multicast states for all the VPLS's. There is only one multicast group address per VPLS instance and in tems of scalability is similar to multicast for L3VPN. -Ali >- Ray >On 11/20/02 13:58, "Sasha Vainshtein" wrote: > > > Ali and all, > > I would like to re-state the issues I have raised at the PPVPN WG Session > > today. > > All these issues deal with the unicast part of the proposal. > > > > 1. Allocation of huge numbers of IP addresses (an IP address per AC). > > This looks highly problematic in inter-provider or even inter-AS > > situations > > (where use of private IP addresses is precluded). > > > > 2. Involvement of core routers in the VPLS: with each new AC, all the core > > routers > > have to learn routes to the associated IP address. > > I'd like to remind you that the PWE3 Charter (I am not sure about the > > PPVPN one) > > explicitly states that PW functionality is limited to PEs only and that > > PWs do not > > exert control over the underlying network. IMHO the proposal violates > > these > > principles. > > > > 3. Forwarding in the egress PE. The draft states that it is is based > > on the destination IP address found in the packet. It does not state > > whether aIP ddresses associated with an AC are considered as IP addresses > > owned by the PE router terminating this AC,or not. If they are not, > > the packets with the AC-associated destination IP address should be > > forwarded as IP packets which seems wrong, because such forwarding > > does not persume stripping of IP header, MAC address look-up etc. > > If they are, they would be treated based on the protocol number > > and according to the protocol-specific rules. In particular,if the > > protocol > > is L2TPv3 (as mentionedin the presentation), the Session ID lookup would > > be > > done and,if such a lookup fails (as it should since the draft explicitly > > states > > that no sessions are established), the packet will be discarded (or so I > > presume). > > > > > > > ---------------------------------------------------------------------------- > > -------- > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > phone: +972-3-7659993 (office) > > +972-8-9254948 (home) > > +972-58-674833 (cellular) > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 19:50: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 TAA08215 for ; Fri, 22 Nov 2002 19:50: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 gAN0qQD27671 for ; Fri, 22 Nov 2002 19:52:26 -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 gAN0qN012859 for ; Fri, 22 Nov 2002 19:52:23 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 22 Nov 2002 16:51:47 -0800 Subject: Re: Issues with draft-sajassi-mvpls-00.txt From: Ray Qiu To: Ali Sajassi , Sasha Vainshtein CC: "Ppvpn (E-mail)" Message-ID: In-Reply-To: <4.3.2.7.2.20021122151055.01bfcf70@airborne.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Nov 2002 00:51:29.0834 (UTC) FILETIME=[75BE40A0:01C2928A] X-SMTP-HELO: RS-SC-EXC4.rs.riverstonenet.com X-SMTP-MAIL-FROM: rqiu@riverstonenet.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host60.riverstonenet.com [64.95.122.60] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On 11/22/02 15:13, "Ali Sajassi" wrote: > At 08:52 PM 11/20/2002 -0800, Ray Qiu wrote: >> I would think another potential scaling issue is that core routers have to >> track all the Multicast states for all the VPLS's. > > There is only one multicast group address per VPLS instance and in tems of > scalability is similar to multicast for L3VPN. > > -Ali That is true, but if you compare it with other VPLS solutions? - Ray From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 21:12:35 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 VAA09592 for ; Fri, 22 Nov 2002 21:12:35 -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 gAN2EKD10479 for ; Fri, 22 Nov 2002 21:14: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 gAN2EH026640 for ; Fri, 22 Nov 2002 21:14:17 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: Scalable and manageable network management and operation of MPLS/ VPN Date: Fri, 22 Nov 2002 21:13:33 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170320B039@OCCLUST04EVS1.ugd.att.com> Thread-Topic: RE: Scalable and manageable network management and operation of MPLS/ VPN Thread-Index: AcKSlcLnu/H7m/sXEdai6ADAT2jDug== From: "Fang, Luyuan, ALCNS" To: "Chen, Weijing" , "Thomas Nadeau" Cc: "PPVPN" X-SMTP-HELO: almso2.proxy.att.com X-SMTP-MAIL-FROM: luyuanfang@att.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: almso2.att.com [192.128.166.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA09592 Weijing, Though your questions were for Tom, I'd like give some quick answers since we implement 2547 to provide the services to our customers. 1. > CE-PE access link: That is what I must do regardless what kind of services, VPN or not. We can check this off. That is right. 2. > CE-PE routing: What do I need to do to: establish, keep track of, and troubleshoot? You can run same protocols as for IP services, eBGP/OSPF/static/RIP, etc. For Enterprise VPN, you provision the VPN on PE only, VRF, RD, RT are all transparent to your customers. Yes, you need keep track of them in your systems. 3. > VRF: Besides RD assignment for this VPN, what about RT? How do I know what RT to use? Is a management system to assign, track RTs necessary? What else need, MP-BGP? VRF, RD and RT can all be assigned automatically by provisioning systems and tracked by provision/management systems. You can develop such system in house or use tools from vendors or third parties. Establish MP-BGP connectivity through RRs is also part of auto-provisioning process. 4. >Inner label (or VRF VPN label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? Labels are assigned by the routers automatically, not assigned by management system or provisioning system. Router A will tell router B to use label X to reach VPN ABC on router A, router B will tell router A to use label Y to reach VPN ABC on router B. 5. Outer label (or PE Tunnel label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? Same as above, all MPLS labels (VPNv4(v6), LDP, IPv4(v6), RSVP-TE, etc.) are auto-generated by the routers, not management systems. You might want to get a little more familiar with RFC2547 and other MPLS basics before criticizing. Luyuan Fang AT&T, IP backbone architecture -----Original Message----- From: Chen, Weijing [mailto:wchen@tri.sbc.com] Sent: Friday, November 22, 2002 3:46 PM To: 'Thomas Nadeau' Cc: 'PPVPN' Subject: RE: Scalable and manageable network management and operation of M PLS/ VPN Thomas, I guess I stirred up a hornet nest. To clam down the concern that I may advocate one VPN technology over another VPN technology, you can relax, I do not. As matter of fact, I have same concern over all the solutions. Now forgive my ignorance, please help me out on the following steps that I must do to establish, keep track of, and troubleshoot a VPN subscriber. If I am wrong, tell me what is right. CE-PE access link: That is what I must do regardless what kind of services, VPN or not. We can check this off. CE-PE routing: What do I need to do to: establish, keep track of, and troubleshoot? VRF: Besides RD assignment for this VPN, what about RT? How do I know what RT to use? Is a management system to assign, track RTs necessary? What else need, MP-BGP? Inner label (or VRF VPN label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? Outer label (or PE Tunnel label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? So help me out here. -- Weijing Chen -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, November 22, 2002 1:50 PM To: Chen, Weijing Cc: 'PPVPN' Subject: Re: Scalable and manageable network management and operation of MPLS/ VPN At 12:07 PM 11/22/2002 -0600, Chen, Weijing wrote: Yakov, Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list archive. >>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"? In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the attributes on the port serving the subscriber. We have to dedicate resources to the subscriber that go deeper into the network than just their port. Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult. If you look at network management this way, then of course, any VPN technology you look at will not be scalable. However, the success of 2547 is indeed that a well designed management system can managed new customers by managing basically the VRF attributes. The typical addition of one (or hundreds) of customers should not affect the layout of your internal network or even the PE where those customers are attached if you did things correctly from the start. For example, many providers I know will size how many customers a particular PE can handle in their lab. Once they know this, they just provision customers in a single, easy way. Once they get near the limit, they order another PE. This also plays into the larger design of the core network of course, but I think that if your network is designed to slimly that it needs to be re-provisioned whenever any customer is added, that you should think about your design again. Specifically, the resources we have to dedicate and manage are: Virtual Routing Functions. Nearly one for each CE/PE interface. Each one of these, from a management standpoint, is a router. Right now, large IP carriers manage hundreds to possibly a few thousand routers. With IP VPNs, we'll be managing tens of thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. Perhaps you can explain to me why you think that the addition of one customer is going to affect all of the nodes in your network? I do not know of any deployments where providers re-provision their entire network based on the addition or re-provision of a 2547 customer. Connections between VRFs. Each VRF in a VPN has to have a connection to every other VRF in the VPN. The more VRFs you have (100,000), the more connections you have between them. You are thinking about this as if MPLS is a connection-oriented network, which it is not. The exception is if you are using RSVP-TE tunnels between PEs. However, a typical 2547 network uses LDP to establish sessions and distribute labels between PEs, not each VRF. In essence, you get paths between PEs over which you switch the VPN labels. I think that you are thinking of things as if there are actual connection-oriented paths between all VRFs in a VPN. Even if you use RSVP-TE tunnels between PEs, you can support many hundreds or thousands of VPNs between those PEs without needing a TE tunnel per VRF inter-connection. Thus only a small number of tunnels exist between PEs (as opposed to specific tunnels for each VPN or VRF-pair). Connections between PEs. Each PE in a VPN has to have a connection to every other PE in the VPN. This connection maybe shared by multiple VRFs in the same PE pairs. Yes, but why is this a problem? However, tracking of what connection to be shared or establishing new one if not shared is another daunting task. Just look at the loopbacks at one VRF and that gives you pointers to the other PEs. If you are interested in figuring out which physical links are shared by which VRFs on a particular PE, then just look at the LFIB based on the label used by the loopback. Each single item above is translated into $$, which including recurring OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for OSS system. I am not sure of that based on my experience with my customers who have deployed 2547 networks. Certainly CAPEX is required for the equipment to begin with, but OPEX is actually quite low for 2547 as compared to many other VPN technologies, especially if your OSS and network deployment strategy is sound to begin with. I am not saying that management of any network and certain 2547-based is easy, but I totally disagree with the assertion that a 2547 network is not scalable based on how it must be managed. --Tom >>Also, when you said "we operation group in service provider", do you mean a specific service provider? Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of subscribers (number of sites), such as us Regards, -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 From bounce-ppvpn-121951@lyris.nortelnetworks.com Fri Nov 22 21:37:29 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 VAA10389 for ; Fri, 22 Nov 2002 21:37: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 gAN2daD14918 for ; Fri, 22 Nov 2002 21:39: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 gAN2dY002942 for ; Fri, 22 Nov 2002 21:39:34 -0500 (EST) Message-Id: <4.3.2.7.2.20021122181430.01c5d818@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Nov 2002 18:38:59 -0800 To: Ray Qiu , Ali Sajassi , Sasha Vainshtein From: Ali Sajassi Subject: Re: Issues with draft-sajassi-mvpls-00.txt Cc: "Ppvpn (E-mail)" In-Reply-To: References: <4.3.2.7.2.20021122151055.01bfcf70@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-msg-core-2.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-2.cisco.com [171.70.145.30] X-LYRIS-Message-Id: At 04:51 PM 11/22/2002 -0800, Ray Qiu wrote: >On 11/22/02 15:13, "Ali Sajassi" wrote: > > > At 08:52 PM 11/20/2002 -0800, Ray Qiu wrote: > >> I would think another potential scaling issue is that core routers have to > >> track all the Multicast states for all the VPLS's. > > > > There is only one multicast group address per VPLS instance and in tems of > > scalability is similar to multicast for L3VPN. > > > > -Ali >That is true, but if you compare it with other VPLS solutions? MVPLS is intended to complement (and not compete with) baseline VPLS solution by providing an efficient mechanism for the support of customers' multicast data. -Ali >- Ray From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 23 03:33:40 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 DAA25019 for ; Sat, 23 Nov 2002 03:33:39 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAN8ZRi19961 for ; Sat, 23 Nov 2002 03:35: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 gAN8ZOE26987 for ; Sat, 23 Nov 2002 03:35:24 -0500 (EST) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15839.15771.109097.898660@lohi.eng.song.fi> Date: Sat, 23 Nov 2002 10:34:35 +0200 To: Yakov Rekhter Cc: "Chen, Weijing" , "'PPVPN'" Subject: Re: Scalable and manageable network management and operation of MPLS/ VPN In-Reply-To: <200211221943.gAMJhdS32016@merlot.juniper.net> References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322716@trimail2> <200211221943.gAMJhdS32016@merlot.juniper.net> X-Mailer: VM 6.97 under Emacs 20.7.2 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 Yakov Rekhter writes: > With provider-provisioned Layer 3 VPNs a provider *by definition of > the service* has to participate in each VPN customer's routing. This > is irrespective of whether one uses 2547, Virtual Routers, or > (provider-provisioned) IPSec between CEs. So, the complexity of Layer > 3 VPN service has nothing to do with MPLS, but has to do with the > service itself. yes, and that is why i prefer layer 2 vpls service, where the provider doesn't need to know anything about the subscribers layer 3 protocols or routing. > If a service provider does not want to participate in VPN customers' > routing, the provider could either (a) offer no VPN services at all, > or (b) offer Layer 2 VPN services (e.g., FR, ATM, VPLS, etc...). All > of the Layer 2 VPN services I mentioned could be offered with > MPLS. So, if you think that Layer 2 VPN services do not have the > "scaleable manageability" problem, then clearly MPLS/VPNs (used to > offer Layer 2 VPN services) would not have the "scaleable > manageability" problem either. yes, and therefore i prefer l2tp over mpls. > Rather than having a complete IBGP mesh among the PEs, it is > advantageous to make use of BGP Route Reflectors [BGP-RR] to > improve scalability. All the usual techniques for using route > reflectors to improve scalability, e.g., route reflector > hierarchies, are available. how does route reflectors work and improve scalability in multi as/isp environment? -- juha From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 23 03:39:12 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25119 for ; Sat, 23 Nov 2002 03:39:11 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAN8fFi24179 for ; Sat, 23 Nov 2002 03:41:17 -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 gAN8fCE01692 for ; Sat, 23 Nov 2002 03:41:12 -0500 (EST) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15839.16131.907916.365447@lohi.eng.song.fi> Date: Sat, 23 Nov 2002 10:40:35 +0200 To: Thomas Nadeau Cc: "Chen, Weijing" , "'PPVPN'" Subject: RE: Scalable and manageable network management and operation of M PLS/VPN In-Reply-To: <4.3.2.7.2.20021122150558.00b16f08@bucket.cisco.com> References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> <4.3.2.7.2.20021122150558.00b16f08@bucket.cisco.com> X-Mailer: VM 6.97 under Emacs 20.7.2 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 Thomas Nadeau writes: > One of the advantages to MPLS L3VPN is that it > can be managed as part of your overall MPLS management strategy > given that it is an extension of MPLS. in case the provider has no other use for mpls than vpns, then the provider needs to start managing mpls in addtion to managing ip, which clearly is an additional burden. -- juha From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 23 10:21:22 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00339 for ; Sat, 23 Nov 2002 10:21: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 gANFMJi01509 for ; Sat, 23 Nov 2002 10:22: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 gANFMHE08214 for ; Sat, 23 Nov 2002 10:22:17 -0500 (EST) Message-Id: <5.2.0.9.2.20021122163515.02df54e0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 22 Nov 2002 16:40:36 -0500 To: "Chen, Weijing" From: "Thomas D. Nadeau" Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Cc: "'PPVPN'" In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D6322719@trimail2> 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: >Yetik, > >Not "doing nothing", but "doing manageable thing". I think you need to define what "doing manageable thing" means exactly before analyzing the technology. Once you have a good set of parameters, then look at the technology and how it can be managed to see if it meets your goals/requirements. I think that looking at the technology and then saying that it doesn't work like what you have today (which you claim below is not scalable to large numbers) and therefore is not scalable, is not the way to go. >What I am trying to >point out is that things we have to do now does not seem scalable to large >number. What are you doing now? >Sure if the number of subscribers does not go up, we will be fine. Well, if you are thinking of making money from this or any other new service, I hope you would like for the number of subscribers to increase . And in the least, to the point where you have at least the same number of subscribers as you have with your old service. >Hay, in that case, even CLI may work. Why is that relevant? I didn't think that we were comparing management interfaces. --Tom >- >Weijing Chen > >-----Original Message----- >From: Serbest, Yetik >Sent: Friday, November 22, 2002 2:29 PM >To: Chen, Weijing; 'raszuk@cisco.com' >Cc: 'PPVPN' >Subject: RE: Scalable and manageable network management and operation of M >PLS/VPN > >Weijing, > >First of all, I need to understand your definition of "scalable >manageability". I think you mean "doing nothing". In other words, all the >intelligence will be at the customer's side, and the network will be dumb. >Let alone that it does not make sense from provider's point of view (i.e., >revenue), it does not make sense from customer's point of view as some of >them don't want to deal with the complexity (e.g, fully meshed connections >and route peerings). > >Otherwise, if you want to provide VPN service, all the things about RFC2547 >you (mis)represented in your e-mail are necessary for this service, they >have not descended from heaven. The pros of RFC2547 are explained in >RFC2547bis draft quite well. In addition, the scalability of tunnels and >VPN-labels are really non-issue. For the troubleshooting, there are alredy >some tools, however, we still need to improve it. > >In utopic world, things could have been different and this service could >have been provided differently. But this is an evolutionary step for a >really working network. On the other hand, I don't believe one can design a >new perfect network from scratch. > >thanks, >yetik > >-----Original Message----- >From: Chen, Weijing >Sent: Friday, November 22, 2002 12:50 PM >To: 'raszuk@cisco.com' >Cc: 'PPVPN' >Subject: RE: Scalable and manageable network management and operation of >M PLS/VPN > > >Robert, > >Thanks for reply. However, I don't think that I mixed the VR-based and >2547bis-based VPN. Regardless it is a VR or a VRF, from management >standpoint, it is a router that we must management, e.g. route target id, >import id, export id, etc. in 2547bis case. Also for VRF and PE connection, >LSP labels in both end and sometime LSP labels in the middle. As long as >they are something that we must establish or assign, keep track of, and >troubleshoot, they require system resource and human resource. And those >resources come with cost. > >It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us >that it is not big deal since it is just a connection. 10 years from then, >we are still bearing the pain of provisioned connection-oriented (S)PVC. > >IP is great since it is connectionless. Telephone (POTS) is also great >since it is connection-oriented with fully functioned end-to-end subscriber >initiatied signaling. Either one will work for us, but not something in >between. Oh, well, I went too far. > > >-- >Weijing Chen >SBC Technology Resources >9505 Arboretum Blvd. >Austin, TX 78759 >512 372 5710 >wchen@tri.sbc.com > > >-----Original Message----- >From: Robert Raszuk [mailto:raszuk@cisco.com] >Sent: Friday, November 22, 2002 12:24 PM >To: Chen, Weijing >Cc: 'Yakov Rekhter'; 'PPVPN' >Subject: Re: Scalable and manageable network management and operation of >MPLS/VPN > > >Weijing, > >Your below email clearly indicates that you are mixing VR based L3VPNs >with the L3VPNs described in 2547bis architecture as non of your points >apply to the latter one. I must admit that they are very true for the >first type of L3VPNs though :-). > >Thx, >R. > > > Yakov, > > > > > > > > Sorry for late response. I didn't receive your reply for somewhat >reason. Yetik pointed this message to me and I found it from mailing list > > archive. > > > > > > > > >>Could you please elaborate on what exactly you are concerned with >respect to "scaleable manageability of MPLS/VPN"? > > > > > > > > In a nutshell, RFC 2547 doesn't scale because it breaks the rule that >all we need to do to manage a subscriber is manage the > > attributes on the port serving the subscriber. We have to dedicate >resources to the subscriber that go deeper into the network than just > > their port. Establishing, keeping track of, and troubleshooting these >resources on a per-subscriber basis will be difficult. > > > > > > > > Specifically, the resources we have to dedicate and manage are: > > > > #Virtual Routing Functions. Nearly one for each CE/PE interface. Each >one of these, from a management standpoint, is a > > router. Right now, large IP carriers manage hundreds to possibly a >few thousand routers. With IP VPNs, we'll be managing tens of > > thousand to possible hundreds of thousands of routers (VRF), a good 2 >orders of magnitude jump. > > #Connections between VRFs. Each VRF in a VPN has to have a connection >to every other VRF in the VPN. The more VRFs > > you have (100,000), the more connections you have between them. > > #Connections between PEs. Each PE in a VPN has to have a connection to >every other PE in the VPN. This connection > > maybe shared by multiple VRFs in the same PE pairs. However, >tracking of what connection to be shared or establishing new one if > > not shared is another daunting task. > > > > > > > > Each single item above is translated into $$, which including >recurring OPEX for operation and OSS system > > maintenance, and nonrecurring CAPEX for OSS system. > > > > > > > > >>Also, when you said "we operation group in service provider", do you >mean a specific service provider? > > > > Any service provider with hundreds of POPs (or COs), thousands of PEs >(routers or switches), millions of > > subscribers (number of sites), such as us > > > > > > > > Regards, > > > > > > > > > > > > -- > > > > Weijing Chen > > > > SBC Technology Resources > > > > 9505 Arboretum Blvd. > > > > Austin, TX 78759 > > > > 512 372 5710 > > > > > > > > > > > > Success is relative; the more success, the more relatives. -Anonymous From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 23 10:25:39 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00372 for ; Sat, 23 Nov 2002 10:25:38 -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 gANFRHi08131 for ; Sat, 23 Nov 2002 10:27:17 -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 gANFREE15745 for ; Sat, 23 Nov 2002 10:27:14 -0500 (EST) Message-ID: <3DDF9C51.8090309@research.att.com> Date: Sat, 23 Nov 2002 10:18:41 -0500 From: Chris Chase User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chen, Weijing" Cc: "'raszuk@cisco.com'" , "'PPVPN'" Subject: Re: Scalable and manageable network management and operation of M PLS/VPN References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mail-blue.research.att.com X-SMTP-MAIL-FROM: chase@research.att.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: H-135-207-30-102.research.att.com [135.207.30.102] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I don't normally follow this mailing list, but an associate pointed me to this thread. Sorry to jump in the middle. Inline. Chen, Weijing wrote: >Robert, > >Thanks for reply. However, I don't think that I mixed the VR-based and >2547bis-based VPN. Regardless it is a VR or a VRF, from management >standpoint, it is a router that we must management, e.g. route target id, >import id, export id, etc. in 2547bis case. Also for VRF and PE connection, >LSP labels in both end and sometime LSP labels in the middle. As long as >they are something that we must establish or assign, keep track of, and >troubleshoot, they require system resource and human resource. And those >resources come with cost. > >It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us >that it is not big deal since it is just a connection. 10 years from then, >we are still bearing the pain of provisioned connection-oriented (S)PVC. > > You are equating resources with cost and I assume you are saying that "pain" for VC service is in terms of costs. So what are you concluding here about PVC service? Has it been a pain for SBC? SBC has the largest U.S. FR market share of the ILECs (although much smaller than the IXCs), but approaching 1/3 billion (market analyst reports for 2001). Are you saying it is so much of a pain (in terms of costs) that SBC can not make money with it? I know that for AT&T and most other carriers PVC service is very profitable. I suspect the same is true for SBC - you may want to talk to your SBC associates that deliver those services. Certainly there are complexities and resource consumption with creating these network based VPN services, whether Layer 2 or Layer 3. But is that not the value add we as carriers bring to the equation? We provide the value add of these services for enterprise WAN service while making money because we do this at scale. Otherwise, you would not being seeing enterprise WANs migrating off private lines nor carriers reporting profitable business data services. Carriers have found how to scale the network based layer 2 services to tremendous sizes and be very efficient with running these services. We believe we can do (and are doing) the same with the nascent Layer 3 (IP) network based VPNs. >IP is great since it is connectionless. Telephone (POTS) is also great >since it is connection-oriented with fully functioned end-to-end subscriber >initiatied signaling. Either one will work for us, but not something in >between. Oh, well, I went too far. > > Layer 3 network based VPNs are connectionless IP from the enterprise WAN user view. Layer 2 network based VPN are connection oriented and proven from the enterprise WAN user view. When you say these services (by implication the "something in between") will not work for "us", who is "us" - the SBC point of view or the corporate enterprise WAN view? Chris Chase AT&T Labs Research > >-- >Weijing Chen >SBC Technology Resources >9505 Arboretum Blvd. >Austin, TX 78759 >512 372 5710 >wchen@tri.sbc.com > > >-----Original Message----- >From: Robert Raszuk [mailto:raszuk@cisco.com] >Sent: Friday, November 22, 2002 12:24 PM >To: Chen, Weijing >Cc: 'Yakov Rekhter'; 'PPVPN' >Subject: Re: Scalable and manageable network management and operation of >MPLS/VPN > > >Weijing, > >Your below email clearly indicates that you are mixing VR based L3VPNs >with the L3VPNs described in 2547bis architecture as non of your points >apply to the latter one. I must admit that they are very true for the >first type of L3VPNs though :-). > >Thx, >R. > > > >>Yakov, >> >> >> >> Sorry for late response. I didn't receive your reply for somewhat >> >> >reason. Yetik pointed this message to me and I found it from mailing list > > >>archive. >> >> >> >> >>Could you please elaborate on what exactly you are concerned with >> >> >respect to "scaleable manageability of MPLS/VPN"? > > >> >> In a nutshell, RFC 2547 doesn't scale because it breaks the rule that >> >> >all we need to do to manage a subscriber is manage the > > >>attributes on the port serving the subscriber. We have to dedicate >> >> >resources to the subscriber that go deeper into the network than just > > >>their port. Establishing, keeping track of, and troubleshooting these >> >> >resources on a per-subscriber basis will be difficult. > > >> >> Specifically, the resources we have to dedicate and manage are: >> >> #Virtual Routing Functions. Nearly one for each CE/PE interface. Each >> >> >one of these, from a management standpoint, is a > > >> router. Right now, large IP carriers manage hundreds to possibly a >> >> >few thousand routers. With IP VPNs, we'll be managing tens of > > >> thousand to possible hundreds of thousands of routers (VRF), a good 2 >> >> >orders of magnitude jump. > > >> #Connections between VRFs. Each VRF in a VPN has to have a connection >> >> >to every other VRF in the VPN. The more VRFs > > >> you have (100,000), the more connections you have between them. >> #Connections between PEs. Each PE in a VPN has to have a connection to >> >> >every other PE in the VPN. This connection > > >> maybe shared by multiple VRFs in the same PE pairs. However, >> >> >tracking of what connection to be shared or establishing new one if > > >> not shared is another daunting task. >> >> >> >> Each single item above is translated into $$, which including >> >> >recurring OPEX for operation and OSS system > > >>maintenance, and nonrecurring CAPEX for OSS system. >> >> >> >> >>Also, when you said "we operation group in service provider", do you >> >> >mean a specific service provider? > > >> Any service provider with hundreds of POPs (or COs), thousands of PEs >> >> >(routers or switches), millions of > > >>subscribers (number of sites), such as us >> >> >> >> Regards, >> >> >> >> >> >> -- >> >> Weijing Chen >> >> SBC Technology Resources >> >> 9505 Arboretum Blvd. >> >> Austin, TX 78759 >> >> 512 372 5710 >> >> >> >> >> >> >> >> > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 23 14:20:22 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03854 for ; Sat, 23 Nov 2002 14:20: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 gANJM4i00535 for ; Sat, 23 Nov 2002 14:22: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 gANJM2E12625 for ; Sat, 23 Nov 2002 14:22:02 -0500 (EST) Message-ID: <39469E08BD83D411A3D900204840EC55763457@VIE-MSGUSR-01> From: "Naidu, Venkata" To: "'Juha Heinanen'" , Thomas Nadeau Cc: "Chen, Weijing" , "'PPVPN'" Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Date: Sat, 23 Nov 2002 14:21:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: Venkata.Naidu@Marconi.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: -> > One of the advantages to MPLS L3VPN is that it -> > can be managed as part of your overall MPLS management strategy -> > given that it is an extension of MPLS. -> -> in case the provider has no other use for mpls than vpns, then the -> provider needs to start managing mpls in addtion to managing -> ip, which clearly is an additional burden. It is just a trade-off and amortized optimization providers has to make. If "managing MPLS/VPNs" overweighs "advantages provider gets by using MPLS/VPNs over IP/VPNs" then provider may prefer to go for IP/VPNs instead of MPLS/VPNs. If provider calculations show that "advantages" overweighs "managing" MPLS/VPNs then, MPLS/VPNs are far better. More over, providers consider "extensibility" along with "scalability". At this point in timeline, a provider might use MPLS only for VPNs. But what if in future provider gets more benefits from MPLS (other than just VPNs)?!? - there are already other benefits, ofcourse. -- Venkata. From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 23 15:03:50 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 PAA04221 for ; Sat, 23 Nov 2002 15:03:49 -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 gANK5ui06326 for ; Sat, 23 Nov 2002 15:05:56 -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 gANK5rE23380 for ; Sat, 23 Nov 2002 15:05:54 -0500 (EST) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632271B@trimail2> From: "Chen, Weijing" To: "'Fang, Luyuan, ALCNS'" , Thomas Nadeau Cc: PPVPN Subject: RE: Scalable and manageable network management and operation of M PLS/ VPN Date: Sat, 23 Nov 2002 14:05:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: wchen@tri.sbc.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: Luyuan, Thank for your clarification. Your explanation is certainly most helpful. I did read 2547bis a couple of times and also pressed the same questions to our suppliers in several meetings. However, I didn't get the information what I need and therefore took the worst case assumptions. Thomas, is it possible to add some explaining text as Luyuan outlined below in your PPVPN-MPLS-VPN MIB draft? Regards, -- Weijing Chen -----Original Message----- From: Fang, Luyuan, ALCNS [mailto:luyuanfang@att.com] Sent: Friday, November 22, 2002 8:14 PM To: Chen, Weijing; Thomas Nadeau Cc: PPVPN Subject: RE: Scalable and manageable network management and operation of MPLS/ VPN Weijing, Though your questions were for Tom, I'd like give some quick answers since we implement 2547 to provide the services to our customers. 1. > CE-PE access link: That is what I must do regardless what kind of services, VPN or not. We can check this off. That is right. 2. > CE-PE routing: What do I need to do to: establish, keep track of, and troubleshoot? You can run same protocols as for IP services, eBGP/OSPF/static/RIP, etc. For Enterprise VPN, you provision the VPN on PE only, VRF, RD, RT are all transparent to your customers. Yes, you need keep track of them in your systems. 3. > VRF: Besides RD assignment for this VPN, what about RT? How do I know what RT to use? Is a management system to assign, track RTs necessary? What else need, MP-BGP? VRF, RD and RT can all be assigned automatically by provisioning systems and tracked by provision/management systems. You can develop such system in house or use tools from vendors or third parties. Establish MP-BGP connectivity through RRs is also part of auto-provisioning process. 4. >Inner label (or VRF VPN label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? Labels are assigned by the routers automatically, not assigned by management system or provisioning system. Router A will tell router B to use label X to reach VPN ABC on router A, router B will tell router A to use label Y to reach VPN ABC on router B. 5. Outer label (or PE Tunnel label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? Same as above, all MPLS labels (VPNv4(v6), LDP, IPv4(v6), RSVP-TE, etc.) are auto-generated by the routers, not management systems. You might want to get a little more familiar with RFC2547 and other MPLS basics before criticizing. Luyuan Fang AT&T, IP backbone architecture -----Original Message----- From: Chen, Weijing [mailto:wchen@tri.sbc.com] Sent: Friday, November 22, 2002 3:46 PM To: 'Thomas Nadeau' Cc: 'PPVPN' Subject: RE: Scalable and manageable network management and operation of M PLS/ VPN Thomas, I guess I stirred up a hornet nest. To clam down the concern that I may advocate one VPN technology over another VPN technology, you can relax, I do not. As matter of fact, I have same concern over all the solutions. Now forgive my ignorance, please help me out on the following steps that I must do to establish, keep track of, and troubleshoot a VPN subscriber. If I am wrong, tell me what is right. CE-PE access link: That is what I must do regardless what kind of services, VPN or not. We can check this off. CE-PE routing: What do I need to do to: establish, keep track of, and troubleshoot? VRF: Besides RD assignment for this VPN, what about RT? How do I know what RT to use? Is a management system to assign, track RTs necessary? What else need, MP-BGP? Inner label (or VRF VPN label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? Outer label (or PE Tunnel label): Where does it come from? Is a management system to assign, track labels necessary? If so, single label, or each pair of labels (both ends)? What about intermediate label? So help me out here. -- Weijing Chen -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, November 22, 2002 1:50 PM To: Chen, Weijing Cc: 'PPVPN' Subject: Re: Scalable and manageable network management and operation of MPLS/ VPN At 12:07 PM 11/22/2002 -0600, Chen, Weijing wrote: Yakov, Sorry for late response. I didn't receive your reply for somewhat reason. Yetik pointed this message to me and I found it from mailing list archive. >>Could you please elaborate on what exactly you are concerned with respect to "scaleable manageability of MPLS/VPN"? In a nutshell, RFC 2547 doesn't scale because it breaks the rule that all we need to do to manage a subscriber is manage the attributes on the port serving the subscriber. We have to dedicate resources to the subscriber that go deeper into the network than just their port. Establishing, keeping track of, and troubleshooting these resources on a per-subscriber basis will be difficult. If you look at network management this way, then of course, any VPN technology you look at will not be scalable. However, the success of 2547 is indeed that a well designed management system can managed new customers by managing basically the VRF attributes. The typical addition of one (or hundreds) of customers should not affect the layout of your internal network or even the PE where those customers are attached if you did things correctly from the start. For example, many providers I know will size how many customers a particular PE can handle in their lab. Once they know this, they just provision customers in a single, easy way. Once they get near the limit, they order another PE. This also plays into the larger design of the core network of course, but I think that if your network is designed to slimly that it needs to be re-provisioned whenever any customer is added, that you should think about your design again. Specifically, the resources we have to dedicate and manage are: Virtual Routing Functions. Nearly one for each CE/PE interface. Each one of these, from a management standpoint, is a router. Right now, large IP carriers manage hundreds to possibly a few thousand routers. With IP VPNs, we'll be managing tens of thousand to possible hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. Perhaps you can explain to me why you think that the addition of one customer is going to affect all of the nodes in your network? I do not know of any deployments where providers re-provision their entire network based on the addition or re-provision of a 2547 customer. Connections between VRFs. Each VRF in a VPN has to have a connection to every other VRF in the VPN. The more VRFs you have (100,000), the more connections you have between them. You are thinking about this as if MPLS is a connection-oriented network, which it is not. The exception is if you are using RSVP-TE tunnels between PEs. However, a typical 2547 network uses LDP to establish sessions and distribute labels between PEs, not each VRF. In essence, you get paths between PEs over which you switch the VPN labels. I think that you are thinking of things as if there are actual connection-oriented paths between all VRFs in a VPN. Even if you use RSVP-TE tunnels between PEs, you can support many hundreds or thousands of VPNs between those PEs without needing a TE tunnel per VRF inter-connection. Thus only a small number of tunnels exist between PEs (as opposed to specific tunnels for each VPN or VRF-pair). Connections between PEs. Each PE in a VPN has to have a connection to every other PE in the VPN. This connection maybe shared by multiple VRFs in the same PE pairs. Yes, but why is this a problem? However, tracking of what connection to be shared or establishing new one if not shared is another daunting task. Just look at the loopbacks at one VRF and that gives you pointers to the other PEs. If you are interested in figuring out which physical links are shared by which VRFs on a particular PE, then just look at the LFIB based on the label used by the loopback. Each single item above is translated into $$, which including recurring OPEX for operation and OSS system maintenance, and nonrecurring CAPEX for OSS system. I am not sure of that based on my experience with my customers who have deployed 2547 networks. Certainly CAPEX is required for the equipment to begin with, but OPEX is actually quite low for 2547 as compared to many other VPN technologies, especially if your OSS and network deployment strategy is sound to begin with. I am not saying that management of any network and certain 2547-based is easy, but I totally disagree with the assertion that a 2547 network is not scalable based on how it must be managed. --Tom >>Also, when you said "we operation group in service provider", do you mean a specific service provider? Any service provider with hundreds of POPs (or COs), thousands of PEs (routers or switches), millions of subscribers (number of sites), such as us Regards, -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 From bounce-ppvpn-121951@lyris.nortelnetworks.com Sat Nov 23 16:40: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 QAA05463 for ; Sat, 23 Nov 2002 16:40: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 gANLgdi17940 for ; Sat, 23 Nov 2002 16:42: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 gANLgaE14222 for ; Sat, 23 Nov 2002 16:42:36 -0500 (EST) Message-ID: <004001c29339$39416080$1b07510c@6640bbc3r131> From: "Brijesh Kumar" To: "Chris Chase" , "Chen, Weijing" Cc: "'PPVPN'" References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> <3DDF9C51.8090309@research.att.com> Subject: Re: Scalable and manageable network management and operation of M PLS/VPN Date: Sat, 23 Nov 2002 13:42:27 -0800 Organization: NetVault Systems 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-SMTP-HELO: mtiwmhc12.worldnet.att.net X-SMTP-MAIL-FROM: brijesh@netvaultsystems.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mtiwmhc12.worldnet.att.net [204.127.131.116] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Chris, I guess, it was your conclusion that Yakov quoted as 2547 BGP/MPLS VPNs being "Certainly scalable and solvable.". I am not doubting that assertion, but I would like to know a bit more. I am wondering what is the scale, we are talking about here? 100s of VPNs, 1000s of VPNs per PE?. How many sites per VPNs? in tens or hundreds? There is yet another issue on which I would like to seek an answer from people like you who seem to have operational experience with configuring and managing Layer 3 VPNs in live networks. There are two aspects to VPN service scalability - the router engineering aspect, and the operational aspect. The first aspect does not look like an issue as the current generation of equipment is designed (or claimed) to facilitate carriers to provision several thousand Layer 3 VPNs (regardless of the VPN model used), if not tens of thousand VPNs like existing Layer 2 technology. I don't know if any one can guarantee that with their equipment, a carrier can support a few thousand VPNs with a few hundred sites per VPN, but most can do a few thousand VPNs with moderate number of sites (<20). I would like to know if any one is running Layer 3 VPNs that have sites in three digits. If I understood Wienjing's mail correctly, he seems to be pointing to the lack of operational scalability i.e., the lack of suitable VPN management and configuration tools that allow operators to manage a large number of layer 3 VPNs, taking a network wide view (as opposed to a point-by-point, PE oriented view). Do you believe that current generation of operation support software provided by your vendor X is good enough for operators to run large networks with thousands of VPNs with some VPNs having hundreds and possibly a few thousand of sites? Cheers, --brijesh ----- Original Message ----- From: "Chris Chase" To: "Chen, Weijing" Cc: ; "'PPVPN'" Sent: Saturday, November 23, 2002 7:18 AM Subject: Re: Scalable and manageable network management and operation of M PLS/VPN > I don't normally follow this mailing list, but an associate pointed me > to this thread. Sorry to jump in the middle. > > Inline. > > Chen, Weijing wrote: > > >Robert, > > > >Thanks for reply. However, I don't think that I mixed the VR-based and > >2547bis-based VPN. Regardless it is a VR or a VRF, from management > >standpoint, it is a router that we must management, e.g. route target id, > >import id, export id, etc. in 2547bis case. Also for VRF and PE connection, > >LSP labels in both end and sometime LSP labels in the middle. As long as > >they are something that we must establish or assign, keep track of, and > >troubleshoot, they require system resource and human resource. And those > >resources come with cost. > > > >It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us > >that it is not big deal since it is just a connection. 10 years from then, > >we are still bearing the pain of provisioned connection-oriented (S)PVC. > > > > > You are equating resources with cost and I assume you are saying that > "pain" for VC service is in terms of costs. So what are you concluding > here about PVC service? Has it been a pain for SBC? SBC has the > largest U.S. FR market share of the ILECs (although much smaller than > the IXCs), but approaching 1/3 billion (market analyst reports for > 2001). Are you saying it is so much of a pain (in terms of costs) that > SBC can not make money with it? I know that for AT&T and most other > carriers PVC service is very profitable. I suspect the same is true for > SBC - you may want to talk to your SBC associates that deliver those > services. > > Certainly there are complexities and resource consumption with creating > these network based VPN services, whether Layer 2 or Layer 3. But is > that not the value add we as carriers bring to the equation? We provide > the value add of these services for enterprise WAN service while making > money because we do this at scale. Otherwise, you would not being > seeing enterprise WANs migrating off private lines nor carriers > reporting profitable business data services. > > Carriers have found how to scale the network based layer 2 services to > tremendous sizes and be very efficient with running these services. We > believe we can do (and are doing) the same with the nascent Layer 3 (IP) > network based VPNs. > > >IP is great since it is connectionless. Telephone (POTS) is also great > >since it is connection-oriented with fully functioned end-to-end subscriber > >initiatied signaling. Either one will work for us, but not something in > >between. Oh, well, I went too far. > > > > > Layer 3 network based VPNs are connectionless IP from the enterprise WAN > user view. Layer 2 network based VPN are connection oriented and proven > from the enterprise WAN user view. When you say these services (by > implication the "something in between") will not work for "us", who is > "us" - the SBC point of view or the corporate enterprise WAN view? > > Chris Chase > AT&T Labs Research > > > > >-- > >Weijing Chen > >SBC Technology Resources > >9505 Arboretum Blvd. > >Austin, TX 78759 > >512 372 5710 > >wchen@tri.sbc.com > > > > > >-----Original Message----- > >From: Robert Raszuk [mailto:raszuk@cisco.com] > >Sent: Friday, November 22, 2002 12:24 PM > >To: Chen, Weijing > >Cc: 'Yakov Rekhter'; 'PPVPN' > >Subject: Re: Scalable and manageable network management and operation of > >MPLS/VPN > > > > > >Weijing, > > > >Your below email clearly indicates that you are mixing VR based L3VPNs > >with the L3VPNs described in 2547bis architecture as non of your points > >apply to the latter one. I must admit that they are very true for the > >first type of L3VPNs though :-). > > > >Thx, > >R. > > > > > > > >>Yakov, > >> > >> > >> > >> Sorry for late response. I didn't receive your reply for somewhat > >> > >> > >reason. Yetik pointed this message to me and I found it from mailing list > > > > > >>archive. > >> > >> > >> > >> >>Could you please elaborate on what exactly you are concerned with > >> > >> > >respect to "scaleable manageability of MPLS/VPN"? > > > > > >> > >> In a nutshell, RFC 2547 doesn't scale because it breaks the rule that > >> > >> > >all we need to do to manage a subscriber is manage the > > > > > >>attributes on the port serving the subscriber. We have to dedicate > >> > >> > >resources to the subscriber that go deeper into the network than just > > > > > >>their port. Establishing, keeping track of, and troubleshooting these > >> > >> > >resources on a per-subscriber basis will be difficult. > > > > > >> > >> Specifically, the resources we have to dedicate and manage are: > >> > >> #Virtual Routing Functions. Nearly one for each CE/PE interface. Each > >> > >> > >one of these, from a management standpoint, is a > > > > > >> router. Right now, large IP carriers manage hundreds to possibly a > >> > >> > >few thousand routers. With IP VPNs, we'll be managing tens of > > > > > >> thousand to possible hundreds of thousands of routers (VRF), a good 2 > >> > >> > >orders of magnitude jump. > > > > > >> #Connections between VRFs. Each VRF in a VPN has to have a connection > >> > >> > >to every other VRF in the VPN. The more VRFs > > > > > >> you have (100,000), the more connections you have between them. > >> #Connections between PEs. Each PE in a VPN has to have a connection to > >> > >> > >every other PE in the VPN. This connection > > > > > >> maybe shared by multiple VRFs in the same PE pairs. However, > >> > >> > >tracking of what connection to be shared or establishing new one if > > > > > >> not shared is another daunting task. > >> > >> > >> > >> Each single item above is translated into $$, which including > >> > >> > >recurring OPEX for operation and OSS system > > > > > >>maintenance, and nonrecurring CAPEX for OSS system. > >> > >> > >> > >> >>Also, when you said "we operation group in service provider", do you > >> > >> > >mean a specific service provider? > > > > > >> Any service provider with hundreds of POPs (or COs), thousands of PEs > >> > >> > >(routers or switches), millions of > > > > > >>subscribers (number of sites), such as us > >> > >> > >> > >> Regards, > >> > >> > >> > >> > >> > >> -- > >> > >> Weijing Chen > >> > >> SBC Technology Resources > >> > >> 9505 Arboretum Blvd. > >> > >> Austin, TX 78759 > >> > >> 512 372 5710 > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 24 00:23:36 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 AAA12305 for ; Sun, 24 Nov 2002 00:23:36 -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 gAO5OtL17781 for ; Sun, 24 Nov 2002 00:24:56 -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 gAO5OrK21544 for ; Sun, 24 Nov 2002 00:24:53 -0500 (EST) Message-ID: From: Sasha Vainshtein To: "'Ali Sajassi'" Cc: "Ppvpn (E-mail)" Subject: RE: Issues with draft-sajassi-mvpls-00.txt Date: Sun, 24 Nov 2002 07:23:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-SMTP-HELO: antivir2 X-SMTP-MAIL-FROM: Sasha@AXERRA.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [80.74.100.67] X-LYRIS-Message-Id: Ali, Thank you for a prompt response. Please see some questions/comments inline. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Saturday, November 23, 2002 1:10 AM > To: Sasha Vainshtein; Ali Sajassi (E-mail) > Cc: Ppvpn (E-mail) > Subject: Re: Issues with draft-sajassi-mvpls-00.txt > > > Sasha, > > I answered some of these questions earlier but let me > elaborate further ... > > At 11:58 PM 11/20/2002 +0200, Sasha Vainshtein wrote: > >Ali and all, > >I would like to re-state the issues I have raised at the > PPVPN WG Session > >today. > >All these issues deal with the unicast part of the proposal. > > > >1. Allocation of huge numbers of IP addresses (an IP address per AC). > > This looks highly problematic in inter-provider or even inter-AS > >situations > > (where use of private IP addresses is precluded). > > I think we agree that we don't have an issue with intra-AS > since a provider > has access to large address space based on RFC 1918. > Now if the majority of the traffic is intra-AS, then for the small > percentage of the end-points that require inter-AS > communications, one can > assign addresses from the public address space. > However, if one still wants to reduce the number of public IP > addresses, > then he can do one of the following: > a) Assign an IP address per VPLS instance instead of per AC > for that PE > (this is described in the draft) > B) Make use of VPLS hierarchy with Ethernet access network > (QinQ access network) I do not really understand how this helps. Can you please elaborate? > C) Use multi-segment Emulated LAN (one segment per AS) How will different segments be inter-connected? > > > >2. Involvement of core routers in the VPLS: with each new > AC, all the core > >routers > > have to learn routes to the associated IP address. > > Not quite. Contrary to MPLS labels, IP addresses do get > summarized in the > core and thus not every time you add an AC, a route update is > needed in the > P nodes. Because of this route summarization, the amount of > the states in > the core is relatively small. > I believe that ability of core routers to summarize routes depends on specific allocation of IP addresses per AC in the given PE. In other words, you should define some "allocation rules", e.g.: * define a subnet per VPLS per PE with substantial width to accomodate a number of prospecive ACs * subnets allocated for different PEs must be disjoint * PEs must advertise route(s) to the subnets allocated to it. > > I'd like to remind you that the PWE3 Charter (I am not > sure about the > >PPVPN one) > > explicitly states that PW functionality is limited to > PEs only and that > >PWs do not > > exert control over the underlying network. IMHO the > proposal violates > >these > > principles. > > Either requirements draft or the charter needs to be updated > to make them > consistent with each other. I think the main reason for > non-path-oriented > PW is the network scalability (avoid keeping per PW state in > the core) and > if keeping per PW state in core is not a requirement for a > path-oriented > scheme, then that scheme can be considered as an alternative option. > I agree that the Charter and the requirements document must correspond to each other. To the best of my knowledge, the new revision of the requirements draft (not posted yet) solves this problem by dropping the notion of path-oriented PWs. > > However, given that MPVLS doesn't use the traditionally > defined PW (as in > PWE3), I might use the term tunnel instead of PW in the next > rev. of the > document to avoid confusion. > I agree. > > >3. Forwarding in the egress PE. The draft states that it is is based > > on the destination IP address found in the packet. It > does not state > > whether aIP ddresses associated with an AC are > considered as IP addresses > > owned by the PE router terminating this AC,or not. If > they are not, > > the packets with the AC-associated destination IP > address should be > > forwarded as IP packets which seems wrong, because such > forwarding > > does not persume stripping of IP header, MAC address look-up etc. > > If they are, they would be treated based on the protocol number > > and according to the protocol-specific rules. In > particular,if the > >protocol > > is L2TPv3 (as mentionedin the presentation), the Session > ID lookup would > >be > > done and,if such a lookup fails (as it should since the > draft explicitly > >states > > that no sessions are established), the packet will be > discarded (or so I > >presume). > > As explained previously, it is the later case (IP addresses > associated with > the AC are owned by the PE) and as mentioned in the > presentation, it can > use either GRE or L2TPv3 encapsulation. In case of L2TPv3, it > only uses the > encapsulation part without session-id as I described in my > previous email. > Frankly given that L2TPv3 encap doesn't buy us anything over > GRE, I am > inclined to make it simple and narrowed it down to only GRE. > > Regards, > Ali > How will this interoperate with (potential) other uses of GRE in the same PE, e.g., for MPLS-in-GRE? > > > > > >------------------------------------------------------------- > --------------- > >-------- > >With best regards, > > Sasha Vainshtein > >email: sasha@axerra.com > >phone: +972-3-7659993 (office) > > +972-8-9254948 (home) > > +972-58-674833 (cellular) > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 24 01:10:24 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 BAA12668 for ; Sun, 24 Nov 2002 01:10:24 -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 gAO6CWL28654 for ; Sun, 24 Nov 2002 01:12:32 -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 gAO6CTK11585 for ; Sun, 24 Nov 2002 01:12:29 -0500 (EST) Reply-To: From: "Joel David" To: Subject: unsubscribe Date: Sun, 24 Nov 2002 14:13:44 +0800 Message-ID: <000101c29380$a61b7730$7600003b@QINTERACTION.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Authenticated-Sender: joeldavid@qinteraction.com X-Return-Path: JoelDavid@Qinteraction.com X-MDaemon-Deliver-To: PPVPN@nortelnetworks.com X-SMTP-HELO: Qmailgate X-SMTP-MAIL-FROM: JoelDavid@Qinteraction.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: qinteraction.com.141.87.203.in-addr.arpa [203.87.141.202] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit unsubscribe From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 24 01:11:26 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 BAA12707 for ; Sun, 24 Nov 2002 01:11:26 -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 gAO6DYL29913 for ; Sun, 24 Nov 2002 01:13: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 gAO6DVK12955 for ; Sun, 24 Nov 2002 01:13:31 -0500 (EST) Reply-To: From: "Joel David" To: Subject: help Date: Sun, 24 Nov 2002 14:14:32 +0800 Message-ID: <000201c29380$c1d9f960$7600003b@QINTERACTION.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Authenticated-Sender: joeldavid@qinteraction.com X-Return-Path: JoelDavid@Qinteraction.com X-MDaemon-Deliver-To: ppvpn@lyris.nortelnetworks.com X-SMTP-HELO: Qmailgate X-SMTP-MAIL-FROM: JoelDavid@Qinteraction.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: qinteraction.com.141.87.203.in-addr.arpa [203.87.141.202] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit help From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 24 17:54:31 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 RAA03904 for ; Sun, 24 Nov 2002 17:54: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 gAOMuDL04524 for ; Sun, 24 Nov 2002 17:56: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 gAOMu9K23009 for ; Sun, 24 Nov 2002 17:56:10 -0500 (EST) Reply-To: From: "Jonathan Jiang" To: "Brijesh Kumar" , "Chris Chase" , "Chen, Weijing" Cc: "'PPVPN'" Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Date: Sun, 24 Nov 2002 17:55:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <004001c29339$39416080$1b07510c@6640bbc3r131> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-SMTP-HELO: vice.smarts.com X-SMTP-MAIL-FROM: jon.jiang@smarts.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: vice.smarts.com [198.49.114.150] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Brijesh, Regarding tools for configuring and managing MPLS VPN, I am aware of at least three OSS products that aim to manage thousands of VPNs, each with hundreds of sites. While they are not in wide deployment yet, I believe it's just a matter of time. Thanks Jon -----Original Message----- From: Brijesh Kumar [mailto:brijesh@netvaultsystems.com] Sent: Saturday, November 23, 2002 4:42 PM To: Chris Chase; Chen, Weijing Cc: 'PPVPN' Subject: Re: Scalable and manageable network management and operation of M PLS/VPN Chris, I guess, it was your conclusion that Yakov quoted as 2547 BGP/MPLS VPNs being "Certainly scalable and solvable.". I am not doubting that assertion, but I would like to know a bit more. I am wondering what is the scale, we are talking about here? 100s of VPNs, 1000s of VPNs per PE?. How many sites per VPNs? in tens or hundreds? There is yet another issue on which I would like to seek an answer from people like you who seem to have operational experience with configuring and managing Layer 3 VPNs in live networks. There are two aspects to VPN service scalability - the router engineering aspect, and the operational aspect. The first aspect does not look like an issue as the current generation of equipment is designed (or claimed) to facilitate carriers to provision several thousand Layer 3 VPNs (regardless of the VPN model used), if not tens of thousand VPNs like existing Layer 2 technology. I don't know if any one can guarantee that with their equipment, a carrier can support a few thousand VPNs with a few hundred sites per VPN, but most can do a few thousand VPNs with moderate number of sites (<20). I would like to know if any one is running Layer 3 VPNs that have sites in three digits. If I understood Wienjing's mail correctly, he seems to be pointing to the lack of operational scalability i.e., the lack of suitable VPN management and configuration tools that allow operators to manage a large number of layer 3 VPNs, taking a network wide view (as opposed to a point-by-point, PE oriented view). Do you believe that current generation of operation support software provided by your vendor X is good enough for operators to run large networks with thousands of VPNs with some VPNs having hundreds and possibly a few thousand of sites? Cheers, --brijesh ----- Original Message ----- From: "Chris Chase" To: "Chen, Weijing" Cc: ; "'PPVPN'" Sent: Saturday, November 23, 2002 7:18 AM Subject: Re: Scalable and manageable network management and operation of M PLS/VPN > I don't normally follow this mailing list, but an associate pointed me > to this thread. Sorry to jump in the middle. > > Inline. > > Chen, Weijing wrote: > > >Robert, > > > >Thanks for reply. However, I don't think that I mixed the VR-based and > >2547bis-based VPN. Regardless it is a VR or a VRF, from management > >standpoint, it is a router that we must management, e.g. route target id, > >import id, export id, etc. in 2547bis case. Also for VRF and PE connection, > >LSP labels in both end and sometime LSP labels in the middle. As long as > >they are something that we must establish or assign, keep track of, and > >troubleshoot, they require system resource and human resource. And those > >resources come with cost. > > > >It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us > >that it is not big deal since it is just a connection. 10 years from then, > >we are still bearing the pain of provisioned connection-oriented (S)PVC. > > > > > You are equating resources with cost and I assume you are saying that > "pain" for VC service is in terms of costs. So what are you concluding > here about PVC service? Has it been a pain for SBC? SBC has the > largest U.S. FR market share of the ILECs (although much smaller than > the IXCs), but approaching 1/3 billion (market analyst reports for > 2001). Are you saying it is so much of a pain (in terms of costs) that > SBC can not make money with it? I know that for AT&T and most other > carriers PVC service is very profitable. I suspect the same is true for > SBC - you may want to talk to your SBC associates that deliver those > services. > > Certainly there are complexities and resource consumption with creating > these network based VPN services, whether Layer 2 or Layer 3. But is > that not the value add we as carriers bring to the equation? We provide > the value add of these services for enterprise WAN service while making > money because we do this at scale. Otherwise, you would not being > seeing enterprise WANs migrating off private lines nor carriers > reporting profitable business data services. > > Carriers have found how to scale the network based layer 2 services to > tremendous sizes and be very efficient with running these services. We > believe we can do (and are doing) the same with the nascent Layer 3 (IP) > network based VPNs. > > >IP is great since it is connectionless. Telephone (POTS) is also great > >since it is connection-oriented with fully functioned end-to-end subscriber > >initiatied signaling. Either one will work for us, but not something in > >between. Oh, well, I went too far. > > > > > Layer 3 network based VPNs are connectionless IP from the enterprise WAN > user view. Layer 2 network based VPN are connection oriented and proven > from the enterprise WAN user view. When you say these services (by > implication the "something in between") will not work for "us", who is > "us" - the SBC point of view or the corporate enterprise WAN view? > > Chris Chase > AT&T Labs Research > > > > >-- > >Weijing Chen > >SBC Technology Resources > >9505 Arboretum Blvd. > >Austin, TX 78759 > >512 372 5710 > >wchen@tri.sbc.com > > > > > >-----Original Message----- > >From: Robert Raszuk [mailto:raszuk@cisco.com] > >Sent: Friday, November 22, 2002 12:24 PM > >To: Chen, Weijing > >Cc: 'Yakov Rekhter'; 'PPVPN' > >Subject: Re: Scalable and manageable network management and operation of > >MPLS/VPN > > > > > >Weijing, > > > >Your below email clearly indicates that you are mixing VR based L3VPNs > >with the L3VPNs described in 2547bis architecture as non of your points > >apply to the latter one. I must admit that they are very true for the > >first type of L3VPNs though :-). > > > >Thx, > >R. > > > > > > > >>Yakov, > >> > >> > >> > >> Sorry for late response. I didn't receive your reply for somewhat > >> > >> > >reason. Yetik pointed this message to me and I found it from mailing list > > > > > >>archive. > >> > >> > >> > >> >>Could you please elaborate on what exactly you are concerned with > >> > >> > >respect to "scaleable manageability of MPLS/VPN"? > > > > > >> > >> In a nutshell, RFC 2547 doesn't scale because it breaks the rule that > >> > >> > >all we need to do to manage a subscriber is manage the > > > > > >>attributes on the port serving the subscriber. We have to dedicate > >> > >> > >resources to the subscriber that go deeper into the network than just > > > > > >>their port. Establishing, keeping track of, and troubleshooting these > >> > >> > >resources on a per-subscriber basis will be difficult. > > > > > >> > >> Specifically, the resources we have to dedicate and manage are: > >> > >> #Virtual Routing Functions. Nearly one for each CE/PE interface. Each > >> > >> > >one of these, from a management standpoint, is a > > > > > >> router. Right now, large IP carriers manage hundreds to possibly a > >> > >> > >few thousand routers. With IP VPNs, we'll be managing tens of > > > > > >> thousand to possible hundreds of thousands of routers (VRF), a good 2 > >> > >> > >orders of magnitude jump. > > > > > >> #Connections between VRFs. Each VRF in a VPN has to have a connection > >> > >> > >to every other VRF in the VPN. The more VRFs > > > > > >> you have (100,000), the more connections you have between them. > >> #Connections between PEs. Each PE in a VPN has to have a connection to > >> > >> > >every other PE in the VPN. This connection > > > > > >> maybe shared by multiple VRFs in the same PE pairs. However, > >> > >> > >tracking of what connection to be shared or establishing new one if > > > > > >> not shared is another daunting task. > >> > >> > >> > >> Each single item above is translated into $$, which including > >> > >> > >recurring OPEX for operation and OSS system > > > > > >>maintenance, and nonrecurring CAPEX for OSS system. > >> > >> > >> > >> >>Also, when you said "we operation group in service provider", do you > >> > >> > >mean a specific service provider? > > > > > >> Any service provider with hundreds of POPs (or COs), thousands of PEs > >> > >> > >(routers or switches), millions of > > > > > >>subscribers (number of sites), such as us > >> > >> > >> > >> Regards, > >> > >> > >> > >> > >> > >> -- > >> > >> Weijing Chen > >> > >> SBC Technology Resources > >> > >> 9505 Arboretum Blvd. > >> > >> Austin, TX 78759 > >> > >> 512 372 5710 > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 24 20:30:29 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 UAA06410 for ; Sun, 24 Nov 2002 20:30:28 -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 gAP1V6L20532 for ; Sun, 24 Nov 2002 20:31: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 gAP1V4K12258 for ; Sun, 24 Nov 2002 20:31:04 -0500 (EST) Message-ID: <3DE17D1F.7D970F08@alcatel.com> Date: Sun, 24 Nov 2002 17:30:07 -0800 From: Mudhafar Hassan-Ali Organization: Alcatel, USA X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jon.jiang@smarts.com CC: Brijesh Kumar , Chris Chase , "Chen, Weijing" , "'PPVPN'" Subject: Re: Scalable and manageable network management and operation of M PLS/VPN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: auds951.usa.alcatel.com X-SMTP-MAIL-FROM: mudhafar.hassan-ali@alcatel.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: auds951.usa.alcatel.com [143.209.238.80] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Jon, It would be useful if you could tell us who they are. Regards, Mudhafar Jonathan Jiang wrote: > Brijesh, > Regarding tools for configuring and managing MPLS VPN, I am aware of at > least three OSS products that aim to manage thousands of VPNs, each with > hundreds of sites. While they are not in wide deployment yet, I believe > it's just a matter of time. > > Thanks > Jon > > -----Original Message----- > From: Brijesh Kumar [mailto:brijesh@netvaultsystems.com] > Sent: Saturday, November 23, 2002 4:42 PM > To: Chris Chase; Chen, Weijing > Cc: 'PPVPN' > Subject: Re: Scalable and manageable network management and operation of > M PLS/VPN > > Chris, > > I guess, it was your conclusion that Yakov quoted as 2547 BGP/MPLS VPNs > being "Certainly scalable and solvable.". I am not doubting that assertion, > but I would like to know a bit more. I am wondering what is the scale, we > are talking about here? 100s of VPNs, 1000s of VPNs per PE?. How many sites > per VPNs? in tens or hundreds? > > There is yet another issue on which I would like to seek an answer from > people like you who seem to have operational experience with configuring and > managing Layer 3 VPNs in live networks. > > There are two aspects to VPN service scalability - the router engineering > aspect, and the operational aspect. The first aspect does not look like an > issue as the current generation of equipment is designed (or claimed) to > facilitate carriers to provision several thousand Layer 3 VPNs (regardless > of the VPN model used), if not tens of thousand VPNs like existing Layer 2 > technology. I don't know if any one can guarantee that with their equipment, > a carrier can support a few thousand VPNs with a few hundred sites per VPN, > but most can do a few thousand VPNs with moderate number of sites (<20). I > would like to know if any one is running Layer 3 VPNs that have sites in > three digits. > > If I understood Wienjing's mail correctly, he seems to be pointing to the > lack of operational scalability i.e., the lack of suitable VPN management > and configuration tools that allow operators to manage a large number of > layer 3 VPNs, taking a network wide view (as opposed to a point-by-point, PE > oriented view). Do you believe that current generation of operation support > software provided by your vendor X is good enough for operators to run > large networks with thousands of VPNs with some VPNs having hundreds and > possibly a few thousand of sites? > > Cheers, > > --brijesh > > ----- Original Message ----- > From: "Chris Chase" > To: "Chen, Weijing" > Cc: ; "'PPVPN'" > Sent: Saturday, November 23, 2002 7:18 AM > Subject: Re: Scalable and manageable network management and operation of M > PLS/VPN > > > I don't normally follow this mailing list, but an associate pointed me > > to this thread. Sorry to jump in the middle. > > > > Inline. > > > > Chen, Weijing wrote: > > > > >Robert, > > > > > >Thanks for reply. However, I don't think that I mixed the VR-based and > > >2547bis-based VPN. Regardless it is a VR or a VRF, from management > > >standpoint, it is a router that we must management, e.g. route target id, > > >import id, export id, etc. in 2547bis case. Also for VRF and PE > connection, > > >LSP labels in both end and sometime LSP labels in the middle. As long as > > >they are something that we must establish or assign, keep track of, and > > >troubleshoot, they require system resource and human resource. And those > > >resources come with cost. > > > > > >It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us > > >that it is not big deal since it is just a connection. 10 years from > then, > > >we are still bearing the pain of provisioned connection-oriented (S)PVC. > > > > > > > > You are equating resources with cost and I assume you are saying that > > "pain" for VC service is in terms of costs. So what are you concluding > > here about PVC service? Has it been a pain for SBC? SBC has the > > largest U.S. FR market share of the ILECs (although much smaller than > > the IXCs), but approaching 1/3 billion (market analyst reports for > > 2001). Are you saying it is so much of a pain (in terms of costs) that > > SBC can not make money with it? I know that for AT&T and most other > > carriers PVC service is very profitable. I suspect the same is true for > > SBC - you may want to talk to your SBC associates that deliver those > > services. > > > > Certainly there are complexities and resource consumption with creating > > these network based VPN services, whether Layer 2 or Layer 3. But is > > that not the value add we as carriers bring to the equation? We provide > > the value add of these services for enterprise WAN service while making > > money because we do this at scale. Otherwise, you would not being > > seeing enterprise WANs migrating off private lines nor carriers > > reporting profitable business data services. > > > > Carriers have found how to scale the network based layer 2 services to > > tremendous sizes and be very efficient with running these services. We > > believe we can do (and are doing) the same with the nascent Layer 3 (IP) > > network based VPNs. > > > > >IP is great since it is connectionless. Telephone (POTS) is also great > > >since it is connection-oriented with fully functioned end-to-end > subscriber > > >initiatied signaling. Either one will work for us, but not something in > > >between. Oh, well, I went too far. > > > > > > > > Layer 3 network based VPNs are connectionless IP from the enterprise WAN > > user view. Layer 2 network based VPN are connection oriented and proven > > from the enterprise WAN user view. When you say these services (by > > implication the "something in between") will not work for "us", who is > > "us" - the SBC point of view or the corporate enterprise WAN view? > > > > Chris Chase > > AT&T Labs Research > > > > > > > >-- > > >Weijing Chen > > >SBC Technology Resources > > >9505 Arboretum Blvd. > > >Austin, TX 78759 > > >512 372 5710 > > >wchen@tri.sbc.com > > > > > > > > >-----Original Message----- > > >From: Robert Raszuk [mailto:raszuk@cisco.com] > > >Sent: Friday, November 22, 2002 12:24 PM > > >To: Chen, Weijing > > >Cc: 'Yakov Rekhter'; 'PPVPN' > > >Subject: Re: Scalable and manageable network management and operation of > > >MPLS/VPN > > > > > > > > >Weijing, > > > > > >Your below email clearly indicates that you are mixing VR based L3VPNs > > >with the L3VPNs described in 2547bis architecture as non of your points > > >apply to the latter one. I must admit that they are very true for the > > >first type of L3VPNs though :-). > > > > > >Thx, > > >R. > > > > > > > > > > > >>Yakov, > > >> > > >> > > >> > > >> Sorry for late response. I didn't receive your reply for somewhat > > >> > > >> > > >reason. Yetik pointed this message to me and I found it from mailing list > > > > > > > > >>archive. > > >> > > >> > > >> > > >> >>Could you please elaborate on what exactly you are concerned with > > >> > > >> > > >respect to "scaleable manageability of MPLS/VPN"? > > > > > > > > >> > > >> In a nutshell, RFC 2547 doesn't scale because it breaks the rule > that > > >> > > >> > > >all we need to do to manage a subscriber is manage the > > > > > > > > >>attributes on the port serving the subscriber. We have to dedicate > > >> > > >> > > >resources to the subscriber that go deeper into the network than just > > > > > > > > >>their port. Establishing, keeping track of, and troubleshooting these > > >> > > >> > > >resources on a per-subscriber basis will be difficult. > > > > > > > > >> > > >> Specifically, the resources we have to dedicate and manage are: > > >> > > >> #Virtual Routing Functions. Nearly one for each CE/PE interface. > Each > > >> > > >> > > >one of these, from a management standpoint, is a > > > > > > > > >> router. Right now, large IP carriers manage hundreds to possibly a > > >> > > >> > > >few thousand routers. With IP VPNs, we'll be managing tens of > > > > > > > > >> thousand to possible hundreds of thousands of routers (VRF), a good > 2 > > >> > > >> > > >orders of magnitude jump. > > > > > > > > >> #Connections between VRFs. Each VRF in a VPN has to have a > connection > > >> > > >> > > >to every other VRF in the VPN. The more VRFs > > > > > > > > >> you have (100,000), the more connections you have between them. > > >> #Connections between PEs. Each PE in a VPN has to have a connection > to > > >> > > >> > > >every other PE in the VPN. This connection > > > > > > > > >> maybe shared by multiple VRFs in the same PE pairs. However, > > >> > > >> > > >tracking of what connection to be shared or establishing new one if > > > > > > > > >> not shared is another daunting task. > > >> > > >> > > >> > > >> Each single item above is translated into $$, which including > > >> > > >> > > >recurring OPEX for operation and OSS system > > > > > > > > >>maintenance, and nonrecurring CAPEX for OSS system. > > >> > > >> > > >> > > >> >>Also, when you said "we operation group in service provider", do > you > > >> > > >> > > >mean a specific service provider? > > > > > > > > >> Any service provider with hundreds of POPs (or COs), thousands of PEs > > >> > > >> > > >(routers or switches), millions of > > > > > > > > >>subscribers (number of sites), such as us > > >> > > >> > > >> > > >> Regards, > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> > > >> Weijing Chen > > >> > > >> SBC Technology Resources > > >> > > >> 9505 Arboretum Blvd. > > >> > > >> Austin, TX 78759 > > >> > > >> 512 372 5710 > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Sun Nov 24 22:27: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 WAA08284 for ; Sun, 24 Nov 2002 22:27: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 gAP3RlL07012 for ; Sun, 24 Nov 2002 22:27:47 -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 gAP3RjK23915 for ; Sun, 24 Nov 2002 22:27:45 -0500 (EST) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5ADA@trimail2> From: "Serbest, Yetik" To: "'Brijesh Kumar'" , Chris Chase , "Chen, Weijing" Cc: "'PPVPN'" Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Date: Sun, 24 Nov 2002 21:27:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: serbest@tri.sbc.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: Brijesh, Complaining about scalable management application is one thing, complaining about scalability of RFC2547 is another. Weijing is confusing these two. RFC2547 is more complex service than point-point connectivity services which most people are used to. It does not mean that it is not scalable. It means you have to do more work to provide that service. thanks, yetik -----Original Message----- From: Brijesh Kumar [mailto:brijesh@netvaultsystems.com] Sent: Saturday, November 23, 2002 3:42 PM To: Chris Chase; Chen, Weijing Cc: 'PPVPN' Subject: Re: Scalable and manageable network management and operation of M PLS/VPN Chris, I guess, it was your conclusion that Yakov quoted as 2547 BGP/MPLS VPNs being "Certainly scalable and solvable.". I am not doubting that assertion, but I would like to know a bit more. I am wondering what is the scale, we are talking about here? 100s of VPNs, 1000s of VPNs per PE?. How many sites per VPNs? in tens or hundreds? There is yet another issue on which I would like to seek an answer from people like you who seem to have operational experience with configuring and managing Layer 3 VPNs in live networks. There are two aspects to VPN service scalability - the router engineering aspect, and the operational aspect. The first aspect does not look like an issue as the current generation of equipment is designed (or claimed) to facilitate carriers to provision several thousand Layer 3 VPNs (regardless of the VPN model used), if not tens of thousand VPNs like existing Layer 2 technology. I don't know if any one can guarantee that with their equipment, a carrier can support a few thousand VPNs with a few hundred sites per VPN, but most can do a few thousand VPNs with moderate number of sites (<20). I would like to know if any one is running Layer 3 VPNs that have sites in three digits. If I understood Wienjing's mail correctly, he seems to be pointing to the lack of operational scalability i.e., the lack of suitable VPN management and configuration tools that allow operators to manage a large number of layer 3 VPNs, taking a network wide view (as opposed to a point-by-point, PE oriented view). Do you believe that current generation of operation support software provided by your vendor X is good enough for operators to run large networks with thousands of VPNs with some VPNs having hundreds and possibly a few thousand of sites? Cheers, --brijesh ----- Original Message ----- From: "Chris Chase" To: "Chen, Weijing" Cc: ; "'PPVPN'" Sent: Saturday, November 23, 2002 7:18 AM Subject: Re: Scalable and manageable network management and operation of M PLS/VPN > I don't normally follow this mailing list, but an associate pointed me > to this thread. Sorry to jump in the middle. > > Inline. > > Chen, Weijing wrote: > > >Robert, > > > >Thanks for reply. However, I don't think that I mixed the VR-based and > >2547bis-based VPN. Regardless it is a VR or a VRF, from management > >standpoint, it is a router that we must management, e.g. route target id, > >import id, export id, etc. in 2547bis case. Also for VRF and PE connection, > >LSP labels in both end and sometime LSP labels in the middle. As long as > >they are something that we must establish or assign, keep track of, and > >troubleshoot, they require system resource and human resource. And those > >resources come with cost. > > > >It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us > >that it is not big deal since it is just a connection. 10 years from then, > >we are still bearing the pain of provisioned connection-oriented (S)PVC. > > > > > You are equating resources with cost and I assume you are saying that > "pain" for VC service is in terms of costs. So what are you concluding > here about PVC service? Has it been a pain for SBC? SBC has the > largest U.S. FR market share of the ILECs (although much smaller than > the IXCs), but approaching 1/3 billion (market analyst reports for > 2001). Are you saying it is so much of a pain (in terms of costs) that > SBC can not make money with it? I know that for AT&T and most other > carriers PVC service is very profitable. I suspect the same is true for > SBC - you may want to talk to your SBC associates that deliver those > services. > > Certainly there are complexities and resource consumption with creating > these network based VPN services, whether Layer 2 or Layer 3. But is > that not the value add we as carriers bring to the equation? We provide > the value add of these services for enterprise WAN service while making > money because we do this at scale. Otherwise, you would not being > seeing enterprise WANs migrating off private lines nor carriers > reporting profitable business data services. > > Carriers have found how to scale the network based layer 2 services to > tremendous sizes and be very efficient with running these services. We > believe we can do (and are doing) the same with the nascent Layer 3 (IP) > network based VPNs. > > >IP is great since it is connectionless. Telephone (POTS) is also great > >since it is connection-oriented with fully functioned end-to-end subscriber > >initiatied signaling. Either one will work for us, but not something in > >between. Oh, well, I went too far. > > > > > Layer 3 network based VPNs are connectionless IP from the enterprise WAN > user view. Layer 2 network based VPN are connection oriented and proven > from the enterprise WAN user view. When you say these services (by > implication the "something in between") will not work for "us", who is > "us" - the SBC point of view or the corporate enterprise WAN view? > > Chris Chase > AT&T Labs Research > > > > >-- > >Weijing Chen > >SBC Technology Resources > >9505 Arboretum Blvd. > >Austin, TX 78759 > >512 372 5710 > >wchen@tri.sbc.com > > > > > >-----Original Message----- > >From: Robert Raszuk [mailto:raszuk@cisco.com] > >Sent: Friday, November 22, 2002 12:24 PM > >To: Chen, Weijing > >Cc: 'Yakov Rekhter'; 'PPVPN' > >Subject: Re: Scalable and manageable network management and operation of > >MPLS/VPN > > > > > >Weijing, > > > >Your below email clearly indicates that you are mixing VR based L3VPNs > >with the L3VPNs described in 2547bis architecture as non of your points > >apply to the latter one. I must admit that they are very true for the > >first type of L3VPNs though :-). > > > >Thx, > >R. > > > > > > > >>Yakov, > >> > >> > >> > >> Sorry for late response. I didn't receive your reply for somewhat > >> > >> > >reason. Yetik pointed this message to me and I found it from mailing list > > > > > >>archive. > >> > >> > >> > >> >>Could you please elaborate on what exactly you are concerned with > >> > >> > >respect to "scaleable manageability of MPLS/VPN"? > > > > > >> > >> In a nutshell, RFC 2547 doesn't scale because it breaks the rule that > >> > >> > >all we need to do to manage a subscriber is manage the > > > > > >>attributes on the port serving the subscriber. We have to dedicate > >> > >> > >resources to the subscriber that go deeper into the network than just > > > > > >>their port. Establishing, keeping track of, and troubleshooting these > >> > >> > >resources on a per-subscriber basis will be difficult. > > > > > >> > >> Specifically, the resources we have to dedicate and manage are: > >> > >> #Virtual Routing Functions. Nearly one for each CE/PE interface. Each > >> > >> > >one of these, from a management standpoint, is a > > > > > >> router. Right now, large IP carriers manage hundreds to possibly a > >> > >> > >few thousand routers. With IP VPNs, we'll be managing tens of > > > > > >> thousand to possible hundreds of thousands of routers (VRF), a good 2 > >> > >> > >orders of magnitude jump. > > > > > >> #Connections between VRFs. Each VRF in a VPN has to have a connection > >> > >> > >to every other VRF in the VPN. The more VRFs > > > > > >> you have (100,000), the more connections you have between them. > >> #Connections between PEs. Each PE in a VPN has to have a connection to > >> > >> > >every other PE in the VPN. This connection > > > > > >> maybe shared by multiple VRFs in the same PE pairs. However, > >> > >> > >tracking of what connection to be shared or establishing new one if > > > > > >> not shared is another daunting task. > >> > >> > >> > >> Each single item above is translated into $$, which including > >> > >> > >recurring OPEX for operation and OSS system > > > > > >>maintenance, and nonrecurring CAPEX for OSS system. > >> > >> > >> > >> >>Also, when you said "we operation group in service provider", do you > >> > >> > >mean a specific service provider? > > > > > >> Any service provider with hundreds of POPs (or COs), thousands of PEs > >> > >> > >(routers or switches), millions of > > > > > >>subscribers (number of sites), such as us > >> > >> > >> > >> Regards, > >> > >> > >> > >> > >> > >> -- > >> > >> Weijing Chen > >> > >> SBC Technology Resources > >> > >> 9505 Arboretum Blvd. > >> > >> Austin, TX 78759 > >> > >> 512 372 5710 > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 00:01: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 AAA09927 for ; Mon, 25 Nov 2002 00:01:52 -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 gAP53im22770 for ; Mon, 25 Nov 2002 00:03:45 -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 gAP53fA18204 for ; Mon, 25 Nov 2002 00:03:42 -0500 (EST) Reply-To: From: "Kanagavel Rajan P" To: Subject: unsubscribe Date: Mon, 25 Nov 2002 10:11:02 +0530 Message-Id: <001b01c2943c$dbc71080$2706140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000101c29380$a61b7730$7600003b@QINTERACTION.COM> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-SMTP-HELO: fsnt.future.futsoft.com X-SMTP-MAIL-FROM: kanagavelr@future.futsoft.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: [203.197.140.35] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 01:48:12 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11451 for ; Mon, 25 Nov 2002 01:48:12 -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 gAP6nlm06883 for ; Mon, 25 Nov 2002 01:49: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 gAP6niA25802 for ; Mon, 25 Nov 2002 01:49:45 -0500 (EST) Reply-To: From: "shyam" To: Subject: unsubscribe Date: Mon, 25 Nov 2002 12:18:58 +0530 Message-ID: <000601c2944e$bb75e1a0$4d04a8c0@itpl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000101c29380$a61b7730$7600003b@QINTERACTION.COM> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-OriginalArrivalTime: 25 Nov 2002 06:48:59.0324 (UTC) FILETIME=[BB762FC0:01C2944E] X-SMTP-HELO: localhost.localdomain X-SMTP-MAIL-FROM: shyamk@internet-trends.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: [203.129.237.108] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit unsubscribe From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 02:18: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 CAA21698 for ; Mon, 25 Nov 2002 02:17:59 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAP7Jmm18408 for ; Mon, 25 Nov 2002 02:19: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 gAP7JjA04896 for ; Mon, 25 Nov 2002 02:19:45 -0500 (EST) Message-Id: <200211250719.QAA27755@infer.nal.ecl.net> To: Cheng-Yin.Lee@alcatel.com cc: "IETF PPVPN list" , pwe3@ietf.org Subject: Re: Bridge or In-reply-to: Your message of "20 Nov 2002 14:47:37 EST." <3DDBE6D9.157B6E1D@alcatel.com> Date: Mon, 25 Nov 2002 16:19:05 +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: Cheng-Yin, 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. Please refer section 3. >3. Requirements for Ethernet Pseudo-Wire Emulation > An Ethernet PW emulates a single Ethernet link between exactly two > endpoints. The mechanisms described in this document are agnostic to > that which is beneath the "Pseudo Wire" level in Figure 2, concerning > itself only with the "Emulated Service" portion of the stack. > > The following reference model describes the termination point of each > end of the PW within the PE: > +-----------------------------------+ > | PE | > +---+ +-+ +-----+ +------+ +------+ +-+ > | | |P| | | |PW ter| | PSN | |P| > | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN > | | |y| | | |on | | | |y| > | C | +-+ +-----+ +------+ +------+ +-+ > | E | | | > | | +-+ +-----+ +------+ +------+ +-+ > | | |P| | | |PW ter| | PSN | |P| > | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN > | | |y| | | |on | | | |y| > +---+ +-+ +-----+ +------+ +------+ +-+ > | | > +-----------------------------------+ > ^ ^ > | | > A B > Figure 3: PW reference diagram > > The PW terminates at a logical port within the PE, defined at point A > in the above diagram. This port provides an Ethernet MAC service that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The above description clearly addresses that the PW provides Ethernet MAC service. > will deliver each Ethernet packet that is received at point A, > unaltered, to the point A in the corresponding PE at the other end of > the PW. > > 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 > functions may include stripping, overwriting or adding VLAN tags, > physical port multiplexing and demultiplexing, PW-PW bridging, L2 > encapsulation, shaping, policing, etc. > > 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. The above two paragraphs clearly defines that the NSP terminates Ethernet MAC frame between PE-CE. Therefore, form a viewpoint of protocol architecture, PW reference mode is interpreted as shown in the following figure. Bridge Bridge +-----------+ +-----------+ |\ /| |\ /| | \ Relay / | | \ Relay / | | \ / | | \ / | | \ / | | \ / | | \ / | | \ / | | V | | V | | MAC | E | | E | MAC | +--+--+--+--+ +--+--+--+--+ | | | | : Ethernet | | GRE/LSP tunnel | | Ethernet : +--+ :LAN segment | | | | LAN segment : +--+ |CE|==:============== +------------------+ =================:====|CE| +--+ : : +--+ : |<---------PW----------->| : Customer A A Customer Interface Interface The above figure shows a "Bridged LAN". Two big boxes are "Brides" and it is a special kind of 1982-style Bridge, because it supports only two ports, so MAC Relay Entity can be shrank. "MAC" and "Relay" in a box are "MAC Entity" and "MAC Relay Entity" respectively. "E" is an Entity that provides MAC service to the upper layer and the service is compatible with the MAC service defined in IEEE 802.3-2002. In summery, it seems to me, draft-ietf-pwe3-ethernet-encap-01.txt does not define any emulation technology, it specifies protocol for Ethernet MAC frame transport over GRE/LSP tunnel and the protocol Entity is refeed as "E" in the above figure. It does not emulate any LAN, because in IEEE 802 context, a LAN means a LAN segment or LAN segments interconnected with repeaters, and LAN segment means the medium connection, e.g., 1000BASE-T, between Medium Dependent Interfaces in a LAN. I think the PW is not intended to support medium dependent service such as 100Mbps-to-100Mbps LAN service, because this kind of service may not make sense. And I also don't understand that someone claimed that today's LAN consists of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore, IEEE 802.11 WG specifies "wireless LAN" :-) If it means an LAN segment, as I described in the above, such service does not make sense. And finally, I think, the following specification in draft-ietf-pwe3-ethernet-encap-01.txt is correct, but need not address in the document. >3.1.6. IEEE 802.3x Flow Control Interworking > In a standard Ethernet network, the flow control mechanism is > optional and typically configured between the two nodes on a point- > to-point link (e.g. between the CE and the PE). IEEE 802.3x PAUSE > frames MUST NOT be carried across the PW. See Appendix A for notes on > CE-PE flow control. This is because, Ethernet PAUSE frame must be terminated in the MAC Entity in the above figure. However, it is clearly addressed in IEEE 802.3-2002 and it is purely Ethernet dependent issue, thus it is out of scope of PWE3. In the PW section, there is no PAUSE frame, because E entity does not generate PAUSE frame because it is not Ethernet. So the draft need not specify anything for PAUSE frame. Thanks, Muneyoshi Suzuki From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 05:22:34 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 FAA23767 for ; Mon, 25 Nov 2002 05:22:34 -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 gAPANvm14724 for ; Mon, 25 Nov 2002 05:23: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 gAPANsA27181 for ; Mon, 25 Nov 2002 05:23:54 -0500 (EST) From: To: ppvpn@nortelnetworks.com Message-ID: Date: Mon, 25 Nov 2002 11:23:22 +0100 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: SUBSCRIBE ppvpn in message body X-Accept-Language: es Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-SMTP-HELO: tid.tid.es X-SMTP-MAIL-FROM: jpmg62@tid.es X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tidos.tid.es [193.145.240.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA23767 SUBSCRIBE ppvpn in message body ------------------------------------------------ Juan Pedro Montaner Giner jpmg62@tid.es TELEFÓNICA I+D www.tid.es Emilio Vargas #6 28043 Madrid (E) Tlfn: +34 913379238 ------------------------------------------------- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 08:22:28 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 IAA26812 for ; Mon, 25 Nov 2002 08:22:27 -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 gAPDO3m08815 for ; Mon, 25 Nov 2002 08:24:03 -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 gAPDO1A08825 for ; Mon, 25 Nov 2002 08:24:01 -0500 (EST) Message-Id: <200211251319.IAA26660@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-00.txt Date: Mon, 25 Nov 2002 08:19: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. 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-00.txt Pages : 21 Date : 2002-11-22 This document described 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-generic-reqts-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-generic-reqts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ppvpn-generic-reqts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-22112557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-generic-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-generic-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-22112557.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 08:56:44 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 IAA28064 for ; Mon, 25 Nov 2002 08:56: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 gAPDwom14527 for ; Mon, 25 Nov 2002 08:58:50 -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 gAPDwlA26890 for ; Mon, 25 Nov 2002 08:58:47 -0500 (EST) Date: Mon, 25 Nov 2002 08:56:34 -0500 From: Binh Pham Subject: unsubscribe To: ppvpn@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: pmesmtp01.wcom.com X-SMTP-MAIL-FROM: Binh.T.Pham@wcom.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pmesmtp01.wcom.com [199.249.20.1] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit unsubscribe From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 08:59:02 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 IAA28163 for ; Mon, 25 Nov 2002 08:59:01 -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 gAPE16m24426 for ; Mon, 25 Nov 2002 09:01: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 gAPE12A07393 for ; Mon, 25 Nov 2002 09:01:03 -0500 (EST) From: Willem.Naudts@alcatel.be To: "Ppvpn" Subject: unsubscribe Date: Mon, 25 Nov 2002 15:00:36 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 15:00:36, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 15:00:38, Serialize complete at 11/25/2002 15:00:38 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01C29493.691914F0" X-SMTP-HELO: mail.alcatel.be X-SMTP-MAIL-FROM: willem.naudts@alcatel.be X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: alc250.alcatel.be [195.207.101.250] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0088_01C29493.691914F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit unsubscribe ------=_NextPart_000_0088_01C29493.691914F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe
 
------=_NextPart_000_0088_01C29493.691914F0-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 14:25:22 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19199 for ; Mon, 25 Nov 2002 14:25:17 -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 gAPJRRm21037 for ; Mon, 25 Nov 2002 14:27: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 gAPJROA27899 for ; Mon, 25 Nov 2002 14:27:24 -0500 (EST) Message-ID: <3DE2796E.7060605@research.att.com> Date: Mon, 25 Nov 2002 14:26:38 -0500 From: Chris Chase User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brijesh Kumar Cc: "Chen, Weijing" , "'PPVPN'" Subject: Re: Scalable and manageable network management and operation of M PLS/VPN References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> <3DDF9C51.8090309@research.att.com> <004001c29339$39416080$1b07510c@6640bbc3r131> In-Reply-To: <004001c29339$39416080$1b07510c@6640bbc3r131> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mail-green.research.att.com X-SMTP-MAIL-FROM: chase@research.att.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: H-135-207-30-103.research.att.com [135.207.30.103] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit inline Brijesh Kumar wrote: >Chris, > >I guess, it was your conclusion that Yakov quoted as 2547 BGP/MPLS VPNs >being "Certainly scalable and solvable.". I am not doubting that assertion, >but I would like to know a bit more. I am wondering what is the scale, we >are talking about here? 100s of VPNs, 1000s of VPNs per PE?. How many sites >per VPNs? in tens or hundreds? > > I think he referred to a talk I gave last year. Okay, first to set the scope here, we are talking about network based MPLS VPNs for Corporate intranets, not VPNs for remote or home office access (which is yet another management problem - to plug those into the network based MPLS VPN). Eventually I would hope 1000s of VPNs. Sites in VPNs: dozens up to 10,000, but the distribution will fall off rapidly. There just aren't that many companies with more than a 1,000 sites compared to the many smaller enterprises with dozens or a couple hundred sites. VPNs of size thousands are large retail business enterprises (we have these. Of course there are significant numbers of these types of enterprises using private line or FR/ATM service for their corporate intranets, the largest of which I have seen is in the multiple 10,000s). Per PE requirements is not a simple question. The objective is that we efficiently use the PE capacity and obtain a reasonable per port cost. We do not yet know if we can get a PE that has multi-gigabit per slot access capacity and be able to terminate low speed (T1 or lower) access efficiently while running routing and QoS queues for every one of those ports. So there can be different PEs for different domains. For enterprise networks port speed distributions are very heavy weighted on the low speeds when you get into more than a few dozen sites. They could have hundreds of low speed sites (T1 or lower) and a handful of high speed sites (T3 and higher). So for a PE that terminates only high speed (>= T3), every high speed port is likely a unique VPN, but then you only have ports numbering in the hundreds for current potential PEs. For a low speed PE, you are likely to have multiple of connections per VPN, so while you may have potentially a couple thousand ports you will have an order magnitude less VPNs (or you might even have a smaller switching capacity PE with only hundreds of ports and then even lower VPN numbers). >There is yet another issue on which I would like to seek an answer from >people like you who seem to have operational experience with configuring and >managing Layer 3 VPNs in live networks. > >There are two aspects to VPN service scalability - the router engineering >aspect, and the operational aspect. The first aspect does not look like an >issue as the current generation of equipment is designed (or claimed) to >facilitate carriers to provision several thousand Layer 3 VPNs (regardless >of the VPN model used), if not tens of thousand VPNs like existing Layer 2 >technology. I don't know if any one can guarantee that with their equipment, >a carrier can support a few thousand VPNs with a few hundred sites per VPN, >but most can do a few thousand VPNs with moderate number of sites (<20). I >would like to know if any one is running Layer 3 VPNs that have sites in >three digits. > > We have a large number of VPNs in the three digits. We even have a VPN in the multi thousands. The PE router engineering is straightforward. Most of the provisioning problem is with the access circuits and termination. At our peak growth we were provisioning over 2,000 customers per week with the FR service. We do have that growth rate with VPNs yet, but we hope to get there. I don't really see a problem with that. The layer 3 VPNs are more of a challenge to get right because there are more orderable parameters (layer 1+2+3; policing, shaping, queuing) than we had with layer 2 or layer 1 services. The more paramters the more opportunities for problems, the more things to troubleshoot. But we have flow through provisioing today (no human hands from order entry to PE service creation). >If I understood Wienjing's mail correctly, he seems to be pointing to the >lack of operational scalability i.e., the lack of suitable VPN management >and configuration tools that allow operators to manage a large number of >layer 3 VPNs, taking a network wide view (as opposed to a point-by-point, PE >oriented view). Do you believe that current generation of operation support >software provided by your vendor X is good enough for operators to run >large networks with thousands of VPNs with some VPNs having hundreds and >possibly a few thousand of sites? > > Provisioning scale we have. I won't make a statement about existing tools in the market place. We tend to have our own rolled OSS's. We often use off the shelf management products, but more in a plugin (like a library, toolkit or module) than a complete system that does ordering, inventory, workflow, billing, alarming, ticket tracking, stats collection, reporting, etc. I have never believed in these wonder systems that claim to do it all. They never meet all our specific requirements. I do think there are operational challenges with Layer 3 versus Layer 2 VPNs for customer facing problems. With Layer 3 VPNs the carrier is participating in the customer's routing. For all the supposition of connectionless IP service having less "pain" [as implied in the original poster] it is more customer support intensive. And thus we need more sophisticated troubleshooting tools. Layer 1 and Layer 2 services have very clear demarcs. For example, internally, the network providing layer 2 service may be complex, e.g., running PNNI, but the customer service is fairly straightforward -- does LMI say the PVC is up? is my access circuit up? Is my bandwidth less than contracted? You don't get IP routing trouble tickets, but in layer 3 routing blurs between the provider and the customer. Actually, it is because managing and supporting Layer 3 IP services are more complex that providers hope to make a lot of money by managing that for the enterprise. Chris Chase AT&T Labs Research >Cheers, > >--brijesh > >----- Original Message ----- >From: "Chris Chase" >To: "Chen, Weijing" >Cc: ; "'PPVPN'" >Sent: Saturday, November 23, 2002 7:18 AM >Subject: Re: Scalable and manageable network management and operation of M >PLS/VPN > > > > >>I don't normally follow this mailing list, but an associate pointed me >>to this thread. Sorry to jump in the middle. >> >>Inline. >> >>Chen, Weijing wrote: >> >> >> >>>Robert, >>> >>>Thanks for reply. However, I don't think that I mixed the VR-based and >>>2547bis-based VPN. Regardless it is a VR or a VRF, from management >>>standpoint, it is a router that we must management, e.g. route target id, >>>import id, export id, etc. in 2547bis case. Also for VRF and PE >>> >>> >connection, > > >>>LSP labels in both end and sometime LSP labels in the middle. As long as >>>they are something that we must establish or assign, keep track of, and >>>troubleshoot, they require system resource and human resource. And those >>>resources come with cost. >>> >>>It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us >>>that it is not big deal since it is just a connection. 10 years from >>> >>> >then, > > >>>we are still bearing the pain of provisioned connection-oriented (S)PVC. >>> >>> >>> >>> >>You are equating resources with cost and I assume you are saying that >>"pain" for VC service is in terms of costs. So what are you concluding >>here about PVC service? Has it been a pain for SBC? SBC has the >>largest U.S. FR market share of the ILECs (although much smaller than >>the IXCs), but approaching 1/3 billion (market analyst reports for >>2001). Are you saying it is so much of a pain (in terms of costs) that >>SBC can not make money with it? I know that for AT&T and most other >>carriers PVC service is very profitable. I suspect the same is true for >>SBC - you may want to talk to your SBC associates that deliver those >>services. >> >>Certainly there are complexities and resource consumption with creating >>these network based VPN services, whether Layer 2 or Layer 3. But is >>that not the value add we as carriers bring to the equation? We provide >>the value add of these services for enterprise WAN service while making >>money because we do this at scale. Otherwise, you would not being >>seeing enterprise WANs migrating off private lines nor carriers >>reporting profitable business data services. >> >>Carriers have found how to scale the network based layer 2 services to >>tremendous sizes and be very efficient with running these services. We >>believe we can do (and are doing) the same with the nascent Layer 3 (IP) >>network based VPNs. >> >> >> >>>IP is great since it is connectionless. Telephone (POTS) is also great >>>since it is connection-oriented with fully functioned end-to-end >>> >>> >subscriber > > >>>initiatied signaling. Either one will work for us, but not something in >>>between. Oh, well, I went too far. >>> >>> >>> >>> >>Layer 3 network based VPNs are connectionless IP from the enterprise WAN >>user view. Layer 2 network based VPN are connection oriented and proven >>from the enterprise WAN user view. When you say these services (by >>implication the "something in between") will not work for "us", who is >>"us" - the SBC point of view or the corporate enterprise WAN view? >> >>Chris Chase >>AT&T Labs Research >> >> >> >>>-- >>>Weijing Chen >>>SBC Technology Resources >>>9505 Arboretum Blvd. >>>Austin, TX 78759 >>>512 372 5710 >>>wchen@tri.sbc.com >>> >>> >>>-----Original Message----- >>>From: Robert Raszuk [mailto:raszuk@cisco.com] >>>Sent: Friday, November 22, 2002 12:24 PM >>>To: Chen, Weijing >>>Cc: 'Yakov Rekhter'; 'PPVPN' >>>Subject: Re: Scalable and manageable network management and operation of >>>MPLS/VPN >>> >>> >>>Weijing, >>> >>>Your below email clearly indicates that you are mixing VR based L3VPNs >>>with the L3VPNs described in 2547bis architecture as non of your points >>>apply to the latter one. I must admit that they are very true for the >>>first type of L3VPNs though :-). >>> >>>Thx, >>>R. >>> >>> >>> >>> >>> >>>>Yakov, >>>> >>>> >>>> >>>> Sorry for late response. I didn't receive your reply for somewhat >>>> >>>> >>>> >>>> >>>reason. Yetik pointed this message to me and I found it from mailing list >>> >>> >>> >>> >>>>archive. >>>> >>>> >>>> >>>> >>Could you please elaborate on what exactly you are concerned with >>>> >>>> >>>> >>>> >>>respect to "scaleable manageability of MPLS/VPN"? >>> >>> >>> >>> >>>> In a nutshell, RFC 2547 doesn't scale because it breaks the rule >>>> >>>> >that > > >>>> >>>> >>>all we need to do to manage a subscriber is manage the >>> >>> >>> >>> >>>>attributes on the port serving the subscriber. We have to dedicate >>>> >>>> >>>> >>>> >>>resources to the subscriber that go deeper into the network than just >>> >>> >>> >>> >>>>their port. Establishing, keeping track of, and troubleshooting these >>>> >>>> >>>> >>>> >>>resources on a per-subscriber basis will be difficult. >>> >>> >>> >>> >>>> Specifically, the resources we have to dedicate and manage are: >>>> >>>> #Virtual Routing Functions. Nearly one for each CE/PE interface. >>>> >>>> >Each > > >>>> >>>> >>>one of these, from a management standpoint, is a >>> >>> >>> >>> >>>> router. Right now, large IP carriers manage hundreds to possibly a >>>> >>>> >>>> >>>> >>>few thousand routers. With IP VPNs, we'll be managing tens of >>> >>> >>> >>> >>>> thousand to possible hundreds of thousands of routers (VRF), a good >>>> >>>> >2 > > >>>> >>>> >>>orders of magnitude jump. >>> >>> >>> >>> >>>> #Connections between VRFs. Each VRF in a VPN has to have a >>>> >>>> >connection > > >>>> >>>> >>>to every other VRF in the VPN. The more VRFs >>> >>> >>> >>> >>>> you have (100,000), the more connections you have between them. >>>> #Connections between PEs. Each PE in a VPN has to have a connection >>>> >>>> >to > > >>>> >>>> >>>every other PE in the VPN. This connection >>> >>> >>> >>> >>>> maybe shared by multiple VRFs in the same PE pairs. However, >>>> >>>> >>>> >>>> >>>tracking of what connection to be shared or establishing new one if >>> >>> >>> >>> >>>> not shared is another daunting task. >>>> >>>> >>>> >>>> Each single item above is translated into $$, which including >>>> >>>> >>>> >>>> >>>recurring OPEX for operation and OSS system >>> >>> >>> >>> >>>>maintenance, and nonrecurring CAPEX for OSS system. >>>> >>>> >>>> >>>> >>Also, when you said "we operation group in service provider", do >>>> >>>> >you > > >>>> >>>> >>>mean a specific service provider? >>> >>> >>> >>> >>>> Any service provider with hundreds of POPs (or COs), thousands of PEs >>>> >>>> >>>> >>>> >>>(routers or switches), millions of >>> >>> >>> >>> >>>>subscribers (number of sites), such as us >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Weijing Chen >>>> >>>> SBC Technology Resources >>>> >>>> 9505 Arboretum Blvd. >>>> >>>> Austin, TX 78759 >>>> >>>> 512 372 5710 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 15:15: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 PAA22633 for ; Mon, 25 Nov 2002 15:15:08 -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 gAPKHDm07496 for ; Mon, 25 Nov 2002 15:17: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 gAPKHAA06595 for ; Mon, 25 Nov 2002 15:17:10 -0500 (EST) Message-Id: <5.2.0.9.2.20021125151410.02e04ab0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 25 Nov 2002 15:15:53 -0500 To: Juha Heinanen From: "Thomas D. Nadeau" Subject: RE: Scalable and manageable network management and operation of M PLS/VPN Cc: "Chen, Weijing" , "'PPVPN'" In-Reply-To: <15839.16131.907916.365447@lohi.eng.song.fi> References: <4.3.2.7.2.20021122150558.00b16f08@bucket.cisco.com> <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> <4.3.2.7.2.20021122150558.00b16f08@bucket.cisco.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: > > One of the advantages to MPLS L3VPN is that it > > can be managed as part of your overall MPLS management strategy > > given that it is an extension of MPLS. > >in case the provider has no other use for mpls than vpns, then the >provider needs to start managing mpls in addtion to managing ip, which >clearly is an additional burden. Yes, that is true and depending on your new management approach, your mileage may vary. However, the typical deployment cases I have seen are where MPLS VPN is added to an existing MPLS-enabled network, therefore adding the addition of MPLS VPN management to the existing OSS is evolutionary. --Tom From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 15:19: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 PAA22998 for ; Mon, 25 Nov 2002 15:19: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 gAPKLEm11655 for ; Mon, 25 Nov 2002 15:21:15 -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 gAPKLCA12151 for ; Mon, 25 Nov 2002 15:21:12 -0500 (EST) Message-Id: <5.2.0.9.2.20021125151731.02e00610@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 25 Nov 2002 15:20:12 -0500 To: "Chen, Weijing" From: "Thomas D. Nadeau" Subject: RE: Scalable and manageable network management and operation of M PLS/ VPN Cc: "'Fang, Luyuan, ALCNS'" , PPVPN In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D632271B@trimail2> 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: >Luyuan, > >Thank for your clarification. Your explanation is certainly most helpful. >I did read 2547bis a couple of times and also pressed the same questions to >our suppliers in several meetings. However, I didn't get the information >what I need and therefore took the worst case assumptions. > >Thomas, is it possible to add some explaining text as Luyuan outlined below >in your PPVPN-MPLS-VPN MIB draft? Clarifying text is always a welcome addition. If you would like to propose text to add based on Luyuan's answers, please post that to the list so that others can review it before we make any changes to the I-D. --Tom >Regards, > > >-- >Weijing Chen > >-----Original Message----- >From: Fang, Luyuan, ALCNS [mailto:luyuanfang@att.com] >Sent: Friday, November 22, 2002 8:14 PM >To: Chen, Weijing; Thomas Nadeau >Cc: PPVPN >Subject: RE: Scalable and manageable network management and operation of >MPLS/ VPN > >Weijing, >Though your questions were for Tom, I'd like give some quick answers since >we implement 2547 to provide the services to our customers. >1. > CE-PE access link: That is what I must do regardless what kind of >services, VPN or not. We can check this off. >That is right. >2. > CE-PE routing: What do I need to do to: establish, keep track of, and >troubleshoot? >You can run same protocols as for IP services, eBGP/OSPF/static/RIP, etc. >For Enterprise VPN, you provision the VPN on PE only, VRF, RD, RT are all >transparent to your customers. Yes, you need keep track of them in your >systems. >3. > VRF: Besides RD assignment for this VPN, what about RT? How do I know >what RT to use? Is a management system to assign, track RTs necessary? What >else need, MP-BGP? >VRF, RD and RT can all be assigned automatically by provisioning systems and >tracked by provision/management systems. You can develop such system in >house or use tools from vendors or third parties. Establish MP-BGP >connectivity through RRs is also part of auto-provisioning process. >4. >Inner label (or VRF VPN label): Where does it come from? Is a management >system to assign, track labels necessary? If so, single label, or each pair >of labels (both ends)? What about intermediate label? >Labels are assigned by the routers automatically, not assigned by management >system or provisioning system. Router A will tell router B to use label X to >reach VPN ABC on router A, router B will tell router A to use label Y to >reach VPN ABC on router B. >5. Outer label (or PE Tunnel label): Where does it come from? Is a >management system to assign, track labels necessary? If so, single label, or >each pair of labels (both ends)? What about intermediate label? >Same as above, all MPLS labels (VPNv4(v6), LDP, IPv4(v6), RSVP-TE, etc.) are >auto-generated by the routers, not management systems. >You might want to get a little more familiar with RFC2547 and other MPLS >basics before criticizing. > >Luyuan Fang >AT&T, IP backbone architecture > > -----Original Message----- > From: Chen, Weijing [mailto:wchen@tri.sbc.com] > Sent: Friday, November 22, 2002 3:46 PM > To: 'Thomas Nadeau' > Cc: 'PPVPN' > Subject: RE: Scalable and manageable network management and >operation of M PLS/ VPN > > Thomas, > I guess I stirred up a hornet nest. To clam down the concern that I >may advocate one VPN technology over another VPN technology, you can relax, >I do not. As matter of fact, I have same concern over all the solutions. > Now forgive my ignorance, please help me out on the following steps >that I must do to establish, keep track of, and troubleshoot a VPN >subscriber. If I am wrong, tell me what is right. > CE-PE access link: That is what I must do regardless what >kind of services, VPN or not. We can check this off. > CE-PE routing: What do I need to do to: establish, keep >track of, and troubleshoot? > VRF: Besides RD assignment for this VPN, what about RT? How >do I know what RT to use? Is a management system to assign, track RTs >necessary? What else need, MP-BGP? > Inner label (or VRF VPN label): Where does it come from? Is >a management system to assign, track labels necessary? If so, single label, >or each pair of labels (both ends)? What about intermediate label? > Outer label (or PE Tunnel label): Where does it come from? >Is a management system to assign, track labels necessary? If so, single >label, or each pair of labels (both ends)? What about intermediate label? >So help me out here. > -- > Weijing Chen > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, November 22, 2002 1:50 PM > To: Chen, Weijing > Cc: 'PPVPN' > Subject: Re: Scalable and manageable network management and >operation of MPLS/ VPN > At 12:07 PM 11/22/2002 -0600, Chen, Weijing wrote: > > > Yakov, > > > > Sorry for late response. I didn't receive your reply for somewhat >reason. Yetik pointed this message to me and I found it from mailing list >archive. > > > > >>Could you please elaborate on what exactly you are concerned with >respect to "scaleable manageability of MPLS/VPN"? > > > > In a nutshell, RFC 2547 doesn't scale because it breaks the rule >that all we need to do to manage a subscriber is manage the attributes on >the port serving the subscriber. We have to dedicate resources to the >subscriber that go deeper into the network than just their port. >Establishing, keeping track of, and troubleshooting these resources on a >per-subscriber basis will be difficult. > > If you look at network management this way, then of course, any VPN >technology you > look at will not be scalable. However, the success of 2547 is indeed >that a well designed > management system can managed new customers by managing basically >the VRF attributes. > The typical addition of one (or hundreds) of customers should not >affect the layout of your internal > network or even the PE where those customers are attached if you did >things correctly > from the start. For example, many providers I know will size how >many customers a > particular PE can handle in their lab. Once they know this, they >just provision > customers in a single, easy way. Once they get near the limit, they >order another > PE. This also plays into the larger design of the core network of >course, but I think > that if your network is designed to slimly that it needs to be >re-provisioned whenever > any customer is added, that you should think about your design >again. > > > Specifically, the resources we have to dedicate and manage are: > Virtual Routing Functions. Nearly one for each CE/PE >interface. Each one of these, from a management standpoint, is a router. >Right now, large IP carriers manage hundreds to possibly a few thousand >routers. With IP VPNs, we'll be managing tens of thousand to possible >hundreds of thousands of routers (VRF), a good 2 orders of magnitude jump. >Perhaps you can explain to me why you think that the addition of one >customer is going to >affect all of the nodes in your network? I do not know of any deployments >where providers >re-provision their entire network based on the addition or re-provision of a >2547 customer. > Connections between VRFs. Each VRF in a VPN has to have a >connection to every other VRF in the VPN. The more VRFs you have (100,000), >the more connections you have between them. >You are thinking about this as if MPLS is a connection-oriented network, >which it >is not. The exception is if you are using RSVP-TE tunnels between PEs. >However, >a typical 2547 network uses LDP to establish sessions and distribute >labels between PEs, not each VRF. In essence, you get paths between PEs >over which you switch the VPN labels. I think that you are thinking of >things >as if there are actual connection-oriented paths between all VRFs in a VPN. >Even if you use RSVP-TE tunnels between PEs, you can >support many hundreds or thousands of VPNs between those PEs without needing > >a TE tunnel per VRF inter-connection. Thus only a small number of tunnels >exist >between PEs (as opposed to specific tunnels for each VPN or VRF-pair). > Connections between PEs. Each PE in a VPN has to have a >connection to every other PE in the VPN. This connection maybe shared by >multiple VRFs in the same PE pairs. >Yes, but why is this a problem? > However, tracking of what connection to be shared or >establishing new one if not shared is another daunting task. >Just look at the loopbacks at one VRF and that gives you pointers to the >other PEs. >If you are interested in figuring out which physical links are shared by >which VRFs on >a particular PE, then just look at the LFIB based on the label used by the >loopback. > > > Each single item above is translated into $$, which including >recurring OPEX for operation and OSS system maintenance, and nonrecurring >CAPEX for OSS system. > > I am not sure of that based on my experience with my customers who >have > deployed 2547 networks. Certainly CAPEX is required for the >equipment to begin > with, but OPEX is actually quite low for 2547 as compared to many >other VPN > technologies, especially if your OSS and network deployment strategy >is sound > to begin with. I am not saying that management of any network and >certain 2547-based > is easy, but I totally disagree with the assertion that a 2547 >network is not scalable > based on how it must be managed. > > --Tom > > > > >>Also, when you said "we operation group in service provider", do >you mean a specific service provider? > > Any service provider with hundreds of POPs (or COs), thousands of >PEs (routers or switches), millions of subscribers (number of sites), such >as us > > > > Regards, > > > > > > -- > > Weijing Chen > > SBC Technology Resources > > 9505 Arboretum Blvd. > > Austin, TX 78759 > > 512 372 5710 > > > Success is relative; the more success, the more relatives. -Anonymous From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 15:24:44 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 PAA23538 for ; Mon, 25 Nov 2002 15:24: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 gAPKQrm15777 for ; Mon, 25 Nov 2002 15:26:53 -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 gAPKQnA18207 for ; Mon, 25 Nov 2002 15:26:49 -0500 (EST) Message-Id: <5.2.0.9.2.20021125152159.02e03740@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 25 Nov 2002 15:26:04 -0500 To: "Brijesh Kumar" From: "Thomas D. Nadeau" Subject: Re: Scalable and manageable network management and operation of M PLS/VPN Cc: "'PPVPN'" In-Reply-To: <004001c29339$39416080$1b07510c@6640bbc3r131> References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> <3DDF9C51.8090309@research.att.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: At 01:42 PM 11/23/2002 -0800, Brijesh Kumar wrote: >Chris, > >I guess, it was your conclusion that Yakov quoted as 2547 BGP/MPLS VPNs >being "Certainly scalable and solvable.". I am not doubting that assertion, >but I would like to know a bit more. I am wondering what is the scale, we >are talking about here? 100s of VPNs, 1000s of VPNs per PE?. How many sites >per VPNs? in tens or hundreds? > >There is yet another issue on which I would like to seek an answer from >people like you who seem to have operational experience with configuring and >managing Layer 3 VPNs in live networks. > >There are two aspects to VPN service scalability - the router engineering >aspect, and the operational aspect. The first aspect does not look like an >issue as the current generation of equipment is designed (or claimed) to >facilitate carriers to provision several thousand Layer 3 VPNs (regardless >of the VPN model used), if not tens of thousand VPNs like existing Layer 2 >technology. I don't know if any one can guarantee that with their equipment, >a carrier can support a few thousand VPNs with a few hundred sites per VPN, >but most can do a few thousand VPNs with moderate number of sites (<20). I >would like to know if any one is running Layer 3 VPNs that have sites in >three digits. > >If I understood Wienjing's mail correctly, he seems to be pointing to the >lack of operational scalability i.e., the lack of suitable VPN management >and configuration tools that allow operators to manage a large number of >layer 3 VPNs, taking a network wide view (as opposed to a point-by-point, PE >oriented view). Do you believe that current generation of operation support >software provided by your vendor X is good enough for operators to run >large networks with thousands of VPNs with some VPNs having hundreds and >possibly a few thousand of sites? As with any technology, there are lots of different approaches to how to manage that technology that vary widely from totally off-the- shelf purchased software, to solutions developed totally in-house. In terms of applications available to manage MPLS/VPN, many commercial 3rd party applications exist to many some or all aspects of MPLS/VPN networks, as well as those produced by vendors specifically for their products. In many cases, the applications are built upon those that can manage other MPLS applications, given that it makes them both more modular, and more suitable for different operating environments. I will leave it to the operators to speak to the effectiveness of their particular approach, but I can say that numerous (very scalable) approaches to management do exist and are in use today. --Tom >Cheers, > >--brijesh > >----- Original Message ----- >From: "Chris Chase" >To: "Chen, Weijing" >Cc: ; "'PPVPN'" >Sent: Saturday, November 23, 2002 7:18 AM >Subject: Re: Scalable and manageable network management and operation of M >PLS/VPN > > > > I don't normally follow this mailing list, but an associate pointed me > > to this thread. Sorry to jump in the middle. > > > > Inline. > > > > Chen, Weijing wrote: > > > > >Robert, > > > > > >Thanks for reply. However, I don't think that I mixed the VR-based and > > >2547bis-based VPN. Regardless it is a VR or a VRF, from management > > >standpoint, it is a router that we must management, e.g. route target id, > > >import id, export id, etc. in 2547bis case. Also for VRF and PE >connection, > > >LSP labels in both end and sometime LSP labels in the middle. As long as > > >they are something that we must establish or assign, keep track of, and > > >troubleshoot, they require system resource and human resource. And those > > >resources come with cost. > > > > > >It reminds me of ATM (S)PVC. Back then, all the (S)PVC people assure us > > >that it is not big deal since it is just a connection. 10 years from >then, > > >we are still bearing the pain of provisioned connection-oriented (S)PVC. > > > > > > > > You are equating resources with cost and I assume you are saying that > > "pain" for VC service is in terms of costs. So what are you concluding > > here about PVC service? Has it been a pain for SBC? SBC has the > > largest U.S. FR market share of the ILECs (although much smaller than > > the IXCs), but approaching 1/3 billion (market analyst reports for > > 2001). Are you saying it is so much of a pain (in terms of costs) that > > SBC can not make money with it? I know that for AT&T and most other > > carriers PVC service is very profitable. I suspect the same is true for > > SBC - you may want to talk to your SBC associates that deliver those > > services. > > > > Certainly there are complexities and resource consumption with creating > > these network based VPN services, whether Layer 2 or Layer 3. But is > > that not the value add we as carriers bring to the equation? We provide > > the value add of these services for enterprise WAN service while making > > money because we do this at scale. Otherwise, you would not being > > seeing enterprise WANs migrating off private lines nor carriers > > reporting profitable business data services. > > > > Carriers have found how to scale the network based layer 2 services to > > tremendous sizes and be very efficient with running these services. We > > believe we can do (and are doing) the same with the nascent Layer 3 (IP) > > network based VPNs. > > > > >IP is great since it is connectionless. Telephone (POTS) is also great > > >since it is connection-oriented with fully functioned end-to-end >subscriber > > >initiatied signaling. Either one will work for us, but not something in > > >between. Oh, well, I went too far. > > > > > > > > Layer 3 network based VPNs are connectionless IP from the enterprise WAN > > user view. Layer 2 network based VPN are connection oriented and proven > > from the enterprise WAN user view. When you say these services (by > > implication the "something in between") will not work for "us", who is > > "us" - the SBC point of view or the corporate enterprise WAN view? > > > > Chris Chase > > AT&T Labs Research > > > > > > > >-- > > >Weijing Chen > > >SBC Technology Resources > > >9505 Arboretum Blvd. > > >Austin, TX 78759 > > >512 372 5710 > > >wchen@tri.sbc.com > > > > > > > > >-----Original Message----- > > >From: Robert Raszuk [mailto:raszuk@cisco.com] > > >Sent: Friday, November 22, 2002 12:24 PM > > >To: Chen, Weijing > > >Cc: 'Yakov Rekhter'; 'PPVPN' > > >Subject: Re: Scalable and manageable network management and operation of > > >MPLS/VPN > > > > > > > > >Weijing, > > > > > >Your below email clearly indicates that you are mixing VR based L3VPNs > > >with the L3VPNs described in 2547bis architecture as non of your points > > >apply to the latter one. I must admit that they are very true for the > > >first type of L3VPNs though :-). > > > > > >Thx, > > >R. > > > > > > > > > > > >>Yakov, > > >> > > >> > > >> > > >> Sorry for late response. I didn't receive your reply for somewhat > > >> > > >> > > >reason. Yetik pointed this message to me and I found it from mailing list > > > > > > > > >>archive. > > >> > > >> > > >> > > >> >>Could you please elaborate on what exactly you are concerned with > > >> > > >> > > >respect to "scaleable manageability of MPLS/VPN"? > > > > > > > > >> > > >> In a nutshell, RFC 2547 doesn't scale because it breaks the rule >that > > >> > > >> > > >all we need to do to manage a subscriber is manage the > > > > > > > > >>attributes on the port serving the subscriber. We have to dedicate > > >> > > >> > > >resources to the subscriber that go deeper into the network than just > > > > > > > > >>their port. Establishing, keeping track of, and troubleshooting these > > >> > > >> > > >resources on a per-subscriber basis will be difficult. > > > > > > > > >> > > >> Specifically, the resources we have to dedicate and manage are: > > >> > > >> #Virtual Routing Functions. Nearly one for each CE/PE interface. >Each > > >> > > >> > > >one of these, from a management standpoint, is a > > > > > > > > >> router. Right now, large IP carriers manage hundreds to possibly a > > >> > > >> > > >few thousand routers. With IP VPNs, we'll be managing tens of > > > > > > > > >> thousand to possible hundreds of thousands of routers (VRF), a good >2 > > >> > > >> > > >orders of magnitude jump. > > > > > > > > >> #Connections between VRFs. Each VRF in a VPN has to have a >connection > > >> > > >> > > >to every other VRF in the VPN. The more VRFs > > > > > > > > >> you have (100,000), the more connections you have between them. > > >> #Connections between PEs. Each PE in a VPN has to have a connection >to > > >> > > >> > > >every other PE in the VPN. This connection > > > > > > > > >> maybe shared by multiple VRFs in the same PE pairs. However, > > >> > > >> > > >tracking of what connection to be shared or establishing new one if > > > > > > > > >> not shared is another daunting task. > > >> > > >> > > >> > > >> Each single item above is translated into $$, which including > > >> > > >> > > >recurring OPEX for operation and OSS system > > > > > > > > >>maintenance, and nonrecurring CAPEX for OSS system. > > >> > > >> > > >> > > >> >>Also, when you said "we operation group in service provider", do >you > > >> > > >> > > >mean a specific service provider? > > > > > > > > >> Any service provider with hundreds of POPs (or COs), thousands of PEs > > >> > > >> > > >(routers or switches), millions of > > > > > > > > >>subscribers (number of sites), such as us > > >> > > >> > > >> > > >> Regards, > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> > > >> Weijing Chen > > >> > > >> SBC Technology Resources > > >> > > >> 9505 Arboretum Blvd. > > >> > > >> Austin, TX 78759 > > >> > > >> 512 372 5710 > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > Success is relative; the more success, the more relatives. -Anonymous From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 16:42: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 QAA27181 for ; Mon, 25 Nov 2002 16:42:23 -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 gAPLiPm13504 for ; Mon, 25 Nov 2002 16:44:26 -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 gAPLiNA16066 for ; Mon, 25 Nov 2002 16:44:23 -0500 (EST) Message-ID: <015001c294cb$c66b7c00$3808510c@6640bbc3r131> From: "Brijesh Kumar" To: "Thomas D. Nadeau" Cc: "'PPVPN'" References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2><3DDF9C51.8090309@research.att.com> <5.2.0.9.2.20021125152159.02e03740@bucket.cisco.com> Subject: Re: Scalable and manageable network management and operation of M PLS/VPN Date: Mon, 25 Nov 2002 13:44:02 -0800 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.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-SMTP-HELO: mtiwmhc11.worldnet.att.net X-SMTP-MAIL-FROM: brijesh.kumar@att.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mtiwmhc11.worldnet.att.net [204.127.131.115] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Thomas wrote: > In terms of applications available to manage MPLS/VPN, many commercial > 3rd party applications exist to many some or all aspects of MPLS/VPN text deleted > butI can say that > numerous (very scalable) approaches to management do exist and are in use > today. Thomas: Can you please be more specific which particular third party OSS tools you are referring to, and what specific features they have for scalable Layer 3/ (Or MPLS/VPN) deployements? I think someone else also asked this, but didn't get any response. Cheers, --brijesh From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 18:05: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 SAA00036 for ; Mon, 25 Nov 2002 18:05: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 gAPN7pH11640 for ; Mon, 25 Nov 2002 18:07: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 gAPN7nA14585 for ; Mon, 25 Nov 2002 18:07:49 -0500 (EST) Message-Id: <5.2.0.9.2.20021125180523.0c3ed9f0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 25 Nov 2002 18:06:50 -0500 To: "Brijesh Kumar" From: "Thomas D. Nadeau" Subject: Re: Scalable and manageable network management and operation of M PLS/VPN Cc: "'PPVPN'" In-Reply-To: <015001c294cb$c66b7c00$3808510c@6640bbc3r131> References: <905A1C4ABF353F4C8CC16FA9F53DD0D6322717@trimail2> <3DDF9C51.8090309@research.att.com> <5.2.0.9.2.20021125152159.02e03740@bucket.cisco.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: >Thomas wrote: > > > > In terms of applications available to manage MPLS/VPN, many commercial > > 3rd party applications exist to many some or all aspects of MPLS/VPN > text deleted > > butI can say that > > numerous (very scalable) approaches to management do exist and are in use > > today. > >Thomas: > >Can you please be more specific which particular third party OSS tools you >are referring to, and what specific features they have for scalable Layer 3/ >(Or MPLS/VPN) deployements? I think someone else also asked this, but >didn't get any response. This mailing list is not appropriate for vendor-specific products. I suggest that you move this to the mplsrc mailing list where those vendors may respond personally. --Tom From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 18:32:15 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 SAA00849 for ; Mon, 25 Nov 2002 18:32: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 gAPNYOH17016 for ; Mon, 25 Nov 2002 18:34: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 gAPNYKA28420 for ; Mon, 25 Nov 2002 18:34:21 -0500 (EST) Date: 25 Nov 2002 18:33:27 -0500 Message-ID: <3DE2B346.2EAF4646@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "Muneyoshi Suzuki" Cc: "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: Bridge or LAN/Ethernet emulation References: <200211250719.QAA27755@infer.nal.ecl.net> Content-Type: multipart/alternative; boundary="------------DAAEE210B1DD628A2D8A030A" 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: --------------DAAEE210B1DD628A2D8A030A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Muneyoshi, You've presented good arguments that what has been defined in PWE3 sounds more like _transport_ of Ethernet MAC frames over PSN, not Ethernet service emulation. I think you're also responding to my email to PWE3 on Ethernet emulation: http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html, I believe we are in agreement here wrt Ethernet MAC frame transport vs Ethernet emulation. I've added to your diagram below where I think Ethernet emulation spans to contrast with the PW defined in PWE3. If PWE3 WG decides it is specifying the transport of Ethernet frames (not Ethernet emulation, otherwise we need the functions spanning the Ethernet emulation in the diagram below), then it's easier to simply said in PWE3 docs that we are defining transport of Ethernet frames, rather than emulating Ethernet or defining it as some kind of Ethernet "wire" service. I hope your example of "wireless LAN" below would convince the WG not go down the path of defining a new "wire" service. > And I also don't understand that someone claimed that today's LAN consists > of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore, > IEEE 802.11 WG specifies "wireless LAN" :-) > I think we have stated our concerns, the rest is up to WG consensus. thanks cheng-yin Muneyoshi Suzuki wrote: > Cheng-Yin, > > 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. > > Please refer section 3. > > >3. Requirements for Ethernet Pseudo-Wire Emulation > > An Ethernet PW emulates a single Ethernet link between exactly two > > endpoints. The mechanisms described in this document are agnostic to > > that which is beneath the "Pseudo Wire" level in Figure 2, concerning > > itself only with the "Emulated Service" portion of the stack. > > > > The following reference model describes the termination point of each > > end of the PW within the PE: > > +-----------------------------------+ > > | PE | > > +---+ +-+ +-----+ +------+ +------+ +-+ > > | | |P| | | |PW ter| | PSN | |P| > > | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN > > | | |y| | | |on | | | |y| > > | C | +-+ +-----+ +------+ +------+ +-+ > > | E | | | > > | | +-+ +-----+ +------+ +------+ +-+ > > | | |P| | | |PW ter| | PSN | |P| > > | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN > > | | |y| | | |on | | | |y| > > +---+ +-+ +-----+ +------+ +------+ +-+ > > | | > > +-----------------------------------+ > > ^ ^ > > | | > > A B > > Figure 3: PW reference diagram > > > > The PW terminates at a logical port within the PE, defined at point A > > in the above diagram. This port provides an Ethernet MAC service that > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The above description clearly addresses that the PW provides Ethernet MAC > service. > > > will deliver each Ethernet packet that is received at point A, > > unaltered, to the point A in the corresponding PE at the other end of > > the PW. > > > > 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 > > functions may include stripping, overwriting or adding VLAN tags, > > physical port multiplexing and demultiplexing, PW-PW bridging, L2 > > encapsulation, shaping, policing, etc. > > > > 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. > > The above two paragraphs clearly defines that the NSP terminates Ethernet > MAC frame between PE-CE. > > Therefore, form a viewpoint of protocol architecture, PW reference > mode is interpreted as shown in the following figure. > > Bridge Bridge > +-----------+ +-----------+ > |\ /| |\ /| > | \ Relay / | | \ Relay / | > | \ / | | \ / | > | \ / | | \ / | > | \ / | | \ / | > | V | | V | > | MAC | E | | E | MAC | > +--+--+--+--+ +--+--+--+--+ > | | | | > : Ethernet | | GRE/LSP tunnel | | Ethernet : > +--+ :LAN segment | | | | LAN segment : +--+ > |CE|==:============== +------------------+ =================:====|CE| > +--+ : : +--+ > : |<---------PW----------->| : > Customer A A Customer > Interface Interface <---------Ethernet Emulation-----------> > > > The above figure shows a "Bridged LAN". Two big boxes are "Brides" and > it is a special kind of 1982-style Bridge, because it supports only > two ports, so MAC Relay Entity can be shrank. "MAC" and "Relay" > in a box are "MAC Entity" and "MAC Relay Entity" respectively. > > "E" is an Entity that provides MAC service to the upper layer and the > service is compatible with the MAC service defined in IEEE 802.3-2002. > In summery, it seems to me, draft-ietf-pwe3-ethernet-encap-01.txt does > not define any emulation technology, it specifies protocol for Ethernet > MAC frame transport over GRE/LSP tunnel and the protocol Entity is > refeed as "E" in the above figure. > > It does not emulate any LAN, because in IEEE 802 context, a LAN means > a LAN segment or LAN segments interconnected with repeaters, and LAN > segment means the medium connection, e.g., 1000BASE-T, between Medium > Dependent Interfaces in a LAN. I think the PW is not intended to support > medium dependent service such as 100Mbps-to-100Mbps LAN service, because > this kind of service may not make sense. > > And I also don't understand that someone claimed that today's LAN consists > of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore, > IEEE 802.11 WG specifies "wireless LAN" :-) If it means an LAN segment, > as I described in the above, such service does not make sense. > > And finally, I think, the following specification in > draft-ietf-pwe3-ethernet-encap-01.txt is correct, but need not address > in the document. > > >3.1.6. IEEE 802.3x Flow Control Interworking > > In a standard Ethernet network, the flow control mechanism is > > optional and typically configured between the two nodes on a point- > > to-point link (e.g. between the CE and the PE). IEEE 802.3x PAUSE > > frames MUST NOT be carried across the PW. See Appendix A for notes on > > CE-PE flow control. > > This is because, Ethernet PAUSE frame must be terminated in the MAC Entity > in the above figure. However, it is clearly addressed in IEEE 802.3-2002 and > it is purely Ethernet dependent issue, thus it is out of scope of PWE3. > In the PW section, there is no PAUSE frame, because E entity does not > generate PAUSE frame because it is not Ethernet. So the draft need not > specify anything for PAUSE frame. > > Thanks, > > Muneyoshi Suzuki --------------DAAEE210B1DD628A2D8A030A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Muneyoshi,
You've presented good arguments that what has been defined in PWE3 sounds more like  _transport_ of Ethernet MAC frames over PSN, not Ethernet service emulation.
I think you're also responding to my email to PWE3 on Ethernet emulation:
http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html, I believe we are in agreement here wrt Ethernet MAC frame transport vs Ethernet emulation. I've added to your diagram below where I think Ethernet emulation spans to contrast with the PW defined in PWE3.

If PWE3 WG decides it is specifying the transport of Ethernet frames (not Ethernet emulation, otherwise we need the functions spanning the Ethernet emulation in the diagram below), then  it's easier to simply said in PWE3 docs that we are defining transport of Ethernet frames, rather than emulating Ethernet or defining it as some kind of  Ethernet "wire" service. I hope your example of "wireless LAN" below would convince the WG not go down the path of defining a new "wire" service.
  

And I also don't understand that someone claimed that today's LAN consists
  of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore,
  IEEE 802.11 WG specifies "wireless LAN" :-)


I think we have stated our concerns, the rest is up to WG consensus.

thanks
cheng-yin
 
 

Muneyoshi Suzuki wrote:

Cheng-Yin,

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.

Please refer section 3.

>3. Requirements for Ethernet Pseudo-Wire Emulation
>   An Ethernet PW emulates a single Ethernet link between exactly two
>   endpoints. The mechanisms described in this document are agnostic to
>   that which is beneath the "Pseudo Wire" level in Figure 2, concerning
>   itself only with the "Emulated Service" portion of the stack.
>
>   The following reference model describes the termination point of each
>   end of the PW within the PE:
>           +-----------------------------------+
>           |                PE                 |
>   +---+   +-+  +-----+  +------+  +------+  +-+
>   |   |   |P|  |     |  |PW ter|  | PSN  |  |P|
>   |   |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
>   |   |   |y|  |     |  |on    |  |      |  |y|
>   | C |   +-+  +-----+  +------+  +------+  +-+
>   | E |   |                                   |
>   |   |   +-+  +-----+  +------+  +------+  +-+
>   |   |   |P|  |     |  |PW ter|  | PSN  |  |P|
>   |   |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
>   |   |   |y|  |     |  |on    |  |      |  |y|
>   +---+   +-+  +-----+  +------+  +------+  +-+
>           |                                   |
>           +-----------------------------------+
>                       ^        ^
>                       |        |
>                       A        B
>           Figure 3: PW reference diagram
>
>   The PW terminates at a logical port within the PE, defined at point A
>   in the above diagram. This port provides an Ethernet MAC service that
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The above description clearly addresses that the PW provides Ethernet MAC
service.

>   will deliver each Ethernet packet that is received at point A,
>   unaltered, to the point A in the corresponding PE at the other end of
>   the PW.
>
>   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
>   functions may include stripping, overwriting or adding VLAN tags,
>   physical port multiplexing and demultiplexing, PW-PW bridging, L2
>   encapsulation, shaping, policing, etc.
>
>   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.

The above two paragraphs clearly defines that the NSP terminates Ethernet
MAC frame between PE-CE.

Therefore, form a viewpoint of protocol architecture, PW reference
mode is interpreted as shown in the following figure.

                   Bridge                   Bridge
                +-----------+            +-----------+
                |\         /|            |\         /|
                | \ Relay / |            | \ Relay / |
                |  \     /  |            |  \     /  |
                |   \   /   |            |   \   /   |
                |    \ /    |            |    \ /    |
                |     V     |            |     V     |
                | MAC |  E  |            |  E  | MAC |
                +--+--+--+--+            +--+--+--+--+
                   |     |                  |     |
      : Ethernet   |     |  GRE/LSP tunnel  |     |   Ethernet    :
+--+  :LAN segment |     |                  |     |  LAN segment  :    +--+
|CE|==:==============    +------------------+    =================:====|CE|
+--+  :                                                           :    +--+
      :               |<---------PW----------->|                  :
    Customer          A                        A          Customer
    Interface                                              Interface

                                    <---------Ethernet Emulation----------->
 
 
 

The above figure shows a "Bridged LAN". Two big boxes are "Brides" and
it is a special kind of 1982-style Bridge, because it supports only
two ports, so MAC Relay Entity can be shrank. "MAC" and "Relay"
in a box are "MAC Entity" and "MAC Relay Entity" respectively.

"E" is an Entity that provides MAC service to the upper layer and the
service is compatible with the MAC service defined in IEEE 802.3-2002.
In summery, it seems to me, draft-ietf-pwe3-ethernet-encap-01.txt does
not define any emulation technology, it specifies protocol for Ethernet
MAC frame transport over GRE/LSP tunnel and the protocol Entity is
refeed as "E" in the above figure.

It does not emulate any LAN, because in IEEE 802 context, a LAN means
a LAN segment or LAN segments interconnected with repeaters, and LAN
segment means the medium connection, e.g., 1000BASE-T, between Medium
Dependent Interfaces in a LAN. I think the PW is not intended to support
medium dependent service such as 100Mbps-to-100Mbps LAN service, because
this kind of service may not make sense.

And I also don't understand that someone claimed that today's LAN consists
of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore,
IEEE 802.11 WG specifies "wireless LAN" :-) If it means an LAN segment,
as I described in the above, such service does not make sense.

And finally, I think, the following specification in
draft-ietf-pwe3-ethernet-encap-01.txt is correct, but need not address
in the document.

>3.1.6. IEEE 802.3x Flow Control Interworking
>   In a standard Ethernet network, the flow control mechanism is
>   optional and typically configured between the two nodes on a point-
>   to-point link (e.g.  between the CE and the PE). IEEE 802.3x PAUSE
>   frames MUST NOT be carried across the PW. See Appendix A for notes on
>   CE-PE flow control.

This is because, Ethernet PAUSE frame must be terminated in the MAC Entity
in the above figure. However, it is clearly addressed in IEEE 802.3-2002 and
it is purely Ethernet dependent issue, thus it is out of scope of PWE3.
In the PW section, there is no PAUSE frame, because E entity does not
generate PAUSE frame because it is not Ethernet. So the draft need not
specify anything for PAUSE frame.

Thanks,

Muneyoshi Suzuki

--------------DAAEE210B1DD628A2D8A030A-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 18:53: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 SAA01721 for ; Mon, 25 Nov 2002 18:53: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 gAPNu4H22444 for ; Mon, 25 Nov 2002 18:56: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 gAPNu1A10559 for ; Mon, 25 Nov 2002 18:56:01 -0500 (EST) Date: 25 Nov 2002 18:55:19 -0500 Message-ID: <3DE2B867.2C69DED7@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: erosen@cisco.com Cc: ppvpn@lyris.nortelnetworks.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: L2TP and IPSec 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 Eric, During the discussion on CE-based VPL, I understood your question to be : "Why use L2TP+IPSec and not just IPSec?", perhaps people in L2TPEXT WG has some comments on that. But someone pointed out perhaps that is not what you meant, could you kindly clarify this pls? thanks, cheng-yin From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 20:11: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 UAA04339 for ; Mon, 25 Nov 2002 20:11: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 gAQ1DKH17096 for ; Mon, 25 Nov 2002 20:13: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 gAQ1DHA19772 for ; Mon, 25 Nov 2002 20:13:17 -0500 (EST) Message-Id: <4.3.2.7.2.20021125164533.01c0b220@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Nov 2002 17:12:41 -0800 To: Sasha Vainshtein , "'Ali Sajassi'" From: Ali Sajassi Subject: RE: Issues with draft-sajassi-mvpls-00.txt Cc: "Ppvpn (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-msg-core-1.cisco.com X-SMTP-MAIL-FROM: sajassi@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-msg-core-1.cisco.com [171.71.163.11] X-LYRIS-Message-Id: At 07:23 AM 11/24/2002 +0200, Sasha Vainshtein wrote: >Ali, >Thank you for a prompt response. You're welcome. Additional comments/clarifications inline ... >Please see some questions/comments inline. > >---------------------------------------------------------------------------- >-------- >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) > > > > -----Original Message----- > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > Sent: Saturday, November 23, 2002 1:10 AM > > To: Sasha Vainshtein; Ali Sajassi (E-mail) > > Cc: Ppvpn (E-mail) > > Subject: Re: Issues with draft-sajassi-mvpls-00.txt > > > > > > Sasha, > > > > I answered some of these questions earlier but let me > > elaborate further ... > > > > At 11:58 PM 11/20/2002 +0200, Sasha Vainshtein wrote: > > >Ali and all, > > >I would like to re-state the issues I have raised at the > > PPVPN WG Session > > >today. > > >All these issues deal with the unicast part of the proposal. > > > > > >1. Allocation of huge numbers of IP addresses (an IP address per AC). > > > This looks highly problematic in inter-provider or even inter-AS > > >situations > > > (where use of private IP addresses is precluded). > > > > I think we agree that we don't have an issue with intra-AS > > since a provider > > has access to large address space based on RFC 1918. > > Now if the majority of the traffic is intra-AS, then for the small > > percentage of the end-points that require inter-AS > > communications, one can > > assign addresses from the public address space. > > However, if one still wants to reduce the number of public IP > > addresses, > > then he can do one of the following: > > a) Assign an IP address per VPLS instance instead of per AC > > for that PE > > (this is described in the draft) > > B) Make use of VPLS hierarchy with Ethernet access network > > (QinQ access network) >I do not really understand how this helps. Can you please elaborate? Basically it helps by reducing number of IP end points (e.g., IP PEs). When access network is Ethernet, the MVPLS will be confined to the core network and thus fewer number of IP end points are needed. You can think of the Ethernet access network as an aggregation network where customers' traffic first get aggregated before getting feed into the IP PE. Each customer VPLS instance is represented by a service provider vlan-id (the outer tag) in the access network. Ethernet access network is a low-cost and efficient way of traffic aggregation. > > C) Use multi-segment Emulated LAN (one segment per AS) >How will different segments be inter-connected? Each segment represent an emulated LAN and it looks and feels like a vlan to a GW. Therefore, a GW that connects multiple Emulated LAN segments, basically provides bridge functionality among them. > > > > > > >2. Involvement of core routers in the VPLS: with each new > > AC, all the core > > >routers > > > have to learn routes to the associated IP address. > > > > Not quite. Contrary to MPLS labels, IP addresses do get > > summarized in the > > core and thus not every time you add an AC, a route update is > > needed in the > > P nodes. Because of this route summarization, the amount of > > the states in > > the core is relatively small. > > >I believe that ability of core routers to summarize routes depends on >specific allocation of IP addresses per AC in the given PE. >In other words, you should define some "allocation rules", e.g.: >* define a subnet per VPLS per PE with substantial width to accomodate > a number of prospecive ACs Not per VPLS but per PE (this is unicast data that we are talking about). >* subnets allocated for different PEs must be disjoint yes >* PEs must advertise route(s) to the subnets allocated to it. > > > > > I'd like to remind you that the PWE3 Charter (I am not > > sure about the > > >PPVPN one) > > > explicitly states that PW functionality is limited to > > PEs only and that > > >PWs do not > > > exert control over the underlying network. IMHO the > > proposal violates > > >these > > > principles. > > > > Either requirements draft or the charter needs to be updated > > to make them > > consistent with each other. I think the main reason for > > non-path-oriented > > PW is the network scalability (avoid keeping per PW state in > > the core) and > > if keeping per PW state in core is not a requirement for a > > path-oriented > > scheme, then that scheme can be considered as an alternative option. > > >I agree that the Charter and the requirements document must >correspond to each other. To the best of my knowledge, the >new revision of the requirements draft (not posted yet) solves this >problem by dropping the notion of path-oriented PWs. Good. Cheers, Ali > > > > However, given that MPVLS doesn't use the traditionally > > defined PW (as in > > PWE3), I might use the term tunnel instead of PW in the next > > rev. of the > > document to avoid confusion. > > >I agree. > > > > >3. Forwarding in the egress PE. The draft states that it is is based > > > on the destination IP address found in the packet. It > > does not state > > > whether aIP ddresses associated with an AC are > > considered as IP addresses > > > owned by the PE router terminating this AC,or not. If > > they are not, > > > the packets with the AC-associated destination IP > > address should be > > > forwarded as IP packets which seems wrong, because such > > forwarding > > > does not persume stripping of IP header, MAC address look-up etc. > > > If they are, they would be treated based on the protocol number > > > and according to the protocol-specific rules. In > > particular,if the > > >protocol > > > is L2TPv3 (as mentionedin the presentation), the Session > > ID lookup would > > >be > > > done and,if such a lookup fails (as it should since the > > draft explicitly > > >states > > > that no sessions are established), the packet will be > > discarded (or so I > > >presume). > > > > As explained previously, it is the later case (IP addresses > > associated with > > the AC are owned by the PE) and as mentioned in the > > presentation, it can > > use either GRE or L2TPv3 encapsulation. In case of L2TPv3, it > > only uses the > > encapsulation part without session-id as I described in my > > previous email. > > Frankly given that L2TPv3 encap doesn't buy us anything over > > GRE, I am > > inclined to make it simple and narrowed it down to only GRE. > > > > Regards, > > Ali > > >How will this interoperate with (potential) other uses of GRE in the >same PE, e.g., for MPLS-in-GRE? > > > > > > > > >------------------------------------------------------------- > > --------------- > > >-------- > > >With best regards, > > > Sasha Vainshtein > > >email: sasha@axerra.com > > >phone: +972-3-7659993 (office) > > > +972-8-9254948 (home) > > > +972-58-674833 (cellular) > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Mon Nov 25 20:37:18 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 UAA04896 for ; Mon, 25 Nov 2002 20:37:17 -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 gAQ1dMH21712 for ; Mon, 25 Nov 2002 20:39: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 gAQ1dJA28753 for ; Mon, 25 Nov 2002 20:39:20 -0500 (EST) Message-Id: <200211260138.KAA30349@infer.nal.ecl.net> To: Cheng-Yin.Lee@alcatel.com cc: "Muneyoshi Suzuki" , "IETF PPVPN list" , pwe3@ietf.org Subject: Re: Bridge or LAN/Ethernet emulation In-reply-to: Your message of "25 Nov 2002 18:33:27 EST." <3DE2B346.2EAF4646@alcatel.com> Date: Tue, 26 Nov 2002 10:38:50 +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: Cheng-Yin, > You've presented good arguments that what has been defined in PWE3 sounds > more > like _transport_ of Ethernet MAC frames over PSN, not Ethernet service > emulation. > I think you're also responding to my email to PWE3 on Ethernet emulation: > http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html, I > believe we are in agreement here wrt Ethernet MAC frame transport vs Ethernet > emulation. I've added to your diagram below where I think Ethernet emulation > spans to contrast with the PW defined in PWE3. How about Bridged (Ethernet) LAN Emulation instead Ethernet emulation? As shown in the following figure, from a viewpoint of service customer, the service capability provided between customer interfaces is equivalent to a Bridged LAN. So, I think "Bridged (Ethernet) LAN Emulation" is not incorrect naming for customers. Bridge Bridge +-----------+ +-----------+ |\ /| |\ /| | \ Relay / | | \ Relay / | | \ / | | \ / | | \ / | | \ / | | \ / | | \ / | | V | | V | | MAC | E | | E | MAC | +--+--+--+--+ +--+--+--+--+ | | | | : Ethernet | | GRE/LSP tunnel | | Ethernet : +--+ :LAN segment | | | | LAN segment : +--+ |CE|==:============== +------------------+ =================:====|CE| +--+ : : +--+ : |<---------PW----------->| : Customer A A Customer Interface Interface : : :<---------------- Bridged LAN Emulation ------------------>: > If PWE3 WG decides it is specifying the transport of Ethernet frames (not > Ethernet emulation, otherwise we need the functions spanning the Ethernet > emulation in the diagram below), then it's easier to simply said in PWE3 > docs > that we are defining transport of Ethernet frames, rather than emulating > Ethernet or defining it as some kind of Ethernet "wire" service. I hope your > example of "wireless LAN" below would convince the WG not go down the path of > defining a new "wire" service. > I think we have stated our concerns, the rest is up to WG consensus. Agreed. Thanks, Muneyoshi Suzuki From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 26 02:51:42 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23646 for ; Tue, 26 Nov 2002 02:51:42 -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 gAQ7rK928761 for ; Tue, 26 Nov 2002 02:53: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 gAQ7rGa23216 for ; Tue, 26 Nov 2002 02:53:17 -0500 (EST) Content-Class: urn:content-classes:message Subject: unsubscribe MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Nov 2002 09:54:17 +0200 Message-ID: Thread-Topic: unsubscribe Thread-Index: AcKVIQUDdQMVIJ1xSLyHKgRykATvnw== From: "Nikolay P. Stamboliev" To: X-SMTP-HELO: hsm-ms.hsmt X-SMTP-MAIL-FROM: nikolay@smartcom.bg X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.haemimont.bg [193.178.153.252] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA23646 unsubscribe From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 26 04:33:03 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 EAA25557 for ; Tue, 26 Nov 2002 04:33:03 -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 gAQ9Z7920118 for ; Tue, 26 Nov 2002 04:35:08 -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 gAQ9Z4a09164 for ; Tue, 26 Nov 2002 04:35:04 -0500 (EST) Message-ID: From: Heiles Juergen To: "'Cheng-Yin.Lee@alcatel.com'" , Muneyoshi Suzuki Cc: IETF PPVPN list , pwe3@ietf.org Subject: AW: Bridge or LAN/Ethernet emulation Date: Tue, 26 Nov 2002 10:33:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2952E.EBD67590" X-SMTP-HELO: beamer.mchh.siemens.de X-SMTP-MAIL-FROM: juergen.heiles@siemens.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: beamer.mchh.siemens.de [194.138.158.163] 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_01C2952E.EBD67590 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Basically, =20 this is the case for all the PWE3 activities in my view. PWE3 defines = the transport of L1/L2 client signal over a packet switched server = layer network (speaking in ITU G.805 terms). In case of Ethernet the = client is the Ethernet MAC frame. In case of SONET/SDH the client is = the STS-SPE/VC. We can today transport SONET STS/VT-SPEs or SDH VCs = over various physical signals like PDH signals or OTN (OTU) signals, = not only via OC-N/STM-N signals. Every server layer transport/mapping = has to take the specific requirements of the client signal into = account. =20 Juergen -----Urspr=FCngliche Nachricht----- Von: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] Gesendet: Dienstag, 26. November 2002 00:33 An: Muneyoshi Suzuki Cc: IETF PPVPN list; pwe3@ietf.org Betreff: Re: Bridge or LAN/Ethernet emulation Muneyoshi,=20 You've presented good arguments that what has been defined in PWE3 = sounds more like _transport_ of Ethernet MAC frames over PSN, not = Ethernet service emulation.=20 I think you're also responding to my email to PWE3 on Ethernet = emulation:=20 http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.ht= ml = , I believe we are in agreement here wrt Ethernet MAC frame = transport vs Ethernet emulation. I've added to your diagram below where = I think Ethernet emulation spans to contrast with the PW defined in = PWE3.=20 If PWE3 WG decides it is specifying the transport of Ethernet frames = (not Ethernet emulation, otherwise we need the functions spanning the = Ethernet emulation in the diagram below), then it's easier to simply = said in PWE3 docs that we are defining transport of Ethernet frames, = rather than emulating Ethernet or defining it as some kind of Ethernet = "wire" service. I hope your example of "wireless LAN" below would = convince the WG not go down the path of defining a new "wire" service.=20 =20 And I also don't understand that someone claimed that today's LAN = consists of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore, IEEE 802.11 WG specifies "wireless LAN" :-) I think we have stated our concerns, the rest is up to WG consensus.=20 thanks=20 cheng-yin=20 =20 =20 Muneyoshi Suzuki wrote:=20 Cheng-Yin,=20 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.=20 It does not emulate anything.=20 Please refer section 3.=20 >3. Requirements for Ethernet Pseudo-Wire Emulation=20 > An Ethernet PW emulates a single Ethernet link between exactly two=20 > endpoints. The mechanisms described in this document are agnostic = to=20 > that which is beneath the "Pseudo Wire" level in Figure 2, = concerning=20 > itself only with the "Emulated Service" portion of the stack.=20 >=20 > The following reference model describes the termination point of = each=20 > end of the PW within the PE:=20 > +-----------------------------------+=20 > | PE |=20 > +---+ +-+ +-----+ +------+ +------+ +-+=20 > | | |P| | | |PW ter| | PSN | |P|=20 > | |<=3D=3D|h|<=3D| NSP |<=3D|minati|<=3D|Tunnel|<=3D|h|<=3D=3D = From PSN=20 > | | |y| | | |on | | | |y|=20 > | C | +-+ +-----+ +------+ +------+ +-+=20 > | E | | |=20 > | | +-+ +-----+ +------+ +------+ +-+=20 > | | |P| | | |PW ter| | PSN | |P|=20 > | |=3D=3D>|h|=3D>| NSP |=3D>|minati|=3D>|Tunnel|=3D>|h|=3D=3D> To = PSN=20 > | | |y| | | |on | | | |y|=20 > +---+ +-+ +-----+ +------+ +------+ +-+=20 > | |=20 > +-----------------------------------+=20 > ^ ^=20 > | |=20 > A B=20 > Figure 3: PW reference diagram=20 >=20 > The PW terminates at a logical port within the PE, defined at point = A=20 > in the above diagram. This port provides an Ethernet MAC service = that=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20 The above description clearly addresses that the PW provides Ethernet = MAC=20 service.=20 > will deliver each Ethernet packet that is received at point A,=20 > unaltered, to the point A in the corresponding PE at the other end = of=20 > the PW.=20 >=20 > The "NSP" function includes packet processing needed to translate = the=20 > Ethernet packets that arrive at the CE-PE interface to/from the=20 > Ethernet packets that are applied to the PW termination point. Such = > functions may include stripping, overwriting or adding VLAN tags,=20 > physical port multiplexing and demultiplexing, PW-PW bridging, L2=20 > encapsulation, shaping, policing, etc.=20 >=20 > The points to the left of A, including the physical layer between = the=20 > 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=20 > here.=20 The above two paragraphs clearly defines that the NSP terminates = Ethernet=20 MAC frame between PE-CE.=20 Therefore, form a viewpoint of protocol architecture, PW reference=20 mode is interpreted as shown in the following figure.=20 Bridge Bridge=20 +-----------+ +-----------+=20 |\ /| |\ /|=20 | \ Relay / | | \ Relay / |=20 | \ / | | \ / |=20 | \ / | | \ / |=20 | \ / | | \ / |=20 | V | | V |=20 | MAC | E | | E | MAC |=20 +--+--+--+--+ +--+--+--+--+=20 | | | |=20 : Ethernet | | GRE/LSP tunnel | | Ethernet :=20 +--+ :LAN segment | | | | LAN segment : = +--+=20 |CE|=3D=3D:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = +------------------+ = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D:=3D=3D=3D=3D|CE|=20 +--+ : : = +--+=20 : |<---------PW----------->| :=20 Customer A A Customer=20 Interface Interface <---------Ethernet = Emulation----------->=20 =20 =20 =20 The above figure shows a "Bridged LAN". Two big boxes are "Brides" and=20 it is a special kind of 1982-style Bridge, because it supports only=20 two ports, so MAC Relay Entity can be shrank. "MAC" and "Relay"=20 in a box are "MAC Entity" and "MAC Relay Entity" respectively.=20 "E" is an Entity that provides MAC service to the upper layer and the=20 service is compatible with the MAC service defined in IEEE 802.3-2002.=20 In summery, it seems to me, draft-ietf-pwe3-ethernet-encap-01.txt does=20 not define any emulation technology, it specifies protocol for Ethernet = MAC frame transport over GRE/LSP tunnel and the protocol Entity is=20 refeed as "E" in the above figure.=20 It does not emulate any LAN, because in IEEE 802 context, a LAN means=20 a LAN segment or LAN segments interconnected with repeaters, and LAN=20 segment means the medium connection, e.g., 1000BASE-T, between Medium=20 Dependent Interfaces in a LAN. I think the PW is not intended to = support=20 medium dependent service such as 100Mbps-to-100Mbps LAN service, = because=20 this kind of service may not make sense.=20 And I also don't understand that someone claimed that today's LAN = consists=20 of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore,=20 IEEE 802.11 WG specifies "wireless LAN" :-) If it means an LAN segment, = as I described in the above, such service does not make sense.=20 And finally, I think, the following specification in=20 draft-ietf-pwe3-ethernet-encap-01.txt is correct, but need not address=20 in the document.=20 >3.1.6. IEEE 802.3x Flow Control Interworking=20 > In a standard Ethernet network, the flow control mechanism is=20 > optional and typically configured between the two nodes on a point- = > to-point link (e.g. between the CE and the PE). IEEE 802.3x PAUSE=20 > frames MUST NOT be carried across the PW. See Appendix A for notes = on=20 > CE-PE flow control.=20 This is because, Ethernet PAUSE frame must be terminated in the MAC = Entity=20 in the above figure. However, it is clearly addressed in IEEE = 802.3-2002 and=20 it is purely Ethernet dependent issue, thus it is out of scope of PWE3. = In the PW section, there is no PAUSE frame, because E entity does not=20 generate PAUSE frame because it is not Ethernet. So the draft need not=20 specify anything for PAUSE frame.=20 Thanks,=20 Muneyoshi Suzuki ------_=_NextPart_001_01C2952E.EBD67590 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Basically,
 
this=20 is the case for all the PWE3 activities in my view. PWE3 defines the = transport=20 of L1/L2 client signal over a packet switched server layer = network=20 (speaking in ITU G.805 terms). In case of Ethernet the client is the = Ethernet=20 MAC frame. In case of SONET/SDH the client is the STS-SPE/VC. We can = today=20 transport SONET STS/VT-SPEs or SDH VCs over various physical signals = like PDH=20 signals or OTN (OTU) signals, not only via OC-N/STM-N signals. Every = server=20 layer transport/mapping has to take the specific requirements of the = client=20 signal into account.
 
Juergen
-----Urspr=FCngliche Nachricht-----
Von: Cheng-Yin = Lee=20 [mailto:Cheng-Yin.Lee@alcatel.com]
Gesendet: Dienstag, 26. = November=20 2002 00:33
An: Muneyoshi Suzuki
Cc: IETF PPVPN = list;=20 pwe3@ietf.org
Betreff: Re: Bridge or LAN/Ethernet=20 emulation

Muneyoshi,
You've presented good = arguments=20 that what has been defined in PWE3 sounds more like  _transport_ = of=20 Ethernet MAC frames over PSN, not Ethernet service emulation.
I = think=20 you're also responding to my email to PWE3 on Ethernet emulation: =
http://www.ietf.org/mail-archive/working-groups/pwe3/current= /msg03181.html,=20 I believe we are in agreement here wrt Ethernet MAC frame transport = vs=20 Ethernet emulation. I've added to your diagram below where I think = Ethernet=20 emulation spans to contrast with the PW defined in PWE3.=20

If PWE3 WG decides it is specifying the transport of Ethernet = frames (not=20 Ethernet emulation, otherwise we need the functions spanning the = Ethernet=20 emulation in the diagram below), then  it's easier to simply = said in PWE3=20 docs that we are defining transport of Ethernet frames, rather than = emulating=20 Ethernet or defining it as some kind of  Ethernet "wire" = service. I hope=20 your example of "wireless LAN" below would convince the WG not go = down the=20 path of defining a new "wire" service.
 =20 

And I also don't understand that =
someone claimed that today's LAN consists
  of "wires". What is "wire"? 1000BASE-LX use "fiber", and =
furthermore,
  IEEE 802.11 WG specifies "wireless LAN" :-)


I think we have stated our concerns, the rest is up to WG = consensus.=20

thanks
cheng-yin
 
 =20

Muneyoshi Suzuki wrote:=20

Cheng-Yin,=20

It seems to me, draft-ietf-pwe3-ethernet-encap-01.txt specifies = refence=20
model and protocol for Ethernet MAC frame transport over = GRE/LSP tunnel.=20
It does not emulate anything.=20

Please refer section 3.=20

>3. Requirements for Ethernet Pseudo-Wire Emulation
>   An Ethernet PW emulates a single Ethernet link = between=20 exactly two
>   endpoints. The mechanisms = described in this=20 document are agnostic to
>   that which is beneath = the=20 "Pseudo Wire" level in Figure 2, concerning
>   = itself only=20 with the "Emulated Service" portion of the stack.
>=20
>   The following reference model describes the = termination=20 point of each
>   end of the PW within the PE:=20 =
>          =20 +-----------------------------------+=20 =
>          =20 = |            = ;   =20 = PE           &nbs= p;    =20 |
>   +---+   +-+  +-----+ =20 +------+  +------+  +-+
>   = |  =20 |   |P|  |     |  |PW = ter|  |=20 PSN  |  |P|
>   |   = |<=3D=3D|h|<=3D|=20 NSP |<=3D|minati|<=3D|Tunnel|<=3D|h|<=3D=3D From PSN =
>  =20 |   |   |y|  |     = | =20 |on    |  |      = |  |y|=20
>   | C |   +-+  +-----+ =20 +------+  +------+  +-+
>   | E = |  =20 = |            = ;            = ;          =20 |
>   |   |   +-+  = +-----+ =20 +------+  +------+  +-+
>   = |  =20 |   |P|  |     |  |PW = ter|  |=20 PSN  |  |P|
>   |   = |=3D=3D>|h|=3D>|=20 NSP |=3D>|minati|=3D>|Tunnel|=3D>|h|=3D=3D> To PSN =
>  =20 |   |   |y|  |     = | =20 |on    |  |      = |  |y|=20
>   +---+   +-+  +-----+ =20 +------+  +------+  +-+=20 =
>          =20 = |            = ;            = ;          =20 | =
>          =20 +-----------------------------------+=20 =
>          &nbs= p;           =20 ^        ^=20 =
>          &nbs= p;           =20 |        |=20 =
>          &nbs= p;           =20 A        B=20 =
>           = Figure=20 3: PW reference diagram
>
>   The PW = terminates at a=20 logical port within the PE, defined at point A
>   = in the=20 above diagram. This port provides an Ethernet MAC service that=20 =
           &n= bsp;           &n= bsp; =20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The above = description clearly=20 addresses that the PW provides Ethernet MAC
service.=20

>   will deliver each Ethernet packet that is = received at=20 point A,
>   unaltered, to the point A in the = corresponding=20 PE at the other end of
>   the PW.
>=20
>   The "NSP" function includes packet processing = needed to=20 translate the
>   Ethernet packets that arrive at = the CE-PE=20 interface to/from the
>   Ethernet packets that = are applied=20 to the PW termination point. Such
>   functions = may include=20 stripping, overwriting or adding VLAN tags,
>   = physical=20 port multiplexing and demultiplexing, PW-PW bridging, L2=20
>   encapsulation, shaping, policing, etc. =
>=20
>   The points to the left of A, including the = physical=20 layer between the
>   CE and PE, and any = adaptation (NSP)=20 functions between it and the PW
>   terminations, = are=20 outside of the scope of PWE3 and are not defined =
>   here.=20

The above two paragraphs clearly defines that the NSP terminates = Ethernet=20
MAC frame between PE-CE.=20

Therefore, form a viewpoint of protocol architecture, PW = reference=20
mode is interpreted as shown in the following figure.=20

          = ;        =20 = Bridge           =        =20 Bridge
          = ;     =20 = +-----------+          = ; =20 +-----------+
          = ;     =20 |\        =20 = /|           =20 |\         /| =
          = ;     =20 | \ Relay /=20 |            = | \=20 Relay / |
          = ;     =20 |  \     / =20 |            = | =20 \     /  |
          = ;     =20 |   \   /  =20 |            = |   \   /   |
          = ;     =20 |    \ /   =20 |            = |    \ /    |
          = ;     =20 |     V    =20 |            = |     V     | =
          = ;     =20 | MAC |  E =20 |            = | =20 E  | MAC |
          = ;     =20 = +--+--+--+--+          = ; =20 +--+--+--+--+
          = ;        =20 |    =20 = |            = ;     =20 |     |
      :=20 Ethernet   |     |  GRE/LSP = tunnel =20 |     |   Ethernet    = :=20
+--+  :LAN segment=20 |    =20 = |            = ;     =20 |     |  LAN segment  = :   =20 +--+
|CE|=3D=3D:=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =   =20 +------------------+    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D:=3D=3D=3D=3D|CE|=20
+--+ =20 = :            = ;            = ;            = ;            = ;          =20 :    +--+
     =20 = :            = ;  =20 = |<---------PW----------->|      &nbs= p;          =20 :
   =20 Customer         =20 = A            = ;           =20 A          = Customer=20
   =20 = Interface          &nb= sp;           &nb= sp;           &nb= sp;          =20 = Interface

      &nb= sp;           &nb= sp;           &nb= sp;    =20 <---------Ethernet=20 Emulation----------->
 
 =20
 =20

The above figure shows a "Bridged LAN". Two big boxes are = "Brides" and=20
it is a special kind of 1982-style Bridge, because it supports = only=20
two ports, so MAC Relay Entity can be shrank. "MAC" and "Relay" =
in a=20 box are "MAC Entity" and "MAC Relay Entity" respectively.=20

"E" is an Entity that provides MAC service to the upper layer = and the=20
service is compatible with the MAC service defined in IEEE = 802.3-2002.=20
In summery, it seems to me, = draft-ietf-pwe3-ethernet-encap-01.txt does=20
not define any emulation technology, it specifies protocol for = Ethernet=20
MAC frame transport over GRE/LSP tunnel and the protocol Entity = is=20
refeed as "E" in the above figure.=20

It does not emulate any LAN, because in IEEE 802 context, a LAN = means=20
a LAN segment or LAN segments interconnected with repeaters, = and LAN=20
segment means the medium connection, e.g., 1000BASE-T, between = Medium=20
Dependent Interfaces in a LAN. I think the PW is not intended = to support=20
medium dependent service such as 100Mbps-to-100Mbps LAN = service, because=20
this kind of service may not make sense.=20

And I also don't understand that someone claimed that today's = LAN=20 consists
of "wires". What is "wire"? 1000BASE-LX use "fiber", = and=20 furthermore,
IEEE 802.11 WG specifies "wireless LAN" :-) If it = means an=20 LAN segment,
as I described in the above, such service does not = make=20 sense.=20

And finally, I think, the following specification in=20
draft-ietf-pwe3-ethernet-encap-01.txt is correct, but need not = address=20
in the document.=20

>3.1.6. IEEE 802.3x Flow Control Interworking =
>   In=20 a standard Ethernet network, the flow control mechanism is=20
>   optional and typically configured between the = two nodes=20 on a point-
>   to-point link (e.g.  between = the CE=20 and the PE). IEEE 802.3x PAUSE
>   frames MUST NOT = be=20 carried across the PW. See Appendix A for notes on =
>  =20 CE-PE flow control.=20

This is because, Ethernet PAUSE frame must be terminated in the = MAC=20 Entity
in the above figure. However, it is clearly addressed in = IEEE=20 802.3-2002 and
it is purely Ethernet dependent issue, thus it = is out of=20 scope of PWE3.
In the PW section, there is no PAUSE frame, = because E=20 entity does not
generate PAUSE frame because it is not = Ethernet. So the=20 draft need not
specify anything for PAUSE frame.=20

Thanks,=20

Muneyoshi Suzuki

------_=_NextPart_001_01C2952E.EBD67590-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 26 07:40: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 HAA28885 for ; Tue, 26 Nov 2002 07:40: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 gAQCgm917834 for ; Tue, 26 Nov 2002 07:42: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 gAQCgia25927 for ; Tue, 26 Nov 2002 07:42:45 -0500 (EST) Message-ID: From: "Wijnen, Bert (Bert)" To: ppvpn@nortelnetworks.com Subject: Draft Minutes SUBIP Area Meeting Date: Tue, 26 Nov 2002 13:42:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: ihemail1.firewall.lucent.com X-SMTP-MAIL-FROM: bwijnen@lucent.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ihemail1.lucent.com [192.11.222.161] X-LYRIS-Message-Id: These minutes (Draft for now, mainly based on Dimitri's notes) have been posted to subip-area@subip.ietf.org Mailing list info: General Discussion: subip-area@subip.ietf.org To subscribe: majordomo@subip.ietf.org in body: subscribe subip-area Archive: ftp://subip.ietf.org/pub/lists/ Thanks, Bert From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 26 08:29:40 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 IAA00351 for ; Tue, 26 Nov 2002 08:29:39 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAQDVn929399 for ; Tue, 26 Nov 2002 08:31:49 -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 gAQDVja10588 for ; Tue, 26 Nov 2002 08:31:46 -0500 (EST) Date: 26 Nov 2002 08:27:00 -0500 Message-ID: <3DE376A4.2D74EE26@alcatel.com> From: "Cheng-Yin Lee" To: "Heiles Juergen" Cc: "Muneyoshi Suzuki" , "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] AW: Bridge or LAN/Ethernet emulation References: Content-Type: text/plain; charset=iso-8859-1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA00351 Thanks for articulating this clearly, Juergen. I too think this is within the scope of PWE3, and it is in the charter too, but there were some opposition to this when this issue was first brought up. I thought the next best option is to clarify what PWE3 is doing. thanks cheng-yin > > Basically, > > this is the case for all the PWE3 activities in my view. PWE3 defines the transport of L1/L2 client signal over a packet switched server > layer network (speaking in ITU G.805 terms). In case of Ethernet the client is the Ethernet MAC frame. In case of SONET/SDH the client > is the STS-SPE/VC. We can today transport SONET STS/VT-SPEs or SDH VCs over various physical signals like PDH signals or OTN > (OTU) signals, not only via OC-N/STM-N signals. Every server layer transport/mapping has to take the specific requirements of the > client signal into account. > > Juergen > > -----Ursprüngliche Nachricht----- > Von: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com] > Gesendet: Dienstag, 26. November 2002 00:33 > An: Muneyoshi Suzuki > Cc: IETF PPVPN list; pwe3@ietf.org > Betreff: Re: Bridge or LAN/Ethernet emulation > > Muneyoshi, > You've presented good arguments that what has been defined in PWE3 sounds more like > _transport_ of Ethernet MAC frames over PSN, not Ethernet service emulation. > I think you're also responding to my email to PWE3 on Ethernet emulation: > http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html, I believe we are > in agreement here wrt Ethernet MAC frame transport vs Ethernet emulation. I've added to your > diagram below where I think Ethernet emulation spans to contrast with the PW defined in PWE3. > > If PWE3 WG decides it is specifying the transport of Ethernet frames (not Ethernet emulation, > otherwise we need the functions spanning the Ethernet emulation in the diagram below), then it's > easier to simply said in PWE3 docs that we are defining transport of Ethernet frames, rather than > emulating Ethernet or defining it as some kind of Ethernet "wire" service. I hope your example of > "wireless LAN" below would convince the WG not go down the path of defining a new "wire" > service. > > > And I also don't understand that someone claimed that today's LAN consists > of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore, > IEEE 802.11 WG specifies "wireless LAN" :-) > > > I think we have stated our concerns, the rest is up to WG consensus. > > thanks > cheng-yin > > > > Muneyoshi Suzuki wrote: > > Cheng-Yin, > > 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. > > Please refer section 3. > > >3. Requirements for Ethernet Pseudo-Wire Emulation > > An Ethernet PW emulates a single Ethernet link between exactly two > > endpoints. The mechanisms described in this document are agnostic to > > that which is beneath the "Pseudo Wire" level in Figure 2, concerning > > itself only with the "Emulated Service" portion of the stack. > > > > The following reference model describes the termination point of each > > end of the PW within the PE: > > +-----------------------------------+ > > | PE | > > +---+ +-+ +-----+ +------+ +------+ +-+ > > | | |P| | | |PW ter| | PSN | |P| > > | |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN > > | | |y| | | |on | | | |y| > > | C | +-+ +-----+ +------+ +------+ +-+ > > | E | | | > > | | +-+ +-----+ +------+ +------+ +-+ > > | | |P| | | |PW ter| | PSN | |P| > > | |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN > > | | |y| | | |on | | | |y| > > +---+ +-+ +-----+ +------+ +------+ +-+ > > | | > > +-----------------------------------+ > > ^ ^ > > | | > > A B > > Figure 3: PW reference diagram > > > > The PW terminates at a logical port within the PE, defined at point A > > in the above diagram. This port provides an Ethernet MAC service that > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The above description clearly addresses that the PW provides Ethernet MAC > service. > > > will deliver each Ethernet packet that is received at point A, > > unaltered, to the point A in the corresponding PE at the other end of > > the PW. > > > > 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 > > functions may include stripping, overwriting or adding VLAN tags, > > physical port multiplexing and demultiplexing, PW-PW bridging, L2 > > encapsulation, shaping, policing, etc. > > > > 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. > > The above two paragraphs clearly defines that the NSP terminates Ethernet > MAC frame between PE-CE. > > Therefore, form a viewpoint of protocol architecture, PW reference > mode is interpreted as shown in the following figure. > > Bridge Bridge > +-----------+ +-----------+ > |\ /| |\ /| > | \ Relay / | | \ Relay / | > | \ / | | \ / | > | \ / | | \ / | > | \ / | | \ / | > | V | | V | > | MAC | E | | E | MAC | > +--+--+--+--+ +--+--+--+--+ > | | | | > : Ethernet | | GRE/LSP tunnel | | Ethernet : > +--+ :LAN segment | | | | LAN segment > : +--+ > |CE|==:============== +------------------+ > =================:====|CE| > +--+ : > : +--+ > : |<---------PW----------->| : > Customer A A Customer > Interface Interface > > <---------Ethernet Emulation-----------> > > > > > > The above figure shows a "Bridged LAN". Two big boxes are "Brides" and > it is a special kind of 1982-style Bridge, because it supports only > two ports, so MAC Relay Entity can be shrank. "MAC" and "Relay" > in a box are "MAC Entity" and "MAC Relay Entity" respectively. > > "E" is an Entity that provides MAC service to the upper layer and the > service is compatible with the MAC service defined in IEEE 802.3-2002. > In summery, it seems to me, draft-ietf-pwe3-ethernet-encap-01.txt does > not define any emulation technology, it specifies protocol for Ethernet > MAC frame transport over GRE/LSP tunnel and the protocol Entity is > refeed as "E" in the above figure. > > It does not emulate any LAN, because in IEEE 802 context, a LAN means > a LAN segment or LAN segments interconnected with repeaters, and LAN > segment means the medium connection, e.g., 1000BASE-T, between Medium > Dependent Interfaces in a LAN. I think the PW is not intended to support > medium dependent service such as 100Mbps-to-100Mbps LAN service, because > this kind of service may not make sense. > > And I also don't understand that someone claimed that today's LAN consists > of "wires". What is "wire"? 1000BASE-LX use "fiber", and furthermore, > IEEE 802.11 WG specifies "wireless LAN" :-) If it means an LAN segment, > as I described in the above, such service does not make sense. > > And finally, I think, the following specification in > draft-ietf-pwe3-ethernet-encap-01.txt is correct, but need not address > in the document. > > >3.1.6. IEEE 802.3x Flow Control Interworking > > In a standard Ethernet network, the flow control mechanism is > > optional and typically configured between the two nodes on a point- > > to-point link (e.g. between the CE and the PE). IEEE 802.3x PAUSE > > frames MUST NOT be carried across the PW. See Appendix A for notes on > > CE-PE flow control. > > This is because, Ethernet PAUSE frame must be terminated in the MAC Entity > in the above figure. However, it is clearly addressed in IEEE 802.3-2002 and > it is purely Ethernet dependent issue, thus it is out of scope of PWE3. > In the PW section, there is no PAUSE frame, because E entity does not > generate PAUSE frame because it is not Ethernet. So the draft need not > specify anything for PAUSE frame. > > Thanks, > > Muneyoshi Suzuki From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 26 10:53: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 KAA07243 for ; Tue, 26 Nov 2002 10:53:23 -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 gAQFtR921925 for ; Tue, 26 Nov 2002 10:55: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 gAQFtOa04730 for ; Tue, 26 Nov 2002 10:55:24 -0500 (EST) Message-Id: <200211261554.gAQFsGoh012960@sj-msg-core-1.cisco.com> To: Cheng-Yin.Lee@alcatel.com cc: ppvpn@lyris.nortelnetworks.com Subject: Re: L2TP and IPSec In-reply-to: Your message of 25 Nov 2002 18:55:19 -0500. <3DE2B867.2C69DED7@alcatel.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, 26 Nov 2002 10:54:16 -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: The intent of CE-based VPN work is usually to allow the CEs to be connected over the public Internet. So it seems that IPsec is needed. For VPLS, you may also want to use IP-encapsulated ethernet pseudowires from PWE3. So the path of least resistance leads to IPsec+L2TP, perhaps L2TP within IPsec transport mode. I was thinking that once you have IPsec between the two CEs, it is overkill to also have L2TP, but maybe there's no real problem with that. From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 26 15:24:01 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 PAA19192 for ; Tue, 26 Nov 2002 15:24:01 -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 gAQKQ6902595 for ; Tue, 26 Nov 2002 15:26: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 gAQKQ4a25097 for ; Tue, 26 Nov 2002 15:26:04 -0500 (EST) From: ananth.nagarajan@mail.sprint.com X-OpenMail-Hops: 1 Date: Tue, 26 Nov 2002 14:23:06 -0600 Message-Id: Subject: Soliciting comments/input on draft-ietf-ppvpn-generic-reqts-00.txt MIME-Version: 1.0 TO: ppvpn@nortelnetworks.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 26 Nov 2002 14:23:06 -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, 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 Tue Nov 26 17:54: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 RAA24563 for ; Tue, 26 Nov 2002 17:54:08 -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 gAQMuG926120 for ; Tue, 26 Nov 2002 17:56:17 -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 gAQMuEa20261 for ; Tue, 26 Nov 2002 17:56:15 -0500 (EST) Message-ID: From: "Marco Carugi" To: ppvpn@nortelnetworks.com Subject: Speakers in Atlanta PPVPN : please send me your presentations Date: Tue, 26 Nov 2002 23:55:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2959E.69B0CDA2" 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_01C2959E.69B0CDA2 Content-Type: text/plain; charset="iso-8859-1" Hi. Please send them if not done yet. Thanks, Marco ------_=_NextPart_001_01C2959E.69B0CDA2 Content-Type: text/html; charset="iso-8859-1" Speakers in Atlanta PPVPN : please send me your presentations

Hi.
Please send them if not done yet.

Thanks, Marco

------_=_NextPart_001_01C2959E.69B0CDA2-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Tue Nov 26 18:40:29 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 SAA26850 for ; Tue, 26 Nov 2002 18:40: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 gAQNgT908332 for ; Tue, 26 Nov 2002 18:42: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 gAQNgQa03131 for ; Tue, 26 Nov 2002 18:42:26 -0500 (EST) Message-Id: <3.0.5.32.20021126173921.008e3820@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 26 Nov 2002 17:39:21 -0500 To: Cheng-Yin.Lee@alcatel.com, erosen@cisco.com From: Mark Duffy Subject: Re: L2TP and IPSec Cc: ppvpn@lyris.nortelnetworks.com In-Reply-To: <3DE2B867.2C69DED7@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: 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, 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. --Mark At 06:55 PM 11/25/02 -0500, Cheng-Yin Lee wrote: >Eric, >During the discussion on CE-based VPL, I understood your question to be >: "Why use L2TP+IPSec and not just IPSec?", perhaps people in L2TPEXT WG >has some comments on that. >But someone pointed out perhaps that is not what you meant, could you >kindly clarify this pls? > >thanks, >cheng-yin > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 01:27:19 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 BAA07200 for ; Wed, 27 Nov 2002 01:27:18 -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 gAR6TQN13167 for ; Wed, 27 Nov 2002 01:29: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 gAR6TN419426 for ; Wed, 27 Nov 2002 01:29:23 -0500 (EST) Sender: msquire@squirehome.org Message-ID: <3DE46518.F1C0EB2B@acm.org> Date: Wed, 27 Nov 2002 01:24:24 -0500 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Juha Heinanen CC: ppvpn@nortelnetworks.com Subject: Re: fate of directory based discovery References: <15837.34153.7463.330618@lohi.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: squirehome.org X-SMTP-MAIL-FROM: mattsquire@acm.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rdu162-244-248.nc.rr.com [24.162.244.248] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I think there's strong support for non-BGP solutions to the problem. There are many many situations where throwing BGP on the VPN device is simply not an option. - Matt Juha Heinanen wrote: > > there was not enough support in atlanta meeting to make the dns > discovery i-d a working group document. i guess it would be appropriate > to confirm that also on the mailing list, since not everyone who has > been working on the dns discovery was able to attend the meeting. > > anyhow, i have always said that i don't care what the directory is as > long as the vpn solution is internet wide and doesn't use bgp. some > people didn't like dns discovery, because (although simple) it overloads > dns with stuff that dns was not designed to do. so there may still be > enough support left for a directory based solution if something "better" > than dns can be found. > > i have been thinking for some time now that radius might be a another > possibility for implementing discovery. it would go something like > this: > > - radius is populated for each ce with information about the vpn that > the ce participates in (if any) > - a ce authenticates to the pe using e.g. 802.1x (or the ce is manually > configured in the pe) > - pe makes a radius query and gets as a response the id of the ce's vpn > and a list of other pes that have members in the same vpn > - the vpn's pe list is kept up in the radius server either manually or > based on radius accounting start/stop messages > > this would be a very flexible and automated solution, since there in > case .1x is used, NOTHING ce related needs to be configured in the pe. > > before spending more time on this, i would need to get an indication > from the working group if there is enough interest for ANY directory > based solution. > > -- juha From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 01:51: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 BAA07775 for ; Wed, 27 Nov 2002 01:51: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 gAR6rsN18816 for ; Wed, 27 Nov 2002 01:53:54 -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 gAR6rp427018 for ; Wed, 27 Nov 2002 01:53:51 -0500 (EST) Message-ID: <024a01c295e2$82f902e0$81c802c0@alok> From: "alok" To: , , "Mark Duffy" Cc: References: <3.0.5.32.20021126173921.008e3820@email.quarrytech.com> Subject: Re: L2TP and IPSec Date: Wed, 27 Nov 2002 12:27:57 +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 > 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. are u planning to use tunnel multiple customers in 1 IPSEC tunnel? and using L2TP to distinguish them? and are you saying the IPSEC tunnels are PE to PE, not CE to CE? From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 03:59:22 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03880 for ; Wed, 27 Nov 2002 03:59: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 gAR91KN13469 for ; Wed, 27 Nov 2002 04:01: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 gAR91G404975 for ; Wed, 27 Nov 2002 04:01:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15844.35137.358293.988041@harjus.eng.song.fi> Date: Wed, 27 Nov 2002 10:58:41 +0200 To: mattsquire@acm.org Cc: ppvpn@nortelnetworks.com Subject: Re: fate of directory based discovery In-Reply-To: <3DE46518.F1C0EB2B@acm.org> References: <15837.34153.7463.330618@lohi.eng.song.fi> <3DE46518.F1C0EB2B@acm.org> 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 since there has been several emails on the list in favor of a directory based solution and especially radius based, i'll write an i-d on using radius for vpn discovery. initial version is likely to only cover pe based vpns, but obviously radius can also be applied to ce based vpns. -- juha From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 06:03:22 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05671 for ; Wed, 27 Nov 2002 06:03: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 gARB5QN07256 for ; Wed, 27 Nov 2002 06:05:26 -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 gARB5N418700 for ; Wed, 27 Nov 2002 06:05:23 -0500 (EST) Message-ID: <3DE40D43.8E7B71F6@alcatel.com> Date: Tue, 26 Nov 2002 16:09:39 -0800 From: Mudhafar Hassan-Ali Organization: Alcatel, USA X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy CC: 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: auds951.usa.alcatel.com X-SMTP-MAIL-FROM: mudhafar.hassan-ali@alcatel.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: auds951.usa.alcatel.com [143.209.238.80] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Mark, I concur with you. Additionally L2TP allows for multiplexing multiple PPP sessions, which leads to the use of AAA functions etc. Mudhafar 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, 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. > > --Mark > > At 06:55 PM 11/25/02 -0500, Cheng-Yin Lee wrote: > >Eric, > >During the discussion on CE-based VPL, I understood your question to be > >: "Why use L2TP+IPSec and not just IPSec?", perhaps people in L2TPEXT WG > >has some comments on that. > >But someone pointed out perhaps that is not what you meant, could you > >kindly clarify this pls? > > > >thanks, > >cheng-yin > > > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 06:53: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 GAA06414 for ; Wed, 27 Nov 2002 06:53: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 gARBtuN13452 for ; Wed, 27 Nov 2002 06:55: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 gARBtr407058 for ; Wed, 27 Nov 2002 06:55:53 -0500 (EST) From: To: "alok" Cc: , , "Mark Duffy" , , ipng@sunroof.eng.sun.co Message-ID: <3235135022.3502232351@tid.es> Date: Wed, 27 Nov 2002 12:53:56 +0100 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: L2TP for IPv6 (Re: L2TP and IPSec) X-Accept-Language: es Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-SMTP-HELO: tid.tid.es X-SMTP-MAIL-FROM: jpmg62@tid.es X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: tidos.tid.es [193.145.240.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA06414 Hi, Has anybody known L2TP for IPv6 features? (for example a draft) I think that it's necessary for encapsulate PPP (IPv6CP) in L2TP for VPN and networks access server. Howerver, it can to transport IPv6 packet from a user to a ISP native IPv6. ./thanks/bye/jp ------------------------------------------------ Juan Pedro Montaner Giner jpmg62@tid.es TELEFÓNICA I+D www.tid.es Emilio Vargas #6 28043 Madrid (E) Tlfn: +34 913379238 ------------------------------------------------- ----- Original Message ----- From: "alok" Date: Wednesday, November 27, 2002 7:57 am Subject: Re: L2TP and IPSec > > > 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. > > are u planning to use tunnel multiple customers in 1 IPSEC tunnel? > > and using L2TP to distinguish them? > > and are you saying the IPSEC tunnels are PE to PE, not CE to CE? > > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 06:56: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 GAA06474 for ; Wed, 27 Nov 2002 06:56:32 -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 gARBwWN16790 for ; Wed, 27 Nov 2002 06:58:32 -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 gARBwU411217 for ; Wed, 27 Nov 2002 06:58:30 -0500 (EST) Message-ID: From: Sasha Vainshtein To: "'jh@lohi.eng.song.fi'" Cc: ppvpn@nortelnetworks.com, mattsquire@acm.org Subject: RE: fate of directory based discovery Date: Wed, 27 Nov 2002 12:11:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" X-SMTP-HELO: antivir2 X-SMTP-MAIL-FROM: Sasha@AXERRA.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [80.74.100.67] X-LYRIS-Message-Id: Juha, I also happen to belive that a directory-based solution is validand that using RADIUS as the method to access the directory may simplify implementations. I will be waiting for your new draft. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Wednesday, November 27, 2002 10:59 AM > To: mattsquire@acm.org > Cc: ppvpn@nortelnetworks.com > Subject: Re: fate of directory based discovery > > > since there has been several emails on the list in favor of a > directory > based solution and especially radius based, i'll write an i-d on using > radius for vpn discovery. initial version is likely to only cover pe > based vpns, but obviously radius can also be applied to ce based vpns. > > -- juha > > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 12:54: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 MAA21581 for ; Wed, 27 Nov 2002 12:54:12 -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 gARHuIN05531 for ; Wed, 27 Nov 2002 12:56:19 -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 gARHuF400166 for ; Wed, 27 Nov 2002 12:56:16 -0500 (EST) Message-ID: <3DE50422.5080501@isi.edu> Date: Wed, 27 Nov 2002 09:42:58 -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: Mark Duffy CC: 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> 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 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. 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. > 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. Having a separate VPN ID space doesn't magically solve anything. VPN IDs must be unique, at least where multiple VPNs 'touchdown' (share routers or so-called 'edge' devices). I.e., there are two solutions: a- IPsec with nonoverlapping (where touchdown occurs) addresses b- L2TP et al extended with nonoverlapping VPN IDs (a) exists; (b) provides a larger IP address space, at the cost of requiring extension and deployment of a new protocol Joe From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 16:52:08 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 QAA29215 for ; Wed, 27 Nov 2002 16:52:08 -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 gARLsHN22262 for ; Wed, 27 Nov 2002 16:54:18 -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 gARLsC404082 for ; Wed, 27 Nov 2002 16:54:12 -0500 (EST) Message-ID: <3DE53565.10502@isi.edu> Date: Wed, 27 Nov 2002 13:13:09 -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: Cheng-Yin.Lee@alcatel.com CC: Mark Duffy , erosen@cisco.com, ppvpn@lyris.nortelnetworks.com, l2tpext@ietf.org Subject: Re: L2TP and IPSec References: <3.0.5.32.20021126173921.008e3820@email.quarrytech.com> <3DE50422.5080501@isi.edu> <3DE521BC.5B5E0612@alcatel.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 Cheng-Yin Lee wrote: > Joe, Mark, Alok, > Some quick comments. > > For CE-based Virtual Private LAN (VPL): > - there is no multiplexing of different customers VPL over a single IPSec > - VPL ID is not used regardless of whether IPsec or L2TP is the tunneling > protocol > - As Eric Rosen pointed out, "the path of least resistance leads to > IPsec+L2TP", and I agree with him on this respect. > I am open to using IPSec (in fact, personally, I do like something like EtherIP, > but would IANA assign a new/recycled protocol ID for CE-based VPL?), but as I > understand from discussions, L2TP options signaling and keepalives are nice for > VPL applications, and L2TP+IPSec overhead is not significant compared to IPSec > only. Perhaps the L2TPEXT WG has some comments. IMO, these VPNs should be largely independent of tunnel used. There is no need for signalling or keep-alives per se in a tunnel - that is the task of a routing protocol within the VPN. The path of least resistance involves not creating new protocols. Joe From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 17:14:07 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 RAA29876 for ; Wed, 27 Nov 2002 17:14:06 -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 gARMGFN00622 for ; Wed, 27 Nov 2002 17:16:15 -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 gARMGC402279 for ; Wed, 27 Nov 2002 17:16:12 -0500 (EST) Date: 27 Nov 2002 16:14:20 -0500 Message-ID: <3DE535AC.5C98FB5B@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "Juha Heinanen" Cc: "Brijesh Kumar" , ppvpn@nortelnetworks.com X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: fate of directory based discovery References: <15837.34153.7463.330618@lohi.eng.song.fi> <00c401c291bb$5ac27340$f300510c@6640bbc3r131> <3DDDA150.712CCED2@alcatel.com> <15838.12228.127616.649068@lohi.eng.song.fi> 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@nortelnetworks.com X-SMTP-PEER-INFO: m115-138.on.tac.net [209.202.115.138] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Juha, Juha Heinanen wrote: > > Question for Juha, and other providers, one issue I would like to > > understand is > > how important is timeliness of VPN site information (e.g. updates, > > add, remove site) ? > > timeliness should be within a range of few seconds after the change has > been administravely made so that the network manager can see the effects > of the change without having to have a coffee break. This is good feedback, thanks. I think you mean that the changes should be effected on PE/CE within a few seconds, not just on the management system, right? > > Is it important to be able to update PEs/CEs of VPN information > > changes or is it > > sufficient to simply poll for VPN site information? > > i don't like any solution that is based on polling. that is why i > suggested that the change is always initiated by the network, not by the > radius server. When do PEs/CEs query for VPN information? A site may be removed without removing or shutting down a CE. > > How about polling less frequently, but have simple > > push/receive-trigger-then-pull mechanisms (which does not require > > keeping states about PEs/CEs that cannot be updated yet)? > > i don't like the idea of specifying any new protocol for discovery > purpose. I'm not suggesting specifying new protocols either. We may be able to use existing push or receive trigger and pull mechanisms in conjuction with a pull mechanism. I agree it's simpler if the requirements are such that we only need one mechanism. thanks cheng-yin From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 18:38:03 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 SAA02698 for ; Wed, 27 Nov 2002 18:38:03 -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 gARNe3N13539 for ; Wed, 27 Nov 2002 18:40:03 -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 gARNdx410673 for ; Wed, 27 Nov 2002 18:40:00 -0500 (EST) Date: 27 Nov 2002 18:07:57 -0500 Message-ID: <3DE5504D.A8B6AF9F@alcatel.com> From: "Cheng-Yin Lee" To: "Joe Touch" Cc: "Mark Duffy" , erosen@cisco.com, ppvpn@lyris.nortelnetworks.com, l2tpext@ietf.org X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: L2TP and IPSec References: <3.0.5.32.20021126173921.008e3820@email.quarrytech.com> <3DE50422.5080501@isi.edu> <3DE521BC.5B5E0612@alcatel.com> <3DE53565.10502@isi.edu> 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 Joe, Joe Touch wrote: > > Cheng-Yin Lee wrote: > > Joe, Mark, Alok, > > Some quick comments. > > > > For CE-based Virtual Private LAN (VPL): > > - there is no multiplexing of different customers VPL over a single IPSec > > - VPL ID is not used regardless of whether IPsec or L2TP is the tunneling > > protocol > > - As Eric Rosen pointed out, "the path of least resistance leads to > > IPsec+L2TP", and I agree with him on this respect. > > I am open to using IPSec (in fact, personally, I do like something like EtherIP, > > but would IANA assign a new/recycled protocol ID for CE-based VPL?), but as I > > understand from discussions, L2TP options signaling and keepalives are nice for > > VPL applications, and L2TP+IPSec overhead is not significant compared to IPSec > > only. Perhaps the L2TPEXT WG has some comments. > > IMO, these VPNs should be largely independent of tunnel used. There is > no need for signalling or keep-alives per se in a tunnel - that is the > task of a routing protocol within the VPN. Perhaps I misunderstood your point, but I was commenting on Virtual Private LAN above. > The path of least resistance involves not creating new protocols. May I know which new protocols are you referring to? thanks cheng-yin > Joe From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 18:49:37 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 SAA03090 for ; Wed, 27 Nov 2002 18:49:36 -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 gARNplN18381 for ; Wed, 27 Nov 2002 18:51:47 -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 gARNpi417595 for ; Wed, 27 Nov 2002 18:51:45 -0500 (EST) Date: 27 Nov 2002 14:49:16 -0500 Message-ID: <3DE521BC.5B5E0612@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "Joe Touch" Cc: "Mark Duffy" , erosen@cisco.com, ppvpn@lyris.nortelnetworks.com, l2tpext@ietf.org X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: L2TP and IPSec References: <3.0.5.32.20021126173921.008e3820@email.quarrytech.com> <3DE50422.5080501@isi.edu> 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 Joe, Mark, Alok, Some quick comments. For CE-based Virtual Private LAN (VPL): - there is no multiplexing of different customers VPL over a single IPSec - VPL ID is not used regardless of whether IPsec or L2TP is the tunneling protocol - As Eric Rosen pointed out, "the path of least resistance leads to IPsec+L2TP", and I agree with him on this respect. I am open to using IPSec (in fact, personally, I do like something like EtherIP, but would IANA assign a new/recycled protocol ID for CE-based VPL?), but as I understand from discussions, L2TP options signaling and keepalives are nice for VPL applications, and L2TP+IPSec overhead is not significant compared to IPSec only. Perhaps the L2TPEXT WG has some comments. thanks cheng-yin 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. > > 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. > > > 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. > > Having a separate VPN ID space doesn't magically solve anything. VPN IDs > must be unique, at least where multiple VPNs 'touchdown' (share routers > or so-called 'edge' devices). > > I.e., there are two solutions: > a- IPsec with nonoverlapping (where touchdown occurs) addresses > b- L2TP et al extended with nonoverlapping VPN IDs > > (a) exists; (b) provides a larger IP address space, at the cost of > requiring extension and deployment of a new protocol > > Joe From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 19:04:40 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 TAA03373 for ; Wed, 27 Nov 2002 19:04:40 -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 gAS06kN02285 for ; Wed, 27 Nov 2002 19:06:47 -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 gAS06h412574 for ; Wed, 27 Nov 2002 19:06:43 -0500 (EST) Date: 27 Nov 2002 15:01:01 -0500 Message-ID: <3DE5247D.2D1237AD@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "Muneyoshi Suzuki" Cc: "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 LAN/Ethernet emulation References: <200211260138.KAA30349@infer.nal.ecl.net> Content-Type: multipart/alternative; boundary="------------F336D9978A76D338C44F1A08" 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: --------------F336D9978A76D338C44F1A08 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Muneyoshi, I am fine with (Ethernet)LAN emulation or Bridged (Ethernet) LAN Emulation as long as the latter does not mean Bridge Emulation. I think Juergen Heiles said it most succinctly about what is within PWE3 WG scope: > this is the case for all the PWE3 activities in my view. PWE3 defines the transport of L1/L2 client signal over a packet switched server layer network (speaking in ITU > G.805 terms). In case of Ethernet the client is the Ethernet MAC frame. In case of SONET/SDH the client is the STS-SPE/VC. We can today transport SONET > STS/VT-SPEs or SDH VCs over various physical signals like PDH signals or OTN (OTU) signals, not only via OC-N/STM-N signals. Every server layer > transport/mapping has to take the specific requirements of the client signal into account. > I hope your example of wireless LAN demonstrates why trying to emulate an Ethernet physical wire is not such a good idea. thanks cheng-yin Muneyoshi Suzuki wrote: > Cheng-Yin, > > > You've presented good arguments that what has been defined in PWE3 sounds > > more > > like _transport_ of Ethernet MAC frames over PSN, not Ethernet service > > emulation. > > I think you're also responding to my email to PWE3 on Ethernet emulation: > > http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html, I > > believe we are in agreement here wrt Ethernet MAC frame transport vs Ethernet > > emulation. I've added to your diagram below where I think Ethernet emulation > > spans to contrast with the PW defined in PWE3. > > How about Bridged (Ethernet) LAN Emulation instead Ethernet emulation? > As shown in the following figure, from a viewpoint of service customer, > the service capability provided between customer interfaces is equivalent > to a Bridged LAN. So, I think "Bridged (Ethernet) LAN Emulation" is not > incorrect naming for customers. > > Bridge Bridge > +-----------+ +-----------+ > |\ /| |\ /| > | \ Relay / | | \ Relay / | > | \ / | | \ / | > | \ / | | \ / | > | \ / | | \ / | > | V | | V | > | MAC | E | | E | MAC | > +--+--+--+--+ +--+--+--+--+ > | | | | > : Ethernet | | GRE/LSP tunnel | | Ethernet : > +--+ :LAN segment | | | | LAN segment : +--+ > |CE|==:============== +------------------+ =================:====|CE| > +--+ : : +--+ > : |<---------PW----------->| : > Customer A A Customer > Interface Interface > : : > :<---------------- Bridged LAN Emulation ------------------>: > > > If PWE3 WG decides it is specifying the transport of Ethernet frames (not > > Ethernet emulation, otherwise we need the functions spanning the Ethernet > > emulation in the diagram below), then it's easier to simply said in PWE3 > > docs > > that we are defining transport of Ethernet frames, rather than emulating > > Ethernet or defining it as some kind of Ethernet "wire" service. I hope your > > example of "wireless LAN" below would convince the WG not go down the path of > > defining a new "wire" service. > > > I think we have stated our concerns, the rest is up to WG consensus. > > Agreed. > > Thanks, > > Muneyoshi Suzuki > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 --------------F336D9978A76D338C44F1A08 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Muneyoshi,
I am fine with (Ethernet)LAN emulation or Bridged (Ethernet) LAN Emulation as long as the latter does not mean Bridge Emulation.

I think Juergen Heiles said it most succinctly about what is within PWE3 WG scope: 

this is the case for all the PWE3 activities in my view. PWE3 defines the transport of L1/L2 client signal over a packet switched server layer network (speaking in ITU
G.805 terms). In case of Ethernet the client is the Ethernet MAC frame. In case of SONET/SDH the client is the STS-SPE/VC. We can today transport SONET
STS/VT-SPEs or SDH VCs over various physical signals like PDH signals or OTN (OTU) signals, not only via OC-N/STM-N signals. Every server layer
transport/mapping has to take the specific requirements of the client signal into account.
I hope your example of wireless LAN demonstrates why  trying to emulate an Ethernet physical wire is not such a good idea.

thanks
cheng-yin

Muneyoshi Suzuki wrote:

Cheng-Yin,

> You've presented good arguments that what has been defined in PWE3 sounds
> more
> like  _transport_ of Ethernet MAC frames over PSN, not Ethernet service
> emulation.
> I think you're also responding to my email to PWE3 on Ethernet emulation:
> http://www.ietf.org/mail-archive/working-groups/pwe3/current/msg03181.html, I
> believe we are in agreement here wrt Ethernet MAC frame transport vs Ethernet
> emulation. I've added to your diagram below where I think Ethernet emulation
> spans to contrast with the PW defined in PWE3.

How about Bridged (Ethernet) LAN Emulation instead Ethernet emulation?
As shown in the following figure, from a viewpoint of service customer,
the service capability provided between customer interfaces is equivalent
to a Bridged LAN. So, I think "Bridged (Ethernet) LAN Emulation" is not
incorrect naming for customers.

                   Bridge                   Bridge
                +-----------+            +-----------+
                |\         /|            |\         /|
                | \ Relay / |            | \ Relay / |
                |  \     /  |            |  \     /  |
                |   \   /   |            |   \   /   |
                |    \ /    |            |    \ /    |
                |     V     |            |     V     |
                | MAC |  E  |            |  E  | MAC |
                +--+--+--+--+            +--+--+--+--+
                   |     |                  |     |
      : Ethernet   |     |  GRE/LSP tunnel  |     |   Ethernet    :
+--+  :LAN segment |     |                  |     |  LAN segment  :    +--+
|CE|==:==============    +------------------+    =================:====|CE|
+--+  :                                                           :    +--+
      :               |<---------PW----------->|                  :
  Customer            A                        A               Customer
  Interface                                                    Interface
      :                                                           :
      :<---------------- Bridged LAN Emulation ------------------>:

> If PWE3 WG decides it is specifying the transport of Ethernet frames (not
> Ethernet emulation, otherwise we need the functions spanning the Ethernet
> emulation in the diagram below), then  it's easier to simply said in PWE3
> docs
> that we are defining transport of Ethernet frames, rather than emulating
> Ethernet or defining it as some kind of  Ethernet "wire" service. I hope your
> example of "wireless LAN" below would convince the WG not go down the path of
> defining a new "wire" service.

> I think we have stated our concerns, the rest is up to WG consensus.

Agreed.

Thanks,

Muneyoshi Suzuki
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3

--------------F336D9978A76D338C44F1A08-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Wed Nov 27 23:26: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 XAA08557 for ; Wed, 27 Nov 2002 23:26: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 gAS4S1N24859 for ; Wed, 27 Nov 2002 23:28: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 gAS4Rx417313 for ; Wed, 27 Nov 2002 23:27:59 -0500 (EST) Message-Id: <200211280419.NAA36047@infer.nal.ecl.net> To: Cheng-Yin.Lee@alcatel.com cc: "Muneyoshi Suzuki" , "IETF PPVPN list" , pwe3@ietf.org Subject: Re: [PWE3] Re: Bridge or LAN/Ethernet emulation In-reply-to: Your message of "27 Nov 2002 15:01:01 EST." <3DE5247D.2D1237AD@alcatel.com> Date: Thu, 28 Nov 2002 13:19:32 +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: Cheng-Yin, > I am fine with (Ethernet)LAN emulation or Bridged (Ethernet) LAN Emulation > as long as the latter does not mean Bridge Emulation. Agreed. > I think Juergen Heiles said it most succinctly about what is within PWE3 > WG scope: > > this is the case for all the PWE3 activities in my view. PWE3 defines > > the transport of L1/L2 client signal over a packet switched server layer > > network (speaking in ITU > > G.805 terms). In case of Ethernet the client is the Ethernet MAC frame. > > In case of SONET/SDH the client is the STS-SPE/VC. We can today transport > > SONET STS/VT-SPEs or SDH VCs over various physical signals like PDH > > signals or OTN (OTU) signals, not only via OC-N/STM-N signals. Every > > server layer transport/mapping has to take the specific requirements > > of the client signal into account. I'm not sure the reason why the PWE3 wg people think they are discussing emulated Ethernet as well as pseudo ATM/FR/PDH/SDH wires. A series of ITU-T recommendations for ATM/FR/PDH/SDH essentially define UNI/NNI protocols for these. Therefore, if PE-CE protocol conforms to ATM UNI recommendations, it provides "ATM" service, not logical/virtual/emulated/pseudo ATM. I fully agree Juergen's view. It seems to me PWE3 WG is discussing foo transport over GRE/LSP tunnel. Thanks, Muneyoshi Suzuki From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 28 03:25:59 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 DAA22789 for ; Thu, 28 Nov 2002 03:25:59 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAS8Rvu23020 for ; Thu, 28 Nov 2002 03:27: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 gAS8Rs616343 for ; Thu, 28 Nov 2002 03:27:55 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15845.53871.382941.405776@harjus.eng.song.fi> Date: Thu, 28 Nov 2002 10:23:11 +0200 To: Cheng-Yin.Lee@alcatel.com Cc: "Brijesh Kumar" , ppvpn@nortelnetworks.com Subject: Re: fate of directory based discovery In-Reply-To: <3DE535AC.5C98FB5B@alcatel.com> References: <15837.34153.7463.330618@lohi.eng.song.fi> <00c401c291bb$5ac27340$f300510c@6640bbc3r131> <3DDDA150.712CCED2@alcatel.com> <15838.12228.127616.649068@lohi.eng.song.fi> <3DE535AC.5C98FB5B@alcatel.com> 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 Cheng-Yin Lee writes: > This is good feedback, thanks. I think you mean that the changes should be > effected on PE/CE within a few seconds, not just on the management system, > right? yes. > When do PEs/CEs query for VPN information? A site may be removed without > removing or shutting down a CE. see my dns-l2tp draft. there is no polling in it. the same can be achieved with radius. -- juha From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 28 04:04:04 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 EAA23414 for ; Thu, 28 Nov 2002 04:04:04 -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 gAS96Fu04908 for ; Thu, 28 Nov 2002 04:06:15 -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 gAS96B610235 for ; Thu, 28 Nov 2002 04:06:11 -0500 (EST) From: To: "Marco Carugi" Cc: ppvpn@nortelnetworks.com Message-ID: <4a5684a1ac.4a1ac4a568@tid.es> Date: Thu, 28 Nov 2002 10:05:35 +0100 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: Re: Speakers in Atlanta PPVPN : please send me your presentations X-Accept-Language: es Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-SMTP-HELO: tid.tid.es X-SMTP-MAIL-FROM: jpmg62@tid.es X-SMTP-RCPT-TO: marco.carugi@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tidos.tid.es [193.145.240.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA23414 Hello, my name is Juan Pedro Montaner Giner and I'm working in Telefonica R&D from Spain. So, my team is IP access technology and we're interesting in VPN, access, operations for IPv6 features. I show IETF mail list everyday, in special IPv6 protocols subjects. Best regards, ./jp ------------------------------------------------ Juan Pedro Montaner Giner jpmg62@tid.es TELEFÓNICA I+D www.tid.es Emilio Vargas #6 28043 Madrid (E) Tlfn: +34 913379238 ------------------------------------------------- ----- Original Message ----- From: "Marco Carugi" Date: Tuesday, November 26, 2002 11:55 pm Subject: Speakers in Atlanta PPVPN : please send me your presentations > Hi. > Please send them if not done yet. > > Thanks, Marco > > From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 28 11:15:26 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 LAA29797 for ; Thu, 28 Nov 2002 11:15:25 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gASGHKu20089 for ; Thu, 28 Nov 2002 11:17: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 gASGHH616561 for ; Thu, 28 Nov 2002 11:17:17 -0500 (EST) Date: 28 Nov 2002 11:16:23 -0500 Message-ID: <3DE64157.6573B6F@alcatel.com> From: "Cheng-Yin Lee" Reply-To: Cheng-Yin.Lee@alcatel.com To: "Norman Finn" Cc: "IETF PPVPN list" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IEEE 802.1 actions on Provider Bridges References: <3DDB2276.23F1A4C8@cisco.com> Content-Type: multipart/alternative; boundary="------------30C4954ECF706176021980A3" 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: --------------30C4954ECF706176021980A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Norm, Thanks for sending this summary to the PPVPN mailing list. In Atlanta, some questions were raised about overlapping work between the IEEE and the IETF, the suggestion was to take this to the mailing list. In particular: > 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. > 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? thanks cheng-yin 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. --------------30C4954ECF706176021980A3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Norm,
Thanks for sending this summary to the PPVPN mailing list.

In Atlanta, some questions were raised about overlapping work between the IEEE and the IETF, the suggestion was to take this to the mailing list.

In particular: 

 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. 

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?

thanks
cheng-yin

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.

--------------30C4954ECF706176021980A3-- From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 28 12:03:39 2002 Received: from zcars0m9.nortelentworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00492 for ; Thu, 28 Nov 2002 12:03:39 -0500 (EST) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelentworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gASH5nu02641 for ; Thu, 28 Nov 2002 12:05:50 -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 gASH5k611047 for ; Thu, 28 Nov 2002 12:05:46 -0500 (EST) Message-Id: <3.0.5.32.20021128115151.008729f0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 28 Nov 2002 11:51:51 -0500 To: "alok" , , , "Mark Duffy" From: Mark Duffy Subject: Re: L2TP and IPSec Cc: In-Reply-To: <024a01c295e2$82f902e0$81c802c0@alok> References: <3.0.5.32.20021126173921.008e3820@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: At 12:27 PM 11/27/02 +0530, alok 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. > >are u planning to use tunnel multiple customers in 1 IPSEC tunnel? > >and using L2TP to distinguish them? > >and are you saying the IPSEC tunnels are PE to PE, not CE to CE? What I plan to do is not for this forum :-) But what I was talking about was using an l2tp session per vpn context. And an ipsec sa per l2tp tunnel. PE-PE. From bounce-ppvpn-121951@lyris.nortelnetworks.com Thu Nov 28 12:04:19 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 MAA00541 for ; Thu, 28 Nov 2002 12:04:19 -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 gASH6Ju03307 for ; Thu, 28 Nov 2002 12:06:19 -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 gASH6G611838 for ; Thu, 28 Nov 2002 12:06:16 -0500 (EST) Message-Id: <3.0.5.32.20021128120250.007c7b20@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 28 Nov 2002 12:02:50 -0500 To: Joe Touch , Mark Duffy From: Mark Duffy Subject: Re: L2TP and IPSec Cc: Cheng-Yin.Lee@alcatel.com, erosen@cisco.com, ppvpn@lyris.nortelnetworks.com In-Reply-To: <3DE50422.5080501@isi.edu> References: <3.0.5.32.20021126173921.008e3820@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: 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. > >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. > >> 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. 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. --Mark