From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun Jun 1 16:41:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01342 for ; Sun, 1 Jun 2003 16:41:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h51KemB26845 for ; Sun, 1 Jun 2003 16:40:49 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h51Kekb08123 for ; Sun, 1 Jun 2003 16:40:46 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C79184430C7A6CBE@zbl6c002.corpeast.baynetworks.com> From: "Vasile Radoaca" To: "'vkompella@timetra.com'" , "Dinesh Mohan" , Ppvpn , Rick Wilder Subject: RE: decisions on L2 solutions documents Date: Sun, 1 Jun 2003 16:39:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3287D.DD19685E" 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_01C3287D.DD19685E Content-Type: text/plain Vach, See my comments below - Cheers Vasile -----Original Message----- From: Vach Kompella [mailto:vkompella@timetra.com] Sent: Friday, May 30, 2003 12:50 PM To: Radoaca, Vasile [BL60:X624:EXCH]; Mohan, Dinesh [CAR:1A11:EXCH]; Ppvpn; Rick Wilder Subject: RE: decisions on L2 solutions documents Vasile, Dinesh, Some comments below. I've tried to identify Rick's, Vasile's and my comments. Outlook may mess the whole thing up, so apologies in advance. -Vach .. clipped Rick>> Here are the questions/requests-for-clarification that came up. Rick>> a) how do the discovery and signaling parts of the document Rick>> relate to those described in the other solutions documents Rick>> and which Rick>> of them are suggested to be mandatory to implement VR> > vasile VR> There are couple of assumptions that need to be taken in VR> consideration: VR> 1) VR> The GVPLS model, as a distributed model, needs to have a signaling mechanism that allows PW to be VR> identified by VPN-ID, and the End Points together. The pwe3-control-protocol-02.txt draft, with VR> Rosen's extensions to the PW Signaling mechanism address this VR> problem. Vach>> As a matter of fact, Rosen's signaling separately identifies the Vach>> PW and the VPN. Think of the Vach>> VPNID as a collection of PWs, and think of the SAII, TAII between Vach>> a pair of PEs as the PW Vach>> identifier. So, if you want to use the Rosen model, why write Vach>> your own draft? >> Vasile Rosen's draft presents only the extensions to the Martini's PW model, for the control plan in order to accommodate more general models, like the distributed model. The new GVPLS draft would be based on Rosen signaling [PWE3-Control 02.txt]. So, the GVPLS has his own role as solution draft. .. clipped Vach>> There are two issues here. The first is whether we need a Vach>> separate model for distributed VPLS or Vach>> not. The second is whether we need a VPN ID. Vach>> To the first point, Ali and Eric have described how to use p2p Vach>> PWs in conjuction with a learning Vach>> bridge in the position of the MTU to make a distributed VPLS Vach>> node. don't think we need to have Vach>> another way to create a distributed VPLS node. >> Vasile The draft-rosen-ppvpn-l2siganling-03.txt, section 5.5 represents an example how a distributed model can be built using the Generalized signaling method [PWE3-Control]. However, such model doesn't scale at all, and it covers only point-to-point type connections between U-PE devices and N-PE devices. In a more general and useful case, is when an Ethernet access network is used between U-PE and N-PE devices. Also, such model needs to be presented in and end-to-end solution. We have here a typical two extreme cases: 1) VPLS/HVPLS [your solution] where the MAC learning is done in PE - in this repsect the scalability is very limited because of MAC explosion 2) "Rosen's model ,section 5.5, where everything is built using PW [access and core], which doesn't scale because of the number of PWs. GVPLS is a third way, where is balance between MAC learning and forwarding and the number of PWs built in the core [and eventual in the access]. ... clipped Vach>> To the second point, the primary difference between the Rosen Vach>> draft and the HVPLS draft is in Vach>> naming the PWs, not in naming the VPN ID. The issue of using a Vach>> globally unique name for the VPLS Vach>> has been discussed. In an attempt to keep the signaling Vach>> compatible with draft-martini, we agreed Vach>> on using a VCID. However, there was an intent all along to Vach>> somehow make that identifier a Vach>> globally unique. Suggestions were made such as adding a VPN ID Vach>> in the optional parameters field, Vach>> etc. My last proposal was to have a bona fide VPN ID TLV in the Vach>> FEC. Vach>> Again, you mention that you would do draft-rosen. Why are you Vach>> specifying a different protocol Vach>> then? Vach>> If LDP is mandatory, why do you feel it is necessary to describe Vach>> BGP signaling in your draft? Vach>> What is different about your BGP signaling and draft-kompella? >> Vasile BGP signaling needs to be done - and we would do in a separate draft. ... clipped Vach>> Then define BGP in a separate draft. There is a claim that the informational model is the same Vach>> for BGP and LDP. However, there are a lot of different fields in Vach>> the signaling that are Vach>> described in the LDP signaling. I don't know how you are going Vach>> to add them to the BGP signaling. Vach>> Are the BGP signaling components such as label blocks and VE IDs Vach>> or site identifiers part of the Vach>> informational model? Are the LDP signaling components Vach>> If draft-rosen is your model for LDP signaling, how are you going Vach>> to keep gvpls interoperable Vach>> with HVPLS? Vasile >> this is up to VPLS/HVPLS solution - I think VPLS/HVPLS should also adopt Rosen's signaling method. VPLS/HVPLS draft is to narrow solution to solve the current market issues. It is one of the possibility. [clipped] Vach>> Some conclusions: Vach>> - GVPLS says LDP is the signaling protocol of choice Vach>> - GVPLS proposes basic interop with draft-lasserre-vkompella-vpls Vach>> - one can construct a distributed VPLS node using ethernet PWs and VPLS Vach>> - MAC-in-MAC is clearly outside the scope of the IETF Vach>> - at the Yokohama IETF we were told MAC-in-MAC was not Vach>> currently in any IEEE charter Vach>> - the BGP in GVPLS is too similar to draft-kompella-vpls to Vach>> warrant a separate draft Vach>> - the claim to identical information models between BGP and LDP signaling is not borne out Vach>> - GVPLS uses different encaps from the ones being defined in Vach>> PWE3 Vach>> Can you stil justify the GVPLS draft? >> Vasile As is today, it is not any other solution draft that described the VPLS distributed model [Rosen's attempt is just an example]. GVPLS is trying to complete this role. A VPLS network can be composed via complex access and core networks. It would be to simplistic to consider the distributed model just with the PWs on the access [the cost and the scalability do not reflect the customer's requirements and the market direction]. From scalability point of view, we just move the VPLS/HVPLS scalability problems from Mac learning to the VC-labels. Also, we need to a have model that is flexible to accommodate new protocols on the access networks, and M-in-M is one of the possibility. Probable, by the time that VPLS/HVPLS solution would move forward, it's scalability and the performance model would be already history, and M-i-M would be part of the IEEE (who knows?). A solution can be justifiable form political, market and theoretical aspects. Yes we recognize that VPLS/HVPLS doesn't scale but we would make some special assumptions like no CE as L2 switching, no IP VPN or legacy inter-working, no replication taken in consideration, no more than 1000 VPLS and so on. It's obvious - from just mathematical\theoretical considerations - that the VPLS/HVPLS doesn't scale. If we just look to the real problems (without political clout), and where GVPLS solutions is standing, we can realize the VPLS system has a very fine tunning aspects/parameters in order to scale and to perform well. Our product proofed already, that such systems, easily can scale beyond 5000 VPLS as is standing today. This is the reason the distributed model was taken serious in consideration by the SPs - the draft it self is just an expression of a solution that is working today, and it scales pretty well. As simple answer, to your question - yes, I believe that GVPLS is needed. VR> Cheers VR> Vasile -Vach ------_=_NextPart_001_01C3287D.DD19685E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: decisions on L2 solutions documents

Vach,

  See my comments below -

Cheers
 Vasile

-----Original Message-----
From: Vach Kompella [mailto:vkompella@timetra.com] =
Sent: Friday, May 30, 2003 12:50 PM
To: Radoaca, Vasile [BL60:X624:EXCH]; Mohan, Dinesh = [CAR:1A11:EXCH]; Ppvpn; Rick Wilder
Subject: RE: decisions on L2 solutions = documents


Vasile, Dinesh,

Some comments below.  I've tried to identify = Rick's, Vasile's and my comments. Outlook may mess the whole thing up, = so apologies in advance.

-Vach

.. clipped
Rick>> Here are the = questions/requests-for-clarification that came up.
Rick>>     a) how do the = discovery and signaling parts of the document
Rick>>        relate = to those described in the other solutions documents
Rick>> and
which
Rick>>        of them = are suggested to be mandatory to implement

VR> > vasile
VR> There are couple of assumptions that need to = be taken in
VR> consideration:
VR> 1)
VR> The GVPLS model, as a distributed model, = needs to have a signaling mechanism
that allows PW to be
VR> identified by VPN-ID, and the End Points = together. The
pwe3-control-protocol-02.txt draft, with
VR> Rosen's extensions to the PW Signaling = mechanism address this
VR> problem.

Vach>> As a matter of fact, Rosen's signaling = separately identifies the
Vach>> PW and
the VPN.  Think of the
Vach>> VPNID as a collection of PWs, and think = of the SAII, TAII between
Vach>> a pair
of PEs as the PW
Vach>> identifier.  So, if you want to = use the Rosen model, why write
Vach>> your own
draft?

>> Vasile
Rosen's draft presents only the extensions to the = Martini's PW model, for the control plan in order to accommodate more = general models, like the distributed model. The new GVPLS draft would = be based on Rosen signaling [PWE3-Control 02.txt].

So, the GVPLS has his own role as solution = draft.

.. clipped

Vach>> There are two issues here.  The = first is whether we need a
Vach>> separate model for distributed VPLS = or
Vach>> not.  The second is whether we = need a VPN ID.

Vach>> To the first point, Ali and Eric have = described how to use p2p
Vach>> PWs in conjuction with a = learning
Vach>> bridge in the position of the MTU to = make a distributed VPLS
Vach>> node.  don't think we need to = have
Vach>> another way to create a distributed = VPLS node.

>> Vasile
The draft-rosen-ppvpn-l2siganling-03.txt, section = 5.5 represents an example how a distributed model can be built using = the Generalized signaling method [PWE3-Control]. However, such model = doesn't scale at all, and it covers only point-to-point type = connections between U-PE devices and N-PE devices. In a more general = and useful case, is when an Ethernet access network is used between = U-PE and N-PE devices. Also, such model needs to be presented in and = end-to-end solution.

We have here a typical two extreme cases:
1) VPLS/HVPLS [your solution] where the MAC learning = is done in PE - in this repsect the scalability is very limited because = of MAC explosion

2) "Rosen's model ,section 5.5, where everything = is built using PW [access and core], which doesn't scale because of the = number of PWs.

GVPLS is a third way, where  is balance between = MAC learning and forwarding and the number of PWs built in the core = [and eventual in the access].

... clipped


Vach>> To the second point, the primary = difference between the Rosen
Vach>> draft and the HVPLS draft is in
Vach>> naming the PWs, not in naming the VPN = ID.  The issue of using a
Vach>> globally unique name for the = VPLS
Vach>> has been discussed.  In an attempt = to keep the signaling
Vach>> compatible with draft-martini, we = agreed
Vach>> on using a VCID.  However, there = was an intent all along to
Vach>> somehow make that identifier a
Vach>> globally unique.  Suggestions were = made such as adding a VPN ID
Vach>> in the optional parameters = field,
Vach>> etc.  My last proposal was to have = a bona fide VPN ID TLV in the
Vach>> FEC.
Vach>> Again, you mention that you would do = draft-rosen.  Why are you
Vach>> specifying a different protocol
Vach>> then?
Vach>> If LDP is mandatory, why do you feel it = is necessary to describe
Vach>> BGP signaling in your draft?
Vach>> What is different about your BGP = signaling and draft-kompella?

>> Vasile
BGP signaling needs to be done - and we would do in = a separate draft.

... clipped

Vach>> Then define BGP in a separate = draft.  There is a claim that the
informational model is the same
Vach>> for BGP and LDP.  However, there = are a lot of different fields in
Vach>> the signaling that are
Vach>> described in the LDP signaling.  I = don't know how you are going
Vach>> to add them to the BGP = signaling.
Vach>> Are the BGP signaling components such = as label blocks and VE IDs
Vach>> or site identifiers part of the
Vach>> informational model?  Are the LDP = signaling components

Vach>> If draft-rosen is your model for LDP = signaling, how are you going
Vach>> to keep gvpls interoperable
Vach>> with HVPLS?

Vasile >> this is up to VPLS/HVPLS solution - I = think VPLS/HVPLS should also adopt Rosen's signaling method. VPLS/HVPLS = draft is to narrow solution to solve the current market issues. It is = one of the possibility.

[clipped]


Vach>> Some conclusions:
Vach>>   - GVPLS says LDP is the = signaling protocol of choice
Vach>>   - GVPLS proposes basic = interop with draft-lasserre-vkompella-vpls
Vach>>   - one can construct a = distributed VPLS node using ethernet PWs and VPLS
Vach>>   - MAC-in-MAC is clearly = outside the scope of the IETF
Vach>>   - at the Yokohama IETF we = were told MAC-in-MAC was not
Vach>> currently in any IEEE charter
Vach>>   - the BGP in GVPLS is too = similar to draft-kompella-vpls to
Vach>> warrant a
separate draft
Vach>>   - the claim to identical = information models between BGP and LDP
signaling is not borne out
Vach>>   - GVPLS uses different = encaps from the ones being defined in
Vach>> PWE3

Vach>> Can you stil justify the GVPLS = draft?

>> Vasile
As is today, it is not any other solution draft that = described the VPLS distributed model [Rosen's attempt is just an = example].  GVPLS is trying to complete this role.

A VPLS network can be composed via complex = access  and core networks. It would be to simplistic to consider = the distributed model just with the PWs on the access [the cost and the = scalability do not reflect the customer's requirements and the market = direction]. From scalability point of view, we just move the VPLS/HVPLS = scalability problems from Mac learning to the VC-labels.

Also, we need to a  have model that is flexible = to accommodate new protocols on the access networks, and M-in-M is one = of the possibility. Probable, by the time that VPLS/HVPLS solution = would move forward, it's scalability and the performance model would be = already history, and M-i-M would be part of the IEEE (who = knows?).

 
A solution can be justifiable form political, market = and theoretical aspects.  Yes we recognize that VPLS/HVPLS doesn't = scale but we would make some special assumptions like no CE as L2 = switching, no IP VPN or legacy inter-working, no replication taken in = consideration, no more than 1000 VPLS and so on. It's obvious - from = just mathematical\theoretical considerations - that the VPLS/HVPLS = doesn't scale.

If we just look to the real problems (without = political clout), and where GVPLS solutions is standing, we can = realize  the VPLS system has a very fine tunning = aspects/parameters in order to scale and to perform well.   =

Our product proofed already, that such systems, = easily can scale beyond 5000 VPLS as is standing today. This is the = reason the distributed model was taken serious in consideration by the = SPs - the draft it self is just an expression of a solution that is = working today, and it scales pretty well.

As simple answer, to your question - yes, I believe = that GVPLS is needed.




VR> Cheers
VR>    Vasile

-Vach


------_=_NextPart_001_01C3287D.DD19685E-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun Jun 1 22:03:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09162 for ; Sun, 1 Jun 2003 22:03:26 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5222tB22854 for ; Sun, 1 Jun 2003 22:02:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5222qN05952 for ; Sun, 1 Jun 2003 22:02:52 -0400 (EDT) Date: Mon, 02 Jun 2003 10:59:26 +0900 (JST) Message-Id: <20030602.105926.07592392.suzuki.muneyoshi@lab.ntt.co.jp> To: sajassi@cisco.com Cc: erosen@cisco.com, ppvpn@nortelnetworks.com, suzuki.muneyoshi@lab.ntt.co.jp Subject: Re: VPLS model for L2VPN Framework document From: Muneyoshi Suzuki In-Reply-To: <4.3.2.7.2.20030530095451.02090ea0@airborne.cisco.com> References: <4.3.2.7.2.20030529142226.02057480@airborne.cisco.com> <20030530.133924.41674429.suzuki.muneyoshi@lab.ntt.co.jp> <4.3.2.7.2.20030530095451.02090ea0@airborne.cisco.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: suzuki.muneyoshi@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: Content-Transfer-Encoding: 7bit Ali, > Frankly I think it was a nit because Eric's wording is general and abstract > enough that applies to both models. However, in the paragraph after the > figure, there is a sentence that says:"Within the VPLS-PE, the bridge > module attaches, through an "Emulated LAN Interface" to an Emulated LAN". > If one considers an emulated LAN as an emulated VLAN, then he can interpret > this sentence as there is a bridge module for every emulated VLAN (e.g., > for every VPLS instance) which in turn becomes the multi-bridge model > within a PE. I'm not sure why the framework misleads such interpretation, however, if there is possibility of misunderstanding, it should be revised. I would like to propose the following figure for replacement of Figure 3. +---------------------------------+ | xSTP, GxRP, etc | +-------+ +-------+ | LLC | | LLC | +-------+-----------------+-------+ | \ MAC / | | (ISS) Relay (ISS) | | \ Entity / | | MAC +---------+ VPLS | | Entity | | Forwarder | | | | | +-----+-----+ +-----+-----+ | | ========= | LAN Segment IP/MPLS Network VPLS Forwarder provides MAC service defined in ISO/IEC 15802-1 and whose service primitives are compatible with MAC service specification defined in IEEE 802.3-2002. VPLS Forwarder may be supported a single point-to-point IP or MPLS connectivity or multiple connectivities that emulate a shared medium. I think there is no possibility to misunderstand the above definition. Needless to say, if the VPLS Forwarders is supported by a single full mesh connectivity, when a path is failed, there will be black-hole or loop. And if the VPLS Forwarders is supported by per VLAN meshes, it does not scale and may violate in-sequence frame delivery ;-) Thanks, From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun Jun 1 22:14:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09461 for ; Sun, 1 Jun 2003 22:14:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h522DYB26526 for ; Sun, 1 Jun 2003 22:13:34 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h522DVN11060 for ; Sun, 1 Jun 2003 22:13:31 -0400 (EDT) Date: Mon, 02 Jun 2003 10:06:29 +0800 From: shengcheng Subject: Fw: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN To: isis-wg@ietf.org, ppvpn@nortelnetworks.com Cc: stefano previdi , manav@samsung.com, lidefeng@huawei.com, heqian@huawei.com, liu_yu@huawei.com Message-id: <003d01c328ab$94f35700$ca326e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: shengc@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Dear all: The below are several emails of the discussion of one doubt about the draft "IS-IS as PE/CE routing protocol in BGP/MPLS/VPN". We wonder if the flooding of LSP accross the Sham link is necessary. According to my opinion, the flooding is not necessary, because sham link is just used to make sure the right next-hop of the VPN-IP route of CE. As per stefano 's view, the flooding is required. But we all agree that it is difficult to flooding the LSP for IS-IS accrossthe sham link because IS-IS is not encapsulated in IP packets as OSPF. Anyone are interested in this topic and can give some good suggestion ? thanks in advance! Sheng ----- Original Message ----- From: "stefano previdi" To: "shengcheng" Cc: ; ; ; Sent: Thursday, May 29, 2003 9:09 PM Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > At 12:49 PM 5/29/2003, shengcheng wrote: > >Stefano: > > > >I don't think the flooding is necessary when the backdoor link fail. > >First, the creation of sham link is just to remove the negative affect by > >backdoor link. when backdoor link fail, sham link is meaningless in fact. > >Second, even we doesn't flush the lsa soon after the backdoor link fail, the > >right result of IS-IS spf route computation will not be affected. > > > I don't agree. If the backdoor link fails, then the two sites cannot > receive the lsp's of the other side. So whatever happens in the one > site will be hidden to the other. However, the sham-link will still > claim connectivity between the two. > > So, the consequence of this is that you have routing inconsistency > between sites with all the issues that are related ti it. > > This is the reason why ospf does flooding over sham-link as well. > > > >With the age of the LSA of the other site's PE and CE in one side, > >the database of the virtual one area (i mean "virtual" is because of sham link) > >may be destroied, but the route table on PE and CE will be still right . > > > >Flooding over sham-link with encapsulation of isis packets into ip almost > >can't be accepted. > > > I know... but you don't have the choice if you want to be sure routing > information is consistent across sites. > > Link-state protocols require that everyone get flooded with all routing > information. If you claim connectivity (sham-link) then you have to be > sure flooding will ALWAYS happen everywhere... which is not the case if > the bakdoor link fails. > > One solution is to shutdown the sham link if the backdoor fails but in > order for this to be possible you have to detect such failure... not > easy without running additional SPFs. > > s. > > > >expect your kindly further discussion.. > > > >regards > >- sheng > > > >----- Original Message ----- > >From: "stefano previdi" > >To: "shengcheng" ; > >Cc: ; ; > >Sent: Thursday, May 29, 2003 3:18 PM > >Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > > > > > >On Thursday 29 May 2003 04:11, shengcheng wrote: > >> > >> > >> Dear Stefano and Manav : > >> Thanks for your attention to our draft of ISIS as PE/CE > >> routing protocol in BGP/MPLS VPN. > >> Unluckily, my email box doesn't work normally recently. > >> This is why we give such a late response. > >> Your issue is really very helpful. We are trying to > >> deliver next version of the draft to update the existing > >> problem(including your issues) in the current version this week. > >> Kindly wish you continue to pay attention to the draft ! > >> > >> thanks & regards > >> Sheng > > > >there is something else that need to be worked out. If the > >backdoor link between two sites failed, then the two sites > >do not receive LSPs anymore but still believe they have > >full connectivity through the sham-link. > > > >I'm affraid we will have to specify that flooding should > >occur over the sham link. This complexify a bit the > >architecture (not to mention that flooding over sham-link > >implies encapsulation of isis packets into ip). > > > >s. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun Jun 1 22:18:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09613 for ; Sun, 1 Jun 2003 22:18:24 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h522HrB00108 for ; Sun, 1 Jun 2003 22:17:53 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h522HoO15103 for ; Sun, 1 Jun 2003 22:17:50 -0400 (EDT) Date: Mon, 02 Jun 2003 10:10:02 +0800 From: shengcheng Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN To: isis-wg@ietf.org, ppvpn@nortelnetworks.com Cc: stefano previdi , manav@samsung.com, liu_y@huawei.com, lidefeng@huawei.com, heqian@huawei.com Message-id: <005201c328ac$144d44c0$ca326e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002c01c32587$a594a220$ca326e0a@HUAWEI.COM> <200305290718.h4T7I6R21806@strange-brew.cisco.com> <4.3.2.7.2.20030529150445.01a06980@strange-brew.cisco.com> <4.3.2.7.2.20030530101958.0340d008@strange-brew.cisco.com> X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: shengc@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT This is for your information. Thanks & Regards Sheng ----- Original Message ----- From: "stefano previdi" To: "shengcheng" Cc: ; ; ; Sent: Friday, May 30, 2003 4:30 PM Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > At 05:58 AM 5/30/2003, shengcheng wrote: > >Stefano: > > As you have said "So, the consequence of this is that you have routing inconsistency > > between sites with all the issues that are related ti it." . What do you mean the "routing inconsistency?" > > > whatever changes in one site will be unknown to the other > one. This may result in routing loops (e.g.: a prefix is > withdrawn from one site and advertised by another one). > > sham-link is considered as a p2p link. If flooding is > stopped because there is no other connectivity than the > sham-link, then the flooding scheme is broken. > > > >Yes the database sychronization has been destroied, but i still think the route is right in PE/CE of > >both side. > > > The PEs _may_ have correct information but not the CEs and > not all the other routers in both sites. CEs and sites will > only have local information and out-of-date information > about the other site. > > > > It is really a disaster for IS-IS to encapsulate its packet in IP format, which is the only way to > >flood the LSP accross the sham link in my opinion. > > > if you want to flood between sites you have to use IP. Note > that you will encap also CSNP/PSNP packets because of reliable > flooding (IP is just the encap). > > > >I think your suggention about shutting down the sham > >link when detecting the backdoor fails is a good idea. Maybe it is the only method that deserve our > >further attention when we have to fufill the database synchronization of IS-IS as a link state protocol. > > > detecting the failure of the backdoor is not trivial. the PE > doesn't know who is the backdoor. The only way to do so is to > run an additional SPF with following constraints: > > 1- do not use the sham-link in the computation > 2- check reachability of the other PE > > if the other PE is found after this special SPF than it means > the backdoor works. If not it means that the sham-link is the > only way to reach the other PE. But you understand that this > means the PE has to run one more SPF at each network change. > > So now the question is: what do we do if the backdoor link > fails ? If you just shutdown the sham-link, then you completely > lose connectivity between sites and it is not the scope of the > game... > > So the alternative is to _always_ redistribute sites routes > into BGP (even if you do flooding over sham-link) so when the > sham-link is shutdown you can rely on mp-bgp to propagate routes > between sites. This has the side effect of flooding twice the > routes... > > s. > > > > >Do you have other constructive suggestion? > > > > > >thanks®ards > >Sheng > > > >----- Original Message ----- > >From: "stefano previdi" > >To: "shengcheng" > >Cc: ; ; ; > >Sent: Thursday, May 29, 2003 9:09 PM > >Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > > > > > >> At 12:49 PM 5/29/2003, shengcheng wrote: > >> >Stefano: > >> > > >> >I don't think the flooding is necessary when the backdoor link fail. > >> >First, the creation of sham link is just to remove the negative affect by > >> >backdoor link. when backdoor link fail, sham link is meaningless in fact. > >> >Second, even we doesn't flush the lsa soon after the backdoor link fail, the > >> >right result of IS-IS spf route computation will not be affected. > >> > >> > >> I don't agree. If the backdoor link fails, then the two sites cannot > >> receive the lsp's of the other side. So whatever happens in the one > >> site will be hidden to the other. However, the sham-link will still > >> claim connectivity between the two. > >> > >> So, the consequence of this is that you have routing inconsistency > >> between sites with all the issues that are related ti it. > >> > >> This is the reason why ospf does flooding over sham-link as well. > >> > >> > >> >With the age of the LSA of the other site's PE and CE in one side, > >> >the database of the virtual one area (i mean "virtual" is because of sham link) > >> >may be destroied, but the route table on PE and CE will be still right . > >> > > >> >Flooding over sham-link with encapsulation of isis packets into ip almost > >> >can't be accepted. > >> > >> > >> I know... but you don't have the choice if you want to be sure routing > >> information is consistent across sites. > >> > >> Link-state protocols require that everyone get flooded with all routing > >> information. If you claim connectivity (sham-link) then you have to be > >> sure flooding will ALWAYS happen everywhere... which is not the case if > >> the bakdoor link fails. > >> > >> One solution is to shutdown the sham link if the backdoor fails but in > >> order for this to be possible you have to detect such failure... not > >> easy without running additional SPFs. > >> > >> s. > >> > >> > >> >expect your kindly further discussion.. > >> > > >> >regards > >> >- sheng > >> > > >> >----- Original Message ----- > >> >From: "stefano previdi" > >> >To: "shengcheng" ; > >> >Cc: ; ; > >> >Sent: Thursday, May 29, 2003 3:18 PM > >> >Subject: Re: About IS-IS as PE/CE routing protocol in BGP/MPLS/VPN > >> > > >> > > >> >On Thursday 29 May 2003 04:11, shengcheng wrote: > >> >> > >> >> > >> >> Dear Stefano and Manav : > >> >> Thanks for your attention to our draft of ISIS as PE/CE > >> >> routing protocol in BGP/MPLS VPN. > >> >> Unluckily, my email box doesn't work normally recently. > >> >> This is why we give such a late response. > >> >> Your issue is really very helpful. We are trying to > >> >> deliver next version of the draft to update the existing > >> >> problem(including your issues) in the current version this week. > >> >> Kindly wish you continue to pay attention to the draft ! > >> >> > >> >> thanks & regards > >> >> Sheng > >> > > >> >there is something else that need to be worked out. If the > >> >backdoor link between two sites failed, then the two sites > >> >do not receive LSPs anymore but still believe they have > >> >full connectivity through the sham-link. > >> > > >> >I'm affraid we will have to specify that flooding should > >> >occur over the sham link. This complexify a bit the > >> >architecture (not to mention that flooding over sham-link > >> >implies encapsulation of isis packets into ip). > >> > > >> >s. > >> > From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun Jun 1 23:10:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10312 for ; Sun, 1 Jun 2003 23:10:14 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5239hB16837 for ; Sun, 1 Jun 2003 23:09:43 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5239eX12012 for ; Sun, 1 Jun 2003 23:09:41 -0400 (EDT) Date: Mon, 02 Jun 2003 11:06:13 +0800 From: lidefeng Subject: Call for discussion on draft-libin-hierarchy-pe-bgp-mpls-vpn-02.txt To: ppvpn@nortelnetworks.com Message-id: <000c01c328b3$ecf45b40$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT The latest version of draft about hierarchy of PE in BGP/MPLS VPN(draft-libin-Hierarchy-pe-bgp-mpls-vpn-02.txt) is attached,and the updation from last version is as following: a. Add the interoperability statement of HoPE and [2547bis]; b. Add the section to resolve the scalability of BGP/MPLS VPN in access the customer in the lower layer network. c. Correct some typo error. The HoPE solution and the HoPE based solution can resolve the scalability problem in access the lower layer customer to BGP/MPLS VPN. This draft is presented on the 56th IETF PPVPN WG meeting,which was not carefully reviewed,I think,however,access to different layer customer is a very important problem for Service Provider and customer,which can't be resolved by normal 2547bis VPN. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 08:52:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05134 for ; Mon, 2 Jun 2003 08:52:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52Cq7716645 for ; Mon, 2 Jun 2003 08:52:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52Cq2p07464 for ; Mon, 2 Jun 2003 08:52:03 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: vkompella@timetra.com, "Hamid Ould-Brahim" , "Vasile Radoaca" , "Dinesh Mohan" , Ppvpn , Rick Wilder Subject: PW Name, VCID/VPNID and VPLS... Date: Mon, 2 Jun 2003 08:50:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32905.7D2198F8" 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_01C32905.7D2198F8 Content-Type: text/plain; charset="iso-8859-1" Vach, [changed the subject to reflect the topic being discussed]... >Two meta-points. First, Eric has resubmitted his draft to >ppvpn as draft-rosen-ppvpn-l2-signaling-03.txt. Yes and it is compatible with pwe3 control draft. > Second, why have two FECs for PWE3? On that I agree with you. It looks like this is the result of two things: a) PWE3/Martini draft didn't take into account the l2vpn problem and the ability to support multiple provisioning models besides just double-sided provisioning/signaling. b) The VCID when reused in a VPLS context changed from representing the PWID to representing a VPLS membership scheme (with all the limitations of a four-octets global id). In other words this is a *bug* resulting from reusing exactly PWE3 initial work to accommodate l2vpn work without taking into account the nature of l2vpn requirements and provisioning models... I think pwe3 wg should have as well addressed the question of provisioning models for a pseudo-wire in early stages not just recently. Ironically, neither the pwe3 requirement draft nor the architecture draft addressed the "pw [multiple] provisioning models" and yet pwe3 control draft contains signaling specification for multiple provisioning models. [Something that needs to be fixed!]. > Surely, if we use the Generalized ID FEC, then we don't need fec type 128. > Let's simplify. >I have no problem with the "Generalized ID FEC TLV" concept. >In fact, we are probably in violent agreement on that. >The (minor) issue is what it looks like: > > AGI: > VPN ID TLV: The AGI is actually The octet string contains a globally unique ID (taken among formats that allow building global unique id such as RD/RT, 2685, etc). Honestly, I don't see why a solution needs to support multiple types of vpn-ids. If one wants a VPN-ID which uniquely identifies a VPN, is a name for a VPN, works across domains, is used in management, etc, then use RFC2685, it is already a standard, and has already been used before (no need to have multiple types). However, if there is a need for multiple globally unique ids (which I think is the case here), then let's not call that VPN-IDs but just globally unique id, defined for that specific solution. Of course the solution needs to describe how these ids are constructed (for example use RT, embed 2685, etc) and more importantly how these ids are used. If we insist on multiple VPN-IDs then we need to ask the question whether we want to extend/obsolete RFC2685...My suggestion is not to take that route and avoid the problem altogether by using globally unique ids and defining them as such. > But where I have considerably more difference of opinion is how > to name a PW. In a VPWS or a VPLS, I would like to be able to name > each constituent PW. So, I want a VPN ID that contains a number of PWs. > pwe3-control says use a 32-bit number that is unique between a pair of PEs. > It also qualifies that 32-bit number with a VC type. That's probably not > necessary, and some of the implementations that I have had the pleasure > of working with agree with me. In other words, a PW is named > (PE1, VC type, VCID, PE2). Okay. I understand your point. Actually what you're saying is we should have a requirement to support a PWID (VCID) in order to uniquely identify the PW within a VPLS in addition to the ability to uniquely identify a VPLS using a VPN ID or global unique id. In that case, I am not sure we can reuse exactly the same provisioning model and semantic of VCID. It looks to me that if a VCID is needed (which I think can be optional for VPLS), instead of using the traditional martini PWid FEC and extending the group id, why not use the Generalized ID FEC and encode the VCID as an optional parameter. > I would suggest that the full name of a PW is > {VPNID (PE1, VC type, VCID, PE2)}. I assume in your suggestion of using a VCID per PW (as in Martini case) implies the provisioning model is a double-sided provisioning of pw. That basically rules out the ability to support a VPN auto-discovery mechanism for VPLS service (since both ends have apriori knowledge of the pw). This has implications on scaling the vpls service... > draft-rosen suggests that a PW is named (PE1, SAII, TAII, PE2). I think in draft-rosen the PW is named based on the pair: , PE2, >, < PE2, , PE1, If we use the VCID as option (as a suggestion), then the pseudo-wire will still be identified with a pair of LSP as above with the addition of a VCID option. > I am not not convinced of the benefits of this naming scheme. I think the ability to assign a VCID (if needed) should not constrain the ability to use a Generalized ID FEC outside the traditional martini PWid FEC. The benefits is the same flexible signaling scheme can be used for multiple l2vpn services, and multiple provisioning models... > Eric and I have exchanged some emails in this regard, > and are continuing to do so. > Finally, draft-rosen says the SAII and TAII are 0 for VPLS. > That means that there is no name for the PW between a pair of VPLS nodes. > > That may generally be ok since the full name of a PW is > {VPNID, (PE1, 0, 0, PE2)} and we generally have only a single > PW between a pair of nodes in a VPLS. Note that in distributed VPLS case, the SAII and TAII are not null and are actually used to identify the U-PE. So the use of non null SAII, and TAII has applicability in the context of VPLS. There is benefit in having these fields for VPLS as well... > However, when we have a VPLS node which has a pair of spokes to the > same MTU (HVPLS situation), we have to name >the PWs differently. > This scenario comes up in certain regulatory environments where the > MTU owner is only allowed to provide L2 transport service. > Consider the following physical topology. > CE1------------MTU-------------PE > | > CE2-------------- >In an unregulated case, the MTU could host a FIB, and turn packets around >between the two CEs. However, in a regulated environment, the PE may have >to host the FIB. We have then two spokes from the PE to the MTU, one for >CE1 and one for CE2. I think you meant two spoke connections from PE to the MTU, each spoke connection is associated with a particular CE. > CE1------------\ /-----------\ > MTU PE > CE2=============/ \=============/ >I want to be able to name each spoke. Let me rewrite your example with some labels: CE1------------\ /---- SPC1 ------\ MTU PE CE2=============/ \====== SPC2 ====/ SP1,2 are Spoke Connections for each CE. > On the PE side, I have a FIB. In draft-rosen, the PE would name the SAII 0. Although hierarchical VPLS wasn't addressed in Eric's draft. You may follow similar procedures with distributed VPLS for that specific scenario (or for all hvpls), for a PW signaled by the MTU for SPC1, the SAII contains an MTU id, let say i, and for SPC2, the SAII will carry an MTU id of j (as an example). > The PE would have to know the name of the TAII on the MTU going to CE1. Same thing, for signaled PW from PE to MTU, the SAII will be null, and TAII will be set to the MTU id for that spoke connection (for example "i"). PW will be used to disambiguate between CEs. A packet received on SPC1 for example will be forwarded directly to CE1. > The PE would have to know the name of the TAII on the MTU going to CE2. > Otherwise, there would be no names for these two PWs. No there is. As I said HVPLS, DVPLS are special cases when generalized id FEC is used. The two PWs will still be identified with the pair mentioned before (and that includes the SAII, TAII, and AGI). From signaling point of view it is the same. >In summary: > - my proposal would remove the limited use Group ID field > (actually, Eric pointed out I had no use for it) One can view it as well as adding a third FEC option in addition to the two existing ones. This will look like a a "double" bug in PWE3 control draft :-). > - my proposal requires a VPN ID that groups PWs across the > network that belong to the same VPN > - my proposal uses the VCID field to name a PW within the VPN With the adverse effect that not only a VPN-ID needs to be configured but as well a VCID needs to be configured on both ends of the PW wire. My suggestion is if an AGI is used, then the VCID can be optional, and need not be configured. > - the delta between existing fec type 128 in pwe3-control and > my proposal is minimal Does it really matter the minimum delta given that we will end up with a new style of FEC being signaled in addition to the current PWid FEC. > - I feel that draft-rosen suggests a much broader change > (with additional benefits, but do we need them?) I would say it has applicability for multiple l2vpn services and deployment scenarios. In my view it's worth considering instead of creating a brand new FEC that requires double-sided provisioning for each pw making up the vpls service. Hamid. -Vach -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Friday, May 30, 2003 10:37 AM To: vkompella@timetra.com; Vasile Radoaca; Dinesh Mohan; Ppvpn; Rick Wilder Subject: RE: decisions on L2 solutions documents Vach, A comment on vpn-id/martini... > Vach>> naming the PWs, not in naming the VPN ID. The issue > of using a globally > unique name for the VPLS > Vach>> has been discussed. In an attempt to keep the > signaling compatible with > draft-martini, we agreed > Vach>> on using a VCID. I think in the pw control draft (draft-ietf-pwe3-control-protocol-02.txt), Eric's signaling extensions have been added that can accommodate as well a global unique id. Why not use the control draft extensions. >However, there was an intent all > along to somehow make > that identifier a > Vach>> globally unique. Suggestions were made such as adding > a VPN ID in the > optional parameters field, > Vach>> etc. My last proposal was to have a bona fide VPN ID > TLV in the FEC. > Yes. But that is not defined in pwe control draft and if added it looks redundant to Eric's additions. I requested before clarifications on the use of VPN-ID TLV (which was left unanswered btw - see the archive) http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305&L=ppvpn&T=0&O= A&P=980. I don't see why we still didn't resolve that problem. Why not just adopt the pwe3 control draft's Generalized ID FEC element instead of defining another VPN-ID TLV (which I assume if done needs to be captured in the same draft). Is there any reason why not? Hamid. ------_=_NextPart_001_01C32905.7D2198F8 Content-Type: text/html; charset="iso-8859-1" PW Name, VCID/VPNID and VPLS...

Vach,

[changed the subject to reflect the topic being discussed]...

>Two meta-points.  First, Eric has resubmitted his draft to
>ppvpn as draft-rosen-ppvpn-l2-signaling-03.txt.  

Yes and it is compatible with pwe3 control draft.

> Second, why have two FECs for PWE3?  

On that I agree with you. It looks like this is the result of two things:

a) PWE3/Martini draft didn't take into account the l2vpn problem
   and the ability to support multiple provisioning models besides
   just double-sided provisioning/signaling.

b) The VCID when reused in a VPLS context changed from representing
   the PWID to representing a VPLS membership scheme (with
   all the limitations of a four-octets global id).

In other words this is a *bug* resulting from reusing exactly
PWE3 initial work to accommodate l2vpn work without taking into account
the nature of l2vpn requirements and provisioning models...

I think pwe3 wg should have as well addressed the question of
provisioning models for a pseudo-wire in early stages not just
recently. Ironically, neither the pwe3 requirement draft nor
the architecture draft addressed the "pw [multiple] provisioning models"
and yet pwe3 control draft contains signaling specification
for multiple provisioning models. [Something that needs to be
fixed!].

> Surely, if we use the Generalized ID FEC, then we don't need fec type 128. 
> Let's simplify.

>I have no problem with the "Generalized ID FEC TLV" concept. 
>In fact, we are probably in violent agreement on that. 
>The (minor) issue is what it looks like:
>
> AGI: <type> <octet-string>
> VPN ID TLV: <type> <length> <octet-string>

The AGI is actually  <one-octet-length> <octet-string>

The octet string contains a globally unique ID
(taken among formats that allow building global
unique id such as RD/RT, 2685, etc).

Honestly, I don't see why a solution needs to support multiple
types of vpn-ids.

If one wants a VPN-ID which uniquely identifies a VPN, is
a name for a VPN, works across domains, is used in management,
etc, then use RFC2685, it is already a standard, and has already
been used before (no need to have multiple types).

However, if there is a need for multiple globally unique ids
(which I think is the case here), then let's not call that VPN-IDs
but just globally unique id, defined for that specific solution.
Of course the solution needs to describe how these ids are
constructed (for example use RT, embed 2685, etc) and more
importantly how these ids are used.

If we insist on multiple VPN-IDs then we need to ask the question
whether we want to extend/obsolete RFC2685...My suggestion is
not to take that route and avoid the problem altogether
by using globally unique ids and defining them as such.

> But where I have considerably more difference of opinion is how
> to name a PW.  In a VPWS or a VPLS, I would like to be able to name
> each constituent PW.  So, I want a VPN ID that contains a number of PWs. 
> pwe3-control says use a 32-bit number that is unique between a pair of PEs. 
> It also qualifies that 32-bit number with a VC type.  That's probably not
> necessary, and some of the implementations that I have had the pleasure
> of working with agree with me.  In other words, a PW is named
> (PE1, VC type, VCID, PE2).

Okay. I understand your point. Actually what you're saying is we should
have a requirement to support a PWID (VCID) in order to uniquely identify
the PW within a VPLS in addition to the ability to
uniquely identify a VPLS using a VPN ID or global unique id.

In that case, I am not sure we can reuse exactly the same
provisioning model and semantic of VCID.

It looks to me that if a VCID is needed (which I
think can be optional for VPLS), instead of using the traditional
martini PWid FEC and extending the group id, why not use the
Generalized ID FEC and encode the VCID as an optional parameter.

> I would suggest that the full name of a PW is
> {VPNID (PE1, VC type, VCID, PE2)}.

I assume in your suggestion of using a VCID per PW (as in Martini
case) implies the provisioning model is a double-sided
provisioning of pw. That basically rules out the ability
to support a VPN auto-discovery mechanism for  VPLS service
(since both ends have apriori knowledge of the pw).
This has implications on scaling the vpls service...

> draft-rosen suggests that a PW is named (PE1, SAII, TAII, PE2). 

I think in draft-rosen the PW is named based on the pair:

  <PE1, <AGI, AII1>, PE2, <AGI, AII2>>,      
  < PE2, <AGI, AII2>, PE1, <AGI, AII1>

If we use the VCID as option (as a suggestion), then the
pseudo-wire will still be identified with a pair of LSP as above with
the addition of a VCID option.

>  I am not not convinced of the benefits of this naming scheme.  

I think the ability to assign a VCID (if needed) should not
constrain the ability to use a Generalized ID FEC
outside the traditional martini PWid FEC. The benefits is
the same flexible signaling scheme can be used for multiple
l2vpn services, and multiple provisioning models...

> Eric and I have exchanged some emails in this regard,
> and are continuing to do so.

> Finally, draft-rosen says the SAII and TAII are 0 for VPLS. 
> That means that there is no name for the PW between a pair of VPLS nodes. 
>
>  That may generally be ok since the full name of a PW is
> {VPNID, (PE1, 0, 0, PE2)} and we generally have only a single
>  PW between a pair of nodes in a VPLS.

Note that in distributed VPLS case, the SAII and TAII are not null
and are actually used to identify the U-PE. So the use of non null
SAII, and TAII has applicability in the context of VPLS. There is
benefit in having these fields for VPLS as well...


> However, when we have a VPLS node which has a pair of spokes to the
> same MTU (HVPLS situation), we have to name >the PWs differently.  
> This scenario comes up in certain regulatory environments where the
> MTU owner is only allowed to provide L2 transport service.   
> Consider the following physical topology.

>   CE1------------MTU-------------PE
>                   |
>   CE2--------------

>In an unregulated case, the MTU could host a FIB, and turn packets around
>between the two CEs.  However, in a regulated environment, the PE may have
>to host the FIB.  We have then two spokes from the PE to the MTU, one for
>CE1 and one for CE2.

I think you meant two spoke connections from PE to the MTU, each spoke
connection is associated with a particular CE.


>   CE1------------\    /-----------\
>                    MTU             PE
>   CE2=============/  \=============/

>I want to be able to name each spoke.  

Let me rewrite your example with some labels:

   CE1------------\    /---- SPC1 ------\
                    MTU                PE
   CE2=============/  \====== SPC2 ====/
 

SP1,2 are Spoke Connections for each CE.

> On the PE side, I have a FIB.  In draft-rosen, the PE would name the SAII 0.  

Although hierarchical VPLS wasn't addressed in Eric's draft. You may follow
similar procedures with distributed VPLS for that specific
scenario (or for all hvpls), for a PW signaled by the MTU for
SPC1, the SAII contains an MTU id, let say i, and for SPC2, the SAII will
carry an MTU id of j (as an example).

> The PE would have to know the name of the TAII on the MTU going to CE1.  

Same thing, for signaled PW from PE to MTU, the SAII will be null,
and TAII will be set to the MTU id for that spoke connection
(for example "i").

PW will be used to disambiguate between CEs. A packet received on
SPC1 for example will be forwarded directly to CE1.

> The PE would have to know the name of the TAII on the MTU going to CE2. 
> Otherwise, there would be no names for these two PWs.

No there is. As I said HVPLS, DVPLS are special cases when
generalized id FEC is used. The two PWs will still be
identified with the pair mentioned before (and that includes
the SAII, TAII, and AGI). From signaling point of view
it is the same.

>In summary:
> - my proposal would remove the limited use Group ID field
> (actually, Eric pointed out I had no use for it)

One can view it as well as adding a third FEC option
in addition to the two existing ones.  This will look like a
a "double" bug in PWE3 control draft :-).

>  - my proposal requires a VPN ID that groups PWs across the
> network that belong to the same VPN
> - my proposal uses the VCID field to name a PW within the VPN

With the adverse effect that not only a VPN-ID needs to
be configured but as well a VCID needs to be configured
on both ends of the PW wire. 

My suggestion is if an AGI is used, then
the VCID can be optional, and need not be configured.
 
> - the delta between existing fec type 128 in pwe3-control and
> my proposal is minimal

Does it really matter the minimum delta given that we will end up with
a new style of FEC being signaled in addition to
the current PWid FEC.

> - I feel that draft-rosen suggests a much broader change
> (with additional benefits, but do we need them?)
 
I would say it has applicability for multiple l2vpn services
and deployment scenarios. In my view it's worth considering
instead of creating a brand new FEC that requires double-sided
provisioning for each pw making up the vpls service.

Hamid.

-Vach

-----Original Message-----
From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com]
Sent: Friday, May 30, 2003 10:37 AM
To: vkompella@timetra.com; Vasile Radoaca; Dinesh Mohan; Ppvpn; Rick Wilder
Subject: RE: decisions on L2 solutions documents


Vach,

A comment on vpn-id/martini...

> Vach>> naming the PWs, not in naming the VPN ID.  The issue
> of using a globally
> unique name for the VPLS
> Vach>> has been discussed.  In an attempt to keep the
> signaling compatible with
> draft-martini, we agreed
> Vach>> on using a VCID. 

I think in the pw control draft (draft-ietf-pwe3-control-protocol-02.txt),
Eric's signaling extensions have been added that can
accommodate as well a global unique id. Why not use
the control draft extensions.



>However, there was an intent all
> along to somehow make
> that identifier a
> Vach>> globally unique.  Suggestions were made such as adding
> a VPN ID in the
> optional parameters field,
> Vach>> etc.  My last proposal was to have a bona fide VPN ID
> TLV in the FEC.
>

Yes. But that is not defined in pwe control draft and if added
it looks redundant to Eric's additions. I requested before
clarifications on the use of VPN-ID TLV (which was left
unanswered btw - see the archive)
 
http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305&L=ppvpn&T=0&O=A&P=980.

I don't see why we still didn't resolve that problem.

Why not just adopt the pwe3 control draft's Generalized ID
FEC element instead of defining another VPN-ID TLV
(which I assume if done needs to be captured in the same
draft).

Is there any reason why not?

Hamid.

------_=_NextPart_001_01C32905.7D2198F8-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 10:24:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09707 for ; Mon, 2 Jun 2003 10:24:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52EOI728141 for ; Mon, 2 Jun 2003 10:24:18 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52EOF323485 for ; Mon, 2 Jun 2003 10:24:15 -0400 (EDT) Message-Id: <200306021421.h52ELTkQ005811@rtp-core-1.cisco.com> To: vkompella@timetra.com cc: "Hamid Ould-Brahim" , "Vasile Radoaca" , "Dinesh Mohan" , "Ppvpn" , "Rick Wilder" Subject: Re: decisions on L2 solutions documents In-reply-to: Your message of Fri, 30 May 2003 12:10:43 -0700. 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.3 (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, 02 Jun 2003 10:21:29 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,mohand@nortelnetworks.com,vasile@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Vach> I would suggest that the full name of a PW is {VPNID (PE1, VC type, Vach> VCID, PE2)}. Vach> draft-rosen suggests that a PW is named (PE1, SAII, TAII, PE2) Whether the VC type is part of the name is orthogonal; either proposal could decide to use it or not, as it is always present. In my proposal, you've left out the AGI above, and the AGI is really a VPNID. The SAII and TAII are really VCids, so I'd say the difference is: Vach: Eric: That is, the only difference is whether to have a VCid which is unique for a given pair of PEs, and have that VCid provisioned at both ends, vs. whether to allow each end to use a different VCid. By allowing each endpoint to have a different VCid, it is possible to accommodate both the "auto-discovered VPWS full mesh" scheme and the "distributed VPLS" scheme, as well as some possible future extensions such as switched VCs. Vach> Finally, draft-rosen says the SAII and TAII are 0 for VPLS. That Vach> means that there is no name for the PW between a pair of VPLS nodes. Vach> That may generally be ok since the full name of a PW is {VPNID, (PE1, Vach> 0, 0, PE2)} and we generally have only a single PW between a pair of Vach> nodes in a VPLS. Yes, when there is only a single PW between a pair of nodes in a VPLS, there is no need to assign a name to the PW, other than the VPNid. Vach> However, in a regulated environment, the PE may have to host the FIB. Vach> We have then two spokes from the PE to the MTU, one for CE1 and one Vach> for CE2. Vach> CE1------------\ /-----------\ Vach> MTU PE Vach> CE2=============/ \=============/ Vach> I want to be able to name each spoke. On the PE side, I have a FIB. In Vach> draft-rosen, the PE would name the SAII 0. The PE would have to know the Vach> name of the TAII on the MTU going to CE1. The PE would have to know the Vach> name of the TAII on the MTU going to CE2. Otherwise, there would be no Vach> names for these two PWs. In this case, I would just have the MTU assign different SAIIs to the PWs, e.g., 1 and 2. The two PWs would be and . I think this is exactly the same as in your proposal. So in my view, the two proposals are semantically exactly the same for VPLS and HVPLS, it's just that one is able to handle additional cases and the other isn't. Vach> In summary: Vach> - my proposal would remove the limited use Group ID field (actually, Vach> Eric pointed out I had no use for it) Both proposals agree on this. Vach> - my proposal requires a VPN ID that groups PWs across the network that Vach> belong to the same VPN Both proposals agree on this. Vach> - my proposal uses the VCID field to name a PW within the VPN Both proposals agree on this. Vach> - the delta between existing fec type 128 in pwe3-control and my Vach> proposal is minimal Eliminating the group id and adding a VPNid is "minimal"? Vach> - I feel that draft-rosen suggests a much broader change (with Vach> additional benefits, but do we need them?) We could compromise by allowing a one-name format and a two-name format, keeping the one-name format for VPLS and HVPLS, and using the two-name format only where is it really required. However, I think that compromise would result in something which is more complicated than it needs to be. Another possible difference between the proposals has to do with whether the setting up of an LSP in one direction can trigger the setting up of the LSP in the other direction, or whether the two directions need to be set up independently. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 11:08:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11023 for ; Mon, 2 Jun 2003 11:08:14 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52F7h722049 for ; Mon, 2 Jun 2003 11:07:44 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52F7e503787 for ; Mon, 2 Jun 2003 11:07:41 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: erosen@cisco.com, vkompella@timetra.com Cc: "Vasile Radoaca" , "Dinesh Mohan" , Ppvpn , Rick Wilder Subject: RE: decisions on L2 solutions documents Date: Mon, 2 Jun 2003 11:05:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32918.6D96560E" 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_01C32918.6D96560E Content-Type: text/plain; charset="iso-8859-1" Eric, > > Vach: > > Eric: > Yes. I think Vach wanted to keep exactly the same model for PW provisioning as in Martini without configuring SAII, TAII to reflect VCID. But I agree from signaling point of view it is the same. > That is, the only difference is whether to have a VCid which > is unique for a > given pair of PEs, and have that VCid provisioned at both > ends, vs. whether > to allow each end to use a different VCid. > Yes. I think that is the difference, and I say ability to support an auto-discovery mechanism is an important aspect of a VPLS solution. If both ends of pw are configured then there is no point of using an auto-discovery mechanism. Not sure that is acceptable. [clipped]... > > We could compromise by allowing a one-name format and a > two-name format, > keeping the one-name format for VPLS and HVPLS, and > using the two-name > format only where is it really required. However, I think > that compromise > would result in something which is more complicated than it > needs to be. > I'd rather prefer one format. Let's not redo the same thing as in pw control draft. Two exclusive formats may imply the need to support compatibility procedures, etc (and I don't see how interoperability can be achieved with two formats). Hamid. ------_=_NextPart_001_01C32918.6D96560E Content-Type: text/html; charset="iso-8859-1" RE: decisions on L2 solutions documents

Eric,

>
> Vach: <VPNid, PE1, PE2, Vcid>
>
> Eric: <VPNid, PE1, PE2, VCid at PE1, VCid at PE2>
>

Yes. I think Vach wanted to keep exactly
the same model for PW provisioning as
in Martini without configuring SAII, TAII to
reflect VCID. But I agree from
signaling point of view it is the same.


> That is, the only difference is whether to have a VCid which
> is unique for a
> given pair of PEs, and have  that VCid provisioned at both
> ends, vs. whether
> to allow each end to use a different VCid.
>

Yes. I think that is the difference, and I say ability
to support an auto-discovery mechanism is an important
aspect of a VPLS solution. If both ends of pw are configured
then there is no point of using an auto-discovery
mechanism. Not sure that is acceptable.

[clipped]...

>
> We could  compromise by  allowing a one-name  format and a 
> two-name format,
> keeping  the one-name  format for  VPLS and  HVPLS, and 
> using  the two-name
> format only where  is it really required.  However,  I think
> that compromise
> would result in something which is more complicated than it
> needs to be.
>

I'd rather prefer one format. Let's not redo the same thing
as in pw control draft. Two exclusive formats may imply the
need to support compatibility procedures, etc (and I don't see
how interoperability can be achieved with two formats).

Hamid.

------_=_NextPart_001_01C32918.6D96560E-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 12:05:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13463 for ; Mon, 2 Jun 2003 12:05:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52G4Y717043 for ; Mon, 2 Jun 2003 12:04:35 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52G4WD00262 for ; Mon, 2 Jun 2003 12:04:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20030602085609.0322fcc0@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Jun 2003 08:59:58 -0700 To: PPVPN@nortelnetworks.com, mpls@uu.net From: "Michael H. Behringer" Subject: Comments requested: draft-behringer-mpls-security-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: mbehring@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: This new version now includes a security analysis for Inter-AS and CsC. So it should cover the whole 2547bis spectrum. I would like to invite comments on what is missing or should be changed. Thanks, Michael --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of the Security of BGP/MPLS IP VPNs Author(s) : M. Behringer Filename : draft-behringer-mpls-security-04.txt Pages : 21 Date : 2003-5-29 This document analyses the security of the BGP/MPLS IP VPN architecture as described in [RFC2547bis], especially in comparison with other VPN technologies such as ATM and Frame Relay. The target audience is service providers and VPN users. The document consists of two main parts: First the requirements for security in VPN services are defined, second BGP/MPLS IP VPNs are examined with respect to these requirements. The analysis shows that BGP/MPLS IP VPN networks can be equally secured as traditional layer-2 VPN networks such as ATM and Frame Relay. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-04.txt From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 12:30:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14260 for ; Mon, 2 Jun 2003 12:30:15 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52GTj724231 for ; Mon, 2 Jun 2003 12:29:45 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52GThe21635 for ; Mon, 2 Jun 2003 12:29:43 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: "Michael H. Behringer" , PPVPN@nortelnetworks.com, mpls@uu.net Subject: RE: Comments requested: draft-behringer-mpls-security-04.txt Date: Mon, 2 Jun 2003 12:27:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32923.DAF22AA6" 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_01C32923.DAF22AA6 Content-Type: text/plain; charset="iso-8859-1" Michael, Not necessarily a comment on the draft which looks okay for me. Some of the content of the draft apply as well to mpls-based layer-2 vpns. Maybe in the future, a more generic security analysis draft for mpls-based vpn that includes l3 and l2 vpns along the lines of this draft is suggested. Hamid. > > This new version now includes a security analysis for > Inter-AS and CsC. So > it should cover the whole 2547bis spectrum. I would like to > invite comments > on what is missing or should be changed. > > Thanks, > Michael > > --- > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Analysis of the Security of > BGP/MPLS IP VPNs > Author(s) : M. Behringer > Filename : draft-behringer-mpls-security-04.txt > Pages : 21 > Date : 2003-5-29 > > This document analyses the security of the BGP/MPLS IP VPN > architecture > as described in [RFC2547bis], especially in comparison with other VPN > technologies such as ATM and Frame Relay. The target audience is > service providers and VPN users. The document consists of two main > parts: First the requirements for security in VPN services > are defined, > second BGP/MPLS IP VPNs are examined with respect to these > requirements. > > The analysis shows that BGP/MPLS IP VPN networks can be > equally secured > as traditional layer-2 VPN networks such as ATM and Frame Relay. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-behringer-mpls-secur ity-04.txt ------_=_NextPart_001_01C32923.DAF22AA6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Comments requested: = draft-behringer-mpls-security-04.txt

Michael,

Not necessarily a comment on the draft which = looks
okay for me. Some of the content of the draft apply = as well
to mpls-based layer-2 vpns. Maybe in the future, a = more generic
security analysis draft for mpls-based vpn
that includes l3 and l2 vpns along the lines of this = draft
is suggested.

Hamid.

>
> This new version now includes a security = analysis for
> Inter-AS and CsC. So
> it should cover the whole 2547bis spectrum. I = would like to
> invite comments
> on what is missing or should be changed.
>
> Thanks,
> Michael
>
> ---
>
> A New Internet-Draft is available from the = on-line
> Internet-Drafts directories.
>
>
>          = Title           : = Analysis of the Security of
> BGP/MPLS IP VPNs
>          = Author(s)       : M. Behringer
>          = Filename        : = draft-behringer-mpls-security-04.txt
>          = Pages           : = 21
>          = Date            = : 2003-5-29
>
> This document analyses the security of the = BGP/MPLS IP VPN
> architecture
> as described in [RFC2547bis], especially in = comparison with other VPN
> technologies such as ATM and Frame Relay. The = target audience is
> service providers and VPN users. The document = consists of two main
> parts: First the requirements for security in = VPN services
> are defined,
> second BGP/MPLS IP VPNs are examined with = respect to these
> requirements.
>
> The analysis shows that BGP/MPLS IP VPN = networks can be
> equally secured
> as traditional layer-2 VPN networks such as ATM = and Frame Relay.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-behringer-mp= ls-secur
ity-04.txt

------_=_NextPart_001_01C32923.DAF22AA6-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 12:52:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14895 for ; Mon, 2 Jun 2003 12:52:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52Gq2700894 for ; Mon, 2 Jun 2003 12:52:02 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52Gpxr15503 for ; Mon, 2 Jun 2003 12:51:59 -0400 (EDT) Message-ID: <20030602164513.60068.qmail@web13506.mail.yahoo.com> Date: Mon, 2 Jun 2003 09:45:13 -0700 (PDT) From: Mark Seery Subject: Re: Comments requested: draft-behringer-mpls-security-04.txt To: "Michael H. Behringer" Cc: PPVPN@nortelnetworks.com, mpls@uu.net In-Reply-To: <4.3.2.7.2.20030602085609.0322fcc0@madrid.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13506.mail.yahoo.com X-SMTP-MAIL-FROM: mark@mseery.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: web13506.mail.yahoo.com [216.136.175.85] X-LYRIS-Message-Id: Hi Michael, Given the statement in 5.1 "...security mechanisms discussed here assume correct configuration..." my comments may not apply, but FYI for consideration in future drafts. label swapping forwarding elements introduce the possibility of label swap/merge faults; either through misconfiguration or through label distribution bugs. the traditional way that label swap networks have dealt with this problem is through continuity tests (verifying correct end point addresses). Such mechanisms are being discussed in PWE/MPLS WGs, and hence when/if applied would provide for a way to recognise a misconfiguration and reduce the amount of time the security leak is present for. When such mechanisms are implemented in MPLS VPN networks, then such a network could be considered as secure as an ATM-based network (for example a Frame over ATM core network). Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 12:57:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15102 for ; Mon, 2 Jun 2003 12:57:12 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52Gug704619 for ; Mon, 2 Jun 2003 12:56:42 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52Gudr23132 for ; Mon, 2 Jun 2003 12:56:40 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: PPVPN@nortelnetworks.com Subject: RE: Comments requested: draft-behringer-mpls-security-04.txt Date: Mon, 2 Jun 2003 12:54:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32927.A3E278DC" 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_01C32927.A3E278DC Content-Type: text/plain; charset="iso-8859-1" Actually draft-fang-ppvpn-security-framework-00.txt addresses security framework for all ppvpn solutions which is a useful document to have... Hamid. >Michael, > Not necessarily a comment on the draft which looks >okay for me. Some of the content of the draft apply as well >to mpls-based layer-2 vpns. Maybe in the future, a more generic >security analysis draft for mpls-based vpn >that includes l3 and l2 vpns along the lines of this draft >is suggested. > >Hamid. >> >> This new version now includes a security analysis for >> Inter-AS and CsC. So >> it should cover the whole 2547bis spectrum. I would like to >> invite comments >> on what is missing or should be changed. >> >> Thanks, >> Michael >> ------_=_NextPart_001_01C32927.A3E278DC Content-Type: text/html; charset="iso-8859-1" RE: Comments requested: draft-behringer-mpls-security-04.txt

Actually draft-fang-ppvpn-security-framework-00.txt addresses
security framework for all ppvpn solutions which is
a useful document to have...

Hamid.

>Michael,

> Not necessarily a comment on the draft which looks
>okay for me. Some of the content of the draft apply as well
>to mpls-based layer-2 vpns. Maybe in the future, a more generic
>security analysis draft for mpls-based vpn
>that includes l3 and l2 vpns along the lines of this draft
>is suggested.
>
>Hamid.

>>
>> This new version now includes a security analysis for
>> Inter-AS and CsC. So
>> it should cover the whole 2547bis spectrum. I would like to
>> invite comments
>> on what is missing or should be changed.
>>
>> Thanks,
>> Michael
>>

------_=_NextPart_001_01C32927.A3E278DC-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 13:25:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15696 for ; Mon, 2 Jun 2003 13:25:17 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52HOk705056 for ; Mon, 2 Jun 2003 13:24:46 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52HOh405116 for ; Mon, 2 Jun 2003 13:24:44 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: Ppvpn Subject: Re: decisions on L2 solutions documents In-reply-to: Your message of "Mon, 02 Jun 2003 11:05:39 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Jun 2003 18:21:24 +0100 From: Peter Willis Message-Id: X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: pjw@ip-engineering.bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Wouldn't it be kind of cool if we could use the same addressing format for what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to say we always identify the end-point of an LSP/PW/tunnel with a unique address (I mean unique for the LSP/PW/tunnel so no 2 PWs share the same address)? Now I know the problem is IPv4 space isn't big enough to do this so why not use IPv6 addresses? Since you've got to implement IPv6 at the RFC specification level anyway wouldn't it be good to use IPv6 to address LSPs/PWs/tunnels consistently? That way we'll have another incentive to move to IPv6 - it'll ease the management & implementation of LSPs/PWs/tunnels. Well I'll let you pragmatic types get back to work ;-) Regards, Peter. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 13:38:45 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16308 for ; Mon, 2 Jun 2003 13:38:44 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52HcD711025 for ; Mon, 2 Jun 2003 13:38:13 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52HcAw21427 for ; Mon, 2 Jun 2003 13:38:11 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Peter Willis , Ppvpn Subject: RE: decisions on L2 solutions documents Date: Mon, 2 Jun 2003 13:34:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3292D.3C4BC894" 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_01C3292D.3C4BC894 Content-Type: text/plain; charset="iso-8859-1" Peter, > > > Wouldn't it be kind of cool if we could use the same > addressing format for > what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to > say we always > identify the end-point of an LSP/PW/tunnel with a unique > address (I mean > unique for the LSP/PW/tunnel so no 2 PWs share the same address)? > But it that case how about pw created for l2vpns. Would these addresses be required to be always unique or can be overlapping? In addition to that if these addresses are taken from the provider space or are unique across VPNs, wouldn't that limit the flexibility of the client to use private addresses particularly for services like svc-vpns. Hamid. ------_=_NextPart_001_01C3292D.3C4BC894 Content-Type: text/html; charset="iso-8859-1" RE: decisions on L2 solutions documents

Peter,

>
>
> Wouldn't it be kind of cool if we could use the same
> addressing format for
> what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to
> say we always
> identify the end-point of an LSP/PW/tunnel with a unique
> address (I mean
> unique for the LSP/PW/tunnel so no 2 PWs share the same address)?
>

But it that case how about pw created for l2vpns. Would these
addresses be required to be always unique or can be
overlapping? 

In addition to that if these addresses are taken from the
provider space or are unique across VPNs, wouldn't that limit
the flexibility of the client to use private addresses
particularly for services like svc-vpns.

 
Hamid.

------_=_NextPart_001_01C3292D.3C4BC894-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 17:33:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25005 for ; Mon, 2 Jun 2003 17:33:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52LX3i28413 for ; Mon, 2 Jun 2003 17:33:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52LX1A24199 for ; Mon, 2 Jun 2003 17:33:01 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6934@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: "Hamid Ould-Brahim" , pjw@ip-engineering.bt.com, ppvpn@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Date: Mon, 2 Jun 2003 22:30:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Hamid Ould-Brahim wrote 02 June 2003 18:35 Peter, > > > Wouldn't it be kind of cool if we could use the same > addressing format for > what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to > say we always > identify the end-point of an LSP/PW/tunnel with a unique > address (I mean > unique for the LSP/PW/tunnel so no 2 PWs share the same address)? > But it that case how about pw created for l2vpns. NH=> Hamid why do you think you need PWs at all? The only reasons PWs exist is as follows: - to fix the problems caused by mp2p LSPs.....if you want any-any connectivity use a cnls mode, in a co pkt-sw mode only p2p and p2mp constructions make any arch sense....mp2p leads to problems and kludges; - to keep the pretence-up that MPLS =~ IP.....if true why do we need MPLS then? Use the right mode for the right application....both are required; - to squeeze a bit of the server-layer BW via client compression (a total non-issue IMO when other technolgies squander BW). Would these addresses be required to be always unique or can be overlapping? NH=> PWs are *not* a layer network....they are actually a set of encapsulation functions that belongs in the client->server adaptation process (network-interworking case). Client->server adaptation should be a minimalist mapping with (ideally) no functions that need management (eg sequence number aberrations). PWs don't need addresses, ie PWs are not switched network entities like LSPs...its MPLS that needs access point addresses in its own right since MPLS creates a layer network. Further, when one considers mixed partition service-interworking between technologies belonging to the *same* network mode (eg FR_access<=>MPLS_core<=>ATM_access) PWs simply disappear anyway. I know service-interworking is not on IETF's (PWE3) agenda, but speaking as an operator its very high on ours to drive down capex/opex so we can have a common core per network mode.....so please (as a vendor) don't ignore it. Its the above issues that sit behind Peter's original comments. regards, Neil From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 18:02:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25958 for ; Mon, 2 Jun 2003 18:02:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52M1Ui12311 for ; Mon, 2 Jun 2003 18:01:30 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52M1Rt24301 for ; Mon, 2 Jun 2003 18:01:27 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: neil.2.harrison@bt.com, pjw@ip-engineering.bt.com, ppvpn@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Date: Mon, 2 Jun 2003 17:59:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32952.4549A13A" 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_01C32952.4549A13A Content-Type: text/plain; charset="iso-8859-1" Neil, > > > > Wouldn't it be kind of cool if we could use the same > > addressing format for > > what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to > > say we always > > identify the end-point of an LSP/PW/tunnel with a unique > > address (I mean > > unique for the LSP/PW/tunnel so no 2 PWs share the same address)? > > > But it that case how about pw created for l2vpns. > NH=> Hamid why do you think you need PWs at all? Actually I don't need them :-). I see them as a tool for l2vpns (among others)...and Peter mentioned addresses for pw...so I asked :-)... >The only > reasons PWs exist > is as follows: > - to fix the problems caused by mp2p LSPs.....if you want any-any > connectivity use a cnls mode, in a co pkt-sw mode only p2p and p2mp > constructions make any arch sense....mp2p leads to problems > and kludges; > - to keep the pretence-up that MPLS =~ IP.....if true why > do we need > MPLS then? Use the right mode for the right application....both are > required; > - to squeeze a bit of the server-layer BW via client > compression (a > total non-issue IMO when other technolgies squander BW). > > Would these > addresses be required to be always unique or can be > overlapping? > NH=> PWs are *not* a layer network....they are actually a set of > encapsulation functions that belongs in the client->server adaptation > process (network-interworking case). Isn't control/signaling, establishment of pws part of pwe3 work besides just encapsulation... > Client->server > adaptation should be a > minimalist mapping with (ideally) no functions that need > management (eg > sequence number aberrations). PWs don't need addresses, ie > PWs are not > switched network entities like LSPs...its MPLS that needs access point > addresses in its own right since MPLS creates a layer > network. Further, > when one considers mixed partition service-interworking > between technologies > belonging to the *same* network mode (eg > FR_access<=>MPLS_core<=>ATM_access) > PWs simply disappear anyway. I know service-interworking is > not on IETF's > (PWE3) agenda, but speaking as an operator its very high on > ours to drive > down capex/opex so we can have a common core per network > mode.....so please > (as a vendor) don't ignore it. > Not at all ignoring it. I am actually in favor of addressing interworking case and I don't see all l2vpn problems need to be solved only through pwe3 to be taken as a complete package. In fact BGP signaling is an example that pwe3 encaps can be useful without pw signaling scheme (that's maybe a different topic)... > Its the above issues that sit behind Peter's original comments. > Okay. Not sure I understand the client-server terminology and mpls/pwe3 layer subtleties...I guess this topic is more appropriate with PWE3 layer discussions and MPLS layer debate going on in pwe3 wg. Hamid. ------_=_NextPart_001_01C32952.4549A13A Content-Type: text/html; charset="iso-8859-1" RE: decisions on L2 solutions documents

Neil,

> >
> > Wouldn't it be kind of cool if we could use the same
> > addressing format for
> > what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to
> > say we always
> > identify the end-point of an LSP/PW/tunnel with a unique
> > address (I mean
> > unique for the LSP/PW/tunnel so no 2 PWs share the same address)?
> >
> But it that case how about pw created for l2vpns.
> NH=> Hamid why do you think you need PWs at all? 


Actually I don't need them :-). I see them as a tool
for l2vpns (among others)...and Peter mentioned addresses
for pw...so I asked :-)...

>The only
> reasons PWs exist
> is as follows:
> -     to fix the problems caused by mp2p LSPs.....if you want any-any
> connectivity use a cnls mode, in a co pkt-sw mode only p2p and p2mp
> constructions make any arch sense....mp2p leads to problems
> and kludges;
> -     to keep the pretence-up that MPLS =~ IP.....if true why
> do we need
> MPLS then?  Use the right mode for the right application....both are
> required;
> -     to squeeze a bit of the server-layer BW via client
> compression (a
> total non-issue IMO when other technolgies squander BW).
>
> Would these
> addresses be required to be always unique or can be
> overlapping? 
> NH=> PWs are *not* a layer network....they are actually a set of
> encapsulation functions that belongs in the client->server adaptation
> process (network-interworking case).

Isn't control/signaling, establishment of pws part of pwe3 work
besides just encapsulation...

> Client->server
> adaptation should be a
> minimalist mapping with (ideally) no functions that need
> management (eg
> sequence number aberrations).  PWs don't need addresses, ie
> PWs are not
> switched network entities like LSPs...its MPLS that needs access point
> addresses in its own right since MPLS creates a layer
> network.  Further,
> when one considers mixed partition service-interworking
> between technologies
> belonging to the *same* network mode (eg
> FR_access<=>MPLS_core<=>ATM_access)
> PWs simply disappear anyway.  I know service-interworking is
> not on IETF's
> (PWE3) agenda, but speaking as an operator its very high on
> ours to drive
> down capex/opex so we can have a common core per network
> mode.....so please
> (as a vendor) don't ignore it.
>

Not at all ignoring it. I am actually in favor of addressing
interworking case and I don't see all l2vpn problems need to be solved
only through pwe3 to be taken as a complete package. In fact BGP
signaling is an example that pwe3 encaps can be useful without pw
signaling scheme (that's maybe a different topic)...

> Its the above issues that sit behind Peter's original comments.
>

Okay. Not sure I understand the client-server terminology
and mpls/pwe3 layer subtleties...I guess this topic is more appropriate with
PWE3 layer discussions and MPLS layer debate going on
in pwe3 wg.

Hamid.

------_=_NextPart_001_01C32952.4549A13A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 2 18:58:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28916 for ; Mon, 2 Jun 2003 18:58:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h52MwSi21124 for ; Mon, 2 Jun 2003 18:58:29 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h52MwQD24134 for ; Mon, 2 Jun 2003 18:58:26 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6937@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: "Hamid Ould-Brahim" , pjw@ip-engineering.bt.com, ppvpn@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Date: Mon, 2 Jun 2003 23:56:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Hi Hamid, thanks for the comments. Please see in-line. regards, Neil Hamid Ould-Brahim wrote 02 June 2003 23:00 Neil, > > > > Wouldn't it be kind of cool if we could use the same > > addressing format for > > what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to > > say we always > > identify the end-point of an LSP/PW/tunnel with a unique > > address (I mean > > unique for the LSP/PW/tunnel so no 2 PWs share the same address)? > > > But it that case how about pw created for l2vpns. > NH=> Hamid why do you think you need PWs at all? Actually I don't need them :-). NH=> Yes I know that too ;-) I see them as a tool for l2vpns (among others)...and Peter mentioned addresses for pw...so I asked :-)... NH=> You are right....this was an oversight on Peter's case. He/I and many others here are of the same view as the one I expressed. >The only > reasons PWs exist > is as follows: > - to fix the problems caused by mp2p LSPs.....if you want any-any > connectivity use a cnls mode, in a co pkt-sw mode only p2p and p2mp > constructions make any arch sense....mp2p leads to problems > and kludges; > - to keep the pretence-up that MPLS =~ IP.....if true why > do we need > MPLS then? Use the right mode for the right application....both are > required; > - to squeeze a bit of the server-layer BW via client > compression (a > total non-issue IMO when other technolgies squander BW). > > Would these > addresses be required to be always unique or can be > overlapping? > NH=> PWs are *not* a layer network....they are actually a set of > encapsulation functions that belongs in the client->server adaptation > process (network-interworking case). Isn't control/signaling, establishment of pws part of pwe3 work besides just encapsulation... NH=> Yes. But think about TCP (or any other 2-point session-like protocols) these need 'control' but they are not 'networked entities'. The mere reason this is being done does not justify PWs existence. Their existence is justified in other less technical ways....my prior comments indicate what I mean by this. > Client->server > adaptation should be a > minimalist mapping with (ideally) no functions that need > management (eg > sequence number aberrations). PWs don't need addresses, ie > PWs are not > switched network entities like LSPs...its MPLS that needs access point > addresses in its own right since MPLS creates a layer > network. Further, > when one considers mixed partition service-interworking > between technologies > belonging to the *same* network mode (eg > FR_access<=>MPLS_core<=>ATM_access) > PWs simply disappear anyway. I know service-interworking is > not on IETF's > (PWE3) agenda, but speaking as an operator its very high on > ours to drive > down capex/opex so we can have a common core per network > mode.....so please > (as a vendor) don't ignore it. > Not at all ignoring it. I am actually in favor of addressing interworking case and I don't see all l2vpn problems need to be solved only through pwe3 to be taken as a complete package. In fact BGP signaling is an example that pwe3 encaps can be useful without pw signaling scheme (that's maybe a different topic)... NH=> I think so. I think BGP is an excellent protocol for distributing reachability information (all modes), esp in a client/server case for a VPN, but I don't think its a good general signalling protocol.....this has to be mode specific. > Its the above issues that sit behind Peter's original comments. > Okay. Not sure I understand the client-server terminology and mpls/pwe3 layer subtleties...I guess this topic is more appropriate with PWE3 layer discussions and MPLS layer debate going on in pwe3 wg. NH=> Agreed....but they are kind-of interwined as I am sure you know. Have a word with Dave Allen in your organisation on these topics....he has an excellent grasp of the issues and they are very important to us anyway. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 04:46:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23424 for ; Tue, 3 Jun 2003 04:46:35 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h538k4T21675 for ; Tue, 3 Jun 2003 04:46:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h538k2o11035 for ; Tue, 3 Jun 2003 04:46:02 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: "Hamid Ould-Brahim" cc: Ppvpn Subject: Re: decisions on L2 solutions documents In-reply-to: Your message of "Mon, 02 Jun 2003 13:34:35 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jun 2003 09:44:12 +0100 From: Peter Willis Message-Id: X-SMTP-HELO: cbibipnt08.hc.bt.com X-SMTP-MAIL-FROM: pjw@ip-engineering.bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: > > Wouldn't it be kind of cool if we could use the same > > addressing format for > > what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to > > say we always > > identify the end-point of an LSP/PW/tunnel with a unique > > address (I mean > > unique for the LSP/PW/tunnel so no 2 PWs share the same address)? > > > > But it that case how about pw created for l2vpns. Would these > addresses be required to be always unique or can be > overlapping? Yes if you created L2VPNs from PWs then the PWs would still be uniquely addressed. However if one wanted to connect a set of uniquely addressed access points together without PWs in an any to any/full mesh/mp-mp fashion then an IP network already does this very neatly ;-) > > In addition to that if these addresses are taken from the > provider space or are unique across VPNs, wouldn't that limit > the flexibility of the client to use private addresses > particularly for services like svc-vpns. The addresses would come from the provider space as the LSPs/PWs/tunnels are connected to the edges of the provider's network. The client can use any addressing scheme they like. But you point out a good issue with signalling if the VPNs set-up where to be signalled by the client then what addresses/names would be used? These names would (should?) not have to be the same as the addresses the provider uses to set-up the VPN. Peter. From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 06:32:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25952 for ; Tue, 3 Jun 2003 06:32:31 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53AW0T15803 for ; Tue, 3 Jun 2003 06:32:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h53AVvi11576 for ; Tue, 3 Jun 2003 06:31:57 -0400 (EDT) X-Originating-IP: [203.124.140.97] X-Originating-Email: [sylvia_sugar@hotmail.com] From: "Sylvia Sugar" To: ppvpn@nortelnetworks.com Subject: Re: decisions on L2 solutions documents Date: Tue, 03 Jun 2003 10:30:08 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jun 2003 10:30:09.0029 (UTC) FILETIME=[1B4EFB50:01C329BB] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: sylvia_sugar@hotmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: bay1-f39.bay1.hotmail.com [65.54.245.39] X-LYRIS-Message-Id: > >Wouldn't it be kind of cool if we could use the same addressing format for >what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to say we always >identify the end-point of an LSP/PW/tunnel with a unique address (I mean >unique for the LSP/PW/tunnel so no 2 PWs share the same address)? What happens if one only knows the "next-hop" and the next-hop knows how to get to the next-hop and so on? Is that a problem? Or is that "not nice"?? > >Now I know the problem is IPv4 space isn't big enough to do this so why not >use IPv6 addresses? Since you've got to implement IPv6 at the RFC >specification >level anyway wouldn't it be good to use IPv6 to address LSPs/PWs/tunnels >consistently? That way we'll have another incentive to move to IPv6 - it'll >ease the management & implementation of LSPs/PWs/tunnels. That would be nice too. I wish we (the market) knew who already owns /8s of v6 addresses....... Is the address distribution done by drawing out globe and saying "so and so latitude and longitude will have so and so address?" -SylviaXO _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 07:50:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27744 for ; Tue, 3 Jun 2003 07:50:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53BnaT27552 for ; Tue, 3 Jun 2003 07:49:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h53BnXa14147 for ; Tue, 3 Jun 2003 07:49:33 -0400 (EDT) Message-Id: <200306031147.HAA27517@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ppvpn@nortelnetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ppvpn-rfc2547bis-04.txt Date: Tue, 03 Jun 2003 07:47:45 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provider Provisioned Virtual Private Networks Working Group of the IETF. Title : BGP/MPLS VPNs Author(s) : E. Rosen et al. Filename : draft-ietf-ppvpn-rfc2547bis-04.txt Pages : 47 Date : 2003-6-2 This document describes a method by which a Service Provider may use an IP backbone to provide VPNs (Virtual Private Networks) for its customers. This method uses a 'peer model', in which the customers' edge routers ('CE routers') send their routes to the Service Provider's edge routers ('PE routers'). BGP is then used by the Service Provider to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This is done in a way which ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. The PE routers distribute, to the CE routers in a particular VPN, the routes from other the CE routers in that VPN. The CE routers do not peer with each other, hence there is no 'overlay' visible to the VPN's routing algorithm. Each route within a VPN is assigned an MPLS label; when BGP distributes a VPN route, it also distributes an MPLS label for that route. Before a customer data packet travels across the Service Provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route that is the best match to the packet's destination address. This MPLS packet is further encapsulated (e.g., with another MPLS label, or with an IP or GRE tunnel header) so that it gets tunneled across the backbone to the proper PE router. Thus the backbone core routers do not need to know the VPN routes. The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises which need an extranet, an Internet Service Provider, an application service provider, another VPN Service Provider which uses this same method to offer VPNs to clients of its own, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value. This document obsoletes RFC 2547. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-rfc2547bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ppvpn-rfc2547bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ppvpn-rfc2547bis-04.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: <2003-6-2145732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-rfc2547bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-rfc2547bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145732.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 08:08:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28603 for ; Tue, 3 Jun 2003 08:08:48 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53C8GT10858 for ; Tue, 3 Jun 2003 08:08:16 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h53C8D815478 for ; Tue, 3 Jun 2003 08:08:13 -0400 (EDT) Subject: RE: decisions on L2 solutions documents From: Giles Heron To: neil.2.harrison@bt.com Cc: "Hamid Ould-Brahim" , pjw@ip-engineering.bt.com, ppvpn@nortelnetworks.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6934@i2km07-ukbr.domain1.systemhost.net > References: <0536FC9B908BEC4597EE721BE6A35389025D6934@i2km07-ukbr.domain1.systemhost.net > Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Jun 2003 13:02:49 +0000 Message-Id: <1054645369.2333.26.camel@gizpad> Mime-Version: 1.0 X-SMTP-HELO: rincewind.office.packetexchange.net X-SMTP-MAIL-FROM: giles@packetexchange.net X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: unknown.Level3.net [212.113.11.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On Mon, 2003-06-02 at 21:30, neil.2.harrison@bt.com wrote: > Hamid Ould-Brahim wrote 02 June 2003 18:35 > > Peter, > > > > > > Wouldn't it be kind of cool if we could use the same > > addressing format for > > what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to > > say we always > > identify the end-point of an LSP/PW/tunnel with a unique > > address (I mean > > unique for the LSP/PW/tunnel so no 2 PWs share the same address)? > > > But it that case how about pw created for l2vpns. > NH=> Hamid why do you think you need PWs at all? The only reasons PWs exist > is as follows: > - to fix the problems caused by mp2p LSPs.....if you want any-any > connectivity use a cnls mode, in a co pkt-sw mode only p2p and p2mp > constructions make any arch sense....mp2p leads to problems and kludges; > - to keep the pretence-up that MPLS =~ IP.....if true why do we need > MPLS then? Use the right mode for the right application....both are > required; > - to squeeze a bit of the server-layer BW via client compression (a > total non-issue IMO when other technolgies squander BW). [rest snipped] Meanwhile, back in the real world, PWs (in the MPLS context) do the following: 1) add a label to the stack to keep state out of the core (this may also create a p2p LSP on top of an mp2p LSP, depending on whether you are using LDP or RSVP-TE for your tunnel LSPs). 2) create a bidirectional p2p construct out of two unidirectional p2p LSPs. 3) adapt the layer 2 protocol being carried to MPLS. This involves three things: i. stripping off the layer 2 header (aka "compression") in the cases such as FR where the header may be different at each end. ii. sequence numbering, if required, for the case where the core network may reorder packets. iii. length checking, for the case where the core network's minimum PDU is larger than that of the PW (this is required because MPLS has no length field). Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 08:52:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01097 for ; Tue, 3 Jun 2003 08:52:25 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53CpoT20858 for ; Tue, 3 Jun 2003 08:51:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h53Cpmw06802 for ; Tue, 3 Jun 2003 08:51:48 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6947@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: giles@packetexchange.net Cc: "Hamid Ould-Brahim" , pjw@ip-engineering.bt.com, ppvpn@nortelnetworks.com Subject: RE: decisions on L2 solutions documents Date: Tue, 3 Jun 2003 13:44:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Giles, > > > > > > Wouldn't it be kind of cool if we could use the same > > > addressing format for > > > what ever MPLS LSP/pseudo wire/tunnel? Is it too simple to > > > say we always > > > identify the end-point of an LSP/PW/tunnel with a unique > > > address (I mean > > > unique for the LSP/PW/tunnel so no 2 PWs share the same address)? > > > > > But it that case how about pw created for l2vpns. > > NH=> Hamid why do you think you need PWs at all? The only > reasons PWs exist > > is as follows: > > - to fix the problems caused by mp2p LSPs.....if you want any-any > > connectivity use a cnls mode, in a co pkt-sw mode only p2p and p2mp > > constructions make any arch sense....mp2p leads to problems > and kludges; > > - to keep the pretence-up that MPLS =~ IP.....if true why > do we need > > MPLS then? Use the right mode for the right application....both are > > required; > > - to squeeze a bit of the server-layer BW via client > compression (a > > total non-issue IMO when other technolgies squander BW). > [rest snipped] > > Meanwhile, back in the real world, PWs (in the MPLS context) do the > following: > > 1) add a label to the stack to keep state out of the core > (this may also > create a p2p LSP on top of an mp2p LSP, depending on whether you are > using LDP or RSVP-TE for your tunnel LSPs). NH=> This is an LSP issue and belongs to the proper MPLS layer network....nothing to do with PWs. > 2) create a bidirectional p2p construct out of two unidirectional p2p > LSPs. NH=> This is an LSP issue and belongs to the proper MPLS layer network....nothing to do with PWs. > 3) adapt the layer 2 protocol being carried to MPLS. NH=> Now you have it....PW are about adaptation....with that I agree. > This involves > three things: > i. stripping off the layer 2 header (aka "compression") in the cases > such as FR where the header may be different at each end. NH=> Yep, bit of BW squeezing > ii. sequence numbering, if required, for the case where the core > network may reorder packets. NH=> Yep, there to fix lower layer MPLS problems. > iii. length checking, for the case where the core network's > minimum PDU > is larger than that of the PW (this is required because MPLS has no > length field). NH=>Agreed, adaptation function should pad to minimum. > > Giles > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 10:02:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04996 for ; Tue, 3 Jun 2003 10:02:48 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53E2HT02362 for ; Tue, 3 Jun 2003 10:02:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h53E2E202173 for ; Tue, 3 Jun 2003 10:02:14 -0400 (EDT) Subject: RE: decisions on L2 solutions documents From: Giles Heron To: neil.2.harrison@bt.com Cc: "Hamid Ould-Brahim" , pjw@ip-engineering.bt.com, ppvpn@nortelnetworks.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6947@i2km07-ukbr.domain1.systemhost.net > References: <0536FC9B908BEC4597EE721BE6A35389025D6947@i2km07-ukbr.domain1.systemhost.net > Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Jun 2003 14:47:28 +0000 Message-Id: <1054651648.2340.53.camel@gizpad> Mime-Version: 1.0 X-SMTP-HELO: rincewind.office.packetexchange.net X-SMTP-MAIL-FROM: giles@packetexchange.net X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: unknown.Level3.net [212.113.11.114] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On Tue, 2003-06-03 at 12:44, neil.2.harrison@bt.com wrote: > Giles, [snip] > > Meanwhile, back in the real world, PWs (in the MPLS context) do the > > following: > > > > 1) add a label to the stack to keep state out of the core > > (this may also > > create a p2p LSP on top of an mp2p LSP, depending on whether you are > > using LDP or RSVP-TE for your tunnel LSPs). > NH=> This is an LSP issue and belongs to the proper MPLS layer > network....nothing to do with PWs. of course there is no such thing as an MPLS layer network. In an architecturally pure parallel universe perhaps we'd have one ;-) In any case please let's not have that debate again... but sure, label stacking is part of the MPLS architecture. In this case the PW label is signalled by the PWE3 control component. > > 2) create a bidirectional p2p construct out of two unidirectional p2p > > LSPs. > NH=> This is an LSP issue and belongs to the proper MPLS layer > network....nothing to do with PWs. last time I checked MPLS LSPs were unidirectional, and PWs required bidirectional connectivity. > > 3) adapt the layer 2 protocol being carried to MPLS. > NH=> Now you have it....PW are about adaptation....with that I agree. > > > This involves > > three things: > > i. stripping off the layer 2 header (aka "compression") in the cases > > such as FR where the header may be different at each end. > NH=> Yep, bit of BW squeezing BW squeezing is a side-effect of stripping the L2 header, not the primary reason it was done AFAIK. > > ii. sequence numbering, if required, for the case where the core > > network may reorder packets. > NH=> Yep, there to fix lower layer MPLS problems. not really. It's just that some client protocols may be less tolerant of re-ordering than others. So some SPs may want to have the option of building a network which does not guarantee strict ordering of packets in all circumstances, and then have the adaptation function provide this for any traffic which needs it. > > iii. length checking, for the case where the core network's > > minimum PDU > > is larger than that of the PW (this is required because MPLS has no > > length field). > NH=>Agreed, adaptation function should pad to minimum. at least we're agreed on something ;-) Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 11:40:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10332 for ; Tue, 3 Jun 2003 11:40:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53FdRT00961 for ; Tue, 3 Jun 2003 11:39:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h53FdPY12426 for ; Tue, 3 Jun 2003 11:39:25 -0400 (EDT) Message-ID: <20408.80.88.128.14.1054654303.squirrel@webmail.444.net> Date: Tue, 3 Jun 2003 17:31:43 +0200 (CEST) Subject: REQUEST FOR URGENT BUSINESS ASSISTANCE From: To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: mail.theinternetone.net X-SMTP-MAIL-FROM: shabangu_susan@444.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: lnx-7-fe1.ams-2.theinternetone.net [62.4.94.8] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Dear Friend, RE: REQUEST FOR URGENT BUSINESS ASSISTANCE After due deliberation with my children, I decided to contact you for your assistance in standing as a beneficiary to the sum of US$30.5M ( Thirty Million, Five Hundred Thousand United States Dollars Only) First, let me start by introducing myself as MRS SUSAN SHABANGU, a mother of three children and the Deputy Minister of Minerals and Energy since 1st April 1996 to date under the auspices of the President of South Africa MR THABO MBEKI. You can view my profile at my website www.gov.za/profiles/shabangu.htm THE PROPOSAL After the swearing in ceremony making me the Deputy Minister of Minerals and Energy, my husband Mr Ndelebe Shabangu died while he was on an official trip to Trinidad and Tobago in2002. After his death, I discovered that he had some funds in a dollar account which amounted to the sum of US$30.5M with a South African bank which had thier offshore House in NIGERIA - CENTRAL BANK OF NIGERIA. This fund emanated as a result of an over-invoiced contract which he executed with the Government of South Africa. Though I assisted him in getting this contract but I never knew that it was over-invoiced by him. Iam afraid that the government of South Africa might start to investigate on contracts awarded from 1998 to date. If they discover this money in his bank account, they will confiscate it and seize his assets here in South Africa and this will definetely affect my political career in government. I want your assistance in transfering this funds from CENTRAL BANK OF NIGERIA through my Attorney so that this fund could be wired into your account directly without any hitch. As soon as the fund gets to your account, you are expected to move it immediately into another personal bank account in your country. I will see to it that the account is not traced from South Africa. As soon as you have confirmed the fund into your account, I will send my eldest son with my Attorney to come to your country to discuss on business investments. For your assistance, I am offering you 20% of the principal sum which amounts to US$6,100.000.00 (Six million One Hundred Thousand United States Dollars Only) However, you have to assure me and also be ready to go into agreement with me that you will no telope with my fund. If you agree to my terms, kindly as a matter of urgency send me an email. Due to my sensitive position in the South African Government, I would not WANT you to call me on phone or send a fax to me. All correspondence must be by email to my private email address, susan_1shabangu@zwallet.com If you want to speak with my Attorney, that is fine and okay by me. His chambers will be representing my interest at CENTRAL BANK OF NIGERIA. All correspondence must be made either to my Attorney Barrister Ayon Richard , of kuramo lodge chambers.,or send me an email. I will also like you to give me your contact address of telephone, fax and email to enable my Attorney call or reach you from time to time. Please I do not need to remind you of the need for absolute Confidentiality if this transaction must succeed. YOU MUST NOT CALL ME! If you do not feel comfortable with this transaction, do not hesitate to discontinue. Thanks for your anticipated co-operation and my regards to your family. Yours faithfully, MRS. SUSAN SHABANGU Deputy Minister of Minerals and Energy South Africa -------------------------------------------- Free Webmail courtesy of http://www.444.net/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 13:52:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16668 for ; Tue, 3 Jun 2003 13:52:57 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53HqPk15362 for ; Tue, 3 Jun 2003 13:52:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h53HqMu13203 for ; Tue, 3 Jun 2003 13:52:22 -0400 (EDT) Message-Id: <200306031749.h53Hn5812264@zrtps0km.us.nortel.com> From: "MR. EMMA SAVIMBI" Reply-To: emma_savimbi_1@elvis.com To: ppvpn@lyris.nortelnetworks.com Date: Tue, 3 Jun 2003 18:48:58 +0100 Subject: YOUR HELPING HAND NEEDED X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: ab17c1608.com X-SMTP-MAIL-FROM: mr_emma_222_sa@elvis.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [80.88.131.40] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16668 Dear sir/Madam, I am Mr Emma Savimbi, please i need your help since after the incidence that lead to the death of my father MR.JONAS M.SAVIMBI of unita of Angola. I know we have not met before, but I am contacting you with due sense of humanity responsibility, and the few awareness that you will give it a mutual understanding. I am soliciting for an assistance to move the sum $24 million USD to your country for investment. The fund is presently in a security company in Ghana for safety, since on the 12/08/1999. The real content was not declared as it was kept as photographic equipment. I need you as partner to assist in transferring the fund and provide good investment plans for it. The fund will be under your investment control for>three (3) years during which only the profit will be shared annually, 80% for me and 20% for you annually. I am a Christian with the fear of GOD in any thing I am doing, so please I want us to build trust to each other. All deposit contract documents shall be sent to you as soon as you indicate your interest. Thanks in anticipation of your response. Best regards, MR.EMMA SAVIMBI From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 13:58:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16839 for ; Tue, 3 Jun 2003 13:58:13 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53Hvfk18870 for ; Tue, 3 Jun 2003 13:57:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h53Hvdu18339 for ; Tue, 3 Jun 2003 13:57:39 -0400 (EDT) Message-Id: <200306031755.h53Htqf27203@zcars0jk.ca.nortel.com> From: "Mrs. Mary Bird" To: ppvpn@lyris.nortelnetworks.com Reply-To: marybird.1@netzero.com Subject: congratulations" Date: Tue, 03 Jun 2003 21:43:01 +0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="84d45c32-9609-11d7-a385-00e006eba285" X-SMTP-HELO: netzero201.com X-SMTP-MAIL-FROM: marybird.1@netzero.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [195.166.238.164] X-LYRIS-Message-Id: This is a multi-part message in MIME format --84d45c32-9609-11d7-a385-00e006eba285 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable UK LOTTO 140 NORTHAMPTON ROAD EC1R 0HB LONDON UNITED KINGDOM FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: NBM44125677 AND BATCH NO: 31/107/AY. ATTENTION: Sir/Madam, RE/ AWARD NOTIFICATION We are pleased to inform you of the announcement today, 3rd june 2003, of = winners of the UK LOTTO /INTERNATIONAL PROGRAMS held on 17TH JAN 2003 as = part of our begining of year bonanza. You or your company, attached to ticket number 1416-4612-750, with serial = number 3187-17 drew the lucky numbers 31-17-8-28-55, and consequently won = the lottery in the "A" category. You have therefore been approved for a lump sum pay out of US$5,500,000.00 in = cash credited to file REF NO. REF: NBM44125677. This is from total prize = money of US$16,500,000.00 shared among the Three (3) international winners = in this category. All participants were selected through a computer = balloting system drawn form 25,000 names from Middle East, Asia, = Africa,Canada,Europe and North America and Oceania as part our International = Promotions Program,which is conducted annually. CONGRATULATIONS! Your fund is now deposited with CLEARING HOUSE, in london. Due to the mix up = of some numbers and names, we ask that you keep this award strictly from = public notice until your claim has been processed and your money remitted = into your account. This is part of our security protocol to avoid = doubleclaiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year = high stakes US$1.1 billion International Lottery. To process your claim, please contact your claim agent; MR. FRED DAVIDS, FOREIGN SERVICE MANAGER, FIRST CORPORATE CLEARING HOUSE EMAIL: : fcchonline@netzero.com for due processing and remittance of your prize money to a designated account = of your choice. Remember, you must contact your claim agent not later than 30th of JUNE, = 2003.After this date, all funds will be returned as unclaimed. All = correspondences to MR.FRED DAVIDS,either by fax or email,should have this = EMAIL sent along with it and also, with your FULL ADDRESS, YOUR COUNTRY OF = RESIDENCE , PHONEAND FAX NUMBERand your EMAIL ADDRESS to which this email is = sent,should be clearly and BOLDLY WRITTEN IN YOUR RESPONSE with your claims = agent. NOTE: In order to avoid unnecessary delays and complications, please = remember to quote your reference and batch numbers in every one of your = correspondences with your agent. Furthermore,should there be any change of = your address, do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our = promotions program. Sincerely, MRS. MARY BIRD. THE PROMOTIONS MANAGER, UK LOTTO . 140 NORTHAMPTON ROAD, EC1R 0HB LONDON, UNITED KINGDOM. N.B. Any breach of confidentiality on the part of the winners will result = to disqualification. Please do not reply to this mail. Contact your claim = agent. --84d45c32-9609-11d7-a385-00e006eba285-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 3 17:03:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24547 for ; Tue, 3 Jun 2003 17:03:28 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h53L2vk23837 for ; Tue, 3 Jun 2003 17:02:58 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h53L2sL06060 for ; Tue, 3 Jun 2003 17:02:54 -0400 (EDT) Message-ID: <4B6D09F3B826D411A67300D0B706EFDE0115C999@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: ppvpn@lyris.nortelnetworks.com Subject: VPLS requirements question Date: Tue, 3 Jun 2003 13:59:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32A13.036D70B8" X-SMTP-HELO: father.pmc-sierra.bc.ca X-SMTP-MAIL-FROM: Shahram_Davari@pmc-sierra.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: father.pmc-sierra.com [216.241.224.13] 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_01C32A13.036D70B8 Content-Type: text/plain; charset="iso-8859-1" Hi, I have the following questions: 1) Section 3.5: What does this sentence mean? "A virtual layer 2 forwarding entity that is closed to a VPLS domain membership" 2) Section 4: Is the definition of WAN link correct (ie., a link between CE and PE)? and if so why is it complex? 3) Section 9.7 is not clear. Is service provider injecting L3 traffic? and if so in which direction? what is the purpose and what is the format of those packets? Thanks, -Shahram ------_=_NextPart_001_01C32A13.036D70B8 Content-Type: text/html; charset="iso-8859-1"
Hi,
 
I have the following questions:
 
1) Section 3.5: What does this sentence mean? "A virtual layer 2 forwarding entity that
   is closed to a VPLS domain membership"
 
2) Section 4: Is the definition of WAN link correct (ie., a link between CE and PE)? and if so why is it complex?
 
3) Section 9.7 is not clear. Is service provider injecting L3 traffic? and if so in which
direction? what is the purpose and what is the format of those packets?
 
Thanks,
-Shahram
------_=_NextPart_001_01C32A13.036D70B8-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 4 04:14:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07511 for ; Wed, 4 Jun 2003 04:14:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h548EP417754 for ; Wed, 4 Jun 2003 04:14:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h548ENY05134 for ; Wed, 4 Jun 2003 04:14:23 -0400 (EDT) Message-Id: <200306040812.h548Cff03970@zrtps0kk.us.nortel.com> From: michael To: ppvpn@nortelnetworks.com Reply-To: harry3105@sina.com Subject: Re:Supplying NI-CD and NI-MH rechargeable batteries Date: Wed, 04 Jun 2003 16:14:08 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="93535e53-96a5-11d7-854b-00e04c000195" X-SMTP-HELO: sina128.com X-SMTP-MAIL-FROM: harry3105@sina.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [218.18.81.96] X-LYRIS-Message-Id: This is a multi-part message in MIME format --93535e53-96a5-11d7-854b-00e04c000195 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sirs, Thank you for your attention to the following comments! This is Michael with Unitech Battery Limited from China saying hello to you! = Nice to meet you on the net. Our company specializes in producing high quality Ni-CD and = Ni-MH batteries, including cylindrical, prismatic and 9V series, especially = in high temperature batteries and high rate discharge batteries, these = products are widely used in cordless phones, cellular phones, transceivers, = remote controlled toys, emergency lightings, garden lightings, power tools, = household appliances, office equipments, etc. Please browse our website www.unitechbatt.com and = www.globalsources.com/unitech8.co for detailed information. Since we are the = manufacturer focuses on the making of Ni-CD and NI-MH rechargeable batteries, = so our products are all with the best quality and low prices, i know from = internet that your esteemed company maybe need some batteries, i write you = this e-mail and see if there is an opportunity for us to cooperate with each = other. maybe our products can lower down your cost and thus improve your = profits. If you want some samples for test or promotional purposes, please do = not hesitate to let me know. We also welcome OEM and ODM orders. Your prompt = reply would be highly appreciated! Yours sincerely! Michael Unitech Battery Limited ADD:No.4 Kaiming Road, Jintang Industrial Zone,Liuyue,Henggang,Shenzhen,China = Tel:0086-755-28509555(Extention 1047) Fax:0086-755-28506266 www.unitechbatt.com or www.globalsources.com/unitech8.co --93535e53-96a5-11d7-854b-00e04c000195-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 4 08:00:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13257 for ; Wed, 4 Jun 2003 08:00:28 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h54Bxu427143 for ; Wed, 4 Jun 2003 07:59:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h54Bxrn15260 for ; Wed, 4 Jun 2003 07:59:53 -0400 (EDT) Message-Id: <200306041157.HAA12971@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: l2tpext@ietf.org, ppvpn@nortelnetworks.com, pwe3@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-luo-l2tpext-l2vpn-signaling-02.txt Date: Wed, 04 Jun 2003 07:57:43 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@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 : L2VPN Signaling Using L2TPv3 Author(s) : W. Luo Filename : draft-luo-l2tpext-l2vpn-signaling-02.txt Pages : 20 Date : 2003-6-3 The Layer 2 Tunneling Protocol (L2TPv3) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TPv3 describes the use of an L2TP session to cross-connect two Layer 2 circuits attached to a pair of peering LACs. A cross-connect is a basic form of Layer 2 Virtual Private Networks (L2VPNs). This document describes mechanisms which utilize the building blocks that L2TP provides to construct different types of L2VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-luo-l2tpext-l2vpn-signaling-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-luo-l2tpext-l2vpn-signaling-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-luo-l2tpext-l2vpn-signaling-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: <2003-6-3151355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-luo-l2tpext-l2vpn-signaling-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-luo-l2tpext-l2vpn-signaling-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-3151355.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 4 09:26:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18310 for ; Wed, 4 Jun 2003 09:26:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h54DPx415496 for ; Wed, 4 Jun 2003 09:25:59 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h54DPtb03778 for ; Wed, 4 Jun 2003 09:25:56 -0400 (EDT) Date: Wed, 04 Jun 2003 15:23:43 +0200 From: Arciprete Claudio Subject: unsubscribe To: ppvpn@nortelnetworks.com Message-id: <2FE6D10B746E524998DEA70F2D418F02C894A5@EXC2K01A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C32A9C.856108A2" Content-transfer-encoding: 7bit Importance: normal Priority: normal Thread-Topic: unsubscribe Thread-Index: AcMqnIVB4xswLmhlRxKWKRgAmZjfGA== content-class: urn:content-classes:message X-OriginalArrivalTime: 04 Jun 2003 13:23:44.0306 (UTC) FILETIME=[85B5E120:01C32A9C] X-SMTP-HELO: dns2.tilab.com X-SMTP-MAIL-FROM: Claudio.Arciprete@TILAB.COM X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: dns2.tilab.com [163.162.42.5] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------_=_NextPart_001_01C32A9C.856108A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit unsubscribe ppvpn ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== ------_=_NextPart_001_01C32A9C.856108A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

unsubscribe = ppvpn

=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
CONFIDENTIALITY NOTICE
This message and its = attachments are addressed solely to the persons
above and may contain = confidential information. If you have received
the message in error, = be informed that any use of the content hereof
is prohibited. Please = return it immediately to the sender and delete
the message. Should = you have any questions, please contact us by
replying to = MailAdmin@tilab.com. Thank = you
=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 ------_=_NextPart_001_01C32A9C.856108A2-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 4 09:42:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19017 for ; Wed, 4 Jun 2003 09:42:07 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h54Dfa425820 for ; Wed, 4 Jun 2003 09:41:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h54DfYq17170 for ; Wed, 4 Jun 2003 09:41:34 -0400 (EDT) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5E43@trimail2> From: "Serbest, Yetik" To: "Vasile Radoaca" , "'vkompella@timetra.com'" , "Dinesh Mohan" , Ppvpn , Rick Wilder Cc: "Puetz, Eric" , "Ballart, Ralph" Subject: Comments on GVPLS Date: Wed, 4 Jun 2003 08:38:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32A9E.893A8920" X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: serbest@tri.sbc.com X-SMTP-RCPT-TO: vasile@nortelnetworks.com,mohand@nortelnetworks.com,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_01C32A9E.893A8920 Content-Type: text/plain Vasile, I took the liberty to change the subject. I want to make a couple of points to your comments. As a general one, GVPLS is a good attempt to create a "perfect" solution. To do so, it includes a lot of complexities (e.g., different encapsulation than PWE3, multicast-unknown frame VCs). The question is "do we need to have all of those now?". I think not. Let's have some experience with the service and evolve it over time. Let's not complicate the solution up front. You said it best in your draft "simplicity, ease of deployment and manageability". - "Scalability" is a freely used term. What do you mean by "VPLS (lasserre-vkompella) is not scaleable"? Where do you see the limitation of 1000 VPLS instances for VPLS (lasserre-vkompella)? - You keep referring to VC label scalability issue? In his draft, Kireeti says this is non issue (which I agree with), and his solution wastes service labels. Your comparison of VC label scalability is not correct either. The comparison should be "CW+VC label" in GVPLS to "VC label" in VPLS. - Would you please elaborate on the MAC explosion in PEs? What scenario do you have in your mind? Do you think customers would put more than roughly hundred hosts per a broadcast domain? We heard those scenarios from marketing (like 900 sites). However, after we talked to the customers themselves, they understand that putting all 900 sites in one broadcast domain is not wise. Most likely they confuse the layer-2 VPN with the layer-3 VPN. - The objective of GVPLS and HVPLS is the same, but their constraints are not. GVPLS relaxes the constraints by not following PWE3 encapsulation. - I am also interested in your answer (maybe you already did and I missed it) to the following e-mail from lidefeng "In draft-radoaca-ppvpn-gvpls-01.txt,when control word is used(as mentioned in section 5.1.2 VSI-n of draft-chen-ppvpn-dvpls-compare-01.txt), the remote forwarding towards remote N-PE in the local N-PE is performed by splicing access PW corresponding to remote U-PE to core PW corresponding to the same remote U-PE-id,and local U-PE-id is added to control word,that is,take the U-PE-id as the SRC-CW-U-PE-ID field,however,U-PE-id is the is a 6-byte-long device id,and SRC-U-PE-ID represents the address of the originator U-PE deivece,is a 4-byte long IP address in IPv4,while the SRC-CW-U-PE-ID is 12 bits long,I wonder how to mapp these parameter in implementation." thanks, yetik -----Original Message----- From: Vasile Radoaca [mailto:vasile@nortelnetworks.com] Sent: Sunday, June 01, 2003 3:39 PM To: 'vkompella@timetra.com'; Dinesh Mohan; Ppvpn; Rick Wilder Subject: RE: decisions on L2 solutions documents Vach, See my comments below - Cheers Vasile -----Original Message----- From: Vach Kompella [mailto:vkompella@timetra.com ] Sent: Friday, May 30, 2003 12:50 PM To: Radoaca, Vasile [BL60:X624:EXCH]; Mohan, Dinesh [CAR:1A11:EXCH]; Ppvpn; Rick Wilder Subject: RE: decisions on L2 solutions documents Vasile, Dinesh, Some comments below. I've tried to identify Rick's, Vasile's and my comments. Outlook may mess the whole thing up, so apologies in advance. -Vach .. clipped Rick>> Here are the questions/requests-for-clarification that came up. Rick>> a) how do the discovery and signaling parts of the document Rick>> relate to those described in the other solutions documents Rick>> and which Rick>> of them are suggested to be mandatory to implement VR> > vasile VR> There are couple of assumptions that need to be taken in VR> consideration: VR> 1) VR> The GVPLS model, as a distributed model, needs to have a signaling mechanism that allows PW to be VR> identified by VPN-ID, and the End Points together. The pwe3-control-protocol-02.txt draft, with VR> Rosen's extensions to the PW Signaling mechanism address this VR> problem. Vach>> As a matter of fact, Rosen's signaling separately identifies the Vach>> PW and the VPN. Think of the Vach>> VPNID as a collection of PWs, and think of the SAII, TAII between Vach>> a pair of PEs as the PW Vach>> identifier. So, if you want to use the Rosen model, why write Vach>> your own draft? >> Vasile Rosen's draft presents only the extensions to the Martini's PW model, for the control plan in order to accommodate more general models, like the distributed model. The new GVPLS draft would be based on Rosen signaling [PWE3-Control 02.txt]. So, the GVPLS has his own role as solution draft. .. clipped Vach>> There are two issues here. The first is whether we need a Vach>> separate model for distributed VPLS or Vach>> not. The second is whether we need a VPN ID. Vach>> To the first point, Ali and Eric have described how to use p2p Vach>> PWs in conjuction with a learning Vach>> bridge in the position of the MTU to make a distributed VPLS Vach>> node. don't think we need to have Vach>> another way to create a distributed VPLS node. >> Vasile The draft-rosen-ppvpn-l2siganling-03.txt, section 5.5 represents an example how a distributed model can be built using the Generalized signaling method [PWE3-Control]. However, such model doesn't scale at all, and it covers only point-to-point type connections between U-PE devices and N-PE devices. In a more general and useful case, is when an Ethernet access network is used between U-PE and N-PE devices. Also, such model needs to be presented in and end-to-end solution. We have here a typical two extreme cases: 1) VPLS/HVPLS [your solution] where the MAC learning is done in PE - in this repsect the scalability is very limited because of MAC explosion 2) "Rosen's model ,section 5.5, where everything is built using PW [access and core], which doesn't scale because of the number of PWs. GVPLS is a third way, where is balance between MAC learning and forwarding and the number of PWs built in the core [and eventual in the access]. ... clipped Vach>> To the second point, the primary difference between the Rosen Vach>> draft and the HVPLS draft is in Vach>> naming the PWs, not in naming the VPN ID. The issue of using a Vach>> globally unique name for the VPLS Vach>> has been discussed. In an attempt to keep the signaling Vach>> compatible with draft-martini, we agreed Vach>> on using a VCID. However, there was an intent all along to Vach>> somehow make that identifier a Vach>> globally unique. Suggestions were made such as adding a VPN ID Vach>> in the optional parameters field, Vach>> etc. My last proposal was to have a bona fide VPN ID TLV in the Vach>> FEC. Vach>> Again, you mention that you would do draft-rosen. Why are you Vach>> specifying a different protocol Vach>> then? Vach>> If LDP is mandatory, why do you feel it is necessary to describe Vach>> BGP signaling in your draft? Vach>> What is different about your BGP signaling and draft-kompella? >> Vasile BGP signaling needs to be done - and we would do in a separate draft. ... clipped Vach>> Then define BGP in a separate draft. There is a claim that the informational model is the same Vach>> for BGP and LDP. However, there are a lot of different fields in Vach>> the signaling that are Vach>> described in the LDP signaling. I don't know how you are going Vach>> to add them to the BGP signaling. Vach>> Are the BGP signaling components such as label blocks and VE IDs Vach>> or site identifiers part of the Vach>> informational model? Are the LDP signaling components Vach>> If draft-rosen is your model for LDP signaling, how are you going Vach>> to keep gvpls interoperable Vach>> with HVPLS? Vasile >> this is up to VPLS/HVPLS solution - I think VPLS/HVPLS should also adopt Rosen's signaling method. VPLS/HVPLS draft is to narrow solution to solve the current market issues. It is one of the possibility. [clipped] Vach>> Some conclusions: Vach>> - GVPLS says LDP is the signaling protocol of choice Vach>> - GVPLS proposes basic interop with draft-lasserre-vkompella-vpls Vach>> - one can construct a distributed VPLS node using ethernet PWs and VPLS Vach>> - MAC-in-MAC is clearly outside the scope of the IETF Vach>> - at the Yokohama IETF we were told MAC-in-MAC was not Vach>> currently in any IEEE charter Vach>> - the BGP in GVPLS is too similar to draft-kompella-vpls to Vach>> warrant a separate draft Vach>> - the claim to identical information models between BGP and LDP signaling is not borne out Vach>> - GVPLS uses different encaps from the ones being defined in Vach>> PWE3 Vach>> Can you stil justify the GVPLS draft? >> Vasile As is today, it is not any other solution draft that described the VPLS distributed model [Rosen's attempt is just an example]. GVPLS is trying to complete this role. A VPLS network can be composed via complex access and core networks. It would be to simplistic to consider the distributed model just with the PWs on the access [the cost and the scalability do not reflect the customer's requirements and the market direction]. From scalability point of view, we just move the VPLS/HVPLS scalability problems from Mac learning to the VC-labels. Also, we need to a have model that is flexible to accommodate new protocols on the access networks, and M-in-M is one of the possibility. Probable, by the time that VPLS/HVPLS solution would move forward, it's scalability and the performance model would be already history, and M-i-M would be part of the IEEE (who knows?). A solution can be justifiable form political, market and theoretical aspects. Yes we recognize that VPLS/HVPLS doesn't scale but we would make some special assumptions like no CE as L2 switching, no IP VPN or legacy inter-working, no replication taken in consideration, no more than 1000 VPLS and so on. It's obvious - from just mathematical\theoretical considerations - that the VPLS/HVPLS doesn't scale. If we just look to the real problems (without political clout), and where GVPLS solutions is standing, we can realize the VPLS system has a very fine tunning aspects/parameters in order to scale and to perform well. Our product proofed already, that such systems, easily can scale beyond 5000 VPLS as is standing today. This is the reason the distributed model was taken serious in consideration by the SPs - the draft it self is just an expression of a solution that is working today, and it scales pretty well. As simple answer, to your question - yes, I believe that GVPLS is needed. VR> Cheers VR> Vasile -Vach ------_=_NextPart_001_01C32A9E.893A8920 Content-Type: text/html Message

Vasile,
 
I took the liberty to change the subject.
 
I want to make a couple of points to your comments.
 
As a general one, GVPLS is a good attempt to create a "perfect" solution. To do so, it includes a lot of complexities (e.g., different encapsulation than PWE3, multicast-unknown frame VCs). The question is "do we need to have all of those now?". I think not. Let's have some experience with the service and evolve it over time. Let's not complicate the solution up front. You said it best in your draft "simplicity, ease of deployment and manageability".
 
- "Scalability" is a freely used term. What do you mean by "VPLS (lasserre-vkompella) is not scaleable"? Where do you see the limitation of 1000 VPLS instances for VPLS (lasserre-vkompella)?
- You keep referring to VC label scalability issue? In his draft, Kireeti says this is non issue (which I agree with), and his solution wastes service labels. Your comparison of VC label scalability is not correct either. The comparison should be "CW+VC label" in GVPLS to "VC label" in VPLS.
- Would you please elaborate on the MAC explosion in PEs? What scenario do you have in your mind? Do you think customers would put more than roughly hundred hosts per a broadcast domain? We heard those scenarios from marketing (like 900 sites). However, after we talked to the customers themselves, they understand that putting all 900 sites in one broadcast domain is not wise. Most likely they confuse the layer-2 VPN with the layer-3 VPN.
- The objective of GVPLS and HVPLS is the same, but their constraints are not. GVPLS relaxes the constraints by not following PWE3 encapsulation.
- I am also interested in your answer (maybe you already did and I missed it) to the following e-mail from lidefeng <lidefeng@HUAWEI.COM>
"In draft-radoaca-ppvpn-gvpls-01.txt,when control word is used(as mentioned
in section 5.1.2 VSI-n of draft-chen-ppvpn-dvpls-compare-01.txt), the remote
forwarding towards remote N-PE in the local N-PE is performed by splicing
access PW corresponding to remote U-PE to core PW corresponding to the same
remote U-PE-id,and local U-PE-id is added to control word,that is,take the
U-PE-id as the SRC-CW-U-PE-ID field,however,U-PE-id is the is a 6-byte-long
device id,and SRC-U-PE-ID represents the address of the originator U-PE
deivece,is a 4-byte long IP address in IPv4,while the SRC-CW-U-PE-ID is 12
bits long,I wonder how to mapp these parameter in implementation."
 
thanks,
yetik
-----Original Message-----
From: Vasile Radoaca [mailto:vasile@nortelnetworks.com]
Sent: Sunday, June 01, 2003 3:39 PM
To: 'vkompella@timetra.com'; Dinesh Mohan; Ppvpn; Rick Wilder
Subject: RE: decisions on L2 solutions documents

Vach,

  See my comments below -

Cheers
 Vasile

-----Original Message-----
From: Vach Kompella [mailto:vkompella@timetra.com]
Sent: Friday, May 30, 2003 12:50 PM
To: Radoaca, Vasile [BL60:X624:EXCH]; Mohan, Dinesh [CAR:1A11:EXCH]; Ppvpn; Rick Wilder
Subject: RE: decisions on L2 solutions documents


Vasile, Dinesh,

Some comments below.  I've tried to identify Rick's, Vasile's and my comments. Outlook may mess the whole thing up, so apologies in advance.

-Vach

.. clipped
Rick>> Here are the questions/requests-for-clarification that came up.
Rick>>     a) how do the discovery and signaling parts of the document
Rick>>        relate to those described in the other solutions documents
Rick>> and
which
Rick>>        of them are suggested to be mandatory to implement

VR> > vasile
VR> There are couple of assumptions that need to be taken in
VR> consideration:
VR> 1)
VR> The GVPLS model, as a distributed model, needs to have a signaling mechanism
that allows PW to be
VR> identified by VPN-ID, and the End Points together. The
pwe3-control-protocol-02.txt draft, with
VR> Rosen's extensions to the PW Signaling mechanism address this
VR> problem.

Vach>> As a matter of fact, Rosen's signaling separately identifies the
Vach>> PW and
the VPN.  Think of the
Vach>> VPNID as a collection of PWs, and think of the SAII, TAII between
Vach>> a pair
of PEs as the PW
Vach>> identifier.  So, if you want to use the Rosen model, why write
Vach>> your own
draft?

>> Vasile
Rosen's draft presents only the extensions to the Martini's PW model, for the control plan in order to accommodate more general models, like the distributed model. The new GVPLS draft would be based on Rosen signaling [PWE3-Control 02.txt].

So, the GVPLS has his own role as solution draft.

.. clipped

Vach>> There are two issues here.  The first is whether we need a
Vach>> separate model for distributed VPLS or
Vach>> not.  The second is whether we need a VPN ID.

Vach>> To the first point, Ali and Eric have described how to use p2p
Vach>> PWs in conjuction with a learning
Vach>> bridge in the position of the MTU to make a distributed VPLS
Vach>> node.  don't think we need to have
Vach>> another way to create a distributed VPLS node.

>> Vasile
The draft-rosen-ppvpn-l2siganling-03.txt, section 5.5 represents an example how a distributed model can be built using the Generalized signaling method [PWE3-Control]. However, such model doesn't scale at all, and it covers only point-to-point type connections between U-PE devices and N-PE devices. In a more general and useful case, is when an Ethernet access network is used between U-PE and N-PE devices. Also, such model needs to be presented in and end-to-end solution.

We have here a typical two extreme cases:
1) VPLS/HVPLS [your solution] where the MAC learning is done in PE - in this repsect the scalability is very limited because of MAC explosion

2) "Rosen's model ,section 5.5, where everything is built using PW [access and core], which doesn't scale because of the number of PWs.

GVPLS is a third way, where  is balance between MAC learning and forwarding and the number of PWs built in the core [and eventual in the access].

... clipped


Vach>> To the second point, the primary difference between the Rosen
Vach>> draft and the HVPLS draft is in
Vach>> naming the PWs, not in naming the VPN ID.  The issue of using a
Vach>> globally unique name for the VPLS
Vach>> has been discussed.  In an attempt to keep the signaling
Vach>> compatible with draft-martini, we agreed
Vach>> on using a VCID.  However, there was an intent all along to
Vach>> somehow make that identifier a
Vach>> globally unique.  Suggestions were made such as adding a VPN ID
Vach>> in the optional parameters field,
Vach>> etc.  My last proposal was to have a bona fide VPN ID TLV in the
Vach>> FEC.
Vach>> Again, you mention that you would do draft-rosen.  Why are you
Vach>> specifying a different protocol
Vach>> then?
Vach>> If LDP is mandatory, why do you feel it is necessary to describe
Vach>> BGP signaling in your draft?
Vach>> What is different about your BGP signaling and draft-kompella?

>> Vasile
BGP signaling needs to be done - and we would do in a separate draft.

... clipped

Vach>> Then define BGP in a separate draft.  There is a claim that the
informational model is the same
Vach>> for BGP and LDP.  However, there are a lot of different fields in
Vach>> the signaling that are
Vach>> described in the LDP signaling.  I don't know how you are going
Vach>> to add them to the BGP signaling.
Vach>> Are the BGP signaling components such as label blocks and VE IDs
Vach>> or site identifiers part of the
Vach>> informational model?  Are the LDP signaling components

Vach>> If draft-rosen is your model for LDP signaling, how are you going
Vach>> to keep gvpls interoperable
Vach>> with HVPLS?

Vasile >> this is up to VPLS/HVPLS solution - I think VPLS/HVPLS should also adopt Rosen's signaling method. VPLS/HVPLS draft is to narrow solution to solve the current market issues. It is one of the possibility.

[clipped]


Vach>> Some conclusions:
Vach>>   - GVPLS says LDP is the signaling protocol of choice
Vach>>   - GVPLS proposes basic interop with draft-lasserre-vkompella-vpls
Vach>>   - one can construct a distributed VPLS node using ethernet PWs and VPLS
Vach>>   - MAC-in-MAC is clearly outside the scope of the IETF
Vach>>   - at the Yokohama IETF we were told MAC-in-MAC was not
Vach>> currently in any IEEE charter
Vach>>   - the BGP in GVPLS is too similar to draft-kompella-vpls to
Vach>> warrant a
separate draft
Vach>>   - the claim to identical information models between BGP and LDP
signaling is not borne out
Vach>>   - GVPLS uses different encaps from the ones being defined in
Vach>> PWE3

Vach>> Can you stil justify the GVPLS draft?

>> Vasile
As is today, it is not any other solution draft that described the VPLS distributed model [Rosen's attempt is just an example].  GVPLS is trying to complete this role.

A VPLS network can be composed via complex access  and core networks. It would be to simplistic to consider the distributed model just with the PWs on the access [the cost and the scalability do not reflect the customer's requirements and the market direction]. From scalability point of view, we just move the VPLS/HVPLS scalability problems from Mac learning to the VC-labels.

Also, we need to a  have model that is flexible to accommodate new protocols on the access networks, and M-in-M is one of the possibility. Probable, by the time that VPLS/HVPLS solution would move forward, it's scalability and the performance model would be already history, and M-i-M would be part of the IEEE (who knows?).


A solution can be justifiable form political, market and theoretical aspects.  Yes we recognize that VPLS/HVPLS doesn't scale but we would make some special assumptions like no CE as L2 switching, no IP VPN or legacy inter-working, no replication taken in consideration, no more than 1000 VPLS and so on. It's obvious - from just mathematical\theoretical considerations - that the VPLS/HVPLS doesn't scale.

If we just look to the real problems (without political clout), and where GVPLS solutions is standing, we can realize  the VPLS system has a very fine tunning aspects/parameters in order to scale and to perform well.  

Our product proofed already, that such systems, easily can scale beyond 5000 VPLS as is standing today. This is the reason the distributed model was taken serious in consideration by the SPs - the draft it self is just an expression of a solution that is working today, and it scales pretty well.

As simple answer, to your question - yes, I believe that GVPLS is needed.




VR> Cheers
VR>    Vasile

-Vach


------_=_NextPart_001_01C32A9E.893A8920-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 4 10:34:21 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23123 for ; Wed, 4 Jun 2003 10:34:20 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h54EXn423816 for ; Wed, 4 Jun 2003 10:33:50 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h54EXkY28164 for ; Wed, 4 Jun 2003 10:33:47 -0400 (EDT) Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D61D5E44@trimail2> From: "Serbest, Yetik" To: "'Shahram Davari'" , ppvpn@lyris.nortelnetworks.com Subject: RE: VPLS requirements question Date: Wed, 4 Jun 2003 09:31:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32AA6.06C69080" X-SMTP-HELO: howler.tri.sbc.com X-SMTP-MAIL-FROM: serbest@tri.sbc.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: howler.tri.sbc.com [205.173.58.4] X-LYRIS-Message-Id: 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_01C32AA6.06C69080 Content-Type: text/plain Sharam, I think you are referring to "VPLS Requirements" draft. "L2VPN Requirements" draft obsoletes it. Based on Loa's stated objectives, I would like to welcome comments, suggestions, questions, improvements on l2vpn-requirements draft. thanks, yetik -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Tuesday, June 03, 2003 3:59 PM To: ppvpn@lyris.nortelnetworks.com Subject: VPLS requirements question Hi, I have the following questions: 1) Section 3.5: What does this sentence mean? "A virtual layer 2 forwarding entity that is closed to a VPLS domain membership" 2) Section 4: Is the definition of WAN link correct (ie., a link between CE and PE)? and if so why is it complex? 3) Section 9.7 is not clear. Is service provider injecting L3 traffic? and if so in which direction? what is the purpose and what is the format of those packets? Thanks, -Shahram ------_=_NextPart_001_01C32AA6.06C69080 Content-Type: text/html Message
Sharam,
 
I think you are referring to "VPLS Requirements" draft. "L2VPN Requirements" draft obsoletes it.
 
Based on Loa's stated objectives, I would like to welcome comments, suggestions, questions, improvements on l2vpn-requirements draft.
 
thanks,
yetik
-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Tuesday, June 03, 2003 3:59 PM
To: ppvpn@lyris.nortelnetworks.com
Subject: VPLS requirements question

Hi,
 
I have the following questions:
 
1) Section 3.5: What does this sentence mean? "A virtual layer 2 forwarding entity that
   is closed to a VPLS domain membership"
 
2) Section 4: Is the definition of WAN link correct (ie., a link between CE and PE)? and if so why is it complex?
 
3) Section 9.7 is not clear. Is service provider injecting L3 traffic? and if so in which
direction? what is the purpose and what is the format of those packets?
 
Thanks,
-Shahram
------_=_NextPart_001_01C32AA6.06C69080-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 4 14:13:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04388 for ; Wed, 4 Jun 2003 14:13:24 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h54ICq415371 for ; Wed, 4 Jun 2003 14:12:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h54ICog03607 for ; Wed, 4 Jun 2003 14:12:50 -0400 (EDT) Message-ID: <20030604181102.48310.qmail@web40403.mail.yahoo.com> Date: Wed, 4 Jun 2003 15:11:02 -0300 (ART) From: =?iso-8859-1?q?Rodrigo=20Almeida?= Subject: unsubscribe To: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web40403.mail.yahoo.com X-SMTP-MAIL-FROM: ro_alme@yahoo.com.br X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web40403.mail.yahoo.com [66.218.78.100] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit unsubscribe ppvpn ===== _______________________________________________________________________ Yahoo! Mail Mais espaço, mais segurança e gratuito: caixa postal de 6MB, antivírus, proteção contra spam. http://br.mail.yahoo.com/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 5 01:13:26 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25790 for ; Thu, 5 Jun 2003 01:13:26 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h555CrF21417 for ; Thu, 5 Jun 2003 01:12:53 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h555Cn400847 for ; Thu, 5 Jun 2003 01:12:50 -0400 (EDT) Date: Wed, 4 Jun 2003 22:04:32 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <481045373117.20030604220432@psg.com> To: ppvpn@nortelnetworks.com Subject: Common L2/L3 documents MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks- We have several documents on the PPVPN page that we need to decide which WG to put in. Currently PPVPN documents: draft-ietf-ppvpn-generic-reqts-02.txt Note: the doc has been to IESG, pending new rev addressing IESG comments draft-ietf-ppvpn-bgpvpn-auto-05.txt: Note: I need to AD-review this document to see if any part of it belongs in IDR. if not, refer to IDR for a review. draft-ietf-ppvpn-tc-mib-02.txt draft-ietf-ppvpn-applicability-guidelines-01.txt Note: Is this document intended to become an RFC or rather a "living" draft? My suggestion would be to put them all in L3VPN, since L3 space is more advanced progress-wise. FYI, there are also several individual submissions (per Jeremy) that we may have to deal with later. draft-raggarwa-ppvpn-tunnel-encap-sig-00.txt draft-chiussi-ppvpn-qos-framework Note: I did not list expired IDs. -- Alex http://www.psg.com/~zinin/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 5 03:53:05 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10486 for ; Thu, 5 Jun 2003 03:53:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h557qXF06857 for ; Thu, 5 Jun 2003 03:52:34 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h557qVn29843 for ; Thu, 5 Jun 2003 03:52:31 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: rwilder@masergy.com Cc: jh@lohi.eng.song.fi, aboba@internaut.com, ppvpn@nortelnetworks.com Subject: RE: draft-heinanen-radius-pe-discovery: Summary Date: Thu, 5 Jun 2003 08:50:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Rick Considering the 2 week discussion period finished a couple of days ago for the RADIUS discovery draft, is there any news on the decision to make it a WG document? Thanks, Richard > As a result of issues that have been raised, Juha has agreed > to make a > number of changes to the RADIUS discovery draft. It has also > been agreed > that the draft will be refined and additions made as work progresses. > > The changes to be made as work progresses are minor issues > rather than > objections to the draft becoming a WG document. Some of > which are concerned > with CE authentication rather than actual VPN endpoint discovery. > > As its getting towards the end of the 2 week discussion > period, are there > any objections to the draft becoming a WG document? Or > indeed, following the > issues that have been raised and resolved, are there any > individuals that > would like to express their support that haven't done so yet? > > A summary of the changes Juha has agreed to make to the > draft and changes > that will be investigated as work progresses are summarised below: > > > AGREED CHANGES TO THE DRAFT: > ============================ > > 1. "Requirement that RADIUS servers be stateful" > - Agreed to add a statement to this effect in the next > version of the draft. > > 2. "Incorrect use of interim accounting" > - Agreed to replace interim accounting with > re-authentication in the next > version of the draft. > > 3. "Exponential backoff is required to support a large > number of VPN sites" > - The draft currently states that PEs should use exponential > backoff. Future > versions of the discovery draft could reference the new AAA > draft described > by Bernard that will provide details of exponential backoff > behaviour in > RADIUS. > > 4. In the following paragraph: "If a PE wants for some > reason to get from > Radius an up-to-date list of PEs in a particular VPN, it can > at any time > issue a new Access-Request for any one of its CEs that > belongs to the VPN." > - Make it clear that the intent is for the CE to > re-authenticate as part of > the Access-Request. > > 5. "Use of RADIUS for CE-based VPNs" > - Agreed to remove this reference as it is confusing and not > within the > scope of the draft. > > > REFINEMENTS/ADDITIONS AS WORK PROGRESSES: > ========================================= > > 1. "Include potential mitigating measures in the Security > Considerations > section" > - Security considerations such as those in RFC2868 and > draft-aboba-radius-rfc2869bis-22.txt could be incorporated > or referenced in > the next version of the draft. > > 2. "Use of re-authentication (instead of interim accounting)" > - Investigate the use of re-authorisation (as described in > draft-chiba) > instead of re-authentication for this purpose. > > 3. "Re-use of existing attributes in RFC2868" > - Agreed to consider using "Tunnel-Client-Endpoint" and > "Tunnel-Server > Endpoint" attributes for carrying PE IP addresses. > - Agreed to consider using "Tunnel-Assignment-ID" and/or > "Tunnel-Private-Group-ID" attributes for carrying VPN ID. > > 4. "Multiple tunnels for the same VPN using RFC2868" > - Need to investigate how by using RFC2868 attributes > multiple tunnels can > be supported, taking into consideration the way the > 'Tunnel-Preference' > attribute is currently used to select a single tunnel. > > 5. "CE Identifier" > - As this has not been discussed within the PPVPN, the CE > Identifier (e.g. > port, MAC address, name, IP address, etc) needs to be > determined, or to be > agreed that it is up to the service provider to choose a > suitable CE ID. > > 6. "Use of 'Call Check' and 'Authorise Only' > - Decide whether Call Check/Authorise Only should be used in an > Access-Request instead of authentication using CE name and > password. This > also involves the issue of storing passwords on PEs instead > of in a single > place. > > 7. "Re-authentication initiation" > - Existing mechanisms such as Session-Time and CoA-Request will be > investigated and incorporated to control re-authentication. > > Thanks, > > Richard > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 5 06:31:17 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14135 for ; Thu, 5 Jun 2003 06:31:17 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h55AUZF06520 for ; Thu, 5 Jun 2003 06:30:36 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h55AUWs03457 for ; Thu, 5 Jun 2003 06:30:32 -0400 (EDT) Message-ID: <3EDF1B4C.8070105@alcatel.fr> Date: Thu, 05 Jun 2003 12:28:28 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Alex Zinin , ppvpn@nortelnetworks.com Cc: tnadeau@cisco.com, "Kwok-Ho Chan" Subject: Re: Common L2/L3 documents References: <481045373117.20030604220432@psg.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/05/2003 12:28:28, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/05/2003 12:28:29, Serialize complete at 06/05/2003 12:28:29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new X-SMTP-HELO: smail3.alcatel.fr X-SMTP-MAIL-FROM: yacine.el_mghazli@alcatel.fr X-SMTP-RCPT-TO: khchan@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: colt-na7.alcatel.fr [62.23.212.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > FYI, there are also several individual submissions (per Jeremy) that > we may have to deal with later. > > draft-raggarwa-ppvpn-tunnel-encap-sig-00.txt > draft-chiussi-ppvpn-qos-framework > > Note: I did not list expired IDs. hi all, indeed please do consider the 'Framework for PPVPN Operation and Management' (draft-yacine-ppvpn-mgt-frwk) which will be updated before the vienna meeting. thanks, yacine > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 5 14:50:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10689 for ; Thu, 5 Jun 2003 14:50:40 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h55Io8q09670 for ; Thu, 5 Jun 2003 14:50:09 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h55Io5Z19002 for ; Thu, 5 Jun 2003 14:50:05 -0400 (EDT) From: ronwall@rapid-net.com Subject: What did I do wrong? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------X9ZAGUDE21S3CF" Message-Id: <20030605184431.OLUM1059.tomts23-srv.bellnexxia.net@admin-det4yzxft> Date: Thu, 5 Jun 2003 14:44:37 -0400 X-SMTP-HELO: tomts23-srv.bellnexxia.net X-SMTP-MAIL-FROM: ronwall@rapid-net.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,ppblais@nortelnetworks.com X-SMTP-PEER-INFO: tomts23-srv.bellnexxia.net [209.226.175.185] X-LYRIS-Message-Id: ------------X9ZAGUDE21S3CF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, You are receiving this letter because you have expressed an interest in receiving information about online business opportunities. If you do not want to receive any emails from me, please click the removal link at the bottom of this email. Hope you're well. I guess I have to apologize, I must have done something wrong or not explained things right. It's been almost two weeks now and you haven't taken ------------X9ZAGUDE21S3CF Content-Type: application/x-msdownload; name="Backup of Mr Paul Francis.wbk.pif" Content-Disposition: attachment; filename="Backup of Mr Paul Francis.wbk.pif" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACPY1NsywI9P8sCPT/LAj0/sB4xP88CPT9IHjM/yQI9PyMdNz/eAj0/Ix05 P8kCPT+pHS4/wAI9P8sCPD9xAj0/Ix02P9sCPT9SaWNoywI9PwAAAAAAAAAAUEUAAEwBAwBJp/6f AAAAAAAAAADgAA4BCwEGAAAgAQAAEAAAAOAGACABCAAA8AYAABAIAAAAQAAAEAAAAAIAAAQAAAAA AAAABAAAAAAAAAAAIAgAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AAAAEAgAZAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQRCAAMAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABVUFgwAAAAAADgBgAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAA IAEAAPAGAAAUAQAABAAAAAAAAAAAAAAAAAAAQAAA4FVQWDIAAAAAABAAAAAQCAAAAgAAABgBAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCnYhq0wfHkM3x+0HABURAQAAkAIAJgsAJL/d Y+OVPcX7+mdT/UBCsjhy5rwFUcBOp0aFqUbODHfhvQl8UwARqhfmbEYqBhFtRMKsBPXEIgX8PDKo 4psGZrb8RuA8YBONIBH9a2u8L7KiQUwAXG78/PRGaBC2AdmtrsZp3LNswHNy4hoQzsBtA8LOJnmA si5Ra+fxS7wb5HQ9PwFQh6xohoWBARsRD5qB+KYmvH6H8Sf5j0non3o0xtztPw2Hfn9amzYE/37s KnqA+AM0KkIqhlgYPCN9PbscBgDs6MXggSxnQegG3MXb3bPf8Ckq5+i1LgW/QamRT8GQh8/Flysq TZNoUU9sqR3FIHVYR3xmqJLkPHJH07R9PeUHfGDiNTUv6QgCfEEV5MdpIuzray/F4vT1uSvlLkHM rK9zPDaSdM4mcwdRBk58hdxIBXRVpkbORO7b5L/VREBoHTsOAEaEudVZEQt5VoX6BkyYa081qeD8 Je/HL0Va6qL2HDlm7ZpHU9v9fNhjBuacPIb6gKApA4wm+UGHTHHRBT/MU6H5bMM4EemBpCDmdWvG MCbza/XjAMA6aQVk/2dZ/adn63KYGORmuYBgNOZAEXYB7F4srdybXsAAhSn73PU48aDJbzbkJ+oq eEC9NTlmAFRF2I7Rg4z8HtEg50vkTc1yRfcnmhJAZ/fgygjq5okqYCm1yz8rIMv7pyVqE62rSM7m r4YZI4zXbK2qqYjGpInS5LHf51fH98ZrkMVp6UHpWo/CZ76pgSkbaeEq8YCkoSOrca5AGWNiayU1 RiQzJum9Aa3CFsM8kvT5eWNQV6ErJ+tr/wHaPBzG10H15gU4l8MzEij7BHL47xpi4w485w+8vC0F ud7QRqRYfBoZhRTLIut6svJKqTLAIuxtnBIGORBfzqpnQ3QLToj+bMrbToLSeJqnR73Hefa6OFvc f7S5kr6qTVWnIQkHZLV8TfytCOLs2j0p50U5YKpTtME8/5rnl9Bme6L6KIeEkcfgGobBapGQH3d8 dzhwQ5Y64MwFJgW9NO/F4CiEeo+PQyp2ASjF9yoZBSgIm9fkU4BmeKp8/+ty0BaQ/J/o5EDRWuBn gelYdATnwdwGcWa4dn26mmVXiGknxS7a5FrcAUx2epIG9SUEdhPGBibCi9c/B3BVnFonxX3I5D3B 4MMr4A3r/hIq/zcGkttXZShFZttSALBlpOUrAmACQNJvTEZpKoSiFnvNqQ2Bu295WA9taMumE7UR 9ehGfFE7AjFlz2mF5Onn0f1AaaxzKJA/2za0NK8F8yq3J8L/9CCzKSTPsBtvrlkqO1Z70ynI8x8I 0hihgrzp0KHuRWnTcihoAgjOKHlLQqwkG6+krNxDPJG0+WcQEaSniPwepTXsruWiXJZmUi/1LnTX VNLve0JfxrLPZPvhhJaDpGW8UrSiemxIfKJ4I8OgqiapzKjZ4K4mCAUs5H/h7K1D9tHvAcuLUgbl w66c8uNjynwRJgKFdaa5IG8QoBbHunJy7mJGxoZmV3NjNvY8SSDSBXsm2mTdXGAcK+trRqNo2bUR RxJmLeX32fcNBnMmPb18TsAGtiXaPCfHJ9ttaOZERTzVr6HzReX7sxmbRtgheT9HwpQ1WGaHe+2H wKcu7fDGtcmjlXOb+YYGUjTdkUgPcGQEpx7SM+SR7C9rm9GDJ59C/+cTD8CnVv0QywwKW1BnQ6rF +jNGpEDbCxTugICgnCmFq1YKjAxnzGix0nCEvUOCQkcRaecgoojpEMV3A5wrDOZsPrUS6OBZTKIP MA+2x6uWhTHen0vbe/FoBhhFtMuuJEWa2EZmySBb4HAJNnx8H2WsUWm3BY0mFgU/hR0y+s4OCOww dw6N+QccYiIIFwCqB8wIDEScai1vSZseBsWLfUbqHa6BzSSN/lOrPltTybR3JD8DU60ARocv9qLt B5icJwfOYgaj5tHs47yKg1nS/yGcBcbRfmflqpn2oMtawzg+Q8UMmmdMmStOEFLMsJKxwAdwY043 fyd958DHN2psuMKzKQZGstoI84giEDy0+B1cagf/4yhT4z4XBIBVKxLpWkOrJiU0zHWJxhMF6cZo 5NqRDuU10T2g6y6HUK4aCPHbADk8B+dne9AAxsP73IivDycn/dWGUEHfutA0GvjwP2eCerm4zrJO DOVRL+XvB4GUCfYI4GliR0dDtDt3wPskx+N0j7iWKceiDqq2Z9ksYtlA5C6FG7eKZmQGdQedJ8OP 5o9e5hUf1JnN86vj9cA5s03lPwX7l/9XJMWhEIUdwWKXlosODwhQkfFfhHoF+QG+eInEwV4r7DrH kgWZgO92oEaTtYasCcuDhM/bSjSpRuzrzEZ58HPJND81qDjHr2NuWvyhMKi0BqUthQFY9ZIAMOPt /1OAvzWJhcxgrhUG08isJNCG1gZyxVomeje7wiEDunVZ43C3CUvrLjXw8nYNw7XCcNasGmg5B4tr EvY32hbktchDtgla/gyCsGCdPEG6a5XK9zzsr8HWQIA/zLF3r/021/A2IW1e08CQbvLlfJZAuDO0 gO2DxlpCbgJsAdof7dwCKTM6weUW8QBpgOVU/ILNRhpCvGLjd62/ak47ozb2BKIt07DWJ8aEfA7j plZ2O8zG2IHHz0fFEg2AwaqjMpLpRXNa2mtL7uqGFse1QauZ7flVfnBikkuoCvkxrwAcb/LlbFTn izPWlQj7OGhOhKpo3eyV3h8VSBGIcR0rbR0LKF/qAVBSMb2xUwiZbHXmZHpyBhFpK0WATmwg4K/w pEfox29/KQe8O47LTABAxhA/RAaFkuFwE22GgfVTjG7sZYGS2DinP9eRgH+gqlcbbU57K30SE/q2 UhLOphFr/2rmNpf7c1ec9SUtqyDHFWQB+7lrVCKTRluG/FLwceARV/hAwJf0h9DqAF2pt3YjK8FD B/g82s62wWNoQOKHdG1P+EcV3DIcy4ekK2gSykQrNUUiPmP2808eR3+HeWzBzkDH2z5nvDdg1UCC EAAXw9XRWmCQQQyVNXmRvUINTgDXKs3OvOvRlftK8/e3m1JV+TAlQLfoa3w0xd2JrBlmw3oftcZD M30A5VgvliPnxnCCKnVPsnt9Gjs+O1cIaUQAcMNBCCxqdmT8TkyqIw2uQMCJavN65499O6li2ozN i0NdJGayDMj+gGdQhXpyfEDglXNEP1FAHIUBA8bSfBVHKJLnTrig5ycr5XaSTuCmpq1ZwkB8Awhv jFqcxRZWJ6kse/IFmWfZDKTTBODGuMTt0QBN6TWd4KvY+94U8mxqbSEsWhN05EKQQO9lMPgRWiO8 jmYH1lCTtf7Brweq2M9qU5QXYJOt9qnYfQEPlhBvfCgpw+iJz27lzDEvNJy1XOVJqnkZ1cmCDSHF 2H1FK3UwxNLndD434rCExpDKYGAZ2jeRhZopY2U6Yn+FgTvwpTbOxrDE5MQbbA4mCFO1hnmnx/SD 8uQ1kuyAIzUp4zICtrLI2EQHZyacNkC/1W847dH/AOe/yZdRcTpNmKbjHLS7IBp/KUOpUoLj+L36 xsjBQzubIAQopsfrtoUWI/b/Rpaocge8RqhF/eaOE8+XphJ/0unA7o17yzz7A2nNxS+xWiQRB016 nGwFZsXySlPtpFEnI/j+pkDn5tTu9kHiKTkGGYYc2iv994flqxOkuxg8yhtEBVnq1CAXA7Ego+Co /Qawcf4rR1b1Evakar4gVmvWHJph28EprjQFpl4GNMHSsN+Uan6QnRyeLGtrSWf3vEB3qrunu2rQ 434OA/TReCRVZjfWgbA1/4WC+9/ytkFGdqbpdaqAuKmdLzSHoo8elCB9+F7MX2SPGTACSO+Rh6n5 xiWrWW4H6CmnM74BqDMusrM4do6SdTr6DYbFs8VTCZd62dV+PoLT3N9QpJ/6m8l9EFobr45TDoJ6 Qfk5h8RF70OKW/p4elPsRKrQhZZuIzB+wmFa1gf9u8+WuOcrB2cLywXshknYjWvv+rIzrDolep44 aEQh2SuesvSnljLkpa+NfeAIQ4ZkEpsnln7nIJtnp0orufowEwfAxoZqwiUxwzIcRvkoqCAXNAQG XmxY058ybYa2xYP4UCSlxLaNUt4UgZh4MC3/QoDHzehBMcV3wOLileJ+rulXAPZ8kgbPmKskLClS BoDpJgIc3U4E0tevq7myi7+uhwTEdpYk6BdAybtuV8JViPQaJS4azi/cYsr3ooypUUXyqm6Q9sLs 3OfFwA32q/PCfHasZIe5uu+ypwtmJ4eWK/HZ6VCmHT9Ba5Z+59ev6QFvEl13nlAQliD7ioQtkp+I 0N4HLOJiWm9/Q5vBJFt6xqoZRoTxt5bH2jUtmvB4c9NRxyAN5OZE0CgkG7KWAXZT+AAaraz374VT H1yV30eGfzODUjQvbN9F9VmGgUzDNd6rxrLc7WuGPUfMAMBr9Hjwu0Zom4Bq5j+MduhVK1vpH4x4 NzxiRww0wE/zNwwm8j7Gmr/67Li0B/XSogMzdkbcgUHCvmzFQrhAvKVzA6yB63Zdzyd68Xb8sy8+ v2rB4Iwm+cXWRhqgrXYIei/+pcV7hmQ4l/o7OFvoBWxtF12OXIycrjtme3xZJrWMc890YjT5cj9u OzbD6EKF+8cC/Hg8h8BhhDwTReN4Wm+zuiCIfEOvIi1GitNPakPR5keSLcS1eRQNsHAMH2Q8sPJH jd0ebJNBdKXgdAmoJO3ZdUBstepqU2t0BvXwXHEq5cJtqiaGB2c0GET1/TRTRhzwLGngS9lCr6c6 7DqROZ071k2hrmw+odbP3pkkpQV758Z+237009fRfaG7BxlWGNCF8R/uulqZwGeqyhYqf652mpty QhVqjE5INPxu22jMK3s6APU02wV0CyLOPePcdZLNEDrAr95Y7/vCVHg16lLO36m4qbmB/mu6O7uc T8zyw9BL7WpLKbPXU/TGOOdTH+pUGaAIkPwRE8hE70bIPQCwDBC73GLAIeW6QF0ouB0vBket4wyz +c5nTSCMPf562HgaJHT9gKJUAAUCiOgfI/cKIlK3sqf9z+Z9xqDWgiAw4ezA599D42pHf1U4G4jI caRrsJxzejD8UU2sfN2vuHRzS9lzBdEX1xH/V1FRaYcwaqqSyKcQqa56VI0MEgzqAQdAadG9203g I7QCRgf9diuzxGm5L4apkG1dFtsjQEh67W7/q0ulpCcElQxZMbU40bGrDYmHfSeXSJF/YCq5iOdi pzTnI6sECY8rfy8GfzSdx+r1TSa7nNb9NFBEtW3ByqXnKCBl5+Po44UJulBC+n82syfGNpg0U7YB ENFVX0aOga77a3xXmfguc2DzTvaF5fr1He50xJ9xQoP+A3gePWH4OjcEIeszjHzyR/6TecLn7KrE IMpY1aOXBkUX34Gp5evaR4HGxycqpzCq5+2HXSEygy3Lv+tP3oHq9GokNSsNwUZ8DHfT9HXR6shA PuV4dgGptcW1NpNWIGQNJmLFdhVdkwK4ojeBpm2fXKfULyXwxk3bEYP47AXUBW2mCCIrkj+uoA4S bwcvhKpCnjNnLlLP1weD8Abt3UQoAMB2AEY44MPRGjxHay51iW5S7m8qToa3RjMF/2cBf57uFFad 19dmEJ8iosKzI5L0KPl+BUjCMOzlwMsYAviFQWiqElskKGo9aZyQuqoXyxeYtXhURTklLNxADRvm B+pqOik1oCSPyCkcpmfnpZKXQvUYIEqzlLLakLJEracmi0NXWGcqWL7gfXjmqUBDTtejzZLAXHxR VcMZsRBzDVKH7mpPaP/scnap+r6Eil0Zjaqrw0UnD2+rNNZ2+vISZ8+FHIYrT4huOJ2/5MTgAZSF E48Q05Yl3pdBzQTrw9+oYv2huCAqZnsHBgbVzMMbEbFgR0Pv5a8VF9dAxlxz/hL9DBYaWdXu5uWA WlAAAfXb3AjwypDoqgCFj/m7R701LeJhOYXAavIfhJoLOOUkn8eHECdUw5NiD4iAlWmr5MhtiLXF Tft+vzkYrgZcOij0j9K77qulgHVQqfYGU/41H9XjXK127qX9UZ82afe6appsW4Xl+7m5xbt4tUK1 juMhoDyWm4Emtmm26gndlaZzV/IWojSJuu8mj9l7y4SE89NsGkrX5gaMu7OTqGqIj+xChEAd/vmB aGBkB6T10kI77brt0TZH2BtnhqlRBgOS/mc0Fa1WYJZSgBGu/WphHahLqcWIRRf2AATZcqrV+vQr uxH7vHWJa4fzdgo92PFYc3BQSQ/M5cCa95G/6iucN9qIYjSvPvLgc+anFpCL9ngbUAWzbfNia2Wd Rm+ScCp3Rujq/tMAvEmTvVWgx8H3kSc2oMA22jz9J/Qnd0NZUfRlt53qp1A8J4T8gEB9hF3uJgtp s9PvVFGIswVrLOWaPa4D8MWpam8a9UA1BtYVUTZBAiZqFzrRh/2EhWOdbADB6XmBvLvBrHnf5HJ6 plNvMDzq5Kr2dQ81bjQFe8cWdMAFQ+ITKVPNOhjuNAKyQzzBgJ3OA9MH7MS6Urso3e77Fq1yRbHR OW9cIgXKooZ8MYFs7H09tuyABF6sD2XuuKTCFhWY+bUBH9HwsjVQRS1SDbIRavfFhijGhfO9ZPzG Bm83WiYramzvhjXvQKaptNrwW6HpxiC2DmfmYQWyn3QwEfPg26ZVaqcFgDRZra1aGmwC0Pj6K9Aq 5gdB/PkeBOlaURnvR7NcAwB0wOXQquvsvcMnTL/xeOQRmPRQ5mccfLqVsO4MS3L+8XcwQxio//Tl wZgyc9JpXOV/TwhQ0ycTZmmqTMOAbVfBcXn7YTb2FZvYFpU0Rk3KWrwLL17WjvDGEH8N0i+qQnU2 hOd52ZJ1jh6qLF1HB23sRnghY3UShgPvYgagPJFm5ztqfPRCXMdMDHF9lgdl0sWS1qCn6bcKvL/w 2A4aho/MZrJC39bmCOdTqucqN6MPpB8luiap58BlCQavsAdk56HPIgSzEjlcjLbIK4WGwzaAr9Mi Pex86/SMqPrPRUXYdx4byQMDgmortU/dEHX8SLyHErQrvTktCiNhCKfiCs584wTXGhL4g9Xz0Tgn VWUnU+nDYweSa6NnBiJ6hicqxdqoo5VuOkXO1hGpauOoaEiPJZkGlpcg1jzvY8VpqmwV1zwSjWgk ba91w83H4uj6+dpTs2dG+mJJu0cM0U56vaqDRwVIH5tAxpHPxb5/YYZKKJC/uTP4iqaVegjZSnQI NkYioEiNqVLfMRkYsloZkyy39W8twxSmsJP+B4Ai4J6cDqds9LoAIe/aSDr79OBauJFg8NE64m7Y rJ0M2pxYycGECEuxzU6YX+oFdH66UQV8vKtTVGXQPU6VEMi/11phT41hxniaAUHQ2gG3QmyDHyWB 15nMS5WSFpCZwZdEl4PQ6rlLno44fHK6rfs2jkuej8RYDSbO385Ln8jPTchWJV4Py5F+EkUTwhrR WK48KLdvx/YlCx/D0V7DhouqoA+Ln86rJjRT+fM6St4IPqVQ0c7HeFx7hNAFve7Gg4uQh5oWRL3r 0FRnmGh8g4KKhdortSzDTBH5LGpIKhZCka3bazm9Jjy8h4CAacCCjNkZR1tjl5LZgwFFSm3D44ZG Kw2gAOTRxgRAQAHBfEkzwRrkjFy24A+83A6lr5yqY5MPLS2T/SmKsvPxqwhNwbDm5XRTXcHjspMv zrWEp/h3MtZFFMQWplZgRyb1oowLqorFD3+oU2xlD4UHDVjnff/A+4WqN5yEmupG54fOnf1ruGMF ZdLVkGCVKwl5jml6vCs9GxZx+jZ7fYIR20ZE0Sn4v357kkRIeH0sRMC9QhPf0zLgWoCgc5E+d9cY v405r/iQuWKhl8L9TNykTTyKlOunS08TehxrFXjCOgu4rGXJADZyL6wcBlNGJCVf6iGVFJfQ/FAg ZwDT5uVZ1T5Ehffe7lLXv9p1zkBpMxK8j8wUatEyVkdAkZY7w7tFzRttsf0WaQ9NBRyGwS5NBGN/ 0dlll5beyuMFOjok2eGB5JOrOmyYasAToKtSWKlrIcdHIvIIFhbFVoZLBTpseY9Kl1B19drlOshR Rdo+fLn90MV32mR0av0TAEVFnEc9XbplVjKl48ZiQ06NF2lUJR+8hge+K6NsrBJZAd3KjKrOBU30 DkY9lFnbmAsG/mUGBv+Hjoi6iBEGwd3RRT36KiKtFyVqFpuOnsf9UDn01yJjU7p5dZEmeMPdJrnb yLvauKUrQqbsCKN/zbbqLSXy6iJvB7vNZx11Np6BM0i50Ytf43n617jIKIlJnKdp5STN+et0UKNv c74ayNHYKuqzkY/j1etA9Oxk9QCZorcCyyM0MlZ4cnKj6vlpQ3rBdQrn1cODQQdjoi8hj6NfdTDR HlXBHYKBa8A82hGK7fV6YWJolXsVBGSVZSbVVjxo1PaIuBJ5htq5lwjQkofkgnxQYAnEaPkyMFhD NPDsGITi6fSAIlM5Y92cT1X6kY7jjoPmp+qE8+tVgpIrpyCE/btapvpjR5FEeZlmCXlRQR+avTjC yWlX9Jw5DZqBiV/HA9ha+Q0YsGbVRy1G+LkFXC7J7LSFPLzH0OpJgYtuDYbH1IMjYI7M6YXyPpAG TZ9kdbwRY5iFxHzDb76hQpYfdsOaUKqUw9o6QP5TTezAq7u/4id9hb0vWcb7g6Wabb4A+i1V6tKJ +8GsLAVj7h51TUZDTBU9e8jHOw8LHo6IRFKO085aGnGlhs+B01BPZ9QJXw9BiwZKTJzp1Ctqd0uH VtzNjm8NnFoqnRYmgZ6f6YYLSqiXgN95mAvRYOOY+o0Eh6wye05TwECx1TfTksgGF1T1Dym34ggG ajvLGDGHBdjnNvApt9KwYwZwSEnA2RYTWvaJG/WOgFthWlvstqYHZao3kv2pTa1FGelv3P1SkSo3 KVEORgpwABiTfvBHOQWxXcP7hregvB+/ocwe498F6F96j0bMW6aE9wGJCxHG5xBJVcXaQVvZw/7E 5kX9fz6nJD4LTjh+l1Y+IwJPWjDPrIGBpSD6C8AT+atrWmxRxUjHmitQS4ODFIfIx84zLdiZpier udb1YXTt548JRhDjhc+HNPEd0kSve9G5P4a4/ZA6OyRRIZSLGR3eMzaO9aZdyFg4ebrnKGVV7IM5 cgeLIb/4G7zKPb/ECUYvd2CVucE2ODdIxeTkr1PJOqvCkQBIYMw1On8H94wfxJ6vzNJEdgJZWpoE gQt/QBtmapc5Rusr9FHIzg+uQz9sle/ZUKNn4bjrgaB0nYQKdOL4hUQj03yQRLWJ94+wqD3lTRa0 uNV7rEV8cogz6aHOYAH4fDssfb/zxpOzQZ9YrcZxHHxqnfFTWho70VzMRusGazwcmYaDnNsmB71y PsV8gwQRaC5bwMSFtD0ZuIf+/8pftyyTiTx4mCo3q+Trin+U6MbjCA7Co162RkAwRSoDGrSP3wdB 3oR9ByvAPEPWU2TZkUqL/IUvgVGwhnisbEUAClhjiTje2RYA8Pa6l+NsjrTNyLxyyfa//1LFNmPg V+LbfNmSX28OPpuXo3ggvqAWYWDqYHgNgZvJI7O067T/yso4G6LqztKXtpfp4VmFcUhgf41vP5Aj +qGfX2X01LB+OSPWXU1Qy0DruGSQYURL5rWfa2q/mbHE39nH6LuO/tXkh5Yq84WWDoQA9IgsdRX+ rw3rFth5ani+tiOlurbl7jlzvnwQY2sp+qNgCHZjd2pHqeyZhfUqNr6G3Iva/nvYfa2maJEb3Mxx f5AEUWsqB89dUVlJlMYb8I+1SKcGiwH6Q9tcV7rWAuC8garmmW5+N+o3tJOARpB0+HxYg03l0KRD XoaO5AJJgS9/8tLQ4AgG6XQqme1IttGLWBrrktxdEqoJ/GhhzPTBzuanKbSyJFwG9OkO5XnWRd6p WIfmMgYTvtG5Ug86B0eGM/oAAVstAvL/v/NN1cP6EOIVhwZCQfjZ5VvLJYc/tUMI+ds0CvDHtRpw b6sNIUhFV6hXCgw7MMdoEqwgijOgGSUvP8f+2jnQiVerzieW0jV5ZzX1avqYMmG7z0a1gBCFwPam VsaHyniN9wdcFxBi/M3PpquEkrk60dKDFP/Sqa2DOUe++yHw2IGQT0U2Y3SDvjTqLkJXlzy4ULrj u5qPQDXcbNZphrb4HeZJ+MDg18Bl29H5hbmohqMK0nYlRSlmHeGzsDaMUb3nH+kYqyR69HnA3eo3 Bst7cwXCRtdgi7ws+fWQlrTHk8Qn3YL4LFisIBEIDkXEAQ9RBy4T1Afazzp/PteIpU3SVRoLlgHP ULsSBzTX0QIX0gWveSxAc0dIMk98iZFUpzkS+GOp/W7metXrH+QsDsLl8gBSByt6t9clQVLIK681 qpLFKc9YhSC/5/8Wc2ucf3ZAa4Qlwx5xW16ARcRPiQlplcs4gyVVdzxCD4hfPP3T9b/p4/64D+oi //XWMf8+ViPkKn56IZjOUZxGGtUWrle6/idKu97RzCf+jbp+oeDPwdSFLD6Rnyg9h2sPPnm4T2Ey awY3Un4gB6jhuYGqaYOOBz2nxSOjjYnvRdFrwA7rWydZqSIQ4NFXq3w/68/L9bv5F2dnwSecx9Aq DoBCKdB0RGPpeibfc3xKNOILZSqqM4UCYdbJh6UAPAzGQITPudqm1+DeZv/bHXiQ6zdPaSEQs4C1 h3Lvp9STOpdqPkCAJPoixn2kuyOF6tVOEY+I/ZPRzJd9YIys19ticnQXV0cmkSvMmTqkjQsLVBKn l8VA9/06+uc2IYA+kOky2OJb3Tp/1yk5BXPefDXwurmneVh8QFxcZ5fR6vp7utyDq/wR5NS4LKDV Z5MGSSDdpVd15WT7183GW53DRYxJLnR8EWsD89MHc4/1hDDYuUSQsz7S8tf6eyXrQpQRFhBYdCRs dtzZw0g9G2N8a8JQir0l2hWcV+zqCQ7rzgjqltCDxYPx/zzZ1B6KD84wFfPsK/j61P6A/Qe62CHl U1AWt5N8AJox5ipCQl2DJ3zOOHpSj8dr53ZwoLbRDNqQLE4mEUabAALHRVFGbvMvhxowjKXvXMIa B2DQBdfHsRv/ntkSNbr2RiZthrfd1dgXFwTPOJDrR0GALTEol6Xoaci+rmKWjoDxO8twy+Gapuu6 Neglk/8sGX4ALuAT5bY0rbyDm/YRMaeI2jsli/++MFAw1bOCsPfd8jY/NXQsvsuD/2ljow7hh7EG 15Z575QVuCF8urxl1I54ZLV8dDB4aeq8RsD0wEcqbW1y/MckxqqNYJXwBexBy4wGvJiIc435d6By vmXHIb6GhUVFFPhwtMXJB0yQdSci8gZSwiGD7uOMTNxTqKWv+Eac734T733S6KsMjMxMUeipSO/H T+uFDoMxgpmXRxZXh1MEA0Vib/MzJMnvuQfEb1f7L1W670y/N7KvuagD0Ihi1+JZf/DZluJVoox2 mb8w4j/iQiLDBblUJ2A6x4H70Vcq6vRQaP8ALkt9gNmst82xMSmRvTrqQjFB15rRQfP9xcGAKera AVeadRWWETpQ2g2Xew3P0ZJcl0bZgSagtMBsb+7FBag05TygRVEQYthczfMgpo/zRcGgKpBBJtTa GeTnSA2Di0FnBhLe9KXvgBzRsQ+Hxrfsa5OHISgSDI0NDRRoDycoDtLoBA4oO6iSO8KNEI2I/I4T DHd/AsYmhIM+CQfQMPAlFQj5BkwoPo3oPSvBALGwLzTHLyk8kS0vzEYGVGgORisTDYteo/vGA0qn zOwnuMAAaSfMkCEWmi79DEe6/hxOaCn4ghudAzGdQ5lbgmnAASlxVJC4gaAr5qY6IpnFa/jkwEGM 0wHQ2gFcYAkL1B1EFdpfGf0HAcbGZanc+fo8hQWGhsanFrzmi15OC1qb7aix877Pa0i850bnR7yU CObjRWd4XEepRkOD+7Qd4PjluXBkE2xa1zn9/UexeQFuz7LB1+dnLL33zQyZt6ek9cBqAJC6aPWO Xv706/5MjKnWnH83w0Xt5S8G8PZdrZQeOkgnlq6WdBkbeA4Grj0+0j/DWRMTsk1pTAAHGGnDxJFG Rw8f1pOuE/jGllKNKQCqUKkTHHT7lTQlEIc0upCDa7kBYAg0IdYPiLz72NyTBbS70oaPRnhWkuh6 yu7VkD78dNqQ7ee2sPzGAAVcgGPheNAEtYKG2bspY4FhwU1HGjdl6gKOhi9ylbSSNKkRrxqmTwWQ vkJG+/4Q4HLRsQBvftDYf++5Q4vJkxQZ+GnM3th07mXuTAT0NaGMuCHoMPGwWTGCXd8B/y+HQZX8 VoEFEY+lR+SRe8rDeY1QAdakJQ9E/cYVQ5Yjt5W9+UOnAsPizAGBWiliWYTDTE1HubirLn4g76DH vyV9gS3AJUeY4g4DAaKGnXkCoEVDVQNMxfqmBtEpCIY+J5Xa1bimh7rY704wihd0hgWm12/lBhhe I/mnIy/dp9ONroxlZOm8vISxvSphTI62PC6D6aC9wwMOi0zC9Z+Luk5QSDV2KB73GjrxA58KUKcf ku2oTwZu+rFfxlcRFiOC+FsMURKqAWyWqYCqM6aP8FeQ+EVJgsc5akItIYaGhoexOK+WxawHrZ56 zWF3PShMhcBthnGj6NRDOeDsa3VXoyfKPqWkKBm3JL8hl8CZc+xuByf2/ksUU4ZBxeM3tvzk6VsS RWnhl6XyB+FXgO6HYRCBrFt50LdGlIjFtfVhoAZFSyiA8P61/yoqXG+Do/gaHKDjL83sh5QhpKxG h9ec4YcfaHR13WgApTJsGTAvSx24mTAhFrvQtzWggE1qk8kFh0kw1/n5DFUdWjL3tkAQ4r/MK2GH aQ7e4n89vEaqCjM+tT4q1WqIf3K6J1GBSz3UgbJCm0LtrTmMuTWqY6D13NDEEAGrVsatMw+HdzsI e8SsbIkBu4tBss8KJ/jVOekNNfb7Lbnbasw7w428ZjIefiGbFEI1p8ZjxM8gEM4Ogz0absKFJYXT p/2S6tkBnGnE1NDG2u4CxUHyRXMUm/wb0BWGunSiR4Volnl6yKG6pbw1/yfQcGcFImzkhlCC+oGY vg2DhYWi7uhNuTm5ui4ms2jBNezjaU1cv+ejYCNM36Rmm96UOnl7KGU26aOsGqn9ka+qMFHA4BhT lqhTls8kDHCApya9O+yQFuc2oJ/MeLKGAOcVGqpc5HyRqobRu+CWvwJVRSHjVS+CIl3XaGsrbCcX P3OChNqqUGsnkJZxL8HR3rSMxUFxZzwA+jMQKT8qJzM/4Nf2ozNpHnUgM3LjA4NMnHapi6AvTFpB JzugJ/hHyhUfR2L4a/qL4GlQDSn2a5DVtDRbAGCe1CaBvgJcF3w+4EbN7AhA5y+jNGMVe/yE/Fgv qufcJIpIxWDIP0QnkG6Qg7DC4bO3Z5YFOQ20AY85l7D8eKz6aYSfXwHefT0MK4w8Do8AdmsQ9GP6 ix+HjW3Ffjxgb5xacxgANAKPTlBxOrpQw1egT2F4EgKPVRbcp0/mhHRJODIlKbnEXj7GcEyBYy3o nEBbKeU2Q3islxPy8Gk05fRqNqm+mNQFrlRQ1k7EkGpNmsYCqFsleXVs/YUJR3aGvXO/3U30cfRD 0JrP/xcI/rxGPkQG/0Yc6Zx2dn0t1mzSltyJvFTHuM1NqzpGy7Cs3NCrhTqpltfGFroxGKY14PwQ U/e+MFEhEHZn1Pt5UHVap+Bfvh+ELjXExz6H5aeFfOZXryT4AvjUVUbHw6dWJtqHMZ+5gDVjekcF 2Kq1C2uQ3I4oDyM0zslg8qhsgfffubnzl2phgI80BStDwH/cUQHbSyvgfilBPLkEwhwPSmz8qvg0 XZzlHzq4acYaa3cYxtnBXplvsnfo6obMfUXMAcaFlqw0FN6Z5G9TQlThFqyKiKLh+xf+Ja2FSvQx O+d8eAOQOu0i5UeT+sAU/D1XBetXawDAeM0E6QjygFv/BGa3W5bMcoH7eSvECYDv1VqjqL0HsYI6 wPdTMtcUQDBAucE6Ga13/ys2dLfF1NSjSX8FGYcJwMp/U9EXRhRFnT8ZbTZqGuqbR9ZAF5QLCRdA LEBx9j/TMYamRmdrGYr/Hi0rHinwaZlZ0UTA7hwBiuIfzjgQMO9WRrSMyx6OC3odoJv2LeExyY98 uRVFNmJy3zbQRdiFJ9dqBZCFp4zHgnSts7KxN5V8e2fWK4GfXc6FXNAWaa/VfKtRjMeQfEkU2glb brb8Tm/cfaN9oZoKq7P07YxxunrZg3WRfbnQPIWjl+BWhhSryAjwkDm6Ffl60JBbIWpdnEDU/U5F RW/0OD6LOnZFwHGHT4gcDhCpCzo5p/eFYzLPHxBrkHu/So5yvtGN4KsXPzldwNn2OvpMKNBSu0GR 2Bw1a6erDcxn/tops+1D7kActdFrkdfW9cXkMxzbKKtaAODmhy+c+EZfq3j8p7/CvsCwqJK33NzT O1kI+w39Vhr+datIWpgcWZhaaFZORtkCc1SPDCMD55fFQ1yyOFGF5LaG4wU7EscszD5ifxA72mTB xcO4tnm6+GSzm1zHCRxA6L+4g/ve1VyFNBNoZxc8QYEI9RGOsmqFRci+ewMDosAimkNGO71xG3Gg kLLAvD1O7XIjjbCGRxO4g9UkCKPnNwnzInMtvzZGCD1aAnQE8xemDweWDEJ7aTkZ4YQVBdFl6cco bT2kG9LnAIynUYVD1ZNHQ1YdBidabC1mPIZZk2gAf4QBD/iTB8PD3QWsZHxQ2iGFqsGMuMOHJ7Dc bwxA2188d645AE62HO4NwNq4BhmUUy+Bu7jA2t9DDLk75jtcK9Nrwyyql3w/8n3dxssO7gRe4Wv6 w71+6UEAPmQWyKpN1Wbhcgc2wjfPvjnOPuBp1i/vzq5/jJapuxO5EudTewlFbI4T//JSq8BQdbE1 fnZLRvnoA0dQHfbhp7MM+EhFg1kGGjHZxZ2DorY2xEOJeQIOHEE00tqIrLKpQ68vvXr5XNp5ShRs kb5jmIFgyZRhIo/t5VYhLA9doY7NP1sQAsBbiVSAMheaxSuDakUTiXizzK3rhDa/F2a1BnMsW3qB OtAU+dDQ1utRMaA/wAIWef0lF6eaF1frgRqHihaQneA6av6QaLvGyurWep0N8Rp8XD+5NGt6hzJq XZYs4HsPe8NrmX81RtiVBUH/IbRzdIC6NjT5Sq3ktPxXiXAG6TMAYAKj6j5sKz8wPUoh5j75uz2h BTmNKC+UChxWhboJTExRPwGUzHn3QAcIJo++KunVM198KFkkJ7ioz/T4sVxYMcW0BrPnNj82xnYs GRIGICC8e3VGMAzA2+uf8KxocBldx/7sgzLPgU1B7Z2/K9hR1n3yrq14ioHFKO+06JMTnIK1kzre fHSSNTZ7E1js0EA62egrFZhcmoRkEaPoBlYbbEiuR3yKa3csF5Cs2ro/DKYBoI/BzVY3gka5q/D9 lEY0iY2IfqsGOfjWeoACbfnE1jpW/A49gPVv6uC4u67vjXFrfQAdBcGsPBUlkPXIy/sBdT9z6Hwc JBvBRioD4tlG9h4a2yci0N7zrO+h1Tzl1JxRV7QvUXQt9PE+Yr5x3XxIBt0oDrwHWZKPW8bHYA/Q 6NLKdPswY5gVdBoNCh+CGYniFETs3WpO/MBsWE+MR+sF9FfPFAyA1aWAfYa1PPt4cU08zof+t1W2 /XSOe07rzt/FA71EgY5hxnpwh2p5Ha+w0ediK7Vpuyn6php9Q+yN5zX7+kd3A+3Wh5D2eOkmM5CZ ZLrhKwDEs4JAEvmWGYMZaIrI6ydGajhWMsyazHcRvydckJNPm21x7mdVhc/d+rQBIAIa5TyyJU+R OHm/iWwwK5ylBa7dR4YeYjafvyIu3xbnugWrvRSbTabutHDUZkasVecvPMxY4Bu0wCdKEWO2dMdM fM1OBEgSUiqEuST+dnoLs2gNC8wafqxLiRtpQIWUg+/jBwWe54a/aEbszBlHZsAnTlZF86T82fEc nLy70QV2R/vWjNGoslXURpyWbPEaWyR9dNEcdURmKpfQkag0OFZFAZ2FZckiV8YPiDYWoIREO6CP DFGw+znUgP7kRb0cBD1x3UrBN86eLCZkoZ5s9IVK8EzWXBh9Qf7sHebrZ2CdbJtBq112f8BImzbV bnVdhH6zK1MXoz3ZQDu2X0iQGk2KvGu1+zTtTsmOLbOjhoMgste6/wc+8IhoESIPau3XXMg0B5Lw QhIQPmXkAMEfn0bbisFRuXp3933UqWyeicJg+rEzUy8qKwxnBYd+R8cmP+kkLriAxiUk6akriGhA zarBxb4Aqe8rbCdi6Z2P0xLHGIMUa92Z78AoA/IWEzRXcJELx4M6utD2BJKLo5hz0hmMOSkn1FMq GQCSdSypYecDy21+np7lESyGHJhrPxnOk8tQrvo0aENAVYvzkMN1+kCwHEz16m4GKcTxkzszWQ2g TR2fBmIch8qAc3f+nYZVGMs/KS7U85sSvpkr+ctdIDq3BZIqzkcWZ4DbzKp/AnmWdXy9iOWSEEFd aBxBVqCMOD3B/05CB1teAFkWzd/PA+DBecNAa3QVGUfFe4hcif1w4ES/6249trCXp5jFA+nY/T/u WBXitNhEaxcYRlH6AalsqZffjAWhB6/dBvOeALM9MHyWoUiuO8+C0eYex7V8o/3xDpwDgQX0kQR6 uMVKdWaQ0tFfL6q9uQojx82Eda3MXpd3Yr8mf3solWMN37VT8qVr+s7mfKDiGOyFyjWHq2niCZCL gtNSXsl/rynmeZJOmGl2EPmetVsYUdRfKSrJX/Pa237AIRnEYbcpAA2E8eJicDS3dvHnXDeZdLAa 2bG29nbb2yTj7SfnZ8OsbrXzfuM7IPZXPnr1HvMcwbpFa3pG5ax9eruQZFPjcgbAVV9QSim/lVfa 2AtKTHqCNrY2b6/pL5W7aLvvaKCQjGR9yzYCYHxYJvq12E7nm6XyucYzLSDv99XTxnfGtXbdmoeg 5BVqjubYRvpl6pB5wHobTbcUanMGhNs44jk9QKjWOXHts78VzYOHpGcHHhe851W8jLmh2AWwQfBv KFo2jVM9IWZr02Q05gHpg9b+tYox//CRdtvGZ61fdYDNV8H574oconHPKiuk+eV7Ve+SuQdH0H1W krjsFqCY4KnHVTQd7eV4BnktxGoFDRY5KgIwhnCqbTUP5x5mrh8cqciF2XYRRWo08IBSv98xXMM1 qvqYQixV+AUsaRS+rQR+xca1+93HddCaz6YqPoCGRs/gHsrIZ0UnnwNZhETGqTasuWVthhFQN38/ Z7sYLF2+Bg4q/iqYKisIiCTmDLzfUeG2JekHYOPMHKw+3YZHTJTmAL6qRHiCAAqo//sEtZULun5c jN9JlYTBDygsu1I5xijBqJ3txxYQDd0tEI1mvsdvoB8ADcpAdXkmAwaddZ4F3oaFg5NNlVVfhWoH oomJ+4ZGh8lKP8KGB4aNpVLi6aUwPaolsMFV1q62Df+VaVIQXxhtcGUzJdv+Q1+WFAPzjoLN/qmY Q/p3FdwC2mJFadAjvWzG1sazixBBtof/VsXYqP56KVcEFYLBM61wXcZezlemmUa7FikCNAAPYr80 7P37/w92u3c79gY1E4xt5d2FNTnIVceSAE5T8rrO5iKJO0MDdF02k95BIgoG9la4wzrmshuf/AyM AZEzzsaf8UXDw/S5rkJPOUfa+lCV253fOf2mZWbo0drlBXQfwStisgAsE7qbBvrbxQ+HRTJ7Bqxq o7dFv++lLYXrFrWkUxrlgC6V4cvFHkb+GBYSiSpD1XWm+tnD0T5CuNisaCiTXngcbTphSX6hxGkK SnWkJ/tczluLPmwn8AZwRjR5O9UA5VKhGgfXsf//vSxdkTf/HNFH/VlZf+tjwFyEAsHSj9iOXJsc zDxt4L1lW9Pok6m655JQ/iAMh0ka8AWLgKB/K47G4tTXGk5UnpWGhVc5Plt/vsEL2Hv6wkMlJYCQ y+inRaT5eU7RKi9HbbrzasUMEZfgxMXk/v7ZP6LICJXaxjoHnqI8FTQcFAABeU2/vYLWwcjLR1eu ByHqroBRP/WMMyk2moBa/zAdAdZ55VYnFSI3CIZovu125o1FD/hhVb7oCHYSND2G4Y1dokx2Dnnb +XpBUb6tHNFf0F3xxs5GzSCXudTGnG6lr3YUuZ9WvF0chuVTygolV1B3EHbc4+t5evgHdjQ6kZAz H9Xz5ZPdtjnTFMRtzUWst3Gl9dAoA1E96YzGsdNFi5jRkVBF35CfuTbDlQZeMEV4hrKqUYlXj3Rp 1VI9VutaZHwnNGfagz/HAfSGzMEnet49BgaGxzvP5EvshQDvxX36lNcG/VLJywZrBjzf9G21MCyK VLxWcHTlt0l5vYoRBFkGxirNaTK0xnt/DoKg78ZJ4HbkMsWl6ILlbTvg+s3JFvE6eu9Mq2samZ4p UiuGCESFlBWfRrRwNc5mlwNTmry5sVmN5yohJkNZZzyPY9CAAfjqw5I8bv4muYwqnmCOzCZ4z5BH VtT+EGZcZQZZNF3NpRBoqVIF6JGiDBU0E3yokqn/KHegx8GZBH0sPc16vWrIOt/H+pqpKgbUAMpQ A8a5+5aapeB9p1EHLEPEfY5fyyjQVc5g6xt9fLaXF+t78scO3WlB/8eOfcLuFR3HITqsxb1HdgZF MqLksiRjG4F5HmUt1BwEkcb1AEI9eww94gwep777LN1mheg/VNTL3beU2Z4O0OLdVp6XaexrYW+I Y70tBJ9Q7CaKkIbBS8kgP2uz8/I0XUzqcidX49Dmv1lrYLw2VvMWZ3rgFsILVjxGmsRN0VKoO268 HfS5eM5gtC8MOfB0+tl8eXpFzGVMGMfipTtHsniUjalBC+Yx51Y96OyoxVGov2EqV7GB2645ppnR OfqlTP1ebgAe0gYeRqYg9SuphhRRh7AObaZz5zWHkOW8ryaGoj6Ds+SVD5CX0LIQwMmGVh1hxdEA YGPAxSfVG8trg7IQDmaRmrqahflFlpuL/6JTVWXRO4S0+5ThfjV5TFwQo6GKXGAG5lcbr8WX6rsN Ibwno485oNb7UDoEEd4RaQbHMRDzRjq3S2bXL5LKK39kZev7hqVFB44dkf35Nr3lELJNkKewr5Sg gIyssYMpk6YjaXTV6rCDRjj0YYGqzi5+KLZ5SrpGeMp1PhyKrLW9f2r2xj4ovHz+7T2R4aDQmxB3 hcLtSTmdBsB2/YVlUIhG54z+j+dQFz00lM7viuImubcQWGHA1jMn4jktl0FgK2iGivrEthvcowFe mpG23l4LEMkKRkWWcelW4jSWhPecLLhWweA6PMYj5RxRqFr9ubNSlqy41RPTBSArkYBnXAVRDslp xssAeD0XCpgH9AT8goUuDBmp/rMmdTNQF7IOihbEmcZu8r0+NoW+PbgB25YZaKtPtPkHUCWpAEVI LwWprEKVDWvDWNuiAebyTjV/7HxqjnMp5UXaBKfwZtlpFHqxnpGUIjCK2ufTdV08IVDiTCLVRo63 vNzi4KtAeJzufJeIvJIwvTJj771ZGUw/WYdaSjAD8AXb3BzIL+f+t8I3+ODhS8Bwo9nLiq7VvwrJ hP008xggXC6D8lP4EWLc5wf4nLJAlO/IQDNHUWvnk7h8QMfckzjrI/iZ/Hh7uUaMzHZQQmm3KadZ O0XlVjWGghuYMD4ufufGw++5/saSli3HB/mDNDFtkeR+Ltocic2WwKrYxRVA6bH8FHhFtwj9H708 ktBp4g1b7FE8VkRC1Xr5aoXJmK86+sAsEsUUSvj70NJYE1dQNpC6ejC9B3rrIrsQN32ZTMHLGudc EAcZ2/T3HAAwhYy32KEH/FuVgZWqEM/hYsXpjHQVEGnptony3dDAYGlVxQDROyGe9gSh+c6a6g3Q sNFq9jpsUe15RrDQut9HpmrGbXk5oE/JEDP6vYmOMNkoehaQfA0ZqDSXsRDWotz5XvnWjGaDVViy DkR8MgckMnWc68UNdXn5Qmi70gmwNUM87IuchxzDaZq8iBCFgvjORYh4hpeJLx38esV0bYLUcAPm NKO6TeI+ReqqkPJFwSqFrUUlDFx4AxFpeuH1imcGAD/K6eclL2ckfTjFYCj+ARllGFLHZoQ667CQ OVK00NZ4Gkxx51E9bPslfDAPtvtQhvH8SpX4xJdsMZM6uM4VEwXcarARfM3hHHVcw++SRxekjU8q f9KJQs5loK7Dmw+z0c8DPf9DdrSo5s4twwcRczRf3d3A+9IikIIzxvSPPF1GyoC8fCMG88xsEvtp 7/vKs7/uXZbcw/uHUXv60uW+83i8R1LHxYdqKH/izYGAG8XCzZpQKOymSQl4x1FrzYXr3U6rh5EJ ywhivFN343HN9ol4tUMK2pubWIClp+rDHDyHpqDxtXry8A0d8PhlnYhyAcfe19Gn0cslG97O5Eb4 MKoyBWq+hElKM7Q7nWy1J118twfUtTk3odIR/dgqhv1p7VpoV++XYCnqZmmAAdWMSKFmFJERU4m0 aHnlv9fNpANRgNWYniLt2AkSs1NrgHoba0fB/owxV6fo8aoK74xxQOcQy+t8/zxWAuftFiR5J39F etl3VVkG0L/5TEhi7DYRQNwTvDTCqyO+zx5bxqD+WYdWPGK+OPxByLwnvkCtRn1puHIl83LSq7f+ MnUpoQadAKjA2RWoZodG1tRkhTYDcr2ulel+3YYApuz8E8J8PCctCLoGZcvTqAtYWkkhY0nZGW+d 7C50USbMP34oNBuk64aoHD++BagI+uxw6vC+5q+TgbKXdcy1/Wel8602bdcBkNfbAcOS+fwbfqQg wI5RwADh62ttzSst9E3oquIB0CDH52pGZms4T5Lxf3uHPkcQZSVEhn5FggWdynki4QBjPauZcygF Bbg+Mqq5CCHslwrmgXJ6keugkHQYoEVS9BdN9NDV+04gC7vxsYGseaed5bWJQopguxyBYgfAzSv+ S/vXrG44f5gAK+qa9d447bzFvhU/fI64raH4hRPDbE7fZ4DpCgx5xMMBBWiJ0JslPSl2U27oAzLd Evv7IWdIDz/8uM0xvyApHcOc7Zc6iQMlD/0t6KvHNawRKbGF8eFYQvNDxkac/NEF1u+Kuo9+4IXj EUGnu0VwRQhnfgVcM5a0hQUSxVqoN7CFyQbFjwfG9JLGtzw7YH3svljlMy+lsULib0tFKwnJ4G+o vgOzGXSeoCmnK2eFSsddaxbZe0CE7zv5HjQvjJQ+cHG431FgRWYDZb78A+mlL8oWF9dcls871inI v7lV/+D5QrQboA8nzeFOnYzNIMVSkiA+rU/I3wVHY9cGZQZGoP5tZUYLfBEp1YPPAlWYoAcLRyTe GuwheN6B3cYSePfTnik2NMfb1kEl5Bncp9O6tlmkXAHUkNI6+gFwueyppwwGQLXptqIGVZdsMEV9 6DujHdi8UQdaBTXHhq0RNRFxqZZgkZbGQ/A+TmgzmRGGnLGBvDIsvBuHs8SvE9XhgP6+EGu5adAG 4qHYaxRMaD+JxwIdfQQiHG4ZFgiAQ8+AfE1FxtGNZ9tShc3mq4XGhUdmh/jyEtnrUW3nNXsk0Pbe pY/vWr0xvKEaerijE678JGrOj8Btf5g69t9kzEb7RsBGG0bl2aahwKBeQLbC036FJsGEI3nDTGoO B6QrnZmU4ytsJ5MNGvmM61F5g3IQFvSOA21oFjMQe8bcAM9j0Ji5xov5B+ulQFaghpB01v4qW2Nx wy4SN8XTfCDPBh9RMvzhq0NnNWQr9zscIG79BzVo5j1to1pjIGtr0sfpxzs8RtEH1eKkH0bhx6A8 6qDph7qGhxkAfyd3SdQdjreaFaDG/ywBqXqjHf8HLhv8ZjaxdazWJmuCMh1fu+Z0KsKLmIaGwIW6 gYbpwoeGamlw5TK/ao87xYT5QGZuZHlNRDsBtlaO54dYQtAhKR+TRtBzpfJqS3kSVHnJ2/6Qh1Bs q7uFV6n3wl+dRY6qe9nps5lHIpPF6AW6OZE2RJhtkEZvWcTEZ96VAdk+qHOdX4xFbQYhOw4JqfVg KoLbJpUWVfMqDBHSM8c2reUq9NdNNXqRUKKoJsaBBVcM+uJrfjWE2dLF20YTlX45ma4pm0TbZB94 7q7kzwck98uqfBJlIv+z04aRzpxF1ZHrm4XUO4AHtAHtk33pWz0TNiqYxR6vW2Ab8GJwkHW+A/Xa Fvv/CrBDqhF/Aw0psztnecD6+rrW5Ve5yNL0OpBi9Nlje0bGZ3kBt6YGF0zlKtd58oBvnLGSqrT0 FZq+V+6mhIureVX5PSvV1vBVbcAAW2wChmhR/TO3OI/lMidwnMC/0UCYjHIgj/aFD/xr5/WSNH7Y e69d2KpzRT1ls8VaqqSgrrDnz6qhlzS2y5m2P0gydDtzVmO/yH2tUlEVEGoat9aiTxKWUJSgtlkS UyYIuMwkVdMRE77GhOdp2KkmsOo9kKdiRIjl38ANoIcEueaFxJsxAmvgB5wI3BrT5P/p9IYI6ojg kil5RS2dafT0WARTBggepk71XyrcdIN2EQB/z74zTp8PT2E0T8+ORgjXtIM2+0Ix0vmGzxKQiJFD sbHJlQiRQ4PR0oISUXhYBv1gk9F+HLP/WvZOJWZzBtjSwdhAanbYmEsOdm0gn2y/LvnB5F+XC3Y2 GvOF5is/BY+PNva2No+PiIiJoG42SJHmEdIV8VrUk8oBrGUb2JjnUJqSIHQlQ8gnO7Yb5r3nHaeO 1YvvgckZuQvYQRG92Et+Xj0+8JSmHR7SN8pLdNiFK1+BXhOhwzcG26YYoechiziyvU7NBY3Ryddj ueyLRRCDvUQVz+duqyKnL587W6X8OntjJQ00a2erRJxzXMCmejF2S6S5PNznBXh6fgPQFOy9Hdy9 FcM3kWjnE0hmhammS4UrDA72q7cwhcfFzrR4Zq7KFzS29Dj/PNJso2IM6BP+7vnMkbTbu7li4/JF Bs9AUyqHdmu1Nar5cSDWvLo/y5LFDQcx0swGFpalSOlZPKvIlXj3I6byR0TiZVK0BXnDxwUqUQaV KcQrsYWFK4Cl9yQFkqryTAjIaz1iJ2cORefctHvG8uU7s8mefG5Y0zyG+orqHjtGMJ5vv1fmjAv6 xtQsdSF48RYbSzpOR6M6Crmkq95+2LtLp5s9w3RjT97yYB5kbTkv38dBzpU05wSyrKRBjg0PQrzQ z9/ofQrvoqabVb3McVnpIDv9LZF+Q0wlSEJbNJ9YEVUmytBVUmowSBuXv8vDcTZJ4XnCPLzigabr 2tx0/EOFrP0kYKjiaUAO33Taxt3rh6MG5IHZppnhqTCot0kG5TP3xwIqSLSBlmw2M7ke9acPhf+M AKbMK9oBd2VQpEaB5z8TsgdO6UWnUXlAzTlXrHZjh0bnmyrVvODQPHtqOENghKXr1GzCkQEyhtFp qhZWGH4kqQ3tFVfD9sZEeFp0vpFbIstKyjJ1Ny4O7wJBtKcHjQVaE7vY3BDasWUUZWytzMBXvKr0 SwYIoD7GPEd6hUQc8Rt1uI7Np5JRgUt09Haq6f9SvtCqUH9UrmN0+Cl5nKCfqfiK6bA4i5LLrhg2 wJWfGc1PtGotCEwdoBqef+ZKQ+nA3apM8rS74B6SwDiGGnwn/o3GEigYNKcv8iFG0mFMVcxDXgsK Q7pRmyRGozJb27ae/PK8vIu8GaV32HeUr8FIz9WMcCVBdZfQmmd6uzCFn3nZ6y9UIg1qpnmQXkSu 5Uf+X1OtRSCEY3GNQ9Xd5AkAjbbQFZq0RaXdeKIkJOTFT8BvGhFT2pKIWo0Ej0bDNKsHWpuDyy02 GquW2sQG3VxwU24fB98EI3SdzXahGzXFBsWo+H6lRAWY78yzsOqGHGnxM1v0B5fVcgkb2OdUmPRp SFmbPdIUxlG7V13hEVpPY6sE7ntjaRUC0RhJR83TF8YIgmrL476Xu8cW3M6cIUAl/Oj5gKXnhneT D6yO2wwmdtX4Dn2yT/jcmm54xv37isl+2T6TtkmcGfLdgv/r+ExBR9wbDItdnUDTxlLNPEgKgdLI MHcW/0pAYTpe1r5fY9t43CUAIJ4s9W0E5FZ6vfu4IA7JRzkHYiqm6e+elsLZgRCEf2VyB28o+hLx f+LCUzIWv2eAJjuyAJYjYJQmsZP6JsygDwKWYDx13SAKFBQnQKfqp6xDd3HSXU93rH3nEQV1Q3Cq la9a/vb2xemvmwZlV0Pmps1kCVXyFYPxyIqZkfuLVTi3GIN0ZwuR8JpWh8d4otwp8YGyYHU5ETuV 7Mz47fzlmAZDXy1v2v4vv3hvDZo952vtpzY3/910MfUlAH2WCxg6vTSwr75AbZSMvLDw78BJm8tA Bj2f1PlWuofRlmqudZHP1829pg0rqxY06dIr6+t0lvf96ys9ZrvRGXSrUjbQEWu16n7w5QcrCIfr KpL9vf3/kpZSkFiDd+3J9z/rJTevA6lQCR+wKvDoD9AlwMQMXqkrL6D5fhbVZyO4/OHGJzPwvVD1 h84OKIWsQNDFS34INWn+/wBK/HCzr4/IO+pRVtpNJsXHMBeSJuqsFoXzQzi1VH2MmdKaZeVEvuv6 20D9dFAOs+r8GOjsH3vyJxfBNEBFnHI4E9eFHaOP0lNdFjqmDtGGx6T3qkVPBnQMkWNc0/yDhjnS xuDHalUaKrCRZJ4vPZGiWy1rgY5xPgR3IUWAiP1WB4roIfMGUtulCC4TuDvMdnNRCAUFqeDI8lJP 5VOzkUCCBRO7OoPJ+bt+7AZGp7qVEBfrpy/JVgJn5wYBvQRMAMVFwZY/Bvl1YMQW/9vKvsX8a0bX 1lk40oK9JsxGZEJatS4G51AwQrbMbjbVhScktzNwlpUFnh1HlmGNsvXiPC6y7MORvsW6oNPGmhdH AfAH56xiWkKQOOR7ypcXuaqV6ugpDGv4fsoyrOPx/XbGbaNT+fTfedBvk26g4d8ex7aGQONe2Bb6 IbZInZyAqfdGLU7evQOe5hDg9c+8AxlAagBjpgKFXYCMpTWp/S898R4xr99xun9c2J/O90Q6/3XS 44jSz7aVR4OM0YdCxbhVLIcFTIrG5CCk1Ezw6CNNRY6e2ZaSwCh4Xqt2JZXwIVOs5LS6wPiWsHD/ jjBnWYDNgcNpO2lhQr8wDuwbziB3DCYHKaaDiMXxN784P0bz7HpH0p0K9qoF9uR/p4hLWNE4Rvb9 0fZCflCn9wQwi8sYqjafVhnMuudJIuQaLu6od5zqqLbn6uAwA7Q6fAdFLocUBA1YvWaCzQBifP0K xWy90Ybbol9ZXFRTpi7GlcmAUTR/vekpuzWHukGRQNTmMvY04SA1zeEmh8iKhtu6xqkZfr+p14ZF pIz9BYzMdVGoOlYGqlMAtjOykg+GtI3ymqJpWMXBFtAgiTxd9AKG7ZA8aDlFhwLFOEKDHjWz/PUt kqp/ixYnNPDBdUaoeYK1powGN6G7k/1tAZwmSXoo66v7MEYypbsVZEAUg1yp6Hm7ddzoe7m/x7mh 0XwvqOGFQ9oApdQ3PpuOx9NCxuYU12HlPMlhlYeM3mgrCcB+Un86FKZtxuAkFdsshfaw+AWSEoiq 4ceCnqmmkoXOZw0QfUN8Z2lAHD/0KnwmgTW49ovEoiI5XAVLp4CEOvTaFzuSdtV6QMB9PlK9sDw8 rOXPYIt1hYEqCFcsbBp7gBAmFea12VP2ZOmFS7rtdq/Le3F7hfqT6jpft0pFfaSgPAAAFWZyVeyd v8ai5pACgHtWuiAwvFJYrMgmAWnRg+MGHHE+q8dVB7ARpNOQThUdOM3nEDtBP9GGL8u1l+MFBwO4 1z8Lqd2c0OsgMrk/WoM9baLPFJhO6zm2Rmm7AtaGF9ui4K9pgkcietXMjCU7MRaQ638klXX+JlEG s1v6/nTKdJWnG3265ZGPPtPDlyVHHMKaASQeE911dH17x55P1COjlFmYenjZPLTafEHzwxC329uH 21aKxkIZYjU227riaKcqRUZFBwARqcwr1qmzg5PuujuhnRyF3FufY/mQjNqhTNiyT28T/NTUD0Ri hQ1h2o+j3aalmBrKmUYIiCoSReTjaFM07FISxrsnCPgzyXX5lV3hI4+ecu0FvwPsZFi8sSEEfqfE hWwKSOVZRnu6BnrARm/fStsqg7hMxdmGYhcSxACV6bfF8oa6+n80rZCxKhWIDsWPvFPsagV2NnhA HBBm/LJ1f4Ws/r+aZzwGEtbUxgwgJJsXC1xfJrt/KpeeLjg5aQCYgKpVAlD1MNAOOHy0Ix/Ggf3L 5tP0kj0CCYB5wEdV6Cc+QMpMmDjt88LWAeZkJDMAjcBlzVVxqmvHelqDesyPxh3/vMcWGnAp/4vM PRA5Hy3mREdH5gzBSUBD3IMH6jTCfGKBPtJB/MbNHlRwxm5GokEptrD54pE/PZ1ZgiKH/aedUYOm 3yZA50wBfRPcIJu35qyY74umq7q7qz4mRhIMapDVQTVHG0CclE+1Wq+VwOZAQa3XJtgqMMVqw0L+ tRaUutfld/uVANWJW9bWfK1bpJNS5bRNbhtX1oEl2DEApweyB8NFss5xKtBH9EtrpQQIR8wfcspk yYsX+JFHcwCpOV6D4NBpa6oHLevgark9/43MQIxAAAt8LjWkpTxxfZQictXyZnvDCqcuwIUvQJYH w+0+KH4jxRE2SSpCE8WOEkT00tS5eyfaYSWxJbjwgMZMKzUiAnaVaiOInkrQNcUndQkeZgb+Ti9s ELO0jLLSxUFEOg6GDlh5uMrF1FYsSTzFDq1mBZQ0DKtGMud1kj+Lg3tpgwUKa+UuRtFBChdJ1SEV 1I9EXgB0AOCwxrYHJskvBcxXgL5zw0InajuHdwWXkjab9wXqRpyHL6PJC4IF6fBqghP+JQol4BpY LCYYBuIUuyZ78YPZhRARQrQ2cIWf071BUNnBc0OGv8N/DBXbiJnBlU6GQs4GFn2kju36QlfWfLWX l1zVGjIHTkJHvd8nZ+J/2pKPAJxURkYEal1Ehb2atd2Tuf0nPQG2I0VqgVRnF9A9n32Ck/wFyz8h 87qRtgWBgi+G0b9tAgl8Jp+KgfdU5boX+DpRLpXIvdR3x7iStFbLWW5zhrWe50W1059J3UfwxvbC f/YeP5IwBYjXNEghxTP9wXr6Bep9XI6xJUvsOPnLx2WCrTAu0znHe6QcD5W3KJyd6SdrXEzsbgWn /AZweSFjMaerxTQBJ9aeIsDMvrha8RCrYCOGEhPf0KmdfuSRFtuAxLiiBfsH65n5mZogFYwtjobv KpHBkv5FXiqpR9vtC4dXydgF6uEziZhGzHKmQGzESQ4qHdDvC2b+/J+YC98hiRfJNZl8Ge4v0uGE RJlG1JcLGgbmMjQJx8XSvkoJYj4PHSHietrZBj8Ly60Cp6//SpL3Rhv3O32gEKakef/9fNW1Mv1+ Qfs4GLS9/YzHQajQcQzVvkzcud/9VB68O4W761QgfcCq8ThQIU3zHJ1/EulC3avVEQSyLPQ1SdwG euHfZzokvzpaAtirhHgvrzymbDxTk4grzzcGBRwVQLIrD1GXS3xq/OswUNCFKzrA1hB5s+SGSF4l JQgphs3q1kWVqmydeiiXpbbzdoAeD/M4cAaFe9X7/cYVhXxvgRz+np9Hwj0ne7aiUSRVQ4us4qPB hr05NE8swDmYqMlY5ZmHJAJkytml8X9Wo7xkOpbGWA9z5A9A/egHRKO5B+q97QZ8Xtkyza0QRvKW HK+fE0YuSHCj6XzQ+t8OPrhqANA1WCaJvofJ0P7mHhUFC2rS2GvRJjvFCCy4RfQEQi7ndeMFdNrK kcQI4DzPQL5n/D0m09CUj0MA3HU4ScehjoEzMPaLuLGGWQwYuirz2BhKd+XgEKp+yvT2PYnXmIec jb5/5LuB0mAqDYmJSMDRjKV+KpG2pYMNx7zmWnqixsJbx+w5S60YSXvCAVRmJa468IHBf34ie6Z9 cAcl94W5zEZN/W5trhZrdaMxOmDQNVYj2jJs7UZmpmqEp3guu/FH8hcHCV9o2P7wV0QyoIf3hur2 uGpzQFL/TvnzaydchT2D4ad8DyxXgSDWxCRH8vLE+Gav9ZMqzjfqIovSEGvB2fFFKWft8zwLZgUN oNaeQD3GDusrmSo6j3Yla3bc3ODfWLCYpYFmq2xM98Sl6Q7cEsQY2O7OO71fLbyPyhMszP78P8ZL u9hWKyqqll5egsqJoH+CHt5JoL8qXp5ek5L0yl6iSIxnfPHp5OsnvOLYhYV6fq0ffD3CI5AavPRi wZWCfKzvdF8FFteFooS6ba2BtByT48wGQGLWljxTNoYbReT8AFLggx7F3tG2RbYe34E2g+m5n8be RbwNCRXexasrtD6Nnt8FmL03d1q17Yv93qNS44a5+p+ryZM/4gHio7/Cv0Mhun1+B+W96rZehcYp m6mYCgrh2Zt8leDt3h9BiftxUhjYmCOH/cUhXh7K+zRhmJ4e+v36tF4cNCzXkJFgfyvXEl4HtCDJ x5Z7jW0LoNbWVlZCFgZil9VWnC1tvpbehcqljV+2Cv2A9NJfLkA6gCPBJAkT/Wy/Ed48fsmULd7b veqly+IFVqCXJevW331F9DoWG4V3NzWWTUYrOnUDN3nCbLxG0YEz+qEbU71CwlHMCbmqPiwaDU8u TziDH/4TwkNH6qAEQMH2amRmwgAlrEfbhgLbLgFa4T2f/VXuv990AQUqbOtItArruyUQ6m0FiSvW 4/JYm2YYkbp7m0lfjT5WVthraZvQW4nd7Z/0uWqAGx+4xSRoZ/B24BbJPwxG5xx9NYgZltHztuQ8 wpiURWHU3tipqMMi5q5po7SpQgECHKoq2uvt61Ck1W781YVHeQD8F1RJKWsV/D4hXpz6mBiQGIbz kpemq6GGip8r+Wq40mA8fIVrvMrBj3oRR9GXBQN7d0P6AVS4s2PwKR/Dnd89tOqr8vtyhhi8YDKb yeiAGztQgWyqlUKFBJTrNC7gvc29L+P0h06lrPU1vzV2nrUdj5RGsP4+ht8JhdhHM/Q47EFDVsbg PxCqPoHxqiEQOVV59JAdzcTXtHd+NMZp/EP9/hoJRymH6zw24IuNvWeCVc8jW0la0xrEeQdAYLHB FiPbAQBfMG8j74E6gcm2wdwMyjfKBLVJEnN4cmXMfA7sf+OCVH36l1aXHuh4Z/8a9tXi9Tei3hzJ ha1gBerFCH08sDspmBldiUkGwYU6RtHnR3mr92xIn8536q4GE6uj6rDTE8h6oK6Gs6BX/EpuVRH/ hkXHHhNexM5+j+rX1in+UyF/tfbOGF03UezAgNpvN0Pbk476SMEPgv0mQotBcDjsSefHKpAZZ8t7 iHop8oZtlgV4IRN14IIK4NAd6nkjh5VLRfs1ADBW8DAMm71GTPIHuM3rdbZpuMGuGlXekIYD84cw 56ZFh09hk6yXPGbCh3nzcY/p/tG/UUDFAPqBvkaodBUM/79/ex85KKT886d7BYHnNpBlKgf1lRj8 8U9htWTB4s9tQKXfw9f5TTi0sMbqzFlvdepMf22HJ7ivQUSLcFmAUqYcSqKi1pp+oP4LoNYFvcUQ eVKw5rBhT7rSON3NIeuYvJ7a001g2AJWEgMs3W2qPb2FqUGGBcG/X/wK4+gjVKVKXIak59vR0OfG 2Q4iXYA+D7irQ66TAKqmQOqWaQCriQBJnEDFaCei3JxgpW0zU6aNqNqQZpLvHORL0JR8i76qzoTU IDqGEHRT0ezOjM9db14q8c8FEGV0XTPN+PT958Tv45VFoedS7pxlsp8/RkRVI38QugXbdBaOACtH PHWSJMwN2ULGaYvA5YDzW3cWbf12fcgqkWLvClBC5RUhDkKJjbvBVSm1X7EqrwR0GhZs1cQST+dK iQiEpIUd6zrFOUIH3YxVhlAqK9PcB6cpNXSnkFVj5t6lj5yBjgenJRA+8oDNWlrQGgVwhMkAUCBq 2P40+Up1efTInBWVuC0qKrT+TFdiLer0gnpC99KtHr/MIl1ix/hhb+AT50bzrYWihSuQfoKphUxF xamsmxfqz4Vpz0bBqYr25aCl3/f2eQB5zU539nc2S4hR0tdqZrCTRcdEJVmLwf5DZqpnFe4dwzyy YK2JA4+Ry7ZK2AsmlMkv3dTIHU1e3QPOkdYfvtjWjIuuheGTC5eB9+LjV1CLCwuL+fq7RF7kctiE K2ed9eeH8BSFYUU5KepERecuvqabIMOhxsd6QWYc68hi0lE/psOhRqNGJpgGR56C+an1/D/vgTJJ p6/+Zb0sgZiW5tWaaePj/ukIrCb3fvrF7z3amaxL6XQoGzVOF+s4KkzMqxd23rR2CzXaGL11acd4 9/S7z2Q1KBeYrEeZaXZ+0Ell2Zx9L+0jhtOrMfauTDsPRuvlPxVA0yJ+mwBnWQx3sdwGAGUmfKxn b612JxsBv+ZxxHb0Eabv/qLCtGOA9OPQDMZixLV8mzbDg4JAGlZ9Y7H8WxhbBcZQ/VmQQi/AxUN9 i8cBDEYyKi7EzkMgiCKaXPxBukfcI/M8G/sH1GtRneeL6TfFqhA5kLfYHb7yS8uQNX2Qp2ud8oqt i4l5pZAXcIHBEWrRCslQeaMQ/T8p1PNhS4DVt8GS4jbFxNX44ZP8/Dl55sZxA6vHevVVa52nxoVT I1gFr6G6F0aBQDlvqh6HtRi22k/au9+6kA4eaDxyFmTpZ0d6LR+1UO/VFLV5XDIC/VOMZrc0ajR0 PR1rASVaMxBTNps/WKydXEnCqQ3YHEmeHgeFdWa6N1iVsm+Bpnf1xnZD2xKk3NEcNh8C+MCTxpyL UMYHcq0QRQdVxt3kmvpkib8NFT18EDfU/vAlUiYoOE1h/YdH5S0UwiJTDV4MAfcyf/P8qJPzHyDQ xuED2futKTjSavi3J6zntEYzBiBbzOl3ZJU4H6cVB2LjpHKjmdmMM6PblbrSPXQOUfJCGiAQAYJ3 rcYHOxdPsGc1zuhcLV1GgGf6jfK/JnYx3xQxRiX2ht5tZ5BQCCszzKNzOGB+P2So6cYTct0F9Z1G dkW1gFlI/cAguQLiKG0CueEXSoYFZvQ/Jb/mzDXtrzN80sej/H0Ud2clPLN8qdtGOJAlFH0rOcnI yd089AW8nCyFHJwrL6iP4oNqXeGAGv88vyX4t+fAyCIYSV255gVix5J2pFQXRbjZhpz1yJ7oGnjE r4bAJhf4xoNHE6PrU2Q6xd3Sp4X/oZsensaGvmx8QgDOPOMvgindn6u9BqSBMi0PEXmzgR17nJNL Mb4R9+viql/Aa7ZsgX2we0Z2e+YGcYbs6zCdQVadtwzSEyBdb8vyRutugE+PDvBf+jHU9LSs8JM3 nEYGXCbnwsv2CxPZBiXSWKg0w7y8tNH601CtB/6IbMwSnhlpQgfSx793d4PDRetsMj5Rr8F1aeOX vUWZoOBSnsIJ3aivbGRFhYzElHdPdu3E40JqFk/GxziatcREraCxxTpv4oA8GMS/Ns3+0yU0MsBg VV56mnMM7F042e2UTXFOgLcDvfuveiRN5qbBjPqpUqrlNCUrrUwnWWbmYMV5b1bDdk9y4aDAepjH xBehen8qeg2+jevTdM6/QKPA1/lofwsOfI64cQROGmhdTCZBqPXHt43sSsZzpe4mfzRHKnjhYJV9 dIfGHF0ixPcNESMRQuacosVJVHZmywAU7MqnoGnnKgNspXX1MGe4OJsM/XvNx/F0sWBkkjcZfu99 eZx9vRa/Ou3GxqZTqkvqYnAFXH4o9qTkgcVGJhQTcmnG4CDp7o30rkaKxknm/h3ZTRt1AKiYcz0O XgP+QGzECH3FhVz9hdzzjJNmhyYb8+kJHZOmNjjppnL5wS97E5AHajeNoMUpJhuYWsTMTyDek5w1 x+R4o9mUJ5B+xAHfxf+KDvLbgyD7aRIpoMJGEsJDFYUnoiueCVMFzDQ+bO/L1Gl+e+vYc9GQkoB6 b7D2p4sV0junwVHcBT+Sn8QwZJPMnKDVjG8GDqfB9MBjIe0PaUcz+4OZr9/+6Ka1i4d4Rrxlo4kk xrpTtqc6DNCUbANkbrGc8/Mc6idnOWcoSGw1KBKirMYcFzKvhiIlJYUuYntA/KcffRyc7UMFjDpL KtapUWC16B7FrHPbs4xwRe3CCwJVnOdK6OLBMlOREzgq6cWS0UxVB4TmWBY8imYM/GIgAFuA+AA9 qYdIfQfFTHCRbCe8TMYF1caeOARkp2A8ydJl9t7NvGOsw5vcaXXFRpUn8ZO4YwyAXZ8AxeUu/XBG klVyNZO/JzP16DVrxIDg1oWM3fKzZVC2fsc1nQyEaqSmd4DOarnO3UOyBVR/TIWyz4e6cnnpeiRE Odtp/qKG/ImNnn4o5GHo6OpqgsDi86ajheC906hPYsfmBYenDAXDg4MAoKDlNLfWDUUqBPWG2JYo DT9/8iuV5ljvvExwE6QJOZFDdoYdxtfnNbs8LA4/XzqrQ/Dcew78RVVjowfo03g9E8CrfVr/8uUl a2tO4spFtuRUqzUB24XAmDYGbtVYaqJPuQAXU3Mur0Evf8/mxth9Rmj0aAZ2K7ZjUh2VzmA6hr5N RVARTc3InCQmYy6g03xJDmV/mOlbzY+Ahwb9ZciarL+sFmlCfNEyiqmHTJxszhQPxQD650BmacVB A8Sb051jQOVrRJPHFpGLCt4v6Lkhh85RepNDEYz05tAgUbM9Hdw8XREQjLaNq9X+I9zBp1GHRsa/ 0Uk/I2sMKPhuR9dwbluoNi9j/hkn1tq+guqQutsVT1A5YSmQISI8c0El0pGm76GXxuydOdP8Cb36 /q/FwLcwb8pinm4Xc6gw7kSI9Guz+uYILZzPImMKT8a8WS7/WE2/0HJUkcUnLX4qpNbCAcP4fLdA cKLi0E53nfTGedeGUEfpC9UxlZAWFwAk2vu9CMIDh9Vq2d8ckVWo9CaQk8GwMmZwPMAgCL4HBS/x wyOERR83f95jzFYEK7uokN3c2kzcF+onDCtVL3S2XMcn8FKIz8soJlbVAEHMn8eChoXcx/bT9yIl nMQsDmNqW8UFVZ/7zAil5fCMwkJFpnzyhbT3xbkWZttI0aqpNo/DbVfl+ni1uUwpVOtb+Q+fn7oq ACc1yojMcblwMvC8vpOkc0CQANqUcJ/RAFOoPbh+iUxnqxjsvTJWDGEzFJfmasYg5A1SOZhBTVQ+ OCWBa/+WYWjng6ZdHOCyNUctzoeg4CEWyCjavOU3nYVncDzsUCZgKXQPZkWeAIpShWwFfy+wliNX V0kLzbZ1DUCUoTymkwRjoJ5W2Yl1piQaxFL5sCOQ1JmbBygG12exokZI2WJX5y9BJKGR1MUG015k 5mKAV9fiZ4alFx6/s77nPow/2MvsdsYW+ZNbLcaU+zwC1gJrjKgTHMvXhU7WrmwnWobKE33oZSmj BaiMmkDnsUamHLfn0JFcRgTFupp5HZWMfNGrBxzhtT4AnLbDoAWsRm2w0muu0u1qIzjh86gXZrwH ZStBunk+s/CrgsJ2hf158Jni2vZlxvEHfOfo2Y8K0XKH7yQvgMZqKb1XR0G9bO0lrbnGaUWQxyWa xfHuzvQ1Bwp8Oc4EyAYxpI9s1JXkOixXJSNXT+rlCY7to6zm3EZCJNeOlxHJPGxGjMw8ULzBf8yB 1cxlHL12EU+MWxNHDoXHrEZqhsKv+ArajUZjk4ZgaYcG2k8HXMxoqqUz/UfA92gGRtZpfVtw0+Sj VZGbgtHv98CGQDbG9Q1UC8Psenp+I6SRPPuUg4OiZLB0okLXm+cAjCPS2qdruADjgJYGWVci6auS wBxCRsJ99eDIw7hrvDxGlmbTbwelhQGqfmDTUj7qE9WAZ4dOK1p1p+aKeztjRtgnpa2DdSHDIMk8 6SB3AEl144H31mDAJZGzz93gUbXC26xIpqkP5WyMkO8SvYbTpGcF/EjjNURsGRKZYocw6gHSb0ks wJNQgcd8/jU8rhmre/zSgHFDB3Tn1xYJbVQCrRAjJqEzNcbRb+mnhkyWvBLjP/WmACnloGqI5CcJ 2OdV3vwAzp6PE7mF+eMFfJPrXgTDIto5H/2nqYl0y8Iy+gEqiaEHMIanYoUezkXUbWnhR+O6L7mD 9e0Hcdmdf/YrYCW+m91jAkBzJHbflXxAUYZ5MT1vR57bVxViRqDlx3P9b9Ur5qJZjTDmANOaTphH 2A0CuMVmM0bIiX1nsIBwbkwa2zUU9jLAZUCps4kFmcWDAPub3wDAII84zuRA50V5gr95UeYMJNPg OXL5hgf+xdsPQfRtBittIHSbzyDONMpmB2SBjYAcNg2UU1IW1vsRgjN02YM3Y3Ya36RLLBoX+L4x SwyoJAAHhl1GeQNFAMQRd3ykI0dAN08mBirHYaoFGeppxchSD6YGv/G6piNQJoDJH5qR0UDISsRC /3TEWmRvTiwWYOWs4OZ0DSRke5zz5tycHGys8oRlm/qcgia492HDsR8JDsORlnMxumb9NJS+V8fs p/kf7hoHnQfqMK2Opoepb4sIEv76KXYFBfxGu+0ASWp8ZiCFzN00MvX63XWd4wh5pn15eLDwNd/H uIcbDpoi9RvTLvM83ucbhVkKguE3M2aGcNXSE+3n2+M5IS6wSISRN96s39xW5Q0mrfwDN1FFz4Dz Tu/oEYDmHL4TEJnGRpxdfXp4rPxXlsJPHwUFxV3jU6M+aQ/XvC975FFiESaQ2qyBLGQ4wUj7Wgpc OKAieqOsdRAn9SDatmdvkuWuNHutNSSSRVv3aLgshR1GthbWw6tTITFrk9jZrUn8OkI4ouTVjtGj bvd1+NzihOewGrb6b6esVHur71MQNsZo+QATojU8hke0E3n5Usi/gAn/Bt6Q5dLcRr/7xHvzxDRy zPSTGPdeLFvAj4mRcsXT04DiCQNhpCUOlQNAHKPcqCvHdTVajhI9fdyjrI3lYWvuvkZVkxPgq442 LGor5nnc/8LRjeLiEHBcumzqQUdaO40JoiD/0QJ0XbS/ZjMnSz8/MpPjPaJ0pGamVRLEdJFdNKIk vGOgecIEBZ7MYQ7EOifKAyz+PgZTbh2mNQbGVTmn9LlDSyp/ZroEYy5Vw88AgLR67Tapnnj8saep MAYmZiX3u1VKhYGguWWKgROHoIe365nn0IEmQUaFeRtwaPygGdjXYSQqQ22n7qFXjKlW0SUoRdNs nvYlM0oSVtBAf74NlzDaVDbaEyKg2B6FfUHj7VQ18A6K1Z8ltzb1pgsXgF+TxiPN3UzReKm4Ji40 2wCm5EEObAgpqHz78FYF21O+AaDQbtAN47lyan1PK/GoDBBOgyv23eUoxtc8/jF2nEP9m7oDl2kr K1U4uBjx0XaaVoeop05ciup6mN/+EBd9/YNqo4BpN+vnZlYExwVEqGlcXWRme1/87YogguPbkwLE ogvqn2u9JEGn+xMpkX/qkQ4li/prASnJbl64hI7jztEGO+C2Lzp2OdfvxoCclQ2yvw4WFtm1r+vc 4yaJ6pcswpZwayvc9+ErjIZSP7KTOyzQaFlRq5qQRICCWZg+UZq7inzw+vZHiOM7OaynmI5lSOyq xzWPfGJ3VYnOBPA5AAWOef149xc8dSAj+o90ebZaBq7Ho+hHuZU/Ebwg+sBPBTkVqdBXslAffhCM TN4lCUYzq/5yCMb61dBMxUsVuoK1ZhzGhUFMQo8b202yDD5XkmMJKeBlIbct2ydHEUaVd9Lxy8TF wWzSVGzlYqOqkROueseLSwrym5ykK1kIwI4D0NDH10gpBAys3v6lqgQnWYib37/AKoqDpRJkf93F bQvPDyix2m/SmNBDt6OF9zckn+aERV6hm+n4xkKaXT+FNZ2lbHU/tPSjoP/CiswjzKeUQfl3FVXT h0WohLS52ocK2mhjv6LyBmPux9z5R75HfnQV4OjTkKq1BQBcWCsszRdxs/xwxkX6QV5EWorOwATD K+5JEE7pqPV09YkUVbCAdFm/Y2NQ7UDgG+mDR/mKb5+tqbt1fHIQdOZEjKiS7/eAVQOO1drYeeVk /2Xzf13yHTwBkDnrOZZgBfoeMru77aPQ1W0CSb/dyNWUY8a30xZZxusmL0bMA5PbBt+6BiTeuEA+ 2s+D7lVEEgYGrqutt7ofucK1Rfa/C3wOGNF3hiR/vOpFp+wU7BCF9DSCuvQfhp5+ffI4Dno6I71m frVyf7WBnxQ6Impi+QcC/5CaT9O5y+yXArkafepmweth+sAZhzGZ+Zr44yiG5O42pOr/s5EuYCVr Zm2NBxYvpqEDBNoGhc1npiHkv3cYH8k1x5pytBCorPhuBBob052uA+ivEZYwJAcko6htvJ0GSSUd o63FrcB/rqEX/TRYfn13QXbRQH9JoMkLVsHlBck8SQYDKNGGOmbuV55d7HZWW71sTJaA5V1fW5yG 0TWgRALI6iIMtr41vjIdnsZxm+Q856KRgKm7ccbQb63g+jg5ingywbPx4JBp+XnhyYx2WqeoBsFx luvDe66mBdCTtwKBqQN4nr/j/C4H+LQ04ICRULs6tt0YXX7IiZgJCnl/qhqwNDZpZ5QtCj0ZgCaD B72gFZWMPqAQ/nzgtMqReXkOIcMF3igAX8c60LrfivCtIGrjocqJORUrlafyYP8xpWYlChDBxTY0 o0K5uHMhtbs3838NWVYaqIDA+o9GtXnEfuMF1/SHgTv7qWyUS8Aqgr188vx849bQ6RvYIAUto93P jQYCDPrD7H9puBGBeAe0OBbsIc+HKaplGQtouDhWLmchC/ngyX4heU7JmZ+owG81gvqeo7WqAUP7 esAZUFZkvG7SoLlUlYaD7RRc/dTG9qtVFAAb0mG1B+4vt8fuk2aVLB9DtOtrPTlSFjN/FoIANAZM GXg14XyU2OYvIYIhTzThIWGOwODPf3nq18xV1N3+ptCwhnqp7DmpVPiAUKiAHqq7ejOBdMkqe6op aZKVPL25Bfh651U9NND+73qhx+2Wdqm2NjwZXhzGagF6o6wGxCvFxgAs4NpFrL3HRYGvCVb9QHpy WGoAYTlGz8NBDE2mrHfDB35pRH96BD10ps7F9jYcR0OVycQgYFFpUVZQLJsjhs1J1uejn3lHN5wK anfEfGB3xylF1BTxRWMccDV9P8VFRQfEtSL/zteWZ9DoRshG2QCUhy7ALY+7xbbuI+t7xTXODBvQ RtVRGddEIp067sbGKthmQMOvEKuiHoQGQBkEBjH8zo5FfHpDFzr6BOUx8nlRKkWIBTTNeKB65Bv/ QE3vgouNwDyISKLDEMWSuPq/JRdApq4Nkijf42a/z9d602g4hxVrkWwqw5wpIWhrQxQA/4c18num vXjA/chQ+0V1evlZcfcN3YZ8iznMpv1pgYCdoZWWOF6DVg8nanccdONzBM+kLIioK20c+K4mf9bR K4VG5KTsc3117/1VwodGUG8rYefI2kYj1jFAhxthRx/LSwbQVpN4n753RJLGCf1Rs1gGk6TXhz4X jTLp3ZV1JypV4YVpBNxCYVIfNAI1Y9+sd6c009OZdArliiujqocMLkSe9GnLpcXsPwBMpgYWz1cm dg64filDOid0vzugQ6GjkTfR3WZ5eM1qpsvBwwhqj0Qu8A1KVX27ekcmwqplvUXI5wm2pAelbVuv esp0KjXrSn0kIuAfVmJB6BUHyI4ynODuKBu2O8YbqYmH9Y/CWhrM/SN0TuXgeL94f48HhpC15hjV pfPAETQ14IVUTTy0BjnmxGtiZKg+MMSoxdX9fqJQOZA5xnb2SSlVOCoHZ+j9kIrrgig//X0abc3b jZqqdKp1xxCkRyGZ60yzvdCj8ufpSYiB8HbySd29O32zVlZ476oIhAQmiiJAqFzVTdjU3q/MP2gF RmorfmEDCF+Oo3ZwUyr/tOQPvhzlhfuajpqV9aXFUa0/VHiAxOMYQ+tMO5HwcevjQOM/j2I9K8em Idb1jfDZ5xQbXDorbekmuIfPyY+nDISAWiEXxVG6r2P4AZV0uGosHnSrq8xcBJVlIzVzhbGMGwrF xsqj/EmR9vqhzlAW6fzsVymQuUF9J/ymgWy8uidq61CEiZ36LHksiR5gUy8Os+nV3rRG6owexaqW sjpemEZShyrz60M4Fk0qOV4FKnkp9PnHf8ZGB+psEvRQ7r2piGecC2D3z7g/VW1eEpm3/P6itoyc il+N/E5i6xY8nQUh9P0hTYykXoO/iEAapjlAEryEYIX25btxf2A2vzme5Sv/yWdJOI6wpYjMK68l yVa9VkiR6lBXhhUQmE3DAcZyUDDQYLi0ptyQvJCXNtPHS724B35hOH3HSf4R98jY3vg0uWz9+HD5 anRnOOXn1xbRXanfwgyjB+e+xudPb3I05NkX97xrSdXmuWaI2rtfcq/IzgfUyZRsyIWqo+10+El2 owXmBzRdPVh3KTcqfUA+gr3G6mVpq8Y0H0evHBB727jSzLR7xeda4kvF2jZaz8Xl1ic5X4DZqtj0 j7G47dlDIl8p5wY9dobDO4CwV+YfJtCvzDMR6jP588UHn5XGRfaqINpgB5DETSNAdKVCvb/9hh1t 1o75d2+6qZydE/zpWsMFO3flwSDFqOZfB0uy8qVkQbHzn+xTceR5+vO0l/kB/PpeBkCyx4kF+v37 bzZ6jMkBEFNMRjIGEIbPZuWMtcZdtm5K1HI+brXPELK+QIUq63pf8yaDPasrUSD5mjax0pb0AHQ8 a9FRjBVG4HYgxHYC8vktPUBJlIfZHOYY/bRu5+MAxOpQGPWHv7AGhLb0dnMco2OGvQQ8/FUodeCT 288K9bB4NDSTcJrE0oWrR5VSyFD3pHCRrjSlQ+jJT+hJOjk8t37yvssv6d0WjbJfMLndqb5DVav0 q8BdfHlAENWn5mgAQNO0Qn+5DQSrtAAhl5W56hyeg+KrnoUXATWaLnCC8W5nMX3ENWqLF63ZrsBF tfUlfFRg1xCWhhwK9sCns3/Stul6uFqb3HUkiM5r9XJf9UR58IwYwJrPOaBfQKr0V/+vPv3eKQYr 7onPzHITervQFTn6gIUPkiOMN61cvwKDkLM+hvpA6qQL4VUxvw7/hWaooOuyxNVOkEpsnl1NR065 ZwiQSqTWzqh6SLN07FByyMw6rcUnajOEeveMDCcVwAEmJ1Vj2fCXlu8kpynbqPTppsfEtfpWMfSM JAmFKTG6VNQrICBH45gU1thPdLcb3u02iirkuEG4RiHLyT0wRVnFaMc6wVEX6IZUHadLIX8Ahpxp xqS7GnfKJJgCoYjayUtQTvkpAJdgr03pCWxGLMYwWK9NvHwWhITEGO2vNxP0l7QRkkXGsCvIRtcF fDi31jW4JcVaHHHL3NA4PD+8sIfjWHDR8+WHx1Da67iyywe5wPl2Fiun0+zOaXvGeEQFxpdv5uw4 KQa5dEfjMMCB95MDPVTBzVUWRkc9jD55j+baTUuMg8jG08XWnMqPQZjZ498ETUwO1wC7wEF6AuIr ISUZTLDGFbVs+mca01uypDBVPQJd07n2O2j05RWmlaHGPFNVzAgxw4RfE6nnRUpVN2FVR+kSyvvT zMbshkaFghxD/lDHyRWq3CRjXljyh1E1OJAKERQszoOODh82KAWkpeC7339bPJyTVZWcf+GMyodC UIhqLY1RMzaG6fsgvjdChcGEv0qG9PQVDite+3Rz1MQ6AE93TiDChKlAVWmGGW8r/H1lLx32x+nQ Q6oVPa5jv5VVfUXh2kD8+0tIlRc9Q+9T+o+mTRlYad6YB5kFQY1N2td/caRqh6ROkOoaXFroC9D+ M1C6uZWReANfDLYMt579sISuOvFn4XZXz7nP+UQNLkMkxwqdO/heJyrPaAsekFgouCkkAeuBz0cQ hORW9GrEEn/kLwhvOc3jsn05ZtYdfyiyvh0Cyed/sXMGoqK5g8yaIgwRSud3vE2/GAuV5/ShuEW7 Fz1jKRurBUshh1rpwNK+v8b3wAGS36S01feRpFKXb23dH5Df+Br0pyqpq54U/ATdsu+Hlzz6DnZQ CFVP4bsCQjVDfK1N+FIadkI8eZasNUL6CaiC55Iad6CJ0HmlT8UQFoOj/rokfF3CNMsTkUNqxenR RRGNhdoD4IfgRcbxB61lx9wGHUb0fw0GB2rH/RK0KkaphrT13sS4h+daVgbqhRPhhke09oV2OsaH NUVyLCaMB9RFxmApQUGHTofGw+DHwD1A9kYDgREFeAzRNkBCBQBq0DGMZUVLGAUM0xz6DH1SdwWH ToBoxzmBL09q2EHXrSHmUH9kueyjMqrvLnBnoZGQgyvQ6/OAAJu88ru+/1uNIbRPwtWLVWUcXyPe RHm8Of/cJBXGTITQHSi8MYHo7Xw2IMyJB/jEQKZABw8u08H6gJpI9BDwe88qbKHqlAlItBErkRzm U5q2QcKOrGCziu5mBUqfLQfQQ3U7J30GXbK8Pz/u3Oiqi9JCb+WvK1qT6iH30TZjXxn4J9X4eX9l FY8qKnJmNOtA/cZuj2+HccsN61AQKq1LuYUGL+M0Demz+rG8rf917mP+5OJfjf6LP2ECkmlGgT1Q vPPSqpWreuubfP2K+3hywga8Wc7d2H0TpZVqyam0+fpTRrlmYefYnmh+N2m2KiFIR/bA9tp9zH4a DOSUKBPSpEOexRDJZC9RYi4AMHTNvFdEUjruArnPenkKaymbDIAQ+8x+VTZmetNrp+VQ4EYAtA7q 2J0M7ikxuaVFRFol3fW+njnLwAv+ncD+palNlpfQ8xHVhsqtixUQBlXDuhMmlfNvfswA6sXAsUVS R/SbMlB06cIp20dMzwkmnUNAAInGy5xxR5KUa9yGwGnjWSb7PgayTJp0ZSVfmcRRR8FmP3yurBfx iEVq5Ro8vFwFqRezJyGGeY8QCX1SjBNRK1Ej96SNoZNAluft6TQANzxA6ejH1572mQVpkRxFqHht 6V5MlbQEdUjGbH+BbK92Qq9F+dzFXjDH/vSEf8Ia/+R81aLR6lwD6znS/FY8TC9n3ZVpuXRh4yZu 5zwAQNxkJfWf173a9rwBMcbvcwXMwVSq4Y3qn3k1hphQ0DZ0Q0X3+VB5tMXnp0sD6Y7Kyk2dCz7F STRUfVdpY9WjlsSX/3y/IzyHm+Dv0FC4VxH54vapT8EyJ3krvLnmoe49ZvKFvJF0v3HXbDhRgYVB QyJH7r5sR4k0gB8RkBF8JinW9weRBPGo3Gl5ACDaAzwR0NRfeJXawjiGnJwyr5e6JzTFRyE/IAmc 1RS6HDSYiD6Af6MF7HitQ2hqa//y0RpoELpEBR7P6zJDYiDmm6PquSTc8u9Ml3myeAYoecZJ/bnm GzoMNYNqfzUXcOlXM97MEzlvjqp1NSpDf1qdC8nNsuECjF8nrM+m643/uFejnQDVBTlqR1T4/Qw3 aYvqhfSMCkCUNMyKpUjzndBA3VfcKRa45ed5qhKav6KQPbkj7IPmPMUFn7ZbLwXiVi0++faWP3r7 gIVXLOVNILGSvDQqnq+GiHBsQBMbANMrWjeVatB0UP/xQGG3Vi0Tvr0MLj/5c566xReGorQHpyv+ 9Nx6VpNq30LLph77BarZ1QTYi9pFvzmrur6eqoufJpWQI4k8ip3+loGElfq2j30nQhd71aKWgnb/ U1XtfZVxB2fFkcZPLQA2vunJgAhmKqZHea+8Kuq/lRFIMLoJ/monhib6XP519ykBI+vM7fLAUpGX 6U05hKDVERo90HvQF0J5Nj0ml8PXPrQm1xGV6cNl6ZZuUccQUWeIMRbCr1rfakJ8lQuqqpNXwSkg RKCVBT8F1mBNFQYhtba+ecHZrlVgn2DN7ICofPR01Y+21j67UEd5BGlpTaDtzUKJWDn89deNga/N LtLhuIKJbRPiW4NR14MmWibXyq5DnBpDjDyBvdiSwPr7ObHGDHlqbyGgg9Imt8f/wKY0aNVmrRfQ 6FlW6jhUbMTpR4CgB46ycKWlVrnruIVHhZX8DAL0QCFPEJwcYHswcseDKbikGUZ1sIcdB19FA5ws vDKYUL9dJ5CdNRIEcZB2jRLG0I5tlEM0PXXWXx94FkOabf3YjtZQxQH6nzVAN1dRF2Y8vall7IBJ rLVQSYatUb3YiEfLCQEzUYE+hYUBmcP6VLB0fgcxNtcRRtFEIlXp64In/w+WBwXFi0mPEDxQJkQy if1/OiyFVkZ6DEHDlllVeIRrEwU+M6B9L3vqhhqBVxoLxIcNO4504/SWKArPXcvInekqPToKh7X1 ftHPoysrLsws6JGYZcHcwmE/PTtY9yrFOLU2x5p+pmzM4xlh6fgB5g8H+hBZPKv5upnlXiVQwMe+ rlA5ImLR3W55PUR63xYEZA0ijD6V/ADzRp36AP1+xExnUWnrx+tdGdn2JXs72pVKR6VnnPwcNYs3 /BkRiPkyehoNz7x96lrm4snPRsAVy94QHenDxdBGnp2QR8Vv0bCalz2nZ5KG+7OJVMWN5C/Dkr2H V/loxfRPZ7/HYNS8oVKglkUqT/SPQ0R+6mmN03mAugI4Z4xJaQdA0lRutVoKnO4+XJJFg/T/8xAm cLNWByUbpALlidnMERD8RqZtC7WlQEn70CtIGAh8GX53wbSGKf6O5VLgaodL7tEEhcnnjbDMvfSF qRf+HuqiubUcq2OHzZFZuOimUF07b4VYLAOGjyAoKRlqPE+mdiaP/pN8Zhf9y3ypiapbQkTBCqVQ qsCkZsSXamlfx8rj/qWFBxNTs7POZ8ENLB5HK8HTwkZQqPrYGaQAR9PFfGkYYJheA5D8fskJRWQg IIngm5oZ8InJiaB3trHsiYnJoKNioVzJoCBgW57ZlP291GALilCUlxbWl9ZMOc24fj8sIc+XxPrG x7c8rYemj3mmMIZR6Vw/QD/zLD7APwBlvOsSr7gfNfI9P4hDoGTszAWQ9TaF/MxRgOl8q+HyVUx4 6RkhhlP7xrUKFAeWNOvHqZFFwDnyZaqlJPlefBiLp84uDmFJ+WsEL44priF6xO36YYc5yjSGjvmO aGEpJmAHyWgmRkAtL3Kv5fiUOtZn/F4+cOYbwrTTBawUd/JRB88bhVX6qlyyXBt1AEjqyAbAbduu ZhWjCJShH0WkgUdtB8vQMgO1jwVgdvlDwsH9ot42PFCIgiO4Z9Isb2m8Y5zMvtFDV8bnh8O1UcUD R7IpBakPT4z00zLZsBBqnCR+NnQz1jC+wEAi/S/A4TCNCLv0EhovMU+A+tR5Mlg+Kl8Q6V9K1ZJ0 7QqQobDImjWwhEfni2FqorqNVymHufi/Zt0DweG0JEU/QUyZbAXlH0zv+aTrXdWO5pSQHBKjhMwg EGWikimWqnqF1xI45ABFRwYU9CPchgTFHsjLuBKGHH+hd3fErv++fL8+tNYi7RWZa1OIh2fYTB+v 9FC7gjs2tlJMjoeQuLYHBdR/Dl8rvvhO8qqjdHoAAaPQRsXMBTfu5iLyhgBwxSsP24Kac+acMNlm gKb9NcBf5KeEla+q6YYR4gyiDAZARv1dFFWpxmJ5aGx0SzHO/MShK5daVYWXtanAK3G28VHB/9ri 9AZIfhpyHt3lyGu6nuT7X4W2ud03hnx00hHGMiIv9C+g9YZBejNYxkzGqwZ7Z7Jo7/bfz+/ihidH cmx6L18p5VusMlGHzLGAZSQAqOerwd1YW1+jZTE4J9g62T5ERIajwlrICaiVsecWRWZQKfpsUIYe zZOJ7fQd3Hv9g1NzFUrv3g+ce1fWVm/6tXTzkZZD/vaKj5JSHOdPDYv6tPcWVeNCha29dJYz5saq Sqo4Y6Sq+8PnNQYrKa/kFWiKFgAl6AbDURVCZ5YpK0NW35F/vPUsFSuKv0TnieCuKvQuItNim5EG kUaahlIrrEI+IaAq5gEWrof8oec9g8YBmbbfoHDcDLZV+ZC1UK9en9fqZdf3DvO80LCHfz6U8e3i D2gfECtApaLtaAfY6VeZAlH051aF9OHLrpvcc2XirAf+WdHXDHBmYD/V8npomGVCU7I8TEK4cMwd YoLsgQMArY117hUaRjupdgdP4xm+9g24EjscG3zjfKVvBTgXhkIQ8xOQr/jlDYWMEClSFWcDBqWL yNLS3b+j6uY11rnrNQFrRM+MB5o9aYcbqHp23zx7akyuTCbk2PmhAdFF5D9jhbWYluipRbz9+KfO oGBDYSwOH2vJ/T4nN/HN9pgJdXzfq272vceDDWaljQUNGM6Mhcor4uMOhqQ6gW0h1gdrkGav4cNn DAGYLyybmCVFBQCYsPW2v3bC1ag6env4LYbxPzUP7NCMcVfsBqXA0LTp5IDzeUI9TisWPXfACI0X 4sXaQ/IoFGwh4J7gjR2fNNnlVL8lv4EeoDxIdfObtRcesCUOre+6Jnw7UQcPEIRmVAYuAeWqBNpO Wc4/7BaeO+Eu33mpbNHXpsWcPFFA2wkWxJJy6ZbQq+OAQNOvh9z6nYOc0da4s2XQzJ04D58nq3H8 ei9WNOt4FcTrdoS4wJziaiYAR4bc/5c0nX2yRSKGs34C/D3N8oU2zFv9lB7cJzxM/2MHfAgIjvPn /lG0HeKFdUJBrwLIFz8yvakCOFGygBut7w7EG3iz0ZrLXve0iO408cKgu8a8rLDZe3Y3NlO8dr77 mdsiKeQn9Ed0Y1YIsAQIzr9RzDyPSlYYtNQEmHTkMFz6kGoUzyjbx/1PMwKNrzKlf1CnPUbxEpPs k1iCpRwh9LyzMYiMHeUUCG+jJR26YvPPOBQwW5pxTuxu5PJgkbSTf++vZmcRqbKR/2cwh9fUher1 M3A3Vat94kU7zLytjYcM5mkveOWvZ2M4slK+CxexDVdn1qTGxomHBkzhxLsMt4c/6FI/LRUIIHAt wAx9auBxfmgP/AHrhnPrEejBQ0DaFUakxoyHkh2ah6/2zcjfzKXu/ZIWVhGrBtKSEk+HkSrFR5HH BpFG61EFLQLSwmjpdcVFNJ3HhpzTCxXs44WpKpqXqOLEUYVp3wqPOCY5e4wbkvFMlkwmH/agUvGj U7Dd6gMwykQkxwotQCUuL7PFwCgagqMJ3DXDM9LM/xI4PtFGY9gYXAaQFmF91FX6arJHEJsMebq0 wzXb89dW5JTQUVk4UYuCwJGrRxiX3BgK070Ewqr0GnQvsS+HhdVoBzREG+GBOzMyDBP++oClrjLE 3IavNA4wJDGGkNn6nM4FKLJGK4CZWscuPF/cjpCRqJuKjX0TzrN9m6cX8hWQenw0FAyLiro9Avs9 TLNdPchaGFKzeP0gr8JUwpMSU8f40P64SUBTho5zkAUuZC/aM9fFgNIpZKBm9NWHBk4d0xyyJ0VF r8Ejhun8JAE4cNpra8erWCmGwbypz5rO5I6zx8eVBs7zSW6YOia4312e92KPYfsTdMWyKBs+iyMW ebqXTfl4Fdp6SqFGnCej0dUHZam9UmO8cvzPSbWFMYxvLwM21THSh5xSfJMGNjNZLMDO5oMxUr4r fUFD9fs3B5x6NGE04SkYjLNPRc2KkeUqv1vW6Wh7adqWu78sGPmA1oCVfY3XToqEByTAvIqHHOS8 WRvO6NoRAJmOmLMMXNHruamCJQeKmK8jzqqvxiEgBwPKOct8MkF0rIaRqFNp/JGSjzyGRdTgQp7G FiXaJ8W2ghcWDNOXhG31/+tRvpPHpRrjXnv+s0KGPaZDBYbLoaX4Mjz3Rqk8oZqW98qpQekZDdHD pf+kJVOoay4c+LSo5DA5hgWVqGqHkGT12S3vh/9q1oX/LeQbWmbpQKXba9u/pE5ky9FHWwXQ706S x3j2QT9M96E+QouXHbL6JTz8glMXkBK9XEPZ6zqM0tpFbvpS2VxdQin4bkhiXJBmYC+XykNjCFUp D0yHKbw6Q2iPKpxW+5NA7k0C/tCqLQ/Qgp4ywmP8Xesq82mZq8yNGDAFLoC68JLmoSucf9YfM4JR 6vzrTgXmEBkHj87RMnv9a/ME1VYjenPQehwOM/vZo+qfEKSz0+R0QupMU0mQHKz03YCjwPnhRnSp wU+1nNclwoXch+IPBpTIXbmLnCu+KgPAS1Sx+lWnAYxYtcWWrnWDaEIGkjDNeK5aTa627Y8NYD// rdM6TwVWRme669hwQLScOkQuezXF/zf1/nbTAFZ8VpNSLFgKqRfc2VPRoqCoiIO8J0bh97i+IkMo fIpJ7OzFVuiwtMfIwXdc7McK8dZ0HXjGQiuKMfr8J30Oa/tRBorDg6D7+n0I5buozupSB5Ihhogd iDbQpC9gnQ3EvbK2hWfjyKbTADEzAL3zpUQtELiCGChzQoOJ+GTP8jS+/JCExU+ITCbLRQGpEqYk u7X5ybxFK4DNH9niBOnkQ4+h+7fexvheQTrtUbCKxg/FvKRRx/qiuKQGXS4cx5FjP4iDK04kVsWH BUXpbc+4wK0opUf2IITplb8UTmxcnbx9CtBRh0cUjl2Hek8BJoy9juvPKQ4/aNMcfLIEkm8sPQux OuUkqLH9QLbKceC8wW/mawJKiOR4ndwrgp/IUd07b6wIZIpJQTxC08iuZ8Lz4xVnLKkFetEDHLzH D1H5aW7xGnm4foX0kSuH3e1nY9rDfGtmhAE89uI8whf+hWbmKsRMgqpSN7gEQ6qyVG7wEarAA4MH JPnxCIBbbz4mqwgRQVInxjgtznLvrMeVeWJ06dEKcExQXW+HDBuKo9vUYfydd56lzC+ljKp5LFG4 b3O+9r3xXPq3tDpQKf+1uqkHfUaA7IDqOjhqK4C8nBrUQMi+Xbplx8OANgvfsxbMHXwZ4DzapVUW uKcGQ3RMhykGLKTxFmhxj0YDDIlgNCT+pb9nFoZ1kD+j+fz6XOnfwcwiquPaAEHANmYHACg+CMVh 4eaTQ4IRaoD40JFXr1MGXOdutFLgQBPHOSbFYhGpCiaSHmNJILX2FAcJCIY6XQhYhwSeu+bwj4yH OqiyeKapA6unQfrjUOc1m8n9Q8Ai6gR1/eMZ5d6xTgSRQyvOLKSmp0zqtWZVEAcSO6y9cJyk6q2n 3HxNZJttvIWBPSv8OYfS9DtQ3j+txu7WFsMFBYlCEZgCObvGMl+CdMOsj6s+LXndXGzGyvBnqjoQ PcANyB60RQjaNSsQ+dXH9RE+I+KGGFw8OPSHZcuIo8g4PJdQFylSXYBbFiOwhTXH64YLQEbAz1h4 Qb3cUgMPOnJp5bZySMfPukdqv+SOVdViDkj+UNGwy3yZrEmwPKuM7LvlI32Q0sjVyApLA25H35UA vXbKG5ypV8zbyMYhmTIBhbNaNGwG9AHMtcc+ep/0dkDThZsuhEfoUxE4DNwmYjkktT2CqEOCwXaj JBS+YT4ABdlmvJpiUJl4f7g3oEEUNqbEQ/0dOcaIVB/VS9L0pxAtv4ZcgAD2hQzziGOdHc/Ag/TJ FhxeolO/Xp6Sej6tSQ7LCIHSVW6F6+u+6zzCd7qETACGKzz1DHQhPqoGnzzJgMcIc/0UK17mBgra u0qE1lH916DYd7Kqd16dZ+l7xg3lBuO5Z9yBIrxjZaU8jk4D0VSqhzzve6kOsT7quUDA/Xf8yDG7 lmHsQEM80xsvxTJRleC/+UejJaSWnNGFpxHHhYDi47bW5XarU41WrNyP1lJFBiWdxmvXF3zQHRHT OZgwxQPVatKWhbAi/GYrOVZWen/yh7vXwns9IpR70Dg0amoAu6lBzN/rLIZiY008V1dcSi+3sypJ BnP8qB0GZZJDKtsH+yhmSXunVkf01wiFQABlL86e9I8k9sxyko8TkGB921AXtl3Nt0fJiUZDk4dS VvoPtsLCllcDlpD7kFFZSOo/P6ndgvAaIfD1KIsvhiOBm4NZ5fhPpbSFhzic+OyWNkqitACNu8xu 2iIDBmqpA6eV0iMtT6ofQ3F4xWxg/Ex10UZAy9HAET9i0vpt9VA+DdekwMHLQvLY+EP+WWOMhujY EiFpXCD41ZrcRYJWiPjaPBQK6eKcByQEt6mv1790T5kAoB3GA0QjNTSvAFsXxlDbfYSDOgGgtdzI 2mvOFxvOKPTkq+YrjgB6U5hYd7zCEfSMglsEYRRcRcdIEOIakUaGBSSYNNO/5PcPGHdelnEaBsZl 9Qbi/Kk5BP9ApwGcb/ZyDQVkwF2/u+Q8iIHi2uTGGgC3vSQxKJ+QfutPmpTicQubRmsCU1r73ZRC Y2XlhL0ORsjid3syTeYPfNY7WIh7VEz2TNM92AszczZj4BjSlcP7ElYdH9Zc2da4ustPQ4iL6Ijg AisXpWcG9m411GOTVvSVOmbNSX1dqxxlQF9pbMG5xJ66J5CYMEZQ4o/lX0ZHkGHWjOa8KMep6mW1 xsMsFS7bihOnr0DCulFPqWlSD8szEF8/+4Haff2+QgZU7piCBCMPUj49I07sztyvWxJHO02l4DbH pdp7n/3QJbZidFCO58m8cZw9R6dnVg5pOgcvqwepxkRFthy6Nphano+lnEqOHYHUV94PCylS3OMv OZz/580AfKbCz17X4ZzWxQV/qU7wbHG3f5cR1o4DUgpf2bcitUH3sJ8VToUVcuKaSnzuEM9YxrQj Rz0eV64kMULjb0UdryFGdt6nYIZOQK6X4R5BytIuEUcN+SKJVXSpS+/y3KLVCKC5YDpcBqvcVeYU jbU0U1aoHzR53XhwKYX4J5pvxqfXQTeYWH2Cf1aRbwy/pNxWtlwFGjfbQ0KaBy+kd36XARJUP/CD nc2h8OUw0ZD+UIy3EOJMJITDLqJmgzbm9TahmLmb+swyhoORiD6IkgYq/D1URUt3SwXXu+qvWcaY gzibtYVB/ny1tMukCqm6c753iOFOjPJ7SlHtgvMny7wqjn7Ffz5sVmsBe9Io5jaYRVaX5ZpkjDxq nqqRwMpzJcftYrUVSlNsEU41/9B6UnYDJCwQppsy6YFaVXzVhsz7wvayJKUA/jvr15zq/3dG1okD qTk9ScvkKsjvjxtFi79CJp/5o3CjIymtgQ49KV/AZwLsEAAXsSYtfcCRUqRyR/9wBlBn1gP4qVMU l4XRDIAB7yXk/90WA//aIX7r050YLPsOkkcCUGwvOuGsC0aGdiPvP/BK4Lu2UpbRhr1aJ5UBtom2 SGLPW7AChp8Iwl9Ouz46sAoxrcYEJjGxhdGHBVKXdf96QePaKbRoknLI+VNKNRALyDkUFt7YLZS/ XsmGMhXU4ao92Oz6h579V4JJujuVKjjRl4eCBcH9oobD0EvburnCLEBZAEen/xltqCngiew6L0NQ +6/e+8XmRC+kE6UPcLRGmMgK78/J71cClCXgOMUQWbnEmtN7CttSr528+cNXQsJlDivFK+YPQFPB wIVHFn1gfo+Jp6lU+DVsE+mPwtAI4awAt1zy9SMrAI2cGEUFzhDGIbraldFCo3E/21BZlYIS2iLp s/EiqkZHd5B3hdLEEWpw0UIC7MGRQr40BYXDsuNP5dELxXxpFtXr7K9RYdYrYlOTrzCHUuWvklhO OUYtOqroOUanBesN/pJBClL73vW3NSqFsHysSPjumHWRPFHEh+f+x5FYb4dGjY+cdGf0hziAkX6q wyZm3bnR+8npT2IGhHYdB7YZbFwGez+TuMnPqGaPBmglHqlFVFDs3MfYrXQW70CQtKxC4rhXfVEx Iz6HU2/PFcifqQgSjZqs0sdHY+FOHcWQq2qUjY2A7G4uPiXE2293pg+4AHaWoHDtbxyfn2blbt6N oXwsrimAtycd21abHWfA825qTHQ86DUpq+TqBwBZ52ZqHljyVaDMDlZ17gXRkvj8kK8EQs+N62DV wAIWvhKFvP8HNLrXu1kKshtgiNaHgJ0GFYXn5NS6ewXpm2jOFHtrMMGyavrOv0C6OcZ8qeIRwYZ7 IkVh8OEio/txgGynlgaDerUqpnHY7dxgF5bcWFY+ThYQOJQHAK1J/UH3Y2EbsXRGsiDTwM9kFbVO 6gHkqoJ0MhLkvGZB0dHGKlGJ+yOd+94iW/+QVpAOarzcYYNMdgTIDwevtk0FT/kvWkbZNdbrhoC2 kJyHdIn+3So6zx+/3NMUdDEmgtAyjzZ6jGb6XefGsPYJj2erfoSjaWNNIt7GLbt8iLgdwMYijLRf gO4cTvMb/JtGmgYop8amOvFnua1q6HosmjpjBnJ5rEZvE0LoycNmQHlHwe0PTt6f691smdG84bSd zHzrUNv00JCdoQrqBgTy/z9GfYUsfJxTZ6f2BfoCasWyGeYYfBiFO48KTd3z6lFnRIdsz2DJlG3E JfbRBrjz4Q2+94A7JL6eIo/BVgK+LWqPDGsqTjtBjsbbqbSlGwAuA4A9g5HHDcdFvzC+qYmWd5/B RuuydqWKyCvEW09el9Cm37MUqnO+/cDUQfAD28Bm/nxOjF3nKf+Kh0XsGm5+1rT2ZXvChSDNANZq wZpvzdMvknB1u/lUTSpMWCORhbfC3HasOR27sEqG1ZarPHcrbI8pLy3et76Rp62FNlKFe0MGHEPa bjng4GyypWGw3w6likySxUdXPEOd0szQriIZQ9DSNf9Su9g9aU8up1gIw/14xpX4/k2+ZbTdgGVn fgzNNOGqVpXkfh5E7Igb50AlC9/93CpnhUoTcOWc8cfZKqNAicg2o/90lysnkBLQRRNDv07/PRL+ J6YNOpyvf5O/nEaSucW9ydLNQMXoqZMIL1bY6w2rqmgkkB6Ayo+NXH2X0qGBm1IEEnRr+QFtwQCx L0aXRbfIYD8ucbvv2jG9VAYARvL2+vnQWYMnNJycxYy+G7ri+lRyf/iXpj2iJO/HdfmBuicFzLrq ramXVwidCyRdVn3dNjp6IH5Wsws7GpvTdMeC3CR8kYcc08J8eK3nVmMq08VDTFyRKQZ3tVBwxSPY iPvN7TqiMiBkjKsxzFMsdfVQB13hXQfOetok+h2iH/QAMc1KwIA6NmlHTkYyTPaWCcNNBgsrh6E9 JDXGj5HnZYJGa22adKsoIjsICIwSWWZseLRWGu/da6JYuAC/zt15WSVNw/11vCttweTWFo70XQE0 xClFxNQ7reexwL1aToWB7L0kz2JZVjINwKDBomyVBpWUhPbdY6HAfTmhRa/8FQeKvezOuev+Ry5L h0ehuwMYWGnilRb43EW5S4+ds0PHVZrAhkAMZ2bjbMT+J2tGIVJatPMtvc8GAlFsmKj9hHJYF2Sf BUPAkxl6/SpUEsGozIAqnEL/vZ2B52TCBc99G2Sr+9xjxlU7/Vra9AxWoRPjG0f9FzN6E+u8u5z3 K37ftqRswyt00f3R5Ig5IdrXuo9O4wVg2GtVm5x4RD70ruSZOlA/sPpqaDmHEwvluqfnASXorQ3A 5TAktLuzNM3b2fIHEOH0Nera0CmKpJTum8cFNC7IpXDERcQF8ccHEIi8Fw7HlolQRhqXA8+D6tVm wFtH7c9IJXRdiCrIwLmgq8epAnwsuNeAhmuX+4+ihJeSM4RMQTzPKjX8fIo6u9pEm380dQ8Bm0LO nHgGeoS+Ez/7cWWF7mErdD406B5uwXWriMBB7Gu1+LwAu9GbXKkXOaAAT7S2HKN0ZajLuhhG+taY 4fdBpIjQRYZFl0agW20PLoVF/296OBxHVZgHDa3eBFzo6muB/CnaOoSoNOfr1lXn7p5NTxrVL8UQ 9VeWyIGASGAAzIltPCzNOpZ4z5tmtPyEwfXbzv1Soa8NInusAtcyBVxxRCf4LNZWqbEZuGvphU+H Rvu7JmJIFMs0Vi+6E0qFilQGsYRp2eoS9qQ0RsVG0iJIvVFf9DmitjV/N4Kzqf0cum1WDkurRHSF 4jBBFzIF5R5WueE+EBAe0FTnx7dgHjqNsoaQNGoNpcF4wmc+RzjybCqsdO9bEy39V5Wpeyh4Frqy KmaQ65aWK7Ua+duwWulGs/q5TDu9HXHi3cXPrQeQT1Z8BCGuLTM0K4E4toXX4LmQqDpdpt2bf7Ra Z4J4BRHr1gyktwbHOttCF3n6GTRghcEHaAHGIWN6uuIZQ9PA0/INXefS90UezlVOHIavsfjrRzdS B/SMkLyFKMKR577T/MxBh0y6xkuPrE0FKlWLx0wleksjHy/98eq6B9Uzx+pF2sO0doFVCsVCKdtA UuUjrMXVf0PzS8/FSvxS6xUKS+rsqcG8Ro664oNDRerk4j4tnsDAn9mmvvv+HlUHJAaQCFu7uMHd VYxIXHIrJP2czLjRRRrF14scHXpM6ICwXgPe5oRhx0xF7FzgtwbgluLne+An2Su2OQQmZ4Tu+mZ1 eJvdaAyWZ+Qmu0cg28y8fWL2BQdzHKQF55uc7QGs5EXAp9lc48b35+uml3Mn9+ztBQHbpKsnXDAY jNzpjEIi+7ydhEd83wRxvRINg3ARTUOaUU1D07b4/KMvvKJItBKg5rd6xGZHagwAPNbMvm+lwLeX a30ZFs8I1x/Wu2Hr5sRbhcEnRvVGFlBU2UMqvnVBsVqClJ1GRQaTKnjnPkXcjoFm4MBMG9tqoDCb LG/la9JyCS25hhuv96c5A3pK9+HraOToNxwZb0rIMgzRRk1H8/PHduNyVSdQhQP6KdKWolDJdmli SLfOR3Nx/J2gwPAKz1JA3S9HNLakqcxc6oRob6gSMwGcFGrC/imhFpa2TFUghaOm5afnU5ZYOfdM 1XkhXyCIc/cgPDEtqu2dUq3FqCjqL4TmIX2Ewys7zE3CyWo86lSXlKTVF2g5rW8ywnGJW0hGvPu0 /HzWusVAXO/OO765w8yd2gXb3ivRKoJXv8qGbp96YV+4R6a2UTISMjBGRUB2hVJyx3Z1Izwi77/L LIM816HGX8WhAloLR56LBgrSxXauTdFdukVQzAf+S8k3Q77G/etG6pcEkIIFBnxXPYcWr8tPUEJt B+Ssx2OSosOb3sdUZ0Hld3cvyYhAz/sAulDCvwtKABdCabhrKqPnj9Cqx6kFVvEpG6eLoFYoLurk 8CtbKO8MtWUqwGzGoWpH/svV8JifK16V62eLz1CCTmsEkDTX0eECWky0gyv1qp3iwzLWMbTWL/d9 Nvd2ronhfR/gc2ZPwn8LSfMNeXzXPjxj549QtMYNfFckzRoLS6CWGzVOrJ4+Yv7eAhRmAIAcLX0c hGcMFRWRlVYW1tZXl1fXEFBQ/IJOwDl5TDq6O43NjU0NTk48PPw8zg/Pj88PCIjIiBGR3ZESktKS E7j4gQFBgUJCgsK/+bz0lcjiDJc7FaRsFlckAYg5jFzYk0XbKqzMqTZ93i8IMbTFimp68nw2HKm+ 6ou+QsEvqkYE6MMIioV0vds2YbTcBje62hTOBEYMDWoc5v50r+mGLKAwJoDL2M0HEnjuObIby8um 7iQ8NeL66recAL1g/kx8ZUXF2Bwc5iG5Q5S9fWwpdBjO+qkG2FSSxg0YmktaTrlKO6VrwPz8PX0e 0xZrRmOJBRUOoiT2dQ47WrWKfP886jVdyBVqRZRU+Ql9PD0HFTEnZsmNenf8x0DUTwxFOq5xa8YP Hmo035J9Gvy9EMAAH6DF/85fN5taftD1UH3M/LOn+UeIb/2kvN03NiRORdmWGnIQKYBZy5eqwSFJ UwZIXRnb/Iwis6nncVVAOnxUlQQG/x9ZGokSufz9vWV3wQYeiBeB/Gzt+4dI3lWadgfAG5J7RMGi CrvVDSLx/IsiAAffUparQArU1UDNmNvgqkDzPDPtY8FF4ieERzjNkFoW1LORRv4HeO2zPDwp6d7J DLRHFEuFuAlsmmR2frsaOsB/lYDD7LxA1XPwBGmE2HYVgGmfB4dJVBCGjxhkLbz4NfWGxp/Pu6qr LfC5acSfsJn2vXJcKQaeztf1PizVDBTfGyQwnatZOssXk3xdFmmqAdFU9jDZjrtKuclr6kBU06mq vHz6a0btNrz/zuKk8FoO0JtJ8fuA3YkQPLlzvMYQ6fDVxshem9ra/vrk+qphyMTGhmynUkVPOGFo 8V4Z26XZPAA9wCNJjq8aHWKoJhmN3U5WNEvsubB1WQ473EPWPLFpCSg4LpfG7QaSHxkkdfLrbFOv aelIFvRTg/mWzfEgcdM9fE/CCbNGuGLqah8JFyuHHqxQ6g6d9LizvVramQgrW1AAB5hI+oSFeIUL GtESr+S0kTTYz9UyHsvVas+fn0qRerxFfAlfAKICBfyHFCC6Bs232WlrFMRXa30YCoyzwHD2wcht 2iWj5pct/PTEecDp3ZEVNOvJijvFSWjb8BFybag6/ccjZ/DPYwmamwiXSntnAG1EidGqadnGBorJ OzTNhW7xvX2jaR7IBcGHrBTR1U+YJCwJCNDA6qVoPPyExX0ep3lAxBuJ2tnP/Mt6a7KvfDwy+8bP KNpAxxmOeqr+1CDWwI/YMAsaDX6s86jVAF4gOYBPGBLk6sEeToQXogoWwA8kJ1kHjOykEQOVs8LG W1vI/QYpRxiIUKv5IMVrZBpyGGjaJJQpuUXUSnn0I5p9rQ+1+W/qVRb5r7DSRg7YWiQayW4gj3IE yrmmMiqJRKXZe+kzXHM8XRvsWg46JTqaqDiFQCkiUrq4BqHL/XFjfQx2BGsroQ1EgH0fyQBPKXKy 4p47MBE723uU8rMCWy1zfMEFlJITgemiy3lFk2MFG2nqFFMX6mIn830BydcOnzDEaQeeDdYqha2K EkXLmKuMN5JqKfH4xiu5vHVMK6O6KepiwZW7IayX9I4eNHzdrD7qwN/4DAZGr4v6tM7ipPQSFqQd chaKO8ry2mGOBAa9rGaOAqvQICiapHGN5R8syR/CnA/a2bdOBkgWaanKNfQTGzFBGJ86Livg1SpS gt3YOJAbJMk5eioZztHV3Ar67gY0dgCOOLyAesnV8vU6Sac6RQ5vZdn+SSBtozoh09Yjida0D2HA HD2yeNI8oTBZE2rfDRXGfZ2p8lStSrvBanCMF2nAMiLq2h7R0BOYFHvHj10+qRj05cN8hBYFA+Jw +TNdpJlpSa+BQID9fP10Bcdq+p33tACYbMVAgF0PBECHyYnWxU9Iz8Ql61y/VUYE57rOgQ+cIhx0 Hc9XauH/Zgf1rGmSySl/UdhkSEseTmNAhb6M+Q3ST8teDiBeX/fb2c33nujRh7RBVpcaAZe7Eaed IveL7pmBW3ESxjT+zoteT4NQjVEm3Q/LnosftVovkNmB91J8gP0Bl03BlxlBkqdd4zDPi+5ZrlFF az8M38/Ln/oOXMrfF1GP1CwaaBLFK/8Nl1nB0bqOU+DkAVCaHXZabjL+yYm8BKwhhTWG/Ma5Wns6 4Jq8fKA40jxGM4bGBkeHx8cA/auHACIE82nqaurqqwfrq6s1/b20tDQ0Pv25vv4+/j5/v///OLm0 umosTQODwwNMjMzOF4VZPTL7BMRExA6Huzz9HE3OE1NTnF0cnKUhpaVn5qbn4OdnIOBgx3yepSBK wUERTkRPURklI+I0Ez9BAUESKF1hz3PoN78cQoPeEY2/+Q1+5D6gzseoxLz9e0x/zcHE/BWppDfD m5GyNBFB1zsgl41gpRYN9OIMMXzI/FyFQHTjALwhRnf0YoWT/DKoPPkOT5E0CFLIzxLd9A4ECdkd 9A7ONNLRR7M8KMk0zgUVULq0DwjNzbiHQIc91VBVUrZq+BfFmbOpWcykesJqFGg0h/z29QeUQ1cc PzDq9MDBvUpgx0VjY0Rab6EIx4V+QYagx9pHVojuwwJMosiEgzGSusb385B50Y0S0bqGYLhB6vKr hdN0+GeEXYSrMyNEGHPZxz7gTuPvD4z4vj+teFsiHs1AbLgOfpNFwJttCeH/ADoWFfkW1QpdEMby PtCp8LiRTo8Il0fSCo3ChKmmxumPFY1otgSMe7wedcGAOrVmMfyUusv1/uuFoIQdeKSjSoPNq3JV aZyGuWPMl4ak4uCOXK78UXlto+aUzGjBIQRFFBWwseJkxSX8dIAQRYG8AFmM8J7T/9HdyZtUxiye zxZRhZkDhv/PpOlYoX8BzDOcQELlYxvRJQeC6wW5/IOSTiMrboSGcILE8CK7NPrpGIyP8I301t7/ RhSroJDydM7AQGX9KX2isyJvCvOYFCmRBJUL27e5MLUHCTw4bryQIKyKUYzwhSkZvU4sFI435lnC 2CzKlpRcSumKPY+slA7g0lLpE2pHiBRIRGeWZKSAZwj3tBx8xd4qaoKBcgea8lO+0IHVTr2pk4f/ KX/E6fuy0kbr+jx8PI5A9jHQru/8li0Thu3ZWUzjRm3SBqxCnh6Txq3SOCBJvsJ8s6wv0060h9KD htkRU7SRY+39Ij+qakQi4L/PUYxzVZD8xZrpXUxm63QeqpiFkGkGIczFm+seVfNIP5AHXGN1tNHv 210Ok2lHL/4E3JoHqqspzkD4lhCumC2Wglsze/vA5gVqCYt2Yz+zOn0lResymnCXeLvM0UMMDngo U2hgx5S0IL5QjkDzKNVWM7UDlYzFNj2aTY4TatTQmJvbgXZR9Z9r4k8jz48GioCpQPLAhqUWmcFz verQwk0iFFfbA5LjPeebme7rOShu5ofX2LzW45NVOt9l0umwzHBcQWxKhUOG0IEqOeBnI4QZ3bZa FwDB4Z6pIIypho3v8zbr9LnO+FIlfWyRUJPGvMtfj0+1Kjfq1BRMx0drWPAlk2k8eaGcAObJq5BM Q+oOz9qc/nIqtAFx3zxdQuCOwW1BrAgFUgsWgnfeOgReOPwW56zq5mmgAvmUBufSJxZ6MAWyoT5P 2PyC8fA4th3BlqfHQJMblenO6SAK2cAS5k/ZHDmCZNwPuKvEP5tEEQYRiPe0DvEzC241jsUFPF3a n/7SKS4q/Gq6aOTMFeMeBrOBE4zM4yB/m9FCp0E5BGWcOoJ+KWfHNee/asAk8LSpXegQDSkDmpwJ 9oWqkddbOJ3mgoimM/s5sDYgaZFqWpGGPsWch7h/MJmJJvowYxcBhZF+0XjLT+XkBaR5PbCSxySB juTGbmT+1MPpM3pUmolzw+fuYm9szzuH6BA/YjPQBdIjCJesvUKeZ+i9kYBUvJtkrbvaO7DuhLhH IdcW2Kcl+f29tHqrDd3nE5D0JgWFIk9ULv50AhYvKdDpHuhszhMbx0TpTUVOVoBFik9TUA2TwR2I d3zPCY8POcU0x8XIDgGAalDIyMAP5LxjM9INkY8TBwnLjg/NzQCGSPIgryNRapOAUoiRSMY+33iz MhGOTpEPT9ExBuenU5EOyI5JDw4CdI+AUW/RQERPxFLRSM4gs48mDo6TPk1dkU1R/Y6Xl2EOKo/H EAW1Td9Oj9OoKxijK4SMh8CVy+MMBosJPHfWzPGfL+zFa0/FzXpS4o6UK32CEJW9M0N424F7bQZw 9yEMzAfITxhklcOPUIz9dgidFkjJCBaSAANGxYiVws4OfEb8lw1fiG+Z0WXOyQRSzTnB0c7sRXm0 q/RbCc4+uuXNiJKdgf7G+lpkKRp/KVK5eZV6wgIs2GNoDPzJhQ9NT03I0+fiRR2PM2DLmDAH4anK q0iI0yyv4mzF1wW71br5wjvFThENiEdFhPpGe/wTz5ET0Ug8Y75fPTGIhN7LPcRNTxLVBE4NTlK1 Bsw60wDUvXxOpQZ45jhJeNQ433ghuOy49/jauOn9fPzdb/jyOIGB/YH5AYM4Fnh5uET4TvgR+FyB p8HKQZQ4hbP8/CJBLME3QZp4pHjvQTK4BULHgerBvUNBAkFVvDz8/MEQwbtBjQGIAZNC5kFgwYmB C0GdQiMBGwIyQXwBhUK0Vzw9vQHDwgSBTQIcQckBS4HeQh/CGAKhASLBI8u8Pbw8wTXN9sK3wrDC WcJaAqQBLsH8wUcBa029zbjBjcFWgT18PP0QwQQBTsEPARLB3MEnQYvB54HdQd+BooGsgTWBG4Hv wXz8PDwvwTLBQYKHAjRC/kL4AbgBA4LVgToBBIFRguXCpwLhQsNAXHPawsGCeQL8/EcPi18iRrxz L9qz7J6P1N4YCidSxMseTksQjMK0wLzzQZdaAejkcPXYJY2XmcrlkbtX7pkBlwx/h4Zz89Tejktx btm1LZ6OlN6PiRwPe9DdDkuejMG0R7yXZYH38yib9t+JnIGQmcGNUJWBPo+U05qpPDw96fAfz9Tf NWEUCeXU3k5LHYTQVcGrAVCRzgaz7+juWiWB15k3o57gnJelgZdP+pX4q4dLno44cm/uWTUhzoue T51gkk0Q2jvLngK0RrLxZJDZwZe34p1gk48BkJnBu1CVuGuPlC6ZRXJomjej3o+Lnl5KZUg7Cx/P yxXBPam8Mu+Nl6WB2rYinqCZwZAlko1QzLgeT7nX9Ecx826ZlN/Pi2whXlWczTvLX85XQjTHcfJZ wRAl5Deh1KeXWcGXkoSWgfSHi56PuHFxrbCilI+Lno5nEw/70NFOS15M+LSHsfPQmUFXqKRwo5jU gZelgaBTz7oWWYHQ2gJ+qgd8n8/L7yhoZHci38uejktUSdyIDXnPyx5ODHi56gbZwTee/OjyriTa l5mBkPVhi0nciAFQmcEOepfVAo550Jn/NKno8++eT4ue7VpwtiHLno5LHUrnXBFPD8sfzgR5zb1q WcHK3oBFL3Jr5JDZwdew9aFei6DBkJlBk0hOuhdlgdDZzEJ/vWoej/nXBwUr8yjky5/OS1o2IVSj kQ/U384OOcy9wFnBUN3oc20wYy2Q2YHXXQtgpdIIwVDZQQ15VcI+DlTX2SnGKCha9x/P1N8jYRQn 09TeTksOucN/K0cNlxn7LvPumfbhJYGXmd2JptKPl6WBl3vQg/6qhUuejjhucu1ZLCHOi55Pnmen Uw/eD8ueRDlWg/8Q0U/LPasHrvIt8M2QmUEiXkqczhnBUCWXA380KR6OuddG/C8vmuMLn8/LH9Qn Uk35DgtfzpVB/vQApYEwnjztrlkiXdeZwVCgnAh5jP8L7lrBa0ctMWnwj9TfzmwY1KfRX85U3/vQ A/+016W7S0A8bf3t2XXNkNlBIlRjkgQawdDZ+Ux/6gYej9QubXFksKzYi56PixRnU045DAHK3854 KsUk7rDlgZDZI59U55MXpYHXSMRQzH9pSx8iAUVk72TZNs6Lnk/sWJ1K5d4OS55I+1aBtBAlgcpH JbKumzaYzZCZQdRJZlMPGgHQ2jtQVQE9H8/50MAFJHEk9kufzgui3qcSjvrPy15OF0K76gfZwded m7PxLVnikCWB113JZpFOOfgQ2UFMfqoGG/LPy55Obhrz7CHfzouf1KBl0Y0LXo/LEAw4fcAkc02X GgEo5GX1IdnNl+WK5ZHNepBaAZcQDI29wOTLXo/LsRt1HsnczkteT896jD5p2cE3nvyb6K3atZfl gZDh3Ypjk48B0JnBRHmVAj+P+dCadMe8GrGa3o+LnnesoV6LlN6PiyAlUUTQAwFK3844K8aa8Vva AdeadViKJsiX2UGQ+1a4agWb1N6Py28ZY17K5s5LXk/RRJcBdNnBN56BmuikN6OX5YGQn8qcT3qV CxOZwXg0h2Xy7s/Lnk4ZH56J09/OS5/O+VX4fRdaO8vrB1qzKCQwjZeZwSyYmYmmmcGQ5ZGOetWC HqOB1z1AvJlvmstejku3Y9gU4JPOVN5PzwSQFcLRzktevipHfPBo0NmBV60ad6wh3o2X5YHLoOVS j1oBkNoEkEwBvR/PudDAvDBx7pvLn85LcDUhWZWcz9TeTggEhZbC2ftLnr9pRXAxZNDZwVe34xhL oNwBl1nBiI2QjMGPuFCZfupHsTJvng/LnqRwdRjL1N5OSyOSzVbCeAG3Hs+HgHezKNtZjZDadyJU IZIQ2cHXTrlWw4E9S58iAWlz8y/bNo6Ln8/jWNRl0V4OVN571gK/q9AlgUpAMHOu8GyfwdCZQUpm UToVD/nQ2j4pvHfvm95Pi57wo19KnMsejktOOcy/NEDNlxl7NvOrmuyYJYGXmcugk4+EkOWBl3nV g/h+gEse4gG8du+bNzWOi56P4lQnUQTdD8uelwJ9qjwQmYE3t2jtWnYh3c2XmUHKnFFNkGIBkNmC vaoG9vLejguebvCjWMqU3k+LIY97TMF0AbDez4BFdaht2VnNkCX231TjkhdZwdePulW46wCL79mB Bnx1KC0ljoufz/ah30qhng+U3k96Fow40NHOSz3pPLHy7pvB0JlBtqNfi6clgZeZ0o26lYGe44GX PamB9e+ayx6OS7Zj3gvgks5U3k/NE4M/KtnNl531M+03op6Q5YHXSuZRzXoWeBDaAUJ/dAZsMs/L nk5tsJ+eit/Pi5/lSE77Fndez8uBPQC8LCjugdCZwVu349iUmYGQmiaRRDmMHyOB1z+qQezxZMsf zkuwNSIep6DP1N5OJg+Lu9DezkueDPi0qUaQmgH3o3PoqZr24sGQmUGUZ1KOEBmB0NoCfqsHfJ/P y+8jcW0aNyLLno5LX0vnUwhOD8sfzjtXzLhrWcHK3um8LGj38BCZwdesn0lmkg4BkNnBuVWBvWmP lC6ZRmNomzei3o+LnlRJXIgECt/P1NDCPipFIugNkJnB27aYnYuZwZDloJxIxJYeo4HXAbRD4vNo y5/OS2QwLK2Upo/U3o4SDxeQ1dHOS16B/al8ou/QmcFXWvZinonTwZdZQYmQQr4pD4vv2Uaicu/k Wd6Py551H0pcyAseT8tXlj+4NCnNl5FPPOGvW/eiJYGXmd2JnM+El6WBl1fMuCtA/Isej/ihcW4Z NSLOi55PnVWlUg3eD8ueehZ/visQ2YHKQGKyr9s3n42QmcHdYKGSD5rB0JnEUEK9Bx6P1C5hchus WMqU3k+LI5JOetYBO1Tfzj5rw4XYstmBV5pobuRwNZDZgZeiH4lcyLsBUJnBF0K9KQaOlN7jmHNv Wzcj3o6Lnl2JZlKPCx6Py0Q5DL4qPM2XmXvY6Fr2IcvZgVeaJhGNEMyfIkGXPimBmPHty16OS7Bs 2Armks5U3k/OE4M+KdnN956F2PGrmreQJYGXo9+LY5GNAdCZwXpWuHQGj9Te4h9vGvXey96OS55l yEWVQRDSD8s/PQBfMy7azZeZQTWYZ6ecGcGQJY+EUMyBblmB135rRzzffYueT8upmndi38vOi15P oE+NUAzaO8ueOKtGX/Ib11nBV+OdIJKPxIGXpYG5TPjqfE+U3mJecaSaNuLej4ueX0pnUwgLH8/L RPoWgbQpwZeRT/yfsa33I+WNkJnYy2fSTRBaAdc5A3vqxR/LX8/Lr9t2Yp7Lz8teTiZSjroW2fvL noG0qR7z79elgVekMGNYlODR11lBT415A/k9IkwXmqoHbdPdLkXO4wq59VbdmAXLpt6Pi54Re1VB Pg0dI9JD3TJAwDw7JTn9HVMfbcd4EkjJDVGJEzgNGQm9D4jPHbhP0s2Fzs14kRIXEY4Ib51pyIEN SM85To2NTYiPgK9xEBtBEfzAPw2O4vLxgqbJ/wnO0REqFtOUWeJqDtHAqgjrqhswyVv9uAWIuEjR /I5Ij8bNfFEv5ASSlziOyA8BKvjzDn1fWg4JzQ75zlG+zlEOkUiRf+JNXVKchc/TI8Ea2Z/wK04O DUiJEU8yco1cT1IEUQ9R3Y0OiByOBFF6m9xI2s2H1Xq4iYULCjxoDI0JEVFDD3hNjw5eTSU7iBs4 fgiSm8X0UkkOjekb7ISTdc2ED1FCg3uaW6eeIqrGkQWSjufsYxrMxKmAjUlNKPV7t7uua89wBXob VLdheHfL27gTj5dSr7KPIr9Ajo/nDvySEp3jjuhOj7D0qUfFElqLj12OEjnADZffd7h7wN8SkduO Kvs0r7jY0JJQTshHE9qJD3W/UxLmMA2IlogEEWnVl2Ab1FCqOSn0ezHaSC8PEo7iwROPSA/OWyXb /aCBwQ6RzQOle7TVwCoRQXrkFq7yDLoNmsiPrY+4gEONOk10m9vrEKkGUbpe+idIiLtQTX77QHp1 9GCDWOxqhLZqG79p0FCZhFo9MZmMUVNiomAUA03Pa7YOI/vnMP+AwwVTjUuIT1ucF/hRAqog2g5k TfCT0QJlYuGvok3wvv50kY93ZQgXNlLSzEDHBxHsvvDCnpUSAgR2Dv8RUAEOQad8EPoAERG4BXtH D7RFPVt34XZlSeiMz/Dw95clJiNOmFFEPYEviADSkVWSD8cROIcVf6gHn08ZfsDIDmfhxHjQPhrP cMEdMIIbq2BNPkkchV//C45N6cxaEoMDxchgTcBOu5Sjevtdz8Z5NmFIeiXVjYfqD7PnB1UrggfK KXiU46aqvp1kNcc3ZyqAXSYNRm4m7QSyqfRRkydSFhkRWKARjwAGJmwRSE6SHuiSSWIN9msR6YsN EgiPPBQcEZKRnur/RsL8QQjOiHyPTdXHHgVQJWa1D5MrG/Akzk8AK9A/OI0GiLGSlC6/Ns8qk8CM gPoGB4GVRSbDgK8/dY/nLv8ktZ3FKRPRxMDToe8cBIfHi+31Dt7apw+kV4AbkmwGImbEA/BPjWuv v33Ej88ATk1RefVF2BSODsh4By+EuNoa3U6/B+r6bDiChJFBmPQLUVoCUdIsBECdgPozkYoS0UOe lwbQr0ap3Yg6kiIEIEp0wIeIBmyqInhSPYxtlj+c5n5qDbBECV7CarsppR/RP5/IDvZBHxHcEXOR cMTgXxYpz8ZgpUHjDf72I2Ypc+FGjc5TdJEKRtqO+uKRSQ2gmA3myt8FgsUVTVK3oVpHd3CXmzKC tRBjxGeqT95ArhhIykkgPoZRgxf5k4ppzw9Qg5vO1zWOTs1cVQ3r0H6Xv5WwJQQNzreXas4BPYxi JRzT6um3Ph+OmUH0OlR/ryXmQDT3q9p1rSvSa3XlFRSYlakAzwjIu+O30Kw0QI1RPile9evNK3G7 uAM4fSo/BVU4B9hTjE3X4EIHZSBECNGyf+/iWOGIYI8S6qQllytOf7GiwbX75ytaUj8IzACMV6FC grM/a/7ojYB/LImANbTl0f4K9JpeCLDBt6E/1qHOeIRRJd3u3Rpyw1fA/nr/mTRf2GXgy9m9VjtC VaSKOf3zeAF2wJEREk2IzXJAh/iL3VAfU0E7ZXsJmsC/WalNj9WxCvXUjhk/6zhwonR4OU8MD/Zp B7SeXfTqwPgz9fpAzxwYvzSYZ+nNY4666qJQnjGCT+nRpzRiQkcrBHfUGI3QyOVXAMF6VohOELiu Y5HEjQEl4MkRkvBpeqVqhADiJoY5+Ki8EQvg36H6XX6JmZPK/VN1j2kzKVGTe7cAbAfPTwuAsISj 07XEx1IGUagAzqUJuYj2I5kb59etwDe3ki3PICC6/0n6xQ/dIgrLgEvWDWcBjckaQRx0xBjajuq4 wKU+ByQExzO4zo4DGjE0Hpx/QwnTzJL4uzW26SwA686N2DKRvq+9//rXjRl+Gq3PFk6PJCsNk0kl AEuIQs3cp/G7pEfFdyqOzXUkM38BT1LvRshv5ruvrscN2EcPLZR1i4fNOtreRi3h8db8Ks5Aj6Wd ED4FmRnPpcWKsI9NbKm55VoGes6lgN8txlqYa1KtgJc4jmPPSQ8iP3T9Did3gF4Fkmpz6pawK6lh BvuHwJ3H9803gsZbq//3xpX1VXQLmlceZAy8MSttp8Y7Kc5dz+wdvbvTyo6SyJHZ2vD97jiAlYdA 5c9BxvTDnM39zuac7CobqtNNx02Rbll+CsMPU5ccKbKJvGpIezqL6v9Z0oHfAOMtCNardr/VgEvR eH7DihhAx0078KvF6p8kau3NPshNkAANDeIBgeSv0cT4tZs0g84gh8sCAI6QthKS/n9rkValxYJD DkSooruyJIue1gbfaVYi7lTFLId/jhpJgalHQ8hRnH85j8id7pEA9XRm0duYYo6c/VFOalLtFtyA wsCbE4Xh4n9EKUcACENRP+RTj5GzD76+SYRFrQ+G7CNlNirpT7BATtQZq2jakfUDjZUA2pwCZfSO 0E4PfXp7zjwOE87hPssp1Y7Ikjx1ja0OKqsAfc6PqrBHvcQG6EWY+adcexTLCAHgKWuOjLZuBvvp qmk3BnrPHaqDSQq6NCWf8ZNBHwRRcRffKb5wx9ytp+gF3dr/DUEc9alFWt6cPeiEjg8lvfMP4JcR wbRH/siiWw7L6cF7/5d6ETEq+cVr6g24ihRY/cuaUk8rtLA+y6bxANHGlY9wAtHOPkAOCE0fQCfR 3ghvmyXXx2KHzRp2k16lTjq0nGSpFXg9E+nAyBkdvdxbKwgPTGl+uj9YWYUqNGaK/09qyPre6eNN rQEFubgDNuFONHu4TX3KXMziuQ96uGQaK1C/hY7bC/Q9E9jpx/6R9aZcOwCJjikPMFftDlFAeDrO o4SRg5y+gNiH1KOAGatJA5dAP8BCHZgIxf2cB3JomxJEJde4N49WSCpgOo81dEKN+6JPjjbAwayu P8XdKYcqVWqafx4I6oAP5c1sxoSIY/LTKruiPQmpef8Oe+EKnm6xkvW9QWvGwSmSqyYc/xvrQ5HR MBuYug9ww9RV4aS2zVMN0YexDE3jnV8E2ugrEY5dCpFAkan4lYqD8jdjqYSInT6W4sryKUuqr0vB xyYg//f8hUWnlYCn/qXJ46pBo1dA2KKAj491aUz7O71EBdIgH5ov0LV8f3lsV3jCDxwUpSABHpXE 9jB9tebEx9Cf2o0RTc3P3YAJjkTATmi0bm2nqkAcTU2+T1o/SyuVSFMKRKpQdt3wAXHEaA9XgJLu CR/bwQQoAV6n+RHVb6nyiJ9D3VtBDtPFA43UEb2sA3ihgBpiKCyCdU7qIBRVfAhzzJBipVBgySnP DUq71Qh2G0DP6Unk0lwXxo4qYRuAZQIpgsjRB6XpLEJACCduD3wRwCuFkcQG0ZAAw40FgMuU7fBA tA0KsCQFaExA28Vh3/IOiOHI0ghYv5ZuA5K9gCopW7bCUhvBOa2DPyz0G/6RzV/MjHidiXEXIVOr TckrjXxPOvVcVOrqJroWWqrQNcLsDyHAwT+CTQnOTJGPOioVWMMn16k/V3gjfaiA1lPDmrRcQE3L 4kdNzZBSfoGRp4fNiHCflAifko+EawllE+t1LFGW+uFETiEf19dm8Ptdlq1AA9V4bhCNEQk6RN0N OYVBWxgNa8cIw6CGzS9G9IjHRuQtRJfmO4eNz4rDCqDftxLs4DAc2oCDvsc/jeHqoryH+MHqE6oH FY0b5f6qHE8sHY1pjUOKJnQKWibt4Y44NCFVBpoJfqd9peN1juuW+h9C32mpsF2RsEfe0Mt1E/uZ TD8I7I9djQfg+D2Mr4+svQpANs/2EVXxhK/OyNXSQSAuIXCEckhAUmKiTQibKe0XQRRPQHA4MWoO ggc6wyBAqg8COmWRbcD/uG3PiE2A4mdNKqkQ5cv6jXoSm4CW3WBjBL3gkn+cWmpb6SwcICz7Ke09 3HRwdIcqmHyRKjGOx8/Ht4bXe2dOTj5Qnlw7/GPd+tN2fYGuNHo2OLtDKrZNb8hWh7t/z8d47YCE rrZp4Hb+ajkYaj85Kw2N1gEEPUeZ+Pt2I0HSa4DHCG38Yillxv5lBx6TxDoOpX8CsdC7wmu0qkPY 5MmIi+rAW0kMKwJWnj1fzMeDu+ID2WTpzdMOu6dNk4hGrhdGJUaU4nj3svXwznjUq3ZIagENsJeI EWclefq1bE6/B0QHceI0SruWWVABKhRQ8G1upk+3akJ6tp/1uMIVLBcZVt5+bHf8D9JSj5JAHfcw zJswz/PvgJ4IjqURBCo/e0l0oYwHuvS/PDhWmI7KAkSTsGvqYh2MbC2Mz4E6Cp0XB4HTzcUPcCY/ /41GhSsPOygQmjORUkAhS6fCZc0fWWqw1sPJX1HPquWhjRfKaSHhTjWOq4lNEo6rqNHHO9Lp54+O iIKGyCvGVsAGxLoQhI1NeQbz6mIBz0BPKqyLid4BCfQShumhiBwa5vrmxHV1hI0qEWf7J6shOAp2 +zzTkrVlNZhHoeVY4xGH6qxkospgeSn1DzVqcNglC42+/z7iyJfcXcjHy5LiGNs8BEd/kTWhYy2E 9A2OwxE/x9oilo73ESlOZZ1ETtyqwDlT9DpWGiW0k8EdIW5N4ulStMd+D/5d6fifB5ZnljaAhxDa NcC/+gTCPGVbQEfGuZJx9emI522t+pLZiexS/Ihz0cUYxLqxD155DEaUqIdLgJLN3t8bScblAMjP RYR5IjwKQXfaURbDWSxPTaRR6WV7o/jPqv+qOYRBJdoPDfR2rCAMSc+4284HeJuXkKD4UeOXdoe4 DtNAUv+YeJH8ObMc/mSdLAQRTI3WQQ13pyfFMSrGoc5Gc0AR9kFrqRJ2wEqhpRtwEnBrtUuSx4jn awuOxeH0XOjdTUBHmjlXSKblti3Xo1jh2KV+dY36D/v02g7Bj41p0UKapSaijSqOjyvOKj0DP4cG eY51FPzD7OlqpNJBDaEUEU4b2ZqKDc7FTjtBNkyi7VHSksWkQRHvNQMcMlJLj/4iapjCAuhNpeNG Zs+LhSwISEEFq7aD9ebj2kcsmiy5wnD4oAWNDw3szghyluY/ehJIoKrYfdqp2IRJyB5CwRiahQ03 itTizdYrP2czPy0qDg2TKcEH1HwdO/z9iQGWOnMNSBFAZTthTTQGZIUNtE6iac+qte9g5VbqaA18 F1bu6lU1FqJYeWlBDA22Dv8PzjTqoL4VPMbAp+XDZM5O86lJIZusnYimKjoAmB4ql81IbsmFYOyD 4H2YYvkh69UqWoThCRe0qtdf+9VGhonkwJHDgSlBzikNpdypVb9BnQ5nQxy3gXGpCXe14pCQKsp/ v5finelJ1fRYm4508s7N9YZVmECgZC4GdY77QE3eplZH70iEuwsq/3c8Ov/0JeMbkcMAze26j4b2 a4a/phBLBdzkzp+SuPZ3h07NeEkYyBhHGBJqD0APCjUhZA3XTwREUiTlzPy7ueebE+bNhSWqja3e /QWjUY/sgQeFHwzghjZxnMFk5/mgKpCOCNJXVSfv6XnO8FhGWLpsSWw9ooeO/KMlZWBidA4gdBW3 l6Nqeb/kVXoRqo55bj1gQwS04hHlx/hYtaU5hqlPiker4anrSetOeM+0RgaDyCr9Jd+YlsB/r105 SYZzlX14EVMOf4hkRnawSulNdaS8NTVI6c2BeYduBtb6gqn+T77qUUVeeo6SgzhmtU4b9460JB8Q 7z4r/tHQqqe/bpEMkw5JT3Bpf84Ns47YPcpEuAEHhnJhLw1dhzVOwPjfFpChzkLQSHFp3Q1rwa3P g+nOidCXgI6h7MterMacgWsSwGu6qcAUmCoS3FQPkM4DjnhCwXbJU2bBDkC+Up/Xx93rzOmVu2FK 3uDpnQgKGGkkQC/I+C+Z9qNPTvkuTm22anqIx01iqE6JVWtTO4hN/hiWv6KSvJkcqvAHSLWrfw83 WmcLiMDRyLiTVeX2eY90wDXFd9eluQ3zkfjD+PpkvyE+g8SqUg+HTgcnXFeSzs/N0cvnTcQf86oR Qga/KU+HQntRWPqISLMCTuHqxoBPpmipmBwBq/7FypOtjcORx07NjEa/hDkaidYM/9NPUs14yI5J h6mPOM/PyIunDV7EjujoIW4O3U2NWsONEQjm/YfaAI6and0WGY75zUMnnJwH4qbNmGycA59JtskS zuSWBnwKIWoNfh0fqQdF75k7hAGaIppP+0D/rSmgRIKHRCkOep/+EeoEPgAYFvuQLn1Kx6ZEQO7Q 4s3mnip3REIdf5x+T887t83ePKuX9UEh99bDT6FueaHGN9dnR4iOO9bsgLp0IweQ2w4JXFbOfAd2 veOAjgTIz2qaYb6bwGZ6b39/jMAzGBDOZQ4eCONx5hVLAE4jwanQbCqpbAjmYRgkTb9PbM2sCZDz 6iaA/xuJlpuvKUAhuka7B8DzKg22FgaxcysnZj8l0qmFuGUaSRGpwFo9uiKMZulAXeBHDYED92pi DeqtT6LPXVpBPWbCSAiSS39rwLT5YmnF3kqG/ipPFccOqWbVdWclzDCrsaHy56UUvmnA/jV1u3OB GSm/a+xpzcohukb9j0/e/D3CnM0H8qSX2lcIIWuqd//TPj7PNHWa30jM6m8p3I+lj977kp+m1uV9 PgTkpw7/K7YNKt4gXTpAMg1FV4oqVWmaZU9uzhO0UuFqKWKMNEhNlb30VT14wDeLWP0LqwXSPG2O vo2IDhFAyoQaSUUp+Y6ou8qHt+tvjggNCgTEmHB6nyVw/Z7vs6q/wCoA/R+O6qMHj49CFxAISka1 YGnh+xO6NkA172kjBRY1gawZquAn0EHYzo7P98tEh81PfcAQw6AFzdo+IE7sdFBYOhD91Bp+KQ0n rs5BVfXwRmN/n8KMuJPbjgdRTQhGo1y5tACYeGDFScf/uyuKfFIHzf7FuM+5ZBn/wYEzu+E/+Wuo 4+3J7H5W+M6dkg7H0E7Fws5KoGF++FgqbuW7FZlcqwS8iG1+/AR9sp5NRDuFdx0AqSpb+40/dCrq hM0HNKopR/3OU5LpgNG0HdKpjw8ZacuJDoXXGEkd68gUwrvRUTkqP6vhxo6rbPt6dVa6iqpQXOer oWBOG5JlJ6XJuenJqtmNyCI/ong0TalPQE7DIIVStYRMmfeS9cC2P4vVcRfKISDEKHsphUlsFRGf KoaGU3dWI0c3hEJlVCvjUTk4BhdKDBE3KgfcFTgO60OAX0QT0c1AH3DHZPtCeDT0DUAAjw82BAGH AR+IaOWB+pQ9O7mTgNdNDJwGdIg1S01My8S9T88ET3m/1GRDsYH5RiqGe20/LXuSwGkP0ThNjvhX hXNAqoLvzGMJqOLMHxf03NJdaqyVGPU8To7SPdeIuguBCpnNFSgAwHiwdWb4j6sBjZYU2rQG7kmT 7Hj9OsMdzUhKmgQrIlkPNEZZhjkNz0xEAR3NHhoDmXmp0U429SQpv7VGdD/DeBWFGWSBETQ0+E// Kc658gr53XoqgIfVOHSXjxMcMXBlPwHRVoZbdRyWlFzAr83mLVayFdruemg8HzHHvxTNAL9ifQuP 3ZrBZN3rYU3XZ79NKXguEEJnR+uITpEICAY+BtuA7yUlHa2S0qrVyTu/DT+pNPQB/dPNEyObNgjG k90qA3QuDdADzVL2j7OUiUXggdBl2A9GftESR8vODepjQNcAwICtCNqo/8A/DUgGgp5reAkH8xhp Y80fQEr0aXt6IA6qwM40vTR69IdfLnbWh8Qb5JQH3fLCO9BIK8Jpj1BMFxCb1KSiaU/SxVYj2uEp 6ID/H4LKLcQN0QmWtQehHLaSjFrcC27S/7nROILbP0pe3kL16d+cIeaXUmNADU6NJb3+IFQ6NQ3I GhdtOFROIV/X6j73BVJ5SWyhi871zDrA+9iqwGGJhVfG0DyIqoiL5iAqPYCBJoWYDpMA9EGQbEGl q8gNPYRKR3jMWVEnAmqSdOlneI96ncIpyr4BBzm0F2EAn346thwrrskw/TvqJatVIapYKUxPv7aD oXjxOzePdGqOQJuQ8hzaFlPpnhyqCpDedKpbJckljsBXR3JeWkGiwMA7Du8GOzkOAFelDWCMeMrE GuG9EeoU6SsUFto9jIDfFVcjqnyLHCblSRE+/vOTjmXpxrAD9a4OCTdNzZumuZhO/ioRS4pVPSvC 6qyVoubLpf43zINwqTVqzb4/gA84+B4lnt2IfEDO0DrjTQiBbIBPdAdaR4tOCziT9hTBXgG0FQP4 FniRLEBDk+hMzRT4zV7uiQU/h07hlrGVhQnrB08EbR7SgirEILeYKoINh7Y7bXaZ+caaJ7jUqcEA QEQl71Y2knjpH0XIOWomHQ4G1QWKH6pT/0ZDjHHNGNXPBaTqRGogC4QBISnHRfrptYMAOC1NQE8O aU/5ZPZBVhNyqSw7Yf7F0rU4kkH7ymS1uUTY4YqAvy2+88X5zwJJxM5Oyb/OKf5OiFNMxGYFoAPb D/SoZp1BBgDaF2nH+wHpU3WcIB3l75PynAJUDGLpp8nGaf+TLfW+ztD/zZrYkkD39QAYDXip+Ms3 oGvRTk3AYk5SbaKFD5WqzRLl/HijDs34eTAHjTZpRLt4o2kelwS/Cc9ap1YY8XEqjqxQ+z3+zEGL MP4Bc3ScHw2VO6CDr+y/+fTp+Om7vVfiqWfGFVvquQAtUAbOoSD1a8GN8QD4OgiVVYcih1fmSXl2 u6aRYWAdjsfR082FNmyO0I2XZAsLNw5z74fLiZ+bNTw7lsfMfqWWJwvc5Zob/6/qBAAksI4h2UA9 zgiSnf9PjYEWuM2LxWOcj8ySgaEgDN9dhKmC+NRpuKbXq/akhAdOBytPQI9UtQcHK4Trzo6KgOB9 ZueY5uWFZVZIF6xXyjJqiWLqBRq4b0FHng3nBHhJkDypUbWnfQc0SYGwCXTMdARAx7nH8E3PrAE5 BMZxYDHXByWCDfWnPexspjSb+ibM1wCAEcxNALjIyyw5taPpT414e0gijyZN6hUDB3bOKlX5FFq1 4NSAuAdqKL3vx85Zt/a/fEXRnS15Hk5TKvIRzgFXhxG5atdh4ruWdSUsKbok4DodAM7OJboaiEfS z3vz1APKiZ8yEu/hWh+DB5tHdnTkAGXITsf5ALG7UdGOg/fGxi2KIc1meY00V+ZCeHtsYGtEfL9N fcupLIcGIwDfqw6eNAea+IIpTNj1SMDRXv9nQd42oS2n/156hJ9H69uVRM/leypdh9Ami599HGrS 5viXhSep4EAGu1/Y72olVsFrjQiSj7XWRZAyQNFPcJGMP1uaPO4qko9FazfH/c9G4pzL32nfCcdR 2EC2U7bYadQONY4/88d7uQfNzqS/5F1kN7tTwEl2DKw5FfaOPhPqbGohz51qsIx5x44H0c85p7Ap v/AICSmZBTlT2cC9JYMlzQID94ztJYCCj89RGItbSr8EDw8ODwdFT4KqVEZTrXxBpkLDhyGhwjXK w8Dwv2j+0/UADBJpkVBoUG9HNVGHhoNAC368x87Yxr3dgPq/TxUhR5q3e4uUTxJHUvljtwAQ3cDS mOT0DS6OyEbHCv/pqUbJ8L/o5/aOLuMqYroZQI/pESOGFce/kGt3hFIIwd1HMYfNxD96TcfN1oOE 6CM2w860US9/R82ah+ROTnjbDo5EFWVlGTTMlqeYDdLkiFOpUYKiSRw1hFnqSelBtFoaqv4H2oEP /p4FSduF+TwOEhljD7S3gEhOdE4NOaFGQHtnGgf3wI0FwG2KEhbDB04MDk8+NKkZ04B5HhBfiHcv aSOxD8cLnv4ODqsHTNL4WwdR4wCBaMDMc5TQ5Q9O2DjlKsU7Q5bVmP3oxw1XXVIRd5FFQmPpLUZr 2DRAacjBE5V+wPiPa4a/KsGvzv/aXb7K5kNAbYswGbsgwPoDv5Hg08pAMgY6zw8rkmJlIjbjk0Dr kU/eXzSEYikpuofHDHZP0i9nnlyiBSpYmXIm1w8gwZNBtt6b3WtAq/9Rxg7DoDr6wQpU/x5fAI50 EQ9qGGDOcQhRc6lG9yMMyH4V/AlFIESIzVJrRzsRCJJ/egSWDiyBCAeBH6FhGG9h0dVnzbZxaUb2 zLYrNH+B5CEHwOxlawganwXYLTC4qTQCPTRtQI/Wbj7QDH95yNi7gXkzqn+1uqG827xi6cBDFZKJ zA9awCeuNvlPbKpJt1LOGiuy/476Jyxbv8l+APY+fZzv/Lg59YMpnwfVUyOPvw5qOtb+J3//Kvl3 ao4CNlrNUmCETeaIaWnL1/6GOjsU1/UQaSGpf6gGTXVs9dRSpw6GX1arp2XCDpMR9zJ3TgQJMf7F 4F6cJ4OJ+7s3xSvWOrWPRAba14SNUU15QBykaQH9i6B3CnLBDVOOBPR/PfxHIqne3BXg0b9MXnKc jwfJsKAF8Ioc6mcHwraZJJkyCqkA3HW5GGnYODHAjo7RdF+FloiytUXP30SpvR2/DlXNOYxoqXkt BLBywIkIydocOXY1F9TzC1ibBE2RO4+pkZimDvOdKWbEXU6LKS3pE8RWPtADOHugHDYdPgFoRR4E 2oA5jSNv6YR6uPcI/UQvEEHpiPi7BlplTsAnUqqTHyLtTgFq08pE/ybpQXpCo+sz9Y5O6scuBETO 8h5HMkUNN0GsQM1XgqBX2nuY3/8RHc84qiBYkg25hUO2tRbWkOk3BhnNFU7DI1GhKreGKU2CBn8E ienT68L3KZg8y45FMP5s+CpcT4FEZjmxd8t0EedrCnvqeQ8BxzjWrrWbsMvL9X1sESq21njcsClp 2czDouCgD2vzgtTYbwDyhM7OoI739gE6QS4TlzRAqVALLEu5Wwj7UejpkeTBBkRORFwaU+C3GPRQ JNZ6XZy0ZPmqHI4fTcdVMH/pn1/Vtypz6lMQvi9GI6ptDshru4CqY4sv2rI4xHfFYeOrq7jFNcVs qc7TlYdMl+eAvzqk/4Y5dlOJJieuA13ewRJEPmIP8A9MWAegzw0/Aj33TcMJeSUGmrnyrEkZwOar HrA7RtIzSOVAQbuxf+bH1s7JlFW/Dndw/10DhOrBDIemFvpIU6uatmssB091f0hPKSnPRqf02odT B/lJqgFH2Uy+KfRaVOoZOcgGdQRTh5fGOQ36qmhMlAJy6c2SDY93J06GpQDOeh+6fwQa9SoeSnx2 Oqvxgml0dmnqCONqUctTf41og7QKzxkFDSlXWv9EZqoBZZdqc8F4xzSIhzw5M0YqAMFKa2dESeyI hcAU150BtaAGwWJrB95OKceqeOkPl5ohah2aT2kI+j+fkTWGh4/mvQ36V1lYqkAwic6O5Yr2vqUq 9bHAFzf3EohTTmbPZhfrXwpIQc9whb45A5rn3CzWIPdqDS3LGNkNnJtNk9tFmgGP/+uhwSXT8BwF ah/ItHUJIM2BqpdwCvlfDt0s1sy3szQNnZk/BSxNhsEIBukPorvHzbInoGuEOM2SAO8cicXH2kFC EFfPFbNBggHwOFvrPafOxrkBGrRHY6UKKkjP2losWOmOwvgD2I54apCBcOajD80Oz0MOwlSaKYG4 kAopYjTPz97/QPrp+LgKtb2Re9j8rI9FhnlRFnl7Hrk7PqS7Fw/O57sRFZPF8LuWWiu6dIQvR/mP e3uQcGX4N8nWCtFVThZdFJBT5c0L7cXBJYYayR35lbdoAE8yCe9v2sdOjrRJ/bjHNfQih5sPmOtb 34hH1ml0lZLCjuK1UQjRu6+GQovp1t/K3zuEVXC9LWoXk0G5+DuG/yn34wQCKEHC3KK6N7uGEnK7 Qqk3tBDLjTQQSXnAAAP7SwL5Os+4ZWz7RbQNPZtap0UAEICPTRR3Os5YIQ3A5avQoKKylgR5BrbW EsKPFGMQ0JeOBtfICuzXwnb2DBWB+eS8fbDMuUwRkbmOzsA7BgdI0MKqULoQrE44YahQG5OJxubk 4MzPgToE0QYDgalQoVvKR1H6hZmdh87S2DpbwfmRbY8Vx32/jZTxDecc8YkK5caiO5GFOGQsdBe0 a8eV1xmqD/pIxn35beC15iAkO0aq12yMpvjn1zI4I7TCXctlTQAqF9cfbGvw6vsU3uV7CO8EIZKG 6VUMWkXQv3LwvVY5+1YOCAe4aIR1CBGN+0UQEw6MOEWMEgYBnc2zoIi6qNV5fbs4+fg81cogRiA5 3y/gwjo01nkqR+rXwkfvQGIIq/po+QtsO3nBequODDTifBe1UdLfIw0zqYW+Ba2PzxNSnijw6ixS TsgShP169IXMk5m4ReFV70sVkX9/Q8Jap4/LJ/1LJnRXGXi5x4H8jijy/IdHPvr9tMXGEqr8wz64 TslF2exx0n/NbVH3S3/pDHl7sMVd6clt0yWQFTkQFZdBWYB10VRba3r/fIC/hbpIUoosfuy8M7jq nOVo8+XRe7oSUm9jLGr4c2GC+DgGyM3dhVGn57SftkW8a42BIwAtMxNIfgdB3R3csyeWl9YCwgS1 oY9ElUhoPCgk7ZT4M+TwMDw88NQxcIQsYvuEy9jUlXBUoBxIISMbm8QqgESUhZTU+LifnJqDSP0X gARqBRcaPL8y/Dz8XMUctPSgfY3JjgZBZ9LfPA0Wb97+uoDX2Sf+QLV9fDz9vNcc+b4KNo1QfOlX gIaVYhJ46qY1KqIszcIcSPpD5sOF/Dw9fOU1Er/GoDUIL6VskjpGhcxouZ/CAKopBlZ8j4M5+scG PP18/Mdqa+u9k6sJqognAMrgZXwqq72CiXhLwEidHQv8K55fpg+avR/fuBn9fTzMbby9dHy0fNKN 3Yp9vDNw1Pwz9B8jUxiYYD0Vs5V8xPxkm4rNRRC4PQS4vnKUNDe7IuI8NbMUnDw0fOjGz8hpBXh8 z/w8/RfKPTuUjgtJX9qAVr8xYS+SD4vg1f18kHNoMybGxQpGnMVltCI5AZT2JFgAdJFYmt89vPz8 Kmo+Imd6Y+oJvc7CbyC7QCVWp9w4xrnepKjPWSRwBRN9ZGd8dqlHRSXlR4+FfMGdElIrBWcr3OZ8 /Dz83DwFp0OLC8crRuqnBPoIJwU5lurG1JWmE73d0Z5+14b8Pb28KiPd094nYdZhIWqOlZi+iucS ovaPYgrZOiuscLCwz/VmPXz8enA7WjpZVsrFxQHk7S4tn3o4Ai4B+0DWgMhdpLz0/6hxcjSAx6pC tK/zvHEoTKKwNmD8g7y9deYGamMPJCakX/5s0+p4P57GxoHXw+bBWEG8SXM8XAbrT/eYnixmxYRr wo9l+hU9xsmpesEQziA8RPL8fXzJQpKo2fsiFWVmADiGMNgNRgM0RL0VoPnchl+9DBkGEJ6pfggh mNcFAv2k/b28ItDZ3/QagVNewSfHYc7KPZyjmnGHZnrlVosDSGA1vD2tFsbIvLYb49ouv+bcheRr gEVu7iFnqzaGQfI8fDzMXb9wc3Ixcy48smy0je0zKeW8myjbN+Q35DG3IRMb2qTaWlsa6doaWXx6 vJulBlmxcHGxcLAwfHZwtzb3d/eEip18dnZ3tvY2NiO29Tb1tTZstfY//X1u7GJ1rLUtbKysY63h 46gjYhkZouI4PRmjIWht4dhf2FgvmNjbn9+z1NQUXp4eHpRdXV3Zi8ve54vUwjP3otXLStTLymAK SjC8wcLJikqVoGBf5yDU56c4yux/p+Zmpicn5ucnJqZnfDiEiiYlJV1Zpebg4F3clFzTBYlv5F2n phOR0xOKkzyRRHPiyNsjBUhv8o8O6hKZjZHPyMAPLZvW42zISBdJ3YjPAz7T+wfPz43fT4KED754 PKwPqY8EdA6pBTyuogkPvE47zQROCYTPRPt4yHtNK85EejhERVBx4og6BQS8BPs6+x27+8Tds/I8 3Hs7uo16TY46Ok46+w4EezkFBDn5OWx/MK1QudDakRDXVRVjTefKfDA3TcNBXcLC+MEB3Lh/PwX/ /bzmL0V0oiJ0g5EqQuoGwRZWRQUyxy+C7AXxxbxyBff8GZm8Lj8N7HYa4WmkBsUZfHyx1zSMZsbo PIX9vP2sNSgs1QeMTqfbqbgY9FzHv9ZdqVlNQFXmRv6eRuWvYn+zX6oJqngEolzuPSP9fDw9OMAp FLQAK4OOMYZ9nYkcRkd4DA3sfEfm8MXDwfoLbS79Wzz9Gv0qODyCxhWlWsF0wSs/6rXEFod8inwW 0P01RkhcvPwpQAbLHDbWwIrDVuvhliw+gPGdB+l9fLjkHec5vUNEvikB/Aj5f4LlwBHukWWCmKmj w76G7Lf5n11v/F0cQFkWbVbnyZcB6q8K4X4z6e1V3lICJiO/b1s8S388fsn4Gdaz66VrNxjEfD2r weXFl0ESHJXg4L85MI9bnh/KXTkMGj0Gu8B1qV76P9dDBseYTsGFiXHCcY2OfXz8/RjYEWhsWHI+ UUjacXJfDBikw+fW7dS8CRb97x1zX8v3+HKy/M6QoZ+7GLpUUyOH/G0URZ8OMKoCWsVchGHwI88Y GMb4/AA8wCRhgCKlorAoI6Mjuo8G4+IjcFIOkfcVBmWajDn+YckOjoSbWEbEoyE4jLx4RPhrOIQu i5ulsWs4akVgxSVWH6JRBpPB/Kmn5wJrHMe8gr7DBzxM0HyrvIcVb/b/00Swr/18/Ps4xb5qwKbN vaboQsO+yX+dRwyAx19TzG8S0B4yeLzZvDQ5H/p0YQt/kdbp6n5zwsH/08e8vWukF3TAfpB0dQi4 ZT14OM6cIHQJfX28PRDBwBBRwek/AUJ/Tnq7yB+AlLmZ6sFCwjirBVcXX9RHhK/9fPn4OL5pv8Ih vx5LlqcUR2e4LII2wRMDNv187XUfF3HHUD7L8P9lgXu9g1vnlXTAPtgQfjS8PIVuwBEC/Xbi2tZA v/SAeHis+CrtgJ9RIYuj/C0a/NIWq6dyNJ3FJ+mbHuqS95Xsqge4W3uBRWjX80hCARF5uXT5ZeV9 HZ/AmjY5/IgxSWwqdBe3nTbFUcQBuPQ9wQ7lZ7c0PH19fEE/c6taNZY3pT1R4UFZYZfQSnb7qQ0Q aeDQgkYHWOp1vMjFQI+m/8QpxhRIruB8RocpPCLy7Mt2Np4dPh/0fvAevsAHWTph4zO3BazaK7Rz U9DHikvYxmkwteoyOMzPL6CpJYZ+rALWKzY8PWwo13TAfqC1ZbaKgYs618QFTQyeReCkIGOmZdtx I71vWCoH6NST5RvWxFjDzH2PtQeClyM9av0JBK9kaYWK/dS4I4IlgVqXQDQkYpH8PN78LjB+z+a4 k0wxP/85vpclP+/trsphpEit1kAW/h01HryPBB7FYW34jHupLXxKM3xFwUajm3S4cMelLDJVNbIE sgjUgjwFZ/w9fbxJBS1RXK3YkVXaN6DMKBhuwsRnrVMAYHZdwa7NfXxvrfvaj1IIfOXIfHlZ61wP PFbGzFsYSDbC9uEYPTw9OgDGCAxk8I1J3pIphJeGKY94PoaHOybFfJ9LOs+mdvl4x/MWo/09fE11 AEZ8AEMj2+YFYFGeGy5EMG9YkwSNVfrJy6WPg9JU1yxr4bqwQ67VT0D1MlacfbyF68ovl/KEqZan iEuuPilJyqMYkbz8/F0cNLACiCUl304Y1AgZRUfRIe7PfhfaRtPp7C/H+oxqDOP8S6VSs+15bcTI U9GoHJw4QtzcDcxGIZtH8b19aJB1BkTU6cGXIapuaZyGTrT+Va/Rn4uYOX28PEj+3reTkAHuOuOb YSm9gmkANKbC+b1clkPh/9QvgXRncUn6/zTmqIm1x9vFRYzmfKolR4Y4lKc3u9qEBPyQQhiNB5xa vUKRA7J8/ODQHYralt5dHbt4R93emjPpNYXOgXssrn19vX0Wyjp84LvfXF5XoZUdxcUpu75K9WAZ SEXHgT9W0LFlOjN8Rb3cVkXdDpjZRGbQ1vRAr8gL82fVBI7PPV1GRGrG7APcXAKlZqbnDlm8XN5R fufTjhIlR4knymCgjjldnf8RRBm39M+Drrm3IXQxPK+uru1trmKEeUqtbgN8224jjbnB+Hp/d5Ib /xtbGTywsPDjTyUefeF3d/BG1KU3PAqcM9NwN3A3HLe1tVUx9ne1LGzgMM+yoyIieOGYD1mpv6z+ cZyfHpSxHMr8QCDhIXCyYSCnZ2YFJmucZibOVeZ4JoPupOGlzRvYuxnTJ8Uc0zycPZPSarsOlEi1 zN+IFYYnPMDcybk5FsNDvHi5B2MeJbYUBwhDunIrGo+lE8VVZatMRSfn6zz9vMVi5usDYGfFwbWA a/7Cv2qgB/6NDAyAOBaV50a4nV3HxwOH/ocfeL2J5YPzvPzG4iOlxrhjpQDpqvSrPnRpf76gwYNW 4Jc40CR8lYLMIqVGBj3V1lWJEIOCPezPrn2sJQfCrq5HuHWjHIDFVuGPTikVfDzyMm0i/3cxKCgv ru+1Em3NG7y0beTk7m/kJPyyjkugvUY8W6Qb25sb91GTF8JZfOcmmVpa+8to4XBN93ZwPPDwNz29 pJM32m/33ViwJPd2cDC2N3d29rC2dbU2t6S2/7CyLvEtdax1Nmws42Mzt5gjbCMfhQi127Zk7Q4I o4iiIQW8rZ4b4d074cvi3yIYD51ilhga6FgZbPeJGKvmEWTT+uL8Xp4d391ZlAud2+0b/zALXZ0Y cB1UlGeRC5sSeGFLJgpfWtSLix8JrBWKShTFfMvJXkrNkTOZisnFfAlgYd2ZMD782aCJyWcd9+fh Ymfx565fVOVjo4u25bdhvz9HJeQlfFycrXeEDfY10zwS40/SjRFS8ZJlSxKRSNFVfEgNGBjKiAim T1xOnncMmAjlzQ3EiY2Oh87yss9FvMXFxEXE+zv7+aG/MLE5uflXF5GW+EXl/3A4PjxzDqz/V25H ghB1xsjYfER9aUBNME2VhgBFqcH76KvLgPPlHC5yEpDM5ytNISMwZQX8P7yF4ngHTF7dz9CAPsOt vEjx/H4pvUeLflFiDdPZVGZGPsuH1q3VsF2MkFW8PD1qyd5pRkOc6YHJMaOFpYVAVaUywVhF1/kq hG49vE2+3qTgPYZJ/Q438rhdvim9hu47UvQ9fPy/fMk4iT3vsAHe6ZUqgT8PgJxZ9sqCyO0bCL28 Pbw1z8ncfQwPCvRUteYKeI7HRGPt9occwZcOs7K97YcqTP0EvP0L/tAY2X6NJT5SX0VMtQ45R0mk hJYmTMDVAXoqfbxRasFRidXdrIVRAOFYdLj0h/b8/oGKldAuWZiveNUVHTe8/bz9F8j5cPIUbYlM IfVN1rGOaY3E55bLcIlM5l2XVX3Hv/w8Sjz8Uv5bUi1kuPEL/T5ivp6F/V4OJBDG4KYd1yTKjGav UQOFN7Wr4vwiGxkysigohevyMqgzMmkyfLF9Oo5EaGgvqKTu7y5brq4tL4Q9Li4vZKUtbVptJNva 5C6bZC7bpCRGm8/fiCQaxpokBuSlWbIDdYBzmptkmtswW1r2UFoVJnlYxsapPTObw/G+2/lFhdlZ sNm2GuZ0nbn3cHe07QdYY9y29fY2hWz29rxf9jvuKFS9fK12duN1tny16GytdtRtCCIsOsOyo2za YrK94h+jyS6ECXyiYh/zIqNhHodtngRYPNsFXjOiXSFYHTI27NhlsR+vKJ1YHguu2N9ZnRRL2rBj GsU2vB8eSdifk8wYGGYE/KeK4+AdPNYDZQ3mBObcXRPcWQu3sfwTVIbT3MXolWJ8XlzRU5zf1lIR fHOwsMqOzxIiTg1YDQRN3ns7y/r7TXPhRblQidCXZd/IiEioFhbf1uY8VpYd1lVVPOTIjwaVSZ/V vBVDn9V/nsxC3gzMp3Kw/RQMwxgMQxiNAx0NAh5MA03CTczB8m1oIkUDg0FfAzUww8OC0XFCeqXC B7yLPRvCPAK4isL/eQEBwsHBSAFQnQFDTzh/7z29vVn5+Dk4zEg/DE9//xl/f9D4ONE/A6V/AbA/ PobobRqcvRl9A/u9fV+1pqsrX6oBCSq8fT1rjAERaSoPx9YwR4ELhVCfvIceP/764pk17Hwi9Mo8 MPlGKb3G6geL5Qd8HGB8/FwFf0EqNIwg7tzF6SxWF0wG/4jwnfS8/P28zS/H6/8r9r7tqm7WH/si CO83RrhankANeoUG/GVZ/te8vXz9FDowAv136eaLfwwJGNnu5muMJoS4G5wdvyfQ3xBuiLw8/arV Nt+WNN+mqmgmGv+6iz1LCtWGldrp6ShAb+2aPb18RtAdUabuVjJdGfXAqwJFGtjEXTZD9NHy1qn8 PP2s4Mnel8r0Vma3jrFqzEM6G4ix3t2gqf/6y4JxxaH+fWPJsXSA07ke1EXHeOAeEY0wvnQqfwUK n7z8/aRVNeECT1sfhqF94H59eJ1BTYX1dmC0oM68/Xy9UBbdcIs7oDxHK+kOU1TNZbxXBf+pz0g+ oMbPU1tvXddhTrA3LX18PXUR1gZIm/c/gQbeD2ANNtyUOZ6Gp3mczQO8vbzVFMrkLShHiw4WtTW6 l3Ht3QHadHCx3S3s3Kx9vP043/0nhxWYbmV51QxJssq9TSb4757XmCcpHEVrVB5OYxiFnWbTCARQ Kdk6VjL0c0/qKH7b0DkOjk4H3jyr/W5Olfy7VcctjTqkvV0heIkNvj8SJfnrDGOB9biIHkbccQOO EUjC0QIfeVfciDyBj4PjR3fSE7Q0a3chUnyN10XAvkbi2pvavA38RsaTOfxv69/03dJSzTyRUpE8 VIUqd4BIoGJXM0XzPzS9OIGJv8UNy2+2tkcDQfRWkP4VOwb63IdQpNBOA3JSYgh5TYxRepDSz8Xd F03O09JjE4EIEUcF1o0N6USAZFjhjXw+nxfS2TkkYmqEAXuoBlLIV6ljpa87qsFWDpB4wfgBiG+u ftZUpUVMNFbkZWkmBA3rwbhBAnS+eanSa1vGIn/rEZtDvtWar458bAV40UGAOhwAh1Bqh93JEy9b +TaQkLl56WqtmV8Izpr01RMOT9bmyEM6PBUEmc634h8bcJ30lnwqz7nVOvFvIBXNy/QndNYox7Wv HBt/FyROPm5cLpY6jjpHJ4/jScA7asATb2LeTitEOs2IB/2UhywBSqECT9Wah/KQey0p2Ct5V7/n E5HfLk0qEA3wJTWeu134+fWJtBXFa/vj3Z7dtDJX35T8OYvE29xgoXmWOEcREAJDOR5xxGMMaUMG Rk/h801TzpFNTL14jFKDPVE9jf7yWMhes4jDNPy0ww1MRvunj20DOMaPxumRfLQNZkwMzH9b27Ib +QRJBHTOII55K3i/EBwHDCjf5ePA5rwjW3C6ryvlTqnNcLjw2z95varNE/3+rxI/QPKr6s/NdPqe jlb18whlrzlzv5YQutdL0dX5O9CWzwi4Y+lPeUs4wc84nPyaUpE9kYeWUNHMNL7MUpPNeKmfSSmX 65ZQlThvyCJXtctD0MbWUFD6xfRVdyNkPDl61VdWavT6jBd5QLkBNH6L6AVawz+0/06lRvJuqf5Q DFcAt/6Q0pTQOIkGItmTJLoHwJFR+ZF0VbCEDnyiOlKXBjmxwILbPv2mEoFb5sejL9L4xoE4AXvH VgjtAoOFBzg4huCOmwiHoDTqToiDWj4VhOXE0dmM4xxI+wU7QzjMIJR9f3mb5Sh4Ao2IRKHIIbLq MHw/+kPV1/m+TwYPgG9Y/7jTexz30ch1Ud1MRJmOnkG3xuORUxfQAkZUxpY79HxAk+Egckx2WkO8 AymmLgeHF2VOHeNCp9nWWsYHa7ziOig1XhpYDpvcWAzkg73WvPSOB7jjp/aN/BX4DdV+gSNoGL2S rIw4qoRDrdYQgi2X//wP6njGK//yuoamvNWn713PETSPSjvhVdlLu1iKp9V5JluUGDzpbKl7QWM4 fX2QTea6g0MCRvc7dio6ZI3YwT5GU7arN/5QENU5lkgqTiy6VffYuI3FHNEkKKkDmHmAKWrulNM7 +XMfZFoBCCR/URdnNCHA+xbIKVJMNrcEskaBBXQOjwgzVDvHUtC4hTjSHty4Ri95RnTJR8ll+kkt DvJgB6ey0h+4hNcq3EOdUAPSB1dhBmBRCKz5GtQ9iUMCdUXuDlSyBsUbDeP+xrAMx9/DaIVCV73O waOFyf3+jMOX5XfOtT0Ak7y4nqsqBI5uBxxh9AQ5q4e4ecJrGtGYBbgmgEL/Fqi75nKGuILCHb/N 1zF8jDMuwNZM0hVVhcK/7NO2RookvyP8PD18xDwMnZUFMjfPNvjNaqUx2FSTvXeWu+tn9GRY7Eib PHc8/P29OTsqBWyU+QPm2VYc2x5tm7E7vXs0+IZgLqTdEtKyfgQ8/bz9cTMCEBk+OiEAG7mujR9l KWxnq1fCb0rXdQTP/lACb5+8Pbz8xtgu7iV73diYgZ88qFErk5tf9/Vklv0ukMEexg92nxR8SOi9 W2hPcUKEkWqczRQ1gl/hw/3TO6bxzW1F/bz8PMA55Y5tsrlN54WISD9R56GsI7ULsgMcnVlVixaT T+lePP18PChyycLZB4e0IWVrRjIYV3CeYUiK2bHCMy08ZlrWFN7orCS8POCrKpxjrhq7aTv7Je7A /bVmD7yFkcjiYTlQ4KoIFBAVVYU8tb30JGF/fIUsUsDeCerdODi4JcX18OrlUIvOz0Lm5c7QF++k pgUhrtOtNmcpfUA/0wnn6ix/CB/QYfCMi5/Vkqr35A9g6VC0bHpYJEclfW0Qestw5xRWogb4ozz0 ByqZDxwSlkwD1hUitF/BwYHnmvGjPLmVNMGBrlYQSlEDAbJqXUPQMNdMVhfC0+19XYKp/sTWFpcQ 3k8vzg7BAXo3FZUoWb2p1c9NkKWm7uxEo206earZyWPxU02lmUHXckVB7EWUSycSENnB11GOVv6A BkufzjgBMu+ksCyPi56OoUslUwjeD8ueRBZCv/0Q2XvLqkZ4cm8aLMHXmUGinlSlkWWBkNnNu1eD vR6PuddpRfjzca8U3o/LbRtwtSMhjouej59dCWbc3g5LnlLPRLpQdMQn1BaDgw0sh8A4QRoBUNoG OH10a2n+yctXR/jzqK1/uJoAluVfoATCmu5f/7ikRdogOfk2JdoCJMkdeGMGX0v4JnxLatbReI57 HHF8PQOY+wo4RlJ/BECpLNAGCyrxj0agMTw8PIgywR7Obp4JDZQBpptAXeJbU/UuGaQmmlrK/5ci /Xz9fQZjExichvjirqC07OBNQONrcfQYjxbRIrKkTK3hk1kkPPz9fWtobRtPOSIl8bZmJaV6Ss+p 7F6IDdPyDbNr9g2g0LuFPXztqGnby4b1DMG8MQDGJ/Z0yIPEQA+T7cxE2VLI/Dw8/M7e2e3GA1dZ BRB85scZCGGHXXOeoYEPiuGVmvasZAyyfXzq82PfbUuazXskVfCHWps6gxnbm7hb/8w8ZT18PX05 3BAbdiqEcO2h8SH9vfWheguJo7BBXWOiFOJG/kYmxXw9vPzEIRuHNn2uh+Gmkwh4KddO+hhrTSwM /07iIMxbUkaIG/y8/X18Y3QZivjAWajn5aGIdaGih92trRRNmWKu3jeGkgGyfDylmPneh8qqigBt 48dPXLjDiMYK4xg81iUJ/FeOrzH5yAJPa318KjIa+M7lUKRyLwmGC4+dRSs1MUble3VA8XZ9fP29 GhjNEO6i6i+ibCAT5qJzpOvkjte/pCmxUxlnTtdZfDo8LRjoxGLXsL/DX6Nerbgj2QyeJNeaSpp9 vbzIzTWZna/xWpnILg+Wb5pIAdfmT1gwYgSk0fiF1Z6yvPzu9MXBRReHX3eTR1tDCIbQ34wFvwD8 Z3zLqKb0x3Y9os67oibIyBkO4hQtBPHBPPw9fDMkBcq2W/+9inBYod7a9uqMIjocR225w7ssIx+P o2z0/bz8/OUiKOMh7EsHbaJFyxnhkUJXWWjZEpkLaT5bgaaqG9EpX7w9vEfNLWWDzUmMjwiHHntP kwfwQK0LvQfJfxgSX329vOHVxxMVygDoWR4G5k5xvLU8dUYOe7pOMvCifDz4PdyIQ8/rLsagUvQZ vGQ7mWfE01sAN1dbj328/XzIJWPzMmmsYJUs46rZYdjELh5am9wKWdS1dRpC+bFkUX29vXwxz2Mw DzrfnmTHIU0QAyEWGz9A2lerRxjyV0XChJOFVT19fb12aMRlOuTPHqigCIHSrA4WZ6GE8+shjyNU 2Qk9gq0OuXxE7rxK0oe3BdaH3+Mrxtx/xvltzGP2/gCjYso8/D19BCE4BQgiO999GvU4cXChoBSb v2sYpfuYds0L/zLJ7ws8PDz83c8Sx4lPBR5GhkvMQ8CvZs8GUWo7vEUm12yKKVNirRi8/b18/9gP givjw5Qh2skHbdmt42lbk3Rkm8eZ2ZomlW0ZqLKs8Lz8LeTOyeYbtDdqbdy7fyPypBNYJ5diKq4E 1fy8x5NIiMA88MPHz/v8wjzsoD0VzWEP2c1yWTxPzTVP6lJth5QoGUebvZyfPPnlxZC17YYCDfke 82oEcBdWz9c3/X28+XfMlw/wGFs7mlvOQKUM6MwawnoYo151FSPknXF9vX18IRdvPaE4qzHs46e1 o/c4CmF53h6h/UbCsGMKB9u3Pjo8/Pw9ZDktD1q+OBOOYqIXTTXF6057SXgI/wNsgKEUIcc16ySU FdZzxTsnqIV/sQziRoCOJHFlfDDwFBWFPCSo3WY9jugFuqgItYerV4Dx74ECrZQp86ryvnwmqrHC UayMSX/vwio6/dQJTs0OT8j0SA5IBud758ab/3rN5SbeDq9aJgYAFIhNQMHWowlgKiS6IMwZ11UH Ez0qgnjVJCgw/bjQw3zRUs63sgAAhEOYP4jGmhxfcIhFBkOM1nmbmHl0v5AqQ42NlTcH6cd4TDlE qQdowGX8SLRmOPlIFf2MS/UTXYT9YgbWgmoEX20IC8j/B8bPJY+2bgd2exwfZ0EeJIcIjnQSJQgA PSMHjjP7FJZVs4hcMNeyexUa7kypwCiG8EU55aMzRBS5JAn5j43G0bZiUn9jo/2R1dIjhploCj6N zvYd9w+EK12/Tc/R7eI6DjjTFBF9WnFOY7oDPgiNrg7Ij7h4Rpr8nCx8wxE74fPADZDOxx3EJePo wo/I/xER6whgGJ00d/QOxtEwAmzTLU5D9EloyWRwi5UMCcwRidP069LH3BPBIccrlGrjQY0RTKor zWcvs8dreJxWkg1umoWRTG/SRZGQuseP43BRdHzm5+Ko62oZgE3ZPPlawGiIgUoTjVcNDv/rN2eD cKMNZTrYf44WjjVVOLWEs9aWNKhXX6W9ScjzWNBIOgyutSExExVmsBcJcg41OB2+m/lnUiOv5Xnr xBLMjnCnMFBcYo5ojU900K3HQMARBWvvz/KOvhEROQQ0S4IUd71hojbdhK2Qx06WcRiiFSaEkXpE SUSrebY0oWpc9DRsKodkB/TMVyyQ+ZX96640VhARDPVmH5wwJEpLTD16Do1EFeXlfJWxRYEXXS8k jpVNzPp6Ij1b2uxOhS5bmna0tPTCSGtQ7zXeqd5Bp+u65zjnebxMdxInOaENdGL721X4Z8RIawwV aaPeWKeQTUA0rpP9p38CaQTyAtYuKQD4pqzt/UHOaQtwZhSVAtR+pHZ/MabpLJjOvfa760ErwpaX cDLsSLT437RPfTbWUUvtQBJMv5V5Q+aOv7+RF0RtDFWebQ7G6tzNPgLTRj0ESEbb1UXLvg8XcByr 4x/V+nykTqzEzjFJgZcYMYGNlnqDgqt8vIV3ENNB0giOk12CQZHVglffeHlbPCIi+inNkpexO7uP gU96AQSCSJeOoxM+O4u810RB1TrTVV20VguL7v94nuTNVi9NJF2WEZVs7MQ0w6IlxZkZZc69lshD 83zjrg40woEBoX88S7c0dLm1x6qC5z8S/UPjRU0Za6y91ZEV+jsHs+lkljlXV9I6x61NiBA5aUaq xz4XMILBuwAeeGEmzGmDAhV1kxc8RgUhxOz9PvePOWjt6ZdD9bspdiREBVWMFc6GkUECekZNcWsI wgywh4XQ9DFLAOfqqnAHC2WJ7PCB/b4BnQkFKav78BT5+IeDNOOX11b/bClt6jh+0oO4knSMrLzt ferpfQYqUXndSEfJ/LQ8B4bgxcq8SlX0dKzLJYNK4C6SlC4ySEPLD6OGoQNfFx7KrDtY5drNDnma Kkvh1pkrQ2JqlGtO4vjDkRnfBbUhmIc9Xe76FQ1G0UZaB636W4JBR2lkP32kSsLOwIKWzhNn3t71 xVmRDjRDGqX4jMh4xHn6Jv/lGnsUyMUipW72w9FNkbWe2UC/dEM83SH/80wsANGOSYjBOMJ4eUV9 jvJ5XcI4QXhKknXAOu1BalEdIl2FX0d7RuXFGUyRe/kMqbzSuJSXYXyCOnqhEPrHeUFPpOuo3noS VXtXOgA7hflxxg5cVAiQlfoA1RQsjsz4WCIGu/1SFaP9Ant5lqk91/1AEYXGCXRqCUWFgetNPSpG zXnHEk291YaBhwF2NCVGh8e3NCYHR8cHbI3e4jxnnABpzXI9C6rHB8fHBQfFQ4GHBsE8gN0cvsXQ yn+UenEcUtdFNAVATEZgYAVPLdtcVgL4jjRANvDyLYVd5oLewemTVxoBG4wRwY77V8N/C1AZzesH /Mwx7k/Lng4bGbbj35/Oi5/UiSbSj8tejkt7EMy4NKnNkJFPxUyybht32cHX5eyhncqml6WBl1LP u9BMgXgQmgF+tGkGjDPPi15OqKTwteHej4ueHUpnXA8LH8/LRPkWg38rwXedT8CFw3LvpCWBl5nZ 9uLflJflgZCJ5pJPe5cBEJnBzEG+qwCPlC6ZRQxy7yQZ3o/LnrdsoR7UlN5PixWmU0jNOg9U384W A/vrx0QssAdrb8uXVY44FXqVS9zd5oNWEtV6QUEAgVm1QmEVVUXR+oD7+dmfPMQc7gdDlnr4+AeE ZGPBFtUkOQH7wbPg3bPBeMfVOXm5jDuCQZet2u2AuZW6AbiQAAJCTCc3GwzGk3/6JoR/AdPVkMPF kF4JwDNPILdVKdV6+roqLxfjwvkCxhBbR9HVb+G+FeI6DFaVbsdPkrhpkWo6lirhTLd3W/vC5KrA bpCIb96DE8WWuxDVRmFWsofuo/o/ANWBdrhqeIQbgnrAO0eGbAAaEYBV18dH6UM6Bkvv0Pl5u5v+ kgW40LqRkHkQ1qaVRwhvINUQtFa/BGKEF4TQvul5UMA9MT5inQ1HwgGc4mVYagAX+aoHTFAhVdH2 vvQHv7ZibxYSF5CXM5DREDI6ISLHTg6MxX2XqtPx4o4zwqqQldAV0KUBYN5Eh2bRl0WXx+QmcwB7 VbgWloxRmyX+IyqQtdBQnYEDjnYbSsGDP86GcoZ6aj+Af1UlUaFmV1JQjcf5wpe4jqB6A8KqVdAQ qnD7l17oF9AYUSokWIWAOMA8OWQN4P2WOblEljjlD1pr3/iB/0GPgCmgItpH69XWkIoC1x9PAVfA QWGK5QOmh1ZWkBbOVLDhfSuIL4TVhy2XSNqVr6yQlTkCcJJ5G4CAB0w6fk/iox8UNADH6Tu+i7id +W5Ba8x5Y47B7RUX+dTXFWAYYpCZ1lTAS/9CZtrNHxU7oWvVL0EX3fxrasBBJD+QwxAGXWMri+oH 1wy9h48KTgTQxIxT7Yllx0OQudBlGrRtPofXFXm5F1aCVhpOQCK6dw3tEXPaIxEYgRA6OhX6V8Ba r2IEFr9WUJDFc8DaJRxFxCME9MQ33NuFZJDAFBAAqyLkLdcFiVE1PA9qfPshHLTSO4i4BGoAYJA5 l+ncOXkdKwB8YD1dzS1HcTzFtAy8NTwrkE78TtggFhV/VAcS/8q3SIOHzfjRhuu65fyAARwwU7CR eamHf9x8Y0fAnAHGxWBVnQcAMgLqEOY2ekmXZ6jP+FXEjI0/zuH/GXQQQpsrDwxYLFeJi8EjzI8n 6vTTwPhDzVG/CIaSCI3rNDi4hQchzlGdZIcP2rrrgeuqtUPmP0k8QNo8AAgdLW3M1czX6I+5AQxO vMHhbNAX0OlElgGCgomB9q/GBoHB3cSPmIWxHnm2Bn4i+uEk/TnNEb7LamqYHqt4WXv/8XhYr2Wa T2wCdYKR078F4heGoKf0A4FDJFuNDBm819bDQICA7OW7U0NCRUhjV6LhmEU6x8hOi5JbwoWcmghT IQRIURHeTuzIg4n4RjiRUm/sDotTThHhiYXIECWBIEXRgQ5NCBalmMMISfiV6kcE9BGBlAVnwAZO S24axrxVMihu5J/P1N/acHZsIsbnjksYHhRC4MYIlQEOUSqOXCTpXPSgFHf4dcjZB6m9xN2eQkAr kebmhYW/kcaBIb4xMOUJdRYDA3cXafc5zQQNuHSYjlkMpMclhNAdaIG3epdEAXgQAAs8ODiIuOs5 KKuMKTlQVVBQg5dQ1gDOBVZQZMaXq9JtsG3qlVCX+dVVVarw6bgPuOzcaRhMKdUWUob75cVXRkWG RkKyRIyRw2wjX66FF84JDEyiDg3ubMdWzaIwWutBJDmZjRPgWf4oc8T2kbpjGVYHG2sGubxm2VcW IYIAzo9ggF5akYsFg0hbs4BfTQdn+4D9Rm4tpTiKRgB+VCZpTNVAPFyLyhTd2DztMQW8t4t/kX25 L5teJP1nutCcdv1DRz+MlUBI9BQfHQyhuQaVzLPBBrSWFbS+iJvs0mkl5389lbx/0ZN2W3erOTRx RSsaRyq9+bshpbrCfyiEPv3uviuhJAholz/GEFgnX9U1OJpeAhv/as/wvluWIbobZNzEE07V4i3C froWCB7lpPbMGevFAmFVub2WekwlxwUsDV3+qSEE7qHQFbz//+vVx0CmO2dghut6tF/rzxS6r4iJ dAmJttaOSkxdjkGjtPdi8wB+5tgk9O/PJ/uRif/VDBRS4RYhIn3Sm770fdhrCMrTORomD9oFZLv/ kkKssJQU6Bf8hvsqp4hgyZ8Zc2PrjzfqUJLGjruEJaDQnvXM12/6mWoGwMoipYVMPTe44udD8RSk +vyPWY6TURBcstfXBoU+AyMDWOLIEdwrRu3fTN2N0Q76It16FRBLbyiHAIc6gQFrx3311X87mvSW 5krblAh6dBFxByOzFKZOSNPO94h26fHWiLvORsz2+Au5a8WYDfP/N4NXOtcb91BsChel9CqQbAC5 nPRkzBcmlSYj97LSnIQq0PO4Nn4RRPcqCrryckc6e+lRvndmi2lP3A90UBO6wWMB/QpEa7wf1wXK iBeAqCdY/sG5EXyN1Ng9Y1wHWz7ZSl44aNA6x01Jn3lIdlsKeZxlhBYXNM0Fa7rgySmXx7mm8IFl 06c8S0wlFniWk7s3szqsKuvoufQIFcUbkXUDHVOHPO8Hqudjc/17vIa9n4iRCNOpylxmBbsWzDk1 ELu9JOqQBTyF1k+PDblPyIkXY0cRPB6BKpZNEf5NkFBkti/AlLNV6e/MepX8lghOSIC5vSf+J5FX xH33XtRSfFUSz87WHhwOMg3IDU8VrCU8kEH6hSgGUKlfFVMpiTQ+DlAuzbiEjngVkkSApE2HPrPV UusP2u6X84hOxE9Q4OYmHb38+cere2iFXYghekGC+YhiKh+zREiRzsiR6lwp7ubtOCP/UUIuTg9W BQxaBh8C1xEBjZWnIoo/ErYQiN9qI71gLs2XAOskBWp8gg3Nlw4NksTrFeeN6k8Of+vFJr0vLUXQ e4Cp+cz4EUlHjKiMiq1JlukTMztFUwI5Fc1PzUDTePoHR+wrBv4jL7PvEXtWQCp7IYzqv05IWL43 NchIk/hIyR+XJljy8taD4nEhos4HT5ONd0aqugpAJT89+1aO75eiT2OqnoH7Db/WHHlUQAy1m066 0avWeSk2abfvkPZ/any5zkaNegUMG1G5j0hGD3Z1W8ZFTAYNfY6AWG7wBov5eKKqhoK33IY6XlAt dU3Et/EDgxlyWGv7hfjOyNOIQaFCgo0RQGRoEfzxOwqL0Yvz+hsrNxb9ajQSuxMwotVYiAB7n/iR uhZja5dsB/rMDR/pV7vj/cHVV/RKDCqlT6lLhYK05eR8JgztEfDrVw2oSthFkmYWiIgpr6uEQrrI vIg6Dg7SUI4SVwC2470/vaqIplXQh9asuVjqt8KLtfOHIkx3uoEZ/EF5UnIkLgkX2I8/040T1MCQ D3pP4lFrEnqUx8B+MNbWSgEnAfk/XTjUpH55y+JhbudWm/0MAItr9SWAKYJ9QEI76uQHwfVRFFPq R5TPLkOFCOmdEeaDWYb5BsWqy+narFwRCIkGRE8NRE2ChkQSR+GbdYfueE4OnXhGSCv3OQQGjgdv vFE/u7wNDQGMOgxQzLrWTLtQKfDwe8VHcquFDlEOcvfbagYIwqsNYTr14lEYn3mPqRIc0usPxSnp hM670Y2hPBUwAI2Bjog7pGMzYAiE1sjIjUQOwxaEK9s7yBYtiMeMWA3GhYux+LYCElgcrRFU0RcA hmfPOPLSj9KTxv/OIIjsTE5G0I3xYs0ObsqYRqtRi4ZJEiyAbvQ0fU0M4AiPG5vnGl1u6UkPoA8E U+Qr7jhdPbYPYodXlZYx/ATExNyIO59IZlAd2QaGPk85wokk2lMSPdaysKjK+ZFIgjpJAxcJBkh6 FVKSZknWbpvGKUNRia1ZcN5uwMhE6TV/g+RdcYU61s+r4A1QFOGrMca8fuYtf4sQjTaOOIZouL00 OsxVTDrRxjZXGQK6I2pIlY9PT+Pa0xCM6v5RDn48fbZ55gg+Wop8TQfbRQHGhZWwILHvK4u01RA5 EBPXSs3XIjVyTEJOl/mB+Gqlt/4J6pOvqurFzcQXeErM5BFFjYz2JSpqeWGWFWP40EPswRE4E/9y nIbfeIeEbASL0Z2N7jS3s9x+XvkRn/McSg7aArxNhWmpyEg6Ck76hYANhgEO+8oNEQe1hcILzXqL 0SqHxsApH8lNukfA6de8nPIRnSiMPDrF/vQHqYfDhWrHxoUQMvz8xwYHhoZABio5wscGAEAFRsDA xXTH6PDGRsDbG6kHtPx+Pbzczv6Fv+orB6spGUc4hvQ4BkDU6YAHAKpGwAE37+Jix79WawN0xsM+ AAKrZCU8/Mc5Rp4HBwZrJ0dHR8aGRzzGxsd9R4YHQEjIj4uGaoHHwccqaQBANP3zcySv6QHAlYDA qqmAKwCHfkDrwAZp5LLjWMQJBjgGhkXqqniNBoWDCJeSYschB4Pp0Tj9tSl7hnOI+aR1h8dpwyPH kwY9tA1cagZGUB9ILwjFU75pKilPKSnhIyKSyG4wNDm01kzGe33JpGLkMAdptOoIQBA1FgKMBbMy /agqQNfKKj+pRuoCfYWGeKrpdHRpzka86fa7/Pd8hvSkiHaszMYpvoJTagAXBsQCenSrvwEHpL0m PHhqQEdr/cc9xxfAVUEWx/QCHasGg+qyiITSB8C/x0H//kUCq+XoAzwHwgDoCRjjPANGsIeAKoan B2ukJNtsU8R+qeqGeH5srsc/aX9Vhx//jf8zbzj+/Y7GvX79xkDEdgc/gs9YE2vCeOphfPdGqdYz raFYoceARsd9+FMWBlD/tEcqh+h8Uj/lr32BTatWwfpAf4z+q0+rSm9W1Ls6MIBHvIZxvYnTdaqH wMfQxUZ+c9xP6gUGzEaHhTRxG49bRtu4aUbHUDOEZkLqdEhGyzoH60MAqXw453RA6is+BwxCuyvp fcV9QID9qQektmkC0Uee0XNTAQBD+GNR5Bt/QOrHef8+Rca4hAyqfEitPMiOqb9H/VEXiBBqfTmX FzT+sx+jrCv0fkPRfv4+Q02FQKt41Yob/g/76cXFaur89aM6f3TVKxFr2zhhAGxSjACqdPiMauvF W8e+XWmCKgvB0UbVBzRry0dAgalHqfjpvAB1gKsAdGoCQci83yvAAHY4UfMVq4H/jzuMx6pH/gdq x9RoNlzW66eBFgfAQCuGNLSlqlX4u88z7E396kaqv4ZAAQFVRoQpsd3dwQELhOn1EIcHKsapGjt/ T0AGqi9GBcW1zpGrB4UfamGu4zDiv2qAas5190fANleeNxgHQPzTqcQeXHNKy6t9hivHRCq/Kym4 RsKr6P08WGd68tfHS0vYxocc1m5IDAZ4wFhAwfSHgKkZ/VonPwOqADuQhzgHEgewHYfGYiJbG0AK uVHLEYadvxW11eJWzljvSgW028Z02k7DWpOiEHR6/TOYOjbRcuqqU1Jpa48NyRz0kjsXQM7cgOsB p9efIQffeJjHKWq0wrlER8Wrk9RYKP6Ngy+cqoAcEhYxVry9QEZH6YVGhkc0nn2NAnTMAOmrkOqA a0CllQjLjZMBNMA1af+tdEd+YyUTgGx0wgwHAXuT3sbRn/BK2ch8CBu0/dbskE4dqgAq/Xu5AgoR anXrb4T4O4pFQMQVLOp4M6vMk6rAw1xMAD+ra5zkdaPHgmsr4io4o8Jrwqk+Qc67c8P2dI8qQ32q IGc/a0nD8yRVOGlAtCo0KQAAxvX3G+Ij+h4gx3q5v7tBWwewvBqAxcmJ4pvHhQBiQCr7nARkeQ91 PlEiBlVFJQG7n0FKcEfXtMePNhKv0q+lFQb6mb/02H70P7hqJr9c+79pkvrGuyBRlnUpwP5spKKx /c0APpMDuMZFAwv4Q1ndp3vjoPk/eZAZAE2r73tIZviqEcfCFJhMt0LNu0RyemVbUqM56gCBB8DX s+t2qUI9f8SRYrsmQio0gIzHUId+UrvjT37pYcBqlcYr/3RQTluR4CwA68t+39Pq1PaD6g/9KmTq gPt3mHBL2zXTg5vFPf1TmkWyh2or9QaBhsNqlgbXBmusD5NeHAu9DUa08EZ5BoC8Xj223Hk0+qpr SopH0QH+acgU/7RVFdc9vGcB3kLpfpBIDVeIk5ipUNAOUNe3M9fosnQCAl4qwDzUhgCvmDKnMXhA aeVmletGaQWqo8VK3I/Uyl7WD1jWvtccf0P9wUepXYxo0U3fHZVM6V2Acc2ErKEAwS67woatR8eu JXIDYYCrdkeORrxd6ES8CWvCh13fVWQdRlX8ySmOt2qA9I6qBaKPuEpkhXj0BAapRQfr0rPLLmpC pAY4/jqTv6E/QBsujgLo0fv940AGJTrUu7vGuTJXexphoUb/hzReR+pEqgQ3XLsIsgYBqYdAKaqG RoDhP9APau3dSXtAB+nnlZPxoBPjupp7VbwHb+mHM+E6XcC+TgXH5VR37YASq+DxTau6bFkHrTLj GABfGZ4ykat7T1fVfYj/InLlHLU6rap0QkxmbL9iNqWyQD1Mv6IK6/sEF72TBsU6hwCA7QKa8Diy pcY3D7SGB4fZ99p7Tm7ru9OjaQgCwqtglgG6tJn9tPs18XunRz0AqZXFz0hrOybb35RWagaMQsHt JNeHQNzHz5jwBE+CxwYC+nVqRBRzoyrBo2r4g71/q9fqAOtYCkW1V/31h11TNDQrFoYJhk9RIcg3 xhd9uFBrgC64Yc4Q00XJDRhs+zoHD8UFWO+OVU9gy4tHDRya1Ekax8GvqqvARD3xLBOr4v4JfeTK PntLXA5QGwY+M2XKKStIbLy1BHs5DL8CkNZM1se4s3TNM2Gc+kbCgP/0uGtWR/8kwHdBPPJcu0aM Pv8G0Ck9kOBXgGu9QL2020dPANmW5Ku977jp718I45uVfpDOaQWP/r+0tNW8H8CwaUQiK4B+wwhF cp94EMbOz8aJi8H+K2roBrrHpBSM3E7we999wR+cRmrkVg/DvUE0xtEH/TgAAc00qoAdJgMAdQW0 xHgIS2D6XmqkInNBG31YGZ3jMD5TBdU+1FftRXRMT88msom+K2sq63zPBjvzfDvM6w6/vj64rYdD gavLRTsv6zwrDDUoK3wHiQbjwkckhetcW4h7PzdC6gZqgWp8P7sU1HmEdSK19AD0awdBR2gSd7Z0 vSZIe6brWmWBBb4oqrywko99V72xKXRp0ZhaTlNIWRBaPkb7/oPriBrEjdhVfFV+NDmCA4EiiH1j xlct2pOR116CvcC09Kua5AXy/X283ToohXwm6fS+WmiQvDrofIXBMPkE1msAhngVTxcQBsfqvol4 wPduBAChhRkp4ZO0ID5dBZ6IjEZMaoI0xseOAzAHDf+LTUAcBDQ3hCB7PmvDZEfpSeXHx/93gP6p dFMi9tVWTT6/ep9qqW0grn0Oqp4AIWhyPHjHKAerdDT0NNtlHZu+6u8AOLnHrkE/rp2PeCUqQUYP pHJB/kMO34F/n4cigM2JCHPiaBodTCpF67p+K2pMxioQz+j6QatB6XSMql76QT8a6kiMKUFleG0I /kHaQSt+og3Op1WohsU5zJRbiN5xaGcFxiC0HsIHv5rEyGJW5gbSRVP9uxvi6XmaafRfuAhswXxE gLqRqzpWwXA4Tv2GDH+DWTf8Yz18egWGKDSFKLg8VsU8NUiboKvHbJMAKvQPxsQneaEfPHXUFkLT E+nrWD5ogQEGxfmvf3iC6ob8Ote/61vXgEVSWAN0c8hP5sGg9wbHB6g1NEH8pqA0xSiD6kU36rKf qPnSD1pHNIps+cdwqWoi7sTdhwAopvzqhimF/AVhfGhVRyoVaamxBYtCxbxxfJYtbUuzAwWHxcZF /ByGPczVRoK6/rxEs4rDivwM/MDkh7w8gNOB80oHwEZGvHxMcviWzjx8ZzyYBvwv/3yHWxjVX64F VtXXpwI1VrxmKeoxq4BChjcGTK7p8zTHdMe0FsG15AtK3lq/HKScbJr15oftB7gbpgdTY9C4Rixk D3dtcPRfiM0S2v5077x8vOzG/Py0xfz9vLz8PPz8/Pz81MYHYL4A8EYAjb4AIPn/V4PN/+l6AQAA kJCQigZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5DHJ g+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D7vwR 2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY////5CLAoPC BIkHg8cEg+kEd/EBz+lM////Xon3uSsEAACKB0cs6DwBd/eAPwt18osHil8EZsHoCMHAEIbEKfiA 6+gB8IkHg8cFidji2Y2+ANAHAIsHCcB0RYtfBI2EMAAACAAB81CDxwj/lowACACVigdHCMB03In5 eQcPtwdHUEe5V0jyrlX/lpAACAAJwHQHiQODwwTr2P+WlAAIAIPHBI1e/DHAigdHCcB0IjzvdxEB w4sDhsTBwBCGxAHwiQPr4iQPweAQZosHg8cC6+Jh6aol+f8AhfQ40SDSuRwRAQAjwIT+cgCBNA6k qYulCeQsAAn2if/BBA4ONAA8XzvagQQOQbKhoQrShcfi2Arb6VX+//8ACf+E5CwA6Un+//8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQQCACMEAgAAAAAAAAA AAAAAAAA0RAIAJwQCAAAAAAAAAAAAAAAAADeEAgApBAIAAAAAAAAAAAAAAAAAOYQCACsEAgAAAAA AAAAAAAAAAAA8RAIALQQCAAAAAAAAAAAAAAAAAD8EAgAvBAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA CBEIABYRCAAmEQgAAAAAADQRCAAAAAAAQhEIAAAAAABSEQgAAAAAAFgRCAAAAAAAAQAAgAAAAABL RVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1QUi5kbGwATVNWQ1JULmRsbABVU0VSMzIuZGxsAFdT T0NLMzIuZGxsAAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABS ZWdDbG9zZUtleQAAAFdOZXRPcGVuRW51bUEAAABwdXRjAABTZXRUaW1lcgAAAAAIAAwAAAAiMQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------------X9ZAGUDE21S3CF-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 5 15:27:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13370 for ; Thu, 5 Jun 2003 15:27:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h55JQwq29329 for ; Thu, 5 Jun 2003 15:26:58 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h55JQsl07929 for ; Thu, 5 Jun 2003 15:26:54 -0400 (EDT) Reply-To: From: "Vishal Sharma" To: , , Subject: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue Call for Papers Date: Thu, 5 Jun 2003 12:24:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-SMTP-HELO: smtp101.mail.sc5.yahoo.com X-SMTP-MAIL-FROM: v.sharma@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp101.mail.sc5.yahoo.com [216.136.174.139] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Folks, The IEEE Communications Magazine has just approved the publication of a Feature Topic issue on "OAM-in MPLS-based Networks." The CFP is attached below. We invite those working in this area to consider sending in their contributions. If you intend to submit a paper for this special issue, please drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your participation! Thanks, -Vishal ************************************* Vishal Sharma Metanoia, Inc. http://www.metanoia-inc.com ************************************* ==================================================================== CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "OAM in MPLS-Based Networks" ********************************************** As carriers and service providers converge multiple services and associated networks on to an MPLS-based infrastructure, OAM functionality becomes pivotal for enabling them to provide service level agreement (SLA) guarantees, service assurance, quality of service (QoS) assurance and overall interworking service management. The advent of new applications of MPLS such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs) also means the emergence of added OAM requirements from operators deploying those networks. As a result, providers today require more efficient means of monitoring network health, performance, and robustness, and of quickly identifying and resolving performance problems. This is leading to the emergence of improved or novel tools and techniques, whose goal is to improve security and billing/accounting, aid in verifying QoS commitments, and reduce operating costs. Standards organizations such as the IETF and the ITU have in the recent past done significant work in this area, and this subject is also being investigated by the IEEE and the Metro Ethernet Forum. This feature topic issue of the IEEE Communications Magazine has a dual focus: to highlight operator requirements and deployment experiences with OAM in MPLS-based networks, and to present a survey of the current engineering and research developments in this area. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but not limited to) the following: * Operational consequences of inadequate OAM capabilities * Service provider requirements for efficient OAM - current operational needs and future demands * Deployment experiences with OAM over MPLS-based networks * Overview or comparative analysis of different approaches/philosophies for OAM * Standards activities o Emerging architectures o New mechanisms for OAM in development (e.g. IETF LSP ping, ITU-T Y.1711, virtual circuit connection verification (VCCV)) * Platform support for OAM * OAM impact on edge services (such as metro Ethernet) using MPLS transport * Interoperability issues, interworking with other technologies (e.g. ATM) * Review of current research in the area - E.g. setting parameters for connectivity verification and their impact on LSP recovery, trade-offs between bandwidth usage by OAM traffic and efficiency of failure/anomaly detection, and results from testbed deployments or simulations On-line CFP with submission instructions can be found at: http://www.comsoc.org/pubs/commag/cfpcommag1004.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided the consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at: http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please submit no later than November 30, 2003. Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Schedule: Manuscript Due: November 30, 2003 Acceptance Notification: February 28, 2004 Final Manuscript Due: April 15, 2004 Publication Date: October 2004 Guest Editors: Monique J. Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Tom Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824, USA. Email: tnadeau@cisco.com Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA. Email: v.sharma@ieee.org About the IEEE Communications Magazine: The IEEE Comm. Mag. is the official technical publication of conferences such as Supercomm, and has the unique distinction of being the most widely read IEEE journal, with its over 50,000 paid subscribers representing key communications engineers and technical managers in our industry. More information on the IEEE Comm. Mag., may be found here: www.comsoc.org/adv/pp/Adpp2003revisedweb.ppt From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 5 21:57:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25122 for ; Thu, 5 Jun 2003 21:57:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h561v5q27920 for ; Thu, 5 Jun 2003 21:57:05 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h561v3500308 for ; Thu, 5 Jun 2003 21:57:03 -0400 (EDT) Date: 6 Jun 2003 01:55:03 -0000 Message-ID: <20030606015503.8268.qmail@machiavelli.synacor.com> From: "richard dafe" To: ridafe@anfmail.com X-Originating-IP: [81.23.193.84] Subject: Your Inheritance Mime-version: 1.0 X-MASSMAIL: 1.0 X-MASSMAIL: precedence.bulk Content-Type: multipart/alternative; boundary="=====================_889472414==_" X-SMTP-HELO: mail1.chek.com X-SMTP-MAIL-FROM: ridafe6@casino.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: barney.synacor.com [208.197.227.8] X-LYRIS-Message-Id: --=====================_889472414==_ Content-Type: text/plain Content-Transfer-Encoding: 8bit Dr. Richard Dafe Branch Manager EcoBank International. Idumota Branch Lagos Nigeria. I am Dr. Richard Dafe The Branch Manager of EcoBank International, Idumota Branch,Lagos Nigeria. I have an urgent and very confidential business proposition for you. On December, 1997, a Taiwanese Oil consultant/contractor with the Nigerian National Petroleum Corporation, Mr. Boris Chen made a numbered time (Fixed) Deposit for Twenty-Four calendar months, valued at US$25,000,000.00 (Twenty- five Million Dollars) in my branch. Upon maturity, I sent a routine notification to his forwarding address but got no reply. After some months, we sent a reminder and finally we discovered from his contract employers, the Nigerian National Petroleum Corporation that Mr. Boris Chen died from an airplane crash ( Singapore Airlines). On further investigation, I found out that he died without making a WILL,and all attempts to trace his next of kin was fruitless. I therefore made further investigation and discovered that Mr.Boris Chen did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$25,000,000.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one has ever come forward to claim it. According to Nigerian Law, at the expiration of 5 (five) years, the money will revert to the ownership of the Nigerian Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you to stand in as the next of kin to Mr.Boris Chen so that the fruits of this old man's labour will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin. We shall employ the services of two Attorney for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate/administration in your favour for the transfer. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in th! e ratio of 70or me and 25or you and 5% be used in settling taxation and all local and foreign expenses.There is no risk at all as all the paperwork for this transaction will be done by the Attorney and my position as the Branch Manager guarantees the successful execution of this transaction. If you are interested, please reply immediately via the private email address below. Upon your response, I shall then provide you with more details and relevant documents that will help you understand the transaction. Please observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. I can be reached through this email address. I do urgently await your response. Best regards, Dr. Richard Dafe. --=====================_889472414==_ Content-Type: text/html Content-Transfer-Encoding: 8bit
Dr. Richard Dafe
Branch Manager
EcoBank International.
Idumota Branch
Lagos Nigeria.


I am Dr. Richard Dafe The Branch Manager of EcoBank International, Idumota Branch,Lagos Nigeria. I have an urgent and very confidential business proposition for you. On December, 1997, a Taiwanese Oil consultant/contractor with the Nigerian National Petroleum Corporation, Mr. Boris Chen made a numbered time (Fixed) Deposit for Twenty-Four calendar months, valued at US$25,000,000.00 (Twenty- five Million Dollars) in my branch. Upon maturity, I sent a routine notification to his forwarding address but got no reply. After some months, we sent a reminder and finally we discovered from his contract employers, the Nigerian National Petroleum Corporation that Mr. Boris Chen died from an airplane crash ( Singapore Airlines).

On further investigation, I found out that he died without making a WILL,and all attempts to trace his next of kin was fruitless. I therefore made further investigation and discovered that Mr.Boris Chen did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$25,000,000.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one has ever come forward to claim it.

According to Nigerian Law, at the expiration of 5 (five) years, the money will revert to the ownership of the Nigerian Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you to stand in as the next of kin to Mr.Boris Chen so that the fruits of this old man's labour will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin. We shall employ the services of two Attorney for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate/administration in your favour for the transfer. A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in th! e ratio of 70or me and 25or you and 5% be used in settling taxation and all local and foreign expenses.There is no risk at all as all the paperwork for this transaction will be done by the Attorney and my position as the Branch Manager guarantees the successful execution of this transaction.

If you are interested, please reply immediately via the private email address below. Upon your response, I shall then provide you with more details and relevant documents that will help you understand the
transaction.

Please observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. I can be reached through this email address.

I do urgently await your response.

Best regards,

Dr. Richard Dafe.



--=====================_889472414==_-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 5 22:28:31 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25835 for ; Thu, 5 Jun 2003 22:28:31 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h562S0q07168 for ; Thu, 5 Jun 2003 22:28:00 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h562Rvj01920 for ; Thu, 5 Jun 2003 22:27:57 -0400 (EDT) Message-Id: <200306060227.AA01223@DF75L51X.lab.ntt.co.jp> From: Junichi Sumimoto Date: Fri, 06 Jun 2003 11:27:55 +0900 To: Alex Zinin Cc: ppvpn@nortelnetworks.com Subject: Re: Common L2/L3 documents In-Reply-To: <481045373117.20030604220432@psg.com> References: <481045373117.20030604220432@psg.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: tama5.ecl.ntt.co.jp X-SMTP-MAIL-FROM: sumimoto.junichi@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: Hi Alex and all, Alex Zinin wrote: >Folks- > >We have several documents on the PPVPN page that we need >to decide which WG to put in. > draft-ietf-ppvpn-applicability-guidelines-01.txt > Note: Is this document intended to become an RFC or rather a > "living" draft? I hope that this document will become an Informational RFC. I believe that such a guideline document must be informative as a bridge between requirements docs and applicability statements docs. >My suggestion would be to put them all in L3VPN, since L3 space >is more advanced progress-wise. I fully agree on that. Thanks, Junichi. -------- Junichi Sumimoto NTT Corporation E-mail: sumimoto.junichi@lab.ntt.co.jp Tel: +81 422 59 3293 From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 6 03:34:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13098 for ; Fri, 6 Jun 2003 03:34:12 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h567XfT29458 for ; Fri, 6 Jun 2003 03:33:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h567Xce17745 for ; Fri, 6 Jun 2003 03:33:38 -0400 (EDT) X-Original-Recipient: Message-ID: <3EE0425E.50602@pi.se> Date: Fri, 06 Jun 2003 09:27:26 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: PPVPN@nortelnetworks.com Subject: ppvpn agenda for IETF 57 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailb.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mailb.telia.com [194.22.194.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit All, the 57th IETF meeting to be held in Vienna is appraoching fast, it is time to set the agenda for the ppvpn working group. Please note that there will be two sessions - one on L3VPNs and one on L2VPNs. Please indicate in which session you want your agenda item to go. As for the "common documents and items" the wg chairs will distribute those between the two session as we see fit. Note that to get a time slot, you MUST have submitted a draft by the draft deadline (June 30, 9:00AM ET). Furthermore, these time slots are for discussing and resolving issues raised on the mailing list, or for first time drafts, a *very* brief overview of the idea, why it's relevant, and how it fits into the ppvpn (L3vpn or L2vpn) charter. No presentations! If you request a time slot, please follow up and start an email discussion on the ppvpn list. Thanks, Loa and Rick. -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 6 13:33:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03545 for ; Fri, 6 Jun 2003 13:33:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h56HWUl03801 for ; Fri, 6 Jun 2003 13:32:31 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h56HWRV11833 for ; Fri, 6 Jun 2003 13:32:28 -0400 (EDT) Date: Fri, 6 Jun 2003 10:27:32 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1751176353356.20030606102732@psg.com> To: ppvpn@nortelnetworks.com Subject: Re: Common L2/L3 documents In-Reply-To: <481045373117.20030604220432@psg.com> References: <481045373117.20030604220432@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit FYI, there's another common draft: draft-fang-ppvpn-security-framework and I've put it in the L3VPN charter I sent last night. -- Alex http://www.psg.com/~zinin/ Wednesday, June 4, 2003, 10:04:32 PM, Alex Zinin wrote: > Folks- > We have several documents on the PPVPN page that we need > to decide which WG to put in. > Currently PPVPN documents: > draft-ietf-ppvpn-generic-reqts-02.txt > Note: the doc has been to IESG, pending new rev addressing > IESG comments > draft-ietf-ppvpn-bgpvpn-auto-05.txt: > Note: I need to AD-review this document to see if any part > of it belongs in IDR. if not, refer to IDR for a review. > draft-ietf-ppvpn-tc-mib-02.txt > draft-ietf-ppvpn-applicability-guidelines-01.txt > Note: Is this document intended to become an RFC or rather a > "living" draft? > My suggestion would be to put them all in L3VPN, since L3 space > is more advanced progress-wise. > FYI, there are also several individual submissions (per Jeremy) that > we may have to deal with later. > draft-raggarwa-ppvpn-tunnel-encap-sig-00.txt > draft-chiussi-ppvpn-qos-framework > Note: I did not list expired IDs. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 6 13:34:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03673 for ; Fri, 6 Jun 2003 13:34:28 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h56HXsl05653 for ; Fri, 6 Jun 2003 13:33:54 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h56HXpV14092 for ; Fri, 6 Jun 2003 13:33:51 -0400 (EDT) Date: Fri, 6 Jun 2003 10:28:06 -0700 (PDT) Message-Id: <200306061728.h56HS6B33164@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Loa Andersson Cc: PPVPN@nortelnetworks.com Subject: ppvpn agenda for IETF 57 In-Reply-To: <3EE0425E.50602@pi.se> References: <3EE0425E.50602@pi.se> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: roque@juniper.net X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Loa Andersson writes: > All, the 57th IETF meeting to be held in Vienna is appraoching fast, > it is time to set the agenda for the ppvpn working group. Please > note that there will be two sessions - one on L3VPNs and one on > L2VPNs. Please indicate in which session you want your agenda item > to go. As for the "common documents and items" the wg chairs will > distribute those between the two session as we see fit. Loa, Would like to give a brief overview of: a) draft-marques-ppvpn-rt-constrain-00.txt b) draft-marques-ppvpn-ibgp-00.txt They are both l3vpn topics. rt-constrain is about liting the scope of distribution of 2547 routes and the ibgp one proposes to have iBGP as the PE-CE routing protocol mechanism for 2547. Would appreciate around 20 mins for both topics. thanks, Pedro. From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 6 22:22:50 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21751 for ; Fri, 6 Jun 2003 22:22:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h572MIl08220 for ; Fri, 6 Jun 2003 22:22:18 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h572MFi26204 for ; Fri, 6 Jun 2003 22:22:15 -0400 (EDT) Date: Sat, 07 Jun 2003 10:18:49 +0800 From: lidefeng Subject: Re: ppvpn agenda for IETF 57 To: Loa Andersson , PPVPN@nortelnetworks.com Message-id: <001b01c32c9b$2218a7a0$07436e0a@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: <3EE0425E.50602@pi.se> X-SMTP-HELO: mta1.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,Loa, Would like to give a brief overview of: a) draft-libin-hierarchy-pe-bgp-mpls-vpn-02.txt b) draft-sheng-ppvpn-isis-bgp-mpls-00.txt They are both l3vpn topics. draft-libin-hierarchy-pe-bgp-mpls-vpn-02 is about the problem of scalability of PE in 2547VPN and the access to the different layer BGP/MPLS VPN customer; and draft-sheng-ppvpn-isis-bgp-mpls-00.txt address the issue of IS-IS as the PE-CE routing protocol mechanism for 2547.the latter draft will be updated recently to include the consideration of wide metric situation. Would appreciate around 20~25 mins for both topics. TIA Defeng Li Huawei Technologies ----- Original Message ----- From: "Loa Andersson" To: Sent: Friday, June 06, 2003 3:27 PM Subject: ppvpn agenda for IETF 57 > All, > > the 57th IETF meeting to be held in Vienna is appraoching fast, > it is time to set the agenda for the ppvpn working group. Please > note that there will be two sessions - one on L3VPNs and one on L2VPNs. > Please indicate in which session you want your agenda item to go. > As for the "common documents and items" the wg chairs will distribute > those between the two session as we see fit. > > Note that to get a time slot, you MUST have submitted a draft by > the draft deadline (June 30, 9:00AM ET). Furthermore, these time > slots are for discussing and resolving issues raised on the mailing > list, or for first time drafts, a *very* brief overview of the idea, > why it's relevant, and how it fits into the ppvpn (L3vpn or L2vpn) > charter. > > No presentations! > > If you request a time slot, please follow up and start an email > discussion on the ppvpn list. > > Thanks, > Loa and Rick. > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Jun 7 06:27:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10310 for ; Sat, 7 Jun 2003 06:27:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h57AQUh07021 for ; Sat, 7 Jun 2003 06:26:31 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h57AQRX02556 for ; Sat, 7 Jun 2003 06:26:28 -0400 (EDT) Date: 7 Jun 2003 09:54:46 -0000 Message-ID: <20030607095446.2810.qmail@mail.rediffmailpro.com> MIME-Version: 1.0 From: "SESAY MASSAQUOE" Reply-To: "SESAY MASSAQUOE" To: sesay@sesmassaq.com Subject: A CRY FOR HELP FROM SESAY MASSAQUOE Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-SMTP-HELO: mail.rediffmailpro.com X-SMTP-MAIL-FROM: sesay@sesmassaq.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: f2mail.rediffmailpro.com [203.199.83.212] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA10310 DEAR FRIEND, THROUGH THE COURTESY OF BUSINESS OPPORTUNITY, I TAKE LIBERTY ANCHORED ON A STRONG DESIRE TO SOLICIT YOUR ASSISTANCE ON THIS MUTUALLY BENEFICIAL AND RISKFREE TRANSACTION WHICH I HOPE YOU WILL GIVE YOUR URGENT ATTENTION. I AM MR.SESAY MASSAQUOE I AM MOVED TO WRITE YOU THIS LETTER ,THIS WAS IN CONFIDENCE CONSIDERING OUR PRESENT CIRCUMSTANCE AND SITUATION. I ESCAPED WITH MY WIFE AND CHILDREN OUT OF SIERRA LEONE TO GHANA WHERE WE ARE PRESENTLY RESIDING ON TEMPORARY POLITICAL ASYLUM. HOWEVER DUE TO THIS SITUATION I DECIDED TO CHANGE MOST OF MY BILLIONS OF DOLLARS DEPOSITED IN SWISS BANK AND OTHER COUNTRIES INTO OTHER FORMS OF MONEY CODED FOR SAFE PURPOSE BECAUSE THE NEW HEAD OF STATES AHMED TIJJAN KABBA MADE ARRANGEMENTS WITH THE SWISS GOVERNMENT AND OTHER EUROPEAN COUNTRIES TO FREEZE ALL MY TREASURES DEPOSITED IN SOME EUROPEAN COUNTRIES,HENCE I AND MY WIFE ALONG WITH MY CHILDREN, DECIDED LAYING LOW IN AFRICA TO STUDY THE SITUATION TILL WHEN THINGS GETS BETTER,SINCE PRESIDENT TIJJAN KABBA TAKING OVER GOVERNMENT AGAIN IN SIERRA LEONE ONE OF MY CHATEAUX IN SOUTHERN FRANCE WAS CONFISCATED BY THE FRENCH GOVERNMENT,AND AS SUCH WE HAD TO CHANGE OUR IDENTITY SO THAT OUR INVESTMENT WILL NOT BE TRACED AND CONFISCATED. I HAVE DEPOSITED THE SUM OF THIRTY MILLION,FIVE HUNDRED THOUSAND UNITED STATES DOLLARS(US$30,500,000)WITH A SECURITY COMPANY FOR SAFEKEEPING. THE FUNDS ARE SECURITY CODED TO PREVENT THEM FROM KNOWING THE ACTUAL CONTENTS. WHAT I WANT YOU TO DO NOW IS TO INDICATE YOUR INTEREST THAT YOU WILL ASSIST ME AND MY IMMEDIATE FAMILY BY RECEIVING THE MONEY ON OUR BEHALF. THE ACCOUNT REQUIRED FOR THIS PROJECT CAN EITHER BE PERSONAL,COMPANY OR AN OFFSHORE ACCOUNT THAT YOU HAVE TOTAL CONTROL OVER,YOUR AREA OF SPECIALISATION WILL NOT BE A HINDERANCE TO THE SUCCESSFUL EXECUTION OF THIS TRANSACTION. ACKOWLEDGE THIS MESSAGE,SO THAT I CAN INTRODUCE YOU TO MY FAMILY AS OUR FOREIGN TRUSTED PARTNER WHO SHALL TAKE CHARGE OF OUR INVESTMENT ABROAD WHERE WE NOW PLAN TO SETTLE. I WANT YOU TO ASSIST US IN INVESTING TH WANT OUR IDENTITY REVEALED.I WILL ALSO WANT TO BUY PROPERTIES AND STOCKS IN MULTI-NATIONAL COMPANIES AND TO ENGAGE IN OTHER SAFE AND NON SPECULATIVE INVESTMENTS. WE HAVE BEEN THROUGH A LOT OF HEALTH AND SPIRITUAL TURMOIL,HENCE WILL NEED YOUR UNDERSTANDING AND ASSISTANCE. MAY I AT THIS POINT EMPHASIZE THE HIGH LEVEL OF CONFIDENTIALLITY WHICH THIS BUSINESS DEMANDS AND HOPE YOU WILL NOT BETRAY THE TRUST AND CONFIDENCE WHICH WE REPOSE IN YOU.I SHALL PUT YOU IN THE PICTURE OF THIS BUSINESS,I.E TELL YOU WHERE THE FUNDS ARE CURRENTLY BEING MAINTAINED AND ALSO DISCUSS OTHER MODALITIES INCLUDING REMUNERATION FOR YOUR SERVICES. I SHALL INFORM YOU WITH THE NEXT LINE OF ACTION AS SOON AS I RECEIVE YOUR POSITIVE RESPONSE. IS THIS PROPOSITION ATTAINABLE?IF IT IS,PLEASE KINDLY FURNISH ME IMMEDIATELY BY E-MAIL WITH YOUR DIRECT TELEPHONE AND FAX NUMBERS TO ENHANCE THE CONFIDENTIALLITY WHICH THIS BUSINESS DEMANDS. BEST REGARDS MR.SESAY MASSAQUOE. ATTN:PLEASE SEND YOUR RESPONSE TO MY PRIVATE EMAIL BELOW: sesaymassaquoe@netscape.net From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Jun 7 16:42:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21111 for ; Sat, 7 Jun 2003 16:42:28 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h57Kfwh09260 for ; Sat, 7 Jun 2003 16:41:58 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h57Kfta13460 for ; Sat, 7 Jun 2003 16:41:55 -0400 (EDT) X-Original-Recipient: PPVPN@nortelnetworks.com Message-ID: <3EE24C89.3090304@pi.se> Date: Sat, 07 Jun 2003 22:35:21 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lidefeng CC: PPVPN@nortelnetworks.com Subject: Re: ppvpn agenda for IETF 57 References: <3EE0425E.50602@pi.se> <001b01c32c9b$2218a7a0$07436e0a@HUAWEI.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailb.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mailb.telia.com [194.22.194.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit All, this is not jumping on this particular request for a time slot, but to indicate how we will handle a more general "problem". Scheduling requests for timeslots on the agenda coming in for drafts/issues that has not been discussed on the mailing list. The method is "Schedule short and late", with the risk that it will drop off the end of the agenda, due to more important issues taking longer time than planned that has been scheduled earlier on the agenda. Note: Li has done what is required, notified the list and invited to discussion. If you think these draft are of interest for the wg and/or there are issues that needs to be discussed, please bring this to the mailing list. Li, I've noted your request for a timeslot at the Vienna meeting. Qouting from my earlier mail: "these time slots are for discussing and resolving issues raised on the mailing list, or for first time drafts, a *very* brief overview of the idea,why it's relevant, and how it fits into the ppvpn (L3vpn or L2vpn) charter." So far the only mails (that I've seen) that relates to the two drafts are the notifications you sent to the mailing list. To have the requested time you need to have discusion on the mailing list, otherwise this will be scheduled with low priority and very brief (10 min maximum) at the end of the agenda to be brought up if we have the time. /Loa lidefeng wrote: > Hi,Loa, > > Would like to give a brief overview of: > a) draft-libin-hierarchy-pe-bgp-mpls-vpn-02.txt > b) draft-sheng-ppvpn-isis-bgp-mpls-00.txt > > They are both l3vpn topics. draft-libin-hierarchy-pe-bgp-mpls-vpn-02 is > about the problem of scalability of PE in 2547VPN and the access to the > different layer BGP/MPLS VPN customer; and > draft-sheng-ppvpn-isis-bgp-mpls-00.txt address the issue of IS-IS as the > PE-CE routing protocol mechanism for 2547.the latter draft will be updated > recently to include the consideration of wide metric situation. > > Would appreciate around 20~25 mins for both topics. > > TIA > > Defeng Li > Huawei Technologies > > ----- Original Message ----- > From: "Loa Andersson" > To: > Sent: Friday, June 06, 2003 3:27 PM > Subject: ppvpn agenda for IETF 57 > > > >>All, >> >>the 57th IETF meeting to be held in Vienna is appraoching fast, >>it is time to set the agenda for the ppvpn working group. Please >>note that there will be two sessions - one on L3VPNs and one on L2VPNs. >>Please indicate in which session you want your agenda item to go. >>As for the "common documents and items" the wg chairs will distribute >>those between the two session as we see fit. >> >>Note that to get a time slot, you MUST have submitted a draft by >>the draft deadline (June 30, 9:00AM ET). Furthermore, these time >>slots are for discussing and resolving issues raised on the mailing >>list, or for first time drafts, a *very* brief overview of the idea, >>why it's relevant, and how it fits into the ppvpn (L3vpn or L2vpn) >>charter. >> >>No presentations! >> >>If you request a time slot, please follow up and start an email >>discussion on the ppvpn list. >> >>Thanks, >>Loa and Rick. >> >> >>-- >>/Loa >> >>mobile + 46 739 81 21 64 >>email: loa@pi.se >> >> >> > > > > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 9 09:52:23 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04726 for ; Mon, 9 Jun 2003 09:52:22 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h59Dotj22951 for ; Mon, 9 Jun 2003 09:50:55 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h59Doqd28770 for ; Mon, 9 Jun 2003 09:50:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16100.36931.885517.524895@harjus.tutpro.com> Date: Mon, 9 Jun 2003 16:48:51 +0300 To: ppvpn@nortelnetworks.com Subject: draft-heinanen-radius-pe-discovery-04.txt X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.tutpro.com X-SMTP-MAIL-FROM: jh@tutpro.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.tutpro.com [192.98.100.3] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit i just submitted draft-heinanen-radius-pe-discovery-04.txt to internet-drafts editor. it fixes several of the issues that were brought up last month on the mailing list. the ones that i didn't take into account were the ones i didn't think were good ideas. the draft is also available as http://tutpro.com/tmp/draft-heinanen-radius-pe-discovery-04.txt since i have retired from my job at song and don't anymore have a sponsor for this work, someone else would need to adopt the draft if is going to be worked on in the future. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 9 09:56:47 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04832 for ; Mon, 9 Jun 2003 09:56:46 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h59DuFj28189 for ; Mon, 9 Jun 2003 09:56:15 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h59DuCd06209 for ; Mon, 9 Jun 2003 09:56:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: call for comment on draft-rosen-vpns-ospf-bgp-mpls-06.txt as WG document Date: Mon, 9 Jun 2003 09:52:16 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C4BD@m-va-bsod03.add0.masergy.com> Thread-Topic: call for comment on draft-rosen-vpns-ospf-bgp-mpls-06.txt as WG document thread-index: AcMujlX/haRUmz9DRxm8uy+98sN1QA== From: "Rick Wilder" To: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA04832 I would like to start a two-week comment period on making draft-rosen-vpns-ospf-bgp-mpls-06.txt a PPVPN working group document. The accompanying draft, draft-rosen-ospf-2547bis-dn-00.txt, has support in the OSPF WG, so work can proceed there if draft-rosen-vpns-ospf-bgp-mpls-06.txt is accepted by this WG. Rick From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 9 23:38:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29654 for ; Mon, 9 Jun 2003 23:38:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5A3cQj13646 for ; Mon, 9 Jun 2003 23:38:26 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5A3cNq14445 for ; Mon, 9 Jun 2003 23:38:23 -0400 (EDT) Message-ID: <20030610033633.16256.qmail@web41809.mail.yahoo.com> Date: Tue, 10 Jun 2003 04:36:33 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: IMplicit NULL Label To: mpls-ops@mplsrc.com, ppvpn@nortelnetworks.com Cc: mpls@uu.net MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41809.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web41809.mail.yahoo.com [66.218.93.143] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Folks, Can BGP ever recieve an Implicit NULL Label from one of its PE peers. If yes, then when and what does it signify? Thanks, John Smith __________________________________________________ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 07:55:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21988 for ; Tue, 10 Jun 2003 07:55:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5ABscq07776 for ; Tue, 10 Jun 2003 07:54:39 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5ABsZP18040 for ; Tue, 10 Jun 2003 07:54:36 -0400 (EDT) Message-Id: <200306101152.HAA21737@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mpls@uu.net, ppvpn@nortelnetworks.com, te-wg@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-06.txt Date: Tue, 10 Jun 2003 07:52:44 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@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 Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Management Overview Author(s) : T. Nadeau, C. Srinivasan, A. Farrel Filename : draft-ietf-mpls-mgmt-overview-06.txt Pages : 28 Date : 2003-6-9 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. This memo describes the management architecture for MPLS and indicates the inter-relationships between the different MIB modules used for MPLS network management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-mgmt-overview-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-9151134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-mgmt-overview-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-mgmt-overview-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9151134.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 09:45:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29842 for ; Tue, 10 Jun 2003 09:45:17 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5ADikq13471 for ; Tue, 10 Jun 2003 09:44:46 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5ADihi21629 for ; Tue, 10 Jun 2003 09:44:43 -0400 (EDT) Message-ID: <018701c32f56$2ff23040$681810ac@movaz.com> From: "Adrian Farrel" To: , , References: <200306101152.HAA21737@ietf.org> Subject: Re: I-D ACTION:draft-ietf-mpls-mgmt-overview-06.txt Date: Tue, 10 Jun 2003 09:42:51 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-SMTP-HELO: jera.movaz.com X-SMTP-MAIL-FROM: afarrel@movaz.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: webmail.movaz.com [65.205.166.188] X-LYRIS-Message-Id: For those excited readers following this draft... Version 6 includes updates - to change all MIB module names to include "-STD" in line with changes to the MIB documents - in line with the latest TE-LINK MIB (thanks Martin) I anticipate another set of changes to pick up the new indexing from the LSR MIB once the WG has agreed it. Adrian ----- Original Message ----- From: To: Cc: ; ; Sent: Tuesday, June 10, 2003 7:52 AM Subject: I-D ACTION:draft-ietf-mpls-mgmt-overview-06.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : Multiprotocol Label Switching (MPLS) Management > Overview > Author(s) : T. Nadeau, C. Srinivasan, A. Farrel > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-06.txt > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 16:49:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17309 for ; Tue, 10 Jun 2003 16:49:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5AKmYq07588 for ; Tue, 10 Jun 2003 16:48:35 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5AKmTo23274 for ; Tue, 10 Jun 2003 16:48:30 -0400 (EDT) Message-ID: <6204FDDE129D364D8040A98BCCB290EF064B1FAF@zbl6c004.corpeast.baynetworks.com> From: "Paul Knight" To: Mark Duffy , ppvpn@nortelnetworks.com Subject: RE: WG LAST CALL on draft-ietf-ppvpn-vpn-vr-04.txt Date: Tue, 10 Jun 2003 16:46:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F91.53AD45B6" 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_01C32F91.53AD45B6 Content-Type: text/plain Hi Mark, Thanks for the detailed comments. Many responses below, marked [pk]... > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Wednesday, May 21, 2003 5:30 PM > To: ppvpn@nortelnetworks.com; Knight, Paul [BL60:1A00:EXCH] > Subject: WG LAST CALL on draft-ietf-ppvpn-vpn-vr-04.txt > > > Hi, here are comments on draft-ietf-ppvpn-vpn-vr-04.txt. > > General comment: Use of the VR approach in significant scale will require > the use of tunneling mechanisms that efficiently support many tunnel links > between a given pair of PEs, with some provision for binding a VPN-ID to > each tunnel link. This document reasonably leaves that to other > documents. However, the wg has no effort underway to produce > any such documents. :-( > [pk] I think your draft (Framework for IPsec Protected Virtual Links for PPVPNs, draft-duffy-ppvpn-ipsec-vlink-00.txt) is a good first step in the direction of looking at the options for binding VPN-ID to tunnel links. [pk] However, it's clear from many of your comments that the current VR draft has not fully communicated to you the functionality of the "backbone VR," which provides an efficient way to multiplex many "tunnel links" (although the binding of the VPN-ID is usually not explicit). I'll try to address this below. > > In the Abstract, and similar text in the Introduction: > Virtual > routers can be deployed in different VPN configurations, direct VR > to VR connectivity through layer-2 or by aggregating multiple VRs > into a single VR combined with IP or MPLS based tunnels. > > [md] This idea of "aggregating multiple VRs ..." seems confusing at the > least. (More comments on this below re sect 5.) How about "... through > layer-2 or by tunneling over a shared IP or MPLS based network." > [pk] The text quoted above (from the Abstract) is unclear due to being condensed too much. I'll re-word it (similar to your suggestion). The similar text in the Introduction is correct: Virtual routers can be deployed in various VPN configurations. Direct VR to VR connectivity may be configured through layer-2 links or through a variety of tunnel mechanisms, using IP- or MPLS-based tunnels. Multiple VRs may be aggregated over a "backbone VR." > > 1. Introduction > That is, the routing > protocol between the VRs may be the same or it might be different > than the routing mechanism used between the CE and VR. > > [md] "... or it may be a different instance of the same protocol" (The > point being that if ospf is used CE-VR and VR-VR, they may be the same > instance, or separate instances with only reachability (not topology) > information redistributed between them.) > [pk] This is a good point, not explicit in the draft. I'll put it in section 2.5.1 or 2.5.3, in order to avoid cluttering up the Introduction. (The Introduction is not wrong, but does not cover all the possibilities.) > > Likewise, > since the VR-to-VR connectivity can use tunnels, the inter-VR > routing protocol can be independent of the routing used in the > backbone network(s) over which the VR-based VPN runs. > > [md] I think it is a fundamental part of the VR model that the routing > within the VPN is independent of that in the shared backbone. So I'd > suggest rephrasing the above more strongly: > Likewise, since the VR-to-VR connectivity uses tunnels or > independent L2 links, the inter-VR routing is independent of > the network layer routing used in the backbone network(s) > over which the VR-based VPN runs. > [pk] The VR-VR routing can potentially use 2547bis (BGP/MPLS), in which case the inter-VR routing protocol is not independent of the backbone routing (although the VPN routing is still separate from the backbone routing information). Although this makes it nice for service provider transitions or interoperability, it also makes it difficult to phrase things very strongly! :^) I'll probably keep this as it is in the Introduction, but address it in more detail in section 5.3.2. > > There are two fundamental architectures for implementing network- > based VPNs: virtual routers (VR) and piggybacking. The main > > [md] s/network-based VPNs/network-based L3 VPNs/ > [pk] right > > 2.1 Membership > All virtual routers that are members of a specific VPN MUST share > the same VPN identifier (VPN-ID). This should be the Globally Unique > Identifier (GID) defined in [VPN-GID] or the VPN-ID format defined > in [VPN-RFC2685]. > > [md] Accommodating two mechanisms here just muddies the > water. Can we please choose one? > [pk] Yes, this has been made easier by the fact that the GID has been resolved in section 4.2.1 of the BGP auto-discovery draft (http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-bgpvpn-auto-05.txt) as equivalent to RFC 2685, so the reference will now be only to 2685. > > 2.2 Scalability > The use of the "backbone VR" (Section 5.3) improves > the scalability of the PE, since many VRs on the PE may use the > backbone VR for connectivity to other VPN sites. > > [md] s/to other VPN sites/to other routers or VRs within the VPN/ > [pk] No, since the backbone VR can be shared by multiple VPNs, this doesn't quite work... maybe: "many VRs on the PE may share a single "backbone VR" connection to peer VRs on another PE, rather than establishing multiple separate per-VR (i.e., per-VPN) connections between PEs." [pk] More on the backbone VR below... (I think this answers several later questions). > > 2.4 Auto-discovery > It is required that the auto- > discovery mechanism take into consideration the case where the VPNs > are implemented across administrative domains. We assume in this > document that an auto-discovery mechanism which provides services > similar to BGP (as described in [VPN-BGP]) is used as the mechanism > to distribute membership, topology, and tunnel information among VRs > which are members of the same VPN. > > [md] I don't see anything in this document that actually assumes that a > BGP-based discovery mechanism is used. The server-based approach of > draft-heinanen-radius-pe-discovery-04.txt seems to me at least as > attractive for use with VRs. In fact, I think that for those service > providers who chose a VR approach over a 2547 approach, not wanting to use > BGP for VPN support may be one of their primary motivations! I urge to > reference draft-heinanen in here also. > [pk] This is definitely an area where future work in VR may lead, but after discussing this with some other draft authors, we will not include this reference for several reasons: 1) Having two mechanisms defined can lead to interoperability issues (as noted above for VPN-ID) 2) There is not a draft describing how VR would use Radius (there is one for BGP Autodiscovery; the one cited above) 3) As far as we know, there is no implementation of VR using Radius (there are implementations using BGP Autodiscovery), and as a proposed standard, the existence of implementations is quite important 4) As of this writing, the radius draft is not accepted as a working group document (and Juha's unavailability as a future "shepherd" may weaken its chances). > > 2.5.1 Routing between PE and CE > The routing protocol between the PE > and the CE can be independent of the PE-to-PE routing. > > [md] s/PE-to-PE/VR-to-VR/ > [pk] Yes, I think the VR and PE terminology needs to be clarified in several places... Thanks! > > 2.5.3 Routing between PEs > Any existing routing protocol can be used between PEs. The routing > protocol between the PEs can be independent of the CE-to-PE routing. > As with any network design, care must be taken when multiple routing > protocols are used, due to differences in metrics, detail of > information, etc. > > [md] s/PEs/VRs/ (3 places in the above section, including the title) > [pk] yes > > 2.6 Security > The architecture MUST accommodate different levels of security for > data, routing, and other control information. > > [md] I hope this is intended to mean that different levels of security > must be accommodated, not that it must be possible to accommodate one level > for data and another level for routing. How about: > The architecture MUST accommodate security for VPN data, routing, > and other control information. Different levels of security must > be possible. > [pk] good! > > 2.7 Topology > For example, in the case where the internal nodes (P devices) are > also VR aware (NOTE this is not required - see section > 2.2) then it > is possible to have either tunnels from the PE or the CE > connecting > to these internal VRs. This type of VPN deployment can be useful > when the internal nodes are geographically suitable to be > a VPN hub. > > [md] I would argue that VR aware P devices are actually not > Ps at all but > PEs. So I suggest removing the above paragraph. > [pk] I agree, this needs clarifying... It may be best just to remove it. > > 2.8 Tunneling > It should be possible to use IPSec, GRE [RFC-1701], IP in > IP, and MPLS tunnels. > > [md] RFC 1701 is obsolescent. This should reference RFC 2784 > (proposed standard). > [pk] Agreed... > > It should also be possible to allow multiple > VPNs to share a tunnel across a backbone. Therefore within a single > VPN, different types of tunnels can be used. > > [md] I agree with the second sentence but I don't think it follows from the > first sentence. So s/Therefore//. [pk] yes, they are separate ideas. > > I think the first sentence is > misleading. What matters to the VPN architecture is the virtual "links" > seen by the VRs. These cannot be shared across multiple VPNs! The virtual > links (aka tunnel links) are facilitated by some tunnelling > mechanism. Some tunnelling mechanisms support one or more levels of > multiplexing within the tunnelling mechanism itself (e.g. MPLS with > multiple-label stacks, L2TP). Other tunnelling mechanisms do not > themselves provide multiplexing (e.g. IP-in-IP). The fact that the > tunnelling mechanism may use the word "tunnel" to refer to an outer > aggregate (outer LSP, L2TP tunnel) containing multiple virtual links (inner > label, L2TP session) is just a distraction. I propose deleting the first > sentence. > [pk] Actually, this is where a key function of the "backbone VR" comes into play. I can explain this using Figure 3 from the draft: PE PE +---------------+ +---------------+ +-----+ | | | | +-----+ |VPN-A| | +----+ MPLS/IP based Tunnels +----+ | |VPN-A| |sites|-|-|VR-A|\.......|<---------->|........|VR-A|-|-|sites| +-----+ | +----+ +----+ | --------- | +----+/+----+ | +-----+ | |VR-1|-|-(IP/MPLS )-|-|VR-2| | +-----+ | +----+/+----+ |(Backbones) | +----+\+----+ | +-----+ |VPN-B|-|-|VR-B| | --------- | |VR-B|-|-|VPN-B| |sites| | +----+........|<---------->|........+----+ | |sites| +-----+ | MPLS/IP based Tunnels | +-----+ | | | | +---------------+ +---------------+ Figure 3: VR-1 and VR-2 used as backbone VRs This diagram is not great; I should make it clearer. But I think we can use the current diagram for explaining how the backbone VR works. The lines are clearer looking at VR-B on each side. You can see that the VR-Bs can either set up an MPLS/IP based tunnel directly from one VR-B to the other... OR they can connect through VR-1 and VR-2, the backbone VRs. (Or do both simultaneously.) If they connect through the backbone VRs, then they can use a tunnel between VR-1 and VR-2. This tunnel can provide multiplexing for both VR-B to VR-B traffic and for VR-A to VR-A traffic. (in the same way that VR-B provides multiplexing for multiple VPN-B sites.) Let's look at the packet encapsulation from a VPN-B site on the left to a VPN-B site on the right: It gets encapsulated in VR-B(left), with a source of VR-B(left) and destination of VR-B(right). Then it is passed to VR-1, where it is encapsulated with a source of VR-1 and destination of VR-2. At VR-2, the outer encapsulation is removed, and the packet is routed to VR-B(right). There it is fully decapsulated and routed to a VPN-B site (right). It looks like the terminology and labeling need to be improved to simplify the description, and I should include a discussion like the one above in the draft. Also, I have used IP encapsulation in my example, but it could also have used MPLS labels... This also illustrates how the service provider can trade off greater scalability (the backbone VR) against higher value "personalized service" for VPN customers (the individual tunnels which may be provisioned with higher QOS). The key is that the "ordinary" VRs and the backbone VR can behave as if they were separate devices. The individual VRs in a PE (representing different VPNs) can relate to the backbone VR as if they were the CEs of a single VPN (with the backbone VR as the PE), so the VPNs can be multiplexed in a hierarchical fashion, using IP encapsulation or stacked labels. > > 3. Network Reference Model > A VPN customer site is connected to the provider backbone by means > of a connection between a Customer Edge (CE) device, (which can be a > bridge or a router) and a virtual router (VR). > > [md] s/can be a bridge or a router/can be one or more hosts > or and\/or routers/ Bridges and other layer 2 things should > be transparent to the VR > scheme. (See the 4th and 5th paragraph of section 1.2 of > draft-ietf-ppvpn-rfc2547bis-03.txt. I think it is equally > applicable to this.) > [pk] yes, I agree. > > 3.1 Backbone > Not all VPNs existing on the same PE are necessarily connected to > the same backbone. A single VPN can be built from multiple transport > technologies. > > [md] in general the VPNs are not "connected to" the backbone. > I would s/connected to the same backbone/using the same backbone/ > [pk] Okay... > > 4. Virtual Router Definition > A given VR holds the routes only for the specific VPN configured for > that VR. > > [md] s/configured for that VR/of which that VR is a member/ > [pk] yes, much clearer. > > 5. How VPNs are built and deployed using VRs > Three main VR deployment scenarios can be used for building virtual > private networks: > 1) VR to VR connectivity over a layer 2 connection. > 2) VR to VR connectivity tunneled over an IP or MPLS network. > 3) Aggregating multiple virtual routers over a "backbone virtual > router," which will provide connectivity over a layer 2, IP, or > MPLS network. > > [md] I believe that #2 and #3, as discussed in the following sections, are > one and the same thing and #3 should be dropped. More comments below. > [pk] No, I hope I've explained this above. > > The above VR deployment scenarios can coexist on a single PE and > they are not mutually exclusive. > > [md] s/on a single PE/ on a single PE and\/or within a single VPN/ > [pk] Good addition > > 5.2 VR to VR Connectivity through IP or MPLS tunnels > Although it is clearly possible to use a topology similar to the > layer-2 model over an IP or MPLS backbone, the VR capability can > support a different network deployment besides full mesh tunnels > between VRs. > > [md] By "layer-2 model" I presume you are referring to "VR to VR > Connectivity over Layer 2 Connections" as described in the preceding > section. There is nothing in that approach that requires a full mesh of > tunnels between VRs. The full mesh of tunnels may be used but is not > required, whether layer 2 connections or tunnelling over an IP or MPLS > backbone are used. > [pk] Yes, Layer 2 certainly does not imply full-mesh... I'll fix it. > > This is the creation (on each PE) of another VR facing > into the backbone network, which is used to build a kind of backbone > VPN that may be shared among multiple customer VPNs. This is > described below as the "backbone VR." > > [md] I do not understand the above text, nor section 5.3 "Virtual Router > Backbone Aggregation" which follows. I think they are talking about the > same approach as 5.2 "VR to VR Connectivity through IP or MPLS tunnels" > which is to say, the VPN packets are tunneled across a shared (i.e. used by > more than just one particular VPN) IP or MPLS backbone. Presumably the > "outer packets" formed by the tunnel encapsulation are sent and received in > the routing context, supported by the PE, that is the native routing > context of the backbone. We can call this the "default router", "public > router", "backbone VR" or whatever. But, this should all be true anytime > tunneling is used. I.e. 5.2 and 5.3 are actually about the same approach. No? > [pk] No, I hope the backbone VR is clearer after the explanation above. The backbone VR can add another layer of encapsulation or MPLS label. This also applies to the next point... > > 5.3.1 Tunneling > A tunnel can be established per VPN or shared among many > VPNs (VRs). > > [md] I do not believe the tunnel can be shared, unless you're taking > advantage of the ambiguity in the term "tunnel" and using it here to refer > to an aggregate entity containing multiple 'tunnel links'. See my comment > above at sect. 2.8. > > > The backbone VR makes it appear as if each VR within a VPN is > directly connected (full and partial mesh configurations supported). > Each VR within the VPN exchanges routing information directly with > the other VRs in the VPN. > > [md] s/with the other VRs/with the adjacent VRs/ > [pk] yes, the adjacent ones in the "overlay topology"... I'll reword this. > > Further work is needed to determine the requirements and usage of > the VPN-ID exchange within IPsec-based tunneling scenarios. > > [md] actually within any tunneling scenarios, not just IPsec-based. > [pk] agreed... The use of multiple encapsulations/labels has its limitations. > > 5.3.1.1 MPLS Tunnels > MPLS tunneling can be used in different forwarding scenarios. A > hierarchy of two labels can be used. One simple forwarding scenario > is where the inner label identifies the VR intended to receive the > private packet (to be forwarded to the CE). > > [md] ok so far, although no one has so much as written a draft about how > the labels would be distributed and bound to VPN-IDs for this case... > > > Another forwarding > scenario is to distribute the inner label on a per-VPN basis across > the tunnel. In this case the label distribution process can be > achieved using BGP or an existing label distribution protocol on a > per-VPN basis. The inner label relates to the private VPN prefix. > The label and reachability distribution is done through the tunnels. > On the egress side traffic will be directed to the egress interface > by looking up the inner label. > > [md] I cannot tell if this is talking about distributing 1 inner label per > VPN context, or one inner label per VPN route -- it seems to say both. And > how is the label distribution done through the tunnels? If MPLS is being > used to create the tunnels, they cannot exist until after the label has > been distributed. > [pk] The BGP auto-discovery draft describes more details of how this is done (see section 4.2), but I agree the context needs to be made more clear in the paragraph above. It is a three-step process: BGP can be used to carry tunnel endpoint (VR) addresses or labels, allowing the VRs to build tunnels between each other. Then they can exchange reachability (routes) across the tunnels. We may need to break out the label and route handling separately for clarity. > > [md] I think this section needs some rewriting. The key point in my mind > would be that MPLS technology is used to create tunnel links, whose > endpoints appear as logical IP interfaces to the routers (VRs) the tunnel > links terminate on. > [pk] I think that having the backbone VR tunnel up can facilitate the label exchange, so this may not be a case of lifting ourselves up by our bootstraps, but it clearly needs to be clearer. :^) > > 5.3.2 Routing > VPN sites exchange routing > information through the tunnels over the backbone. > > [md] That isn't correct. VPN sites exchange routing information with VRs > across CE-VR links, and VRs exchange routing information with adjacent VRs > in the same VPN across VR-VR links. (Though I'm not sure if all of that is > relevant in this section - maybe it is only trying to talk about the VR-VR > routing.) > [pk]Yes, it's referring to the VR-VR routing.. I'll clarify. > > 6. VPN Auto-Discovery > > [md] the above heading would tie better to the text if we s/VPN > Auto-Discovery/VPN Membership and Topology Auto-Discovery/ > [pk] yes, that's better > > VPN topology represents the set of PEs and their > interconnectivity within the VPN. The topology can be a full-mesh of > PEs, a hub and spoke, or anything in between. > > [md] s/PEs/VRs/ (2 occurrences) > [pk] yes, I think that works. > > VPN discovery can be achieved through different mechanisms, for > example: > > - Directory server approach, in which VRs query a server to > determine their neighbors. > > [md] draft-heinanen-radius-pe-discovery-04.txt would be good > to reference here. > [pk] Makes more sense here than in the "requirements" section above. > > In this document it is assumed that a mechanism that provides > services similar to BGP is used to achieve auto-discovery of VPN > members. As described in [VPN-BGP], VR addresses are exchanged, > along with the information needed to enable the PEs to determine > which VRs are in the same VPN ("membership"), and which of those VRs > are to have VPN connectivity ("topology"). > > [md] I don't think the document "assumes" BGP-based discovery in the sense > that anything else in the document depends on that. Please see my comment > at sect. 2.4. > [pk] We tried to avoid saying it had to be BGP ("provides services similar to BGP"), but it does need to exchange VR addresses, identify a VPN mapping, and specify the overlay topology. The existing auto-discovery implementations use this. > > It is important to note that, for the VR architecture, the auto- > discovery mechanism is only used to automatically exchange VPN > control information between VRs. > > [md] shouldn't that be s/between VRs/between PEs/ ? > [pk] Since there may be more than one VR in a PE running auto-discovery (potentially across multiple backbones) I think this should stay as it is. > > 8. VPNs across Domains > The main > requirement on the service provider in order to achieve end-to-end > cross-domain VPN connectivity is the ability for both domains to > support a common tunnel technology. > > [md] ... plus the ability to support a common membership and topology > discovery technology. > [pk] Agreed. > > Once the tunnel is established, > private data (e.g., routing information, and private customer data) > can flow from one domain to the other with the same level of > security as is provided in a single service provider network. > > [md] s/security/isolation/ ? > [pk] maybe, but people usually want security rather than just isolation. Maybe something like: "... same level of security or isolation as is provided by that tunnel mechanism when it is used entirely within a single service provider network." > > Another possible scenario is to use two virtual routers configured > on each PE at the interconnection point. > > [md] I would clarify that as follows: > Another possible scenario is to deploy PE devices at each side > of the interconnection point, with a virtual router configured > on each PE for each VPN that spans the interconnection point. > [pk] I think the VR-per-VPN may be overkill, depending on the granularity of filtering needed. The idea is not to terminate the VPNs, but to provide ingress/egress filtering for all the bidirectional tunneled VPN traffic crossing the boundary. The VPN traffic should be opaque at the boundary, so it would normally be filtered all-or-nothing (by VPN) based on the visible packet identifiers (which could be mapped to a VPN by each service provider, for instance using the VPN-ID). I'm not sure what other policies would be applied by the service providers on the VPN traffic transiting the boundary, but I don't think they would normally require a VR per VPN on the boundary. > > [md] I think this section (8) should also contain something > along the > lines of: > An important consideration for VPNs spanning multiple > administrative domains is whether the domains involved are > always adjacent or whether there may be intervening domains > that are unaware of the VPN. Transitive techniques such as > deploying VPN-aware PE devices at the domain boundaries will > not work in the latter type of case. > [pk] I think that as long as an IP or MPLS tunnel can be built across the intervening domains, it will be okay. The key point is whether tunnels can be built from end to end. The discussion of using VRs at the interconnection point is only intended to allow the service providers to provide ingress/egress filtering if they desire, but it is not needed for transporting the traffic. > > The ability to use a standard VPN-ID format also allows unambiguous > VPN identification across domains. > > [md] s/standard/standard, globally unique/ > [pk] yes, that's needed. > > 9. Internet Access > There are a number of ways to provide Internet access to a VPN using > the VR model. One way of providing VPN Internet access is to > configure the backbone VR to steer private traffic to the VPN VR, > and Internet traffic to the normal backbone/Internet forwarding > table. > > [md] I don't understand that. My understanding of the backbone router > concept is that the relationship between a tunnel link within a VPN and the > backbone is an overlay one -- VPN packets only enter the backbone after > being encapsulated in a backbone-context packet and vice versa for packets > in the other direction. See my comment at sect. 5.2. > [pk] Yes, I think this explanation needs more work. It's worth taking a few more sentences or paragraphs to describe at least one of the methods to support Internet access in detail. > > [md] An important way to provide Internet access, which I don't think is > included in the descriptions in this section, is simply to create a link > (real or virtual or internal or whatever) between the VPN-context VR and > any router (or virtual router) that is in the Internet context. Note that > this would be a routing adjacency relationship between the VPN and Internet > (virtual) routers as opposed to the overlay relationship used to tunnel > packets across the Internet (or SP backbone). > [pk] Yes, this works, but I believe the goal of using the backbone VR is to provide some filtering functionality which can be shared among multiple VPNs. I think this could be clarified... But your key point of avoiding the overlay with its encapsulation is necessary. Thanks! > > 10. Carrier's Carrier Case > > [md] It is very difficult to understand this section. I think this is > because it is difficult to tell whether each use of the terms (VPN, CE, VPN > service, etc.) refers to entities in the carrier's network or the carrier's > carrier's network. > [pk] noted... I'll work on it. I think a diagram will help, too. > > 11. Operations and Management > In some > implementations, it may be possible for a VR to be "rebooted" by a > customer without affecting other VRs. > > [md] I suggest removing the words "by a customer", since it > might just as > well be the service provider or an attacker :-) that would > reboot the VR. > [pk] Yes, although that is a nice capability, the identity doesn't add to this draft. > > 11.2 Troubleshooting > This access may provide only the privilege to > monitor (with no privilege to change) the layer 3 status of the > customer's VPN. > > [md] s/VPN/VR/ ? > [pk] Well, it is the VR's view of the routing across the whole VPN (for instance, the OSPF LSDB). I'll try to clarify it. > > 13. Scalability > Only the PEs are handling the VPN type information. The internal > backbone routers (the P routers) are usually not VPN aware. > > [md] s/usually// (If it is VPN-aware than it _is_ a PE router.) > [pk] yes. [pk] Thanks a lot Mark!! ------_=_NextPart_001_01C32F91.53AD45B6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: WG LAST CALL on draft-ietf-ppvpn-vpn-vr-04.txt

Hi Mark,

Thanks for the detailed comments.  Many = responses below, marked [pk]...

> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com]<= /FONT>
> Sent: Wednesday, May 21, 2003 5:30 PM
> To: ppvpn@nortelnetworks.com; Knight, Paul = [BL60:1A00:EXCH]
> Subject: WG LAST CALL on = draft-ietf-ppvpn-vpn-vr-04.txt
>
>
> Hi, here are comments on = draft-ietf-ppvpn-vpn-vr-04.txt.
>
> General comment:  Use of the VR approach = in significant scale will require
> the use of tunneling mechanisms that = efficiently support many tunnel links
> between a given pair of PEs, with some = provision for binding a VPN-ID to
> each tunnel link.  This document = reasonably leaves that to other
> documents.  However, the wg has no effort = underway to produce
> any such documents.  :-(
>
[pk]  I think your draft (Framework for IPsec = Protected Virtual Links for PPVPNs, = draft-duffy-ppvpn-ipsec-vlink-00.txt) is a good first step in the = direction of looking at the options for binding VPN-ID to tunnel = links. 

[pk] However, it's clear from many of your comments = that the current VR draft has not fully communicated to you the = functionality of the "backbone VR," which provides an = efficient way to multiplex many "tunnel links" (although the = binding of the VPN-ID is usually not explicit).  I'll try to = address this below.

>
> In the Abstract, and similar text in the = Introduction:
>          = ;            = ;            = ;            = ;            = ;   Virtual
>     routers can be deployed = in different VPN configurations, direct VR
>     to VR connectivity = through layer-2 or by aggregating multiple VRs
>     into a single VR = combined with IP or MPLS based tunnels.
>
> [md] This idea of "aggregating multiple = VRs ..." seems confusing at the
> least.  (More comments on this below re = sect 5.)  How about "... through
> layer-2 or by tunneling over a shared IP or = MPLS based network."
>
[pk] The text quoted above (from the Abstract) is = unclear due to being condensed too much.  I'll re-word it (similar = to your suggestion).  The similar text in the Introduction is = correct:

   Virtual routers can be deployed in = various VPN
   configurations. Direct VR to VR = connectivity may be configured
   through layer-2 links or through a = variety of tunnel mechanisms,
   using IP- or MPLS-based tunnels. = Multiple VRs may be aggregated over
   a "backbone VR."
 
>
> 1. Introduction
>          = ;            = ;            = ;            = ;  That is, the routing
>     protocol between the = VRs may be the same or it might be different
>     than the routing = mechanism used between the CE and VR.
>
> [md]  "... or it may be a different = instance of the same protocol"   (The
> point being that if ospf is used CE-VR and = VR-VR, they may be the same
> instance, or separate instances with only = reachability (not topology)
> information redistributed between them.)
>
[pk] This is a good point, not explicit in the = draft.  I'll put it in section 2.5.1 or 2.5.3, in order to avoid = cluttering up the Introduction.  (The Introduction is not wrong, = but does not cover all the possibilities.)

>
>          = ;            = ;            = ;            = ;            = ;  Likewise,
>     since the VR-to-VR = connectivity can use tunnels, the inter-VR
>     routing protocol can be = independent of the routing used in the
>     backbone network(s) = over which the VR-based VPN runs.
>
> [md] I think it is a fundamental part of the VR = model that the routing
> within the VPN is independent of that in the = shared backbone.  So I'd
> suggest rephrasing the above more = strongly:
>     Likewise, since the = VR-to-VR connectivity uses tunnels or
>     independent L2 links, = the inter-VR routing is independent of
>     the network layer = routing used in the backbone network(s)
>     over which the VR-based = VPN runs.
>
[pk] The VR-VR routing can potentially use 2547bis = (BGP/MPLS), in which case the inter-VR routing protocol is not = independent of the backbone routing (although the VPN routing is still = separate from the backbone routing information).  Although this = makes it nice for service provider transitions or interoperability, it = also makes it difficult to phrase things very strongly!  :^)  = I'll probably keep this as it is in the Introduction, but address it in = more detail in section 5.3.2.

>
>     There are two = fundamental architectures for implementing network-
>     based VPNs: virtual = routers (VR) and piggybacking. The main
>
> [md] s/network-based VPNs/network-based L3 = VPNs/
>
[pk] right
>
> 2.1 Membership
>     All virtual routers = that are members of a specific VPN MUST share
>     the same VPN identifier = (VPN-ID). This should be the Globally Unique
>     Identifier (GID) = defined in [VPN-GID] or the VPN-ID format defined
>     in = [VPN-RFC2685].
>
> [md] Accommodating two mechanisms here just = muddies the
> water.  Can we please choose one?
>
[pk] Yes, this has been made easier by the fact that = the GID has been resolved in section 4.2.1 of the BGP auto-discovery = draft (http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-b= gpvpn-auto-05.txt) as equivalent to RFC 2685, so the reference will = now be only to 2685.

>
> 2.2 Scalability
>          = ;         The use of the = "backbone VR" (Section 5.3) improves
>     the scalability of the = PE, since many VRs on the PE may use the
>     backbone VR for = connectivity to other VPN sites.
>
> [md]  s/to other VPN sites/to other = routers or VRs within the VPN/
>
[pk] No, since the backbone VR can be shared by = multiple VPNs, this doesn't quite work... maybe: "many VRs on the = PE may share a single "backbone VR" connection to peer VRs on = another PE, rather than establishing multiple separate per-VR (i.e., = per-VPN) connections between PEs."

[pk] More on the backbone VR below... (I think this = answers several later questions).
>
> 2.4 Auto-discovery
>          = ;            = ;            = ;    It is required that the auto-
>     discovery mechanism = take into consideration the case where the VPNs
>     are implemented across = administrative domains. We assume in this
>     document that an = auto-discovery mechanism which provides services
>     similar to BGP (as = described in [VPN-BGP]) is used as the mechanism
>     to distribute = membership, topology, and tunnel information among VRs
>     which are members of = the same VPN.
>
> [md] I don't see anything in this document that = actually assumes that a
> BGP-based discovery mechanism is used.  = The server-based approach of
> draft-heinanen-radius-pe-discovery-04.txt seems = to me at least as
> attractive for use with VRs.  In fact, I = think that for those service
> providers who chose a VR approach over a 2547 = approach, not wanting to use
> BGP for VPN support may be one of their primary = motivations!  I urge to
> reference draft-heinanen in here also.
>
[pk] This is definitely an area where future work in = VR may lead, but after discussing this with some other draft authors, = we will not include this reference for several reasons:

1) Having two mechanisms defined can lead to = interoperability issues (as noted above for VPN-ID)
2) There is not a draft describing how VR would use = Radius (there is one for BGP Autodiscovery; the one cited above)
3) As far as we know, there is no implementation of = VR using Radius (there are implementations using BGP Autodiscovery), = and as a proposed standard, the existence of implementations is quite = important

4) As of this writing, the radius draft is not = accepted as a working group document (and Juha's unavailability as a = future "shepherd" may weaken its chances).

>
> 2.5.1 Routing between PE and CE
>          = ;            The = routing protocol between the PE
>     and the CE can be = independent of the PE-to-PE routing.
>
> [md] s/PE-to-PE/VR-to-VR/
>
[pk] Yes, I think the VR and PE terminology needs to = be clarified in several places... Thanks!
>
> 2.5.3 Routing between PEs
>     Any existing routing = protocol can be used between PEs. The routing
>     protocol between the = PEs can be independent of the CE-to-PE routing.
>     As with any network = design, care must be taken when multiple routing
>     protocols are used, due = to differences in metrics, detail of
>     information, = etc.
>
> [md]  s/PEs/VRs/  (3 places in the = above section, including the title)
>
[pk] yes
>
> 2.6 Security
>     The architecture MUST = accommodate different levels of security for
>     data, routing, and = other control information.
>
> [md]  I hope this is intended to mean that = different levels of security
> must be accommodated, not that it must be = possible to accommodate one level
> for data and another level for routing.  = How about:
>     The architecture MUST = accommodate security for VPN data, routing,
>     and other control = information.  Different levels of security must
>     be possible.
>
[pk] good! 
>
> 2.7 Topology
>     For example, in the = case where the internal nodes (P devices) are
>     also VR aware (NOTE = this is not required - see section
> 2.2) then it
>     is possible to have = either tunnels from the PE or the CE
> connecting
>     to these internal VRs. = This type of VPN deployment can be useful
>     when the internal nodes = are geographically suitable to be
> a VPN hub.
>
> [md] I would argue that VR aware P devices are = actually not
> Ps at all but
> PEs.  So I suggest removing the above = paragraph.
> 
[pk] I agree, this needs clarifying... It may be = best just to remove it.
>
> 2.8 Tunneling
>          = ;      It should be possible to use IPSec, GRE = [RFC-1701], IP in
>     IP, and MPLS = tunnels.
>
> [md] RFC 1701 is obsolescent.  This should = reference RFC 2784
> (proposed standard).
>
[pk] Agreed...
>
>          It = should also be possible to allow multiple
>     VPNs to share a tunnel = across a backbone.  Therefore within a single
>     VPN, different types of = tunnels can be used.
>
> [md] I agree with the second sentence but I = don't think it follows from the
> first sentence.  So = s/Therefore//.  
[pk] yes, they are separate ideas.
>
> I think the first sentence is
> misleading.  What matters to the VPN = architecture is the virtual "links"
> seen by the VRs.  These cannot be shared = across multiple VPNs!  The virtual
> links (aka tunnel links) are facilitated by = some tunnelling
> mechanism.  Some tunnelling mechanisms = support one or more levels of
> multiplexing within the tunnelling mechanism = itself (e.g. MPLS with
> multiple-label stacks, L2TP).  Other = tunnelling mechanisms do not
> themselves provide multiplexing (e.g. = IP-in-IP).  The fact that the
> tunnelling mechanism may use the word = "tunnel" to refer to an outer
> aggregate (outer LSP, L2TP tunnel) containing = multiple virtual links (inner
> label, L2TP session) is just a = distraction.  I propose deleting the first
> sentence.
>
[pk] Actually, this is where a key function of the = "backbone VR" comes into play.  I can explain this using = Figure 3 from the draft:

          &nb= sp;     = PE           &nbs= p;           &nbs= p;    PE
         = +---------------+         &= nbsp;  +---------------+
 +-----+ = |            = ;   = |            = |            = ;   | +-----+
 |VPN-A| | +----+     = MPLS/IP based Tunnels    +----+ | |VPN-A|
 |sites|-|-|VR-A|\.......|<---------->|........|VR-A= |-|-|sites|
 +-----+ | +----+ +----+ | ---------  | = +----+/+----+ | +-----+
         = |        |VR-1|-|-(IP/MPLS = )-|-|VR-2|        |
 +-----+ | +----+/+----+ |(Backbones) | = +----+\+----+ | +-----+
 |VPN-B|-|-|VR-B|       = ; | ---------  |        = |VR-B|-|-|VPN-B|
 |sites| | = +----+........|<---------->|........+----+ | |sites|
 +-----+ = |           MPLS/IP = based = Tunnels           = ; | +-----+
         = |            = ;   = |            = |            = ;   |
         = +---------------+         &= nbsp;  +---------------+
   
          &nb= sp; Figure 3: VR-1 and VR-2 used as backbone VRs

This diagram is not great; I should make it = clearer.  But I think we can use the current diagram for = explaining how the backbone VR works.

The lines are clearer looking at VR-B on each = side.  You can see that the VR-Bs can either set up an MPLS/IP = based tunnel directly from one VR-B to the other...  OR they can = connect through VR-1 and VR-2, the backbone VRs.  (Or do both = simultaneously.)  If they connect through the backbone VRs, then = they can use a tunnel between VR-1 and VR-2.  This tunnel can = provide multiplexing for both VR-B to VR-B traffic and for VR-A to VR-A = traffic.  (in the same way that VR-B provides multiplexing for = multiple VPN-B sites.)

Let's look at the packet encapsulation from a VPN-B = site on the left to a VPN-B site on the right: It gets encapsulated in = VR-B(left), with a source of VR-B(left) and destination of = VR-B(right).  Then it is passed to VR-1, where it is encapsulated = with a source of VR-1 and destination of VR-2.  At VR-2, the outer = encapsulation is removed, and the packet is routed to = VR-B(right).  There it is fully decapsulated and routed to a VPN-B = site (right).

It looks like the terminology and labeling need to be = improved to simplify the description, and I should include a discussion = like the one above in the draft. Also, I have used IP encapsulation in = my example, but it could also have used MPLS labels...

This also illustrates how the service provider can = trade off greater scalability (the backbone VR) against higher value = "personalized service" for VPN customers (the individual = tunnels which may be provisioned with higher QOS).

The key is that the "ordinary" VRs and the = backbone VR can behave as if they were separate devices.  The = individual VRs in a PE (representing different VPNs) can relate to the = backbone VR as if they were the CEs of a single VPN (with the backbone = VR as the PE), so the VPNs can be multiplexed in a hierarchical = fashion, using IP encapsulation or stacked labels. 

 
>
> 3. Network Reference Model
>     A VPN customer site is = connected to the provider backbone by means
>     of a connection between = a Customer Edge (CE) device, (which can be a
>     bridge or a router) and = a virtual router (VR).
>
> [md] s/can be a bridge or a router/can be one = or more hosts
> or and\/or routers/ Bridges and other layer 2 = things should
> be transparent to the VR
> scheme.  (See the 4th and 5th paragraph of = section 1.2 of
> draft-ietf-ppvpn-rfc2547bis-03.txt.  I = think it is equally
> applicable to this.)
>
[pk] yes, I agree. 
>
> 3.1 Backbone
>     Not all VPNs existing = on the same PE are necessarily connected to
>     the same backbone. A = single VPN can be built from multiple transport
>     technologies.
>
> [md] in general the VPNs are not = "connected to" the backbone.
>  I would s/connected to the same = backbone/using the same backbone/
>
[pk] Okay...
>
> 4. Virtual Router Definition
>     A given VR holds the = routes only for the specific VPN configured for
>     that VR.
>
> [md] s/configured for that VR/of which that VR = is a member/
>
[pk] yes, much clearer.
>
> 5. How VPNs are built and deployed using = VRs
>     Three main VR = deployment scenarios can be used for building virtual
>     private = networks:
>     1) VR to VR = connectivity over a layer 2 connection.
>     2) VR to VR = connectivity tunneled over an IP or MPLS network.
>     3) Aggregating multiple = virtual routers over a "backbone virtual
>       = router," which will provide connectivity over a layer 2, IP, = or
>       MPLS = network.
>
> [md] I believe that #2 and #3, as discussed in = the following sections, are
> one and the same thing and #3 should be = dropped.  More comments below.
>
[pk]  No, I hope I've explained this above. =
>
>     The above VR deployment = scenarios can coexist on a single PE and
>     they are not mutually = exclusive.
>
> [md] s/on a single PE/ on a single PE and\/or = within a single VPN/
>
[pk]  Good addition
>
> 5.2 VR to VR Connectivity through IP or MPLS = tunnels
>     Although it is clearly = possible to use a topology similar to the
>     layer-2 model over an = IP or MPLS backbone, the VR capability can
>     support a different = network deployment besides full mesh tunnels
>     between VRs.
>
> [md]  By "layer-2 model" I = presume you are referring to "VR to VR
> Connectivity over Layer 2 Connections" as = described in the preceding
> section.  There is nothing in that = approach that requires a full mesh of
> tunnels between VRs.  The full mesh of = tunnels may be used but is not
> required, whether layer 2 connections or = tunnelling over an IP or MPLS
> backbone are used.
>
[pk] Yes, Layer 2 certainly does not imply = full-mesh... I'll fix it.
>
>     This is the creation = (on each PE) of another VR facing
>     into the backbone = network, which is used to build a kind of backbone
>     VPN that may be shared = among multiple customer VPNs. This is
>     described below as the = "backbone VR."
>
> [md] I do not understand the above text, nor = section 5.3 "Virtual Router
> Backbone Aggregation" which follows.  = I think they are talking about the
> same approach as 5.2 "VR to VR = Connectivity through IP or MPLS tunnels"
> which is to say, the VPN packets are tunneled = across a shared (i.e. used by
> more than just one particular VPN) IP or MPLS = backbone.  Presumably the
> "outer packets" formed by the tunnel = encapsulation are sent and received in
> the routing context, supported by the PE, that = is the native routing
> context of the backbone.  We can call this = the "default router", "public
> router", "backbone VR" or = whatever.  But, this should all be true anytime
> tunneling is used.  I.e. 5.2 and 5.3 are = actually about the same approach.  No?
>
[pk]  No, I hope the backbone VR is clearer = after the explanation above. The backbone VR can add another layer of = encapsulation or MPLS label.  This also applies to the next = point...

>
> 5.3.1 Tunneling
>     A tunnel can be = established per VPN or shared among many
> VPNs (VRs).
>
> [md] I do not believe the tunnel can be shared, = unless you're taking
> advantage of the ambiguity in the term = "tunnel" and using it here to refer
> to an aggregate entity containing multiple = 'tunnel links'.  See my comment
> above at sect. 2.8.
>
>
>     The backbone VR makes = it appear as if each VR within a VPN is
>     directly connected = (full and partial mesh configurations supported).
>     Each VR within the VPN = exchanges routing information directly with
>     the other VRs in the = VPN.
>
> [md] s/with the other VRs/with the adjacent = VRs/
>
[pk]  yes, the adjacent ones in the = "overlay topology"...  I'll reword this.
>
>     Further work is needed = to determine the requirements and usage of
>     the VPN-ID exchange = within IPsec-based tunneling scenarios.
>
> [md] actually within any tunneling scenarios, = not just IPsec-based.
>
[pk] agreed... The use of multiple = encapsulations/labels has its limitations.
>
> 5.3.1.1 MPLS Tunnels
>     MPLS tunneling can be = used in different forwarding scenarios. A
>     hierarchy of two labels = can be used. One simple forwarding scenario
>     is where the inner = label identifies the VR intended to receive the
>     private packet (to be = forwarded to the CE).
>
> [md] ok so far, although no one has so much as = written a draft about how
> the labels would be distributed and bound to = VPN-IDs for this case...
>
>
>          = ;            = ;            = ;            = ;   Another forwarding
>     scenario is to = distribute the inner label on a per-VPN basis across
>     the tunnel. In this = case the label distribution process can be
>     achieved using BGP or = an existing label distribution protocol on a
>     per-VPN basis. The = inner label relates to the private VPN prefix.
>     The label and = reachability distribution is done through the tunnels.
>     On the egress side = traffic will be directed to the egress interface
>     by looking up the inner = label.
>
> [md]  I cannot tell if this is talking = about distributing 1 inner label per
> VPN context, or one inner label per VPN route = -- it seems to say both.  And
> how is the label distribution done through the = tunnels?  If MPLS is being
> used to create the tunnels, they cannot exist = until after the label has
> been distributed.
>
[pk]  The BGP auto-discovery draft describes = more details of how this is done (see section 4.2), but I agree the = context needs to be made more clear in the paragraph above.  It is = a three-step process: BGP can be used to carry tunnel endpoint (VR) = addresses or labels, allowing the VRs to build tunnels between each = other.  Then they can exchange reachability (routes) across the = tunnels.  We may need to break out the label and route handling = separately for clarity.

>
> [md] I think this section needs some = rewriting.  The key point in my mind
> would be that MPLS technology is used to create = tunnel links, whose
> endpoints appear as logical IP interfaces to = the routers (VRs) the tunnel
> links terminate on.
>
[pk] I think that having the backbone VR tunnel up = can facilitate the label exchange, so this may not be a case of lifting = ourselves up by our bootstraps, but it clearly needs to be = clearer.  :^)

>
> 5.3.2 Routing
>          = ;            = ;        VPN sites exchange = routing
>     information through the = tunnels over the backbone.
>
> [md] That isn't correct.  VPN sites = exchange routing information with VRs
> across CE-VR links, and VRs exchange routing = information with adjacent VRs
> in the same VPN across VR-VR links.  = (Though I'm not sure if all of that is
> relevant in this section - maybe it is only = trying to talk about the VR-VR
> routing.)
>
[pk]Yes, it's referring to the VR-VR routing.. I'll = clarify.
>
> 6. VPN Auto-Discovery
>
> [md] the above heading would tie better to the = text if we s/VPN
> Auto-Discovery/VPN Membership and Topology = Auto-Discovery/
>
[pk] yes, that's better 
>
>          = ;           VPN = topology represents the set of PEs and their
>     interconnectivity = within the VPN. The topology can be a full-mesh of
>     PEs, a hub and spoke, = or anything in between.
>
> [md] s/PEs/VRs/    (2 = occurrences)
>
[pk] yes, I think that works.
>
>     VPN discovery can be = achieved through different mechanisms, for
>     example:
>
>     - Directory server = approach, in which VRs query a server to
>     determine their = neighbors.
>
> [md] draft-heinanen-radius-pe-discovery-04.txt = would be good
> to reference here.
>
[pk] Makes more sense here than in the = "requirements" section above.
>
>     In this document it is = assumed that a mechanism that provides
>     services similar to BGP = is used to achieve auto-discovery of VPN
>     members. As described = in [VPN-BGP], VR addresses are exchanged,
>     along with the = information needed to enable the PEs to determine
>     which VRs are in the = same VPN ("membership"), and which of those VRs
>     are to have VPN = connectivity ("topology").
>
> [md] I don't think the document = "assumes" BGP-based discovery in the sense
> that anything else in the document depends on = that.  Please see my comment
> at sect. 2.4.
>
[pk]  We tried to avoid saying it had to be BGP = ("provides services similar to BGP"), but it does need to = exchange VR addresses, identify a VPN mapping, and specify the overlay = topology.  The existing auto-discovery implementations use = this.

>
>     It is important to note = that, for the VR architecture, the auto-
>     discovery mechanism is = only used to automatically exchange VPN
>     control information = between VRs.
>
> [md] shouldn't that be  s/between = VRs/between PEs/  ?
>
[pk] Since there may be more than one VR in a PE = running auto-discovery (potentially across multiple backbones) I think = this should stay as it is.

>
> 8. VPNs across Domains
>          = ;            = ;            = ;            = ;            The = main
>     requirement on the = service provider in order to achieve end-to-end
>     cross-domain VPN = connectivity is the ability for both domains to
>     support a common tunnel = technology.
>
> [md]  ... plus the ability to support a = common membership and topology
> discovery technology.
>
[pk] Agreed.
>
>          = ;            = ;          Once the tunnel = is established,
>     private data (e.g., = routing information, and private  customer data)
>     can flow from one = domain to the other with the same level of
>     security as is provided = in a single service provider network.
>
> [md]  s/security/isolation/  ?
>
[pk] maybe, but people usually want security rather = than just isolation.  Maybe something like:
"... same level of security or isolation as is = provided by that tunnel mechanism when it is used entirely within a = single service provider network."

>
>     Another possible = scenario is to use two virtual routers configured
>     on each PE at the = interconnection point.
>
> [md] I would clarify that as follows:
>     Another possible = scenario is to deploy PE devices at each side
>     of the interconnection = point, with a virtual router configured
>     on each PE for each VPN = that spans the interconnection point.
>
[pk] I think the VR-per-VPN may be overkill, = depending on the granularity of filtering needed.  The idea is not = to terminate the VPNs, but to provide ingress/egress filtering for all = the bidirectional tunneled VPN traffic crossing the boundary.  The = VPN traffic should be opaque at the boundary, so it would normally be = filtered all-or-nothing (by VPN) based on the visible packet = identifiers (which could be mapped to a VPN by each service provider, = for instance using the VPN-ID).  I'm not sure what other policies = would be applied by the service providers on the VPN traffic transiting = the boundary, but I don't think they would normally require a VR per = VPN on the boundary.

>
> [md]  I think this section (8) should also = contain something
> along the
> lines of:
>     An important = consideration for VPNs spanning multiple
>     administrative domains = is whether the domains involved are
>     always adjacent or = whether there may be intervening domains
>     that are unaware of the = VPN.  Transitive techniques such as
>     deploying VPN-aware PE = devices at the domain boundaries will
>     not work in the latter = type of case.
>
[pk] I think that as long as an IP or MPLS tunnel = can be built across the intervening domains, it will be okay.  The = key point is whether tunnels can be built from end to end.  The = discussion of using VRs at the interconnection point is only intended = to allow the service providers to provide ingress/egress filtering if = they desire, but it is not needed for transporting the = traffic.

>
>     The ability to use a = standard VPN-ID format also allows unambiguous
>     VPN identification = across domains.
>
> [md] s/standard/standard, globally = unique/
>
[pk] yes, that's needed.
>
> 9. Internet Access
>     There are a number of = ways to provide Internet access to a VPN using
>     the VR model. One way = of providing VPN Internet access is to
>     configure the backbone = VR to steer private traffic to the VPN VR,
>     and Internet traffic to = the normal backbone/Internet forwarding
>     table.
>
> [md] I don't understand that.  My = understanding of the backbone router
> concept is that the relationship between a = tunnel link within a VPN and the
> backbone is an overlay one -- VPN packets only = enter the backbone after
> being encapsulated in a backbone-context packet = and vice versa for packets
> in the other direction.  See my comment at = sect. 5.2.
>
[pk] Yes, I think this explanation needs more = work.  It's worth taking a few more sentences or paragraphs to = describe at least one of the methods to support Internet access in = detail.

>
> [md] An important way to provide Internet = access, which I don't think is
> included in the descriptions in this section, = is simply to create a link
> (real or virtual or internal or whatever) = between the VPN-context VR and
> any router (or virtual router) that is in the = Internet context.  Note that
> this would be a routing adjacency relationship = between the VPN and Internet
> (virtual) routers as opposed to the overlay = relationship used to tunnel
> packets across the Internet (or SP = backbone).
>
[pk] Yes, this works, but I believe the goal of = using the backbone VR is to provide some filtering functionality which = can be shared among multiple VPNs.  I think this could be = clarified...

But your key point of avoiding the overlay with its = encapsulation is necessary.  Thanks!
>
> 10. Carrier's Carrier Case
>
> [md]  It is very difficult to understand = this section.  I think this is
> because it is difficult to tell whether each = use of the terms (VPN, CE, VPN
> service, etc.) refers to entities in the = carrier's network or the carrier's
> carrier's network.
>
[pk] noted... I'll work on it.  I think a = diagram will help, too.
>
> 11. Operations and Management
>          = ;            = ;            = ;            = ;    In some
>     implementations, it may = be possible for a VR to be "rebooted" by a
>     customer without = affecting other VRs.
>
> [md] I suggest removing the words "by a = customer", since it
> might just as
> well be the service provider or an attacker :-) = that would
> reboot the VR.
>
[pk] Yes, although that is a nice capability, the = identity doesn't add to this draft.
>
> 11.2 Troubleshooting
>          = ;            = ;     This access may provide only the privilege = to
>     monitor (with no = privilege to change) the layer 3 status of the
>     customer's VPN.
>
> [md] s/VPN/VR/   ?
>
[pk] Well, it is the VR's view of the routing across = the whole VPN (for instance, the OSPF LSDB).  I'll try to clarify = it.

>
> 13. Scalability
>     Only the PEs are = handling the VPN type information. The internal
>     backbone routers (the P = routers) are usually not VPN aware.
>
> [md] s/usually//    (If it is = VPN-aware than it _is_ a PE router.)
>
[pk] yes.

[pk]  Thanks a lot Mark!!

------_=_NextPart_001_01C32F91.53AD45B6-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 19:06:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22185 for ; Tue, 10 Jun 2003 19:06:27 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5AN5tq13380 for ; Tue, 10 Jun 2003 19:05:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5AN5qo07796 for ; Tue, 10 Jun 2003 19:05:53 -0400 (EDT) Message-Id: <200306102302.h5AN25709403@mail.csaprc.com> Date: Wed, 11 Jun 2003 06:59:12 GMT From: 6677jimohlawal@primposta.com X-Priority: 3 To: radko.istenic@ijs.si Subject: acquisition Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: mail.csaprc.com X-SMTP-MAIL-FROM: 6677jimohlawal@primposta.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [210.5.9.9] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Dear sir/Madam ASSISTANCE REQUIRED FOR ACQUISITION OF ESTATES. I write to inform you of my desire to acquire estates or landed properties in your country on behalf of the Director of Contracts and Finance Allocation, of the Federal Ministry of works and Housing in Nigeria. Considering his very strategic and influential position, he would want the transaction to be strictly as confidential as possible. He further want his identity to remain undisclosed at least for now, until the completion of the transaction. Hence our desire to have an overseas agent. I have therefore been directed to inquire if you would agree to act as our overseas agent in order to actualise this transaction. The deal in brief is that the funds with which to carry out our proposed investments in your country is presently in a coded account in the Nigerian apex bank and we need your assistance to transfer the funds to your country or any safe account outside your country in a convenient bank account that will be provided by you before we can put the funds into use. For this you shall be considered to have executed a contract for the ministry. The contract sum of which shall run into US15.5Million of which your share shall be 25% if you agree to be our overseas agent. Your area of specialisation does not matter in this transaction, all that is required of you is a safe account and your willingness to assist us acquire estates in your country As soon as payment is effected and the amount mentioned above is successfully transferred into your account, we intend to use our own share in acquiring some estates abroad. For this too, you shall serve as our agent . It might interest you to note that last year, a similar transaction was carried out with one MR. LI WAI of Taiwan but after securing the payment approvals, and payment effected, MR.LI WAI changed his numbers and addresses, and was no where to be found on our getting to Taiwan. That was how we lost US$1.5Million. So this time around , I will be with you before the remmittance is made into your provided account to avoid future occurrence and allow trust to play a very minimal role until performance is seen. You are requested to communicate your acceptance or otherwise of this proposal,after which we shall discuss in details the modalities for seeing this transaction through. If however, you are not disposed to assist, kindly destroy this letter in view of the confidentiality of the proposed transaction and interest of personalities involved. Thank you in anticipation of your co-operation. Best Regard, Jimoh Lawal From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 21:14:04 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25298 for ; Tue, 10 Jun 2003 21:14:04 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B1DXq04395 for ; Tue, 10 Jun 2003 21:13:33 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B1DUM29567 for ; Tue, 10 Jun 2003 21:13:30 -0400 (EDT) Message-ID: From: "Ignacio Lynch" To: Subject: Ppvpn,Take control Date: Wed, 11 Jun 03 04:03:43 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".39B0E6084B." X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: NCABRERA-DT X-SMTP-MAIL-FROM: starfires@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [200.93.15.175] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --.39B0E6084B. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
&nbs= p; Current Low Interest Rates Create Win-Win for Homeowners!
 
Could this b= e a good time to pull some equity cash out of your home o= r just
take advantage of these lower rates to substantially <= FONT face=3DArial>reduce your monthly payments.
 
It's quick and simple to see what's avail= able and then decide if this makes
any sense for you personally. Of course t= here is not a charge or any obligation
for taking advantage of this online insta-quote service.
 
 
          &= nbsp;            Start here for = a fast quote and
=            = ;           monthly savings calculation
 
 
           The= re may be no other way to so quickly and easily
           = ;            &= nbsp;    slash your monthly expenses!
irrefutable= clearheaded
bistable finch holt deform actuate apropos
infinitum barycentric compacter
 
 
 
 
 
 
 
 
 
 
 
 
 
 
< --.39B0E6084B.-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 21:17:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25385 for ; Tue, 10 Jun 2003 21:17:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B1Gqq08936 for ; Tue, 10 Jun 2003 21:16:52 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B1GnO04824 for ; Tue, 10 Jun 2003 21:16:49 -0400 (EDT) Message-ID: From: "Danial Harris" To: Subject: Ppvpn,why wait? Date: Tue, 10 Jun 03 22:04:04 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C76B9_.AE2.0" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: DL380B X-SMTP-MAIL-FROM: stateman@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [208.144.210.27] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --C76B9_.AE2.0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
&nbs= p; Current Low Interest Rates Create Win-Win for Homeowners!
 
Could this b= e a good time to pull some equity cash out of your home o= r just
take advantage of these lower rates to substantially <= FONT face=3DArial>reduce your monthly payments.
 
It's quick and simple to see what's avail= able and then decide if this makes
any sense for you personally. Of course t= here is not a charge or any obligation
for taking advantage of this online insta-quote service.
 
 
          &= nbsp;            Start here for = a fast quote and
=            = ;           monthly savings calculation
 
 
           The= re may be no other way to so quickly and easily
           = ;            &= nbsp;    slash your monthly expenses!
involuntary= annuli
diagnosis civil detract breakage bowline eye
europa figural homo
 
 
 
 
 
 
 
 
 
 
 
 
 
 
< --C76B9_.AE2.0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 21:20:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25498 for ; Tue, 10 Jun 2003 21:20:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B1JTq12595 for ; Tue, 10 Jun 2003 21:19:29 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B1JQO09019 for ; Tue, 10 Jun 2003 21:19:27 -0400 (EDT) Message-ID: <5j1$5g6r$9$e3-80t7$39@98vfp6wsc7> From: "Sean Slater" To: Subject: Ppvpn,why wait? Date: Wed, 11 Jun 03 02:06:32 GMT X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".39B0E6084B." X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: host219-0.pool217172202.interbusiness.it X-SMTP-MAIL-FROM: starkisd@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: host219-0.pool217172202.interbusiness.it [217.172.202.219] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --.39B0E6084B. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
&nbs= p; Current Low Interest Rates Create Win-Win for Homeowners!
 
Could this b= e a good time to pull some equity cash out of your home o= r just
take advantage of these lower rates to substantially <= FONT face=3DArial>reduce your monthly payments.
 
It's quick and simple to see what's avail= able and then decide if this makes
any sense for you personally. Of course t= here is not a charge or any obligation
for taking advantage of this online insta-quote service.
 
 
          &= nbsp;            Start here for = a fast quote and
=            = ;           monthly savings calculation
 
 
           The= re may be no other way to so quickly and easily
           = ;            &= nbsp;    slash your monthly expenses!
lottery= troutman
useful betty negligible anachronistic combine conversion
defiant commute utopia
 
 
 
 
 
 
 
 
 
 
 
 
 
 
< --.39B0E6084B.-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 21:20:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25536 for ; Tue, 10 Jun 2003 21:20:57 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B1KPq13904 for ; Tue, 10 Jun 2003 21:20:25 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B1KMO10508 for ; Tue, 10 Jun 2003 21:20:22 -0400 (EDT) Message-ID: <61kr8-j4y7u-dv$-p$-8x@mll0t4> From: "Drew Currie" To: Subject: Ppvpn,a simple answer Date: Wed, 11 Jun 03 04:00:20 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".39B0E6084B." X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: ntt2-ppp284.gunma.sannet.ne.jp X-SMTP-MAIL-FROM: stavoe@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: ntt2-ppp284.gunma.sannet.ne.jp [211.133.181.30] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --.39B0E6084B. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
&nbs= p; Current Low Interest Rates Create Win-Win for Homeowners!
 
Could this b= e a good time to pull some equity cash out of your home o= r just
take advantage of these lower rates to substantially <= FONT face=3DArial>reduce your monthly payments.
 
It's quick and simple to see what's avail= able and then decide if this makes
any sense for you personally. Of course t= here is not a charge or any obligation
for taking advantage of this online insta-quote service.
 
 
          &= nbsp;            Start here for = a fast quote and
=            = ;           monthly savings calculation
 
 
           The= re may be no other way to so quickly and easily
           = ;            &= nbsp;    slash your monthly expenses!
headquarters= quadrilateral
sliver leisure salesmen clone bipolar paragon
drumlin pyongyang demurred
 
 
 
 
 
 
 
 
 
 
 
 
 
 
< --.39B0E6084B.-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 21:22:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25559 for ; Tue, 10 Jun 2003 21:22:54 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B1MNq16638 for ; Tue, 10 Jun 2003 21:22:23 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B1MKO13668 for ; Tue, 10 Jun 2003 21:22:21 -0400 (EDT) Message-ID: <54-$9h0joz7c8$m6q3--4gw-4z9@0mos.ic> From: "Christopher Elder" To: Subject: Ppvpn,you decide Date: Tue, 10 Jun 03 23:07:04 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C76B9_.AE2.0" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: PREFERRE-6B863D X-SMTP-MAIL-FROM: stcamry91@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com,ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [65.82.123.135] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --C76B9_.AE2.0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
&nbs= p; Current Low Interest Rates Create Win-Win for Homeowners!
 
Could this b= e a good time to pull some equity cash out of your home o= r just
take advantage of these lower rates to substantially <= FONT face=3DArial>reduce your monthly payments.
 
It's quick and simple to see what's avail= able and then decide if this makes
any sense for you personally. Of course t= here is not a charge or any obligation
for taking advantage of this online insta-quote service.
 
 
          &= nbsp;            Start here for = a fast quote and
=            = ;           monthly savings calculation
 
 
           The= re may be no other way to so quickly and easily
           = ;            &= nbsp;    slash your monthly expenses!
hickey= cochineal
writhe piazza zealot rapture malocclusion levee
methyl vendor capitol
 
 
 
 
 
 
 
 
 
 
 
 
 
 
< --C76B9_.AE2.0-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 22:08:49 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26296 for ; Tue, 10 Jun 2003 22:08:49 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B28Hq14415 for ; Tue, 10 Jun 2003 22:08:17 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B28E607636 for ; Tue, 10 Jun 2003 22:08:14 -0400 (EDT) Message-ID: <029r3$$fz1755o5-$8t$$f-23@kxw.ikd.zdqr0> From: "Concepcion Aragon" <4p045k4y1oao@mymail2u.net> To: Subject: Gives energy and burns fat. y Date: Wed, 11 Jun 03 16:56:42 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D.D4D48C_73_0..4" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: ip68-103-122-30.ks.ok.cox.net X-SMTP-MAIL-FROM: 4p045k4y1oao@mymail2u.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: ip68-103-122-30.ks.ok.cox.net [68.103.122.30] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --D.D4D48C_73_0..4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Our product is doctor endorsed.


10= 0% Herbal, HGH is proven to...
<= /font>


  • Reduces Wrinkles
  • Reduces Hairloss
  • Burns Fat
  • Increases Energ= y
  • Increases Memor= y
  • Increases Stam= ina


    • Click To Learn Mo= re
     po p ohufngxx aj b ftvver xb pmmebza g rkyis hoczwb hzrlup nlbiq --D.D4D48C_73_0..4-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 22:11:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26355 for ; Tue, 10 Jun 2003 22:11:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B2B3q18130 for ; Tue, 10 Jun 2003 22:11:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B2Aw612179 for ; Tue, 10 Jun 2003 22:10:58 -0400 (EDT) Message-ID: From: "Milton Vance" <7v93xsli4gt@mymail2u.biz> To: Subject: Look and feel years younger. zoskh n rwhnqtipva Date: Wed, 11 Jun 03 14:55:47 GMT X-Mailer: Microsoft Outlook Express 5.00.2615.200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2A1_5FA0_010.B.487B" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: adsl-67-65-17-132.dsl.austtx.swbell.net X-SMTP-MAIL-FROM: 7v93xsli4gt@mymail2u.biz X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: adsl-67-65-17-132.dsl.austtx.swbell.net [67.65.17.132] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --2A1_5FA0_010.B.487B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

    Our product is doctor endorsed.


    10= 0% Herbal, HGH is proven to...
    <= /font>


    • Reduces Wrinkles
    • Reduces Hairloss
    • Burns Fat
    • Increases Energ= y
    • Increases Memor= y
    • Increases Stam= ina


      • Click To Learn Mo= re
       v wkkqmoaycgmj n sofnovforlx ijmynl v zqqvoumdfaale xcyvvuvjtsz lzndlhswstgnt --2A1_5FA0_010.B.487B-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 22:14:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26415 for ; Tue, 10 Jun 2003 22:14:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B2Deq21808 for ; Tue, 10 Jun 2003 22:13:40 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B2Db616489 for ; Tue, 10 Jun 2003 22:13:37 -0400 (EDT) Message-ID: From: "Chuck Haywood" To: Subject: Takes years off your appearance. rr pyykhvpg Date: Thu, 12 Jun 03 00:01:33 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2A1_5FA0_010.B.487B" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: 47.234.0.34 X-SMTP-MAIL-FROM: hvr4cctm6pr@mymail2u.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [203.236.141.200] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --2A1_5FA0_010.B.487B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

      Our product is doctor endorsed.


      10= 0% Herbal, HGH is proven to...
      <= /font>


      • Reduces Wrinkles
      • Reduces Hairloss
      • Burns Fat
      • Increases Energ= y
      • Increases Memor= y
      • Increases Stam= ina


        • Click To Learn Mo= re
         xfyoogf d icjupyphi i bukgjwxb xjyn es --2A1_5FA0_010.B.487B-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 22:15:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26448 for ; Tue, 10 Jun 2003 22:15:53 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B2FMq24044 for ; Tue, 10 Jun 2003 22:15:23 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B2FJG19060 for ; Tue, 10 Jun 2003 22:15:19 -0400 (EDT) Message-ID: From: "Jo Molina" To: Subject: Anti-Aging miracle. k il wts lzo levvf Date: Wed, 11 Jun 03 12:01:00 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D.D4D48C_73_0..4" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: 250.Red-80-35-87.pooles.rima-tde.net X-SMTP-MAIL-FROM: u6fe1syys7@mymail2u.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: 250.Red-80-35-87.pooles.rima-tde.net [80.35.87.250] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --D.D4D48C_73_0..4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

        Our product is doctor endorsed.


        10= 0% Herbal, HGH is proven to...
        <= /font>


        • Reduces Wrinkles
        • Reduces Hairloss
        • Burns Fat
        • Increases Energ= y
        • Increases Memor= y
        • Increases Stam= ina


          • Click To Learn Mo= re
           cncvuvjr p yfyupha qp m uq ufkaw joxzdcmg jvtm bceh --D.D4D48C_73_0..4-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 10 22:28:09 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26932 for ; Tue, 10 Jun 2003 22:28:09 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B2Rbq28263 for ; Tue, 10 Jun 2003 22:27:37 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B2RZG25675 for ; Tue, 10 Jun 2003 22:27:35 -0400 (EDT) Message-ID: From: "Chris Chartrand" To: ppvpn@nortelnetworks.com Subject: Unsubscribe ppvpn Date: Tue, 10 Jun 2003 22:26:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32FC0.CC87E430" 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_01C32FC0.CC87E430 Content-Type: text/plain Unsubscribe ppvpn ------_=_NextPart_001_01C32FC0.CC87E430 Content-Type: text/html Unsubscribe ppvpn

          Unsubscribe ppvpn

          ------_=_NextPart_001_01C32FC0.CC87E430-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 11 04:22:17 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29299 for ; Wed, 11 Jun 2003 04:22:16 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5B8Lk217148 for ; Wed, 11 Jun 2003 04:21:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5B8Lgm16367 for ; Wed, 11 Jun 2003 04:21:43 -0400 (EDT) Message-ID: <8812A03F65CDD511AE98006008F5E87105E8054F@hermes.hyperchip.com> From: Beatty Lane-Davis To: "'Sean Slater'" , ppvpn@lyris.nortelnetworks.com Subject: RE: Ppvpn,why wait? Date: Wed, 11 Jun 2003 04:18:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32FF2.187F1A80" X-SMTP-HELO: mail2.hyperchip.com X-SMTP-MAIL-FROM: bldavis@hyperchip.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: mail2.hyperchip.com [216.94.112.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_01C32FF2.187F1A80 Content-Type: text/plain; charset="iso-8859-1" Has anyone else noticed a recent surge in the amount of spam they've been receiving? Phase of the moon? Aquarius rising? Something... I must say, it is pretty funny to see 10 SPAM's along the lines of "PPVPN, why wait, enlarge your...." followed by an "unsubscribe ppvpn." So it goes... -----Original Message----- From: Sean Slater [mailto:starkisd@aol.com] Sent: Tuesday, June 10, 2003 10:07 PM To: ppvpn@lyris.nortelnetworks.com Subject: Ppvpn,why wait? Current Low Interest Rates Create Win-Win for Homeowners! Could this be a good time to pull some equity cash out of your home or just take advantage of these lower rates to substantially reduce your monthly payments. It's quick and simple to see what's available and then decide if this makes any sense for you personally. Of course there is not a charge or any obligation for taking advantage of this online insta-quote service. Start here for a fast quote and monthly savings calculation There may be no other way to so quickly and easily slash your monthly expenses! lotterytroutman useful betty negligible anachronistic combine conversion defiant commute utopia please Go here to stop all future offers. < ------_=_NextPart_001_01C32FF2.187F1A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
          Has=20 anyone else noticed a recent surge in the amount of spam they've been=20 receiving?  Phase of the moon?  Aquarius rising? =20 Something...
          I must=20 say, it is pretty funny to see 10 SPAM's along the lines of "PPVPN, why = wait,=20 enlarge your...."  followed by an "unsubscribe ppvpn." =20
          So it=20 goes...
           
          -----Original Message-----
          From: Sean Slater=20 [mailto:starkisd@aol.com]
          Sent: Tuesday, June 10, 2003 = 10:07=20 PM
          To: ppvpn@lyris.nortelnetworks.com
          Subject: = Ppvpn,why=20 wait?

            Current=20 Low Interest Rates Create Win-Win for=20 Homeowners!
           
          Could this be a good=20 time to pull some equity cash out of your = home or just=20
          take advantage of these lower rates to substantially = reduce your monthly payments.
           
          It's quick and simple to see what's = available and=20 then decide if this makes
          any sense for you personally. Of = course there is=20 not a charge or any obligation
          for taking advantage of this online insta-quote = service.
           
           
                    = ;            = ; Start here = for a fast=20 quote and
                    &nb= sp;          =20 monthly savings=20 calculation
           
           
                     T= here may=20 be no other way to so quickly and easily
                    &nb= sp;           &nb= sp;    =20 slash your monthly expenses!
          lotterytroutman =
          useful betty=20 negligible anachronistic combine conversion
          defiant commute=20 utopia
           
           
          please Go here to = stop all=20 future offers.
           
           
           
           
           
           
           
           
           
           
           
           
          <
          ------_=_NextPart_001_01C32FF2.187F1A80-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 11 12:16:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15855 for ; Wed, 11 Jun 2003 12:16:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BGFW209932 for ; Wed, 11 Jun 2003 12:15:33 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5BGFTj01444 for ; Wed, 11 Jun 2003 12:15:29 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: discussion topics for the mail list Date: Wed, 11 Jun 2003 12:11:58 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C4C0@m-va-bsod03.add0.masergy.com> Thread-Topic: discussion topics for the mail list thread-index: AcMwNC9ePAMn5mNwRs2hY1jlvtrRGQ== From: "Rick Wilder" To: X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15855 I'd like to call a 2-week discussion period on this list for the following topics: 1. draft-heinanen-radius-pe-discovery-04.txt: Does this version adequately address the Radius issues raised so that it can now become a WG document? 2. draft-guichard-pe-ce-addr-02.txt: Should this become a WG document? 3. What direction should the WG take for L3 VPN authentication? draft-behringer-mpls-vpn-auth-02.txt has been discussed some. Earlier, the WG took a look at draft-bonica-l3vpn-auth-00.txt. Do we have a draft we want to adopt as a WG document? From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 11 13:11:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17600 for ; Wed, 11 Jun 2003 13:11:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BHAG202415 for ; Wed, 11 Jun 2003 13:10:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5BHADq23381 for ; Wed, 11 Jun 2003 13:10:13 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: Rick Wilder , ppvpn@nortelnetworks.com Subject: RE: discussion topics for the mail list Date: Wed, 11 Jun 2003 13:08:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3303C.16A75764" 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_01C3303C.16A75764 Content-Type: text/plain; charset="iso-8859-1" Rick, > 3. What direction should the WG take for L3 VPN authentication? > draft-behringer-mpls-vpn-auth-02.txt has been discussed some. Earlier, > the WG took a look at draft-bonica-l3vpn-auth-00.txt. Do we > have a draft > we want to adopt as a WG document? > I think this draft is already a ppvpn WG document renamed to draft-ietf-ppvpn-l3vpn-auth-03.txt. Hamid. ------_=_NextPart_001_01C3303C.16A75764 Content-Type: text/html; charset="iso-8859-1" Rick,

          > 3. What direction should the WG take for L3 VPN authentication?
          > draft-behringer-mpls-vpn-auth-02.txt has been discussed some. Earlier,
          > the WG took a look at draft-bonica-l3vpn-auth-00.txt. Do we
          > have a draft
          > we want to adopt as a WG document?
          >

          I think this draft is already a ppvpn WG document renamed to
          draft-ietf-ppvpn-l3vpn-auth-03.txt.
           
          Hamid.
          ------_=_NextPart_001_01C3303C.16A75764-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 11 13:49:32 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19114 for ; Wed, 11 Jun 2003 13:49:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BHn0211394 for ; Wed, 11 Jun 2003 13:49:00 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5BHmvp21997 for ; Wed, 11 Jun 2003 13:48:57 -0400 (EDT) Message-ID: <3EE76B18.3070907@cisco.com> Date: Wed, 11 Jun 2003 19:47:04 +0200 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rick Wilder CC: ppvpn@nortelnetworks.com Subject: Re: discussion topics for the mail list References: <6B25E083A064374CA3D2FAB305CFAF7A03C4C0@m-va-bsod03.add0.masergy.com> In-Reply-To: <6B25E083A064374CA3D2FAB305CFAF7A03C4C0@m-va-bsod03.add0.masergy.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: townsley@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Rick Wilder wrote: > > I'd like to call a 2-week discussion period on this list for the > following topics: > > > 1. draft-heinanen-radius-pe-discovery-04.txt: Does this version > adequately address the Radius issues raised so that it can now become a > WG document? There has been a good bit of open technical participation on this list such that the document is taking on a WG tone already. Making it a WG document seems to be the next logical step. - Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 11 14:27:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20496 for ; Wed, 11 Jun 2003 14:27:48 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BIRH205248 for ; Wed, 11 Jun 2003 14:27:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5BIRDn27737 for ; Wed, 11 Jun 2003 14:27:13 -0400 (EDT) Date: Wed, 11 Jun 2003 11:24:10 -0700 (PDT) From: Kireeti Kompella Message-Id: <200306111824.h5BIOAw43780@kummer.juniper.net> To: rwilder@masergy.com, townsley@cisco.com Subject: Re: discussion topics for the mail list Cc: ppvpn@nortelnetworks.com In-Reply-To: <3EE76B18.3070907@cisco.com> X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: kireeti@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] X-LYRIS-Message-Id: > > 1. draft-heinanen-radius-pe-discovery-04.txt: Does this version > > adequately address the Radius issues raised so that it can now become a > > WG document? > > There has been a good bit of open technical participation on this list such that > the document is taking on a WG tone already. Making it a WG document seems to be > the next logical step. Sorry, Mark, the fact that there is a discussion/open technical participation DOES NOT qualify the doc as a WG doc; by no stretch is "the next logical step" to make this a WG doc. I think Rick is doing the right thing in calling for WG consensus. This is not a statement of my support or dissent for this document, just a commentary on process. Kireeti. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 11 15:08:40 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22595 for ; Wed, 11 Jun 2003 15:08:38 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BJ85225871 for ; Wed, 11 Jun 2003 15:08:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5BJ82F26018 for ; Wed, 11 Jun 2003 15:08:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: discussion topics for the mail list Date: Wed, 11 Jun 2003 15:06:09 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C4C2@m-va-bsod03.add0.masergy.com> Thread-Topic: discussion topics for the mail list thread-index: AcMwPBknN4irlyoFR+u12l8Kc4ejjAAD7dUQ From: "Rick Wilder" To: "Hamid Ould-Brahim" , X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA22595 Hamid, The discussion is about the WG's take on the draft-behringer-mpls-vpn-auth-02.txt and how the 2 docs are related. Pardon the use of the old name for draft-ietf-ppvpn-l3vpn-auth-03.txt. Rick -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Wednesday, June 11, 2003 11:09 AM To: Rick Wilder; ppvpn@nortelnetworks.com Subject: RE: discussion topics for the mail list Rick, > 3. What direction should the WG take for L3 VPN authentication? > draft-behringer-mpls-vpn-auth-02.txt has been discussed some. Earlier, > the WG took a look at draft-bonica-l3vpn-auth-00.txt. Do we > have a draft > we want to adopt as a WG document? > I think this draft is already a ppvpn WG document renamed to draft-ietf-ppvpn-l3vpn-auth-03.txt.   Hamid. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 11 16:48:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02173 for ; Wed, 11 Jun 2003 16:48:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BKm3204872 for ; Wed, 11 Jun 2003 16:48:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5BKm0916511 for ; Wed, 11 Jun 2003 16:48:00 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: rwilder@masergy.com, ppvpn@nortelnetworks.com Subject: RE: discussion topics for the mail list Date: Wed, 11 Jun 2003 21:44:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: > I'd like to call a 2-week discussion period on this list for the > following topics: > > 1. draft-heinanen-radius-pe-discovery-04.txt: Does this version > adequately address the Radius issues raised so that it can > now become a WG document? I support making the draft a WG document for the following reasons: 1. It is the only auto-discovery draft with inherent support for CE authentication (which as already discussed on the list, is considered more useful to some than others). 2. It limits the distribution of VPN information to only those PEs that are members of a particular VPN (without having to use any filtering). 3. It is extendible to distribute information in addition to LSP src/dest addresses on a p2p basis (although there has been no consensus if this is useful or not, it might be found to be useful in the future). Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 11 18:00:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05103 for ; Wed, 11 Jun 2003 18:00:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BLxe229589 for ; Wed, 11 Jun 2003 17:59:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5BLxbo12441 for ; Wed, 11 Jun 2003 17:59:37 -0400 (EDT) Message-ID: <3EE7A596.9050003@cisco.com> Date: Wed, 11 Jun 2003 23:56:38 +0200 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kireeti Kompella CC: rwilder@masergy.com, ppvpn@nortelnetworks.com Subject: Re: discussion topics for the mail list References: <200306111824.h5BIOAw43780@kummer.juniper.net> In-Reply-To: <200306111824.h5BIOAw43780@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: townsley@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: >>>1. draft-heinanen-radius-pe-discovery-04.txt: Does this version >>>adequately address the Radius issues raised so that it can now become a >>>WG document? >> >>There has been a good bit of open technical participation on this list such that >>the document is taking on a WG tone already. Making it a WG document seems to be >>the next logical step. > > > Sorry, Mark, the fact that there is a discussion/open technical > participation DOES NOT qualify the doc as a WG doc; by no stretch What, would you instead count the number of people chiming in with "[I,My company] supports this draft" type comments? I obviously thought that the technical participation thus far was supportive of the document. But in case there is any question, I will restate: "There has been a good bit of support and open technical participation on this list such that the document is taking on a WG tone already." > is "the next logical step" to make this a WG doc. I think Rick is > doing the right thing in calling for WG consensus. The actual question that should be raised is consensus of whether or not the mechanism being proposed in general is something that the WG should and is willing to address with a document or not. It certainly helps to have a well-written and reviewed document to articulate this effectively and generate discussion, but the real focus should be on whether the topic at hand is a legitimate WG effort more than on whether a given individual submission has reached some level of readiness or not. I think that plenty of discussion was generated during the previous 2 week call on this topic already. I saw no need to restate Richard Spencer's excellent summary of the results of this discussion and subsequent actions taken by Juha as an individual draft author here: http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305&L=ppvpn&T=0&F=&S=&P=52918 http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305&L=ppvpn&T=0&F=&S=&P=60930 This type of WG interaction (not to mention the show of hands at the last IETF meeting that caused Juha to continue the work individually to begin with), are all indications that there is strong potential for a productive WG effort, and that at least some (perhaps significant) number of people consider this to be a Good Thing. Not that there is consensus on every last issue the document raises or it is in any sort of final form, but this particular call for consensus comes before the document becomes an RFC, not before it becomes a WG document. Finally, I will add now that given the fact that Juha is retiring, it seems the perfect opportunity for the WG to adopt the work. - Mark > > Kireeti. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 11 18:36:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07583 for ; Wed, 11 Jun 2003 18:36:08 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5BMZb209613 for ; Wed, 11 Jun 2003 18:35:38 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5BMZZu28372 for ; Wed, 11 Jun 2003 18:35:35 -0400 (EDT) Message-Id: <5.2.0.9.0.20030611171755.0295ad28@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 11 Jun 2003 18:32:32 -0400 To: "Paul Knight" , ppvpn@nortelnetworks.com From: Mark Duffy Subject: RE: WG LAST CALL on draft-ietf-ppvpn-vpn-vr-04.txt In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF064B1FAF@zbl6c004.corpeast .baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: qtech1.quarrytech.com X-SMTP-MAIL-FROM: mduffy@quarrytech.com X-SMTP-RCPT-TO: paul.knight@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: email.quarrytech.com [4.17.144.4] X-LYRIS-Message-Id: Hi Paul, thanks for your response. I agree with almost all your points :-) I have further questions on one point below. You are right that I did not correctly interpret the "backbone VR" concept as described. I think the additional explanation in your email would indeed be good to add to the document. I'll reread it with the new understanding. > > 8. VPNs across Domains > > [...] > > Another possible scenario is to use two virtual routers configured > > on each PE at the interconnection point. > > > > [md] I would clarify that as follows: > > Another possible scenario is to deploy PE devices at each side > > of the interconnection point, with a virtual router configured > > on each PE for each VPN that spans the interconnection point. > > >[pk] I think the VR-per-VPN may be overkill, depending on the granularity >of filtering needed. The idea is not to terminate the VPNs, but to >provide ingress/egress filtering for all the bidirectional tunneled VPN >traffic crossing the boundary. The VPN traffic should be opaque at the >boundary, so it would normally be filtered all-or-nothing (by VPN) based >on the visible packet identifiers (which could be mapped to a VPN by each >service provider, for instance using the VPN-ID). I'm not sure what other >policies would be applied by the service providers on the VPN traffic >transiting the boundary, but I don't think they would normally require a >VR per VPN on the boundary. [md2] Ah, ok, I see that the text was not meant to suggest a VR per VPN at the peering point (I agree that would be unnecessary in most cases). But I don't understand yet what it does mean. If the objective is to filter packets of certain VPNs (or more precisely, filter packets on certain virtual links) then why are any VRs needed? Is this to terminate the VPN represented by some "backbone VRs" to get visibility into the nested VPNs? Is "two virtual routers configured on each PE" really meant to mean two on the first PE and two on the second, or two altogether (one on each)? It seems in any event that one could only filter packets on those tunnels one is aware of. If one is aware of them it probably means one has configured their network to support that VPN. But in that case why filter (all) the packets involved? Thanks, Mark From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 13 15:26:21 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20645 for ; Fri, 13 Jun 2003 15:26:20 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5DJPmU25901 for ; Fri, 13 Jun 2003 15:25:48 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5DJPhM19231 for ; Fri, 13 Jun 2003 15:25:44 -0400 (EDT) Message-Id: <200306131923.h5DJNtS10878@zrtps0kk.us.nortel.com> From: "FEDOKIN KALUSHA KABILA." To: ppvpn@lyris.nortelnetworks.com Reply-To: fedokin@netscape.net Subject: URGENT ASAP. Date: Fri, 13 Jun 2003 21:24:07 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="412df96e-1401-41ba-aef5-e3332d761ebf" X-SMTP-HELO: netscape637.com X-SMTP-MAIL-FROM: fedoki@netscape.net X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: 167.Red-217-126-240.pooles.rima-tde.net [217.126.240.167] X-LYRIS-Message-Id: This is a multi-part message in MIME format --412df96e-1401-41ba-aef5-e3332d761ebf Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable URGENT ASSISTANCE NEEDED You may be surprise to receive this Email from me since you do not know me personally. However, I would like to introduce myself. I am Mr.Fedokin = Kalusha Kabila. Kalusha Jr, the son of Dr. Stephen Kalusha who was murdered few months ago in Zimbabwe as a result of land dispute. Before the death of my father (Dr. Kalusha), he had taken me to AMSTERDAM to deposit the sum of TWENTY Million United States dollars (US$20,000,000) in a security company, as he foresaw the looming danger in Zimbabwe. The money in question was deposited in a box as Gemstones to avoid much demurrage from the security company. The proposed amount was meant for the purchase of new machines and chemicals for the farms and establishment of new farms on Swaziland. As you may be aware this land problem came into force when Zimbabwe president Mr. Robert Mugabe Introduced the Land Reformed Act of which my father rich farmers and some black farmers where affectted. This resulted to the killing and Mob action by Zimbabwe war veterans and some lunatics in the society, infact, a lot of people were killed because of this Land Reformed act of which my dad was one of the victims. It is against this background that my family and I who are currently staying in Amsterdam decided to transfer my father=3D92s money to a foreign account. Since the Dutch law prohibit a refugee (asylum seeker) to open any account or be involved in any financial transaction. As the eldest son of my father, I am saddled with the responsibility of seeking a genuine foreign account where the money could =3D = be transferred . I am faced with the dilemma of investing this amount of money in Holland for the fear of going through the same experience in future since both countries have similar history. Moreover, The Netherlands foreign exchange policy does not allow such investment from asylum seekers. As a businessman, whom I have entrusted my future and my family in his hands , I must let you know that this transaction is risk free. If you accept to assist me and my family, all I need you to do for me is to make arrangement and come to AMSTERDAM ,THE NETHERLANDS, so that we can open the non-resident account which will aid us in transferring the money into any account you will nominate overseas. This money I intend using for investment. I have options to offer you, first you can choose to have certain percentage of the money for nominating your account for the transaction, or you can go into partnership for a proper profitable investment of the money in your country. Which ever option you choose, feel free to notify me. I have mapped out 5% of this money for all expenses incurred in processing the transaction. If for some reasons you do not prefer a partnership, I am willing to give you 25% of the money while the remaining 70% that is meant for me, will be for the investment in your country. Please, contact me on the Email or telephone below so we can discuss further and a chance for you to ask me any question you may have in mind, while you maintain the absolute secrecy required in the transaction.i will be very happy if you can call me on telephone +31-645-586-741 or email me :fedokin@netscape.net Yours faithfully FEDOKIN KALUSHA KABILA. --412df96e-1401-41ba-aef5-e3332d761ebf-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 13 18:09:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25456 for ; Fri, 13 Jun 2003 18:09:11 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5DM8fU08056 for ; Fri, 13 Jun 2003 18:08:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5DM8bo18017 for ; Fri, 13 Jun 2003 18:08:37 -0400 (EDT) Message-ID: From: "Sabrina Callahan" To: Subject: qualify? .................. position Date: Fri, 13 Jun 03 23:02:40 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".9858B8A5F4_CA8DCCBF6_7" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: p13028-ipadfx01maru.tokyo.ocn.ne.jp X-SMTP-MAIL-FROM: stacymenard@aol.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: p13028-ipadfx01maru.tokyo.ocn.ne.jp [219.165.71.28] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --.9858B8A5F4_CA8DCCBF6_7 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

          FREE CASH GRANTS, NEVER REPAY!

          TO GET MORE INFORMATION, SIMPLY&nbs= p;START HERE!

          You Can Get The Money You Need...<= /H2>
          Here are some samples of what you can app= ly for, just to name a few.
          Grants and Programs for:
          • Child Care
          • Health Care
          • Personal Grants to Attend U.S Colleges =
          • 1st Time Home Buyers/Owners
          • Education
          • Minorities
          • Affordable Housing
          • Business Grants and Loans
          • Research
          • Home Improvement
          • Home Repair
          • Housing
          • Real Estate
          • Many many more
          Why put this off? check it out now
          leatherneck pulmonary quantify= ritchie
           = ;
          PLease Go Here to unsubscribe and be removed from ou= r list
          --.9858B8A5F4_CA8DCCBF6_7-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 10:51:28 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16891 for ; Mon, 16 Jun 2003 10:51:27 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GEouT08326 for ; Mon, 16 Jun 2003 10:50:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5GEoqY06446 for ; Mon, 16 Jun 2003 10:50:53 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: ppvpn@nortelnetworks.com Subject: Use of BGP label block Date: Mon, 16 Jun 2003 13:00:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cbibipnt05.hc.bt.com X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: I have a question from an operators perspective regarding the use of the label block in the BGP signalling drafts. The recommended algorithm uses a CE or VE identifier as an index to determine the correct label a receiving PE should use to send packets destined for a particular VPN to a particular PE. The drafts state that the CE/VE IDs must be unique within a particular VPN but not across VPNs. This doesn't seem too bad in the intra-provider case as the operator can manage his own CE/VE ID space and simply allocate the next CE to join a VPN the next available ID for that particular VPN. However, in the inter-AS case how are operators to co-ordinate their use of CE/VE IDs? For large operators that might peer with several other large operators, keeping track of which CE/VE IDs belong to which operator, and mapping the CE/VE IDs to the correct VPNs doesn't sound appealing. Obviously when choosing a signalling protocol there are many things to take into consideration, and as a result an operator may decide that having to manage CE/VE IDs is a minor consequence. However, generally speaking the use of a label block to overcome BGPs inability to signal labels on an individual point-to-point basis will lead to an increase in operational costs (compared to signalling mechanisms that don't use a label block and therefore CE/VE IDs do not need to be provisioned and managed). Are there any plans to produce guidelines on how CE/VE IDs should be provisioned and managed, particularly in the inter-provider case? Thanks, Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 10:56:12 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17000 for ; Mon, 16 Jun 2003 10:56:12 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GEtfT09884 for ; Mon, 16 Jun 2003 10:55:41 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5GEtZY15134 for ; Mon, 16 Jun 2003 10:55:35 -0400 (EDT) Message-Id: <200306161241.h5GCfAd17453@zrtps06u.us.nortel.com> From: chumaemma@netscape.net Reply-To: chumaemma@netscape.net To: ppvpn@nortelnetworks.com Date: Mon, 16 Jun 2003 15:18:00 +0200 Subject: BUSINESS PROPOSAL X-Mailer: QuickSender 1.05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: localhost.com X-SMTP-MAIL-FROM: chumaemma@netscape.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: node131bd.a2000.nl [24.132.49.189] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA17000 Dear Friend, Difficulties encountered in efforts to establish a business abroad necessitate this search for someone to assist me in securing and investing the sum of USD41,000.000 forty one million dollars)inherited from my father's business reserve. I am the heir of a Zimbabwean family; my father was an agriculturist. He became rich from his old-aged investment in agriculture and later was victimized by President Robert Mugabe's land reform policy. He was assassinated by unknown gunmen for defending his land ownership and siding the minority white farmers. Before his death, my father foresaw the insecurity of both our lives and property then decided to deposit the above sum with a private finance and security firm in Europe. This money has become the only inherited property of our family since our home was burnt,and the farmlands and machines seized; yet the government and it's loyalists are bent on making life difficult for us. To summarise this traumatic story, my mother and I have decided to offer 15% of the above sum to anyone who assists us to secure this funds overseas or 25% share for possible help on investing in any reliable venture. there are however some minimal cost involved in securing the release of this deposit from the present holding company.i do not intend to overburden you with these cost.but you must know beforehand that we will be sharing whatever cost involved in retrieving this deposit and putting it to beneficial use. if you would want to proceed under these terms,please reply for detailed information. if you do not accept my offer,please in good fate treat with utmost confidentiality . A quick reply with your name,telephone and fax numbers for more confidential communication will be highly appreciated. Sincerely yours, CHUMA EMMANUEL From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 12:54:39 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20783 for ; Mon, 16 Jun 2003 12:54:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GGs2T29234 for ; Mon, 16 Jun 2003 12:54:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5GGrxV11655 for ; Mon, 16 Jun 2003 12:53:59 -0400 (EDT) Message-Id: <200306161651.h5GGpRu58993@merlot.juniper.net> To: "W. Mark Townsley" cc: Kireeti Kompella , rwilder@masergy.com, ppvpn@nortelnetworks.com Subject: Re: discussion topics for the mail list In-Reply-To: Your message of "Wed, 11 Jun 2003 23:56:38 +0200." <3EE7A596.9050003@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <49688.1055782287.1@juniper.net> Date: Mon, 16 Jun 2003 09:51:27 -0700 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: Mark, > Kireeti Kompella wrote: > >>>1. draft-heinanen-radius-pe-discovery-04.txt: Does this version > >>>adequately address the Radius issues raised so that it can now become a > >>>WG document? > >> > >>There has been a good bit of open technical participation on this list such > >>that the document is taking on a WG tone already. Making it a WG document > >>seems to be the next logical step. > > > > > > Sorry, Mark, the fact that there is a discussion/open technical > > participation DOES NOT qualify the doc as a WG doc; by no stretch > > What, would you instead count the number of people chiming in > with "[I,My company] supports this draft" type comments? > > I obviously thought that the technical participation thus far was supportive > of the document. But in case there is any question, I will restate: > > "There has been a good bit of support and open technical participation on > this list such that the document is taking on a WG tone already." > > > is "the next logical step" to make this a WG doc. I think Rick is > > doing the right thing in calling for WG consensus. > > The actual question that should be raised is consensus of whether or not the > mechanism being proposed in general is something that the WG should and is > willing to address with a document or not. It certainly helps to have a > well-written and reviewed document to articulate this effectively and generate > discussion, but the real focus should be on whether the topic at hand is a > legitimate WG effort more than on whether a given individual submission has > reached some level of readiness or not. We can argue on what should be the "the actual question that should be raised", but that is *not* the topic of this discussion. This discussion is about the specific document, namely draft-heinanen-radius-pe-discovery-04.txt. Yakov. P.S. Since Rick asked for WG consensus, I don't think that draft-heinanen-radius-pe-discovery-04.txt is ready to be the WG document. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 13:09:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21223 for ; Mon, 16 Jun 2003 13:09:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GH8RT14186 for ; Mon, 16 Jun 2003 13:08:28 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5GH8LL05478 for ; Mon, 16 Jun 2003 13:08:21 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: yakov@juniper.net, townsley@cisco.com Cc: kireeti@juniper.net, rwilder@masergy.com, ppvpn@nortelnetworks.com Subject: RE: discussion topics for the mail list Date: Mon, 16 Jun 2003 18:06:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: cbibipnt02.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Yakov, Please can you give the reasons why you think the draft is not ready to be made a WG document? Thanks, Richard > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: 16 June 2003 17:51 > To: W. Mark Townsley > Cc: Kireeti Kompella; rwilder@masergy.com; ppvpn@nortelnetworks.com > Subject: Re: discussion topics for the mail list > > > Mark, > > > Kireeti Kompella wrote: > > >>>1. draft-heinanen-radius-pe-discovery-04.txt: Does this version > > >>>adequately address the Radius issues raised so that it > can now become a > > >>>WG document? > > >> > > >>There has been a good bit of open technical > participation on this list such > > >>that the document is taking on a WG tone already. Making > it a WG document > > >>seems to be the next logical step. > > > > > > > > > Sorry, Mark, the fact that there is a discussion/open technical > > > participation DOES NOT qualify the doc as a WG doc; by no stretch > > > > What, would you instead count the number of people chiming in > > with "[I,My company] supports this draft" type comments? > > > > I obviously thought that the technical participation thus > far was supportive > > of the document. But in case there is any question, I will restate: > > > > "There has been a good bit of support and open technical > participation on > > this list such that the document is taking on a WG tone already." > > > > > is "the next logical step" to make this a WG doc. I > think Rick is > > > doing the right thing in calling for WG consensus. > > > > The actual question that should be raised is consensus of > whether or not the > > mechanism being proposed in general is something that the > WG should and is > > willing to address with a document or not. It certainly > helps to have a > > well-written and reviewed document to articulate this > effectively and generate > > discussion, but the real focus should be on whether the > topic at hand is a > > legitimate WG effort more than on whether a given > individual submission has > > reached some level of readiness or not. > > We can argue on what should be the "the actual question that > should be > raised", but that is *not* the topic of this discussion. > This discussion is > about the specific document, namely > draft-heinanen-radius-pe-discovery-04.txt. > > Yakov. > > P.S. Since Rick asked for WG consensus, I don't think that > draft-heinanen-radius-pe-discovery-04.txt is ready to be the > WG document. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 13:12:48 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21316 for ; Mon, 16 Jun 2003 13:12:46 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GHCET18073 for ; Mon, 16 Jun 2003 13:12:14 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5GHCBL10834 for ; Mon, 16 Jun 2003 13:12:11 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16109.63977.428185.640713@harjus.tutpro.com> Date: Mon, 16 Jun 2003 20:10:01 +0300 To: Yakov Rekhter Cc: "W. Mark Townsley" , Kireeti Kompella , rwilder@masergy.com, ppvpn@nortelnetworks.com Subject: Re: discussion topics for the mail list In-Reply-To: <200306161651.h5GGpRu58993@merlot.juniper.net> References: <3EE7A596.9050003@cisco.com> <200306161651.h5GGpRu58993@merlot.juniper.net> X-Mailer: VM 7.14 under Emacs 21.2.1 From: Juha Heinanen X-SMTP-HELO: harjus.tutpro.com X-SMTP-MAIL-FROM: jh@tutpro.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.tutpro.com [192.98.100.3] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov Rekhter writes: > P.S. Since Rick asked for WG consensus, I don't think that > draft-heinanen-radius-pe-discovery-04.txt is ready to be the WG document. could you be more specific, why you think that that is the case? it don't think that it is enough that someone doesn't like the idea, since noone likes every idea. me for instance don't like any bgp based proposal, but still i have not started a campaign against them, because i feel that other people are free to do what they like and it doesn't bother me. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 13:17:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21472 for ; Mon, 16 Jun 2003 13:17:48 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GHHGT22867 for ; Mon, 16 Jun 2003 13:17:17 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5GHHDj16997 for ; Mon, 16 Jun 2003 13:17:13 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Loa Andersson" , "Ppvpn" Subject: Timeslot to discuss VPLS issues Date: Mon, 16 Jun 2003 10:15:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Importance: Normal X-OriginalArrivalTime: 16 Jun 2003 17:14:28.0759 (UTC) FILETIME=[BE9AC270:01C3342A] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Loa/Rick, Can I get a timeslot to discuss some VPLS issues in draft-lasserre-vkompella (soon to be submitted as draft-ietf-ppvpn-vpls-ldp-00.txt which is substantively the same as draft-lasserre-vkompella-ppvpn-vpls-04)? These are the issues: 1. The VC type has changed from 0xb (VPLS) to 0x5 (ethernet). Most people have implemented VPLS using 0xb, but the newer implementations use 0x5. It's not the value, but the concept here that is at question: if the VC type is no different from a pt2pt ethernet PW, then how does one distinguish a group of pt2pt PWs from a group of split-horizon PWs? One idea is to use an optional parameter, say Split horizon Group ID, to name a split horizon group of PWs. This would give us both the capability to identify whether a PW is split horizon enabled or not, as well as extend the notion of split-horizon-ness to groups. 2. Naming the VPLS: currently the name of the VPLS is the VCID. This is not adequate. I proposed a VPN ID TLV. Eric proposed a Generalized ID FEC. I'd like to get this resolved as to which direction we should proceed. I have already raised this issue on the mailing list, and would like to get some more feedback before Vienna. What I would like is to be able to name the VPLS, name each PW in the VPLS, identify each PW with a VC type, and associate each PW with a split-horizon group. Apart from causing inconsistencies between draft versions, this also impacts progress on the hvpls oam draft, so I'd like this cleaned up asap. Thanks. Vach Kompella TiMetra Networks vkompella@timetra.com 650-237-5152 From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 13:48:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22481 for ; Mon, 16 Jun 2003 13:48:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GHm4T00238 for ; Mon, 16 Jun 2003 13:48:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5GHm1U10070 for ; Mon, 16 Jun 2003 13:48:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: discussion topics for the mail list Date: Mon, 16 Jun 2003 13:45:55 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C4C7@m-va-bsod03.add0.masergy.com> Thread-Topic: discussion topics for the mail list thread-index: AcM0KiUNlYEm3l86Qfy7PSLLYvH6qwAA23SQ From: "Rick Wilder" To: "Juha Heinanen" , "Yakov Rekhter" Cc: "W. Mark Townsley" , "Kireeti Kompella" , X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA22481 My view of this process is that there was WG consensus behind this document at the SF meeting and the mail list. Then specific issues were raised, primarily by Bernard, about this solution's use of Radius. I think the main point to be discussed is whether the changes made by this latest version of the document adequately address those concerns. It seems only fair for people to have a chance to look at the changes and comment, but I don't think we need to go back to square one unless we have a specific and compelling reason (which I don't think I've seen). Rick -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Monday, June 16, 2003 11:10 AM To: Yakov Rekhter Cc: W. Mark Townsley; Kireeti Kompella; Rick Wilder; ppvpn@nortelnetworks.com Subject: Re: discussion topics for the mail list Yakov Rekhter writes: > P.S. Since Rick asked for WG consensus, I don't think that > draft-heinanen-radius-pe-discovery-04.txt is ready to be the WG document. could you be more specific, why you think that that is the case? it don't think that it is enough that someone doesn't like the idea, since noone likes every idea. me for instance don't like any bgp based proposal, but still i have not started a campaign against them, because i feel that other people are free to do what they like and it doesn't bother me. -- juha From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 14:08:29 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23397 for ; Mon, 16 Jun 2003 14:08:28 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GI7tT27267 for ; Mon, 16 Jun 2003 14:07:56 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5GI7qO10835 for ; Mon, 16 Jun 2003 14:07:53 -0400 (EDT) Message-ID: <3EEE06EA.5000502@cisco.com> Date: Mon, 16 Jun 2003 20:05:30 +0200 From: "W. Mark Townsley" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter CC: Kireeti Kompella , rwilder@masergy.com, ppvpn@nortelnetworks.com Subject: Re: discussion topics for the mail list References: <200306161651.h5GGpRu58993@merlot.juniper.net> In-Reply-To: <200306161651.h5GGpRu58993@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: townsley@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > Mark, > > >>Kireeti Kompella wrote: >> >>>>>1. draft-heinanen-radius-pe-discovery-04.txt: Does this version >>>>>adequately address the Radius issues raised so that it can now become a >>>>>WG document? >>>> >>>>There has been a good bit of open technical participation on this list such >>>>that the document is taking on a WG tone already. Making it a WG document >>>>seems to be the next logical step. >>> >>> >>>Sorry, Mark, the fact that there is a discussion/open technical >>>participation DOES NOT qualify the doc as a WG doc; by no stretch >> >>What, would you instead count the number of people chiming in >>with "[I,My company] supports this draft" type comments? >> >>I obviously thought that the technical participation thus far was supportive >>of the document. But in case there is any question, I will restate: >> >>"There has been a good bit of support and open technical participation on >>this list such that the document is taking on a WG tone already." >> >> >>>is "the next logical step" to make this a WG doc. I think Rick is >>>doing the right thing in calling for WG consensus. >> >>The actual question that should be raised is consensus of whether or not the >>mechanism being proposed in general is something that the WG should and is >>willing to address with a document or not. It certainly helps to have a >>well-written and reviewed document to articulate this effectively and generate >>discussion, but the real focus should be on whether the topic at hand is a >>legitimate WG effort more than on whether a given individual submission has >>reached some level of readiness or not. > > > We can argue on what should be the "the actual question that should be > raised", but that is *not* the topic of this discussion. This discussion is > about the specific document, namely draft-heinanen-radius-pe-discovery-04.txt. I believe Kireeti took the thread in this direction when he said: "This is not a statement of my support or dissent for this document, just a commentary on process." However, if it is OK with him, I would be happy to get back to the discussion about draft-heinanen-radius-pe-discovery-04.txt. As such, could you kindly identify why you think this draft should not be a WG document? > > Yakov. > > P.S. Since Rick asked for WG consensus, I don't think that > draft-heinanen-radius-pe-discovery-04.txt is ready to be the WG document. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 14:14:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23852 for ; Mon, 16 Jun 2003 14:14:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5GIDkT01537 for ; Mon, 16 Jun 2003 14:13:46 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5GIDhO22189 for ; Mon, 16 Jun 2003 14:13:44 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D69E4@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: rwilder@masergy.com, jh@tutpro.com, yakov@juniper.net Cc: townsley@cisco.com, kireeti@juniper.net, ppvpn@nortelnetworks.com Subject: RE: discussion topics for the mail list Date: Mon, 16 Jun 2003 19:11:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: I support pursual of draft-heinanen-radius-pe-discovery-04.txt based on the following reasoning: I believe the base 'VPN problem' has the following functional building blocks: 1 server layer discovery of access points that belong to a given VPN....radius could provide a common functional component here across all network modes. A key observation here is that the server layer in question must have its own layer network addressable access points and some agreed method of VPN-ID 'name' generation; 2 server layer signalling to create data-plane connectivity between above access points......I see the signalling chosen as being network mode specific; [1 and 2 effectively create a simple managed BW VPN in the server layer network in question] 3 client layer reachability distribution. This is a 'value-add' feature agreed between SP and VPN customer. BGP looks a good common choice here across all modes. Note - It does assume that the client layer has 'sensibly' structured addressing and its own robust routing protocol. IMO draft-heinanen-radius-pe-discovery-04.txt is largely targetted at the first of these functional components. regards, Neil > -----Original Message----- > From: Rick Wilder [mailto:rwilder@masergy.com] > Sent: 16 June 2003 18:46 > To: Juha Heinanen; Yakov Rekhter > Cc: W. Mark Townsley; Kireeti Kompella; ppvpn@nortelnetworks.com > Subject: RE: discussion topics for the mail list > > > > My view of this process is that there was WG consensus behind this > document at the SF meeting and the mail list. Then specific > issues were > raised, primarily by Bernard, about this solution's use of Radius. > > I think the main point to be discussed is whether the changes made by > this latest version of the document adequately address those concerns. > It seems only fair for people to have a chance to look at the changes > and comment, but I don't think we need to go back to square one unless > we have a specific and compelling reason (which I don't think I've > seen). > > Rick > > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Monday, June 16, 2003 11:10 AM > To: Yakov Rekhter > Cc: W. Mark Townsley; Kireeti Kompella; Rick Wilder; > ppvpn@nortelnetworks.com > Subject: Re: discussion topics for the mail list > > Yakov Rekhter writes: > > > P.S. Since Rick asked for WG consensus, I don't think that > > draft-heinanen-radius-pe-discovery-04.txt is ready to be the WG > document. > > could you be more specific, why you think that that is the case? it > don't think that it is enough that someone doesn't like the > idea, since > noone > likes every idea. me for instance don't like any bgp based proposal, > but still i have not started a campaign against them, because i feel > that other people are free to do what they like and it doesn't bother > me. > > -- juha > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 22:22:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13166 for ; Mon, 16 Jun 2003 22:22:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5H2M3T15913 for ; Mon, 16 Jun 2003 22:22:04 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5H2L7U14355 for ; Mon, 16 Jun 2003 22:21:07 -0400 (EDT) Message-ID: <20030617021929.5660.qmail@web13604.mail.yahoo.com> Date: Mon, 16 Jun 2003 19:19:29 -0700 (PDT) From: Naveen Gowda Subject: unsubscribe To: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13604.mail.yahoo.com X-SMTP-MAIL-FROM: naveenietf@yahoo.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13604.mail.yahoo.com [216.136.175.115] X-LYRIS-Message-Id: __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 22:25:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13234 for ; Mon, 16 Jun 2003 22:25:24 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5H2OqT19927 for ; Mon, 16 Jun 2003 22:24:52 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5H2NfU18613 for ; Mon, 16 Jun 2003 22:23:42 -0400 (EDT) Message-ID: <20030617022110.5840.qmail@web13604.mail.yahoo.com> Date: Mon, 16 Jun 2003 19:21:10 -0700 (PDT) From: Naveen Gowda Subject: unsubscribe To: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web13604.mail.yahoo.com X-SMTP-MAIL-FROM: naveenietf@yahoo.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web13604.mail.yahoo.com [216.136.175.115] X-LYRIS-Message-Id: unsubscribe __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 16 23:09:19 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14118 for ; Mon, 16 Jun 2003 23:09:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5H38lT10503 for ; Mon, 16 Jun 2003 23:08:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5H37iR03334 for ; Mon, 16 Jun 2003 23:07:44 -0400 (EDT) Date: Tue, 17 Jun 2003 11:04:11 +0800 From: lidefeng Subject: Updation to 01 version of draft-sheng-isis-bgp-mpls-vpn To: internet-drafts@ietf.org Cc: ppvpn@nortelnetworks.com, isis-wg@ietf.org Message-id: <003b01c3347d$20dcbf40$07436e0a@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_19fYOrwtx5lF6NSyE5qYdA)" X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_19fYOrwtx5lF6NSyE5qYdA) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT --Boundary_(ID_19fYOrwtx5lF6NSyE5qYdA) Content-type: text/plain; name=draft-sheng-isis-bgp-mpls-vpn-01.txt Content-disposition: attachment; filename=draft-sheng-isis-bgp-mpls-vpn-01.txt Content-Transfer-Encoding: 7BIT Network Working Group Sheng Cheng INTERNET DRAFT Liu Yu Expiration Date: December 2003 Li Defeng Huawei Technologies. Chen Yunqing China Telecommunication June 2003 ISIS as the PE/CE Protocol in BGP/MPLS VPNs draft-sheng-isis-bgp-mpls-vpn-01.txt 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 IS-IS protocol, which is specified in [1], can be used as IGP between the Customer Edge (CE) router and the Provider Edge (PE) router in BGP/MPLS VPNs as per [VPN]. This document provides a detailed solution for IS-IS working as PE/CE Protocol in VPN services specified in [VPN]. Cheng Sheng Expires October 2003 [Page 1] Internet Draft draft-sheng-isis-bgp-mpls-vpn-01.txt June 2003 Table of Contents 1 Terms ................................................. 2 2 Introduction .......................................... 2 3 Fundamental Requirments .............................. 3 3.1 Assumptions ........................................... 3 3.2 Multiple instances ................................... 3 3.3 IS-IS interaction with BGP on PE ..................... 3 3.4 Supplement............................................. 3 4 Extended Requirments .................................. 4 4.1 Sham Links ........................................... 4 4.2 Carry IS-IS imformation with BGP Extended communities . 4 4.3 Route loop prevention on PEs ......................... 5 4.4 IS-IS interaction with BGP on PE ..................... 5 4.5 Sham-link Creation ................................... 6 5 Acknowledgments ...................................... 7 6 References ........................................... 7 7 Authors' Address ..................................... 7 1. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Introduction The IS-IS protocol is specified in [1], with extensions for supporting IPv4 (Internet Protocol) specified in [2]. [VPN] describes a VPN service architecture, in which BGP is used to distribute IP-VPN routes between PEs in IP backbone. A CE router can then learn the routes to other CE sites in the same VPN by peering with its attached PE router through a routing protocol. The routing protocol is in charge of exchanging routes between PE and its attached CE. It has been proved till now that BGP, OSPF or RIP can help. And of course, IS-IS can do it as well. Obviously, as one of the most widely used IGPs, IS-IS is capable of distributing routes of CE to PE router. Using IS-IS on the PE-CE link is prefered especially when the VPN use IS-IS as its intra-site routing protocol, which means less administative expense and good backward compatibility. This draft is mainly focusing on proposing two different solutions, in which one is fundamental and the other is somewhat complicated, to implement IS-IS between PE and its attached CE. Cheng Sheng Expires October 2003 [Page 2] Internet Draft draft-sheng-isis-bgp-mpls-vpn-01.txt June 2003 3. Fundamental Requirments In this part, some basic requirements have been listed out to address the issues of IS-IS working on PE-CE link. 3.1 Assumptions +-----+ +-----+ | PE1 |---------| PE2 | +-----+ +-----+ | | | | +-----+ +-----+ | CE1 | | CE2 | +-----+ +-----+ Two different sites of one VPN are not connected by direct(backdoor) link. Further, if this physical link does exist, there is no IS-IS adjacency over the backdoor link. If this can not be avoided, the second solution described in [4] should be chosen. 3.2 Multiple instances Multiple IS-IS instances should be supported on PE, which means multiple IS-IS instances can run in one PE with each bound to one specific VRF. The relationship between IS-IS instances and VRFs is listed as follows: Multiple IS-IS instances can be associated with the same VRF (n:1). A single IS-IS instance should not be associated with multiple VRFs (1:n). Of course, a single IS-IS instance can be associated with just a single VRF. 3.3 IS-IS interaction with BGP on PE The PE router should have the capability to import IS-IS and BGP routes to/from a particular VRF with each other. When importing the BGP routes into a single IS-IS instance bound to a specific VRF on PE, the routes will always be regarded as external routes and IS-IS delivers the routes with external reachability TLV(TLV 130) in IS-IS LSP. a) If PE uses the narrow-metric style and the metric of the original route is greater than 1023, the metric of the converted IS-IS route will be set to 1023; If PE uses the wide-metric style and the metric of the original route is greater than 4261412864(2^32-2^25) which is the max path metric in wide-metric style, the route will be ignored. Cheng Sheng Expires October 2003 [Page 3] Internet Draft draft-sheng-isis-bgp-mpls-vpn-01.txt June 2003 b) When wide-metric style is used by the PE, TLV 135 will be chosen, in which the internal/external bit of the ip reachabilty has been deprecated. The level of the converted IS-IS LSP will be decided by configuration. It is recommended to set the default level as Level-1. 3.4 Supplement - There is no special toplogy limitation for PE/CE link and CE's sites. - There is no special requirement for CE router. 4. Extended Requirments +-----+ +-----+ L1/2| PE1 |---------| PE2 |L1/2 +-----+ +-----+ | | | | +-----+ +-----+ | CE1 |-------- | CE2 | +-----+ +-----+ Though clear and easily implemented, the solution as per section 3 has some disvantages, such as: - Routes delivered from one site to another are always treated as external routes is not desirable, because it will make the "false" routes undistinguished from the "real" external routes. - When there exists backdoor link connecting two CEs which belong to two different sites of one VPN, the IS-IS intra-area routes will be prefered to the VPN-IP routes which has been regarded as IS-IS external routes. As a result, the traffic will choose the direct link between CEs instead of passing through the IP backbone, which may be not accepted. - Moreover, when backdoor exists between sites, the route loop will happen on PEs, as both PE1 and PE2 import BGP routes into IS-IS. 4.1 Assumption There exists direct (backdoor) link between two different VPN sites. Further, there is IS-IS adjacency established over the backdoor link. Cheng Sheng Expires October 2003 [Page 4] Internet Draft draft-sheng-isis-bgp-mpls-vpn-01.txt June 2003 4.2 Carry IS-IS imformation with BGP Extended communities Per [VPN], BGP is in charge of distributing VPN-IP routes accross the VPN backbone. It is very useful to carry some of the important original IS-IS route information by BGP with BGP extended communities. These "important" original IS-IS route information are listed as follows: - IS-IS Route Type Extended Communites Attribute. This attribute is required, which is encoded with a two-byte type field and the type is 0201. The third byte is encoded as follows: - Level type: The first bit. When it is set 0, it indicates level-1 type route and the value of 1 indicates level-2 type route. - Metric style type: The second bit. When it is set 0, it indicates that the original IS-IS route is of narrow metric style which means the metric range of the route is [0, 1023], the value of 1 indicates wide metric style with the metric range expanded to [0, 2^32 -2^24] defined by [ISIS-TRAFFIC]. By default, it is set to 0. - TLV Reachability type: The third bit. When it is set 0, it indicates that the original IS-IS route is of internal reachability and the value 1 indicates external reachability. As per [ISIS-TRAFFIC], the internal/external type bit has been deprecated, this bit will be ignored when the metric style bit(the second bit) is set. - Metric type: The fourth bit. When it is set 0, it indicates the original route is of internal metric type and the value of 1 indicates external metric type. - sham-link endpoint address: the fifth bit. When it is set 1, it indicates the route is of sham-link endpoint address, which will be specified in 4.5. By default, this bit should be set as 0. - IS-IS System ID Extended Communites Attribute This attribute specifies the system ID of the particular VRF from which this route was exported. It is encoded with a two-byte type and the type is 0202. The system ID is carried in the rest six bytes. This attribute is optional, which means it is only necessary to be carried in the sham-link endpoint address route. Cheng Sheng Expires October 2003 [Page 5] Internet Draft draft-sheng-isis-bgp-mpls-vpn-01.txt June 2003 - MED. By default, this SHOULD be set to the value of the IS-IS distance associated with the route, plus 1. 4.3 Route loop prevention on PEs As per the diagram in section 4, when PE1 and PE2 both import BGP routes into their attached CE sites, the route loop will happen on both PEs. To avoid the route loop, it is assumed here that both PE1 and PE2 act as L1/2 router and there exists level-1 adjacency between each PE-CE link. The mechanism of how to avoid route loop with up/down bit in IS-IS level-1 LSP is specified in [ROUTE-LEAKING]. 4.4 IS-IS interaction with BGP on PE When PE receives a VPN-IP route, it will convert the route back to IS-IS. The creation of IS-IS LSP will be based on IS-IS route original information carried by BGP extended communities(as per section 4.2). For example, if the orignal IS-IS route is of level-1 type /internal reachability/internal metric type, the route will be re-converted to a level-1 intra-area route with internal metric type. Besides, the configuration for route redistribution about the IS-IS LSP information is prefered. All such function will work normally most of the time when only narrow-metric is used. When wide-metric is involved, the specification specified by 3.3 a) and b) should be followed. 4.5 Sham-link Creation As per [OSPF-VPN], sham-link plays a very important role for an link state IGP such as IS-IS and OSPF in preventing the VPN traffic going through backdoor between CEs. Before establishing the sham-link, each end PE should be assigned an real shamlink endpoint address which can be a loopback address in VRF to which the CE belongs. Also, we should ensure that the endpoint address of one side PE is visible to the PE of the other side. The source and destination sham-link endpoint address is designated by configuraiton. Cheng Sheng Expires October 2003 [Page 6] Internet Draft draft-sheng-isis-bgp-mpls-vpn-01.txt June 2003 For example, as per the diagram in section 4, it is necessary to establish a sham-link between PE1 and PE2. As the first step for PE1, BGP imports the loopback direct route which is designated as source shamlink endpoint address on PE2. Next, the converted BGP route carries BGP extended communities with sham-link endpoint address bit(as per section 4.2) set and IS-IS System ID Extended Communites Attribute with the value equal to the System ID of the specific IS-IS instance on the PE2.When PE1 receives the route, it checks the sham-link endpoint address bit and gets the IS-IS System ID the BGP route carry. If what the endpoint address PE1 get is the same as its configured destination sham-link endpoint address, it is believed that there exists an sham-link from PE1 to PE2. Finally,PE1 adds one Neighbor reachability TLV(TLV 2) in its self-originated LSP and floods it out to CE1. Similar process will happen on PE2. Note: when the PE finds that the system ID of the other end of the sham-link is changed, it will flush the old LSP and generate new LSP according to the new system ID got from BGP route. 5. Acknowledgments The authors would like to thank yangang, heqian, xuxiaofei, weixiugang chenjie for their comments on this work. 6. References [1] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)". [Also republished as RFC 1142.] [2] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [BGP-EXT] "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext- communities-05.txt>, Sangli, S., Tappan, D., Rekhter, Y., May 2002 [VPN] "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-02.txt, Rosen, E., et. al., July, 2002 [ROUTE-LEAKING] "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, T. Li Request, October 2000 [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-rosen-vpns-ospf-bgp-mpls-06.txt, Eric C. Rosen, June 2003 Cheng Sheng Expires October 2003 [Page 7] Internet Draft draft-sheng-isis-bgp-mpls-vpn-01.txt June 2003 7. Author's Addresses: Sheng Cheng D401 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : shengc@huawei.com Liu Yu A401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : liu_yu@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 Chen Yunqing Email : chenyunqing@vip.sina.com Cheng Sheng Expires October 2003 [Page 8] Internet Draft draft-sheng-isis-bgp-mpls-vpn-01.txt June 2003 --Boundary_(ID_19fYOrwtx5lF6NSyE5qYdA)-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 17 01:55:55 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17987 for ; Tue, 17 Jun 2003 01:55:55 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5H5tIo05871 for ; Tue, 17 Jun 2003 01:55:18 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5H5rsu13869 for ; Tue, 17 Jun 2003 01:53:54 -0400 (EDT) Date: Tue, 17 Jun 2003 13:50:35 +0800 From: lidefeng Subject: Re: Rejected posting to PPVPN@STANDARDS.NORTELNETWORKS.COM To: "L-Soft list server at Nortel Networks (1.8e)" Cc: PPVPN@qrtpd001.us.nortel.COM, ppvpn@nortelnetworks.com Message-id: <001601c33494$6008cee0$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0HGL003F8V9WLP@mta0.huawei.com> X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Why reject my e-mail posting a draft updation to the wg mail-list? ----- Original Message ----- From: "L-Soft list server at Nortel Networks (1.8e)" To: Sent: Tuesday, June 17, 2003 11:06 AM Subject: Rejected posting to PPVPN@STANDARDS.NORTELNETWORKS.COM > You are not authorized to send mail to the PPVPN list from your > lidefeng@HUAWEI.COM account. You might be authorized to send to the list from > another of your accounts, or perhaps when using another mail program which > generates slightly different addresses, but LISTSERV has no way to associate > this other account or address with yours. If you need assistance or if you have > any question regarding the policy of the PPVPN list, please contact the list > owners: PPVPN-request@STANDARDS.NORTELNETWORKS.COM. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 17 03:40:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02035 for ; Tue, 17 Jun 2003 03:40:42 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5H7e9o23853 for ; Tue, 17 Jun 2003 03:40:10 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5H7e6017661 for ; Tue, 17 Jun 2003 03:40:06 -0400 (EDT) Reply-To: From: =?us-ascii?Q?Guillermo_Ibanez?= To: Subject: unsubscribe Date: Tue, 17 Jun 2003 09:37:42 +0200 Message-ID: <000301c334a3$57402100$0201a8c0@windowxp> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030617022110.5840.qmail@web13604.mail.yahoo.com> Importance: Normal X-SMTP-HELO: smtp4.yaonline.es X-SMTP-MAIL-FROM: gibanezfer@jazzfree.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp4.yaonline.es [62.151.11.134] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Unsubscribe From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 17 04:03:27 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02926 for ; Tue, 17 Jun 2003 04:03:27 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5H82to02759 for ; Tue, 17 Jun 2003 04:02:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5H82qZ18098 for ; Tue, 17 Jun 2003 04:02:52 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: ppvpn@nortelnetworks.com Subject: BGP PW inter-provider scalability for VPLS Date: Tue, 17 Jun 2003 09:00:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: I have a couple of questions regarding the scalability of the VPLS BGP signalling draft. It seems to me there are two VPLS scaling issues regarding signalling in the inter-provider case: i) Number of BGP/LDP sessions ii) Number of PWs The BGP signalling draft addresses the first issue as service providers can use route reflectors with EBGP sessions between them (option C from rfc2547), however it does not address the second issue. For example, lets say we have an intra-provider network (SP1) with 800 customers, each of which have an average of 10 fully meshed VPN sites, the number of intra-provider PWs required would be: = m(n*(n-1)/2) - where m is the number of VPLS instances and n is the number of PEs = 800(10(10-1)/2) = 36,000 PWs Now lets say SP1 wanted to connect to another provider (SP2) to create an inter-provider service, and that 200 customers want to connect their 10 sites in SP1s network 10 sites in SP2s network in a full mesh giving a total of 20 sites. The number of PWs required would be: = m(n*(n-1)/2) = 200(20(20-1)/2) = 38,000 PWs Of these 38,000 PWs, some are SP1s intra-provider PWs, and some are SP2s intra-provider PWs. SP1s intra-provider PWs can be calculated using: = m(n*(n-1)/2) = 200(10(10-1)/2) = 9,000 PWs The calculation for SP2s intra-provider PWs gives the same number (9,000), which means the total number of inter-provider VPNs required between SP1 and SP2 is: 38,000 - 9,000 - 9,000 = 20,000. So, in the inter-provider case, SP1 must now provision and manage its original 36,000 intra-provider VPNs, plus 20,000 inter-provider PWs. This is just over a 55% increase in the number of PWs to provision and manage, even though only 25% of SP1s customers have inter-provider VPNs. The LDP VPLS signalling draft addresses this issue by defining a hierarchical model in which two fully meshed VPLS networks are connected together using a single LSP tunnel between the VPLS gateway devices. In the above example, only 200 PWs would be required between the two gateway PEs, as opposed to the 20,000 fully meshed PW in the BGP case. The LDP hierarchical model also addresses issue i) regarding the number of sessions required as only one LDP session is required between gateway sites. Although the hierarchical model may not be without its own problems (e.g. the issue of gateway PEs having to perform MAC address learning when connecting to multiple ASs has been brought up) it does address the problem regarding the number of PWs required. Questions: ========== I would be grateful if anyone can help with the following: 1. Are there plans to address the number of PWs scaling issue in the BGP VPLS draft? (Or perhaps this is addresses in a separate draft and I've missed it?) 2. I would also be interested to know what people think the biggest problem in the above example would be: a) MAC address learning at the gateway PE for 200 PWs, or provisioning and managing an extra 1,800 PWs. Thanks, Richard From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 17 07:16:08 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06995 for ; Tue, 17 Jun 2003 07:16:07 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HBFbo04715 for ; Tue, 17 Jun 2003 07:15:37 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5HBFYb15174 for ; Tue, 17 Jun 2003 07:15:34 -0400 (EDT) Message-ID: From: richard.spencer@bt.com To: ppvpn@nortelnetworks.com Subject: RE: BGP PW inter-provider scalability for VPLS Date: Tue, 17 Jun 2003 12:12:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: richard.spencer@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Having thought about this properly, option A or B from RFC2547 could be used instead of option C to reduce the number of PWs required. I guess the only question that remains is what's more important (i) reducing the number of inter-AS PWs at the expense of placing a heavier workload on the gateway devices, or (ii) using RRs with EBGP sessions between them to reduce the workload on ASBRs at the expense of increasing the number of inter-AS PWs?... Richard > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: 17 June 2003 09:01 > To: ppvpn@nortelnetworks.com > Subject: BGP PW inter-provider scalability for VPLS > > > I have a couple of questions regarding the scalability of > the VPLS BGP > signalling draft. It seems to me there are two VPLS scaling > issues regarding > signalling in the inter-provider case: > > i) Number of BGP/LDP sessions > ii) Number of PWs > > The BGP signalling draft addresses the first issue as > service providers can > use route reflectors with EBGP sessions between them (option C from > rfc2547), however it does not address the second issue. For > example, lets > say we have an intra-provider network (SP1) with 800 > customers, each of > which have an average of 10 fully meshed VPN sites, the number of > intra-provider PWs required would be: > > = m(n*(n-1)/2) - where m is the number of VPLS instances and > n is the number > of PEs > = 800(10(10-1)/2) > = 36,000 PWs > > Now lets say SP1 wanted to connect to another provider > (SP2) to create an > inter-provider service, and that 200 customers want to > connect their 10 > sites in SP1s network 10 sites in SP2s network in a full > mesh giving a total > of 20 sites. The number of PWs required would be: > > = m(n*(n-1)/2) > = 200(20(20-1)/2) > = 38,000 PWs > > Of these 38,000 PWs, some are SP1s intra-provider PWs, and > some are SP2s > intra-provider PWs. SP1s intra-provider PWs can be calculated using: > > = m(n*(n-1)/2) > = 200(10(10-1)/2) > = 9,000 PWs > > The calculation for SP2s intra-provider PWs gives the same > number (9,000), > which means the total number of inter-provider VPNs required > between SP1 and > SP2 is: 38,000 - 9,000 - 9,000 = 20,000. > > So, in the inter-provider case, SP1 must now provision and manage its > original 36,000 intra-provider VPNs, plus 20,000 > inter-provider PWs. This is > just over a 55% increase in the number of PWs to provision > and manage, even > though only 25% of SP1s customers have inter-provider VPNs. > > The LDP VPLS signalling draft addresses this issue by defining a > hierarchical model in which two fully meshed VPLS networks > are connected > together using a single LSP tunnel between the VPLS gateway > devices. In the > above example, only 200 PWs would be required between the > two gateway PEs, > as opposed to the 20,000 fully meshed PW in the BGP case. The LDP > hierarchical model also addresses issue i) regarding the > number of sessions > required as only one LDP session is required between gateway sites. > > Although the hierarchical model may not be without its own > problems (e.g. > the issue of gateway PEs having to perform MAC address learning when > connecting to multiple ASs has been brought up) it does > address the problem > regarding the number of PWs required. > > Questions: > ========== > > I would be grateful if anyone can help with the following: > > 1. Are there plans to address the number of PWs scaling > issue in the BGP > VPLS draft? (Or perhaps this is addresses in a separate > draft and I've > missed it?) > 2. I would also be interested to know what people think the > biggest problem > in the above example would be: a) MAC address learning at > the gateway PE for > 200 PWs, or provisioning and managing an extra 1,800 PWs. > > Thanks, > > Richard > > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 17 07:58:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08641 for ; Tue, 17 Jun 2003 07:58:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HBwQo10661 for ; Tue, 17 Jun 2003 07:58:27 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5HBwNA08063 for ; Tue, 17 Jun 2003 07:58:23 -0400 (EDT) Message-Id: <200306171156.HAA08249@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-yacine-ppvpn-mgt-frwk-01.txt Date: Tue, 17 Jun 2003 07:56:18 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] X-LYRIS-Message-Id: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework for PPVPN Operation and Management Author(s) : Y. Mghazli, A. Gonguet, T. Nadeau Filename : draft-yacine-ppvpn-mgt-frwk-01.txt Pages : 24 Date : 2003-6-16 This document provides a framework for Provider Provisioned Virtual Private Networks (PPVPNs) operation and management. This framework intends to produce a coherent description of the significant technical issues which are important in the design of PPVPN management solution. Selection of specific approaches, making choices among information models and protocols are outside of the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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: <2003-6-17075240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yacine-ppvpn-mgt-frwk-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-yacine-ppvpn-mgt-frwk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075240.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 17 08:16:44 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09376 for ; Tue, 17 Jun 2003 08:16:44 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HCGCo23914 for ; Tue, 17 Jun 2003 08:16:12 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5HCG9p16695 for ; Tue, 17 Jun 2003 08:16:10 -0400 (EDT) Message-ID: <20030617121419.34641.qmail@web41801.mail.yahoo.com> Date: Tue, 17 Jun 2003 13:14:19 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: Nos of Labels in CE To: mpls-ops@mplsrc.com, ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41801.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web41801.mail.yahoo.com [66.218.93.135] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Hi, Suppose there is an ingress edge router which has 2 interfaces and it has a nos of networks (basically different routes) which are reachable through these interfaces. Will this router allocate 2 labels (distinct for each interface) and advertise these different routes using these 2 labels OR will it allocate as many labels as the number of routes and then advertise to other PE routers using BGP? I assume that we would generally always go in for the former approach and not the latter. Is that true? And under what scenario will one want to advertise a unique label for each route? Carriers over Carriers, etc? Regards, JS ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 17 13:17:35 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27047 for ; Tue, 17 Jun 2003 13:17:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HHH3o05535 for ; Tue, 17 Jun 2003 13:17:03 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5HHH0u04604 for ; Tue, 17 Jun 2003 13:17:00 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: ppvpn@nortelnetworks.com Subject: RE: I-D ACTION:draft-yacine-ppvpn-mgt-frwk-01.txt Date: Tue, 17 Jun 2003 09:39:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C334D5.E72BDEDA" 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_01C334D5.E72BDEDA Content-Type: text/plain; charset="iso-8859-1" I assume this draft falls into common l2+l3 vpn drafts and most likely needs to appear in l3vpn charter (like the others)... Hamid. > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Framework for PPVPN Operation and Management > Author(s) : Y. Mghazli, A. Gonguet, T. Nadeau > Filename : draft-yacine-ppvpn-mgt-frwk-01.txt > Pages : 24 > Date : 2003-6-16 > > This document provides a framework for Provider Provisioned Virtual > Private Networks (PPVPNs) operation and management. This framework > intends to produce a coherent description of the significant > technical issues which are important in the design of PPVPN > management solution. Selection of specific approaches, making choices > among information models and protocols are outside of the scope of > this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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_001_01C334D5.E72BDEDA Content-Type: text/html; charset="iso-8859-1"
          I assume this draft falls into common l2+l3 vpn drafts and
          most likely needs to appear in l3vpn charter
          (like the others)...

          Hamid.

          >
          >
          > A New Internet-Draft is available from the on-line
          > Internet-Drafts directories.
          >
          >
          >       Title           : Framework for PPVPN Operation and Management
          >       Author(s)       : Y. Mghazli, A. Gonguet, T. Nadeau
          >       Filename        : draft-yacine-ppvpn-mgt-frwk-01.txt
          >       Pages           : 24
          >       Date            : 2003-6-16
          >      
          > This document provides a framework for Provider Provisioned Virtual
          > Private Networks (PPVPNs) operation and management. This framework
          > intends to produce a coherent description of the significant
          > technical issues which are important in the design of PPVPN
          > management solution. Selection of specific approaches, making choices
          > among information models and protocols are outside of the scope of
          > this document.
          >
          > A URL for this Internet-Draft is:
          >           http://www.ietf.org/internet-drafts/draft-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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_001_01C334D5.E72BDEDA-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 17 14:10:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29267 for ; Tue, 17 Jun 2003 14:10:21 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5HI8wo25137 for ; Tue, 17 Jun 2003 14:09:18 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5HI8tR28915 for ; Tue, 17 Jun 2003 14:08:55 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "Hamid Ould-Brahim" , Subject: RE: I-D ACTION:draft-yacine-ppvpn-mgt-frwk-01.txt Date: Tue, 17 Jun 2003 14:01:20 -0400 Organization: Cisco Systems Message-ID: <005601c334fa$7856ab00$ed472ca1@amer.cisco.com> 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, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal X-SMTP-HELO: sj-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-1.cisco.com [171.71.177.237] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I agree. --Tom > -----Original Message----- > From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] > Sent: Tuesday, June 17, 2003 9:40 AM > To: ppvpn@nortelnetworks.com > Subject: RE: I-D ACTION:draft-yacine-ppvpn-mgt-frwk-01.txt > > > I assume this draft falls into common l2+l3 vpn drafts and > most likely needs to appear in l3vpn charter > (like the others)... > > Hamid. > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Framework for PPVPN Operation and Management > > Author(s) : Y. Mghazli, A. Gonguet, T. Nadeau > > Filename : draft-yacine-ppvpn-mgt-frwk-01.txt > > Pages : 24 > > Date : 2003-6-16 > > > > This document provides a framework for Provider Provisioned Virtual > > Private Networks (PPVPNs) operation and management. This framework > > intends to produce a coherent description of the > significant technical > > issues which are important in the design of PPVPN > management solution. > > Selection of specific approaches, making choices among information > > models and protocols are outside of the scope of this document. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-yacine-ppvpn-mgt-frw > k-01.txt > > > > t> > > > > 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-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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. > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 18 02:42:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21432 for ; Wed, 18 Jun 2003 02:42:17 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5I6fjn12525 for ; Wed, 18 Jun 2003 02:41:45 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5I6fgI28683 for ; Wed, 18 Jun 2003 02:41:42 -0400 (EDT) Message-ID: <00e401c33564$61326440$56726051@c2f4r3> Reply-To: "MVNOinfo" From: "MVNOinfo" To: "MVNO world" References: <005301c33248$19e3cee0$56726051@c2f4r3> Subject: Very Hot Telecoms News Date: Wed, 18 Jun 2003 07:36:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01C3356C.54A2C780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SMTP-HELO: mta05-svc.ntlworld.com X-SMTP-MAIL-FROM: MVNOinfo@prs15891.demon.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mta05-svc.ntlworld.com [62.253.162.45] X-LYRIS-Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_00CC_01C3356C.54A2C780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Industry Colleague =20 Here is some hot-off-the-press industry news! =20 =20 UK MINUTES RESELLER SCOOPS US$300 million PHILIPPINE = PRE-PAID PHONECARD DEAL - VISIT: WWW.CHAMELEA.COM TO FIND OUT MORE a.. UK Minutes Reseller Milliennium Communications = scooped a US$300 million pre-paid calling card deal with the Seafarers = Association in the Philippines - right from under the noses of the = Asia-Pacific telecoms industry. Find out why & how the UK minutes resale = channel is so strong, by simply registering with the Community Section = at: www.Chamelea.com. What's the 'hottest' opportunity in Global Telecoms = today? - find out at: WWW.MVNOINFO.COM=20 a.. "LAN Hotspots"; "PW-LANs"; "R-LANs" - call = them what you will - but these are much sought-after locations for = Laptop Nomads and Road Warriors. Find out more about about this exciting = new area of telecoms at WiFi-World by simply registering for our = Community Section at: www.MVNOinfo.com. =20 Hot Telecom Topics brought to you by: Chameleon = Communication Consulting 40 years experience in telecommunications - = www.chamelea.com =20 =20 =20 =20 ------------------------------------------------------------------------ Messages are e-mailed to keep you up-to-date with new Chameleon = Communication Consulting topics, products and services. If you prefer = not to receive these messages, please reply with 'unsubscribe' in the = subject area. =20 =20 =20 ------=_NextPart_000_00CC_01C3356C.54A2C780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
          Dear = Industry=20 Colleague
           
          Here is=20 some hot-off-the-press industry news!

           

          UK MINUTES = RESELLER=20 SCOOPS US$300 million PHILIPPINE PRE-PAID PHONECARD = DEAL -=20 VISIT: WWW.CHAMELEA.COM TO=20 FIND OUT MORE

          • UK Minutes Reseller = Milliennium=20 Communications scooped a US$300 million pre-paid = calling=20 card deal with the Seafarers Association in = the=20 Philippines - right from under the noses of the=20 Asia-Pacific telecoms industry. Find out why = &=20 how the UK minutes resale channel is so = strong, by=20 simply registering with the Community = Section=20 at: www.Chamelea.com.

          What's the 'hottest'=20 opportunity in Global Telecoms today? - = find out=20 at: WWW.MVNOINFO.COM

          • "LAN=20 Hotspots"; "PW-LANs"; "R-LANs"  - call them = what you=20 will - but these are much sought-after locations = for=20 Laptop Nomads and Road Warriors. Find out more = about about=20 this exciting new area of telecoms at = WiFi-World by=20 simply registering for our Community Section=20 at: www.MVNOinfo.com.
           
           
          Hot Telecom=20 Topics brought to you by: = Chameleon Communication = Consulting
          40=20 years experience in telecommunications -=20 www.chamelea.com=20 =
                     Messages are e-mailed to = keep you=20 up-to-date with new Chameleon Com          munication=20 Consulting t= opics,=20 products and services. If you prefer not to receive these = messages,=20 please reply with 'unsubscribe' in the subject=20 area.
          =20 ------=_NextPart_000_00CC_01C3356C.54A2C780-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 18 08:38:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00659 for ; Wed, 18 Jun 2003 08:38:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5ICc0n27857 for ; Wed, 18 Jun 2003 08:38:00 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5ICbvn18222 for ; Wed, 18 Jun 2003 08:37:57 -0400 (EDT) Message-ID: <3EF05CAE.8080109@alcatel.fr> Date: Wed, 18 Jun 2003 14:35:58 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 CC: ppvpn@nortelnetworks.com Subject: Re: I-D ACTION:draft-yacine-ppvpn-mgt-frwk-01.txt References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/18/2003 14:35:58, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/18/2003 14:35:59, Serialize complete at 06/18/2003 14:35:59 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new X-SMTP-HELO: smail3.alcatel.fr X-SMTP-MAIL-FROM: yacine.el_mghazli@alcatel.fr X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: na5.alcatel.fr [194.133.58.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit yes, as well as Security and QoS frameworks. Hamid Ould-Brahim wrote: > I assume this draft falls into common l2+l3 vpn drafts and > > most likely needs to appear in l3vpn charter > > (like the others)... > > Hamid. > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Framework for PPVPN Operation and Management > > Author(s) : Y. Mghazli, A. Gonguet, T. Nadeau > > Filename : draft-yacine-ppvpn-mgt-frwk-01.txt > > Pages : 24 > > Date : 2003-6-16 > > > > This document provides a framework for Provider Provisioned Virtual > > Private Networks (PPVPNs) operation and management. This framework > > intends to produce a coherent description of the significant > > technical issues which are important in the design of PPVPN > > management solution. Selection of specific approaches, making choices > > among information models and protocols are outside of the scope of > > this document. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 18 08:51:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01919 for ; Wed, 18 Jun 2003 08:51:32 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5ICoun04129 for ; Wed, 18 Jun 2003 08:50:57 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5ICorS01026 for ; Wed, 18 Jun 2003 08:50:54 -0400 (EDT) Message-ID: <3EF05F6B.EF835696@alcatel.be> Date: Wed, 18 Jun 2003 14:47:39 +0200 From: jeremy.de_clercq@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Hamid Ould-Brahim" CC: ppvpn@nortelnetworks.com Subject: Re: I-D ACTION:draft-yacine-ppvpn-mgt-frwk-01.txt References: X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/18/2003 14:47:39, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/18/2003 14:47:45, Serialize complete at 06/18/2003 14:47:45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: bt0rjw.god.bel.alcatel.be X-SMTP-MAIL-FROM: jeremy.de_clercq@alcatel.be X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: alc240.alcatel.be [195.207.101.240] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit I agree that it needs to appear in the L3VPN charter. Jeremy. -- +=================== > Hamid Ould-Brahim wrote: > > I assume this draft falls into common l2+l3 vpn drafts and > most likely needs to appear in l3vpn charter > (like the others)... > > Hamid. > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Framework for PPVPN Operation and Management > > Author(s) : Y. Mghazli, A. Gonguet, T. Nadeau > > Filename : draft-yacine-ppvpn-mgt-frwk-01.txt > > Pages : 24 > > Date : 2003-6-16 > > > > This document provides a framework for Provider Provisioned Virtual > > Private Networks (PPVPNs) operation and management. This framework > > intends to produce a coherent description of the significant > > technical issues which are important in the design of PPVPN > > management solution. Selection of specific approaches, making > choices > > among information models and protocols are outside of the scope of > > this document. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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-yacine-ppvpn-mgt-frwk-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. > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 18 11:40:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13329 for ; Wed, 18 Jun 2003 11:40:20 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5IFdnn05815 for ; Wed, 18 Jun 2003 11:39:49 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5IFdjG26442 for ; Wed, 18 Jun 2003 11:39:45 -0400 (EDT) Message-ID: <20030618153758.50533.qmail@web41806.mail.yahoo.com> Date: Wed, 18 Jun 2003 08:37:58 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Final Call for Participation To: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1100949293-1055950678=:49163" X-SMTP-HELO: web41806.mail.yahoo.com X-SMTP-MAIL-FROM: info@caitr.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web41806.mail.yahoo.com [66.218.93.140] X-LYRIS-Message-Id: --0-1100949293-1055950678=:49163 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 =================================================================== http://www.caitr.org/internetworking03/index.htm =================================================================== You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials. Registration for the conference is underway - online registration is available. To register, go to: http://www.caitr.org/internetworking03/registration.htm Program: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details) Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - Domain Constrained Multicast: A New Approach for IP Multicast Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - C ertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - An Analysis of Hand-off methods in some WAN and LAN networks Tuesday June 24 Session: Routing Performance - Optimizing Route Convergence - Active Dynamic Routing - Fluid flow network modeling for hop-by-hop feedback control design and analysis Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseu dowire OAM: A Mandatory Yet Often Overlooked Feature - Non-Elementary Routing and Wavelength Assignment under General Wavelength-Switching Constraints - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: Routing Architecture & QoS - QoS Routing in Networks with Non-Deterministic Information - A new routing architecture: Atomised Routing - Traceroute and BGP AS Path Incongruities - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs : - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-1100949293-1055950678=:49163 Content-Type: text/html; charset=us-ascii
               Internetworking 2003 International Conference
               Hilton San Jose & Towers Hotel, California
                        June 22-June 24, 2003
          ===================================================================
              http://www.caitr.org/internetworking03/index.htm
          ===================================================================
           
          You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.

          Registration for the conference is underway - online registration is available. To register, go to:
           http://www.caitr.org/internetworking03/registration.htm
           
          Program:
          -------------
          (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
           
          Sunday June 22
              Tutorial-1: MPLS VPNs
              Tutorial-2: IPv6
              Tutorial-3: Mobile Wireless Internet Architecture and Protocols
              Tutorial-4: Voice over Packet
           
          Monday June 23
              Welcome and Keynote
           
              Session: Network Technology Trends
                - Forwarding Element and Control Separation
                - Evolution of Inter-Domain Routing 
                - Network Processing Building Blocks: Enabling the Routers of the Future
           
              Session: Network Architecture
                - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
                - Domain Constrained Multicast: A New Approach for IP Multicast Routing
                - Internetworking MPLS Layer 2 Transport with an IP Services Network
           
              Session: Storage Area Networks
                - Storage as a Network Node
                - Object-Based Storage
                - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP
                - SANs Considerations
           
              Session: Mobile & Wireless Networks
                - C ertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
                - Challenges and Roadmap of UMTS Network Deployment
                - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS
                - Mobile Authentication and QoS
                - An Analysis of Hand-off methods in some WAN and LAN networks
           
          Tuesday June 24
              Session: Routing Performance
                - Optimizing Route Convergence
                - Active Dynamic Routing 
                - Fluid flow network modeling for hop-by-hop feedback control design and analysis
           
              Session:  Applications & Services
                - Securing the Web with Next Generation Encryption Technologies
                - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 
                - A novel EAC semantic for the RTSP protocol
                - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
           
              Session:  Network Management & Planning
                - Pse! u dowire OAM: A Mandatory Yet Often Overlooked Feature
                - Non-Elementary Routing and Wavelength Assignment under General Wavelength-Switching Constraints
                - Cross-domain multimedia service provisioning, the EVOLUTE solution
           
              Session:  Routing Architecture & QoS
                - QoS Routing in Networks with Non-Deterministic Information
                - A new routing architecture: Atomised Routing
                - Traceroute and BGP AS Path Incongruities
                - QoS routing for Differentiated Services: simulations and prototype experiments
                - Probabilistic routing for QoS improvement in GPS networks
           
          We look forward to seeing you at the Conference.
           
          Regards,
           Conference Technical Co-chairs :
           - Dr. Maurice Gagnaire, ENST, France
           - Daniel Awduche
           Technical Program Committee of the Internetworking 2003 Conference:
           - Roberto Sabella, Erisson
           - Dr. Moshe Zukerman, Univ. of Melbourne
           - Nada Golmie, NIST
           - Dr. Guy Pujolle, LIP6, France
           - Dr. Samir Tohme, ENST, France
           - Stefano Trumpy, Italian National Research Council
           - Dr. Ibrahim Habib, City Univ. of NY
           - Dr. Marc Lobelle, UCL University, Belgium
           - Dr. Parviz Yegani, Cisco Systems
           - Dr. G.S. Kuo
           - Dr. Abbas Jamalipour, Univ. of Sydney
           - Dr. Hussein Mouftah, Univ. of Ottawa
           - James Kempf
           - Elizabeth Rodriguez
           - Dr. Ferit Yegenoglu, Isocore
           - Dr. Ali Zadeh, George Mason University
           - Dr. Tony Przygienda, Xebeo
           - Ran Canetti, IBM
          --0-1100949293-1055950678=:49163-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 18 13:49:00 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18098 for ; Wed, 18 Jun 2003 13:48:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5IHmRn21119 for ; Wed, 18 Jun 2003 13:48:27 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5IHmMM29407 for ; Wed, 18 Jun 2003 13:48:22 -0400 (EDT) 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.6375.0 Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Wed, 18 Jun 2003 12:42:33 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA011BEA31@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG lat call on LSR and LDP MIB modules - setting dates Thread-Index: AcMwvo69ayfmybo0R6SDCEKbpC4cTAANNqBQATAhrUA= From: "Ash, Gerald R (Jerry), ALABS" To: "Wijnen, Bert (Bert)" , "Loa Andersson" , "MPLS WG" Cc: "Ash, Gerald R (Jerry), ALABS" , "Lai, Wai S (Waisum), ALABS" , "Chung, Li-Jin W, ALABS" , X-SMTP-HELO: almso1.proxy.att.com X-SMTP-MAIL-FROM: gash@att.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: almso1.att.com [192.128.167.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA18098 Bert, Loa, All, I'd like to follow up on Wai Sum's comments below, and encourage that high-priority MPLS-MIB problems/requirements identified through extensive testing be addressed in the MPLS MIB modules. The MPLS MIB problems/requirements are identified in http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, and are critical operator requirements stemming from detailed lab testing by Li Chung and others at AT&T. MPLS-VPNs aren't going to operate as well as needed until and unless these requirements are met. It is expected that operators wishing to use the same MPLS MIBs would have similar concerns. The I-D does not propose specific MIB extensions based on the requirements. Rather, such extensions are left to the MIB designers, in order to avoid past discussions of why specific extensions won't work. But so far there is no help or response from MIB designers on how to meet the requirements, even though the problems have been identified on email lists for more than one year. Here is a summary of requirements (R1,R2,R3 LDP related; R4,R5 VPN related): R1. It is required to capture the signaling usage/performance of the LDP Entities, as well as the traffic usage/performance of the LDP Sessions. R2. It is required to ensure persistency of information in the LDP-MIB Entity Table and Entity Statistics Table, whenever an LDP Entity is disabled and then re-enabled. R3. It is required that a count be reported of mplsNumVrfRouteMaxThreshExceeded notification when the operator-defined VRF maximum route threshold is exceeded. R4. It is required to have an explicit mapping between VRF, RD, and RT in the mplsVpnVrfRouteTargetTable table. R5. It is required to track the number of BGP prefixes on the PE-CE link, and that the BGP neighbor maximum-prefix limit on the PE-CE link be used to limit the number of eBGP routes injected in the VRF. I agree with Harmen Van der Linde, "We need to get this MPLS MIB module, together with the MPLS LDP and MPLS VPN modules, standardized ASAP. There is a critical need for these MPLS MIB modules for management of MPLS-enabled networks, which are currently being deployed by many service providers." Bert threatened at IETF-56 to start over on MPLS MIBs if not finished by IETF-57. We need the MPLS MIB designers to meet critical requirements and complete ASAP. Thanks, Jerry -----Original Message----- From: Lai, Wai S (Waisum), ALABS Sent: Thursday, June 12, 2003 2:52 PM To: Loa Andersson; MPLS WG Cc: Chung, Li-Jin W, ALABS; Ash, Gerald R (Jerry), ALABS Subject: RE: WG last call on LSR and LDP MIB modules - setting dates I would like to bring to your attention, once again, the requirements in http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt For the LDP and possibly the LSR MIBs, requirements are specified in the above I-D, which include, for example, requirements for performance and fault management so as to lessen dependence on the NMS. Such capabilities should be considered based on the requirements, and if appropriate, should be included in the appropriate MIBs. Thanks, Wai Sum -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, June 12, 2003 4:24 AM To: MPLS WG Subject: WG last call on LSR and LDP MIB modules - setting dates Folks, the time for this wg call has been extended to June 24th noon CET. /Loa -------- Original Message -------- Subject: Re: WG last call on LSR and LDP MIB modules - CORRECTION! Date: Tue, 10 Jun 2003 08:12:00 +0200 From: Loa Andersson To: MPLS WG CC: Loa Andersson , Bert Wijnen , Alex Zinin All, a misunderstanding between me and the authors resulted in that the wrong version of the LDP mib module was sent to this wg last call. The correct version is this has just been sent for publication (and with a copy to the mailing list). My take is that we continue the wg last call as planned, but as soon as I see the LDP mib being published I will extend the last call period. This way will get both a head start and the required period of time. /Loa Loa Andersson wrote: > All, > > this is to initiate a two week wg last call on > > Multiprotocol Label Switching (MPLS) Label Switching > Router (LSR) Management Information Base > > > and > Definitions of Managed Objects for the Multiprotocol Label > Switching, Label Distribution Protocol (LDP) > > > this wg last call ends June 22nd, and is limited to the changes in the > IDs since the previous wg last call, as well as interdependencies between > the two mib modules and the mib modules listed below. > > For the LSR MIB please re-read the mail I sent to the list June 6 called > "prequeal to WG last call on the LSR mib module" > > A usual silence will be understood as support, but this would not > necessarily stop you from giving positive comments. Please do. > > There are more MIB modules coming up for wg last call and that have been > through wg last call, all of those will have interdependencies. > > 1. the TC mib module are wg last called and updated, but waiting for the > others to be ready for IESG review > > 2. the TE link MIB module is in wg last call (to end June 13) > > 3. the management overview has been through wg last call and has been > updated > > > Two other MIB modules are in the pipe and new version will be released > shortly > > 5. The TE mib module > 6. The FTN mib module > > It is important that we complete this process of reviewing and updating > before the ID cut off date (June 30) for the Vienna meeting. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 18 14:06:57 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18938 for ; Wed, 18 Jun 2003 14:06:56 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5II6Nn06199 for ; Wed, 18 Jun 2003 14:06:24 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5II6K118828 for ; Wed, 18 Jun 2003 14:06:20 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Wijnen, Bert \(Bert\)'" , "'Loa Andersson'" , "'MPLS WG'" Cc: "'Lai, Wai S \(Waisum\), ALABS'" , "'Chung, Li-Jin W, ALABS'" , , "'Van der Linde, Harmen, ALABS'" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Wed, 18 Jun 2003 14:03:33 -0400 Organization: Cisco Systems Message-ID: <01bf01c335c3$f2fb82d0$ed472ca1@amer.cisco.com> 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, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA011BEA31@KCCLUST06EVS1.ugd.att.com> Importance: Normal X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Jerry, I do fully agree with Harmen's statement that the MIBs need to be wrapped up ASAP and appreciate his feedback as an operator. I think that we are well on this track. To address your statement about requirements, as discussed previously offline with yourself and the MIB co-authors, many of the requirements you listed below require changes to the LDP protocol itself. Given this, I suggest that you consult with other SPs in the WG on these requirements to make sure that they are consistent. I personally have not been hearing any of these requirements from other SPs that participate in the MPLS WG. In addition, I suggest that you direct your requirements to the authors of the LDP specifications and propose extensions/additions there first because the MIBs cannot manage what the protocols will not provide. The remaining requirements you listed below apply specifically to the PPVPN-MPLS-VPN MIB and not to the base MPLS MIBs which are in WG last call presently. --Tom > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: Wednesday, June 18, 2003 1:43 PM > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > Bert, Loa, All, > > I'd like to follow up on Wai Sum's comments below, and > encourage that high-priority MPLS-MIB problems/requirements > identified through extensive testing be addressed in the MPLS > MIB modules. > > The MPLS MIB problems/requirements are identified in > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.tx > t, and are critical operator requirements stemming from > detailed lab testing by Li Chung and others at AT&T. > MPLS-VPNs aren't going to operate as well as needed until and > unless these requirements are met. It is expected that > operators wishing to use the same MPLS MIBs would have > similar concerns. > > The I-D does not propose specific MIB extensions based on the > requirements. Rather, such extensions are left to the MIB > designers, in order to avoid past discussions of why specific > extensions won't work. But so far there is no help or > response from MIB designers on how to meet the requirements, > even though the problems have been identified on email lists > for more than one year. > > Here is a summary of requirements (R1,R2,R3 LDP related; > R4,R5 VPN related): > > R1. It is required to capture the signaling usage/performance > of the LDP Entities, as well as the traffic usage/performance > of the LDP Sessions. R2. It is required to ensure persistency > of information in the LDP-MIB Entity Table and Entity > Statistics Table, whenever an LDP Entity is disabled and then > re-enabled. R3. It is required that a count be reported of > mplsNumVrfRouteMaxThreshExceeded notification when the > operator-defined VRF maximum route threshold is exceeded. R4. > It is required to have an explicit mapping between VRF, RD, > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is > required to track the number of BGP prefixes on the PE-CE > link, and that the BGP neighbor maximum-prefix limit on the > PE-CE link be used to limit the number of eBGP routes > injected in the VRF. > > I agree with Harmen Van der Linde, "We need to get this MPLS > MIB module, together with the MPLS LDP and MPLS VPN modules, > standardized ASAP. There is a critical need for these MPLS > MIB modules for management of MPLS-enabled networks, which > are currently being deployed by many service providers." > > Bert threatened at IETF-56 to start over on MPLS MIBs if not > finished by IETF-57. > > We need the MPLS MIB designers to meet critical requirements > and complete ASAP. > > Thanks, > Jerry > > -----Original Message----- > From: Lai, Wai S (Waisum), ALABS > Sent: Thursday, June 12, 2003 2:52 PM > To: Loa Andersson; MPLS WG > Cc: Chung, Li-Jin W, ALABS; Ash, Gerald R (Jerry), ALABS > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > I would like to bring to your attention, once again, the > requirements in > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt > > For the LDP and possibly the LSR MIBs, requirements are > specified in the above I-D, which include, for example, > requirements for performance and fault management so as to > lessen dependence on the NMS. Such capabilities should be > considered based on the requirements, and if appropriate, > should be included in the appropriate MIBs. > > Thanks, Wai Sum > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Thursday, June 12, 2003 4:24 AM > To: MPLS WG > Subject: WG last call on LSR and LDP MIB modules - setting dates > > Folks, > > the time for this wg call has been extended to June 24th noon CET. > > /Loa > > -------- Original Message -------- > Subject: Re: WG last call on LSR and LDP MIB modules - CORRECTION! > Date: Tue, 10 Jun 2003 08:12:00 +0200 > From: Loa Andersson > To: MPLS WG > CC: Loa Andersson , Bert Wijnen , Alex > Zinin > > All, > > a misunderstanding between me and the authors resulted in > that the wrong version of the LDP mib module was sent to this > wg last call. > > The correct version is > > > > this has just been sent for publication (and with a copy to > the mailing list). > > My take is that we continue the wg last call as planned, but > as soon as I see the LDP mib being published I will extend > the last call period. This way will get both a head start and > the required period of time. > > /Loa > > Loa Andersson wrote: > > > All, > > > > this is to initiate a two week wg last call on > > > > Multiprotocol Label Switching (MPLS) Label Switching > > Router (LSR) Management Information Base > > > > > > and > > Definitions of Managed Objects for the Multiprotocol Label > > Switching, Label Distribution Protocol (LDP) > > > > > > this wg last call ends June 22nd, and is limited to the > changes in the > IDs since the previous wg last call, as > well as interdependencies between > the two mib modules and > the mib modules listed below. > > For the LSR MIB please > re-read the mail I sent to the list June 6 called > > "prequeal to WG last call on the LSR mib module" > > A > usual silence will be understood as support, but this would > not > necessarily stop you from giving positive comments. > Please do. > > There are more MIB modules coming up for wg > last call and that have been > through wg last call, all of > those will have interdependencies. > > 1. the TC mib module > are wg last called and updated, but waiting for the > > others to be ready for IESG review > > > > 2. the TE link MIB module is in wg last call (to end June 13) > > > > 3. the management overview has been through wg last call > and has been > > updated > > > > > > Two other MIB modules are in the pipe and new version will > be released > shortly > > 5. The TE mib module > > 6. The FTN mib module > > > It is important that > we complete this process of reviewing and updating > before > the ID cut off date (June 30) for the Vienna meeting. > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 18 15:20:07 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23928 for ; Wed, 18 Jun 2003 15:20:07 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5IJJ1n01298 for ; Wed, 18 Jun 2003 15:19:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5IJIwx28166 for ; Wed, 18 Jun 2003 15:18:59 -0400 (EDT) From: "FWION" To: Subject: unsubscribe Date: Wed, 18 Jun 2003 15:16:28 -0400 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) Importance: Normal In-Reply-To: <20030617022110.5840.qmail@web13604.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SMTP-HELO: mailsrv02.fwion.com X-SMTP-MAIL-FROM: mbowser@fwion.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: h-66-134-29-228.NYCMNY83.covad.net [66.134.29.228] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit unsubscribe From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 18 16:56:37 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29411 for ; Wed, 18 Jun 2003 16:56:37 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5IKu4n28131 for ; Wed, 18 Jun 2003 16:56:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5IKu1Z11332 for ; Wed, 18 Jun 2003 16:56:01 -0400 (EDT) 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.6249.0 Subject: unsubscribe Date: Wed, 18 Jun 2003 15:54:01 -0500 Message-ID: Thread-Topic: unsubscribe Thread-Index: AcM1zp6qwWK2Fh4EQd+UmTIQbwGsQQADRNOg From: "Liu, Jacques" To: X-OriginalArrivalTime: 18 Jun 2003 20:54:01.0814 (UTC) FILETIME=[BF2EEF60:01C335DB] X-SMTP-HELO: corpsmtp2.molex.com X-SMTP-MAIL-FROM: Jacques.Liu@molex.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [204.188.53.6] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA29411 unsubscribe From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 19 07:44:20 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10113 for ; Thu, 19 Jun 2003 07:44:19 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JBhlV19952 for ; Thu, 19 Jun 2003 07:43:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5JBhhQ03212 for ; Thu, 19 Jun 2003 07:43:43 -0400 (EDT) Reply-To: From: "Sakthivadivu.S.S" To: Subject: BGP/MPLS VPN Date: Thu, 19 Jun 2003 16:50:51 +0530 Message-Id: <003301c33654$d7c6f940$4406140a@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) 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: sakthivss@future.futsoft.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [203.197.140.35] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi, When two sites namely site1 and site2 are connected to the same PE router (PE1), is it required to run two instances of BGP in PE router.Suppose if both site1 and site2 are having same route (110.10/16) and EBGP is running between CE router and PE router, how will PE router handle this routes. since IPV4 routes will be same which are received from CE router.Before converting to VPN-IPV4 routes, the decesion process will be run and only one route will be installed in BGP. Please help me to handle this situation without using multiple instance of BGP in PE router. Regards, Sakthi *************************************************************************** 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-132618@lyris.nortelnetworks.com Thu Jun 19 08:40:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14119 for ; Thu, 19 Jun 2003 08:40:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JCdYV03133 for ; Thu, 19 Jun 2003 08:39:34 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5JCdVF28480 for ; Thu, 19 Jun 2003 08:39:31 -0400 (EDT) Message-Id: <3.0.1.32.20030619083652.018448d4@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 19 Jun 2003 08:36:52 -0400 To: , "'Ash, Gerald R \(Jerry\), ALABS'" , "'Wijnen, Bert \(Bert\)'" , "'Loa Andersson'" , "'MPLS WG'" From: jcucchiara@mindspring.com Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Cc: "'Lai, Wai S \(Waisum\), ALABS'" , "'Chung, Li-Jin W, ALABS'" , , "'Van der Linde, Harmen, ALABS'" In-Reply-To: <01bf01c335c3$f2fb82d0$ed472ca1@amer.cisco.com> References: <9473683187ADC049A855ED2DA739ABCA011BEA31@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: tisch.mail.mindspring.net X-SMTP-MAIL-FROM: jcucchiara@mindspring.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: tisch.mail.mindspring.net [207.69.200.157] X-LYRIS-Message-Id: At 02:03 PM 6/18/03 -0400, Thomas D. Nadeau wrote: > > Jerry, > > I do fully agree with Harmen's statement >that the MIBs need to be wrapped up ASAP and >appreciate his feedback as an operator. I think >that we are well on this track. Agreed. > > To address your statement about requirements, >as discussed previously offline with yourself >and the MIB co-authors, many of the requirements >you listed below require changes to the LDP protocol >itself. Given this, I suggest that you consult with >other SPs in the WG on these requirements to make sure >that they are consistent. I personally have not been hearing >any of these requirements from other SPs that participate >in the MPLS WG. In addition, I suggest that you >direct your requirements to the authors of the LDP >specifications and propose extensions/additions there >first because the MIBs cannot manage what the protocols >will not provide. The remaining requirements you listed My read of the draft is that the authors are indeed requesting changes to the LDP protocol. One example is the discussion on sessions being enabled/disabled. As Tom points out, this is not in the MIB because it is not in the protocol. Additionally, there are several claims made about the NMS but these are not given in any context. For example, is not clear how many nodes are on the network, how many nodes an NMS is monitoring, if an out-of-band management network is being used, what other MIBs are supported on the device and being polled for by the NMS? etc. Context would be helpful to better understand what the problem is that is trying to be solved. Why does the NMS have problems with the LDP-MIB and not with the polling for other MIBs? That does not make sense to me. A question was made privately to one of the authors at the Atlanta IETF that perhaps a MIB which stores LDP counter information in a history table (such as is done in SONET) could be useful to them? I did not receive any response to this question. So I am asking again, why wouldn't a history table solve some of the issues? If history tables would be thought useful, this could be proposed to the working group in a separate MIB module, but would be outside the scope of the present LDP-MIB. -Joan >below apply specifically to the PPVPN-MPLS-VPN MIB and not >to the base MPLS MIBs which are in WG last call presently. > > --Tom > > >> -----Original Message----- >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> Sent: Wednesday, June 18, 2003 1:43 PM >> To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG >> Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; >> Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com >> Subject: RE: WG last call on LSR and LDP MIB modules - setting dates >> >> >> Bert, Loa, All, >> >> I'd like to follow up on Wai Sum's comments below, and >> encourage that high-priority MPLS-MIB problems/requirements >> identified through extensive testing be addressed in the MPLS >> MIB modules. >> >> The MPLS MIB problems/requirements are identified in >> http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.tx >> t, and are critical operator requirements stemming from >> detailed lab testing by Li Chung and others at AT&T. >> MPLS-VPNs aren't going to operate as well as needed until and >> unless these requirements are met. It is expected that >> operators wishing to use the same MPLS MIBs would have >> similar concerns. >> >> The I-D does not propose specific MIB extensions based on the >> requirements. Rather, such extensions are left to the MIB >> designers, in order to avoid past discussions of why specific >> extensions won't work. But so far there is no help or >> response from MIB designers on how to meet the requirements, >> even though the problems have been identified on email lists >> for more than one year. >> >> Here is a summary of requirements (R1,R2,R3 LDP related; >> R4,R5 VPN related): >> >> R1. It is required to capture the signaling usage/performance >> of the LDP Entities, as well as the traffic usage/performance >> of the LDP Sessions. R2. It is required to ensure persistency >> of information in the LDP-MIB Entity Table and Entity >> Statistics Table, whenever an LDP Entity is disabled and then >> re-enabled. R3. It is required that a count be reported of >> mplsNumVrfRouteMaxThreshExceeded notification when the >> operator-defined VRF maximum route threshold is exceeded. R4. >> It is required to have an explicit mapping between VRF, RD, >> and RT in the mplsVpnVrfRouteTargetTable table. R5. It is >> required to track the number of BGP prefixes on the PE-CE >> link, and that the BGP neighbor maximum-prefix limit on the >> PE-CE link be used to limit the number of eBGP routes >> injected in the VRF. >> >> I agree with Harmen Van der Linde, "We need to get this MPLS >> MIB module, together with the MPLS LDP and MPLS VPN modules, >> standardized ASAP. There is a critical need for these MPLS >> MIB modules for management of MPLS-enabled networks, which >> are currently being deployed by many service providers." >> >> Bert threatened at IETF-56 to start over on MPLS MIBs if not >> finished by IETF-57. >> >> We need the MPLS MIB designers to meet critical requirements >> and complete ASAP. >> >> Thanks, >> Jerry >> >> -----Original Message----- >> From: Lai, Wai S (Waisum), ALABS >> Sent: Thursday, June 12, 2003 2:52 PM >> To: Loa Andersson; MPLS WG >> Cc: Chung, Li-Jin W, ALABS; Ash, Gerald R (Jerry), ALABS >> Subject: RE: WG last call on LSR and LDP MIB modules - setting dates >> >> I would like to bring to your attention, once again, the >> requirements in >> http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt >> >> For the LDP and possibly the LSR MIBs, requirements are >> specified in the above I-D, which include, for example, >> requirements for performance and fault management so as to >> lessen dependence on the NMS. Such capabilities should be >> considered based on the requirements, and if appropriate, >> should be included in the appropriate MIBs. >> >> Thanks, Wai Sum >> >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.se] >> Sent: Thursday, June 12, 2003 4:24 AM >> To: MPLS WG >> Subject: WG last call on LSR and LDP MIB modules - setting dates >> >> Folks, >> >> the time for this wg call has been extended to June 24th noon CET. >> >> /Loa >> >> -------- Original Message -------- >> Subject: Re: WG last call on LSR and LDP MIB modules - CORRECTION! >> Date: Tue, 10 Jun 2003 08:12:00 +0200 >> From: Loa Andersson >> To: MPLS WG >> CC: Loa Andersson , Bert Wijnen , Alex >> Zinin >> >> All, >> >> a misunderstanding between me and the authors resulted in >> that the wrong version of the LDP mib module was sent to this >> wg last call. >> >> The correct version is >> >> >> >> this has just been sent for publication (and with a copy to >> the mailing list). >> >> My take is that we continue the wg last call as planned, but >> as soon as I see the LDP mib being published I will extend >> the last call period. This way will get both a head start and >> the required period of time. >> >> /Loa >> >> Loa Andersson wrote: >> >> > All, >> > >> > this is to initiate a two week wg last call on >> > >> > Multiprotocol Label Switching (MPLS) Label Switching >> > Router (LSR) Management Information Base >> > >> > >> > and >> > Definitions of Managed Objects for the Multiprotocol Label >> > Switching, Label Distribution Protocol (LDP) >> > >> > >> > this wg last call ends June 22nd, and is limited to the >> changes in the > IDs since the previous wg last call, as >> well as interdependencies between > the two mib modules and >> the mib modules listed below. > > For the LSR MIB please >> re-read the mail I sent to the list June 6 called > >> "prequeal to WG last call on the LSR mib module" > > A >> usual silence will be understood as support, but this would >> not > necessarily stop you from giving positive comments. >> Please do. > > There are more MIB modules coming up for wg >> last call and that have been > through wg last call, all of >> those will have interdependencies. > > 1. the TC mib module >> are wg last called and updated, but waiting for the >> > others to be ready for IESG review >> > >> > 2. the TE link MIB module is in wg last call (to end June 13) >> > >> > 3. the management overview has been through wg last call >> and has been >> > updated >> > >> > >> > Two other MIB modules are in the pipe and new version will >> be released > shortly > > 5. The TE mib module >> > 6. The FTN mib module >> > > It is important that >> we complete this process of reviewing and updating > before >> the ID cut off date (June 30) for the Vienna meeting. >> >> >> > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 19 09:37:34 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17396 for ; Thu, 19 Jun 2003 09:37:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JDb2V25142 for ; Thu, 19 Jun 2003 09:37:02 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5JDaw412285 for ; Thu, 19 Jun 2003 09:36:58 -0400 (EDT) Date: Thu, 19 Jun 2003 09:34:53 -0400 (EDT) From: Siddharth Aanand X-X-Sender: saanand@boysenberry To: "Sakthivadivu.S.S" cc: ppvpn@lyris.nortelnetworks.com Subject: Re: BGP/MPLS VPN In-Reply-To: <003301c33654$d7c6f940$4406140a@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: saanand@pit.comms.marconi.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: mailgate.pit.comms.marconi.com [169.144.68.6] X-LYRIS-Message-Id: In your example, do site1 and site2 belong to the same VRF or not? -Sidd Aanand On Thu, 19 Jun 2003, Sakthivadivu.S.S wrote: > Hi, > > When two sites namely site1 and site2 are connected to the same PE > router (PE1), is it required to run two instances of BGP in PE > router.Suppose if both site1 and site2 are having same route (110.10/16) and > EBGP is running between CE router and PE router, how will PE router handle > this routes. since IPV4 routes will be same which are received from CE > router.Before converting to VPN-IPV4 routes, the decesion process will be > run and only one route will be installed in BGP. > > Please help me to handle this situation without using multiple instance of > BGP in PE router. > > Regards, > Sakthi > > *************************************************************************** > 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-132618@lyris.nortelnetworks.com Thu Jun 19 10:06:22 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19137 for ; Thu, 19 Jun 2003 10:06:22 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JE5oV16804 for ; Thu, 19 Jun 2003 10:05:51 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5JE5l012474 for ; Thu, 19 Jun 2003 10:05:47 -0400 (EDT) Message-ID: <3EF1C280.8010105@marconi.com> Date: Thu, 19 Jun 2003 10:02:40 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030618 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: IETF PPVPN List Subject: Re: BGP/MPLS VPN References: <003301c33654$d7c6f940$4406140a@future.futsoft.com> In-Reply-To: <003301c33654$d7c6f940$4406140a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: mailgate.pit.comms.marconi.com X-SMTP-MAIL-FROM: David.Charlap@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: Content-Transfer-Encoding: 7bit Sakthivadivu.S.S wrote: > > When two sites namely site1 and site2 are connected to the same PE > router (PE1), is it required to run two instances of BGP in PE > router.Suppose if both site1 and site2 are having same route (110.10/16) and > EBGP is running between CE router and PE router, how will PE router handle > this routes. since IPV4 routes will be same which are received from CE > router.Before converting to VPN-IPV4 routes, the decesion process will be > run and only one route will be installed in BGP. Whether or not to run two instances is an implementation detail. You could run two instances, or you could have one instance that is designed to track routes from multiple VRFs. Either way is doable. The best way will depend on your router's architecture. As for what the decision process is, it will depend on if the two sites are in the same VRF or not. If they're in the same VRF, then all the usual BGP rules for aggregation, policy, etc. will apply. There is little difference between this an a non-VPN environment. If they're in separate VRFs, then the routes will be kept separate (either in different BGP instances, different tables within a single BGP instance, or in a single table using a per-VRF key as a discriminator.) They will be exported to other VRFs and to the core according to whatever route targets are configured. > Please help me to handle this situation without using multiple instance of > BGP in PE router. If you don't want to create multiple BGP instances, then you must be able to track which routes are learned from which VRF. Which means either using separate per-VRF tables, or changing the keys of your existing table in order to discriminate between identical prefixes learned from different VRFs. -- David From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 19 10:32:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21719 for ; Thu, 19 Jun 2003 10:32:33 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JEW1V23847 for ; Thu, 19 Jun 2003 10:32:02 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5JEVxO08602 for ; Thu, 19 Jun 2003 10:31:59 -0400 (EDT) Message-ID: <305D2EAC01C45448A7F3ECC487666F6C0781D184@md6370exch004u.nse.lucent.com> From: "Natale, Robert C (Bob)" To: jcucchiara@mindspring.com Cc: "'MPLS WG'" , tnadeau@cisco.com, "'Ash, Gerald R (Jerry), ALABS'" , "Wijnen, Bert (Bert)" , "'Loa Andersson'" , "'Lai, Wai S (Waisum), ALABS'" , "'Chung, Li-Jin W, ALABS'" , ppvpn@nortelnetworks.com, "'Van der Linde, Harmen, ALABS'" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Thu, 19 Jun 2003 10:30:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SMTP-HELO: ihemail2.firewall.lucent.com X-SMTP-MAIL-FROM: bnatale@lucent.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ihemail2.lucent.com [192.11.222.163] X-LYRIS-Message-Id: Hi, Apologies for keeping the long cc: list.... > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Thursday, June 19, 2003 8:37 AM > > ... > My read of the draft is that the authors are indeed requesting > changes to the LDP protocol. One example is the > discussion on sessions being enabled/disabled. As Tom points out, > this is not in the MIB because it is not in the protocol. Yes, and we all understand (I hope) the futility of that. However, these exchanges do raise several very good points: E.g., - Isn't it a good idea to have a fuller understanding of how a technology should be managed *before and/or during* protocol development? - If so, perhaps: - Each protocol development WG should have a Mgmt & Ops advisor? (The "MIB Doctors" service is valuable but seems to tend to focus on SMI compliance (and similar issues) to the exclusion of MIB sufficiency relative to the management requirements of using the technology at hand.) - The Mgmt & Ops Area should publish a set of critical generic management requirements for all protocol development WGs to refer to as they do their core work. (Yes, everyone knows how important management and operations are :-], but everyone also knows how much that is just given "lip service" in the segments of the real world that don't include real users.) > ... > A question was made privately to one of the authors at the > Atlanta IETF that perhaps a MIB which stores LDP counter information > in a history table (such as is done in SONET) could be useful to them? This is a good example of the kind of generic feature and "re-use" that I am talking about above. Cheers, BobN From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 19 11:12:10 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24068 for ; Thu, 19 Jun 2003 11:08:25 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JF7rV18112 for ; Thu, 19 Jun 2003 11:07:54 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5JF7m927377 for ; Thu, 19 Jun 2003 11:07:49 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Natale, Robert C \(Bob\)'" , Cc: "'MPLS WG'" , "'Ash, Gerald R \(Jerry\), ALABS'" , "'Wijnen, Bert \(Bert\)'" , "'Loa Andersson'" , "'Lai, Wai S \(Waisum\), ALABS'" , "'Chung, Li-Jin W, ALABS'" , , "'Van der Linde, Harmen, ALABS'" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Thu, 19 Jun 2003 11:03:56 -0400 Organization: Cisco Systems Message-ID: <02b001c33674$057d2660$ed472ca1@amer.cisco.com> 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, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <305D2EAC01C45448A7F3ECC487666F6C0781D184@md6370exch004u.nse.lucent.com> Importance: Normal X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Natale, Robert C (Bob) [mailto:bnatale@lucent.com] > Sent: Thursday, June 19, 2003 10:30 AM > To: jcucchiara@mindspring.com > Cc: 'MPLS WG'; tnadeau@cisco.com; 'Ash, Gerald R (Jerry), > ALABS'; Wijnen, Bert (Bert); 'Loa Andersson'; 'Lai, Wai S > (Waisum), ALABS'; 'Chung, Li-Jin W, ALABS'; > ppvpn@nortelnetworks.com; 'Van der Linde, Harmen, ALABS' > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > Hi, > > Apologies for keeping the long cc: list.... > > > -----Original Message----- > > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > > Sent: Thursday, June 19, 2003 8:37 AM > > > > ... > > My read of the draft is that the authors are indeed requesting > > changes to the LDP protocol. One example is the > > discussion on sessions being enabled/disabled. As Tom points out, > > this is not in the MIB because it is not in the protocol. > > Yes, and we all understand (I hope) the futility of that. > > However, these exchanges do raise several very good points: E.g., > > - Isn't it a good idea to have a fuller understanding of > how a technology should be managed *before and/or during* > protocol development? Yes. > - If so, perhaps: > > - Each protocol development WG should have a Mgmt & Ops advisor? > > (The "MIB Doctors" service is valuable but seems to tend to > focus on SMI compliance (and similar issues) to the exclusion > of MIB sufficiency relative to the management requirements of > using the technology at hand.) Yes, I agree. > - The Mgmt & Ops Area should publish a set of critical generic > management requirements for all protocol development WGs to > refer to as they do their core work. BUT, those requirements should be used hand-in-hand with those produced by the WG. Also, the WG may have a good reason to not use some of those requirements and should be free to do so if there is consensus to do so. --Tom > (Yes, everyone knows how important management and operations > are :-], but everyone also knows how much that is just given > "lip service" in the segments of the real world that don't > include real users.) > > > ... > > A question was made privately to one of the authors at the > > Atlanta IETF that perhaps a MIB which stores LDP counter information > > in a history table (such as is done in SONET) could be > useful to them? > > This is a good example of the kind of generic feature and > "re-use" that I am talking about above. > > Cheers, > > BobN > From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 19 14:02:36 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05174 for ; Thu, 19 Jun 2003 13:58:51 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JHwJV07700 for ; Thu, 19 Jun 2003 13:58:19 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5JHwGc08102 for ; Thu, 19 Jun 2003 13:58:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Thu, 19 Jun 2003 12:56:17 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA011BEA45@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG last call on LSR and LDP MIB modules - setting dates Thread-Index: AcM1xAEariWgGK9QRWG+X54QX0ySqAAvQrWQ From: "Ash, Gerald R (Jerry), ALABS" To: Cc: "Ash, Gerald R (Jerry), ALABS" , , "Wijnen, Bert (Bert)" , "Loa Andersson" , "MPLS WG" , "Lai, Wai S (Waisum), ALABS" , "Chung, Li-Jin W, ALABS" , , "Van der Linde, Harmen, ALABS" , "Adrian Farrel" X-SMTP-HELO: kcmso1.proxy.att.com X-SMTP-MAIL-FROM: gash@att.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kcmso1.att.com [192.128.133.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05174 Tom, > the MIBs need to be wrapped up ASAP and ... > we are well on this track. Good, hopefully by IETF-57, in order to avoid 'sending them to the dust-bin' as Bert has suggested. > To address your statement about requirements, > as discussed previously offline with yourself > and the MIB co-authors, There is about a one-year history/archive of posts to the lists regarding these requirements. > many of the requirements you listed below require > changes to the LDP protocol itself. Which of the 3 LDP requirements constitute 'many' that need LDP changes? Obviously we're not proposing LDP protocol changes. Also, the requirements I-D does not propose specific MIB extensions, *in order to avoid past discussions of why specific extensions won't work*. Step-1 is to make sure the requirements are understood, and then step-2 is to decide how to meet them. Joan has suggested (I believe for requirements R1 and R2) 'a MIB which stores LDP counter information in a history table'. That's a step-2 in the right direction. Furthermore, Adrian has suggested that 'instances of entities' is a concept that has been handled in MIBs before and could be added in an optional way so that implementations did not have to maintain persistent information, but can choose to. As to R3, it should be clear, a MIB should be straightforward. > I suggest that you consult with > other SPs in the WG on these requirements to make sure > that they are consistent. I personally have not been hearing > any of these requirements from other SPs that participate > in the MPLS WG. So that signifies the death-knell pronouncement from the self-appointed OAM/MIB-czar? Perhaps the famous 25 pro-VCCV SPs you often quote (but who never speak for themselves) can attest to the MPLS-MIBs perfection/no-more-requirements-needed? There has been no opposition to the requirements R1-R5 we've been stating for a long time (except, consistently, from you). > I suggest that you direct your requirements to the > authors of the LDP specifications and propose > extensions/additions there first because the MIBs > cannot manage what the protocols will not provide. We're not proposing any changes to LDP. As above, Joan is suggesting approaches to R1 & R2. R3 clearly requires no protocol changes. > The remaining requirements you listed > below apply specifically to the PPVPN-MPLS-VPN MIB and not > to the base MPLS MIBs which are in WG last call presently. R3 and R4 need to be addressed, have been there a long time, and do not have to wait until last call to be discussed/progressed. Jerry > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: Wednesday, June 18, 2003 1:43 PM > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > Bert, Loa, All, > > I'd like to follow up on Wai Sum's comments below, and > encourage that high-priority MPLS-MIB problems/requirements > identified through extensive testing be addressed in the MPLS > MIB modules. > > The MPLS MIB problems/requirements are identified in > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, > and are critical operator requirements stemming from > detailed lab testing by Li Chung and others at AT&T. > MPLS-VPNs aren't going to operate as well as needed until and > unless these requirements are met. It is expected that > operators wishing to use the same MPLS MIBs would have > similar concerns. > > The I-D does not propose specific MIB extensions based on the > requirements. Rather, such extensions are left to the MIB > designers, in order to avoid past discussions of why specific > extensions won't work. But so far there is no help or > response from MIB designers on how to meet the requirements, > even though the problems have been identified on email lists > for more than one year. > > Here is a summary of requirements (R1,R2,R3 LDP related; > R4,R5 VPN related): > > R1. It is required to capture the signaling usage/performance > of the LDP Entities, as well as the traffic usage/performance > of the LDP Sessions. R2. It is required to ensure persistency > of information in the LDP-MIB Entity Table and Entity > Statistics Table, whenever an LDP Entity is disabled and then > re-enabled. R3. It is required that a count be reported of > mplsNumVrfRouteMaxThreshExceeded notification when the > operator-defined VRF maximum route threshold is exceeded. R4. > It is required to have an explicit mapping between VRF, RD, > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is > required to track the number of BGP prefixes on the PE-CE > link, and that the BGP neighbor maximum-prefix limit on the > PE-CE link be used to limit the number of eBGP routes > injected in the VRF. > > I agree with Harmen Van der Linde, "We need to get this MPLS > MIB module, together with the MPLS LDP and MPLS VPN modules, > standardized ASAP. There is a critical need for these MPLS > MIB modules for management of MPLS-enabled networks, which > are currently being deployed by many service providers." > > Bert threatened at IETF-56 to start over on MPLS MIBs if not > finished by IETF-57. > > We need the MPLS MIB designers to meet critical requirements > and complete ASAP. > > Thanks, > Jerry From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 19 15:10:11 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11016 for ; Thu, 19 Jun 2003 15:06:22 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JJ5eV11452 for ; Thu, 19 Jun 2003 15:05:40 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5JJ5aw26373 for ; Thu, 19 Jun 2003 15:05:37 -0400 (EDT) Reply-To: From: "Thomas D. Nadeau" To: "'Ash, Gerald R \(Jerry\), ALABS'" Cc: , "'Wijnen, Bert \(Bert\)'" , "'Loa Andersson'" , "'MPLS WG'" , "'Lai, Wai S \(Waisum\), ALABS'" , "'Chung, Li-Jin W, ALABS'" , , "'Van der Linde, Harmen, ALABS'" , "'Adrian Farrel'" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Thu, 19 Jun 2003 14:34:02 -0400 Organization: Cisco Systems Message-ID: <02f301c33691$5ba16ed0$ed472ca1@amer.cisco.com> 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, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA011BEA45@KCCLUST06EVS1.ugd.att.com> Importance: Normal X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit > Tom, > > > the MIBs need to be wrapped up ASAP and ... > > we are well on this track. > > Good, hopefully by IETF-57, in order to avoid 'sending them > to the dust-bin' as Bert has suggested. > > > To address your statement about requirements, > > as discussed previously offline with yourself > > and the MIB co-authors, > > There is about a one-year history/archive of posts to the > lists regarding these requirements. > > > many of the requirements you listed below require > > changes to the LDP protocol itself. > > Which of the 3 LDP requirements constitute 'many' that need > LDP changes? All of the requirements you listed below with the exception of the ones pertaining to VPN. > Obviously we're not proposing LDP protocol changes. Also, > the requirements I-D does not propose specific MIB > extensions, *in order to avoid past discussions of why > specific extensions won't work*. Step-1 is to make sure the > requirements are understood, and then step-2 is to decide how > to meet them. Of course you aren't proposing specific changes to anything. What we are saying is that is what you need to do in order to accomplish what you want in this case. The LDP MIB is not a place for redefining how LDP works. > Joan has suggested (I believe for requirements R1 and R2) 'a > MIB which stores LDP counter information in a history table'. > That's a step-2 in the right direction. Furthermore, Adrian > has suggested that 'instances of entities' is a concept that > has been handled in MIBs before and could be added in an > optional way so that implementations did not have to maintain > persistent information, but can choose to. This is not something that should go into the existing LDP MIB because the LDP protocol does not support the counters/concepts required to count these things regardless of what has been suggested. If you look at the specific details of what is being proposed in the draft (which I and others have done numerous times now) they CANNOT be achieved with the current standard LDP. > As to R3, it should be clear, a MIB should be straightforward. > > > I suggest that you consult with > > other SPs in the WG on these requirements to make sure > > that they are consistent. I personally have not been hearing > > any of these requirements from other SPs that participate > > in the MPLS WG. > > So that signifies the death-knell pronouncement from the > self-appointed OAM/MIB-czar? Perhaps the famous 25 pro-VCCV > SPs you often quote (but who never speak for themselves) can > attest to the MPLS-MIBs perfection/no-more-requirements-needed? > > There has been no opposition to the requirements R1-R5 we've > been stating for a long time (except, consistently, from you). I have not read any emails that claimed support for or acknowledged these requirements either. > > I suggest that you direct your requirements to the > > authors of the LDP specifications and propose > > extensions/additions there first because the MIBs > > cannot manage what the protocols will not provide. > > We're not proposing any changes to LDP. As above, Joan is > suggesting approaches to R1 & R2. R3 clearly requires no > protocol changes. So then go ahead and propose a MIB based on those changes. There is nothing preventing you or anyone else on the co-author list of the draft in question from doing this. > > The remaining requirements you listed > > below apply specifically to the PPVPN-MPLS-VPN MIB and not > > to the base MPLS MIBs which are in WG last call presently. > > R3 and R4 need to be addressed, have been there a long time, > and do not have to wait until last call to be discussed/progressed. And these will be addressed in the PPVPN MPLS VPN MIB when Harmen and I get around to editing the MIB, assuming there is consensus to make these additions. And as you can see, I have been a little busy with the base MIBs for the last few months. *) --Apparently self-appointed OAM/MIB-czar > Jerry > > > -----Original Message----- > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > Sent: Wednesday, June 18, 2003 1:43 PM > > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG > > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; > > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com > > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > > > > Bert, Loa, All, > > > > I'd like to follow up on Wai Sum's comments below, and > > encourage that high-priority MPLS-MIB problems/requirements > > identified through extensive testing be addressed in the MPLS > > MIB modules. > > > > The MPLS MIB problems/requirements are identified in > > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, > > and are critical operator requirements stemming from > > detailed lab testing by Li Chung and others at AT&T. > > MPLS-VPNs aren't going to operate as well as needed until and > > unless these requirements are met. It is expected that > > operators wishing to use the same MPLS MIBs would have > > similar concerns. > > > > The I-D does not propose specific MIB extensions based on the > > requirements. Rather, such extensions are left to the MIB > > designers, in order to avoid past discussions of why specific > > extensions won't work. But so far there is no help or > > response from MIB designers on how to meet the requirements, > > even though the problems have been identified on email lists > > for more than one year. > > > > Here is a summary of requirements (R1,R2,R3 LDP related; > > R4,R5 VPN related): > > > > R1. It is required to capture the signaling usage/performance > > of the LDP Entities, as well as the traffic usage/performance > > of the LDP Sessions. R2. It is required to ensure persistency > > of information in the LDP-MIB Entity Table and Entity > > Statistics Table, whenever an LDP Entity is disabled and then > > re-enabled. R3. It is required that a count be reported of > > mplsNumVrfRouteMaxThreshExceeded notification when the > > operator-defined VRF maximum route threshold is exceeded. R4. > > It is required to have an explicit mapping between VRF, RD, > > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is > > required to track the number of BGP prefixes on the PE-CE > > link, and that the BGP neighbor maximum-prefix limit on the > > PE-CE link be used to limit the number of eBGP routes > > injected in the VRF. > > > > I agree with Harmen Van der Linde, "We need to get this MPLS > > MIB module, together with the MPLS LDP and MPLS VPN modules, > > standardized ASAP. There is a critical need for these MPLS > > MIB modules for management of MPLS-enabled networks, which > > are currently being deployed by many service providers." > > > > Bert threatened at IETF-56 to start over on MPLS MIBs if not > > finished by IETF-57. > > > > We need the MPLS MIB designers to meet critical requirements > > and complete ASAP. > > > > Thanks, > > Jerry > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 02:32:16 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19159 for ; Fri, 20 Jun 2003 02:32:15 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5K6VhP14922 for ; Fri, 20 Jun 2003 02:31:43 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5K6VeP17245 for ; Fri, 20 Jun 2003 02:31:41 -0400 (EDT) Message-ID: <20030620062949.15156.qmail@web41809.mail.yahoo.com> Date: Fri, 20 Jun 2003 07:29:49 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: Nos of Labels in CE To: mpls-ops@mplsrc.com, ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41809.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web41809.mail.yahoo.com [66.218.93.143] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Hi, WHat is that implementations generally do when they have multiple prefixes associated with a single interface. DO they advertise a single label for all these routes OR does it advertise multiple unique labels per route? I think it should be the former. Is there any case when one might want to do the latter? Regards, John Smith ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 03:16:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20207 for ; Fri, 20 Jun 2003 03:16:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5K7FkP24163 for ; Fri, 20 Jun 2003 03:15:46 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5K7Fh422801 for ; Fri, 20 Jun 2003 03:15:43 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 20 Jun 2003 03:13:48 -0400 Subject: Re: [MPLS-OPS]: Nos of Labels in CE From: Aamer Akhter To: John Smith , , Message-ID: In-Reply-To: <20030620062949.15156.qmail@web41809.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SMTP-HELO: sj-iport-2.cisco.com X-SMTP-MAIL-FROM: aakhter@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-iport-2-in.cisco.com [171.71.176.71] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On 6/20/03 2:29 AM, "John Smith" wrote: > Hi, > WHat is that implementations generally do when they have multiple prefixes > associated > with a single interface. I think you want to say same next-hop rather than interface. >DO they advertise a single label for all these routes > OR does it > advertise multiple unique labels per route? > > I think it should be the former. > > Is there any case when one might want to do the latter? In general, cases where it might be useful to be able to distinguish between prefixes. One specific case is in mpls-vpn if the prefix is reachable via two different nexthop's on the same PE. This allows the PE to loadshare between the two next-hops. > > Regards, > John Smith -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 04:30:59 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21373 for ; Fri, 20 Jun 2003 04:30:58 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5K8URP05819 for ; Fri, 20 Jun 2003 04:30:27 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5K8UO702185 for ; Fri, 20 Jun 2003 04:30:24 -0400 (EDT) Message-ID: <20030620082838.97308.qmail@web41812.mail.yahoo.com> Date: Fri, 20 Jun 2003 09:28:38 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: Re: [MPLS-OPS]: Nos of Labels in CE To: mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41812.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web41812.mail.yahoo.com [66.218.93.146] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Aamer, > > WHat is that implementations generally do when they have multiple prefixes > > associated > > with a single interface. > > I think you want to say same next-hop rather than interface. No, I mean the same interface. What difference does it make to me if i have a prefix which has different next-hops and both the next-hops are reachable to me thru the same interface/sub-interface (e.g. ethernet) > > >DO they advertise a single label for all these routes > > OR does it > > advertise multiple unique labels per route? > > > > I think it should be the former. > > > > Is there any case when one might want to do the latter? > > In general, cases where it might be useful to be able to distinguish between > prefixes. > > One specific case is in mpls-vpn if the prefix is reachable via two > different nexthop's on the same PE. This allows the PE to loadshare between > the two next-hops. PE can only load share if both the next-hops are accessable through different interfaces. Thus in this case too, the PE will be advertisiing differnet labels per interface. IMHO the label should be associated with an interface. So that when this PE receives a MPLS packet with this label, it does nothing but pushes the native IPv4 packet out on the associated interface! Am i missing something? Regards, John Smith ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 08:40:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03767 for ; Fri, 20 Jun 2003 08:40:51 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KCeIP13784 for ; Fri, 20 Jun 2003 08:40:19 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5KCeF517089 for ; Fri, 20 Jun 2003 08:40:15 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 20 Jun 2003 08:38:22 -0400 Subject: Re: [MPLS-OPS]: Nos of Labels in CE From: Aamer Akhter To: John Smith , CC: Message-ID: In-Reply-To: <20030620082838.97308.qmail@web41812.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SMTP-HELO: sj-iport-1.cisco.com X-SMTP-MAIL-FROM: aakhter@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-iport-1-in.cisco.com [171.71.176.70] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On 6/20/03 4:28 AM, "John Smith" wrote: > Aamer, > >>> WHat is that implementations generally do when they have multiple prefixes >>> associated >>> with a single interface. >> >> I think you want to say same next-hop rather than interface. > > No, I mean the same interface. What difference does it make to me if i have a > prefix > which has different next-hops and both the next-hops are reachable to me thru > the same > interface/sub-interface (e.g. ethernet) Which next-hop would you forward the packet to, in the case of multiple next-hops reachable via a multi-access interface (eg ethernet)? Keep in mind that unlike point-point interfaces you have to do a L2 rewrite that includes a MAC address on multi-access interfaces. >>> DO they advertise a single label for all these routes >>> OR does it >>> advertise multiple unique labels per route? >>> >>> I think it should be the former. >>> >>> Is there any case when one might want to do the latter? >> >> In general, cases where it might be useful to be able to distinguish between >> prefixes. >> >> One specific case is in mpls-vpn if the prefix is reachable via two >> different nexthop's on the same PE. This allows the PE to loadshare between >> the two next-hops. > > PE can only load share if both the next-hops are accessable through different > interfaces. > Thus in this case too, the PE will be advertisiing differnet labels per > interface. IMHO > the label should be associated with an interface. So that when this PE > receives a MPLS > packet with this label, it does nothing but pushes the native IPv4 packet out > on the > associated interface! I am guessing you will advertise the prefix twice in BGP? BGP's best path will make sure that only one of the labels will ever get used. (there are exceptions to the rule in this case, of course). > > Am i missing something? > > Regards, > John Smith > > > ________________________________________________________________________ > Want to chat instantly with your online friends? Get the FREE Yahoo! > Messenger http://uk.messenger.yahoo.com/ > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 09:36:25 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05792 for ; Fri, 20 Jun 2003 09:32:40 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KDW8P04331 for ; Fri, 20 Jun 2003 09:32:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5KDW5q04527 for ; Fri, 20 Jun 2003 09:32:05 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG last call on LSR and LDP MIB modules - setting dates Date: Fri, 20 Jun 2003 08:25:59 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A6850@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG last call on LSR and LDP MIB modules - setting dates Thread-Index: AcM2X4WKW+jeT5SERXGkmdqAulyqRQAzPG7A From: "Ash, Gerald R (Jerry), ALABS" To: , "MPLS WG" Cc: "Ash, Gerald R (Jerry), ALABS" , "Lai, Wai S (Waisum), ALABS" , "Chung, Li-Jin W, ALABS" , X-SMTP-HELO: kcmso1.proxy.att.com X-SMTP-MAIL-FROM: gash@att.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: kcmso1.att.com [192.128.133.69] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA05792 Joan, > perhaps a MIB which stores LDP counter information in a > history table (such as is done in SONET) could be useful... > why wouldn't a history table solve some of the issues? > If history tables would be thought useful, this could be > proposed to the working group in a separate MIB module, > but would be outside the scope of the present LDP-MIB. Thanks for your suggestion. I presume this is regarding requirements R1 and R2 below, correct? If so, it does appear useful and we'd like to work with you to define details and progress. Thanks, Jerry P.S. Correction to requirements below, R3 is a VPN requirements, not an LDP requirement. >> -----Original Message----- >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> Sent: Wednesday, June 18, 2003 1:43 PM >> To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG >> Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; >> Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com >> Subject: RE: WG last call on LSR and LDP MIB modules - setting dates >> >> Bert, Loa, All, >> >> I'd like to follow up on Wai Sum's comments below, and >> encourage that high-priority MPLS-MIB problems/requirements >> identified through extensive testing be addressed in the MPLS >> MIB modules. >> >> The MPLS MIB problems/requirements are identified in >> http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.tx >> t, and are critical operator requirements stemming from >> detailed lab testing by Li Chung and others at AT&T. >> MPLS-VPNs aren't going to operate as well as needed until and >> unless these requirements are met. It is expected that >> operators wishing to use the same MPLS MIBs would have >> similar concerns. >> >> The I-D does not propose specific MIB extensions based on the >> requirements. Rather, such extensions are left to the MIB >> designers, in order to avoid past discussions of why specific >> extensions won't work. But so far there is no help or >> response from MIB designers on how to meet the requirements, >> even though the problems have been identified on email lists >> for more than one year. >> >> Here is a summary of requirements (R1,R2,R3 LDP related; >> R4,R5 VPN related): >> >> R1. It is required to capture the signaling usage/performance >> of the LDP Entities, as well as the traffic usage/performance >> of the LDP Sessions. >> R2. It is required to ensure persistency >> of information in the LDP-MIB Entity Table and Entity >> Statistics Table, whenever an LDP Entity is disabled and then >> re-enabled. >> R3. It is required that a count be reported of >> mplsNumVrfRouteMaxThreshExceeded notification when the >> operator-defined VRF maximum route threshold is exceeded. >> R4. It is required to have an explicit mapping between VRF, RD, >> and RT in the mplsVpnVrfRouteTargetTable table. >> R5. It is >> required to track the number of BGP prefixes on the PE-CE >> link, and that the BGP neighbor maximum-prefix limit on the >> PE-CE link be used to limit the number of eBGP routes >> injected in the VRF. >> >> I agree with Harmen Van der Linde, "We need to get this MPLS >> MIB module, together with the MPLS LDP and MPLS VPN modules, >> standardized ASAP. There is a critical need for these MPLS >> MIB modules for management of MPLS-enabled networks, which >> are currently being deployed by many service providers." >> >> Bert threatened at IETF-56 to start over on MPLS MIBs if not >> finished by IETF-57. >> >> We need the MPLS MIB designers to meet critical requirements >> and complete ASAP. >> >> Thanks, >> Jerry From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 09:46:14 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06019 for ; Fri, 20 Jun 2003 09:46:14 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KDjaP10532 for ; Fri, 20 Jun 2003 09:45:37 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5KDjSI15589 for ; Fri, 20 Jun 2003 09:45:29 -0400 (EDT) From: "Vinay Bannai" To: "John Smith" , Cc: Subject: RE: [MPLS-OPS]: Nos of Labels in CE Date: Fri, 20 Jun 2003 06:40:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030620082838.97308.qmail@web41812.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SMTP-HELO: smtp805.mail.sc5.yahoo.com X-SMTP-MAIL-FROM: bannai@pacbell.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp805.mail.sc5.yahoo.com [66.163.168.184] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit John, If both the next hops are available on the same interface (ethernet as you mentioned), then you need to have a distinct mac address for each of the next hop. Either you have one label per route and associate the next hop L2 information (usually the destination mac address) with the label and save it in the lookup table OR you pop the label and do a lookup on the IP DA to figure out the next hop that you can ARP (assuming it is still ethernet) to get the next hop L2 information. However, if you have point to point link (say PPP) as the outgoing interface, then it might make some sort of sense to associate label binding for IP routes based on outgoing links. But if you do that you lost your ability to load balance unless you can figure out a way to associate multiple label bindings for the same IP routes emanating from different interfaces. Vinay Bannai Luminous Networks -----Original Message----- From: John Smith [mailto:jsmith4112003@yahoo.co.uk] Sent: Friday, June 20, 2003 1:29 AM To: mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com Subject: Re: [MPLS-OPS]: Nos of Labels in CE Aamer, > > WHat is that implementations generally do when they have multiple prefixes > > associated > > with a single interface. > > I think you want to say same next-hop rather than interface. No, I mean the same interface. What difference does it make to me if i have a prefix which has different next-hops and both the next-hops are reachable to me thru the same interface/sub-interface (e.g. ethernet) > > >DO they advertise a single label for all these routes > > OR does it > > advertise multiple unique labels per route? > > > > I think it should be the former. > > > > Is there any case when one might want to do the latter? > > In general, cases where it might be useful to be able to distinguish between > prefixes. > > One specific case is in mpls-vpn if the prefix is reachable via two > different nexthop's on the same PE. This allows the PE to loadshare between > the two next-hops. PE can only load share if both the next-hops are accessable through different interfaces. Thus in this case too, the PE will be advertisiing differnet labels per interface. IMHO the label should be associated with an interface. So that when this PE receives a MPLS packet with this label, it does nothing but pushes the native IPv4 packet out on the associated interface! Am i missing something? Regards, John Smith ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 10:56:01 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10253 for ; Fri, 20 Jun 2003 10:56:00 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KEtTP10430 for ; Fri, 20 Jun 2003 10:55:29 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5KEtQr03325 for ; Fri, 20 Jun 2003 10:55:27 -0400 (EDT) Message-ID: <20030620145336.24598.qmail@web41806.mail.yahoo.com> Date: Fri, 20 Jun 2003 15:53:36 +0100 (BST) From: =?iso-8859-1?q?John=20Smith?= Subject: RE: [MPLS-OPS]: Nos of Labels in CE To: bannai@pacbell.net, mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SMTP-HELO: web41806.mail.yahoo.com X-SMTP-MAIL-FROM: jsmith4112003@yahoo.co.uk X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web41806.mail.yahoo.com [66.218.93.140] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit Vinay, > Either you have one label per route and associate the next hop L2 > information (usually the destination mac address) with the label and save it > in the lookup table OR you pop the label and do a lookup on the IP DA to > figure out the next hop that you can ARP (assuming it is still ethernet) to > get the next hop L2 information. The latter suits fine to me. > > However, if you have point to point link (say PPP) as the outgoing > interface, then it might make some sort of sense to associate label binding > for IP routes based on outgoing links. But if you do that you lost your > ability to load balance unless you can figure out a way to associate > multiple label bindings for the same IP routes emanating from different > interfaces. I think i wasnt clear in stating my problem. What i want to do is to bind a label to an interface, rather than the routes which i recieve. Say, i have a BGP CE peering over an interface - What this means is that my BGP peering takes place through one interface. I will now bind one label Lx for this interface. I will be advertising this label for all the routes which i learn from this peer as i know it will always be this peer which i will use as my next-hop (as its an EBGP peer). Is this correct? Is it okay to associate a Label Lx with a BGP CE peer (implicitly an interface) and to always use when i need to advertise routes learnt from this peer. Lets verify that data forwarding will be done correctly? If this router recieves a MPLS packet with the BGP label as Lx, it will simply pop off this label and push the native IPv4 packet on the interface over which the BGP peering takes place. This packet when reaches the EBGP CE peer, will decide where it needs to forward this packet. I think it works fine - and thus my idea of binding an interface to a Label!! Does anyone see any problems in this? Regards, JOhn Smith ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 11:28:02 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12288 for ; Fri, 20 Jun 2003 11:28:02 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KFRVP00324 for ; Fri, 20 Jun 2003 11:27:31 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5KFRS524370 for ; Fri, 20 Jun 2003 11:27:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20030620101530.036219c8@fargo.cisco.com> X-Sender: chrlewis@fargo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jun 2003 10:25:28 -0500 To: John Smith From: Christopher Lewis Subject: RE: [MPLS-OPS]: Nos of Labels in CE Cc: bannai@pacbell.net, mpls-ops@mplsrc.com, ppvpn@nortelnetworks.com In-Reply-To: <20030620145336.24598.qmail@web41806.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SMTP-HELO: sj-iport-3.cisco.com X-SMTP-MAIL-FROM: chrlewis@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-iport-3-in.cisco.com [171.71.176.72] X-LYRIS-Message-Id: John, I think the suggestion you propose has already been implemented by at least one major router vendor. At least one other major router vendor assigns a distinct label per route learned from the CE. At first glance the label per interface (or label per CE) seems to offer scaling advantages in terms of the number of labels that need to be supported (if you have issues in your architecture with the number of labels that can be supported, that is a clear advantage), however, as mentioned, there are issues with carrier supporting carrier and some load balancing situations. For CsC, you could implement your label per CE/interface scheme, then when LDP is enabled under a VRF, allocate a label per prefix instead of a label per CE. This may be perceived by some operators as inconsistent operation, but that is the choice. If you did not do this, there would be no way to communicate the destination route (PE) to the egress CE. You can't just "pop and forward", because this isn't an IP packet. If you just popped off the backbone VPN label, then you'd expose the customer VPN label, which wasn't assigned by the egress CE. For load balancing, consider this case PE2 | PE1------- | | R1---Y---R2---Z | X PE1 will advertise routes X, Y, Z to PE2 the best path for X is via R1, so in the label per CE/interface implementation it would advertise the label for R1 the best path for Z is via R2, so in the label per CE/interface implementation it would advertise the label for R2 Y is equidistant via R1 and R2. Ideally PE1 would loadshare the traffic to Y between R1 and R2. Since you can advertise only a single label with the route, what label would the label per CE/interface implementation advertise? Chris At 09:53 AM 6/20/2003, John Smith wrote: >Vinay, > > > Either you have one label per route and associate the next hop L2 > > information (usually the destination mac address) with the label and > save it > > in the lookup table OR you pop the label and do a lookup on the IP DA to > > figure out the next hop that you can ARP (assuming it is still ethernet) to > > get the next hop L2 information. > >The latter suits fine to me. > > > > > However, if you have point to point link (say PPP) as the outgoing > > interface, then it might make some sort of sense to associate label binding > > for IP routes based on outgoing links. But if you do that you lost your > > ability to load balance unless you can figure out a way to associate > > multiple label bindings for the same IP routes emanating from different > > interfaces. > >I think i wasnt clear in stating my problem. What i want to do is to bind >a label to an >interface, rather than the routes which i recieve. Say, i have a BGP CE >peering over an >interface - What this means is that my BGP peering takes place through one >interface. I >will now bind one label Lx for this interface. I will be advertising this >label for all >the routes which i learn from this peer as i know it will always be this >peer which i >will use as my next-hop (as its an EBGP peer). > >Is this correct? > >Is it okay to associate a Label Lx with a BGP CE peer (implicitly an >interface) and to >always use when i need to advertise routes learnt from this peer. > >Lets verify that data forwarding will be done correctly? > >If this router recieves a MPLS packet with the BGP label as Lx, it will >simply pop off >this label and push the native IPv4 packet on the interface over which the >BGP peering >takes place. This packet when reaches the EBGP CE peer, will decide where >it needs to >forward this packet. > >I think it works fine - and thus my idea of binding an interface to a Label!! > >Does anyone see any problems in this? > >Regards, >JOhn Smith > > > > >________________________________________________________________________ >Want to chat instantly with your online friends? Get the FREE Yahoo! >Messenger http://uk.messenger.yahoo.com/ From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 13:55:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20513 for ; Fri, 20 Jun 2003 13:55:29 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KHsuP04024 for ; Fri, 20 Jun 2003 13:54:56 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5KHsrd12112 for ; Fri, 20 Jun 2003 13:54:53 -0400 (EDT) Message-ID: <3EF348C8.46EF6EBB@GraIyMage.com> Date: Fri, 20 Jun 2003 13:47:52 -0400 From: Eric Gray Reply-To: ewgray@graiymage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: tnadeau@cisco.com CC: "'Ash, Gerald R (Jerry), ALABS'" , jcucchiara@mindspring.com, "'Wijnen, Bert (Bert)'" , "'Loa Andersson'" , "'MPLS WG'" , ppvpn@nortelnetworks.com, ewgray@graiymage.com Subject: Re: WG last call on LSR and LDP MIB modules - setting dates References: <02f301c33691$5ba16ed0$ed472ca1@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - nortelnetworks.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com X-SMTP-HELO: host19.ipowerweb.com X-SMTP-MAIL-FROM: ewgray@graiymage.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host19.ipowerweb.com [12.129.211.119] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Tom and others, This discussion seems skewed a bit because of different perspectives that people are speaking from. First of all, it is not the case that a protocol specification must necessarily define counters and knobs for every detail of how the protocol should be managed. It is often the case that people would prefer this to be the case, however, requiring it to be the case would be a sure fire way to delay specification of protocol standards well beyond some window of utility for a standard - meaning that placing too many barriers in the way of defining standards leads to de facto standards. For example, in this discussion, what exactly is it that LDP _should_ have defined to support the requirements that Jerry points out? I do not think that the protocol should be involved in the business of keeping track of the enabled status of potential protocol peers - it should be sufficient from a protocol perspective to know whether a protocol peer is currently visible. Also, the protocol specification should not specify what happens to protocol management data (counters and knobs) during the period in which the protocol itself is not active - except to the extent that proper protocol behavior absolutely depends on such specification. My sense is that it is perfectly within the purview of a management specification to make statements about this kind of behavior as long as such statements are not actually incompatible with underlying protocol specifications. It would then be up to implementers to determine whether or not their implementation supports these capabilities. And it is equally reasonable to assert that specifying required behaviors may be the task of some subsequent management specification. In the same way that requiring full manageability of a protocol can unnecessarily delay the protocol specification process, requiring complete satisfaction of evolving management requirements in current management specifications can unnecessarily delay the management specification process. My 2 cents worth... -- Eric Gray "Thomas D. Nadeau" wrote: > > > Tom, > > > > > the MIBs need to be wrapped up ASAP and ... > > > we are well on this track. > > > > Good, hopefully by IETF-57, in order to avoid 'sending them > > to the dust-bin' as Bert has suggested. > > > > > To address your statement about requirements, > > > as discussed previously offline with yourself > > > and the MIB co-authors, > > > > There is about a one-year history/archive of posts to the > > lists regarding these requirements. > > > > > many of the requirements you listed below require > > > changes to the LDP protocol itself. > > > > Which of the 3 LDP requirements constitute 'many' that need > > LDP changes? > > All of the requirements you listed below with > the exception of the ones pertaining to VPN. > > > Obviously we're not proposing LDP protocol changes. Also, > > the requirements I-D does not propose specific MIB > > extensions, *in order to avoid past discussions of why > > specific extensions won't work*. Step-1 is to make sure the > > requirements are understood, and then step-2 is to decide how > > to meet them. > > Of course you aren't proposing specific changes to > anything. What we are saying is that is what you need to > do in order to accomplish what you want in this case. The > LDP MIB is not a place for redefining how LDP works. > > > Joan has suggested (I believe for requirements R1 and R2) 'a > > MIB which stores LDP counter information in a history table'. > > That's a step-2 in the right direction. Furthermore, Adrian > > has suggested that 'instances of entities' is a concept that > > has been handled in MIBs before and could be added in an > > optional way so that implementations did not have to maintain > > persistent information, but can choose to. > > This is not something that should go into the existing > LDP MIB because the LDP protocol does not support the > counters/concepts required to count these things regardless > of what has been suggested. If you look at the specific details > of what is being proposed in the draft (which I and others have > done numerous times now) they CANNOT be achieved with > the current standard LDP. > > > As to R3, it should be clear, a MIB should be straightforward. > > > > > I suggest that you consult with > > > other SPs in the WG on these requirements to make sure > > > that they are consistent. I personally have not been hearing > > > any of these requirements from other SPs that participate > > > in the MPLS WG. > > > > So that signifies the death-knell pronouncement from the > > self-appointed OAM/MIB-czar? Perhaps the famous 25 pro-VCCV > > SPs you often quote (but who never speak for themselves) can > > attest to the MPLS-MIBs perfection/no-more-requirements-needed? > > > > There has been no opposition to the requirements R1-R5 we've > > been stating for a long time (except, consistently, from you). > > I have not read any emails that claimed support for > or acknowledged these requirements either. > > > > I suggest that you direct your requirements to the > > > authors of the LDP specifications and propose > > > extensions/additions there first because the MIBs > > > cannot manage what the protocols will not provide. > > > > We're not proposing any changes to LDP. As above, Joan is > > suggesting approaches to R1 & R2. R3 clearly requires no > > protocol changes. > > So then go ahead and propose a MIB based on those > changes. There is nothing preventing you or anyone else > on the co-author list of the draft in question from doing > this. > > > > The remaining requirements you listed > > > below apply specifically to the PPVPN-MPLS-VPN MIB and not > > > to the base MPLS MIBs which are in WG last call presently. > > > > R3 and R4 need to be addressed, have been there a long time, > > and do not have to wait until last call to be discussed/progressed. > > And these will be addressed in the PPVPN MPLS VPN MIB > when Harmen and I get around to editing the MIB, assuming there > is consensus to make these additions. And as you can see, I > have been a little busy with the base MIBs for the last > few months. *) > > --Apparently self-appointed OAM/MIB-czar > > > > Jerry > > > > > -----Original Message----- > > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > > > Sent: Wednesday, June 18, 2003 1:43 PM > > > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG > > > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; > > > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com > > > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates > > > > > > > > > Bert, Loa, All, > > > > > > I'd like to follow up on Wai Sum's comments below, and > > > encourage that high-priority MPLS-MIB problems/requirements > > > identified through extensive testing be addressed in the MPLS > > > MIB modules. > > > > > > The MPLS MIB problems/requirements are identified in > > > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, > > > and are critical operator requirements stemming from > > > detailed lab testing by Li Chung and others at AT&T. > > > MPLS-VPNs aren't going to operate as well as needed until and > > > unless these requirements are met. It is expected that > > > operators wishing to use the same MPLS MIBs would have > > > similar concerns. > > > > > > The I-D does not propose specific MIB extensions based on the > > > requirements. Rather, such extensions are left to the MIB > > > designers, in order to avoid past discussions of why specific > > > extensions won't work. But so far there is no help or > > > response from MIB designers on how to meet the requirements, > > > even though the problems have been identified on email lists > > > for more than one year. > > > > > > Here is a summary of requirements (R1,R2,R3 LDP related; > > > R4,R5 VPN related): > > > > > > R1. It is required to capture the signaling usage/performance > > > of the LDP Entities, as well as the traffic usage/performance > > > of the LDP Sessions. R2. It is required to ensure persistency > > > of information in the LDP-MIB Entity Table and Entity > > > Statistics Table, whenever an LDP Entity is disabled and then > > > re-enabled. R3. It is required that a count be reported of > > > mplsNumVrfRouteMaxThreshExceeded notification when the > > > operator-defined VRF maximum route threshold is exceeded. R4. > > > It is required to have an explicit mapping between VRF, RD, > > > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is > > > required to track the number of BGP prefixes on the PE-CE > > > link, and that the BGP neighbor maximum-prefix limit on the > > > PE-CE link be used to limit the number of eBGP routes > > > injected in the VRF. > > > > > > I agree with Harmen Van der Linde, "We need to get this MPLS > > > MIB module, together with the MPLS LDP and MPLS VPN modules, > > > standardized ASAP. There is a critical need for these MPLS > > > MIB modules for management of MPLS-enabled networks, which > > > are currently being deployed by many service providers." > > > > > > Bert threatened at IETF-56 to start over on MPLS MIBs if not > > > finished by IETF-57. > > > > > > We need the MPLS MIB designers to meet critical requirements > > > and complete ASAP. > > > > > > Thanks, > > > Jerry > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 20 16:38:24 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07191 for ; Fri, 20 Jun 2003 16:38:23 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KKbqP20040 for ; Fri, 20 Jun 2003 16:37:53 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5KKboN09638 for ; Fri, 20 Jun 2003 16:37:50 -0400 (EDT) Message-ID: <0536FC9B908BEC4597EE721BE6A35389025D6A11@i2km07-ukbr.domain1.systemhost.net> From: neil.2.harrison@bt.com To: townsley@cisco.com, kireeti@juniper.net Cc: rwilder@masergy.com, ppvpn@nortelnetworks.com Subject: RE: discussion topics for the mail list Date: Fri, 20 Jun 2003 21:35:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" X-SMTP-HELO: cbibipnt03.HC.BT.COM X-SMTP-MAIL-FROM: neil.2.harrison@bt.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: saturn.bt.com [193.113.57.20] X-LYRIS-Message-Id: Well said Mark....sorry bit late in response on this. My mail queue is a bit out of control. I sincerely hope Juha does not 'retire' in totality as our industry would be all the worse for this. regards, Neil > -----Original Message----- > From: W. Mark Townsley [mailto:townsley@cisco.com] > Sent: 11 June 2003 22:57 > To: Kireeti Kompella > Cc: rwilder@masergy.com; ppvpn@nortelnetworks.com > Subject: Re: discussion topics for the mail list > > > > > Kireeti Kompella wrote: > >>>1. draft-heinanen-radius-pe-discovery-04.txt: Does this version > >>>adequately address the Radius issues raised so that it can > now become a > >>>WG document? > >> > >>There has been a good bit of open technical participation > on this list such that > >>the document is taking on a WG tone already. Making it a WG > document seems to be > >>the next logical step. > > > > > > Sorry, Mark, the fact that there is a discussion/open technical > > participation DOES NOT qualify the doc as a WG doc; by no stretch > > What, would you instead count the number of people chiming in > with "[I,My company] supports this draft" type comments? > > I obviously thought that the technical participation thus far > was supportive of > the document. But in case there is any question, I will restate: > > "There has been a good bit of support and open technical > participation on this > list such that the document is taking on a WG tone already." > > > is "the next logical step" to make this a WG doc. I think Rick is > > doing the right thing in calling for WG consensus. > > The actual question that should be raised is consensus of > whether or not the > mechanism being proposed in general is something that the WG > should and is > willing to address with a document or not. It certainly helps > to have a > well-written and reviewed document to articulate this > effectively and generate > discussion, but the real focus should be on whether the topic > at hand is a > legitimate WG effort more than on whether a given individual > submission has > reached some level of readiness or not. I think that plenty > of discussion was > generated during the previous 2 week call on this topic > already. I saw no need > to restate Richard Spencer's excellent summary of the results > of this discussion > and subsequent actions taken by Juha as an individual draft > author here: > > http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305& L=ppvpn&T=0&F=&S=&P=52918 http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305&L=ppvpn&T=0&F= &S=&P=60930 This type of WG interaction (not to mention the show of hands at the last IETF meeting that caused Juha to continue the work individually to begin with), are all indications that there is strong potential for a productive WG effort, and that at least some (perhaps significant) number of people consider this to be a Good Thing. Not that there is consensus on every last issue the document raises or it is in any sort of final form, but this particular call for consensus comes before the document becomes an RFC, not before it becomes a WG document. Finally, I will add now that given the fact that Juha is retiring, it seems the perfect opportunity for the WG to adopt the work. - Mark > > Kireeti. > From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Jun 21 05:42:54 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04867 for ; Sat, 21 Jun 2003 05:42:53 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5L9gNL17006 for ; Sat, 21 Jun 2003 05:42:23 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5L9gIj10565 for ; Sat, 21 Jun 2003 05:42:19 -0400 (EDT) X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] From: "M. ELK" To: jsmith4112003@yahoo.co.uk, bannai@pacbell.net, mpls-ops@mplsrc.com Cc: ppvpn@nortelnetworks.com Subject: RE: [MPLS-OPS]: Nos of Labels in CE Date: Sat, 21 Jun 2003 09:38:42 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Jun 2003 09:38:42.0938 (UTC) FILETIME=[E74A5DA0:01C337D8] X-SMTP-HELO: hotmail.com X-SMTP-MAIL-FROM: elkou141061@hotmail.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: bay8-f2.bay8.hotmail.com [64.4.27.2] X-LYRIS-Message-Id: John AFAIK U are assuming that the PE to CE is conncected by a single p-2-p link ,which is normally the case but consider that it is also possible to connect PE to CE by several p-2-p interfaces and still run a single eBGP session between the PE and CE ( Load Sharing Using the Loopback Address as a BGP Neighbor, http://www.cisco.com/warp/public/459/40.html#1) . As Per the approach U describe (single label for all routes learned from a certain BGP neighbor) ,only one interface will be used for traffic . As another case : Consider a MCS (Mission critical site) composed of 2 CE's connected to the same PE on the same VRF. CE1 advertise 10./8 with mid=10 over intf1 and CE1 advertise 10./8 with mid=100 over intf2 . With the approach U descripe PE will bind assign L1 to all routes learned from CE1 and L2 to all routes learned from CE2 . PE will advertise RD:10./8 with L1 . assume now that CE1 advertise 10./8 with mid=200 so the PE have to withdraw RD:10./8 and re-advertise RD:10./8 with Label L2 (actually it is done by implicit withdraw by re-advertising Rd:10/8 with the new label L2 ) . so we creating Mp-BGP extra advertisement for no good reason . On the other side ,consider PE advertise RD:10./8 with L3 which is selected randomly . First L3 is pointing to IF1 . after the MID change the PE have to just update it's internal table to point L3 to If2 without any MP-BGP re-advertisement . Brgds >From: John Smith >To: bannai@pacbell.net, mpls-ops@mplsrc.com >CC: ppvpn@nortelnetworks.com >Subject: RE: [MPLS-OPS]: Nos of Labels in CE >Date: Fri, 20 Jun 2003 15:53:36 +0100 (BST) > >Vinay, > > > Either you have one label per route and associate the next hop L2 > > information (usually the destination mac address) with the label and >save it > > in the lookup table OR you pop the label and do a lookup on the IP DA to > > figure out the next hop that you can ARP (assuming it is still ethernet) >to > > get the next hop L2 information. > >The latter suits fine to me. > > > > > However, if you have point to point link (say PPP) as the outgoing > > interface, then it might make some sort of sense to associate label >binding > > for IP routes based on outgoing links. But if you do that you lost your > > ability to load balance unless you can figure out a way to associate > > multiple label bindings for the same IP routes emanating from different > > interfaces. > >I think i wasnt clear in stating my problem. What i want to do is to bind a >label to an >interface, rather than the routes which i recieve. Say, i have a BGP CE >peering over an >interface - What this means is that my BGP peering takes place through one >interface. I >will now bind one label Lx for this interface. I will be advertising this >label for all >the routes which i learn from this peer as i know it will always be this >peer which i >will use as my next-hop (as its an EBGP peer). > >Is this correct? > >Is it okay to associate a Label Lx with a BGP CE peer (implicitly an >interface) and to >always use when i need to advertise routes learnt from this peer. > >Lets verify that data forwarding will be done correctly? > >If this router recieves a MPLS packet with the BGP label as Lx, it will >simply pop off >this label and push the native IPv4 packet on the interface over which the >BGP peering >takes place. This packet when reaches the EBGP CE peer, will decide where >it needs to >forward this packet. > >I think it works fine - and thus my idea of binding an interface to a >Label!! > >Does anyone see any problems in this? > >Regards, >JOhn Smith > > > > >________________________________________________________________________ >Want to chat instantly with your online friends? Get the FREE Yahoo! >Messenger http://uk.messenger.yahoo.com/ > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Jun 21 10:43:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09550 for ; Sat, 21 Jun 2003 10:43:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5LEgkL03569 for ; Sat, 21 Jun 2003 10:42:47 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5LEghw28419 for ; Sat, 21 Jun 2003 10:42:44 -0400 (EDT) From: "kobakiokonji" Message-Id: <200306211346.TAA13219@WS0005.indiatimes.com> To: Reply-To: "kobakiokonji" Subject: URGENT RESPOND Date: Sat, 21 Jun 2003 20:08:35 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_2003621620835861021530" MIME-Version: 1.0 X-SMTP-HELO: WS0005.indiatimes.com X-SMTP-MAIL-FROM: kobakiokonji@indiatimes.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [203.199.93.15] X-LYRIS-Message-Id: --=_MAILER_ATTACH_BOUNDARY1_2003621620835861021530 Content-Type: text/plain; charset=us-ascii ATTN: SIR/MADAM FROM: KOBAKI OKONJI DIRECTOR, DELIVERY/OPERATIONS I am Kobaki Okonji , the Director of Delivery/Operations in a security company here in South Africa. Our firm is a securitycompany of high repute with years of outstanding service to the people of Africa especially top government officials and military leaders here in Africa. I have resolved to contact you through this medium based on businessproposal that will be of mutual benefit to both of us. I have not discussed this transaction with anybody because it is of top secret. To be explicit and straight to the point, some time early 1997, a reputable client of ours deposited a consignment in our company's vault for safe keeping. And since then our client has failed to come forward to claim his Consignment, which has accumulated a considerable amount of money in demurrage. Consequently, in our bide to contact this client to redeem the demurrage which his consignment had accumulated we discovered that our client was the former president of the Federal Republic of Zaire, who died of illness after he was dethroned in the same year the consignment was entrusted into our care. Since the death of our client President Mobutu Seseseko, none of his benefactors has come forward to claim the consignment with us, which means that non of his relatives or aids had any knowledge of this consignment. Hence out of curiosity I decided to secretly open the box that our client deposited in our vault. And to my surprise I discovered that the two boxes that were registered as treasures by our client actually contained a considerable amount of money in United States Dollars amounting to about US$9.5million US Dollar. Since this development I have been nursing plans secretly. I also found out from enquiries and the foreign media that our late client siphoned a lot of money from his country while he was in office as head of state. It is my conviction that the consignment in our vault was part of the money that our client siphoned and now that he is dead there is no trace to this money in our care. I am now soliciting your noble assistance to assist me in transferring this money out of South Africa to your country for immediate investment with your assistance. I have also decided that you and i will both agree on a percentage that will be entitled to you if this money is transfered into your nominated account. Upon my receipt of your reply confirming your willingness to assist me of this transaction, I will immediately arrange and transfer all the rights of ownership of this consignment to your name to facilitate your easy clearance and transfer of the complete funds to your country for onwards investment. This transaction is 100% risk free. Please maintain absolute confidentiality on this matter. I await your most prompt response. Yours faithfully, KOBAKI OKONJI Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now ! --=_MAILER_ATTACH_BOUNDARY1_2003621620835861021530 Content-Type: text/html; charset=us-ascii

          ATTN: SIR/MADAM
          FROM:  KOBAKI OKONJI   
          DIRECTOR, DELIVERY/OPERATIONS

          I am  Kobaki Okonji , the Director of Delivery/Operations in a security company here in South Africa. Our firm is a securitycompany of high repute with years of outstanding service to the people of Africa especially top government officials and military leaders here in Africa.
          I have resolved to contact you through this medium based on businessproposal that will be of mutual benefit to both of us. I have not discussed this transaction with anybody because it is of top secret.
          To be explicit and straight to the point, some time early 1997, a reputable client of ours deposited a consignment in our company's vault for safe keeping. And since then our client has failed to come forward to claim his Consignment, which has accumulated a considerable amount of money in
          demurrage. Consequently, in our bide to contact this client to redeem the demur! ra! ge which his consignment had accumulated we discovered that our client was the former president of the Federal Republic of Zaire, who died of illness after he was dethroned in the same year the
          consignment was entrusted into our care. Since the death of our client President Mobutu Seseseko, none of his benefactors has come forward to claim the consignment with us, which means that non of his relatives or aids had any knowledge of this consignment. Hence out of curiosity I decided to secretly open the box that our client deposited in our vault. And to my surprise I discovered that the two boxes that were registered as treasures by our client actually contained a considerable amount of money in
          United States Dollars amounting to about US$9.5million US Dollar.

          Since this development I have been nursing plans secretly. I also found out from enquiries and the foreign media that our late client siphoned a lot of money from his country
          while he was in office as hea! d ! of state. It is my conviction that the consignment in our vault was part of the money that our client siphoned and now that he is dead there is no trace to this money in our care.
           I am now soliciting your noble assistance to assist me in transferring this money out of South Africa to your country for immediate investment with your assistance.

          I have also decided that you and i will both agree on a percentage that will be entitled to you if this money is transfered into your nominated account.  Upon my receipt of your reply confirming your willingness to assist me of this transaction, I will immediately arrange and transfer all the rights of ownership of this consignment to your name to facilitate your easy clearance and transfer of the complete funds to your country for onwards investment.
          This transaction is 100% risk free. Please maintain absolute confidentiality on this matter.

          I await your most prompt response.


           Yours faithfully,

          KOBAKI OKONJI  

          Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
          Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com
          Bid for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now !           --=_MAILER_ATTACH_BOUNDARY1_2003621620835861021530-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 23 09:30:33 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19845 for ; Mon, 23 Jun 2003 09:30:31 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NDLtI06554 for ; Mon, 23 Jun 2003 09:21:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5NDLqT17413 for ; Mon, 23 Jun 2003 09:21:52 -0400 (EDT) Date: Mon, 23 Jun 2003 10:14:21 -0300 (EST) From: Marcel Cavalcanti De Castro To: mpls-ops@mplsrc.com, ppvpn@nortelnetworks.com Subject: Network measurement systems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ariadne.dt.fee.unicamp.br id JAA21297 X-SMTP-HELO: ariadne.dt.fee.unicamp.br X-SMTP-MAIL-FROM: castro@dt.fee.unicamp.br X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ariadne.dt.fee.unicamp.br [143.106.12.20] X-LYRIS-Message-Id: Content-Transfer-Encoding: quoted-printable Hi Sorry for this disturb but I would like to know if there is someone that have some experience with Network Delay Measurement (oneway delay measurement)? I am looking for some software or hardware that I could do it. Thanks in advantage @> /()\ -^^--------------------------------------------------------- Marcel Cavalcanti de Castro Departamento de Telem=E1tica - DT Universidade Estadual de Campinas - UNICAMP www.dt.fee.unicamp.br/~castro ICQ: 131702293 ----------------------------------------------------------- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 23 10:25:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22539 for ; Mon, 23 Jun 2003 10:25:40 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NENqI00201 for ; Mon, 23 Jun 2003 10:23:52 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5NENmQ23216 for ; Mon, 23 Jun 2003 10:23:49 -0400 (EDT) Message-ID: <3EF70D0D.6020609@fusiontel.com> Date: Mon, 23 Jun 2003 10:22:05 -0400 From: joshua sahala User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Cavalcanti De Castro CC: mpls-ops@mplsrc.com, ppvpn@nortelnetworks.com Subject: Re: [MPLS-OPS]: Network measurement systems References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SMTP-HELO: nt_exchange.fusiontel.com X-SMTP-MAIL-FROM: jsahala@fusiontel.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: 216-199-153-34.ftl.fdn.com [216.199.153.34] X-LYRIS-Message-Id: Content-Transfer-Encoding: 8bit check out http://www.caida.org/tools/taxonomy/performance.xml#oneway /joshua Marcel Cavalcanti De Castro wrote: > Hi > > Sorry for this disturb but I would like to know if there is someone > that have some experience with Network Delay Measurement (oneway delay > measurement)? > I am looking for some software or hardware that I could do it. > Thanks in advantage > > @> > /()\ > -^^--------------------------------------------------------- > Marcel Cavalcanti de Castro > Departamento de Telemática - DT > Universidade Estadual de Campinas - UNICAMP > www.dt.fee.unicamp.br/~castro > ICQ: 131702293 > ----------------------------------------------------------- > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 23 14:48:15 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03747 for ; Mon, 23 Jun 2003 14:47:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NIRxN06499 for ; Mon, 23 Jun 2003 14:27:59 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5NIRbB10560 for ; Mon, 23 Jun 2003 14:27:37 -0400 (EDT) Message-Id: <200306231523.h5NFNxai028398@rtp-core-1.cisco.com> To: vkompella@timetra.com cc: "Loa Andersson" , "Ppvpn" Subject: Re: VPLS naming issues In-reply-to: Your message of Mon, 16 Jun 2003 10:15:17 -0700. 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.3 (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, 23 Jun 2003 11:23:58 -0400 From: Eric Rosen X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: erosen@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] X-LYRIS-Message-Id: Vach> 2. Naming the VPLS: currently the name of the VPLS is the VCID. This Vach> is not adequate. I proposed a VPN ID TLV. Eric proposed a Vach> Generalized ID FEC. I'd like to get this resolved as to which Vach> direction we should proceed. I have already raised this issue on Vach> the mailing list, and would like to get some more feedback before Vach> Vienna. Vach> What I would like is to be able to name the VPLS, name each PW in the Vach> VPLS, identify each PW with a VC type, and associate each PW with a Vach> split-horizon group. I'd like to be able to do this too; in fact, the Generalized FEC Id does this easily. The only real difference between the VPN ID TLV and the Generalized FEC ID is that the latter allows a PW to have a different name at each of its endpoints, while the former requires it to have the same name at both endpoints. If one considers only those applications which appear in drafts co-authored by Vach ;-), then it will appear that there is no need for PWs to be named differently at the two endpoints. If there is no such need, then the two proposals are functionally identical, but the Generalized FEC Id is more complicated. (I'd say only "slightly" more complicated, but perhaps others would diagree.) However, if one considers some additional applications (such as those described in draft-rosen-ppvpn-l2-signaling-03.txt sections 5.1.1.2, 5.3, 5.4, and 5.5), then I don't think the VPN ID TLV is adequate. Of particular concern is the application in 5.5 (distributed VPLS), as this needs to be interoperable with "regular" VPLS. I think we need one naming space which covers both the distributed VPLS and the regular VPLS, and I don't see how this can be the VPN ID TLV. Perhaps not everyone takes distributed VPLS seriously, but if it is to be ruled out, it should be done so explicitly, not as a (possibly unintended) side-effect of the way we adopt a naming space. The other applications for which the VPN ID TLV is unsuitable are VPWS applications, and conceivably we could use a different naming structure for VPWS than for VPLS. However, I think that would be a complication rather than a simplification. My thinking is that the Generalized FEC Id is a naming mechanism which provides everything that is needed for VPLS, but which also can cover more applications. So I don't really see the downside. From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 23 15:31:42 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07040 for ; Mon, 23 Jun 2003 15:31:41 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NJVAN04484 for ; Mon, 23 Jun 2003 15:31:10 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5NJV7Z13935 for ; Mon, 23 Jun 2003 15:31:07 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: erosen@cisco.com, vkompella@timetra.com Cc: Loa Andersson , Ppvpn Subject: RE: VPLS naming issues Date: Mon, 23 Jun 2003 15:13:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C339BB.83F4686A" 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_01C339BB.83F4686A Content-Type: text/plain; charset="iso-8859-1" Eric, > > My thinking is that the Generalized FEC Id is a naming > mechanism which > provides everything that is needed for VPLS, but which also > can cover more > applications. So I don't really see the downside. > I haven't seen this subject line before (I guess I didn't realize that Vach's email on timeslot request included items to be discussed). I agree that VPN-ID TLV doesn't address the scope of deployment scenarios that a VPLS system needs to consider and particularly distributed VPLS case. I am not sure I understand why Vach is insisting on VPN-ID TLV since clearly it requires extra work that has already been done within PWE3 wg and l2vpn drafts proposals (which pretty much address Vach's main requirements and other l2vpn requirements). Besides that any VPN-ID proposal will need to be standardized...why go through all of that while we do have an approach that is already available and documented. I thought initially the motivation behind VCID is to line up with Martini's initial signaling model (PWid FEC), but with the introduction of a VPN-ID TLV that goal disappears anyway. Are there clearly new requirements or technical benefits that justify defining a new VPN-ID TLV besides just using the Generalized ID FEC? Hamid. ------_=_NextPart_001_01C339BB.83F4686A Content-Type: text/html; charset="iso-8859-1"
          Eric,

          >
          > My  thinking is  that the  Generalized FEC  Id is  a naming 
          > mechanism which
          > provides everything that  is needed for VPLS, but which  also
          > can cover more
          > applications.  So I don't really see the downside.
          >
           
          I haven't seen this subject line before (I guess I didn't realize
          that Vach's email on timeslot request included items to be
          discussed).
           
          I agree that VPN-ID TLV doesn't address the scope of
          deployment scenarios that a VPLS system needs to consider
          and particularly distributed VPLS case.
           
          I am not sure I understand why Vach is insisting on VPN-ID
          TLV since clearly it requires extra work that has already been done
          within PWE3 wg and l2vpn drafts proposals (which pretty much address
          Vach's main requirements and other l2vpn requirements). Besides that any
          VPN-ID proposal will need to be standardized...why go through all of
          that while we do have an approach that is already available and
          documented.
           
          I thought initially the motivation behind VCID is to line up
          with Martini's initial signaling model (PWid FEC), but with
          the introduction of a VPN-ID TLV that goal disappears anyway.
           
          Are there clearly new requirements or technical benefits
          that justify defining a new VPN-ID TLV besides just
          using the Generalized ID FEC?
           
          Hamid.
          ------_=_NextPart_001_01C339BB.83F4686A-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 23 15:43:51 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07411 for ; Mon, 23 Jun 2003 15:43:34 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NJglN09796 for ; Mon, 23 Jun 2003 15:42:47 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5NJgfZ03251 for ; Mon, 23 Jun 2003 15:42:41 -0400 (EDT) Reply-To: From: "Vach Kompella" To: "Hamid Ould-Brahim" , Cc: "Loa Andersson" , "Ppvpn" Subject: RE: VPLS naming issues Date: Mon, 23 Jun 2003 12:34:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 23 Jun 2003 19:33:04.0467 (UTC) FILETIME=[440B5A30:01C339BE] X-SMTP-HELO: exchange.timetra.com X-SMTP-MAIL-FROM: vkompella@timetra.com X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: host-64-47-48-7.masergy.com [64.47.48.7] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit >> I am not sure I understand why Vach is insisting on VPN-ID >> TLV since clearly it requires extra work that has already been done >> within PWE3 wg and l2vpn drafts proposals (which pretty much address >> Vach's main requirements and other l2vpn requirements). I don't believe I'm insisting on a VPN ID TLV. Hamid, you should probably go and read my email. I think I know both Hamid's and Eric's opinions. I'm sure there are any number of ways of encoding a VPN ID. I am trying to gauge consensus before I go and make a significant unilateral change in a document that is a WG document. I hope people are not as apathetic in Vienna. >> I haven't seen this subject line before (I guess I didn't realize >> that Vach's email on timeslot request included items to be >> discussed). Loa asked for us to post the points we wanted to raise in our timeslots so that we could get email activity before the meeting (and hopefully have brief timeslots). -Vach From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 23 15:47:41 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07584 for ; Mon, 23 Jun 2003 15:47:39 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NJl8N13293 for ; Mon, 23 Jun 2003 15:47:08 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5NJl4310544 for ; Mon, 23 Jun 2003 15:47:05 -0400 (EDT) Message-ID: From: "Hamid Ould-Brahim" To: vkompella@timetra.com, erosen@cisco.com Cc: Loa Andersson , Ppvpn Subject: RE: VPLS naming issues Date: Mon, 23 Jun 2003 15:43:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C339BF.A8CBDBD8" 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_01C339BF.A8CBDBD8 Content-Type: text/plain; charset="iso-8859-1" Vach, > I think I know both Hamid's and Eric's opinions. I'm sure > there are any number > of ways of encoding a VPN ID. I am trying to gauge consensus > before I go and > make a significant unilateral change in a document that is a > WG document. Sure. Fair enough. Hamid. ------_=_NextPart_001_01C339BF.A8CBDBD8 Content-Type: text/html; charset="iso-8859-1"

          Vach,

          >           I think I know both Hamid's and Eric's opinions.  I'm sure
          > there are any number
          > of ways of encoding a VPN ID.  I am trying to gauge consensus
          > before I go and
          > make a significant unilateral change in a document that is a
          > WG document. 

          Sure. Fair enough.
           
          Hamid.
          ------_=_NextPart_001_01C339BF.A8CBDBD8-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 24 10:32:13 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18423 for ; Tue, 24 Jun 2003 10:31:57 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5OEMsC17916 for ; Tue, 24 Jun 2003 10:22:54 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5OEMpS03372 for ; Tue, 24 Jun 2003 10:22:51 -0400 (EDT) Message-ID: From: "" To: "Paul Nevill" Subject: Re: that guy can wait Date: Tue, 24 Jun 03 08:16:26 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4E.._AF8_.E.F7.39B_E2" X-Priority: 3 X-MSMail-Priority: Normal X-SMTP-HELO: 47.234.0.33 X-SMTP-MAIL-FROM: margreturhofer@gmx.at X-SMTP-RCPT-TO: pnevill@nortelnetworks.com,postmaster@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [218.76.15.194] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --4E.._AF8_.E.F7.39B_E2 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Nuova pagina 1


          FOR YOU ONLY

          Hello friends,
          I do it just to satisfate my pleasure, not for money!
          ASK ME ANYTHING YOU LIKE! THERE IS NO LIMIT!
          TRY IF I AM ON LINE
          Meet me on line when you have time!
          Giusy85

           

           

           

           

           

          Are you not = interested?
           Leave


           

           

          obflhioz udw ru arycdydwu vfmecidvqwiimg e --4E.._AF8_.E.F7.39B_E2-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Tue Jun 24 23:25:43 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04766 for ; Tue, 24 Jun 2003 23:25:42 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5P3Ls628068 for ; Tue, 24 Jun 2003 23:21:54 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5P3Lq710974 for ; Tue, 24 Jun 2003 23:21:52 -0400 (EDT) Subject: UNSUBSCRIBE To: ppvpn@nortelnetworks.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: weng.qing@zte.com.cn Date: Wed, 25 Jun 2003 11:13:23 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-06-25 11:20:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-SMTP-HELO: zte.com.cn X-SMTP-MAIL-FROM: weng.qing@zte.com.cn X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [211.96.102.115] X-LYRIS-Message-Id: UNSUBSCRIBE From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 25 02:05:44 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12523 for ; Wed, 25 Jun 2003 02:05:43 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5P64T615674 for ; Wed, 25 Jun 2003 02:04:30 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5P64Qq23496 for ; Wed, 25 Jun 2003 02:04:27 -0400 (EDT) Message-Id: <200306250602.h5P62oW29216@zcars0jk.ca.nortel.com> From: =?GB2312?B?s8LWx8H6?= <777man@sina.com.cn> Subject: =?GB2312?B?z/LE+s3GvPbSu7/uuN/Q1Lzbsci1xLfAu/DHvaOos8LWx8H6o6k=?= To: ppvpn@nortelnetworks.com Content-Type: text/plain;charset="GB2312" Reply-To: 777man@sina.com.cn Date: Wed, 25 Jun 2003 14:02:39 +0800 X-Priority: 3 X-Mailer: FoxMail 4.0 beta 2 [cn] X-SMTP-HELO: sina.com.cn X-SMTP-MAIL-FROM: 777man@sina.com.cn X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [218.19.0.105] X-LYRIS-Message-Id: ÄúºÃ! ·Ç³£¸ßÐËÄܹ»ÓëÄúÁªÏµ, ÎҽгÂÖÇÁú£¬Ö÷Òª´ÓÊÂÍøÂ簲ȫµÄ²úÆ·ÏúÊÛ¹¤×÷£¬ÎÒ´ÓһλÅóÓÑ´¦µÃÖªÄúµÄE-MAIL µØÖ·£¬²¢ÇÒ±»¸æÖªÄú¶ÔÍøÂ簲ȫ·Ç³£¸ÐÐËȤ£¬ËùÒÔðÃÁµØ¸øÄãдÕâ·âÐÅ£¬Èç¹ûÕâ·âПøÄú´øÀ´²»±ã£¬»¹ÇëÔ­Á£¡ ÎÒÏÖÔÚ¸øÄúÍƼöÒ»¸öеÄÆ·ÅƵķÀ»ðǽ²úÆ·£¬¾ÍÊÇÀ´×Ô¹úºãÁªºÏµÄËÙͨ·À»ðǽ£¬±±¾©¹úºãÁªºÏ¿Æ¼¼ÓÐÏÞ¹«Ë¾³ÉÁ¢ÓÚ2002Äê12Ô£¬ÊDZ±¾©¹úºã¼¯ÍŹ«Ë¾ÏÂÊôµÄ¸ßм¼ÊõÆóÒµ¡£¹«Ë¾Á¢×ã¹úÄÚÊг¡£¬µ÷ÑÐÕþ¸®¡¢µçÐÅ¡¢½ðÈÚ¡¢ÖÐСÆóÒµµÈ¸÷ÀàÓû§ÍøÂ簲ȫÐèÇóÌص㣬ÒÔ×ÔÓм¼Êõ×ÔÐпª·¢ÍøÂ簲ȫ²úÆ·£¬ÍƳöÊʺÏÉÏÊöÓû§ÐèÇóµÄ²úÆ·ºÍ½â¾ö·½°¸£¬ÌṩÓÐЧµÄ°²È«·þÎñ¡£Í¬Ê±ÎÒÃÇ»á¸ù¾ÝÊг¡ÐèÇóÌصãÊÊʱÍƳö¸ü¾ß¾ºÕùÁ¦µÄÆäËû°²È«²úÆ·¡£ Ä¿Ç°ÒÑÔÚÊг¡³É¹¦ÍƳöµÄ²úÆ·ÓйúºãËÙͨϵÁзÀ»ðǽ£¬¹²·ÖAºÍB ϵÁУ¬ÆäÖÐAϵÁÐÖ÷ÒªÕë¶Ô´óÖÐÐÍÆóÒµÒÔ¼°µçÐż¶ÆóÒµ£¬¶øBϵÁзÀ»ðǽÖ÷ÒªÕë¶ÔÖÐСÐÍÆóÒµ£¬ËäÈ»BϵÁзÀ»ðǽÖ÷Òª¿Í»§Ä¿±êËø¶¨ÔÚÖÐСÐÍÆóÒµ£¬µ«ÊÇËûµÄÐÔÄÜÓëÄ¿Ç°Êг¡ÉϵİÙÕ×ÏßËÙÏà±ÈÈ´Ò»µãÒ²²»Ñ·É«£¬Ëü³ýÁ˲»Ö§³ÖVLAN£¬Á÷Á¿¼Æ·Ñ£¬×¨ÓüÓÃÜÓ²¼þºÍ¸ºÔؾùºâÍ⣬ÆäËû·À»ðǽµÄ¹¦Äܶ¼Ö§³Ö£¬±ÈÈçÖ§³Ö͸Ã÷ºÍ·ÓÉģʽ£¬Ö§³ÖIP/MAC°ó¶¨£¬Ö§³ÖÓëÈëÇÖ¼ì²âµÄÁª¶¯£¬Ö§³ÖVPNÍø¹ØµÈ£¬ÁíÍâËü»¹¾ßÓÐÓÅÔ½µÄÐԼ۱ȣ¬B100-3·À»ðǽ֧³Ö100Õ×´ø¿í£¬×î´ó²¢·¢Á¬½ÓÊý´ïµ½5Íò¸ö£¬×î¼Ñ״̬ʱÓû§¿É´ïµ½100¸ö£¬¶øÕâÑùÒ»¿îÐÔÄÜÓÅÔ½µÄ·À»ðǽÏÖÔÚµÄÇþµÀ¼Û¸ñÖ»ÓÐ8600ÔªÈËÃñ±Ò£¬ÏàÐÅÄúÒ»¶¨ÓÐÐËȤ¡£ ÎÒÃÇÏàÐÅͨ¹ý±±¾©¹úºãÁªºÏ¿Æ¼¼ÓÐÏÞ¹«Ë¾ºÍÄúµÄ¹²Í¬Å¬Á¦£¬¶ÔÓÚ¹úºãËÙͨ·À»ðǽ²úÆ·µÄÊг¡¸²¸ÇÃæ¡¢Êг¡Õ¼ÓÐÂʽ«»á´øÀ´·ÉËÙµÄÔö³¤ºÍÏÔÖøÌá¸ß¡£ÎÒÃÇÒ²³ä·ÖÐÅÈÎÄú¶ÔÓÚÄúËùÔÚÇøÓòµÄÊг¡¿ªÍØÄÜÁ¦ºÍ²úÆ·ÇþµÀÏúÊÛÄÜÁ¦¡£ Ôڹ㷺ºÏ×÷ºÍË«Ó®Ô­Ôò»ù´¡ÉÏ£¬ÎÒÃÇΪ´úÀíÉ̽¨Á¢ÁËÈ«·½Î»µÄÅàѵ֧³ÖºÍ¼¼Êõ·þÎñÖ§³Ö£¬Í¬Ê±¿¼Âǵ½°²È«²úÆ·µÄÌصãÎÒÃÇÍƳöÁ˼«¾ßÓÅÊƵÄÊг¡ÍƹãÖ§³ÖºÍ½â¾ö·½°¸Ö§³ÖµÈ£¬ÖÔÐĵػ¶Ó­Äú¼ÓÈë¹úºãËÙͨ´úÀíÉÌ´ó¼ÒÍ¥£¬ÄúµÄ¼ÓÃ˽«ÎªÎÒÃÇÔöÌíÁËеĻîÁ¦ºÍÉú»ú£¬ÈÃÎÒÃÇЯÊÖ²¢½ø£¬¹²´´ÃÀºÃδÀ´¡£ ÖÔÐÄÏ£ÍûÎÒÃǽ«À´Äܹ»Óлú»áºÏ×÷,ÄúÈç¹û¶Ô¼¼ÊõÉÏÓÐʲôÒÉÎÊ»ò»¹¶Ô²úÆ·½øÐÐÉîÈëµÄÁ˽⣬¿ÉÒÔÖµçÎÒÃÇ020-87564813»òÖ±½Ó·ÃÎÊÎÒ¹«Ë¾µÄÍøÕ¾: www.goldenhope.com.cn ,ÎÒ¶ÔÓÚÇþµÀÕþ²ßµÄÒÉÎÊ¿ÉÒÔÖ±½ÓÓëÎÒÁªÏµ13822194195 ²¢×£ ¹¤×÷Óä¿ì,ÉíÌ彡¿µ! ______________________________________ ÍøÂçÐèÒª±£»¤£¬ÎÒÀ´ÎªÄú±£ÕÏ£¡ ±±¾©¹úºãÁªºÏ¿Æ¼¼ÓÐÏÞ¹«Ë¾¹ãÖÝ°ìÊ´¦ ÍøÂ簲ȫ²úÆ·¸ºÔðÈË ³ÂÖÇÁú ¹ãÖÝÊÐÌìºÓÇøÖÐɽ´óµÀ20ºÅÃ÷Ðù´óÏÃB×ù2109 Tel:020-87564813 Fax:020-87564813ת ÊÖ»ú:13822194195 www.goldenhope.com.cn E-MAIL: 777man@sina.com.cn From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 25 04:57:18 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05108 for ; Wed, 25 Jun 2003 04:57:18 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5P8uW607108 for ; Wed, 25 Jun 2003 04:56:32 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5P8uTE14462 for ; Wed, 25 Jun 2003 04:56:29 -0400 (EDT) Date: Wed, 25 Jun 2003 16:46:20 +0800 From: lidefeng Subject: About PPVPN wg To: rwilder@masergy.com, narten@us.ibm.com, zinin@psg.com, bwijnen@lucent.com, Loa Andersson Cc: ppvpn@nortelnetworks.com Message-id: <009a01c33af6$4079dd40$07436e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi,all, What is the agenda for the 57th PPVPN wg meeting,and I learned that PPVPN wg has the plan to split the wg into two wg,l3vpn and l2vpn, how about its progress? And where should I submit the latest draft? By the way, we hope the two drafts we submited can be discussed on the coming meeting,one is draft-libin-hierarchy-pe-bgp-mpls-vpn-02,the other is draft-sheng-isis-bgp-mpls-vpn-01.I wonder why these two drafts have no the relevant I-D ACTION notification in the mail-list? Thanks Defeng Li Huawei Technologies +86-10-82882343 lidefeng@huawei.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 25 05:20:06 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05370 for ; Wed, 25 Jun 2003 05:20:06 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5P9Ja623285 for ; Wed, 25 Jun 2003 05:19:36 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5P9JXe02522 for ; Wed, 25 Jun 2003 05:19:33 -0400 (EDT) Message-ID: <03ce01c33afb$24da6280$81c802c0@alok> From: "Alok Dube" To: "Aamer Akhter" , "John Smith" , Cc: References: Subject: Re: [MPLS-OPS]: Nos of Labels in CE Date: Wed, 25 Jun 2003 14:51:04 +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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-SMTP-HELO: mail.apara.com X-SMTP-MAIL-FROM: alok.dube@apara.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [64.106.140.220] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Aamer, I would like to ask the following: > >> I think you want to say same next-hop rather than interface. > > > > No, I mean the same interface. What difference does it make to me if i have a > > prefix > > which has different next-hops and both the next-hops are reachable to me thru > > the same > > interface/sub-interface (e.g. ethernet) > > Which next-hop would you forward the packet to, in the case of multiple > next-hops reachable via a multi-access interface (eg ethernet)? Keep in mind > that unlike point-point interfaces you have to do a L2 rewrite that includes > a MAC address on multi-access interfaces. agreed, but wherever the "label switching starts" too,you have to do an L3 lookup.. take the case of a packet entring a VRF with multiple interfaces in the VRF.(L3VPN) how does one determine where to Label switch the packet to without doing an L3 lookup? atleast in the case of binding labels to P2P interfaces we have an advantage of avoiding an L3 lookup at egress point. From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 25 06:05:30 2003 Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06038 for ; Wed, 25 Jun 2003 06:05:30 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5PA1v610069 for ; Wed, 25 Jun 2003 06:01:57 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5PA1sl05346 for ; Wed, 25 Jun 2003 06:01:54 -0400 (EDT) X-Original-Recipient: ppvpn@nortelnetworks.com Message-ID: <3EF97131.9010204@pi.se> Date: Wed, 25 Jun 2003 11:53:53 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lidefeng CC: rwilder@masergy.com, narten@us.ibm.com, zinin@psg.com, bwijnen@lucent.com, ppvpn@nortelnetworks.com Subject: Re: About PPVPN wg References: <009a01c33af6$4079dd40$07436e0a@HUAWEI.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-HELO: maild.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: maild.telia.com [194.22.190.101] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Li, the discussion on the l2vpn and l3vpn lists and since the wg action hs been announced also on the ietf-list. General information about the mailing lists is at: https://www1.ietf.org/mailman/listinfo/l2vpn https://www1.ietf.org/mailman/listinfo/l3vpn In Vienna there will be two ppvpn sessions - on for l3 vpn's and on for l2 vpn's. As for the two drafts you are referring to they are in the repository, but it is a requirment that they are discussed on the list (ppvpn) before we will assign agenda slots. /Loa lidefeng wrote: > Hi,all, > > What is the agenda for the 57th PPVPN wg meeting,and I learned that PPVPN wg > has the plan to split the wg into two wg,l3vpn and l2vpn, how about its > progress? And where should I submit the latest draft? > > By the way, we hope the two drafts we submited can be discussed on the > coming meeting,one is > draft-libin-hierarchy-pe-bgp-mpls-vpn-02,the other is > draft-sheng-isis-bgp-mpls-vpn-01.I wonder why these two drafts have no the > relevant I-D ACTION notification in the mail-list? > > Thanks > > Defeng Li > Huawei Technologies > +86-10-82882343 > lidefeng@huawei.com > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se Welcome to the L2vpn@ietf.org mailing list! To post to this list, send your email to: l2vpn@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/l2vpn ************************************************************************** From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 25 09:57:28 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09942 for ; Wed, 25 Jun 2003 09:57:27 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5PDtCj24173 for ; Wed, 25 Jun 2003 09:55:12 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5PDt9518799 for ; Wed, 25 Jun 2003 09:55:09 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 25 Jun 2003 09:53:06 -0400 Subject: Re: [MPLS-OPS]: Nos of Labels in CE From: Aamer Akhter To: Alok Dube , John Smith , CC: Message-ID: In-Reply-To: <03ce01c33afb$24da6280$81c802c0@alok> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SMTP-HELO: sj-iport-1.cisco.com X-SMTP-MAIL-FROM: aakhter@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-iport-1-in.cisco.com [171.71.176.70] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit On 6/25/03 5:21 AM, "Alok Dube" wrote: > Aamer, > > I would like to ask the following: > > >>>> I think you want to say same next-hop rather than interface. >>> >>> No, I mean the same interface. What difference does it make to me if i > have a >>> prefix >>> which has different next-hops and both the next-hops are reachable to me > thru >>> the same >>> interface/sub-interface (e.g. ethernet) >> >> Which next-hop would you forward the packet to, in the case of multiple >> next-hops reachable via a multi-access interface (eg ethernet)? Keep in > mind >> that unlike point-point interfaces you have to do a L2 rewrite that > includes >> a MAC address on multi-access interfaces. > > agreed, > > but wherever the "label switching starts" too,you have to do an L3 lookup.. Not really. You only really need to look at the ip address (lets ignore internal loadsharing implementations for now) if the label type is 'aggregate'. In the aggregate case the label does not convey enough information about what the forwarding behavior should be. > > take the case of a packet entring a VRF with multiple interfaces in the > VRF.(L3VPN) > > how does one determine where to Label switch the packet to without doing an > L3 lookup? When you allocate the label, you should know what the forwarding behavior is going to be for the label. If you need to do a arp later on, you do it and cache it. > > atleast in the case of binding labels to P2P interfaces we have an advantage > of avoiding an L3 lookup at egress point. > > > > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml -- Aamer Akhter / aa@cisco.com NSITE - cisco Systems From bounce-ppvpn-132618@lyris.nortelnetworks.com Wed Jun 25 10:57:26 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13401 for ; Wed, 25 Jun 2003 10:57:25 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5PEuej08027 for ; Wed, 25 Jun 2003 10:56:40 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5PEuaf29260 for ; Wed, 25 Jun 2003 10:56:36 -0400 (EDT) Message-Id: <200306251454.KAA13246@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-ldp-00.txt Date: Wed, 25 Jun 2003 10:54:44 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@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 Private LAN Services over MPLS Author(s) : M. Lasserre et al. Filename : draft-ietf-ppvpn-vpls-ldp-00.txt Pages : 25 Date : 2003-6-24 This document describes a virtual private LAN service (VPLS) solution over MPLS, also known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users. It delivers a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. Many VPLS services can be supported from a single PE node. This document describes the control plane functions of signaling demultiplexor labels, extending [PWE3-CTRL] and rudimentary support for availability (multi-homing). It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing, in particular, on the learning of MAC addresses. The encapsulation of VPLS packets is described by [PWE3- ETHERNET]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-ldp-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-vpls-ldp-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-vpls-ldp-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: <2003-6-25103640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-vpls-ldp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-vpls-ldp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103640.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Thu Jun 26 09:00:46 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22871 for ; Thu, 26 Jun 2003 09:00:31 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5QCjhW03630 for ; Thu, 26 Jun 2003 08:45:45 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5QCjXD07473 for ; Thu, 26 Jun 2003 08:45:34 -0400 (EDT) Message-Id: <200306261243.h5QChAp15335@zcars0ms.ca.nortel.com> From: ARNOUTS TREASURE LYNEX LOTTERY To: ppvpn@lyris.nortelnetworks.com Reply-To: realityprocessing@wowmail.com Subject: Your Winning Notification from Arnouts Treasure Lottery. Date: Thu, 26 Jun 2003 14:43:31 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="09701e1b-a7e2-11d7-9591-0040c72e03bc" X-SMTP-HELO: excite2262.com X-SMTP-MAIL-FROM: arnoutswinning@excite.com X-SMTP-RCPT-TO: ppvpn@lyris.nortelnetworks.com X-SMTP-PEER-INFO: [213.201.146.42] X-LYRIS-Message-Id: This is a multi-part message in MIME format --09701e1b-a7e2-11d7-9591-0040c72e03bc Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FROM: THE DESK OF THE DIRECTOR, INTERNATIONAL PROMOTION/PRIZE AWARD DEPT ARNOUTS TREASURE LYNEX LOTTERY EUROPE BRANCH BURDENSTRAAT 22 1053 DS, AMSTERDAM.THE NETHERLANDS. REF: UC/2311786008/01=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 BATCH: 14/011/IPD Sir/Madam, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= RE: WINNING NOTIFICATION/FINAL NOTICE. We are pleased to inform you of the release today the=A026th of=A0June 2003, = of the=A0Arnouts Treasure Lynex B.V Lottery International=A0program held on = the 23rd of=A0June 2003. Your company or personal email address attached to = ticket number 305-12294178-819 with serial number 2275-99 drew lucky numbers = 8-23-55-6-4-32 which consequently won the lottery in the 2nd category. You = have therefore been approved for a lump sum payout of 2,000,000.00 Euros (Two = million Euros)=A0in cash credited to file Ref. No UC/2311786008/01.This is = from a total cash prize of 20 million Euros shared among=A0ten international = lucky winners in this category. CONGRATULATIONS. Your fund is now deposited with our Correspondence paying = Bank in Spain to your attached winning details due to mix up of some numbers = and names, we ask that you keep this winning=A0private from public notice = until your claim has been processed and your money remitted to your = designated account. This is part of our security protocol to avoid double = claim and unwarranted taking advantage of this program by participants. All participants were selected through a computer ballot system drawn from = over 500,000 companies and individual email addresses from all over the world = as part of our international promotions programme, which takes place every = year for a free promotion. This prize is free for you and is an avenue for = our publicity against future staking. You are are required to contact our processing agency on below details with = your full Name, Telephone and Fax Number to process your winning and submit = your file with our correspondence bank for payment. And we hope, with part of = your winning, you will take part in our end of year stake of 50 million Euros = international lottery.=A0Remember, all winning must be claimed not later = than=A0July of 10th 2003. After this date all unclaimed fund will be returned = to the pool as unclaimed. NOTE: In order to avoid unnecessary delays and complications please remember = to quote your Reference, Batch,Seria and Draw=A0numbers in all correspondence = with our agent MR. PINAS LAN ROCESSING CO-ORDINATOR OF REALTY PROCESSING = AGENCY,=A0=A0 A DIVISION OF=A0R CAMARA GROUP=A0=A0=A0 = realityprocessing@wowmail.com =A0Furthermore, should there be any change of address, do inform your agent = as soon as possible. Anybody under the age of 18 years is automatically = disqualified. Congratulations once more from our members of staff and thank you for being = part of our promotional program. Sincerely Kaline Matijs --09701e1b-a7e2-11d7-9591-0040c72e03bc-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 27 08:52:37 2003 Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26471 for ; Fri, 27 Jun 2003 08:52:36 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5RCq3514043 for ; Fri, 27 Jun 2003 05:52:04 -0700 (PDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5RCIbk24303 for ; Fri, 27 Jun 2003 08:18:37 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5RCIYq17481 for ; Fri, 27 Jun 2003 08:18:34 -0400 (EDT) Date: Fri, 27 Jun 2003 17:18:07 +0800 From: lidefeng Subject: Consult about draft-behringer-mpls-vpn-auth-02.txt To: "Michael H. Behringer" , Jim Guichard , Pedro Roque Marques Cc: ppvpn@nortelnetworks.com Message-id: <000901c33c8d$06199120$07436e0a@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=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi, In Section 4 Extranet VPN Processing of draft-behringer-mpls-vpn-auth-02.txt,it states that "There are typically two types of Extranets that can be defined using the [RFC2547] architecture; Central Services Extranet and Distributed Extranet." I can't figure out the scenarios of the two types of Extranets,especially the topology,Could you please clarify them to me with the illustration of topology of the two types of Extranets. Sincerely Yours Defeng Li Huawei Technologies +86-10-82882343 lidefeng@huawei.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 27 08:50:45 2003 Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26371 for ; Fri, 27 Jun 2003 08:50:30 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5RCeC512836 for ; Fri, 27 Jun 2003 05:40:12 -0700 (PDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5RCe9L29494 for ; Fri, 27 Jun 2003 08:40:09 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5RCNoq26321 for ; Fri, 27 Jun 2003 08:23:50 -0400 (EDT) Date: Fri, 27 Jun 2003 19:04:27 +0800 From: lidefeng Subject: Fw: Warning: could not send message for past 1 hour To: rwilder@masergy.com, Loa Andersson , bwijnen@lucent.com, zinin@psg.com Cc: ppvpn@nortelnetworks.com Message-id: <00ac01c33c9b$e09a1e60$07436e0a@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_f7CAJk3Ewm6bWyjKI7WEUA)" X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta1.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: This is a multi-part message in MIME format. --Boundary_(ID_f7CAJk3Ewm6bWyjKI7WEUA) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT What happened to ppvpn wg? My colleagues' e-mail and mine are always rejected? especially during the days prior to the 57th IETF meeting. Could you please help address this problem? Thank you very much! ----- Original Message ----- From: "Mail Delivery Subsystem" To: Sent: Friday, June 27, 2003 6:23 PM Subject: Warning: could not send message for past 1 hour > ********************************************** > ** THIS IS A WARNING MESSAGE ONLY ** > ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** > ********************************************** > > The original message was received at Fri, 27 Jun 2003 05:23:29 -0400 (EDT) > from ertpsms1.nortelnetworks.com [47.234.0.31] > > ----- The following addresses had transient non-fatal errors ----- > > > ----- Transcript of session follows ----- > 451 4.4.1 reply: read error from zrchb175.us.nortel.com. > ... Deferred: Connection reset by zrchb175.us.nortel.com. > Warning: message still undelivered after 1 hour > Will keep trying until message is 1 day old > --Boundary_(ID_f7CAJk3Ewm6bWyjKI7WEUA) Content-type: application/octet-stream; name=ATT00143.dat Content-disposition: attachment; filename=ATT00143.dat Content-Transfer-Encoding: quoted-printable Reporting-MTA: dns; zrtps0kk.us.nortel.com Received-From-MTA: DNS; ertpsms1.nortelnetworks.com Arrival-Date: Fri, 27 Jun 2003 05:23:29 -0400 (EDT) Final-Recipient: RFC822; ppvpn@zrchb175.us.nortel.com Action: delayed Status: 4.4.2 Remote-MTA: DNS; zrchb175.us.nortel.com Diagnostic-Code: SMTP; 451 4.4.1 reply: read error from = zrchb175.us.nortel.com. Last-Attempt-Date: Fri, 27 Jun 2003 06:23:32 -0400 (EDT) Will-Retry-Until: Sat, 28 Jun 2003 05:23:29 -0400 (EDT) --Boundary_(ID_f7CAJk3Ewm6bWyjKI7WEUA) Content-type: message/rfc822; name="Consult about draft-behringer-mpls-vpn-auth-02.txt.eml" Return-path: Received: from ertpsms1.nortelnetworks.com (ertpsms1.nortelnetworks.com [47.234.0.31]) by zrtps0kk.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5R9NTp24672 for ; Fri, 27 Jun 2003 05:23:29 -0400 (EDT) Received: from mta0.huawei.com ( [61.144.161.2]) by ertpsms1.nortelnetworks.com with SMTP (MailShield v1.5); Fri, 27 Jun 2003 05:26:51 -0400 Received: from l04955 (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HH4000QBV5SAB@mta0.huawei.com> for ppvpn@nortelnetworks.com; Fri, 27 Jun 2003 17:17:53 +0800 (CST) Date: Fri, 27 Jun 2003 17:18:07 +0800 From: lidefeng Subject: Consult about draft-behringer-mpls-vpn-auth-02.txt To: "Michael H. Behringer" , Jim Guichard , Pedro Roque Marques Cc: ppvpn@nortelnetworks.com Message-id: <000901c33c8d$06199120$07436e0a@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=Windows-1252 X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] Content-Transfer-Encoding: 7BIT Hi, In Section 4 Extranet VPN Processing of draft-behringer-mpls-vpn-auth-02.txt,it states that "There are typically two types of Extranets that can be defined using the [RFC2547] architecture; Central Services Extranet and Distributed Extranet." I can't figure out the scenarios of the two types of Extranets,especially the topology,Could you please clarify them to me with the illustration of topology of the two types of Extranets. Sincerely Yours Defeng Li Huawei Technologies +86-10-82882343 lidefeng@huawei.com --Boundary_(ID_f7CAJk3Ewm6bWyjKI7WEUA)-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Fri Jun 27 15:18:15 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15776 for ; Fri, 27 Jun 2003 15:17:59 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5RJ12i25633 for ; Fri, 27 Jun 2003 15:01:02 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5RJ0wm23366 for ; Fri, 27 Jun 2003 15:00:58 -0400 (EDT) From: "Jim Guichard" To: "lidefeng" , "Michael H. Behringer" , "Pedro Roque Marques" Cc: Subject: RE: Consult about draft-behringer-mpls-vpn-auth-02.txt Date: Fri, 27 Jun 2003 14:53:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: <000901c33c8d$06199120$07436e0a@HUAWEI.COM> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-SMTP-HELO: ams-iport-1.cisco.com X-SMTP-MAIL-FROM: jguichar@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: ams-iport-1.cisco.com [144.254.74.5] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7bit Hi, (1) Central services extranet is basically a hub site which imports a bunch of spoke routes but exports "central service" routes that are imported by the spokes. Typically the spokes do not have direct connectivity, or connectivity via the hub. (2) Distributed extranet is basically the import and export of routes between different VPNs e.g Enterprise x & y import each others routes. Hope this helps. Jim > >-----Original Message----- > >From: lidefeng [mailto:lidefeng@huawei.com] > >Sent: Friday, June 27, 2003 5:18 AM > >To: Michael H. Behringer; Jim Guichard; Pedro Roque Marques > >Cc: ppvpn@nortelnetworks.com > >Subject: Consult about draft-behringer-mpls-vpn-auth-02.txt > > > > > >Hi, > > > >In Section 4 Extranet VPN Processing of > >draft-behringer-mpls-vpn-auth-02.txt,it states that "There are > >typically two > >types of Extranets that can be defined using the [RFC2547] architecture; > >Central Services Extranet and Distributed Extranet." > > > >I can't figure out the scenarios of the two types of Extranets,especially > >the topology,Could you please clarify them to me with the illustration of > >topology of the two types of Extranets. > > > >Sincerely Yours > > > >Defeng Li > >Huawei Technologies > >+86-10-82882343 > >lidefeng@huawei.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Sat Jun 28 15:52:13 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01612 for ; Sat, 28 Jun 2003 15:52:13 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5SJosD18143 for ; Sat, 28 Jun 2003 15:50:55 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5SJoqs13982 for ; Sat, 28 Jun 2003 15:50:52 -0400 (EDT) Message-Id: <3.0.1.32.20030628154550.01878088@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 28 Jun 2003 15:45:50 -0400 To: ewgray@GraIyMage.com, tnadeau@cisco.com From: jcucchiara@mindspring.com Subject: Re: WG last call on LSR and LDP MIB modules - setting dates Cc: "'Ash, Gerald R (Jerry), ALABS'" , "'Wijnen, Bert (Bert)'" , "'Loa Andersson'" , "'MPLS WG'" , ppvpn@nortelnetworks.com, ewgray@GraIyMage.com In-Reply-To: <3EF348C8.46EF6EBB@GraIyMage.com> References: <02f301c33691$5ba16ed0$ed472ca1@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SMTP-HELO: barry.mail.mindspring.net X-SMTP-MAIL-FROM: jcucchiara@mindspring.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: barry.mail.mindspring.net [207.69.200.25] X-LYRIS-Message-Id: Hi Eric, At 01:47 PM 6/20/03 -0400, Eric Gray wrote: >Tom and others, > > This discussion seems skewed a bit because of different perspectives that people >are speaking from. > > First of all, it is not the case that a protocol specification must necessarily define >counters and knobs for every detail of how the protocol should be managed. It is >often the case that people would prefer this to be the case, however, requiring it to >be the case would be a sure fire way to delay specification of protocol standards >well beyond some window of utility for a standard - meaning that placing too many >barriers in the way of defining standards leads to de facto standards. I would have to agree with this sentiment. One aspect of the LDP Specification was the use of TLVs. Using TLVs and defining them so clearly, made writing the LDP-MIB straightforward. Many of the objects come directly from the TLVs. Also, this approach allows the protocol to be extensible which is also good. As new TLVs are added, so to can new MIB Module(s). > > For example, in this discussion, what exactly is it that LDP _should_ have defined >to support the requirements that Jerry points out? I do not think that the protocol >should be involved in the business of keeping track of the enabled status of potential >protocol peers - it should be sufficient from a protocol perspective to know whether a >protocol peer is currently visible. And this is reflected in the mplsLdpPeerTable of the LDP-MIB. Additionally, an NMS (SNMP Manager) can display an LPD Session-based topology by querying each Agent/LSR and then each Peer to build up such a topology. > > Also, the protocol specification should not specify what happens to protocol >management data (counters and knobs) during the period in which the protocol >itself is not active - except to the extent that proper protocol behavior absolutely >depends on such specification. > > My sense is that it is perfectly within the purview of a management specification >to make statements about this kind of behavior as long as such statements are not >actually incompatible with underlying protocol specifications. It would then be up >to implementers to determine whether or not their implementation supports these >capabilities. Agreed. > > And it is equally reasonable to assert that specifying required behaviors may >be the task of some subsequent management specification. In the same way that >requiring full manageability of a protocol can unnecessarily delay the protocol >specification process, requiring complete satisfaction of evolving management >requirements in current management specifications can unnecessarily delay the >management specification process. Very astute statements above. In point of fact, the LDP-MIB's one and only goal is to support the LDP Specification. 4 years, and 4 MIB Modules later (not to mention draft-ietf-mpls-tc-mib-07.txt) and several MIB doctor reviews and 3 working group last calls later, I believe that it does this. Adding additional requirements would indeed delay this MIB, or worse, cause it to be put in the dustbin. MIBs, by their nature, are added to in the form of MIB Modules, and that can certainly be done with additional requirements. -Joan > > My 2 cents worth... > >-- >Eric Gray > >"Thomas D. Nadeau" wrote: > >> >> > Tom, >> > >> > > the MIBs need to be wrapped up ASAP and ... >> > > we are well on this track. >> > >> > Good, hopefully by IETF-57, in order to avoid 'sending them >> > to the dust-bin' as Bert has suggested. >> > >> > > To address your statement about requirements, >> > > as discussed previously offline with yourself >> > > and the MIB co-authors, >> > >> > There is about a one-year history/archive of posts to the >> > lists regarding these requirements. >> > >> > > many of the requirements you listed below require >> > > changes to the LDP protocol itself. >> > >> > Which of the 3 LDP requirements constitute 'many' that need >> > LDP changes? >> >> All of the requirements you listed below with >> the exception of the ones pertaining to VPN. >> >> > Obviously we're not proposing LDP protocol changes. Also, >> > the requirements I-D does not propose specific MIB >> > extensions, *in order to avoid past discussions of why >> > specific extensions won't work*. Step-1 is to make sure the >> > requirements are understood, and then step-2 is to decide how >> > to meet them. >> >> Of course you aren't proposing specific changes to >> anything. What we are saying is that is what you need to >> do in order to accomplish what you want in this case. The >> LDP MIB is not a place for redefining how LDP works. >> >> > Joan has suggested (I believe for requirements R1 and R2) 'a >> > MIB which stores LDP counter information in a history table'. >> > That's a step-2 in the right direction. Furthermore, Adrian >> > has suggested that 'instances of entities' is a concept that >> > has been handled in MIBs before and could be added in an >> > optional way so that implementations did not have to maintain >> > persistent information, but can choose to. >> >> This is not something that should go into the existing >> LDP MIB because the LDP protocol does not support the >> counters/concepts required to count these things regardless >> of what has been suggested. If you look at the specific details >> of what is being proposed in the draft (which I and others have >> done numerous times now) they CANNOT be achieved with >> the current standard LDP. >> >> > As to R3, it should be clear, a MIB should be straightforward. >> > >> > > I suggest that you consult with >> > > other SPs in the WG on these requirements to make sure >> > > that they are consistent. I personally have not been hearing >> > > any of these requirements from other SPs that participate >> > > in the MPLS WG. >> > >> > So that signifies the death-knell pronouncement from the >> > self-appointed OAM/MIB-czar? Perhaps the famous 25 pro-VCCV >> > SPs you often quote (but who never speak for themselves) can >> > attest to the MPLS-MIBs perfection/no-more-requirements-needed? >> > >> > There has been no opposition to the requirements R1-R5 we've >> > been stating for a long time (except, consistently, from you). >> >> I have not read any emails that claimed support for >> or acknowledged these requirements either. >> >> > > I suggest that you direct your requirements to the >> > > authors of the LDP specifications and propose >> > > extensions/additions there first because the MIBs >> > > cannot manage what the protocols will not provide. >> > >> > We're not proposing any changes to LDP. As above, Joan is >> > suggesting approaches to R1 & R2. R3 clearly requires no >> > protocol changes. >> >> So then go ahead and propose a MIB based on those >> changes. There is nothing preventing you or anyone else >> on the co-author list of the draft in question from doing >> this. >> >> > > The remaining requirements you listed >> > > below apply specifically to the PPVPN-MPLS-VPN MIB and not >> > > to the base MPLS MIBs which are in WG last call presently. >> > >> > R3 and R4 need to be addressed, have been there a long time, >> > and do not have to wait until last call to be discussed/progressed. >> >> And these will be addressed in the PPVPN MPLS VPN MIB >> when Harmen and I get around to editing the MIB, assuming there >> is consensus to make these additions. And as you can see, I >> have been a little busy with the base MIBs for the last >> few months. *) >> >> --Apparently self-appointed OAM/MIB-czar >> >> >> > Jerry >> > >> > > -----Original Message----- >> > > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> > > Sent: Wednesday, June 18, 2003 1:43 PM >> > > To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG >> > > Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; >> > > Chung, Li-Jin W, ALABS; ppvpn@nortelnetworks.com >> > > Subject: RE: WG last call on LSR and LDP MIB modules - setting dates >> > > >> > > >> > > Bert, Loa, All, >> > > >> > > I'd like to follow up on Wai Sum's comments below, and >> > > encourage that high-priority MPLS-MIB problems/requirements >> > > identified through extensive testing be addressed in the MPLS >> > > MIB modules. >> > > >> > > The MPLS MIB problems/requirements are identified in >> > > http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt, >> > > and are critical operator requirements stemming from >> > > detailed lab testing by Li Chung and others at AT&T. >> > > MPLS-VPNs aren't going to operate as well as needed until and >> > > unless these requirements are met. It is expected that >> > > operators wishing to use the same MPLS MIBs would have >> > > similar concerns. >> > > >> > > The I-D does not propose specific MIB extensions based on the >> > > requirements. Rather, such extensions are left to the MIB >> > > designers, in order to avoid past discussions of why specific >> > > extensions won't work. But so far there is no help or >> > > response from MIB designers on how to meet the requirements, >> > > even though the problems have been identified on email lists >> > > for more than one year. >> > > >> > > Here is a summary of requirements (R1,R2,R3 LDP related; >> > > R4,R5 VPN related): >> > > >> > > R1. It is required to capture the signaling usage/performance >> > > of the LDP Entities, as well as the traffic usage/performance >> > > of the LDP Sessions. R2. It is required to ensure persistency >> > > of information in the LDP-MIB Entity Table and Entity >> > > Statistics Table, whenever an LDP Entity is disabled and then >> > > re-enabled. R3. It is required that a count be reported of >> > > mplsNumVrfRouteMaxThreshExceeded notification when the >> > > operator-defined VRF maximum route threshold is exceeded. R4. >> > > It is required to have an explicit mapping between VRF, RD, >> > > and RT in the mplsVpnVrfRouteTargetTable table. R5. It is >> > > required to track the number of BGP prefixes on the PE-CE >> > > link, and that the BGP neighbor maximum-prefix limit on the >> > > PE-CE link be used to limit the number of eBGP routes >> > > injected in the VRF. >> > > >> > > I agree with Harmen Van der Linde, "We need to get this MPLS >> > > MIB module, together with the MPLS LDP and MPLS VPN modules, >> > > standardized ASAP. There is a critical need for these MPLS >> > > MIB modules for management of MPLS-enabled networks, which >> > > are currently being deployed by many service providers." >> > > >> > > Bert threatened at IETF-56 to start over on MPLS MIBs if not >> > > finished by IETF-57. >> > > >> > > We need the MPLS MIB designers to meet critical requirements >> > > and complete ASAP. >> > > >> > > Thanks, >> > > Jerry >> > > > > From bounce-ppvpn-132618@lyris.nortelnetworks.com Sun Jun 29 12:34:01 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01716 for ; Sun, 29 Jun 2003 12:34:01 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5TGX4B25153 for ; Sun, 29 Jun 2003 12:33:04 -0400 (EDT) Received: from lyris.nortelnetworks.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5TGX1V04279 for ; Sun, 29 Jun 2003 12:33:01 -0400 (EDT) Message-ID: <20030629163113.47274.qmail@web102.bizmail.yahoo.com> Date: Sun, 29 Jun 2003 09:31:13 -0700 (PDT) From: Joseph Laria Subject: draft-ietf-ppvpn-vr-mib-05 To: internet-drafts@ietf.org Cc: ppvpn@nortelnetworks.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1679104002-1056904273=:44282" X-SMTP-HELO: web102.bizmail.yahoo.com X-SMTP-MAIL-FROM: jlaria@levelstream.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: web102.bizmail.yahoo.com [216.136.172.122] X-LYRIS-Message-Id: --0-1679104002-1056904273=:44282 Content-Type: text/plain; charset=us-ascii Content-Id: Content-Disposition: inline Hi, Attached is the latest version of draft-ietf-ppvpn-vr-mib. The Virtual Router MIB is a work item of the Provider Provisioned Virtual Private Networks (L3) Working Group. Title: Virtual Router Management Information Base Using SMIv2 Author(s): Elwin Stelzer, Sam Hancock, Benson Schliesser, Joeseph Laria Filename: draft-ietf-ppvpn-vr-mib-05.txt Pages: XX Date: June 2003 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). --0-1679104002-1056904273=:44282 Content-Type: text/plain; name="draft-ietf-ppvpn-vr-mib-05.txt" Content-Description: draft-ietf-ppvpn-vr-mib-05.txt Content-Disposition: inline; filename="draft-ietf-ppvpn-vr-mib-05.txt" INTERNET-DRAFT Elwin Stelzer draft-ietf-ppvpn-vr-mib-05.txt Sam Hancock Expires: December 2003 Corona Networks, Inc. Benson Schliesser SAVVIS Communications Joseph Laria Level Stream Research June 2003 Virtual Router Management Information Base Using SMIv2 1.0 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. 2.0 Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). 3.0 Table of Contents 1.0 Status of this Memo 2.0 Abstract 3.0 Table of Contents 4.0 Terminology 5.0 Introduction 6.0 The SNMP Network Management Framework 7.0 Overview of the Virtual Router MIB 7.1 SNMP Contexts for Management for Virtual Routers 7.2 VR Indexing 7.3 Creation and Deletion of VRs 7.4 Administrative and Operational Status of VRs 7.5 Binding interfaces to a VR 7.6 Setting per VR limits 7.7 Per VR Statistics 7.8 Traps 8.0 Sample VR MIB Configuration Scenario 8.1 Creation of a VR 9.0 Definition of the Virtual Router MIB 10.0 Summary for Sub-IP Area 10.1 Where does it fit in the Picture of the Sub-IP Work 10.2 Why is it Targeted at this WG 10.3 Justification 11.0 Security Considerations 12.0 Acknowledgments 13.0 References 14.0 Authors' Addresses 4.0 Terminology This document uses terminology defined in [PPVPN-FW] and [PPVPN-VR]. 5.0 Introduction This memo defines a MIB for the Virtual Router [PPVPN-VR, PPVPN-VR-AS] model of Provider Provisioned VPNs [PPVPN-FW]. Following are the goals, in defining this MIB: - To have a means for Service Providers to provision VPN service for subscribers, at the PE device. - To make the agent-side implementation simple, by not modifying the existing standard MIBs. - Define all the gluing tables that are needed toward this end. 6.0 The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, which consists of RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [22]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 7.0 Overview of the Virtual Router MIB 7.1 SNMP Contexts for Management for Virtual Routers There is a need for a single agent to manage multiple Virtual Routers. The Architecture for describing Internet Management Frameworks [1] provides a way to support such cases. Managing multiple virtual routers requires that the PE management plane be subdivided into logical VR management domains. In the VR model of PPVPNs a single PE device may contain many virtual routers. Different management entities SHOULD be able to manage specific virtual routers and associated services. The Service Provider MUST be able to manage all virtual routers and associated services. Using SNMP contexts to group a collection of management information provides the following benefits: (1) Uses a standard framework defined by the IETF, allowing the product to remain flexible to all implementations of virtual router devices. (a) Use SNMPv2c Community String's (b) Use SNMPv3 contextName's (2) Prevents vendors from having to modify the standard MIBs, allowing the implementation to remain standards compliant. (3) Provides a framework that will work for RIP, OSPF, IS-IS, BGP, IP-FORWARDING, MPLS, and any other MIB that can be administratively grouped with a VR. The SNMP context for the Virtual Router instance can be specified in the VrConfigTable. The VrContextName columnar object is used to set the SNMPv2c Community String or the SNMPv3 contextName for a given VR. A virtual router context represents the set of MIB objects that could be administratively grouped within a VR. For example, each VR would maintain its own instance of routing protocol MIB tables. However, the ADMIN context would contain single instances of objects and tables that pertain to system wide configuration such as the Entity, Interfaces, and ATM MIBs. A management system using the SNMP context of a particular virtual router MUST be able to manage the virtual router without disrupting other virtual routers in the same PE device. For example, a PE can be subdivided into two 2 VRs running the OSPF routing protocol. Each VR will maintain a unique instance of the OSPF-MIB. Therefore, the ospfAreaTable of VR-A is distinct from the ospfAreaTable of VR-B. +-----------------------------------------------------------------+ | +------------------------------------------------------------+ | | | SNMP entity (including Engine, Applications) | | | | | | | | example contextNames: | | | | | | | | "vr01" "vr09" "admin" | | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context=vr01 | | context=vr09 | | context=admin | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | OSPF MIB | | | | OSPF MIB | | | | VR MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | BGP MIB | | | | BGP MIB | | | | ATM MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | IP MIB | | | | IP MIB | | | | ENTITY MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | other MIB | | | | other MIB | | | | IF MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | ... | | ... | | ... | | | +-----------------------------------------------------------------+ Filtering mechanisms based on the SNMP context of a particular virtual router may implemented to allow different management entities to manage those objects and services provisioned the “Admin” context. 7.2 VR Indexing While the standard protocol MIB tables are instantiated in the context specified using SNMP contexts, there may be tables that are defined with the VRID as index. The VRID is of local significance to a particular PE device, and need not be globally unique. Thus a particular VRID value assigned to a VR in one PE device may indicate a different VR in another PE device. The VRID has an Unsigned32 value, and this value is assigned by the management station. To aid the management station in assigning a VRID without conflict, the management station can get the 'NextAvailableVRID' from the PE device. A SNMP manager SHOULD NOT assume global significance of any VRID value other than 0. For those MIB tables instantiated in the virtual router context, indexing can only be assumed unique for that particular VR. However those indices in the "ADMIN" context are unique across the entire system, including all VRs. 7.3 Creation and Deletion of VRs The VR Config Table is used for this purpose. This is a read-create table and adding an entry into this table will create a VR. Removing an entry from this table marks the deletion of a VR. VRID 0 is assigned to the Administrative VR, which exists by default, and need not be created. Deletion of the Administrative VR will not be permitted. The VRID of the Administrative VR (VRID 0) should be a reserved VRID number. VRID 0 could be termed the "null VR" and it could be the context that manages the resource pool of unattached interfaces. Routing would then not exist in the context of Administrative VR. 7.4 Administrative and Operational Status of VRs VRs can be administratively turned down. When this is done, no packet forwarding via the VR takes place. VrOperStatus denotes the operational status of a VR. Currently the VrOperStatus is expected to change along the VrAdminStatus unless an error condition exists. 7.5 Binding interfaces to a VR Interfaces are bound to a VR, using vrIfConfigTable. This is a read-write table, and note that interfaces are not created through this table. The vrIfConfigTable MIB table is used to indicated the relationship between interfaces and virtual router IDs. For each interface present in the system, this table is used to provide the mapping from IfIndex to a unique VR. The table show which interfaces are “attached or connected” to a virtual router. An interface can not be attached to more than one VR. The "Admin" VR could be used to manage the resource pool of unattached interfaces. However interfaces would not be attached to VRID 0. 7.6 Setting per VR limits VRs consume resources on a device, and hence the following parameters defined in vrConfigTable are used to specify an upper bound of resource utilization: VrMaxRoutes - Specify the maximum number of routes that will be permitted in VR. This includes all routes, such as the statically configured routes, and the routes learnt via dynamic routing protocols. 7.7 Per VR Statistics In addition to those statistics available through the VR instantiated MIB tables, there are some per-VR statistics available through vrStatTable. 7.8 Traps This memo defines that VrUp and VrDown traps are generated just after VrOperStatus leaves, or just before it enters, the down state, respectively. (1) A transition into the down state will occur when an error is detected on a VR instance. (2) Departing the down state generally indicates that the VR is going to up, which is considered a "healthy" state. An exception to the above generation of VrUp/VrDown traps on changes in VrOperStatus, occurs when an VR is "flapping", i.e., when it is rapidly oscillating between the up and down states. If traps were generated for each such oscillation, the network and the network management system would be flooded with unnecessary traps. In such a situation, the agent should limit the rate at which it generates traps. This memo defines that enabling and disabling the VR traps is achieved by setting the VrTrapEnable to true(1) or false(2), respectively. By default, this object should have the value true(1). 8.0 Sample VR MIB Configuration Scenario 8.1 Creation of a VR Creating VR instances can be achieved using the following example. (1) Get the next available Virtual Router Id using the NextAvailableVrId, to create a VR: Using a context with 'read' access for system level entities. GetRequest { NextAvailableVrId.0 } Response { NextAvailableVrId.0 = 5555 } (2) In VrConfigTable, create VR Instance using VrRowStatus: Using a context with 'read-write' access for system level entities SetRequest { VrRowStatus.5555 createAndGo(4), VrName.5555 "BigTelcoVR", VrContextName.5555 "vr5555", VrTrapEnable.5555 true(1), VrAdminStatus.5555 up(1) } 9.0 Definition of the Virtual Router MIB -- -- VIRTUAL-ROUTER-MIB -- VIRTUAL-ROUTER-MIB DEFINITIONS ::= BEGIN IMPORTS InterfaceIndex FROM IF-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP FROM SNMPv2-CONF experimental, Unsigned32, OBJECT-TYPE, MODULE-IDENTITY, TimeTicks, NOTIFICATION-TYPE FROM SNMPv2-SMI TruthValue, DisplayString, RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC; virtualRouterMIB MODULE-IDENTITY LAST-UPDATED "200301311200Z" ORGANIZATION "IETF PPVPN WG" CONTACT-INFO " Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3832 Email: elwinietf@yahoo.com Samuel Hancock Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3800 Ext 421 Email: hancoc_s@yahoo.com Benson Schliesser SAVVIS Communications 1 Savvis Parkway Town and Country, MO 63017 USA Phone: +1-314-628-7036 Email: bensons@savvis.net Joseph Laria Level Stream Research Wilmington, MA 01887 USA Phone: +1-978-884-3537 Emain: jlaria@levelstream.com " DESCRIPTION "The MIB is the definition of the managed objects for the Virtual Router." REVISION "200306011200Z" DESCRIPTION "VR-MIB Draft of the IETF PPVPN WG" ::= { experimental xxxx } -- To be assigned -- -- Textual conventions -- VrId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Virtual Router Identifier. VRID 0 is reserved for the Administrative VR and cannot be used to create VR's. " SYNTAX Unsigned32 VpnIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "RFC2685: The global VPN Identifier format is: 3 octet VPN authority Organizationally Unique Identifier followed by 4 octet VPN index identifying VPN according to OUI" SYNTAX OCTET STRING(SIZE (0..7)) -- -- Node definitions -- vrMIBObjects OBJECT IDENTIFIER ::= { virtualRouterMIB 1 } vrConfig OBJECT IDENTIFIER ::= { vrMIBObjects 1 } vrConfigScalars OBJECT IDENTIFIER ::= { vrConfig 1 } vrConfigNextAvailableVrId OBJECT-TYPE SYNTAX VrId MAX-ACCESS read-only STATUS current DESCRIPTION "The next available Virtual Router Id (index). This object provides a hint for the vrID value to use when administratively creating a new vrConfigEntry. A GET of this object returns the next available vrId value to be used to create an entry in the associated vrConfigTable; or zero, if no valid vrId value is available. A value of zero(0) indicates that it is not possible to create a new vrConfigEntry This object also returns a value of zero when it is the lexicographic successor of a varbind presented in an SNMP GETNEXT or GETBULK request, for which circumstance it is assumed that ifIndex allocation is unintended. Successive GETs will typically return different values, thus avoiding collisions among cooperating management clients seeking to create table entries simultaneously. Unless specified otherwise by its MAX-ACCESS and DESCRIPTION clauses, an object of this type is read-only, and a SET of such an object returns a notWritable error." ::= { vrConfigScalars 1 } vrConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF VrConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is for creating the new Virtual Routers." ::= { vrConfig 2 } vrConfigEntry OBJECT-TYPE SYNTAX VrConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries in this table can be added/deleted using the vrRowStatus." INDEX { vrId } ::= { vrConfigTable 1 } VrConfigEntry ::= SEQUENCE { vrId VrId, vrRowStatus RowStatus, vrName DisplayString, vrContextName DisplayString, vrTrapEnable TruthValue, vrMaxRoutes Unsigned32, vrAdminStatus INTEGER, vrVpnId VpnIdentifier, vrRpTrigger Unsigned32 } vrId OBJECT-TYPE SYNTAX VrId MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique id of this virtual router instance. A Virtual Router cannot not be created with vrId = 0. VRID 0 is reserved for the Administrative VR. " ::= { vrConfigEntry 1 } vrRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status column has three defined values: - `active', which indicates that the conceptual row is available for use by the managed device; - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row." ::= { vrConfigEntry 2 } vrName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The Name of the Virtual Router.. " ::= { vrConfigEntry 3 } vrContextName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The SNMPv2 Community String or SNMPv3 contextName denotes the VR 'context' and is used to logically separate the MIB management. RFC2571 and RFC2737 describe this approach." ::= { vrConfigEntry 4 } vrTrapEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This objects is used to enable the generation of the VrUp and VrDown traps. true(1) - VR Traps Enabled false(2) - VR Traps Disabled" DEFVAL { true } ::= { vrConfigEntry 5 } vrMaxRoutes OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the maximum number of routes that this VR can support. The default value is 4 Gig (meaning unlimited)." DEFVAL { 4294967295 } ::= { vrConfigEntry 6 } vrAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), testing(3), unknown(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the Virtual Router." DEFVAL { down } ::= { vrConfigEntry 7 } vrVpnId OBJECT-TYPE SYNTAX VpnIdentifier MAX-ACCESS read-create STATUS current DESCRIPTION "The Virtual Private Network Identifier of the Virtual Router." ::= { vrConfigEntry 8 } vrRpTrigger OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The Routing Protocol Triggers on the Virtual Router. This can be used to initiate or shutdown routing protocols on a VR. The 32 bits are divided into: 16 bits of RP bitmap, 15 bits reserved (0), and 1 bit of action-code. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |RP bitmap (MSB)| +-+-+-+-+-+-+-+-+ |RP bitmap (LSB)| +-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+ |*| Reserved | +-+-+-+-+-+-+-+-+ *=action-code The RP bitmap specify the RP that is to be initiated or shutdown. Multiple RPs can be acted on simultaneously. Also, individual RPs can be brought up in steps, which should not affect the RPs that were running. Action-code specify what needs to be done for the RPs in the RP bitmap. The actions are: initiate or shutdown. The running status of the RP shall be available in the VR stats table's vrRpStatus, which has a similar format, but represent the status." ::= { vrConfigEntry 9 } vrStat OBJECT IDENTIFIER ::= { vrMIBObjects 2 } vrStatScalars OBJECT IDENTIFIER ::= { vrStat 1 } vrConfiguredVRs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRs configured on this network element." ::= { vrStatScalars 1 } vrActiveVRs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRs that are active on the network element. These are VRs for which the vrStatOperationalStatus = up(1)" ::= { vrStatScalars 2 } vrStatTable OBJECT-TYPE SYNTAX SEQUENCE OF VrStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains statistics for the Virtual Router." ::= { vrStat 2 } vrStatEntry OBJECT-TYPE SYNTAX VrStatEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table a per vrId." INDEX { vrId } ::= { vrStatTable 1 } VrStatEntry ::= SEQUENCE { vrStatRouteEntries Unsigned32, vrStatFIBEntries Unsigned32, vrStatUpTime TimeTicks, vrOperStatus INTEGER, vrRpStatus Unsigned32, vrRouterAddressType InetAddressType, vrRouterAddress InetAddress } vrStatRouteEntries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of routes for this VR." ::= { vrStatEntry 1 } vrStatFIBEntries OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of FIB Entries for this VR." ::= { vrStatEntry 2 } vrStatUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time in (in hundredths of a second) since this VR entry has been operational." ::= { vrStatEntry 3 } vrOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), unknown(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational state of the Virtual Router." ::= { vrStatEntry 4 } vrRpStatus OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "List of Routing Protocols on this VR." ::= { vrStatEntry 5 } vrRouterAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "Router Address Type of this VR." ::= { vrStatEntry 6 } vrRouterAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Router Address of this VR. It is derived from one of the interfaces. If loopback interface is present, the loopback interface address can be used. However, loopback interface is optional." ::= { vrStatEntry 7 } vrIfConfig OBJECT IDENTIFIER ::= { vrMIBObjects 3 } vrIfConfigScalars OBJECT IDENTIFIER ::= { vrIfConfig 1 } vrIfConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF VrIfConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is for configuring VR Interfaces." ::= { vrIfConfig 2 } vrIfConfigEntry OBJECT-TYPE SYNTAX VrIfConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in this table correspond to the entries in the ifTable that apply to the Virtual Router." INDEX { vrId, vrIfId } ::= { vrIfConfigTable 1 } VrIfConfigEntry ::= SEQUENCE { vrIfId InterfaceIndex, vrIfConfigRowStatus RowStatus } vrIfId OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "Virtual Router Interface Index." ::= { vrIfConfigEntry 1 } vrIfConfigRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION " This object is used to create, delete or modify a row in this table." ::= { vrIfConfigEntry 2 } -- ********************************************************************* -- Module Traps/Notifications -- ********************************************************************* vrNotificationsPrefix OBJECT IDENTIFIER ::= { vrMIBObjects 4 } vrNotifications OBJECT IDENTIFIER ::= { vrNotificationsPrefix 0 } vrUp NOTIFICATION-TYPE OBJECTS { vrRowStatus } STATUS current DESCRIPTION "This notification is generated when the specified VR is about to initialized or change the status from down to up." ::= { vrNotifications 1 } vrDown NOTIFICATION-TYPE OBJECTS { vrRowStatus } STATUS current DESCRIPTION "This notification is generated when the specified VR is about to go down." ::= { vrNotifications 2 } vrMaxRoutesExceeded NOTIFICATION-TYPE OBJECTS { vrRowStatus, vrMaxRoutes, vrStatRouteEntries } STATUS current DESCRIPTION "This notification is generated when the specified VR has exceeded the maximum number of routes specified" ::= { vrNotifications 3 } -- ********************************************************************* -- Module Compliance/Conformance Statements -- ********************************************************************* vrConformance OBJECT IDENTIFIER ::= { virtualRouterMIB 2 } vrCompliances OBJECT IDENTIFIER ::= { vrConformance 1 } vrMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities that implement the VIRTUAL-ROUTER-MIB. Implementation of this MIB is strongly recommended for any platform targeted for a carrier-class environment." MODULE -- this module MANDATORY-GROUPS { vrConfigGroup, vrStatGroup, vrIfGroup, vrNotificationGroup } ::= { vrCompliances 1 } vrGroups OBJECT IDENTIFIER ::= { vrConformance 2 } vrConfigGroup OBJECT-GROUP OBJECTS { vrRowStatus, vrName, vrContextName, vrTrapEnable, vrMaxRoutes, vrAdminStatus, vrVpnId, vrRpTrigger, vrConfigNextAvailableVrId } STATUS current DESCRIPTION "A collection of attributes that support provisioning of a virtual router." ::= { vrGroups 1 } vrStatGroup OBJECT-GROUP OBJECTS { vrConfiguredVRs, vrActiveVRs, vrStatRouteEntries, vrStatFIBEntries, vrStatUpTime, vrOperStatus, vrRpStatus, vrRouterAddress, vrRouterAddressType } STATUS current DESCRIPTION "A collection of attributes that contain stats about the virtual router." ::= { vrGroups 2 } vrIfGroup OBJECT-GROUP OBJECTS { vrIfConfigRowStatus } STATUS current DESCRIPTION "A collection of attributes that support provisioning of a virtual router interfaces." ::= { vrGroups 3 } vrNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { vrUp, vrDown, vrMaxRoutesExceeded } STATUS current DESCRIPTION "A collection of traps that are supported by the VR." ::= { vrGroups 4 } END 10.0 Summary for Sub-IP Area This document defines a MIB that provides a way to provision VPNs at the PE devices employing the Virtual Router model. 10.1 Where does it fit in the Picture of the Sub-IP Work This work fits in the PPVPN Working Group. 10.2 Why is it Targeted at this WG The WG is chartered with developing Provider Provisioned VPN solutions. This draft contributes to this. 10.3 Justification The WG should consider this document since it provides a means to configure and manage Virtual Router based PPVPNs. 11.0 Security Considerations The Administrative VR provides visibility into and control over multiple VPNs. As such, security considerations for implementations of the Administrative VR and associated control plane(s) are critical to the security of the VPNs supported on each PE device. Use of any vrContextName MUST be allowed in the Administrative VR. Additional authentication and security mechanisms SHOULD be used for SNMP access in the Administrative VR. VRs other than the Administrative VR MUST NOT have access to other VRÈås Instantiated MIBs, and MAY have access to their own instantiated MIBs. In VRs other than the Administrative VR, access to that VRÈås instantiated MIBs MAY be permitted via that VRÈås vrContextName. Use of any vrContextName other than that assigned to the accessed VR MUST result in an error, and implementations SHOULD provide a logging mechanism for such events. 12.0 Acknowledgments Special thanks to Joan Cucchiara for providing valuable comments on this MIB. 13.0 References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996 [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, January 1998. [16] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [17] Ouldbrahim's VR draft, "Network Based IP VPN Architecture Using Virtual Routers", draft-ouldbrahim-vpn-vr-01.txt [18] RFC 2685, "Virtual Private Networks Identifier" [19] RFC 2764, "A Framework for IP Based Vitual Private Networks" [20] RFC 2547bis, "BGP/MPLS VPNs", draft-rosen-rfc2547bis-03.txt [21] "BGP/IPsec VPN", draft-declercq-bgp-ipsec-vpn-00.txt [22] RFC 2667, "IP Tunnel MIB" [PPVPN-FW] R. Callon, et al., "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", draft-ietf-ppvpn-framework-06.txt, October 2002. [PPVPN-VR] P. Knight, et al., "Network based IP VPN Architecture using Virtual Routers", draft-ietf-ppvpn-vpn-vr-03.txt, July 2002. [PPVPN-VR-AS] A. Nagarajan, et al., "Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches", draft-ietf-ppvpn-as-vr-00.txt, August 2002. 14.0 Authors' Addresses Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3832 Email: elwinietf@yahoo.com Samuel Hancock Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 USA Phone: +1-408-519-3800 Ext 421 Email: hancoc_s@yahoo.com Benson Schliesser SAVVIS Communications 1 Savvis Parkway Town and Country, MO 63017 USA Phone: +1-314-628-7036 Email: bensons@savvis.net Joseph Laria Level Stream Research Wilmington, MA 01887 USA Phone: +1-978-884-3537 Emain: jlaria@levelstream.com --0-1679104002-1056904273=:44282-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 30 03:50:23 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04434 for ; Mon, 30 Jun 2003 03:50:07 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5U7n5U09230 for ; Mon, 30 Jun 2003 03:49:05 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5U7n2A01501 for ; Mon, 30 Jun 2003 03:49:02 -0400 (EDT) Date: Mon, 30 Jun 2003 15:45:47 +0800 From: lidefeng Subject: How about the agenda for the 57th IETF ppvpn wg meeting ? To: l3vpn@ietf.org, l2vpn@ietf.org, ppvpn@nortelnetworks.com Message-id: <003801c33edb$9eae7860$07436e0a@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=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: 7BIT Hi, all The 57th IETF meeting is forthcoming,but I don't know the agenda of PPVPN wg yet, and I wrote e-mails to the maillist and some important individuals to inquire the arrangement,but they are always rejected by the server or something called Lyris Listmanager, I don't know the reason. I just registered to the maillist of l3vpn and l2vpn today. and I have a concern about the operation of vpn relevant wg, I wonder what happened to ppvpn wg,and what is the arrangement in the following future. Who can clarify the question? TIA & Regards Sincerely Yours Defeng Li Huawei Technologies +86-10-82882343 lidefeng@huawei.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 30 04:12:20 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05252 for ; Mon, 30 Jun 2003 04:12:05 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5U8BVU18244 for ; Mon, 30 Jun 2003 04:11:32 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5U8BTK07640 for ; Mon, 30 Jun 2003 04:11:29 -0400 (EDT) Message-ID: <2AE8BAEBBD9EFD41A0AECD89806A9BADB6E19A@PLJY108A.my001.siemens.net> From: Edmund Kueh / ICN Malaysia To: ppvpn@nortelnetworks.com Subject: RE: unsubscribe Date: Mon, 30 Jun 2003 16:11:48 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: pljy103a.siemens.com.my X-SMTP-MAIL-FROM: Edmund.Kueh@siemens.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [203.121.32.11] X-LYRIS-Message-Id: Greetings Edx -----Original Message----- From: Naveen Gowda [mailto:naveenietf@yahoo.com] Sent: Tuesday, June 17, 2003 10:21 AM To: ppvpn@nortelnetworks.com Subject: unsubscribe unsubscribe __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ##################################################################################### Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. SIEMENS MALAYSIA SDN BHD and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. ##################################################################################### From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 30 07:56:27 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13366 for ; Mon, 30 Jun 2003 07:56:26 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UBtqU07878 for ; Mon, 30 Jun 2003 07:55:53 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5UBtnl11531 for ; Mon, 30 Jun 2003 07:55:49 -0400 (EDT) Message-Id: <200306301153.HAA12559@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-applicability-guidelines-02.txt Date: Mon, 30 Jun 2003 07:53:30 -0400 Sender: nsyracus@cnri.reston.va.us X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@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 : Guidelines of Applicability Statements for PPVPNs Author(s) : J. Sumimoto et al. Filename : draft-ietf-ppvpn-applicability-guidelines-02.txt Pages : 10 Date : 2003-6-27 This document plays a role of guidelines to assist development of applicability statements for each specific Layer 2 and Layer 3 PPVPN approach. It provides a check-list which consists of metrics, each of which is intended to clearly point out what must be evaluated and written in each approach specific applicability statement document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-applicability-guidelines-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-applicability-guidelines-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-applicability-guidelines-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: <2003-6-27150756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ppvpn-applicability-guidelines-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ppvpn-applicability-guidelines-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150756.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 30 11:00:46 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29282 for ; Mon, 30 Jun 2003 11:00:31 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UEqJU00632 for ; Mon, 30 Jun 2003 10:52:20 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5UEqGn18569 for ; Mon, 30 Jun 2003 10:52:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: agendas for the Vienna wg meetings Date: Mon, 30 Jun 2003 10:49:34 -0400 Message-ID: <6B25E083A064374CA3D2FAB305CFAF7A03C4E3@m-va-bsod03.add0.masergy.com> Thread-Topic: agendas for the Vienna wg meetings Thread-Index: AcM+2/bO3E2e/3rbTzmrZliGjAaDxwAOPJfQ From: "Rick Wilder" To: "lidefeng" , , , X-SMTP-HELO: m-va-bsod03.add0.masergy.com X-SMTP-MAIL-FROM: rwilder@masergy.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mail.masergy.com [64.47.12.2] X-LYRIS-Message-Id: Content-Transfer-Encoding: quoted-printable Defeng and all participants, There will be two meetings in Vienna to address L2 and L3 VPN work. I expect the agendas for these two meetings to be posted to the ppvpn, l2vpn, and l3vpn lists by the end of this week.=20 I am sorry you have been having difficulties with the mail list. People at Nortel have been notified and are looking into this. Anyone with specific error messages or debug information documenting a problem with the list can forward it to John Pugh [johnpugh@nortelnetworks.com]. He has offered to try and help. Rick -----Original Message----- From: lidefeng [mailto:lidefeng@huawei.com]=20 Sent: Monday, June 30, 2003 1:46 AM To: l3vpn@ietf.org; l2vpn@ietf.org; ppvpn@nortelnetworks.com Subject: How about the agenda for the 57th IETF ppvpn wg meeting ? Hi, all The 57th IETF meeting is forthcoming,but I don't know the agenda of PPVPN wg yet, and I wrote e-mails to the maillist and some important individuals to inquire the arrangement,but they are always rejected by the server or something called Lyris Listmanager, I don't know the reason. I just registered to the maillist of l3vpn and l2vpn today. and I have a concern about the operation of vpn relevant wg, I wonder what happened to ppvpn wg,and what is the arrangement in the following future. Who can clarify the question? TIA & Regards Sincerely Yours Defeng Li Huawei Technologies +86-10-82882343 lidefeng@huawei.com From bounce-ppvpn-132618@lyris.nortelnetworks.com Mon Jun 30 14:12:05 2003 Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09226 for ; Mon, 30 Jun 2003 14:12:04 -0400 (EDT) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UIBV302419 for ; Mon, 30 Jun 2003 14:11:32 -0400 (EDT) Received: from zrchb175.us.nortel.com (zrchb175..us.nortel.com [47.103.121.54]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id h5UIBSF20036 for ; Mon, 30 Jun 2003 14:11:28 -0400 (EDT) Date: Mon, 30 Jun 2003 14:03:50 -0400 From: Dave McDysan Subject: MPLS 2003 Conference - Submission Deadline Extended to July 3rd To: ppvpn@nortelnetworks.com, l2vpn@ietf.org, l3vpn@ietf.org, Mpls , Pwe3 , Ccamp Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: pmesmtp01.wcom.com X-SMTP-MAIL-FROM: dave.mcdysan@mci.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: QUOTED-PRINTABLE The MPLS 2003 Conference will be held in Washington D.C. from October= 26 through October 28. This year=92s conference will include but is not = limited to topics such as: - MPLS as a convergence technology - MPLS network management and operational issues - Provisioning and migration strategies - MPLS in multi-AS networks - L2 VPNs (pseudo-wire, VPLS, and other) - L3 VPNs (BGP/MPLS, IPSec interworking, virtual routers, and other) - Scalability and performance - Traffic engineering and QoS - Network processor architectures for next generation applications - Testing MPLS applications and performance - Network security - Disaster recovery - Reliability and graceful restart techniques - Optical Integration and challenges The Program Committee of MPLS 2003 is soliciting presentation proposa= ls for this conference. If you wish to suggest a particular topic or a contribution please send a one page long proposal, including speaker= =92s contact details to the attention of the Technical Program Committee a= t TPC@mpls2003.com by July 3, 2003 (this will= be the last extension.) See www.mpls2003.com for m= ore details. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of coveri= ng cutting-edge topics. Presentations from the vendor, service provider = and user community are solicited on new technologies and operational experience.